1. 06 September 2007Kaiser: COMS W4156 Fall 20071 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19. 06 September 2007Kaiser: COMS W4156 Fall 200719 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 –…

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

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

22. 06 September 2007Kaiser: COMS W4156 Fall 200722 Another Gantt

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

24. 06 September 2007Kaiser: COMS W4156 Fall 200724 Another Pert

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

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

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

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

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

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

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

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

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

34. 06 September 2007Kaiser: COMS W4156 Fall 200734 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 implemented 29 FPs?

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

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

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

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

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

40. 06 September 2007Kaiser: COMS W4156 Fall 200740 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 http://sunset.usc.edu/research/COCOMOII/

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

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

43. 06 September 2007Kaiser: COMS W4156 Fall 200743 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 –…

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

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

46. 06 September 2007Kaiser: COMS W4156 Fall 200746 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 e-mail, dictionary, notepad and help. Priority High

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

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

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

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

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

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

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

54. 06 September 2007Kaiser: COMS W4156 Fall 200754 Another Simple Example

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

77. 06 September 2007Kaiser: COMS W4156 Fall 200777 COMS W4156: Advanced Software Engineering Prof. Gail Kaiser Kaiser+4156@cs.columbia.edu http://york.cs.columbia.edu/classes/cs4156/