软件项目管理（7）

 软件项目管理（7）

1、需求分析
1）也称为需求建模，是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述，并尽可能多地捕获现实世界的语义。
2）需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。
3）分析用户需求应执行下列活动：
（1）以图形表示的方式描述系统的整体结构，包括系统的边界与接口；
（2）通过原型、页面流或其它方式向用户提供可视化的界面，用户可以对需求做出自己的评价；
（3）以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。
4）需求分析的基本策略是采用头脑风暴、专家评审、焦点会议组等方式进行具体的流程细化、数据项的确认，必要时可以提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。
5）用户方可以通过审查业务流程报告、数据项表，以及操作开发方提供的原型系统，来提出反馈意见，并对可接受的报告、文档签字确认。
6）需求分析的难点：
（1）问题的复杂性；
（2）交流障碍；
（3）不完备性和不一致性；
（4）需求易变性。
2、需求规格
软件需求规格的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。
需求分析完成的标志是提交一份完整的软件需求规格说明书（SRS）。
对项目来说，需求规格说明书（SRS）和工作陈述（SOW）是很关键的两个文档。
3、需求验证
在构造设计开始之前验证需求的正确性及其质量，就能大大减少项目后期的返工现象。
在项目计划中应为这些保证质量的活动预留时间并提供资源。
从客户代表方获得参与需求评审的赞同，并尽早且以尽可能低的成本通过非正式评审和正式评审来找出其存在的问题。
需求规格提交后，开发人员需要与客户对需求分析的结果进行验证，以需求规格说明为输入，通过符号执行、模拟或快速原型等途经，分析需求规格的正确性和可行性。验证包括：
1）需求的正确性。
2）需求的一致性。
3）需求的完整性。
4）需求的可行性。
5）需求的必要性。
6）需求的可检验性。
7）需求的可跟踪性。
8）最后的签字。
4、需求变更
1）事实上，很少一个软件的需求改动是少于三次的。需求的变更可以发生在任何的阶段，即使到项目后期。
导致项目失败的最重要的原因与需求有关。
管理需求变更应该处理好变更的请求，对需求的变更进行严格的控制。
没有控制的变更会对项目的进度、成本、质量等产生严重的影响。
需求变更成本可以占项目总成本的40％。
需求变更是项目范围变更的最主要的变更。
2）对待变更的正确处理方法是：根据变更的输入，按照变更控制系统规定的审批程序执行，通过严格审查变更申请后，决定项目变更是否应该得到批准或者拒绝。
SCCB（Software Configuration Control Board）软件配置控制委员会
3）导致需求变更的原因有：
开发人员对待需求开发的态度不认真；
用户参与不够；
用户需求的不断增加；
模棱两可的需求；
用户和需求开发人员在理解上的差异；
开发人员的画蛇添足；
过于简单的规格说明；
忽略了用户分类；
不准确的计划等。
4）有效控制变更应采取合理的需求管理方法：
（1）需求分析阶段尽可能采用原型或者用例方法明确用户需求；
（2）采用严格的需求变更管理流程；
（3）采用良好的体系结构；
（4）采用面向对象思想。
5）在管理变更的时候，应该采取一定的策略，采用的策略是：
对合同范围之内的变化，要求坚决修改；
对合同范围之外的，但影响系统开通的变化，也进行修改，但要通知客户；
合同范围之外的可延后开发的变化，要和客户商量并达成一致，在系统开通之后再进行开发。