1

Management of Software Projects

Management of software development Cost (and its estimation): Scope: Time: Risk: Quality:

2

Project Management Process

A process is a series of actions directed toward a particular result.

Project management can be viewed as a number of interlinked processes.

The project management process groups include: Initiating processes Planning processes Executing processes Monitoring and controlling processes Closing processes

3

Level of Activity and Overlap of Process Groups Over Time

4

What is Cost and Project Cost Management? Cost is a resource sacrificed or foregone to

achieve a specific objective, or something given up in exchange.

Costs are usually measured in monetary units, such as dollars.

Project cost management includes the processes required to ensure that the project is completed within an approved budget.

5

Project Cost Management Processes

Cost estimating: Developing an approximation or estimate of the costs of the resources needed to complete a project.

Cost budgeting: Allocating the overall cost estimate to individual work items to establish a baseline for measuring performance.

Cost control: Controlling changes to the project budget.

6

Basic Principles of Cost Management

Tangible costs or benefits are those costs or benefits that an organization can easily measure in dollars.

Intangible costs or benefits are costs or benefits that are difficult to measure in monetary terms.

Direct costs are costs that can be directly related to producing the products and services of the project.

Indirect costs are costs that are not directly related to the products or services of the project, but are indirectly related to performing the project.

Sunk cost is money that has been spent in the past; when deciding what projects to invest in or continue, you should not include sunk costs.

7

Typical Problems with IT Cost Estimates

Developing an estimate for a large software project is a complex task that requires a significant amount of effort.

People who develop estimates often do not have much experience.

Human beings are biased toward underestimation.

Management might ask for an estimate, but really desire a bid to win a major contract or get internal funding.

8

Cost Control Project cost control includes:

Monitoring cost performance.

Ensuring that only appropriate project changes are included in a revised cost baseline.

Informing project stakeholders of authorized changes to the project that will affect costs.

Many organizations around the globe have problems with cost control.

9

Earned Value Management (EVM)

EVM is a project performance measurement technique that integrates scope, time, and cost data.

Given a baseline (original plan plus approved changes), you can determine how well the project is meeting its goals.

You must enter actual information periodically to use EVM.

More and more organizations around the world are using EVM to help control project costs.

10

Earned Value Management Terms

The planned value (PV), formerly called the budgeted cost of work scheduled (BCWS), also called the budget, is that portion of the approved total cost estimate planned to be spent on an activity during a given period.

Actual cost (AC), formerly called actual cost of work performed (ACWP), is the total of direct and indirect costs incurred in accomplishing work on an activity during a given period.

The earned value (EV), formerly called the budgeted cost of work performed (BCWP), is an estimate of the value of the physical work actually completed.

EV is based on the original planned costs for the project or activity and the rate at which the team is completing work on the project or activity to date.

11

Rate of Performance

Rate of performance (RP) is the ratio of actual work completed to the percentage of work planned to have been completed at any given time during the life of the project or activity.

12

Earned Value Formulas

13

Predicting the resources required for a software development process

Size related measures based on some output from the software process. This may be lines of delivered source code, object code instructions, etc.

Function-related measures based on an estimate of the functionality of the delivered software. Function-points are the best known of this type of measure

Productivity measures

14

Function points Based on a combination of program

characteristics external inputs and outputs user interactions external interfaces files used by the system

A weight is associated with each of these The function point count is computed by

multiplying each raw count by the weight and summing all values

15

Function points Function point count modified by complexity of

the project FPs can be used to estimate LOC depending on

the average number of LOC per FP for a given language LOC = AVC * number of function points AVC is a language-dependent factor varying from

200-300 for assembly language to 2-40 for a 4GL FPs are very subjective. They depend on the

estimator. Automatic function-point counting is impossible

16

Object points Object points are an alternative function-related

measure to function points when 4Gls or similar languages are used for development

Object points are NOT the same as object classes The number of object points in a program is a

weighted estimate of The number of separate screens that are displayed The number of reports that are produced by the

system The number of 3GL modules that must be developed

to supplement the 4GL code

17

Object point estimation Object points are easier to estimate from

