Software Engineering Notes

Software Engineering
An initial calibration of perspective:

How many lines of code are produced, on average, by one software engineer in a year? How long would it take you to do the attached web generation problem? How long would it take you to do the attached web generation problem?
July 03
Chapter 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 $100s of millions?
July 03 Chapter 1 2
Software Engineering Introduction

Some questions to put SE in perspective (cont): 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

In theory, software does not wear out at all.
BUT, Hardware upgrades. Software upgrades.

July 03 Chapter 1 5

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
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
Software Myths
Myth: Its 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 dont 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 cant 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
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
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

Maintenance
Correction -- bugs will appear Adaptation -- to changing operating systems, CPUs, etc. Enhancement -- changing customer needs Prevention -- software reengineering
August 2003
Chapter 2

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

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

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)
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
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 80s The US spent $150 billion $225 billion worldwide
Projects frequently fail or have severe difficulties

New FAA air traffic control system They dont 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.
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
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
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.
Impact of Project Characteristics
January 2004
SRIMCA
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?
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.
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.
A Study on the Impact of Coordination Techniques
January 2004
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.
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
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.
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.
CHECKOUT & LAUNCH CONTROL SYSTEM

Delivery Process Presentation to the Aerospace Safety Advisory Panel
March 19, 1998
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
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
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
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
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
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
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
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
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.
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 teams ability to control the product quality
Process Metrics and Software Process Improvement

Project
Customer characteristics Process
Business conditions
People
Development environment
Technology
March 2004
SRIMCA
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?
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
Use of Software Metrics

Use common sense and organizational sensitivity. Provide regular feedback to individuals and teams. Dont 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. Dont obsess on a single metric to the exclusion of other important metrics. Do not rely on metrics to solve your problems. Beware of people performing to metrics rather than product quality or safety.
Statistical Software Process Improvement (SSPI)

All errors and defects are categorized by origin. The cost to correct each error and defect is recorded. The number of errors and defects in each category is counted and ranked in descending order. The overall cost of errors and defects in each category is computed. Resultant data are analyzed to uncover the categories that result in highest cost to the organization. Plans are developed to modify the process with the intent of eliminating (or reducing) the class of errors and defects that is most costly.
Typical Causes of Product Defects
March 2004
SRIMCA
Example of Defect Analysis

missing ambiguous specification defects
wrong customer queried
customer gave wrong infor.
inadequate inquiries
used outdated information
March 2004
incorrect
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
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.
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
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
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
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
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?
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
SRIMCA
18
Function Point Extensions

Function Points emphasizes data dimension Transformations added to capture functional dimension Transitions added to capture control dimension
March 2004
SRIMCA
19
3-D Function Point Calculation
March 2004
SRIMCA
20
Reconciling Different Metrics
March 2004
C++ Visualbasic
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
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
Measures of Software Quality (Contd)

Integrity to measure a systems 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
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
Integrating Metrics within the Processes

Arguments for S/w Metrics Measurement is used to establish process baseline from which improvements can be assessed. Developers are anxious to find after design: Which user reqs. are most likely to change? Which components in this system are most error prone? How much testing should be planned for each component? How many errors can I expect when testing commences? Answers to these can be found if metrics are collected and used as technical guide.
Integrating Metrics within the Processes

Establishing a baseline Benefits can be obtained at process, project & product levels Consists of data collected from past s/w development Baseline data should have following attributes: 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
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
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.
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
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
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 didnt fully understand, and they will change. Government is trying for a more enlightened approach.
Scope Information
Some typical questions Overall Goals Whos 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
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
Scoping Example
Conveyor Line Motion ID No. ID No. ID No. ID No. Bin 1 Bin 2 Bin 3 Bin 4
Control connection
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
Resources
March 2004
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
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
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
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
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))
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
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
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
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
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
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
Function Point Based Estimation
Complexity factor = [0.65 0.01 Fi ] = 0.65+0.0152 = 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.
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

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.0545FP Albrecht & Gaffney E = 60.62 + 7.72810-8FP3 Kemerer Model E = 585.7 + 15.12FP Albrecht & Gaffney Must calibrate for local conditions
The COCOMO II Model

