1. Ch. 71 The software production process

2. Ch. 72 Questions What is the life cycle of a software product? Why do we need software process models? What are the goals of a software process and what makes it different from other industrial processes?

3. Ch. 73 Life cycle The life cycle of a software product –from inception of an idea for a product through requirements gathering and analysis architecture design and specification coding and testing delivery and deployment maintenance and evolution retirement

4. Ch. 74 Software process model Attempt to organize the software life cycle by defining activities involved in software production order of activities and their relationships Goals of a software process –standardization, predictability, productivity, high product quality, ability to plan time and budget requirements

5. Ch. 75 Code&Fix The earliest approach Write code Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features Source of difficulties and deficiencies –impossible to predict –impossible to manage

6. Ch. 76 Models are needed Symptoms of inadequacy: the software crisis –scheduled time and cost exceeded –user expectations not met –poor quality The size and economic value of software applications required appropriate "process models"

7. Ch. 77 Process as a "black box"

8. Ch. 78 Problems The assumption is that requirements can be fully understood prior to development Interaction with the customer occurs only at the beginning (requirements) and end (after delivery) Unfortunately the assumption almost never holds

9. Ch. 79 Process as a "white box"

10. Ch. 710 Advantages Reduce risks by improving visibility Allow project changes as the project progresses –based on feedback from the customer

11. Ch. 711 The main activities They must be performed independently of the model The model simply affects the flow among activities

12. Ch. 712 Feasibility study Why a new project? –cost/benefits tradeoffs –buy vs make Requires to perform preliminary requirements analysis Produces a Feasibility Study Document 1.Definition of the problem 2.Alternative solutions and their expected benefits 3.Required resources, costs, and delivery dates in each proposed alternative solution

13. Ch. 713 Requirements engineering activities

14. Ch. 714 Requirements engineering Involves –eliciting –understanding –analyzing –specifying Focus on –what qualities are needed, NOT on –how to achieve them

15. Ch. 715 What is needed Understand interface between the application and the external world Understand the application domain Identify the main stakeholders and understand expectations –different stakeholders have different viewpoints –software engineer must integrate and reconcile them

16. Ch. 716 The requirements specification document (1) Provides a specification for the interface between the application and the external world –defines the qualities to be met Has its own qualities –understandable, precise, complete, consistent, unambiguous, easily modifiable

17. Ch. 717 The requirements specification document (2) Must be analyzed and confirmed by the stakeholders –may even include version 0 of user manual May be accompanied by the system test plan document

18. Ch. 718 The requirements specification document (3) As any large document, it must be modular –"vertical" modularity the usual decomposition, which may be hierarchical –"horizontal" modularity different viewpoints Defines both functional and non functional requirements

19. Ch. 719 A case study railway automation Who are the stakeholders? –management of the train company –train drivers and their unions –passengers (customers) –contractors Each has different goals

20. Ch. 720 Case study how to classify requirements Safety requirements –the probability of accidents should be less than 10 -9 per year Utility requirements –level of usefulness of the system as perceived by the various stakeholders

21. Ch. 721 Case study the produced document Introduction: the “mission” of the system Architecture: the main structure of the system Specific requirements associated with each subsystem –discussion of how the subsystems’ requirements guarantee that the overall goals are indeed achieved

22. Ch. 722 Software architecture and detailed design activity The result of this activity is a Design Specification Document Usually follows a company standard, which may include a standard notation, such as UML

23. Ch. 723 Coding and module testing activity Company wide standards often followed for coding style Module testing –based on black box/white box criteria

24. Ch. 724 Integration and system test activity These activities may be integrated with coding and module testing Integration may be done incrementally through subsystems –top down vs. bottom up The last step is system test –may be followed by alpha testing

25. Ch. 725 Delivery, deployment, and maintenance activities Delivery –real delivery may be preceded by beta testing Deployment –components allocated on physical architecture Maintenance –corrective, adaptive, perfective

26. Ch. 726 Maintenance Requirements errors are main cause of maintenance activities Late discovery of requirements errors causes increased costs

