1. September 30, 2010COMS W41561 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://bank.cs.columbia.edu/classes/cs4156/

2. September 30, 2010COMS W41562 Topics covered in this lecture Introduce software process Describe several generic process models and consider advantages/disadvantages

3. September 30, 2010COMS W41563 Software Process

4. September 30, 2010COMS W41564 What is a software process? A structured set of activities required to develop a software product –Specification; –Design and implementation; –Validation; –Evolution (operation and maintenance).

5. September 30, 2010COMS W41565 Software specification The process of establishing what features and services are required, as well as the constraints on the system’s operation and development. Requirements engineering process –Feasibility study; –Requirements elicitation and analysis; –Requirements specification; –Requirements validation.

6. September 30, 2010COMS W41566 Software design and implementation The process of converting the system specification into an executable system. Software design –Design a software structure that realizes the specification; Implementation –Translate this structure into an executable program; The activities of design and implementation are closely related and may be inter-leaved.

7. September 30, 2010COMS W41567 Software validation Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the customer(s). Involves checking and review processes, and acceptance or beta testing. Custom software: Acceptance testing involves executing the system with test cases that are derived from the real data to be processed by the system in the customer’s environment. Generic software: Beta testing executes the system in many customers’ environments under real use.

8. September 30, 2010COMS W41568 Software evolution Software is inherently flexible and can change. As requirements change due to changing business circumstances, the software that supports the business must also evolve and change. Although there has historically been a demarcation between development and evolution, this is increasingly irrelevant as fewer and fewer systems are completely new.

9. September 30, 2010COMS W41569 Process Models

10. September 30, 2010COMS W415610 Software Process A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. –Major Task Identification –Sequencing In the beginning was......

11. September 30, 2010COMS W415611 Build First Version Retirement Operations Modify until Customer satisfied Code-and-Fix

12. September 30, 2010COMS W415612 Discussion of Code-and-Fix Really Bad Really Common Advantages –No Overhead –No Expertise Disadvantages –No means of assessing progress –Difficult to coordinate multiple programmers Useful for “hacking” single-use/personal-use programs: start with empty program and debug until it works

13. September 30, 2010COMS W415613 Requirements Validate Retirement Operations Test Implementation Verify Design Waterfall

14. September 30, 2010COMS W415614 More Detailed Waterfall REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

15. September 30, 2010COMS W415615 Discussion of Waterfall Articulated by Win Royce, ~1970Articulated by Win Royce Widely used today Advantages –Measurable progress –Experience applying steps in past projects can be used in estimating duration of “similar” steps in future projects –Produces software artifacts that can be re-used in other projects Disadvantages –Difficulty of accommodating change after the process is underway: One phase has to be complete before moving onto the next phase.

16. September 30, 2010COMS W415616 Discussion of Waterfall The original waterfall model (as interpreted by many) disallowed iteration –Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. –Therefore, this model is only appropriate when the requirements are very well-understood and changes will be very limited during the design process. –But few business systems have stable requirements. The “waterfall with feedback” model was, however, what Royce had in mind

17. September 30, 2010COMS W415617 Requirements Validate Retirement Operations Test Implementation Verify Design Requirements Change Waterfall*

18. September 30, 2010COMS W415618 Waterfall* REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

19. September 30, 2010COMS W415619 Evolutionary Throw-away prototyping –Objective is to understand the system requirements. –Should start with poorly understood requirements to clarify what is really needed. Incremental development –Objective is to work with customers to evolve a final system from an initial outline specification. –Should start with well understood requirements and stage development and delivery.

20. September 30, 2010COMS W415620 Prototyping Initial Concept Complete and Release Prototype Refine Prototype Until Acceptance Design and Implement Initial Prototype

21. September 30, 2010COMS W415621 Discussion of prototyping Mock-ups allow users to visualize an application that hasn't yet been constructed Used to help develop requirements specification –Useful for rapidly changing requirements –Or when customer isn’t sure what specification should be Prototypes should be discarded once requirements are “known”, and another process model used for development –Prototypes should not be used as a basis for implementation, since rapid prototyping tools do not create production quality code –Customer (and management) may need to be “educated” about prototypes: a prototype is not 80-90% of the final product, usually not even 10%

