The software production process

1. CSC 3910 Software Engineering Spring 2011 Time: 1:30 to 2:20 Meeting Days: MWF Location: Oxendine 1256 Textbook: Fundamentals of Software Engineering, Author: Carlo Ghezzi, et al, 2003, Pearson The software production process Ch. 7

2. 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? Ch. 7

3. Outline • Traditional answer: "waterfall" lifecycles • Flexible, incremental processes • Case studies • "synchronize-and-stabilize" (Microsoft) • the "open source" development model • Organizing the process • software methodologies • the "Unified Process" • Organizing artifacts: configuration management • Standards Ch. 7

4. 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 Ch. 7

5. 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 Ch. 7

6. 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 Ch. 7

7. 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" Ch. 7

8. Process model goals (B. Boehm 1988) "determine the order of stages involved in software development and evolution, and to establish the transition criteria for progressing from one stage to the next. These include completion criteria for the current stage plus choice criteria and entrance criteria for the next stage. Thus a process model addresses the following software project questions: What shall we do next? How long shall we continue to do it?" Ch. 7

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

10. 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 Ch. 7

11. Process as a "white box" Ch. 7

12. Advantages • Reduce risks by improving visibility • Allow project changes as the project progresses • based on feedback from the customer Ch. 7

13. The main activities • They must be performed independently of the model • The model simply affects the flow among activities Ch. 7

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

15. Requirements engineering activities Ch. 7

16. Requirements engineering • Involves • eliciting • understanding • analyzing • specifying • Focus on • what qualities are needed, NOT on • how to achieve them Ch. 7

17. 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 Ch. 7

18. 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, easilymodifiable Ch. 7

19. 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 Ch. 7

20. 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 Ch. 7

21. A case studyrailway automation • Who are the stakeholders? • management of the train company • train drivers and their unions • passengers (customers) • contractors • Each has different goals Ch. 7

22. Case studyhow 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 Ch. 7

23. Case studythe 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 Ch. 7

24. 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 Ch. 7

25. Coding and module testing activity • Company wide standards often followed for coding style • Module testing • based on black box/white box criteria Ch. 7

26. 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 Ch. 7

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

28. Maintenance • Requirements errors are main cause of maintenance activities • Late discovery of requirements errors causes increased costs Ch. 7

29. Other software activities • Documentation • Verification • Management They can be considered as parts of any kind of software related activity Ch. 7

30. Overview of software process models Ch. 7

31. Waterfall models (1) • 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 Ch. 7

32. A waterfall model Ch. 7

33. Waterfall models (2) • Organizations adopting them standardize the outputs of the various phases (deliverables) • May also prescribe methods to follow in each phase • organization of methods in frameworks often called methodology • Example: Military Standard (MIL-STD-2167) Ch. 7

34. 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 Ch. 7

35. Waterfall with feedback Ch. 7

36. 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 Ch. 7

37. 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" Ch. 7

38. Incremental delivery • Identify self-contained functional units that may be delivered to customers • To get early feedback • According to T. Gilb, 1988: • Deliver something to the real user • Measure the added value to the user in all critical dimensions • Adjust design and objectives Ch. 7

39. Transformation model • Guided by formal methods • Specifications transformed into implementations via transformations • Still a theoretical reference model Ch. 7

40. Transformation model Ch. 7

41. Spiral model B. Boehm, 1989 Ch. 7

42. A final model assessment(1) • Waterfall • document driven • Transformational • specification driven • Spiral • risk driven Ch. 7

43. 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) Ch. 7

44. Legacy software Ch. 7

45. 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 Ch. 7

46. Case study Synchronize&Stabilize (The Microsoft Software Process) Ch. 7

47. The process • Planning phase • vision of the product, specification, schedule • Development • team composed of 2 groups • developers and testers (continuous testing) • process prescribes • daily synchronization • product stabilization Ch. 7

48. Case study The Open Source Approach Ch. 7

49. 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.) Ch. 7

50. The process • Highly distributed process characterized by frequent iterations • wide availability of source code • openness to contributions from a large community of developers • Enabling technology • Internet (large scale and fast collaborations) • repositories with version control and configuration management Ch. 7