27252883 software engineering notes

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


In theory, software does not wear out at all.

July 03 Chapter 15

BUT,Hardware upgrades.Software upgrades.


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


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


Software project planningRequirements analysis

DevelopmentSoftware designCodingTesting


MaintenanceCorrection -- bugs will appear Adaptation -- to changing operating systems,

CPU’s, etc.


CPU’s, etc.Enhancement -- changing customer needsPrevention -- software reengineering


Typical activities in these phasesProject tracking and control Formal reviewsSoftware quality assurance


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


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


Subcontract managementProject tracking and oversightSoftware project planningRequirements management

Key Process Areas

Maturity Level 3Peer ReviewsIntergroup coordinationIntegrated software management


Integrated software managementTraining programOrganization process definitionOrganization process focus

Key Process Areas

Maturity Level 4Software quality managementQuantitative process management


Maturity Level 5Process change managementTechnology change managementDefect prevention

Software Process Models


Waterfall Model

Requirements Analysis Design Code

System/Information Engineering


Test

Maintain

The Prototyping Model


The RAD Model

Business Modeling

Data Modeling

Business Modeling

Data Modeling

Process Modeling

Application


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?


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


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


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


Evolutionary nature of S/W not considered in classic models

Evolutionary Process Models

The Incremental Model



The Spiral ModelProposed by Boehm

Couples iterative prototyping with controlled and systematic Linear Sequential


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


The Spiral Model

Concept Development Projects

New Product Development


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.


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


The Concurrent Development Model


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


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


Other Models

Formal MethodsRigorous mathematical representation of

requirementsProvides basis for automatic verification test

generation


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


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


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.


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


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.


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


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


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


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


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


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


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


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.


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


Process Decomposition

Typical activitiesReview the customer request.Plan and schedule a formal, facilitated meeting with the

customer.Conduct research to define proposed solutions.


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


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


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


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


characteristics

People

conditions

Technology

Process

Development environment

Measurement

What to measure?errors uncovered before releasedefects delivered to and reported by end userswork products delivered


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?


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


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


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


Example of Defect Analysismissing ambiguous

wrong customer queried

specification defects


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


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


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.


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


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


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


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


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


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”


3-D Function Point Calculation


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


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


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


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


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:


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:


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


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


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.


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


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


Create Project Estimates

Make or buy decision

Scope

What scope means:Functions

Literally refers to all functions performed by a systemPerformance


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


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


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


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


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


Decode part code dataDo database lookupDetermine bin locationProduce control signal for shuntMaintain record of box destinations

Resources


Resources

For each type of resources, 4 characteristics are examined:Description of resourceAvailabilityTime resource needed


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.


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


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


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


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


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


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,


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


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


• 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


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


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


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


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


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


--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


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


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


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


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


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:


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


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


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


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)


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


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.


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


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”,


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,


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:


“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


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)


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


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


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?


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:


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


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


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


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


degrade system performance to a point

where misssion success is questionable


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


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


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


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


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.


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,


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.


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


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


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


d) Tracke) Controlf) Communicate

SEI Software Development Risk


SEI Technical Reviews

Software Risk Management

Ronald P. Higuera, Yacov Y. Haimes; June 1996

An Introduction To Team Management (Version 1.0)


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


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


NASA - Shuttle-Mir


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


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


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


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


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


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


Application longevityStability of requirementsEase of customer/developer communicationsMaturity of applicable technologyPerformance constraintsEmbedded/nonembedded characteristicsProject staffingReengineering factors

Task Set Selector Values


(compute average value)

Example


Linear, Sequential Model

See text for outline of example procedure


Evolutionary (Spiral) Model


Example of Task Network


Scheduling

Typical tools

Program Evaluation and Review Technique (PERT) charts

Critical Path Method (CPM)

Work Breakdown Structure (WBS) Formal term for task structure


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


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


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


Typical Project Plan Outline


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.


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


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


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.


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


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


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


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


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


System specification

Software requirement specification



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


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


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.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


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 testing


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


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


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

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


information.information. ElementsElements SoftwareSoftware HardwareHardware PeoplePeople DatabaseDatabase DocumentationDocumentation ProceduresProcedures

System of Systems -- ExampleSystem of Systems -- Example


The System EngineeringHierarchy

A hierarchy of views are necessary, for A hierarchy of views are necessary, for example,example, World ViewWorld View


World ViewWorld View

Domain ViewDomain View

Element viewElement view