22. September 30, 2010COMS W415622 Incremental (staged) delivery Detailed Design, Implement, Test, Deliver Feature Set Requirements Validate Retirement Operations Verify Architectural Design

23. September 30, 2010COMS W415623 Discussion of incremental delivery Iterations are classified according to feature sets: –e.g., features 1 and 2 will be delivered in this iteration, features 3 and 4 are next. Series of increasingly “complete” releases. Lack of process visibility - when will it be done? Systems are often poorly structured.

24. September 30, 2010COMS W415624 Process Iteration System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems. Iteration can be applied to any of the generic process models. Several approaches.

25. September 30, 2010COMS W415625 Iterative delivery Initial Concept Operations Acceptance Testing and Delivery Requirements and Iteration Planning Next Iteration Design and Implement

26. September 30, 2010COMS W415626 Discussion of iterative delivery Rather than deliver the system as a completed product, the development and delivery is broken down into iterations, with each iteration delivering part of the required functionality. User requirements are prioritized and the highest priority requirements are included in early iterations. Once the development of an iteration is started, the requirements are frozen - but requirements for later iterations can continue to evolve (this is the distinction compared to incremental delivery of feature sets)

27. September 30, 2010COMS W415627 Discussion of iterative development Customer value can be delivered with each iteration so system functionality is available earlier. Each iteration’s deliverable is not a prototype, but an operational system. However, early iterations act as a prototype to help elicit requirements for later iterations (exploratory). Lower risk of overall project failure. The highest priority system services tend to receive the most testing.

28. September 30, 2010COMS W415628 Agile (eXtreme) Programming Iterative, but with a lot of hypehype Timeboxing: –Set the date for delivering an iteration –Date cannot change –Only functionality (scope) can change –Short duration iterations (weeks, not months)

29. September 30, 2010COMS W415629 Spiral model PLANDEVELOP AND TEST DETERMINE GOALS, ALTERNATIVES, CONSTRAINTS EVALUATE ALTERNATIVES AND RISKS Requirements, life-cycle plan Budget 1 Alternatives 1 Constraints 1 Risk analysis 1 2 3 4 Constraints 2 3 4 Budget 2 3 4 Alternatives 2 3 4 Prototype 1 Proto- type 2 Proto- type 3 Proto- type 4 Concept of operation Software requirements Validated requirements Development plan Integration and test plan Software design Validated, verified design Detailed design Code Unit test System test Acceptance test Implementation plan start

30. September 30, 2010COMS W415630 Discussion of Spiral Model Proposed by Barry Boehm, ~1986Proposed by Barry Boehm Process is represented as a spiral rather than as a sequence of activities with backtracking. –Each loop in the spiral represents a phase in the process. –No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.

31. September 30, 2010COMS W415631 Discussion of Spiral Model Each iteration is driven by “risk management” –Determine objectives and current status –Identify risks and priorities –Next iteration addresses (current) highest risk and/or highest priority items

32. September 30, 2010COMS W415632 The Basic Problem: Risk The spiral and agile iterative process models view “risk” as the main problem of software development –Schedule slips –Business changes –Staff turnovers –New technologies –…

33. Upcoming Assignments September 30, 2010COMS W415633

34. Upcoming Assignments Project Concept due Tuesday 5 October, 10am Project Concept Posted on course websitecourse website Submit via CourseWorksCourseWorks September 30, 2010COMS W415634

35. Team Project Planning and Progression September 30, 2010COMS W415635

36. First Iteration Assignments First Iteration Plan due Tuesday 19 October. First Iteration Plan First Iteration Progress Report due Tuesday 26 October. First Iteration Progress Report First Iteration Demo Wednesday 3 November – Thursday 11 November. First Iteration Demo First Iteration Final Report due Friday 12 November. First Iteration Final Report September 30, 2010COMS W415636

37. COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://bank.cs.columbia.edu/classes/cs4156/ September 30, 2010COMS W415637