Chapter 2 Software Processes 30102014 Chapter 2 Software

Chapter 2 – Software Processes 30/10/2014 Chapter 2 Software Processes 1

Topics covered ² Software process models ² Process activities ² Coping with change 30/10/2014 Chapter 2 Software Processes 2

The software process ² A structured set of activities required to develop a software system. ² Many different software processes but all involve: § Specification – defining what the system should do; § Design and implementation – defining the organization of the system and implementing the system; § Validation – checking that it does what the customer wants; § Evolution – changing the system in response to changing customer needs. 30/10/2014 Chapter 2 Software Processes 3

Software process descriptions ² When we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities. ² When describing processes, it is also important to describe who is involved, what is produced, and conditions that influence the sequence of activities. 30/10/2014 Chapter 2 Software Processes 4

Software process descriptions ² Process descriptions may also include: § Products, which are the outcomes of a process activity; For example, the outcome of the activity of architectural design may be a model of the software architecture. § Roles, which reflect the responsibilities of the people involved in the process; Examples of roles are project manager, configuration manager, and programmer. § Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced. For example, before architectural design begins, a precondition may be that the consumer has approved all requirements; after this activity is finished, a postcondition might be that the UML models describing the architecture have been reviewed. 30/10/2014 Chapter 2 Software Processes 5

Plan-driven and agile processes ² Two types of software processes: ² Plan-driven processes are processes where all of the process activities are planned in advance 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. 30/10/2014 Chapter 2 Software Processes 6

Software process models 30/10/2014 Chapter 2 Software Processes 7

Software process models ² A software process model (sometimes called a Software Development Life Cycle or SDLC model) is a simplified representation of a software process. Each process model represents a process from a particular perspective and thus only provides partial information about that process. ² For example, a process activity model shows the activities and their sequence but may not show the roles of the people involved in these activities. 30/10/2014 Chapter 2 Software Processes 8

Software process models ² This course introduces a number of very general process models (sometimes called process paradigms) and presents these from an architectural perspective. That is, we see the framework of the process but not the details of process activities. ² These generic models are high-level, abstract descriptions of software processes that can be used to explain different approaches to software development. You can think of them as process frameworks that may be extended and adapted to create more specific software engineering processes. 30/10/2014 Chapter 2 Software Processes 9

Software process models ² The waterfall model § Plan-driven model. Separate and distinct phases of specification and development. ² Incremental development § Specification, development and validation are interleaved. May be plan-driven or agile. ² Integration and configuration § The system is assembled from existing configurable components. May be plan-driven or agile. ² In practice, most large systems are developed using a process that incorporates elements from all of these models. 30/10/2014 Chapter 2 Software Processes 10

Software process models ² There is no universal process model that is right for all kinds of software development. The right process depends on the customer and regulatory requirements, the environment where the software will be used, and the type of software being developed. ² In practice, most large systems are developed using a process that incorporates elements from all of these models. 30/10/2014 Chapter 2 Software Processes 11

The waterfall model Ø It presents the software development process as a number of stages, as shown in the following Figure. Ø Because of the cascade from one phase to another, this model is known as the waterfall model or software life cycle. Ø It is an example of a plan-driven process. 30/10/2014 Chapter 2 Software Processes 12

Waterfall model phases ² There are separate identified phases in the waterfall model: § § § 30/10/2014 Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance Chapter 2 Software Processes 13

Waterfall model phases ² Requirements analysis and definition § 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. ² System and software design § The systems design process allocates the requirements to either hardware or software systems. It establishes an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships. 30/10/2014 Chapter 2 Software Processes 14

Waterfall model phases ² 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. 30/10/2014 Chapter 2 Software Processes 15

Waterfall model phases ² 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. 30/10/2014 Chapter 2 Software Processes 16

Waterfall model phases ² In principle, the result of each phase in the waterfall model is one or more documents that are approved (“signed off”). The following phase should not start until the previous phase has finished. ² The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. 30/10/2014 Chapter 2 Software Processes 17

Waterfall model problems ² Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. § Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. § Few business systems have stable requirements. 30/10/2014 Chapter 2 Software Processes 18

Waterfall model problems ² The waterfall model is only appropriate for some types of system: § Embedded systems where the software has to 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. § Large software systems that are part of broader engineering systems developed by several partner companies. 30/10/2014 Chapter 2 Software Processes 19

Waterfall model problems ² The waterfall model is not the right process model in situations where informal team communication is possible and software requirements change quickly. ² Iterative development and agile methods are better for these systems. 30/10/2014 Chapter 2 Software Processes 20

Incremental development Ø Incremental development is based on the idea of developing an initial implementation, getting feedback from users and others, and evolving the software through several versions until the required system has been developed. Ø Specification, development, and validation activities are interleaved rather than separate, with rapid feedback across activities. 30/10/2014 Chapter 2 Software Processes 21

Incremental development ² Incremental software development, is better than a waterfall approach for systems whose requirements are likely to change during the development process. § This is the case for most business systems and software products. ² By developing the software incrementally, it is cheaper and easier to make changes in the software. § Each increment or version of the system incorporates some of the functionality that is needed by the customer. Generally, the early increments of the system include the most important or most urgently required functionality. § This means that the customer or user can evaluate the system at a relatively early stage in the development to see if it delivers what is required. 30/10/2014 Chapter 2 Software Processes 22

