Lecture 2 Software Process Models / Requirements Analysis Topics Mythical Man Month Waterfall model Spiral Method Requirements Analysis Readings: Chapter 3 May 31, 2006 CSCE 492 Software Engineering

– 2 – CSCE 492 Summer 2006 Overview Last Time Overview Quality Software Today’s Lecture Pragmatics UML references, Teams Models for the process of software development Waterfall model, Spiral model, Agile, RequirementsReferences: Chapters 2 and 3 of the text Boehm paper “Spiral Model” Next Time:

– 3 – CSCE 492 Summer 2006 UML – Unified Modeling Language UML reference Website of Quickreference Cards

– 4 – CSCE 492 Summer 2006 Teams Hal Hubbard, Jeremy Lane, Yoni Rayburn, Marvin Million Hal Hubbard, Jeremy Lane, Yoni Rayburn, Marvin Million Lewis Clyburn, Scott Sanders, Eun Yoon Lewis Clyburn, Scott Sanders, Eun Yoon Segi Simmons, Pinar Wilbanks, Adriel Shaw, Segi Simmons, Pinar Wilbanks, Adriel Shaw, Clarke ? Clarke ?

– 5 – CSCE 492 Summer 2006 Working in Teams Be conscientious about due dates Be conscientious about due dates Meet regularly with your team Meet regularly with your team Always create an agenda for every team meeting Always create an agenda for every team meeting Rotate responsibility for chairing team meetings Rotate responsibility for chairing team meetings Authors’ slide modified

– 6 – CSCE 492 Summer 2006 Holding Effective Team Meetings Create a clear agenda addressing the essential tasks that must be accomplished in order to complete the necessary deliverables Create a clear agenda addressing the essential tasks that must be accomplished in order to complete the necessary deliverables Stick to the agenda during the meeting Stick to the agenda during the meeting Ensure that each team member understands his or her tasks before the meeting is adjourned Ensure that each team member understands his or her tasks before the meeting is adjourned Ensure that tasks are equitably distributed Ensure that tasks are equitably distributed Authors’ slide modified

– 7 – CSCE 492 Summer 2006 Class Project Deliverables The deliverables associated with the class project are essential to successfully completing the project The deliverables associated with the class project are essential to successfully completing the project The class project is not merely a programming assignment The class project is not merely a programming assignment The deliverables result from completing tasks associated with analysis, design, implementation, and testing the class project The deliverables result from completing tasks associated with analysis, design, implementation, and testing the class project Authors’ slide modified

– 8 – CSCE 492 Summer 2006 Should we fix this bug or not? Four questions when a bug is discovered  (Severity) When this bug happens, how bad is the impact?  (Frequency) How often does this bug happen?  (Cost) How much effort would be required to fix this bug?  (Risk) What is the risk of fixing this bug?

– 9 – CSCE 492 Summer 2006 Severity and Frequency The vertical axis is Severity. The vertical axis is Severity. The top of the graph represents a bug with extremely severe impact: "This bug causes the user's computer to burst into flame." The bottom of the graph represents a bug with extremely low impact: "One of the pixels on the splash screen is the wrong shade of gray." The horizontal axis is Frequency. The horizontal axis is Frequency. The right side represents a bug which happens extremely often: "Every user sees this bug every day." The left side represents a bug which happens extremely seldom: "This bug only affects people who live in eastern Washington state and who have both Visual Studio 2003 and Visual Studio 2005 installed and it only happens during leap years on the day that daylight savings time goes into effect and only if the first day of that month was a Tuesday."

– 10 – CSCE 492 Summer 2006 Mythical Man-Month Main Ideas in “Mythical Man-Month” collection of essays Mythical Man-Month Mythical Man-Month Second-system effect Second-system effect Second-system effect Second-system effect IBM 7094  360, the second system an engineer designs will be too ambitious, including way too much Progress Tracking Progress Tracking Question: How does a large software project get to be one year late? Answer: One day at a time! Question: How does a large software project get to be one year late? Answer: One day at a time! Conceptual Integrity Conceptual Integrity The Pilot System The Pilot System Communication Communication

