1. Trang chủ
  2. » Công Nghệ Thông Tin

Process Improvement

16 421 1
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Process Improvement
Tác giả Ian Sommerville
Trường học University of Glasgow
Chuyên ngành Software Engineering
Thể loại Thesis
Năm xuất bản 2004
Thành phố Glasgow
Định dạng
Số trang 16
Dung lượng 99,92 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Process Improvement

Trang 1

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 1

Process Improvement

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 2

improvement

influence software quality and productivity

software processes

and the CMMI process improvement model

Objectives

Topics covered

Trang 2

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 4

introducing process changes to improve product quality, reduce costs or accelerate schedules

focused on defect reduction This reflects the increasing attention paid by industry to quality

be the focus of improvement

Process improvement

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 5

Process attributes

Process

characteristic

Description

Understandability To what extent is the process explicitly defined and how easy is it t o

understand the process definition?

Visibility Do the process activities culminate in clear results so that the progress

of the process is externally visible?

Supportability To what extent can CASE tools be used to support the process

activities?

Acceptability Is t he defined process acceptable to and usable by the engineers

responsi ble for producing the software product?

Reliability Is the process designed in such a way that process errors are avoided or

trapped before they result in product errors?

Robustness Can the process continue in spite of unexpected problems?

Maintainability Can the process evolve to reflect changing organisational requirements

or identified process improvements?

Rapidity How fast can the process of delivering a sys tem from a given

specification be completed?

The process improvement cycle

Analyse Measure

Change

Trang 3

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 7

measured These are a baseline for

assessing improvements

bottlenecks and weaknesses are identified

identified during the analysis are introduced

Process improvement stages

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 8

related and process improvement benefits arise because the quality of the product depends on its development process

good product

principal quality determinant

involved especially the capabilities of the designers

Process and product quality

Principal product quality factors

Product quality

De velopment technolo gy

Cost, time and schedule

Process

quality

People quality

Trang 4

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 10

Quality factors

the development process determines product quality

developers is the main determinant

significant for small projects

imposed then product quality will suffer

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 11

their own way of working.

process.

as the RUP.

Process classification

Process applicability

Prototypes Shor t-lifetime systems 4GL b usiness systems Small/medium-sized systems

Infor mal

process

Large systems Long-lifetime pr oducts Mana ged

process

Well-understood applica tion domains Re-eng ineer edsystems Methodical

process

Trang 5

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 13

product which is being developed

problem so you need a strictly managed process;

should be standardised within an organisation

process on a development team;

to reduced quality.

Process choice

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 14

Process tool support

Informal

process

Mana ged

process

Methodical process

Impr o ving process

Specialis ed tools Analysis and design wor kbenches

Pr oject mana gement tools Configur ation

mana gement

tools

Generic

tools

should be collected

process standards this is very difficult as you don’t know what to measure A process may have to be defined before any measurement is possible.

assess process improvements

the improvements The improvement driver should be the organizational objectives.

Process measurement

Trang 6

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 16

completed

activity or process

activities

Classes of process measurement

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 17

objective of process improvement is to satisfy these goals

the goals You need process knowledge to derive these

questions

Goal-Question-Metric Paradigm

Process analysis and modelling

the relationships between parts of the process and to compare them with other processes

the tasks, the roles and the entities used;

different perspectives

Trang 7

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 19

activities

You should normally represent this

graphically Several different views (e.g activities, deliverables, etc.) may be required

problems This involves discussing process activities with stakeholders and discovering problems and possible process changes

Process analysis and modelling

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 20

standards

model People then may extend and change this.

they think you want to hear.

Best for in-depth analysis of process fragments rather than for whole-process understanding.

Process analysis techniques

Process model elements 1

Activity

(shown as a round-edged

rectangle with no drop

shadow)

An activity has a clearly defined objective, entry and exit conditions Examples of activities are preparing a set of test data to test a module, coding a fu nction or a module, proof-reading a responsibility of one person or group It is not decomposed into sub-activities.

Process

(shown as a round-edged

rectangle with drop

shadow)

A p rocess is a set of activities which have some coherence and whose objective is generally agreed within an organisation Examples of processes are requirements analysis, architectural design, test planning, etc.

Deliverable

(shown as a rectangle with

drop shadow)

A deliverable is a tangible output of an activity that is predicted in a project plan.

Condition

(shown as a parallelogram )

A condition is either a p re-condition that must hold before a process

or activity can start or a post-condition that holds after a p rocess or activity has finished.

Trang 8

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 22

Process model elements 2

Role

(shown as a circle with

drop shadow)

A role is a b ounded area of responsibility Examples of roles might person may have several different roles and a s ingle role may be associated with several different people.

Exception

(not shown in examples

here but may be

represented as a double

edged box)

An exception is a description of how to modify the process if some undefined and it i s left to the ingenuity of the project managers and enginee rs to handle the exception.

Communication

(shown as an arrow)

An interchange of information between people or between people and supporting computer systems Commu nications may be informal or formal Formal communications might be the approval

of a deliverable by a p roject manager; informal communications

a document.

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 23

The module testing activity

