Software Process

1. Software Process • Engineering Activities • SW Development Process • Process Tailoring • Process Improvement • Tools

2. Life-Cycle vs. Process • Recall: The evolution of an item is referred to as the item’s life cycle. It is usually conceived as starting with the initial conception of the product to its removal from service. • Each of the tasks within a life cycle is accomplished by means of one or more processes. The combination of all relevant processes within the life cycle is called the software life cycle process.

3. Processes • As per IEEE/EIA Standard 12207-1996 • Primary processes: • Acquisition, supply, and development process • Supporting processes: • Documentation, Config Mgmt, QA, V&V, Joint review, Audits, etc. • Institutional processes: • Management, Infrastructure, improvement, training

4. Processes

6. Development Process • Do all the engineering activities have to be performed in the linear sequence proposed by previous slide? • What are development processes (or process models) about? • Try to model in a specific process how to sequence engineering activities in order to develop software. • Try to identify the key engineering activities in the development of software and their relationships to one another.

7. High Level Process • Processes are made of two majors blocks: • Transformation activities • Control activities • Transformation and control blocks may also themselves incorporate micro processes. Process Engineering transformation activities Working software Requirements Control activities Analyzing, designing, coding, documenting Remarks: this high level process does not prescribe how to sequence the activities. Audit/review, inspection, compiler check, testing, debugging

8. Methodology/Method vs. Process Model • Process Models: key activities and their relationships • Methodologies:prescribes how these activities are supposed to be carried out: when, what, who, and precisely how some tasks have to be performed. Methodologies are specific implementations of a process model.

9. Development Process Models • There are different software development process models that propose different sequences of engineering activities: • Waterfall Model • Evolutionary • Incremental • Spiral • Rational Unified Process (RUP)* • Rapid Application Development (RAD)** • Agile Development • XP, Scrum, Crystal, Feature Driven, Adaptive • Etc. * result from previous models (unified) ** gave birth to Agile

10. Classifying Development Process • Prescriptive Process Models • Waterfall model • Incremental & Evolutionary models • Spiral model • Rational Unified Process (RUP) • Agile Methods • eXtreme Programming (XP) (method) • Scrum • Crystal • etc. • We will have a quick look at waterfall, incremental and spiral to better understand RUP. • We will have a closer look at: RUP and XP

11. Lifecycle Models • Most Primitive: Code-and-Fix ->good for small projects where the solution is obvious

12. Software requirements Analysis Design Coding Testing Maintenance Waterfall Model

13. Waterfall Model – Characteristics • Place considerable emphasis on a careful analysis before the system is actually built. • Try to identify and tie down the user’s requirements as early as possible • Transition from one activity to the next typically requires: • completion of a defined work product • formal evaluation and acceptance of the work product • Tends to be a document-driven process.

14. Strengths of Waterfall • Encourages periodic review, validation and verification, results in higher performance product, more closely matches the requirements • Each phase results in document, helps clarify decisions, provides an audit trail, serves as concrete milestone. • Formal transition from phase to phase results in a progressive “setting” of the product; reduces unnecessary changes. • Because the above items, this model is appealing to • project managers since it provides them a “sense of control”, easy flow to understand; • to contractors since often they get paid for document delivery (low risk to make considerable money without building the actual product)

15. Weaknesses of Waterfall • inherent assumption: possible to get requirements, design complete and correct on first pass • true for some projects • for most projects, difficult to correctly state or visualize requirements before system designed or implemented • first designs almost always sub-optimal • when necessary to revisit completed phases, normally large administrative overhead, inertia • reduces “recursive engineering” • also reduces ability to make course corrections when early decisions turn out to be inappropriate • Does not respect the transformation-control loop of generic process.

16. Revised Waterfall Model need Analysing & documenting Statement of requirements Reviewing, auditing Designing & documenting Reviewing, auditing Design Spec Coding and commenting code inspecting, compiler checking, testing, debugging deploying Software in operation maintaining disposing Work product waste bin

17. Modified Waterfall – Characteristics • Work product flows down the primary, stepwise path of normal development. • The reverse flow represents iterative changes applied to a prior deliverable, the need for which has been only recognized in the next phase or even later. • Such iteration implies rework which requires that work from prior phases is to be repeated (not efficient).

18. Relative cost to fix or change software throughout the life cycle 200 100 50 20 10 5 2 1 larger projects smaller projects Requirements Design Code Development Test Acceptance Test Operation Waterfall: Premise 2

