软件工程 Chapter 3 - USTChome.ustc.edu.cn/~xiaoning/se2017/PPT/SE_03_Planning_and...Pfleeger and Atlee, Software Engineering: Theory and Practice 软件工程 Chapter 3 计划和管理项目

Pfleeger and Atlee, Software Engineering: Theory and Practice

软件工程

Chapter 3

计划和管理项目

Shari L. Pfleeger Joanne M. Atlee

4th Edition


软件工程

内容 3.1 跟踪项目进展 3.2 项目人员 3.3 工作量估量 3.4 风险管理 3.5 项目计划 3.6 过程模型和项目管理 3.7 信息系统的例子 3.8 实时系统的例子 3.9 本章对你的意义


软件工程

第3章的目标

• 跟踪项目进展 • 项目人员和组织 • 工作量和进度估算 • 风险管理 • 项目计划和过程建模


软件工程

3.1 跟踪项目进展

• Do we understand customer’s needs? • Can we design a system to solve customer’s

problems or satisfy customer’s needs? • How long will it take to develop the system? • How much will it cost to develop the system?


软件工程

3.1 跟踪项目进展项目进度(Project Schedule)

• 描述特定项目的软件开发周期 – 列举项目的各个阶段 – 把各个阶段分解成离散的任务或活动

• 描绘这些活动之间的交互，并估计每项任务或活动将花费的时间


软件工程

3.1跟踪项目进展项目进度: Approach

• 通过列出所有的项目可交付产品(deliverable)来明确顾客的需求 – Documents – Demonstrations of function – Demonstrations of subsystems – Demonstrations of accuracy – Demonstrations of reliability, performance or security

• 确定为了生产这些产品，必须进行的活动以及里程碑(milestones )


软件工程

3.1跟踪项目进展里程碑和活动(Milestones and activities)

• 活动 Activity: takes place over a period of time • 里程碑 Milestone: completion of an activity -- a

particular point in time • 前驱 Precursor: event or set of events that must occur

in order for an activity to start • 工期 Duration: length of time needed to complete an

activity • 截止日期 Due date: date by which an activity must be

completed


软件工程

3.1跟踪项目进展项目进度

• 开发过程可以划分为一系列阶段，每个阶段由若干步骤组成，每个步骤由活动组成


软件工程

3.1跟踪项目进展项目进度

• Table 3.1 盖房子的阶段、步骤和活动 – landscaping phase – building the house phase

• Table 3.2 盖房子过程中的里程碑


软件工程

3.1跟踪项目进展 Phases, Steps, and Activities in Building a House

Phase 1: Landscaping the lot Phase 2: Building the house Step 1.1: Clearing and grubbing

Step 2.1: Prepare the site

Activity 1.1.1: Remove trees Activity 2.1.1: Survey the land Activity 1.1.2: Remove stumps Activity 2.1.2: Request permits Step 1.2:

Seeding the turf

Activity 2.1.3: Excavate for the foundation

Activity 1.2.1: Aerate the soil Activity 2.1.4: Buy materials Activity 1.2.2: Disperse the seeds Step 2.2:

Building the exterior

Activity 1.2.3: Water and weed Activity 2.2.1: Lay the foundation Step 1.3:

Planting shrubs and trees

Activity 2.2.2: Build the outside walls

Activity 1.3.1: Obtain shrubs and trees

Activity 2.2.3: Install exterior plumbing

Activity 1.3.2: Dig holes Activity 2.2.4: Exterior electrical work

Activity 1.3.3: Plant shrubs and trees Activity 2.2.5: Exterior siding Activity 1.3.4: Anchor the trees and mulch around them

Activity 2.2.6: Paint the exterior

Activity 2.2.7: Install doors and fixtures

Activity 2.2.8: Install roof Step 2.3:

Finishing the interior

Activity 2.3.1: Install the interior plumbing

Activity 2.3.2: Install interior electrical work

Activity 2.3.3: Install wallboard Activity 2.3.4: Paint the interior Activity 2.3.5: Install floor covering Activity 2.3.6: Install doors and

fixtures


