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 web generation problem? How long would it take you to do the attached web generation problem?

July 03

Chapter 1

1

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? Maple.exe = 1.3 Mbytes.-- System over 3.8 Mbytes Netscape.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?
July 03 Chapter 1 2

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? Why is it so difficult to measure software development progress? 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?
July 03 Chapter 1 3

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 1

4

Some Software Characteristics
 In theory, software does not wear out at all.

 BUT, Hardware upgrades. Software upgrades.
July 03 Chapter 1 5

Some Software Characteristics
 Thus, reality is more like this.

Most serious corporations control and constrain changes  Most software is custom built, and customer never really knows what she/he wants.
July 03 Chapter 1 6

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

July 03

Chapter 1

7

Types of Software Applications
 Systems Software  Real Time Software  Business Software  Engineering & Scientific Software  Embedded Software  Personal Computer Software  Web Based Software  Artificial Intelligence Software

July 03

Chapter 1

8

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 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.
July 03 Chapter 1 9

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 1

10

Percent Maintenance Historgram
35%

30%

25%

20%

15%

10%

5%

0% (0,15] (15,30] (30,45] (45,60] (60,75]

July 03

Chapter 1

11

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.  Myth: The only deliverable that matters is working code. 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.
July 03 Chapter 1 12

35%

31% 30%

25%

25%

20%

15% 13%

10%

8% 6%

5%

0% <=2 (2.4] (4,6] Estimate in weeks (6,8] (8,10]

July 03

Chapter 1

13

SLOCs per Year Histogram
40% 35% 30% 25% 20% 15% 10% 5% 0% (0,5k]
July 03

(5k,10k]
Chapter 1

(10k,20k]

(20k,50k]

>50k
14

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 efficiently on real machines. Software Engineering is a layered technology.

August 2003

Chapter 2

1

A Layered Technology
Tools Editors Design aids Compilers Computer Aided Software Engineering (CASE) Methods Includes standards (formal or informal) May include conventions, e.g., low level such as naming, variable use, language construct use, etc. May involve design methodologies. Chapter 2

August 2003

2

Some Generic Engineering Phases
Definition
System or information engineering (leading to requirements) Software project planning Requirements analysis

Development
Software design Coding Testing
August 2003 Chapter 2 3

Some Generic Engineering Phases
Maintenance
Correction -- bugs will appear Adaptation -- to changing operating systems, CPU’s, etc. Enhancement -- changing customer needs Prevention -- software reengineering

August 2003

Chapter 2

4

Some Generic Engineering Phases
Typical activities in these phases
Project tracking and control Formal reviews Software quality assurance Configuration management Documentation Reusability management Measurement Risk management
Chapter 2

August 2003

5

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 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.
August 2003 Chapter 2 6

Key Process Areas
Maturity Level 2 Software Configuration Management Software Quality Assurance Subcontract management Project tracking and oversight Software project planning Requirements management

August 2003

Chapter 2

7

Key Process Areas
Maturity Level 3 Peer Reviews Intergroup coordination Integrated software management Training program Organization process definition Organization process focus

August 2003

Chapter 2

8

Key Process Areas
Maturity Level 4 Software quality management Quantitative process management Maturity Level 5 Process change management Technology change management Defect prevention
Chapter 2

August 2003

9

Software Process Models

August 2003

Chapter 2

10

Waterfall Model
System/Information Engineering Requirements Analysis Design Code

Test

Maintain

August 2003

Chapter 2

11

The Prototyping Model

August 2003

Chapter 2

12

The RAD Model
Business Modeling
Business Modeling Data Modeling

Data Modeling

Process Modeling Application Generation Testing & Turnover

Process Modeling

Application Generation 60 – 90 days
August 2003 Chapter 2

Testing & Turnover
13

RAD Model
 Business Modeling What info. Drives the business process? What info. Is generated? Who generates it? Where does the info go? Who processes it? Etc..  Data Modeling Refinement from business model into data objects Characteristics of object identified and relationships between objects are defined.
August 2003 Chapter 2 14

RAD Model
 Process Modeling Data objects are transformed to achieve the info. flow Process desc. added for adding, modifying, deleting or retrieving a data object  Application Generation Use of 4GL techniques Automated tools use for construction of S/W  Testing & Turnover Testing time is less bcoz of reusable components Only new components tested and interfaces
August 2003 Chapter 2 15

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

August 2003

Chapter 2

16

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

August 2003

Chapter 2

17

Evolutionary Process Models
 The Incremental Model

August 2003

Chapter 2

18

Evolutionary Process Models
The Spiral Model
Proposed by Boehm Couples iterative prototyping with controlled and 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

August 2003

Chapter 2

19

Evolutionary Process Models
The Spiral Model
Concept Development Projects New Product Development Projects Product Enhancement Projects Product Maintenance Projects

Project Entry Point Axis

August 2003

Chapter 2

20

The Spiral Model – Task Regions
 Customer Communication
Tasks reqd. to establish effective comm. between developer and customer

 Planning
Tasks required to define resources, timelines & other project related info.

 Risk Analysis
Tasks required to assess both technical and mgt. Risks

 Engineering
Tasks required to build one or more representations of the application

 Construction & Release
Tasks required to construct, test, install, and provide user support (e.g. documentation and training)
August 2003 Chapter 2 21

The WinWin Spiral Model

August 2003

Chapter 2

22

The WinWin Spiral Model

August 2003

Chapter 2

23

The Concurrent Development Model

August 2003

Chapter 2

24

The Concurrent Development Model
     CDM is driven by user needs, mgt. decision and review results All activities exist concurrently, but reside in different states A state is some externally observable mode of behavior CDM is used for developing Client/Server applications 2 dimensions – System and Component dimension 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
August 2003 Chapter 2 25

The Component Assembly Model

August 2003

Chapter 2

26

The Component Assembly Model

August 2003

Chapter 2

27

Other Models
Formal Methods
Rigorous mathematical representation of requirements Provides basis for automatic verification test generation Fourth Generation Techniques Use code generators to produce specific parts of product Process Technology Provides a variety of tools to aid software developers, e.g., workload flow, configuration management, quality assurance management, etc. Chapter 2

August 2003

28

Project Management Concepts
Why is project management important?
Cost
Dod already spending $30 billion annually on software in late 80’s The 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
January 2004 Chapter 3 – R. S. Pressman SRIMCA 1

Why Do Major Engineering Undertakings Often Fail?
Large projects often fail for two principal reasons:
Communication: Inadequate communication leads to project failure Coordination: 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.
January 2004 Chapter 3 – R. S. Pressman SRIMCA 2

The Spectrum of Management Concerns
Effective Software management encompasses three main areas:
People The product The process The project

January 2004

Chapter 3 – R. S. Pressman

SRIMCA

3

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. Project Managers - who plan, motivate, organize and control the practitioners Practitioners - who deliver the technical skill that are necessary to engineer the project Customers - who specify the requirements End users - who interact with the software once it is released. Chapter 3 – R. S. Pressman SRIMCA January 2004
4

Team Leadership -- A Critical Item
The Problem
The best programmers often make poor team leaders. Different skills are required. Technical leadership model Motivation - 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 withinS.aPressmanof restrictions. set SRIMCA Chapter 3 – R. January 2004

5

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. 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. 3 – R. S. Pressman SRIMCA Chapter January 2004
6

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 modularized. The required quality and reliability of the system. The rigidity of the delivery date. The degree of communication required for the project.
January 2004 Chapter 3 – R. S. Pressman SRIMCA 7

Impact of Project Characteristics

January 2004

Chapter 3 – R. S. Pressman

SRIMCA

8

Other Underlying Organizational Factors
Matrix model The organization has divisions organized by skills, e.g., engineering, safety and mission assurance (SMA), human factors, etc. Projects “rent” people from the divisions, as needed. Issues Who evaluates person for raises? Independence of reporting for safety & quality issues? Who is boss?
January 2004 Chapter 3 – R. S. Pressman SRIMCA 9

How Do We Communicate?
Informally - Good phone/electronic service, a clear definition of group interdependencies and good relationships help encourage communication Meetings - Regular project meetings help alleviate minor misunderstandings Workbook - a formal project workbook must be started from the beginning.
January 2004 Chapter 3 – R. S. Pressman SRIMCA 10

Project Coordination techniques
Formal, impersonal approaches - software engineering documents and deliverables, technical memos, project milestones, schedules and control tools Formal interpersonal procedures - quality assurance activities - reviews and design and code inspections Informal, interpersonal procedures - group meetings Electronic communication - Email, bulletin boards, web sites, extension and video conferences Interpersonal network - discussions with those outside of the project.
January 2004 Chapter 3 – R. S. Pressman SRIMCA 11

A Study on the Impact of Coordination Techniques

January 2004

Chapter 3 – R. S. Pressman

SRIMCA

12

The Product
Must first determine project scope. Context - How does this software to be built fit into the larger system? What constraints are imposed as a result of this? Information objectives - What customer-visible 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.
January 2004 Chapter 3 – R. S. Pressman SRIMCA 13

The Process
Select a software engineering model. Project framework. Customer communication. Planning -- determine resources, time line & other info. Risk analysis -- assess technical and management risks Engineering -- build one or more representations of the product. Construction and release -- construct, test, install and provide user support. Customer evaluation -- obtain feedback on product Chapter 3 – R. S. Pressman SRIMCA January 2004
14

Common Process Framework Activities

January 2004

Chapter 3 – R. S. Pressman

SRIMCA

15

Process Decomposition
Typical activities Review the customer request. Plan and schedule a formal, facilitated meeting with the customer. 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.
January 2004 Chapter 3 – R. S. Pressman SRIMCA 16

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 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.
January 2004 Chapter 3 – R. S. Pressman SRIMCA 17

CHECKOUT & LAUNCH CONTROL SYSTEM
Delivery Process Presentation to the Aerospace Safety Advisory Panel

March 19, 1998

1

SYSTEM ENGINEERING AND INTEGRATION IN CLCS
System Engineering And Integration

System Design
• System Level Requirements • Hardware Architecture • Software Architecture • Performance Analysis

Strategic Engineering
• Delivery Planning • Thread Definition

System Integration and Test
• System Level Integration • System Level Testing • Delivery Management • System Analysis

Specialty Engineering
• Quality Assurance • Human Factors • Quality Engineering

2

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 • Hardware Status Reviews - Reviews Provided at Those Times in the Project Development Cycle Which Coincide With Significant Hardware and Software Procurement Activities

3

SYSTEM ENGINEERING AND INTEGRATION TERMINOLOGY
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 Network

Command Control Processor

Data Distribution Processor

Archive And Retrieval Display and Control Network

Human Computer Interface

Thread Statement of Work –A conceptual description of a capability that considers the implementation of the System Level and Product Level Requirements

4

CLCS DELIVERY THREAD MATRIX
JUNO 3/97
Demos Ice Team Support LCC X Demo Consolidated SDS CLCS Consolidated SDS SLWT Monitor HMF Pathfinder

REDSTONE 9/97
HMF Demo GSE Demo SLWT Demo

THOR 3/98
Fuel Cell Support SLWT Test Stress Test 1 System Capability Demo 1 Consolidated SDS Turnover IVHM SLWT IPT HMF IPT Orbitor Power IPT

ATLAS 9/98
Haz Gas IVHM Stress Test 2 System Capability Demo 2 RPS Haz Gas(req) HMF IPT Orbitor Power IPT GSE Phase 1 IPT

TITAN 3/99
HMF Operational Sail Certification Stress Test 3 Performance Validation LISI/CWLIS SSME HMF IPT Orbitor Power IPT GSE Phase 1 IPT GSE Phase 2 IPT OPF Final CITE Intg Ops Launch Control Performance Modeling System Testing End to End Gateway 2 Gateway Ph 1(req) PCM SSME LDB Interface Ph 3 Uplink Support Ph1 Safing System DDP Ph 1

Ops Improvments Application Sets

Launch Control Project Support Gateways GSE Link Support Ph 1 Open System Pathfinder Performance Modeling Regression Testing Pathfinder End to End Gateway 1 GSE Link Support Ph 2 PCM Support Ph 1 LDB Interface Ph 1 Open System Demo Performance Modeling System Testing PCM Support Ph 2 LDB Interface Ph 2 T iming System Safing System Data Handling & Routing (req)

Data Handling

Reliable Message Ph 1

Display Command and Control System Control

Reliable Message Ph 2 Data Distribution Data Fusion Data Health User Display Monitoring Plotting Pathfinder User Commanding Ph 1

Reliable Message Ph 3 Data Distribution Data Fusion Data Health System Viewers User Commanding Ph 2 Constraint Manager Ph 1 TAS Pathfinder End Item Manager System Integrity Ph 1

HCI Ph 1 User Commanding Ph 3(req) Constraint Manager Ph 2 End Item Manager Redundancy Management Ph 1 Check Point Restart Ph1 System Control Ph 1

HCI Ph 2(req) User Commanding Ph 4(req) OCF-TCS TAS (under review) CCP Ph 1 Master Console Ph 1 Redundancy Management Ph 2 System Security Check Point Restart Ph2 Resource Management Ph 1 System Control Ph 2 ORT External Center Support

BASIS Development Simulation Simulation I/F to RTCN Ph 1 SDC Set Build and Load Ph 1 Test Build, Load, & Act Ph 1 Sys SW Development Development Environment Application Debug Config

Basis Pathfinder Advance Retrieval Basic Real-Time Advisory Desk Top Development Simulation I/F to RTCN Ph 2 SDC Transistion Log Record and Retrieval Ph 1

Basis Transition Support Advance Retrieval Basic Real-Time Advisory Simulation Release

Simulation I/F to RTCN Ph 3 SDC Operational Log Record and Retrieval Ph 2 Set Build and Load Ph 2 Test Build, Load, & Act Ph 2 Log Record and Retrieval Ph 3 Test Build, Load, & Act Ph 3

5

CLCS SYSTEM DESIGN PROCESS
System Level Requirements Thread Statement of Work System Design Issues

Issue Resolution Teams

Engineering Review Panel

Design Panel Process • Concept • Requirements • Detail

OR

• CSCI/HWCI Requirements and Design Docs

• SLS, SDD

6

CLCS DESIGN PANEL PROCESS

Process is Managed by The Design Panel Chairman Minutes are kept by Design Panel Secretary

Design Panels Provide the System Engineering and Development Community a Method of Communicating. Allow the User Communities to Gain Significant Insight Throughout the Incrementally Help to Meet the Intent of Preliminary Design Reviews and Critical Design Reviews As Discussed in MILSTD-2167, MIL-STD-498

7

CLCS DESIGN PANEL PROCESS - THREE STEPS
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 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

8

CLCS DESIGN PANEL PROCESS
Project User

Concept Design Panel

Requirements Design Panel

Detailed Design Panel

Delivery Capability Agreement Thread Kick-off

Thread Lead and CSCI/HWCI Leads System Engineering Work Session • Thread Concept • CI Impacts Assessment • Schedule CSCI/HWCI Developer Work sessions • Refined Concept • Prelim. Product Specifications • Prelim. Test Plans CSCI/HWCI Developer Work sessions •Refined Product •Specifications •Refined Data Flows •Refined Specs

9

Software Process and Project Metrics
 Outline: In the Software Metrics Domain: product metrics project metrics process metrics Software Measurement size-oriented metrics function-oriented metrics Metrics for Software Quality
March 2004 Chapter 4 – R. S. Pressman SRIMCA 1

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 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.
March 2004 Chapter 4 – R. S. Pressman SRIMCA 2

In the Process and Project Domains
 Process Indicator enable insight into the efficacy of an existing process to assess the current work status Goal -- to lead to long-term software process improvement  Project Indicator assess the status of an ongoing project track potential risks uncover problem areas before they go “critical” evaluate the project team’s ability to control the product quality
March 2004 Chapter 4 – R. S. Pressman SRIMCA 3

Process Metrics and Software Process Improvement
Project

Customer characteristics Process

Business conditions

People

Development environment
Chapter 4 – R. S. Pressman

Technology

March 2004

SRIMCA

4

Measurement
 What to measure? errors uncovered before release defects delivered to and reported by end users work products delivered human effort expended calendar time expended schedule conformance  At what level of aggregation? By team? Individual? Project?
March 2004 Chapter 4 – R. S. Pressman SRIMCA 5

Privacy Issues
 Should they be used for personnel evaluation?  Some issues? Privacy?  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.
March 2004 Chapter 4 – R. S. Pressman SRIMCA

6

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  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.
March 2004 Chapter 4 – R. S. Pressman SRIMCA 7

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 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.
March 2004 Chapter 4 – R. S. Pressman SRIMCA 8

Typical Causes of Product Defects

March 2004