– 11 – CSCE 492 Summer 2006 Software Crisis "[The major cause of the software crisis is] that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem." Edsger Dijkstra: The Humble Programmer (PDF, 473Kb)

– 12 – CSCE 492 Summer 2006 Waterfall Model of Software Life Cycle Not the first iterative method But the first paper to explain why to use the iterative method Figure from Barry Boehm88

– 13 – CSCE 492 Summer 2006 Water Fall Model Requirements analysis Requirements analysis Design Design Implementation Implementation Testing (validation) Testing (validation) Integration Integration maintenance maintenanceReference

– 14 – CSCE 492 Summer 2006 Requirements Analysis Software requirements analysis is the activity of eliciting, analyzing, and recording requirements for software systems. requirements 1 Eliciting Requirements 2 Analyzing Requirements 3 Recording Requirements

– 15 – CSCE 492 Summer 2006 Software testing Software testing is the process used to help identify the correctness, completeness, security and quality of developed computer software. correctnesscompletenesssecurityqualitycomputer software correctnesscompletenesssecurityqualitycomputer software testing can never completely establish the correctness of arbitrary computer software. testing can never completely establish the correctness of arbitrary computer software. computability theory, a field of computer science, an elegant mathematical proof concludes that it is impossible to solve the halting problem computability theory, a field of computer science, an elegant mathematical proof concludes that it is impossible to solve the halting problem computability theorycomputer sciencehalting problem computability theorycomputer sciencehalting problem Categories of Testing Techniques Categories of Testing Techniques Black box vs white or clear box Functional vs Structural (refinement of the black vs white)

– 16 – CSCE 492 Summer 2006 Capability Maturity Model Integration Capability Maturity Model (CMM now CMMI) is a collection of instructions an organization can follow with the purpose to gain better control over its software development process. The CMM ranks software development organizations in a hierarchy of five levels, each with a progressively greater capability of producing quality software.  Chaos 75% fall organizations here. . . . .

– 17 – CSCE 492 Summer 2006 Current trends in software engineering Aspects Aspects Agile Agile Software architectures Software architectures Software Product lines Software Product lines

– 18 – CSCE 492 Summer 2006 Agile Software Development We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. … Reference: Reference:

– 19 – CSCE 492 Summer 2006 Requirements Analysis A requirement is a feature of the system A requirement is a feature of the system Requirements analysis seeks to assess and specify the behavior of the final system Requirements analysis seeks to assess and specify the behavior of the final system Requirements analysis can be iteratively carried out or done in a top-down fashion Requirements analysis can be iteratively carried out or done in a top-down fashion It is desirable to establish the breadth of behavior of a system to determine the primary classes that will comprise the system It is desirable to establish the breadth of behavior of a system to determine the primary classes that will comprise the systemReference: Most requirements analysis slides are from authors

– 20 – CSCE 492 Summer 2006 The Importance of Requirements Analysis Frederick Brooks: “The hardest single part of building a software system is deciding precisely what to build” Barry Boehm: by investing more up-front effort in verifying and validating the software requirements, software developers will see reduced integration and test costs, as well as higher software reliability and maintainability

– 21 – CSCE 492 Summer 2006 Examples of Good Requirements Analysis Participatory analysis Involves staff members of all levels from the domain area interacting directly with the development team Negotiation-based technique Developed by USC Center for Software Engineering Collaborative analysis approach involving end-users

– 22 – CSCE 492 Summer 2006 Requirements Specification Requirements analysis results in a complete, consistent, correct, and unambiguous requirements specification The initial specification may be created by the end users or by the technical staff Independent of the source of the initial specification it must be refined and verified to be correct and complete

– 23 – CSCE 492 Summer 2006 Possible Elements of Requirements Specification Supported activity list Supported activity list Human-computer interface description Human-computer interface description solved problem list solved problem list Information source list Information source list Information requesting organization list Information requesting organization list Checks and balances Checks and balances Security and fault-tolerant requirements Security and fault-tolerant requirements

