10 October 2006Kaiser: COMS W4156 Fall COMS W4156: Advanced Software Engineering Prof. Gail Kaiser

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

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

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

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

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

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

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

10 October 2006Kaiser: COMS W4156 Fall 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 October 2006Kaiser: COMS W4156 Fall Waterfall* REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

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

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

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

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

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

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

10 October 2006Kaiser: COMS W4156 Fall 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 Constraints Budget Alternatives 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

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

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

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

10 October 2006Kaiser: COMS W4156 Fall 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 –…

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

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

10 October 2006Kaiser: COMS W4156 Fall Another Gantt

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

10 October 2006Kaiser: COMS W4156 Fall Another Pert

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

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

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

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

10 October 2006Kaiser: COMS W4156 Fall 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 * ( TCF)

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

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

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

10 October 2006Kaiser: COMS W4156 Fall 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 Distributed data processing 32.2 Online data management 43.2 Need to reuse the code later 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) Requirements to run on multiple sites Readiness to change2 Partial (3)13 Total = 39

10 October 2006Kaiser: COMS W4156 Fall FP for Making Cappuccino FP = UFP * ( TCF) = 28 * ( (39 * 0.01)) = So what was the time/effort required last time your firm implement 29 FPs?

10 October 2006Kaiser: COMS W4156 Fall 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!) –

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10 October 2006Kaiser: COMS W4156 Fall COMS W4156: Advanced Software Engineering Prof. Gail Kaiser