Chapter 4 – R. S. Pressman

SRIMCA

9

Example of Defect Analysis
missing ambiguous specification defects
wrong customer queried
customer gave wrong infor.

inadequate inquiries
used outdated information
March 2004

incorrect
Chapter 4 – R. S. Pressman

changes
SRIMCA 10

Project Metrics
 Software Project Measures Are Tactical used by a project manager and a software team to adapt project work flow and technical activities  The Intent of Project Metrics Is Twofold to minimize the development schedule to avoid delays and mitigate potential problems and risks to assess project quality on an ongoing basis and modify the technical approach to improvement quality  Production Rates pages of documentation review hours function points delivered source lines errors uncovered during SW engineering tasks
March 2004 Chapter 4 – R. S. Pressman SRIMCA 11

Software Metrics
 Direct measures Cost and effort applied (in SEing process) Lines of code(LOC) produced Execution speed CPU utilization Memory size Defects reported over certain period of time  Indirect Measures Functionality, quality, complexity, efficiency, reliability, maintainability.
March 2004 Chapter 4 – R. S. Pressman SRIMCA 12

Software Measurement
 Size-Oriented Metrics are 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.
project LOC effort 24 62 43 $(000) 168 440 314 pp.doc 365 1224 1050 errors 134 321 256 defects 29 86 64 people 3 5 6

alpha 12,100 beta 27,200 gamma 20,200

. . . .

. . .

. . .

. . .

. . .

March 2004

Chapter 4 – R. S. Pressman

SRIMCA

13

Typical Size-Oriented Metrics
 Errors per KLOC  Defects per KLOC  Dollars per KLOC  Pages of documentation per KLOC  Errors per person month  LOC per person month  Dollars per page of documentation

March 2004

Chapter 4 – R. S. Pressman

SRIMCA

14

Software Measurement
 Function-Oriented Metrics use “functionality” to measure derived from “function point” 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 project Normalizing other metrics, e.g., $/FP, errors/FP

March 2004

Chapter 4 – R. S. Pressman

SRIMCA

15

Function Point Calculation

measurement parameter number of user inputs number of user outputs # of user inquiries number of files # of external interfaces count_total

count * * * * *

Weighting Factor simple average complex 3 4 3 7 5 4 5 4 10 7 6 7 6 15 10 = = = = =

March 2004

Chapter 4 – R. S. Pressman

SRIMCA

16

Function Point Calculation
Computing function points
Rate each factor on a scale of 0 to 5 1 2 3 4 5 6

no influence

incidental

moderate

average

significant

essential

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?
March 2004 Chapter 4 – R. S. Pressman SRIMCA 17

Function-Oriented Metrics
FP = count_total * [0.65 + 0.01 * sum of Fi]
Outcome: errors per FP defects per FP $ per FP page of documentation per FP FP per person_month

March 2004

Chapter 4 – R. S. Pressman

SRIMCA

18

Function Point Extensions
 Function Points emphasizes “data dimension”  Transformations added to capture “functional dimension”  Transitions added to capture “control dimension”

March 2004

Chapter 4 – R. S. Pressman

SRIMCA

19

3-D Function Point Calculation

March 2004

Chapter 4 – R. S. Pressman

SRIMCA

20

Reconciling Different Metrics

March 2004

C++ Visualbasic

Chapter 4 – R. S. Pressman

64 SRIMCA 32

21

Metrics for Software Productivity
 LOC and FP Measures Are Often Used to Derive Productivity Metrics  5 Important Factors That Influence SW Productivity people factors problem factors process factors product factors resource factors

March 2004

Chapter 4 – R. S. Pressman

SRIMCA

22

Measures of Software Quality
 Correctness is the degree to which the software performs its required function. the most common measure for correctness is defects per KLOC (per year)  Maintainability the 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
March 2004 Chapter 4 – R. S. Pressman SRIMCA 23

Measures of Software Quality (Cont’d)
 Integrity to 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 use the net increase in productivity user attitudes toward system
March 2004 Chapter 4 – R. S. Pressman SRIMCA 24

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 the end user D = # of defects found after delivery  More generally, DREi = Ei / ( Ei + Ei+1 ) Ei = # of errors found during SE activity i
March 2004 Chapter 4 – R. S. Pressman SRIMCA 25

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.
March 2004 Chapter 4 – R. S. Pressman SRIMCA 26

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: 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
March 2004 Chapter 4 – R. S. Pressman SRIMCA

27

Summary View

March 2004

Chapter 4 – R. S. Pressman

SRIMCA

28

Summary
 Metrics are a tool which can be used to improve the productivity and quality of the software system  Process metrics takes a strategic view to the effectiveness of a software process  Project metrics are tactical that focus on project work flow 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
March 2004 Chapter 4 – R. S. Pressman SRIMCA 29

METRICS
 CLCS Metrics Philosophy
Phase 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.
March 2004 Chapter 4 – R. S. Pressman SRIMCA 30

METRICS
System Software
Milestones Redston e CIT Complet e Thor CIT Complet e Jul-98 0.0 0.0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Atlas CIT Complet e Aug-98 0.0 0.0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 TOTAL 23 151 155 130 459 19 98 103 86 306

Month/Year Software Size (KSLOC) Actual Size of Executable Code Code Delivered Comments Razor Issue Closure Issues Opened Urgent (this month) Critical Major Minor Total: Issues Closed Urgent (this month) Critical Major Minor Total: Current Issues Open: Urgent Critical Major Minor Total: Error Density: Issues / KSLOC

Sep-97 Oct-97 Nov-97 Dec-97 Jan-98 Feb-98 Mar-98 Apr-98 May-98 Jun-98 377.2 377.2 383.3 388.1 450.2 554.3 214.1 214.1 218.2 221.3 250.6 319.3 0.0 0.0 0.0 0.0 163.1 163.1 165.1 166.8 199.6 242.1 0.0 0.0 0.0 0.0 9 54 60 57 180 6 36 39 27 108 3 18 21 30 72 0.84 3 19 16 17 55 6 26 24 17 73 0 11 13 30 54 1.10 2 8 20 6 36 1 11 12 19 43 1 8 21 17 47 1.24 0 1 5 0 6 1 0 4 5 10 0 9 22 12 43 1.25 4 16 28 13 61 3 13 14 2 32 1 12 36 23 72 1.35 5 53 26 37 121 2 12 10 16 40 4 53 52 44 153 1.44 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

March 2004

Chapter 4 – R. S. Pressman

SRIMCA

31

Software Project Planning
 Observations on Estimating Estimation of Resources, Cost and Schedules Factors affecting estimation Project Complexity Project Size Degree of Structural uncertainty

March 2004

Chapter 5 Software Project Planning 1

Software Project Planning
 Steps to Software Planning Define Software Scope Determine Resources Create Project Estimates Make or buy decision

March 2004

Chapter 5 Software Project Planning 2

Scope
 What scope means: Functions Literally refers to all functions performed by a system Performance Refers to processing and response time requirements Constraints Limits placed on the software by external hardware, available memory or existing systems Interfaces Reliability
March 2004 Chapter 5 Software Project Planning 3

Scope
 Obtaining the information Communication, communication, communication!!! Meet with customer as often as needed. Have free form discussion Try 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.
March 2004 Chapter 5 Software Project Planning 4

Scope Information
 Some typical questions Overall Goals Who’s request; What benefit; Who else has solution Understanding The Problem What output; What Problem; What Issues; What Constraints Effectiveness of Meeting Are answers official; Are my questions relevant; Other sources of Info.

March 2004

Chapter 5 Software Project Planning 5

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  Organization of Information Get everything down with diagrams Create and save transcripts of Meetings Possibly use Web.

March 2004

Chapter 5 Software Project Planning 6

Scoping Example
Conveyor Line Motion ID No. ID No. ID No. ID No. Bin 1 Bin 2 Bin 3 Bin 4
Control connection
March 2004 Chapter 5 Software Project Planning 7

Shunt
Bar Code

Sorting Station

Bin 5

Project Decomposition
 For our example: Read bar code input Read pulse tachometer Decode part code data Do database lookup Determine bin location Produce control signal for shunt Maintain record of box destinations

March 2004

Chapter 5 Software Project Planning 8

Resources

March 2004

Chapter 5 Software Project Planning 9

Resources
 For each type of resources, 4 characteristics are examined: Description of resource Availability Time resource needed Duration of time for which the resource is needed

March 2004

Chapter 5 Software Project Planning 10

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.

March 2004

Chapter 5 Software Project Planning 11

Reusable Software Resources
 Off-the-shelf components Existing s/w acquired from 3rd party, fully validated  Full experience components Existing specs, code or test data developed for past projects  Partial experience components New validation will have to be performed  New Components

March 2004

Chapter 5 Software Project Planning 12

Environmental Resources
 Software Engineering Environment Compilers Editors Design tools Configuration management tools Management tracking tools Problem Reporting And Corrective Action (PRACA) tools Documentation tools Hardware resources Network support
March 2004 Chapter 5 Software Project Planning 13

Software Project Estimation
 Estimation critical -- software costs usually dominate project.  Categories of estimation techniques Delay estimation until late in the project Base estimates on similar projects already completed 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))
March 2004 Chapter 5 Software Project Planning 14

Decomposition Techniques
 Software Sizing The degree of the size of product estimated Ability to translate size estimate into human effort, calendar time, dollars 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

March 2004

Chapter 5 Software Project Planning 15

Software Sizing
 4 approaches to Software Sizing problem “Fuzzy Logic” Sizing Function Point Sizing Standard Component Sizing Change Sizing  These methods can be combined statistically to create a ThreePoint or expected value estimate  Done by developing Optimistic(low), most likely, and pessimistic(high) values for size and combining them in equation

March 2004

Chapter 5 Software Project Planning 16

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

March 2004

Chapter 5 Software Project Planning 17

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 user interface and control facilities 2-D geometric analysis 3-D opt = 4600 LOC 3-D geometirc analysis 3-D m. likely = 6900 LOC database management 3-D pess. = 8600 LOC computer graphics display => (4600+4*6900+8600)/6 peripheral control = 6800 design analysis models
March 2004 Chapter 5 Software Project Planning 18

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
Chapter 5 Software Project Planning 19

March 2004

Function Point Based Estimation
 Function Point Complexity Weighting Factors backup and recovery 4 Data communications 2 Distributed processing 0 Performance critical 4 Existing operating environment 3 On-line data entry 4 … Application designed for change 5 Total 52
March 2004 Chapter 5 Software Project Planning 20

Function Point Based Estimation

 Complexity factor = [0.65  0.01  Fi ] = 0.65+0.01×52 = 1.17  FP estimate = count-total× [0.65 0.01 Fi ] = 318 × 1.17 = 372  Then, if 6.5 FP/PM, cost = 372 × $8,000 ÷ 6.5 = $457,000 and 58 person months Chapter 5 Software Project Planning March 2004
21

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  If estimated separately, then there are two or three distinct cost estimates. Reconcile differences If radically different, perhaps problem is not well understood, or productivity data is obsolete, or the models have not been used correctly.
March 2004 Chapter 5 Software Project Planning 22

Process Based Estimation -- Example
Customer Activity Communication Planning Risk Analysis
Task

Engineering
Analysis Design

Customer Evaluation Construction Release
Code Test

Function UICF 2DGA 3DGA DSM CGDF PCF DAM Total % effort 0.25 1% 0.25 1% 0.25 1% 0.50 0.75 0.50 0.50 0.50 0.25 0.50 3.50 8% 2.50 4.00 4.00 3.00 3.00 2.00 2.00 20.50 45% 0.40 0.60 1.00 1.00 0.75 0.50 0.50 4.75 10% 5.00 2.00 3.00 1.50 1.50 1.50 2.00 16.50 36% n/a n/a n/a n/a n/a n/a n/a

• If labor rate is $8,000/PM, then Est. cost = $368,000
March 2004 Chapter 5 Software Project Planning 23

Empirical Estimation Models
 Based on limited number of sample projects Typical form E = A + B×(ev)C  Some examples E = 5.2×(KLOC)0.91 Walston-Felix Model E = 5.5 + 0.73×(KLOC)1.16 Bailey-Basili Model E = 3.2×(KLOC)1.05 Boehm simple model E = 5.288×(KLOC)1.047 Doty model for KLOC > 9 E = -13.39 + 0.0545×FP Albrecht & Gaffney E = 60.62 + 7.728×10-8FP3 Kemerer Model E = 585.7 + 15.12×FP Albrecht & Gaffney  Must calibrate for local conditions
March 2004 Chapter 5 Software Project Planning 24

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
March 2004 Chapter 5 Software Project Planning 25

COCOMO II
 Object point is computed using count of 1. Screen 2. Report & 3. Components required to build the application Object Type Simple Screen Report 3GL comonent 1 2 Complexity Weight Medium 2 5

Difficult 3 8 10

 NOP = (object points) * [(100 - %reuse)/100]; NOP -> new object points  Productivity rate = NOP/person-month
March 2004 Chapter 5 Software Project Planning 26

COCOMO II
Developers experience/capability Environment maturity/capability PROD  Estimated effort = NOP/PROD Very low Very low 4 Low Low 7 Nominal Nominal 13 High High 25 Very High Very High 50

March 2004

Chapter 5 Software Project Planning 27

“The Software Equation”
 The software equation -- E=[LOC * B0.333/P]3 * (1/t4), where E = effort in person months t = project duration in months B = “special skills factor” For KLOC (5, 15) use 0.16, for KLOC > 70, use B = 0.39 P = “productivity parameter” reflecting overall process maturity and management practices extent to which good software engineering used state of software environment skill and experience of team complexity of application
March 2004 Chapter 5 Software Project Planning 28

Software Equation Example
 Typical productivity values P e.g., 2,000 for real-time, 10,000 for tele-comm, 28,000 for business applications.  Simplified model suggested for tmin, E: tmin = 8.14(LOC/P)0.43 in months for tmin > 6 months E = 180Bt3 for E >= 20 person months  For P = 12,000 (typical scientific computation) tmin = 8.14(33,200/12,000)0.43 = 12.6 months E = 180(0.28)(1.05)3 = 58 person months  Study implications of these equations. Trying to get done too fast requires much more effort.
March 2004 Chapter 5 Software Project Planning 29

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

March 2004

Chapter 5 Software Project Planning 30

Resources - Make-Buy Decision
 Develop specification for desired software  Estimate cost to develop internally and estimate delivery date  Select candidate applications that come closest to meeting specifications.  Select reusable components that could assist constructing the 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
March 2004 Chapter 5 Software Project Planning 31

Resources - Make-Buy Decision
 Make/Buy decision is made based on following: Will the delivery date of s/w product be sooner than that for internally developed s/w? Will the cost of acquisition plus the cost of customization 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?

March 2004

Chapter 5 Software Project Planning 32

Decision Tree Support
 EC = (path prob)i * (est. path cost)
simple (.30) Build reuse major changes (.60) buy difficult (.70) minor changes (.40) simple (.20) complex (.80) minor changes (.70) $380,000 $450,000 $275,000 $310,000 $490,000 $210,000 $400,000 $350,000 $500,000 33

System X Expected cost = ∑ (path probablity)I x (estimated path cost)I
March 2004

major changes (.30) contract without changes (.60) with changes (.40) Chapter 5 Software Project Planning

Make/Buy Decision
1. 2. 3. 4.  Build system X from scratch Reuse partial-experience components to construct the system Buy an available s/w product and modify to meet local needs 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
Chapter 5 Software Project Planning 34

March 2004