– 24 – CSCE 492 Summer 2006 More: Possible Elements of Requirements Specification Inter-operating systems list Inter-operating systems list Estimates of present information capacity and projected growth Estimates of present information capacity and projected growth Project time frame Project time frame Prioritization of requirements Prioritization of requirements Ethical concerns list Ethical concerns list

– 25 – CSCE 492 Summer 2006 Case Study: Library Management System Independent of who creates the requirements specification (end users or technical staff), it is the responsibility of the system developers to ensure the user requirements are adequately fleshed out The first step of requirements analysis is to establish and refine the problem statement which takes the form of the requirements specification

– 26 – CSCE 492 Summer 2006 LMS Case Study: Clarifying the Requirements Specification What sort of human-computer interface is envisioned? What sort of human-computer interface is envisioned? What sort of search facility is necessary for library patrons? What sort of search facility is necessary for library patrons? Will patrons be assigned a unique ID number? Will patrons be assigned a unique ID number? Should the system support inter-library loan requests? Should the system support inter-library loan requests?

– 27 – CSCE 492 Summer 2006 LMS Case Study: More Clarifying the Requirements Specification Are there any limits on patrons’ use of research databases? Are there any limits on patrons’ use of research databases? How are books retired from the library collection? How are books retired from the library collection? How long are requested books held for patrons? How long are requested books held for patrons? Are overdue fees the same for all type of library resources? Are overdue fees the same for all type of library resources? Which online databases will the system interact with? Which online databases will the system interact with?

– 28 – CSCE 492 Summer 2006 Creating Quality Requirements Specifications The key is to keep in close communication with the end users throughout the development process, but especially during requirements analysis The key is to keep in close communication with the end users throughout the development process, but especially during requirements analysis Ideally, a whole array of different end users should be involved with the development team to gain sufficient breadth of input Ideally, a whole array of different end users should be involved with the development team to gain sufficient breadth of input

– 29 – CSCE 492 Summer 2006 LMS Case Study: Supported Activity List Support Library staff activities like checking out resources to patrons Support Library staff activities like checking out resources to patrons Validating patrons Validating patrons Current membership No resources more than two weeks overdue Not over maximum of checked resources Assigning library numbers to patrons Assigning library numbers to patrons

– 30 – CSCE 492 Summer 2006 LMS Case Study: More Supported Activity List Deleting expired library numbers and associated patron records Deleting expired library numbers and associated patron records Checking out library resources: books,CDs, etc Checking out library resources: books,CDs, etc Checking in library resources Checking in library resources Changing the status of a library resource Changing the status of a library resource Allowing materials to be placed on reserve Allowing materials to be placed on reserve Allowing the searching of the library’s holdings on line Allowing the searching of the library’s holdings on line Additional activities listed in text Additional activities listed in text

– 31 – CSCE 492 Summer 2006 Other Elements of the LMS Requirements Specification Human-computer interface Human-computer interface Solved problems list Solved problems list Information source list Information source list Information requesting organizations Information requesting organizations Automated checks and balances Automated checks and balances Security and fault-tolerant requirements Security and fault-tolerant requirements Present information capacity and projected growth Present information capacity and projected growth

– 32 – CSCE 492 Summer 2006 More Elements of the LMS Requirements Specification Projected time frame Prioritization of requirements Ethical concerns Who has access of borrowing history of patrons? How are children protected from questionable materials found on the Internet?

– 33 – CSCE 492 Summer 2006 Verifying Requirements A structured walkthrough with the end users is a good technique for ensuring that the user needs are being addressed A structured walkthrough with the end users is a good technique for ensuring that the user needs are being addressed To ensure that the resulting software supports the requirements specification, items on the supported activity list are numbered and propagated through the software models and source code To ensure that the resulting software supports the requirements specification, items on the supported activity list are numbered and propagated through the software models and source code

