Software engineering by Ian Sommerville Notes, Cheat Sheet of Introduction to Software Engineering

Download Software engineering by Ian Sommerville Notes and more Cheat Sheet Introduction to Software Engineering in PDF only on Docsity!

Chapter 2 – Software Processes

Week 2

Topics covered

 Software process models

o (^) Waterfall model o (^) Integration and configuration model o (^) Incremental development

 Process activities

o (^) Software specification o (^) Software design and implementation o (^) Software validation o (^) Software evolution

 Coping with change

o (^) Software prototyping

 Process improvement

04/05/2024 Chapter 2 Software Processes 2

Plan-driven and agile processes

 Plan-driven processes are processes where all the

process activities are planned, and progress is

measured against this plan.

 In agile processes, planning is incremental, and it is

easier to change the process to reflect changing

customer requirements.

 In practice, most practical processes include elements of

both plan-driven and agile approaches.

 There are no right or wrong software processes.

Software process models

The waterfall model

Waterfall model phases

 There are separate identified phases in the waterfall model:

• (^) Requirements analysis and definition
• (^) System and software design
• (^) Implementation and unit testing
• (^) Integration and system testing
• (^) Operation and maintenance

 The main drawback of the waterfall model is the difficulty of

accommodating change after the process is underway. In

principle, a phase must be completed before moving onto the

next phase.

Waterfall model phases – Activities, cont.

 Implementation and unit testing

• (^) During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.

 Integration and system testing

• (^) 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.

Waterfall model phases – Activities, cont.

 Operation and maintenance

• (^) Normally, this is the longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors that 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.

Waterfall model problems

 Embedded systems where the software must interface

with hardware systems.

• (^) Because of the inflexibility of hardware, it is not usually possible to delay decisions on the software’s functionality until it is being implemented

 Critical systems where there is a need for extensive

safety and security analysis of the software specification

and design.

• (^) In these systems, the specification and design documents must be complete so that this analysis is possible. Safety related problems in the specification and design are usually very expensive to correct at the implementation stage.

Advantages and Disadvantages of waterfall model

Incremental development benefits

 The cost of accommodating changing customer

requirements is reduced.

• (^) The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model.

 It is easier to get customer feedback on the development

work that has been done.

• (^) Customers can comment on demonstrations of the software and see how much has been implemented.

 Early delivery and deployment of useful software to the

customer is possible.

• (^) Customers are able to use and gain value from the software earlier than is possible with a waterfall process.

Incremental development problems

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

 System structure tends to degrade as new increments

are added.

• (^) Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. Incorporating further software changes becomes increasingly difficult and costly. To reduce structural degradation and general code messiness, agile methods suggest that you should regularly refactor (improve and restructure) the software.

Integration and configuration Model

 Based on software reuse where systems are integrated

from existing components or application systems.

 Reused elements may be configured to adapt their

behaviour and functionality to a user’s requirements

 Reuse is now the standard approach for building many

types of business system

• (^) Reuse covered in more depth in Chapter 15.

Types of reusable software

 Stand-alone application systems that are configured for

use in a particular environment.

 Collections of objects that are developed as a package

to be integrated with a component framework such

as .NET or Java Spring framework.

 Web services that are developed according to service

standards and which are available for remote invocation

over the internet.