软件工程

3.1跟踪项目进展 Milestones in Building a House

1.1. Survey complete 1.2. Permits issued 1.3. Excavation complete 1.4. Materials on hand 2.1. Foundation laid 2.2. Outside walls complete 2.3. Exterior plumbing complete 2.4. Exterior electrical work complete 2.5. Exterior siding complete 2.6. Exterior painting complete 2.7. Doors and fixtures mounted 2.8. Roof complete 3.1. Interior plumbing complete 3.2. Interior electrical work complete 3.3. Wallboard in place 3.4. Interior painting complete 3.5. Floor covering laid 3.6. Doors and fixtures mounted


软件工程

3.1跟踪项目进展 Work Breakdown and Activity Graphs

• 工作分解结构(Work breakdown structure)把项目描述为由若干离散部分构成的集合

• 活动图(Activity graphs)描述活动间的依赖关系 – Nodes: project milestones – Lines: activities involved


软件工程

3.1跟踪项目进展 Work Breakdown and Activity Graphs

• 盖房子的活动图


软件工程

3.1跟踪项目进展估算完成时间

• 在活动图中加入每个活动的估算时间信息，以使得活动图更加有用


软件工程

3.1跟踪项目进展 Estimating Completion for Building a House

Activity Time estimate (in days) Step 1: Prepare the site Activity 1.1: Survey the land 3 Activity 1.2: Request permits 15 Activity 1.3: Excavate for the foundation 10 Activity 1.4: Buy materials 10 Step 2: Building the exterior Activity 2.1: Lay the foundation 15 Activity 2.2: Build the outside walls 20 Activity 2.3: Install exterior plumbing 10 Activity 2.4: Exterior electrical work 10 Activity 2.5: Exterior siding 8 Activity 2.6: Paint the exterior 5 Activity 2.7: Install doors and fixtures 6 Activity 2.8: Install roof 9 Step 3: Finishing the interior Activity 3.1: Install the interior plumbing 12 Activity 3.2: Install interior electrical work 15 Activity 3.3: Install wallboard 9 Activity 3.4: Paint the interior 18 Activity 3.5: Install floor covering 11 Activity 3.6: Install doors and fixtures 7


软件工程

3.1跟踪项目进展关键路径法Critical Path Method (CPM)

• 完成项目所需的最短时间 – 为了按时完成项目，哪些活动是最为关键的

• 真实时间 / 实际时间 Real time (actual time): 估算的完成此活动必须时间量

• 可用时间 Available time: 完成活动可用的时间量 • 时差 Slack time: 可用时间和真实时间之差


软件工程

3.1跟踪项目进展 Critical Path Method (CPM)

• 关键路径Critical path: 路径上每个节点的时差都为0 – 可能存在多条关键路径

• 时差 Slack time = available time – real time = latest start time – earliest start time


软件工程

盖房子各活动的时差

Activity Earliest start time

Latest start time

Slack

1.1 1 13 12 1.2 1 1 0 1.3 16 16 0 1.4 26 26 0 2.1 36 36 0 2.2 51 51 0 2.3 71 83 12 2.4 81 93 12 2.5 91 103 12 2.6 99 111 12 2.7 104 119 15 2.8 104 116 12 3.1 71 71 0 3.2 83 83 0 3.3 98 98 0 3.4 107 107 0 3.5 107 107 0 3.6 118 118 0

Finish 124 124 0


软件工程

3.1跟踪项目进展 CPM Bar Chart

• 包含最早开始时间和最晚开始时间的信息

• 星号表示关键路径


软件工程

3.1跟踪项目进展跟踪进展的工具

• 构造通信软件，工作分解结构的例子


软件工程

3.1跟踪项目进展跟踪进展的工具: 甘特图

• Activities shown in parallel – 帮助理解哪些活动可以并行进行


软件工程

3.1跟踪项目进展跟踪进展的工具: 资源直方图

• 表示分配给项目的人员和每一个开发阶段需要的人员


软件工程

3.1跟踪项目进展跟踪进展的工具: 开销对比图

• An example of how expenditures can be monitored