a specification than function points as they are simply concerned with screens, reports and 3GL modules

They can therefore be estimated at an early point in the development process. At this stage, it is very difficult to estimate the number of lines of code in a system

18

Real-time embedded systems, 40-160 LOC/P-month

Systems programs , 150-400 LOC/P-month

Commercial applications, 200-800 LOC/P-month

In object points, productivity has been measured between 4 and 50 object points/month depending on tool support and developer capability

Productivity estimates

19

Factors affecting productivity

Factor DescriptionApplication domainexperience

Knowledge of the application domain is essential foreffective software development. Engineers who alreadyunderstand a domain are likely to be the mostproductive.

Process quality The development process used can have a significanteffect on productivity. This is covered in Chapter 31.

Project size The larger a project, the more time required for teamcommunications. Less time is available fordevelopment so individual productivity is reduced.

Technology support Good support technology such as CASE tools,supportive configuration management systems, etc.can improve productivity.

Working environment As discussed in Chapter 28, a quiet workingenvironment with private work areas contributes toimproved productivity.

20

All metrics based on volume/unit time are flawed because they do not take quality into account

Productivity may generally be increased at the cost of quality

It is not clear how productivity/quality metrics are related

If change is constant then an approach based on counting lines of code is not meaningful

Quality and productivity

21

Estimation techniques There is no simple way to make an

accurate estimate of the effort required to develop a software system Initial estimates are based on inadequate

information in a user requirements definition The software may run on unfamiliar computers

or use new technology The people in the project may be unknown

Project cost estimates may be self-fulfilling The estimate defines the budget and the

product is adjusted to meet the budget

22

Cost Estimation Tools and Techniques

Basic tools and techniques for cost estimates: Analogous or top-down estimates: Use the actual cost of

a previous, similar project as the basis for estimating the cost of the current project.

Bottom-up estimates: Involve estimating individual work items or activities and summing them to get a project total.

Parametric modeling: Uses project characteristics (parameters) in a mathematical model to estimate project costs.

Computerized tools: Tools, such as spreadsheets and project management software, that can make working with different cost estimates and cost estimation tools easier.

23

Top-down and bottom-up estimation

Any of these approaches may be used top-down or bottom-up

Top-down Start at the system level and assess the overall

system functionality and how this is delivered through sub-systems

Bottom-up Start at the component level and estimate the

effort required for each component. Add these efforts to reach a final estimate

24

Top-down estimation Usable without knowledge of the system

architecture and the components that might be part of the system

Takes into account costs such as integration, configuration management and documentation

Can underestimate the cost of solving difficult low-level technical problems

25

Bottom-up estimation Usable when the architecture of

the system is known and components identified

Accurate method if the system has been designed in detail

May underestimate costs of system level activities such as integration and documentation

26

Experience-based estimates

Estimating is primarily experience-based However, new methods and technologies may

make estimating based on experience inaccurate Object oriented rather than function-oriented

development Client-server systems rather than mainframe systems Off the shelf components Component-based software engineering CASE tools and program generators

27

Managing Scope:Preliminary Scope Statements

A scope statement is a document used to develop and confirm a common understanding of the project scope.

It is an important tool for preventing scope creep:

The tendency for project scope to keep getting bigger.

A good practice is to develop a preliminary or initial scope statement during project initiation and a more detailed scope statement as the project progresses.

28

Contents of a Preliminary Scope Statement

Project objectives Product or service

requirements and characteristics

Project boundaries Deliverables Product acceptance

criteria Project assumptions

and constraints Organizational structure

for the project

Initial list of defined risks

Summary of schedule milestones

Rough order of magnitude cost estimate

Configuration management requirements

Description of approval requirements

29

Monitoring and Controlling Project Work

Changes are inevitable on most projects, so it’s important to develop and follow a process to monitor and control changes.

Monitoring project work includes collecting, measuring, and disseminating performance information.

Two important outputs of monitoring and controlling project work include recommended corrective and preventive actions.

30

Integrated Change Control Three main objectives are:

Influence the factors that create changes to ensure that changes are beneficial.