Application Composition model --Used during early stages of design Early Design Stage model --When basic s/w archie. has been established Post-Architecture stage model --During construction of s/w 3 sizing options object points, function points & LOC
COCOMO II
Object point is computed using count of 1. Screen 2. Report & 3. Components required to build the application Object Type 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
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
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
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.
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 purchasers specifications. For expensive s/w, some guidelines are to be followed:
March 2004

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

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
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
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
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
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 Websters 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
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
Introduction
Management is the act or art of managing and judicious use of means to accomplish an end(1) RISK MANAGEMENT can be defined as: A logical process for identifying and analyzing leading to appropriate methods for handling and monitoring exposures to loss(3) Risk management deals with: Systematic identification of an exposure to the risk of loss, & Making decisions on the best methods for handling these exposures to minimize losses
Introduction
Risk Strategies
Reactive Software team does nothing about risks until something 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
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
Risk Identification
Risk identification is a systematic attempt to specify threats to the project plan
Identify known and predictable risks
Generic
Product-specific
What characteristics of this product may threaten our project plan?
Risk Item List
Product size Business impact Customer characteristics Process definition Development environment Technology to be built Staff size and experience
Risk Identification
Product Size Risk : Estimated size of the product in LOC or FP? Percentage deviation in size of product from average for previous products? Number of users/projected changes to the requirements for the product? Amount of reused software? Business Impact risks: Effect of this product on the company revenue? Visibility of this product to senior management? Amount & quality of product documentation to be produced? Governmental constraints on the construction of the product?
Risk Identification
Customer related risks: (needs, personalities, contradictions , associations) Have you worked with the customer in the past? Does the customer have a solid idea of what is required? Will the customer agree to have meetings? Is the customer technically sophisticated in the product area? Does the customer understand the software process? Technology Risks: Is the technology to be built new to your organization? Does the SW interface with new or unproven HW/SW? Do requirements demand creation of new components ? Do requirements impose excessive performance constraints ?
Risk Identification
Process Risks : (4) Does senior management support a written policy statement that emphasizes a standard process for software development ? Is there a written description of the software process to be used? 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 ? TechAre 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?
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?
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
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
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
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
15
Risk Matrix
L I k e l I h o o d 5 4 3 2 1 1 2 3 4 Consequences
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.
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.
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.
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
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
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
22
SEI Software Development Risk
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
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 dont actively attack the risks, they will actively attack you. Major projects should all have a risk management plan..
25
NASA Risk Management
November 9, 1997
Chapter 6 -- R. A. Volz -- Assistance -- Julio
NASA
November 9, 1997
NASA - Shuttle-Mir
November 9, 1997
November 9, 1997
November 9, 1997
November 9, 1997
November 9, 1997
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
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
# 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.
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
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
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
Task Set Selector Values
(compute average value)

Example
November 5, 1997
Chapter 7
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
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
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 programs characteristics; as cyclomatic complexity, cohesion, fp, loc etc.
SRIMCA
Quality Concepts
Quality of Design refers to the characteristics that designers 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 FTRs
SRIMCA
Limit the number of participants and insist upon advance preparation Develop a checklist for each work product to be reviewed Training for all reviewers 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

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
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 (Contd)
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 (contd)
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
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 100s or 1000s 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 (contd)

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

The
art of identifying, organizing and controlling modifications to the software being built
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
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
baseline is a milestone in the development of software that marked the delivery of one or more software configuration items
November 16, 1997
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
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
November 16, 1997
SCI (Contd)
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
SCI Modification Process
November 16, 1997
SCM Process
Identification Version control Change control Configuration auditing Status reporting
November 16, 1997
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
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
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
Configuration Objects
November 16, 1997
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
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 100s or 1000s of modules?
November 16, 1997
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.

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

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
Change Control (contd)

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
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
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
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
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
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
System of Systems -- Example
January 31, 1999
The System Engineering Hierarchy
A hierarchy of views are necessary, for example,