软件工程

3.2 项目人员 • Key activities requiring personnel

– requirements analysis – system design – program design – program implementation – testing – training – maintenance – quality assurance

• There is great advantage in assigning different responsibilities to different people 不同的责任分配给不同的人


软件工程

3.2项目人员 Choosing Personnel

• 完成工作的能力 Ability to perform work • 对工作的兴趣 Interest in work • 经验 Experience with

– similar applications – similar tools, languages, or techniques – similar development environments

• 培训 Training • 与其他人交流的能力 Ability to communicate with others • 与其他人共同承担责任的能力Ability to share responsibility • 管理技巧 Management skills


软件工程

3.2项目人员交流 Communication

• 项目的进行受…影响 –交流程度 –单个开发人员交流其思想的能力

• 交流和理解中的障碍可能导致软件失败


软件工程

3.2项目人员交流 Communication

• 交流路径的增长速度

• If there is n worker in project, then there are n(n-1)/2 pairs of communication


软件工程

3.2项目人员补充材料 3.1 让会议促进项目进展

• 通常对会议的抱怨 – 会议的目的不清楚 the purpose is unclear – 与会者无准备 the attendees are unprepared – 主要人员缺席或迟到 essential people are late or absent – 谈话内容偏离主题 the conversation veers away from its purpose – 会议参与者争论而不是讨论 participants do not discuss, instead argue – 决策没有被执行 decisions are never enacted afterward

• 保障一个会议的成效 – 清楚谁应该出席 clearly decide who should be in the meeting – 制定会议议程 develop an agenda – 有人负责确保讨论不偏离主题have someone who tracks the discussion – 有人负责确保决策被执行 have someone who ensures follow-up actions


软件工程

3.2项目人员工作风格Work Styles

• 外向型 Extroverts: tell their thoughts • 内向型 Introverts: ask for suggestions • 感性的 Intuitives: base decisions on feelings • 理性的 Rationals: base decisions on facts,

options


软件工程


• 水平轴: 交流风格 • 垂直轴: 决策风格


软件工程


• 工作风格决定交流方式 • 理解工作风格有利于

– help to be flexible – give information based on other's priorities

• 影响着客户、开发人员和用户之间的交互


软件工程

3.2项目人员项目组织Project Organization

• 取决于 – 团队成员的背景和工作风格 – 团队成员的数目 – 客户和开发人员的管理风格

• 示例: – 主程序员负责制组Chief programmer team: one

person totally responsible for a system's design and development

– 忘我方法Egoless approach: hold everyone equally responsible


软件工程

3.2项目人员项目组织:主程序员负责制组

• 每个小组成员必须经常与主程序员交互，但不必和其他小组成员交流


软件工程

3.2项目人员项目组织

• 项目的特性，针对这些特性所建议采用的组织结构

Highly structured Loosely structured High certainty Uncertainty Repetition New techniques or technology Large projects Small projects


软件工程

3.2项目人员补充材料 3.2 结构化与创造性

• Experiment by Sally Phillip examining two groups building a hotel – structured team: clearly defined responsibilities – unstructured team: no directions

• The results are always the same – Structured teams finish a functional Days Inn – Unstructured teams build a creative, multistoried Taj Mahal and

never complete

• 好的项目管理意味着在结构化和创造性中找到一种平衡


软件工程

3.3 工作量评估 • 项目计划和管理的一个重要的方面是：了解项目成本 • 估算成本应在项目的生命周期中尽早进行 • Type of costs

– 设施 facilities: hardware, space, furniture, telephone, etc

– 支持开发工作的软件和工具 software tools for designing software

– 工作量 staff (effort): the biggest component of cost


软件工程

3.3工作量评估成本估算应该反复进行

• Uncertainty early in the project can affect the accuracy of cost and size estimations


软件工程

3.3工作量评估补充材料 3.3 不精确估算的原因

• 关键原因 – 用户频繁变更需求 Frequent request for change by users – 忽略了任务 Overlooked tasks – 用户对自己的需求缺乏了解 User's lack of understanding of the requirements – 进行估算时缺乏充分分析 Insufficient analysis when developing estimates – 系统开发、技术服务、操作、数据管理与开发中其他功能之间缺乏协调 Lack of coordination of system development, technical services,

