06 September 2007Kaiser: COMS W4156 Fall COMS W4156: Advanced Software Engineering Prof. Gail Kaiser

06 September 2007Kaiser: COMS W4156 Fall Software Engineering Activities System Engineering Process Selection and Training Requirements –Eliciting –Analysis –Recording Technology Selection and Training Design –Architecture –Components –Modules Coding –Unit Testing –Debugging Integration –Build –Integration Testing –Configuration Management System Testing –Performance Testing & Optimization –Acceptance Testing –Beta Testing Deployment –Delivery –Installation Operations –System Management –Maintenance –Upgrades Support Activities –Project Planning and Tracking –Customer Interaction –Process Improvement –Training –Documentation –Personnel Management

06 September 2007Kaiser: COMS W4156 Fall Software Process Major Task Identification Sequencing General model to be tailored In the beginning was......

06 September 2007Kaiser: COMS W4156 Fall Build First Version Retirement Operations Modify until Customer satisfied Code-and-Fix

06 September 2007Kaiser: 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

06 September 2007Kaiser: COMS W4156 Fall Requirements Validate Retirement Operations Test Implementation Verify Design Waterfall

06 September 2007Kaiser: COMS W4156 Fall More Detailed Waterfall REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

06 September 2007Kaiser: 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

06 September 2007Kaiser: COMS W4156 Fall Waterfall* REQUIREMENTS ANALYSIS SYSTEM DESIGN PROGRAM DESIGN CODING UNIT & INTE- GRATION TESTING SYSTEM TESTING ACCEPTANCE TESTING OPERATION & MAINTENANCE

06 September 2007Kaiser: COMS W4156 Fall Requirements Validate Retirement Operations Test Implementation Verify Design Requirements Change Waterfall*

06 September 2007Kaiser: COMS W4156 Fall Prototyping Initial Concept Complete and Release Prototype Refine Prototype Until Acceptance Design and Implement Initial Prototype

06 September 2007Kaiser: COMS W4156 Fall 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 won’t commit to specification Once requirements “known”, waterfall (or some other process model) 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 (and management) may need to be “educated” about prototypes: a prototype is not 80-90% of the final product, usually not even 10%

06 September 2007Kaiser: COMS W4156 Fall Incremental (Staged) Detailed Design, Implement, Test, Deliver Feature Set Requirements Validate Retirement Operations Verify Architectural Design

06 September 2007Kaiser: 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

06 September 2007Kaiser: 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

06 September 2007Kaiser: 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

06 September 2007Kaiser: COMS W4156 Fall Agile Programming Initial Concept Operations Acceptance Testing and Delivery Requirements and Iteration Planning Next Iteration Design and Implement

06 September 2007Kaiser: COMS W4156 Fall Discussion of Agile Each iteration a mini-project –Each iteration’s deliverable 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: –Set the date for delivering an iteration –Date cannot change –Only functionality (scope) can change –Short duration iterations (weeks, not months)

06 September 2007Kaiser: 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 –…

06 September 2007Kaiser: 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

06 September 2007Kaiser: COMS W4156 Fall Gantt chart example Programmer working on a small software project Explicit start time, end time, and duration (e.g., in days ) Explicit calendar bar

06 September 2007Kaiser: COMS W4156 Fall Another Gantt

06 September 2007Kaiser: 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

06 September 2007Kaiser: COMS W4156 Fall Another Pert

06 September 2007Kaiser: COMS W4156 Fall The BIG Question: How do you know how long a software engineering task is going to take?

06 September 2007Kaiser: 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 end-user’s viewpoint

06 September 2007Kaiser: COMS W4156 Fall 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

06 September 2007Kaiser: COMS W4156 Fall UFP Scores LowMediumHigh Input files 346 Output files 457 Inquiries 346 Internal files External interfaces 5710

06 September 2007Kaiser: 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)

06 September 2007Kaiser: 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

06 September 2007Kaiser: 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

06 September 2007Kaiser: 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

06 September 2007Kaiser: 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

06 September 2007Kaiser: 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 implemented 29 FPs?

06 September 2007Kaiser: 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) –

06 September 2007Kaiser: 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, dividing according to development mode

06 September 2007Kaiser: 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

06 September 2007Kaiser: 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

06 September 2007Kaiser: 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

06 September 2007Kaiser: 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 - and elsewhere - but costs $$$) Supporting software available from USC and commercially

06 September 2007Kaiser: 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

06 September 2007Kaiser: COMS W4156 Fall Software Engineering Activities System Engineering Process Selection and Training Requirements –Eliciting –Analysis –Recording Technology Selection and Training Design –Architecture –Components –Modules Coding –Unit Testing –Debugging Integration –Build –Integration Testing –Configuration Management System Testing –Performance Testing & Optimization –Acceptance Testing –Beta Testing Deployment –Delivery –Installation Operations –System Management –Maintenance –Upgrades Support Activities –Project Planning and Tracking –Customer Interaction –Process Improvement –Training –Documentation –Personnel Management

