1. Software Engineering Chapter 4 Software processes Ku-Yaw Chang canseco@mail.dyu.edu.tw Assistant Professor Department of Computer Science and Information Engineering Da-Yeh University

2. 2Ku-Yaw ChangSoftware processes Objectives Understand the concept of software process and software process model Understand three generic software process models and when they might be used Understand, in outline, the activities involved in software requirements engineering, software development, testing and evolution Understand how the Rational Unified Process integrates good software process practice to create a modern, generic process model Have been introduced to CASE technology that is used to support software process activities

3. 3Ku-Yaw ChangSoftware processes Preamble A software process A set of activities that leads to the production of a software product A set of activities that leads to the production of a software product No ideal process No ideal process Many organizations have developed their own approach to software development Fundamental activities to all software processes Specification Specification Design and implementation Design and implementation Validation Validation Evolution Evolution

4. 4Ku-Yaw ChangSoftware processes Contents 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.6 Exercises

5. 5Ku-Yaw ChangSoftware processes 4.1 Software process models A software process model An abstract representation of a software process An abstract representation of a software process Represent a process from a particular perspective Represent a process from a particular perspective General process models ( sometimes called process paradigms) The waterfall model The waterfall model Evolutionary (Iterative) development Evolutionary (Iterative) development Component-based software engineering Component-based software engineering The above models are not mutual exclusive Often be used together Often be used together

6. 6Ku-Yaw ChangSoftware processes 4.1.1 The waterfall model

7. 7Ku-Yaw ChangSoftware processes Waterfall model phases Requirements analysis and definition Service, constraints and goals Service, constraints and goals Consultation with system users Consultation with system users System and software design System design System design Partition the requirements to either hardware or software systems Establish an overall system architecture Software design Software design Identify and describe the fundamental software abstractions and their relationships

8. 8Ku-Yaw ChangSoftware processes Waterfall model phases Implementation and unit testing Software design is realized Software design is realized A set of programs or program units Unit testing Unit testing Verify that each unit meets its specification Integration and system testing Integrate individual program units or programs Integrate individual program units or programs Be tested as a complete system Be tested as a complete system Operation and maintenance Install the system and put it into practical use Install the system and put it into practical use Maintenance Maintenance Correct errors Improve the implementation Enhance services

9. 9Ku-Yaw ChangSoftware processes The waterfall model Advantages The documentation is produced at each phase The documentation is produced at each phase It fits with other engineering process models It fits with other engineering process models Particularly when the software project is part of a larger system engineering project. Disadvantages Inflexible partitioning of the project into distinct stages Inflexible partitioning of the project into distinct stages Commitments must be made at an early stage Commitments must be made at an early stage Difficult to respond to changing customer requirements Only appropriate when the requirements are well-understood and changes will be fairly limited during the design process. Few business systems have stable requirements. Few business systems have stable requirements.

10. 10Ku-Yaw ChangSoftware processes 4.1.2 Evolutionary development Based on the idea of Developing an initial implementation Developing an initial implementation Exposing this to user commitment Exposing this to user commitment Refining it through many versions Refining it through many versions Specification, development and validation activities are interleaved rather than separate With rapid feedback across activities With rapid feedback across activities

11. 11Ku-Yaw ChangSoftware processes Evolutionary development

12. 12Ku-Yaw ChangSoftware processes Two fundamental types Exploratory development Work with customers and to evolve a final system from an initial outline specification Work with customers and to evolve a final system from an initial outline specification Start with well-understood requirements and add new features as proposed by the customer Start with well-understood requirements and add new features as proposed by the customer Throwaway prototyping Understand the system requirements Understand the system requirements Start with poorly understood requirements to clarify what is really needed Start with poorly understood requirements to clarify what is really needed

13. 13Ku-Yaw ChangSoftware processes Evolutionary development Often more effective than the waterfall approach In producing systems that meet the immediate needs of customers In producing systems that meet the immediate needs of customersAdvantage The specification can be developed incrementally The specification can be developed incrementallyDisadvantages The process is not visible The process is not visible Not cost-effective to produce documents that reflect every version of the system Systems are often poorly structured Systems are often poorly structured Continual change tends to corrupt the software structure

