1. 10 October 2006Kaiser: COMS W4156 Fall 20061 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/

2. 10 October 2006Kaiser: COMS W4156 Fall 20062 Software Development Activities Process Selection System Engineering Requirements –Determining Needs –Analysis Design –Architecture –Modules Coding –Unit Testing –Debugging Integration –Build –Integration Testing System Testing –Performance Testing & Optimization –Acceptance Testing –Beta Testing Deployment –Delivery –Installation Operations –System Management –Maintenance –Upgrades

3. 10 October 2006Kaiser: COMS W4156 Fall 20063 Support Activities Project Planning and Tracking Customer Interaction Configuration Management Process Improvement Training Documentation Personnel Management …

4. 10 October 2006Kaiser: COMS W4156 Fall 20064 Software Process Major Task Identification Sequencing General model to be tailored In the beginning was......

5. 10 October 2006Kaiser: COMS W4156 Fall 20065 Build First Version Retirement Operations Modify until Customer satisfied Code-and-Fix

6. 10 October 2006Kaiser: COMS W4156 Fall 20066 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

7. 10 October 2006Kaiser: COMS W4156 Fall 20067 Requirements Validate Retirement Operations Test Implementation Verify Design Waterfall

8. 10 October 2006Kaiser: COMS W4156 Fall 20068 More Detailed Waterfall REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

9. 10 October 2006Kaiser: COMS W4156 Fall 20069 Discussion of Waterfall Articulated by Win Royce, ~1970 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 The original waterfall model (as interpreted by many) disallowed iteration –Inflexible –Monolithic –Requirements change over time –Maintenance not handled well The “waterfall with feedback” model was, however, what Royce had in mind

10. 10 October 2006Kaiser: COMS W4156 Fall 200610 Waterfall* REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

11. 10 October 2006Kaiser: COMS W4156 Fall 200611 Requirements Validate Retirement Operations Test Implementation Verify Design Requirements Change Waterfall*

12. 10 October 2006Kaiser: COMS W4156 Fall 200612 Rapid Prototyping Rapid Prototype Validate Retirement Operations Test Implementation Verify Design Requirements Change

13. 10 October 2006Kaiser: COMS W4156 Fall 200613 Evolutionary Prototyping Initial Concept Complete and Release Prototype Refine Prototype Until Acceptance Design and Implement Initial Prototype

14. 10 October 2006Kaiser: COMS W4156 Fall 200614 Discussion of Prototyping Prototypes used to help develop requirements specification –Useful for rapidly changing requirements –Or when customer won’t commit to specification Once requirements “known”, waterfall (or some other process model) is used Prototypes discarded once design begins –Prototypes should not be used as a basis for implementation, since prototyping tools do not create production quality code –Customer may need to be “educated” about prototypes, a prototype is not 80-90% of the final product (not even 10%)

15. 10 October 2006Kaiser: COMS W4156 Fall 200615 Incremental (Staged) Detailed Design, Implement, Test, Deliver Feature Set Requirements Validate Retirement Operations Verify Architectural Design

16. 10 October 2006Kaiser: COMS W4156 Fall 200616 Discussion of Incremental 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

17. 10 October 2006Kaiser: COMS W4156 Fall 200617 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

18. 10 October 2006Kaiser: COMS W4156 Fall 200618 Discussion of Spiral Model Proposed by Barry Boehm, ~1986 Similar to Incremental Model, but each iteration is driven by “risk management” and/or customer feedback Determine objectives and current status Identify risks and priorities Next iteration addresses (current) highest risk and/or highest priority items Repeat

19. 10 October 2006Kaiser: COMS W4156 Fall 200619 Agile Programming Initial Concept Operations Acceptance Testing and Delivery Requirements and Iteration Planning Next Iteration Design and Implement

20. 10 October 2006Kaiser: COMS W4156 Fall 200620 Discussion of Agile Each iteration a mini-project –Each piece is not a prototype, but an operational system –Understand risk vs. business value in planning iterations –Put some working functionality into user’s hands as early as possible Timeboxing: –Setting the date for an iteration –Date cannot change –Only functionality (scope) can change –Short duration iterations (weeks, not months)

21. 10 October 2006Kaiser: COMS W4156 Fall 200621 The Basic Problem: Risk The spiral model and agile programming view “risk” as the main problem of software development –Schedule slips –Business changes –Staff turnovers –New technologies –…

22. 10 October 2006Kaiser: COMS W4156 Fall 200622 Planning and Scheduling: Gantt Chart 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

23. 10 October 2006Kaiser: COMS W4156 Fall 200623 Gantt chart example Programmer working on a small software project Explicit start time, end time, and duration (in days ) Explicit calendar bar

24. 10 October 2006Kaiser: COMS W4156 Fall 200624 Another Gantt

25. 10 October 2006Kaiser: COMS W4156 Fall 200625 Planning and Scheduling: Pert chart Alternative to Gantt chart Different perspective –Focuses on dependencies more than calendar time No fixed format Start time Duration End time Task

26. 10 October 2006Kaiser: COMS W4156 Fall 200626 Another Pert

27. 10 October 2006Kaiser: COMS W4156 Fall 200627 So how do you know how long a task is going to take?

28. 10 October 2006Kaiser: COMS W4156 Fall 200628 Function Points A.J. Albrecht of IBM, ~1979 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 user’s viewpoint

29. 10 October 2006Kaiser: COMS W4156 Fall 200629 Function Points Number of basic FP building blocks determined from application, not implementation: –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

30. 10 October 2006Kaiser: COMS W4156 Fall 200630 UFP Scores LowMediumHigh Input files 346 Output files 457 Inquiries 346 Internal files 71015 External interfaces 5710