06 September 2007Kaiser: COMS W4156 Fall Requirements What is the (future) software system supposed to “do”? And “why?” Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design Usage scenarios –User stories –Use Cases –Process specifications –Generic natural language –…

06 September 2007Kaiser: COMS W4156 Fall User Stories Written by the customers (or end-users) as things that the system needs to do for them About 3 sentences in the customer’s terminology, without technical detail Written on index cards (!) May be augmented by samples (e.g., formatted report) Prioritize (high, medium, low) Generally does not address non-functional requirements (e.g., performance, security)

06 September 2007Kaiser: COMS W4156 Fall Example Story Card 111 Instructor View The instructor view for a given course includes the course number, name and semester; a button to edit the introduction; a button to designate library reserves; and a button to adjust settings for the course. Otherwise the instructor view is the same as the student view. Priority High

06 September 2007Kaiser: COMS W4156 Fall Continuing Example 222 Student View The student view for a given course includes the course number, name and semester; general course information; and instructor information. There are buttons to select introduction, discussion, board, class , dictionary, notepad and help. Priority High

06 September 2007Kaiser: COMS W4156 Fall Continuing Example 123 Instructor vs. Student View When an instructor selects one of the courses he/she is teaching, the instructor view is shown. The instructor view should include a button to show the student view, and then that special student view should include a button to switch back to the instructor view Priority Medium

06 September 2007Kaiser: COMS W4156 Fall Continuing Example 321 Login The user is prompted to enter uni and password If the uni and password match database, the user is shown the default screen with his/her list of current courses Priority High

06 September 2007Kaiser: COMS W4156 Fall Why are user stories on cards? Easy to rip up Tangible Unit of –Discussion –Estimation –Scheduling –Testing –Completion Used for: –Construction of engineering tasks –Creation of acceptance tests –Derivation of time estimates for planning

06 September 2007Kaiser: COMS W4156 Fall Use Case Modeling Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal Use case model emphasizes the behavior as it appears to external actors, treats the system as a black box Partitions system functionality into interactions (‘use cases’) that are meaningful to users or external systems (‘actors’) Sometimes hundreds of use cases are needed to fully specify a system

06 September 2007Kaiser: COMS W4156 Fall Use Case Diagram Using, e.g., UML = Unified Modeling Language Visualizes the high-level functions of the system and the system's scope –Including the relationship of "actors" to essential processes and system functionality –As well as the relationships among different use cases By looking at a use case diagram, you can easily tell the functions that the system provides (and doesn’t provide) Generally does not address non-functional requirements (e.g., performance, security)

06 September 2007Kaiser: COMS W4156 Fall Example Use Case This system lets the band manager view a sales statistics report and the Billboard 200 report for the band's CDs It also lets the record manager view a sales statistics report and the Billboard 200 report for a particular CD The diagram also tells us that our system delivers Billboard reports from an external system called Billboard Reporting Service

06 September 2007Kaiser: COMS W4156 Fall Continuing Example This use case diagram does not provide a way for a band manager to listen to songs from the different albums on the Billboard 200 — i.e., we see no reference to a use case called Listen to Songs from Billboard 200

06 September 2007Kaiser: COMS W4156 Fall Another Simple Example

06 September 2007Kaiser: COMS W4156 Fall Fig. 3-54, UML Notation Guide Not So Simple Use Case Relationships

06 September 2007Kaiser: COMS W4156 Fall Yet Another Simple Example

06 September 2007Kaiser: COMS W4156 Fall More Not So Simple Use Case Relationships

06 September 2007Kaiser: COMS W4156 Fall Use Cases vs. User Stories Both intended to capture functional requirements Neither directly address non-functional requirements Use Cases are more formal User Stories tend to be more fine-grained User Stories don’t easily map relationships

06 September 2007Kaiser: COMS W4156 Fall One problem with User Stories and User Cases Where do the usage scenarios come from? The customers (or users). But how do the customers know what to put in their usage scenarios?

06 September 2007Kaiser: COMS W4156 Fall Requirements Elicitation Process of “discovering” the requirements for a system Through communication with customers, system users, system administrators and other stakeholders Through domain analysis Through investigation of previous and similar systems – reuse requirements –Saves time and money –Reduces risk –Reused requirements have a better chance of being understood by all stakeholders –Requirements reuse may lead to additional reuse in other lifecycle activities

06 September 2007Kaiser: COMS W4156 Fall Requirements Elicitation Use Business Concerns to drive elicitation –If a system is to be useful, it must contribute to the key concerns of the business –If those business concerns are identified and used as drivers of the requirements elicitation process, there will be higher confidence that the system will meet real organization needs Collect requirements from Multiple Viewpoints –If the requirements are collected from a single viewpoint, unlikely to meet other stakeholders requirements –Identified viewpoints can be used to help organize requirements elicitation and the resulting requirements specification

