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

2. September 10, 2009COMS W41562 Topics covered in this lecture Introduce software process Describe several generic process models and consider advantages/disadvantages If time permits: Overview of planning and scheduling

3. September 10, 2009COMS W41563 Software Process

4. September 10, 2009COMS 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 10, 2009COMS 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 10, 2009COMS 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 10, 2009COMS 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 10, 2009COMS 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 10, 2009COMS W41569 Process Models

10. September 10, 2009COMS 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 10, 2009COMS W415611 Build First Version Retirement Operations Modify until Customer satisfied Code-and-Fix

12. September 10, 2009COMS 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 10, 2009COMS W415613 Requirements Validate Retirement Operations Test Implementation Verify Design Waterfall

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

15. September 10, 2009COMS 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 10, 2009COMS 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 10, 2009COMS W415617 Requirements Validate Retirement Operations Test Implementation Verify Design Requirements Change Waterfall*

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

19. September 10, 2009COMS 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 10, 2009COMS W415620 Prototyping Initial Concept Complete and Release Prototype Refine Prototype Until Acceptance Design and Implement Initial Prototype

21. September 10, 2009COMS 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 coderapid prototyping tools –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 10, 2009COMS W415622 Incremental (staged) delivery Detailed Design, Implement, Test, Deliver Feature Set Requirements Validate Retirement Operations Verify Architectural Design

23. September 10, 2009COMS 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 10, 2009COMS 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 10, 2009COMS W415625 Iterative delivery Initial Concept Operations Acceptance Testing and Delivery Requirements and Iteration Planning Next Iteration Design and Implement

26. September 10, 2009COMS 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 10, 2009COMS 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 10, 2009COMS 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 10, 2009COMS 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 10, 2009COMS 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 10, 2009COMS 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 10, 2009COMS 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. September 10, 2009COMS W415633 Planning and Scheduling

34. September 10, 2009COMS W415634 Gantt charts Articulated by Henry Gantt, ~1903Henry Gantt List tasks Graphically represent dependencies among tasks Show duration and time period of each task Heavily dependent on prediction regarding: –Activities involved –Effort and time required

35. September 10, 2009COMS W415635 Gantt chart example Programmer working on a small software project Explicit start time, end time, and duration (e.g., in days) Explicit calendar bar

36. September 10, 2009COMS W415636 Another Gantt chart

37. September 10, 2009COMS W415637 Planning and Scheduling: Pert chart Alternative to Gantt chart PERT = Project Evaluation and Review Technique (developed for US DoD, ~1958)PERT Different perspective - Focuses on dependencies more than calendar time Start time Duration End time Task

38. September 10, 2009COMS W415638 Another Pert chart

39. September 10, 2009COMS W415639 The BIG Question: How do you know how long a software engineering task is going to take?

40. September 10, 2009COMS W415640 Function Points A.J. Albrecht of IBM, ~1979A.J. Albrecht of IBM FP is a unit for estimating time and effort independent of programming language Identify set of application activities (building blocks) and sum the weights assigned to each From end-user’s viewpoint

41. September 10, 2009COMS W415641 Function Points Number of basic FP building blocks determined from application, not implementation (which doesn’t exist yet!): –Input files –Output files –Inquiries (snapshot request, no state change) –Internal files (transformations) –External interfaces (to other systems) Score for each block based on complexity: low, medium, high Unadjusted FP (UFP) is sum of the scores

42. September 10, 2009COMS W415642 UFP Scores LowMediumHigh Input files 346 Output files 457 Inquiries 346 Internal files 71015 External interfaces 5710

43. September 10, 2009COMS W415643 Function Points 14 “technical factors” related to complexity –Grouped under 3 classes of complexity: system, I/O, application –Each factor ranked from 0 to 5 Technical complexity factor (TCF) Adjusted function points (AFP or FP) FP = UFP * (0.65 + TCF)

44. September 10, 2009COMS W415644 Technical Factors 1. System Complexity 2. I/O Complexity 3. Application Complexity 1.1 Data communication2.1 Reliable and transaction-oriented data management 3.1 Algorithms and processing ability 1.2 Distributed data processing 2.2 Online data management 3.2 Need to reuse the code later 1.3 Relevance of performance 2.3 Usability and efficiency of end user 3.3 Installation easiness 1.4 Configuration of hardware and software 2.4 Online update of the data 3.4 Startup, shutdown, and operation easiness Partial (1)Partial (2) 3.5 Requirements to run on multiple sites 3.6 Readiness to change Partial (3) Total

