The big idea - PowerPoint PPT Presentation

1 / 18
About This Presentation
Title:

The big idea

Description:

Title: PowerPoint Presentation Author: Anthony Kesterton Created Date: 10/2/2001 9:48:04 AM Document presentation format: On-screen Show Company: Rational Software BV – PowerPoint PPT presentation

Number of Views:129
Avg rating:3.0/5.0
Slides: 19
Provided by: AnthonyK4
Category:

less

Transcript and Presenter's Notes

Title: The big idea


1
The big idea
  • Idea to code
  • Be responsive to new requirements

'If an error occurred, log it. If
Err.Number ltgt 0 Then Dim Message As
String Message "Unexpected error"
vbComma " " CStr(Err.Number) " was
raised." Log.Message Message,
TSS_LOG_RESULT_FAIL, Err.Description End If
'Close the datapool If Not dp Is Nothing
And UseDP Then dp.Close Set dp
Nothing End If 'Shutdown test data
store and log services tms.EndTestServices
2
So what is the problem?
  • Who identifies problems in your organisation?
  • Look for the problem behind the problem
  • Problem analysis techniques

3
Five steps in problem analysis
  • Gain agreement
  • Understand the root causes
  • Identify stakeholders and users
  • Define the solution system boundary
  • Identify constraints

4
Business modeling A problem analysis technique
  • Understand the business processes automated by
    the system
  • System context
  • Who will use the system?
  • Activities to be automated
  • What should the system do?
  • Set of services the system should provide to the
    users
  • What should the system output to users?
  • Performance goals
  • How fast should the system be?
  • Understand where the system will fit in the
    deployment environment

5
An approach to root cause analysis
Fishbone Diagram
What the customer believes to be the problem
6
Define solution system boundary Actors
  • Actor
  • Someone/something outside the system that
    interacts with the system
  • Example
  • Customer
  • Administrator
  • Billing system
  • Radar

Actor
7
Moving to the solution space
Problem Space
Problem
Needs
Solution Space
Features
The Product To Be Built
Software Requirements
8
Requirements and requirements management
  • Requirement A condition or capability to which
    the system must conform
  • Requirements management A systematic approach
    to
  • Eliciting, organizing, and documenting the
    requirements
  • Establishing and maintaining agreement between
    customer/user and project team on the changing
    requirements

9
Kinds of requirements
Components of FURPS
F
unctionality

Feature Set
Generality
Capabilities
Security
U
sability

Human Factors
Consistency
Aesthetics
Documentation
R
eliability

Frequency/Severity
Predictability
of Failure
Accuracy
Recoverability
MTBF
P
erformance

Speed
Throughput
Efficiency
Response Time
Resource Usage
S
upportability

Testability
Configurability
Extensibility
Serviceability
Adaptability
Installability
Maintainability
Localizability
Compatibility
Robustness
Grady, 1992
10
How do requirements drive development?
Verified by
Realized by
Implemented by
11
Requirements management plan
Stakeholder Requests
Features
Supplementary Specifications
Use Cases
Actors
Test
12
UML model of functional requirements
The System
Use Case 1
Use Case 2
Use Case 3
13
Analysis
  • Formulate a model of the problem domain
  • Analysis focuses on what to do
  • design focuses on how to do it
  • Creating use case realizations and upper layers
    of the architecture

14
Data modeling in UML
  • Traditionally, developers and database analysts
    work in isolation
  • Database structure dictates applications, or
  • Application dictates database structure
  • UML extended to include database concepts
  • Some concepts already existed in UML (eg Table)

Object Model
Logical Data Model
Physical Data model
15
Use case realizations
  • A use-case realization describes how a particular
    use case is realized within the design model, in
    terms of collaborating objects.
  • Class diagrams
  • Interaction diagrams
  • Modeled as a UML collaboration
  • One per use case (minimum)
  • New design can result in new realization

16
Class diagrams
  • Used to model classes participating in a use case
    realization.
  • Used to document a domain model
  • Used to model logical architecture
  • Analysis stereotypes
  • Boundary
  • Control
  • Entity

17
Sequence diagrams
  • Model a scenario of a use case realisation

18
Managing change
All requests go through a single channel
Change requests come from many sources throughout
each iteration of the product lifecycle
Customer andEnd-User inputs
New Feature
Req
Marketing
Single Channel for Approval
New Requirement
Design
ApprovedDecisionProcess
Coders inputs Testers inputs
Code
Bug
Test
Help Desk End-User inputs
ChangeRequest (CR)
Maint
Write a Comment
User Comments (0)
About PowerShow.com