19. Waterfall, does it work? • For very small projects the waterfall is sometimes adequate. • Because it is easy to get all the requirements correct the first time for small and not complex projects. • For large production projects, it may also be adequate. • Because knowledge acquired during previous similar projects allows us to properly gather and identify all the user and design requirements, and where little new development is required. • For large development projects, it is NOT adequate. • Because it is almost impossible to properly identify all the user and design requirements; many changes to the product are then required.

20. Waterfall : Conclusion • First formally defined • First widely accepted • Still the most widely used • Simple • Flexible : many variants overcome weaknesses (prototyping inside requirements phase, feedback loops allow iteration) • Highly refined standards (e.g. 2167A)

21. Waterfall vs Life-Cycle • Recall: • First formally defined • First widely accepted • Old Life-Cycle terminology • Requirement Analysis • Design • Implementation • Testing • Integrating • Maintenance

22. Classifying Development Process • Prescriptive Process Models • Waterfall • Incremental & Evolutionary models • Spiral • Rational Unified Process (RUP) • Agile Methods • eXtreme Programming (XP) • Scrum • Crystal • etc. • We will have a quick look at waterfall, incremental and spiral to better understand RUP. • We will have a closer look at: RUP and XP

23. Increment Design Product Requirements Coding Testing Increment Design Coding Testing Increment Design Coding Testing Incremental Development Process Model

24. Revised Incremental Model need Work product Designing & documenting Statement of requirements Design Spec Coding commenting Design Spec Source code Design Spec Source code integrating integration testing Source code inspecting, compiler checking, testing, debugging Integrated source code

25. Incremental Characteristics • Same as Waterfall, except • Overall product functionality is delivered in small increments. • Each increment uses the waterfall. • Advantages over Waterfall • Improvement over the Waterfall in getting user to better define essential requirements. • focused on essential features, therefore reduces the amount of unnecessary functionality; • User involved in selecting which features will be implemented in the next increment. • May reduce the number of developers. • Does it work? • Still falls short of providing developers with iterative engineering process.

26. Waterfall vs. Incremental Version Comparative staffing curves strict waterfall Required personnel incremental Development timeline

27. Classifying Development Process • Prescriptive Process Models • Waterfall • Incremental& Evolutionary models • Spiral • Rational Unified Process (RUP) • Agile Methods • eXtreme Programming (XP) • Scrum • Crystal • etc. • We will have a quick look at waterfall, incremental and spiral to better understand RUP. • We will have a closer look at: RUP and XP

28. Evolutionary Model Work product need SOR for build 1 SOR for build 2 SOR for build 3 Design &Spec Design &Spec Design &Spec Source Code Source Code Source Code

29. Evolutionary Characteristics • Model can be used when the requirements cannot or will not be specified. • User can experiment with the system to improve the requirements • Greater user involvement is required than in the waterfall method.

30. Dangers of Evolutionary • This model is used as an excuse for hacking or to avoid proper requirements analysis and design, including their documentation even if the requirements are well understood. • may be impossible to adequately tune performance once system is complete • Use of this model is exploratory in nature and therefore constitutes a high-risk endeavour. Strong management is required. • without strong management control, possible to iterate endlessly; difficult to schedule

31. Prototyping • This is not a engineering process. It is an engineering activity. Prototyping by itself is insufficient to develop a product to production stage. Consequently to correct this lacuna , the “evolutionary prototype process” was invented. This consists of taking a prototype and making it evolve into the final product. This implies that the prototype will be using the same technology as the final product, therefore taking has much time to build. Consequently it ends up more like an incremental or an iterative development process. So it is not significantly different enough to be worth specially naming the process as “ prototyping”. • Prototyping is an engineering activity. A prototype is something that you build and that you will eventually throw away. A prototype does not encompass all the functionality of the final product, nor its robustness, etc. A prototype should be relatively quick and cheap to build so special technology has to be used to that effect (wood instead of steel, scripting language instead of strong typed language, etc.). • Prototyping is not always a required engineering activity for product development. It is something use to help define user requirements. Consequently, users should be involved in this activity. It may also be useful to evaluate different design architectures. • In regard to software development, this requires the use of high-level languages (e.g. script language), and often developing a quick and dirty GUI, so users can review and provide clarification on the product requirements.

33. Prototyping Approaches • Key feature of prototyping is to rapidly develop simple models of the system to either • get rapid customer feedback and clarify requirements; or • reduce uncertainty about design aspects that are poorly understood; or • evaluate the use of specific technologies. • Key question in prototyping: • What do you prototype first?

34. Prototyping (Requirements) • problem • customer defines general objectives but is unable to identify detailed input, processing, or output requirements • solution: Gather requirements from customer Build prototype Quick design Customer evaluates prototype Refine prototype