World View Domain View Element view Detailed View
January 31, 1999
Typical Hierarchy
January 31, 1999
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

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

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
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
A Diagrammatic View
January 31, 1999
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

January 31, 1999
A Diagrammatic View
January 31, 1999
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
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

January 31, 1999
Typical Organizational Chart
January 31, 1999
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.
January 31, 1999
Typical Relationship Among Objects
January 31, 1999
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
Domain View
January 31, 1999
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

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
Typical Process Flow Model
January 31, 1999
With Information Flow
January 31, 1999
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
January 31, 1999
Product Engineering
TradeTrade-off Criteria

Project Considerations Business Considerations Technical Analysis Manufacturing Evaluation Human Issues Environmental Interfaces Legal Considerations
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

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

Benefit Analysis
January 31, 1999
Cost Analysis
January 31, 1999
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
Architecture Template
January 31, 1999
CLSS Example
January 31, 1999
Expanded Example
January 31, 1999
Building a Hierarchy
January 31, 1999
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
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

Analysis
Concepts and Principle
August 2003
Pressman Chap. 11
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
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
Problem Recognition
Some problems to overcome

Understanding what the customer really wants Getting inside the customers requirements usus-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
Facilitated Application Specification Techniques (FAST)
Refinement with subgroups
August 2003
Pressman Chap. 11
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
V f
1
f2
X f
4
f6 Z z1 f5 z3
z2 f7
W f3 Y X Y
f f
41
x1 y1
f f
43
x2 y2
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
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
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
August 2003 35
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 Earths 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
Relation of Analysis to Design
Sep. 2003
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
Data Design
The Design Model Which is mapped from the Analysis model S.E. - RSP
Sep. 2003
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
The Design Process

Mc Glaughlins 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
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
Sep. 2003
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
Sep. 2003
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

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

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

(cont.)
Transform Flow
outgoing flows B C
incoming flow A transform center
October 2003
SRIMCA
14