14. 14Ku-Yaw ChangSoftware processes Evolutionary development Applicability For small or medium-size systems (up to 500,000 lines of code) For small or medium-size systems (up to 500,000 lines of code) For parts of large systems (e.g. the user interface) For parts of large systems (e.g. the user interface) A mixed process incorporating the waterfall and evolutionary models A throwaway prototyping to resolve uncertainties in the system specification A throwaway prototyping to resolve uncertainties in the system specification Implement the system in a more structural approach Implement the system in a more structural approach The user interface could be developed using an exploratory approach The user interface could be developed using an exploratory approach For short-lifetime systems For short-lifetime systems

15. 15Ku-Yaw ChangSoftware processes 4.1.3 Component-based software engineering Software reuse The majority of software projects The majority of software projects Essential for rapid system development Essential for rapid system developmentCBSE Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems Becoming increasingly used as component standards have emerged Becoming increasingly used as component standards have emerged

16. 16Ku-Yaw ChangSoftware processes Component-based software engineering

17. 17Ku-Yaw ChangSoftware processes CBSE stages System specification Component analysis A search is made for components A search is made for components Usually no exact match Usually no exact match Requirements modification Analyze requirements using information about components that have been discovered Analyze requirements using information about components that have been discovered System design and reuse Take into account the components that are reuse Take into account the components that are reuse Reorganize the framework of the system Reorganize the framework of the system Some new software may be designed reusable components are not available Some new software may be designed reusable components are not available Development and integration Develop software that cannot be externally procured Develop software that cannot be externally procured Integrate newly developed software and COTS systems Integrate newly developed software and COTS systems System validation

18. 18Ku-Yaw ChangSoftware processes Component-based software engineering Advantages Reduce the amount of software to be developed Reduce the amount of software to be developed Costs and risk Lead to faster delivery of the software Lead to faster delivery of the softwareDisadvantages Requirements compromises are inevitable Requirements compromises are inevitable Some control over the system evolution is lost Some control over the system evolution is lost

19. 19Ku-Yaw ChangSoftware processes Contents 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.6 Exercises

20. 20Ku-Yaw ChangSoftware processes Process iteration Change is inevitable in large software projects The essence of iterative processes The specification is developed in conjunction with the software The specification is developed in conjunction with the software Conflict with the procurement model of many organizations Conflict with the procurement model of many organizations The complete system specification is part of the system development contract Two process models to support process iteration Incremental delivery Incremental delivery Spiral development Spiral development

21. 21Ku-Yaw ChangSoftware processes 4.2.1 Incremental delivery Waterfall model Separation of design and implementation leads to well-documented systems that are amenable to change Separation of design and implementation leads to well-documented systems that are amenable to change Evolutionary development May be poorly structured and difficult to understand and maintain May be poorly structured and difficult to understand and maintain Incremental delivery An in-between approach that combines the advantages of the above models An in-between approach that combines the advantages of the above models

22. 22Ku-Yaw ChangSoftware processes Incremental delivery Customers outline the services Identify which are most/least important Identify which are most/least important Define a number of delivery increments Each increment provide a sub-set of the system functionality Each increment provide a sub-set of the system functionality Develop an increment Requirements are defined in detail Requirements are defined in detail Further requirements analysis for later increments can take place Further requirements analysis for later increments can take place Put an increment into service New increments are integrated with existing increments New increments are integrated with existing increments

23. 23Ku-Yaw ChangSoftware processes Incremental delivery

24. 24Ku-Yaw ChangSoftware processes Incremental development Advantages Customer value can be delivered with each increment so system functionality is available earlier 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 Early increments act as a prototype to help elicit requirements for later increments Lower risk of overall project failure Lower risk of overall project failure The highest priority system services tend to receive the most testing The highest priority system services tend to receive the most testing

25. 25Ku-Yaw ChangSoftware processes Incremental development Problems Difficult to map requirements onto increments of the right size Difficult to map requirements onto increments of the right size Relatively small – no more than 20,000 lines of code Hard to identify facilities that are needed by all increments Hard to identify facilities that are needed by all increments Extreme programming An approach to development An approach to development Based on the development and delivery of very small increments of functionality Relies on constant code improvement, user involvement in the development team and pairwise programming.