35. Gather requirements from customer Build prototype Quick design Customer evaluates prototype Refine prototype Requirements Prototyping Aim: by prototyping and refining the requirements during the analysis stage, we reduce the risk of designing from incorrect or incomplete software requirements. System requirements Software requirements Analysis Design

36. Danger of Requirements Prototyping • customer sees “working system” and is not aware that the system • is unlikely to be maintainable • is almost certainly of low quality then demands that prototype be “fixed up” and delivered rather than thrown away • solutions • ensure customer understands reason for prototype and “buys into” process before beginning • build prototype using technologies (hardware, OS, programming language, etc.) that make it obviously unsuitable for delivery

37. Identify critical design criteria Build prototype Quick design Review against critical design criteria Refine prototype Prototyping (Design) • problem • some aspects of the design are poorly understood and are therefore high risk • solution:

38. Identify critical design criteria Build prototype System requirements Quick design Review critical design criteria Refine prototype Software requirements Analysis Design Coding Design Prototyping Aim: by prototyping and refining the design until it meets the key design criteria, we reduce the risk that we will implement an inadequate or flawed design.

39. Danger of Design Prototyping • in order to get a prototype working quickly, developers make implementation compromises • inappropriate programming language, library, algorithms, database, user-interface toolkit, etc. then forget why compromises were inappropriate and reuse them in actual system design • solutions • document design compromises as they are made • insist on full validation of final design, explicitly guarding against inappropriate carry-over from the prototype

40. Observation • For some applications, a prototype may be sufficient to meet end user’s needs. These applications are characterised by: • low technical risk • immediate requirement • possibility of close user involvement • availability of a development environment • in which developers can work fast enough to support prototyping • but which is small/efficient/robust enough to be suitable for the deployment environment • Often can make use of fourth-generation languages (4GL), off-the-shelf components or tuneable application frameworks (e.g., SAP, Peoplesoft)

41. Plan to Throw One Away… In most projects, the first system built is barely usable. It may be to slow, too big, awkward in use or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved… When a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers… — Fred Brooks, The Mythical Man-Month

42. Boehm’s Observation (1988) • both the waterfall model and evolutionary prototyping models are aimed at reducing risk • waterfall reduces risk of requirements/design thrashing by insisting they are finalized and signed off early • evolutionary prototyping model reduces risk of misunderstanding user needs by giving user constant feedback while system evolves • relative risks vary by project, change through project life span • so, develop a software process model that explicitly recognizes risk as key driver

43. Classifying Development Process • Prescriptive Process Models • Waterfall • Incremental& Evolutionary models • Spiral • Rational Unified Process (RUP) • Agile Methods • eXtreme Programming (XP) • Scrum • Crystal • etc. • We will have a quick look at waterfall, incremental and spiral to better understand RUP. • We will have a closer look at: RUP and XP

44. 1. Establish next-level objectives, constraints, alternatives 2. Evaluate product and process alternatives, identify and resolve risks 5. Review progress, confirm commitment to continue 3. Develop, verify next-level product 4. Plan next phases Spiral Model

45. Example Spiral Model Project

46. Starting and Stopping • start with a hypothesis • a particular user need can be met cost-effectively by the development of a software system • stop when either • system complete and fielded • must test hypothesis by determining whether software system actually meets need • hypothesis demonstrated to be false • system determined to be too expensive, unnecessary; alternative becomes available; etc.

47. Key features • Development of documentation and other work products non-uniform • highest risk items addressed first, more heavily documented • Includes the waterfall process • Incorporates prototyping as a risk-reduction activity • Provides an integral framework for rework by allowing previous decisions to be revisited in a principled manner

48. Difficulties • Contracting • the Spiral model is difficult (but not impossible) to use in a contracting situation, both for the contractor and for the customer • difficult to accommodate the required flexibility • difficult to contract without specifying deliverables in advance • Risk assessment expertise • successful use of the model requires the effective identification and resolution of risks, something many managers and developers are poorly trained in • Need for further elaboration • as defined, the model is quite general and is difficult to effectively apply without significant expertise

49. Classifying Development Process • Prescriptive Models • Waterfall, Incremental, Evolutionary, Spiral, etc. • Rational Unified Process (RUP) • Agile Methods • eXtreme Programming (XP) • Scrum, Crystal, Open, etc.

50. References • The Project Manager’s Guide to Software Engineering’s Best Practices • M.J. Christensen, R.H. Thayer, IEEE, 2001, ISBN 0-7695-1199-6 • Software Project Management - A Unified Framework • Walker Royce, Addison-Wesley, 1998, ISBN 0-201-30958-0 • Software Engineering - A Practitioner’s Approach • fifth edition, Roger S. Pressman, McGraw-Hill, 2001, ISBN 0-07-052182-4