Test module

Signed-of f test recor d

Module test data Module

specifica tion

Module compiles

without syntax

errors

All defined tests run on module Test

eng ineer Pre-condition

Input

Process

Role

Post-condition

Outputs Responsib le

for

Activities in module testing

Prepar e test da ta

accor ding to

Read module

specifica tion

Submit test da ta for review Review test da ta TEST DATA P REPARATION

Read and understand

module inter face

Checkout module

from configur ation

mana gement system

Prepar etestharness for module

Compile test harness MODULE TEST HARNESS PR EPARATION

Incorpor ate module

with test harness

Run a ppro ved tests

on module

Recor d test r esults forr eg ressiontests TEST EXECUTION

Write repor t on module

testing including details

of disco vered pr ob lems

Submit r epor t for appr o val

Submit test results to CM TEST REPORTING

Trang 9

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 25

Process exceptions

models cannot effectively represent how to handle exceptions:

review;

communications are out of action for several days;

proposals.

and managers use their initiative to deal with the exception

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 26

Process change

processes

processes;

goals

The process change process

Process

model

Pr ocess change

plan

Training plan Feedback on impr o vements

Revised pr ocess model

Identify

improvements

Prioritise impr ovements

Tune process changes

Introduce process change

Train eng ineers

Trang 10

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 28

Process change stages

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 29

The CMMI framework

process assessment and improvement that started

at the Software Engineering Institute in the 1980s

transfer particularly to US defence contractors

improvement

Process capability assessment

which an organisation’s processes follow best practice

possible to identify areas of weakness for process improvement

assessment and improvement models but the SEI work has been most influential

Trang 11

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 31

and used

The SEI capability maturity model

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 32

Problems with the CMM

at the same time but if all practices from a lower level were not used, it was not possible to move beyond that level

bottom of levels

rather than the goals to be achieved.

The CMMI model

software and systems engineering capability assessment

of capability levels;

computed

Trang 12

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 34

CMMI model components

and improvement are identified These are organised into

4 groups.

Each process area has associated goals.

are advisory and other approaches to achieve the goal may be used.

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 35

CMMI process areas 1

Process management Organisational process definition

Organisational process focus Organisational training Organisational process performance Organisational innovation and deployment Project management Project planning

Project monitoring and control Supplier agreement management Integrated project management Risk management Integrated teaming Quantitative project management

CMMI process areas 2

Engineering Requirements management

Requirements development

Technical solution

Product integration

Verification

Validation

Support Configuration management

Process and product quality management

Measurement and analysis

Decision analys is and resolution

Organisational environment for integration

Causal analysis and resolution

Trang 13

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 37

CMMI goals

Corrective actions are managed to

closure when the projectÕs performance

plan.

Specific goal in Project Monitoring and Control

Actual performance and progress of the

project is monitored against the project

plan.

Specific goal in project monitoring and control

The requirements are analysed and

validated and a definition of the required

functionality is deve loped

Specific goal in requirements deve lopment.

Root causes of de fects and other

problems are systematically determined.

Specific goal in causal analysis and resolution.

The process is institutionalised as a

defined p rocess.

Gene ric goal

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 38

CMMI practices

Analyse derived requirements to ensure that they are

necessary and sufficient

Validate requirements to ensure that the resulting

product will perform as intended in the userÕs

environment using multiple techniques as

appropriate.

The requirements are analysed and validated and a definition of the required functionality is developed.

Select the defects and other problems for analysis.

Perform causal analysis of selected defects and other

problems and propose actions to address them.

Root causes of defects and other problems are systematically determined.

Establish and maintain an organisational policy for

planning and performing the requirements

development process.

Assign responsibility and authority for performing

the process, developing the work products and

providing the services of the requirements

development process.

The process is institutionalised as a defined process.

CMMI assessment

and assesses their maturity in each process area

Trang 14

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 40

The staged CMMI model

goals For example, the process area associated with the managed level include:

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 41

The staged CMMI model

Level 3 Defined

Level 2

Managed

Level 1

Initial

Level 4 Quantitatively managed

Level 5 Optimizing

Institutional practices

should have institutionalised practices that are geared to standardisation

project management process;

project management process;

process;

project planning process

Trang 15

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 43

The continuous CMMI model

or groups of practices and assesses their use

a set of values showing the organisations maturity in each area

5

organisations can pick and choose process areas to improve according to their local needs

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 44

A process capability profile

Project monitoring

and control

Supplier ag reement

management

Risk

management

Configuration

management

Requirements

management

Verification

Validation

standardisation, measurement and change

methodical and improving This classification can be used to identify process tool support

measurement, process analysis and process

change

specific process questions, based on organisational improvement goals

Key points

Trang 16

©Ian Sommerville 2004 Software Engineering, 7th edition Chapter 28 Slide 46

measurement process are time metrics, resource utilisation metrics and event metrics

activities, roles, exceptions, communications,

deliverables and other processes

and systems engineering process improvement

reaching a set of goals related to good software engineering practice

Key points

Ngày đăng: 14/09/2012, 11:41

TỪ KHÓA LIÊN QUAN

w