Bài giảng Bộ môn Công nghệ phần mềm - Bài 10: Các chủ đề khác trong SE

Bài 10: Các chủ đề khác trong SE cung cấp các nội dung liên quan đến lĩnh vực công nghệ phần mềm như: Quản lý phần mềm (Software project management), ước lượng chi phí phần mềm (SE Cost Estimation), cải tiến quy trình phát triển phần mềm (Software Process Improvement), sản xuất phần mềm... Mời các bạn cùng tham khảo.

Các v n đ  khác trong SE ấ ề

BM CNPM – Khoa CNTT – 

HVKTQS 10/2012

 S n ph m vô hình ả ẩ

 Ph n m m là lo i s n ph m linh ho t  ầ ề ạ ả ẩ ạ duy nh t ấ

 Quy trình phát tri n ph n m m không  ể ầ ề

đ ượ c chu n hóa ẩ

 Nhi u d  án ph n m m ch  đ ề ự ầ ề ỉ ượ c th c  ự

hi n m t l n ệ ộ ầ

Software management – nét riêng

Management activities

 Thường  không  có  nh ng  con  ngữ ười  lý  tưởng  trong các d  ánự

 Ngân  sách  d   án  không  cho  phép  s   d ng  các  nhân  viên  ự ử ụ

đ ượ c tr  l ả ươ ng cao;

 Có th  không có nh ng nhân viên có kinh nghi m thích h p; ể ữ ệ ợ

 T  ch c mu n phát tri n k  năng nhân viên thông qua d   ổ ứ ố ể ỹ ự án.

 Các nhà qu n lý ph i làm vi c v i nh ng khó khăn ả ả ệ ớ ữ

đ c  bi t  khi  có  s   thi u  h t  c a  đ i  ngũ  nhân  viên ặ ệ ự ế ụ ủ ộ

được đào t o.ạ

 + Ng ườ i phân tích thi t k  h  th ng là ng ế ế ệ ố ườ i gi i  ỏ

nh t v  chuyên môn, ph  trách thu nh n yêu c u  ấ ề ụ ậ ầ

c a khách hàng đ  thi t k  1 h  th ng đáp  ng c a  ủ ể ế ế ệ ố ứ ủ khách hàng.

 + Ti p đ n là ng ế ế ườ i ph  trách ph n m m, có  ụ ầ ề nhi m v  tr  giúp cho c  nhóm, cung c p cho nhóm  ệ ụ ợ ả ấ

t t c  các ch ấ ả ươ ng trình tr  giúp liên quan, các ph n  ợ ầ

m m liên quan, các công c  Đi u đó giúp gi m b t  ề ụ ề ả ớ

th i gian, công s c và s  trùng l p ờ ứ ự ặ

important assets.

 The tasks of a manager are essentially  people­oriented. Unless there is some  understanding of people, management  will be unsuccessful.

important contributor to project failure.

management plan  Describes  the  configuration  management  procedures  and structures to be used. See Chapter 29. 

Maintenance plan  Predicts  the  maintenance  requirements  of  the  system, 

maintenance costs and effort required. See Chapter 21. 

Staff  development 

plan.  Describes how the skills and experience of the project team members will be developed. See Chapter 25. 

Establish the project constraints

Make initial assessments of the project parameters

Define project milestones and deliverables

while project has not been completed or cancelled loop

Draw up project schedule Initiate activities according to schedule Wait ( for a while )

Review project progress Revise estimates of project parameters Update the project schedule

Re-negotiate project constraints and deliverables

if ( problems arise ) then

Initiate technical review and possible revision end if

end loop

 The resources available to the  project;

 The work breakdown;

 A schedule for the work.

 Chia d  án thành các nhi m v  và d  toán th i  ự ệ ụ ự ờ gian, ngu n l c c n thi t đ  hoàn thành m i  ồ ự ầ ế ể ỗ

nhi m v ệ ụ

 T  ch c th c hi n các nhi m v  đ ng th i đ   ổ ứ ự ệ ệ ụ ồ ờ ể