operations, data administration, and other functions during development – 缺乏适当的估算反复或指导原则 Lack of an adequate method or guidelines for estimating


软件工程

3.3工作量评估补充材料 3.3 不精确估算的原因

• 对估算产生重要影响的方面 – Complexity of the proposed application system – Required integration with existing system – Complexity of the program in the system – Size of the system expressed as number of functions or programs – Capabilities of the project team members – Project team's experience with the application, the programming

language, and hardware – Capabilities of the project team members – Database management system – Number of project team member – Extent of programming and documentation standards


软件工程

3.3工作量评估估算方法

• 专家判断

• Top-down or bottom-up

– 类推 Analogy: 悲观pessimistic (x), 乐观optimistic (y), 最可能most likely (z); estimate as (x + 4y + z)/6

– Delphi technique: based on the average of “secret” expert judgments

• 算法方法: E = (a + bSc) m(X) – Walston and Felix model: E = 5.25 S 0.91

– Bailey and Basili model: E = 5.5 + 0.73 S1.16


软件工程

3.3工作量评估专家判断: Wolverton Model

• 难度取决于两个因素 – whether problem is old (O) or new (N) – whether it is easy (E) or moderate (M)

Difficulty Type of software OE OM OH NE NM NH Control 21 27 30 33 40 49 Input/output 17 24 27 28 35 43 Pre/post processor 16 23 26 28 34 42 Algorithm 15 20 22 25 30 35 Data management 24 31 35 37 46 57 Time-critical 75 75 75 75 75 75


软件工程

3.3工作量评估算法方法: Watson and Felix Model

• 基本的方程式补充有一个生产率指标 • 可能影响生产率的29个指标

– 1 if increase the productivity – 0 if decrease the productivity


软件工程

3.3工作量评估 Watson and Felix Model Productivity Factors

1. Customer interface complexity 16. Use of design and code inspections

2. User participation in requirements definition

17. Use of top-down development

3. Customer-originated program design changes

18. Use of a chief programmer team

4. Customer experience with the application area

19. Overall complexity of code

5. Overall personnel experience 20. Complexity of application processing

6. Percentage of development programmers who participated in the design of functional specifications

21. Complexity of program flow

7. Previous experience with the operational computer

22. Overall constraints on program’s design

8. Previous experience with the programming language

23. Design constraints on the program’s main storage

9. Previous experience with applications of similar size and complexity

24. Design constraints on the program’s timing

10. Ratio of average staff size to project duration (people per month)

25. Code for real-time or interactive operation or for execution under severe time constraints

11. Hardware under concurrent development

26. Percentage of code for delivery

12. Access to development computer open under special request

27. Code classified as nonmathematical application and input/output formatting programs

13. Access to development computer closed

28. Number of classes of items in the database per 1000 lines of code

14. Classified security environment for computer and at least 25% of programs and data

29. Number of pages of delivered documentation per 1000 lines of code

15. Use of structured programming


软件工程

3.3工作量评估算法方法: Bailey-Basili technique

• 最小化标准误差，产生的方程式： E = 5.5 + 0.73S1.16

• 根据误差比率调整初始估算 – 如果R是实际工作量E和预测工作量E’之间的比率，则工作量调整定义为 – ERadj = R – 1 if R > 1 = 1 – 1/R if R < 1

• 调整初始的工作量估算 Eadj – Eadj = (1 + ERadj)E if R > 1 = E/(1 + ERadj) if R < 1


软件工程

3.3工作量评估算法方法: Bailey-Basily Modifier

Total methodology (METH)

Cumulative complexity (CPLX)

Cumulative experience (EXP)

Tree charts Customer interface complexity

Programmer qualifications

Top-down design Application complexity Programmer machine experience

Formal documentation Program flow complexity Programmer language experience

Chief programmer teams

Internal communication complexity

Programmer application experience

Formal training Database complexity Team experience Formal test plans External communication

