打印本文 
关闭窗口 (1)系统规划区分系统各部分交付的优先次序，了解其内部的相互依赖关系，明确交付系统的能力、容量和可能的制约因素，按照优先级次序启动不同流程。
(2)确认系统方案的可行性对系统方案交付选项进行有效的评估，保证业务和信息系统在理念上的一致性，确认真正的需求范围和交付内容，保证预算在各个子目标之间的合理分配，利用原型法把模拟的应用转换为实际的应用。
(3)评估影响考虑新的应用系统对组织现有系统、流程和利益相关者的影响。
(4)考虑所有可能的方案权衡是购买还是自行开发系统，考虑每种选择所包含的风险并进行分析，以利于持续改进。
3.2开发/采购
对于大多数信息系统来说，开发/采购阶段比起始阶段更复杂，可以分为以下三个子阶段。
3.2.1需求和方案设计
在开发，采购阶段的初期，系统计划者定义系统的需求，风险管理的需求也应该与此同时制定，风险管理的目标是保证在系统解决方案开始构建之前，明确方案的优缺点，避免返工。方案架构设计过程应该坚持对方案进行严格的质量评估，同时要积极管理合作伙伴合同和技术采购上可能出现的风险。
确定需求的优先级在整个系统方案范围内，评估并确认需求的优先顺序和组织的能力，哪些是必须做的，哪些是可以完成的，哪些是可能完成的，哪些是可能完不成的。
定义接口如果多个团队必须同步开展系统开发，应该为最终集成在一起的多个子系统定义清晰的接口。
选择技术组件挑选需要采购、改造、修改的技术组件，确认其来源的可靠性、质量和持续支持的能力。
3.2.2系统构建(开发/采购)
如果系统要自行开发，编码工作此时已经开始启动，对采购软件，则需要同步开始进行裁剪和配置工作，这个阶段需要避免的风险主要和系统各个组成部分自身携带的缺陷有关，这些组件集成到整个系统中，也可能引入新的缺陷。
系统分割和合并系统设计一般都是分开进行。这样便于多个团队并行工作，提高效率，最终要把这些工作集成到一起。尤其是需要多次发布的软件，分割和合并的工作更为复杂。
3.2.3系统测试
系统测试阶段主要的风险管理目标是通过测试识别不可接受的缺陷，并确认每个缺陷都得到了解决。
确认系统的正确性和完整性依照系统规范和业务需求，按部就班地对系统实施“肯定性”和“否定性”测试，以保证系统能够正常运作。
增强信心对重要的业务流程，必须从端到端的角度来验证系统具备正确的功能。
获得用户认可提供证据证明来自交付伙伴的方案组件和整体系统在业务上都是可以接受的。
3.3实施
在实施阶段，系统主要的风险管理目标是保持业务的持续运行，避免业务中断。
预演在系统投产前，组织用户代表进行技术演练，使用户对系统在时问、次序和可能造成的影响等方面都有一个清晰的了解。
投产动员实施队伍，按照计划进行应用实施，并验证系统实施是否取得成功。
回退制定一套可以让业务退回原有状态的备用计划，并在实施前进行演练。
3.4运行和维护
由于系统的复杂性和资源限制，测试阶段很难对信息系统进行穷尽测试，系统在运行中总会出现新的缺陷，同时业务的发展变化也会对系统提出变更和改进要求，此时风险管理的目标是把系统从故障状态中恢复正常运行，避免系统改进造成新的故障。
变更管理对必要的系统变更进行系统管理。
定期安全检查认识系统安全的重要性，完善安全策略，定期进行检查审核。
灾难恢复计划更新系统发生变更后及时更新灾难恢复计划，并定期进行演练。
3.5退出与废弃
信息系统生命周期的退出和废弃阶段涉及到信息、硬件和软件的处置。在理想情况下，旧应用系统退出计划应该作为新应用系统实施和切换的一部分。
信息可以转移到其它系统、存档、丢弃或销毁，对信息存档时应该考虑未来能够取回信息的方法。
硬件和软件硬件和软件可以被销毁、出售、赠送或丢弃。对包含保密信息的存储介质必须进行销毁，对软件的处置应遵循许可证和其它与开发商的协议。
费用用来清除一个过时的
打印本文 关闭窗口