软件工程过程 第2章 软件开发的主要活动

标签：参考   --   独立   新版本   需求   合作   概要设计   标识   构造解   

• 需求是任何软件开发项目的基础。
• 好的需求是项目成功开发的必要条件。
• 需求分析工作可划分为两个阶段：需求开发和需求管理。需求开发就是传统意义上的需求分析。

• 与客户和其他涉众在系统的工作内容方面达成并保持一致。
• 使系统开发人员能够更清楚地了解系统需求，定义系统边界；
• 为软件实施计划提供基础；
• 为估算开发系统所需成本和时间提供基础；
• 定义系统用户的需求和目标。

• 收集背景资料。
• 定义项目前景和范围。
• 选择信息的来源。
• 选择获取方法，执行获取。

• 系统需求分析。
• 软件需求分析

• 主要工作是通过建模来整合各种信息，从而使人们更好地理解问题。
• 为问题定义了一个需求集合，并进而形成一个初步的解决方案。
• 还要检查需求中存在的错误、遗漏、闭一只等缺陷，并加以修正。
• 首要任务是去诶递归系统边界背景分析。

• 以需求规格说明书的形式固化下来。文档化需求前，首先要定制文档模板，以及模板撰写需求文档。
• 在撰写中一方面要选择最准确的表示方式，
• 同时又要注意保证文档的良好结构和易读性。

• 验证的主要任务是执行验证和问题修改。
• 需求验证通过之后，会形成需求规格说明书基线文档，该文档被纳入管理配置，作为指导系统后续开发的依据。

• 正向跟踪
• 反向跟踪

• 目标是构造解决方案，设计过程是把对软件的需求描述转为软件表示，这种表示能在编码开始以前对其质量做出评价。
• 关键是对软件体系结构、数据结构、过程细节以及接口这4中程序属性的确定。

• 高层设计即传统软件工程中的概要设计和体系结构设计。
• 高层设计是为了系统后续实现做准备的，因此但凡对系统影响大的因素或风险，都应该在高层设计阶段加以考虑，并给出可行的解决方案。
• 高层设计至少应包括定义相关标准、确定系统的开发与运行的软硬件环境、确定系统体系结构、模块或组件划分、数据库设计等主要活动。
• 高层设计主要讨论的问题应该是涉及面广、影响大的问题，或者对系统的关键指标影响大的纵深性问题。

• 详细设计的主要任务是选定数据结构和算法设计，完成模块或者对象设计。
• 包括的主要活动有模块的进一步细化与设计、数据迁移程序的开发、通用程序框架的设计/开发、实用工具的开发、单元测试计划的开发。

• 阶段目标是形成完整并经验证的程序组件集。
• 主要活动可描述为：建立测试数据库、生产代码、实施独立的单元测试。

• 单元测试
• 集成测试
• 系统测试
• 验收测试

• 软件更新——会导致软件产品的功能说明发生变化。
• 校正性维护——在不改变软件功能说明的前提下，修正软件中处理、性能或实现方面的错误。
• 适应性维护——在不改变软件功能说明的前提下，修正运行环境或数据环境的改变。
• 完善性维护——在不改变软件功能说明的前提下，为增强性能或可维护性而进行的维护。

• 项目启动。为确定项目的目标和范围。
• 项目规划。简历项目的基准计划。
• 项目实施。按照计划实施和监控项目。
• 项目收尾。交付产品以及总结经验教训。

• 确定项目的工作范围。（功能、性能、约束、界面和可靠性要求）
• 识别资源。（描述资源是什么、可用性陈述、要求使用的先后、使用多长时间）
• 软件项目评估。（确定工作量、判定需要多少人、要多少钱才能开发出这个软件）
• 做出外购决策。（自行开发、修改本单位已有的重用件、购买一个成品件并加以修改、软件外包出去）
• 编制项目计划。（参与项目的各种角色通信的范围和资源、定义风险和风险管理技术、定义费用和进度、为所有参与者提供活动途径、勾画质量保证和变更如何管理等）

• 软件估算风险
• 商业影响风险
• 客户相关风险
• 开发技术风险
• 开发环境风险
• 开发人员风险
• 过程相关风险

• 风险识别：确定项目有哪些风险，包括运行专家判断法、头脑风暴法等方法分析项目风险产生的各种原因或者影响因素，以确定风险事件及其来源
• 风险分析：比较风险大小，确定风险性质。通过对各种风险进行定性、定量的分析，包括发生概率、影响严重程度等，确定各种风险的大小及性质
• 风险评估：指定风险相应的措施和实施步骤，按照风险的大小和性质，制定相应的措施去应对相应的风险，包括风险接受、风险转移。
• 风险监控：监督、检查风险事件的发生情况及风险措施的落实情况，通过对风险事件及来源的控制和对风险计划落实情况监督，确保风险措施有效

• 操作概念
• 需求规格说明
• 设计文档
• 源代码
• 目标代码
• 测试计划
• 测试用例、测试配置和测试结束
• 维护和开发工具
• 用户手册
• 维护手册
• 接口控制文档