26. 26Ku-Yaw ChangSoftware processes 4.2.2 Spiral development The software process is represented as a spiral Each loop represents a phase Each loop represents a phase

27. 27Ku-Yaw ChangSoftware processes Spiral model

28. 28Ku-Yaw ChangSoftware processes Contents 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.6 Exercises

29. 29Ku-Yaw ChangSoftware processes Process Activities Basic process activities Specification, development, validation, and evolution Specification, development, validation, and evolution Organized in sequence in the waterfall model Interleaved in evolutionary development No right or wrong way to organize these activities Depend on the type of software, people and organizational structures involved Depend on the type of software, people and organizational structures involved

30. 30Ku-Yaw ChangSoftware processes 4.3.1 Software specification Also called requirements engineering (RE) The process of The process of Understanding and defining required services Identifying constraints on operation and development Four main phases in the RE process Feasibility study Feasibility study Requirements elicitation and analysis Requirements elicitation and analysis Requirements specification Requirements specification Requirements validation Requirements validation

31. 31Ku-Yaw ChangSoftware processes The requirements engineering process

32. 32Ku-Yaw ChangSoftware processes 4.3.2 Software design and implementation Software development The process of converting a system specification into an executable system The process of converting a system specification into an executable system Design process Developing several models of the system at different levels of abstraction Developing several models of the system at different levels of abstraction Stages are sequential A specification for the next stage is the output of each design activity A specification for the next stage is the output of each design activity

33. 33Ku-Yaw ChangSoftware processes A general model of the design process

34. 34Ku-Yaw ChangSoftware processes Structured methods Be invented in 1970s to support function-oriented design Be invented in 1970s to support function-oriented design Produce graphical models of the system Produce graphical models of the system Automatically generating code from these models Various competing methods to support object- oriented design were unified in the 1990s Unified Modeling Language (UML) Unified Modeling Language (UML) Current official version : 2.1.1 (2007/04) Unified design process Unified design process Rational Unified Process (RUP)

35. 35Ku-Yaw ChangSoftware processes Structured methods Support part or all of the following models An object model An object model Object classes and dependencies A sequence model A sequence model Objects interaction during execution A state transition model A state transition model System states and triggers for the transitions A structural model A structural model System components and their aggregations A data flow model A data flow model Focus on the data transformations

36. 36Ku-Yaw ChangSoftware processes The debugging process Testing Establish the existing of defects Establish the existing of defectsDebugging Locating and correcting these defects Locating and correcting these defects

37. 37Ku-Yaw ChangSoftware processes 4.3.3 Software validation Verification and Validation ( V & V ) Verification Verification a system conforms to its specification Validation Validation the system meets the expectations of the customer Systems should not be tested as a single, monolithic unit. A three-stage testing process A three-stage testing process

38. 38Ku-Yaw ChangSoftware processes The testing process

39. 39Ku-Yaw ChangSoftware processes Stages in the testing process Component (or unit) testing Individual components are tested independently; Individual components are tested independently; Components may be functions or objects or coherent groupings of these entities. Components may be functions or objects or coherent groupings of these entities. System testing Testing of the system as a whole. Testing of emergent properties is particularly important. Testing of the system as a whole. Testing of emergent properties is particularly important. Acceptance testing Testing with customer data to check that the system meets the customer’s needs. Testing with customer data to check that the system meets the customer’s needs.

40. 40Ku-Yaw ChangSoftware processes 4.3.3 Software validation Component development and testing are interleaved An economically sensible approach An economically sensible approach Programmers make up their own test data and test the code as it is developed. Alpha testing Sometimes called acceptance testing Sometimes called acceptance testing The system developer and the client agree that the delivered system is an acceptable implementation The system developer and the client agree that the delivered system is an acceptable implementation Beta testing Delivering a system to a number of potential customers Delivering a system to a number of potential customers

41. 41Ku-Yaw ChangSoftware processes Testing phases

42. 42Ku-Yaw ChangSoftware processes System evolution It makes more sense to see development and maintenance as a continuum.

43. 43Ku-Yaw ChangSoftware processes Contents 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.6 Exercises

44. 44Ku-Yaw ChangSoftware processes Rational Unified Process Rational Unified Process (RUP) A modern process model that derived from work on the UML and associated process A modern process model that derived from work on the UML and associated process OMG’s Unified Modeling Language