31. 10 October 2006Kaiser: COMS W4156 Fall 200631 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)

32. 10 October 2006Kaiser: COMS W4156 Fall 200632 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

33. 10 October 2006Kaiser: COMS W4156 Fall 200633 Technical Factors 1. System Complexity 2. I/O Complexity 3. Application Complexity 1.1 Data communication 2.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

34. 10 October 2006Kaiser: COMS W4156 Fall 200634 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

35. 10 October 2006Kaiser: COMS W4156 Fall 200635 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 management 43.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 data 23.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

36. 10 October 2006Kaiser: COMS W4156 Fall 200636 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 firm implement 29 FPs?

37. 10 October 2006Kaiser: COMS W4156 Fall 200637 Function Points Building blocks identification and weight assignment depend critically on: –A world-wide database of FP practices –History of the firm (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/

38. 10 October 2006Kaiser: COMS W4156 Fall 200638 Constructive Cost Model Barry Boehm of TRW (now USC), ~1981, updated ~1995 COCOMO estimates best/likely/worst case range for cost, effort and schedule required to develop software Based on empirical data from numerous projects, divided according to 3 development modes: organic, semidetached, embedded

39. 10 October 2006Kaiser: COMS W4156 Fall 200639 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

40. 10 October 2006Kaiser: COMS W4156 Fall 200640 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

41. 10 October 2006Kaiser: COMS W4156 Fall 200641 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

42. 10 October 2006Kaiser: COMS W4156 Fall 200642 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) Supporting software available from USC and commercially http://sunset.usc.edu/research/COCOMOII/

43. 10 October 2006Kaiser: COMS W4156 Fall 200643 Summary FP and COCOMO macro-estimation based partially on large historical databases of contributing software projects from multiple domains and partially on in-house experience In contrast, most software industry micro- estimation entirely in-house, usually based on same or similar projects by same or related project team

44. 10 October 2006Kaiser: COMS W4156 Fall 200644 IDA #3 due TODAY!

45. 10 October 2006Kaiser: COMS W4156 Fall 200645 Project Deliverables Project concept (P/F) Revised concept (P/F) First iteration (25%) –1 st iteration plan –1 st iteration progress report –1 st iteration demo –1 st iteration final report Second iteration (25%) –2 nd iteration plan –Code inspection –2 nd iteration progress report –2 nd iteration demo –2 nd iteration final report

46. 10 October 2006Kaiser: COMS W4156 Fall 200646 First Iteration Plan due Tuesday October 24 th The purpose of this assignment is to –more precisely define the requirements for your systems, and –to plan the engineering tasks necessary to fulfill those requirements.

47. 10 October 2006Kaiser: COMS W4156 Fall 200647 Requirements Reconsider the user stories or informal use cases you submitted for your Revised Project Concept. –It may be appropriate to subdivide some requirements and merge others. –You may also want to add or remove some requirements. Assign a priority to each requirement, e.g., high, medium, low. –Any requirements that must be fulfilled in order to demonstrate your system should be labeled as high priority.

48. 10 October 2006Kaiser: COMS W4156 Fall 200648 Work Breakdown Refine and elaborate your user stories or informal use cases as engineering tasks. Some requirements may consist of multiple engineering tasks. –Make sure to label each engineering task with the requirement it corresponds to. “Infrastructure” tasks: –Some engineering tasks may cut across multiple functional requirements, such as implementing a database facility or a client GUI –Some engineering tasks may not correspond directly to functional requirements, such as getting the component model framework up and running, setting up a shared code repository, etc.

49. 10 October 2006Kaiser: COMS W4156 Fall 200649 Work Breakdown Assign each engineering task a positive number of "points", where a "point" is the amount of work you expect one pair to be able to accomplish within one week. You will probably want to assign most tasks as fractional, e.g., 1/2 point, 1/4 point, etc. You have three weeks between the Revised Project Concept deadline (Tuesday 17 October) and the beginning of demo week (Wednesday 8 November) –So for a two-pair team, there should be a maximum of 6 points assigned to high priority requirements and infrastructure (maximum 3 points if only one pair) –It is ok if there are fewer than 6 points. –Note one of those weeks will already be past by the time this assignment is due!

50. 10 October 2006Kaiser: COMS W4156 Fall 200650 Schedule Map out a day to day schedule for the three weeks, including the week already past. –Your schedule should include both already completed tasks as well as upcoming tasks. –You do not need to show the schedule in any fancy format such as a Gantt or Pert chart. Keep in mind that you must have a demoable system at the end of this iteration, to be able to show during the first iteration demo week (November 8-14). A "sliding scale" of extra credit will be granted to teams who demo earlier during demo week rather than later.

51. 10 October 2006Kaiser: COMS W4156 Fall 200651 First Iteration Plan: Deliverables 1.Cover page (maximum 1 page): Team name, membership, which component model framework you are using 2.Requirements (maximum 4 pages): Define your requirements in the form of use cases or informal use cases, each with a stated priority. You may be able to copy and paste much of this from your Revised Project Concept, but make sure to add the priorities! 3.Work Breakdown (maximum 4 pages): Define your engineering tasks, each with a (fractional) point value. Give the detailed schedule with personnel assignments for completing the engineering tasks, including any work already completed. 4.Controversies (maximum 1 page) Post in YOUR TEAM FOLDER on CourseWorks

52. 10 October 2006Kaiser: COMS W4156 Fall 200652 Upcoming Revised project concept due October 17 th First iteration plan due October 24 th First iteration progress report due October 31 st First demo week November 8-14 First iteration final report due November 14

53. 10 October 2006Kaiser: COMS W4156 Fall 200653 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/