Ch. 71 The software production process

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?

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

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

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

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"

Ch. 77 Process as a "black box"

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

Ch. 79 Process as a "white box"

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

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

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

Ch. 713 Requirements engineering activities

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ch. 728 Overview of software process models

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

Ch. 730 A waterfall model

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

Ch. 732 Waterfall with feedback

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

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"

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

Ch. 736 Transformation model

Ch. 737 Spiral model B. Boehm, 1989

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

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)

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

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

Ch. 742 Methodologies to organize the process

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

Ch. 744 DFDs: a reminder

Ch. 745 Analysis of office work

Ch. 746 Unified Software Development Process (UP)

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)

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

Ch. 749 Distribution of workflows over phases

Ch. 750 Organizing artifacts Configuration management

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

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

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

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

Ch. 755 Software standards

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

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