Make/Buy Decision
EC(buy) = 0.70 ($210K) + 0.30 ($400K) = $267K EC(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.

March 2004

Chapter 5 Software Project Planning 35

Summary
 Project planner must estimate three things: how long project will take how much effort 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

March 2004

Chapter 5 Software Project Planning 36

Risk Management
 Introduction  Risk Identification  Risk Projection  Risk Mitigation, Monitoring, and Management  Safety Risks and Hazards  The RMMM plan  SEI Technical Reviews  Summary
Chapter 6 – Risk Management 1

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

Chapter 6 – Risk Management

2

Introduction
 Robert Charette(2) presented the following conceptual definitions of risk: Risk concerns future happenings 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
Chapter 6 – Risk Management 3

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
Chapter 6 – Risk Management 4

Introduction
Risk Strategies
 Reactive Software team does nothing about risks until something goes wrong “fire fighting mode”  Proactive Begins long before 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
5

At best, monitors the projects for likely risks

Chapter 6 – Risk Management

Introduction
• Project Risks (budgetary, schedule, personnel, resource, customer) • Technical Risks (design, implementation, interfacing, verification) • Business Risks (market, strategic, management,budget) Software Risk Charette: (2) • Known risks • Predictable • Unpredictable
Chapter 6 – Risk Management 6

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

Chapter 6 – Risk Management

7

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 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?
Chapter 6 – Risk Management 8

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? 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 ?
Chapter 6 – Risk Management 9

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? Process Is the software process used for other projects ? Issues: Is configuration management used to maintain consistency among system/software requirements, design, code and test? Is a procedure followed for tracking subcontractor performance? Are facilitated application specification techniques used to aid in communication between the customer and developer ? TechAre specific methods used for software analysis? nical Issues: 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?
Chapter 6 – Risk Management 10

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 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?
Chapter 6 – Risk Management 11

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 Cost risk: the degree of uncertainty that the project budget will be maintained Support risk:the degree of uncertainty that the software will be easy to correct, adapt, and enhance Schedule risk: the degree of uncertainty that the project schedule will be maintained
Chapter 6 – Risk Management

12

Risk Identification
COMPONENTS PERFORMANCE CATEGORY
Failure to meet the requirements would 1 CATASTROPHIC result in mission failure Significant Nonresponsive or degradation to 2 unsupportable nonachievement of technical performance software Failure to meet the requirements would 1 degrade system performance to a point CRITICAL 2 where misssion success is questionable Some reduction in Minor delays in software technical performance modifications Failure to meet the requirements would 1 result in degradation of secondary MARGINAL misssion Minimal to small Responsive 2 reduction in technical performance software support Failure to meet the requirements would 1 create inconv enience or nonoperational NEGLIGIBLE impact No reduction in Easily supportable 2 technical performance software Failure results in increased costs and schedule delays with expected values in exc esss of $500k Significant financial shortages, budget ov errun likely delivery date Failure results in operational delays and/or increased costs with expected values of $100k to $500k Some shortage of Possible slippage in financial resources, possible ov erruns delivery date Cost, impacts, and/or recoverable schedule slips with expected value of $1 to $100K Sufficient financial Realistic, Unachievable

SUPPORT

COST

SCHEDULE

resources achievable schedule Error in minor cost and/or schedule impact with expected value of less than $1k Poss ible budget underrun Early achiev able delivery date

Chapter 6 – Risk Management

13

Risk Projection
 Also called risk estimation, attempts to rate each risk in two ways: Likelihood (probability) Consequences Develop a risk table: A risk table provides a project manager with a simple technique for risk projection For each identified risk, list likelihood, consequence and impact Risk 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
Chapter 6 – Risk Management 14

Risk Projection
Risks
Size estimate may be significantly low Larger number of users than planned Less reuse than planned End users resist system Delivery deadline will be tightened Funding will be lost Customer will change requirements Technology will not meet expectations Lack of training on tools Staff inexperienced Staff turnover will be high

Category Probability Impact RMMM
PS PS PS BU BU CU PS TE DE ST ST

. . .

60% 30% 70% 40% 50% 40% 80% 30% 80% 30% 60%

2 3 2 3 2 1 2 1 2 2 2

Chapter 6 – Risk Management

15

Risk Matrix
L I k e l I h o o d 5 4 3 2 1 1 2 3 4 Consequences
Chapter 6 – Risk Management

5
16

Risk Mitigation, Monitoring, and Management
 An effective strategy must consider three issues: risk avoidance, risk monitoring, and risk management and contingency planning.  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 turnover assume turnover will occur and develop techniques to ensure continuity when people leave. define a backup staff member for every critical technologies.
Chapter 6 – Risk Management 17

Risk Mitigation, Monitoring, and Management
 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, 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.
Chapter 6 – Risk Management 18

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

Chapter 6 – Risk Management

19

The RMMM plan
1. Introduction 1.1. Scope and Purpose of Document 1.2. Overview of major risks 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
Chapter 6 – Risk Management

An outline for the Risk Mitigation, Monitoring, and Management plan.

20

The RMMM plan
3. Risk Mitigation, Monitoring, Management
3.n Risk #n (for each risk above cut-off) 3.1.1. Mitigation 3.1.1.1. General strategy 3.1.1.2. Specific steps to mitigate the risk 3.1.2. Monitoring 3.1.2.1. Factors to be monitored 3.1.2.2. Monitoring approach 3.1.3.Management 3.1.3.1. Contingency plan 3.1.3.2. Special considerations 4. RMMM Plan Iteration Schedule 5. Summary
Chapter 6 – Risk Management

An outline for the Risk Mitigation, Monitoring, and Management plan.

21

SEI Risk Management Paradigm
a) Identify b) Analyze c) Plan d) Track e) Control f) Communicate

Chapter 6 – Risk Management

22

SEI Software Development Risk

Chapter 6 – Risk Management

23

SEI Technical Reviews
 Software Risk Management Ronald P. Higuera, Yacov Y. Haimes; June 1996  An Introduction To Team Management (Version 1.0) 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
Chapter 6 – Risk Management 24

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 resources.  If you don’t actively attack the risks, they will actively attack you.  Major projects should all have a risk management plan..

Chapter 6 – Risk Management

25

NASA Risk Management

November 9, 1997

Chapter 6 -- R. A. Volz -- Assistance -- Julio

1

NASA

November 9, 1997

Chapter 6 -- R. A. Volz -- Assistance -- Julio

2

NASA - Shuttle-Mir

November 9, 1997

Chapter 6 -- R. A. Volz -- Assistance -- Julio

3

November 9, 1997

Chapter 6 -- R. A. Volz -- Assistance -- Julio

4

November 9, 1997

Chapter 6 -- R. A. Volz -- Assistance -- Julio

5

November 9, 1997

Chapter 6 -- R. A. Volz -- Assistance -- Julio

6

November 9, 1997

Chapter 6 -- R. A. Volz -- Assistance -- Julio

7

Project Scheduling and Tracking
 Basic problem -- Software is almost always late. Unrealistic deadlines Changing requirements Miscommunication among staff Risks not considered at beginning of project Technical difficulties that could not be foreseen in advance Human difficulties that could not be foreseen in advance Failure by management to recognize and correct the problem An “honest” underestimate of effort required “Reviewed into failure”
November 5, 1997 Chapter 7 1

Project Scheduling and Tracking
 An approach to unrealistic deadlines -- project redefinition Perform detailed estimate based on previous projects Use incremental process to deliver critical functionality on time Meet with customer (which may be upper management) Offer incremental development strategy as an alternative

November 5, 1997

Chapter 7

2

Basic Principles
 Compartmentalization  Identify task interdependencies  Allocate time for each task  Develop feasible schedule  Define responsibilities. Each task should have a single person responsible. Each person should know their responsibilities.  Define outcomes  Define milestones

November 5, 1997

Chapter 7

3

# of People vs. Effort
 Adding people to a project increases communication requirements  Recall the software equation -- E=[LOC * B0.333/P]3 * (1/t4), where E = effort in person months t = project duration in months B = “special skills factor” For KLOC (5, 15) use 0.16, for KLOC > 70, use B = 0.39 P = “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.
November 5, 1997 Chapter 7 4

Defining the Task Set
 Recall the general categories of tasks (from Ch. 2) Customer communication Planning 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
November 5, 1997 Chapter 7 5

Broad Categories of Projects & Degrees of Rigor
 Types of projects Concept development New application development projects Application enhancement projects Application maintenance projects Reengineering projects  There can be a progression through these kinds of projects  These can be approached with different levels of rigor: casual Structured Strict Quick Reaction
November 5, 1997 Chapter 7 6

Degrees of Rigor
 Adaptation criteria -- rate 1 to 5 Size of the project Number of potential users Mission criticality Application longevity Stability of requirements Ease of customer/developer communications Maturity of applicable technology Performance constraints Embedded/nonembedded characteristics Project staffing Reengineering factors
November 5, 1997 Chapter 7 7

Task Set Selector Values

(compute average value)
November 5, 1997 Chapter 7 8

Example

November 5, 1997

Chapter 7

9

Linear, Sequential Model
 See text for outline of example procedure

November 5, 1997

Chapter 7

10

Evolutionary (Spiral) Model

November 5, 1997

Chapter 7

11

Example of Task Network

November 5, 1997

Chapter 7

12

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 charts Earliest beginning time for a task Latest time to initiate a task without delaying project Earliest task completion time Latest task completion time Total float
November 5, 1997 Chapter 7 13

Example of Timeline Chart

November 5, 1997

Chapter 7

14

Tracking the Schedule
 Conduct periodic status meetings  Evaluate all Software Engineering Process Reviews  Determine whether formal milestones are met on time  Compare actual start date on each task to that planned  Informal subjective assessment from practitioners Possible corrective actions in case of problems  Re-deploy personnel  Commit reserve resources  Reschedule  Re-scope the project
November 5, 1997 Chapter 7 15

Example Project Table

November 5, 1997

Chapter 7

16

Typical Project Plan Outline

November 5, 1997

Chapter 7

17

Software Quality Assurance Outline
What is Software Quality assurance(SQA)?  Quality Concepts.  Software Quality Assurance Activities.  Software Reviews and their importance  Statistical SQA.  Software Reliability  ISO 9000 approach to SQA

SRIMCA

What is SQA?

Software Quality Assurance is an umbrella activity that is applied throughout the software process...

SRIMCA

It encompasses..
A quality management approach  Effective software engineering technology  Formal technical reviews that are applied throughout the software process  A multitiered testing strategy  Control of software documentation and changes to it  A procedure to assure compliance with software development standards  Measurement and reporting techniques

SRIMCA

Quality ???
Quality refers to any measurable characteristics such as correctness, maintainability, portability, testability, usability, reliability, efficiency, integrity, reusability and interoperability.  Measures of program’s characteristics; as cyclomatic complexity, cohesion, fp, loc etc.

SRIMCA

Quality Concepts

Quality of Design refers to the characteristics that designer’s specify for an item. Quality of Conformance is the degree to which the design specifications are followed during manufacturing. Quality Control is the series of inspections, reviews and tests used throughout the development cycle to ensure that each work product meets the requirements placed upon it.
SRIMCA

