软件工程实践者的研究方法讲义.ppt
合集下载
《软件工程-实践者的研究方法》chapter_17.ppt
![《软件工程-实践者的研究方法》chapter_17.ppt](https://img.taocdn.com/s3/m/449c10ba581b6bd97e19ea2f.png)
2
What Are These Changes?
changes in business requirements
changes in technical requirements
changes in user requirements
other documents
Project Plan
software models
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
Bersoff, et al, 1980
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
4
Baselines
The IEEE (IEEE Std. No. 610.12-1990) defines a baseline as:
• A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.
《软件工程-实践者的研究方法》chapter_20_cn_项目估算PPT精品文档29页
![《软件工程-实践者的研究方法》chapter_20_cn_项目估算PPT精品文档29页](https://img.taocdn.com/s3/m/c814a383be1e650e52ea99df.png)
2005
5
了解范围...
理解客户需求 理解业务上下文 理解项目边界 理解用户的动机 理解改变发生的可能路径 理解…….
即使你已经理解了,还是不能保证任何事情!
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s
har dware
environment
network resources
proj ect
OTS components
reusable software
new components
full -experi ence components
par t.-experience components
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s
Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001,
2005
1
项目计划任务集合——I
构造项目范围 确定可行性 分析风险
见25章
确定需要的资源
Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001,
《软件工程-实践者的研究方法》chapter_17_cn_软件配置管理PPT精品文档23页
![《软件工程-实践者的研究方法》chapter_17_cn_软件配置管理PPT精品文档23页](https://img.taocdn.com/s3/m/ae2e43c5b0717fd5370cdc30.png)
Bus ines s Cont ent
u se -case s an aly sis m o d e l
sce n ario -b ase d d iag ram s f lo w -o rie n t e d d iag ram s class-b ase d d iag ram s b e h av io ral d iag ram s d e sig n m o d e l arch it e ct u ral d iag ram s in t e rf ace d iag ram s co m p o n e n t -le v e l d iag ram s t e ch n ical m e t rics
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s
Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001,
Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001,
2005
9
SCM 库
SCM中心库是一组机制和数据结构,使软件团队能够 用一种更有效地方法管理变更。
已经通过正式评审和批准的规格说明或产品,它可以作为 进一步开发的基础,并且只有通过正式的变更控制规程才 能修改它。
u se -case s an aly sis m o d e l
sce n ario -b ase d d iag ram s f lo w -o rie n t e d d iag ram s class-b ase d d iag ram s b e h av io ral d iag ram s d e sig n m o d e l arch it e ct u ral d iag ram s in t e rf ace d iag ram s co m p o n e n t -le v e l d iag ram s t e ch n ical m e t rics
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s
Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001,
Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001,
2005
9
SCM 库
SCM中心库是一组机制和数据结构,使软件团队能够 用一种更有效地方法管理变更。
已经通过正式评审和批准的规格说明或产品,它可以作为 进一步开发的基础,并且只有通过正式的变更控制规程才 能修改它。
《软件工程-实践者的研究方法》chapter_07.ppt
![《软件工程-实践者的研究方法》chapter_07.ppt](https://img.taocdn.com/s3/m/f94e50102b160b4e767fcf6a.png)
the design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.
the design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.
be ha v i or a l element s
state diagrams sequence diagrams
Com pone nt Le v e l De sign
Int e rfa c e De sign Arc hit e c t ura l De sign
D a t a / Cla ss D e sig n
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman.
Design Model
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman.
the design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.
be ha v i or a l element s
state diagrams sequence diagrams
Com pone nt Le v e l De sign
Int e rfa c e De sign Arc hit e c t ura l De sign
D a t a / Cla ss D e sig n
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman.
Design Model
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill, 2009) Slides copyright 2009 by Roger Pressman.
《软件工程-实践者的研究方法》chapter_09_cn_构件设计共15页
![《软件工程-实践者的研究方法》chapter_09_cn_构件设计共15页](https://img.taocdn.com/s3/m/ea75ba6e79563c1ec4da7137.png)
Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001,
2005
2
什么是构件?
在面向对象软件工程环境中,构件包括一组协作的类 (有时,一个构件只包含一个单独的类)。
2005
5
基本设计原则
开关原则/The Open-Closed Principle (OCP). “A module [component] should be open for extension but closed for modification.
什么是构件?
构件是计算机软件中的一个模块化的构造块。 OMG UML规范对构件的定义:系统中模块化的、可配
置的和可替换的部件,该部件封装了实现并暴露了一组 接口。 OMG Unified Modeling Language Specification [OMG01] defines a component as
com put ePageC ost ( ) com put ePaper C ost ( ) com put ePr odC ost ( ) c o m p u t e To t a lJ o b C o s t ( )
< < in t e r f a c e > > in it ia t e J o b
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s
Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001,
《软件工程-实践者的研究方法》chapter_21.ppt
![《软件工程-实践者的研究方法》chapter_21.ppt](https://img.taocdn.com/s3/m/9f9fb85f03d8ce2f00662376.png)
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
2
Scheduling Principles
compartmentalization—define distinct tasks
interdependency—indicate task interrelationship
falling behind schedule and a lack of action to correct the problem
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
4
Effort Allocation
40-50% 15-20% 30-40%
“front end” activities
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Rogeivery Time
Ef fort Cost
Impos sible region
软件工程实践者的研究方法讲义(PPT29张)
![软件工程实践者的研究方法讲义(PPT29张)](https://img.taocdn.com/s3/m/5f9e22f9b14e852458fb577c.png)
软件风险
一般认为软件风险包含两个特性:
不确定性——风险可能发生也可能不发生; 损失——如果风险发生,就会产生恶性后果或损失。
进行风险分析时,重要的是量化每个风险的不 确定程度和损失程度。为了实现这点,必须考虑 不同类型的风险。 项目风险威胁到项目计划。如果项目风险发生, 就有可能会拖延项目的进度和增加项目的成本。 项目风险是指预算、进度、人员、资源、利益相 关方、需求等方面的潜在问题以及它们对软件项 目的影响。
风险管理
工作产品是风险缓解、监测和管理计划或 一且风险信息表单。 所要分析和管理的风险,应该通过彻底研 究人员、产品、过程和项目来确定。 RMMM计划应该随着项目的进展而修订, 以保证所考虑的风险是近期可能发生的。 风险管理的应急计划应该是符合实际的。
风险管理
首先,风险涉及的是未来将要发生的事情。 今天和昨天的事情已不再关心。问题是: 我们是否能够通过改变今天的行为,而为 一个不同的、充满希望的、更美好的明天 创造机会。其次,风险涉及改变。如思想、 观念、行为、地点的改变……第三,风险 涉及选择,而选择本身就具有不确定性。 [CHA89]
1.高层的软件管理者和客户管理者已经正式承诺支持该项目了吗? 2.最终用户对项目和待开发的系统/产品热心支持吗? 3.软件工程团队及其客户充分理解需求了吗? 4.客户已经完全地参与到需求定义中了吗? 5.最终用户的期望现实吗? 6.项目范围稳定吗? 7.软件工程团队的技能搭配合理吗? 8.项目需求稳定吗? 9.项目团队对将实现的技术有经验吗? 10.项目团队的人员数满足项目需要吗? 11.所有的客户/用户对项目的重要性和待开发的系统/产品的需求有共识 吗?
风险管理
对于软件工程领域中的风险,以上三条概念定义 是显而易见的。未来是我们所关心的——什么样的 风险会导致软件项目彻底失败?改变也是我们所关 心的——客户需求、开发技术、目标环境以及所有 其他与项目相关因素的改变将会对进度安排和总体 成功产生什么影响?最后,我们必须抓住选择机 会——应该采用什么方法及工具?需要多少人员参 与?对质量的要求要达到什么程度才是“足够的”? 当没有办法消除风险,甚至连试图降低该风险也 存在疑问时,这个风险就是真正的风险了。“在弄 清楚软件项目中的”真正风险“之前,识别出所有 对管理者及开发者而言显而易见的风险是很重要的。
《软件工程-实践者的研究方法》chapter_12_cn_评审技术
![《软件工程-实践者的研究方法》chapter_12_cn_评审技术](https://img.taocdn.com/s3/m/6d9e4a36a98271fe910ef9f6.png)
ppt课件Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S.
Pressman & Associates, Inc., copyright © 1996, 2001, 2005Software Engineering: A Practitioner’s Approach,
6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 199员领导,并面向技术人员的一个会议 在软件工程过程中,对一个工作产品的技术评估 一种软件质量保证机制 一个培训园地
4
What Do We Look For?
Errors and defects
Error—a quality problem found before the software is released to end users
Defect—a quality problem found only after the software has been released to end-users
ppt课件Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S.
Pressman & Associates, Inc., copyright © 1996, 2001, 2005Software Engineering: A Practitioner’s Approach,
软件工程实践者的研究方法 (8)PPT课件
![软件工程实践者的研究方法 (8)PPT课件](https://img.taocdn.com/s3/m/20698258700abb68a882fb15.png)
Chapter 9
Architectural Design
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. PLeabharlann essman1第一部分
整体概述
THE FIRST PART OF THE OVERALL OVERVIEW, PLEASE SUMMARIZE THE CONTENT
to establish a conceptual framework and vocabulary for use during the design of software architecture,
to provide detailed guidelines for representing an architectural description
A set of architectural archetypes(原型) should be identified
An archetype is an abstraction (similar to a class) that represents one element of system behavior
3
What Is Architecture?
The software architecture of a program or system is the structure of the system, which comprise software components, the external visible properties of those components, and the relationships among them.
Architectural Design
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. PLeabharlann essman1第一部分
整体概述
THE FIRST PART OF THE OVERALL OVERVIEW, PLEASE SUMMARIZE THE CONTENT
to establish a conceptual framework and vocabulary for use during the design of software architecture,
to provide detailed guidelines for representing an architectural description
A set of architectural archetypes(原型) should be identified
An archetype is an abstraction (similar to a class) that represents one element of system behavior
3
What Is Architecture?
The software architecture of a program or system is the structure of the system, which comprise software components, the external visible properties of those components, and the relationships among them.
软件工程——实践者的研究方法
![软件工程——实践者的研究方法](https://img.taocdn.com/s3/m/c4f1cbfdfab069dc502201a3.png)
·到底什么是计算机软件?
·为什么我们不断努力要建造高质量的基于计算机的系统?
·我们如何对计算机软件的应用领域分类?
·关于软件仍存在什么样的神话?
·什么是软件过程?
·是否存在一般性的方法评价一个过程的质量?
·软件开发中可以应用什么过程模型?
·线性过程和迭代过程有何区别?
·它们的优点和缺点是什么?
·在软件工程中可以建议什么更高级的过程模型?
本书的第4版试图成为正逐步走向成熟的软件工程学科的一个指南。和前面三版一样,第4版的主要读者群仍然是学生和实践者,而且在写作风格上我们力图仍然保持前面各版的格式和风格。本书的基本目标仍然是:作为产业界专业人员的指南以及作为高年级大学生和一年级研究生的软件工程的全面导论。
我们在第4版中并不仅仅简单地修订了原稿,为适应本领域快速的增长我们完全重新组织了书中的内容,并着重讨论了新的重要的软件工程方法,还全面地修订了从早期版本保留的章节,加入了12章新内容,以提供对当代趋势和技术的完整讨论。加入了很多新例子、思考题,每一章中还增补了推荐阅读文献及其他信息搜索地址,包括数百个新的出版站点以及超过160个WWW信息站地。
译者序
20世纪末发生在我们这个星球上的最大变化之一无疑是席卷全球的信息技术(IT)革命,人们将这场革命视为21世纪——知识经济时代的前奏曲。在这场IT革命中,软件无疑扮演了极其重要的角色。软件产业作为一个独立形态的产业,正在全球经济中占据越来越举足轻重的地位。而软件工程正是软件产业健康发展的关键技术之一。
但是,在本书的早期版本中很多讨论的问题仍然存在,很多个人和公司仍然在随意地开发软件,很多专业人员和学生不知道现代方法,最终,我们生产的软件仍然存在大量质量问题。此外,关于软件工程方法的真实性质的争论仍在继续。然而,今天软件工程已成为研究的热点,人们对它的态度已有很大变化,它的发展也很明显,但是,要使软件工程最终发展成为一个完全成熟的学科还需sman博士主要从事的是航空航天应用中高级工程和制造的CAD/CAM系统的开发,他也从事科学及系统程序设计方面的工作。
·为什么我们不断努力要建造高质量的基于计算机的系统?
·我们如何对计算机软件的应用领域分类?
·关于软件仍存在什么样的神话?
·什么是软件过程?
·是否存在一般性的方法评价一个过程的质量?
·软件开发中可以应用什么过程模型?
·线性过程和迭代过程有何区别?
·它们的优点和缺点是什么?
·在软件工程中可以建议什么更高级的过程模型?
本书的第4版试图成为正逐步走向成熟的软件工程学科的一个指南。和前面三版一样,第4版的主要读者群仍然是学生和实践者,而且在写作风格上我们力图仍然保持前面各版的格式和风格。本书的基本目标仍然是:作为产业界专业人员的指南以及作为高年级大学生和一年级研究生的软件工程的全面导论。
我们在第4版中并不仅仅简单地修订了原稿,为适应本领域快速的增长我们完全重新组织了书中的内容,并着重讨论了新的重要的软件工程方法,还全面地修订了从早期版本保留的章节,加入了12章新内容,以提供对当代趋势和技术的完整讨论。加入了很多新例子、思考题,每一章中还增补了推荐阅读文献及其他信息搜索地址,包括数百个新的出版站点以及超过160个WWW信息站地。
译者序
20世纪末发生在我们这个星球上的最大变化之一无疑是席卷全球的信息技术(IT)革命,人们将这场革命视为21世纪——知识经济时代的前奏曲。在这场IT革命中,软件无疑扮演了极其重要的角色。软件产业作为一个独立形态的产业,正在全球经济中占据越来越举足轻重的地位。而软件工程正是软件产业健康发展的关键技术之一。
但是,在本书的早期版本中很多讨论的问题仍然存在,很多个人和公司仍然在随意地开发软件,很多专业人员和学生不知道现代方法,最终,我们生产的软件仍然存在大量质量问题。此外,关于软件工程方法的真实性质的争论仍在继续。然而,今天软件工程已成为研究的热点,人们对它的态度已有很大变化,它的发展也很明显,但是,要使软件工程最终发展成为一个完全成熟的学科还需sman博士主要从事的是航空航天应用中高级工程和制造的CAD/CAM系统的开发,他也从事科学及系统程序设计方面的工作。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
❖在开始估算之前,首先要对范围陈述中 描述的功能进行评估,在某些情况下,还 要进行细化,以提供更多的细节。由于成 本和进度的估算都是面向功能的,因此某 种程度上的功能分解常常是有用的。性能 方面的考虑包括处理时间和响应时间的需 求。约束条件则标识了外部硬件、可用存 储,或其他现有系统对软件的限制。
软件范围和可行性
对估算的观察
❖估算的风险取决于对资源、成本及进 度的定量估算中存在的不确定性。如 果对项目范围不太了解,或者项目需 求经常改变,不确定性和估算风险就 会非常高。计划人员,尤其是客户, 都应该认识到经常改变软件需求意味 着在成本和进度上的不稳定性。
项目策划过程
❖软件项目策划的目标是提供一个能使管理 人员对资源、成本及进度做出合理估算的 框架。此外,估算应该尝试定义“最好的 情况”和“最坏的情况”,使项目的结果 能够限制在一定范围内。项目计划是在计 划任务中创建的,尽管它具有与生俱来的 不确定性,软件团队还是要根据它着手开 发。因此,随着项目的进展,必须不断地 对计划进行调整和更新。
估算
❖ 如果有经验并遵循系统化的方法,使用 可靠的历史数据进行估算,利用至少两种 不同的方法创建估算数据点,制定现实的 进度表并随着项目的进展不断进行调整, 则可以确信已经为项目做了最好的估算。
估算
❖软件项目管理从一组统称为项目策划的活 动开始。在项目可以开始前,项目经理和 软件团队必须估算将要完成的工作、所需 的资源,以及从开始到完成所需要的时间。 这些活动一旦完成,软件团队就要制定项 目进度计划。在项目进度计划中,要定义 软件工程任务及里程碑,确定每一项任务 的负责人,详细指明对项目进展影响很大 的任务间的相互依赖关系。
估算
❖软件项目经理——利用从共利益者和软件工程 师那里获得的信息以及从以往项目收集的软件度 量数据。 ❖估算首先要描述产品的范围。然后,将问题分 解为一组较小的问题,再以历史数据和经验为指 南,对每个小问题进行估算。在进行最终的估算 之前,要考虑问题的复杂度和风险。 ❖工作产品是生成一个简单的表,描述要完成的 任务、要实现的功能,以及完成每一项所需的成 本、工作量和时间。
❖一旦确定了软件范围,人们自然会问: 我们能够开发出满足范围要求的软件吗? 这个项目可行吗?软件工程师常常匆忙越 过这些问题,不料竟会一开始就注定要陷 入这个项目的泥潭中。
资源
❖项目策划的第二个任务是对完成软件开发工 作所需的资源进行估算。图20-1描述了三类 主要的软件工程资源——人员、可复用的软 件构件及开发环境。对每一类资源,都要说 明以下四个特征:资源的描述、可用性说明、 何时需要资源、使用资源的持续时间。最后 两个特性可以看成是时间窗口。对于一个特 定的时间窗口,必须在开发初期就建立资源 的可用性。
可复用软件资源
❖基于构件的软件工程强调可复用性,即创 建并复用软件构造块,这种构造块通常被 称为构件。为了容易引用,必须对这些构 件进行分类;为了容易应用,必须使这些 构件标准化;为了容易集成,必须对这些 构件进行确认。
可复用软件资源
❖[BEN92]建议在制定计划时应该考虑以 下四种软件资源。
软件工程
第20章 软件项目估算
主要内容
❖对估算的观察 ❖项目策划过程 ❖软件范围和可行性 ❖资源 ❖软件项目估算 ❖分解技术 ❖经验估算模型 共利益者们都 已就绪;软件工程师准备开始;项目将要 启动。但是如何进行下去呢?软件项目计 划包括五项主要活动——估算、进度安排、 风险分析、质量管理计划和变更管理计划。 本章考虑估算——尝试确定构造一个特定 的基于软件的系统或产品所需要花费的资 金、工作量、资源及时间。
估算
❖很多技术工作者宁愿从事技术工作,而不愿花 费时间制定计划。很多技术管理者没有接受过充 分的技术管理方面的培训,对他们的计划能够改 善项目成果缺乏信心。这两部分人都不想制定计 划,因此就经常不制定计划。 ❖但是没有很好地制定计划是一个项目犯的最严 重的错误之一……有效的计划是必需的,可以在 上游以较低的成本解决问题,而不是在下游以较 高成本解决问题。一般的项目要将80%的时间 花费在返工上——改正在项目早期所犯的错误。
软件范围和可行性
❖软件范围描述了将要交付给最终用户的功 能和特性、输入和输出的数据、使用软件 时要呈现给用户的“内容”,以及界定系 统的性能、约束条件、接口和可靠性。定 义范围可以使用两种方法: 1、在与所有共利益者交流之后,写出对 软件范围的叙述性描述。 2、由最终用户开发一组用例。
软件范围和可行性
资源
图20-1 项目资源
人力资源
❖计划人员首先评估软件范围,并选择完成开 发所需的技能,还要指定组织中的职位和专 业。对于一些比较小的项目,只要向专家做 些咨询,也许一个人就可以完成所有的软件 工程任务。而对于一些较大的项目,软件团 队的成员可能分散在很多不同的地方,因此, 要详细说明每个人所处的位置。 ❖只有在估算出开发工作量后,才能确定软件 项目需要的人员数量。
对估算的观察
❖对软件工程工作的资源、成本及进度进行估算 时,需要经验,需要了解有用的历史信息,还要 有当只存在定性的信息时进行定量预言的勇气。 估算具有与生俱来的风险,正是这种风险导致了 不确定性。 ❖历史信息的有效性对估算的风险有很大影响。 通过回顾过去,能够仿效做过的工作,并改进出 现问题的地方。如果能取得对以往项目的全面的 软件度量,做估算就会有更大的保证,合理安排 进度以避免重走过去的弯路,总体风险也会降低。
对估算的观察
❖估算是一门艺术,更是一门科学,这项重要 的活动不能以随意的方式来进行。现在已经 有了估算时间和工作量的实用技术。过程度 量和项目度量为定量估算从历史角度提供了 依据和有效的输入。当建立估算和评审估算 时,过去经验的辅助作用是不可估量的。由 于估算是所有其他项目策划活动的基础,而 且项目计划又提供了通往成功的软件工程的 路线图。因此,没有估算就着手开发,将陷 入盲目性。
软件范围和可行性
对估算的观察
❖估算的风险取决于对资源、成本及进 度的定量估算中存在的不确定性。如 果对项目范围不太了解,或者项目需 求经常改变,不确定性和估算风险就 会非常高。计划人员,尤其是客户, 都应该认识到经常改变软件需求意味 着在成本和进度上的不稳定性。
项目策划过程
❖软件项目策划的目标是提供一个能使管理 人员对资源、成本及进度做出合理估算的 框架。此外,估算应该尝试定义“最好的 情况”和“最坏的情况”,使项目的结果 能够限制在一定范围内。项目计划是在计 划任务中创建的,尽管它具有与生俱来的 不确定性,软件团队还是要根据它着手开 发。因此,随着项目的进展,必须不断地 对计划进行调整和更新。
估算
❖ 如果有经验并遵循系统化的方法,使用 可靠的历史数据进行估算,利用至少两种 不同的方法创建估算数据点,制定现实的 进度表并随着项目的进展不断进行调整, 则可以确信已经为项目做了最好的估算。
估算
❖软件项目管理从一组统称为项目策划的活 动开始。在项目可以开始前,项目经理和 软件团队必须估算将要完成的工作、所需 的资源,以及从开始到完成所需要的时间。 这些活动一旦完成,软件团队就要制定项 目进度计划。在项目进度计划中,要定义 软件工程任务及里程碑,确定每一项任务 的负责人,详细指明对项目进展影响很大 的任务间的相互依赖关系。
估算
❖软件项目经理——利用从共利益者和软件工程 师那里获得的信息以及从以往项目收集的软件度 量数据。 ❖估算首先要描述产品的范围。然后,将问题分 解为一组较小的问题,再以历史数据和经验为指 南,对每个小问题进行估算。在进行最终的估算 之前,要考虑问题的复杂度和风险。 ❖工作产品是生成一个简单的表,描述要完成的 任务、要实现的功能,以及完成每一项所需的成 本、工作量和时间。
❖一旦确定了软件范围,人们自然会问: 我们能够开发出满足范围要求的软件吗? 这个项目可行吗?软件工程师常常匆忙越 过这些问题,不料竟会一开始就注定要陷 入这个项目的泥潭中。
资源
❖项目策划的第二个任务是对完成软件开发工 作所需的资源进行估算。图20-1描述了三类 主要的软件工程资源——人员、可复用的软 件构件及开发环境。对每一类资源,都要说 明以下四个特征:资源的描述、可用性说明、 何时需要资源、使用资源的持续时间。最后 两个特性可以看成是时间窗口。对于一个特 定的时间窗口,必须在开发初期就建立资源 的可用性。
可复用软件资源
❖基于构件的软件工程强调可复用性,即创 建并复用软件构造块,这种构造块通常被 称为构件。为了容易引用,必须对这些构 件进行分类;为了容易应用,必须使这些 构件标准化;为了容易集成,必须对这些 构件进行确认。
可复用软件资源
❖[BEN92]建议在制定计划时应该考虑以 下四种软件资源。
软件工程
第20章 软件项目估算
主要内容
❖对估算的观察 ❖项目策划过程 ❖软件范围和可行性 ❖资源 ❖软件项目估算 ❖分解技术 ❖经验估算模型 共利益者们都 已就绪;软件工程师准备开始;项目将要 启动。但是如何进行下去呢?软件项目计 划包括五项主要活动——估算、进度安排、 风险分析、质量管理计划和变更管理计划。 本章考虑估算——尝试确定构造一个特定 的基于软件的系统或产品所需要花费的资 金、工作量、资源及时间。
估算
❖很多技术工作者宁愿从事技术工作,而不愿花 费时间制定计划。很多技术管理者没有接受过充 分的技术管理方面的培训,对他们的计划能够改 善项目成果缺乏信心。这两部分人都不想制定计 划,因此就经常不制定计划。 ❖但是没有很好地制定计划是一个项目犯的最严 重的错误之一……有效的计划是必需的,可以在 上游以较低的成本解决问题,而不是在下游以较 高成本解决问题。一般的项目要将80%的时间 花费在返工上——改正在项目早期所犯的错误。
软件范围和可行性
❖软件范围描述了将要交付给最终用户的功 能和特性、输入和输出的数据、使用软件 时要呈现给用户的“内容”,以及界定系 统的性能、约束条件、接口和可靠性。定 义范围可以使用两种方法: 1、在与所有共利益者交流之后,写出对 软件范围的叙述性描述。 2、由最终用户开发一组用例。
软件范围和可行性
资源
图20-1 项目资源
人力资源
❖计划人员首先评估软件范围,并选择完成开 发所需的技能,还要指定组织中的职位和专 业。对于一些比较小的项目,只要向专家做 些咨询,也许一个人就可以完成所有的软件 工程任务。而对于一些较大的项目,软件团 队的成员可能分散在很多不同的地方,因此, 要详细说明每个人所处的位置。 ❖只有在估算出开发工作量后,才能确定软件 项目需要的人员数量。
对估算的观察
❖对软件工程工作的资源、成本及进度进行估算 时,需要经验,需要了解有用的历史信息,还要 有当只存在定性的信息时进行定量预言的勇气。 估算具有与生俱来的风险,正是这种风险导致了 不确定性。 ❖历史信息的有效性对估算的风险有很大影响。 通过回顾过去,能够仿效做过的工作,并改进出 现问题的地方。如果能取得对以往项目的全面的 软件度量,做估算就会有更大的保证,合理安排 进度以避免重走过去的弯路,总体风险也会降低。
对估算的观察
❖估算是一门艺术,更是一门科学,这项重要 的活动不能以随意的方式来进行。现在已经 有了估算时间和工作量的实用技术。过程度 量和项目度量为定量估算从历史角度提供了 依据和有效的输入。当建立估算和评审估算 时,过去经验的辅助作用是不可估量的。由 于估算是所有其他项目策划活动的基础,而 且项目计划又提供了通往成功的软件工程的 路线图。因此,没有估算就着手开发,将陷 入盲目性。