Chapter 7 Software production process Refers to the

Chapter 7: Software production process Refers to the activities that are used for building, delivering, deploying, and evolving a software product, from inception of an idea all the way to the delivery and final retirement of the system

Life cycle (Overview of different Activities) The life cycle of a software product: n from inception of an idea for a product towards: n requirements gathering and analysis n architecture design and specification n coding and testing n delivery and deployment n maintenance and evolution n retirement

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

Code & Fix The earliest approach n Write code n Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features n Source of difficulties and deficiencies n n n impossible to predict impossible to manage CMM initial phase

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

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? "

Process as a "black box" Quality? Uncertain / Incomplete requirement In the beginning

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

Process as a "white box"

Waterfall Software Process model (1) Invented in the late 1950 s for large air defense systems, popularized in the 1970 s n They organize activities in a sequential flow n Exist in many variants, all sharing sequential flow style n

A waterfall model

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

Critical evaluation of the waterfall model § Software process subject to discipline, planning, and management. § Postpone implementation to after understanding objectives. § Linear, rigid, monolithic: § § § No feedback No parallelism A single delivery date

Waterfall with feedback

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

Evolutionary models n n Many variants available Product development evolves through increments n n n "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"

Spiral Model Spiral model B. Boehm, 1989 Ch. 7 17

Unified Software Development Process (UP) Ch. 7 18

Principles n n n Industry standard process model, initiated by Ericsson, then Objectory and Rational companies Development of an OO system Uses the UML notation throughout the process: n n n Different views that are informal and not necessarily consistent. Supports an iterative and incremental process Decomposes a large process into controlled iterations (mini projects) Ch. 7 19

UML Models Ch. 7 20

Unified Process (UP) n Underlying model: n n n Any large software project should be broken into controlled iterations (mini-projects) that provide increments of the product A UP life cycle can be depicted abstractly as a sequence of cycles from the project’s inception to its termination. Each cycle outputs a product release - (I. e. , ready for delivery). The output is complete and consistent set of artifacts, including the executable code and all the needed documents (requ, design, tests, . . ), specified in UML. Each cycle in turn is divided into a sequence of four phases, where each phase terminates with in a milestone that is used for project control. Ch. 7 21

Phases of a UP cycle important n Inception: roughly corresponds to feasibility study; that is documenting a vision of the product and a business analysis to justify why this product should be developed. n Elaboration: defining use cases and software architecture for the current release, where the architecture will become a baseline that must be agreed on and stakeholders must adhere to it. n Construction: building the product through enriching the architecture’s baseline and developing and testing the code. Milestone for this phase is quality control via validation checking. n Transition: corresponds to beta testing. A trusted set of early adopters tries the product and provides reports on possible defects. Either fixed or deferred to next release. Milestone: consists of delivering an intermediate set of artifacts that can be subject to quality control via reviews and inspections. Ch. 7 22

Unified Process Cycles and phases of a cycle Inception Elaboration Construction milestone Transition product release Intermediate set of artifacts for quality control Ch. 7 23

Distribution of workflows over phases - Use cases - Architecture -Feasibility - Base line Ch. 7 -Develop -Beta test -Test -Quality check 24