s  d ng t i  u l c l ử ụ ố ư ự ượ ng lao đ ng ộ

 Gi m thi u s  ph  thu c gi a nhi m v  đ   ả ể ự ụ ộ ữ ệ ụ ể

tránh s  ch m tr  gây ra b i m t nhi m v  nào  ự ậ ễ ở ộ ệ ụ

đó đ  d  án hoàn thành đúng ti n đ ể ự ế ộ

 Ph  thu c vào tr c giác và kinh nghi m qu n  ụ ộ ự ệ ả

lý d  án ự

Estimate resources for activities

Identify activity dependencies

 Đánh giá m c đ  khó khăn c a v n đ  và  ứ ộ ủ ấ ề chi phí phát tri n gi i pháp là m t bài toán  ể ả ộ khó.

 Năng su t lao đ ng không t  l  thu n v i  ấ ộ ỷ ệ ậ ớ

s   l ố ượ ng  ng ườ i  làm  vi c  trên  m t  nhi m  ệ ộ ệ

v ụ

 Thêm ng ườ i vào d  án ch m làm cho d   ự ậ ự

án  b   kéo  dài  do  phát  sinh  các  chi  phí  ị truy n thông ề

networks

 Graphical notations used to illustrate the  project schedule.

 Show project breakdown into tasks. Tasks  should not be too small. They should take  about a week or two.

 Activity charts show task dependencies 

and the critical path.

 Bar charts show schedule against 

calendar time.

Task durations and  dependencies

Activity Duration (days) Dependencies

M2 T4

25 days

10 days

20 days

5 days 25/7/03

M4 T9 M7 T10

M6 T11

M8 T12

Start

Finish

T9 T2

 Risk management is concerned with 

identifying risks and drawing up plans to  minimise their effect on a project.

 A risk is a probability that some adverse  circumstance will occur 

Risk Affects Description

Staff turnover Project Experienced staff will leave the project before it is finished Management change Project There will be a change of organisational management with

Risk avoidance and contingency

 The physical workplace provision has an important effect on individual productivity and satisfaction

 Comfort;

 Privacy;

 Facilities.

 Health and safety considerations must be taken into account

 Lighting;

 Heating;

 Furniture.

Working environments

the development of people involved in  software development.

 To improve organisational capability by  improving workforce capability.

 Optimizing. Continuous focus on improving individual 

competence and workforce motivation

Software cost estimation

cost, to the developer, of producing a  software system.

 There is not a simple relationship 

between the development cost and the  price charged to the customer.

political and business considerations  influence the price charged.

 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

 What's  a line of code?

 The measure was first proposed when programs were typed 

on cards with one line per card;

 How does this correspond to statements as in Java which  can span several lines or where there can be several 

statements on one line.

 What programs should be counted as part of the 

system?

 This model assumes that there is a linear relationship between system size and volume of documentation

Lines of code

UFC = (number of elements of given type) *(weight)

 The function point count is 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 assemble language to 2­40 for a 4GL;

 FPs are very subjective. They depend on the 

estimator

 Automatic function­point counting is impossible.

 Object points (alternatively named application points) are an alternative function­related measure to 

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

 Object points are easier to estimate from a  specification than function points as they  are simply concerned with screens, 

reports and programming language 

modules.

 They can therefore be estimated at a fairly  early point in the development process.

  At this stage, it is very difficult to estimate  the number of lines of code in a system.

 Real­time embedded systems, 40­160  LOC/P­month.

points/month depending on tool support  and developer capability.

Productivity estimates

 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 requirements are constantly changing then an approach based on counting lines of code is not meaningful as the program itself is not static;

Quality and productivity

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

 An empirical model based on project experience

 Well­documented, ‘independent’ model which is not tied to a specific software vendor

 Long history from initial version published in 1981 (COCOMO­81) through various instantiations to 

COCOMO 2

 COCOMO 2 takes into account different approaches 

to software development, reuse, etc. 

COCOMO 81

Process Improvement 

 Hi u bi t v  các quy trình hi n có và gi i thi u  ể ế ề ệ ớ ệ quá trình thay đ i đ  c i thi n ch t l ổ ể ả ệ ấ ượ ng s n  ả