27. Ch. 727 Other software activities Documentation Verification Management They can be considered as parts of any kind of software related activity

28. Ch. 728 Overview of software process models

29. Ch. 729 Waterfall models Invented in the late 1950s for large air defense systems, popularized in the 1970s They organize activities in a sequential flow Exist in many variants, all sharing sequential flow style

30. Ch. 730 A waterfall model

31. Ch. 731 Critical evaluation of the waterfall model +sw process subject to discipline, planning, and management +postpone implementation to after understanding objectives –linear, rigid, monolithic no feedback no parallelism a single delivery date

32. Ch. 732 Waterfall with feedback

33. Ch. 733 Problems with waterfall Estimates made when limited knowledge available Difficult to gather all requirements once and for all –users may not know what they want –requirements cannot be frozen

34. Ch. 734 Evolutionary models Many variants available Product development evolves through increments –"do it twice" (F. Brooks, 1995) –evolutionary prototype Evolutionary process model (B. Boehm, 1988) "model whose stages consist of expanding increments of an operational software product, with the direction of evolution being determined by operational experience"

35. Ch. 735 Transformation model Guided by formal methods Specifications transformed into implementations via transformations Still a theoretical reference model

36. Ch. 736 Transformation model

37. Ch. 737 Spiral model B. Boehm, 1989

38. Ch. 738 A final model assessment(1) Waterfall –document driven Transformational –specification driven Spiral –risk driven

39. Ch. 739 A final model assessment(2) Flexibility needed to reduce risks –misunderstandings in requirements –unacceptable time to market Waterfall may be useful as a reference structure for documentation –describes the "rationale" a posteriori (Parnas and Clements, 1989)

40. Ch. 740 Software evolution Existing software must evolve because requirements change Re-engineering –process through which an existing system undergoes an alteration, to be reconstituted in a new form Reverse engineering –from an existing system to its documentation, which may not exist, or may be incomplete –includes program understanding –preventive maintenance

41. Ch. 741 Open source Regulates licensed software, specifying its use, copy, modification, and distribution rights Business does not derive from selling software, but rather from other, indirect activities (services, accessories, advertisement, etc.)

42. Ch. 742 Methodologies to organize the process

43. Ch. 743 SA/SD Structured Analysis/Structured Design 3 major conceptual tools for modeling –data flow diagrams functional specifications –data dictionaries centralized definitions –Structured English to describe transformation of terminal bubbles

44. Ch. 744 DFDs: a reminder

45. Ch. 745 Analysis of office work

46. Ch. 746 Unified Software Development Process (UP)

47. Ch. 747 Principles Development of an OO system Uses the UML notation throughout the process Supports an iterative and incremental process Decomposes a large process into controlled iterations (mini projects)

48. Ch. 748 Cycles and phases of a cycle milestone product release Inception Elaboration Construction Transition

49. Ch. 749 Distribution of workflows over phases

50. Ch. 750 Organizing artifacts Configuration management

51. Ch. 751 CM concepts Configuration –identifies components and their versions Configuration management –discipline of coordinating software development and controlling the change and evolution of software products and components

52. Ch. 752 Key CM issues Multiple access to shared repository Handling product families –different members of the family comprise components which may have different versions

53. Ch. 753 Member 1 A B C1 Member 2 A B C2 Member 3 A D 1 2 3 A A B D E A C C 1 1 2 2 3 Component database

54. Ch. 754 Versions Can be refined into –revisions new version supersedes the previous define a linear order –variants e.g., alternative implementations of the same specification for different machines, or access to different I/O devices

55. Ch. 755 Software standards

56. Ch. 756 Why standards? They are needed to achieve quality in both software products and processes They may be imposed internally or externally –e.g., MIL-STD 2167A imposed to contractors for military applications Other examples: ISO series, IEEE

57. Ch. 757 Main benefits From the developers' viewpoint –standards enforce a uniform behavior within an organization –they facilitate communication among people, stabilizes the production process, and makes it easier to add new people to ongoing projects From the customers' viewpoint –they make it easier to assess the progress and quality of results –they reduce the strict dependency of customers on specific contractors