1、2003.01.10,SOFTWARE ENGINEERING,授课安排,系统工程 软件项目计划 软件需求分析 软件设计 编程 软件测试 软件维护 面向对象方法、软件复用和构件技术等,2003.01.10,SOFTWARE ENGINEERING,软件项目管理,软件工程管理是对软件项目的开发管理，是对整个软件生存期的所有活动进行管理。任何工程的成败，都与管理的好坏密切相关，软件工程更不例外。尤其是软件产品的特殊性，软件工程的管理对于保证软件产品的质量也具有极为重要的作用。 任何技术先进的大型项目的开发如果没有一套科学的管理方法和严格的组织领导，是不可能取得成功的 。,2003.01.10,SO
2、FTWARE ENGINEERING,软件项目管理,4P：人员(People)、产品(product)、过程(Process)和项目(Rroject)。 将人员组织起来以有效地完成工作； 和客户及其他共利益者很好地沟通，以便了解产品的目标和范围，方案和限制等； 选择合适于人员和产品的过程； 估算工作量和工作时间，制定项目计划，包括：定义工作产品，建立质量检查点以及确定一些机制以监控计划所规定的工作。,2003.01.10,SOFTWARE ENGINEERING,软件项目管理,要让软件项目失败很容易，只要符合下列条件之一即可： （1）项目经理对软件一无所知； （2）技术负责人对编程不感兴趣；
3、（3）真正编写代码的程序员是临时雇用的。 如果上述三个条件同时具备，就请放心失败好了。 让我们少幻想自己是比尔盖茨，先当好程序员和程序经理再说。,2003.01.10,SOFTWARE ENGINEERING,The Definition Phase,SystemEngineering,Softwareproject planning,Softwarerequirementsanalysis,Software scope,Refined,2003.01.10,SOFTWARE ENGINEERING,Software Project Planning 软件项目计划,软件项目计划包括五项主要活动
4、：估算、进度安排、风险分析、质量管理计划和变更管理计划。 很多技术人员宁愿从事技术工作，而不愿花费时间制定计划。很多管理者也对计划的效果没有信心，所以很多软件项目就经常不制定计划。,2003.01.10,SOFTWARE ENGINEERING,Software Project Planning 软件项目计划,在可行性分析之后，项目计划与质量管理将贯穿需求分析、系统设计、程序设计、测试、维护等软件工程环节。 项目计划是要提供一份合理的进程表，让所有开发人员任务明确、步调一致，最终共同准时地完成项目。项目计划是要付诸实施的，不象喊政治口号。软件的项目计划重在“准确”而非“快速”。,2003.01
5、.10,SOFTWARE ENGINEERING,Software Project Planning 软件项目计划,在做软件的项目计划时，应屏弃一切浮夸作风。只有“知已知彼”才能做出合理的项目计划。这里“知彼”是指要了解项目的规模、难度与时间限制。“知已”是指要了解有多少可用资源，如可调用的软件人员有几个？他们的水平如何？软硬件设施如何？等,2003.01.10,SOFTWARE ENGINEERING,软件项目计划,如有进行系统定义，则“系统规格说明书”的功能描述和约束所有有关软件的信息几乎都是可用的，否则计划人员必须起系统分析员的作用。,确定软件的作用范围 资源需求估计 工作量和成本估计
6、进度安排(里程碑),系统规格 说明书,=软件计划,不确定性,2003.01.10,SOFTWARE ENGINEERING,Software Scope（范围）,The first activity in software project planning is the determination of software scope.Function and perform-ance allocated to software during system engineering should be assessed to establish a project scope that is un
7、ambiguous and understandable at management and technical levels.,2003.01.10,SOFTWARE ENGINEERING,Software Scope,Software scope describes function, performance,constraints,interfaces,and reliability. Functions described in the statement of scope are evaluated and in some cases refined to provide more
8、 detail prior to the beginning of estimation.Because both cost and schedule estimates are functionally oriented,some degree of decomposition is often useful.,2003.01.10,SOFTWARE ENGINEERING,Software Scope,The most commonly used technique to bridge the communication gap between the customer and devel
9、oper and to get the communication process started is to conduct a preliminary meeting or interview. The analyst start by asking “context free questions.”,2003.01.10,SOFTWARE ENGINEERING,Project Planning Objectives,The objective of software project planning is to provide a framework that enables the
10、manager to make reasonable estimates of resources,cast, and schedule.These estimates are made within a limited time frame at the beginning of a software project and should be updated regularly as the project progresses. In addition, estimates should attempt to define “best case” and “worst case” sce
11、narios so that project outcomes can be bounded.,2003.01.10,SOFTWARE ENGINEERING,Software Project Planning,The software project planner must estimate three things before a project begin:how long it will take,how much effort will be required, and how many people will be involved.In addition,the planne
12、r must predict the resources (software and hardware) that will be required and the risk involved.,2003.01.10,SOFTWARE ENGINEERING,Estimating（估算）,The estimating is as much art as it is science. A leading executive was once asked what single characteristic was most important when selecting a project m
13、anager.His response: “a person with the ability to know what will go wrong before it actually does.”We might add: “and the courage to estimate when the future is cloudy.”,2003.01.10,SOFTWARE ENGINEERING,Estimating,Estimation of resources,cost,and schedule for a software development effort requires e
14、xperience,access to good historical information,and the courage to commit to quantitative measures when qualitative data are all that exist.,2003.01.10,SOFTWARE ENGINEERING,Estimating Risk（风险）,Project complexity Project size The degree of structural uncertainty The availability of historical informa
15、tionIf project scope is poorly understood or project requirements are subject to change,uncertainty and risk become dangerously high.,2003.01.10,SOFTWARE ENGINEERING,Software Project Estimation,In the early days of computing,software costs comprised a small percentage of overall computer-based syste
16、m cost.An order of magnitude error in estimates of software cost had relatively little impact. Software cost and effort estimation will never be an exact science.,2003.01.10,SOFTWARE ENGINEERING,Software Project Estimation,To achieve reliable cost and effort estimates, a number of options arise: Del
17、ay estimation until late in the project. Base estimates on similar projects that have already been completed. Use relatively simple “decomposition techniques” to generate project cost and effort estimates. Use one or more empirical models for software cost and effort estimation.,2003.01.10,SOFTWARE
18、ENGINEERING,(Estimate of) Resources,The second task of software planning is estimation of resources required to accomplish the software development effort. Each resource is specified with four characteristics:description of the resource, a statement of availability, chronological time that the resou
19、rce will be required,and dur-ation of time that the resource will be applied.,2003.01.10,SOFTWARE ENGINEERING,Resources（资源）,Hardware&Software Tools,Reusable Software Components,People,可复用的软构件,软件工程环境,2003.01.10,SOFTWARE ENGINEERING,Resources-People,2003.01.10,SOFTWARE ENGINEERING,Resources-People,人是最
20、有价值的资源。项目计划的制定者要确定开发人员的名单，要根据他们的专长进行分工。 工作在第一线的软件开发人员是程序员和程序经理，他们决定着软件的命运。良好的程序员队伍和出色的管理是软件项目成功的必要条件。,2003.01.10,SOFTWARE ENGINEERING,软件开发组织,开发小组的组织有以下原则： 软件开发小组的规模不宜太大，人数不能太多，一般3-5人左右为宜。 切忌在开发过程中增加人员，这将因增加人员之间的联系而降低效率。 常见的三种组织形式：主程序员组、民主制小组、层次式小组,2003.01.10,SOFTWARE ENGINEERING,软件项目小组主程序员组,主程序员,后援,
21、技术人员 （2至5人）,专家 （1至多人）,支持人员 （1至多人）,资料员1人,支持或取代主程序员,2003.01.10,SOFTWARE ENGINEERING,软件项目小组主程序员,主程序员是指一支软件开发队伍的领导者，不管他的职务是开发组长，项目经理，还是部门经理。主程序员是技术性的基层或中层干部，是软件企业得以发展的生力军。 好的主程序员至少应具备以下几个条件： 技术水平是程序员队伍中的最高级别 能做最多且最难的工作 有人格魅力等,2003.01.10,SOFTWARE ENGINEERING,软件项目小组现代程序员组,2003.01.10,SOFTWARE ENGINEERING,R
22、esources (Reusable software components),软构件并非一定要用自己的，可以向专业的软件供应商购买。 为了促成软件的复用，以提高软件的生产率和软件产品的质量，应建立可复用的软件部件库。对于软件的复用，人们经常忽略，但这却是相当重要的一环。,2003.01.10,SOFTWARE ENGINEERING,Resources (Reusable software components),Bennatan suggests four software resource categories that should be considered as planning
23、proceeds: Off-the-shelf components Full-experience components Partial-experience components New components,2003.01.10,SOFTWARE ENGINEERING,Environmental Resources,The environment that supports the software project,often called a software engineering environment(SEE), incorporates software and hardwa
24、re. A project planner must prescribe the time window required for software and hardware and verify that these resources will be available.,2003.01.10,SOFTWARE ENGINEERING,Environmental Resources,软硬件（开发、运行）环境虽然不是最重要的资源，却是必需的资源。原则上软硬件环境只要符合项目的开发要求即可。有些项目可能要用到特殊的设备，则要事先作好准备，以免用时找不到而担搁了开发进程。,2003.01.10,
25、SOFTWARE ENGINEERING,Cost and Effort Estimation,成本估算是软件可行性分析的重要依据，也是软件管理的重要内容，直接影响到软件开发的风险。 软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价，即主要是人的劳动的消耗。因此，软件产品开发成本的计算方法不同于其他物理产品的成本的计算。,2003.01.10,SOFTWARE ENGINEERING,Cost and Effort Estimation,软件产品不存在重复制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此软件成本估算，应以软件计划、需求分析、设计、编码到测试的软件开
26、发全过程所花费的代价为依据。 对于大型软件项目来说，由于项目的复杂性，成本估算并不单纯是一个计算过程，还需要进行一系列的估算处理，处理手段主要是分解和类比。,2003.01.10,SOFTWARE ENGINEERING,Cost and Effort Estimation,自顶向下和自底向上的估算 专家估算、类推估算、算式估算 LOC(Line Of Code)-Based Estimation FP(Function Points)-Based Estimation Process-Based Estimation Empirical Estimation Model Automated
27、Estimation Tools,2003.01.10,SOFTWARE ENGINEERING,Cost and Effort Estimation,软件成本估算通常是对以下量进行估算 源代码行（LOC）：是指机器指令行/非机器语言的执行步 开发工作量：常用的单位是：人-月（PM）、人-年（PY）、人-日（PD） 软件生产率：单位劳动量所能完成的软件数量，LOC/PM、￥/LOC、￥/PM 软件开发时间,2003.01.10,SOFTWARE ENGINEERING,Estimation-代码行技术,估计出有多少行的代码(code)，再乘以每行的开发成本(cost)和复杂度(complexi
28、ty)，即可估算出开发成本。有时对代码行的估计有一定的难度（利用专家估算等）。,2003.01.10,SOFTWARE ENGINEERING,Estimation-任务分解技术,把软件开发工程分解成若干个相对独立的任务，再分别估计每个任务的开发成本，最后累加起来就是总成本（人/年）估计工作量 。一般可按阶段划分任务，再按阶段把每个阶段划分成更小的任务。,可行性研究 5 需求分析 15 设计 20 编码和单元测试 40 综合测试 20,2003.01.10,SOFTWARE ENGINEERING,Estimation-自动估算,可以更快、更客观地估计成本。但需要有长期的经验积累、强大的数据库
29、(data base)、以及决策支持系统软件(decision support system)。,2003.01.10,SOFTWARE ENGINEERING,Cost and Effort Estimation 估算模型,Halstead估算模型 IBM估算模型 SLIM估算模型 PRICE-S估算模型 Putnam 估算模型 COCOMO估算模型 Balley-Basili估算模型 Schneider估算模型,2003.01.10,SOFTWARE ENGINEERING,Cost and Effort Estimation,Accurate project estimates gene
30、rally make use of at least two of the techniques noted above.By comparing and reconciling estimates derived using different techniques, the planner is more likely to derive an accurate estimate. Software project estimation can never be an exact science,but a combination of good historical data and s
31、ystematic techniques can improve estimation accuracy.,2003.01.10,SOFTWARE ENGINEERING,Software Project Scheduling 软件项目进度安排,Scheduling is the culmination of a planning activity that is a primary component of software management. When combined with estimation methods and risk analysis, scheduling esta
32、blishes a road map for the project manager.,2003.01.10,SOFTWARE ENGINEERING,Software Project Scheduling 软件项目进度安排,同意执行一个他本人都认为有缺点的计划的指挥官应该受到谴责。 过于乐观的进度安排并不会缩短实际进度，反而会拖后进度。 完成一个项目的时间与投入该项目的人员工作量之间是高度非线性的关系。 通过略为延长时间可以使用较少的人员实现同样的目标。,2003.01.10,SOFTWARE ENGINEERING,Software Project Scheduling 软件项目进度安排,
33、如果最乐观的估算都表明截止期限是不现实的，一个胜任的项目管理者就应该“保护其队伍免受不适当的进度安排的压力并将这种压力反映给施加压力的一方”。,2003.01.10,SOFTWARE ENGINEERING,Software Project Scheduling 软件项目进度安排,虽然软件延期交付的原因很多，但大多数都可追溯到下面列出的一或多个根本原因上： 一个不现实的截止期限，由软件开发组以外的某人所设立并强加给软件开发组内的管理者和项目开发者 客户需求发生变化，而需求的变化没有能够反映在项目进度的变化上 对工作量和/或完成该工作所需的资源数量估计不足,2003.01.10,SOFTWARE
34、 ENGINEERING,Software Project Scheduling 软件项目进度安排,在项目开始时，没有将可以预测的和/或不可预测的风险考虑在内 事先无法预计的技术困难 事先无法预计的人力困难 由于项目组成员之间的交流不畅而导致的延期 项目管理者未能发现进度拖后，也未能采取行动解决这一问题,2003.01.10,SOFTWARE ENGINEERING,Software Project Scheduling,两种进度：最后交付日期已经确定；有大致时限，但最后交付日期由软件机构指定。 有时进度安排的正确性比价格估算的正确性更为重要。 软件无法按时完成软件工程试图解决的一个主要问题（
35、提高估算、时间安排的准确性，加强项目管理等）。,2003.01.10,SOFTWARE ENGINEERING,Software Project Scheduling,项目落后于进度表乃是家常便饭，不必大惊小怪。以下一些事件经常会导致项目被延误： 上级领导主管臆断，制定了不现实的期限。项目经理与程序员们被迫按照不合理的进度表开展工作。 客户的需求发生了变化，但没有对进度表作出相应的修改。 低估了项目的规模与难度，导致投入的人力和物力不足。 并未预见到存在难以克服的技术障碍。 并未预见到开发人员会发生问题，如生病，辞职等。 开发人员之间不能很好的交流、协作，导致各阶段任务难以如期完成。,2003
36、.01.10,SOFTWARE ENGINEERING,Software Project Scheduling,Although there are many reasons why software is delivered late,most can be traced to one or more the following root causes: An unrealistic deadline Changing customer requirements An honest underestimate（低估） Predictable and/or unpredictable risk
37、s Technical difficulties Human difficulties Miscommunication among project staff,2003.01.10,SOFTWARE ENGINEERING,Software Project Scheduling,以下是对进度安排的一些有益的建议（一）： 制定进度表的人最好就是项目负责人，他最了解项目和开发人员。 进度表要经过开发小组的讨论，在得到大部数人的支持后才能实施。 进度安排并不见得一定要符合逻辑顺序。应尽可能地先做技术难度高的事，后做难度低的事。 开发一个大的软件项目，应该将进度表分为若干个里程碑。 进度表中必须留有
38、缓冲时间，并将缓冲时间用到不确定的事情上。,2003.01.10,SOFTWARE ENGINEERING,Software Project Scheduling,以下是对进度安排的一些有益的建议（二）： 如果发现项目应交付的期限非常不合理，就要跟领导或跟客户据理力争，请求放宽期限、调整进度。 当客户的需求发生变化时，就要对进度表作出相应的修正。不要觉得修改进度表很困难很麻烦，不修改才会产生真真的麻烦。很多人认为戒烟很困难，但马克吐温曾说：“戒烟很容易，我一年就戒几十次。”,2003.01.10,SOFTWARE ENGINEERING,Software Project Scheduling,
39、Like all other areas of software engineering, a number basic principles guide software project scheduling: Compartmentalization（划分） Interdependency（相关性） Time allocation Effort validation Define responsibilities（责任） Define outcomes（成果） Define milestones（里程碑）,2003.01.10,SOFTWARE ENGINEERING,An Unreali
40、stic Deadline,If best estimates indicate that the deadline is unrealistic,a competent project manager should “protect his or her team from undue schedule pressure and reflect the pressure back to its originators.”Using an incremental process model,2003.01.10,SOFTWARE ENGINEERING,The Relationship Bet
41、ween People and Effort,Although communication is absolutely essential to successful software development,every new communication path requires additional effort and therefore additional time.理想化的模型：说明通信的代价，进度落后的项目增加人基本无用,2003.01.10,SOFTWARE ENGINEERING,Effort Distribution,A recommended distribution
42、of effort across the definition and development phases is often referred to as the 40-20-40 rule (no in a strict sense).,2003.01.10,SOFTWARE ENGINEERING,Software Project Scheduling （实施步骤）,Defining a task set for the software project(取决于项目类型和严格程度) Selecting software engineering tasks Refinement of ma
43、jor tasks Defining a task network Scheduling,2003.01.10,SOFTWARE ENGINEERING,The Project Type,Concept development projects New application development projects Application enhancement projects Application maintenance projects Reengineering projects,2003.01.10,SOFTWARE ENGINEERING,Defining a task net
44、work,A task network is a graphic representation of the task flow for a project. Because parallel tasks occur asynchronously, the planner must determine intertask dependencies to ensure continuous progress toward completion.In addition,the project manager should be aware of those tasks that lie on th
45、e critical path.,2003.01.10,SOFTWARE ENGINEERING,Scheduling,Scheduling of a software project does not differ greatly from scheduling of any multi-task engineering effort.Therefore,generalized project scheduling tools and techniques can be applied to software with little modification. Program evaluat
46、ion and review technique (PERT)and critical path method(CPM) are two project scheduling methods that can be applied to software development.,2003.01.10,SOFTWARE ENGINEERING,Scheduling-甘特图（Gantt Chart）,优点：标明了各任务的计划进度和当前进度。能够动态反映软件开发的进展情况。 缺点：不能够反映多个任务之间的复杂逻辑关系。,2003.01.10,SOFTWARE ENGINEERING,Schedul
47、ing-PERT技术和CPM方法,2003.01.10,SOFTWARE ENGINEERING,Scheduling,Scheduling begins with process decomposi-tion.The characteristics of the project are used to adapt an appropriate task set for the work to be done. The task network is used to computer the critical project path,a timeline chart,and a variet
48、y of project information. Using the schedule as a guide, the project manager can track and control each step in the software engineering process.,2003.01.10,SOFTWARE ENGINEERING,风险分析和风险管理,风险分析和风险管理就是一系列步骤，用来帮助软件团队理解和管理不确定的事物。 时刻准备着-理解风险、采取主动的措施去回避或管理风险-是一个好的软件项目管理者应具备的基本条件。 被动风险策略-救火模式；主动风险策略：识别潜在的风
49、险，评估它们发生的概率及产生的影响，并按其重要性进行排序，然后软件项目团队就可以制定一个计划来管理风险。,2003.01.10,SOFTWARE ENGINEERING,风险分析和管理识别风险,软件风险及其分类 没有经理实际风险的项目不能认为是成功的。这种项目几乎是无益的，否则这些项目早就有人开发了。 风险识别：试图系统化地指出对项目计划（估算、进度、资源分配等）的威胁。 建立风险条目检查表,2003.01.10,SOFTWARE ENGINEERING,风险分析和管理风险预测,又称风险估计，试图从两个方面评估每一个风险：风险发生的可能性或概率；风险相关问题产生的后果。,2003.01.10,
50、SOFTWARE ENGINEERING,风险缓解、监测和管理,风险分析的目的就是辅助项目团队制定处理风险的策略：风险回避，风险监测，风险管理和应急计划。 风险管理策略可以包含在软件项目计划中，也可以将风险管理步骤组织成一个独立的风险缓解、监测和管理计划(RMMM计划)。,2003.01.10,SOFTWARE ENGINEERING,The Software Project Plan,Each step in the software engineering process should produce a work product that can be reviewed and that can act as a foundation for the steps that follow.The software project plan is produced at the culmination of the planning tasks.It provides baseline cost and scheduling information that will be used throughout the software engineering process.,