complexity

Design formalisms Customer-initiated program design changes

Code reading Unit development folders


软件工程

3.3工作量评估 COCOMO model

• Introduced by Boehm • COCOMO II

– updated version – include models of reuse

• The basic models – E = bScm(X) – where

• bSc is the initial size-based estimate • m(X) is the vector of cost driver information


软件工程

3.3工作量评估 COCOMO II: 开发项目的主要阶段

• 应用组装 Application composition – 构造原型以解决高风险问题 prototyping to resolve high-risk user interface issues

– 使用应用点对规模进行测量 size estimates in object points

• 早期设计阶段 Early design – 研究可选的体系结构 to explore alternative architectures and concepts

– 使用功能点对规模进行测量 size estimates in function points

• 后体系结构阶段 Postarchitecture – 开发已经开始 development has begun

– 根据代码行对规模进行测量 size estimates in lines of code


软件工程

Three Stages of COCOMO II

Stage 1: Stage 2: Application Early Stage 3: Model Aspect Composition Design Post-architecture

Size Application Function points (FP) FP and language or source lines points and language of code (SLOC)

Reuse Implicit in Equivalent SLOC as Equivalent SLOC as function of model function of other other variables variables

Requirements Implicit in % change expressed as % change expressed as a change model a cost factor cost factor

Maintenance Application Function of ACT, software Function of ACT, software Point understanding, understanding, Annual unfamiliarity unfamiliarity Change Traffic

Scale (c) in 1.0 0.91 to 1.23, depending 0.91 to 1.23, depending on nominal effort on precedentedness, precedentedness, conformity, equation conformity, early early architecture, risk resolution, architecture, risk team cohesion, and SEI process resolution, team maturity cohesion, and SEI process maturity

Product cost None Complexity, required Reliability, database size, drivers reusability documentation needs, required reuse, and product complexity

Platform cost None Platform difficulty Execution time constraints, main drivers storage constraints, and virtual machine volatility

Personnel None Personnel capability Analyst capability, applications cost drivers and experience experience, programmer capability, programmer experience, language and tool experience, and personnel continuity

Project cost None Required development Use of software tools, required drivers schedule, development development schedule, and environment multisite development


软件工程

3.3工作量评估 COCOMO II: Estimate Application Points

• 为了计算应用点，首先要计算应用中将要包含的屏幕、报告、构件。并确定其复杂程度。

To compute application points, first we need to count the number of screens, reports and programming language used to determine the complexity level

8 + medium difficult difficult 4 + medium difficult difficult

For Screens For Reports

Number and source of data tables Number and source of data tables

Number of

views

contained

Total < 4

(<2

server,

<3

client)

Total < 8

(2-3

server,

3-5

client)

Total 8+

(>3

server, >5

client)

Number of

sections

contained

Total < 4

(<2

server,

<3

client)

Total < 8

(2-3

server, 3-

5 client)

Total 8+

(>3

server,

>5

client)

<3 simple simple medium 0 or 1 simple simple medium

3 - 7 simple medium difficult 2 or 3 simple medium difficult


软件工程

3.3工作量评估 COCOMO II: Estimate Application Point

• Determine the relative effort required to implement a report or screen simple, medium or difficult

• Calculate the productivity factor based on developer experience and capability

• Determine the adjustment factors expressed as multipliers based on rating of the project


软件工程

3.3工作量评估 Complexity Weights for Application Points

应用点的复杂性权重

Object type Simple Medium Difficult

Screen 1 2 3

Report 2 5 8

3GL component - - 10


软件工程

3.3工作量评估 Productivity Estimate Calculation

生产率估量的计算

Developers’ experience and capability

Very low Low Nominal High Very high

CASE maturity and capability

Very low Low Nominal High Very high

Productivity factor 4 7 13 25 50


软件工程

3.3工作量评估工具使用类别

Category Meaning Very low Edit, code, debug Low Simple front-end, back-end CASE, little integration Nominal Basic life-cycle tools, moderately integrated High Strong, mature life-cycle tools, moderately

integrated Very high Strong, mature, proactive life-cycle tools, well-

