Chap 4 Software Processes

1. Chap 4Software Processes

2. 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 • To introduce CASE technology to support software process activities

3. Topics covered • 4.1 Software process models • 4.2 Process iteration • 4.3 Process activities • 4.4 The Rational Unified Process • 4.5 Computer-aided software engineering

4. What is the software process? • A software process is a set of activities that leads to the production of a software product. These activities may involve the development of software from scratch in a standard programming language. Increasingly, however, new software is developed by extending and modifying existing systems and by configuring and integrating off-the-shelf software or system components.

5. The fundamental activities of software processes. • Although there are many software processes, some fundamental activities are common to all software processes: • Software specification : the functionality of the software and constraints on its operation must be defined. • Software design and implementation : the software to meet the specification must be produced. • Software validation : the software must be validated to ensure that it does what the customer wants. • Software evolution : the software must evolve to meet changing customer needs. 64

6. 4.1 The software process • A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective, and thus provides only partial information about that process.

7. Generic software process models • The waterfall model • Separate and distinct phases of specification development, validation and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing and so on. • Evolutionary development • This approach interleaves (interchange) the activities of specification, development and validation. An initial system is rapidly developed from abstract specifications. This is then refined with customer input to produce a system that satisfies the customer’s needs. • Component-based software engineering • The system is assembled from existing components, the focuses on integrating these components into a system rather than developing them from scratch.

8. These generic process models are widely used in current software engineering practice. They are not mutually (interchange) exclusive and are often used together, especially for large systems development. • Sub-system within a larger system may be developed using different approaches, but we should understand that, in practice, they are often combined.

9. 4.1.1 Waterfall model Figure 4.1the software life cycle

10. 4.1.1 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 a detail system specification. • System and software design • Systems design process partitions 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. • Implementation and unit testing • Software design is realized (accomplish) as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.

11. Waterfall model phases • Integration and system testing • 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. • Operation and maintenance • This is 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. 67

12. 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. • The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.

13. 4.1.2 Evolutionary development There are two fundamental types of evolutionary development: • Exploratory development Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer. • Throw-away prototyping • Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed.

14. 4.1.2 Evolutionary development Figure 4.2Evolutionary development

15. 4.1.2 • An evolutionary approach to software development is often more effective than the waterfall approach in producing system that meet the immediate needs of customers. • From an engineering and management perspective, the evolutionary approach has two problems: • Process is not visible: Managers need regular deliverables (report) to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. • Systems are often poorly structured: Continual change tend to corrupt the software structure. incorporating (combine) software changes becomes increasingly difficult and costly.

16. 4.1.2 Evolutionary development • Problems • Lack of process visibility; • Systems are often poorly structured; • Special skills may be required. • Applicability (suitable) • For small or medium-size interactive systems; • For parts of large systems (e.g. the user interface); • For short-lifetime systems.

17. For small and medium-sized systems (up to 500,000 lines of code). I think that the evolutionary approach is the best approach to development. • For large, complex, long-life-time systems, where different teams develop different part 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.

18. For large systems, I recommend a mixed process that incorporates the best features of the waterfall and the evolutionary development models. • This may involve developing a throwaway prototype to resolve uncertainties in the system specification, then re-implement the system using a more structured approach. • Part of the system that are well understood can be specified and developed using a waterfall-based process. • Other part of system, such as the user interface, which are difficult to specify in advance, should always be developed using an exploratory programming approach.

19. 4.1.3 Component-based software engineering (CBSE) • Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. • This approach is becoming increasingly used as component standards have emerged.

20. 4.1.3 • 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 (consider) the available components. Where modifications are impossible, the component analysis activity may be re-entered to search for alternative solutions.

21. System design with reuse; • During this phase, the framework of the system is designed or an existing framework is reused. The designers take into account the components that are reused and organize the framework to cater (supply) to this. Some new software may have to be designed if reusable components are not available. • Development and integration. • Software that cannot be externally procured is developed, and the components and COTS systems are integrated to create the new system. System integration, in this model, may be part of the development process rather than a separate activity.

22. Reuse-oriented development Figure 4.3component-based software engineering CBSE : Component-based software engineering

23. Advantage and short-point of Component-based software engineering • Has obvious advantage of reducing the amount of software to be developed and so reducing cost and risks. • 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 organization using them.70

24. 4.2 Process iteration • Change is inevitable in all large software projects. • The system requirements change as the business procuring the system responds to external pressures. • Management priorities change. • As new technologies become available designs and implementation change. • This means that the software process is not a one-off process; rather, the process activities are regularly repeated as the system is reworked in response to change requests.

25. 4.2 • Two (related) approaches • Incremental delivery: • The software specification, design and implementation are broken down into a series of increments that are each developed in turn. • Spiral development: • The development of the system spirals outwards from an initial outline through to the final developed system.

26. 4.2 • The essence of iterative processes is that the specification is developed in the same time with the software developed. • However, this conflicts with the procurement model of many organizations 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. • So which large customers such as government agencies may find difficult to accommodate.