Determine that a change has occurred.

Manage actual changes as they occur.

A baseline is the approved project management plan plus approved changes.

31

Change Control on Information Technology Projects

Former view: The project team should strive to do exactly what was planned on time and within budget.

Problem: Stakeholders rarely agreed beforehand on the project scope, and time and cost estimates were inaccurate.

Modern view: Project management is a process of constant communication and negotiation.

Solution: Changes are often beneficial, and the project team should plan for them.

32

Change Control System A formal, documented process that

describes when and how official project documents and work may be changed.

Describes who is authorized to make changes and how to make them.

33

Change Control Boards (CCBs) A formal group of people responsible for

approving or rejecting changes on a project.

CCBs provide guidelines for preparing change requests, evaluate change requests, and manage the implementation of approved changes.

CCBs include stakeholders from the entire organization.

34

Managing time:Conflict Intensity Over the Life of a Project

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

ProjectFormation

Early Phases Middle Phases End Phases

Co

nfl

ict

Inte

ns

ity

Schedules

Priorities

Manpower

Technical opinions

Procedures

Cost

Personality conflicts

AverageTotal Conflict

35

Project Time Management Processes

Activity definition: Identifying the specific activities that the project team members and stakeholders must perform to produce the project deliverables.

Activity sequencing: Identifying and documenting the relationships between project activities.

Activity resource estimating: Estimating how many resources a project team should use to perform project activities.

Activity duration estimating: Estimating the number of work periods that are needed to complete individual activities.

Schedule development: Analyzing activity sequences, activity resource estimates, and activity duration estimates to create the project schedule.

Schedule control: Controlling and managing changes to the project schedule.

36

Activity Definition An activity or task is an element of work normally found on

the WBS that has an expected duration, a cost, and resource requirements.

Project schedules grow out of the basic documents that initiate a project.

The project charter includes start and end dates and budget information.

The scope statement and WBS help define what will be done.

Activity definition involves developing a more detailed WBS and supporting explanations to understand all the work to be done, so you can develop realistic cost and duration estimates.

37

Activity Lists and Attributes

An activity list is a tabulation of activities to be included on a project schedule. The list should include: The activity name An activity identifier or number A brief description of the activity

Activity attributes provide more information about each activity, such as predecessors, successors, logical relationships, leads and lags, resource requirements, constraints, imposed dates, and assumptions related to the activity.

38

Milestones A milestone is a significant event that normally

has no duration.

It often takes several activities and a lot of work to complete a milestone.

Milestones are useful tools for setting schedule goals and monitoring progress.

Examples include completion and customer sign-off on key documents and completion of specific products.

39

Activity Sequencing

Involves reviewing activities and determining dependencies.

A dependency or relationship relates to the sequencing of project activities or tasks.

You must determine dependencies in order to use critical path analysis.

40

Three Types of Dependencies

Mandatory dependencies: Inherent in the nature of the work being performed on a project; sometimes referred to as hard logic.

Discretionary dependencies: Defined by the project team; sometimes referred to as soft logic and should be used with care because they may limit later scheduling options.

External dependencies: Involve relationships between project and non-project activities.

41

Network Diagrams

Network diagrams are the preferred technique for showing activity sequencing.

A network diagram is a schematic display of the logical relationships among, or sequencing of, project activities.

Two main formats are the arrow and precedence diagramming methods.

42

Sample Activity-on-Arrow (AOA) Network Diagram for Project X

43

Arrow Diagramming Method (ADM)

Also called activity-on-arrow (AOA) network diagram.

Activities are represented by arrows.

Nodes or circles are the starting and ending points of activities.

Can only show finish-to-start dependencies.

44

Process for Creating AOA Diagrams

1. Find all of the activities that start at node 1. Draw their finish nodes and draw arrows between node 1 and those finish nodes. Put the activity letter or name and duration estimate on the associated arrow.

2. Continuing drawing the network diagram, working from left to right. Look for bursts and merges. A burst occurs when a single node is followed by two or more activities. A merge occurs when two or more nodes precede a single node.

