软件项目管理教程
与依靠团队每个成员的能力、智慧与经验，放弃项目的微观管理，在某种意义上真正做到“你办事我放心”。
项目经理做决策前要听取大家的意见与建议，这不代表你没有意见与主见。如果你没有充足的理由否定其他成员的建议，那就不要马上否定。你最好的做法是：“聆听”、“信任”、“支持”、“总结”、“吸取”与“提高”。
当然你不能盲目地信任你的团队，你需要评估建议的合理性。本书除了讲清项目管理的原理与过程外，还重点讲解了如何做系统分析、软件的架构设计等，其目的就是让项目经理能掌握覆盖软件项目开发全过程的知识，以便做好项目的“指导”工作。
1.4.3复查与测试原则
从一般意义上看，复查是一件枯燥无新意的工作，并不是很多人愿意反复查看与研究自己“已经”搞定的事的。另外，复查也没有一个好的名声，好像是一批人戴着放大镜吹毛求疵地查找另一批人的缺点似的。因此，在项目管理的实际过程中往往需要某些人在项目的相关文档上签字，以此表示文档内容的正确与否性与签字人有关。
复查的目的不是为了形成一件完美无缺的产品，而是为了防止出现不必要的错误，因为从纸张上发现错误总要比用软件测试容易和便宜得多；同时也是项目利益人（包括开发人员）给项目经理的一个可靠的信息，一个可信的承诺，项目经理以此可作出种种的项目决策。
复查是静态的，测试可视作为动态的。静态时的人，状态甚好，往往思维缜密，目标、条理与逻辑性都比较强，可找出文档中的许多不当之处，真可用成语“安心定志”与“心静神怡”来形容。测试是复查的一种动态抽样证明，关键是需要做好测试计划，使得测试既具有典型性、代表性，又具有全面性。
1.4.4平等原则
做软件项目不仅仅是写代码，在软件项目的整个开发周期中会产生各种各样的产品，例如：文档、进度表、计划、源代码、错误报告等，它们分别是由项目团队中的不同成员制造出来的，我们绝对不能说某个产品比其它产品重要，因为只要某件产品中存在缺陷，就会影响最终软件产品的正确性与质量，这也就意味着项目团队成员之间只有分工的不同，没有重要性的不同。
对许多项目经理来说，当程序员与测试员有意见分歧时，项目经理往往倾向于信任程序员；当系统分析师与程序员有意见分歧时，项目经理又会倾向于信任系统分析师。这可不是一个好的习惯，会导致一个项目团队进入一个人与人之间不相平等的境地。
客观地对待项目组成员在项目开发中的各类建议是制造一个好软件产品的关键，项目组成员在项目决策中应有平等的发言权与地位。
1.4.5正确地做事原则
众所周知，软件项目的开发需要分若干个阶段来进行，一开始就要正确地做项目，要比以后发现问题，纠正问题要好得多得多。
11
软件项目管理教程
第2章 软件项目开发流程
2.1 开发流程简介
2.1.1需求分析
1．相关系统分析员初步了解用户需求，用WORD写出要开发的系统的主要功能模块，每个功能模块有哪些小功能模块。具体来讲，要做以下一些事：
（1）听取用户的项目介绍；
（2）明白用户的主要需求（用户想干什么，他们的目的是什么）；
（3）收集用户的主要表格（统计与分析表）与表单（往往是今后的软件系统的原始数据的输入界面）；
（4）逐一理解用户的表格与表单（各数据项目的含义）； （5）把你的理解写成WORD文档； （6）初步定义相关的用户操作界面；
（7）把上述的WORD文档提交给用户确认；
（8）重复上述过程，直至你和用户均认为理解了用户的需求。
这一步的特点是：
（1）按用户的思路分析问题； （2）理解用户的需求为唯一目的；
（3）不要加以归纳、总结、抽象与提高。
2．系统分析员深入了解和分析需求，根据自己的经验写出一份详细的需求文档。文档越详细，界面越多越好。
这一步的特点是：
（1）融入了开发方的经验与建议（包括工作流程的定义、表单格式的定义、报表格式的定义等）；
（2）尽一切可能让用户理解与接受这一版的系统需求分析说明书，需要用户方的项目负责人签字确认。该版系统分析说明书具有一定的法律效力，可作为软件开发合同的附件。
2.1.2概要设计
概要设计是面向用户的设计，是用户能看得懂的设计。主要针对下列几个方面进行设计：
（1）软件系统的一层、二层操作界面（点击主界面上的某些菜单显示出二层操作界面。这部分工作可由美工完成）；
（2）功能菜单的布局设计；
12
软件项目管理教程
（3）主要功能的输入界面设计（表单格式设计）； （4）主要报表的输出界面（浏览与打印格式）设计； （5）软件系统的基本处理流程（数据流程）设计； （6）用户的组织结构设计； （7）子系统间的接口设计。
概要设计的要点有下列几条： （1）简洁性；
（2）可视化性。最好能进行软件系统的原型演示； （3）功能全面性。否则用户会提出异议；
2.1.3详细设计
详细设计是面向程序员的设计，是指导与规范程序员的代码编制行为的设计。设计工作主要有下列几个方面：
（1）功能模块划分设计，或叫做软件分解结构（PBS）设计； （2）模块的主要算法（流程图）、接口（入口参数、出口参数，甚至需要指定入出口参数的名称）设计；
（3）页面布局设计（包括页面上所有按钮的功能、点击流程、位置布局等的设计）； （4）数据结构设计（数据库中所有表文件，及各表文件中各字段的代码、类型与宽度等的设计）。
详细设计的目标是：可按功能模块下发软件开发任务，使每个任务均能放心地让程序员去实现，使得程序员在编码阶段没有太大的自由度。
详细设计也许会扼杀某些程序员的聪明才智，但我们赞成这样的口号，叫做“步调一致才能得胜利”。
本阶段的里程牌是《软件系统详细设计说明书》。
2.1.4编码
开发者根据《软件系统详细设计说明书》中对数据结构、算法和模块实现等方面的设计要求，开始编写程序，分别实现各模块的功能，从而实现目标系统的功能。
程序员完成各自的功能模块，对各自的模块质量负责，为系统联调作好准备。
2.1.5测试
本步骤的目的是测试程序员已编写好的模块，先进行模块测试，然后逐步进行模块与模块之间的系统联调。为了做好测试，测试人员需要依据《系统分析说明书》、《软件系统详细设计说明书》来预先编制一本测试计划（非常详细的测试报告，含有测试用例）。
13
软件项目管理教程
这一步骤的里程碑是：《测试报告》与可交付给用户测试的软件系统。 用户需要独立地进行“用户接收性测试”，用户在这一过程中完成软件系统中各功能的确认（初次验收）。
2.1.6系统交付
软件测试达到用户的要求后，软件系统开发者应向用户提交开发的安装程序、数据字典、《系统安装手册》、《用户使用指南》、《需求分析报告》、《设计报告》、《测试报告》等双方合同约定的产品。
《系统安装手册》应详细介绍安装软件对运行环境的要求、安装软件的定义和内容、在客户端、服务器端及中间件的具体安装步骤、安装后的系统配置等。
作为项目性开发，系统安装由开发方完成；对于软件产品，系统安装由用户自行完成。 《用户使用指南》应包括软件各项功能的使用流程、操作步骤、相应业务介绍、特殊提示和注意事项等方面的内容，在需要时还应举例说明。 用户使用手册或指南编写的目标是让用户能依据手册学会软件系统的使用。
2.1.7项目验收
用户验收。
目标：用户或客户方的相关领导在验收书上签字。 验收手段：一般是开验收会议。
2.2 项目准备与启动
2.2.1 项目建议书
项目建议书 (project proposal )，就是项目立项申请报告。它可以比较简要，也可以比较详尽，而重点是如何向有关的投资方或上级阐述立项的必要性
项目建议书的常规内容有： ? 项目的背景
? 项目的意义和必要性
? 项目产品或服务的市场预测 ? 项目规模和期限
? 项目建设必需的条件、已具备和尚不具备的条件分析 ? 投资估算和资金筹措的设想 ? 市场前景及经济效益初步分析 ? 其它需要说明的情况
14
软件项目管理教程
2.2.2 项目可行性分析
一、可行性分析前提
? 当前业务流程分析 ? 主要功能点需求分析 ? 系统的非功能需求分析
? 性能需求 ? 环境需求 ? 安全需求
? 一些限制条件的分析
? 经费来源和使用限制 ? 开发时间限制
? 项目资源需求的优先顺序
二、可行性分析因素
外加一个大类“社会效益分析”。
三、可行性分析流程
15