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

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

91 5 0

Đ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 đề Lecture Software process improvement: Lesson 17 - Dr. Ghulam Ahmad Farrukh
Chuyên ngành Software Process Improvement
Thể loại lecture
Định dạng
Số trang 91
Dung lượng 285,73 KB

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

Nội dung

Lecture Software process improvement: Lesson 17 provide students with knowledge about: CMMI staged maturity level 3; process areas for maturity level 3; select work products for verification; establish the verification environment; establish verification procedures and criteria;... Please refer to the detailed content of the lecture!

Trang 3

Verification

PA 4

3

Trang 8

Verification

• The Verification PA allows the usage of test setups and test simulators. Sometimes, the same test setups and simulators may be 

Trang 9

or the other, if possible

9

Trang 10

Things People Forget ­ 2

• What is a peer? If you are peer reviewing code, a  peer is a coder. If you are peer reviewing a project  plan, a peer is another project manager. Do not 

mix people of different job status—for example, 

do not mix project managers in with coders. They  are not peers

• A peer review board is not one person

• Peer reviews are not the place to philosophic 

discussions. Keep it short and sweet and focus on 

Trang 11

Things People Forget ­ 3

• You must ensure that the errors found 

during a peer review are resolved. Another peer review may be necessary. Quality 

Assurance should also check to see that 

these problems have been resolved

11

Trang 12

Generic Practices

• There are no generic practices that directly map to this process area

12

Trang 13

Verification

• Verification includes selecting which work products are to be verified; creating the 

environment necessary for verification of those products; documenting procedures 

and criteria for verification and then 

following those procedures; conducting 

peer reviews; and verifying the product and taking any corrective actions needed

13

Trang 14

Validation

PA 5

14

Trang 16

16

Trang 17

SG2 Validate Product or Product  Components – Specific Practices

• SP 2.1 Perform Validation

• SP 2.2 Analyze Validation Results

17

Trang 18

18

Trang 19

Things People Forget ­ 1

• You don’t need to test everything. You do need to test almost everything. You cannot test in quality

• Validation is not performed at the end of 

the project. It can be performed throughout the development life cycle, depending on the product being produced

19

Trang 20

Things People Forget ­ 2

• Make sure you plan in detail any tests to be performed by the users or in the user 

environment

• If you are simulating the user environment, make sure it truly replicates the actual 

environment. This will require planning and testing of the environment itself

20

Trang 21

Things People Forget ­ 3

• If you are developing a Web­based system using the Web that your users will use, then you may have satisfied Validation without knowing about it. Basically, if you are 

developing and testing the system using the same resources and procedures that the 

users will use (or are using), you may have this PA covered

21

Trang 22

General Practices

• There are no general practices that directly map to this process are

22

Trang 23

Validation

• Validation asks: are you building the right product? It includes selecting products and approaches for validating products, 

Trang 24

Organizational Process Focus

PA 6

24

Trang 25

25

Trang 26

SG1 Determine Process  Improvement Opportunities – 

26

Trang 28

28

Trang 29

• The EPG is the group responsible for 

planning process improvement and 

implementing the plans

29

Trang 31

Things People Forget ­ 1

• This PA probably has the most “churn” in the beginning of any process improvement effort. That is because the people who staff 

it (the EPG) are as unfamiliar with process improvement as everyone else in the 

organization. If you decide to staff this 

group with personnel who have supposedly already “done” process improvement 

somewhere else, make sure they are flexible31

Trang 32

Things People Forget ­ 2

• Don’t try to change everything at once. Do a  little at a time

• After one or two years on the EPG, rotate 

some of the members out! You need new 

blood, new ways of thinking, new ways of 

meeting new challenges. Plus, the members of  the EPG are more likely to create and 

implement usable processes if they must return 

to their previous jobs and follow those 

Trang 33

33

Trang 34

Organizational Process Focus

• Organizational Process Focus includes  establishing a  fundamental understanding of what process is and 

why it is important to an organization ;  assessing 

current processes in the organization and identifying  areas in need of improvement ;   creating and following  action plans for improvement ;  determining how to 

institute process improvement in the organization and  what plans and documentation will be needed ; and 

reviewing the process improvement effort itself and  instituting improvements in this area

34

Trang 36

Organizational Process Definition

• The purpose of Organizational Process 

Definition (OPD) is to establish and maintain a  usable set of organizational process assets and  work environment standards.

• For IPPD: Organizational Process Definition +  IPPD also covers the establishment of 

organizational rules and guidelines that enable  conducting work using integrated teams

36

Trang 39

• We’ll discuss software only; IPPD is 

applicable to DOD projects specifically

39

Trang 40

Things People Forget ­ 1

• How to document processes that can be 

used. Individuals create processes that are either too complex to properly implement 

or too high­level to properly implement. 

You will need to rewrite, re­plan, and re­

pilot your processes and procedures

40

Trang 41

Things People Forget ­ 2

• There are differences between the types of documentation you will need to produce

• IPPD is optional

41

Trang 43

Organizational Process Definition

• Organizational Process Definition includes generating the Organization’s Set of 

Standard Processes (OSSP); describing 

various life cycles approved for use; 

documenting tailoring criteria and 

guidelines; and creating and maintaining the measurement repository and process asset library

43

Trang 44

Organizational Training

PA 8

44

Trang 46

SG1 Establish an Organizational  Training Capability – Specific 

• SP 1.4 Establish Training Capability

46

Trang 48

Process Area

