Lecture 3 Software Process Models / Requirements Analysis Topics Mythical Man Month Waterfall model...
-
date post
20-Dec-2015 -
Category
Documents
-
view
228 -
download
1
Transcript of Lecture 3 Software Process Models / Requirements Analysis Topics Mythical Man Month Waterfall model...
Lecture 3 Software Process Models /
Requirements Analysis
Lecture 3 Software Process Models /
Requirements Analysis
Topics Topics Mythical Man Month Waterfall model Spiral Method Requirements Analysis
Readings: Chapter 3Readings: Chapter 3January 15, 2009
CSCE 492 Software Engineering
– 2 – CSCE 492 Spring 2009
OverviewOverviewLast TimeLast Time
Overview Quality Software
Today’s Lecture Today’s Lecture Pragmatics
UML references, Teams
Models for the process of software developmentWaterfall 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 Spring 2009
UML – Unified Modeling LanguageUML – Unified Modeling Language
UML 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 Spring 2009
TeamsTeams
Team 1: BENDER SAMUEL, BENNETT RONALD, Team 1: BENDER SAMUEL, BENNETT RONALD, BUSH BRANDON, SCHANDLER J M, CHILDERS BUSH BRANDON, SCHANDLER J M, CHILDERS WESLEYWESLEY
Team 2: CROCKETT MATTHEW, DINKINS CHANCE, Team 2: CROCKETT MATTHEW, DINKINS CHANCE, ELLIOTT MICHAEL, GALLOWAY SCOTT, HITE EELLIOTT MICHAEL, GALLOWAY SCOTT, HITE E
Team 3: MICHALSKI JASEN, RABON TONI ANN, Team 3: MICHALSKI JASEN, RABON TONI ANN, SHANNON MARION, SIMMONS KATIA, STIFFLER NSHANNON MARION, SIMMONS KATIA, STIFFLER N
Team 4: STOICHITA RAZVAN, TAYLOR KAREEM, Team 4: STOICHITA RAZVAN, TAYLOR KAREEM, THAPA BIJAYA, VAN O'LINDA MTHAPA BIJAYA, VAN O'LINDA M
– 5 – CSCE 492 Spring 2009
Working in TeamsWorking 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 Spring 2009
Holding Effective Team MeetingsHolding 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 Spring 2009
Class Project DeliverablesClass 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 Spring 2009
General Project ParametersGeneral Project Parameters
Type 1 Projects: Web-enabled System Type 1 Projects: Web-enabled System Web interface Database backend Publically accessible Security/permissions issues Examples: appointment calendar, scheduling system
Type 2 Projects: Stand-alone SystemsType 2 Projects: Stand-alone Systems More elaborate graphics May require a database Examples: games, mobile data collection tool
Suggestions from the floor?Suggestions from the floor?
– 9 – CSCE 492 Spring 2009
Should we fix this bug or not?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
– 10 – CSCE 492 Spring 2009
Severity and FrequencySeverity 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."
http://software.ericsink.com/articles/Four_Questions.html
– 11 – CSCE 492 Spring 2009
Mythical Man-MonthMythical Man-Month
Main 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
– 12 – CSCE 492 Spring 2009
Waterfall Model of Software Life Cycle
Waterfall Model of Software Life Cycle
Not 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 Spring 2009
Water Fall ModelWater 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 Spring 2009
The Spiral ModelThe Spiral Model
Note iterative Note iterative repetition of repetition of the cycle!the cycle!
– 15 – CSCE 492 Spring 2009
Requirements AnalysisRequirements Analysis
Software 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
– 16 – CSCE 492 Spring 2009
Requirements AnalysisRequirements 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
– 17 – CSCE 492 Spring 2009
The Importance of Requirements AnalysisThe 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
– 18 – CSCE 492 Spring 2009
Examples of Good Requirements AnalysisExamples 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
– 19 – CSCE 492 Spring 2009
Requirements SpecificationRequirements Specification
Requirements 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
– 20 – CSCE 492 Spring 2009
Possible Elements of Requirements SpecificationPossible 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
– 21 – CSCE 492 Spring 2009
More: Possible Elements of Requirements SpecificationMore: 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
– 22 – CSCE 492 Spring 2009
Case Study: Library Management SystemCase 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
– 23 – CSCE 492 Spring 2009
LMS Case Study: Clarifying the Requirements SpecificationLMS 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?
– 24 – CSCE 492 Spring 2009
LMS Case Study: More Clarifying the Requirements SpecificationLMS 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?
– 25 – CSCE 492 Spring 2009
Creating Quality Requirements SpecificationsCreating 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
– 26 – CSCE 492 Spring 2009
LMS Case Study: Supported Activity ListLMS 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
– 27 – CSCE 492 Spring 2009
LMS Case Study: More Supported Activity ListLMS 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
– 28 – CSCE 492 Spring 2009
Other Elements of the LMS Requirements SpecificationOther 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
– 29 – CSCE 492 Spring 2009
More Elements of the LMS Requirements SpecificationMore Elements of the LMS Requirements Specification
Projected 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?
– 30 – CSCE 492 Spring 2009
Verifying RequirementsVerifying 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
– 31 – CSCE 492 Spring 2009
The Process of Requirements AnalysisThe 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
– 32 – CSCE 492 Spring 2009
Identifying Use CasesIdentifying 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
– 33 – CSCE 492 Spring 2009
Characteristics of Use CasesCharacteristics 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
– 34 – CSCE 492 Spring 2009
Use Case LayoutUse 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
– 35 – CSCE 492 Spring 2009
LMS Case Study: Use CasesLMS 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
– 36 – CSCE 492 Spring 2009
LMS Case Study: Check out Resource Use CaseLMS 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
– 37 – CSCE 492 Spring 2009
More LMS Case Study: Check out Resource Use CaseMore 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
– 38 – CSCE 492 Spring 2009
Scenario DevelopmentScenario Development
Scenarios are derived from use casesScenarios are derived from use cases
Scenarios are like informal scenarios, but are more formally Scenarios are like informal scenarios, but are more formally structuredstructured
Informal scenarios may be modified to produce scenariosInformal scenarios may be modified to produce scenarios
Use cases are abstract because they do Use cases are abstract because they do notnot reference specific reference specific valuesvalues
Scenarios are concrete because they Scenarios are concrete because they do do referencereference specific valuesspecific values
Multiple scenarios may be required for a single use caseMultiple scenarios may be required for a single use case
– 39 – CSCE 492 Spring 2009
UML Use Case DiagramsUML 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
– 40 – CSCE 492 Spring 2009
Notational Elements of Use Case DiagramsNotational Elements of Use Case Diagrams
Use casename
Actor Use case
Relationships:Dependency Association Generalization
– 41 – CSCE 492 Spring 2009
LMS Case Study: Use Case DiagramLMS Case Study: Use Case Diagram
BrowseResource
RequestResource
ReserveResourcePatron Resource
– 42 – CSCE 492 Spring 2009
Steps in UCCD Analysis ProcessSteps in UCCD Analysis Process
Create/refine requirements specificationCreate/refine requirements specification
Create informal scenariosCreate informal scenarios
Create list of primary classesCreate list of primary classes
Create use casesCreate use cases
Create scenarios from use casesCreate scenarios from use cases
Create class diagrams showing basic inter-class relationshipsCreate class diagrams showing basic inter-class relationships
Model key class collaborationsModel key class collaborations
Create use case diagramsCreate use case diagrams