– 34 – CSCE 492 Summer 2006 The Process of Requirements Analysis Create verified requirements specification Create verified requirements specification Create list of primary classes Create list of primary classes Create informal scenarios Create informal scenarios Create use cases Create use cases Create scenarios Create scenarios Create class diagrams Create class diagrams Create use case diagrams Create use case diagrams

– 35 – CSCE 492 Summer 2006 Identifying Use Cases A use case is a description of a scenario (or closely related set of scenarios) in which the system interacts with users of the system A use case is a description of a scenario (or closely related set of scenarios) in which the system interacts with users of the system The behavior of the system is expressed without specifying how the behavior is implemented The behavior of the system is expressed without specifying how the behavior is implemented Use cases are initially described narratively, and then modeled graphically by class diagrams and interaction diagrams (to be discuss later) Use cases are initially described narratively, and then modeled graphically by class diagrams and interaction diagrams (to be discuss later) Informal scenarios are a good starting point for use cases Informal scenarios are a good starting point for use cases

– 36 – CSCE 492 Summer 2006 Characteristics of Use Cases Use cases are more abstract than informal scenarios Use cases are more abstract than informal scenarios A single use case may encompass multiple scenarios A single use case may encompass multiple scenarios Use cases avoid redundancy Use cases avoid redundancy Use cases are more formally structured than scenarios Use cases are more formally structured than scenarios Use cases seek to capture complete breadth of system behavior Use cases seek to capture complete breadth of system behavior

– 37 – CSCE 492 Summer 2006 Use Case Layout Precondition Precondition What conditions must be true at the beginning of the use case? Main flow of events Main flow of events Describe the essential behavior associated with the use case Post condition Post condition What occurs as a result of the use case executing Exceptional flow of events ( zero to many) Exceptional flow of events ( zero to many) Enumerate possible erroneous flow of events

– 38 – CSCE 492 Summer 2006 LMS Case Study: Use Cases Validate patron Validate patron Check out resource Check out resource Check in resource Check in resource Request resource Request resource Reserve resource Reserve resource Manage Resource Manage Resource Manage Patron Manage Patron Generate from letter Generate from letter

– 39 – CSCE 492 Summer 2006 LMS Case Study: Check out Resource Use Case Precondition Library staff and patron validated to LMS Library DB initialized Main flow of events Enter resource Determine due date Exceptional flow of events Patron ID not valid Patron has over due resources or too many checked Resource number not valid

– 40 – CSCE 492 Summer 2006 More LMS Case Study: Check out Resource Use Case Postcondition Patron DB entry updated to reflect new resource Resource DB entry updated to reflect changed status: checked out Due date assigned to the resource DB entry

– 41 – CSCE 492 Summer 2006 Scenario Development Scenarios are derived from use cases Scenarios are like informal scenarios, but are more formally structured Informal scenarios may be modified to produce scenarios Use cases are abstract because they do not reference specific values Scenarios are concrete because they do reference specific values Multiple scenarios may be required for a single use case

– 42 – CSCE 492 Summer 2006 UML Use Case Diagrams Use case diagrams depict use cases interacting with external actors Use case diagrams depict use cases interacting with external actors External actors are entities that interact with the software system, like system users, databases, or books External actors are entities that interact with the software system, like system users, databases, or books Use cases represent system requirements and show a functional partitioning of the system Use cases represent system requirements and show a functional partitioning of the system Functional partitioning is useful for a dividing a system into smaller pieces Functional partitioning is useful for a dividing a system into smaller pieces

– 43 – CSCE 492 Summer 2006 Notational Elements of Use Case Diagrams Use case name ActorUse case Relationships: Dependency AssociationGeneralization

– 44 – CSCE 492 Summer 2006 LMS Case Study: Use Case Diagram Browse Resource Request Resource Reserve Resource Patron Resource

– 45 – CSCE 492 Summer 2006 Steps in UCCD Analysis Process Create/refine requirements specification Create informal scenarios Create list of primary classes Create use cases Create scenarios from use cases Create class diagrams showing basic inter-class relationships Model key class collaborations Create use case diagrams