View
215
Download
0
Tags:
Embed Size (px)
Citation preview
James Nowotarski
3 October 2006
SE 325/425Principles and
Practices of Software Engineering
Autumn 2006
2
Topic Duration
Finish risk management 30 minutes
Requirements process 45 minutes
*** Break
Current event reports 30 minutes
Requirements process 60 minutes
Wrap-up 15 minutes
Today’s Agenda
3
“The basic problem of software development is risk”
Beck, K. (2000). Extreme Programming Explained. Boston, MA: Addison-Wesley
Risk management
4
Categories of software risk
Project Technical Business Legal
5
“It is futile to try to eliminate risk”
-- Peter Drucker, management guru
Risk management
6
Risk management process
Identify Analyze Plan
Cost of protection Cost of exposure
$$ $$
Control
7
Risk management process: artifacts
Identify Analyze Plan Control
• List of risks • Probability• Impact• Cutoff• Risk exposure
• Mitigation plan• Monitoring plan• Contingency plan
8
“Worrying about what might go wrong may not be as glamorous a job as speculating about the future, but it is a more essential job right now.”
Carr, N. (2003, May). IT doesn’t matter. Harvard Business Review. Retrieved September 8, 2006 from EBSCO Host – Business Source Premier database.
Does SE Matter?
9
Topic Duration
Finish risk management 30 minutes
Requirements process 45 minutes
*** Break
Current event reports 30 minutes
Requirements process 60 minutes
Wrap-up 15 minutes
Today’s Agenda
10
Quote
“The hardest single part of building software is deciding what to build” – Fred Brooks
11
Survey Results[plus Jordan] [plus all DL]
Key issues/trends: Outsourcing 11 Security 7 Web 2.0 6 Requirements 1/5 Dispersed teams 5 Speed of delivery 4 Project mgmt 3/1 Six sigma/Quality 4/1 Agile methods 4 Upgrades 3 IT working with business units 2 Commoditization of IT/SW 2 Others 1
12
Areas of most disruptive change
Software requirements Program design
- Winston W. Royce
13
Context
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
14
Context
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
elicitation Requirementsengineeringtasks (Ch. 7-8)
15
Context
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
elicitationRequirementsengineeringtasks (Ch. 7-8)
elaborationspecification
Chapter 7
Chapter 8
16
Context
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
elicitationRequirementsengineeringtasks (Ch. 7-8)
elaborationspecification
Primarydeliverables
functional reqtsnon-functional reqts
analysis modelsoftware reqts spec
17
What is a requirement?
A requirement can be defined simply as a property of a system, or a constraint upon the product or process by which the system is to be created
IEEE Std 610.12-1990 defines a requirement as
A condition or capability needed by a user to solve a problem or achieve an objective.
A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
18
Functional vs. Non-Functional
A functional requirement (FR) describes what the system needs to do.
Example: ‘The system shall display the current customer balance’.
19
Functional vs. Non-Functional
A non-functional requirement (NFR) describes a constraint upon the solution space.
Examples: Performance, flexibility, reliability, usability, portability, maintainability, safety, and security.Also called “quality” requirements, “ilities”, or even “systemic” requirements. Emergent Properties: An NFR that is realized through the careful implementation of other requirements on which it depends. Example: “The query must return its results in less than three seconds” is only realizable once the architecture and much of the system functionality has been implemented.
20
Quote
“It’s not enough to do good. It must be done well” – St. Vincent de Paul
21
Management involvement and governance
Senior management needs to be involved in critical business/IT decisions
Educating management is a technique to help users who “don’t know what they want”
High degree of involvement helps to improve the strategic business value of information technology
Example: What security and privacy risks will we accept?
Senior management needs to lead the decision making
22
The Requirements Process
Elicitation: Proactively working with stakeholders to discover their needs, identify potential conflicts, and establish a clear scope and boundaries for the project.
Elaboration (Analysis): Gaining a deeper understanding of the product and its interactions.
Specification: Production of a series of documents that capture the system and software requirements in order to support their systematic review, evaluation, and approval.
Validation: Inspecting requirements to ensure their correctness.
Management: Issues such as software configuration management, traceability, impact analysis, and version control.
23
Key Question: Deliverables
Steps Techniques
What does the system need to do?How well does it need to do it?
Functional requirementsQuality requirements
1. Review as-is system2. Identify requirements of
to-be system
Re-engineering AHPInterviewing PrototypingObservationSurveys/Focus GroupsJoint Application Design (JAD)Benchmarking
Elicitation
Roles Estimating guidelines
Business analyst
24
Elicitation Techniques
Collaborative sessions are useful for brainstorming and problem solving activities.
A Joint Application Design (JAD) can bring together a small group of stakeholders to form initial goals and requirements.
Helps to avoid ambiguity
Helps to reduce scope creep
25
Joint Application Design (JAD)
26
Elicitation Techniques
Interviewing techniques are simple yet effective.
Structured around a specific set of questions
Closed ended
Open ended
Can be conducted in stages, so that responses from the first round can be used to generate a deeper set of more focused questions for the second round.
Can be expensive
27
Elicitation Techniques
Observation involves observing the way users interact with an existing system.
Useful when users are unable to fully articulate their needs, or are too busy to attend other types of elicitation meetings. Observe how tasks are executed, problems, shortcuts, & areas for improvement. Sometimes referred to as “going to the gemba”Especially good for uncovering unstated requirements
“Exciting requirements” – Exceed user’s initial expectations
28
Elicitation Techniques
Prototyping – taking an early set of requirements and using them to elicit further requirements.
Low fidelity models useful because for very little cost you can obtain useful feedback from the user. Higher fidelity prototypes enable the user to interact with something closer to the finished product.
29
Elicitation Techniques
Analytic Hierarchy Process (AHP) – a mathematically-based prioritization technique
Represents the elements of any problem hierarchicallyGuides decision makers through a series of pairwise comparisonsResults in quantitative assessment of relative strength of requirements Developed by Dr. Thomas Saaty of the University of Pittsburgh
30
Elicitation Techniques: AHP
Develop QualitySoftware Goal
ArchitectureChoice 1
ArchitectureChoice 2 Alternatives
Performance Usability FlexibilityQualityreqts
31
Elicitation Techniques: AHP
Develop Software
Performance Usability Flexibility
ArchitectureChoice 1
ArchitectureChoice 2
Goal
Alternatives
Qualityreqts
.08 .64 .28
.41.59
32
Activity: AHP
33
Context ModelsDetermine the boundaries of the system.
What is the system?What is the system’s environment?
Develop a context model that shows the context of the system within its environment.
Auto-TellerSystem
SecuritySystem
MaintenanceSystem
Branchaccounting
System
BranchcounterSystem
AccountDatabase
UsageDatabase
34
Context Models
Understand the types of interaction the software system has with its adjacent systems.
Some adjacent systems cooperate with your system through two-way communication. Consider them black-box components of your system.
Some adjacent systems initiate events and interact with your system (i.e., people).
Some adjacent systems have one way communication but otherwise work autonomously.
Trigger events that must be specified.
Incoming communication may trigger an event to be specified. Also don’t forget TIMED events
35
Model these interactions as Use Cases
Identify actors
Model their interactions with the system.
Through elicitation fully explore all the ways each actor may interact with the system.
Banking Software Product
Withdraw Money
Customer Teller
36
Requirement Qualities
Each individual requirement should be:
Concise
Correct
Non-ambiguous
Feasible
Verifiable
Traceable
Manageable
37
Concise
A requirement should describe a single property of the desired system and should include no information beyond that necessary to describe the intended property.
It should be stated in clear, simple, and understandable terms.
Note the need to define terms such as “Emergency calls” and “Public” in the requirements definition document.
Emergency calls from the public shall be answered in the order in which they are received.
38
Correct
A requirement should accurately describe the intended property of the intended system.
No information missing that is needed to define or implement the system.
The following requirement is obviously (or at least probably should be) incorrect:
When an ambulance crew is dispatched to pick-up a patient more than 2 miles away, they shall wait three minutes before departing in order to give the dispatch operator the chance to locate a closer crew.
39
Non-ambiguous A requirement should be stated clearly and
understandably, in order to avoid ambiguous interpretations.
The following requirement is OBVIOUSLY ambiguous. Why?
How could you fix it?
When a call is received the dispatcher assigns the job to the best crew.
Shoes mustbe worn!
Dogs mustbe carried!
40
What is wrong with this requirement?
“The same display shall also be able to generate a visible or audible caution/warning sign for the attention of the ambulance driver or medic.”
41
Conjunctions are dangerous…
Disambiguate what the ‘and’ means…
The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and the current workspace or input data shall be saved.
We can separate the requirement into multiple parts…
The battery low warning lamp shall light up when the voltage drops below 3.6 Volts.
When the battery low warning lamp lights up the current workspace shall be saved.
The battery low warning lamp shall remain lit until the voltage rises above 3.7 Volts.
?? Go back to the stakeholder
42
Conjunctions are dangerous…
Problems arise when readers try to puzzle out which part applies.
The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and the current workspace shall be saved.
Or disambiguate…
The battery low warning lamp shall light up when the voltage drops below 3.6 Volts, and then the current workspace shall be saved.
43
Conjunctions are dangerous…
What about this requirement?
An aircraft that is non-friendly and has an unknown mission or the potential to enter restricted airspace within 5 minutes shall raise an alert.
Again – disambiguate and/or precedence. Two options:
An aircraft that is non-friendly and (has an unknown mission or the potential to enter restricted airspace within 5 minutes) shall raise an alert.
If [an aircraft is non-friendly] and [has an unknown mission or the potential to enter restricted airspace within 5 minutes], the system shall <raise> <an alert>.
44
Feasible
A requirement should be feasible from a technical, financial, and managerial perspective.
The following requirement is INFEASIBLE except possibly in a James Bond movie!
This is just overly optimistic wishful thinking because we didn’t specify anything about traffic congestion, location of the patient, distance to the hospital etc.
All patients shall be delivered to a hospital within 5 minutes of their pick-up.
45
Verifiable
A requirement should be written in such a way as to provide a clear and testable acceptance criterion.
For example, it is not sufficient to specify that:
Instead, the requirement should be written in a verifiable form such as:
The dispatcher must be able to quickly identify the closest open emergency room.
The dispatcher must be able to identify the closest open emergency room within 1 second.
46
Traceable
A requirement is traceable if it has been assigned a unique ID and if it is focused on one property.
For example a requirement stating that:
creates traceability problems because it involves tracking the implementation of crew allocations and ambulance allocations.
A driver and medic shall be assigned to an ambulance crew and the crew shall be assigned to an ambulance.
Never build in let-out or escape clauses(if, when, but, except, unless, although)
The forward passenger doors shall open automatically when the aircraft has halted, except when the rear ramp is deployed.
The fire alarm shall always be sounded when smoke is detected, unless the alarm is being tested or the engineer has suppressed the alarm.
Don’t ramble
Provided that the designated input signals from the specified devices are received in the correct order where the system is able to differentiate the designators, the output signal shall comply with the required framework of section 3.1.5 to indicate the desired input state.
Refrain from designing the system
The antenna shall be capable of receiving FM signals, using a copper core with nylon covering and a waterproof hardened rubber shield.
Avoid mixing different kinds of requirements Do not speculate
Users normally require early indication of intrusion into the system.
Do not play on ambiguous requirementsAlways make requirements as clear as possible
Do not use vague undefinable termsThe print dialog shall be versatile and user-friendly
Do not express possibilitiesThe reception subsystem probably ought to be powerful enough to receive a signal inside a steel-framed building.
Avoid wishful thinkingThe gearbox shall be 100% safe in normal operationThe network shall handle all unexpected errors without crashing.
49
Manageable
Attributes should be used to support requirements management.
For example:
Date created
Date last edited
Priority (High, Mid, Low etc)
Status (Completed, Undergoing Change, Scheduled, Unassigned).
50
Qualities of a Good Set of Requirements
Realistic: The requirements should represent realistic goals at both the product and project level.
Concise: The requirements as a whole should concisely describe the system that is to be developed. Long-winded requirements create greater opportunity for ambiguity and errors.
Complete: The requirements should collectively describe the entire system to be implemented with no information missing.
Consistent: Inconsistencies between requirements lead to conflicts that prohibit all of the requirements being implemented successfully. Inconsistencies should be identified and conflicts negotiated.
Begin with the end in mind - Sample SRSOverviewRevision HistoryTable of Contents1.0 Introduction
1.1 Purpose1.2 Scope1.3 References1.4 Assumptions and Dependencies
2.0 Use-Cases3.0 Requirements
3.1 Functional Requirements3.2 Non-Functional Requirements
3.2.1 Usability3.2.2 Reliability3.2.3 Performance3.2.4 Supportability
4.0 Online User Documentation and Help System
Requirements5.0 Design Constraints6.0 Purchased Components7.0 Interfaces
7.1 User Interfaces7.2 Hardware
Interfaces7.3 Software Interfaces7.4 Communication
Interfaces8.0 Licensing Requirements9.0 Legal, Copyright, and Other
notices10.0 Applicable StandardsIndexGlossary
52
Topic Duration
Finish risk management 30 minutes
Requirements process 45 minutes
*** Break
Current event reports 30 minutes
Requirements process 60 minutes
Wrap-up 15 minutes
Today’s Agenda
53
Read Pressman Chapters 13-14 (Testing) Current Event Reports:
FitzgeraldMaroseMikaelNan
For October 10
54
Extra slides
55
Testing
Requirements
Functional Design
TechnicalDesign
DetailedDesign
Code
Unit Test
IntegrationTest
SystemTest
AcceptanceTest
Flow of Work
Verification
Validation
Testing: Test that the product implements the specification
Legend:
56
Change Control Process
Create InitialSections
Create/ModifyDraft
Review Draft(V&V)
Create Changes to Incorporate
Changes Needed In Document
DocumentApproved
Create Review Revise ReviewReview Approved
Time
...
Document in Production and Under Formal Change Control
Document in Production and Under Formal Change Control
Document Under Development and User Change Control
Document Under Development and User Change Control
57
Waterfall model
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Source: Royce, W. "Managing the Development of Large Software Systems."
58
RUP Artifacts by Phase and Discipline
Discipline Inception Elaboration Construction TransitionBusiness Modeling
RequirementsVisionUse Cases (20-80%)ActorsSoftware Req SpecGlossary
Analysis & Design Software Arch Doc
Implementation
Build PlanBuildTest Results
Test
Test PlanTest ScriptTest DataTest Results
Test Strategy
DeploymentDeployment Plan Training Materials
Support MaterialsAcceptance Test ResultsChange Requests
Product
Executable ArchitectureUser Interface PrototypeUser Interface DesignUse Case RealizationDesign ModelDatabase Design
Business Architecture
59
RUP Artifacts by Phase and Discipline
Discipline Inception Elaboration Construction Transition
Configuration and Change Management
Project Management Risk ListRisk Mgmt PlanBusiness CaseQA PlanSoftware Dev Plan
Environment
Dev Case (Process)ToolsGuidelinesTemplatesSupport
CM PlanCM EnvironmentChange Requests
60
Risk vs. Technology Maturity
Impact of Technology Maturity
Risk Early Adopter Mid Adopter Late Adopter
hands-on implementation experience little exper / high riskmore exper / mid risk
much exper / low risk
vendor survival for project after shake-out high risk mid risk low risk
sudden changes in direction of technology high risk mid risk low riskintegrating technology with existing portfolio
high risk mid risk low risk
Benefits
Period for Start of Payoff Short term Mid term Long term
Size of Returns per period Biggest Bigger Big
Risk vs. Return
Flow of Extension ActivitiesFlow of Extension Activities
Describe Use Case
Perform Use Case Analysis
Model User Experience
Identify Design Elements
Implement Elements
Design Classes
Design Subsystems & Components
62
Technology
ProcessPeople
The focus of SE 425 is the process component of software engineering
Core Concepts
Technology
ProcessPeople
… for the delivery of technology-enabled business solutions