(cont'd)...

Quality policy refers to the basic aims and objectives of an organization regarding quality as stipulated by the management. Quality assurance consists of the auditing and reporting functions of management. Cost of Quality provide a baseline for current cost of quality, identify opportunities for reducing the cost of quality, and provide a normalized basis of comparision.
SRIMCA

(cont'd)...

Quality Costs are divided into costs associated with prevention, appraisal, failure – internal & external costs
 Prevention

– Quality planning, formal technical reviews, test equipment, training  Appraisal – gain insight into product condition “first time through” each process; which include
In-process and inter-process inspection Ininter Equipment calibration and maintenance  Testing

SRIMCA

(cont'd)...
 Failure

Costs – those which disappear before shipping product to customer
 Internal

– detection of defect prior to shipment
 Rework,

repair, failure mode analysis

 External

– defect found after shipment

 Complaint

resolution, product return & replacement, help line support, warranty work
SRIMCA

Relative cost of correcting an error

SRIMCA

(cont'd)...

  

Quality planning is the process of assessing the requirements of the procedure and of the product and the context in which these must be observed. Quality testing is assessment of the extent to which a test object meets given requirements Quality assurance plan is the central aid for planning and checking the quality assurance. Quality assurance system is the organizational structure, responsibilities, procedures, processes and resources for implementing quality management.
SRIMCA

Defn. of Software Quality Assurance

Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.

SRIMCA

Defn. of Software Quality Assurance

1. S/W requirements are the foundation of quality; lack of conformance to requirements is lack of quality. 2. Specified standards define a set of development criteria that guide the teams in which s/w is engineered; if not followed, lack of quality will surely result 3. A set of implicit requirements often goes unmentioned; if not met, s/w quality is suspect.
SRIMCA

SQA
 SQA

is composed with tasks associated

with:
 S/w

Engineers who do technical work  SQA group responsible for quality assurance planning, oversight, recordrecordkeeping, analysis and reporting – to assist the s/w team in achieving a high quality end product.
SRIMCA

SQA Group Plan
SQA group perform following activities:
     

Evaluations to be performed Audits and reviews to be performed Standards that are applicable to the project Procedures for error reporting and tracking Documents to be produced by the SQA group Amount of feedback provided to software project team
SRIMCA

SQA Group Activities
Participates in the development of the projects software process description  Reviews software engineering activities to verify compliance with the defined software process.  Audits designated software work products to verify compliance with those defined as part of the software process.

SRIMCA

(cont'd)...
Ensures that deviations in software work and work products are documented and handled according to a document procedure.  Records any non-compliance and reports to nonsenior management.

 In

addition to these, SQA group may cocoordinate the control and management of change, and helps to collect and analyze s/w metrics.
SRIMCA

Software Reviews
‘Filter’ for the software engineering process  ‘Purify’ the software work products that occur as a result of analysis, design, and coding.  Achieve technical work of more uniform, greater and more predictable quality.  Detect errors and problems at the earliest possible time.

SRIMCA

Formal Technical Reviews

   

To uncover errors in function, logic, or implementation for any representation of the software To verify that software meets its requirements To ensure that software representation meets predefined standards To achieve software development in a uniform manner To make projects more manageable
SRIMCA

Cost Impact of Software Defects
  

Defect = Fault (We knew it as error before delivery) Industry studies reveal that almost 50-65 % of all errors 50(defects) are introduced during design activities By detecting and removing them, review process substantially reduces the cost of subsequent steps in the development and support phases. E.g. assume that an error uncovered during design will cost 1 Rs., relative to this, the same error uncovered just before testing commences will be 6.5 Rs., during testing, 15 Rs. And after release 60-100 Rs. 60SRIMCA

Defect Amplification Model
Development Step Defects Errors passed through Detection Percent efficiency for Amplified errors 1 : x error Newly generated errors detection Errors passed to next step

Errors from previous step

SRIMCA

Defect Amplification Model

SRIMCA

Defect Amplification with Reviews

SRIMCA

Cost Comparison of Error Repair

SRIMCA

Review Guidelines..
   

 

Review the product, not producer Set an agenda and maintain it Limit the debate Enunciate problem areas, not to solve every problem noted Take written notes Allocate resources and time schedule for FTR’s
SRIMCA

 

Limit the number of participants and insist upon advance preparation Develop a checklist for each work product to be reviewed Training for all reviewer’s Reviewing earlier reviews

Additional Structures

Requirements Control Board
 All

requirement changes must be formally reviewed and approved design changes must be formally reviewed and approved

Software Control Board
 All

Interface Control Board
SRIMCA

Statistical Quality Assurance
Implies information about software defects is collected and categorized  An attempt is made to trace each defect to its underlying cause  Isolate the vital few causes of the major source of all errors  Then move to correct the problems that have caused the defects

SRIMCA

Categories of Errors
Incomplete or erroneous specification (IES)  Misinterpretation of customer comm (MCC)  Intentional deviation from specification (IDS)  Violation of programming standards (VPS)  Error in data representation (EDR)  Inconsistent module interface (IMI)  Error in design logic (EDL)

SRIMCA

Categories of Errors (cont'd)
Incomplete or erroneous testing (IET)  Inaccurate or incomplete documentation (IID)  Error in programming lang. Translation (PLT)  Ambiguous or inconsistent human-computer humaninterface (HCI)  Miscellaneous (MIS)  Most often IES, MCC and EDR are the vital few causes for majority of errors.

SRIMCA

Definitions Ei = the total number of errors uncovered during the ith step in the software engineering process  Si = the number of serious errors  Mi = the number of moderate errors  Ti = the number of minor errors  PS = size of the product (LOC, design statements, pages of documentation)

SRIMCA

error index
Phase index for each step and then error index is calculated PIi = ws(Si/Ei)+wm(Mi/Ei)+wt(Ti/Ei)  Formula:

 (iXPI ) / PS
i

 ( PI 1  2 PI 2  3 PI 3  iPIi ) / PS
SRIMCA

Software Reliability

    

Defined as the probability of failure free operation of a computer program in a specified environment for a specified time. It can measured, directed and estimated A measure of software reliability is mean time between failures where MTBF = MTTF + MTTR MTTF = mean time to failure MTTR = mean time to repair
SRIMCA

Software Availability
 

Availability =MTTF/(MTTF + MTTR) * 100% Software availability is the probability that a program is operating according to requirements at a given point in time

SRIMCA

Software Safety
Processes that help reduce the probability that critical failures will occur due to SW  Hazard analyses

 Identify hazards that could call failure  Develop fault tree  Identify all possible causes of the hazard

Redundancy  Require a written software safety plan  Require independent verification & validation

SRIMCA

 Formally

review the remedy for each

Example Fault Tree -- Thermal
Loss of heat

...

Power failure

Computer failure

Incorrect input

SW failed to throw switch

Computer failure

SW failed to throw switch

...

Logic reversed

SRIMCA

Software Safety

Redundancy
 Replicated at

the hardware level  Similar vs.. dis-similar redundancy dis 

Verification
 Assuring

that the software specifications are met that the product functions as desired

Validation
 Assuring

Independence
SRIMCA

Overview of SQA Plan
       

Purpose of Plan References Management Documentation Standards, Practices and Conventions Reviews and Audits Test Problem Reporting and Corrective action SRIMCA

    

 

Tools, Techniques and Methodologies Code Control Media Control Supplier control Records Collection, Maintenance and Retention Training Risk Management

ISO 9000 Quality Standards
   

ISO 9000 describes quality assurance elements in generic terms that can be applied to any business. It treats an enterprise as a network of interconnected processes. To be ISO-complaint processes should adhere to ISOthe standards described. Elements include organizational structure, procedures, processes and resources. Ensures quality planning, quality control, quality assurance and quality improvement.
SRIMCA

ISO 9001
An international standard which provides broad guidance to software developers on how to Implement, maintain and improve a quality software system capable of ensuring high quality software  Consists of 20 requirements...  Differs from country to country..

SRIMCA

ISO 9001 (cont'd)..requirements
     

Management responsibility Quality system Contract review Design Control Document and data control Purchasing
SRIMCA

    

Control of customer supplied product Product identification and traceability Process control Inspection and testing Control of inspection, measuring and test equipment

ISO 9001 (cont'd)..
   

Inspection and test status Control of nonnonconfirming product Corrective and preventive action Handling, storage, packaging, preservation and delivery
SRIMCA

    

Control of quality records Internal quality audits Training Servicing Statistical techniques

SummarySQA must be applied at each step  SQA might be complex  Software reviews are important SQA activities  Statistical SQA helps improve product quality and software process  Software Safety is essential for critical systems  ISO 9001 standardizes the SQA activities

SRIMCA

Software Configuration Management (SCM)

Overview
 What

is SCM?  What are the processes of SCM?  How does each process do?  Summary

Software Configurations

Software configuration -- the output
 Computer

programs (source and executables)  Documents  Data

Software Configuration Management (SCM)
 The

art of identifying, organizing and controlling modifications to the software being built

Why Do We Need SCM?

First Law of System Engineering
 No

matter where you are in the system life cycle, the system will change and the desire to change it will persist throughout the life cycle

Sources of Change
 New

business or market conditions  new customer needs  Organization and/or business downsizing  Budgetary or scheduling constraints

Baseline Concept
 IEEE

defines a baseline as:

A specification or product that has been formally reviewed and agreed upon, that thereafter serve as the basis for further development, and that can be changed only through formal change control procedures

A

baseline is a milestone in the development of software that marked the delivery of one or more software configuration items

Common Baselines
System engineering Requirement analysis Software design Coding Testing Release

System specification Software requirement specification Design specification Source code Test plans/Procedures/Data Operational system

Software Configuration Item (SCI)
 

Information created as part of SE process SCIs used as target in SCM:  System specification  Software project plan  Software requirements specification  Preliminary user manual  Design specification  Source code listing

SCI (Cont’d)
 Test

specification  Operation and installation manuals  Executable program  Database description  As-built user manual As Maintenance documents  Standards and procedures for SE

SCI Modification Process

SCM Process
Identification  Version control  Change control  Configuration auditing  Status reporting

Object identification in SW configuration
SCI can be named and organized using OO approach  Two types of objects:

 basic

object: object: ‘unit of text’ created during analysis, design, coding, or testing.  Aggregated objects: a collect of basic objects objects:

Object identification in SW configuration (cont’d)

Features of objects:
 name:

a character string  description: a list of data items to identify the SCI type and a project id, version information, etc.  resources: entity that are provided, processed, referenced by the object  Realization: a pointer to ‘unit of text’ for a basic ‘unit object or null for an aggregate object

Object identification in SW configuration (cont’d)

Relationships between objects
 part-of: part-

a hierarchical relationship  interrelated: a cross-structural relationship cross

Object identification methods
 evolution

graph  automated SCM tools  module interconnection language

Configuration Objects

Evolution Graph
obj 1.3 obj 1.0 obj 1.1 obj 1.2 obj 2.0 obj 1.1.2 obj 1.4 obj 2.1

obj 1.1.1

Version Control

Some of the issues
 When

an executable is built, the versions of its constituents must be consistent.  If A depends upon B and B is recompiled, A may also need to be recompiled.  What if multiple people need to modify same SCI?  Need to know what version different customers have  How do you keep track of 100’s or 1000’s of modules?

Version Control
Evolution graph to represent different versions  Uses an object pool representing components, variants and versions, and their relationship  RCS (Revision Control System) is common tool.

 Use

for documentation as well as code development.

Version Control Support

At the language level (in Ada):
With B; Spec A Body A Spec B Body B

If only body of B changes, no change to A  If spec of B changes, A must be recompiled

Change Control
Change request from user Developer evaluates Change report is generated Change 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 change ‘Check in’ changed SCIs Establish a baseline for testing Do SQA and ‘promote’ changes for inclusion in next release Rebuild appropriate version Audit the SCI changes/ include changes in new version Release the new version

Access and Synchronization Control

Configuration Audit

 

Two approaches can be used to ensure proper implementation of change:  formal technical review  software configuration audit CA assesses a configuration object for characteristics that are not generally not considered during review CA generally checks:
•Changes incorporated •FTR conducted •SE standards followed •SCM procedures followed •all related SCIs properly updated •change date and author specified

Status Reporting
     

Event occurred -- An SCI received updated ID people involved Time happened Effects on others Generated on a regular basis To improve communication among all parties

Summary
SCM identifies, controls, audits and reports modifications  An object becomes a baseline once developed and reviewed  Version control is the set of procedures and tools for managing the use of these objects

Summary
Change control is a procedure activity necessary to achieve quality and consistency  Configuration audit is an SQA activity to help ensure quality is maintained  Reporting provides information for better communication

Software Configuration Management (SCM)

Overview
 What

is SCM?  What are the processes of SCM?  How does each process do?  Summary

November 16, 1997

Assistance - Changheng Du

Software Configurations

Software configuration -- the output
 Computer

programs (source and executables)  Documents  Data

Software Configuration Management (SCM)
 The

art of identifying, organizing and controlling modifications to the software being built
Assistance - Changheng Du

November 16, 1997

Why Do We Need SCM?

First Law of System Engineering
 No

matter where you are in the system life cycle, the system will change and the desire to change it will persist throughout the life cycle

Sources of Change
 New

business or market conditions  new customer needs  Organization and/or business downsizing  Budgetary or scheduling constraints
November 16, 1997
Assistance - Changheng Du

Baseline Concept
 IEEE

defines a baseline as:

A specification or product that has been formally reviewed and agreed upon, that thereafter serve as the basis for further development, and that can be changed only through formal change control procedures

A

baseline is a milestone in the development of software that marked the delivery of one or more software configuration items

November 16, 1997

Assistance - Changheng Du

Common Baselines
System engineering Requirement analysis Software design Coding Testing Release
November 16, 1997

System specification Software requirement specification Design specification Source code Test plans/Procedures/Data Operational system
Assistance - Changheng Du

Software Configuration Item (SCI)
 

Information created as part of SE process SCIs used as target in SCM:  System specification  Software project plan  Software requirements specification  Preliminary user manual  Design specification  Source code listing
Assistance - Changheng Du

November 16, 1997

SCI (Cont’d)
 Test

specification  Operation and installation manuals  Executable program  Database description  As-built user manual As Maintenance documents  Standards and procedures for SE

November 16, 1997

Assistance - Changheng Du

SCI Modification Process

November 16, 1997

Assistance - Changheng Du

SCM Process
Identification  Version control  Change control  Configuration auditing  Status reporting

November 16, 1997

Assistance - Changheng Du

Object identification in SW configuration
SCI can be named and organized using OO approach  Two types of objects:

 basic

object: object: ‘unit of text’ created during analysis, design, coding, or testing.  Aggregated objects: a collect of basic objects objects:

November 16, 1997

Assistance - Changheng Du

Object identification in SW configuration (cont’d)

Features of objects:
 name:

a character string  description: a list of data items to identify the SCI type and a project id, version information, etc.  resources: entity that are provided, processed, referenced by the object  Realization: a pointer to ‘unit of text’ for a basic ‘unit object or null for an aggregate object
November 16, 1997
Assistance - Changheng Du

Object identification in SW configuration (cont’d)

Relationships between objects
 part-of: part-

a hierarchical relationship  interrelated: a cross-structural relationship cross

Object identification methods
 evolution

graph  automated SCM tools  module interconnection language
November 16, 1997
Assistance - Changheng Du

Configuration Objects

November 16, 1997

Assistance - Changheng Du

Evolution Graph
obj 1.3 obj 1.0 obj 1.1 obj 1.2 obj 2.0 obj 1.1.2 obj 1.4 obj 2.1

obj 1.1.1

November 16, 1997

Assistance - Changheng Du

Version Control

Some of the issues
 When

an executable is built, the versions of its constituents must be consistent.  If A depends upon B and B is recompiled, A may also need to be recompiled.  What if multiple people need to modify same SCI?  Need to know what version different customers have  How do you keep track of 100’s or 1000’s of modules?
November 16, 1997
Assistance - Changheng Du

Version Control
Evolution graph to represent different versions  Uses an object pool representing components, variants and versions, and their relationship  RCS (Revision Control System) is common tool.

 Use

for documentation as well as code development.
Assistance - Changheng Du

November 16, 1997

Version Control Support

At the language level (in Ada):
With B; Spec A Body A Spec B Body B

If only body of B changes, no change to A  If spec of B changes, A must be recompiled

November 16, 1997
Assistance - Changheng Du

Change Control
Change request from user Developer evaluates Change report is generated Change control authority makes decision Request is queued, persons are assigned “Check out” SCI(s)
November 16, 1997

Change request is denied User is informed

Assistance - Changheng Du

Change Control (cont’d)
Make the change/review change ‘Check in’ changed SCIs Establish a baseline for testing Do SQA and ‘promote’ changes for inclusion in next release Rebuild appropriate version Audit the SCI changes/ include changes in new version
November 16, 1997

Release the -new version Assistance Changheng Du

Access and Synchronization Control

November 16, 1997

Assistance - Changheng Du

Configuration Audit

 

Two approaches can be used to ensure proper implementation of change:  formal technical review (FTR)  software configuration audit CA assesses a configuration object for characteristics that are not generally not considered during review CA generally checks:
•Changes incorporated •FTR conducted •SE standards followed •SCM procedures followed •all related SCIs properly updated •change date and author specified

November 16, 1997

Assistance - Changheng Du

Status Reporting
     

Event occurred -- An SCI received updated ID people involved Time happened Effects on others Generated on a regular basis To improve communication among all parties

November 16, 1997

Assistance - Changheng Du

Summary
SCM identifies, controls, audits and reports modifications  An object becomes a baseline once developed and reviewed  Version control is the set of procedures and tools for managing the use of these objects

November 16, 1997

Assistance - Changheng Du

Summary
Change control is a procedure activity necessary to achieve quality and consistency  Configuration audit is an SQA activity to help ensure quality is maintained  Reporting provides information for better communication

November 16, 1997

Assistance - Changheng Du

Systems Engineering

System
 

 

January 31, 1999

A set or arrangement of things so related as to form a unity or organic whole. A set of facts, principles, rules, etc., classified and arranged in an orderly form so as to show a logical plan linking the various parts. A method or plan of classification or arrangement. An established way of doing something; method; procedure.
Assistance - Eric Christensen

Computer-Based Systems
Definition: A set or arrangement of elements that are organized to accomplish some pre-defined goal by processing preinformation.  Elements

     

Software Hardware People Database Documentation Procedures

January 31, 1999

Assistance - Eric Christensen

System of Systems -- Example

January 31, 1999

Assistance - Eric Christensen

The System Engineering Hierarchy

A hierarchy of views are necessary, for example,
   

World View Domain View Element view Detailed View

January 31, 1999

Assistance - Eric Christensen

Typical Hierarchy

January 31, 1999

Assistance - Eric Christensen

System Modeling
Define the processes that define the needs of the view under consideration  Represent the behavior of the processes and the assumptions on which the behavior is based  Explicitly define all inputs and outputs to each component  Define the transformation between inputs and outputs of each component  Represent all linkages (interfaces)

January 31, 1999
Assistance - Eric Christensen

Critical Factors

It is absolutely essential that the following be spelled out completely and in detail
    

Assumptions Simplifications Limitations Constraints Preferences

Changes in these is a principal contributor to software change
Assistance - Eric Christensen

January 31, 1999

Information Engineering

Architecture -- another overused word
 

A set of component types together with a set of principles and guidelines for their interconnection. Also used to refer to the structure of a system. data architecture applications architecture technology infrastructure
Assistance - Eric Christensen

One classification of architectures
  

January 31, 1999

Information Engineering Activities

Another set of terms or phases of activity
   

Information strategy planning(isp) Business area analysis(baa) Business system design(bsd) Construction and integration(C&I)

January 31, 1999

Assistance - Eric Christensen

A Diagrammatic View

January 31, 1999

Assistance - Eric Christensen

Product Engineering
Develop support infrastructure  Develop systems view of components  Systems analysis

 

allocate functions and behaviors (given requirements) determine interfaces

Component engineering  Element & Detailed views

 

Analysis & design modeling Construction & integration
Assistance - Eric Christensen

January 31, 1999

A Diagrammatic View

January 31, 1999

Assistance - Eric Christensen

Information Strategy Planning
Define strategic business objectives and goals  Isolate the critical success factors that will enable the business to achieve goals  Analyze the impact of technology and automation on goals and objectives  Analyze existing information to determine its role in achieving goals and objectives  Create a business-level data model business
January 31, 1999
Assistance - Eric Christensen

Information Strategy Planning

Enterprise Modeling -- a 3-D view 3  

Organizational structures and functions Decomposes business functions to isolate processes that make function happen Relate objectives, goals, and CSFs to the organization and its functions

It is increasingly important that the various functions be interoperable
Assistance - Eric Christensen

January 31, 1999

Typical Organizational Chart

January 31, 1999

Assistance - Eric Christensen

Information Strategy Planning

BusinessBusiness-Level Data Modeling
 

focuses on the data objects required to achieve the business functions identifies relationships between customers, products, salespersons, etc.

Culmination - a series of cross reference matrices that establish the relationship between the organization, business objectives and goals, business functions, and data objects.
Assistance - Eric Christensen

January 31, 1999

Typical Relationship Among Objects

January 31, 1999

Assistance - Eric Christensen

Business Area Analysis
Establishes a detailed framework for building an information-based enterprise information Models

   

data models process flow models process decomposition diagrams crosscross-reference matrices
Assistance - Eric Christensen

Domain View

January 31, 1999

Business Area Analysis

Data Modeling
   

Identify data object types (or classes) Determine essential attributes Determine other objects with which the object has relations Determine operations which will need to be performed on the object

January 31, 1999

Assistance - Eric Christensen

Business Area Analysis
Process Modeling - describes the business functions within a business area  Information Flow Modeling - integrates process and data models to show how information flows through a business area

January 31, 1999

Assistance - Eric Christensen

Typical Process Flow Model

January 31, 1999

Assistance - Eric Christensen

With Information Flow

January 31, 1999

Assistance - Eric Christensen

Product Engineering
Problem solving activity where desired product data, function, and behavior are analyzed and allocated to individual components  Major activities

  

Support infrastructure Bound function, performance, constraints, and interfaces Develop alternative allocations
Assistance - Eric Christensen

January 31, 1999

Product Engineering

TradeTrade-off Criteria
      

Project Considerations Business Considerations Technical Analysis Manufacturing Evaluation Human Issues Environmental Interfaces Legal Considerations
Assistance - Eric Christensen

January 31, 1999

System Analysis
Identification of Need  Feasibility Study  Perform economic and technical analyses  Allocate functions to hardware, software, people, database  Establish cost and schedule constraints  Create system definition

January 31, 1999
Assistance - Eric Christensen

Feasibility Study
Economic - cost-benefit analysis cost Technical - development risk, resource availability, technology  Legal - definition of infringements or violations from system development  Alternatives - evaluation of alternative approaches

January 31, 1999
Assistance - Eric Christensen

Benefit Analysis

January 31, 1999

Assistance - Eric Christensen

Cost Analysis

January 31, 1999

Assistance - Eric Christensen

Modeling the System Architecture
Architecture template - user interface, input, system function and control, output, maintenance and self-test self Architecture context diagram - establishes the information boundary between the system being implemented and the environment in which it is to operate  Architectural flow diagram - shows how information flows between subsystems January 31, 1999

Assistance - Eric Christensen

Architecture Template

January 31, 1999

Assistance - Eric Christensen

CLSS Example

January 31, 1999

Assistance - Eric Christensen

Expanded Example

January 31, 1999

Assistance - Eric Christensen

Building a Hierarchy

January 31, 1999

Assistance - Eric Christensen

System Modeling and Simulation
Reactive Systems - real-time and embedded realsystems -- particularly difficult systems to develop correctly.  CASE tools - eliminate surprises when introducing a reactive system

 

One can build models of the systems to be built One can “test drive” the model before building it
Assistance - Eric Christensen

January 31, 1999

System Specification
Document that serves as a foundation for hardware engineering, software engineering, data base engineering, and human engineering  Describes function and performance of computercomputer-based system as well as constraints  An essential element required for systems engineering

January 31, 1999
Assistance - Eric Christensen

Analysis
Concepts and Principle

August 2003

Pressman – Chap. 11

1

Requirement Analysis
Results in specs. of s/w operational characteristics (function, data and behavior)  Indicate s/w interface with other system elements  Establish constraints that s/w must meet

August 2003

Pressman – Chap. 11

2

Requirement Analysis
RA allows the analyst to refine the s/w allocation and build models of the data, functional and behavioral domains  It provides the analyst with a representation of info., function & behavior that can be translated into data, architectural and component level design  Means to access quality once s/w is built

August 2003 Pressman – Chap. 11
3

Requirements Analysis

Five Activities
    

Problem recognition Evaluation and synthesis Modeling Specification Review

August 2003

Pressman – Chap. 11

4

Problem Recognition

Some problems to overcome
   

Understanding what the customer really wants Getting inside the customers requirements “us“us-them” paradigm rather than “we” Federal Acquisition Regulations (FARs)
 

Require customer to prepare specifications Limit discussion between customer and supplier during bidding process.
Pressman – Chap. 11
5

August 2003

Techniques for Requirements Acquisition

Facilitated Application Specification Techniques (FAST)
     

Meeting (often at neutral site) Establish meeting rules Agenda to cover important points A facilitator -- best if not customer or supplier Definition mechanism Understand goal -- to identify problem, specify a preliminary set of requirements
Pressman – Chap. 11
6

August 2003

Techniques for Requirements Acquisition

Facilitated Application Specification Techniques (FAST)

Refinement with subgroups

August 2003

Pressman – Chap. 11

7

Techniques for Requirements Acquisition

Quality Function Deployment
 

Normal Requirements

What will make customer happy Unstated requirements that are so “obvious” that they need not be stated Enhancements beyond customer requirements
Pressman – Chap. 11
8

Expected Requirements

Unexpected Requirements

August 2003

Analysis Principles

First Operational Analysis principle requires examination of the info. Domain and creation of data model Second & Third operational analysis principle require that we build models of function and behavior Fourth Op. analysis principle suggests that the info., functional and behavioral domains of s/w can be partitioned.
Pressman – Chap. 11
9

August 2003

Analysis Principles

Basic prinicples
    

Represent and understand information domain Define functions that must be performed Represent behavior of software (to external events) Partition information, function and behavior models hierarchically Move from essential information to implementation detail
Pressman – Chap. 11
10

August 2003

Guiding Principles
Understand problem before analysis  Develop prototypes for HCI  Record rationale for every requirement  Develop multiple views of each requirement

Data, functional and behavioral models

Determine priorities of requirements  Eliminate ambiguity

August 2003 Pressman – Chap. 11
11

Information Domain

Software processes data
 

Payroll processing Computing control signals for radar system Timer went off -- time to calculate a control Sensor turned on -- indicates intruder Heart rate monitor exceeded threshold -indicates fibrillation.
Pressman – Chap. 11
12

Software also processes events
  

August 2003

Information Domain

Three views of information
  

Information content Information flow Information structure Functional -- possibly show block diagrams Behavioral -- define states and transitions
Pressman – Chap. 11
13

Process Models
 

Try to show models diagrammatically

August 2003

Partitioning

August 2003

Pressman – Chap. 11

14

Prototyping

Highly desirable
  

Clarify requirements Identify missing requirements Help define user interfaces Throwaway Evolutionary -- a potential problem is that intended throwaways become evolutionary
Pressman – Chap. 11
15

Types of prototypes
 

August 2003

Prototyping

Important questions underlying prototyping

Customer commitment -- must be involved
 

Must commit resources for evaluation Must be capable of making requirements decisions in timely manner

August 2003

Pressman – Chap. 11

16

Prototyping

Methods and tools
  

Fourth Generation Techniques -- program application generators Reusable Software Components -- build from existing components Formal Specification and Prototyping Environments

Translate specifications into code
Pressman – Chap. 11
17

August 2003

Specifications
      

Separate Function from Implementation Develop Model Define Environment Define how software interacts with environ. Create Cognitive model -- how world sees it Recognize specs as imperfect Flexibility -- be amenable to change
Pressman – Chap. 11
18

August 2003

Representation
   

Format and content relevant to problem Information should be nested

Multiple layers or levels

Diagrams should be consistent in use Representations should be revisable

August 2003

Pressman – Chap. 11

19

Requirements Specifications Documentation

August 2003

Pressman – Chap. 11

20

Specifications Review

Macroscopic Level

  

View from the top Goals met ? Alternatives explored ? Customer satisfied ? Avoid persuasive, intimidating connectors Ambiguous words Vague language Watch for unstated assumptions
Pressman – Chap. 11
21

Specifics
   

August 2003

Analysis Modeling

Two primary methods today
 Structured

Analysis  Object-oriented analysis Object

Some important considerations
 Analysis

products must be maintainable  Effective partitioning is essential  Graphics should be used whenever possible  Distinguish between logical and implementation
August 2003 1

Structured Analysis

Elements of Analysis
  

Describe what customer requires Establish basis for creating software design Define requirements that can be validated

August 2003 2

Graphical View of Model

Entity Relationship Diagram ( ERD) Data

Data Flow Diagram (DFD)

Dictionary State Transition Diagram (STD)

August 2003 3

Data Modeling

The model consists of
  

Data object [types] Attributes Relationships A representation of almost any composite information that must be understood by software.
4

Data objects

August 2003

Data Modeling

Attributes

Attributes define the properties of a data object and take on one of three different characteristics:

Name an instance of the data object  Describe the instance  Make reference to another instance Referential Descriptive attributes Naming attributes attributes Identifier

Make

Model

ID#
Q12A45.. AB123...

Body type
Sedan Sports

Color Owner
Blue White ABC XYZ
5

Ford Taurus August 2003 Lexus LS400

Data Modeling

Relationships

Defined pairwise -- many varieties orders displays

Book

sells returns

Bookstore

August 2003 6

Cardinality and Modality

Cardinality

How many occurrences of object X are related to how many occurrences of object Y
  

One-toOne-to-one (1:1) One-toOne-to-many (1:N) Many-toMany-to-many (M:N)

Modality
 

=0 => optional relationship =1 => relationship must appear
7

August 2003

Example

Customer

is provided with

Repair action

Mandatory: in order to have a repair action, we must have a customer

Optional: there may be a situation in which a repair action is not necessary

August 2003 8

Entity Relation Diagrams (ERD)

Cornerstone of the data model -- includes
   

data objects, attributes, relationships, and various type indicators
builds

manufacturer

car

Data Object Table
ID# model
August 2003

body type

engine

transmission

...
9

Example

August 2003 10

Data Object Hierarchies

August 2003 11

Associating Data Objects

August 2003 12

Functional Modeling

Entity Relationship Diagram

Data Flow Diagram Data Dictionary State Transition Diagram ( DFD )

August 2003 13

Data Flow Diagrams (DFD)

 

A graphical technique that depicts information flow and the transforms applied as data move from input to output Not the same as flow charts. Does not show the logic of the transformations Can be used at any level of abstraction

August 2003 14

General Information Flow Model

August 2003 15

Basic Notation

August 2003 16

Information Flow Refinement
A F B

A

V f
1

f2

X f
4

f6 Z z1 f5 z3

z2 f7

W f3 Y X Y

B

f f

41

x1 y1

f f

43

x2 y2

f

45

Z
17

42

44

August 2003

Real Time Extensions

Fundamental issue - The time at which results are produced is a part of the correctness of the computation. Hatley/Pirbhai notation

August 2003 18

Ward/Mellor Notation

August 2003 19

Example

August 2003 20

Example

August 2003 21

Hatley and Pirbhai Extensions
 

Use separate data flow diagram (DFD) and control flow diagram (CFD) Data flow diagrams

Used to represent data and the processes that manipulate it Show how events flow among processes and show those external events that cause various processes to be activated
22

Control flow diagrams

August 2003

Relationship Between Models

August 2003 23

Example

August 2003 24

CFD for Photocopier
paper feed status (jammed, empty) start/stop read operator Info input Copy alarm

manage copying

status

produce user displays Problem type

Reload status perform reload paper full
August 2003

problem diagnosis

repro fault

25

Behavioral Modeling

Entity Relationship Diagram Data Dictionary

Data Flow Diagram

State Transition Diagram ( STD )
August 2003 26

State Transition Diagrams

A State is any observable mode of behavior

e.g., reading commands, computing control, waiting for next time event

   

States represented as rectangles Arrows represent transitions Value above arrow identifies event causing transition Value below arrow indicates ensuring action
27

August 2003

State Transition Diagram
full and start invoke manage-coping idle invoke read-op-input reading commands full invoke read-op-input reloading paper

copies done invoke read-op-input making copies

empty invoke reload paper

jammed
invoke perform problem-diagnosis
August 2003

diagnosing problem

not jammed invoke read-op-input
28

Creating an ERD
      

List entities that customer addresses For each, determine the connections For each connection, create one or more objectobject-relationship pairs For each relationship, determine cardinality and modality Define the attributes of each entity Formalize and review ERD Iterate
29

August 2003

Home Security System Example

Initial entities

Homeowner, control panel, sensors, security system and monitoring service

August 2003 30

Home Security System Example

Relationships between sensor and security sys.
   

Security system monitors sensor Security system enables/disables sensor Security system tests sensor Security system programs sensor

August 2003 31

Creating a Data Flow Model

First create level 0 diagram
 

Depict software system as single bubble Show primary inputs and outputs

   

Identify processes, data objects, and data stores to be expanded at next level Label all arrows with meaningful names Information flow continuity must be maintained Refine only one bubble at a time
August 2003 32

Home Security System Example

August 2003 33

Refinement

Analyze textual description of bubble
 

verbs are often processes nouns are often external entities, data or control objects or data stores Control panel is used to program and configure the system Upon a sensor event, the software invokes an alarm
34

Examples
 

August 2003

Home Security System Example

August 2003 35

Home Security System Example

August 2003 36

Creating Control Flow Models
 

Strip arrows from DFD Add event and control items. E.g., try
      

List all sensors read by the software List all interrupt conditions List all operator actuated switches List all data conditions Check noun-verb parse for possible CSPEC I/O nounIdentify states, how each is reached and transitions Focus on possible omissions
37

August 2003

Level 1 CFD for Safe-Home

August 2003 38

Control Specification

August 2003 39

Process Activation Table

August 2003 40

Process Specifications

Describes all flow model processes at final level of refinement
     

Narrative text, Program design language description Mathematical equations Tables Diagrams Charts
41

August 2003

Data Dictionary

Entity Relationship Diagram

Data Flow Diagram Data Dictionary

State Transition Diagram
August 2003 42

Data Dictionary
 

Why a data dictionary? Need an organized way to represent data & control characteristics Usual contents
    

Name Alias Where and how used Content description (of composite items) Supplementary information, e.g., restrictions, limitations, preset values
43

August 2003

Example
    

Name: Shuttle position Aliases: Position-orientation vector PositionWhere used: Display of Shuttle on map Content: x, y, z position wrt to Earth’s Center, roll, pitch, yaw Supplementary Info: Elevation must be above 140 nautical miles
44

August 2003

Data Dictionary

Common tools supporting DD
    

Preventing creation of duplicate names Enforce naming conventions Printing dictionary Determine the range of impact of changes, i.e., which processes are affected Assist configuration management

August 2003 45

Summary

Key elements

Data modeling
  

Data objects, attributes and relationships Cardinality and modality EntityEntity-relationship diagrams Data and control flow diagrams State transition diagrams

  

Functional modeling

Behavioral modeling

Data Dictionary
46

August 2003

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 Software Architecture Program Partitioning Coupling and Cohesion

Sep. 2003

S.E. - RSP

2

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 the major structural elements of a program

Procedural Design Interface Design

Architectural Design

Data Design

The Design Model Which is mapped from the Analysis model S.E. - RSP

Sep. 2003

4

The Design Model
• Interface Design
– Describes how the software communicates with itself, to systems that interact with it and with humans.
Procedural Design Interface Design Architectural Design Data Design

• Procedural Design
– Transforms structural elements of the architecture into a procedural description of software construction

The Design Model Which is mapped from the Analysis model S.E. - RSP

Sep. 2003

5

The Design Process
• Mc Glaughlin’s suggestions for good design:
– Design must enable all requirements of the analysis model and implicit needs of the 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
S.E. - RSP

Sep. 2003

6

Design Guidelines
• A design should exhibit a hierarchical organization • A design should be modular • 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
Sep. 2003 7

Design Principles
• Design Process:
– Iterative steps that enable description of all aspects of the software

• Design principles:
– 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
Sep. 2003 S.E. - RSP 8

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 – 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
Sep. 2003 S.E. - RSP 9

Module Specification Body

Specification Type definitions Subprogram profiles Constants Body Encapsulated data Subprogram definitions

Sep. 2003

10

Proc Main; x: tp; ax: a; … p(x); ax = F; ...

type tp is .. type a is access tp; Proc P(z: tp); func F ret a;
// Caution with pointers!!

//

Y: tp; Proc P is … end P; func F is … end F;
11

Sep. 2003

Module A specification Module B body s: A.shuttle; x_coord: float; … s := A.get; display(s); … x_coord := s.x; ...
Sep. 2003

type shuttle is record x: float; -- wrt to coord sys y: float; -- wrt to coord sys z: float: -- wrt to coord sys roll: float; pitch: float; yaw: float; end record; function get return shuttle; Body A
12

Module A specification Module B body s: A.shuttle; x_coord: float; … s := A.get; display(s); … x_coord := s.x; ...
Sep. 2003

type shuttle is record x: float; -- latitude y: float; -- longitude z: float: -- elevation roll: float; pitch: float; yaw: float; end record; function get return shuttle; Body A
13

Module A specification Module B body s: A.shuttle; x_coord: float; … s := A.get; A.display(s); … x_coord := A.get_x(s); ...
Sep. 2003

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; … procedure display(s:shuttle); … private type shuttle is record x,y,z: float; roll, pitch,yaw: float; end record;
14

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 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.
Sep. 2003 S.E. - RSP 15

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
– 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
Sep. 2003 S.E. - RSP 16

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 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
Sep. 2003 S.E. - RSP 17

Module A specification Module B body s: A.shuttle; x_coord: float; … s := A.get; A.display(s); … x_coord := A.get_x(s); ...
Sep. 2003

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; … procedure display(s:shuttle); … private type shuttle is record x,y,z: float; roll, pitch,yaw: float; end record;
18

Modularity & Software Cost

Sep. 2003

19

Modularity
Objectives of modularity in a design method • Modular Decomposability
– Provide a systematic mechanism to decompose a problem into sub problems

• 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.
Sep. 2003 S.E. - RSP 20

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)

• Modular Protection
– If there is an error in the module, then those errors are localized and not spread to other modules
S.E. - RSP

Sep. 2003

21

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 – This addresses how the design architecture achieves requirements for performance, reliability and security • Families of Related Systems
– The ability to reuse architectural building blocks
Sep. 2003 S.E. - RSP 22

Structural Diagrams

Sep. 2003

23

Kinds of Models
• Terminology
– Structural models
• Organized collection of components

– 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
Sep. 2003 24

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

S.E. - RSP

25

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 • Also very maintainable

Sep. 2003

S.E. - RSP

26

Information Hiding
• Modules are characterized by design decisions that are hidden from others • 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
Sep. 2003 27

Module A specification Module B body s: A.shuttle; x_coord: float; … s := A.get; A.display(s); … x_coord := A.get_x(s); ...
Sep. 2003

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; … procedure display(s:shuttle); … private type shuttle is record x,y,z: float; roll, pitch,yaw: float; end record;
28

Functional Independence
• Critical in dividing system into independently implementable parts • Measured by two qualitative criteria
– Cohesion
• Relative functional strength of a module

– Coupling
• Relative interdependence among modules

Sep. 2003

29

Modular Design -- Cohesion
• A cohesive module performs a single task • Different levels of cohesion
– Coincidental, logical, temporal, procedural, communications, sequential, functional

Sep. 2003

30

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 connection in data and control

• Temporal Cohesion
– Modules are bound together because they must be used at approximately the same time
Sep. 2003 S.E. - RSP 31

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 necessity to be activated in a particular order

• Functional Cohesion
– All elements of a module relate to the performance of a single function

Sep. 2003

S.E. - RSP

32

Modular Design -- Coupling
• Coupling describes the interconnection among modules • Data coupling
– Occurs when one module passes local data values to another as parameters

• Stamp coupling
– Occurs when part of a data structure is passed to another module as a parameter

Sep. 2003

S.E. - RSP

33

Modular Design -- Coupling
• Control Coupling
– Occurs when control parameters are passed between modules

• Common Coupling
– 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
Sep. 2003 S.E. - RSP 34

Examples of Coupling

Sep. 2003

35

Design Heuristics
• Evaluate 1st iteration to reduce coupling & improve cohesion • 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
Sep. 2003 36

Design Heuristics
• Define modules with predictable function & avoid being overly restrictive
– 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
Sep. 2003 37

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 enable design simplification • A design document is an essential part of the process

Sep. 2003

S.E. - RSP

40

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 components, and the relationships between them

October 2003

SRIMCA

2

S/W Architecture
Analyze the effectiveness of the design in meeting its stated reqs.  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.

October 2003 SRIMCA 3

Why is Architecture important?
 

Enabler for comm. between parties (stakeholders). Highlights early design decisions which 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.
SRIMCA 4

October 2003

Data Design

What is data design?

Transform the information domain model created during analysis into data structure required to implement the software Well-designed data lead to better program structure and modularity, reduced procedural complexity

October 2003

SRIMCA

5

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 operate directly upon the data structure
 Constrain

the scope of effect of data design

decisions

Or, from OO perspective, define all operations performed on the data structure
October 2003 SRIMCA 6

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.

October 2003

SRIMCA

7

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

October 2003

8

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

October 2003

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

October 2003

SRIMCA

10

Architectural Styles

Taxonomy of styles
Data-centered architectures  Data-flow architectures  Call and return architectures

– Main Program/Subprogram – Remote procedure call

Object-oriented architectures  Layered architectures

Organization and refinement
Control  Data

October 2003

SRIMCA

11

Architectural Design

Objective

develop a modular program structure and represent control relationships between modules

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)

October 2003 SRIMCA 12

Architectural Design Process

Six-step Process
     

the type of information flow is established flow boundary are indicated 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.
SRIMCA 13

October 2003

Architectural Design Process
(cont.)

Transform Flow
outgoing flows B C

incoming flow A transform center

October 2003

SRIMCA

14

Architectural Design Process
(cont.)

Transaction Flow
Transaction T Action paths

Transaction center

October 2003

SRIMCA

15

Transform Mapping

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

October 2003

SRIMCA

16

Level 0 Safehome DFD

October 2003

SRIMCA

17

Level 1 Safehome DFD

October 2003

SRIMCA

18

Level 2 Safehome DFD - Monitor

October 2003

SRIMCA

19

Transform Mapping

(cont)

Design steps
 Step

1. Review the fundamental system 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
October 2003 SRIMCA 20

Level 3 DFD for Monitor Sensors

October 2003

SRIMCA

21

Transform Mapping

(cont)

step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries
 

different designers may select slightly differently transform center can contain more than one 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.

October 2003

SRIMCA

22

First Level Factoring

October 2003

SRIMCA

23

Transform Mapping
 step

(cont)

6. Perform “second-level factoring”

– mapping individual transforms(bubbles) to appropriate modules. – factoring accomplished by moving outwards from transform center boundary.
 step

7. Refine the first iteration program structure using design heuristics for improved software quality.

October 2003

SRIMCA

24

Second Level Factoring

October 2003

SRIMCA

25

First-Cut Program Structure

October 2003

SRIMCA

26

Refined Program Structure

October 2003

SRIMCA

27

Transaction Mapping
A single data item triggers one or more information flows

October 2003

SRIMCA

28

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 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.
October 2003 SRIMCA 29

Transaction Mapping (cont)

step 5. Map the DFD in a program structure amenable to transaction processing
 incoming  dispatch

branch branch

– bubbles along this path map to modules – dispatcher module controls all subordinate action modules – each action path mapped to corresponding structure
October 2003 SRIMCA 30

Transaction Mapping

October 2003

SRIMCA

31

First Level Factoring

October 2003

SRIMCA

32

First-cut Program Structure

October 2003

SRIMCA

33

Transaction Mapping (cont)
step 6. Factor and refine the transaction structure and the structure of each action path  step 7. Refine the first iteration program structure using design heuristics for improved software quality

October 2003

SRIMCA

34

Design Postprocessing
     

A processing narrative must be developed for each module An interface description is provided for each 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)
SRIMCA 35

October 2003

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 characteristics described in the analysis model to derive program structure DFD is mapped into program structure use two approaches: transform and transaction mapping
SRIMCA 36

October 2003

Interface Design
Interfaces between software modules  Interfaces between software and nonhuman producers and consumers

 For

example, sensors and actuators

Interfaces between the human and computer

October 2003

SRIMCA

37

INTERNAL & EXTERNAL INTERFACE DESIGN

Intermodular interface design
 

DFDs show data flow between modules Arrows map into parameters in and out of interface Determine functions & procedures using/producing the data Typically involves both hardware & software Often supplied by vendor, e.g., A/D boards Often complex functionality

External interface design
  

Data validation and error handling SRIMCA October 2003

HCI DESIGN MODELS
 

Design Model - data, architectural, interface,
and procedural representations

User Model - profile of end user,
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
SRIMCA

October 2003

The User Interface Design Process
 User,

task, and environment analysis and modeling  Interface design  Interface construction  Interface validation

October 2003

SRIMCA

TASK ANALYSIS & MODELING
 

Define and classify tasks

Stepwise elaboration

Establish goals and intentions for task  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
October 2003 SRIMCA

DESIGN ISSUES

System response time - primary user complaint
 

Length Variability Scope Access methods Representation How return to normal process Structure
SRIMCA

User help facilities - integrated vs. add-on
    

October 2003

DESIGN ISSUES - CONTINUED

frustration  Understandable language  Constructive advice  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
October 2003 SRIMCA

Error information handling - reduce user

DESIGN EVALUATION
Length and complexity of written specification  Number of commands, average number of arguments per command, operations per action  Number of actions, commands, and system states -- memory load on user  Interface style, help facilities, and error handling protocol

October 2003 SRIMCA

DESIGN EVALUATION

October 2003

SRIMCA

45

DESIGN GUIDELINES GENERAL INTERACTION
         

Be consistent Offer meaningful feedback Ask for verification of any destructive action 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
SRIMCA

October 2003

DESIGN GUIDELINES INFORMATION DISPLAY
        

Display only information relevant to current context Use format that enables rapid assimilation of information 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
SRIMCA

October 2003

DESIGN GUIDELINES DATA INPUT
       

Minimize number of input actions Maintain consistency between display and input Allow user to customize input Allow for flexible interaction Deactivate commands not relevant in current context Let user control interactive flow Provide help Eliminate unnecessary input
SRIMCA

October 2003

SUMMARY
THE INTERFACE TRIAD
Be good to your users  Do not deceive your users  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

October 2003 SRIMCA

PROCEDURAL DESIGN
 

Basic constructs
 Sequence,

condition and repetition

Notations
 Flow

charts  Tabular  Program Description Language

October 2003

SRIMCA

50

FLOWCHARTS

October 2003

SRIMCA

51

TABULAR NOTATION

October 2003

SRIMCA

52

PROGRAM DESCRIPTION LANGUAGE
REPEAT UNTIL activate switch is turned off reset all signal.values and swtiches; DO FOR alarm.type = smoke, fire, water, temp, burglar; 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; PARBEGIN CALL alarm PROCEDURE WITH “on”, time in sec. CALL phone PROCEDURE WITH mess [alarm.type], phone.number; ... 53
October 2003 SRIMCA

CONTROL STRUCTURE DIAGRAM

October 2003

SRIMCA

54

DESIGN FOR REAL-TIME SYSTEMS

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

Outline
• The introduction to real-time system
– Some key issues that differentiate the real-time systems from other types of computer software

• Analysis and simulation of real-time systems • Design for real-time systems

December 25, 1997

Assistance - Yaru Liu

2

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 constrains • Time is the most important issue in realtime system • Fast and real-time are not the same
– Real-time is predictability and meeting deadlines, not necessarily fast.
December 25, 1997 Assistance - Yaru Liu 3

System Considerations
Some differences between real-time software development and other software engineering 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
December 25, 1997 Assistance - Yaru Liu 4

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 • 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
December 25, 1997 Assistance - Yaru Liu 5

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 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?
December 25, 1997 Assistance - Yaru Liu 6

Performance Issues
• Key parameters that affect the system response time
– 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
December 25, 1997 Assistance - Yaru Liu 7

Interrupt handling
“Normal” processing flow

Interrupt is posted

Software Interrupt handling
•Save state of interrupted program •Determine nature of the interrupt •Service interrupt •Restore state of interrupted program •Return to interrupted program

December 25, 1997

Assistance - Yaru Liu

8

Nested Interrupt Handling

December 25, 1997

Assistance - Yaru Liu

9

Real-time Date Bases
• Distributed databases
– Multitasking is the commonplace and data are often processed in parallel – A failure of one database need not cause failure 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.
December 25, 1997 Assistance - Yaru Liu 10

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 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.
December 25, 1997 Assistance - Yaru Liu 11

Real-Time Operating Systems
• Must provide memory sharing threads • Must provide efficient tasking (context) switching • Should provide synchronization mechanism • Advanced RTOS may provide task scheduling

December 25, 1997

Assistance - Yaru Liu

12

Real-time languages
• Some differences between a real-time language and a general-purpose language
– Multitasking capability – 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
Assistance - Yaru Liu 13

December 25, 1997

Task Synchronization and Communication
• Three general approaches
– Queuing semaphores
• manage several queues

– Mailboxes
• 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
December 25, 1997 Assistance - Yaru Liu

14

Analysis and simulation of realtime systems
• Tools for real-time system analysis
– 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
December 25, 1997 Assistance - Yaru Liu 15

Mathematical tools for real-time system 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
December 25, 1997 Assistance - Yaru Liu 16

Mathematical tools for real-time system analysis
Data arrival rate P12 = 0.6 Information source in

2 3

1
P13 = 0.4

Unit cost = 4.6 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
December 25, 1997 Assistance - Yaru Liu 17

DFD for Real-Time

December 25, 1997

Assistance - Yaru Liu

18

Queuing Model

December 25, 1997

Assistance - Yaru Liu

19

Queuing Reduction Rules

December 25, 1997

Assistance - Yaru Liu

20

Simplifying Networks

December 25, 1997

Assistance - Yaru Liu

21

Simulation and modeling tools
• The conceptual view
– Functional view is captured with activitycharts, 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
December 25, 1997 Assistance - Yaru Liu 22

Example

December 25, 1997

Assistance - Yaru Liu

23

Statechart for Example

December 25, 1997

Assistance - Yaru Liu

24

Simulation and modeling tools
• The physical view
– The conceptual model is the foundation, but not a real system – Decompose a system into subsystem, 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
December 25, 1997 Assistance - Yaru Liu 25

Simulation and modeling tools
• Running scenarios
– Correctness of function or behavior – Engineer can play role of user & enter tests

• Programming simulations
– Simulation control language (SCL)

• Automatic translation of activity and statecharts into code
December 25, 1997 Assistance - Yaru Liu 26

Real-time design
• Incorporate all of the fundamental concepts and principles associated with high-quality software • A set of unique problems
– Representation of interrupts and context switching – Concurrency as manifested by multitasking and multiprocessing – Inter-task communication and synchronization
December 25, 1997 Assistance - Yaru Liu 27

Real-time design (cont’d)
– Wide variations in data and communication rates – Resource management of shared resources – 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)
December 25, 1997 Assistance - Yaru Liu 28

Real-time design
• A number of modeling principles
– – – – Explicit atomicity Interleaving Nonterminating histories and fairness Closed system principle - include environment with computer system in analysis – Structuring state by objects – Sometimes, physically measure task times
December 25, 1997 Assistance - Yaru Liu 29

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 realworld 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
December 25, 1997 Assistance - Yaru Liu 30

Software Testing Techniques

Introduction
• Many aspects to achieving software quality
– Formal reviews (of both the software process and the various stages of development), audits, documentation, etc. – Unit testing – Integration testing – Verification
• Does the module meet the specifications

– Validation
• Does the product meet the requirements
2

CLCS Test Approach
Operations Environment

User Acceptance Tests

System S/W Validation Tests
System Delivery

COTS H/W on Dock

System Test

User App S/W Validation Tests

Acceptance Test

User Eval CSCI Int Test

Integration Environment

Developers
Early Unit Integ User Eval Test

System Integration and Test Group Validation Group Application S/W IPT

Design

Unit Test

Development Environment

Users

Introduction
• A Critical element of the Software Quality Assurance • 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)
4

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 probability of finding an as-yet undiscovered error • A Successful test is one that uncovers an asyet undiscovered error
5

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

6

Testability
• The ease with which a computer program can be tested .

7

Characteristics for Testability
• Operability
– the better it works , 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

8

Characteristics for Testability
• Observability
– what you see is what you test
• • • • • • 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
9

Characteristics for Testability
• Controllability
– the better we can control the software , the more testing can be automated
• 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
10

Characteristics for Testability
• Decomposability
– By controlling the scope of testing , isolate 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
11

Characteristics for Testability
• Simplicity
– the less there is to test , the more quickly we can test it
• Functional simplicity • Structural simplicity • Code simplicity

12

Characteristics for Testability
• Stability
– the fewer the changes , the fewer disruptions to testing
• • • • Changes are infrequent Changes are controlled Changes do not invalidate existing tests The software recovers well from failures

13

Characteristics for Testability
• Understandability
– the more information we have , 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
14

“A Good Test”
• A good test has a high probability of finding an error • 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

15

Types of Testing
• White-Box Testing
– Knowing the internal workings of a product, tests are conducted to ensure that “all gears all 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)
16

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

Why White Box Testing?
• Logic errors and incorrect assumptions are inversely proportional to the probability that a 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.

18

Basis Path Testing
• Attacks the control flow of the program • Provides us with a logical complexity 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
19

Basis Path Testing
• A Flow Graph created
– 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

20

Flow Graph Notation

21

Basis Path Testing ( contd.)
• Example PDL
1: 2: 3: 4: 5: 6: 7a: 7b: 8: procedure sort do while records remain read record ; if record field1 = 0 then process record ; store in buffer ; increment counter ; elseif record field2 = 0 then reset counter ; else process record ; store in file ; endif endif enddo end 22

Basis Path Testing ( contd.)
• Flow Graph 1 2 4 6 7a 7b 8
23

3 5

Basis Path Testing ( contd.)
• Cyclomatic Complexity
– 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
24

Basis Path Testing ( contd.)
• Cyclomatic Complexity calculation
V (G) = E -N+ 2 = P+1 = No. of regions in the graph where E = no. of edges, N = no. of nodes, and P = no. of predicate nodes

• For the previous example

Independent paths path 1 : path 2 : path 3 : path 4 : 1-8 1 - 2 - 3 - 7b - 1 - 8 1 - 2 - 4 - 6 - 7a - 7b - 1 - 8 1- 2 - 4 - 5 - 7a - 7b - 1 - 8

Cyclomatic complexity = 11 - 9 + 2 = 3 + 1 = 4
25

Basis Path Testing ( contd.)
• Prepare test cases that will force execution of each independent path in the Basis Path set • Each test case is executed and compared to expected results

26

Example

27

Example

28

Condition Testing
• Exercises all the logical conditions in a module • Types of possible errors
– – – – Boolean variable error Boolean Parenthesis error Boolean Operator error Arithmetic expression error
29

Types of Condition Testing
• Branch Testing
– the TRUE and FALSE branches of the condition 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.
30

Types of Condition Testing
• BRO (Branch and Relational Operator) Testing – detection of branch and relation operator errors in a condition, provided that, all boolean variables and relational operators in the condition occur only once and have no common values.

31

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

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

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

Loop Testing ( contd.)
• Concatenated loops
– Multiple simple loop tests if independent – Nested loop approach if dependent

• Unstructured loops
– Should be restructured into a combination of simple and nested loops

36

Black Box Testing
• Focus is on the functional requirements of the software • Uncovers errors such as
– – – – – 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
37

Graph Based Testing
• Identify all objects modeled by the software • Identify the relationships that connect these objects • Create an Object-Relationship graph
– – – – node node weights links link weights
38

Graph Testing ( contd.)
• Example graph
menu select generates generation < 1 sec allows editing of

new file
is represented as

Document window
Attributes :
start dimension Background color text color

contains

Document text

39

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

40

Equivalence Partitioning
• Input domain divided into classes of data from which test cases are derived • 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
41

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

Equivalence Partitioning ( cont. )
• Example
Automatic Banking
– area code : input condition , boolean input condition , range [200,999] – prefix : input condition , range >200, no 0’s, < 1000 – suffix : input condition , value -- 4 digits : input condition , boolean – password input condition , value -- 6 char str – command : input condition , set
43

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

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

Other Cases
• GUI testing
– See text for partial list of things to test

• Client Server
– Often distributed -- complicates testing – Additional emphasis on non-interference among clients

• Documentation
– Use black box techniques

• Real-time
– Beyond the scope of this course
46

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 Data flow testing Loop testing Graph based testing Equivalence partitioning Boundary Value testing Comparison testing

• Black Box Testing - Functional requirements

47

CLCS Example
Software IRIX (UNIX operating system) Vendor Silicon Graphics Incorporated (SGI) Version 6.2 6.3 5.2 Platform SGI Indigo 2, SGI Indy, SGI Challenge SGI O2 SDS Gateway, CS Gateways Facility SDE, LCC-X SDE, LCC-X SDE, LCC-X

IRIX (UNIX Silicon Graphics operating system) Incorporated (SGI) VxWorks (Gateway VxWorks OS)

Table 1.1: Juno Baselined COTS Software
48

CLCS Example
data. Step 1. 2.

Description
Turn on SDE1 network hardware and PC’s Turn on the sde1net workstation, wait for it to finish booting (login screen will be displayed), then turn on the sde1boot workstation and wait for it to finish booting. Turn on all remaining HCI workstations and the sde1ddp1 machine.

Expected Results
Blinky lights start blinking on the network devices, PC’s execute power on self tests, boots OS POST (Power On Self Test) tests occur, Operating system start procedures initiate, Login screens appear. POST (Power On Self Test) tests occur, Operating system start procedures initiate, Login screens appear.
49

3.

CLCS Example
16.
Initiate data acquisition at the sde1hci7 workstation. In the Dnav master menu, select “Global Apps”, then select “Start receive process”, then select “GW to HCI JUNO_DDP_8” Start data display. In the Dnav master menu, select “Shuttle”, then select any of the following: Wind Speed Wind Direction PAD A Wind Direction PAD B Temperature Stop data display at the workstation. Select quit from display menu(s) The System messages window indicates that the Start receive process is executing, no unexpected errors are displayed in the console window. The command is accepted (as shown in the System messages and console windows), the appropriate display(s) are started and are regularly updated.

17.

18.

Display windows are closed.

50

Test Results
Number Title Juno-11 Juno-12 Juno-13 Juno-14 Juno-15 Telnet from sde1hci1 to sde1ddp-r failed Remote delog written into wrong directory Application displays CPU intensive Telnet to SDS Gateway not working Error received when attempting to start receive process Opened During System Test System Integration System Integration System Test System Test Criticality Major Major Minor Minor Major Date Opened 4/14/97 4/15/97 4/15/97 4/22/97 4/22/97 Current Status Open Open Open Open Open

51

Lessons Learned
• The configuration management process was not complete, multiple baselines of some software components existed. • 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.
52

CHAPTER 17

SOFTWARE TESTING STRATEGIES

1

TOPICS
A

strategic approach to software testing  Unit Testing  Integration Testing  Validation Testing  System Testing  The ART of Debugging  Summary
2 April 2004 SRIMCA

STRATEGIC APPROACH TO SOFTWARE TESTING
Generic characteristics of software testing strategies: Testing

begins at module level and works outward 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.
3 April 2004 SRIMCA

Verification and Validation

 Verification

-- Does the product meet its specifications?  Validation -- Does the product perform as desired?
April 2004 SRIMCA

4

Software Testing Strategy
A Software Testing Strategy

5 April 2004 SRIMCA

Software Testing Strategy

6 April 2004 SRIMCA

Software Error Model
 f(t)

= cumulative remaining errors at time t  l0 = initial failure rate  p = exponential reduction as errors repaired f(t) = (1/p)ln(l0pt + 1)

7 April 2004 SRIMCA

STRATEGIC APPROACH
 Issues

to be addressed to develop a successful software testing strategy:
 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.”
8 April 2004 SRIMCA

STRATEGIC APPROACH
 Issues

to be addressed to develop a successful software testing strategy:
 Build

robust software that is designed to test

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
9 April 2004 SRIMCA

UNIT TESTING
 Unit

testing -- focuses on the smallest element of software design viz. the module.
 Corresponds

to class testing in the OO context.

 Makes

heavy use of white-box testing.

10 April 2004 SRIMCA

UNIT TESTING
Unit Test Generation Considerations:
Review Design information - develop unit test cases. interface local data structures boundary conditions independent paths error handling paths Test cases
11 April 2004 SRIMCA

driver Module to be tested stub stub

Unit Test Generation
 Interface
#

considerations

of input parameters = # arguments?  Parameter and argument attributes match?  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?
12 April 2004 SRIMCA

Unit Test Generation
 External
 Files

I/O considerations

attributes correct?  OPEN/CLOSE correct? 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?
13 April 2004 SRIMCA

Unit Test Generation
 Data

structure considerations

 Improper

or inconsistent typing?  Erroneous initialization or default values?  Incorrect variable names?  Inconsistent data types?  Underflow, overflow and addressing exceptions?

14 April 2004 SRIMCA

Unit Test Generation
 Test

cases must cover all execution paths  Common computational errors to be checked:
 incorrect

arithmetic  mixed mode operations  incorrect initialization  precision inaccuracy  incorrect symbolic representation of expression
 Other

tests needed

 incompatible

data types in comparisons  incorrect logical operators or precedence  comparison problems (e.g., == on floats)  loop problems
April 2004 SRIMCA

15

Unit Test Generation
 Error

handling tests

 Exception-handling

is incorrect?  Error description is unintelligible, insufficient or incorrect?  Error condition causes system interrupt before error handling completed?

16 April 2004 SRIMCA

INTEGRATION TESTING
A

systematic approach for constructing program structure while conducting tests to uncover errors associated with interfacing.  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
17 April 2004 SRIMCA

INTEGRATION TESTING

18 April 2004 SRIMCA

INTEGRATION TESTING
Top-Down Approach  Begin construction and testing with main module.
 Stubs

are substituted for all subordinate modules.

 Subordinate

stubs are replaced one at a time by 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.
19 April 2004 SRIMCA

Top Down Approach - Use Stubs

20 April 2004 SRIMCA

INTEGRATION TESTING
Top-Down Approach :
 Advantages:
 Verifies

major control or decision points early in the test process.  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.
SRIMCA

21

April 2004

INTEGRATION TESTING
Bottom Up Approach :
 This

approach begins construction and testing with modules at the lowest levels in the 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.
22 April 2004 SRIMCA

Bottom Up Approach

23 April 2004 SRIMCA

INTEGRATION TESTING
Bottom Up Approach
 Advantages:
 Easier

test case design and lack of stubs.

 Disadvantages:
 The

program as an entity is does not exist until the last module is added.

Sandwich Testing:- combined approach
 Top

down strategy for upper levels and Bottom up strategy for subordinate levels.
24 SRIMCA

April 2004

INTEGRATION TESTING
 Regression

Testing

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 different classes of test cases :  A representative sample of tests that will exercise all software functions  Additional tests that focus on functions that are likely to be affected by the change.  Tests that focus on software components that have changed. 25
April 2004 SRIMCA

 Re-execution

INTEGRATION TESTING
Integration Test Documentation
1
Scope of testing

2
Test plan

3
Test Procedure n

4
Actual Test Results

5
Ref. & Appendix

Environment Test Unit Test Schedule / Resources case test phases data Overhead and Test software builds environment Order of Integration
April 2004 SRIMCA

Expected Results for build n

26

VALIDATION TESTING
 It

provides final assurance that software meets all functional, behavioral, and performance requirements.

-- 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 testing
 Alpha

test -- At developer’s site by customer.  Beta test -- At customer’s site in a “live” environment. 27
April 2004 SRIMCA

SYSTEM TESTING
A

series of tests to verify that all system elements have been properly integrated.
Testing:
 Forces

 Recovery

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

April 2004

SYSTEM TESTING
 Stress

Testing:

 Executes

the system in a manner that demands resources in abnormal quantity, frequency or volume.

 Performance
 To

Testing:

test the run time performance of a system within the context of an integrated system.

29 April 2004 SRIMCA

CLCS Test Approach
Operations Environment

User Acceptance Tests

System S/W Validation Tests
System Delivery

COTS H/W on Dock

System Test

User App S/W Validation Tests

Acceptance Test

User Eval CSCI Int Test

Integration Environment

Developers
Early Unit Integ User Eval Test

System Integration and Test Group Validation Group Application S/W IPT

Design

Unit Test

Development Environment

Users

THE 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.  Debugging is an ART. The external manifestation of the error and the cause of the error normally do not share an obvious relationships.
31 April 2004 SRIMCA

THE ART OF DEBUGGING
The Debugging process
Execution of test cases Test cases

Results Suspected causes Debugging
32

Additional tests

Regression tests Corrections
April 2004 SRIMCA

Identified causes

THE ART OF DEBUGGING
 Debugging
 Brute

Approaches
:- Once an error is uncovered, trace

force : - Take memory dumps, invoke run

time traces. Least efficient and quite common.
 Backtracking  Cause  Use

your way back to the cause of the error.

Elimination : - Isolate potential causes,

devise cause hypotheses tests to isolate bug.

of debugging tools

33 April 2004 SRIMCA

COMMENTS
 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 is destructive.
 When

are we done with testing ?

 “You

are never done with testing, the burden shifts from you to the customer.”
34

April 2004

SRIMCA

SUMMARY
 Software

Testing accounts for the largest percentage of technical effort in the software process.  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.
35 April 2004 SRIMCA

Technical Metrics for Software
Chapter 18

Chapter Outline
       

Software Quality A Framework for Technical Software Metrics Metrics for the Analysis Model Metrics for the Design Model Metrics for Source Code Metrics for Testing Metrics for Maintenance Summary
January 2004 Chapter 18 -- SRIMCA 2

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 rather than after-the-fact

January 2004

Chapter 18 -- SRIMCA

3

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

January 2004

Chapter 18 -- SRIMCA

4

McCall’s Software Quality Factors
Maintainability Flexibility Testability Portability Reusability Interoperability

Product Revision

Product Transition

Product Operation
Correctness Reliability Usability Integrity Efficiency

Fq   c i  mi
January 2004 Chapter 18 -- SRIMCA 5

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
January 2004 Chapter 18 -- SRIMCA 6

Transition to a Quantitative View
 

Previous slides described qualitative factors for the measurement of software quality Everyday quality measurements
  

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

January 2004

Chapter 18 -- SRIMCA

7

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 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.
January 2004 Chapter 18 -- SRIMCA 8

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
January 2004 Chapter 18 -- SRIMCA 9

Attributes of Effective Software Metrics
     

Simple and computable Empirically and intuitively persuasive Consistent and objective Consistent in units and dimensions Programming language independent Effective mechanism for quality feedback

January 2004

Chapter 18 -- SRIMCA

10

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

January 2004 Chapter 18 -- SRIMCA 11

Function Point Metric
MEASUREMENT PARAMETER count Weighting Factor simple average complex total

number of user inputs number of user outputs number of user inquiries number of files number of external interfaces count - total

3 2 2 1 4

x x x x x

3 4 3 7 5

4 5 4 10 7

6 7 6 15 10

=9 =8 =6 =7 = 20 50

Overall implemented size can be estimated from the projected FP value

FP = count-total  (0.65 + 0.01   Fi)
January 2004 Chapter 18 -- SRIMCA 12

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. With the evaluation of these primitives, software can be defined as either function-strong or datastrong. Once the Bang metric is computed, past history must be used to predict software size and effort.
January 2004 Chapter 18 -- SRIMCA 13

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

January 2004

Chapter 18 -- SRIMCA

14

Metrics for Requirements Quality

Specificity (lack of ambiguity)
Q = nui/nr  nui - number of requirements for which all 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
January 2004 Chapter 18 -- SRIMCA 15

High-Level Design Metrics

Structural Complexity
S(i) = f out(i)  fout(i) = fan-out of module i

2

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)
January 2004 Chapter 18 -- SRIMCA 16

High-Level Design Metrics (Cont.)

Morphology Metrics
size = n + a  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

January 2004 Chapter 18 -- SRIMCA 17

Morphology Metrics
a b f h size depth
January 2004

c g m

d i n

e j p k q l r

width

arc-to node ratio
18

Chapter 18 -- SRIMCA

AF Design Structure Quality Index
 S1

= total number of modules  S2 = # modules dependent upon correct data source or produces data used, excl. control  S3 = # modules dependent upon prior processing  S4 = total number of database items  S5 = # unique database items  S6 = # of database segments  S7 = # modules with single entry & exit
January 2004 Chapter 18 -- SRIMCA 19

AF Design Structure Quality Index
 D1

= 1 if arch design method used, else 0  D2 = 1 - (S2/S1) -- module independence  D3 = 1 - (S3/S1) -- independence of prior processing  D4 = 1 - (S5/S4) -- database size  D5 = 1 - (S6/S4) -- DB compartmentalization  D6 = 1 - (S7/S1) -- Module entrance/exit
January 2004 Chapter 18 -- SRIMCA 20

AF Design Structure Quality Index
= wiDi, where the wi are weights totaling 1 which give the relative importance  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.
 DSQI
January 2004 Chapter 18 -- SRIMCA 21

Component-Level Design Metrics
 

Cohesion Metrics Coupling Metrics
data and control flow coupling  global coupling  environmental coupling

Complexity Metrics
Cyclomatic complexity  Experience shows that if this > 10, it is very difficult to test

January 2004 Chapter 18 -- SRIMCA 22

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  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 Cohesion
SFC(i) = SG(i)/tokens(i)

January 2004

Chapter 18 -- SRIMCA

23

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 gd = number of global variables used as data gc = number of global variables used as control 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)