integrated with processes, methods, reuse


软件工程

3.3工作量评估机器学习方法

• Example: case-based reasoning (CBR，基于案例的推理)

• Example: neural network 神经网络 – cause-effect network “trained” with data from

past history


软件工程

3.3工作量评估机器学习方法: 神经网络

• Shepperd的前馈神经网络


软件工程

3.3工作量评估机器学习方法: CBR

• 4个步骤 – 用户将一个新问题标识为一个案例 user identifies new problem as a case – 系统从历史信息库中检索相似案例 system retrieves similar cases from repository – 系统复用先前案例的知识 system reuses knowledge from previous cases – 系统对新的案例提出一个解决方案 system suggests solution for new case

• 建立一个成功的CBR系统时的两大障碍

– 描述案例的特性 characterizing cases – 确定相似度 determining similarity


软件工程

3.3工作量评估找出适合具体情况的模型

• 相对误差的平均幅度 Mean magnitude of relative error (MMRE) – absolute value of mean of [(actual - estimate)/actual] – goal: should be .25 or less

• Pred(x/100): percentage of projects for which estimate is within x% of the actual – goal: should be .75 or greater for x = .25 – 75% project estimates are within 25% of actual


软件工程

3.3工作量评估评估模型

• 还没有模型能够抓住所有类型开发的本质特性及其关系 No model appears to have captured the essential charateristics and

their relationships for all types of development

Model PRED(0.25) MMRE Walston-Felix 0.30 0.48 Basic COCOMO 0.27 0.60 Intermediate COCOMO 0.63 0.22 Intermediate COCOMO (variation)

0.76 0.19

Bailey-Basili 0.78 0.18 Pfleeger 0.50 0.29 SLIM 0.06-0.24 0.78-1.04 Jensen 0.06-0.33 0.70-1.01 COPMO 0.38-0.63 0.23-5.7 General COPMO 0.78 0.25


软件工程

3.3工作量评估评估模型

• 即使在估算模型估算得相当准确时，还必须了解哪些类型的工作是开发过程中所必须的 – 分类和记录结果

• 工作量分布的不同报告


软件工程

3.4 风险管理什么是风险?

• 风险(Risk)是一种具有负面后果的，人们不希望发生的事件

• Distinguish risks from other project events – 风险影响 Risk impact: the loss associated with the event – 风险概率 Risk probability: the likelihood that the event will occur

• Quantify the effect of risks – 风险暴露 Risk exposure = (risk probability) x (risk impact)

• 风险来源Risk sources: – 一般风险 generic – 特定项目风险 project-specific


软件工程

3.4风险管理风险管理活动


软件工程

3.4 风险管理风险管理活动

• 风险暴露计算的例子 PU: prob. of

unwanted outcome

LU: lost assoc with unwanted outcome


软件工程

3.4风险管理风险管理活动

• 3种降低风险的策略 – 避免风险Avoiding the risk: 改变对性能或功能的需求 – 转移风险Transferring the risk: 转移到其他系统，或购买保险 – 假设风险Assuming the risk: 接收并控制它

