Lecture 2 Software Process Models / Requirements Analysis

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

description

Lecture 2 Software Process Models / Requirements Analysis. CSCE 492 Software Engineering. Topics Mythical Man Month Waterfall model Spiral Method Requirements Analysis Readings: Chapter 3. May 31, 2006. Overview. Last Time Overview Quality Software Today’s Lecture Pragmatics - PowerPoint PPT Presentation

Transcript of Lecture 2 Software Process Models / Requirements Analysis

Page 1: Lecture 2  Software Process Models /  Requirements Analysis

Lecture 2 Software Process Models /

Requirements Analysis

Topics Topics Mythical Man Month Waterfall model Spiral Method Requirements Analysis

Readings: Chapter 3Readings: Chapter 3May 31, 2006

CSCE 492 Software Engineering

Page 2: Lecture 2  Software Process Models /  Requirements Analysis

– 2 – CSCE 492 Summer 2006

OverviewLast TimeLast Time

Overview Quality Software

Today’s Lecture Today’s Lecture Pragmatics

UML references, Teams Models for the process of software development

Waterfall model, Spiral model, Agile, Requirements

References: References: Chapters 2 and 3 of the text Boehm paper “Spiral Model”

Next Time: Next Time:

Page 3: Lecture 2  Software Process Models /  Requirements Analysis

– 3 – CSCE 492 Summer 2006

UML – Unified Modeling LanguageUML referenceUML reference

http://www.holub.com/goodies/uml/

Website of Quickreference CardsWebsite of Quickreference Cards http://www.digilife.be/quickreferences/quickrefs.htm

Page 4: Lecture 2  Software Process Models /  Requirements Analysis

– 4 – CSCE 492 Summer 2006

Teams Hal Hubbard, Jeremy Lane, Yoni Rayburn, Marvin Hal Hubbard, Jeremy Lane, Yoni Rayburn, Marvin

MillionMillion Lewis Clyburn, Scott Sanders, Eun YoonLewis Clyburn, Scott Sanders, Eun Yoon Segi Simmons, Pinar Wilbanks, Adriel Shaw, Segi Simmons, Pinar Wilbanks, Adriel Shaw, Clarke ?Clarke ?

Page 5: Lecture 2  Software Process Models /  Requirements Analysis

– 5 – CSCE 492 Summer 2006

Working in Teams

Be conscientious about due datesBe conscientious about due dates Meet regularly with your teamMeet regularly with your team Always create an agenda for every team meetingAlways create an agenda for every team meeting Rotate responsibility for chairing team meetingsRotate responsibility for chairing team meetings

Authors’ slide modified

Page 6: Lecture 2  Software Process Models /  Requirements Analysis

– 6 – CSCE 492 Summer 2006

Holding Effective Team Meetings Create a clear agenda addressing the essential tasks Create a clear agenda addressing the essential tasks

that must be accomplished in order to complete the that must be accomplished in order to complete the necessary deliverablesnecessary deliverables

Stick to the agenda during the meetingStick to the agenda during the meeting Ensure that each team member understands his or Ensure that each team member understands his or

her tasks before the meeting is adjournedher tasks before the meeting is adjourned Ensure that tasks are equitably distributedEnsure that tasks are equitably distributed

Authors’ slide modified

Page 7: Lecture 2  Software Process Models /  Requirements Analysis

– 7 – CSCE 492 Summer 2006

Class Project Deliverables

The deliverables associated with the class project The deliverables associated with the class project are essential to successfully completing the are essential to successfully completing the projectproject

The class project is not merely a programming The class project is not merely a programming assignmentassignment

The deliverables result from completing tasks The deliverables result from completing tasks associated with analysis, design, implementation, associated with analysis, design, implementation, and testing the class projectand testing the class project

Authors’ slide modified

Page 8: Lecture 2  Software Process Models /  Requirements Analysis

– 8 – CSCE 492 Summer 2006

Should we fix this bug or not?Four questions when a bug is discoveredFour questions when a bug is discovered

1.1. (Severity) When this bug happens, how bad is the (Severity) When this bug happens, how bad is the impact?impact?

2.2. (Frequency) How often does this bug happen? (Frequency) How often does this bug happen?

3.3. (Cost) How much effort would be required to fix this (Cost) How much effort would be required to fix this bug? bug?