3. Continue drawing the project network diagram until all activities that have dependencies are included in the diagram.

4. As a rule of thumb, all arrowheads should face toward the right, and no arrows should cross in an AOA network diagram.

45

Precedence Diagramming Method (PDM)

Activities are represented by boxes.

Arrows show relationships between activities.

More popular than ADM method and used by project management software.

Better at showing different types of dependencies.

46

Task Dependency Types

47

Activity Resource Estimating

Before estimating activity durations, you must have a good idea of the quantity and type of resources that will be assigned to each activity.

Consider important issues in estimating resources: How difficult will it be to complete specific activities

on this project? What is the organization’s history in doing similar

activities? Are the required resources available?

48

Three-Point Estimates Instead of providing activity estimates as a

discrete number, such as four weeks, it’s often helpful to create a three-point estimate: An estimate that includes an optimistic, most likely,

and pessimistic estimate, such as three weeks for the optimistic, four weeks for the most likely, and five weeks for the pessimistic estimate.

Three-point estimates are needed for PERT estimates and Monte Carlo simulations.

49

Gantt Charts

Gantt charts provide a standard format for displaying project schedule information by listing project activities and their corresponding start and finish dates in a calendar format.

Symbols include: Black diamonds: Milestones Thick black bars: Summary tasks Lighter horizontal bars: Durations of tasks Arrows: Dependencies between tasks

50

Gantt Chart for Project X

Note: In Project 2003 darker bars are red to represent critical tasks.

51

Gantt Chart for Software Launch Project

52

Adding Milestones to Gantt Charts

Many people like to focus on meeting milestones, especially for large projects.

Milestones emphasize important events or accomplishments in projects.

You typically create milestone by entering tasks that have a zero duration, or you can mark any task as a milestone.

53

Sample Tracking Gantt Chart

54

Project Risk Management Processes

Risk management planning: Deciding how to approach and plan the risk management activities for the project.

Risk identification: Determining which risks are likely to affect a project and documenting the characteristics of each.

Qualitative risk analysis: Prioritizing risks based on their probability and impact of occurrence.

55

Project Risk Management Processes (cont’d)

Quantitative risk analysis: Numerically estimating the effects of risks on project objectives.

Risk response planning: Taking steps to enhance opportunities and reduce threats to meeting project objectives.

Risk monitoring and control: Monitoring identified and residual risks, identifying new risks, carrying out risk response plans, and evaluating the effectiveness of risk strategies throughout the life of the project.

56

Risk Management Planning

The main output of risk management planning is a risk management plan—a plan that documents the procedures for managing risk throughout a project.

The project team should review project documents and understand the organization’s and the sponsor’s approaches to risk.

The level of detail will vary with the needs of the project.

57

Topics Addressed in a Risk Management Plan

Methodology

Roles and responsibilities

Budget and schedule

Risk categories

Risk probability and impact

Risk documentation

58

Contingency and Fallback Plans, Contingency Reserves

Contingency plans are predefined actions that the project team will take if an identified risk event occurs.

Fallback plans are developed for risks that have a high impact on meeting project objectives, and are put into effect if attempts to reduce the risk are not effective.

Contingency reserves or allowances are provisions held by the project sponsor or organization to reduce the risk of cost or schedule overruns to an acceptable level.

59

Common Sources of Risk in Information Technology Projects

Several studies show that IT projects share some common sources of risk.

The Standish Group developed an IT success potential scoring sheet based on potential risks.

Other broad categories of risk help identify potential risks.

60

Information Technology Success Potential Scoring Sheet

61

Potential Negative Risk Conditions Associated With Each Knowledge Area

Knowledge Area Risk Conditions

Integration Inadequate planning; poor resource allocation; poor integrationmanagement; lack of post-project review

Scope Poor definition of scope or work packages; incomplete definitionof quality requirements; inadequate scope control

Time Errors in estimating time or resource availability; poor allocationand management of float; early release of competitive products

Cost Estimating errors; inadequate productivity, cost, change, orcontingency control; poor maintenance, security, purchasing, etc.