• 降低风险的成本 – 风险杠杠 Risk leverage = (risk exposure before reduction – (risk exposure

after reduction) / (cost of risk reduction)


软件工程

3.4风险管理补充材料3.4 Boehm的十个风险事项

• 人员短缺 Personnel shortfalls • 不现实的进度和预算 Unrealistic schedules and budgets • 开发错误的功能 Developing the wrong functions • 开发错误的用户界面 Developing the wrong user interfaces • 华丽的计划 Gold-plating • 持续的需求变化 Continuing stream of requirements changes • 外部执行的任务为达到要求 Shortfalls in externally-performed tasks • 外部提供的构件达不到要求 Shortfalls in externally-furnished components • 实时性能达不到要求 Real-time performance shortfalls • 超出计算机科学的能力 Straining computer science capabilities


软件工程

3.5 项目计划项目计划内容

• 项目范围 Project scope • 项目进度 Project schedule • 项目团队组织结构Project team

organization • 系统的技术描述 Technical

description of system • 项目标准、过程Project

standards and procedures • 质量保证计划Quality

assurance plan • 配置管理计划 Configuration

management plan

• 文档计划 Documentation plan • 数据管理计划 Data

management plan • 资源管理计划 Resource

management plan • 测试计划 Test plan • 培训计划 Training plan • 安全计划 Security plan • 风险管理计划 Risk

management plan • 维护计划 Maintenance plan


软件工程

3.5项目计划 Project Plan Lists

• 列出开发团队的成员 • 列出硬件和软件 • 列出使用的标准和方法, such as

– 算法 algorithms – 工具 tools – 评审或审查技术 review or inspection techniques – 设计语言或标识 design language or representaions – 编码语言 coding languages – 测试技术 testing techniques


软件工程

3.6 过程模型和项目管理注册管理模型: Digital Alpha AXP

• 建立一个适当大的共享愿景

Establish an appropriately large shared vision

• 完全委托，并请参与者给出明确的承诺

Delegate completely and elicit specific commitments from participants

• 积极审查并提供支持性反馈

Inspect vigorously and provide supportive feedback

• 认可每一次进步，随着规模的进展不断学习

Acknowledge every advance and learn as the program progresses


软件工程

3.6过程模型和项目管理 Management Digital Alpha AXP

• 愿景(Vision): 用于 “enroll” 相关规划，使之具有同样的目标


软件工程

3.6过程模型和项目管理 Management Digital Alpha AXP

• 项目组织结构：使得技术和项目两个方面的焦点都服从于整个项目


软件工程

3.6过程模型和项目管理责任建模: Lockheed Martin

• 矩阵组织 Matrix organization – 每个工程师属于某个功能单元，根据其技术

Each engineer belongs to a functional unit based on type of skill

• 集成产品开发团队 Integrated product development team – 来自不同功能组的个人组合成一个交叉学科的工作单元

Combines people from different functional units into interdisciplinary work unit

• 对每个活动跟踪进展，方法包括成本估算、关键路径分析、进度跟踪 – 挣值(Earned value) a common measure for progress


软件工程


• F-16项目中的责任模型


软件工程


• 团队有多个，重叠的活动

• 用活动图说明每个活动的进展


软件工程


• 每个活动的进展用挣值汇总图来跟踪


软件工程

3.6过程模型和项目管理紧密结合里程碑

• 生命周期计划

• 目标 Objectives: Why is the system being developed? • 里程碑和进度 Milestones and schedules: What will be done by when? • 责任 Responsibilities: Who is responsible for a function? • 方法 Approach: How will the job be done, technically and managerially? • 资源 Resources: How much of each resource is needed? • 可行性 Feasibility: Can this be done, and is there a good business reason for

doing it? • 生命周期体系结构: 定义系统和软件的系统结构，说明体系结构的选择及其风险 • 初始运作能力: 软件就绪readiness of software, 场所 deployment site, 用户培训user

training


软件工程

3.6过程模型和项目管理紧密结合里程碑

• 作为对这些里程碑的补充，Boehm建议使用双赢螺旋模型(Win-Win spiral model)


软件工程

3.7 信息系统的例子 Piccadilly System

• Using COCOMO II • Three screens and one report

– Booking screen: complexity simple, weight 1 – Ratecard screen: complexity simple, weigth 1 – Availability screen: complexity medium, weight 2 – Sales report: complexity medium, weight 5

• Estimated effort = 182 person-month


软件工程

3.8 实时系统的例子 Ariane-5 System

• The Ariane-5 destruction might have been prevented had the project managers developed a risk management plan – Risk identification: possible problem with reuse of the Ariane-4) – Risk exposure: prioritization would have identified if the inertial

reference system (SRI) did not work as planned – Risk control: assesment of the risk using reuse software – Risk avoidance: using SRI with two different designs


软件工程

3.7 本章对你的意义

• Key concepts in project management – Project planning – Cost and schedule estimation – Risk management – Team Organization

• Project planning involves input from all team members • Communication path grows as the size of the team

increases and need to be taken into account when planning and estimating schedule