ph m, gi m chi phí ho c đ y nhanh ti n đ ẩ ả ặ ẩ ế ộ

 H u  h t  các  công  vi c  c i  ti n  quy  trình  cho  ầ ế ệ ả ế

đ n nay t p trung vào vi c gi m khi m khuy t.  ế ậ ệ ả ế ế

Đi u  này  ph n  ánh  s   quan  tâm  ngày  càng  ề ả ự tăng  c a  ngành  công  nghi p  đ i  v i  ch t  ủ ệ ố ớ ấ

l ượ ng.

 Tuy  nhiên,  các  thu c  tính  khác  c a  quá  trình  ộ ủ

s n xu t phát tri n cũng c n đ ả ấ ể ầ ượ c c i ti n ả ế

Process improvement

Process attributes

Analyse Measure

Change

 Process quality and product quality are closely 

related and process improvement benefits arise 

because the quality of the product depends on its development process

Product quality

Development technolo gy

Cost, time and schedule

Process

quality

People quality

 In all cases, if an unrealistic schedule is  imposed then product quality will suffer.

 Wherever possible, quantitative process data 

should be collected

 However, where organisations do not have clearly defined  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.

 Process measurements should be used to 

assess process improvements

 But this does not mean that measurements should drive the  improvements. The improvement driver should be the 

organizational objectives.

Process measurement

 Time taken for process activities to be  completed

 E.g. Calendar time or effort to complete an  activity or process.

 Resources required for processes or 

activities

 E.g. Total effort in person­days.

 Number of occurrences of a particular  event

 E.g. Number of defects discovered.

Classes of process 

measurement

 Goals

The objective of process improvement is to  satisfy these goals.

modelling

 Process analysis

 The study of existing processes to understand  the relationships between parts of the process  and to compare them with other processes.

Process analysis and 

modelling

 The CMMI framework is the current stage of work on process assessment and improvement that started at the Software Engineering Institute in the 1980s

 The SEI’s mission is to promote software technology transfer particularly to US defence contractors

 It has had a profound influence on process 

improvement

 Capability Maturity Model introduced in the early 1990s.

 Revised maturity framework (CMMI) introduced in 2001.

influential.

 Practices associated with model levels

 Companies could be using practices from different levels at  the same time but if all practices from a lower level were not  used, it was not possible to move beyond that level

 24 process areas that are relevant to process capability and  improvement are identified. These are organised into 4 

groups.

 Goals are descriptions of desirable organisational states.  Each process area has associated goals.

 Practices are ways of achieving a goal ­ however, they are  advisory and other approaches to achieve the goal may be  used.

CMMI process areas 1

CMMI goals

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.

 Examines the processes used in an organisation and assesses their maturity in each process area

 Comparable with the software CMM.

 Each maturity level has process areas and  goals. For example, the process area 

Level 3 Defined

Level 2 Managed

Level 1

Initial

Level 4

Quantitatively managed

Level 5 Optimizing

 Institutions operating at the managed level  should have institutionalised practices that  are geared to standardisation.

 Establish and maintain  policy for performing  the project management process;

 Provide adequate resources for performing the  project management process;

 Monitor and control the project planning 

process;

 Review the activities, status and results of the  project planning process.

 This is a finer­grain model that considers individual or groups of practices and assesses their use

 The maturity assessment is not a single value but is a set of values showing the organisations maturity in each area

 The CMMI rates each process area from levels 1 to 5

 The advantage of a continuous approach is that 

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

Tài li u tham kh o ệ ả

 R. Pressman, K  ngh  ph n m m. T p 1, 2, 3. NXB Giáo d c,  ỹ ệ ầ ề ậ ụ

Hà N i, 1997 (Ng ộ ườ ị i d ch: Ngô Trung Vi t) ệ

 R.  Pressman,  Software  Engineering:  A  Practioner’s  Approach.  5th Ed., McGraw­Hill, 2001. Chapters 3, 4, 5, 6, 7.

 I. Sommerville, Software Engineering. 5th Ed., Addison­Wesley, 

1995. Chapters 22, 23, 25.