4.4. (Risk) What is the risk of fixing this bug? (Risk) What is the risk of fixing this bug?

http://software.ericsink.com/articles/Four_Questions.html

Page 9: Lecture 2  Software Process Models /  Requirements Analysis

– 9 – CSCE 492 Summer 2006

Severity and FrequencyThe 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."

http://software.ericsink.com/articles/Four_Questions.html

Page 10: Lecture 2  Software Process Models /  Requirements Analysis

– 10 – CSCE 492 Summer 2006

Mythical Man-MonthMain Ideas in “Mythical Man-Month” collection of essaysMain Ideas in “Mythical Man-Month” collection of essays Mythical Man-Month Mythical Man-Month Second-system effectSecond-system effect

IBM 7094360, 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 Question: How does a large software project get to be one year

late? Answer: One day at a time!late? Answer: One day at a time! Conceptual Integrity  Conceptual Integrity  The Pilot System The Pilot System Communication Communication

http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Page 11: Lecture 2  Software Process Models /  Requirements Analysis

– 11 – CSCE 492 Summer 2006

Software Crisis"[The major cause of the software crisis is] that the "[The major cause of the software crisis is] that the

machines have become several orders of magnitude machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as more powerful! To put it quite bluntly: as long as there were no machines, programming was no there were no machines, programming was no problem at all; when we had a few weak computers, problem at all; when we had a few weak computers, programming became a mild problem, and now we programming became a mild problem, and now we have gigantic computers, programming has become have gigantic computers, programming has become an equally gigantic problem." an equally gigantic problem." Edsger Dijkstra: The Humble Programmer (PDF, 473Kb)

Page 12: Lecture 2  Software Process Models /  Requirements Analysis

– 12 – CSCE 492 Summer 2006

Waterfall Model of Software Life CycleNot the first iterative Not the first iterative

methodmethod

But the first paper to But the first paper to explain why to use explain why to use the iterative methodthe iterative method

Figure from Barry Boehm88

Page 13: Lecture 2  Software Process Models /  Requirements Analysis

– 13 – CSCE 492 Summer 2006

Water Fall Model Requirements analysis Requirements analysis DesignDesign ImplementationImplementation Testing (validation)Testing (validation) IntegrationIntegration maintenancemaintenance

ReferenceReference http://en.wikipedia.org/wiki/Waterfall_processhttp://en.wikipedia.org/wiki/Waterfall_process

Page 14: Lecture 2  Software Process Models /  Requirements Analysis

– 14 – CSCE 492 Summer 2006

Requirements AnalysisSoftware requirements analysis is the activity of Software requirements analysis is the activity of

eliciting, analyzing, and recording eliciting, analyzing, and recording requirementsrequirements for for software systems. software systems.

1 Eliciting Requirements1 Eliciting Requirements

2 Analyzing Requirements2 Analyzing Requirements

3 Recording Requirements3 Recording Requirements

Page 15: Lecture 2  Software Process Models /  Requirements Analysis

– 15 – CSCE 492 Summer 2006

Software testingSoftware testing is the process used to help identify the Software testing is the process used to help identify the

correctnesscorrectness, , completenesscompleteness, , securitysecurity and and qualityquality of of developed developed computer softwarecomputer software. .

testing can never completely establish the testing can never completely establish the correctness of arbitrary computer software. correctness of arbitrary computer software.

computability theorycomputability theory, a field of , a field of computer sciencecomputer science, an , an elegant mathematical proof concludes that it is elegant mathematical proof concludes that it is impossible to solve the impossible to solve the halting problemhalting 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)

Page 16: Lecture 2  Software Process Models /  Requirements Analysis

– 16 – CSCE 492 Summer 2006

Capability Maturity Model IntegrationCapability Maturity Model (CMM now CMMI) is a Capability Maturity Model (CMM now CMMI) is a

collection of instructions an organization can follow collection of instructions an organization can follow with the purpose to gain better control over its with the purpose to gain better control over its software development process.software development process.

The CMM ranks software development organizations in The CMM ranks software development organizations in a hierarchy of five levels, each with a progressively a hierarchy of five levels, each with a progressively greater capability of producing quality software. greater capability of producing quality software.

1.1. Chaos 75% fall organizations here.Chaos 75% fall organizations here.2.2. ..3.3. ..4.4. ..5.5. ..

http://www.sei.cmu.edu/cmmi/general/general.html

