Software Development Life Cycle
Models
A
software development life cycle model is an abstract representation of a
software process. Each process model represents a process from a particular
perspective, and thus provides only partial information about that process.
There are several models for such processes, each describing approaches to a
variety of tasks or activities that take place during the process. Some people
consider a life cycle model a more general term and a software development
process a more specific term. For example, there are many specific software
development processes that ‘fit’ the spiral life cycle model. ISO 12207 is an
ISO standard for software life cycle processes. It aims to be the standard that
defines all the tasks required for developing and maintaining software.
A process model for software engineering is chosen based on the nature of the project
and application, the methods and tools to be used, and the controls and deliverables
that are required. Several models exist to streamline the development process. Each
one has its pros and cons, and it’s up to the development team to adopt the most appropriate one for the project. Sometimes a combination of the models may be more
suitable. Some of the models are:
• The waterfall model
• Incremental model
• Prototyping model
• Spiral model
• Evolutionary development
A process model for software engineering is chosen based on the nature of the project
and application, the methods and tools to be used, and the controls and deliverables
that are required. Several models exist to streamline the development process. Each
one has its pros and cons, and it’s up to the development team to adopt the most appropriate one for the project. Sometimes a combination of the models may be more
suitable. Some of the models are:
• The waterfall model
• Incremental model
• Prototyping model
• Spiral model
• Evolutionary development
The waterfall model
This model is also known as linear sequential model. The first published model, suggests a systematic, sequential approach5 to software development that begins at the system level and progresses through analysis, design, coding, testing, and support. Figure 1.1 illustrates the waterfall model for software engineering. In a strict Waterfall model, after each phase is finished, it proceeds to the next one. Reviews may occur before moving to the next phase which allows for the possibility of changes (which may involve a formal change control process). Reviews may also be employed to ensure that the phase is indeed complete; the phase completion criteria are often referred to as a “gate” that the project must pass through to move to the next phase. Waterfall discourages revisiting and revising any prior phase once it’s complete. This “inflexibility” in a pure Waterfall model has been a source of criticism by supporters of other more “flexible” models.
This model is also known as linear sequential model. The first published model, suggests a systematic, sequential approach5 to software development that begins at the system level and progresses through analysis, design, coding, testing, and support. Figure 1.1 illustrates the waterfall model for software engineering. In a strict Waterfall model, after each phase is finished, it proceeds to the next one. Reviews may occur before moving to the next phase which allows for the possibility of changes (which may involve a formal change control process). Reviews may also be employed to ensure that the phase is indeed complete; the phase completion criteria are often referred to as a “gate” that the project must pass through to move to the next phase. Waterfall discourages revisiting and revising any prior phase once it’s complete. This “inflexibility” in a pure Waterfall model has been a source of criticism by supporters of other more “flexible” models.
Different stages of the waterfall model:
I. Requirements: The system’s services, constraints and goals are established
by consultation with system users. They are then defined in detail and serve as
a system specification.
II. Design: The system design process partitions the requirements to either
hardware or software systems. It establishes an overall system architechture.
Software design involves identifying and describing the fundamental software
system abstraction and their relationships.
III. Implementation: In this step, software engineers actually program the code
for the project.
IV. Verification: The individual program units or programs are integrated and
tested as a complete system to ensure that the software requirements have
been met. After testing, the software system is delivered to the customer.
V. Maintenance: This is the longest life cycle phase. The system is installed and
put into practical use. Maintenance involves correcting errors which were not
discovered in earlier stages of the life cycle, improving the implementation of
system and enhancing the system’s services as new requirements are
discovered.
Advantages of waterfall model
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than cost or schedule
Disadvantages of waterfall model
• All requirements must be known upfront
• Deliverables created for each phase are considered frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of software development – iterations
of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the system (until it may be too late)
I. Requirements: The system’s services, constraints and goals are established
by consultation with system users. They are then defined in detail and serve as
a system specification.
II. Design: The system design process partitions the requirements to either
hardware or software systems. It establishes an overall system architechture.
Software design involves identifying and describing the fundamental software
system abstraction and their relationships.
III. Implementation: In this step, software engineers actually program the code
for the project.
IV. Verification: The individual program units or programs are integrated and
tested as a complete system to ensure that the software requirements have
been met. After testing, the software system is delivered to the customer.
V. Maintenance: This is the longest life cycle phase. The system is installed and
put into practical use. Maintenance involves correcting errors which were not
discovered in earlier stages of the life cycle, improving the implementation of
system and enhancing the system’s services as new requirements are
discovered.
Advantages of waterfall model
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than cost or schedule
Disadvantages of waterfall model
• All requirements must be known upfront
• Deliverables created for each phase are considered frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of software development – iterations
of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the system (until it may be too late)
Incremental Model
In this development model, product is built as sequence of
incremental builds. Each build has collection of code and are designed, coded
and tested. This is the evolutionary software. Here, partial implementation of
a total system is constructed. Then slowly add increased functionality. The
incremental modal prioritizes requirements of the system and then implements
them in groups. Each subsequent release of the system adds function to the
previous release, until all designed functionality has been implemented.
Advantages of Incremental Model
• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
• Risk of changing requirements is reduced
Disadvantages of Incremental Model
• Requires good planning and design
• Requires early definition of a complete and fully functional system to allow
for the definition of increments
• Well-defined module interfaces are required (some will be developed long
before others)
• Total cost of the complete system is not lower
Advantages of Incremental Model
• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
• Risk of changing requirements is reduced
Disadvantages of Incremental Model
• Requires good planning and design
• Requires early definition of a complete and fully functional system to allow
for the definition of increments
• Well-defined module interfaces are required (some will be developed long
before others)
• Total cost of the complete system is not lower
Prototyping Model
This prototype is used when customer and developer is not sure
about the product. This is also known as working or paper design. The
prototyping model (Figure 2.5) begins with requirements gathering. Developer
and customer meet and define the overall objectives for the software,
identify whatever requirements are known, and outline areas where
further definition is mandatory. A “quick design” then occurs. The quick design
focuses on a representation of those aspects of the software that will be
visible to the customer/user (e.g., input approaches and output formats). The
quick design leads to the construction of a prototype. The prototype is
evaluated by the customer/user and used to refine requirements for the software
to be developed. Iteration occurs as the prototype is tuned to satisfy the
needs of the customer, while at the same time enabling the developer to better
understand what needs to be done. Ideally, the prototype serves as a mechanism
for identifying software requirements. If a working prototype is built, the
developer attempts to use existing program fragments or applies tools (e.g.,
report generators, window managers) that enable working programs to be
generated quickly.
Advantage of Prototype Model
§ Customers can “see” the
system requirements as they are being gathered
§ Developers learn from
customers
§ A more accurate end
product
§ Unexpected requirements
accommodated
§ Allows for flexible
design and development
§ Steady, visible signs of
progress produced
§ Interaction with the
prototype stimulates awareness of additional needed
functionality
functionality
Disadvantage of Prototype Model
• Tendency to abandon structured program development for “code
development
• Bad reputation for “quick
• Overall maintainability may be overlooked
• The customer may want the prototype delivered.
• Process may continue forever (scope creep)
• Tendency to abandon structured program development for “code
development
• Bad reputation for “quick
• Overall maintainability may be overlooked
• The customer may want the prototype delivered.
• Process may continue forever (scope creep)
Spiral Model
The
spiral model, originally proposed by Boehm [BOE88], is an evolutionary software
process model that couples the iterative nature of prototyping with the
controlled and systematic aspects of the linear sequential model. It provides
the potential for rapid development of incremental versions of the software.
Using the spiral model, software is developed in a series of incremental
releases. During early iterations, the incremental release might be a paper
model or prototype. During later iterations, increasingly more complete
versions of the engineered system are produced. This model consists if four
quadrant in each cycle.
1.
Determine objectives, alternatives and constraints
• Objectives: functionality, performance, hardware/software interface, critical
success factors, etc.
• Alternatives: build, reuse, buy, sub-contract, etc.
• Constraints: cost, schedule, interface, etc.
2. Evaluate alternatives, identify and resolve risks
• Study alternatives relative to objectives and constraints
• Identify risks (lack of experience, new technology, tight schedules, poor
process, etc.
• Resolve risks (evaluate if money could be lost by continuing system
development
3. Develop next-level product Typical activates:
• Create a design
• Review design
• Develop code
• Inspect code
• Test product
4. Plan next phase Typical activities
• Develop project plan
• Develop configuration management plan
• Develop a test plan
• Develop an installation plan
• Objectives: functionality, performance, hardware/software interface, critical
success factors, etc.
• Alternatives: build, reuse, buy, sub-contract, etc.
• Constraints: cost, schedule, interface, etc.
2. Evaluate alternatives, identify and resolve risks
• Study alternatives relative to objectives and constraints
• Identify risks (lack of experience, new technology, tight schedules, poor
process, etc.
• Resolve risks (evaluate if money could be lost by continuing system
development
3. Develop next-level product Typical activates:
• Create a design
• Review design
• Develop code
• Inspect code
• Test product
4. Plan next phase Typical activities
• Develop project plan
• Develop configuration management plan
• Develop a test plan
• Develop an installation plan
Advantages of Spiral Model
• Provides early indication of insurmountable risks, without much cost
• Users see the system early because of rapid prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently
Disadvantage of Spiral Model
• Time spent for evaluating risks too large for small or low-risk projects
• Time spent planning, resetting objectives, doing risk analysis and prototyping
may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during non-development phase activities
• May be hard to define objective, verifiable milestones that indicate readiness
to proceed through the next iteration
• Provides early indication of insurmountable risks, without much cost
• Users see the system early because of rapid prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently
Disadvantage of Spiral Model
• Time spent for evaluating risks too large for small or low-risk projects
• Time spent planning, resetting objectives, doing risk analysis and prototyping
may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during non-development phase activities
• May be hard to define objective, verifiable milestones that indicate readiness
to proceed through the next iteration
Evolutionary Development
Evolutionary development is based on the idea of developing an initial
implementation, exposing this to user comment and refining it through many versions
until as adequate system has been developed (fig 1.5.1). Specification, development
and validation activities are interleaved rather than separate, with rapid feedback
across activities.
Evolutionary development is based on the idea of developing an initial
implementation, exposing this to user comment and refining it through many versions
until as adequate system has been developed (fig 1.5.1). Specification, development
and validation activities are interleaved rather than separate, with rapid feedback
across activities.
There are two fundamental types of evolutionary development:
1. Exploratory development where the objective of the process is to work with the customer to explore their requirements and deliver a final system. The development starts with the parts of the system that are understood. The system evolves ab adding new features proposed by the customer.
2. Throwaway Prototype where the objective of the evolutionary development process is to understand the customer’s requirements and hence develop a better requirements definition for the system. The prototype concentrates on experimenting with the customer requirements that are poorly understood.
1. Exploratory development where the objective of the process is to work with the customer to explore their requirements and deliver a final system. The development starts with the parts of the system that are understood. The system evolves ab adding new features proposed by the customer.
2. Throwaway Prototype where the objective of the evolutionary development process is to understand the customer’s requirements and hence develop a better requirements definition for the system. The prototype concentrates on experimenting with the customer requirements that are poorly understood.
An evolutionary approach to software development is often more
effective than the waterfall approach in producing systems that meet the
immediate needs of customers. The advantage of a software process that is based
on an evolutionary approach is that the specification can be developed
incrementally. As users develop a better understanding of their problem, this
can be reflected in the software system. However, from an engineering and
management perspective, the evolutionary approach has two problems:
i. The process is not visible Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.
ii. Systems are often poorly structured Continual change tends to corrupt the software structure. Incorporating software changes becomes increasingly difficult and costly.
For small and medium-sized systems (upto 500,000 lines of code) the evolutionary
approach is the best approach to development. The problems of evolutionary
development become particularly acute for large, complex, long-life-time systems,
where different teams develop different parts of the system. It is difficult to establish
a stable system architecture using this approach, which makes it hard to integrate
contributions from the teams.
i. The process is not visible Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.
ii. Systems are often poorly structured Continual change tends to corrupt the software structure. Incorporating software changes becomes increasingly difficult and costly.
For small and medium-sized systems (upto 500,000 lines of code) the evolutionary
approach is the best approach to development. The problems of evolutionary
development become particularly acute for large, complex, long-life-time systems,
where different teams develop different parts of the system. It is difficult to establish
a stable system architecture using this approach, which makes it hard to integrate
contributions from the teams.
For
large systems, a mixed process that incorporates the best features of the
waterfall
and the evolutionary development models. This may involve developing a throwaway
prototype using an evolutionary approach to resolve uncertainties in the system
specification.
and the evolutionary development models. This may involve developing a throwaway
prototype using an evolutionary approach to resolve uncertainties in the system
specification.
Advantages
§ Deals constantly with changes
§ Provides quickly an initial version of the
system
§ Involves all development teams
Disadvantages
§ Quick fixes may be involved
§ “Invisible” process, not well-supported by
documentation
§ The system’s structure can be corrupted by
continuous change
No comments:
Post a Comment