45. 45Ku-Yaw ChangSoftware processes Rational Unified Process Be described from three perspectives A dynamic perspective A dynamic perspective The phases of the model over time A static perspective A static perspective The process activities that are enacted A practice perspective A practice perspective Suggest good practices

46. 46Ku-Yaw ChangSoftware processes Phases in the RUP(1/4) Four discrete phases Focus on business Focus on business Not technical concerns like the waterfall model

47. 47Ku-Yaw ChangSoftware processes Phases in the RUP(2/4) Inception Goal Goal Establish a business case for the system Identify external entities (people and systems) and define their interactions Identify external entities (people and systems) and define their interactionsElaboration Goals Goals Develop an understanding of the problem domain Establish an architectural framework for the system Develop the project plan Identify key project risks

48. 48Ku-Yaw ChangSoftware processes Phases in the RUP(3/4) Construction Be concerned with system design, programming and testing Be concerned with system design, programming and testing Parts are developed in parallel and integrated Parts are developed in parallel and integratedTransition From the development community to the user community From the development community to the user community Work in a real environment

49. 49Ku-Yaw ChangSoftware processes Phases in the RUP(4/4) Iterations are supported in two ways Each phase may be enacted in an interactive way Each phase may be enacted in an interactive way The whole set of phases may also be enacted incrementally The whole set of phases may also be enacted incrementally

50. 50Ku-Yaw ChangSoftware processes Static view of the RUP (1/2) Activities (called workflows) during the development process Six core workflows Six core workflows Three core supporting workflows Three core supporting workflows Be oriented around associated UML models

51. 51Ku-Yaw ChangSoftware processes Static view of the RUP (2/2)

52. 52Ku-Yaw ChangSoftware processes Good practice of the RUP Develop software iteratively Deliver the highest priority system features early Deliver the highest priority system features early Manage requirements Document requirements Document requirements Keep track of changes Keep track of changes Analyze the impact of changes Analyze the impact of changes Use component-based architectures Visually model software Graphical UML models (static and dynamic) Graphical UML models (static and dynamic) Verify software quality Control changes to software

53. 53Ku-Yaw ChangSoftware processes Contents 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.6 Exercises

54. 54Ku-Yaw ChangSoftware processes 4.5 Computer-Aided Software Engineering CASE Software used to support software process activities Software used to support software process activities Activity automation Graphical editors for system model development; Graphical editors for system model development; Data dictionary to manage design entities; Data dictionary to manage design entities; Graphical UI builder for user interface construction; Graphical UI builder for user interface construction; Debuggers to support program fault finding; Debuggers to support program fault finding; Automated translators to generate new versions of a program. Automated translators to generate new versions of a program.

55. 55Ku-Yaw ChangSoftware processes 4.5 CASE CASE technology has led to significant improvements in the software process. Limited by two factors: Software engineering requires creative thought - this is not readily automated; Software engineering requires creative thought - this is not readily automated; Software engineering is a team activity and, for large projects, much time is spent in team interactions. Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these.

56. 56Ku-Yaw ChangSoftware processes 4.5.1 CASE classification Different types of CASE tools and their support for process activities. Functional perspective Functional perspective Tools are classified according to their specific function. Process perspective Process perspective Tools are classified according to process activities that are supported. Integration perspective Integration perspective Tools are classified according to their organization into integrated units.

57. 57Ku-Yaw ChangSoftware processes Functional classification

58. 58Ku-Yaw ChangSoftware processes Activity-based classification

59. 59Ku-Yaw ChangSoftware processes CASE categories – from process perspective Tools Support individual process tasks such as design consistency checking, text editing, etc. Support individual process tasks such as design consistency checking, text editing, etc.Workbenches Support a process phase such as specification or design, Normally include a number of integrated tools. Support a process phase such as specification or design, Normally include a number of integrated tools.Environments Support all or a substantial part of an entire software process. Normally include several integrated workbenches. Support all or a substantial part of an entire software process. Normally include several integrated workbenches.

60. 60Ku-Yaw ChangSoftware processes Tools, workbenches and environments

61. 61Ku-Yaw ChangSoftware processes Contents 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.6 Exercises

62. 62Ku-Yaw ChangSoftware processes Exercises None

63. The End