Detailed ViewDetailed View

Typical HierarchyTypical Hierarchy


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


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


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.


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)


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


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


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


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


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


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


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



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,


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


Business Area Analysis

Establishes a detailed framework for Establishes a detailed framework for building an informationbuilding an information--based enterprisebased enterprise

ModelsModels


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


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


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


With Information FlowWith Information Flow


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


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


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


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


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


Cost AnalysisCost Analysis


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


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


CLSS ExampleCLSS Example


Expanded ExampleExpanded Example


Building a HierarchyBuilding a Hierarchy


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.


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


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


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


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


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


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)


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


Facilitated Application Specification Facilitated Application Specification Techniques (FAST)Techniques (FAST) Refinement with subgroupsRefinement with subgroups


Refinement with subgroupsRefinement with subgroups


Quality Function DeploymentQuality Function Deployment Normal RequirementsNormal Requirements

What will make customer happyWhat will make customer happy


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


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


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


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


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


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


PrototypingPrototyping

Highly desirableHighly desirable Clarify requirementsClarify requirements

Identify missing requirementsIdentify missing requirements


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


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


Must be capable of making requirements decisions Must be capable of making requirements decisions in timely mannerin timely manner


Methods and toolsMethods and tools Fourth Generation Techniques Fourth Generation Techniques ---- program program

application generatorsapplication generators


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


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


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


Specifications ReviewSpecifications Review

Macroscopic LevelMacroscopic Level View from the topView from the top Goals met ?Goals met ?

Alternatives explored ?Alternatives explored ?


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..


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


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


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


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


August 200335


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


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


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


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


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;


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;…


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



s: A.shuttle;

x_coord: float;

…

Module B body

Sep. 2003 18



end record;

…

s := A.get;