Global coupling
 

Environmental coupling
    

January 2004

Chapter 18 -- SRIMCA

24

Interface Design Metrics
 

Layout Entities - graphic icons, text, menus, windows, . Layout Appropriateness
  

absolute and relative position of each layout entity 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
January 2004 Chapter 18 -- SRIMCA 25

Metrics for Source Code

Software Science Primitives  n1 = the number of distinct operators  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)
January 2004 Chapter 18 -- SRIMCA 26

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 SAVE = X(I) X(I) = X(J) X(J) = SAVE 10 CONTINUE 20 CONTINUE RETURN END

OPERATOR COUNT 1 END OF STATEMENT 7 2 ARRAY SUBSCRIPT 6 3 = 5 4 IF( ) 2 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 = 22 n2 = 7

January 2004

Chapter 18 -- SRIMCA

27

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

January 2004 Chapter 18 -- SRIMCA 28

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

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
January 2004 Chapter 18 -- SRIMCA 29

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.

January 2004

Chapter 18 -- SRIMCA

30

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 assess program quality. Using the metrics as a comparison with known successful or unsuccessful projects is better than treating them as absolute quantities.

January 2004

Chapter 18 -- SRIMCA

31

Chapter 19 OBJECT ORIENTED MODELING, CONCEPTS AND PRINCIPLES

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat

1

CONTENTS
 What

is object-oriented development ?  Object-oriented process model  Object-oriented concepts  Object modeling technique  Unified Modeling Language (UML)  Concepts and Principles of Object Modeling  Object-oriented vs functional approach
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 2

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 single entity called an object.
 Leads

to reuse, faster software development and higher quality programs.  Easier to maintain
• Structure inherently decoupled • Fewer side-effects
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 3

The OO process model
 Moves

through an evolutionary spiral  Emphasizes development of reuse capability

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat

4

Object Oriented Concepts
 Objects

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. 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.
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 5

 Classification

Object Modeling
& Classes

• A class describes a group of objects with similar properties (attributes), common behavior (operations), common relationships to other objects, and common semantics.

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat

6

Object Classes
 Thus,

a class is an abstraction that describes relevant properties and hides the rest. Represented diagrammatically as below. Class Name Attributes Operations

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat

7

Object Modeling

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat

8

Object Modeling
 Attributes:

An attribute is a data value held by the objects in a class. Name, age, and weight are attributes of Person objects.

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat

9

Object Modeling
 Operations

and Methods :

• Operations : An operation is a function or transformation that may be applied to or by objects in a class. Each operation has a target object as an implicit argument. The behavior of 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.
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 10

Object Modeling
 An