Quality Poor attitude toward quality; substandarddesign/materials/workmanship; inadequate quality assuranceprogram

Human Resources Poor conflict management; poor project organization anddefinition of responsibilities; absence of leadership

Communications Carelessness in planning or communicating; lack of consultationwith key stakeholders

Risk Ignoring risk; unclear assignment of risk; poor insurancemanagement

Procurement Unenforceable conditions or contract clauses; adversarial relations

62

Risk Register The main output of the risk identification process is a

list of identified risks and other information needed to begin creating a risk register.

A risk register is: A document that contains the results of various risk

management processes and that is often displayed in a table or spreadsheet format.

A tool for documenting potential risk events and related information.

Risk events refer to specific, uncertain events that may occur to the detriment or enhancement of the project.

63

Risk Register Contents An identification number for each risk event. A rank for each risk event. The name of each risk event. A description of each risk event. The category under which each risk event falls. The root cause of each risk. Triggers for each risk; triggers are indicators or symptoms of

actual risk events. Potential responses to each risk. The risk owner or person who will own or take responsibility

for each risk. The probability and impact of each risk occurring. The status of each risk.

64

Probability/Impact Matrix A probability/impact matrix or chart lists the

relative probability of a risk occurring on one side of a matrix or axis on a chart and the relative impact of the risk occurring on the other.

List the risks and then label each one as high, medium, or low in terms of its probability of occurrence and its impact if it did occur.

Can also calculate risk factors: Numbers that represent the overall risk of specific

events based on their probability of occurring and the consequences to the project if they do occur.

65

Sample Probability/Impact Matrix

66

Sample Probability/Impact Matrix for Qualitative Risk Assessment

67

Chart Showing High-, Medium-, and Low-Risk Technologies

68

Top Ten Risk Item Tracking

Top Ten Risk Item Tracking is a qualitative risk analysis tool that helps to identify risks and maintain an awareness of risks throughout the life of a project.

Establish a periodic review of the top ten project risk items.

List the current ranking, previous ranking, number of times the risk appears on the list over a period of time, and a summary of progress made in resolving the risk item.

69

Example of Top Ten Risk Item Tracking

Monthly Ranking

Risk Item This

Month

Last

Month

Numberof Months

Risk ResolutionProgress

Inadequateplanning

1 2 4 Working on revising theentire project plan

Poor definitionof scope

2 3 3 Holding meetings withproject customer andsponsor to clarify scope

Absence ofleadership

3 1 2 Just assigned a newproject manager to leadthe project after old onequit

Poor costestimates

4 4 3 Revising cost estimates

Poor timeestimates

5 5 3 Revising scheduleestimates

70

What Is Quality? The International Organization for

Standardization (ISO) defines quality as “the degree to which a set of inherent characteristics fulfils requirements” (ISO9000:2000).

Other experts define quality based on: Conformance to requirements: The project’s

processes and products meet written specifications.

Fitness for use: A product can be used as it was intended.

71

Software quality management

Concerned with ensuring that the required level of quality is achieved in a software product

Involves defining appropriate quality standards and procedures and ensuring that these are followed

Should aim to develop a ‘quality culture’ where quality is seen as everyone’s responsibility

72

What is quality? Quality, simplistically, means that a product

should meet its specification This is problematical for software systems

Tension between customer quality requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.)

Some quality requirements are difficult to specify in an unambiguous way

Software specifications are usually incomplete and often inconsistent

73

What Is Project Quality Management?

Processes include: Quality planning: Establish organisational

procedures and standards for quality. Identifying which quality standards are relevant to the project and how to satisfy them.

Quality assurance: Periodically evaluating overall project performance to ensure the project will satisfy the relevant quality standards.

Quality control: Monitoring specific project results to ensure that they comply with the relevant quality standards. Ensure that procedures and standards are followed by the software development team.

74

Quality management and software development

Software developmentprocess

Quality managementprocess

D1 D2 D3 D4 D5

Standards andprocedures

Qualityplan

Quality review reports

75

Scope Quality Aspects of IT Projects

Functionality is the degree to which a system performs its intended function.