Page 17: Lecture 2  Software Process Models /  Requirements Analysis

– 17 – CSCE 492 Summer 2006

Current trends in software engineering AspectsAspects AgileAgile Software architecturesSoftware architectures Software Product linesSoftware Product lines

Page 18: Lecture 2  Software Process Models /  Requirements Analysis

– 18 – CSCE 492 Summer 2006

Agile Software DevelopmentWe follow these principles:We follow these principles: Our highest priority is to satisfy the customerOur highest priority is to satisfy the customer

through early and continuous deliverythrough early and continuous deliveryof valuable software. of valuable software.

Welcome changing requirements, even late in Welcome changing requirements, even late in development. Agile processes harness change for development. Agile processes harness change for the customer's competitive advantage.the customer's competitive advantage.

…… Reference: http://agilemanifesto.org/principles.htmlReference: http://agilemanifesto.org/principles.html

Page 19: Lecture 2  Software Process Models /  Requirements Analysis

– 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 Requirements analysis seeks to assess and specify

the behavior of the final system the behavior of the final system Requirements analysis can be iteratively carried out Requirements analysis can be iteratively carried out

or done in a top-down fashionor done in a top-down fashion It is desirable to establish the breadth of behavior of It is desirable to establish the breadth of behavior of

a system to determine the primary classes that will a system to determine the primary classes that will comprise the systemcomprise the system

Reference:Reference: Most requirements analysis slides are from authors

Page 20: Lecture 2  Software Process Models /  Requirements Analysis

– 20 – CSCE 492 Summer 2006

The Importance of Requirements Analysis

Frederick Brooks: “The hardest single part of Frederick Brooks: “The hardest single part of building a software system is deciding precisely building a software system is deciding precisely what to build”what to build”

Barry Boehm: by investing more up-front effort in Barry Boehm: by investing more up-front effort in verifying and validating the software verifying and validating the software requirements, software developers will see requirements, software developers will see reduced integration and test costs, as well as reduced integration and test costs, as well as higher software reliability and maintainabilityhigher software reliability and maintainability

Page 21: Lecture 2  Software Process Models /  Requirements Analysis

– 21 – CSCE 492 Summer 2006

Examples of Good Requirements Analysis

Participatory analysisParticipatory analysis Involves staff members of all levels from the domain

area interacting directly with the development team

Negotiation-based techniqueNegotiation-based technique Developed by USC Center for Software Engineering Collaborative analysis approach involving end-users

Page 22: Lecture 2  Software Process Models /  Requirements Analysis

– 22 – CSCE 492 Summer 2006

Requirements SpecificationRequirements analysis results in a complete, Requirements analysis results in a complete,

consistent, correct, and unambiguous requirements consistent, correct, and unambiguous requirements specificationspecification

The initial specification may be created by the end The initial specification may be created by the end users or by the technical staffusers or by the technical staff

Independent of the source of the initial specification it Independent of the source of the initial specification it must be refined and verified to be correct and must be refined and verified to be correct and completecomplete

Page 23: Lecture 2  Software Process Models /  Requirements Analysis

– 23 – CSCE 492 Summer 2006

Possible Elements of Requirements Specification Supported activity listSupported activity list Human-computer interface descriptionHuman-computer interface description solved problem listsolved problem list Information source listInformation source list Information requesting organization listInformation requesting organization list Checks and balancesChecks and balances Security and fault-tolerant requirementsSecurity and fault-tolerant requirements

Page 24: Lecture 2  Software Process Models /  Requirements Analysis

– 24 – CSCE 492 Summer 2006

More: Possible Elements of Requirements Specification Inter-operating systems listInter-operating systems list Estimates of present information capacity and Estimates of present information capacity and

projected growthprojected growth Project time frameProject time frame Prioritization of requirementsPrioritization of requirements Ethical concerns listEthical concerns list

Page 25: Lecture 2  Software Process Models /  Requirements Analysis

– 25 – CSCE 492 Summer 2006

Case Study: Library Management System

Independent of who creates the requirements Independent of who creates the requirements specification (end users or technical staff), it is specification (end users or technical staff), it is the responsibility of the system developers to the responsibility of the system developers to ensure the user requirements are adequately ensure the user requirements are adequately fleshed outfleshed out