(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
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.
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
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 - users model; end

users 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 (dont 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
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
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 systems internal and external timing constraints Scheduling of tasks to guarantee meeting deadlines
Performance Issues
The performance of a real-time system is determined primarily by the system response time and its data transfer rate
System response time is the time within which a system must detect an internal or external event and respond with an action The data transfer rate indicates how fast serial or parallel data, as well as analog or digital data, must be moved into or out of the system
Fundamental question
Does it meet all deadlines or not?
Performance Issues
Key parameters that affect the system response time
Context switching
the time and overhead to switch among tasks
Interrupt latency
the time lag before the switch is actually possible
Speed of computation Speed of access to mass storage

Interrupt handling
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
Nested Interrupt Handling
December 25, 1997
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.
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.
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
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 systems performance Build a prototype, execute it, and thereby get an understanding of a systems behavior
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
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
DFD for Real-Time
December 25, 1997
18
Queuing Model
December 25, 1997
19
Queuing Reduction Rules
December 25, 1997
20
Simplifying Networks
December 25, 1997
21

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
Example
December 25, 1997
23
Statechart for Example
December 25, 1997
24

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

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

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
Real-time design (contd)

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)
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
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
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
Testability
The ease with which a computer program can be tested .
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

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

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

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

Simplicity
the less there is to test , the more quickly we can test it
Functional simplicity Structural simplicity Code simplicity
12

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

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

Flow Graph 1 2 4 6 7a 7b 8
23
3 5

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

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

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 0s, < 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 PCs 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, PCs 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
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
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
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?

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?

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

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

Error
handling tests
Exception-handling
is incorrect? Error description is unintelligible, insufficient or incorrect? Error condition causes system interrupt before error handling completed?
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

INTEGRATION TESTING
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.
Top Down Approach - Use Stubs
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.
Bottom Up Approach
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 developers site by customer. Beta test -- At customers 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 softwares 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.
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.

The Debugging process
Execution of test cases Test cases
Results Suspected causes Debugging

32
Additional tests
Regression tests Corrections

April 2004 SRIMCA
Identified causes

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
COMMENTS
Should
the software developer be involved with testing ?

Developers
have a vested interest in demonstrating that their software is error-free. Developers (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.
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
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
McCalls Software Quality Factors

Maintainability Flexibility Testability Portability Reusability Interoperability
Product Revision
Product Transition
Product Operation
Correctness Reliability Usability Integrity Efficiency
Fq c i mi
HPs FURPS

Functionality - evaluate the feature set and capabilities

of the program
Usability - aesthetics, consistency, documentation Reliability - frequency and severity of failures Performance - processing speed, response time,
resource consumption, throughput, efficiency
Supportability - maintainability testability,

compatibility, ease of installation
Transition to a Quantitative View

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

gymnastics, talent contests etc. side by side comparisons quality judged by an expert in the field
Quantitative metrics dont explicitly measure quality, but some manifestation of quality
January 2004
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.
Measurement Principles

Formulation - derivation of software metrics

appropriate for the software being considered
Collection - accumulating data required to derive the

formulated metrics
Analysis - computation of metrics and application of

mathematical tools
Interpretation - evaluation of metrics in an effort to

gain insight into the quality of the system
Feedback - recommendations derived from the

interpretation of metrics
Attributes of Effective Software Metrics

Simple and computable Empirically and intuitively persuasive Consistent and objective Consistent in units and dimensions Programming language independent Effective mechanism for quality feedback
January 2004
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
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)

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.
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
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
High-Level Design Metrics
Structural Complexity
S(i) = f out(i) fout(i) = fan-out of module i
Data Complexity
D(i) = v(i)/[fout(i) +1] v(i) = # of input and output variables to and from module i
System Complexity
C(i) = S(i) + D(i)

High-Level Design Metrics (Cont.)
Morphology Metrics
size = n + a n = number of modules a = number of arcs (lines of control) arc-to-node ratio, r = a/n depth = longest path from the root to a leaf width = maximum number of nodes at any level
Morphology Metrics
a b 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
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

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

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

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
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
31
Chapter 19 OBJECT ORIENTED MODELING, CONCEPTS AND PRINCIPLES
February 14, 1999
R. A. Volz
Chapter 19 -- Assistance -- Lamimi V. Kamat
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
The OO process model

Moves
through an evolutionary spiral Emphasizes development of reuse capability
February 14, 1999
R. A. Volz
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.
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
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
Object Modeling
February 14, 1999
R. A. Volz
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
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.
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
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

Abstraction and Encapsulation
February 14, 1999
R. A. Volz

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.

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.
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.
Inheritance
Sharing
of attributes and operations among classes based on hierarchical relationship.
February 14, 1999
R. A. Volz
February 14, 1999
R. A. Volz
Class and Subclass

Polygon Vertices Border Color Fill Color Draw Erase Move
Right Triangle
Vertices Hypotenuse length Border Color Fill Color
Draw Erase Move

February 14, 1999
R. A. Volz
February 14, 1999
R. A. Volz
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.
Polymorphism
Polygon Paint Car Paint
Triangle Paint
Square Paint
Communication
Message:
[destination, operation, params]
February 14, 1999
R. A. Volz
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
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.
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
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.
Binary Association & Multiplicity
February 14, 1999
R. A. Volz
Ternary Association
February 14, 1999
R. A. Volz
Link Associations
February 14, 1999
R. A. Volz
Aggregation
A
part-whole or a-part-of relationship
February 14, 1999
R. A. Volz
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
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
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
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
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
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
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.
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
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.
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).

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
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.
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
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.
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.
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.
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.
Generic OOA Model Components
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.
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?
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.

Mode AtHome or Mode Away

System
Identifying Object Classes
Identifying Object Classes
Subjects and Subsystems
OOA model with Subject references
Safe Home Level 1 DFD
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.
CRC model index card:
CRC
model tested by conducting a review driven by use cases.

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
Associations & Operations