45. September 10, 2009COMS W415645 Using FPs to Estimate Time/Effort Previous measurements of FP per staff month or FP per calendar month Applies to maintenance as well as development (“enhancement function points”) Tables available for lines of code per FP in various programming languages

46. September 10, 2009COMS W415646 UFP for Making Cappuccino NameType (building block) ComplexityValue MilkInput FileMedium4 CoffeeInput FileMedium4 WaterInput FileLow3 CappuccinoOutput FileHigh7 Water TemperatureInquiryLow3 External TemperatureExternal InterfaceMedium7 Total Unadjusted Function Points28

47. September 10, 2009COMS W415647 FP for Making Cappuccino 1. System Complexity2. I/O Complexity3. Application Complexity 1.1 Data communication52.1 Reliable and transaction- oriented data management 03.1 Algorithms and processing ability 1 1.2 Distributed data processing 32.2 Online data management43.2 Need to reuse the code later 0 1.3 Relevance of performance 42.3 Usability and efficiency of end user 43.3 Installation easiness5 1.4 Configuration of the hardware and the software 42.4 Online update of the data23.4 Startup, shutdown, and operation easiness 3 Partial (1)16Partial (2)10 3.5 Requirements to run on multiple sites 2 3.6 Readiness to change2 Partial (3)13 Total = 39

48. September 10, 2009COMS W415648 FP for Making Cappuccino FP = UFP * (0.65 + TCF) = 28 * (0.65 + (39 * 0.01)) = 29.12 So what was the time/effort required last time your company implemented 29 FPs?

49. September 10, 2009COMS W415649 Function Points Building blocks identification and weight assignment depend critically on: –A world-wide database of FP practices –History of the company (or consultants) –Experience of the FP estimators (certification) International Function Points User Group –200 page Function Point Counting Practices Manual (but you have to be a member to get it) –http://www.ifpug.org/http://www.ifpug.org/

50. September 10, 2009COMS W415650 Constructive Cost Model Barry Boehm [again], ~1981, updated ~199519811995 COCOMO estimates best/likely/worst case range for cost, effort and schedule required to develop software Based on empirical data from numerous projects, dividing according to development mode

51. September 10, 2009COMS W415651 Development Modes Organic: relatively small software teams develop software in a highly familiar, in-house environment Semidetached: intermediate stage between the organic and embedded modes Embedded: Product must operate within (is embedded in) a strongly coupled complex of hardware, software, regulations and operational procedures

52. September 10, 2009COMS W415652 Additional Factors PlatformPersonnelProject Execution Time Constraints Analyst Capability Use of Modern Programming Practices Main Storage ConstraintsProgrammer CapabilityUse of Software Tools Platform Volatility Applications ExperienceMulti-site Development Computer Turnaround Time Platform ExperienceRequired Development Schedule Language and Tool Experience Classified Security Application Personnel Continuity

53. September 10, 2009COMS W415653 COCOMO Assumes separate guestimate of lines of code (e.g., “backfiring” function points), then considers additional factors Polynomial model A and B are computed based on the development mode and additional factors

54. September 10, 2009COMS W415654 Using COCOMO Continued data collection to improve prediction accuracy (questionnaires, software, NDAs) 544 page handbook available as a guide for the calculations of A and B (anyone can order from amazon.com - and elsewhere - but costs $$$)order from amazon.com Supporting software available from USC and commercially http://sunset.usc.edu/csse/research/COCOMOII/coco mo_main.htmlhttp://sunset.usc.edu/csse/research/COCOMOII/coco mo_main.html

55. September 10, 2009COMS W415655 Final Notes

56. September 10, 2009COMS W415656 Reminder: First Assignment Due Next Week! Due Tuesday 15 September, 10am Posted on course websitecourse website Submit via CourseWorksCourseWorks Pair Formation

57. September 10, 2009COMS W415657 Upcoming Deadlines Teams announced September 22 nd Team project concept due September 29 thproject concept Project concept feedback by October 6 th  First iteration begins October 6 th

58. September 10, 2009COMS W415658 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://bank.cs.columbia.edu/classes/cs4156/