Notes: Software Life-Cycles

When 24th Sept 98

Where Mitchell Library Glasgow

What ITIL Guide Software Life Cycle Support by Brian… ISBN 0-11-330559-1
Gilb Principles of software engineering management
( didn’t have Boehm Software Engineering Economics L )
Learning tree course notes for 340 S/W Project planning & management

Notes

ITIL guide is generally a plea for the infrastructure managers to be involved in the up-front requirements spec, planning and execution of s.w projects, plus the use of s/w lifecycles during the maintenance phases of projects.

Life cycle is primary tool of the project manager input to the planning process

Method is not lifecycle, but has heavy impact as they often dictate the order in which some tasks are executed

Choice of lifecycles is influenced by following factors

·  type of system being built: batch, online, interactive, real time, function strong (eg a CAD/CAM tool), data strong (eg a RDBMS based commercial tp system)
influence include whether the approach is top-down, bottom up etc

·  degree of uncertainty in the requirements, highly uncertain favours the spiral

·  interfaces with other systems/developments and the impact of their lifecycle where sharing of schedules is a factor

·  expected degree of change the system will have to absorb

·  the development timeframe

·  the size and complexity of the development

Selection should be based on

·  Are lifecycle processes clearly enough defined so they can be communicated to all who need to know them

·  Are QA and project management activities to support the L-C defined

·  Is the lifecycle usable on a project of the size & complexity. Neither to much overhead for small projects to bear nor insufficient in scope of techniques and models to control the complexity

·  Is the lifecycle productive enough for the environemnt, for example are tools available to support the usage, are the L_C risks understood and covered, do the skills in its use sufficiently accessible

·  Is the whole lifecycle covered or will more that one L-C be required

There really is only one Life-Cycle, the waterfall model. There really are only two ways of looking at it.

The" long drop" monolithic process that concludes each phase for the whole project scope before moving on.

The "sequence of small drops" - shooting-rapids ? where all phases are completed for focused elements of the overall scope. And the whole drop is repeated often.

The evolutionary model runs the rapids in with several work-streams in parallel, the spiral fits either long or short drop but adds extra activity into the phases up-front to deal with uncertainty and risk.

Prototyping is the creation of a MODEL of what the final system will do. It is a model because one or more of the following is true: some attributes may be fully engineered while others will be entirely absent. The whole thing may be engineered but the scale may be different from the final deliverable. The most widely understood prototypes in s/w are painting user interfaces and report layouts. This is appropriate as it is a key part of the contractual elements of the base-lined requirements specification.

SPIRAL Life Cycle boehm's model for addressing risks in projects by building risk management into the front of each stage.
The Spiral uses the classic waterfall in each phase, starting with the priority features.

Phase 1-3 are intended to remove uncertainty during the requirements and design stage so that all construction activities can proceed without doubt or disruption.
The spiral model is well suited to environments where requirements are volatile because of the use of risk analysis and the incorporation of prototyping in each of the phases.

PHASE 1 Planning

Initiation determine objectives, explore alternatives, constraints

Risk assessment do risk analysis, prototype ideas, evaluate and resolve risks

Development define the concept of operations ( IEEE term for user requirements )

Planning generate requiremets plan and life-cycle plan

PHASE 2 REQUIREMENTS

I examine the requirements plan, determine objectives, search for alternatives, understand constraints

RA do phase risk analysis, prototype ideas, evaluate and resolve risks

Development software requirements analysis and definition

Planning develop the design plan

PHASE 3 PRODUCT DESIGN

Initiation examine the development plan, determine objectives, look for alternatives, understand constraints

Risk Assessment do phase risk analysis, prototype ideas, evaluate and resolve risks

Development software product design, design verification and if required validation

Planning Design, Integration and test planning

PHASE 4 DETAILED DESIGN, CODE, TEST, INTEGRATION, ACCEPTANCE & IMPLEMENTATION.

Initiation examine design integration and test plans, understand objectives and alternatives and constraints

Risk asssessment do phase risk analysis, prototype ideas, evaluate and resolve risks

Development carry out detailed design, code and unit test, integration test, user acceptance test and implementation

Plan for next phase (¿maintenance¿)

Evolutionary & Rapid Prototyping Models: issues for evolutinary model in determining when to involve infrastructure management groups. For example the 1st delivery maywell not have any capacity & performance implications, but the final delivery will be after the right time to address capacity & performance.

Evolutionary implies using the waterfall for the smallest deliverable elements of the project with several streams active in parallel

Rapid proptotype implies AnalysisàSpecifyàDesignàimplementàtestàSpecifyàdesign…. Note that test is post implement.

Simon Harris Page 3 Created on 08/03/01 19:34
C:\windows\TEMP\FrontPageTempDir\lifecycles.doc