Incremental development benefits ² Incremental development has three major advantages over the waterfall model: § 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. § More rapid 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. 30/10/2014 Chapter 2 Software Processes 23

Incremental development problems ² The incremental approach has two 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. 30/10/2014 Chapter 2 Software Processes 24

Integration and configuration ² Based on software reuse where systems are integrated from existing components or COTS (Commercial-off-theshelf) 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. 30/10/2014 Chapter 2 Software Processes 25

Types of reusable software ² Three types of software components are frequently reused: § Stand-alone application systems (sometimes called COTS) 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 J 2 EE. § Web services that are developed according to service standards and which are available for remote invocation. 30/10/2014 Chapter 2 Software Processes 26

Reuse-oriented software engineering The figure shows a general process model for reuse-based development, based on integration and configuration. 30/10/2014 Chapter 2 Software Processes 27

Key process stages ² The stages in this process are: § § § 30/10/2014 Requirements specification Software discovery and evaluation Requirements refinement Application system configuration Component adaptation and integration Chapter 2 Software Processes 28

Key process stages ² Requirements specification § The initial requirements for the system are proposed. These do not have to be elaborated in detail but should include brief descriptions of essential requirements and desirable system features. ² Software discovery and evaluation § Given an outline of the software requirements, a search is made for components and systems that provide the functionality required. § Candidate components and systems are evaluated to see if they meet the essential requirements and if they are generally suitable for use in the system. 30/10/2014 Chapter 2 Software Processes 29

Key process stages ² Requirements refinement § During this stage, the requirements are refined using information about the reusable components and applications that have been discovered. The requirements are modified to reflect the available components, and the system specification is redefined. Where modifications are impossible, the component analysis activity may be reentered to search for alternative solutions. 30/10/2014 Chapter 2 Software Processes 30

Key process stages ² Application system configuration § If an off-the-shelf application system that meets the requirements is available, it may then be configured for use to create the new system. ² Component adaptation and integration § If there is no off-the-shelf system, individual reusable components may be modified and new components developed. These are then integrated to create the system. 30/10/2014 Chapter 2 Software Processes 31

Advantages and disadvantages ² Reduced costs and risks as less software is developed from scratch ² Faster delivery and deployment of system ² But requirements compromises are inevitable so system may not meet real needs of users ² Loss of control over evolution of reused system elements 30/10/2014 Chapter 2 Software Processes 32

Process activities 30/10/2014 Chapter 2 Software Processes 33

Process activities ² Real software processes are inter-leaved sequences of technical, collaborative and managerial activities with the overall goal of specifying, designing, implementing and testing a software system. ² The four basic process activities of specification, development, validation and evolution are organized differently in different development processes. ² For example, in the waterfall model, they are organized in sequence, whereas in incremental development they are interleaved. 30/10/2014 Chapter 2 Software Processes 34

The requirements engineering process 30/10/2014 Chapter 2 Software Processes 35

Software specification ² The process of establishing what services are required and the constraints on the system’s operation and development. ² The requirements engineering process aims to produce an agreed requirements document that specifies a system satisfying stakeholder requirements. ² Requirements are usually presented at two levels of detail. § End-users and customers need a high-level statement of the requirements; § System developers need a more detailed system specification. 30/10/2014 Chapter 2 Software Processes 36

Software specification ² There are three main activities in the requirements engineering process: § Requirements elicitation and analysis • What do the system stakeholders require or expect from the system? § Requirements specification • Requirements specification is the activity of translating the information gathered during requirements analysis into a document that defines a set of requirements. § Requirements validation • Checking the requirements for realism, consistency, and completeness. 30/10/2014 Chapter 2 Software Processes 37

Software design and implementation ² The process of converting the system specification into an executable system. ² Software design § Design a software structure that realises the specification; ² Implementation § Translate this structure into an executable program; ² The activities of design and implementation are closely related and may be inter-leaved. 30/10/2014 Chapter 2 Software Processes 38

A general model of the design process 30/10/2014 Chapter 2 Software Processes 39

Design activities ² Four activities that may be part of the design process for information systems are: § § 30/10/2014 Architectural design Database design Interface design Component selection and design Chapter 2 Software Processes 40

Design activities ² Architectural design, where you identify the overall structure of the system, the principal components (subsystems or modules), their relationships and how they are distributed. ² Database design, where you design the system data structures and how these are to be represented in a database. ² Interface design, where you define the interfaces between system components. ² Component selection and design, where you search for reusable components. If unavailable, you design how it will operate. 30/10/2014 Chapter 2 Software Processes 41

System implementation ² The software is implemented either by developing a program or programs or by configuring an application system. ² Design and implementation are interleaved activities for most types of software system. ² Programming is an individual activity with no standard process. ² Debugging is the activity of finding program faults and correcting these faults. 30/10/2014 Chapter 2 Software Processes 42