The first step of requirements analysis is to The first step of requirements analysis is to establish and refine the problem statement which establish and refine the problem statement which takes the form of the requirements specificationtakes the form of the requirements specification

Page 26: Lecture 2  Software Process Models /  Requirements Analysis

– 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 What sort of search facility is necessary for library patrons?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?

Page 27: Lecture 2  Software Process Models /  Requirements Analysis

– 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?

Page 28: Lecture 2  Software Process Models /  Requirements Analysis

– 28 – CSCE 492 Summer 2006

Creating Quality Requirements Specifications The key is to keep in close communication with the The key is to keep in close communication with the

end users throughout the development process, but end users throughout the development process, but especially during requirements analysisespecially during requirements analysis

Ideally, a whole array of different end users should Ideally, a whole array of different end users should be involved with the development team to gain be involved with the development team to gain sufficient breadth of inputsufficient breadth of input

Page 29: Lecture 2  Software Process Models /  Requirements Analysis

– 29 – CSCE 492 Summer 2006

LMS Case Study: Supported Activity List Support Library staff activities like checking out Support Library staff activities like checking out

resources to patronsresources to patrons

Validating patronsValidating patrons Current membership No resources more than two weeks overdue Not over maximum of checked resources

Assigning library numbers to patronsAssigning library numbers to patrons

Page 30: Lecture 2  Software Process Models /  Requirements Analysis

– 30 – CSCE 492 Summer 2006

LMS Case Study: More Supported Activity List

Deleting expired library numbers and associated patron Deleting expired library numbers and associated patron recordsrecords

Checking out library resources: books,CDs, etcChecking out library resources: books,CDs, etc Checking in library resourcesChecking in library resources Changing the status of a library resourceChanging the status of a library resource Allowing materials to be placed on reserveAllowing materials to be placed on reserve Allowing the searching of the library’s holdings on lineAllowing the searching of the library’s holdings on line Additional activities listed in textAdditional activities listed in text

Page 31: Lecture 2  Software Process Models /  Requirements Analysis

– 31 – CSCE 492 Summer 2006

Other Elements of the LMS Requirements Specification

Human-computer interfaceHuman-computer interface Solved problems listSolved problems list Information source listInformation source list Information requesting organizationsInformation requesting organizations Automated checks and balancesAutomated checks and balances Security and fault-tolerant requirementsSecurity and fault-tolerant requirements Present information capacity and projected growthPresent information capacity and projected growth

Page 32: Lecture 2  Software Process Models /  Requirements Analysis

– 32 – CSCE 492 Summer 2006

More Elements of the LMS Requirements SpecificationProjected time frameProjected time frame

Prioritization of requirementsPrioritization of requirements

Ethical concernsEthical concerns Who has access of borrowing history of patrons? How are children protected from questionable

materials found on the Internet?

Page 33: Lecture 2  Software Process Models /  Requirements Analysis

– 33 – CSCE 492 Summer 2006

Verifying Requirements A structured walkthrough with the end users is a A structured walkthrough with the end users is a

good technique for ensuring that the user needs are good technique for ensuring that the user needs are being addressedbeing addressed

To ensure that the resulting software supports the To ensure that the resulting software supports the requirements specification, items on the supported requirements specification, items on the supported activity list are numbered and propagated through activity list are numbered and propagated through the software models and source codethe software models and source code

Page 34: Lecture 2  Software Process Models /  Requirements Analysis

– 34 – CSCE 492 Summer 2006

The Process of Requirements Analysis Create verified requirements specificationCreate verified requirements specification Create list of primary classesCreate list of primary classes Create informal scenariosCreate informal scenarios Create use casesCreate use cases Create scenariosCreate scenarios Create class diagramsCreate class diagrams Create use case diagramsCreate use case diagrams

Page 35: Lecture 2  Software Process Models /  Requirements Analysis

– 35 – CSCE 492 Summer 2006

Identifying Use Cases

A use case is a description of a scenario (or closely A use case is a description of a scenario (or closely related set of scenarios) in which the system related set of scenarios) in which the system interacts with users of the systeminteracts with users of the system

The behavior of the system is expressed without The behavior of the system is expressed without specifying how the behavior is implementedspecifying how the behavior is implemented

Use cases are initially described narratively, and Use cases are initially described narratively, and then modeled graphically by then modeled graphically by class diagramsclass diagrams and and interaction diagramsinteraction diagrams (to be discuss later) (to be discuss later)