• This PA expects a Strategic Training Plan coming from the OSSP, as well as business plans, process improvement plans, defined skill sets of existing groups, missing skill sets of existing groups, skill sets needed for any nonexistent groups necessary to be 

formed, mission statements, and vision 

statements

48

Trang 49

• And all of these things are tied into training plans. That’s a lot of documentation that 

Trang 50

• Organizational­level training plans bubble 

up from project­level training plans and 

needs. Organizations also need to evaluate the effectiveness of the training received

• This process area is not about knowledge management. While you may define core competencies and certifications necessary, the concepts are not that similar. For that 

consult People CMM 50

Trang 51

schedules and budget for that training in the 

Trang 52

52

Trang 53

53

Trang 54

• GP 2.2 Plan the Process matches this 

process area from a project perspective

54

Trang 55

Organizational Training

• Organizational Training includes 

determining the strategic training needs of the organization and how to achieve them; procuring or delivering the training; and 

tracking its effectiveness

55

Trang 57

Integrated Project Management

• The purpose of Integrated Project Management  (IPM) is to establish and manage the project 

57

Trang 59

SG1 Use the Project’s Defined  Process – Specific Practices

• SP 1.6 Contribute to the Organizational Process  Assets

59

Trang 60

SG2 Coordinate and Collaborate  with Relevant Stakeholders – 

Trang 61

• We’ll not talk about IPPD related specific practices

61

Trang 62

Process Area

• This PA is supposed to be the evolution of Project Planning, and Project Monitoring 

and Control from Level 2, plus more 

sophistication for Level 3. That means that this PA involves more rigorous techniques for planning and monitoring projects within the organization

62

Trang 63

Process Area

• In this PA, each project reviews the OSSP and tailors the OSSP to fit a project’s 

specific needs. The result is called the 

project’s defined process, and yes, it must 

be documented. This process is then used to help build the project plan

63

Trang 65

• The difference between management at 

Level 2 and at Level 3 is that Level 3 uses a set of organizational plans, processes, and assets (templates, checklists) based on best practices and lessons learned

65

Trang 66

Things People Forget

• The Project’s Defined Process (PDP). This 

process is actually one or more documents that  describe how the project functions in a step­

by­step manner (usually either by process area 

or by life­cycle phase). It uses the OSSP as 

input and tailors the OSSP to fit the project. In  some cases, especially when the organization 

is small and non­diverse, the OSSP can be 

used as the PDP, as appropriate

66

Trang 68

Integrated Project Management

• Integrated Project Management includes defining a process 

or processes at the project­level when necessary that are  tailored from the organizational process(es);  using the 

processes and documentation developed from the 

organization ; integrating all plans (including plans for each  process area as well as project management plans) with the  project’s defined process;  managing the project according 

to the plan ;  incorporating measurements, documentation,  and improvements into the project or organizational­level  repositories and processes ; ensuring stakeholder 

involvement;  tracking critical dependencies ; and resolving 

Trang 69

Risk Management

PA 10

69

Trang 70

Risk Management

• The purpose of Risk Management (RSKM) 

is to identify potential problems before they occur so that risk­handling activities can be planned and invoked as needed across the life of the product or project to mitigate 

adverse impacts on achieving objectives

70

Trang 72

SG1 Prepare for Risk  Management – Specific Practices

Trang 73

73

Trang 75

Process Area

• The Risk Management process area is much more proactive, involving identification of risk parameters, formal strategies for 

handling risks, preparing risk mitigation 

plans, and structured risk assessments

75

Trang 76

• Periodic and event­driven reviews should occur on the project to summarize the most critical risks that may occur. Make sure you review risks during periodic reviews

• Why? Discussing risks as a events exposes projects – discuss this clearly

• Plus, risk probability changes over time and over the course of the project

76

Trang 78

Things People Forget

• This PA is the big time of risk management. This PA is not just about listing risks and 

reviewing them at project meetings. It is 

about studying the risks and measuring their impact and probability on project activities

• The main focus of this PA is on project 

risks. However, the same concepts can be applied to organizational risks

78

Trang 79

• There are no generic practices that directly map to this process area

79

Trang 80

Risk Management

• Risk Management includes identifying and categorizing risks; generating a risk 

Trang 82

• Specific goal for this process area is

– SG1 Evaluate Alternatives

82

Trang 84

• Difficulty of using this PA

84

Trang 85

Things People Forget ­ 1

• You must define when this PA should be 

used. Otherwise, some projects will use it for every decision, and some projects will not use it at all

85

Trang 86

Things People Forget ­ 2

• You must create and document “ established criteria ” 

These criteria are used to judge proposed alternatives   Your criteria may already have been established as 

part of a technical or contractual requirement. 

However, the criteria for allowing or disallowing an  alternative may change, depending on changes to the  project involved with budget, personnel, schedule, 

safety, and other unanticipated factors.  Document all  changes to the criteria, why the change was made, 

who initiated the change, and the impact and results of 

Trang 87

• There are no generic practices that directly map to this process area

87

Trang 88

Decision Analysis and Resolution

• Decision Analysis and Resolution includes determining which decisions will be part of 

a formal decision­making evaluation 

process; creating evaluation criteria; 

determining the types of evaluation 

methods to use; and determining alternative solutions

88

Trang 90

Summary

90

Trang 91

References

• Interpreting the CMMI: A Process 

Improvement Approach, Second Edition, by Margaret K. Kulpa and Kent A. Johnson, 

Auerbach Publication, 2008 (electronic 

file), (Chapter 6)

91

Ngày đăng: 09/12/2022, 03:19