operation may have arguments in addition to its target object. Such arguments parameterize the operation but do not affect the choice of method.

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 11

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 12

Class and Instance
Polygon Vertices Border Color Fill Color Draw Erase Move
February 14, 1999 R. A. Volz

Polygon v={(0,0),(0,1),(1,0)} BC = Red FC = Blue Draw Erase Move
Chapter 19 -- Assistance -- Lamimi V. Kamat 13

Abstraction and Encapsulation

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 14

Abstraction and Encapsulation
 Abstraction

• Isolate those aspects that are important and suppress (or hide) those that are unimportant (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.
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 15

Abstraction and Encapsulation
 Encapsulation

(Information Hiding)

• Separates the external aspects of an object, 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.
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 16

Interfaces
<<Interface>> Class Name Operations
 Does

not have an implementation of its own.  Other classes provide implementations of it.  Client classes are only interested in behavior.
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 17

Inheritance
 Sharing

of attributes and operations among classes based on hierarchical relationship.

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 18

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 19

Class and Subclass
Polygon Vertices Border Color Fill Color Draw Erase Move
February 14, 1999 R. A. Volz

Right Triangle
Vertices Hypotenuse length Border Color Fill Color

• •

Draw Erase Move
Chapter 19 -- Assistance -- Lamimi V. Kamat 20

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 21

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 22

Operations
 Polymorphism

• The same “operation” may behave differently on different classes. E.g., the move operation behaves 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.
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 23

Polymorphism
Polygon Paint Car Paint

Triangle Paint
February 14, 1999 R. A. Volz

Square Paint
Chapter 19 -- Assistance -- Lamimi V. Kamat 24

Communication
 Message:

[destination, operation, params]

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 25

What Does OO Mean?
 Pressman

(Coad & Yourdon)

• • • • • • • •
February 14, 1999

Objects (identity) Classification Inheritance Communication Objects (identity) Classification Inheritance Polymorphism
R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 26

 Rumbaugh

Object Modeling Technique
 Object

modeling technique (OMT) extends from analysis thru design to implementation  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.

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 27

Object Modeling Technique
 The

same seamless notation is used from analysis to design to implementation.  The system is modeled using three related 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.
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 28

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.
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 29

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 30

Object Modeling
 Multiplicity:

• Specifies how many instances of one class may relate to a single instance of an associated class
 Role

Names: attributes

• One end of an association. Binary association has two roles.
 Link

• May be defined for associations, e.g., if the association is “uses,” the link attribute might be one of permission.
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 31

Binary Association & Multiplicity

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 32

Ternary Association

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 33

Link Associations

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 34

Aggregation
A

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

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 35

OO Software Process
 Framework

• • • • • • • • •

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.
R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 36

February 14, 1999

OO Metrics
 Because

of reuse, LOC not so useful  # of Scenario scripts, each a triplet of the form [initiator, action, participant], where
• 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
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 37

Possible Estimating Approach
 Develop

scenario scripts and estimate count  Determine the number of key classes  Categorize key classes Interface type Multiplier No GUI 2.0 Text-based user int. 2.25 GUI 2.5 Complex GUI 3.0
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 38

Possible Estimating Approach
 Estimate

# of support classes by multiplying # key classes in each category by multiplier  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
February 14, 1999 R. A. Volz Chapter 19 -- Assistance -- Lamimi V. Kamat 39

OO Progress Tracking
 This

needs to be done for each iteration (see text for list of specifics in each category)
• • • • OO analysis completed OO design completed OO programming completed OO testing completed

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 40

Object-Oriented vs Structured Approach
 Easier

to maintain  Combines data structure and behavior in a single entity  Emphasizes object structure  Reuse more readily accomplished

 Harder

to maintain  May separate data and behavior  Emphasizes procedural structure  Reuse limited, hence possible delay in software construction

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 41

Object-Oriented vs Structured Approach
 Strong

cohesion and weak coupling  Encapsulation, Inheritance and Polymorphism are strong features of OO software development

 Harder

to achieve weak Coupling and strong cohesion  Some languages support encapsulation and polymorphism, but rarely inheritance

February 14, 1999

R. A. Volz

Chapter 19 -- Assistance -- Lamimi V. Kamat 42

Object Oriented Analysis

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

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? • 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?
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

Principles to Develop OOA model
 Model

Information domain  Describe model function  Represent model behavior  Partition models to expose greater detail
Thus, Early models represent essence of problem while later models provide implementation details.

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

OOA Model Development Steps
 Obtain

basic user requirements; problem statement classes, define attributes, methods class hierarchy Object - Object relationships

 Identify  Specify

 Represent  Model

Object behavior

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

Booch Method - Micro & Macro Development.  Identify classes and objects:
• • • • • • • • • • Propose candidate objects, Conduct behavior analysis, Identify relevant scenarios, Define attributes and operations for each class

OOA Approaches

 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.
Chapter 20 -- Assistance -- Senthil K Veluswamy

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

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:

• Produce appropriate diagrams for representation, • Define class hierarchies, • Perform clustering based on class commonality
 Implement

classes and objects (i.e., complete OO Analysis model).
Chapter 20 -- Assistance -- Senthil K Veluswamy

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

OOA Approaches
Rumbaugh 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
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

Outline of Rumbaugh Method
 Develop

a statement of scope for problem.  Build an Object model
• • • • • • • • • Identify classes, Define attributes and associations, Define object links, Organize classes using inheritance.

 Develop

dynamic model

Prepare scenarios, Define events and trace them, Draw event flow, State diagrams, Review behavior.
Chapter 20 -- Assistance -- Senthil K Veluswamy

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Outline of Rumbaugh Method
 Construct

functional model for system

• Identify inputs and outputs • Use data flow diagrams to represent flow, • Develop Process Specifications for each function, • Specify constraints and optimization criteria.

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

9

Domain Analysis
Domain

Analysis

• Emphasize creating & using library of reusable classes. • Identification, analysis and specification of 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.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

Domain Analysis Process
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 multimedia video games to medical applications.

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

Domain Analysis Procedure
 Goal:

create software within the domain with a high percentage of reusable components.
• • • • • 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.

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

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

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

Generic OOA Model Components

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy 14

OOA Process
 Define

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 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.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

Generating Use Cases
 Begin

with identifying actors and determining how they interact with the system.
• • • • • 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?

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

Use Case Example - Safe Home

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy 17

Use Case Example - Safe Home
 Owner

looks at control panel - Is system ready? enters password;

• If not ready, physically close windows & doors so the ready indicator is present.
 Owner

• Password compared with valid password. • If not correct, beep and reset. • If correct, await further commands.
 Owner

activates system. alarm light comes on.
Chapter 20 -- Assistance -- Senthil K Veluswamy

• Mode AtHome or • Mode Away
 System

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Identifying Object Classes

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

Identifying Object Classes

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy 20

Subjects and Subsystems

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

OOA model with Subject references

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

Safe Home Level 1 DFD

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy 23

OOA Process
 Class-Responsibility-Collaborator

Modeling:

• A means of identifying and organizing classes relevant to the system.
 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.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy

CRC model index card:

CRC

model “tested” by conducting a review driven by use cases.
Chapter 20 -- Assistance -- Senthil K Veluswamy 25

February 21, 1999 -- R. A. Volz

Collaboration Example
 Responsibility:

(As part of activation

procedure)
• Safe home Control Panel must determine if any sensors are open - responsibility determinesensor-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.
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 26

Associations
 Collaborators

suggest associations
Sensor
Determine sensor status

Control Panel

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy 27

Associations & Operations
 Collaborations

suggest operations
Sensor
Determine sensor status

Control Panel

GetState ()

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy 28

OOA Process
 Guidelines

for organizing classes and assigning them responsibilities:
• System intelligence should be evenly distributed. • 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.
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 29

The Object relationship model

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy

Object behavior model
 Evaluate

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. • 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.
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 31

Use Case Example - Safe Home
 Owner

looks at control panel - Is system ready? enters password;

• If not ready, physically close windows & doors so the ready indicator is present.
 Owner

• Password compared with valid password. • If not correct, beep and reset. • If correct, await further commands.
 Owner

activates system. alarm light comes on.
Chapter 20 -- Assistance -- Senthil K Veluswamy

• Mode AtHome or • Mode Away
 System

Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz

State Transition model

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy 33

Event Trace

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy 34

Partial Event Flow Diagram

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy 35

Summary
 OOA

begins with use cases.  Create object, functional and dynamic models  Object Analysis
• 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.

February 21, 1999 -- R. A. Volz

Chapter 20 -- Assistance -- Senthil K Veluswamy 36

Object-Oriented Design

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

1

Outline
From Analysis to Design Design Issues System Design Object Design Design patterns & Conclusion
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 2

Object-Oriented Design
 Transforms

OOA model into blueprint for software construction  Builds upon four essential design concepts
• • • • Abstraction Information hiding Functional independence Modularity

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

3

Mapping OOA to OOD

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

4

Outline
From Analysis to Design Design Issues System Design Object Design Design patterns & Conclusion
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 5

Comparison of Conventional & OOD
 Representation

of module hierarchies  Specification of data definitions  Specification of procedural logic  Indication of end-to-end processing flow  Representation of object states and transitions  Definition of classes and hierarchies  Assignment of operations to classes  Detailed definition of operations  Specification of message connections  Identification of exclusive services
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 6

Design Issues for Modularity
 Decomposability  Composability  Understandability  Continuity  Protection  Linguistic modular units  Few interfaces  Small interfaces (weak coupling)  Explicit interfaces  Information hiding (no global data)
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 7

OOD Methodologies
 The

Booch Method  The Coad and Yourdon Method  The Jacobson Method  The Rumbaugh Method  The Wirfs-Brock Method

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

8

Booch Method
 Architectural

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.
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 9

Booch Method
 Tactical

design

• Define domain-independent 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.
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 10

Booch Method
 Release

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.
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 11

The Rumbaugh OMT
 Perform

system design  Conduct object design  Implement Control mechanisms  Adjust class structure to strengthen inheritance  Design messaging to implement the object relationships  Package classes and associations into modules
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 12

Outline
From Analysis to Design Design Issues System Design Object Design Design patterns & Conclusion
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 13

OOD Process Flow

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

14

System Design
 Partition

the analysis model into subsystems

• A subsystem is a package (collection) of classes and associations, events and constraints that are interrelated and have a small interface. • Usually identified by the services it provides.
 Identify

concurrencies  Allocate subsystems to processors and tasks  Choose a basic strategy for data management

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

15

System Design
 Identify

global resources and access control mechanisms  Design control mechanism for system  Determine how to handle boundary conditions.  Review & modify if necessary

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

16

System Design
Partition 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 subsystem  Communication between subsystems: client/ server (one way) or peer-to-peer (two way)
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 17

Communication Models

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

18

System Design
Going towards High Cohesion

Cohesion
 Coincidental  Logical  Temporal  Communication  Sequential  Functional  Data

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

19

System Design
Concurrency and subsystem Allocation
 Identify

active objects (threads of control)  Where to allocate subsystems
• same processor? -- need concurrency control • independent processor ? -- may still need concurrency control
 Allocation

and design issues:

• performance requirements. • costs • overheads and efficiency
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 20

Concurrency Example
DB access • • • • • • DB access Database

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

21

Concurrency
 Ada

-- Use tasks

task type DB_access is … end; type dba is access DB_access; a, b: dba; … a := new DB_access; b:= new DB_access; …
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 22

Concurrency
 Java

-- Use threads

class dbAccess extends thread{… public void run () { …} … new dbAccess.start(); new dbAccess.start(); }

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

23

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

• 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.
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 24

Data Management
 Generally

refers to shared objects  Concurrency controls essential  Often 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
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 25

System design
Resource Management
 Resources:

External entities vs. abstractions

• E.g., disk, processor, comm line • Databases, objects, interfaces
 Guardian

object:

• Keeper of the resource • Controlling access to the resource • Moderating conflicts for requests
 Language

support can vary widely
Chapter 21 -- Assistance -- Magy Seif El-Nasr 26

February 1, 1998 R. A. Volz

System design
Human-Computer Interface
 Inputs:

user scenarios and roles

 Identify  Reuse

command hierarchy (menu bars, popups, windows, interactive controls, ...) existing support tools whenever possible
• So all that is needed are objects that have appropriate characteristics of problem domain
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 27

Intersubsystem Communication
 Create

a table for each contract

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

28

Subsystem Collaboration Graph
 List

each request made by a collaborator

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

29

Outline
From Analysis to Design Design Issues System Design Object Design Design patterns & Conclusion
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 30

Object Design

February 1, 1998 R. A. Volz

Chapter 21 -- Assistance -- Magy Seif El-Nasr

31

Key Object Characteristics
(Available from Analysis)
 Object

name (or name of class of objects)  Description  Services provided or functions  How created  How invoked  Shared resources  Communication
• With whom? • Interfaces
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 32

Object Design
Object Internals
 Protocol

description

• List each message type the object can receive, e.g., • 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
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 33

Use a PDL to Describe Object
PACKAGE program_component_name IS type specification of data objects … Proc specifications of related operations PRIVATE data structure details for object types PACKAGE BODY program_component_name IS PROC operation: (interface specification) IS … PROC operation: (interface specification) IS END program_component_name
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 34

High Level Sensor PDL
PACKAGE sensor IS TYPE sensor_status IS (ON | OFF) TYPE sensor_id, alarm_char PROC read, set, test PRIVATE sensor_id, IS STRING LENGTH (8) alarm_char DEFINED threshold, sig_type, sig_level IS INTEGER PACKAGE BODY sensor IS TYPE update_rate IS INTEGER PROC read (sensor_id, sensor_status: OUT) ...
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 35

Object Design
Steps done in object design
 Detail

object attributes and operations object-relationship model operations and transitions using

 Review

 Describe

PDLs.
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 36

Outline
From Analysis to Design Design Issues System Design Object Design Design patterns & Conclusion
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 37

Design Patterns
 An

abstraction that conveys meaning about a class’s applicability.  pattern template
• • • • Name : (applicability and intent) Problem description: (env. and conditions) Characteristics Consequences

 Naming

-- choose to aid search  Two different mechanisms
• is-a (inheritance) -- a basis for new subclasses • has-a (composition) - ensemble
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 38

What next ?
 From

Design to implementation  Success of complex projects relies more on the design architecture rather than the 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.
February 1, 1998 R. A. Volz Chapter 21 -- Assistance -- Magy Seif El-Nasr 39

Object-Oriented Testing

February 8, 1998 -- R. A. Volz

Chapter 22

1

Triad to test OO systems
 Broaden

the view of testing  Change strategy for unit and integration testing  Design test cases to account for the unique characteristics of OO software

February 8, 1998 -- R. A. Volz

Chapter 22

2

Broadening the View of Testing
 Review

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
February 8, 1998 -- R. A. Volz Chapter 22 3

Testing OOA & OOD Models
 Use

CRC index card for review

February 8, 1998 -- R. A. Volz

Chapter 22

4

Testing OOA & OOD Models
 Correctness  Consistency

of OOA & OOD Models of OOA & OOD Models

• Judge by conformance with real world domain • 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.
February 8, 1998 -- R. A. Volz Chapter 22 5

Testing OOA & OOD Models
 Consistency

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.

February 8, 1998 -- R. A. Volz

Chapter 22

6

OO - Testing Strategies
 Unit

testing in the OO context testing in the OO context

• Class is the unit of testing • But, one must test through the class hierarchy
 Integration

• Thread-based • Use-based (dependent & independent classes) • Cluster testing -- find errors in collaborations
 Validation

testing in an OO context

• System level testing
February 8, 1998 -- R. A. Volz Chapter 22 7

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:
• • • • • 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.
Chapter 22 8

February 8, 1998 -- R. A. Volz

Test Case Design
 Conventional

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.

February 8, 1998 -- R. A. Volz

Chapter 22

9

Test Case Design
 Fault

based testing

• Use plausible faults to guide test design • 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.
Chapter 22 10

February 8, 1998 -- R. A. Volz

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, summarize, and close, generate random seq. • This should test inappropriate and well as appropriate sequences.

February 8, 1998 -- R. A. Volz

Chapter 22

11

Multiple Class Testing
 For

each client class, generate random test sequences.  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.
February 8, 1998 -- R. A. Volz Chapter 22 12

Multiple Class Testing

February 8, 1998 -- R. A. Volz

Chapter 22

13

Behavior Testing Models
 Ensure

coverage of all states and transitions.

February 8, 1998 -- R. A. Volz

Chapter 22

14

THE PRESENTATION -BY


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

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.