06 September 2007Kaiser: COMS W4156 Fall Requirements Challenges: “Yes, But” The first time users see the system, the first reaction is either, “Wow this is so cool” or “Yes, but, hmm, now that I see it what about this…?” This reaction is simply human nature Need to get the “buts” out early Anticipate that there will be “buts” and add time and resources to plan for feedback

06 September 2007Kaiser: COMS W4156 Fall Requirements Challenges: “Undiscovered Ruins” Developers struggle with determining when they are done with requirements elicitation –How can we tell whether all the requirements have been elicited, or have we found at least enough? –Like asking an archeologist “how many undiscovered ruins are there?” First scope the elicitation effort by defining the business problem(s) to be solved by the system Employ techniques that help find some of those ruins and get the stakeholders to buy-into the requirements

06 September 2007Kaiser: COMS W4156 Fall Requirements Challenges: “User versus Developer” Users do not know what they want, or cannot articulate it Users think they know what they want until developers give them what they said they wanted Developers think they understand user problems better than users do Recognize and appreciate the users as domain experts Provide alternative elicitation techniques earlier: storyboard, role playing, prototypes, etc. Put the developers in the users’ place

06 September 2007Kaiser: COMS W4156 Fall Requirements Challenge: Living with “the Sins of your Predecessors” Like it or not, your customers and developers remember what happened in the past –“Total Quality Management” programs that promised things would be different –The last project where requirements were vague and/or were delivered short of expectations Need to build trust slowly: do not over-commit to features, schedule or budget Deliver highest priority features early

06 September 2007Kaiser: COMS W4156 Fall Requirements Elicitation Techniques Interviewing and questionnaires Brainstorming and idea reduction Storyboarding Role Playing Requirements workshops Prototyping

06 September 2007Kaiser: COMS W4156 Fall Technique: Interviewing Simple direct technique Context-free questions about what system needs to do for the users Convergence on some common needs will initiate a “requirements repository” A questionnaire is no substitute for an interview, but may precede or follow interviews

06 September 2007Kaiser: COMS W4156 Fall Interview: Context-free questions Goal is to prevent prejudicing the user’s response to the questions Examples: –Who is the customer? –Who is the user? –Who is the user’s customer? –Are their needs different? –Where else can a solution to this problem be found? After context-free questions are asked, suggested solutions can be explored

06 September 2007Kaiser: COMS W4156 Fall Technique: Brainstorming Brainstorming involves both idea generation and idea reduction The most creative, innovative ideas often result from combining seemingly unrelated ideas Various voting techniques may be used to prioritize the ideas created Although live brainstorming is preferred, web- based brainstorming may be a viable alternative

06 September 2007Kaiser: COMS W4156 Fall Rules for Brainstorming Do not allow criticism or debate Let your imagination soar Generate as many ideas as possible Mutate and combine ideas Only then do Idea Reduction –Prune ideas that are not worthy of further discussion –Group similar ideas into one super topic Prioritize the remaining ideas

06 September 2007Kaiser: COMS W4156 Fall Technique: Storyboarding Scripted walkthrough of system activities and/or screen mockups Identify the players, explain what happens to them, and describes how it happens Make the storyboard sketchy and easy to modify

06 September 2007Kaiser: COMS W4156 Fall Technique: Role Playing Role playing allows developers to experience the user’s world from the user’s perspective Live storyboard or unscripted walkthrough Generate system activities and/or screen mockups as you go along

06 September 2007Kaiser: COMS W4156 Fall Technique: Requirements Workshop Perhaps the most powerful technique for eliciting requirements Gather all key stakeholders together for a short but intensely focused period Use an outside facilitator experienced in requirements management May combine interviewing, brainstorming, storyboards, role playing

06 September 2007Kaiser: COMS W4156 Fall Technique: Prototyping Partial implementation of a software system, built to help developers, users and customers better understand system requirements Focus on the “fuzzy” requirements: poorly defined and/or poorly understood

06 September 2007Kaiser: COMS W4156 Fall Reminder: First Assignments Due Next Week! Tuesday 11 September, 10am Assignments posted on course websitecourse website Submit via CourseWorksCourseWorks Individual Development Assignment #1 Pair Formation

06 September 2007Kaiser: COMS W4156 Fall Upcoming Deadlines Individual development assignment #2 due September 18 th Teams announced September 18 th Team project concept due September 25 th Individual development assignment #3 due October 2 nd Revised project concept due October 9 th – first iteration begins

06 September 2007Kaiser: COMS W4156 Fall COMS W4156: Advanced Software Engineering Prof. Gail Kaiser