标签：适合 设计模型 交互 sys 需求变化 承担 程序 质量保证 发行版
1. 每一个项目阶段都以一个或数个可交付成果的完成为标志。
2. 把项目分为多个节点的目的在于确保达到本阶段的目标并通过评估验收。
3. 项目绩效评审的目标是决定项目是否可以进入下一个阶段。
4. 软件开发生命周期包括调试。
5. 只有对需求进行确认，才能作为后续开发的基础，从而减少风险。
6. 项目的需求会发生变更，允许变更，但要规范变更，尽量减少变更。
7. 在项目策划阶段，变更成本较低。
8. 一般情况下，随着项目的逐渐进展，成本和人员投入呈现出先增后减。
9. 一般情况下，随着项目的逐渐进展，项目干系人对于项目最终产品的特征和项目最终费用的影响会逐渐减小。
10. 一般情况下，随着项目的逐渐进展，变更和缺陷修改的费用会逐渐增加。
1. 瀑布模型适用于需求明确或很少变更的项目（问题定义->可行性研究->[需求分析->总体设计->详细设计->程序编码->单元测试->功能测试->集成测试->系统测试]）。
2. 喷泉模型主要用来描述面向对象的软件开发过程。
3. 迭代模型适用于项目事先不能完整定义产品的所有需求，计划多期开发的(开发初期智能提供基本需求时采用)。RUP模型是迭代模型的一种。
4. 信息系统开发方法包括：结构化方法，原型法，面向对象方法。
5. 结构化方法：主要特点是严格区分工作阶段，每个阶段都有明确的任务和取得成果，强调系统的整体性和系统开发过程顺序，开发过程工程和，文档资料标准化。
6. 新项目与过去成功开发过的一个项目类似，但规模更大，这时应采用瀑布模型进行项目开发设计。
7. V模型（[需求分析->总体设计->详细设计->程序编码->单元测试>集成测试->系统测试->验收测试]）描述了软件基本的开发过程和测试行为，描述了不同测试阶段与开发过程各阶段的对应关系。
8. V模型中的系统测试用于检查系统作为一个整体是否有效运行。
9. V模型决定了在对应阶段制定对应的测试计划，测试工作往往采用V模型来进行，V模型从需求分析就开始编写测试计划。
10. 原型法：用户对系统的目标不是很清楚，难以定义需求，需求变化大, 目的是获取用户需求，帮助用户明确需求。
11. 原型法不适用的情形为（用户的数据或软件资源缺乏组织和管理；缺少使用的原型开发工具；用户不参与不配合开发过程）
12. 原型法特征（简化项目管理；尽快建立初步需求；加强用户参与和决策；开发过程密切依赖用户的良好配合，动态响应用户的需求，通过反复修改来实现用户的最终系统需要）
13. 增量模型是一种能够快速构造可运行产品的好方法。
14. 螺旋模型综合了瀑布模型和演化模型的优点，并增加了这两种模型忽略的风险分析，每个阶段都有目标设定，风险分析，开发和有效性验证以及评审构成。（循环+里程碑）
15. 软件组织采用的范型：（瀑布；迭代【演化、增量、喷泉】；螺旋【瀑布+演进+风险】；转换；第四代自动生成代码）
16. 基于演进过程模型包括：增量、螺旋、并发开发。
17. 螺旋模型包括：计划制定，风险分析，工程实施，客户评价。
18. 敏捷方法以原型开发思想为基础，采用迭代增量式开发，发行版本小化，比较适合需求变化较大或者开发前期对需求不是很清晰地项目。
19. 敏捷方法基本思想（个体交互胜过过程和工具；可以工作的软件胜过全面的文档；客户合作胜过合同谈判【快速反馈及时调整】；响应变化胜过遵循计划）
20. 敏捷开发适用于（难以提前预测哪些需求是稳定的/变化的；从制定计划的角度来看，分析、设计、实现和测试并不容易预测；可执行原型和部分实现的可运行系统是了解用户需求和反馈的）
21. 结构化方法认为：设计和实现可以做到基本分离。
22. 极限编程准则包括：策划、设计、编程和测试（持续集成）
23. 极限编程核心价值：沟通（Communication）、简单（Simplicity）、反馈（feedback）、勇气（Courage）
24. 极限编程提倡在基本设计完成之后，团队不应该直接开始编码，而是开发一系列用于检测本次发布的包括所有故事（story）的单元测试。
25. 极限编程过程中建立的单元测试应当使用一个可以自动实施的框架，支持代码修改后即时的回归测试策略。
26. 统一开发过程是一种基于面向对象技术的软件开发过程。
27. RUP（Rational Unified Process），统一软件开发过程特点：（用例驱动；以架构为核心；迭代并增量）
28. RUP 4 种通用开发阶段（1. Inception起始阶段，【构想文档、用例模型调查、初期业务用例、早期风险评估】生命周期目标；）。
29. RUP 4 种通用开发阶段（2. Elaboration细化阶段，【详细需求分析、软件架构描述、可执行的架构原型】生命周期架构/框架；）。
30. RUP 4 种通用开发阶段（3. Construction构建阶段，【得到设计模型、软件产品、用户手册】最初运作能力；）。
31. RUP 4 种通用开发阶段（4. Transition交付阶段，【】产品发布；）。
32. 细化阶段的任务：确保软件结构、需求、计划足够稳定；确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度；针对项目的软件结构上的主要风险已经解决或者处理完成。
33. 信息系统集成项目的技术过程和管理过程的正确顺序是：制定业务发展计划-》项目需求分析-》制定项目管理计划。
1. 规划策略（The Planning Game）。
2. 结对编程（Pair programming）。
3. 测试（Testing）。
4. 重构（Refactoring）。
5. 简单设计（Simple Design）。
6. 代码集成所有权（Colective Code Ownership）。
7. 持续继承（Continuous Integration）。
8. 现场客户（On-site Customer）。
9. 小型发布（Small Release）。
10. 每周40小时工作制（40-hour Week）。
11. 编码规范（Code Standards）
12. 系统隐喻（System Metaphor）
1. 启动过程组：选定项目，定义并批准项目或阶段。
2. 规划过程组：定义并细化目标，规划最佳的行动方案，即从各种备选方案中选择最优方案，以实现项目或阶段所承担的目标和范围【风险识别】。
3. 执行过程组：整合人力和其他资源，在项目的生命期或某个阶段执行项目管理计划【实施质量保证，项目团队组建，询价，卖方选择】。
4. 监控过程组：要求定期测量和监控进展，识别与项目管理计划的偏差，以便在必要的时候采取纠正措施，确保项目或阶段目标的达成【合同管理、随时收集干系人需求、分析项目风险、编制绩效报告】。
5. 首尾过程组：正式接收产品，服务或工作成果，有序地结束项目或阶段。
优点：
阶段划分次序清晰，各个阶段的人员的职责规范、明确，便于前后活动的衔接，有利于活动重用和管理。
缺点：
是一种理想的线性开发模型，缺乏灵活性，无法解决需求不明确或不准确以及需求变化等问题。
弥补：
原型化模型用于解决需求不明的情况。
螺旋模型，强调风险分析，特别适合庞大而负责的高风险的系统。
回答：
1. 需求分析与需求分析说明书。
2. 验收测试计划。
3. 系统设计工作说明书。
4. 系统测试计划。
5. 详细的项目计划。
6. 单元测试用例以及测试计划。
7. 编码后经过测试的代码。
8. 测试工作报告。
9. 项目监控文档如周例会纪要等。
标签：适合 设计模型 交互 sys 需求变化 承担 程序 质量保证 发行版
原文地址：https://www.cnblogs.com/haimishasha/p/12178469.html
