Lecture 2 Software Process Models / Requirements Analysis
description
Transcript of 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
– 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:
– 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
– 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 ?
– 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
– 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
– 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
– 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
– 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
– 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
– 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)
– 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
– 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
– 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
– 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)
– 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
– 17 – CSCE 492 Summer 2006
Current trends in software engineering AspectsAspects AgileAgile Software architecturesSoftware architectures Software Product linesSoftware Product lines
– 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
– 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
– 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
– 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
– 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
– 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
– 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
– 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
– 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?
– 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 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
– 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
– 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
– 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
– 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?
– 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
– 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
– 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
– 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
– 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
– 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
– 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
– 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
– 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
– 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
– 43 – CSCE 492 Summer 2006
Notational Elements of Use Case Diagrams
Use casename
Actor Use case
Relationships:Dependency Association Generalization
– 44 – CSCE 492 Summer 2006
LMS Case Study: Use Case Diagram
BrowseResource
RequestResource
ReserveResourcePatron Resource
– 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