Lecture Software process improvement: Lesson 10B - Dr. Ghulam Ahmad Farrukh

Lecture Software process improvement: Lesson 10B provide students with knowledge about: the repeatable level; requirements management; software project planning; software project tracking and oversight; software subcontract management; software quality assurance; software configuration management;... Please refer to the detailed content of the lecture!

Lecture # 10B

1

The Repeatable Level

Moving from  Level 1 to Level 2

Moving from  Level 1 to Level 2

• Organizations have introduced at least some  rigor into project management and technical  development tasks

• Approaches such as formal cost estimating are  noted for project management, and formal 

requirements gathering are often noted during  development

• Compared to initial level, a higher frequency 

of success and a lower incidence of overruns  and cancelled projects can be observed

4

5

Requirements Management

Other  Groups

Software Engineering

Customer  requirements

System  requirements  allocated to  software

System requirements  allocated to software

Software  requirements

• The system requirements assigned to software Engineering  must be documented

• Documenting system requirements can be as simple as a  memo or as elaborate as a multi volume specification

• If requirements change, the changes must be documented  and all resulting necessary changes in other documents 

must be tracked and verified

• The software engineering group  ensures that the 

system requirements allocated to software are  documented and controlled. For  which, the software  engineering group reviews the initial and revised 

system requirements allocated to  software to resolve  issues 

Software Project Planning

• The purpose is to establish reasonable plans for 

performing the software engineering and managing the  project

• Involves:

– developing estimates for the work – establishing necessary commitments – defining the plan to perform the work

• Plan provides the basics for initiating the software effort  and managing the work.

What is a Software  Development Plan

• A software development plan specifies many or all of the  following:

• Commitment ­ a pact that is freely assumed, visible, and  expected  to be kept by all parties.

• Commitment is necessary to achieve plans.

• Feasible commitments are made when plans are realistic.

• Commitment is a process.

Software Project Tracking and Oversight

 To provide adequate visibility into actual progress so that  management can take effective actions when the software  projects performance deviates significantly from the software  plans

 Involves:

 tracking and reviewing software accomplishments and results  against documented estimates, commitments and plans

 adjusting plans based on actual accomplishments and results

 Progress must be tracked against plans and specifications,  including

 If and when discrepancies between plans and actual progress  occur, a judgement must be made about whether to:

Management

• To select qualified software subcontractors and manage  them effectively. 

• Involves

– selecting a software subcontractor – establishing commitments with the subcontractor – tracking and reviewing the subcontractor performance and  results 

Purpose

• The prime contractor is the organization responsible for  building a system

• The prime contractor may contract out part of the work to  another contractor, the subcontractor

• Performance of the prime contractor may critically depend 

on performance of the subcontractor

• In selecting and managing subcontractor, prime contractors must  perform activities additional to the ordinary project management  effort.

Software Quality Assurance

• Purpose is to provide management with appropriate 

visibility in to the process being used by software project  and products being built. 

• Involves 

– reviewing and auditing products and activities to ensure that  they comply with applicable procedures and standards

– providing the software project and other appropriate managers  with the results of those reviews and audits

Purpose

• Commitment 1.2 (the SQA group has an “independent reporting  channel” to the senior management) indicates that an independent  SQA group is normally expected.

• Goal 2 of SQA (verify adherence objectively) provides latitude in  defining SQA.

• Without an independent SQA group, can the organization 

demonstrate objective means of adherence?

Independent Versus Objective

• There are three possible ways for resolving a 

noncompliance issue:

– Make the product or process satisfy the standard, procedure or  requirement

– Change the standard or procedure to make it useable

– Make an executive decision not to satisfy the standard, 

procedure or requirement  

• Proactive SQA functions as a value adding member of  the project team

– SQA starts early in the project – SQA helps to prepare and review procedures, plans and  standards

• At higher levels, the CMM provides flexibility for SQA 

to function proactively to drive improvements in the  software process and product.

Software Configuration  Management

• Purpose is to establish and maintain the integrity of the  products of the software projects throughout the project’s  software life cycle

• SCM relies on baselining software work products.

• A baseline is a specification or product that

– has been formally reviewed and agreed on – serves as the basis for further work

– can be changed only through formal change control  procedures

Using Baselines

• SCM provides a stable working environment.

• Uncontrolled change of work product is a chaotic process.

• SCM provides a memory of the status of software work  products via baselines.

• When many individuals are working on the same product,  SCM coordinates access to and change of the software 

work products.

Controlling Change

• Software Product  ­ the complete set, or any of the individual  items of the set, of computer programs, procedures, associated 

documentation, and data designated for delivery to a customer or end  user.

• Software Work Product  ­ any artifact created as part of 

defining, maintaining, or using a software process, including process  descriptions, plans, procedures, computer programs, and associated  documents, which may or may not be intended for delivery top a  customer or end user.

Software Product and  Software Work Product

• The SCM KPA can be satisfied using at a minimum 

baseline configuration management

• Some software work products do not need the formality of 

configuration management but do need to be placed under some  form of

• The Capability Maturity Model: Guidelines  for Improving Software Process 

44