Collaborations
suggest operations
Sensor
Determine sensor status
Control Panel
GetState ()
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.
The Object relationship model
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.

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.

Mode AtHome or Mode Away

System
State Transition model
Event Trace
Partial Event Flow Diagram
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.
Object-Oriented Design
Chapter 21 -- Assistance -- Magy Seif El-Nasr
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
Mapping OOA to OOD
Outline
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
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)
OOD Methodologies
The
Booch Method The Coad and Yourdon Method The Jacobson Method The Rumbaugh Method The Wirfs-Brock Method
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.
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.
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.
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
Outline
OOD Process Flow
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
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
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)
Communication Models
18
System Design
Going towards High Cohesion
Cohesion
Coincidental Logical Temporal Communication Sequential Functional Data
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

Concurrency Example
DB access DB access Database
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;
Concurrency
Java
-- Use threads
class dbAccess extends thread{ public void run () { } new dbAccess.start(); new dbAccess.start(); }
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.
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

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
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
Intersubsystem Communication
Create
a table for each contract
28
Subsystem Collaboration Graph

List
each request made by a collaborator
29
Outline
Object Design
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
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 objects name and reference to class Spec. of private data encapsulated Procedural description of each operation Specification of control structures
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
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) ...
Object Design
Steps done in object design
Detail
object attributes and operations object-relationship model operations and transitions using
Review
Describe
PDLs.
Outline
Design Patterns
An
abstraction that conveys meaning about a classs 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
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.
Object-Oriented Testing
Chapter 22
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
Chapter 22
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
Chapter 22

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 collaborators definition Ensure that each collaborator is receiving requests from proper source -- inverted conn.

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

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
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.
Chapter 22
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
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.
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.
Multiple Class Testing
Chapter 22
13
Behavior Testing Models

Ensure
coverage of all states and transitions.
Chapter 22
14
THE PRESENTATION -BY

Software Engineering Notes

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Software Engineering Notes

Hochgeladen von

Copyright:

Verfügbare Formate

Software Engineering

An initial calibration of perspective:

Software Engineering Introduction

Software Engineering Introduction

Some Software Characteristics

Some Software Characteristics

BUT, Hardware upgrades. Software upgrades.

Some Software Characteristics

Some General Approaches

Types of Software Applications

Percent Maintenance Historgram

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

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

SLOCs per Year Histogram

Some Generic Engineering Phases

Some Generic Engineering Phases

Some Generic Engineering Phases

SEI Software Maturity Model

Key Process Areas

Key Process Areas

Key Process Areas

Software Process Models

The Prototyping Model

The RAD Model

Process Modeling Application Generation Testing & Turnover

Application Generation 60 90 days

Testing & Turnover

Evolutionary process Models

Evolutionary Process Models

Evolutionary Process Models

Evolutionary Process Models

Project Entry Point Axis

The Spiral Model Task Regions

Construction & Release

The WinWin Spiral Model

The WinWin Spiral Model

The Concurrent Development Model

The Concurrent Development Model

The Component Assembly Model

The Component Assembly Model

Project Management Concepts

Projects frequently fail or have severe difficulties

Why Do Major Engineering Undertakings Often Fail?

The Spectrum of Management Concerns

Team Leadership -- A Critical Item

Team Organizational Models

Project Features Impacting Organization

Impact of Project Characteristics

Other Underlying Organizational Factors

Project Coordination techniques

A Study on the Impact of Coordination Techniques

Common Process Framework Activities

CHECKOUT & LAUNCH CONTROL SYSTEM

March 19, 1998

SYSTEM ENGINEERING AND INTEGRATION IN CLCS

System Integration and Test

CLCS PROJECT LEVEL REVIEWS

SYSTEM ENGINEERING AND INTEGRATION TERMINOLOGY

Real Time Critical Network

Command Control Processor

Data Distribution Processor

Archive And Retrieval Display and Control Network