Informal scenarios are a good starting point for use Informal scenarios are a good starting point for use casescases

Page 36: Lecture 2  Software Process Models /  Requirements Analysis

– 36 – CSCE 492 Summer 2006

Characteristics of Use Cases Use cases are more abstract than informal Use cases are more abstract than informal

scenariosscenarios A single use case may encompass multiple A single use case may encompass multiple

scenariosscenarios Use cases avoid redundancyUse cases avoid redundancy Use cases are more formally structured than Use cases are more formally structured than

scenariosscenarios Use cases seek to capture complete breadth of Use cases seek to capture complete breadth of

system behaviorsystem behavior

Page 37: Lecture 2  Software Process Models /  Requirements Analysis

– 37 – CSCE 492 Summer 2006

Use Case Layout PreconditionPrecondition

What conditions must be true at the beginning of the use case? Main flow of eventsMain flow of events

Describe the essential behavior associated with the use case Post conditionPost 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

Page 38: Lecture 2  Software Process Models /  Requirements Analysis

– 38 – CSCE 492 Summer 2006

LMS Case Study: Use Cases Validate patronValidate patron Check out resourceCheck out resource Check in resourceCheck in resource Request resourceRequest resource Reserve resourceReserve resource Manage ResourceManage Resource Manage PatronManage Patron Generate from letterGenerate from letter

Page 39: Lecture 2  Software Process Models /  Requirements Analysis

– 39 – CSCE 492 Summer 2006

LMS Case Study: Check out Resource Use CasePreconditionPrecondition

Library staff and patron validated to LMS Library DB initialized

Main flow of eventsMain flow of events Enter resource Determine due date

Exceptional flow of eventsExceptional flow of events Patron ID not valid Patron has over due resources or too many checked Resource number not valid

Page 40: Lecture 2  Software Process Models /  Requirements Analysis

– 40 – CSCE 492 Summer 2006

More LMS Case Study: Check out Resource Use Case

PostconditionPostcondition 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

Page 41: Lecture 2  Software Process Models /  Requirements Analysis

– 41 – CSCE 492 Summer 2006

Scenario Development

Scenarios are derived from use casesScenarios are derived from use casesScenarios are like informal scenarios, but are more formally Scenarios are like informal scenarios, but are more formally

structuredstructuredInformal scenarios may be modified to produce scenariosInformal scenarios may be modified to produce scenariosUse cases are abstract because they do Use cases are abstract because they do notnot reference specific reference specific

valuesvaluesScenarios are concrete because they Scenarios are concrete because they do do referencereference specific valuesspecific valuesMultiple scenarios may be required for a single use caseMultiple scenarios may be required for a single use case

Page 42: Lecture 2  Software Process Models /  Requirements Analysis

– 42 – CSCE 492 Summer 2006

UML Use Case Diagrams Use case diagrams depict use cases interacting with Use case diagrams depict use cases interacting with

external actorsexternal actors External actors are entities that interact with the External actors are entities that interact with the

software system, like system users, databases, or software system, like system users, databases, or books books

Use cases represent system requirements and show Use cases represent system requirements and show a functional partitioning of the systema functional partitioning of the system

Functional partitioning is useful for a dividing a Functional partitioning is useful for a dividing a system into smaller piecessystem into smaller pieces

Page 43: Lecture 2  Software Process Models /  Requirements Analysis

– 43 – CSCE 492 Summer 2006

Notational Elements of Use Case Diagrams

Use casename

Actor Use case

Relationships:Dependency Association Generalization

Page 44: Lecture 2  Software Process Models /  Requirements Analysis

– 44 – CSCE 492 Summer 2006

LMS Case Study: Use Case Diagram

BrowseResource

RequestResource

ReserveResourcePatron Resource

Page 45: Lecture 2  Software Process Models /  Requirements Analysis

– 45 – CSCE 492 Summer 2006

Steps in UCCD Analysis Process

Create/refine requirements specificationCreate/refine requirements specificationCreate informal scenariosCreate informal scenariosCreate list of primary classesCreate list of primary classesCreate use casesCreate use casesCreate scenarios from use casesCreate scenarios from use casesCreate class diagrams showing basic inter-class relationshipsCreate class diagrams showing basic inter-class relationshipsModel key class collaborationsModel key class collaborationsCreate use case diagramsCreate use case diagrams