|
本篇目录:
5.1 需求开发与管理
5.1.1 需求调研
5.1.2 需求分析
5.1.3 需求定义
5.1.4 需求评审确认
5.1.5 需求细化跟踪
5.1.6 需求变更控制
5.2 软件系统设计
5.2.1 系统结构设计
5.2.2 用户界面设计
5.2.3 数据库设计
5.2.4 系统设计评审
5.3 模块开发和集成
5.3.1 模块需求细化
5.3.2 模块设计
5.3.3 模块实现和集成
5.4 测试与改错
5.4.1 测试准备
5.4.2 执行测试
5.4.3 消除缺陷
5.5 软硬件系统集成
5.5.1 系统集成方案设计
5.5.2 选择设备供应商
5.5.3 设备采购和验收
5.5.4 设备安装调试
5.6 部署试用
5.6.1 撰写文档
5.6.2 软件部署
5.6.3 客户培训
5.6.4 客户试用
5.7 软件维护
5.7.1 接受维护请求
5.7.2 分析维护请求
5.7.3 执行维护
摘要:
5.1.6 需求变更控制
对大多数项目而言,需求发生若干次变更似乎是不可避免的。需求发生变更的起因主要有:
随着项目的进展,人们(包括开发方和客户方)对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足,因此要变更需求。
市场发生了变化,原先的需求文档可能跟不上当前市场需求,因此要变更需求。
提出需求变更的动机是好的,目的是希望产品更加符合用户的需求。对项目开发团队而言,变更需求意味着要调整资源、重新分配任务、修改前期工作成果等,开发团队要为此付出较重的代价。如果每次需求变更请求都被采纳的话,这个项目也许永远不能按时完成。
需求变更控制的动机是:
(1)如果需求变更带来的好处大于坏处,那么允许变更,但必须按照已定义的变更规程执行,以免变更失去控制。
(2)如果需求变更带来的坏处大于好处,那么拒绝变更。
需求的变更应当遵循“变更控制流程”,即“变更申请->审批->执行”,详见本书第6.3.2节“变更控制”。
……
第5章 IDP项目研发过程.zip
(49.71 KB, 下载次数: 28)
上一篇:林锐系列之集成化软件研发流程IDP5.0--第4章 IDP项目管理过程 下一篇:林锐系列之集成化软件研发流程IDP5.0--第6章 IDP支持过程 |
|