27. 4.2.1 Incremental delivery • The waterfall model of development requires customers for a system to commit (make sure) to a set of requirements before design begins and the designer to commit to particular design strategies before implementation. • 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. • Incremental delivery is an in-between approach that combines the advantages of these models. 71

28. In the incremental development process • Customer identify, in outline, the services should be provided in the system. • They identify which of the services are most important and which are least important to them. • A number of delivery increments are then defined, with each increment providing a sub-set of the system functionality. • The allocation (assign) of services to increments depends on the service priority with the highest priority services delivered first. 72

29. Incremental development

30. 4.2.1 Incremental development advantages • Customer do not have to wait until the entire system is delivered before they can gain value from it, the first increment satisfies their most critical requirements so they can use the software immediately. • Customer can use the early increments as prototypes and gain experience that informs their requirements for later system increments.

31. There is a lower risk of overall project failure. Although problems may be encountered in some increments, it is likely that most of them will be successfully delivered to the customer. • As the highest priority services are delivered first, and later increments are integrated with them, it is inevitable that the most important system services receive the most testing. This means that customers are less likely to encounter software failures in the most important parts of the system. 72

32. Incremental delivery problems • Should be relatively small ( no more than 20,000 lines of code ) • Each increment should deliver some system functionality.

33. 4.2.2 Spiral development • Process is represented as a spiral rather than as a sequence of activities with backtracking. • Each loop in the spiral represents a phase in the process. • No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. • Thus the innermost loop might be concerned with system feasibility (practicability), the next loop with requirements definition, the next loop may with system designed.

34. Spiral model of the software process

35. Spiral model sectors Each loop in the spiral is split into four sectors: • Objective setting • Specific objectives for that phase are defined. Constraints on the process and the product are identified and a detailed management plan is drawn up. Project risks are identified. Alternative strategies, depending on these risks, may be planned. • Risk assessment and reduction (reduce) • For each of the identified project risks, a detailed analysis is carried out. Steps are taken to reduce the risk. For example, if there is risk that the requirements are inappropriate, a prototype system may be developed.

36. Development and validation • After risk evaluation, a development model for the system is chosen. • If safety risks are the main consideration, development based on Formal Transformations may be the most appropriate. • If the main identified risk is sub-system integration then Waterfall model may be the most appropriate development model. • Planning • The project is reviewed and the next phase of the spiral is planned.

37. Conclusion of Spiral development • The main difference between the spiral model and other software process models is the explicit recognize of risk in the spiral model. • For example, if the intention is to use a new programming language, a risk is that the available compilers are unreliable or do not produce sufficiently efficient object code. So risk in project problems such as schedule and cost overrun so risk minimization is very important project management activity.

38. A cycle of the spiral begins by determine clear objectives. such as performance and functionality. • Alternative ways of achieving these objectives and the constraints imposed on each of the loop. • Each alternative is assessed or evaluate. • To resolve these risks by information-gathering activities such as more detailed analysis, prototyping and simulation. • Once risks have been assessed, some development is carried out, followed by a planning activity for the next phase of the process. 74

39. 4.3 Process activities • Software specification • Software design and implementation • Software validation • Software evolution

40. 4.3.1 Software specification • The process of establishing what services are required and the constraints on the system’s operation and development. • Requirements engineering process • Feasibility study; • An estimate is made of whether the identified user needs may be satisfied using current software and hardware technologies, and whether the proposed system will be cost-effective from a business point of view and within existing budgetary constraints.

41. Requirements elicitation (draw out) and analysis; • This is a process of deriving the system requirements through observation of existing systems, discussions with potential users and customer, task analysis and so on. • Requirements specification; • This activity will translating the information gathered during the analysis activity into a set of requirement documents. • Requirements validation. • This activity checks the requirements for consistency and completeness .in this stage, error in the requirements document may occur, it must be modified to correct these problems.

42. The requirements engineering process

43. 4.3.2 Software design and implementation • The process of converting the system specification into an executable system. • Software design • Design a software structure that realizes the specification; • Implementation • Translate this structure into an executable program; • The activities of design and implementation are closely related and may be interleaved.

44. Design process activities • Architectural design • The sub-system making up the system and their relationships are identified and documented. • Abstract specification • For each sub-system, under its services an abstract specification and the constraints which will be produced. • Interface design • For each sub-system, its interface with other sub-systems is designed and documented. This interface specification must be clear,

45. Component design • Service are assigned to components and interface of these components are designed. • Data structure design • To designed a detail and specified Data structure for the implementation system. • Algorithm design • Detail designed and specified the algorithms that used to provide service.

46. The software design process

47. Structured methods Structured methods is approach that rely on producing graphical models of the system，include a design process model，notations to represent the design, report formats, rules and design guidelines, it may support some or all of the following models of a system:

48. Structured methods • Possible models • Object model; that show the object classes used in the system and their dependencies. • Sequence model; show how objects in the system interact when the system is executing. • State transition model; shows system states and the triggers condition for the transitions from one state to another. • Structural model; to documented the system components and their aggregations. • Data-flow model. to describe the model when data transformation is processed. 78

49. Programming and debugging • Translating a design into a program and removing errors from that program. • Programming is a personal activity - there is no generic programming process. • Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process.79

50. The debugging process