Features are the system’s special characteristics that appeal to users.

System outputs are the screens and reports the system generates.

Performance addresses how well a product or service performs the customer’s intended use.

Reliability is the ability of a product or service to perform as expected under normal conditions.

Maintainability addresses the ease of performing maintenance on a product.

76

Quality Assurance Quality assurance includes all the activities related to

satisfying the relevant quality standards for a project. Another goal of quality assurance is continuous quality

improvement. Benchmarking generates ideas for quality

improvements by comparing specific project practices or product characteristics to those of other projects or products within or outside the performing organization.

A quality audit is a structured review of specific quality management activities that help identify lessons learned that could improve performance on current or future projects.

77

Table of Contents for a Quality Assurance Plan*

*U.S. Department of Energy

1.0 Draft Quality Assurance Plan1.1 Introduction1.2 Purpose1.3 Policy Statement1.4 Scope2.0 Management2.1 Organizational Structure2.2 Roles and Responsibilities2.2.1 Technical Monitor/Senior Management2.2.2 Task Leader2.2.3 Quality Assurance Team2.2.4 Technical Staff3.0 Required Documentation

4.0 Quality Assurance Procedures4.1 Walkthrough Procedure4.2 Review Process4.2.1 Review Procedures4.3 Audit Process4.3.1 Audit Procedures4.4 Evaluation Process4.5 Process Improvement5.0 Problem Reporting Procedures5.1 Noncompliance Reporting Procedures6.0 Quality Assurance MetricsAppendixQuality Assurance Checklist Forms

78

Pareto Analysis Pareto analysis involves identifying the vital

few contributors that account for the most quality problems in a system.

Also called the 80-20 rule, meaning that 80 percent of problems are often due to 20 percent of the causes.

Pareto diagrams are histograms, or column charts representing a frequency distribution, that help identify and prioritize problem areas.

79

Sample Pareto Diagram

80

Types of Tests Unit testing tests each individual component (often a

program) to ensure it is as defect-free as possible.

Integration testing occurs between unit and system testing to test functionally grouped components.

System testing tests the entire system as one entity.

User acceptance testing is an independent test performed by end users prior to accepting the delivered system.

81

Testing Alone Is Not Enough

Watts S. Humphrey, a renowned expert on software quality, defines a software defect as anything that must be changed before delivery of the program.

Testing does not sufficiently prevent software defects because:

The number of ways to test a complex system is huge.

Users will continue to invent new ways to use a system that its developers never considered.

Humphrey suggests that people rethink the software development process to provide no potential defects when you enter system testing; developers must be responsible for providing error-free code at each stage of testing.

82

The Cost of Quality The cost of quality is the cost of conformance

plus the cost of nonconformance. Conformance means delivering products that meet

requirements and fitness for use. Cost of nonconformance means taking

responsibility for failures or not meeting quality expectations.

A 2002 study reported that software bugs cost the U.S. economy $59.6 billion each year and that one third of the bugs could be eliminated by an improved testing infrastructure.**RTI International, “Software Bugs Cost U.S. Economy $59.6 Billion Annually, RTI Study Finds,” July 1, 2002.

83

Five Cost Categories Related to Quality

Prevention cost: Cost of planning and executing a project so it is error-free or within an acceptable error range.

Appraisal cost: Cost of evaluating processes and their outputs to ensure quality.

Internal failure cost: Cost incurred to correct an identified defect before the customer receives the product.

External failure cost: Cost that relates to all errors not detected and corrected before delivery to the customer.

Measurement and test equipment costs: Capital cost of equipment used to perform prevention and appraisal activities.

84

Maturity Models

Maturity models are frameworks for helping organizations improve their processes and systems.

The Software Quality Function Deployment Model focuses on defining user requirements and planning software projects.

The Software Engineering Institute’s Capability Maturity Model is a five-level model laying out a generic path to process improvement for software development in organizations.

85

CMM Levels and CMMI CMM levels, from lowest to highest, are:

Initial Repeatable Defined Managed Optimizing

The Capability Maturity Model Integration (CMMI) is replacing the older CMM ratings and addresses software engineering, system engineering, and program management.