• 计划基线
• 需求基线
• 规格说明基线
• 设计基线
• 实现基线
• 测试基线
• 操作基线

• 创建基线的事件。
• 与基线和配置控制相关联的SCI。
• 自基线创建以来，对基线所做的变更。
• 建立和更改基线以及基线中的SCI所使用的规程。
• 批准基线中SCI更改的机构应该具有的权限。
• 如何标识更改，如何将这一变更与基线和其中的SCI关联起来。

• 被批准的一个SCI的最初版本。
• 对于该SCI，所有请求的变化状态。
• 对于该SCI，所有被批准的变更的实现状态。

• 尽早发现和改正软件错误。
• 增强过程与产品风险的洞察力。
• 支持软件生存周期过程，确保程序性能、进度、指出的需要。

• 根据项目需求的关键度确定 V&V 投入的工作量和实时 V&V 个人或组织的独立程度。
• 根据 V&V 过程投入的工作量确定是否要建立一个 V&V 软件产品的过程。
• 建立软件开发过程中的活动或软件产品的 V&V 过程。
• 基于确定的 V&V 过程，开发 V&V 实施计划。
• 执行并监控 V&V 计划。

•  根据项目特征建立一个适合本项目的SQA过程，来监控软件产品及其开发过程，以确保与标准、过程相符，确保软件产品、过程、使用标准的缺陷对管理者可见。
• 确保SQA过程与V&V 过程、联合评审过程和审计过程一致。
• 开发SQA过程的活动和任务计划，并在整个合同期内实施并维护已文档化的SQA计划。
• 按计划执行SQA活动和任务。
• SQA活动和任务记录要符合获取方合同的要求
• 负责保证遵守合同需求的个人应具有组织自由度和资源的调配能力，并具有允许客观评估或发起、影响、处理和验证问题的权威性。

• 确保依照合同要求按时执行所有过程。
• 确保内部软件工程实践、开发环境、测试环节和配置库符合合同要求。
• 确保初始化合同需求分解成自合同的合理性，确保自合同的软件产品满足初始化合同的需求。
• 在遵守合同、谈判与计划方面，确保获取者和其他团体得到了所需要的支持和合作。
• 确保软件产品和过程度量遵守所建立的标准和规程。
• 确保指定的人员有足够的技能和必要的知识以满足项目需求，并接受必要的培训。

• 对所有开发计划和质量计划的完整性进行评审。
• 作为审查主持人，参与设计和代码的审查。
• 对所有测试计划是否符合标准进行评审。
• 对所有测试结果的显著样本进行评审，以确定是否按照计划执行。
• 定期审核SCM的执行情况，以确定是否符合标准。
• 参与所有项目的季度和阶段评审，如果没有合理得到相关标准和规程的要求，应对不符合项进行登记。

• 质量保证实践：定义了足都的开发工具、技术、方法和标准，可用作质量保证评审的标准。
• 软件项目规划评价：如果一开始没有进行充分的质量实践规划，就不可能真正实施该评估。
• 需求评价：由于低质量的需求不可能产生高质量的产品，因此必须评审初始需求是否符合质量标准。
• 设计过程的评价：需要某种手段，确保设计遵循了规划的方法，实现了需求，且设计本身的质量已通过了独立评审。
• 软件集成和测试过程评价：建立软件质量测试规程，测试由独立的组进行，这个组应积极并能够找出问题，应及早对测试进行规划，测试本身的质量也要经过评审。
• 管理和项目控制过程内部评价：通过确认管理过程有效实施，SQA有助于确保整个组织将重点放在取得高质量的成果上。
• 质量保证规程的剪裁：应对软件质量保证计划进行剪裁，以保证每个项目的特殊需要。

• 相同点：两者的目标都是监控项目和产品，确保客户得到符合质量保准的产品。
• 不同点：SQA是一种内部的方法，主要处理标准的符合问题和产品流的符合问题。V&V 工作关注一个项目产品的技术属性及其开发过程。

• 启动SQA程序
• 表示SQA问题
• 编制SQA计划
• 建立标准
• 确定SQA功能
• 进行培训并宣传SQA程序
• 实施SQA计划
• 评价SQA程序

• 目的
• 参考文件
• 管理
• 文档
• 标准、管理和约定
• 评审和审核
• 软件配置管理
• 问题报告和纠正措施
• 工具、技术和方法
• 代码控制
• 媒介控制
• 供应商控制
• 记录的收集、维护和保持

• 需求分析、设计、构造、测试等软件开发的核心活动固然重要，但支持这些核心活动的项目管理、配置管理、验证与确认、质量保证等支持活动对提高软件产品的开发效率与保护软件开发成果等，与主要的软件开发活动同等重要，有时在这些支持活动上花费的成本可能更高。

软件工程过程 第2章 软件开发的主要活动

标签：参考   --   独立   新版本   需求   合作   概要设计   标识   构造解   

原文地址：http://www.cnblogs.com/zpfbuaa/p/6974016.html