27252883 software engineering notes
TRANSCRIPT
Software Engineering
An initial calibration of perspective:How many lines of code are produced, on
average, by one software engineer in a year?How long would it take you to do the attached
July 03 Chapter 11
How long would it take you to do the attached web generation problem?How long would it take you to do the attached
web generation problem?
Software Engineering — Introduction
What is Software Engineering (SE)?The process of building a software product.
Some questions to put SE in perspective:What are the sizes of some typical software products?
July 03 Chapter 12
What are the sizes of some typical software products?Maple.exe = 1.3 Mbytes.-- System over 3.8 MbytesNetscape.exe = 1.26 megabytes.Microsoft Office 97 > 180 megabytes.
How many people would it take to build these in 1 year? 2?What would you do if a bug could cost lives and $2 billion?What would you do if a delay could cost $100’s of millions?
Software Engineering — Introduction Some questions to put SE in perspective (con’t):What is the impact of distributing buggy software?Why do we have so many software upgrades?What is the impact of software upgrades?What are some of the ethical issues in software
development?
July 03 Chapter 13
Why is it so difficult to measure software development progress?
development?
Why does it take so long to develop software?Why does software cost so much?
Why do people continue to use buggy and/or obsolete software?
Some Software Characteristics
Software is engineered or developed, not manufactured in the traditional sense.
Software does not wear out in the same sense as hardware.
July 03 Chapter 14
Some Software Characteristics
In theory, software does not wear out at all.
July 03 Chapter 15
BUT,Hardware upgrades.Software upgrades.
Some Software Characteristics
Thus, reality is more like this.
July 03 Chapter 16
Most serious corporations control and constrain changes
Most software is custom built, and customer never really knows what she/he wants.
Some General Approaches
Develop and use good engineering practices for building software.
Make heavy use of reusable software components.
Use modern languages that support good software
July 03 Chapter 17
Use modern languages that support good software development practices, e.g., Ada95, Java.
Use 4th generation languages.
But, almost everything is a two-edged sword.
Consider long term tool maintenance.Right now, this is a major problem for NASA.
Types of Software Applications
Systems Software Real Time Software Business Software Engineering & Scientific Software
July 03 Chapter 18
Engineering & Scientific Software Embedded Software Personal Computer SoftwareWeb Based Software Artificial Intelligence Software
Software Myths
Myth: It’s in the software. So, we can easily change it.Reality: Requirements changes are a major cause of
software degradation.Myth: We can solve schedule problems by adding more
July 03 Chapter 19
Myth: We can solve schedule problems by adding more programmers.Reality: Maybe. It increases coordination efforts and may
slow things down.Myth: While we don’t have all requirements in writing yet, we
know what we want and can start writing code.Reality: Incomplete up-front definition is the major cause
of software project failures.
Software Myths
Myth: Writing code is the major part of creating a software product.Reality: Coding may be as little as 10% of the effort, and
50 - 70% may occur after delivery.
July 03 Chapter 110
Percent Maintenance Historgram
20%
25%
30%
35%
July 03 Chapter 111
0%
5%
10%
15%
(0,15] (15,30] (30,45] (45,60] (60,75]
Myth: The only deliverable that matters is working code.
Software Myths
Myth: I can’t tell you how well we are doing until I get parts of it running.Reality: Formal reviews of various types both can give
good information and are critical to success in large projects.
July 03 Chapter 112
Myth: The only deliverable that matters is working code.projects.Reality: Documentation, test history, and program
configuration are critical parts of the delivery.Myth: I am a (super) programmer. Let me program it, and I
will get it done.Reality: A sign of immaturity. A formula for failure.
Software projects are done by teams, not individuals, and success requires much more than just coding.
25%
31%
20%
25%
30%
35%
July 03 Chapter 113
13%
8%
6%
0%
5%
10%
15%
<=2 (2.4] (4,6] (6,8] (8,10]
Estimate in weeks
SLOCs per Year Histogram
25%
30%
35%
40%
July 03 Chapter 114
0%
5%
10%
15%
20%
(0,5k] (5k,10k] (10k,20k] (20k,50k] >50k
Software as a Process
Software Engineering -- a definition:[Software engineering is] the establishment and use
of sound engineering principles in order to obtain economically software that is reliable and works
Chapter 2August 2003 1
economically software that is reliable and works efficiently on real machines.
Software Engineering is a layered technology.
A Layered Technology
ToolsEditors
Design aids
Compilers
Chapter 2August 2003 2
Compilers
Computer Aided Software Engineering (CASE)MethodsIncludes standards (formal or informal)
May include conventions, e.g., low level such as naming, variable use, language construct use, etc.
May involve design methodologies.
Some Generic Engineering Phases
DefinitionSystem or information engineering (leading to
requirements)Software project planning
Chapter 2August 2003 3
Software project planningRequirements analysis
DevelopmentSoftware designCodingTesting
Some Generic Engineering Phases
MaintenanceCorrection -- bugs will appear Adaptation -- to changing operating systems,
CPU’s, etc.
Chapter 2August 2003 4
CPU’s, etc.Enhancement -- changing customer needsPrevention -- software reengineering
Some Generic Engineering Phases
Typical activities in these phasesProject tracking and control Formal reviewsSoftware quality assurance
Chapter 2August 2003 5
Software quality assuranceConfiguration management Documentation Reusability managementMeasurementRisk management
SEI Software Maturity Model
Level 1: Initial -- The software process is characterized as ad hoc, and occasionally even chaotic. Few processes defined.
Level 2: Repeatable -- Basic project management processes established to track cost, schedule and functionality.
Level 3: Defined -- Process for both management and
Chapter 2August 2003 6
established to track cost, schedule and functionality. Level 3: Defined -- Process for both management and
engineering is documented, standardized and integrated. Level 4: Managed -- Detailed measures of the process and
product quality collected. Both are quantitatively understood and controlled.
Level 5: Optimizing -- Continuous process improvement enabled by quantitative feedback and testing innovative ideas.
Key Process Areas
Maturity Level 2Software Configuration ManagementSoftware Quality AssuranceSubcontract management
Chapter 2August 2003 7
Subcontract managementProject tracking and oversightSoftware project planningRequirements management
Key Process Areas
Maturity Level 3Peer ReviewsIntergroup coordinationIntegrated software management
Chapter 2August 2003 8
Integrated software managementTraining programOrganization process definitionOrganization process focus
Key Process Areas
Maturity Level 4Software quality managementQuantitative process management
Chapter 2August 2003 9
Maturity Level 5Process change managementTechnology change managementDefect prevention
Software Process Models
Chapter 2August 2003 10
Waterfall Model
Requirements Analysis Design Code
System/Information Engineering
Chapter 2August 2003 11
Test
Maintain
The Prototyping Model
Chapter 2August 2003 12
The RAD Model
Business Modeling
Data Modeling
Business Modeling
Data Modeling
Process Modeling
Application
Chapter 2August 2003 13
Modeling
Process Modeling
Application Generation
Testing & Turnover
Application Generation
Testing & Turnover
60 – 90 days
RAD Model
Business ModelingWhat info. Drives the business process?What info. Is generated?Who generates it?
Chapter 2August 2003 14
Who generates it?Where does the info go?Who processes it? Etc..
Data ModelingRefinement from business model into data objectsCharacteristics of object identified and relationships
between objects are defined.
RAD Model
Process ModelingData objects are transformed to achieve the info. flowProcess desc. added for adding, modifying, deleting or
retrieving a data object
Chapter 2August 2003 15
Application GenerationUse of 4GL techniquesAutomated tools use for construction of S/W
Testing & TurnoverTesting time is less bcoz of reusable componentsOnly new components tested and interfaces
Limitations of RAD
More human resources required to created right teams
Time crucial-if commitment lack-RAD fails
Modular systems implementable – not appropriate for high performance systems which require rigorous tuning of
Chapter 2August 2003 16
performance systems which require rigorous tuning of interfaces
Not appropriate where technical risks are high – i.e. applications making heavy use of new tech. or new S/W require high degree of interoperability with existing systems
Evolutionary process Models
Iterative in nature
Waterfall model – straight line development
Prototyping – not designed to deliver a production system
Evolutionary nature of S/W not considered in classic models
Chapter 2August 2003 17
Evolutionary nature of S/W not considered in classic models
Evolutionary Process Models
The Incremental Model
Chapter 2August 2003 18
Evolutionary Process Models
The Spiral ModelProposed by Boehm
Couples iterative prototyping with controlled and systematic Linear Sequential
Chapter 2August 2003 19
systematic Linear Sequential
S/w developed in series of incremental releases
Divided in no. of framework activities – task regions
Typically between 3 to 6 task regions
Each task region consist of work task called – task set
Evolutionary Process Models
The Spiral Model
Concept Development Projects
New Product Development
Chapter 2August 2003 20
New Product Development Projects
Product Enhancement Projects
Product Maintenance Projects
Project Entry Point Axis
The Spiral Model – Task Regions
Customer CommunicationTasks reqd. to establish effective comm. between developer and customer
PlanningTasks required to define resources, timelines & other project related info.
Chapter 2August 2003 21
Risk AnalysisTasks required to assess both technical and mgt. Risks
EngineeringTasks required to build one or more representations of the application
Construction & ReleaseTasks required to construct, test, install, and provide user support (e.g.
documentation and training)
The WinWin Spiral Model
Chapter 2August 2003 22
The WinWin Spiral Model
Chapter 2August 2003 23
The Concurrent Development Model
Chapter 2August 2003 24
The Concurrent Development Model
CDM is driven by user needs, mgt. decision and review results
All activities exist concurrently, but reside in different states
A state is some externally observable mode of behavior
CDM is used for developing Client/Server applications
2 dimensions – System and Component dimension
Chapter 2August 2003 25
2 dimensions – System and Component dimension
System – design, assembly and use
Component – design and realisation
Concurrency is achieved by carrying out both system and component activities at same time
Network of activities – events generated within one activity in a network of activities, trigger transitions among the states of an activity
The Component Assembly Model
Chapter 2August 2003 26
The Component Assembly Model
Chapter 2August 2003 27
Other Models
Formal MethodsRigorous mathematical representation of
requirementsProvides basis for automatic verification test
generation
Chapter 2August 2003 28
generationFourth Generation TechniquesUse code generators to produce specific parts of
productProcess TechnologyProvides a variety of tools to aid software
developers, e.g., workload flow, configuration management, quality assurance management, etc.
Project Management Concepts
Why is project management important?CostDod already spending $30 billion annually on software
in late 80’s
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 1
in late 80’sThe US spent $150 billion$225 billion worldwide
Projects frequently fail or have severe difficulties“New” FAA air traffic control system
They don’t meet specifications
They take much longer than expected
Why Do Major EngineeringUndertakings Often Fail?
Large projects often fail for two principal reasons:
Communication: Inadequate communication
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 2
Communication: Inadequate communication leads to project failureCoordination: Lack of communication implies
that the team can not coordinate. Thus each group moves in an independent direction and the project will grind to a halt.
The Spectrum of Management Concerns
Effective Software management encompasses three main areas:People
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 3
PeopleThe productThe processThe project
People
The Players -- It is important to recognize the different categories of people involved in a large software project.Senior Managers - who define business issues.
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 4
Senior Managers - who define business issues.Project Managers - who plan, motivate, organize
and control the practitionersPractitioners - who deliver the technical skill
that are necessary to engineer the projectCustomers - who specify the requirementsEnd users - who interact with the software once
it is released.
Team Leadership -- A Critical Item
The ProblemThe best programmers often make poor team
leaders.Different skills are required.
Technical leadership model
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 5
Technical leadership modelMotivation - The ability to encourage technical
people to produce to their best ability.Organization - The ability to mold existing
processes that will enable the initial concept to be translated into reality.Ideas and Innovation - The ability to invite
creativeness even within a set of restrictions.
Team Organizational Models
Marilyn Mantei model:Democratic decentralized (DD). -- Does not have a
defined leader. “Task Coordinators” are appointed to assure that a particular job is to be executed. These are later replaced by other “Task Coordinators” as new tasks arise.
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 6
later replaced by other “Task Coordinators” as new tasks arise.Controlled decentralized (CD) -- Has a defined
leader who coordinates tasks, and secondary leaders who carry out subtasks. Problem solving is done by the group, implementation is done by subgroups.Controlled Centralized (CC) - Top-level problem
solving and team coordination managed by the team leader. The communication between the leader and members is vertical.
Project Features Impacting Organization
Difficulty of problem to be solved.
Expected size of the resultant program.
The time the team will remain together.
The degree to which the problem can be
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 7
The degree to which the problem can be modularized.
The required quality and reliability of the system.
The rigidity of the delivery date.
The degree of communication required for the project.
Impact of Project Characteristics
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 8
Other Underlying Organizational Factors
Matrix modelThe organization has divisions organized by
skills, e.g., engineering, safety and mission assurance (SMA), human factors, etc.Projects “rent” people from the divisions, as
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 9
Projects “rent” people from the divisions, as needed.
IssuesWho evaluates person for raises?Independence of reporting for safety & quality
issues?Who is boss?
How Do We Communicate?
Informally - Good phone/electronic service, a clear definition of group interdependencies and good relationships help encourage communication
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 10
communicationMeetings - Regular project meetings help
alleviate minor misunderstandings Workbook - a formal project workbook must
be started from the beginning.
Project Coordination techniques
Formal, impersonal approaches - software engineering documents and deliverables, technical memos, project milestones, schedules and control tools
Formal interpersonal procedures - quality assurance
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 11
Formal interpersonal procedures - quality assurance activities - reviews and design and code inspections
Informal, interpersonal procedures - group meetingsElectronic communication - Email, bulletin boards,
web sites, extension and video conferencesInterpersonal network - discussions with those
outside of the project.
A Study on the Impact ofCoordination Techniques
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 12
The Product
Must first determine project scope.Context - How does this software to be built fit
into the larger system? What constraints are imposed as a result of this?Information objectives - What customer-visible
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 13
Information objectives - What customer-visible objects are produced from the software? What data objects are necessary for input?Function and performance - What functions or
actions does the software perform to transform the output?
The stability, or lack thereof, of the project requirements is a major factor in project management.
The Process
Select a software engineering model.Project framework.Customer communication.Planning -- determine resources, time line & other info.
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 14
Planning -- determine resources, time line & other info.
Risk analysis -- assess technical and management risksEngineering -- build one or more representations
of the product.Construction and release -- construct, test, install
and provide user support.Customer evaluation -- obtain feedback on
product
Common Process Framework Activities
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 15
Process Decomposition
Typical activitiesReview the customer request.Plan and schedule a formal, facilitated meeting with the
customer.Conduct research to define proposed solutions.
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 16
Conduct research to define proposed solutions.Prepare a “working document” and meeting agenda.Conduct meeting with customer.Jointly develop mini-specs for the product.Review each mini-spec for correctness, lack of
ambiguity.Assemble the mini-specs into a scoping document.Review the scoping document with all concerned.Modify the scoping document as required.
Summary
Software project management is an umbrella activity that continues throughout the life cycle of the system.
Software management includes people, the problem, and the process.
The most critical element in all software system
Chapter 3 – R. S. Pressman SRIMCAJanuary 2004 17
The most critical element in all software system projects is the people. The team can have an number of structures that effect the way work is accomplished.
However, complete, consistent problem definition and an effective process are also essential ingredients.
CHECKOUT & LAUNCHCONTROL SYSTEM
Delivery Process Presentation to the
Aerospace Safety Advisory Panel
1
Aerospace Safety Advisory Panel
March 19, 1998
SYSTEM ENGINEERING AND INTEGRATION IN CLCS
System EngineeringAnd
Integration
System Strategic System Specialty
2
SystemDesign
StrategicEngineering
System Integrationand Test
• System Level Requirements• Hardware Architecture• Software Architecture• Performance Analysis
• Delivery Planning• Thread Definition
• System Level Integration• System Level Testing• Delivery Management• System Analysis
Specialty Engineering
• Quality Assurance• Human Factors• Quality Engineering
CLCS PROJECT LEVEL REVIEWS
• Architectural Baseline Review - Review Provided at the Discretion of the Project Manager to Capture a “Snapshot” of the System Architecture
• Design Panel - Reviews Held Throughout the Development Cycle the Incrementally meet the traditional “MIL-STD-2167” Preliminary and Critical Design Reviews
3
Preliminary and Critical Design Reviews
• Hardware Status Reviews - Reviews Provided at Those Times in the Project Development Cycle Which Coincide With Significant Hardware and Software Procurement Activities
SYSTEM ENGINEERING AND INTEGRATIONTERMINOLOGY
System Thread
A collection of Hardware and Software when combined and integrated as part of a CLCS delivery provides a system wide capability
Threads imply : • Quality Oversight in the development process
• User Acceptance Testing where applicable
Gateways Real Time Critical
4
Thread Statement of Work
–A conceptual description of a capability that considers the implementation of the System Level and Product Level Requirements
Display and Control Network
CommandControlProcessor
Data DistributionProcessor
Archive AndRetrieval
HumanComputerInterface
Critical Network
JUNO 3/97 REDSTONE 9/97 THOR 3/98 ATLAS 9/98 TITAN 3/99Demos Ice Team Support HMF Demo Fuel Cell Support Haz Gas HMF Operational
LCC X Demo GSE Demo SLWT Test IVHM Sail CertificationSLWT Demo Stress Test 1 Stress Test 2 Stress Test 3
System Capability Demo 1 System Capability Demo 2 Performance ValidationOps Consolidated SDS Consolidated SDS Turnover RPS LISI/CWLIS
Improvments CLCS Consolidated SDS IVHM Haz Gas(req) SSMEApplication SLWT Monitor SLWT IPT
Sets HMF Pathfinder HMF IPT HMF IPT HMF IPTOrbitor Power IPT Orbitor Power IPT Orbitor Power IPT
GSE Phase 1 IPT GSE Phase 1 IPTGSE Phase 2 IPTOPF FinalCITEIntg Ops
Launch Control Launch Control
Project Open System Pathfinder Open System DemoSupport Performance Modeling Performance Modeling Performance Modeling
Regression Testing Pathfinder System Testing System Testing Gateways End to End Gateway 1 End to End Gateway 2
GSE Link Support Ph 1 GSE Link Support Ph 2 Gateway Ph 1(req)PCM Support Ph 1 PCM Support Ph 2 PCM SSMELDB Interface Ph 1 LDB Interface Ph 2 LDB Interface Ph 3
Uplink Support Ph1T iming System Safing System Safing System
Data HandlingReliable Message Ph 1
Reliable Message Ph 2 Reliable Message Ph 3 Data Handling & Routing (req) DDP Ph 1Data Distribution Data Distribution
CLCS DELIVERY THREAD MATRIX
5
Reliable Message Ph 1 Data Distribution Data DistributionData Fusion Data FusionData Health Data Health
Display User Display MonitoringSystem Viewers
HCI Ph 1 HCI Ph 2(req)Plotting Pathfinder
Command User Commanding Ph 1 User Commanding Ph 2 User Commanding Ph 3(req) User Commanding Ph 4(req) and Constraint Manager Ph 1 Constraint Manager Ph 2 OCF-TCS
Control TAS Pathfinder TAS (under review)End Item Manager End Item Manager CCP Ph 1
System
System Integrity Ph 1
Master Console Ph 1Control Redundancy Management Ph 1 Redundancy Management Ph 2
System SecurityCheck Point Restart Ph1 Check Point Restart Ph2
Resource Management Ph 1System Control Ph 1 System Control Ph 2
ORTBASIS Basis Pathfinder Basis Transition Support External Center Support
Advance Retrieval Advance RetrievalBasic Real-Time Advisory Basic Real-Time Advisory
Development Sys SW Development Application Debug Config Desk Top Development Development Environment
Simulation Simulation ReleaseSimulation I/F to RTCN Ph 1 Simulation I/F to RTCN Ph 2 Simulation I/F to RTCN Ph 3
SDC SDC Transistion SDC OperationalLog Record and Retrieval Ph 1 Log Record and Retrieval Ph 2 Log Record and Retrieval Ph 3
Set Build and Load Ph 1 Set Build and Load Ph 2Test Build, Load, & Act Ph 1 Test Build, Load, & Act Ph 2 Test Build, Load, & Act Ph 3
CLCS SYSTEM DESIGN PROCESS
Design Panel Process• Concept• Requirements
Thread Statement of Work
System Level Requirements System Design Issues
EngineeringReviewPanel
Issue ResolutionTeams
6
• Requirements• Detail OR
• SLS, SDD• CSCI/HWCI Requirementsand Design Docs
CLCS DESIGN PANEL PROCESS
Design Panels
Provide the System Engineering and Development Community a Method of Communicating.
Allow the User Communities to Gain Significant Insight Throughout the
7
Throughout the
Incrementally Help to Meet the Intent of Preliminary Design Reviews and Critical Design Reviews As Discussed in MIL-STD-2167, MIL-STD-498
Process is Managed byThe Design Panel Chairman
Minutes are kept by Design PanelSecretary
Concept Design Panel Represents a “Contract” Between System Engineering and the Development Communities
– System Engineering Presentation Representing Concept of Thread Statement of Work Implementation
– Represents Development Community Work Assessment for a Particular System Thread
– Captures and Documents Development Schedule
Requirement Design Panel– CSCI and HWCI Based Presentation
– Equivalent to a ‘mini’ Preliminary Design Review Per CSCI and HWCI
CLCS DESIGN PANEL PROCESS - THREE STEPS
8
– Equivalent to a ‘mini’ Preliminary Design Review Per CSCI and HWCI
– Emphasizes Product Level Specifications in Response to all System Thread Impacts and Dependencies
– Identifies all External Interfaces and Top Level Data Flow Diagrams
Detailed Design Panel– CSCI and HWCI Based Presentation
– Equivalent to a ‘mini’ Critical Design Review Per CSCI and HWCI
– Emphasizes the external design of the CSCI and HWCI
CLCS DESIGN PANEL PROCESS
Delivery CapabilityAgreement
Thread Leadand CSCI/HWCI
Concept DesignPanel
RequirementsDesign Panel
Detailed DesignPanel
Project User
9
Agreement
ThreadKick-off
SystemEngineeringWork Session
and CSCI/HWCILeads
CSCI/HWCI DeveloperWork sessions
CSCI/HWCI DeveloperWork sessions
• Thread Concept
• CI ImpactsAssessment
• Schedule
• Refined Concept• Prelim. ProductSpecifications
• Prelim. TestPlans
•Refined Product•Specifications•Refined Data Flows•Refined Specs
Software Process and Project Metrics
Outline:
In the Software Metrics Domain:
product metrics
project metrics
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 1
project metrics
process metricsSoftware Measurement
size-oriented metrics
function-oriented metricsMetrics for Software Quality
Measure, Metrics, and Indicator
Measure -- Provides a quantitative indication of the extent, amount, dimensions, capacity, or size of some product or process attribute.
Metrics -- A quantitative measure of the degree to which a
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 2
Metrics -- A quantitative measure of the degree to which a system, component, or process possesses a given attribute.
Software Metrics -- refers to a broad range of measurements for computer software.
Indicator -- a metric or combination of metrics that provide insight into the software process, a software project, or the product itself.
In the Process and Project Domains
Process Indicator
enable insight into the efficacy of an existing processto assess the current work status
Goal -- to lead to long-term software process improvement
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 3
Goal -- to lead to long-term software process improvement
Project Indicator
assess the status of an ongoing projecttrack potential risksuncover problem areas before they go “critical”evaluate the project team’s ability to control the product
quality
Process Metrics and SoftwareProcess Improvement
Customer characteristics
Project
Business conditions
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 4
characteristics
People
conditions
Technology
Process
Development environment
Measurement
What to measure?errors uncovered before releasedefects delivered to and reported by end userswork products delivered
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 5
work products deliveredhuman effort expendedcalendar time expendedschedule conformance
At what level of aggregation?By team?Individual?Project?
Privacy Issues
Should they be used for personnel evaluation?
Some issues?
Privacy?
Is total assignment being measured?
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 6
Is total assignment being measured?
Are the items being measured the same as for other individuals being measured?
Are the conditions of measurement the same across individuals?
However, they can be useful for individual improvement.
Use of Software Metrics
Use common sense and organizational sensitivity. Provide regular feedback to individuals and teams. Don’t use metrics to appraise individuals. Set clear goal and metrics. Never use metrics to threaten individuals or teams
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 7
Never use metrics to threaten individuals or teams Problems != negative. These data are merely an indicator
for process improvement. Don’t obsess on a single metric to the exclusion of other
important metrics. Do not rely on metrics to solve your problems. Beware of people performing to metrics rather than
product quality or safety.
Statistical Software Process Improvement (SSPI)
All errors and defects are categorized by origin. The cost to correct each error and defect is recorded.
The number of errors and defects in each category is counted and ranked in descending order.
The overall cost of errors and defects in each category is
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 8
The overall cost of errors and defects in each category is computed.
Resultant data are analyzed to uncover the categories that result in highest cost to the organization.
Plans are developed to modify the process with the intent of eliminating (or reducing) the class of errors and defects that is most costly.
Typical Causes of Product Defects
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 9
Example of Defect Analysismissing ambiguous
wrong customer queried
specification defects
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 10
wrong customer queried
customer gave wrong infor.
inadequate inquiries
used outdated information changesincorrect
Project Metrics
Software Project Measures Are Tacticalused by a project manager and a software teamto adapt project work flow and technical activities
The Intent of Project Metrics Is Twofoldto minimize the development schedule to avoid delays and
mitigate potential problems and risks
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 11
mitigate potential problems and risksto assess project quality on an ongoing basis and modify
the technical approach to improvement quality Production Ratespages of documentationreview hoursfunction pointsdelivered source lineserrors uncovered during SW engineering tasks
Software Metrics
Direct measures
Cost and effort applied (in SEing process)
Lines of code(LOC) produced
Execution speed
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 12
Execution speed
CPU utilization
Memory size
Defects reported over certain period of time Indirect Measures
Functionality, quality, complexity, efficiency, reliability, maintainability.
Software Measurement
Size-Oriented Metricsare derived by normalizing quality and/or productivity
measures by considering the “size” of the software that has been produced.
lines of code often as normalization value.
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 13
lines of code often as normalization value.
project LOC effort $(000) pp.doc errors defects people
alpha 12,100 24 168 365 134 29 3beta 27,200 62 440 1224 321 86 5
gamma 20,200 43 314 1050 256 64 6
. . . . ... . . . .
. . . . .
Typical Size-Oriented Metrics
Errors per KLOC Defects per KLOC
Dollars per KLOC Pages of documentation per KLOC
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 14
Pages of documentation per KLOC Errors per person month LOC per person month Dollars per page of documentation
Software Measurement
Function-Oriented Metricsuse “functionality” to measure
derived from “function point”using an empirical relationship
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 15
using an empirical relationship
based on countable (direct) measure of SW information domain and assessments of software complexity
Use of Function-Oriented Metrics
Measuring scale of a projectNormalizing other metrics, e.g., $/FP, errors/FP
Function Point Calculation
Weighting Factormeasurement parameter count simple average complex
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 16
number of user outputs * 4 5 7 =# of user inquiries * 3 4 6 =number of files * 7 10 15 =# of external interfaces * 5 7 10 =
count_total
number of user inputs * 3 4 6 =
Function Point Calculation
Computing function pointsRate each factor on a scale of 0 to 5
no influence incidental moderate average significant essential
1 2 3 4 5 6
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 17
1. does the system require reliable backup and recovery?
2. are data communications required?
3. are there distributed processing functions?
4. is performance critical?
........
14. is the application designed to facilitate change and ease of use by the user?
Function-Oriented Metrics
FP = count_total * [0.65 + 0.01 * sum of Fi]
Outcome:
errors per FP
defects per FP
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 18
defects per FP
$ per FP
page of documentation per FP
FP per person_month
Function Point Extensions
Function Points emphasizes “data dimension” Transformations added to capture “functional dimension”
Transitions added to capture “control dimension”
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 19
3-D Function Point Calculation
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 20
Reconciling Different Metrics
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 21C++ 64 Visualbasic 32
Metrics for Software Productivity
LOC and FP Measures Are Often Used to Derive Productivity Metrics
5 Important Factors That Influence SW Productivity
people factors
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 22
people factorsproblem factorsprocess factorsproduct factorsresource factors
Measures of Software Quality
Correctness
is the degree to which the software performs its required function. the most common measure for correctness isdefects per KLOC (per year)
Maintainability
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 23
Maintainabilitythe ease that a program can be corrected
adapted if the environment changes
enhanced if the customer desires changes in requirements
based on the time-oriented measure mean time to change (MTTC).
Spoilage – a cost oriented metric for maintainability
Measures of Software Quality (Cont’d)
Integrityto measure a system’s ability to withstand attacks (both
accidental and intentional) on its security threat and security are defined
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 24
integrity = sum [ 1 - threat * (1- security)]
Usability - an attempt to quantify “user friendliness” physical/intellectual requirement to learn time required to become moderately efficient in the usethe net increase in productivityuser attitudes toward system
Defect Removal Efficiency
A Quality Metric That Provides Benefit at Both the Project and Process Level
DRE = E / ( E + D )
E = # of errors found before delivery of the software to
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 25
E = # of errors found before delivery of the software to the end user
D = # of defects found after delivery
More generally,
DREi = Ei / ( Ei + Ei+1 )
Ei = # of errors found during SE activity i
Integrating Metrics within the Processes
Arguments for S/w Metrics
Measurement is used to establish process baseline from which improvements can be assessed.
Developers are anxious to find after design:
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 26
Which user reqs. are most likely to change?
Which components in this system are most error prone?
How much testing should be planned for each component?
How many errors can I expect when testing commences?
Answers to these can be found if metrics are collected and used as technical guide.
Integrating Metrics within the Processes
Establishing a baseline
Benefits can be obtained at process, project & product levels
Consists of data collected from past s/w development
Baseline data should have following attributes:
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 27
Baseline data should have following attributes:
Data must be reasonably accurate
Collect data for as many projects as possible
Measures must be consistent
Applications should be similar to work
Metrics collection, computation and Evaluation
Summary View
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 28
Summary
Metrics are a tool which can be used to improve the productivity and quality of the software system
Process metrics takes a strategic view to the effectiveness of a software process
Project metrics are tactical that focus on project work flow
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 29
Project metrics are tactical that focus on project work flow and technical approach
Size-oriented metrics use the line of code as a normalizing factor
Function-oriented metrics use function points
Four quality metrics------correctness, integrity, maintainability, and usability were discussed
METRICS
CLCS Metrics PhilosophyPhase 1: Provide a mandatory, nearly automated, metrics foundation to
track lines of code and errors.
Phase 2: Provide additional high-return metrics with recognized value.
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 30
Schedule metrics (milestones)
Additional S/W Problem metrics (actuals, trends, prediction)
Defect correction metrics
Run-time analysis metrics (McCabe tools, automated, COTS)
Phase 3: Be driven to additional metrics only by absolute need.
METRICSSystem Software
Milestones Redstone CIT
Complete
Thor CIT Complet
e
Atlas CIT
Complete
Month/Year Sep-97 Oct-97 Nov-97 Dec-97 Jan-98 Feb-98 Mar-98 Apr-98 May-98 Jun-98 Jul-98 Aug-98Software Size (KSLOC) 377.2 377.2 383.3 388.1 450.2 554.3
Actual Size of Executable Code 214.1 214.1 218.2 221.3 250.6 319.3 0.0 0.0 0.0 0.0 0.0 0.0
Code Delivered Comments 163.1 163.1 165.1 166.8 199.6 242.1 0.0 0.0 0.0 0.0 0.0 0.0Razor Issue Closure TOTAL
Chapter 4 – R. S. Pressman SRIMCAMarch 2004 31
Issues Opened Urgent 9 3 2 0 4 5 0 0 0 0 0 0 23(this month) Critical 54 19 8 1 16 53 0 0 0 0 0 0 151
Major 60 16 20 5 28 26 0 0 0 0 0 0 155
Minor 57 17 6 0 13 37 0 0 0 0 0 0 130Total: 180 55 36 6 61 121 0 0 0 0 0 0 459
Issues Closed Urgent 6 6 1 1 3 2 0 0 0 0 0 0 19
(this month) Critical 36 26 11 0 13 12 0 0 0 0 0 0 98Major 39 24 12 4 14 10 0 0 0 0 0 0 103
Minor 27 17 19 5 2 16 0 0 0 0 0 0 86Total: 108 73 43 10 32 40 0 0 0 0 0 0 306
Current Issues Open: Urgent 3 0 1 0 1 4 0 0 0 0 0 0
Critical 18 11 8 9 12 53 0 0 0 0 0 0
Major 21 13 21 22 36 52 0 0 0 0 0 0
Minor 30 30 17 12 23 44 0 0 0 0 0 0
Total: 72 54 47 43 72 153 0 0 0 0 0 0
Error Density: Issues / KSLOC 0.84 1.10 1.24 1.25 1.35 1.44
Software Project Planning
Observations on Estimating
Estimation of Resources, Cost and Schedules
Factors affecting estimation
Project Complexity
Chapter 5 Software Project PlanningMarch 20041
Project Complexity
Project Size
Degree of Structural uncertainty
Software Project Planning
Steps to Software Planning
Define Software Scope
Determine Resources
Create Project Estimates
Chapter 5 Software Project PlanningMarch 20042
Create Project Estimates
Make or buy decision
Scope
What scope means:Functions
Literally refers to all functions performed by a systemPerformance
Chapter 5 Software Project PlanningMarch 20043
Performance
Refers to processing and response time requirementsConstraints
Limits placed on the software by external hardware, available memory or existing systems
Interfaces
Reliability
Scope
Obtaining the information
Communication, communication, communication!!!Meet with customer as often as needed.
Have free form discussion
Chapter 5 Software Project PlanningMarch 20044
Have free form discussionTry to understand his/her goals/constraints, not just what
she/he thinks they want.Government procurement often provides detailed written
specifications on what they want.
The problem is that those writing them probably didn’t fully understand, and they will change.
Government is trying for a more enlightened approach.
Scope Information
Some typical questionsOverall Goals
Who’s request; What benefit; Who else has solutionUnderstanding The Problem
Chapter 5 Software Project PlanningMarch 20045
Understanding The Problem
What output; What Problem; What Issues; What ConstraintsEffectiveness of Meeting
Are answers official; Are my questions relevant; Other sources of Info.
Scoping - Subsequent Meetings
Begin high level planning
Know the capabilities of existing software and staff
Joint teams of customer and developers/analysts
Checklist of items to cover
Chapter 5 Software Project PlanningMarch 20046
Checklist of items to cover
Organization of Information
Get everything down with diagrams
Create and save transcripts of Meetings
Possibly use Web.
Scoping Example
Bin 2ID No.
Bin 1
ID No. ID No. ID No.
Conveyor Line Motion
Chapter 5 Software Project PlanningMarch 20047
Sorting Station
Bin 2
ShuntBin 3
Bin 4
Bin 5
Bar Code
Control connection
Project Decomposition
For our example:Read bar code inputRead pulse tachometerDecode part code data
Chapter 5 Software Project PlanningMarch 20048
Decode part code dataDo database lookupDetermine bin locationProduce control signal for shuntMaintain record of box destinations
Resources
Chapter 5 Software Project PlanningMarch 20049
Resources
For each type of resources, 4 characteristics are examined:Description of resourceAvailabilityTime resource needed
Chapter 5 Software Project PlanningMarch 200410
Time resource neededDuration of time for which the resource is needed
Human Resources
Scope and skills required Organizational position and specialty must both be considered
As estimate of development effort is essential to determine the number of people required for the project.
Chapter 5 Software Project PlanningMarch 200411
number of people required for the project.
Reusable Software Resources
Off-the-shelf componentsExisting s/w acquired from 3rd party, fully validated
Full experience components
Existing specs, code or test data developed for past
Chapter 5 Software Project PlanningMarch 200412
Existing specs, code or test data developed for past projects
Partial experience components
New validation will have to be performed
New Components
Environmental Resources
Software Engineering Environment
CompilersEditors Design tools
Chapter 5 Software Project PlanningMarch 200413
Design toolsConfiguration management toolsManagement tracking toolsProblem Reporting And Corrective Action (PRACA) toolsDocumentation toolsHardware resourcesNetwork support
Software Project Estimation
Estimation critical -- software costs usually dominate project.
Categories of estimation techniques
Base estimates on similar projects already completedUse simple decomposition (possibly in combination with
Delay estimation until late in the project
Chapter 5 Software Project PlanningMarch 200414
Use simple decomposition (possibly in combination with other methods).
Use one or more empirical models, i.e.,
d = f(vi) where d – no of estimated values; vi – LOC or FP etc.
For example,
# of people = LOC ÷(Duration*(LOC/PM))
Decomposition Techniques
Software SizingThe degree of the size of product estimatedAbility to translate size estimate into human effort,
calendar time, dollarsThe degree to which project plan reflects abilities of s/w
Chapter 5 Software Project PlanningMarch 200415
The degree to which project plan reflects abilities of s/w team
The stability of product reqs. and the environment that supports the se effort
Using Direct approach, size can be measured in LOC Using Indirect approach, size is represented as FP
Software Sizing
4 approaches to Software Sizing problem“Fuzzy Logic” SizingFunction Point SizingStandard Component SizingChange Sizing
Chapter 5 Software Project PlanningMarch 200416
Change Sizing These methods can be combined statistically to create a Three-
Point or expected value estimate Done by developing Optimistic(low), most likely, and
pessimistic(high) values for size and combining them in equation
Problem-Based Estimation
Projects should be grouped by team size, application area, complexity, other parameters.
Local domain averages should be computed.
When new project is estimated, first allocate it to a domain,
Chapter 5 Software Project PlanningMarch 200417
and them determine domain average to generate the estimate
LOC use decomposition invariably, function wise.
FP uses info domain characteristics – inputs, outputs, data files, inquiries, external interfaces – as well as the 14 complexity adjustment values
Software Project Estimation
Precise estimation is difficult. So, make three estimates: optimistic, most likely, and pessimistic. Then combine as:
Expected value of size EV=(Sopt + 4Sm + Spess)/6
An example – CAD application s/w for mechanical unit
Chapter 5 Software Project PlanningMarch 200418
An example – CAD application s/w for mechanical unituser interface and control facilities2-D geometric analysis3-D geometirc analysisdatabase managementcomputer graphics displayperipheral controldesign analysis models
3-D opt = 4600 LOC3-D m. likely = 6900 LOC3-D pess. = 8600 LOC=> (4600+4*6900+8600)/6= 6800
Estimation Table
Chapter 5 Software Project PlanningMarch 200419
• Suppose 620 LOC/PM, and $8,000/PM, based upon historical data. Then,
Est. Cost = 33,200*$8,000/620 = $431,000 & Est. effort = 54 person months
Function Point Based Estimation
Function Point Complexity Weighting Factors
backup and recovery 4
Data communications 2
Distributed processing 0
Chapter 5 Software Project PlanningMarch 200420
Distributed processing 0
Performance critical 4
Existing operating environment 3
On-line data entry 4
…
Application designed for change 5
Total 52
Function Point Based Estimation
Chapter 5 Software Project PlanningMarch 200421
Complexity factor =
= 0.65+0.01×52 = 1.17
][ iF0.010.65
FP estimate = count-total×
= 318 × 1.17 = 372
]F0.010.65[i
Then, if 6.5 FP/PM, cost = 372 × $8,000 ÷ 6.5 = $457,000 and 58 person months
Process Based Estimation
Decompose the process into a set of activities or tasks Estimate effort or cost to perform each task
Estimate cost of each function
May be done using LOC and FP estimation or separately
Chapter 5 Software Project PlanningMarch 200422
May be done using LOC and FP estimation or separately
If estimated separately, then there are two or three distinct cost estimates.Reconcile differencesIf radically different, perhaps problem is not well
understood, or productivity data is obsolete, or the models have not been used correctly.
Process Based Estimation -- Example
ActivityCustomer
CommunicationPlanning Risk AnalysisCustomer Evaluation
Task Analysis Design Code Test
Function
UICF 0.50 2.50 0.40 5.00 n/a
Engineering Construction Release
Chapter 5 Software Project PlanningMarch 200423
UICF 0.50 2.50 0.40 5.00 n/a2DGA 0.75 4.00 0.60 2.00 n/a3DGA 0.50 4.00 1.00 3.00 n/a
DSM 0.50 3.00 1.00 1.50 n/aCGDF 0.50 3.00 0.75 1.50 n/a
PCF 0.25 2.00 0.50 1.50 n/aDAM 0.50 2.00 0.50 2.00 n/a
Total 0.25 0.25 0.25 3.50 20.50 4.75 16.50
% effort 1% 1% 1% 8% 45% 10% 36%
• If labor rate is $8,000/PM, then Est. cost = $368,000
Empirical Estimation Models
Based on limited number of sample projects
Typical form E = A + B×(ev)C
Some examplesE = 5.2×(KLOC)0.91 Walston-Felix Model
Chapter 5 Software Project PlanningMarch 200424
E = 5.2×(KLOC) Walston-Felix ModelE = 5.5 + 0.73×(KLOC)1.16 Bailey-Basili ModelE = 3.2×(KLOC)1.05 Boehm simple modelE = 5.288×(KLOC)1.047 Doty model for KLOC > 9E = -13.39 + 0.0545×FP Albrecht & GaffneyE = 60.62 + 7.728×10-8FP3 Kemerer ModelE = 585.7 + 15.12×FP Albrecht & Gaffney
Must calibrate for local conditions
The COCOMO II Model
•Application Composition model--Used during early stages of design
•Early Design Stage model
Chapter 5 Software Project PlanningMarch 200425
--When basic s/w archie. has been established
•Post-Architecture stage model--During construction of s/w
•3 sizing options – object points, function points & LOC
COCOMO II
Object point is computed using count of 1. Screen 2. Report & 3. Components required to build the application
Object Type Complexity Weight
Simple Medium Difficult
Chapter 5 Software Project PlanningMarch 200426
Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
3GL comonent 10
NOP = (object points) * [(100 - %reuse)/100]; NOP -> new object points
Productivity rate = NOP/person-month
COCOMO II
Developers experience/capability
Very low
Low Nominal High Very High
Environment maturity/capability
Very low
Low Nominal High Very High
PROD 4 7 13 25 50
Chapter 5 Software Project PlanningMarch 200427
Estimated effort = NOP/PROD
PROD 4 7 13 25 50
“The Software Equation”
The software equation -- E=[LOC * B0.333/P]3 * (1/t4), whereE = effort in person monthst = project duration in monthsB = “special skills factor” For KLOC (5, 15) use 0.16, for
KLOC > 70, use B = 0.39
Chapter 5 Software Project PlanningMarch 200428
KLOC > 70, use B = 0.39P = “productivity parameter” reflectingoverall process maturity and management practicesextent to which good software engineering usedstate of software environmentskill and experience of teamcomplexity of application
Software Equation Example
Typical productivity values Pe.g., 2,000 for real-time, 10,000 for tele-comm, 28,000 for
business applications. Simplified model suggested for tmin, E:t = 8.14(LOC/P)0.43 in months for t > 6 months
Chapter 5 Software Project PlanningMarch 200429
min
tmin = 8.14(LOC/P)0.43 in months for tmin > 6 monthsE = 180Bt3 for E >= 20 person months
For P = 12,000 (typical scientific computation)tmin = 8.14(33,200/12,000)0.43 = 12.6 monthsE = 180(0.28)(1.05)3 = 58 person months
Study implications of these equations.Trying to get done too fast requires much more effort.
Resources - Make-Buy Decision
Acquire or develop? Make/buy?
Acquisition options:
S/w may be purchased off-the-shelf
“Full-experience or partial-experience components may be acquired and then modified an integrated to meet specific
Chapter 5 Software Project PlanningMarch 200430
acquired and then modified an integrated to meet specific needs
S/w can be custom built by an outside contractor to meet purchaser’s specifications.
For expensive s/w, some guidelines are to be followed:
Resources - Make-Buy Decision
Develop specification for desired software Estimate cost to develop internally and estimate delivery date Select candidate applications that come closest to meeting
specifications. Select reusable components that could assist constructing the
Chapter 5 Software Project PlanningMarch 200431
Select reusable components that could assist constructing the required application
Develop comparison matrix that compares key functions and costs. Possibly conduct benchmark tests
Evaluate each s/w package or component based on past product quality, vendor support,. Product direction, reputation and the like
Contact other users of the s/w and ask for opinions
Resources - Make-Buy Decision
Make/Buy decision is made based on following:
Will the delivery date of s/w product be sooner than that for internally developed s/w?
Will the cost of acquisition plus the cost of customization
Chapter 5 Software Project PlanningMarch 200432
Will the cost of acquisition plus the cost of customization be less than the cost of developing the s/w internally
Will the cost of outside support (e.g. maintenance contract) be less than the cost of internal support?
Decision Tree Support
Build
reuse
EC = (path prob)i * (est. path cost)
major
minor changes (.40)
simple (.30)
difficult (.70)
$380,000
$450,000
$275,000simple (.20)
Chapter 5 Software Project PlanningMarch 200433
System Xbuy
contract
with changes (.40)
without changes (.60)
minor changes (.70)
major changes (.30)
major changes
(.60)$310,000
$490,000
$210,000
$400,000
$350,000
$500,000
simple (.20)
complex (.80)
Expected cost = ∑ (path probablity)I x (estimated path cost)I
Make/Buy Decision
1. Build system X from scratch
2. Reuse partial-experience components to construct the system
3. Buy an available s/w product and modify to meet local needs
4. Contract the s/w development to an outside vendor
Chapter 5 Software Project PlanningMarch 200434
The ev for cost computed along any branch is
Expected cost = (Path probability)i x (estimated path cost) I
where i = decision tree path. For the “build” path
EC(build) = 0.30 ($380K) + 0.70 ($450K) = $429K
EC(reuse) = 0.40 ($275K) + 0.60 (0.20 ($310K) + 0.80 ($490K)= $382 K
Make/Buy Decision
EC(buy) = 0.70 ($210K) + 0.30 ($400K) = $267KEC(contract) = 0.60 ($350K) + 0.40 ($500K) = $410K
Based on above figures, the lowest expected option is “buy” option.
Chapter 5 Software Project PlanningMarch 200435
Availability, experience of developer/vendor/contractor, conformance to requirements, local “politics” and likelihood of change are also the criteria that may affect the decision to build, reuse, buy or contract.
Summary
Project planner must estimate three things:
how long project will take
how much effort will be required
how many people will be required
Chapter 5 Software Project PlanningMarch 200436
how many people will be required
Must use decomposition and empirical modeling
Most empirical techniques need to be calibrated to individual situations.
Use multiple techniques to gain confidence in result
Risk Management
Introduction
Risk Identification
Risk Projection
Chapter 6 – Risk Management 1
Risk Mitigation, Monitoring, and Management
Safety Risks and Hazards
The RMMM plan
SEI Technical Reviews
Summary
Introduction
Risk management is a process that is used extensively for various purposes
Recall earlier questions raised about safety, costs, etc.
According to “Webster’s Seventh New Collegiate Dictionary”,
Chapter 6 – Risk Management 2
According to “Webster’s Seventh New Collegiate Dictionary”, risk is defined as a:
“possibility of loss or injury”
“the chance of loss or the perils to the subject matter of an insurance contract” and
“the degree of probability of such loss.”(1)
Introduction
Robert Charette(2) presented the following conceptual definitions of risk:
Risk concerns future happenings
Risk involves change, such as changes of mind, opinion,
Chapter 6 – Risk Management 3
Risk involves change, such as changes of mind, opinion, action or places
Risk involves choice, and the uncertainty that choice itself entails
Risk Characteristics :
uncertainty: may or may not happen
loss: unwanted consequences
Introduction
Management is
“the act or art of managing” and
“judicious use of means to accomplish an end”(1)
RISK MANAGEMENT can be defined as:
Chapter 6 – Risk Management 4
“A logical process for identifying and analyzing leading to appropriate methods for handling and monitoring exposures to loss”(3)
Risk management deals with:
Systematic identification of an exposure to the risk of loss, &
Making decisions on the best methods for handling these exposures to minimize losses
Introduction
Risk Strategies
Reactive
Software team does nothing about risks until something
Proactive
Begins long before technical work is initiated
Chapter 6 – Risk Management 5
about risks until something goes wrong
“fire fighting mode”
At best, monitors the projects for likely risks
technical work is initiated
Identification of potential risks (studies of probability, impact and priorities)
Objective: AVOID RISK
Responds are in a controlled and effective manner
Our Concern
Introduction
• Project Risks (budgetary, schedule, personnel, resource, customer)
• Technical Risks (design, implementation, interfacing, verification)
• Business Risks (market, strategic, management,budget)
Chapter 6 – Risk Management 6
SoftwareRisk
• Business Risks (market, strategic, management,budget)
Charette: (2)
• Known risks • Predictable• Unpredictable
Risk Identification
Risk identification is a systematic attempt to specify threats to the project plan
Identify known and predictable risks
Chapter 6 – Risk Management 7
Generic Product-specific
What characteristics of this product may threaten our project plan?
Risk Item List
Product size Business impact Customer characteristics Process definition Development environment Technology to be built Staff size and experience
Risk Identification
Product Size Risk : Estimated size of the product in LOC or FP?Percentage deviation in size of product from average for
previous products?Number of users/projected changes to the requirements for
Chapter 6 – Risk Management 8
Number of users/projected changes to the requirements for the product?
Amount of reused software? Business Impact risks:Effect of this product on the company revenue?Visibility of this product to senior management?Amount & quality of product documentation to be produced?Governmental constraints on the construction of the product?
Risk Identification
Customer related risks: (needs, personalities, contradictions , associations)Have you worked with the customer in the past?Does the customer have a solid idea of what is required?Will the customer agree to have meetings?
Chapter 6 – Risk Management 9
Will the customer agree to have meetings?Is the customer technically sophisticated in the product area?Does the customer understand the software process?
Technology Risks:Is the technology to be built new to your organization?Does the SW interface with new or unproven HW/SW?Do requirements demand creation of new components ?Do requirements impose excessive performance constraints ?
Risk Identification Process Risks : (4)
Does senior management support a written policy statement that emphasizes a standard process for software development ?
Is there a written description of the software process to be used?Is the software process used for other projects ?Is configuration management used to maintain consistency among
ProcessIssues:
Chapter 6 – Risk Management 10
Is configuration management used to maintain consistency among system/software requirements, design, code and test?
Is a procedure followed for tracking subcontractor performance?
Tech-nical Issues:
Are facilitated application specification techniques used to aid in communication between the customer and developer ?
Are specific methods used for software analysis?Do you use specific method for data and architectural design?Are software tools used to support the software analysis and design?Are tools used to create software prototypes?Are quality/productivity metrics collected for all software projects?
Risk Identification Development Environment Risks:Is a software project/process management tool available?Are tools for analysis and design available??Are testing tools available and appropriate for the product?Are all SW tools integrated with one another?Have members of the project team received training in
Chapter 6 – Risk Management 11
Have members of the project team received training in each of the tools?
Risk Associated with Staff Size and Experience:Are the best people available?Do the people have the right combination of skills?Are staff committed for entire duration of the project?Do staff have the right expectations about the job at hand?Will turnover among staff be low enough to allow continuity?
Risk Identification
Risk Components and Drivers (U.S. Air Force guidelines)
Performance risk: the degree of uncertainty that the product will meet its requirements and be fit for its intended use
Chapter 6 – Risk Management 12
intended useCost risk: the degree of uncertainty that the project budget
will be maintainedSupport risk:the degree of uncertainty that the software
will be easy to correct, adapt, and enhanceSchedule risk: the degree of uncertainty that the project
schedule will be maintained
Risk Identification
1
2
Significant degradation to nonachievement of
Nonresponsive or
unsupportable
Significant financial
shortages, budget
Unachievable CATASTROPHIC
COMPONENTS
CATEGORY
PERFORMANCE SUPPORT COST SCHEDULE
Failure to meet the requirements would
result in mission failure
Failure results in increased costs and
schedule delays with expected values in
excesss of $500k
Chapter 6 – Risk Management 13
technical performance software overrun likely delivery date
1
2
Some reduction in
technical performance
Minor delays in
software
modifications
Some shortage of
financial resources,
possible overruns
Possible slippage in
delivery date
1
2Minimal to small reduction in technical performance
Responsive
software support
Sufficient financial
resources
Realistic,
achievable schedule
1
2No reduction in technical performance
Easily supportable software
Possible budget underrun
Early achievable delivery date
NEGLIGIBLE
MARGINAL
CRITICAL
Failure to meet the requirements would
degrade system performance to a point
where misssion success is questionable
Failure to meet the requirements would
result in degradation of secondary
misssion
Failure results in operational delays
and/or increased costs with expected
values of $100k to $500k
Cost, impacts, and/or recoverable
schedule slips with expected value of $1
to $100K
Failure to meet the requirements would
create inconvenience or nonoperational
impact
Error in minor cost and/or schedule
impact with expected value of less than
$1k
Risk Projection
Also called risk estimation, attempts to rate each risk in two ways:Likelihood (probability)
ConsequencesDevelop a risk table: A risk table provides a project
Chapter 6 – Risk Management 14
Develop a risk table: A risk table provides a project manager with a simple technique for risk projectionFor each identified risk, list likelihood, consequence
and impactRisk Assessment: Examine the accuracy of the estimates
that were made during risk projection. A risk referent level must be defined and the referent point or break point should be established
Risk Projection
Risks Category Probability Impact RMMMSize estimate may be significantly low PS 60% 2Larger number of users than planned PS 30% 3Less reuse than planned PS 70% 2End users resist system BU 40% 3
Chapter 6 – Risk Management 15
End users resist system BU 40% 3Delivery deadline will be tightened BU 50% 2Funding will be lost CU 40% 1Customer will change requirements PS 80% 2Technology will not meet expectations TE 30% 1Lack of training on tools DE 80% 2Staff inexperienced ST 30% 2Staff turnover will be high ST 60% 2...
Risk Matrix
LIkel
5
4
Chapter 6 – Risk Management 16
Consequences1 2 3 4 5
lIhood
3
2
1
Risk Mitigation, Monitoring, andManagement
An effective strategy must consider three issues:risk avoidance,risk monitoring, andrisk management and contingency planning.
A proactive approach to risk avoidance is the best strategy.
Chapter 6 – Risk Management 17
A proactive approach to risk avoidance is the best strategy. Develop a plan for risk mitigation. For example: assume that high staff turnover is noted as a project risk r1, some of the possible steps to be taken are these:meet with current staff to determine causes for turnoverassume turnover will occur and develop techniques to
ensure continuity when people leave.define a backup staff member for every critical technologies.
Risk Mitigation, Monitoring, andManagement
As the project proceeds, the following factors can be monitored:general attitude of team members based on project
pressures,the degree to which the team has jelled,
Chapter 6 – Risk Management 18
the degree to which the team has jelled,interpersonal relationship among team members,availability of jobs within the company and outside it
In addition of these factors, the project manager should monitor the effectiveness of risk mitigation steps.
Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become reality.
Safety Risks and Hazards
Software safety and hazard analysis are software quality assurance activities that focus on the identification and assessment of potential hazard that may impact software negatively and cause an entire system to fail.
Chapter 6 – Risk Management 19
negatively and cause an entire system to fail.
If hazards can be identified early in the software engineering process, software design features can be specified that will either eliminate or control potential hazards.
The RMMM plan
1. Introduction
1.1. Scope and Purpose of Document
1.2. Overview of major risks
1.3. Responsibilities
An outline for the Risk Mitigation, Monitoring, and Management
Chapter 6 – Risk Management 20
1.3. Responsibilities
1.3.1. Management
1.3.2. Technical staff
2. Project Risk Table
2.1. Description of all risks above cut-off
2.2. Factors influencing probability and impact
Management plan.
The RMMM plan
3. Risk Mitigation, Monitoring, Management3.n Risk #n (for each risk above cut-off)
3.1.1. Mitigation3.1.1.1. General strategy3.1.1.2. Specific steps to mitigate
the risk
An outline for the Risk Mitigation, Monitoring, and Management
Chapter 6 – Risk Management 21
the risk3.1.2. Monitoring
3.1.2.1. Factors to be monitored3.1.2.2. Monitoring approach
3.1.3.Management3.1.3.1. Contingency plan3.1.3.2. Special considerations
4. RMMM Plan Iteration Schedule5. Summary
Management plan.
SEI Risk Management Paradigm
a) Identifyb) Analyzec) Pland) Track
Chapter 6 – Risk Management 22
d) Tracke) Controlf) Communicate
SEI Software Development Risk
Chapter 6 – Risk Management 23
SEI Technical Reviews
Software Risk Management
Ronald P. Higuera, Yacov Y. Haimes; June 1996
An Introduction To Team Management (Version 1.0)
Chapter 6 – Risk Management 24
Ronald P. Higuera, David P. Gluch, Richard L. Murphy ; May 1994
Software Development Risk: Opportunity Not Problem
Roger L. Van Scoy; September 1992
Taxonomy-Based Risk Identification
Marvin J. Carr, Surresh L. Konda, Ira Monarch, F. Carol Ulrich; June 1993
www.sei.cmu.edu/products/publications.info.html
Summary
Risk analysis is an important part of most software projects.
Risk analysis requires a significant amount of project planning effort.
Understanding risk helps you know where to commit your
Chapter 6 – Risk Management 25
Understanding risk helps you know where to commit your resources.
If you don’t actively attack the risks, they will actively attack you.
Major projects should all have a risk management plan..
NASA Risk Management
Chapter 6 -- R. A. Volz -- Assistance -- JulioNovember 9, 1997 1
NASA
Chapter 6 -- R. A. Volz -- Assistance -- JulioNovember 9, 1997 2
NASA - Shuttle-Mir
Chapter 6 -- R. A. Volz -- Assistance -- JulioNovember 9, 1997 3
Chapter 6 -- R. A. Volz -- Assistance -- JulioNovember 9, 1997 4
Chapter 6 -- R. A. Volz -- Assistance -- JulioNovember 9, 1997 5
Chapter 6 -- R. A. Volz -- Assistance -- JulioNovember 9, 1997 6
Chapter 6 -- R. A. Volz -- Assistance -- JulioNovember 9, 1997 7
Project Scheduling and Tracking
Basic problem -- Software is almost always late.
Unrealistic deadlinesChanging requirementsMiscommunication among staff
Chapter 7November 5, 1997 1
Miscommunication among staffRisks not considered at beginning of projectTechnical difficulties that could not be foreseen in advanceHuman difficulties that could not be foreseen in advanceFailure by management to recognize and correct the problemAn “honest” underestimate of effort required
“Reviewed into failure”
Project Scheduling and Tracking
An approach to unrealistic deadlines -- project redefinitionPerform detailed estimate based on previous projects
Use incremental process to deliver critical functionality on time
Chapter 7November 5, 1997 2
time
Meet with customer (which may be upper management)
Offer incremental development strategy as an alternative
Basic Principles
Compartmentalization
Identify task interdependencies
Allocate time for each task
Develop feasible schedule
Chapter 7November 5, 1997 3
Develop feasible schedule
Define responsibilities. Each task should have a single person responsible. Each person should know their responsibilities.
Define outcomes
Define milestones
# of People vs. Effort
Adding people to a project increases communication requirements
Recall the software equation -- E=[LOC * B0.333/P]3 * (1/t4), whereE = effort in person months
Chapter 7November 5, 1997 4
E = effort in person monthst = project duration in monthsB = “special skills factor” For KLOC (5, 15) use 0.16, for
KLOC > 70, use B = 0.39P = “productivity parameter”
Decreasing the time to complete the project requires more people, but look at the exponential nature of the relationship!
Effort distribution -- often as little as 10% goes into coding.
Defining the Task Set
Recall the general categories of tasks (from Ch. 2)
Customer communication
Planning
Risk analysis
Chapter 7November 5, 1997 5
Risk analysis
Engineering and design
Construction and release
Customer evaluation
Need to refine the task definitions in each of these categories No set rules for doing so Different projects can require different degrees of rigor
Broad Categories of Projects &Degrees of Rigor
Types of projectsConcept developmentNew application development projectsApplication enhancement projectsApplication maintenance projects
Chapter 7November 5, 1997 6
Application maintenance projectsReengineering projects
There can be a progression through these kinds of projects
These can be approached with different levels of rigor:casualStructuredStrictQuick Reaction
Degrees of Rigor
Adaptation criteria -- rate 1 to 5Size of the projectNumber of potential usersMission criticalityApplication longevity
Chapter 7November 5, 1997 7
Application longevityStability of requirementsEase of customer/developer communicationsMaturity of applicable technologyPerformance constraintsEmbedded/nonembedded characteristicsProject staffingReengineering factors
Task Set Selector Values
Chapter 7November 5, 1997 8
(compute average value)
Example
Chapter 7November 5, 1997 9
Linear, Sequential Model
See text for outline of example procedure
Chapter 7November 5, 1997 10
Evolutionary (Spiral) Model
Chapter 7November 5, 1997 11
Example of Task Network
Chapter 7November 5, 1997 12
Scheduling
Typical tools
Program Evaluation and Review Technique (PERT) charts
Critical Path Method (CPM)
Work Breakdown Structure (WBS) Formal term for task structure
Chapter 7November 5, 1997 13
Useful information derivable from timeline chartsEarliest beginning time for a taskLatest time to initiate a task without delaying projectEarliest task completion timeLatest task completion timeTotal float
Formal term for task structure
Example of Timeline Chart
Chapter 7November 5, 1997 14
Tracking the Schedule
Conduct periodic status meetings
Evaluate all Software Engineering Process Reviews
Determine whether formal milestones are met on time
Compare actual start date on each task to that planned
Chapter 7November 5, 1997 15
Compare actual start date on each task to that planned
Informal subjective assessment from practitioners
Possible corrective actions in case of problems
Re-deploy personnel Commit reserve resources Reschedule Re-scope the project
Example Project Table
Chapter 7November 5, 1997 16
Typical Project Plan Outline
Chapter 7November 5, 1997 17
Software Quality Assurance -OutlineSoftware Quality Assurance -Outline
What is Software Quality assurance(SQA)?What is Software Quality assurance(SQA)?
Quality Concepts.Quality Concepts.
Software Quality Assurance Activities.Software Quality Assurance Activities.
SRIMCA
Software Quality Assurance Activities.Software Quality Assurance Activities.
Software Reviews and their importanceSoftware Reviews and their importance
Statistical SQA.Statistical SQA.
Software ReliabilitySoftware Reliability
ISO 9000 approach to SQAISO 9000 approach to SQA
What is SQA?What is SQA?
Software Quality Assurance is an umbrella Software Quality Assurance is an umbrella activity that is applied throughout the activity that is applied throughout the software process...software process...
SRIMCA
software process...software process...
It encompasses..It encompasses..
A quality management approachA quality management approach Effective software engineering technologyEffective software engineering technology Formal technical reviews that are applied Formal technical reviews that are applied
throughout the software processthroughout the software process
SRIMCA
throughout the software processthroughout the software process A multitiered testing strategyA multitiered testing strategy Control of software documentation and Control of software documentation and
changes to itchanges to it A procedure to assure compliance with A procedure to assure compliance with
software development standardssoftware development standards Measurement and reporting techniquesMeasurement and reporting techniques
Quality ???Quality ???
QualityQuality refers to any measurable refers to any measurable characteristics such as correctness, characteristics such as correctness, maintainability, portability, testability, maintainability, portability, testability,
SRIMCA
maintainability, portability, testability, maintainability, portability, testability, usability, reliability, efficiency, integrity, usability, reliability, efficiency, integrity, reusability and interoperability.reusability and interoperability.
Measures of program’s characteristics; as Measures of program’s characteristics; as cyclomatic complexity, cohesion, fp, loc etc.cyclomatic complexity, cohesion, fp, loc etc.
Quality ConceptsQuality Concepts
Quality of DesignQuality of Design refers to the characteristics that refers to the characteristics that designer’s specify for an item.designer’s specify for an item.
Quality of ConformanceQuality of Conformance is the degree to which the is the degree to which the
SRIMCA
Quality ControlQuality Control is the series of inspections, is the series of inspections, reviews and tests used throughout the reviews and tests used throughout the development cycle to ensure that each work development cycle to ensure that each work product meets the requirements placed upon it.product meets the requirements placed upon it.
Quality of ConformanceQuality of Conformance is the degree to which the is the degree to which the design specifications are followed during design specifications are followed during manufacturing.manufacturing.
(cont'd)...(cont'd)...
Quality policyQuality policy refers to the basic aims and refers to the basic aims and objectives of an organization regarding quality as objectives of an organization regarding quality as stipulated by the management.stipulated by the management.
Quality assuranceQuality assurance consists of the auditing and consists of the auditing and
SRIMCA
Quality assuranceQuality assurance consists of the auditing and consists of the auditing and reporting functions of management.reporting functions of management.
Cost of QualityCost of Quality provide a baseline for current cost provide a baseline for current cost of quality, identify opportunities for reducing the of quality, identify opportunities for reducing the cost of quality, and provide a normalized basis of cost of quality, and provide a normalized basis of comparision.comparision.
(cont'd)...(cont'd)...
Quality Costs Quality Costs are divided into costs associated are divided into costs associated with prevention, appraisal, failure with prevention, appraisal, failure –– internal & internal & external costsexternal costs
Prevention Prevention –– Quality planning, formal technical Quality planning, formal technical
SRIMCA
Prevention Prevention –– Quality planning, formal technical Quality planning, formal technical reviews, test equipment, trainingreviews, test equipment, training
Appraisal Appraisal –– gain insight into product condition gain insight into product condition “first time through” each process; which include“first time through” each process; which include InIn--process and interprocess and inter--process inspectionprocess inspection Equipment calibration and maintenanceEquipment calibration and maintenance TestingTesting
(cont'd)...(cont'd)...
Failure CostsFailure Costs –– those which disappearthose which disappearbefore shipping product to customerbefore shipping product to customerInternal Internal –– detection of defect prior to detection of defect prior to
SRIMCA
Internal Internal –– detection of defect prior to detection of defect prior to shipmentshipmentRework, repair, failure mode analysisRework, repair, failure mode analysis
External External –– defect found after shipmentdefect found after shipmentComplaint resolution, product return & Complaint resolution, product return &
replacement, help line support, warranty workreplacement, help line support, warranty work
Relative cost of correcting an errorRelative cost of correcting an error
SRIMCA
(cont'd)...(cont'd)...
Quality planningQuality planning is the process of assessing the is the process of assessing the requirements of the procedure and of the product requirements of the procedure and of the product and the context in which these must be observed.and the context in which these must be observed.
Quality testingQuality testing is assessment of the extent to which is assessment of the extent to which
SRIMCA
Quality testingQuality testing is assessment of the extent to which is assessment of the extent to which a test object meets given requirementsa test object meets given requirements
Quality assurance planQuality assurance plan is the central aid for is the central aid for planning and checking the quality assurance.planning and checking the quality assurance.
Quality assurance systemQuality assurance system is the organizational is the organizational structure, responsibilities, procedures, processes and structure, responsibilities, procedures, processes and resources for implementing quality management.resources for implementing quality management.
Defn. of Software Quality AssuranceDefn. of Software Quality Assurance
Conformance to explicitly stated functional Conformance to explicitly stated functional and performance requirements, explicitly and performance requirements, explicitly documented development standards, and documented development standards, and
SRIMCA
documented development standards, and documented development standards, and implicit characteristics that are expected of implicit characteristics that are expected of all professionally developed software.all professionally developed software.
Defn. of Software Quality AssuranceDefn. of Software Quality Assurance
1. S/W requirements are the foundation of quality; 1. S/W requirements are the foundation of quality; lack of conformance to requirements is lack of lack of conformance to requirements is lack of quality.quality.
2. Specified standards define a set of development 2. Specified standards define a set of development
SRIMCA
2. Specified standards define a set of development 2. Specified standards define a set of development criteria that guide the teams in which s/w is criteria that guide the teams in which s/w is engineered; if not followed, lack of quality will engineered; if not followed, lack of quality will surely resultsurely result
3. A set of implicit requirements often goes 3. A set of implicit requirements often goes unmentioned; if not met, s/w quality is suspect.unmentioned; if not met, s/w quality is suspect.
SQASQA
SQA is composed with tasks associatedSQA is composed with tasks associatedwith:with: S/w Engineers who do technical workS/w Engineers who do technical work
SRIMCA
S/w Engineers who do technical workS/w Engineers who do technical work
SQA group responsible for quality SQA group responsible for quality assurance planning, oversight, recordassurance planning, oversight, record--keeping, analysis and reporting keeping, analysis and reporting –– to assist to assist the s/w team in achieving a high quality end the s/w team in achieving a high quality end product.product.
SQA Group PlanSQA Group Plan
Evaluations to be performedEvaluations to be performed
Audits and reviews to be performed Audits and reviews to be performed
SQASQA group perform following group perform following activitiesactivities::
SRIMCA
Audits and reviews to be performed Audits and reviews to be performed
Standards that are applicable to the project Standards that are applicable to the project
Procedures for error reporting and trackingProcedures for error reporting and tracking
Documents to be produced by the SQA groupDocuments to be produced by the SQA group
Amount of feedback provided to software Amount of feedback provided to software project teamproject team
SQA Group ActivitiesSQA Group Activities
Participates in the development of the Participates in the development of the projects software process descriptionprojects software process description
Reviews software engineering activities to Reviews software engineering activities to
SRIMCA
Reviews software engineering activities to Reviews software engineering activities to verify compliance with the defined software verify compliance with the defined software process.process.
Audits designated software work products Audits designated software work products to verify compliance with those defined as to verify compliance with those defined as part of the software process.part of the software process.
(cont'd)...(cont'd)...
Ensures that deviations in software work Ensures that deviations in software work and work products are documented and and work products are documented and handled according to a document procedure.handled according to a document procedure.
Records any nonRecords any non--compliance and reports to compliance and reports to
SRIMCA
Records any nonRecords any non--compliance and reports to compliance and reports to senior management.senior management.
In addition to these, SQA group may coIn addition to these, SQA group may co--ordinate the control and management of ordinate the control and management of change, and helps to collect and analyze s/w change, and helps to collect and analyze s/w metrics.metrics.
Software ReviewsSoftware Reviews
‘Filter’ for the software engineering process‘Filter’ for the software engineering process
‘Purify’ the software work products that ‘Purify’ the software work products that occur as a result of analysis, design, and occur as a result of analysis, design, and
SRIMCA
occur as a result of analysis, design, and occur as a result of analysis, design, and coding.coding.
Achieve technical work of more uniform, Achieve technical work of more uniform, greater and more predictable quality.greater and more predictable quality.
Detect errors and problems at the earliest Detect errors and problems at the earliest possible time.possible time.
Formal Technical ReviewsFormal Technical Reviews
To uncover errors in function, logic, or To uncover errors in function, logic, or implementation for any representation of the implementation for any representation of the softwaresoftware
To verify that software meets its requirementsTo verify that software meets its requirements
SRIMCA
To verify that software meets its requirementsTo verify that software meets its requirements
To ensure that software representation meets To ensure that software representation meets predefined standardspredefined standards
To achieve software development in a uniform To achieve software development in a uniform mannermanner
To make projects more manageableTo make projects more manageable
Cost Impact of Software DefectsCost Impact of Software Defects
Defect = Fault (We knew it as Defect = Fault (We knew it as error error before delivery)before delivery)
Industry studies reveal that almost 50Industry studies reveal that almost 50--65 % of all errors 65 % of all errors (defects) are introduced during design activities(defects) are introduced during design activities
SRIMCA
By detecting and removing them, review process By detecting and removing them, review process substantially reduces the cost of subsequent steps in the substantially reduces the cost of subsequent steps in the development and support phases.development and support phases.
E.g. assume that an error uncovered during design will E.g. assume that an error uncovered during design will cost 1 Rs., relative to this, the same error uncovered just cost 1 Rs., relative to this, the same error uncovered just before testing commences will be 6.5 Rs., during testing, before testing commences will be 6.5 Rs., during testing, 15 Rs. And after release 6015 Rs. And after release 60--100 Rs.100 Rs.
Defect Amplification ModelDefect Amplification Model
Errors passed throughErrors passed through Percent Percent
Development StepDevelopment Step
Errors Errors Errors Errors
DefectsDefects DetectionDetection
SRIMCA
Errors passed throughErrors passed through Percent Percent efficiency for efficiency for
error error detectiondetection
Amplified errors 1 : xAmplified errors 1 : x
Newly generated errorsNewly generated errors
Errors Errors from from previous previous stepstep
Errors Errors passed passed to next to next stepstep
Defect Amplification ModelDefect Amplification Model
SRIMCA
Defect Amplification withReviewsDefect Amplification withReviews
SRIMCA
Cost Comparison of Error RepairCost Comparison of Error Repair
SRIMCA
Review Guidelines..Review Guidelines..
Review the product, not Review the product, not producerproducer
Set an agenda and Set an agenda and maintain itmaintain it
Limit the number of Limit the number of participants and insist participants and insist upon advance upon advance preparationpreparation
SRIMCA
maintain itmaintain it Limit the debate Limit the debate Enunciate problem Enunciate problem
areas, not to solve every areas, not to solve every problem notedproblem noted
Take written notesTake written notes Allocate resources and Allocate resources and
time schedule for FTR’stime schedule for FTR’s
preparationpreparation Develop a checklist for Develop a checklist for
each work product to be each work product to be reviewedreviewed
Training for all Training for all reviewer’sreviewer’s
Reviewing earlier Reviewing earlier reviewsreviews
Additional StructuresAdditional Structures
Requirements Control BoardRequirements Control Board All requirement changes must be formally All requirement changes must be formally
reviewed and approvedreviewed and approved
SRIMCA
reviewed and approvedreviewed and approved
Software Control BoardSoftware Control Board All design changes must be formally reviewed All design changes must be formally reviewed
and approvedand approved
Interface Control BoardInterface Control Board
Statistical Quality AssuranceStatistical Quality Assurance
Implies information about software defects Implies information about software defects is collected and categorized is collected and categorized
An attempt is made to trace each defect to An attempt is made to trace each defect to
SRIMCA
An attempt is made to trace each defect to An attempt is made to trace each defect to its underlying causeits underlying cause
Isolate the vital few causes of the major Isolate the vital few causes of the major source of all errorssource of all errors
Then move to correct the problems that Then move to correct the problems that have caused the defectshave caused the defects
Categories of ErrorsCategories of Errors
Incomplete or erroneous specification (IES)Incomplete or erroneous specification (IES)
Misinterpretation of customer comm (MCC)Misinterpretation of customer comm (MCC)
Intentional deviation from specification (IDS)Intentional deviation from specification (IDS)
SRIMCA
Intentional deviation from specification (IDS)Intentional deviation from specification (IDS)
Violation of programming standards (VPS)Violation of programming standards (VPS)
Error in data representation (EDR)Error in data representation (EDR)
Inconsistent module interface (IMI)Inconsistent module interface (IMI)
Error in design logic (EDL)Error in design logic (EDL)
Categories of Errors (cont'd)Categories of Errors (cont'd)
Incomplete or erroneous testing (IET)Incomplete or erroneous testing (IET)
Inaccurate or incomplete documentation (IID)Inaccurate or incomplete documentation (IID)
Error in programming lang. Translation (PLT)Error in programming lang. Translation (PLT)
SRIMCA
Error in programming lang. Translation (PLT)Error in programming lang. Translation (PLT)
Ambiguous or inconsistent humanAmbiguous or inconsistent human--computer computer interface (HCI)interface (HCI)
Miscellaneous (MIS)Miscellaneous (MIS)
Most often IES, MCC and EDR are the vital Most often IES, MCC and EDR are the vital few causes for majority of errors.few causes for majority of errors.
DefinitionsDefinitions
EEi i = = the total number of errors uncovered the total number of errors uncovered during the iduring the ith th step in the software step in the software engineering processengineering process
SRIMCA
engineering processengineering process
SSii = the number of serious errors= the number of serious errors
MMii = the number of moderate errors= the number of moderate errors
TTii = the number of minor errors= the number of minor errors
PS = size of the product (LOC, design PS = size of the product (LOC, design statements, pages of documentation)statements, pages of documentation)
error indexerror index
Phase index for each step and then error Phase index for each step and then error index is calculatedindex is calculated
PIPIii = w= wss(S(Sii/E/Eii)+w)+wmm(M(Mii/E/Eii)+w)+wtt(T(Tii/E/Eii))
SRIMCA
PIPIii = w= wss(S(Sii/E/Eii)+w)+wmm(M(Mii/E/Eii)+w)+wtt(T(Tii/E/Eii))
Formula:Formula:
( ) /
( ) /
i PI PS
PI PI PI iPI PS
X i
i
1 2 32 3
Software ReliabilitySoftware Reliability
Defined as the probability of failure free operation Defined as the probability of failure free operation of a computer program in a specified environment of a computer program in a specified environment for a specified time.for a specified time.
It can measured, directed and estimated It can measured, directed and estimated
SRIMCA
It can measured, directed and estimated It can measured, directed and estimated
A measure of software reliability is A measure of software reliability is mean time mean time between failuresbetween failures wherewhere
MTBF = MTTF + MTTRMTBF = MTTF + MTTR
MTTF = MTTF = mean time to failuremean time to failure
MTTR = MTTR = mean time to repairmean time to repair
Software AvailabilitySoftware Availability
Availability =MTTF/(MTTF + MTTR) * 100%Availability =MTTF/(MTTF + MTTR) * 100%
Software availabilitySoftware availability is the probability that a is the probability that a program is operating according to requirements at program is operating according to requirements at a given point in time a given point in time
SRIMCA
a given point in time a given point in time
Software SafetySoftware Safety
Processes that help reduce the probability Processes that help reduce the probability that critical failures will occur due to SWthat critical failures will occur due to SW
Hazard analysesHazard analyses Identify hazards that could call failureIdentify hazards that could call failure
SRIMCA
Identify hazards that could call failureIdentify hazards that could call failure Develop fault treeDevelop fault tree Identify all possible causes of the hazardIdentify all possible causes of the hazard Formally review the remedy for eachFormally review the remedy for each
RedundancyRedundancy Require a written software safety planRequire a written software safety plan Require independent verification & validationRequire independent verification & validation
Example Fault Tree -- ThermalExample Fault Tree -- Thermal
Loss of heatLoss of heat
Power failurePower failure Computer failureComputer failure IncorrectIncorrect SW failed SW failed
......
SRIMCA
Power failurePower failure Computer failureComputer failure IncorrectIncorrect
inputinput
SW failed SW failed to throw to throw switchswitch
Computer failureComputer failure SW failed SW failed to throw to throw switchswitch
......Logic reversedLogic reversed
Software SafetySoftware Safety
RedundancyRedundancy Replicated at the hardware levelReplicated at the hardware level
Similar vs.. disSimilar vs.. dis--similar redundancysimilar redundancy
SRIMCA
Similar vs.. disSimilar vs.. dis--similar redundancysimilar redundancy VerificationVerification Assuring that the software specifications are metAssuring that the software specifications are met
ValidationValidation Assuring that the product functions as desiredAssuring that the product functions as desired
IndependenceIndependence
Overview of SQA PlanOverview of SQA Plan
Purpose of PlanPurpose of Plan
ReferencesReferences
Management Management
Tools, Techniques and Tools, Techniques and MethodologiesMethodologies
Code ControlCode Control
Media ControlMedia Control
SRIMCA
DocumentationDocumentation
Standards, Practices and Standards, Practices and ConventionsConventions
Reviews and AuditsReviews and Audits
TestTest
Problem Reporting and Problem Reporting and Corrective actionCorrective action
Media ControlMedia Control
Supplier controlSupplier control
Records Collection, Records Collection, Maintenance and Maintenance and RetentionRetention
Training Training
Risk ManagementRisk Management
ISO 9000 Quality StandardsISO 9000 Quality Standards
ISO 9000 describes quality assurance elements in ISO 9000 describes quality assurance elements in generic terms that can be applied to any business.generic terms that can be applied to any business.
It treats an enterprise as a network of It treats an enterprise as a network of interconnected processes.interconnected processes.
SRIMCA
interconnected processes.interconnected processes.
To be ISOTo be ISO--complaint processes should adhere to complaint processes should adhere to the standards described.the standards described.
Elements include organizational structure, Elements include organizational structure, procedures, processes and resources.procedures, processes and resources.
Ensures quality planning, quality control, quality Ensures quality planning, quality control, quality assurance and quality improvement. assurance and quality improvement.
ISO 9001ISO 9001
An international standard which provides An international standard which provides broad guidance to software developers on broad guidance to software developers on how to Implement, maintain and improve a how to Implement, maintain and improve a
SRIMCA
how to Implement, maintain and improve a how to Implement, maintain and improve a quality software system capable of ensuring quality software system capable of ensuring high quality softwarehigh quality software
Consists of 20 requirements...Consists of 20 requirements...
Differs from country to country..Differs from country to country..
ISO 9001 (cont'd)..requirementsISO 9001 (cont'd)..requirements
Management Management responsibilityresponsibility
Quality systemQuality system
Control of customer Control of customer supplied productsupplied product
Product identification Product identification and traceabilityand traceability
SRIMCA
Contract reviewContract review
Design ControlDesign Control
Document and data Document and data controlcontrol
PurchasingPurchasing
and traceabilityand traceability
Process controlProcess control
Inspection and testingInspection and testing
Control of inspection, Control of inspection, measuring and test measuring and test equipmentequipment
ISO 9001 (cont'd)..ISO 9001 (cont'd)..
Inspection and test Inspection and test statusstatus
Control of nonControl of non--confirming productconfirming product
Control of quality Control of quality recordsrecords
Internal quality auditsInternal quality audits
TrainingTraining
SRIMCA
confirming productconfirming product
Corrective and Corrective and preventive actionpreventive action
Handling, storage, Handling, storage, packaging, packaging, preservation and preservation and deliverydelivery
TrainingTraining
ServicingServicing
Statistical techniquesStatistical techniques
Summary-Summary-
SQA must be applied at each stepSQA must be applied at each step
SQA might be complexSQA might be complex
Software reviews are important SQA activitiesSoftware reviews are important SQA activities
SRIMCA
Software reviews are important SQA activitiesSoftware reviews are important SQA activities
Statistical SQA helps improve product quality Statistical SQA helps improve product quality and software processand software process
Software Safety is essential for critical systems Software Safety is essential for critical systems
ISO 9001 standardizes the SQA activitiesISO 9001 standardizes the SQA activities
Software ConfigurationManagement (SCM)Software ConfigurationManagement (SCM)
OverviewOverviewWhat is SCM?What is SCM?
What are the processes of SCM?What are the processes of SCM?What are the processes of SCM?What are the processes of SCM?
How does each process do?How does each process do?
SummarySummary
Software ConfigurationsSoftware Configurations
Software configuration Software configuration ---- the outputthe output Computer programs (source and executables)Computer programs (source and executables)
DocumentsDocuments DocumentsDocuments
DataData
Software Configuration Management (SCM)Software Configuration Management (SCM) The art of identifying, organizing and controlling The art of identifying, organizing and controlling
modifications to the software being builtmodifications to the software being built
Why Do We Need SCM?Why Do We Need SCM?
First Law of System EngineeringFirst Law of System Engineering No matter where you are in the system life No matter where you are in the system life
cycle, the system will change and the desire to cycle, the system will change and the desire to change it will persist throughout the life cyclechange it will persist throughout the life cyclechange it will persist throughout the life cyclechange it will persist throughout the life cycle
Sources of ChangeSources of Change New business or market conditions New business or market conditions new customer needsnew customer needs Organization and/or business downsizingOrganization and/or business downsizing Budgetary or scheduling constraintsBudgetary or scheduling constraints
Baseline Concept
IEEE defines a baseline as:IEEE defines a baseline as: A specification or product that has been formally A specification or product that has been formally
reviewed and agreed upon, that thereafter serve as the reviewed and agreed upon, that thereafter serve as the basis for further development, and that can be changed basis for further development, and that can be changed basis for further development, and that can be changed basis for further development, and that can be changed only through formal change control proceduresonly through formal change control procedures
A baseline is a milestone in the development of A baseline is a milestone in the development of software that marked the delivery of one or more software that marked the delivery of one or more software configuration itemssoftware configuration items
Common Baselines
System engineering System engineering
Requirement analysisRequirement analysis
Software designSoftware design
System specification
Software requirement specificationSoftware designSoftware design
CodingCoding
TestingTesting
ReleaseRelease
specificationDesign specification
Source code
Test plans/Procedures/Data
Operational system
Software Configuration Item (SCI)
Information created as part of SE processInformation created as part of SE process
SCIs used as target in SCM:SCIs used as target in SCM:
System specificationSystem specification System specificationSystem specification
Software project planSoftware project plan
Software requirements specificationSoftware requirements specification
Preliminary user manualPreliminary user manual
Design specificationDesign specification
Source code listingSource code listing
SCI (Cont’d)
Test specificationTest specification
Operation and installation manualsOperation and installation manuals
Executable programExecutable program
Database descriptionDatabase description Database descriptionDatabase description
AsAs--built user manualbuilt user manual
Maintenance documentsMaintenance documents
Standards and procedures for SEStandards and procedures for SE
SCI Modification Process
SCM Process
IdentificationIdentification
Version controlVersion control
Change controlChange control Change controlChange control
Configuration auditing Configuration auditing
Status reportingStatus reporting
Object identification in SW configuration
SCI can be named and organized using OO SCI can be named and organized using OO approachapproach
Two types of objects:Two types of objects: Two types of objects:Two types of objects: basic objectbasic object: ‘unit of text’ created during : ‘unit of text’ created during
analysis, design, coding, or testing.analysis, design, coding, or testing.
Aggregated objectsAggregated objects: a collect of basic objects: a collect of basic objects
Object identification in SWconfiguration (cont’d)
Features of objects:Features of objects: name: a character stringname: a character string
description: a list of data items to identify the SCI description: a list of data items to identify the SCI description: a list of data items to identify the SCI description: a list of data items to identify the SCI type and a project id, version information, etc.type and a project id, version information, etc.
resources: entity that are provided, processed, resources: entity that are provided, processed, referenced by the objectreferenced by the object
Realization: a pointer to ‘Realization: a pointer to ‘unit of text’unit of text’ for a basic for a basic object or object or nullnull for an aggregate objectfor an aggregate object
Object identification in SWconfiguration (cont’d)
Relationships between objectsRelationships between objects partpart--of: a hierarchical relationshipof: a hierarchical relationship
interrelated: a crossinterrelated: a cross--structural relationshipstructural relationship interrelated: a crossinterrelated: a cross--structural relationshipstructural relationship
Object identification methodsObject identification methods evolution graphevolution graph
automated SCM toolsautomated SCM tools
module interconnection languagemodule interconnection language
Configuration ObjectsConfiguration Objects
Evolution Graph
obj1.2
obj1.4
obj1.3
obj1.0
obj1.1 1.2
obj2.0
obj1.1.1
obj1.1.2
obj2.1
1.0 1.1
Version Control
Some of the issuesSome of the issuesWhen an executable is built, the versions of its When an executable is built, the versions of its
constituents must be consistent.constituents must be consistent. If A depends upon B and B is recompiled, A may If A depends upon B and B is recompiled, A may If A depends upon B and B is recompiled, A may If A depends upon B and B is recompiled, A may
also need to be recompiled.also need to be recompiled.What if multiple people need to modify same SCI?What if multiple people need to modify same SCI? Need to know what version different customers haveNeed to know what version different customers have How do you keep track of 100’s or 1000’s of How do you keep track of 100’s or 1000’s of
modules?modules?
Version ControlVersion Control
Evolution graph to represent different Evolution graph to represent different versionsversions
Uses an object pool representing components, Uses an object pool representing components, Uses an object pool representing components, Uses an object pool representing components, variants and versions, and their relationshipvariants and versions, and their relationship
RCS (Revision Control System) is common RCS (Revision Control System) is common tool.tool. Use for documentation as well as code Use for documentation as well as code
development.development.
Version Control SupportVersion Control Support
At the language level (in Ada):At the language level (in Ada):
Spec ASpec A Spec BSpec B
With B;With B;
If only body of B changes, no change to AIf only body of B changes, no change to A
If spec of B changes, A must be recompiledIf spec of B changes, A must be recompiled
Spec ASpec A
Body ABody A
Spec BSpec B
Body BBody B
Change Control
Change request from userChange request from user
Developer evaluatesDeveloper evaluates
Change report is generatedChange report is generated
Change control authority makes decisionChange control authority makes decision
Request is queued, persons are assigned
“Check out” SCI(s)
Change request is denied
User is informed
Change Control (cont’d)
Make the change/review changeMake the change/review change
‘Check in’ changed SCIs‘Check in’ changed SCIs
Establish a baseline for testingEstablish a baseline for testingEstablish a baseline for testingEstablish a baseline for testing
Do SQA and ‘promote’ changes for inclusion in next Do SQA and ‘promote’ changes for inclusion in next releaserelease
Rebuild appropriate versionRebuild appropriate version
Audit the SCI changes/ include changes in new versionAudit the SCI changes/ include changes in new version
Release the new versionRelease the new version
Access and Synchronization Control
Configuration Audit
Two approaches can be used to ensure proper Two approaches can be used to ensure proper implementation of change:implementation of change:
formal technical reviewformal technical review
software configuration auditsoftware configuration audit
CA assesses a configuration object for characteristics that CA assesses a configuration object for characteristics that are not generally not considered during revieware not generally not considered during review
CA generally checks:CA generally checks:
•SCM procedures followed•all related SCIs properly updated•change date and author specified
•Changes incorporated•FTR conducted•SE standards followed
Status Reporting
Event occurred Event occurred ---- An SCI received updated IDAn SCI received updated ID
people involvedpeople involved
Time happenedTime happened Time happenedTime happened
Effects on othersEffects on others
Generated on a regular basisGenerated on a regular basis
To improve communication among all partiesTo improve communication among all parties
Summary
SCM identifies, controls, audits and reports SCM identifies, controls, audits and reports modificationsmodifications
An object becomes a baseline once developed An object becomes a baseline once developed An object becomes a baseline once developed An object becomes a baseline once developed and reviewedand reviewed
Version control is the set of procedures and Version control is the set of procedures and tools for managing the use of these objectstools for managing the use of these objects
SummarySummary
Change control is a procedure activity Change control is a procedure activity necessary to achieve quality and consistencynecessary to achieve quality and consistency
Configuration audit is an SQA activity to Configuration audit is an SQA activity to Configuration audit is an SQA activity to Configuration audit is an SQA activity to help ensure quality is maintainedhelp ensure quality is maintained
Reporting provides information for better Reporting provides information for better communicationcommunication
Software ConfigurationManagement (SCM)Software ConfigurationManagement (SCM)
OverviewOverviewWhat is SCM?What is SCM?
What are the processes of SCM?What are the processes of SCM?
Assistance - Changheng DuNovember 16, 1997
What are the processes of SCM?What are the processes of SCM?
How does each process do?How does each process do?
SummarySummary
Software ConfigurationsSoftware Configurations
Software configuration Software configuration ---- the outputthe output Computer programs (source and executables)Computer programs (source and executables)
DocumentsDocuments
Assistance - Changheng DuNovember 16, 1997
DocumentsDocuments
DataData
Software Configuration Management (SCM)Software Configuration Management (SCM) The art of identifying, organizing and controlling The art of identifying, organizing and controlling
modifications to the software being builtmodifications to the software being built
Why Do We Need SCM?Why Do We Need SCM?
First Law of System EngineeringFirst Law of System Engineering No matter where you are in the system life No matter where you are in the system life
cycle, the system will change and the desire to cycle, the system will change and the desire to change it will persist throughout the life cyclechange it will persist throughout the life cycle
Assistance - Changheng DuNovember 16, 1997
change it will persist throughout the life cyclechange it will persist throughout the life cycle
Sources of ChangeSources of Change New business or market conditions New business or market conditions new customer needsnew customer needs Organization and/or business downsizingOrganization and/or business downsizing Budgetary or scheduling constraintsBudgetary or scheduling constraints
Baseline Concept
IEEE defines a baseline as:IEEE defines a baseline as: A specification or product that has been formally A specification or product that has been formally
reviewed and agreed upon, that thereafter serve as the reviewed and agreed upon, that thereafter serve as the basis for further development, and that can be changed basis for further development, and that can be changed
Assistance - Changheng DuNovember 16, 1997
basis for further development, and that can be changed basis for further development, and that can be changed only through formal change control proceduresonly through formal change control procedures
A baseline is a milestone in the development of A baseline is a milestone in the development of software that marked the delivery of one or more software that marked the delivery of one or more software configuration itemssoftware configuration items
Common Baselines
System engineering System engineering
Requirement analysisRequirement analysis
Software designSoftware design
System specification
Software requirement specification
Assistance - Changheng DuNovember 16, 1997
Software designSoftware design
CodingCoding
TestingTesting
ReleaseRelease
specificationDesign specification
Source code
Test plans/Procedures/Data
Operational system
Software Configuration Item (SCI)
Information created as part of SE processInformation created as part of SE process
SCIs used as target in SCM:SCIs used as target in SCM:
System specificationSystem specification
Assistance - Changheng DuNovember 16, 1997
System specificationSystem specification
Software project planSoftware project plan
Software requirements specificationSoftware requirements specification
Preliminary user manualPreliminary user manual
Design specificationDesign specification
Source code listingSource code listing
SCI (Cont’d)
Test specificationTest specification
Operation and installation manualsOperation and installation manuals
Executable programExecutable program
Database descriptionDatabase description
Assistance - Changheng DuNovember 16, 1997
Database descriptionDatabase description
AsAs--built user manualbuilt user manual
Maintenance documentsMaintenance documents
Standards and procedures for SEStandards and procedures for SE
SCI Modification Process
Assistance - Changheng DuNovember 16, 1997
SCM Process
IdentificationIdentification
Version controlVersion control
Change controlChange control
Assistance - Changheng DuNovember 16, 1997
Change controlChange control
Configuration auditing Configuration auditing
Status reportingStatus reporting
Object identification in SW configuration
SCI can be named and organized using OO SCI can be named and organized using OO approachapproach
Two types of objects:Two types of objects:
Assistance - Changheng DuNovember 16, 1997
Two types of objects:Two types of objects: basic objectbasic object: ‘unit of text’ created during : ‘unit of text’ created during
analysis, design, coding, or testing.analysis, design, coding, or testing.
Aggregated objectsAggregated objects: a collect of basic objects: a collect of basic objects
Object identification in SWconfiguration (cont’d)
Features of objects:Features of objects: name: a character stringname: a character string
description: a list of data items to identify the SCI description: a list of data items to identify the SCI
Assistance - Changheng DuNovember 16, 1997
description: a list of data items to identify the SCI description: a list of data items to identify the SCI type and a project id, version information, etc.type and a project id, version information, etc.
resources: entity that are provided, processed, resources: entity that are provided, processed, referenced by the objectreferenced by the object
Realization: a pointer to ‘Realization: a pointer to ‘unit of text’unit of text’ for a basic for a basic object or object or nullnull for an aggregate objectfor an aggregate object
Object identification in SWconfiguration (cont’d)
Relationships between objectsRelationships between objects partpart--of: a hierarchical relationshipof: a hierarchical relationship
interrelated: a crossinterrelated: a cross--structural relationshipstructural relationship
Assistance - Changheng DuNovember 16, 1997
interrelated: a crossinterrelated: a cross--structural relationshipstructural relationship
Object identification methodsObject identification methods evolution graphevolution graph
automated SCM toolsautomated SCM tools
module interconnection languagemodule interconnection language
Configuration ObjectsConfiguration Objects
Assistance - Changheng DuNovember 16, 1997
Evolution Graph
obj1.2
obj1.4
obj1.3
obj1.0
obj1.1
Assistance - Changheng DuNovember 16, 1997
1.2obj2.0
obj1.1.1
obj1.1.2
obj2.1
1.0 1.1
Version Control
Some of the issuesSome of the issuesWhen an executable is built, the versions of its When an executable is built, the versions of its
constituents must be consistent.constituents must be consistent. If A depends upon B and B is recompiled, A may If A depends upon B and B is recompiled, A may
Assistance - Changheng DuNovember 16, 1997
If A depends upon B and B is recompiled, A may If A depends upon B and B is recompiled, A may also need to be recompiled.also need to be recompiled.
What if multiple people need to modify same SCI?What if multiple people need to modify same SCI? Need to know what version different customers haveNeed to know what version different customers have How do you keep track of 100’s or 1000’s of How do you keep track of 100’s or 1000’s of
modules?modules?
Version ControlVersion Control
Evolution graph to represent different Evolution graph to represent different versionsversions
Uses an object pool representing components, Uses an object pool representing components,
Assistance - Changheng DuNovember 16, 1997
Uses an object pool representing components, Uses an object pool representing components, variants and versions, and their relationshipvariants and versions, and their relationship
RCS (Revision Control System) is common RCS (Revision Control System) is common tool.tool. Use for documentation as well as code Use for documentation as well as code
development.development.
Version Control SupportVersion Control Support
At the language level (in Ada):At the language level (in Ada):
Spec ASpec A Spec BSpec B
With B;With B;
Assistance - Changheng DuNovember 16, 1997
If only body of B changes, no change to AIf only body of B changes, no change to A
If spec of B changes, A must be recompiledIf spec of B changes, A must be recompiled
Spec ASpec A
Body ABody A
Spec BSpec B
Body BBody B
Change Control
Change request from userChange request from user
Developer evaluatesDeveloper evaluates
Change report is generatedChange report is generated
Assistance - Changheng DuNovember 16, 1997
Change control authority makes decisionChange control authority makes decision
Request is queued, persons are assigned
“Check out” SCI(s)
Change request is denied
User is informed
Change Control (cont’d)
Make the change/review changeMake the change/review change
‘Check in’ changed SCIs‘Check in’ changed SCIs
Establish a baseline for testingEstablish a baseline for testing
Assistance - Changheng DuNovember 16, 1997
Establish a baseline for testingEstablish a baseline for testing
Do SQA and ‘promote’ changes for inclusion in next Do SQA and ‘promote’ changes for inclusion in next releaserelease
Rebuild appropriate versionRebuild appropriate version
Audit the SCI changes/ include changes in new versionAudit the SCI changes/ include changes in new version
Release the new versionRelease the new version
Access and Synchronization Control
Assistance - Changheng DuNovember 16, 1997
Configuration Audit
Two approaches can be used to ensure proper Two approaches can be used to ensure proper implementation of change:implementation of change:
formal technical review (FTR)formal technical review (FTR)
software configuration auditsoftware configuration audit
Assistance - Changheng DuNovember 16, 1997
CA assesses a configuration object for characteristics that CA assesses a configuration object for characteristics that are not generally not considered during revieware not generally not considered during review
CA generally checks:CA generally checks:
•SCM procedures followed•all related SCIs properly updated•change date and author specified
•Changes incorporated•FTR conducted•SE standards followed
Status Reporting
Event occurred Event occurred ---- An SCI received updated IDAn SCI received updated ID
people involvedpeople involved
Time happenedTime happened
Assistance - Changheng DuNovember 16, 1997
Time happenedTime happened
Effects on othersEffects on others
Generated on a regular basisGenerated on a regular basis
To improve communication among all partiesTo improve communication among all parties
Summary
SCM identifies, controls, audits and reports SCM identifies, controls, audits and reports modificationsmodifications
An object becomes a baseline once developed An object becomes a baseline once developed
Assistance - Changheng DuNovember 16, 1997
An object becomes a baseline once developed An object becomes a baseline once developed and reviewedand reviewed
Version control is the set of procedures and Version control is the set of procedures and tools for managing the use of these objectstools for managing the use of these objects
SummarySummary
Change control is a procedure activity Change control is a procedure activity necessary to achieve quality and consistencynecessary to achieve quality and consistency
Configuration audit is an SQA activity to Configuration audit is an SQA activity to
Assistance - Changheng DuNovember 16, 1997
Configuration audit is an SQA activity to Configuration audit is an SQA activity to help ensure quality is maintainedhelp ensure quality is maintained
Reporting provides information for better Reporting provides information for better communicationcommunication
Systems EngineeringSystems Engineering
SystemSystem A set or arrangement of things so related as to A set or arrangement of things so related as to
form a unity or organic whole.form a unity or organic whole.A set of facts, principles, rules, etc., classified A set of facts, principles, rules, etc., classified
Assistance - Eric ChristensenJanuary 31, 1999
A set of facts, principles, rules, etc., classified A set of facts, principles, rules, etc., classified and arranged in an orderly form so as to show a and arranged in an orderly form so as to show a logical plan linking the various parts.logical plan linking the various parts.
A method or plan of classification or A method or plan of classification or arrangement.arrangement.
An established way of doing something; An established way of doing something; method; procedure.method; procedure.
Definition: A set or arrangement of Definition: A set or arrangement of elements that are organized to accomplish elements that are organized to accomplish some presome pre--defined goal by processing defined goal by processing information.information.
Computer-Based Systems
Assistance - Eric ChristensenJanuary 31, 1999
information.information. ElementsElements SoftwareSoftware HardwareHardware PeoplePeople DatabaseDatabase DocumentationDocumentation ProceduresProcedures
System of Systems -- ExampleSystem of Systems -- Example
Assistance - Eric ChristensenJanuary 31, 1999
The System EngineeringHierarchy
A hierarchy of views are necessary, for A hierarchy of views are necessary, for example,example, World ViewWorld View
Assistance - Eric ChristensenJanuary 31, 1999
World ViewWorld View
Domain ViewDomain View
Element viewElement view
Detailed ViewDetailed View
Typical HierarchyTypical Hierarchy
Assistance - Eric ChristensenJanuary 31, 1999
System Modeling
Define the processes that define the needs of Define the processes that define the needs of the view under considerationthe view under consideration
Represent the behavior of the processes and the Represent the behavior of the processes and the assumptions on which the behavior is basedassumptions on which the behavior is based
Assistance - Eric ChristensenJanuary 31, 1999
assumptions on which the behavior is basedassumptions on which the behavior is based Explicitly define all inputs and outputs to each Explicitly define all inputs and outputs to each
componentcomponent Define the transformation between inputs and Define the transformation between inputs and
outputs of each componentoutputs of each component Represent all linkages (interfaces) Represent all linkages (interfaces)
Critical Factors
It is absolutely essential that the following It is absolutely essential that the following be spelled out completely and in detailbe spelled out completely and in detail AssumptionsAssumptions
Assistance - Eric ChristensenJanuary 31, 1999
SimplificationsSimplifications LimitationsLimitations ConstraintsConstraints PreferencesPreferences
Changes in these is a principal contributor Changes in these is a principal contributor to software changeto software change
Information Engineering
Architecture Architecture ---- another overused wordanother overused word A set of component types together with a set of A set of component types together with a set of
principles and guidelines for their interconnection.principles and guidelines for their interconnection.
Assistance - Eric ChristensenJanuary 31, 1999
principles and guidelines for their interconnection.principles and guidelines for their interconnection.
Also used to refer to the structure of Also used to refer to the structure of aa system.system.
One classification of architecturesOne classification of architectures data architecturedata architecture
applications architectureapplications architecture
technology infrastructuretechnology infrastructure
Information Engineering ActivitiesInformation Engineering Activities
Another set of terms or phases of activityAnother set of terms or phases of activity Information strategy planning(isp)Information strategy planning(isp)
Business area analysis(baa)Business area analysis(baa)
Assistance - Eric ChristensenJanuary 31, 1999
Business area analysis(baa)Business area analysis(baa)
Business system design(bsd)Business system design(bsd)
Construction and integration(C&I)Construction and integration(C&I)
A Diagrammatic ViewA Diagrammatic View
Assistance - Eric ChristensenJanuary 31, 1999
Product Engineering
Develop support infrastructureDevelop support infrastructure Develop systems view of componentsDevelop systems view of components Systems analysisSystems analysis
allocate functions and behaviors (given allocate functions and behaviors (given
Assistance - Eric ChristensenJanuary 31, 1999
allocate functions and behaviors (given allocate functions and behaviors (given requirements)requirements)
determine interfacesdetermine interfaces Component engineeringComponent engineering Element & Detailed viewsElement & Detailed views Analysis & design modelingAnalysis & design modeling Construction & integrationConstruction & integration
A Diagrammatic ViewA Diagrammatic View
Assistance - Eric ChristensenJanuary 31, 1999
Information Strategy Planning
Define strategic business objectives and goalsDefine strategic business objectives and goals
Isolate the critical success factors that will Isolate the critical success factors that will enable the business to achieve goalsenable the business to achieve goals
Assistance - Eric ChristensenJanuary 31, 1999
enable the business to achieve goalsenable the business to achieve goals
Analyze the impact of technology and Analyze the impact of technology and automation on goals and objectivesautomation on goals and objectives
Analyze existing information to determine its Analyze existing information to determine its role in achieving goals and objectivesrole in achieving goals and objectives
Create a businessCreate a business--level data modellevel data model
Information Strategy Planning
Enterprise Modeling Enterprise Modeling ---- a 3a 3--D viewD view Organizational structures and functionsOrganizational structures and functions
Decomposes business functions to isolate Decomposes business functions to isolate
Assistance - Eric ChristensenJanuary 31, 1999
Decomposes business functions to isolate Decomposes business functions to isolate processes that make function happenprocesses that make function happen
Relate objectives, goals, and CSFs to the Relate objectives, goals, and CSFs to the organization and its functionsorganization and its functions
It is increasingly important that the various It is increasingly important that the various functions be interoperablefunctions be interoperable
Typical Organizational ChartTypical Organizational Chart
Assistance - Eric ChristensenJanuary 31, 1999
Information Strategy Planning
BusinessBusiness--Level Data ModelingLevel Data Modeling focuses on the data objects required to achieve focuses on the data objects required to achieve
the business functionsthe business functions identifies relationships between customers, identifies relationships between customers,
Assistance - Eric ChristensenJanuary 31, 1999
identifies relationships between customers, identifies relationships between customers, products, salespersons, etc.products, salespersons, etc.
Culmination Culmination -- a series of cross reference a series of cross reference matrices that establish the relationship matrices that establish the relationship between the organization, business between the organization, business objectives and goals, business functions, objectives and goals, business functions, and data objects.and data objects.
Typical Relationship AmongObjectsTypical Relationship AmongObjects
Assistance - Eric ChristensenJanuary 31, 1999
Business Area Analysis
Establishes a detailed framework for Establishes a detailed framework for building an informationbuilding an information--based enterprisebased enterprise
ModelsModels
Assistance - Eric ChristensenJanuary 31, 1999
ModelsModels data modelsdata models
process flow modelsprocess flow models
process decomposition diagramsprocess decomposition diagrams
crosscross--reference matricesreference matrices
Domain ViewDomain View
Business Area AnalysisBusiness Area Analysis
Data ModelingData Modeling Identify data object types (or classes)Identify data object types (or classes)
Determine essential attributesDetermine essential attributes
Assistance - Eric ChristensenJanuary 31, 1999
Determine essential attributesDetermine essential attributes
Determine other objects with which the object Determine other objects with which the object has relationshas relations
Determine operations which will need to be Determine operations which will need to be performed on the objectperformed on the object
Business Area Analysis
Process Modeling Process Modeling -- describes the business describes the business functions within a business areafunctions within a business area
Information Flow Modeling Information Flow Modeling -- integrates integrates
Assistance - Eric ChristensenJanuary 31, 1999
Information Flow Modeling Information Flow Modeling -- integrates integrates process and data models to show how process and data models to show how information flows through a business areainformation flows through a business area
Typical Process Flow ModelTypical Process Flow Model
Assistance - Eric ChristensenJanuary 31, 1999
With Information FlowWith Information Flow
Assistance - Eric ChristensenJanuary 31, 1999
Product Engineering
Problem solving activity where desired Problem solving activity where desired product data, function, and behavior are product data, function, and behavior are analyzed and allocated to individual analyzed and allocated to individual
Assistance - Eric ChristensenJanuary 31, 1999
analyzed and allocated to individual analyzed and allocated to individual componentscomponents
Major activitiesMajor activities Support infrastructureSupport infrastructure Bound function, performance, constraints, and Bound function, performance, constraints, and
interfacesinterfaces Develop alternative allocationsDevelop alternative allocations
Product Engineering
TradeTrade--off Criteriaoff Criteria Project ConsiderationsProject Considerations
Business ConsiderationsBusiness Considerations
Assistance - Eric ChristensenJanuary 31, 1999
Business ConsiderationsBusiness Considerations
Technical AnalysisTechnical Analysis
Manufacturing EvaluationManufacturing Evaluation
Human IssuesHuman Issues
Environmental InterfacesEnvironmental Interfaces
Legal ConsiderationsLegal Considerations
System Analysis
Identification of NeedIdentification of Need
Feasibility Study Feasibility Study
Perform economic and technical analysesPerform economic and technical analyses
Assistance - Eric ChristensenJanuary 31, 1999
Perform economic and technical analysesPerform economic and technical analyses
Allocate functions to hardware, software, Allocate functions to hardware, software, people, databasepeople, database
Establish cost and schedule constraintsEstablish cost and schedule constraints
Create system definition Create system definition
Feasibility StudyFeasibility Study
Economic Economic -- costcost--benefit analysisbenefit analysis
Technical Technical -- development risk, resource development risk, resource availability, technologyavailability, technology
Assistance - Eric ChristensenJanuary 31, 1999
availability, technologyavailability, technology
Legal Legal -- definition of infringements or definition of infringements or violations from system developmentviolations from system development
Alternatives Alternatives -- evaluation of alternative evaluation of alternative approachesapproaches
Benefit AnalysisBenefit Analysis
Assistance - Eric ChristensenJanuary 31, 1999
Cost AnalysisCost Analysis
Assistance - Eric ChristensenJanuary 31, 1999
Modeling the SystemArchitecture
Architecture template Architecture template -- user interface, input, user interface, input, system function and control, output, system function and control, output, maintenance and selfmaintenance and self--testtest
Assistance - Eric ChristensenJanuary 31, 1999
Architecture context diagram Architecture context diagram -- establishes establishes the information boundary between the the information boundary between the system being implemented and the system being implemented and the environment in which it is to operateenvironment in which it is to operate
Architectural flow diagram Architectural flow diagram -- shows how shows how information flows between subsystemsinformation flows between subsystems
Architecture TemplateArchitecture Template
Assistance - Eric ChristensenJanuary 31, 1999
CLSS ExampleCLSS Example
Assistance - Eric ChristensenJanuary 31, 1999
Expanded ExampleExpanded Example
Assistance - Eric ChristensenJanuary 31, 1999
Building a HierarchyBuilding a Hierarchy
Assistance - Eric ChristensenJanuary 31, 1999
System Modeling and Simulation
Reactive Systems Reactive Systems -- realreal--time and embedded time and embedded systems systems ---- particularly difficult systems to particularly difficult systems to develop correctly.develop correctly.
Assistance - Eric ChristensenJanuary 31, 1999
develop correctly.develop correctly.
CASE tools CASE tools -- eliminate surprises when eliminate surprises when introducing a reactive systemintroducing a reactive system One can build models of the systems to be builtOne can build models of the systems to be built
One can “test drive” the model before building One can “test drive” the model before building itit
System Specification
Document that serves as a foundation for Document that serves as a foundation for hardware engineering, software hardware engineering, software engineering, data base engineering, and engineering, data base engineering, and
Assistance - Eric ChristensenJanuary 31, 1999
engineering, data base engineering, and engineering, data base engineering, and human engineeringhuman engineering
Describes function and performance of Describes function and performance of computercomputer--based system as well as based system as well as constraintsconstraints
An essential element required for systems An essential element required for systems engineeringengineering
AnalysisConcepts and Principle
Pressman – Chap. 11 11August 2003
Requirement AnalysisRequirement Analysis
Results in specs. of s/w operational Results in specs. of s/w operational characteristics (function, data and behavior)characteristics (function, data and behavior)
Indicate s/w interface with other system Indicate s/w interface with other system
Pressman – Chap. 11 22August 2003
Indicate s/w interface with other system Indicate s/w interface with other system elementselements
Establish constraints that s/w must meetEstablish constraints that s/w must meet
Requirement AnalysisRequirement Analysis
RA allows the analyst to refine the s/w RA allows the analyst to refine the s/w allocation and build models of the data, allocation and build models of the data, functional and behavioral domainsfunctional and behavioral domainsIt provides the analyst with a representation It provides the analyst with a representation
Pressman – Chap. 11 33August 2003
It provides the analyst with a representation It provides the analyst with a representation of info., function & behavior that can be of info., function & behavior that can be translated into data, architectural and translated into data, architectural and component level designcomponent level design
Means to access quality once s/w is builtMeans to access quality once s/w is built
Requirements AnalysisRequirements Analysis
Five ActivitiesFive Activities Problem recognitionProblem recognition
Evaluation and synthesisEvaluation and synthesis
Pressman – Chap. 11 44August 2003
Evaluation and synthesisEvaluation and synthesis
ModelingModeling
SpecificationSpecification
ReviewReview
Problem RecognitionProblem Recognition
Some problems to overcomeSome problems to overcome Understanding what the customer really wantsUnderstanding what the customer really wants
Getting inside the customers requirementsGetting inside the customers requirements
Pressman – Chap. 11 55August 2003
Getting inside the customers requirementsGetting inside the customers requirements
“us“us--them” paradigm rather than “we”them” paradigm rather than “we”
Federal Acquisition Regulations (FARs)Federal Acquisition Regulations (FARs) Require customer to prepare specificationsRequire customer to prepare specifications
Limit discussion between customer and supplier Limit discussion between customer and supplier during bidding process.during bidding process.
Techniques for RequirementsAcquisitionTechniques for RequirementsAcquisition
Facilitated Application Specification Facilitated Application Specification Techniques (FAST)Techniques (FAST) Meeting (often at neutral site)Meeting (often at neutral site)
Pressman – Chap. 11 66August 2003
Establish meeting rulesEstablish meeting rules
Agenda to cover important pointsAgenda to cover important points
A facilitator A facilitator ---- best if not customer or supplierbest if not customer or supplier
Definition mechanismDefinition mechanism
Understand goal Understand goal ---- to identify problem, to identify problem, specify a specify a preliminarypreliminary set of requirementsset of requirements
Techniques for RequirementsAcquisitionTechniques for RequirementsAcquisition
Facilitated Application Specification Facilitated Application Specification Techniques (FAST)Techniques (FAST) Refinement with subgroupsRefinement with subgroups
Pressman – Chap. 11 77August 2003
Refinement with subgroupsRefinement with subgroups
Techniques for RequirementsAcquisitionTechniques for RequirementsAcquisition
Quality Function DeploymentQuality Function Deployment Normal RequirementsNormal Requirements
What will make customer happyWhat will make customer happy
Pressman – Chap. 11 88August 2003
What will make customer happyWhat will make customer happy
Expected RequirementsExpected Requirements Unstated requirements that are so “obvious” that Unstated requirements that are so “obvious” that
they need not be statedthey need not be stated
UnexpectedUnexpected RequirementsRequirements Enhancements beyond customer requirementsEnhancements beyond customer requirements
Analysis PrinciplesAnalysis Principles
First Operational Analysis principle requires First Operational Analysis principle requires examination of the info. Domain and creation examination of the info. Domain and creation of data modelof data model
Second & Third operational analysis principle Second & Third operational analysis principle
Pressman – Chap. 11 99August 2003
Second & Third operational analysis principle Second & Third operational analysis principle require that we build models of function and require that we build models of function and behaviorbehavior
Fourth Op. analysis principle suggests that the Fourth Op. analysis principle suggests that the info., functional and behavioral domains of s/w info., functional and behavioral domains of s/w can be partitioned.can be partitioned.
Analysis PrinciplesAnalysis Principles
Basic prinicplesBasic prinicples Represent and understand information domainRepresent and understand information domain
Define functions that must be performedDefine functions that must be performed
Pressman – Chap. 11 1010August 2003
Define functions that must be performedDefine functions that must be performed
Represent behavior of software (to external Represent behavior of software (to external events)events)
Partition information, function and behavior Partition information, function and behavior models hierarchicallymodels hierarchically
Move from essential information to Move from essential information to implementation detailimplementation detail
Guiding PrinciplesGuiding Principles
Understand problem before analysisUnderstand problem before analysis
Develop prototypes for HCIDevelop prototypes for HCI
Pressman – Chap. 11 1111August 2003
Develop prototypes for HCIDevelop prototypes for HCI
Record rationale for every requirementRecord rationale for every requirement
Develop multiple views of each requirementDevelop multiple views of each requirement Data, functional and behavioral modelsData, functional and behavioral models
Determine priorities of requirementsDetermine priorities of requirements
Eliminate ambiguityEliminate ambiguity
Information DomainInformation Domain
Software processes dataSoftware processes data Payroll processingPayroll processing
Computing control signals for radar systemComputing control signals for radar system
Pressman – Chap. 11 1212August 2003
Computing control signals for radar systemComputing control signals for radar system
Software also processes Software also processes eventsevents Timer went off Timer went off ---- time to calculate a controltime to calculate a control
Sensor turned on Sensor turned on ---- indicates intruderindicates intruder
Heart rate monitor exceeded threshold Heart rate monitor exceeded threshold ----indicates fibrillation.indicates fibrillation.
Information DomainInformation Domain
Three views of informationThree views of information Information contentInformation content
Information flowInformation flow
Pressman – Chap. 11 1313August 2003
Information flowInformation flow
Information structureInformation structure
Process ModelsProcess Models Functional Functional ---- possibly show block diagramspossibly show block diagrams
Behavioral Behavioral ---- define states and transitionsdefine states and transitions
Try to show models diagrammatically Try to show models diagrammatically
PartitioningPartitioning
Pressman – Chap. 11 1414August 2003
PrototypingPrototyping
Highly desirableHighly desirable Clarify requirementsClarify requirements
Identify missing requirementsIdentify missing requirements
Pressman – Chap. 11 1515August 2003
Identify missing requirementsIdentify missing requirements
Help define user interfacesHelp define user interfaces
Types of prototypesTypes of prototypes ThrowawayThrowaway
Evolutionary Evolutionary ---- a potential problem is that a potential problem is that intended throwaways become evolutionaryintended throwaways become evolutionary
PrototypingPrototyping
Important questions underlying prototypingImportant questions underlying prototyping Customer commitment Customer commitment ---- must be involvedmust be involved
Must commit resources for evaluationMust commit resources for evaluation
Must be capable of making requirements decisions Must be capable of making requirements decisions
Pressman – Chap. 11 1616August 2003
Must be capable of making requirements decisions Must be capable of making requirements decisions in timely mannerin timely manner
PrototypingPrototyping
Methods and toolsMethods and tools Fourth Generation Techniques Fourth Generation Techniques ---- program program
application generatorsapplication generators
Pressman – Chap. 11 1717August 2003
application generatorsapplication generators
Reusable Software Components Reusable Software Components ---- build from build from existing componentsexisting components
Formal Specification and Prototyping Formal Specification and Prototyping EnvironmentsEnvironments Translate specifications into codeTranslate specifications into code
SpecificationsSpecifications
Separate Function from ImplementationSeparate Function from Implementation
Develop ModelDevelop Model
Define EnvironmentDefine Environment
Pressman – Chap. 11 1818August 2003
Define EnvironmentDefine Environment
Define how software interacts with environ.Define how software interacts with environ.
Create Cognitive model Create Cognitive model ---- how world sees ithow world sees it
Recognize specs as imperfectRecognize specs as imperfect
Flexibility Flexibility ---- be amenable to changebe amenable to change
RepresentationRepresentation
Format and content relevant to problemFormat and content relevant to problem
Information should be nestedInformation should be nested Multiple layers or levelsMultiple layers or levels
Pressman – Chap. 11 1919August 2003
Multiple layers or levelsMultiple layers or levels
Diagrams should be consistent in useDiagrams should be consistent in use
Representations should be revisableRepresentations should be revisable
Requirements SpecificationsDocumentationRequirements SpecificationsDocumentation
Pressman – Chap. 11 2020August 2003
Specifications ReviewSpecifications Review
Macroscopic LevelMacroscopic Level View from the topView from the top Goals met ?Goals met ?
Alternatives explored ?Alternatives explored ?
Pressman – Chap. 11 2121August 2003
Alternatives explored ?Alternatives explored ? Customer satisfied ?Customer satisfied ?
SpecificsSpecifics Avoid persuasive, intimidating connectorsAvoid persuasive, intimidating connectors Ambiguous wordsAmbiguous words Vague languageVague language Watch for unstated assumptionsWatch for unstated assumptions
Analysis ModelingAnalysis Modeling
Two primary methods todayTwo primary methods today Structured AnalysisStructured Analysis
ObjectObject--oriented analysisoriented analysis
August 20031
ObjectObject--oriented analysisoriented analysis
Some important considerationsSome important considerations Analysis products must be maintainableAnalysis products must be maintainable
Effective partitioning is essentialEffective partitioning is essential
Graphics should be used whenever possibleGraphics should be used whenever possible
Distinguish between logical and implementationDistinguish between logical and implementation
Structured AnalysisStructured Analysis
Elements of AnalysisElements of Analysis Describe what customer requiresDescribe what customer requires
Establish basis for creating software designEstablish basis for creating software design
August 20032
Establish basis for creating software designEstablish basis for creating software design
Define requirements Define requirements that can be validatedthat can be validated
Graphical View of ModelGraphical View of Model
Entity
Relationship
Data Flow
Diagram
August 20033
Data
Dictionary
Relationship
Diagram
Diagram
State Transition
Diagram
( ERD)
(DFD)
(STD)
Data ModelingData Modeling
The model consists ofThe model consists of Data object [types]Data object [types]
AttributesAttributes
August 20034
AttributesAttributes
RelationshipsRelationships
Data objectsData objects A representation of almost any composite A representation of almost any composite
information that must be understood by information that must be understood by softwaresoftware..
Data ModelingData Modeling
AttributesAttributes Attributes define the properties of a data object Attributes define the properties of a data object
and take on one of three different characteristics:and take on one of three different characteristics: Name an instance of the data objectName an instance of the data object
Describe the instanceDescribe the instance
August 20035
Describe the instanceDescribe the instance Make reference to another instanceMake reference to another instance
Make Model ID# Body type Color Owner
Ford Taurus Q12A45.. Sedan Blue ABC
Lexus LS400 AB123... Sports White XYZ
Naming attributesDescriptiveattributes
Referentialattributes
Identifier
Data ModelingData Modeling
RelationshipsRelationships Defined pairwise Defined pairwise ---- many varietiesmany varieties
orders
August 20036
Book Bookstore
orders
displays
sells
returns
Cardinality and ModalityCardinality and Modality
CardinalityCardinality How many occurrences of object X are related How many occurrences of object X are related
to how many occurrences of object Yto how many occurrences of object Y
August 20037
to how many occurrences of object Yto how many occurrences of object Y OneOne--toto--one (1:1)one (1:1)
OneOne--toto--many (1:N)many (1:N)
ManyMany--toto--many (M:N)many (M:N)
ModalityModality =0 => optional relationship=0 => optional relationship
=1 => relationship must appear=1 => relationship must appear
ExampleExample
Customer Repair actionis provided with
August 20038
Customer Repair action
Mandatory: in order to havea repair action, we must havea customer
Optional: there may be a situationin which a repair action is not necessary
Entity Relation Diagrams (ERD)Entity Relation Diagrams (ERD)
Cornerstone of the data model Cornerstone of the data model ---- includesincludes data objects, data objects, attributes, attributes, relationships, andrelationships, and
various type indicatorsvarious type indicators
August 20039
various type indicatorsvarious type indicators
manufacturer carbuilds
ID# model body type engine transmission . . .Data Object Table
ExampleExample
August 200310
Data Object HierarchiesData Object Hierarchies
August 200311
Associating Data ObjectsAssociating Data Objects
August 200312
Functional ModelingFunctional Modeling
Entity
Relationship
Data Flow
Diagram
August 200313
Data
Dictionary
Relationship
Diagram
Diagram
State Transition
Diagram
( DFD )
Data Flow Diagrams (DFD)Data Flow Diagrams (DFD)
A graphical technique that depicts A graphical technique that depicts information flow and the transforms applied information flow and the transforms applied as data move from input to outputas data move from input to output
August 200314
as data move from input to outputas data move from input to output
NotNot the same as flow charts. Does not the same as flow charts. Does not show the logic of the transformationsshow the logic of the transformations
Can be used at any level of abstractionCan be used at any level of abstraction
General Information Flow ModelGeneral Information Flow Model
August 200315
Basic NotationBasic Notation
August 200316
Information Flow RefinementInformation Flow Refinement
AB
V X
F
f f2
August 200317
AB
V
W
X
Y
Z
X
Y
z z
z
x x
yy
Z
12
3
1
1
2
2
f
f
f
ff
f
f
f
f
f
f
f
1
2
3
4
5
6
7
41
42
43
44
45
Real Time ExtensionsReal Time Extensions
Fundamental issue Fundamental issue -- The time at which The time at which results are produced is a part of the results are produced is a part of the correctness of the computation.correctness of the computation.
Hatley/Pirbhai notationHatley/Pirbhai notation
August 200318
Hatley/Pirbhai notationHatley/Pirbhai notation
Ward/Mellor NotationWard/Mellor Notation
August 200319
ExampleExample
August 200320
ExampleExample
August 200321
Hatley and Pirbhai ExtensionsHatley and Pirbhai Extensions
Use separate Use separate data flow diagramdata flow diagram (DFD) and (DFD) and control flow diagramcontrol flow diagram (CFD)(CFD)
Data flow diagrams Data flow diagrams
August 200322
Data flow diagrams Data flow diagrams Used to represent data and the processes that Used to represent data and the processes that
manipulate itmanipulate it
Control flow diagrams Control flow diagrams Show how events flow among processes and Show how events flow among processes and
show those external events that cause various show those external events that cause various processes to be activatedprocesses to be activated
Relationship Between ModelsRelationship Between Models
August 200323
ExampleExample
August 200324
CFD for PhotocopierCFD for Photocopier
managecopying produce
user
paper feed status(jammed, empty)
start/stop
alarm
Copystatus
August 200325
readoperator
input
copying userdisplays
reloadpaper
performproblem
diagnosis
fullreprofault
Copy
Info
Reloadstatus
Problemtype
Behavioral ModelingBehavioral Modeling
Data Flow
August 200326
DataDictionary
Entity
Relationship
Diagram
Data Flow
Diagram
State Transition
Diagram ( STD )
State Transition DiagramsState Transition Diagrams
A State is any observable mode of behaviorA State is any observable mode of behavior e.g., reading commands, computing control, e.g., reading commands, computing control,
waiting for next time eventwaiting for next time event
August 200327
States represented as rectanglesStates represented as rectangles Arrows represent transitionsArrows represent transitions Value above arrow identifies event causing Value above arrow identifies event causing
transitiontransition Value below arrow indicates ensuring actionValue below arrow indicates ensuring action
State Transition DiagramState Transition Diagram
readingcommands
idle
invoke read-op-inputfull and start
invoke manage-coping
August 200328
making copiesreloading
paper
diagnosingproblem
jammedinvoke perform problem-diagnosis
emptyinvoke reload paper
not jammedinvoke read-op-input
fullinvoke read-op-input
copies doneinvoke read-op-input
Creating an ERDCreating an ERD
List entities that customer addressesList entities that customer addresses For each, determine the connectionsFor each, determine the connections For each connection, create one or more For each connection, create one or more
objectobject--relationship pairsrelationship pairs
August 200329
objectobject--relationship pairsrelationship pairs For each relationship, determine cardinality For each relationship, determine cardinality
and modalityand modality Define the attributes of each entityDefine the attributes of each entity Formalize and review ERDFormalize and review ERD IterateIterate
Home Security System ExampleHome Security System Example
Initial entitiesInitial entities Homeowner, control panel, sensors, security Homeowner, control panel, sensors, security
system and monitoring servicesystem and monitoring service
August 200330
system and monitoring servicesystem and monitoring service
Home Security System ExampleHome Security System Example
Relationships between sensor and security sys.Relationships between sensor and security sys. Security system monitors sensorSecurity system monitors sensor Security system enables/disables sensorSecurity system enables/disables sensor Security system tests sensorSecurity system tests sensor
August 200331
Security system tests sensorSecurity system tests sensor Security system programs sensorSecurity system programs sensor
Creating a Data Flow ModelCreating a Data Flow Model
First create level 0 diagramFirst create level 0 diagram Depict software system as single bubbleDepict software system as single bubble
Show primary inputs and outputsShow primary inputs and outputs
August 200332
Show primary inputs and outputsShow primary inputs and outputs
Identify processes, data objects, and data stores Identify processes, data objects, and data stores to be expanded at next levelto be expanded at next level
Label all arrows with meaningful namesLabel all arrows with meaningful names
Information flow continuity must be maintainedInformation flow continuity must be maintained
Refine only one bubble at a timeRefine only one bubble at a time
Home Security System ExampleHome Security System Example
August 200333
RefinementRefinement
Analyze textual description of bubbleAnalyze textual description of bubble verbs are often processesverbs are often processes
nouns are often external entities, data or nouns are often external entities, data or
August 200334
nouns are often external entities, data or nouns are often external entities, data or control objects or data storescontrol objects or data stores
ExamplesExamples Control panel is used to program and configure Control panel is used to program and configure
the systemthe system
Upon a sensor event, the software invokes an Upon a sensor event, the software invokes an alarmalarm
Home Security System ExampleHome Security System Example
August 200335
Home Security System ExampleHome Security System Example
August 200336
Creating Control Flow ModelsCreating Control Flow Models
Strip arrows from DFDStrip arrows from DFD Add event and control items. E.g., tryAdd event and control items. E.g., try
List all sensors read by the softwareList all sensors read by the software
August 200337
List all sensors read by the softwareList all sensors read by the software List all interrupt conditionsList all interrupt conditions List all operator actuated switchesList all operator actuated switches List all data conditionsList all data conditions Check nounCheck noun--verb parse for possible CSPEC I/Overb parse for possible CSPEC I/O Identify states, how each is reached and transitionsIdentify states, how each is reached and transitions Focus on possible omissionsFocus on possible omissions
Level 1 CFD for Safe-HomeLevel 1 CFD for Safe-Home
August 200338
Control SpecificationControl Specification
August 200339
Process Activation TableProcess Activation Table
August 200340
Process SpecificationsProcess Specifications
Describes all flow model processes at final Describes all flow model processes at final level of refinementlevel of refinement Narrative text,Narrative text,
August 200341
Narrative text,Narrative text,
Program design language descriptionProgram design language description
Mathematical equationsMathematical equations
TablesTables
DiagramsDiagrams
ChartsCharts
Data DictionaryData Dictionary
Entity Data Flow
August 200342
DataDictionary
Entity
Relationship
Diagram
Data Flow
Diagram
State Transition
Diagram
Data DictionaryData Dictionary
Why a data dictionary? Need an organized way Why a data dictionary? Need an organized way to represent data & control characteristicsto represent data & control characteristics
Usual contentsUsual contents
August 200343
Usual contentsUsual contents NameName AliasAlias Where and how usedWhere and how used Content description (of composite items)Content description (of composite items) Supplementary information, e.g., restrictions, Supplementary information, e.g., restrictions,
limitations, preset valueslimitations, preset values
ExampleExample
Name:Name: Shuttle positionShuttle position
Aliases:Aliases: PositionPosition--orientation vectororientation vector
Where used:Where used: Display of Shuttle on mapDisplay of Shuttle on map
August 200344
Where used:Where used: Display of Shuttle on mapDisplay of Shuttle on map
Content:Content: x, y, z position wrt to Earth’s x, y, z position wrt to Earth’s Center, roll, pitch, yawCenter, roll, pitch, yaw
Supplementary Info: Elevation must be Supplementary Info: Elevation must be above 140 nautical milesabove 140 nautical miles
Data DictionaryData Dictionary
Common tools supporting DDCommon tools supporting DD Preventing creation of duplicate namesPreventing creation of duplicate names
Enforce naming conventionsEnforce naming conventions
August 200345
Enforce naming conventionsEnforce naming conventions
Printing dictionary Printing dictionary
Determine the range of impact of changes, i.e., Determine the range of impact of changes, i.e., which processes are affectedwhich processes are affected
Assist configuration managementAssist configuration management
SummarySummary
Key elementsKey elements Data modelingData modeling
Data objects, attributes and relationshipsData objects, attributes and relationships Cardinality and modalityCardinality and modality
August 200346
Cardinality and modalityCardinality and modality EntityEntity--relationship diagramsrelationship diagrams
Functional modelingFunctional modeling Data and control flow diagramsData and control flow diagrams
Behavioral modelingBehavioral modeling State transition diagramsState transition diagrams
Data DictionaryData Dictionary
Design Concepts And Principles
Software Design -- An iterative process transforming requirements into a “blueprint” for constructing the software.
Topics
• The Design Process
• Design Principles
• Design Concepts-Abstraction & Refinement
Sep. 2003 2S.E. - RSP
• Design Concepts-Abstraction & Refinement
• Software Architecture
• Program Partitioning
• Coupling and Cohesion
Relation of Analysis to Design
Sep. 2003 3
The Design Model• Data Design
– Transforms information domain model into data structures required to implement software
• Architectural Design– Defines relationship among
Procedural Design
Interface Design
Sep. 2003 4S.E. - RSP
– Defines relationship among the major structural elements of a program
Interface Design
Architectural Design
Data Design
The Design Model
Which is mapped from the Analysis model
The Design Model
• Interface Design– Describes how the software
communicates with itself, to systems that interact with it and with humans.
• Procedural Design
Procedural Design
Interface Design
Sep. 2003 5S.E. - RSP
• Procedural Design– Transforms structural
elements of the architecture into a procedural description of software construction
Interface Design
Architectural Design
Data Design
The Design Model
Which is mapped from the Analysis model
The Design Process
• Mc Glaughlin’s suggestions for good design:– Design must enable all requirements of the
analysis model and implicit needs of the
Sep. 2003 6S.E. - RSP
customer to be met
– Design must be readable and an understandable guide for coders, testers and maintainers
– The design should address the data, functional and behavioral domains of implementation
Design Guidelines
• A design should exhibit a hierarchical organization
• A design should be modular• A design should contain both data and
Sep. 2003 7
• A design should contain both data and procedural abstractions
• Modules should exhibit independent functional characteristics
• Interfaces should reduce complexity• A design should be obtained from a
repeatable method, driven by analysis
Design Principles• Design Process:
– Iterative steps that enable description of all aspects of the software
• Design principles:– The design process should consider various
Sep. 2003 8S.E. - RSP
– The design process should consider various approaches based on requirements
– The design should be traceable to the requirements analysis model
– The design should not reinvent the wheel -- Reuse!
– Design should mimic the structure in the problem domain
Design Principles– Design should be uniform and exhibit integrity– Design should accommodate change– Design should minimize coupling between modules– Design should be structured to degrade gently
• It should terminate gracefully and not bomb suddenly
– Design and coding are not interchangeable
Sep. 2003 9S.E. - RSP
– Design and coding are not interchangeable– Design should have quality assessment during
creation, not afterwards• This is to reduce development time
– Design should be reviewed to minimize on conceptual errors -- Formal design reviews!
– There is a tendency to focus on the wrong things• All conceptual elements have to be addressed
Specification
Body
Module
Type definitions
Subprogram profiles
Constants
Specification
Sep. 2003 10
Constants
Encapsulated data
Subprogram definitions
Body
Proc Main;
x: tp;
type tp is ..type a is
access tp;Proc P(z: tp);func F ret a;
Sep. 2003 11
x: tp;ax: a;…p(x);ax = F;...
func F ret a;
Y: tp;Proc P is…end P;func F is… end F;
//
//
Cautionwithpointers!!
type shuttle is recordx: float; -- wrt to coord sysy: float; -- wrt to coord sysz: float: -- wrt to coord sysroll: float;
Module A specification
s: A.shuttle;
x_coord: float;
…
Module B body
Sep. 2003 12
roll: float;pitch: float;yaw: float;
end record;function get return shuttle;
…
s := A.get;
display(s);
…
x_coord := s.x;
... Body A
type shuttle is recordx: float; -- latitudey: float; -- longitudez: float: -- elevationroll: float;
Module A specification
s: A.shuttle;
x_coord: float;
…
Module B body
Sep. 2003 13
roll: float;pitch: float;yaw: float;
end record;function get return shuttle;
…
s := A.get;
display(s);
…
x_coord := s.x;
... Body A
type shuttle is private;function get return shuttle;function get_lat(s) return float;function get_x(s) return float;function get_long(s) return float;…
Module A specification
s: A.shuttle;
x_coord: float;
…
Module B body
Sep. 2003 14
…procedure display(s:shuttle);…privatetype shuttle is record
x,y,z: float; roll, pitch,yaw: float;
end record;
…
s := A.get;
A.display(s);
…
x_coord := A.get_x(s);
...
Design Concepts-Abstraction• Wasserman: “Abstraction permits one to
concentrate on a problem at some level of abstraction without regard to low level details”
• Data Abstraction– This is a named collection of data that describes a
Sep. 2003 15S.E. - RSP
data object• Procedural Abstraction
– Instructions are given in a named sequence– Each instruction has a limited function
• Control Abstraction– A program control mechanism without specifying
internal details, e.g., semaphore.
Refinement
• Refinement is a process where one or several instructions of the program are decomposed into more detailed instructions.
• Stepwise refinement is a top down strategy
Sep. 2003 16S.E. - RSP
• Stepwise refinement is a top down strategy– Basic architecture is developed iteratively
– Step wise hierarchy is developed
• Forces a designer to develop low level details as the design progresses
– Design decisions at each stage
Modularity• In this concept, software is divided into
separately named and addressable components called modules
• Follows “divide and conquer” concept, a complex problem is broken down into several
Sep. 2003 17S.E. - RSP
complex problem is broken down into several manageable pieces
• Let p1 and p2 be two program parts, and E the effort to solve the problem. Then,
E(p1+p2) > E(p1)+E(p2), often >>• A need to divide software into optimal sized
modules
type shuttle is private;function get return shuttle;function get_lat(s) return float;function get_x(s) return float;function get_long(s) return float;…
Module A specification
s: A.shuttle;
x_coord: float;
…
Module B body
Sep. 2003 18
…procedure display(s:shuttle);…privatetype shuttle is record
x,y,z: float; roll, pitch,yaw: float;
end record;
…
s := A.get;
A.display(s);
…
x_coord := A.get_x(s);
...
Modularity & Software Cost
Sep. 2003 19
ModularityObjectives of modularity in a design method
• Modular Decomposability– Provide a systematic mechanism to decompose a
problem into sub problems
Sep. 2003 20S.E. - RSP
• Modular Composability– Enable reuse of existing components
• Modular Understandability– Can the module be understood as a stand alone unit?
Then it is easier to understand and change.
Modularity• Modular Continuity
– If small changes to the system requirements result in changes to individual modules, rather than system-wide changes, the impact of the side effects is reduced (note implications in previous example)
Sep. 2003 21S.E. - RSP
is reduced (note implications in previous example)
• Modular Protection– If there is an error in the module, then those errors
are localized and not spread to other modules
Software Architecture
Desired properties of an architectural design• Structural Properties
– This defines the components of a system and the manner in which these interact with one another.
• Extra Functional Properties
Sep. 2003 22S.E. - RSP
• Extra Functional Properties– This addresses how the design architecture
achieves requirements for performance, reliability and security
• Families of Related Systems– The ability to reuse architectural building blocks
Structural Diagrams
Sep. 2003 23
Kinds of Models
• Terminology– Structural models
• Organized collection of components– Framework models
Sep. 2003 24
– Framework models• Abstract to repeatable architectural patterns
– Dynamic models• Behavioral (dynamic) aspects of structure
– Process models• Business or technical process to be built
– Functional models• Functional hierarchy of the system
Program Structure Partitioning
• Horizontal Partitioning– Easier to test– Easier to maintain (questionable)– Propagation of fewer side effects (questionable)– Easier to add new features
F1 (Ex: Input) F2 (Process) F3(Output)
Sep. 2003 25S.E. - RSP
F1 (Ex: Input) F2 (Process) F3(Output)
Program Structure Partitioning• Vertical Partitioning
– Control and work modules are distributed top down
– Top level modules perform control functions– Lower modules perform computations
• Less susceptible to side effects
Sep. 2003 26S.E. - RSP
• Less susceptible to side effects• Also very maintainable
Information Hiding
• Modules are characterized by design decisions that are hidden from others
• Modules communicate only through well
Sep. 2003 27
• Modules communicate only through well defined interfaces
• Enforce access constraints to local entities and those visible through interfaces
• Very important for accommodating change and reducing coupling
type shuttle is private;function get return shuttle;function get_lat(s) return float;function get_x(s) return float;function get_long(s) return float;…
Module A specification
s: A.shuttle;
x_coord: float;
…
Module B body
Sep. 2003 28
…procedure display(s:shuttle);…privatetype shuttle is record
x,y,z: float; roll, pitch,yaw: float;
end record;
…
s := A.get;
A.display(s);
…
x_coord := A.get_x(s);
...
Functional Independence
• Critical in dividing system into independently implementable parts
• Measured by two qualitative criteria
Sep. 2003 29
• Measured by two qualitative criteria– Cohesion
• Relative functional strength of a module
– Coupling• Relative interdependence among modules
Modular Design -- Cohesion
• A cohesive module performs a single task
• Different levels of cohesion– Coincidental, logical, temporal, procedural,
Sep. 2003 30
– Coincidental, logical, temporal, procedural, communications, sequential, functional
Modular Design -- Cohesion
• Coincidental Cohesion– Occurs when modules are grouped together for
no reason at all
• Logical Cohesion– Modules have a logical cohesion, but no actual
Sep. 2003 31S.E. - RSP
– Modules have a logical cohesion, but no actual connection in data and control
• Temporal Cohesion– Modules are bound together because they must
be used at approximately the same time
Modular Design -- Cohesion• Communication Cohesion
– Modules grouped together because they access the same Input/Output devices
• Sequential Cohesion– Elements in a module are linked together by the
Sep. 2003 32S.E. - RSP
– Elements in a module are linked together by the necessity to be activated in a particular order
• Functional Cohesion– All elements of a module relate to the
performance of a single function
Modular Design -- Coupling
• Coupling describes the interconnection among modules
• Data coupling– Occurs when one module passes local data values
to another as parameters
Sep. 2003 33S.E. - RSP
to another as parameters• Stamp coupling
– Occurs when part of a data structure is passed to another module as a parameter
Modular Design -- Coupling
• Control Coupling– Occurs when control parameters are passed
between modules
• Common Coupling– Occurs when multiple modules access common
Sep. 2003 34S.E. - RSP
– Occurs when multiple modules access common data areas such as Fortran Common or C extern
• Content Coupling– Occurs when a module data in another module
• Subclass Coupling– The coupling that a class has with its parent
class
Examples of Coupling
Sep. 2003 35
Design Heuristics
• Evaluate 1st iteration to reduce coupling & improve cohesion
• Minimize structures with high fan-out;
Sep. 2003 36
• Minimize structures with high fan-out; strive for depth
• Keep scope of effect of a module within scope of control of that module
• Evaluate interfaces to reduce complexity and improve consistency
Design Heuristics
• Define modules with predictable function & avoid being overly restrictive– Avoid static memory between calls where
Sep. 2003 37
– Avoid static memory between calls where possible
• Strive for controlled entry -- no jumps into the middle of things
• Package software based on design constraints and portability requirements
Program Structure
Sep. 2003 38
Documentation
Sep. 2003 39
Summary
• Design is the core of software engineering
• Design concepts provide the basic criteria for design quality
• Modularity, abstraction and refinement
Sep. 2003 40S.E. - RSP
• Modularity, abstraction and refinement enable design simplification
• A design document is an essential part of the process
Chapter 14: Design Method---data and architectural design
Design -- A multistep process in which representations of data structure, program structure, interface characteristics, and procedural detail are synthesized.
S/W Architecture
Structure(s) of the system, which comprise s/w components, the externally visible properties of those
October 2003 SRIMCA2
externally visible properties of those components, and the relationships between them
S/W Architecture
Analyze the effectiveness of the design in meeting its stated reqs.
Consider architectural alternatives at a
October 2003 SRIMCA3
Consider architectural alternatives at a stage when making design changes is still relatively easy.
Reducing the risks associated with the construction of the s/w.
Why is Architecture important?
Enabler for comm. between parties (stakeholders).
Highlights early design decisions which affect all s.e. work that follows, resulting
October 2003 SRIMCA4
affect all s.e. work that follows, resulting into success of the system as operational entity.
Constitutes a relatively small, whole model of how the system is structured and how components work together.
Data Design
What is data design? Transform the information domain model
created during analysis into data structure
October 2003 SRIMCA5
created during analysis into data structure required to implement the software
Well-designed data lead to better program structure and modularity, reduced procedural complexity
Data Design Process
Define data structures identified during the requirements and specification phase. Often base decision on algorithm to be used.
Identify all program modules that must
October 2003 SRIMCA6
Identify all program modules that must operate directly upon the data structureConstrain the scope of effect of data design
decisions
Or, from OO perspective, define all operations performed on the data structure
Principles of Data Design
The systematic analysis principles applied to function and behavior should also be applied to data
October 2003 SRIMCA7
All data structures and the operations to be performed on each should be identified.
Principles of Data Design
A data dictionary should be established and used for both data and program design
Low-level data design decisions should be deferred until late in the design process
October 2003 SRIMCA8
deferred until late in the design process
The representation of data structures should be known only to those modules that must make direct use of the data contained within the structure. Information hiding
Principles of Data Design (cont.)
A library of useful data structures and the operations that may be applied to them should be developed. – Reuse
October 2003 SRIMCA9
The software design and programming languages should support the specification and realization of abstract data types.
Architectural Styles What is an architectural style?
A set of components than perform a function required by the system
A set of connectors that enable communication, co-ordination and co-operation among components.
October 2003 SRIMCA10
ordination and co-operation among components.
Constraints that define how components can be integrated to form the system.
Semantic models that enable designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.
Architectural Styles
Taxonomy of styles Data-centered architectures Data-flow architectures Call and return architectures
– Main Program/Subprogram
October 2003 SRIMCA11
– Main Program/Subprogram– Remote procedure call
Object-oriented architectures Layered architectures
Organization and refinement Control Data
Architectural Design
Objective develop a modular program structure and
represent control relationships between modules
Data flow-oriented design
October 2003 SRIMCA12
Data flow-oriented design amenable to a broad range of applications
very useful when information is processed sequentially, such as microprocessor control application; complex, numerical analysis procedure; etc.
two approaches (transform and transaction mapping)
Architectural Design Process
Six-step Process the type of information flow is established flow boundary are indicated data flow diagram is mapped into program
October 2003 SRIMCA13
data flow diagram is mapped into program structure
control hierarchy is defined by factoring resultant structure is refined using design
measures heuristics the architectural description is refined and
elaborated.
Architectural Design Process(cont.)
Transform Flow
incoming flow outgoing flows
October 2003 SRIMCA14
A Btransformcenter
incoming flow outgoing flows
C
Architectural Design Process(cont.)
Transaction Flow
TransactionAction
October 2003 SRIMCA15
T
Transactioncenter
Actionpaths
Transform Mapping
Allow data flow diagram(DFD) with transform flow characteristics to be mapped into a predefined template for
October 2003 SRIMCA16
mapped into a predefined template for program structure
Level 0 Safehome DFD
October 2003 SRIMCA17
Level 1 Safehome DFD
October 2003 SRIMCA18
Level 2 Safehome DFD - Monitor
October 2003 SRIMCA19
Transform Mapping (cont)
Design steps Step 1. Review the fundamental system
model.
October 2003 SRIMCA20
model.
Step 2. Review and refine data flow diagrams for the software.
Step 3. Determine whether DFD has transform or transaction flow characteristics.
–in general---transform flow
–special case---transaction flow
Level 3 DFD for Monitor Sensors
October 2003 SRIMCA21
Transform Mapping (cont)
step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries different designers may select slightly differently
transform center can contain more than one
October 2003 SRIMCA22
transform center can contain more than one bubble.
step 5. Perform “first-level factoring” program structure represent a top-down
distribution control. factoring results in a program structure(top-level,
middle-level, low-level) number of modules limited to minimum.
First Level Factoring
October 2003 SRIMCA23
Transform Mapping (cont)
step 6. Perform “second-level factoring”– mapping individual transforms(bubbles) to
appropriate modules.
– factoring accomplished by moving outwards
October 2003 SRIMCA24
– factoring accomplished by moving outwards from transform center boundary.
step 7. Refine the first iteration program structure using design heuristics for improved software quality.
Second Level Factoring
October 2003 SRIMCA25
First-Cut Program Structure
October 2003 SRIMCA26
Refined Program Structure
October 2003 SRIMCA27
Transaction Mapping
A single data item triggers one or more information flows
October 2003 SRIMCA28
Transaction Mapping Design
Step 1.Review the fundamental system model.
Step 2.Review and refine DFD for the software
Step 3.Determine whether the DFD has
October 2003 SRIMCA29
Step 3.Determine whether the DFD has transform or transaction flow characteristics
Step 4. Identify the transaction center and flow characteristics along each of the action paths
– isolate incoming path and all action paths
–each action path evaluated for its flow characteristic.
Transaction Mapping (cont)
step 5. Map the DFD in a program structure amenable to transaction processing incoming branch
October 2003 SRIMCA30
incoming branch– bubbles along this path map to modules
dispatch branch– dispatcher module controls all subordinate
action modules
– each action path mapped to corresponding structure
Transaction Mapping
October 2003 SRIMCA31
First Level Factoring
October 2003 SRIMCA32
First-cut Program Structure
October 2003 SRIMCA33
Transaction Mapping (cont)
step 6. Factor and refine the transaction structure and the structure of each action path
October 2003 SRIMCA34
action path
step 7. Refine the first iteration program structure using design heuristics for improved software quality
Design Postprocessing
A processing narrative must be developed for each module
An interface description is provided for each module
October 2003 SRIMCA35
module
Local and global data structures are defined
All design restrictions/limitations are noted
A design review is conducted
“Optimization” is considered (if required and justified)
Summary - Data & Architectural
Data design translates the data objects defined in the analysis model into data structure that reside with in the software
Architectural design use information flow
October 2003 SRIMCA36
Architectural design use information flow characteristics described in the analysis model to derive program structure
DFD is mapped into program structure use two approaches: transform and transaction mapping
Interface Design
Interfaces between software modules
Interfaces between software and non-human producers and consumers
October 2003 SRIMCA37
human producers and consumers For example, sensors and actuators
Interfaces between the human and computer
INTERNAL & EXTERNALINTERFACE DESIGN
Intermodular interface design DFDs show data flow between modules Arrows map into parameters in and out of
interface
October 2003 SRIMCA
interface Determine functions & procedures
using/producing the data External interface design
Typically involves both hardware & software Often supplied by vendor, e.g., A/D boards Often complex functionality
Data validation and error handling
HCI DESIGN MODELS
Design Model - data, architectural, interface, and procedural representations
User Model - profile of end user, categorization as novice, intermittent, or
October 2003 SRIMCA
categorization as novice, intermittent, or frequent user & expert
System Perception - user’s model; end user’s mental image of the system
System Image - outward appearance and supporting information
The User Interface Design Process
User, task, and environmentanalysis and modeling
Interface design
October 2003 SRIMCA
Interface design
Interface construction
Interface validation
TASK ANALYSIS & MODELING
Define and classify tasks Stepwise elaboration
Establish goals and intentions for task Map goal to sequence of actions as it will
October 2003 SRIMCA
Map goal to sequence of actions as it will be executed through the interface
Specify action sequence Indicate state of the system Define control mechanism and effects on
system state Indicate how user interprets system state
DESIGN ISSUES
System response time - primary user complaint Length Variability
User help facilities
October 2003 SRIMCA
User help facilities - integrated vs. add-on Scope Access methods Representation How return to normal process Structure
DESIGN ISSUES - CONTINUED
Error information handling - reduce user frustration Understandable language Constructive advice
Negative consequences of error
October 2003 SRIMCA
Negative consequences of error Audible or visible cue Nonjudgmental (don’t call user an idiot)
Command labeling - hot keys vs. point and click Scope Form Ease of use Customization or abbreviation
DESIGN EVALUATION
Length and complexity of written specification
Number of commands, average number of arguments per command, operations per action
October 2003 SRIMCA
action
Number of actions, commands, and system states -- memory load on user
Interface style, help facilities, and error handling protocol
DESIGN EVALUATION
October 2003 SRIMCA45
DESIGN GUIDELINES -GENERAL INTERACTION
Be consistent Offer meaningful feedback Ask for verification of any destructive action Permit easy reversal of actions
October 2003 SRIMCA
Permit easy reversal of actions Reduce amount of information to be memorized Seek efficiency in dialog, motion, and thought Forgive mistakes Categorize activities and organize
geographically Provide help facilities Use simple action verbs to name commands
DESIGN GUIDELINES -INFORMATION DISPLAY
Display only information relevant to current context
Use format that enables rapid assimilation of informationUse consistent labels, abbreviations, and colors
October 2003 SRIMCA
Use consistent labels, abbreviations, and colors Allow user to maintain visual context Produce meaningful error messages Use text formatting to aid understanding Compartmentalize information Use analog displays when appropriate Use screen geography efficiently
DESIGN GUIDELINES -DATA INPUT
Minimize number of input actions
Maintain consistency between display and input
Allow user to customize input
Allow for flexible interaction
October 2003 SRIMCA
Allow for flexible interaction
Deactivate commands not relevant in current context
Let user control interactive flow
Provide help
Eliminate unnecessary input
SUMMARYTHE INTERFACE TRIAD
Be good to your users
Do not deceive your users
Allow your users to use his/her mind to
October 2003 SRIMCA
Allow your users to use his/her mind to its greatest potential
In other words:
Use common sense
Do undo your users as you would have others do undo you
PROCEDURAL DESIGN
Basic constructs Sequence, condition and repetition
Notations
October 2003 SRIMCA50
Notations Flow charts
Tabular
Program Description Language
FLOWCHARTS
October 2003 SRIMCA51
TABULAR NOTATION
October 2003 SRIMCA52
PROGRAM DESCRIPTION LANGUAGE
REPEAT UNTIL activate switch is turned offreset all signal.values and swtiches;DO FOR alarm.type = smoke, fire, water, temp, burglar;
READ address [alarm.type] signal.value;
October 2003 SRIMCA53
READ address [alarm.type] signal.value;IF signal.value > bound[alarm.type]
THEN phone.message = message [alarm.type];set alarm.bell to “on” for alarm.timeseconds;
PARBEGINCALL alarm PROCEDURE WITH “on”, time in sec.CALL phone PROCEDURE WITH mess [alarm.type],
phone.number;...
CONTROL STRUCTURE DIAGRAM
October 2003 SRIMCA54
DESIGN FORREAL-TIME SYSTEMS
1
Real-time Systems - Systems in which the correctness of the program depends upon the time are which the results are delivered as well as the values calculated.
Outline
• The introduction to real-time system– Some key issues that differentiate the real-time
December 25, 1997 Assistance - Yaru Liu 2
systems from other types of computer software
• Analysis and simulation of real-time systems
• Design for real-time systems
Real-time System Overview• Real-time software is highly coupled to the
external world• Perform high-speed data acquisition and
control under severe time and reliability
December 25, 1997 Assistance - Yaru Liu 3
control under severe time and reliability constrains
• Time is the most important issue in real-time system
• Fast and real-time are not the same– Real-time is predictability and meeting
deadlines, not necessarily fast.
System Considerations
Some differences between real-time software
development and other software engineering
effort:
December 25, 1997 Assistance - Yaru Liu 4
effort:• The design of a real-time system is resource
constrained
• Real-time systems are compact, yet complex
• Real-time systems often work without the presence of a human user
Performance Issues• Each real-time design concern for software
must be applied in the context of system performance– Coordination between the real-time tasks
• Synchronization
December 25, 1997 Assistance - Yaru Liu 5
• Synchronization• Shared resources, e.g., memory, cpu
– Processing of system interrupts– I/O handling to ensure that no data are lost– Specifying the system’s internal and external
timing constraints– Scheduling of tasks to guarantee meeting
deadlines
Performance Issues
• The performance of a real-time system is determined primarily by the system response time and its data transfer rate– System response time is the time within which a
December 25, 1997 Assistance - Yaru Liu 6
– System response time is the time within which a system must detect an internal or external event and respond with an action
– The data transfer rate indicates how fast serial or parallel data, as well as analog or digital data, must be moved into or out of the system
• Fundamental question– Does it meet all deadlines or not?
Performance Issues
• Key parameters that affect the system response time– Context switching
December 25, 1997 Assistance - Yaru Liu 7
– Context switching• the time and overhead to switch among tasks
– Interrupt latency• the time lag before the switch is actually possible
– Speed of computation
– Speed of access to mass storage
Interrupt handling
Software Interrupt handling•Save state of interrupted program
“Normal”processing
flow
Interrupt
December 25, 1997 Assistance - Yaru Liu 8
•Save state of interrupted program
•Determine nature of the interrupt
•Service interrupt
•Restore state of interrupted program
•Return to interrupted program
Interruptis posted
Nested Interrupt Handling
December 25, 1997 Assistance - Yaru Liu 9
Real-time Date Bases
• Distributed databases– Multitasking is the commonplace and data are
often processed in parallel
– A failure of one database need not cause failure
December 25, 1997 Assistance - Yaru Liu 10
– A failure of one database need not cause failure of the entire system, if redundancy is build in
– Concurrency control problem. It involves synchronizing the databases so that all copies have the correct, identical information
• Use of time stamps and locking.
Real-time operating systems• Two broad classes of OS are used for RT work
– RTOS designed exclusively for RT applications– General-purpose OS enhanced to provide RT RTOS
• Beware false claims -- checkout capabilities
• Must provide non-blocking I/O
December 25, 1997 Assistance - Yaru Liu 11
• Must provide non-blocking I/O• Must provide a priority mechanism
– For interrupts– For executing tasks
• RTOS must have a memory locking mechanism• Must provide timing control mechanisms
– Time resolution should be 1 ms. or less.
Real-Time Operating Systems
• Must provide memory sharing threads
• Must provide efficient tasking (context) switching
December 25, 1997 Assistance - Yaru Liu 12
switching
• Should provide synchronization mechanism
• Advanced RTOS may provide task scheduling
Real-time languages• Some differences between a real-time language
and a general-purpose language– Multitasking capability– Constructs to directly implement real-time functions
December 25, 1997 Assistance - Yaru Liu 13
– Constructs to directly implement real-time functions• timing management• task scheduling
– Features to help achieve program correctness• package structures -- enable information hiding• structured mutual exclusion -- monitor functions• structured synchronization -- task rendezvous• type attributes -- e.g., range(A) for array A
Task Synchronization andCommunication
• Three general approaches– Queuing semaphores
• manage several queues– Mailboxes
• buffers which store message or message pointer sent
December 25, 1997 Assistance - Yaru Liu 14
• buffers which store message or message pointer sent from one process to another
– Message systems• one process sends a message to another
• Advanced concepts– Tasking– Rendezvous– Monitors
Analysis and simulation of real-time systems
• Tools for real-time system analysis– Statistical
December 25, 1997 Assistance - Yaru Liu 15
– Statistical
– Hard real-time guarantees
• Simulation and modeling tools– Analyze a system’s performance
– Build a prototype, execute it, and thereby get an understanding of a system’s behavior
Mathematical tools for real-timesystem analysis
– DFD-like model
– Assign transitional probabilities between the process states to each flow path
December 25, 1997 Assistance - Yaru Liu 16
– Add to the process a “unit cost” that represents the estimated ( or actual ) execution time required to perform its function
– Add to the process an “entrance value” that depicts the number of system interrupts (or execution requests) corresponding to it
Mathematical tools for real-timesystem analysis
Information
2
1in
Dataarrival rate
P12 = 0.6
December 25, 1997 Assistance - Yaru Liu 17
Informationsource
3
1in
Unit cost = 4.6
P13 = 0.4
Compute:• The expected number of visits to a process• The time spent in the system when processing begins at a specific process• The total time spent in the system
DFD for Real-Time
December 25, 1997 Assistance - Yaru Liu 18
Queuing Model
December 25, 1997 Assistance - Yaru Liu 19
Queuing Reduction Rules
December 25, 1997 Assistance - Yaru Liu 20
Simplifying Networks
December 25, 1997 Assistance - Yaru Liu 21
Simulation and modeling tools
• The conceptual view– Functional view is captured with activity-
charts, which are similar to conventional DFD
December 25, 1997 Assistance - Yaru Liu 22
charts, which are similar to conventional DFD
– Dynamic view uses state-charts ( similar to CFD). Transitions between states are typically triggered by events
– Integration: each level of an activity-chart, there will usually be a state-chart
Example
December 25, 1997 Assistance - Yaru Liu 23
Statechart for Example
December 25, 1997 Assistance - Yaru Liu 24
Simulation and modeling tools
• The physical view– The conceptual model is the foundation, but not
a real system– Decompose a system into subsystem,
December 25, 1997 Assistance - Yaru Liu 25
– Decompose a system into subsystem, component, sub-component
– Relation to conceptual model
• Analysis and simulation– Statecharts syntactically correct
• complete - no obviously missing label, names• consistency - e.g., correctness of I/O
Simulation and modeling tools
• Running scenarios– Correctness of function or behavior
– Engineer can play role of user & enter tests
December 25, 1997 Assistance - Yaru Liu 26
– Engineer can play role of user & enter tests
• Programming simulations– Simulation control language (SCL)
• Automatic translation of activity and statecharts into code
Real-time design
• Incorporate all of the fundamental concepts and principles associated with high-quality software
December 25, 1997 Assistance - Yaru Liu 27
software• A set of unique problems
– Representation of interrupts and context switching
– Concurrency as manifested by multitasking and multiprocessing
– Inter-task communication and synchronization
Real-time design (cont’d)
– Wide variations in data and communication rates
– Resource management of shared resources– Representation of timing constraints
December 25, 1997 Assistance - Yaru Liu 28
– Representation of timing constraints– Need for scheduling– Asynchronous processing– Necessary and unavoidable coupling with
operating systems, hardware, and other external system elements
– High reliability (usually)
Real-time design
• A number of modeling principles– Explicit atomicity
– Interleaving
December 25, 1997 Assistance - Yaru Liu 29
– Interleaving
– Nonterminating histories and fairness
– Closed system principle - include environment with computer system in analysis
– Structuring state by objects
– Sometimes, physically measure task times
Summary
• The design of real-time software =all aspects of conventional software design + a new set of design criteria and concerns
• Real-time software must respond to real-
December 25, 1997 Assistance - Yaru Liu 30
• Real-time software must respond to real-world events in a time frame dictated by those events
• Clock or event driven
• Can be very difficult to design and even more difficult to test, verify and validate
Software TestingTechniques
Introduction• Many aspects to achieving software quality
– Formal reviews (of both the software process and the various stages of development), audits, documentation, etc.
2
documentation, etc.
– Unit testing
– Integration testing
– Verification • Does the module meet the specifications
– Validation• Does the product meet the requirements
CLCS Test ApproachOperations Environment User Acceptance Tests
System TestCOTS H/Won Dock
System Delivery
System S/W Validation Tests
User App S/W Validation Tests
Developers
System Integration and Test Group
Validation Group
Application S/W IPT
UsersDevelopment Environment
UnitTestDesign
Early User Eval
Unit IntegTest
Integration Environment
User Eval CSCI IntTest
AcceptanceTest
Introduction
• A Critical element of the Software Quality Assurance
• Represents a critical review of
4
• Represents a critical review of Specifications, Design and Coding
• Destructive rather than Constructive (try to break the system)
• Major objective is to find errors not to show the absence of errors (as distinct from Verification and Validation)
Objectives
• Testing is a process of executing a program with the intent of finding an error
• A good test case is one that has a high
5
• A good test case is one that has a high probability of finding an as-yet undiscovered error
• A Successful test is one that uncovers an as-yet undiscovered error
Principles• All tests should be traceable to customer
requirements• Tests should be planned long before testing begins• The Pareto principle applies to Testing
– Typically, 80% of the errors come from 20% of the
6
– Typically, 80% of the errors come from 20% of the modules
• Testing should begin ‘‘in the small’’ and progress towards “in the large”
• Exhaustive Testing is not possible, but, – if time permits, conduct multiple failure mode testing
• Test plans must receive independent review
Testability
• The ease with which a computer program
7
• The ease with which a computer program can be tested .
Characteristics for Testability
• Operability– the better it works ,
8
the more efficiently it can be tested• The system has few bugs
• No bugs block the execution of tests
• The product evolves in functional stages
Characteristics for Testability
• Observability– what you see is what you test
• Distinct output for each input
9
• Distinct output for each input
• System states and variables visible during execution
• Past system states and variables are visible
• All factors affecting the output are visible
• Incorrect output is easily identified
• Internal errors are automatically detected and reported
Characteristics for Testability
• Controllability– the better we can control the software ,
the more testing can be automated
10
• All possible outputs can be generated through some combination of input
• All code is executable through some combination of input
• Input and Output formats are consistent and structured
• All sequences of task interaction can be generated• Tests can be conveniently specified and reproduced
Characteristics for Testability
• Decomposability– By controlling the scope of testing , isolate
problems and perform smarter retesting
11
problems and perform smarter retesting• The Software system is built from independent
modules
• Software modules can be tested independently
– While this is very important, it does not obviate the need for integration testing
Characteristics for Testability
• Simplicity– the less there is to test ,
12
– the less there is to test , the more quickly we can test it
• Functional simplicity
• Structural simplicity
• Code simplicity
Characteristics for Testability
• Stability– the fewer the changes ,
the fewer disruptions to testing
13
the fewer disruptions to testing• Changes are infrequent
• Changes are controlled
• Changes do not invalidate existing tests
• The software recovers well from failures
Characteristics for Testability
• Understandability– the more information we have ,
the smarter we will test
14
the smarter we will test• The design is well understood
• Dependencies between internal, external and shared components well understood
• Changes to design are well communicated
• Technical documentation is instantly accessible, well-organized, specific and accurate
“A Good Test”
• A good test has a high probability of finding an error
• A good test is not redundant
15
• A good test is not redundant
• A good test should be “best of breed”
• A good test should be neither too simple nor too complex
Types of Testing
• White-Box Testing– Knowing the internal workings of a product,
tests are conducted to ensure that “all gears all gears mesh”mesh”
16
mesh”mesh”• Black-Box Testing
– Knowing the specified function that a product has been designed to perform , tests are conducted to demonstrate that each function is fully operational (note: this is still different from validation)
White Box Testing• Uses the control structure of the procedural design
to derive test cases
• Guarantees that all independent paths within a module have been exercised at least once
• Exercise all logical decisions on their true and
17
• Exercise all logical decisions on their true and false sides
• Exercises all loops at their boundaries and within their operational bounds
• Exercises internal data structures to assure their validity - again, at their boundaries and with their operational bounds
Why White Box Testing?
• Logic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed.
18
program path will be executed.
• We often believe that a logical path is not likely to be executed when , in fact, it may be executed on a regular basis.
• Typographical errors are random.
Basis Path Testing
• Attacks the control flow of the program
• Provides us with a logical complexity measure of a procedural design
19
measure of a procedural design
• Use this measure as a guide for defining a Basis set of execution paths
• Test cases derived to exercise the Basis set are guaranteed to execute every statement in the program at least once
Basis Path Testing
• A Flow Graph created
– represents the control flow of the program
20
– represents the control flow of the program
– each node in the graph represents one or more procedural statements
– Any procedural design representation can be translated into a flow graph
Flow Graph Notation
21
Basis Path Testing ( contd.)
• Example PDL
procedure sort1 : do while records remain
read record ;2 : if record field1 = 03 : then process record ;
22
3 : then process record ;store in buffer ;increment counter ;
4 : elseif record field2 = 05 : then reset counter ;6 : else process record ;
store in file ;7a: endif
endif7b: enddo8 : end
Basis Path Testing ( contd.)• Flow Graph
1
2
4 3
23
3
6 5
7a
7b
8
Basis Path Testing ( contd.)
• Cyclomatic Complexity
– Quantitative measure of the complexity of a
24
– Quantitative measure of the complexity of a program
– is the number of independent paths in the basis set of a program
– Upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once
Basis Path Testing ( contd.)
• Cyclomatic Complexity calculation
V (G) = E -N+ 2= P + 1= No. of regions in the graph
where E = no. of edges, N = no. of nodes, and P = no. of predicate nodes
25
• For the previous example
– Independent paths
path 1 : 1 - 8path 2 : 1 - 2 - 3 - 7b - 1 - 8path 3 : 1 - 2 - 4 - 6 - 7a - 7b - 1 - 8path 4 : 1- 2 - 4 - 5 - 7a - 7b - 1 - 8
– Cyclomatic complexity = 11 - 9 + 2 = 3 + 1 = 4
Basis Path Testing ( contd.)
• Prepare test cases that will force execution of each independent path in the Basis Path
26
of each independent path in the Basis Path set
• Each test case is executed and compared to expected results
Example
27
Example
28
Condition Testing
• Exercises all the logical conditions in a module
• Types of possible errors
29
• Types of possible errors – Boolean variable error
– Boolean Parenthesis error
– Boolean Operator error
– Arithmetic expression error
Types of Condition Testing
• Branch Testing – the TRUE and FALSE branches of the condition
and every simple condition in it are tested
30
and every simple condition in it are tested
• Domain Testing– for every Boolean expression of n variables ,
all of 2n possible tests are required– this can detect boolean operator, variable,
parenthesis errors, if n is small.
Types of Condition Testing
• BRO (Branch and Relational Operator) Testing – detection of branch and relation operator errors in a condition, provided that,
31
operator errors in a condition, provided that, all boolean variables and relational operators in the condition occur only once and have no common values.
Data Flow Testing
• This method selects test paths of a program according to the locations of definitions and uses of variables in the program.
• Assume that each statement in program is assigned a unique no. & functions do not
32
assigned a unique no. & functions do not modify their arguments or global variables. Then define– DEF ( S ) = { X | Statement S contains a
definition of X }– USE ( S ) = { X | Statement S contains a
use of X }
Data Flow Testing
• The definition of variable X at statement S is said to be live at statement S’ if there exists a path from statement S to satatement S’ that contains no other definition of X.
33
– Definition - Use chain ( DU chain )• [ X , S , S ‘ ] , where X DEF ( S ) and X USE ( S ‘ ) and the definition of X in S is live at S ’
• DU Testing Strategy - Every DU chain to be covered at least once.
Kinds of Loops
34
Loop Testing• Focus is on the validity of loop constructs• Simple loop ( n is the max. no. of allowable passes )
– Skip the loop entirely– Only one pass through the loop– Two passes
35
– Two passes– m passes , where m < n – n-1 , n , n+1 passes
• Nested loop– Start at innermost loop– Conduct simple loop test for this loop holding the outermost loop at their
minimum iteration parameter– Move outwards one loop at a time– Continue until all loops have been tested
Loop Testing ( contd.)
• Concatenated loops– Multiple simple loop tests if independent
– Nested loop approach if dependent
36
– Nested loop approach if dependent
• Unstructured loops– Should be restructured into a combination of
simple and nested loops
Black Box Testing
• Focus is on the functional requirements of the software
• Uncovers errors such as
37
– Incorrect or missing functions
– Interface errors
– Errors in data structures
– Behavior or Performance errors
– Initialization and Termination errors
• Unlike White Box Testing , this is performed at later stages of testing
Graph Based Testing
• Identify all objects modeled by the software
• Identify the relationships that connect these
38
• Identify the relationships that connect these objects
• Create an Object-Relationship graph– node– node weights– links– link weights
Graph Testing ( contd.)
• Example graph
newfile
Document window
allows
menu select generates
generation < 1 sec
39
Document text
is represented as containsAttributes :
start dimensionBackground colortext color
allowsediting
of
Graph Test Generation
• Add entry and exit nodes• For an object A, values for all objects in the
transitive closure of Z must be tested for
40
transitive closure of Z must be tested for their impact on Z
• Test the symmetry of all bi-directional links, e.g., “undo”
• Be sure all nodes have a reflexive link. Test it for each node.
• Test each relationship (the links).
Equivalence Partitioning
• Input domain divided into classes of data from which test cases are derived
• Goal is to design a single test case that
41
• Goal is to design a single test case that uncovers classes of errors , thereby reducing the total number of test cases to be developed
• Each class represents a set of valid or invalid states for input conditions
Equivalence Partitioning ( contd.)
• Test case design is based on an evaluation of equivalence classes for an input condition– range specified , one valid and two invalid
equivalence classes
42
equivalence classes– requires a specific value , one valid and two invalid
equivalence classes– specifies a member of a set , one valid and one
invalid equivalence classes– is boolean , one valid & one invalid equivalence
class
Equivalence Partitioning ( cont. )
• ExampleAutomatic Banking
– area code : input condition , boolean
43
– area code : input condition , booleaninput condition , range [200,999]
– prefix : input condition , range >200, no 0’s, < 1000
– suffix : input condition , value -- 4 digits
– password : input condition , booleaninput condition , value -- 6 char str
– command : input condition , set
Boundary Value Analysis• Greater number of errors tend to occur at the
boundaries of the input domain• Select test cases that exercise bounding values• Input condition
– range , test cases are just below min and just above max
44
– range , test cases are just below min and just above max– set , test cases are minimum and maximum values, if
ordered• The above guidelines are also applied to output
conditions– example
• outputs that produce minimum and maximum values in the output range
Comparison Testing
• Multiple copies of the software are constructed in case of critical applications– Example: Shuttle Flight Control Software
• Each version is independently built from the
45
• Each version is independently built from the specs by different teams
• Test cases derived from other BB Testing techniques are provided as input to each version
• Outputs are compared and versions validated• Not fool proof
Other Cases• GUI testing
– See text for partial list of things to test• Client Server
– Often distributed -- complicates testing
46
– Often distributed -- complicates testing– Additional emphasis on non-interference
among clients• Documentation
– Use black box techniques• Real-time
– Beyond the scope of this course
Summary
• Destructive rather than constructive• Main goal is to find errors not to prove the
absence of errors• White Box Testing
– control structure testing– Condition testing
47
– Condition testing– Data flow testing– Loop testing
• Black Box Testing - Functional requirements– Graph based testing – Equivalence partitioning– Boundary Value testing– Comparison testing
CLCS Example
Software Vendor Version Platform Facility
IRIX (UNIX Silicon Graphics 6.2 SGI Indigo 2, SDE,
48
IRIX (UNIXoperating system)
Silicon GraphicsIncorporated (SGI)
6.2 SGI Indigo 2,SGI Indy,SGI Challenge
SDE,LCC-X
IRIX (UNIXoperating system)
Silicon GraphicsIncorporated (SGI)
6.3 SGI O2 SDE,LCC-X
VxWorks (GatewayOS)
VxWorks 5.2 SDS Gateway,CS Gateways
SDE,LCC-X
Table 1.1: Juno Baselined COTS Software
CLCS Example
data.
Step Description Expected Results1.
49
1. Turn on SDE1 network hardware and PC’s Blinky lights start blinking on thenetwork devices, PC’s execute poweron self tests, boots OS
2. Turn on the sde1net workstation, wait for it to finishbooting (login screen will be displayed), then turn onthe sde1boot workstation and wait for it to finishbooting.
POST (Power On Self Test) testsoccur, Operating system startprocedures initiate, Login screensappear.
3. Turn on all remaining HCI workstations and thesde1ddp1 machine.
POST (Power On Self Test) testsoccur, Operating system startprocedures initiate, Login screensappear.
CLCS Example
16. Initiate data acquisition at the sde1hci7 workstation.In the Dnav master menu, select “Global Apps”, thenselect “Start receive process”, then select “GW toHCI JUNO_DDP_8”
The System messages windowindicates that the Start receiveprocess is executing, no unexpectederrors are displayed in the console
50
HCI JUNO_DDP_8” errors are displayed in the consolewindow.
17. Start data display. In the Dnav master menu, select“Shuttle”, then select any of the following:
Wind SpeedWind Direction PAD AWind Direction PAD BTemperature
The command is accepted (as shownin the System messages and consolewindows), the appropriate display(s)are started and are regularly updated.
18. Stop data display at the workstation. Select quit fromdisplay menu(s)
Display windows are closed.
Test Results
Number Title Opened
During
Criticality Date
Opened
Current
Status
Juno-11 Telnet from sde1hci1 to
sde1ddp-r failed
System
Test
Major 4/14/97 Open
51
sde1ddp-r failed Test
Juno-12 Remote delog written
into wrong directory
System
Integration
Major 4/15/97 Open
Juno-13 Application displays
CPU intensive
System
Integration
Minor 4/15/97 Open
Juno-14 Telnet to SDS Gateway
not working
System
Test
Minor 4/22/97 Open
Juno-15 Error received when
attempting to start
receive process
System
Test
Major 4/22/97 Open
Lessons Learned• The configuration management process was
not complete, multiple baselines of some software components existed.
• A CLCS software sustaining process needs
52
• A CLCS software sustaining process needs to be defined and implemented as soon as possible.
• Requirements buy-off process needs to be refined.
• Hardware identification could be improved.
CHAPTER 17CHAPTER 17
SOFTWARE TESTINGSOFTWARE TESTINGSTRATEGIESSTRATEGIES
1
STRATEGIESSTRATEGIES
TOPICSTOPICS
A strategic approach to software testing
Unit Testing
Integration Testing
April 2004 SRIMCA2
Integration Testing
Validation Testing
System Testing
The ART of Debugging
Summary
STRATEGIC APPROACH TOSTRATEGIC APPROACH TOSOFTWARE TESTINGSOFTWARE TESTING
Generic characteristics of software testing strategies:-
Testing begins at module level and works outwardtowards the of integration entire computer based system.
April 2004 SRIMCA3
towards the of integration entire computer based system. Different testing techniques are required at different
points in time. Testing is conducted by the s/w developer and ITG
( Independent Test Group ) for large projects. Testing and Debugging are different and Debugging is
essential in any testing strategy.
Verification and ValidationVerification and Validation
April 2004 SRIMCA4
Verification -- Does the product meet its specifications?
Validation -- Does the product perform as desired?
Software Testing StrategySoftware Testing Strategy
A Software Testing Strategy
April 2004 SRIMCA5
Software Testing StrategySoftware Testing Strategy
April 2004 SRIMCA6
Software Error ModelSoftware Error Model
f(t) = cumulative remaining errors at time t l0 = initial failure ratep = exponential reduction as errors repaired
f(t) = (1/p)ln(l0pt + 1)
April 2004 SRIMCA7
f(t) = (1/p)ln(l0pt + 1)
STRATEGIC APPROACHSTRATEGIC APPROACH
Issues to be addressed to develop a successful software testing strategy:Specify product requirements in a quantifiable
April 2004 SRIMCA8
Specify product requirements in a quantifiable manner long before testing commences.
State testing objectives explicitly.
Understand the users of the software.
Develop testing plan that emphasizes “rapid cycle testing.”
STRATEGIC APPROACHSTRATEGIC APPROACH
Issues to be addressed to develop a successful software testing strategy:Build robust software that is designed to test
itself.
April 2004 SRIMCA9
itself.
Use effective formal technical reviews as a filter to testing.
Conduct formal technical reviews to assess test strategy and test cases.
Develop continuous improvement approach
UNIT TESTINGUNIT TESTING
Unit testing -- focuses on the smallest element of software design viz. the module. Corresponds to class testing in the OO context.
April 2004 SRIMCA10
Corresponds to class testing in the OO context.
Makes heavy use of white-box testing.
UNIT TESTINGUNIT TESTING
Unit Test Generation Considerations:
Review Design information - develop unit test cases.
interfacelocal data structures
April 2004 SRIMCA11
Testcases
local data structuresboundary conditionsindependent pathserror handling paths
driver
Module to be tested
stubstub
Unit Test GenerationUnit Test Generation
Interface considerations# of input parameters = # arguments?Parameter and argument attributes match?Parameter and argument units match?
April 2004 SRIMCA12
Parameter and argument units match?Order correct (if important)?Number and order of arguments for built-ins?References to parms not associated with entry point?Attempt to modify input-only arguments?Global variable definitions consistent?Constraints passed as arguments?
Unit Test GenerationUnit Test Generation
External I/O considerationsFiles attributes correct?
OPEN/CLOSE correct?Format specification matches I/O statement?
April 2004 SRIMCA13
Format specification matches I/O statement?
Buffer size matches record size?
Files opened before use?
EOF handled correctly?I/O errors handled?
Textual errors in output?
Unit Test GenerationUnit Test Generation
Data structure considerationsImproper or inconsistent typing?
Erroneous initialization or default values?
Incorrect variable names?
April 2004 SRIMCA14
Incorrect variable names?
Inconsistent data types?
Underflow, overflow and addressing exceptions?
Unit Test GenerationUnit Test Generation
Test cases must cover all execution pathsCommon computational errors to be checked:incorrect arithmeticmixed mode operationsincorrect initialization
April 2004 SRIMCA15
incorrect initializationprecision inaccuracyincorrect symbolic representation of expression
Other tests neededincompatible data types in comparisonsincorrect logical operators or precedencecomparison problems (e.g., == on floats)loop problems
Unit Test GenerationUnit Test Generation
Error handling testsException-handling is incorrect?
Error description is unintelligible, insufficient
April 2004 SRIMCA16
Error description is unintelligible, insufficient or incorrect?
Error condition causes system interrupt before error handling completed?
INTEGRATION TESTINGINTEGRATION TESTING
A systematic approach for constructing program structure while conducting tests to uncover errors associated with interfacing.
Tendency for Non-Incremental integration..
April 2004 SRIMCA17
Tendency for Non-Incremental integration.. Big Bang approach …. Chaos !! ( usually ).
Incremental integration - program is constructed and tested in small segments.Top-Down Integration testing
Bottom-Up Integration testing
INTEGRATION TESTINGINTEGRATION TESTING
April 2004 SRIMCA18
INTEGRATION TESTINGINTEGRATION TESTING
Top-Down ApproachBegin construction and testing with main module. Stubs are substituted for all subordinate modules.
Subordinate stubs are replaced one at a time by actual modules.
April 2004 SRIMCA19
actual modules. Tests are conducted as each module is integrated.On completion of each set of tests, another stub is
replaced with the real module.Regression testing may be conducted to ensure
that new errors have not been introduced.
Top Down ApproachTop Down Approach -- Use StubsUse Stubs
April 2004 SRIMCA20
INTEGRATION TESTINGINTEGRATION TESTING
Top-Down Approach : Advantages:
Verifies major control or decision points early in the test process.
April 2004 SRIMCA21
With the use of depth-first integration testing, a complete function of the software can be demonstrated. -- Confidence builder for developer/customer.
Disadvantages:Since stubs replace lower level modules, no
significant data can flow upwards to the main module.
INTEGRATION TESTINGINTEGRATION TESTING
Bottom Up Approach :This approach begins construction and testing
with modules at the lowest levels in the program structure.
April 2004 SRIMCA22
program structure.Low-level modules are combined into clusters.
A driver is written to coordinate test case input and output.
The cluster is tested.
Drivers are removed and clusters are combined moving upward in the program hierarchy.
Bottom Up ApproachBottom Up Approach
April 2004 SRIMCA23
INTEGRATION TESTINGINTEGRATION TESTING
Bottom Up Approach Advantages:
Easier test case design and lack of stubs.
Disadvantages:
April 2004 SRIMCA24
Disadvantages:The program as an entity is does not exist until the
last module is added.
Sandwich Testing:- combined approachTop down strategy for upper levels and Bottom
up strategy for subordinate levels.
INTEGRATION TESTINGINTEGRATION TESTING
Regression Testing Re-execution of some subset of tests already
conducted to ensure that the new changes do not have unintended side effects.
The Regression test suite should contain three
April 2004 SRIMCA25
The Regression test suite should contain three different classes of test cases :A representative sample of tests that will
exercise all software functionsAdditional tests that focus on functions that are
likely to be affected by the change.Tests that focus on software components that
have changed.
INTEGRATION TESTINGINTEGRATION TESTINGIntegration Test Documentation
Scope of testing
1 2 3 4
Test planTest
Procedure nActual Test
Results
5
Ref. &Appendix
April 2004 SRIMCA26
Order ofIntegration
Test phases
and builds
Schedule
Overheadsoftware
Environment / Resources
Unit test
Testenvironment
Test case data
Expected Results
for build n
VALIDATION TESTINGVALIDATION TESTING
It provides final assurance that software meets all functional, behavioral, and performance requirements.-- Exclusive use of Black-box testing techniques.
April 2004 SRIMCA27
-- Exclusive use of Black-box testing techniques. After each validation test case either software
conforms to specs or a deviation from specs is detected and a deficiency list needs to be worked.
Alpha and Beta testingAlpha test -- At developer’s site by customer.Beta test -- At customer’s site in a “live”
environment.
SYSTEM TESTINGSYSTEM TESTING
A series of tests to verify that all systemelements have been properly integrated.
Recovery Testing:Forces software to fail in a variety of ways and
April 2004 SRIMCA28
Forces software to fail in a variety of ways and verifies that recovery is properly performed.
Security Testing:Attempts to verify the software’s protection
mechanisms. The software designer tries to make penetration cost more than the value of information obtained by breaking in.
SYSTEM TESTINGSYSTEM TESTING
Stress Testing: Executes the system in a manner that demands
resources in abnormal quantity, frequency or volume.
April 2004 SRIMCA29
volume.
Performance Testing: To test the run time performance of a system
within the context of an integrated system.
CLCS Test ApproachCLCS Test ApproachOperations Environment User Acceptance Tests
System TestCOTS H/Won Dock
System Delivery
System S/W Validation Tests
User App S/W Validation Tests
Developers
System Integration and Test Group
Validation Group
Application S/W IPT
UsersDevelopment Environment
UnitTestDesign
Early User Eval
Unit IntegTest
Integration Environment
User Eval CSCI IntTest
AcceptanceTest
THE ART OF DEBUGGINGTHE ART OF DEBUGGING
Debugging is a consequence of successful testing -- when a test case uncovers an error, it is the debugging process that results in the removal of the error.
April 2004 SRIMCA31
removal of the error.
Debugging is an ART. The external manifestation of the error and the cause of the error normally do not share an obvious relationships.
THE ART OF DEBUGGINGTHE ART OF DEBUGGING
The Debugging process
Execution of test cases Results
April 2004 SRIMCA32
Test cases
Results
Debugging
Suspected causes
Additional tests
Identified causesCorrections
Regression tests
THE ART OF DEBUGGINGTHE ART OF DEBUGGING
Debugging ApproachesBrute force : - Take memory dumps, invoke run
time traces. Least efficient and quite common.
Backtracking :- Once an error is uncovered, trace
April 2004 SRIMCA33
Backtracking :- Once an error is uncovered, trace your way back to the cause of the error.
Cause Elimination : - Isolate potential causes,
devise cause hypotheses tests to isolate bug.
Use of debugging tools
COMMENTSCOMMENTS
Should the software developer be involved with testing ?Developer’s have a vested interest in
demonstrating that their software is error-free.Developer’s (psychologically) feel that testing
April 2004 SRIMCA34
Developer’s (psychologically) feel that testing is destructive.
When are we done with testing ?“You are never done with testing, the burden
shifts from you to the customer.”
SUMMARYSUMMARY
Software Testing accounts for the largest percentage of technical effort in the software process.
Objective of Software testing -- To uncover
April 2004 SRIMCA35
Objective of Software testing -- To uncover errors, maintain software quality.
Steps : Unit, Integration, Validation, System.
Debugging is often an art and the most valuable resource is often the counsel of other software engineers.
Technical Metrics for SoftwareChapter 18
Chapter Outline
Software Quality
A Framework for Technical Software Metrics
Metrics for the Analysis Model
Chapter 18 -- SRIMCAJanuary 2004 2
Metrics for the Design Model
Metrics for Source Code
Metrics for Testing
Metrics for Maintenance
Summary
Technical Metrics Are NOT absolute (hence they are open to debate)
Provide us with a systematic way to assess quality
Provide insight into product quality on-the-spot
Chapter 18 -- SRIMCAJanuary 2004 3
Provide insight into product quality on-the-spot
rather than after-the-fact
Software Quality Software requirements are the foundation from
which quality is measured. Specified standards define a set of development
criteria that guide the manner in which software is engineered.
Chapter 18 -- SRIMCAJanuary 2004 4
engineered. There is a set of implicit requirements that often
goes unmentioned. Software quality is a complex mix of factors that
will vary across different applications and the customers who request them.
McCall’s Software Quality Factors
MaintainabilityFlexibilityTestability
PortabilityReusabilityInteroperability
Chapter 18 -- SRIMCAJanuary 2004 5
Correctness Reliability Usability Integrity Efficiency
Product Operation
Product Revision Product Transition
iiq mcF
HP’s FURPS Functionality - evaluate the feature set and capabilities
of the program
Usability - aesthetics, consistency, documentation
Chapter 18 -- SRIMCAJanuary 2004 6
Reliability - frequency and severity of failures
Performance - processing speed, response time, resource consumption, throughput, efficiency
Supportability - maintainability testability, compatibility, ease of installation
Transition to a Quantitative View Previous slides described qualitative factors for
the measurement of software quality
Everyday quality measurementsgymnastics, talent contests etc.
Chapter 18 -- SRIMCAJanuary 2004 7
gymnastics, talent contests etc.
side by side comparisons
quality judged by an expert in the field
Quantitative metrics don’t explicitly measure quality, but some manifestation of quality
The Challenge of Technical Metrics
Each quality measurement takes a different view of what quality is and what attributes in a system lead to complexity.
e.g. “attractive car” - difficult to derive single
Chapter 18 -- SRIMCAJanuary 2004 8
e.g. “attractive car” - difficult to derive single value for “attractiveness”.
The goal is to develop measures of different program attributes to use as indicators of quality.
Unfortunately, a scientific methodology of realizing this goal has not been achieved.
Measurement Principles Formulation - derivation of software metrics
appropriate for the software being considered
Collection - accumulating data required to derive the formulated metrics
Chapter 18 -- SRIMCAJanuary 2004 9
Analysis - computation of metrics and application of mathematical tools
Interpretation - evaluation of metrics in an effort to gain insight into the quality of the system
Feedback - recommendations derived from the interpretation of metrics
Attributes of Effective Software Metrics
Simple and computable
Empirically and intuitively persuasive
Consistent and objective
Chapter 18 -- SRIMCAJanuary 2004 10
Consistent and objective
Consistent in units and dimensions
Programming language independent
Effective mechanism for quality feedback
Function Based Metrics The Function Point (FP) metric can be used
as a means for predicting the size of a system (derived from the analysis model).
Chapter 18 -- SRIMCAJanuary 2004 11
number of user inputs
number of user outputs
number of user inquiries
number of files
number of external interfaces
Function Point Metric
Weighting FactorMEASUREMENT PARAMETER count simple average complex total
number of user inputs 3 x 3 4 6 = 9number of user outputs 2 x 4 5 7 = 8number of user inquiries 2 x 3 4 6 = 6
Chapter 18 -- SRIMCAJanuary 2004 12
number of user inquiries 2 x 3 4 6 = 6number of files 1 x 7 10 15 = 7number of external interfaces 4 x 5 7 10 = 20count - total 50
Overall implemented size can be estimated from the projected FP value
FP = count-total (0.65 + 0.01 Fi)
The Bang Metric Used to predict the application size based on the
analysis model.
The software engineer first evaluates a set of primitives unsubdividable at the analysis level.
Chapter 18 -- SRIMCAJanuary 2004 13
primitives unsubdividable at the analysis level.
With the evaluation of these primitives, software can be defined as either function-strong or data-strong.
Once the Bang metric is computed, past history must be used to predict software size and effort.
Metrics for Requirements Quality
Requirements quality metrics - completeness, correctness, understandability, verifiability, consistency, achievability, traceability, modifiability, precision, and reusability - design metric for each. See Davis.
Chapter 18 -- SRIMCAJanuary 2004 14
E.g., let nr = nf + nnf , where nr = number of requirements
nf = number of functional requirements
nnf = number of nonfunctional requirements
Metrics for Requirements Quality Specificity (lack of ambiguity) Q = nui/nr nui - number of requirements for which all
reviewers had identical interpretations
Chapter 18 -- SRIMCAJanuary 2004 15
reviewers had identical interpretations For completeness, Q = nu/(ni ns) nu = number of unique function requirements ni = number of inputs specified ns = number of states specified
High-Level Design Metrics
Structural Complexity S(i) = f2
out(i)
fout(i) = fan-out of module i
Data Complexity
Chapter 18 -- SRIMCAJanuary 2004 16
Data Complexity D(i) = v(i)/[fout(i) +1]
v(i) = # of input and output variables to and from module i
System Complexity C(i) = S(i) + D(i)
High-Level Design Metrics (Cont.)
Morphology Metrics size = n + a
n = number of modules
Chapter 18 -- SRIMCAJanuary 2004 17
n = number of modules
a = number of arcs (lines of control)
arc-to-node ratio, r = a/n
depth = longest path from the root to a leaf
width = maximum number of nodes at any level
Morphology Metrics
a
b c d e
Chapter 18 -- SRIMCAJanuary 2004 18
f g i j k l
h m n p q r
size depth width arc-to node ratio
AF Design Structure Quality Index
S1 = total number of modulesS2 = # modules dependent upon correct data
source or produces data used, excl. control
Chapter 18 -- SRIMCAJanuary 2004 19
S3 = # modules dependent upon prior processing
S4 = total number of database itemsS5 = # unique database itemsS6 = # of database segmentsS7 = # modules with single entry & exit
AF Design Structure Quality Index
D1 = 1 if arch design method used, else 0
D2 = 1 - (S2/S1) -- module independence
D3 = 1 - (S3/S1) -- independence of prior
Chapter 18 -- SRIMCAJanuary 2004 20
D3 = 1 - (S3/S1) -- independence of prior processing
D4 = 1 - (S5/S4) -- database size
D5 = 1 - (S6/S4) -- DB compartmentalization
D6 = 1 - (S7/S1) -- Module entrance/exit
DSQI = wiDi, where the wi are weights totaling 1 which give the relative importance
The closer this is to one, the higher the
AF Design Structure Quality Index
Chapter 18 -- SRIMCAJanuary 2004 21
The closer this is to one, the higher the quality.
This is best used on a comparison basis, i.e., with previous successful projects.
If the value is too low, more design work should be done.
Component-Level Design Metrics Cohesion Metrics
Coupling Metrics data and control flow coupling
global coupling
Chapter 18 -- SRIMCAJanuary 2004 22
global coupling
environmental coupling
Complexity Metrics Cyclomatic complexity
Experience shows that if this > 10, it is very difficult to test
Cohesion Metrics
Data slice - data values within the module that affect the module location at which a backward trace began.
Data tokens - Variables defined for a module
Glue Tokens - The set of tokens lying on multiple data slices
Chapter 18 -- SRIMCAJanuary 2004 23
data slices
Superglue tokens - The set of tokens on all slices
Stickiness - of a glue token is proportional to number of data slices that it binds
Strong Functional CohesionSFC(i) = SG(i)/tokens(i)
Coupling Metrics Data and control flow coupling
di = number of input data parameters
ci = number of input control parameters
d0 = number of output data parameters
c0 = number of output control parameters
Global couplingg = number of global variables used as data
Chapter 18 -- SRIMCAJanuary 2004 24
gd = number of global variables used as data
gc = number of global variables used as control
Environmental coupling w = number of modules called (fan-out)
r = number of modules calling the module under consideration (fan-in)
Module Coupling: mc = 1/ (di + 2*ci + d0 + 2*c0 + gd + 2*gc + w + r)
mc = 1/(1 + 0 + 1 + 0 + 0 + 0 + 1 + 0) = .33 (Low Coupling)
mc = 1/(5 + 2*5 + 5 + 2*5 + 10 + 0 + 3 + 4) = .02 (High Coupling)
Interface Design Metrics Layout Entities - graphic icons, text, menus, windows, .
Layout Appropriateness absolute and relative position of each layout entity
frequency used
Chapter 18 -- SRIMCAJanuary 2004 25
frequency used
cost of transition from one entity to another
LA = 100 x [(cost of LA-optimal layout) / (cost of proposed layout)]
Final GUI design should be based on user feedback on GUI prototypes
Metrics for Source Code
Software Science Primitives
n1 = the number of distinct operators
n2 = the number of distinct operands
Chapter 18 -- SRIMCAJanuary 2004 26
n2 = the number of distinct operands
N1 = the total number of operator occurrences
N2 = the total number of operand occurrences
Length: N = n1log2n1 + n2log2n2
Volume: V = Nlog2(n1 + n2)
Metrics for Source Code (Cont.)
SUBROUTINE SORT (X,N)
DIMENSION X(N)
IF (N.LT.2) RETURN
DO 20 I=2,N
DO 10 J=1,I
IF (X(I).GE.X(J) GO TO 10
OPERATOR COUNT
1 END OF STATEMENT 7
2 ARRAY SUBSCRIPT 6
3 = 5
4 IF( ) 2
5 DO 2
Chapter 18 -- SRIMCAJanuary 2004 27
IF (X(I).GE.X(J) GO TO 10
SAVE = X(I)
X(I) = X(J)
X(J) = SAVE
10 CONTINUE
20 CONTINUE
RETURN
END
5 DO 2
6 , 2
7 END OF PROGRAM 1
8 .LT. 1
9 .GE. 1
10 GO TO 10 1
n1 = 10 N1 = 28
n2 = 7 N2 = 22
Metrics for Testing
Analysis, design, and code metrics guide the design and execution of test cases.
Metrics for Testing Completeness Breadth of Testing - total number of requirements
Chapter 18 -- SRIMCAJanuary 2004 28
Breadth of Testing - total number of requirements that have been tested
Depth of Testing - percentage of independent basis paths covered by testing versus total number of basis paths in the program.
Fault profiles used to prioritize and categorize errors uncovered.
Metrics for Maintenance Software Maturity Index (SMI) MT = number of modules in the current release
Fc = number of modules in the current release that have been changed
Chapter 18 -- SRIMCAJanuary 2004 29
been changed
Fa = number of modules in the current release that have been added
Fd = number of modules from the preceding release that were deleted in the current release
SMI = [MT - (Fc + Fa + Fd)] / MT
Summary Software metrics provide a quantitative way to
asses the quality of product attributes.
A software metric needs to be simple, computable, persuasive, consistent, and objective.
Chapter 18 -- SRIMCAJanuary 2004 30
The function point and bang metrics provide quantitative means for evaluating the analysis model.
Metrics for design consider high-level, component level, and interface design issues.
Summary Interface design metrics provide an indication of
layout appropriateness for a GUI.
Using the number of operators and operands present in the code provides a variety of metrics to
Chapter 18 -- SRIMCAJanuary 2004 31
present in the code provides a variety of metrics to assess program quality.
Using the metrics as a comparison with known successful or unsuccessful projects is better than treating them as absolute quantities.
OBJECT ORIENTED
Chapter 19
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 1
OBJECT ORIENTEDMODELING, CONCEPTS
AND PRINCIPLES
CONTENTS
What is object-oriented development ?
Object-oriented process model
Object-oriented concepts
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 2
Object-oriented concepts
Object modeling technique
Unified Modeling Language (UML)
Concepts and Principles of Object Modeling
Object-oriented vs functional approach
What is OO Development ?“New” way of thinking about problems using
models organized around real world concepts.The fundamental construct is the object
• Combines both data structure and operations in a
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 3
• Combines both data structure and operations in a single entity called an object.
Leads to reuse, faster software development and higher quality programs.
Easier to maintain• Structure inherently decoupled• Fewer side-effects
The OO process modelMoves through an evolutionary spiralEmphasizes development of reuse capability
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 4
Object Oriented ConceptsObjects and Object Model
• Object: Data and operations relevant to some real world or significant program entity encapsulated into a monolithic unit accessible only through a well defined interface. For ex.
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 5
only through a well defined interface. For ex. File in the file system together with operations such as open, close, read, & write,
• Object Model: Describes the structure of the objects in the system
– their identity, relationships to other objects, attributes and operations.
Classification & Classes• A class describes a group of objects with
similar properties (attributes), common behavior (operations), common relationships to other objects, and common semantics.
Object Modeling
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 6
Object ClassesThus, a class is an abstraction that describes
relevant properties and hides the rest. Represented diagrammatically as below.
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 7
Class Name
Attributes
Operations
Object Modeling
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 8
Object Modeling
Attributes: An attribute is a data value held by the objects in a class. Name, age, and weight are attributes of Person objects.
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 9
Object Modeling
Operations and Methods : • Operations : An operation is a function or
transformation that may be applied to or by objects in a class. Each operation has a target object as an implicit argument. The behavior of
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 10
object as an implicit argument. The behavior of the operation depends on the class of its target.
• Methods : A method is the implementation of an operation for a class.
– Categories: 1) manipulate data, 2) perform computation, and 3) monitor for occurrence of controlling event.
An operation may have arguments in addition to its target object. Such arguments parameterize the operation but do not affect the choice of method.
Object Modeling
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 11
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 12
Class and Instance
Polygon
VerticesBorder Color
Polygon
v={(0,0),(0,1),(1,0)}BC = Red
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 13
Border ColorFill Color
DrawEraseMove
BC = RedFC = Blue
DrawEraseMove
Abstraction and Encapsulation
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 14
Abstraction• Isolate those aspects that are important and
suppress (or hide) those that are unimportant (e.g., representations).
Abstraction and Encapsulation
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 15
(e.g., representations). • Focus on what object is and does before
deciding how it should be implemented. • Abstraction allows dealing only with
application domain concepts, not making design and implementation decision before problem is understood.
Encapsulation (Information Hiding) • Separates the external aspects of an object,
which are accessible to other objects, from the
Abstraction and Encapsulation
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 16
which are accessible to other objects, from the internal implementation details of the object, which are hidden from other objects.
Combining Data and Operations: • The OO approach combines the data structure
and operations in a single entity.
Interfaces
<<Interface>>
Class Name
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 17
Does not have an implementation of its own.
Other classes provide implementations of it.
Client classes are only interested in behavior.
Operations
InheritanceSharing of attributes and operations among
classes based on hierarchical relationship.
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 18
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 19
Class and Subclass
Polygon
VerticesBorder Color
Right Triangle
VerticesHypotenuse length
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 20
Border ColorFill Color
DrawEraseMove
Hypotenuse lengthBorder Color
Fill Color
DrawEraseMove
••
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 21
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 22
OperationsPolymorphism
•The same “operation” may behave differently on different classes. E.g., the move operation behaves differently on a Window and ChessPiece.
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 23
differently on a Window and ChessPiece.
•Operations may be overloaded when subclasses defined.
– The compiler can distinguish based on the type of the operands in method invocations which operation is actually needed.
Polymorphism
Car
Paint
Polygon
Paint
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 24
Triangle
Paint
Square
Paint
CommunicationMessage: [destination, operation, params]
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 25
What Does OO Mean?Pressman (Coad & Yourdon)
• Objects (identity)• Classification• Inheritance
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 26
• Inheritance• Communication
Rumbaugh• Objects (identity)• Classification• Inheritance• Polymorphism
Object Modeling Technique
Object modeling technique (OMT) extends from analysis thru design to implementation
Analysis model contains objects found in
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 27
Analysis model contains objects found in the application domain, including properties of object and their operations.
These application domain objects form a framework to the design model.
The same seamless notation is used from analysis to design to implementation.
The system is modeled using three related but different view points.
Object Modeling Technique
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 28
but different view points.• Object Model : Represents the static, structural,
“data” aspects of the system.• Dynamic Model : Represents the temporal,
behavioral, “control” aspects of the system.• Functional Model : Represents transformational,
“functional” aspects of the system.
Object Modeling
Links and Associations • Link: A physical or conceptual connection between
instances. E.g., Joe Smith Works-for Simplex company. Mathematically, a tuple, i.e., an ordered
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 29
list of object instances. A link is an instance of an association.
• Associations : A group of links with common structure and semantics. E.g., a person Worksfor a company. All the links in an association connect objects from the same classes.
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 30
Object Modeling
Multiplicity: • Specifies how many instances of one class may
relate to a single instance of an associated classRole Names:
• One end of an association. Binary association
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 31
• One end of an association. Binary association has two roles.
Link attributes• May be defined for associations, e.g., if the
association is “uses,” the link attribute might be one of permission.
Binary Association & Multiplicity
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 32
Ternary Association
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 33
Link Associations
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 34
AggregationA “part-whole” or “a-part-of” relationship
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 35
OO Software ProcessFramework
• Identify major classes and connections.• Do enough design to ensure they are implementable• Extract reusable components and build prototype.
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 36
• Test to uncover errors and get customer feedback.• Iterate on design and refine it.• Engineer special objects (not in library).• Assemble a new prototype.• Test and obtain customer feedback.• Iterate until satisfactory product obtained.
OO MetricsBecause of reuse, LOC not so useful# of Scenario scripts, each a triplet of the form
[initiator, action, participant], where• Initiator = object initiating a request
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 37
• Initiator = object initiating a request• action = result of request (method invocation)• participant = server object satisfying request
# of key [highly independent] classes# of support classes (and ave. per key class)# of subsystems
Possible Estimating Approach
Develop scenario scripts and estimate countDetermine the number of key classesCategorize key classes
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 38
Categorize key classesInterface type MultiplierNo GUI 2.0Text-based user int. 2.25GUI 2.5Complex GUI 3.0
Possible Estimating ApproachEstimate # of support classes by multiplying
# key classes in each category by multiplier
Estimate # of person-days per class, e.g.,
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 39
Estimate # of person-days per class, e.g., 15-20
Estimate the number of major iterations
There should be a contract deliverable for each major iteration
OO Progress TrackingThis needs to be done for each iteration (see
text for list of specifics in each category)• OO analysis completed
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 40
• OO analysis completed
• OO design completed
• OO programming completed
• OO testing completed
Object-Oriented vs Structured Approach
Easier to maintain
Combines data structure and behavior in a single entity
Harder to maintain
May separate data and behavior
Emphasizes
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 41
in a single entity
Emphasizes object structure
Reuse more readily accomplished
Emphasizes procedural structure
Reuse limited, hence possible delay in software construction
Object-Oriented vs Structured Approach
Strong cohesion and weak coupling
Encapsulation, Inheritance and
Harder to achieve weak Coupling and strong cohesion
Some languages
Chapter 19 -- Assistance -- Lamimi V. KamatFebruary 14, 1999 R. A. Volz 42
Inheritance and Polymorphism are strong features of OO software development
Some languages support encapsulation and polymorphism, but rarely inheritance
Object Oriented Analysis
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
Object Oriented Analysis (OOA)First Technical activity performed as part of
OO Software Engineering.
Involves the answering the following questions when a new Product is developed:• How is the proposed system amenable to OOSE?
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
• How is the proposed system amenable to OOSE?
• What are the relevant objects?
• How do the objects behave in context of the system?
• How do we specify or model a problem in order to implement an effective design?
Principles to Develop OOA model
Model Information domain
Describe model function
Represent model behavior
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
Represent model behavior
Partition models to expose greater detail
Thus, Early models represent essence of problem
while later models provide implementation details.
OOA Model Development Steps
Obtain basic user requirements; problem statement
Identify classes, define attributes, methods
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
Identify classes, define attributes, methods
Specify class hierarchy
Represent Object - Object relationships
Model Object behavior
OOA ApproachesBooch Method - Micro & Macro Development. Identify classes and objects:
• Propose candidate objects, • Conduct behavior analysis, • Identify relevant scenarios, • Define attributes and operations for each class
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
• Define attributes and operations for each class Identify class and object semantics :
• Select scenarios and analyze,• Assign responsibility • Partition responsibilities to balance behavior, • Enumerate object roles and responsibilities, • Define operations to achieve responsibilities,• Look for “collaborations” among objects.
Booch method - contd, Identify relationships among classes and
objects:• Define dependencies between objects, • describe role of each object, • validate by “walking thru” scenarios.
Conduct series of refinements:
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
Conduct series of refinements:• Produce appropriate diagrams for representation, • Define class hierarchies, • Perform clustering based on class commonality
Implement classes and objects (i.e., complete OO Analysis model).
OOA ApproachesRumbaugh Method: Object Modeling
Technique (OMT) for Analysis, System design and Object-level design.
Analysis : creates 3 models
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
• Object model - Representation of classes, objects, hierarchies, and relationships
• Functional model - A high-level DFD-like information flow representation.
• Dynamic model - Representation of Object and system behavior
Develop a statement of scope for problem.Build an Object model
• Identify classes, • Define attributes and associations, • Define object links,
Outline of Rumbaugh Method
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
• Define object links, • Organize classes using inheritance.
Develop dynamic model • Prepare scenarios, • Define events and trace them, • Draw event flow, • State diagrams, • Review behavior.
Outline of Rumbaugh Method
Construct functional model for system• Identify inputs and outputs
• Use data flow diagrams to represent flow,
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 9
• Use data flow diagrams to represent flow,
• Develop Process Specifications for each function,
• Specify constraints and optimization criteria.
Domain AnalysisDomain Analysis
• Emphasize creating & using library of reusable classes.
• Identification, analysis and specification of common requirements from application domain,
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
common requirements from application domain, for reuse on multiple projects within that domain.
Levels of Abstraction for System Analysis:• Enterprise - Entire business• Business level - Workings of a particular activity• Application level - Specific customer
requirements.
A series of activities that begin with identification of domain to be investigated and end with a specification of the objects and classes that characterize the domain(Domain Analysis model)
Domains can range from avionics to banking, to
Domain Analysis Process
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
Domains can range from avionics to banking, to multimedia video games to medical applications.
Goal: create software within the domain with a high percentage of reusable components.
• Define the domain, then extract objects.
Domain Analysis Procedure
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
• Define the domain, then extract objects.
• Categorize the items extracted in a hierarchy.
• Collect sample of applications in the domain.
• Analyze each application in the sample.
• Develop an analysis model for the objects.
Generic OOA Model Components
Static components - Structural in nature, indicate characteristics that hold throughout the operational lifetime of the application.• Static view of Semantic classes• Static view of attributes
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
• Static view of attributes• Static view of relationships• Static view of behaviors
Dynamic components: Focus on control and are sensitive to timing and event processing.• Dynamic view of Communication,• Dynamic view of Control and Time.
Generic OOA Model Components
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 14
OOA ProcessDefine a set of system usage scenarios
• Identified from meeting with the customer.• Identify the different roles that interact with the
system or product. These are called actors.– Anything that communicates with system and is
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
– Anything that communicates with system and is external to it.
• Actors are different from user: user may play part of several actors. e.g.:
– programmer, tester, monitor or troubleshooter .
• Define Use Cases: unambiguous narrative of interaction between actor and system.
Begin with identifying actors and determining how they interact with the system.• What are the main tasks performed by actors?
Generating Use Cases
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
• What are the main tasks performed by actors?
• What system info will actor use or produce?
• Will actor inform system about external changes?
• What info will actor delete from system?
• Is actor informed about unexpected changes?
Use Case Example - Safe Home
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 17
Use Case Example - Safe HomeOwner looks at control panel - Is system ready?
• If not ready, physically close windows & doors so the ready indicator is present.
Owner enters password;• Password compared with valid password.• If not correct, beep and reset.
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
• If not correct, beep and reset.• If correct, await further commands.
Owner activates system.• Mode AtHome or• Mode Away
System alarm light comes on.
Identifying Object Classes
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
Identifying Object Classes
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 20
Subjectsand Sub-
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
systems
OOAmodelwith
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
with
Subjectreferences
Safe Home Level 1 DFD
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 23
OOA ProcessClass-Responsibility-Collaborator Modeling:
• A means of identifying and organizing classes relevant to the system.
Responsibilities:
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
Responsibilities: • The attributes and operations that are relevant
for the class - anything a class knows or does.
Collaborators:• Those classes that are required to provide a class
with information needed to complete a responsibility.
CRC model index card:
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 25
CRC model “tested” by conducting a review driven by use cases.
Collaboration ExampleResponsibility: (As part of activation
procedure)• Safe home Control Panel must determine if
any sensors are open - responsibility determine-sensor-status.
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 26
sensor-status.
Collaborator:• Sensor info is obtained from Sensor Object.
• For determine-sensor-status to be fulfilled, Control Panel has to work in collaboration with Sensor.
AssociationsCollaborators suggest associations
Control Panel Sensor
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 27
Determine
sensor
status
Associations & OperationsCollaborations suggest operations
Control Panel Sensor
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 28
GetState ()
Determine
sensor
status
OOA ProcessGuidelines for organizing classes and
assigning them responsibilities:• System intelligence should be evenly
distributed.• State responsibility as generally as possible.
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 29
• State responsibility as generally as possible.• Share responsibilities among related classes.
– Will lead to inheritance.• Information and related behavior should reside
in same class• Information about one thing should be localized
in a single class.
The Object relationship model
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
Object behavior modelEvaluate use cases to determine interactions.
• Look at the states of each object• Look at states of system as observed from outside
Identify events that drive the interactions.• Events are Boolean.
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 31
• Events are Boolean.• Typically represent the completion of some
action.Create an event trace.Build a state-transition diagram.Review the object-behavior model to verify
accuracy and consistency.
Use Case Example - Safe HomeOwner looks at control panel - Is system ready?
• If not ready, physically close windows & doors so the ready indicator is present.
Owner enters password;• Password compared with valid password.• If not correct, beep and reset.
Chapter 20 -- Assistance -- Senthil K VeluswamySenthil VeluswamyFebruary 21, 1999 -- R. A. Volz
• If not correct, beep and reset.• If correct, await further commands.
Owner activates system.• Mode AtHome or• Mode Away
System alarm light comes on.
State Transition model
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 33
Event Trace
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 34
Partial Event Flow Diagram
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 35
SummaryOOA begins with use cases.Create object, functional and dynamic modelsObject Analysis
• model as objects, attributes and operations.
Chapter 20 -- Assistance -- Senthil K VeluswamyFebruary 21, 1999 -- R. A. Volz 36
• model as objects, attributes and operations.• Develop relationships among objects.
Common characteristics• Representation of classes and class hierarchies,• Creation of object-relationship models, and• Derivation of object-behavior models.
Object-Oriented Design
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 1
OutlineFrom Analysis to
Design
Design Issues
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 2
System Design
Object Design
Design patterns &
Conclusion
Object-Oriented DesignTransforms OOA model into blueprint for
software construction
Builds upon four essential design concepts
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 3
Builds upon four essential design concepts• Abstraction
• Information hiding
• Functional independence
• Modularity
Mapping OOA to OOD
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 4
OutlineFrom Analysis to
Design
Design Issues
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 5
System Design
Object Design
Design patterns &
Conclusion
Comparison of Conventional & OOD
Representation of module hierarchies Specification of data definitionsSpecification of procedural logic Indication of end-to-end processing flow
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 6
Indication of end-to-end processing flowRepresentation of object states and transitionsDefinition of classes and hierarchiesAssignment of operations to classesDetailed definition of operationsSpecification of message connections Identification of exclusive services
Design Issues for Modularity
DecomposabilityComposabilityUnderstandabilityContinuity
Protection
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 7
Protection
Linguistic modular unitsFew interfacesSmall interfaces (weak coupling)Explicit interfaces Information hiding (no global data)
OOD Methodologies
The Booch Method
The Coad and Yourdon Method
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 8
The Jacobson Method
The Rumbaugh Method
The Wirfs-Brock Method
Booch MethodArchitectural planning
• Cluster similar objects in separate architectural partitions.
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 9
• Layer objects by level of abstraction.
• Identify relevant scenarios.
• Create a design prototype.
• Validate the design prototype by applying it to usage scenarios.
Booch MethodTactical design
• Define domain-independent policies.
• Define domain specific policies.
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 10
• Define domain specific policies.
• Develop a scenario that describes the semantics of each policy.
• Create a prototype of each policy.
• Instrument and refine the prototype.
• Review each policy.
Booch MethodRelease planning
• Organize scenarios developed during OOA by priority.
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 11
• Allocate corresponding architectural releases to the scenarios.
• Design and construct each release incrementally.
• Adjust goals and schedule of incremental release as required.
The Rumbaugh OMT
Perform system designConduct object design Implement Control mechanisms
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 12
Adjust class structure to strengthen inheritance
Design messaging to implement the object relationships
Package classes and associations into modules
OutlineFrom Analysis to
Design
Design Issues
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 13
System Design
Object Design
Design patterns &
Conclusion
OOD Process Flow
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 14
System Design
Partition the analysis model into subsystems• A subsystem is a package (collection) of classes
and associations, events and constraints that are interrelated and have a small interface.
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 15
• Usually identified by the services it provides. Identify concurrenciesAllocate subsystems to processors and tasksChoose a basic strategy for data management
System Design
Identify global resources and access control mechanisms
Design control mechanism for system
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 16
Design control mechanism for systemDetermine how to handle boundary
conditions.Review & modify if necessary
System DesignPartition the Analysis Model
Small number of subsystems, • Partition subsystems to reduce complexity
Well-defined interface, services
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 17
Intra- (use) and inter- (minimize) communication
Achieve high Cohesion within a subsystemCommunication between subsystems: client/
server (one way) or peer-to-peer (two way)
Communication Models
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 18
System DesignCohesion
Goi
ng t
owar
ds H
igh
Coh
esio
n
Coincidental
Logical
Temporal
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 19
Goi
ng t
owar
ds H
igh
Coh
esio
n
Temporal
Communication
Sequential
Functional
Data
System DesignConcurrency and subsystem Allocation
Identify active objects (threads of control)Where to allocate subsystems
• same processor? -- need concurrency control• independent processor ? -- may still need
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 20
• independent processor ? -- may still need concurrency control
Allocation and design issues:• performance requirements.• costs• overheads and efficiency
Concurrency Example
Database
•DB access
•
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 21
•
•
•
•
•
DB access
Concurrency
Ada -- Use taskstask type DB_access is … end;
type dba is access DB_access;
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 22
type dba is access DB_access;
a, b: dba;
…
a := new DB_access;
b:= new DB_access;
…
Concurrency
Java -- Use threadsclass dbAccess extends thread{…
public void run () { …}
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 23
public void run () { …}
…
new dbAccess.start();
new dbAccess.start();
}
Some Concurrency Issues
Mutual exclusion of shared objects• Two objects should not be able to write to the
same shared object at the “same time.”
Communication
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 24
Communication• Allow messages to be sent between objects.
When is an object ready to receive a message?
Synchronization • Ensure that two or more objects are at known
points at the same time.
Data ManagementGenerally refers to shared objectsConcurrency controls essentialOften refers to data to have a permanence
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 25
beyond scope of program Issues
• Infrastructure for access and storage• Management of data
Often look for interfaces to existing support subsystems
System designResource Management
Resources: External entities vs. abstractions• E.g., disk, processor, comm line
• Databases, objects, interfaces
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 26
• Databases, objects, interfaces
Guardian object:• Keeper of the resource
• Controlling access to the resource
• Moderating conflicts for requests
Language support can vary widely
System designHuman-Computer Interface
Inputs: user scenarios and roles
Identify command hierarchy (menu bars, popups, windows, interactive controls, ...)
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 27
popups, windows, interactive controls, ...)
Reuse existing support tools whenever possible
• So all that is needed are objects that have appropriate characteristics of problem domain
Intersubsystem CommunicationCreate a table for each contract
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 28
Subsystem Collaboration GraphList each request made by a collaborator
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 29
OutlineFrom Analysis to
Design
Design Issues
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 30
System Design
Object Design
Design patterns &
Conclusion
Object Design
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 31
Key Object Characteristics(Available from Analysis)
Object name (or name of class of objects)DescriptionServices provided or functions
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 32
How createdHow invokedShared resourcesCommunication
• With whom?• Interfaces
Object DesignObject Internals
Protocol description• List each message type the object can receive, e.g.,
• MESS(motion sensor): read RET id, status
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 33
• MESS(motion sensor): read RET id, status
Implementation description• Spec. of object’s name and reference to class
• Spec. of private data encapsulated
• Procedural description of each operation
• Specification of control structures
Use a PDL to Describe ObjectPACKAGE program_component_name IS
type specification of data objects…Proc specifications of related operations
PRIVATE
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 34
PRIVATEdata structure details for object types
PACKAGE BODY program_component_name ISPROC operation: (interface specification) IS…PROC operation: (interface specification) IS
END program_component_name
High Level Sensor PDLPACKAGE sensor IS
TYPE sensor_status IS (ON | OFF)TYPE sensor_id, alarm_charPROC read, set, testPRIVATE
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 35
PRIVATEsensor_id, IS STRING LENGTH (8)alarm_char DEFINED
threshold, sig_type, sig_level IS INTEGERPACKAGE BODY sensor IS
TYPE update_rate IS INTEGERPROC read (sensor_id, sensor_status: OUT)...
Object DesignSteps done in object design
Detail object attributes and operations
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 36
Review object-relationship model
Describe operations and transitions using PDLs.
OutlineFrom Analysis to
Design
Design Issues
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 37
System Design
Object Design
Design patterns &
Conclusion
Design Patterns
An abstraction that conveys meaning about a class’s applicability.
pattern template• Name : (applicability and intent)• Problem description: (env. and conditions)
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 38
• Problem description: (env. and conditions)• Characteristics• Consequences
Naming -- choose to aid searchTwo different mechanisms
• is-a (inheritance) -- a basis for new subclasses• has-a (composition) - ensemble
What next ?From Design to implementationSuccess of complex projects relies more on
the design architecture rather than the implementation. So SW Eng. stresses OOA
Chapter 21 -- Assistance -- Magy Seif El-NasrFebruary 1, 1998 R. A. Volz 39
implementation. So SW Eng. stresses OOA and OOD
If you have a good and complete design, implementation should be straightforward
Nevertheless, language choice does have an influence.
Object-Oriented Testing
Chapter 22February 8, 1998 -- R. A. Volz 1
Triad to test OO systems
Broaden the view of testing
Change strategy for unit and integration
Chapter 22February 8, 1998 -- R. A. Volz 2
Change strategy for unit and integration testing
Design test cases to account for the unique characteristics of OO software
Broadening the View of TestingReview OOA & OOD models
• Especially useful since same semantic constructs (classes, etc.) appear in analysis, design and impl.
Chapter 22February 8, 1998 -- R. A. Volz 3
Can help avoid• Subclasses added to accommodate unnecessary
attributes.
• Incorrect or extraneous class relationships
• Improper behavior to accommodate extraneous attributes
Testing OOA & OOD ModelsTesting OOA & OOD ModelsUse CRC index card for review
Chapter 22February 8, 1998 -- R. A. Volz 4
Testing OOA & OOD ModelsTesting OOA & OOD ModelsCorrectness of OOA & OOD Models
• Judge by conformance with real world domain
Consistency of OOA & OOD Models
Chapter 22February 8, 1998 -- R. A. Volz 5
Consistency of OOA & OOD Models• Check CRC and object-relationship models for
inclusion of all collaborations
• Ensure that delegated responsibilities are part of collaborator’s definition
• Ensure that each collaborator is receiving requests from proper source -- inverted conn.
Testing OOA & OOD ModelsTesting OOA & OOD ModelsConsistency of OOA & OOD Models
• Use inverted connection to determine whether other classes or responsibilities are needed.
Chapter 22February 8, 1998 -- R. A. Volz 6
• Determine whether widely requested responsibilities might be combined, e.g., read credit card and get authorization.
• Iterate on the above.
OO - Testing StrategiesUnit testing in the OO context
• Class is the unit of testing• But, one must test through the class hierarchy
Integration testing in the OO context
Chapter 22February 8, 1998 -- R. A. Volz 7
Integration testing in the OO context• Thread-based• Use-based (dependent & independent classes)• Cluster testing -- find errors in collaborations
Validation testing in an OO context• System level testing
Test Case Design For OO
1. Uniquely identify each test case and associate with the class to be tested.
2. Clearly state the purpose of the test.3. Develop a list of testing steps:
Chapter 22February 8, 1998 -- R. A. Volz 8
3. Develop a list of testing steps:• List of specified states for object to be tested.• List of messages and operations to be exercised.• List of exceptions to be tested. • List of external conditions.• Supplementary information that will aid in
understanding or implementing the test.
Test Case DesignConventional test case design is driven by
an input-process-output view or by algorithmic detail of individual modules.
Chapter 22February 8, 1998 -- R. A. Volz 9
OO testing focuses on designing appropriate sequences of operations to exercise the states of a class.• Within object, similar to white box testing.
Test Case Design
Fault based testing• Use plausible faults to guide test design
• Look for range boundaries, e.g., look for
Chapter 22February 8, 1998 -- R. A. Volz 10
• Look for range boundaries, e.g., look for mixups of <, <=, etc.
• Look for common operator errors, e.g., mixing up <, > or OR, AND, XOR, +/-, etc.
• Use hazard analysis fault trees.
Scenario based testing.
Test Case Design
Random OO class testing• Randomly generate test sequences of method
invocations, e.g., if a banking object has methods, open, deposit, withdraw, balance,
Chapter 22February 8, 1998 -- R. A. Volz 11
methods, open, deposit, withdraw, balance, summarize, and close, generate random seq.
• This should test inappropriate and well as appropriate sequences.
Multiple Class Testing
For each client class, generate random test sequences.
For each message, determine collaborators.
Chapter 22February 8, 1998 -- R. A. Volz 12
For each message, determine collaborators.
For each server operation, determine messages it sends.
For each message, determine the next level of operators.
Compose to form overall test sequence.
Multiple Class Testing
Chapter 22February 8, 1998 -- R. A. Volz 13
Behavior Testing ModelsEnsure coverage of all states and transitions.
Chapter 22February 8, 1998 -- R. A. Volz 14
THE PRESENTATION-BY
Chapter 22
February 8, 1998 -- R. A. Volz 15