Overview of Software Processes: Waterfall, Evolutionary, and Component-Based Models, Thesis of System Programming

Download Overview of Software Processes: Waterfall, Evolutionary, and Component-Based Models and more Thesis System Programming in PDF only on Docsity!

Chapter Two

Software Processes & Models

Objectives

• To introduce software process models
• To describe three generic process models and when they may be used
• To describe outline process models for requirements engineering, software

development, testing and evolution

• To explain the Rational Unified Process model

Generic software process models

• The waterfall model
  • Separate and distinct phases of specification and development.
• Evolutionary development
  • Specification, development and validation are interleaved.
• Component-based software engineering
  • The system is assembled from existing components rather than developing from

scratch.

• There are many variants of these models e.g. formal development where a waterfall- like process is used but the specification is a formal specification that is refined through several stages to an implementable design.

Waterfall model

Waterfall model phases ….CONT’D

• Operation and maintenance: Normally 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 units and enhancing the system’s services as new

requirements are discovered.

• In principle, the result of each phase is one or more documents that are approved (‘signed off’). The

following phase should not start until the previous phase has finished. In practice, these stages overlap and

feed information to each other. During design, problems with requirements are identified; during coding

design problems are found and so on.

• Because of the costs of producing and approving documents, iterations are costly and involve significant

rework. Therefore, after a small number of iterations, it is normal to freeze parts of the development, such

as the specification, and to continue with the later development stages. Problems are left for later

resolution, ignored or programmed around. This premature freezing of requirements may mean that the

system won’t do what the user wants. It may also lead to badly structured systems as design problems are

circumvented by implementation tricks

Waterfall model phases ….CONT’D

• Because of the costs of producing and approving documents, iterations are costly and involve significant rework. Therefore, after a small number of iterations, it is normal to freeze parts of the development, such as the specification, and to continue with the later development stages. Problems are left for later resolution, ignored or programmed around. This premature freezing of requirements may mean that the system won’t do what the user wants. It may also lead to badly structured systems as design problems are circumvented by implementation tricks
• During the final life-cycle phase (operation and maintenance), the software is put into use. Errors and omissions in the original software requirements are discovered. Program and design errors emerge and the need for new functionality is identified. The system must therefore evolve to remain useful. Making these changes (software maintenance) may involve repeating previous process stages.
• Hence, the main drawback of the waterfall model is the difficulty of accommodating change after the process is underway (in progress). One phase has to be complete before moving onto the next phase.

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 an adequate system has been developed. 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

• 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 by adding new features proposed by the customer.

2. Throw-away prototyping

• 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 Prepared by Bekre 10

Evolutionary development….CONT’D

Evolutionary development….CONT’D

1. 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.

2. Systems are often poorly structured Continual change tends to corrupt the software structure. Incorporating software

changes becomes increasingly difficult and costly.

• Applicability
  • For small or medium-size interactive systems (up to 500,000 lines of code);
  • For parts of large systems (e.g. the user interface);
  • For short-lifetime systems.
• The problems of evolutionary development become particularly acute for large, complex, long-lifetime 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.

Component-based software engineering….CONT’D

• Based on systematic reuse where systems are integrated from existing components or COTS (Commercial- off-the-shelf) systems.
• Process stages
• Component analysis Given the requirements specification, a search is made for components to implement that specification. Usually, there is no exact match, and the components that may be used only provide some of the functionality required.;
• Requirements modification During this stage, the requirements are analysed using information about the components that have been discovered. They are then modified to reflect the available components. Where modifications are impossible, the component analysis activity may be re-entered to search for alternative solutions;

Component-based software engineering….CONT’D

• Component-based software engineering has the obvious advantage of reducing

the amount of software to be developed and so reducing cost and risks.

• It usually also leads to faster delivery of the software.
• However, requirements compromises are inevitable and this may lead to a

system that does not meet the real needs of users.

• Furthermore, some control over the system evolution is lost as new versions of

the reusable components are not under the control of the organisation using

them.

Reuse-oriented development

Process iteration….CONT’D

• The essence of iterative processes is that the specification is developed in

conjunction with the software. However, this conflicts with the procurement

model of many organisations where the complete system specification is part of

the system development contract.

• In the incremental approach, there is no complete system specification until the

final increment is specified.

• This requires a new form of contract, which large customers such as

government agencies may find difficult to accommodate.

Incremental delivery

• The waterfall model of development requires customers for a system to commit to a set of requirements before design begins and the designer to commit to particular design strategies before implementation. Changes to the requirements require rework of the requirements, design and implementation. However, the separation of design and implementation should lead to well-documented systems that are amenable to change.
• By contrast, an evolutionary approach to development allows requirements and design decisions to be delayed but also leads to software that may be poorly structured and difficult to understand and maintain.
• Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality.
• User requirements are prioritised and the highest priority requirements are included in early increments.
• Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.