Companies may not get to bid on government projects unless they have a CMMI Level 3.

86

ISO 9000

International set of standards for quality management

Applicable to a range of organisations from manufacturing to service industries

ISO 9001 applicable to organisations which design, develop and maintain products

ISO 9001 is a generic model of the quality process Must be instantiated for each organisation

87

Documentation standards Particularly important - documents are the

tangible manifestation of the software Documentation process standards

How documents should be developed, validated and maintained

Document standards Concerned with document contents, structure, and

appearance Document interchange standards

How documents are stored and interchanged between different documentation systems

88

Documentation process

Createinitial draft

Reviewdraft

Incorporatereview

comments

Re-draftdocument

Proofreadtext

Producefinal draft

Checkfinal draft

Layouttext

Reviewlayout

Produceprint masters

Printcopies

Stage 1:Creation

Stage 2:Polishing

Stage 3:Production

Approved document

Approved document

89

Document standards Document identification standards

How documents are uniquely identified Document structure standards

Standard structure for project documents Document presentation standards

Define fonts and styles, use of logos, etc. Document update standards

Define how changes from previous versions are reflected in a document

90

Document interchange standards

Documents are produced using different systems and on different computers

Interchange standards allow electronic documents to be exchanged, mailed, etc.

Need for archiving. The lifetime of word processing systems may be much less than the lifetime of the software being documented

XML is an emerging standard for document interchange which will be widely supported in future

91

Software quality attributes

Safety Understandability PortabilitySecurity Testability UsabilityReliability Adaptability ReusabilityResilience Modularity EfficiencyRobustness Complexity Learnability

92

Quality control Checking the software development

process to ensure that procedures and standards are being followed

Two approaches to quality control Quality reviews Automated software assessment and

software measurement

93

Quality reviews The principal method of validating the

quality of a process or of a product Group examined part or all of a process or

system and its documentation to find potential problems

There are different types of review with different objectives Inspections for defect removal (product) Reviews for progress assessment(product and

process) Quality reviews (product and standards)

94

Types of reviewReview type Principal purposeDesign or programinspections

To detect detailed errors in the design orcode and to check whether standards havebeen followed. The review should be drivenby a checklist of possible errors.

Progress reviews To provide information for managementabout the overall progress of the project.This is both a process and a product reviewand is concerned with costs, plans andschedules.

Quality reviews To carry out a technical analysis of productcomponents or documentation to find faultsor mismatches between the specificationand the design, code or documentation. Itmay also be concerned with broader qualityissues such as adherence to standards andother quality attributes.

95

A group of people carefully examine part or all of a software system and its associated documentation.

Code, designs, specifications, test plans, standards, etc. can all be reviewed.

Software or documents may be 'signed off' at a review which signifies that progress to the next development stage has been approved by management.

Quality reviews

96

Software measurement and metrics

Software measurement is concerned with deriving a numeric value for an attribute of a software product or process

This allows for objective comparisons between techniques and processes

Although some companies have introduced measurement programmes, the systematic use of measurement is still uncommon

There are few standards in this area

97

A software property can be measured The relationship exists between what we

can measure and what we want to know This relationship has been formalized and

validated It may be difficult to relate what can be

measured to desirable quality attributes

Metrics assumptions

98

Internal and external attributes

Reliability

Number of procedureparameters

Cyclomatic complexity

Program size in linesof code

Number of errormessages

Length of user manual

Maintainability

Usability

Portability

99

A quality metric should be a predictor of product quality

Classes of product metric Dynamic metrics which are collected by

measurements made of a program in execution Static metrics which are collected by

measurements made of the system representations

Dynamic metrics help assess efficiency and reliability; static metrics help assess complexity, understandability and maintainability

Product metrics

100

Dynamic and static metrics

Dynamic metrics are closely related to software quality attributes It is relatively easy to measure the response

time of a system (performance attribute) or the number of failures (reliability attribute)

Static metrics have an indirect relationship with quality attributes You need to try and derive a relationship

between these metrics and properties such as complexity, understandability and maintainability