Software validation ² Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer. ² Involves checking and review processes and system testing. ² System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system. ² Testing is the most commonly used V & V activity. 30/10/2014 Chapter 2 Software Processes 43

Stages of testing 30/10/2014 Chapter 2 Software Processes 44

Testing stages ² Component testing § Individual components are tested independently; § Components may be functions or objects or coherent groupings of these entities. ² System testing § Testing of the system as a whole. Concerned with finding errors that result from unanticipated interactions between components and component interface problems. § Testing of emergent properties is particularly important. ² Customer testing § Testing with customer data to check that the system meets the customer’s needs. 30/10/2014 Chapter 2 Software Processes 45

Testing phases in a plan-driven software process (V-model) 30/10/2014 Chapter 2 Software Processes 46

Software evolution ² Software is inherently flexible and can change. ² As requirements change through changing business circumstances, the software that supports the business must also evolve and change. ² Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new. 30/10/2014 Chapter 2 Software Processes 47

System evolution 30/10/2014 Chapter 2 Software Processes 48

Coping with change 30/10/2014 Chapter 2 Software Processes 49

Coping with change ² Change is inevitable in all large software projects. § Business changes lead to new and changed system requirements § New technologies open up new possibilities for improving implementations § Changing platforms require application changes ² Change leads to rework so the costs of change include both rework (e. g. re-analysing requirements) as well as the costs of implementing new functionality 30/10/2014 Chapter 2 Software Processes 50

Reducing the costs of rework ² Two related approaches may be used to reduce the costs of rework: § Change anticipation, where the software process includes activities that can anticipate possible changes before significant rework is required. • For example, a prototype system may be developed to show some key features of the system to customers. § Change tolerance, where the process is designed so that changes can be accommodated at relatively low cost. • This normally involves some form of incremental development. Proposed changes may be implemented in increments that have not yet been developed. If this is impossible, then only a single increment (a small part of the system) may have be altered to incorporate the change. 30/10/2014 Chapter 2 Software Processes 51

Coping with changing requirements ² Two ways of coping with change and changing system requirements are: § System prototyping, where a version of the system or part of the system is developed quickly to check the customer’s requirements and the feasibility of design decisions. This approach supports change anticipation. § Incremental delivery, where system increments are delivered to the customer for comment and experimentation. This supports both change avoidance and change tolerance. 30/10/2014 Chapter 2 Software Processes 52

Software prototyping ² A prototype is an initial version of a system used to demonstrate concepts and try out design options. ² A prototype can be used in: § The requirements engineering process to help with requirements elicitation and validation; § In design processes to explore options and develop a UI design; § In the testing process to run back-to-back tests. 30/10/2014 Chapter 2 Software Processes 53

Benefits of prototyping ² Improved system usability. ² A closer match to users’ real needs. ² Improved design quality. ² Improved maintainability. ² Reduced development effort. 30/10/2014 Chapter 2 Software Processes 54

The process of prototype development 30/10/2014 Chapter 2 Software Processes 55

Prototype development ² The first stage for prototype development is to make the objectives. § These may be to develop the user interface, to develop a system to validate functional system requirements, or to develop a system to demonstrate the application to managers. ² The next stage in the process is to decide what to put into and, perhaps more importantly, what to leave out of the prototype system. § To reduce prototyping costs and accelerate the delivery schedule, you may leave some functionality out of the prototype, such as relaxing non-functional requirements, ignoring error handling, etc. ² The final stage of the process is prototype evaluation. 30/10/2014 Chapter 2 Software Processes 56

Throw-away prototypes ² Prototypes should be discarded after development as they are not a good basis for a production system: § It may be impossible to tune the system to meet non-functional requirements; § Prototypes are normally undocumented; § The prototype structure is usually degraded through rapid change; § The prototype probably will not meet normal organisational quality standards. 30/10/2014 Chapter 2 Software Processes 57

Incremental delivery ² 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. 30/10/2014 Chapter 2 Software Processes 58

Incremental development and delivery ² Once an increment is completed and delivered, it is installed in the customer’s normal working environment. They can experiment with the system, and this helps them clarify their requirements for later system increments. As new increments are completed, they are integrated with existing increments so that system functionality improves with each delivered increment. 30/10/2014 Chapter 2 Software Processes 59

Incremental delivery 30/10/2014 Chapter 2 Software Processes 60

Incremental delivery advantages ² Customer value can be delivered with each increment so system functionality is available earlier. ² Early increments act as a prototype to help elicit requirements for later increments. ² Lower risk of overall project failure. ² The highest priority system services tend to receive the most testing. 30/10/2014 Chapter 2 Software Processes 61

Incremental delivery problems ² Most systems require a set of basic facilities that are used by different parts of the system. § As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities that are needed by all increments. ² 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 organizations, where the complete system specification is part of the system development contract. 30/10/2014 Chapter 2 Software Processes 62

Discussion ² Giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems: • A system to control anti-lock braking in a car • A virtual reality system to support software maintenance • A university accounting system that replaces an existing system • An interactive travel planning system that helps users plan journeys with the lowest environmental impact 30/10/2014 Chapter 2 Software Processes 63