A.display(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



s: A.shuttle;

x_coord: float;

…

Module B body

Sep. 2003 28



end record;

…

s := A.get;

A.display(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


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


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


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


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


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


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


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.


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


– Main Program/Subprogram– Remote procedure call

Object-oriented architectures Layered architectures

Organization and refinement Control Data


Objective develop a modular program structure and

represent control relationships between modules

Data flow-oriented design


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


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


A Btransformcenter

incoming flow outgoing flows

C

Architectural Design Process(cont.)

Transaction Flow

TransactionAction


T

Transactioncenter

Actionpaths

Transform Mapping

Allow data flow diagram(DFD) with transform flow characteristics to be mapped into a predefined template for


mapped into a predefined template for program structure

Level 0 Safehome DFD


Level 1 Safehome DFD


Level 2 Safehome DFD - Monitor


Transform Mapping (cont)

Design steps Step 1. Review the fundamental system

model.


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



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


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



step 6. Perform “second-level factoring”– mapping individual transforms(bubbles) to

appropriate modules.

– factoring accomplished by moving outwards


– 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


First-Cut Program Structure


Refined Program Structure


Transaction Mapping

A single data item triggers one or more information flows


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


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


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


First Level Factoring


First-cut Program Structure


Transaction Mapping (cont)

step 6. Factor and refine the transaction structure and the structure of each action path


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


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


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


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


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


Notations Flow charts

Tabular

Program Description Language

FLOWCHARTS


TABULAR NOTATION


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;


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


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


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:


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


• 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


– 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


– 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


•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


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


– 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


• 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


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


– 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


• 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


– 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


– 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


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


Queuing Model


Queuing Reduction Rules


Simplifying Networks


Simulation and modeling tools

• The conceptual view– Functional view is captured with activity-

charts, which are similar to conventional DFD


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


Statechart for Example



• The physical view– The conceptual model is the foundation, but not

a real system– Decompose a system into subsystem,


– 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


• Running scenarios– Correctness of function or behavior

– Engineer can play role of user & enter tests


– 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


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


– 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


– 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-


• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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


• 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?


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?


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?


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


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


April 2004 SRIMCA18


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


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.


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


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.


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 Debugging process

Execution of test cases Results

April 2004 SRIMCA32

Test cases

Results

Debugging

Suspected causes

Additional tests

Identified causesCorrections

Regression tests


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


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.


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


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


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.


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


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


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


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).


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


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.


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.


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


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


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


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


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


S3 = # modules dependent upon prior processing

S4 = total number of database itemsS5 = # unique database itemsS6 = # of database segmentsS7 = # modules with single entry & exit


D1 = 1 if arch design method used, else 0

D2 = 1 - (S2/S1) -- module independence

D3 = 1 - (S3/S1) -- independence of prior


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



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


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


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


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


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


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


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


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


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.


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


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


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


• 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


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.


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


Object ClassesThus, a class is an abstraction that describes

relevant properties and hides the rest. Represented diagrammatically as below.


Class Name

Attributes

Operations

Object Modeling


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.


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


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


Class and Instance

Polygon

VerticesBorder Color

Polygon

v={(0,0),(0,1),(1,0)}BC = Red


Border ColorFill Color

DrawEraseMove

BC = RedFC = Blue

DrawEraseMove

Abstraction and Encapsulation


Abstraction• Isolate those aspects that are important and

suppress (or hide) those that are unimportant (e.g., representations).



(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



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


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.


Class and Subclass

Polygon

VerticesBorder Color

Right Triangle

VerticesHypotenuse length


Border ColorFill Color

DrawEraseMove

Hypotenuse lengthBorder Color

Fill Color

DrawEraseMove

••

OperationsPolymorphism

•The same “operation” may behave differently on different classes. E.g., the move operation behaves differently on a Window and ChessPiece.


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


Triangle

Paint

Square

Paint

CommunicationMessage: [destination, operation, params]


What Does OO Mean?Pressman (Coad & Yourdon)

• Objects (identity)• Classification• Inheritance


• 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


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


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


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.

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


• 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


Ternary Association


Link Associations


AggregationA “part-whole” or “a-part-of” relationship


OO Software ProcessFramework

• Identify major classes and connections.• Do enough design to ensure they are implementable• Extract reusable components and build prototype.


• 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


• 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


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.,


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


• 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


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


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?


• 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


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


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


• 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:


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


• 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


• 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,


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


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


• 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


• 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


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


– 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


• 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


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.


• 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


Subjectsand Sub-


systems

OOAmodelwith


with

Subjectreferences

Safe Home Level 1 DFD


OOA ProcessClass-Responsibility-Collaborator Modeling:

• A means of identifying and organizing classes relevant to the system.

Responsibilities:


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:


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.


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


Determine

sensor

status

Associations & OperationsCollaborations suggest operations

Control Panel Sensor


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.


• 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


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.


• 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.


• 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


Event Trace


Partial Event Flow Diagram


SummaryOOA begins with use cases.Create object, functional and dynamic modelsObject Analysis

• model as objects, attributes and operations.


• 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


System Design

Object Design

Design patterns &

Conclusion

Object-Oriented DesignTransforms OOA model into blueprint for

software construction

Builds upon four essential design concepts


Builds upon four essential design concepts• Abstraction

• Information hiding

• Functional independence

• Modularity

Mapping OOA to OOD



Design

Design Issues


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


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


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


The Jacobson Method

The Rumbaugh Method

The Wirfs-Brock Method

Booch MethodArchitectural planning

• Cluster similar objects in separate architectural partitions.


• 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.


• 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.


• 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


Adjust class structure to strengthen inheritance

Design messaging to implement the object relationships

Package classes and associations into modules


Design

Design Issues


System Design

Object Design

Design patterns &

Conclusion

OOD Process Flow


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.


• 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


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


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


System DesignCohesion

Goi

ng t

owar

ds H

igh

Coh

esio

n

Coincidental

Logical

Temporal


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


• independent processor ? -- may still need concurrency control

Allocation and design issues:• performance requirements.• costs• overheads and efficiency

Concurrency Example

Database

•DB access

•


•

•

•

•

•

DB access

Concurrency

Ada -- Use taskstask type DB_access is … end;

type dba is access DB_access;


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 () { …}


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


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


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


• 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, ...)


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


Subsystem Collaboration GraphList each request made by a collaborator



Design

Design Issues


System Design

Object Design

Design patterns &

Conclusion

Object Design


Key Object Characteristics(Available from Analysis)

Object name (or name of class of objects)DescriptionServices provided or functions


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


• 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


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


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


Review object-relationship model

Describe operations and transitions using PDLs.


Design

Design Issues


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)


• 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


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


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.


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


Testing OOA & OOD ModelsTesting OOA & OOD ModelsCorrectness of OOA & OOD Models

• Judge by conformance with real world domain

Consistency of OOA & OOD Models


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.


• 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


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:


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.


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


• 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,


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.


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


Behavior Testing ModelsEnsure coverage of all states and transitions.


THE PRESENTATION-BY

Chapter 22

February 8, 1998 -- R. A. Volz 15