4.1软件过程
过程的含义
过程是一组将输入转化为输出的相互关联或相互作用的活动。
过程方法
过程方法是系统地识别和管理组织内所使用的过程，保证更有效地获得期望的结果。
软件过程
软件开发活动分为以下几个环节：
问题定义：人们通过开展技术探索和市场调查等活动，研究系统的可行性和可能的 解决方案，确定待开发系统的总体目标和范围。
需求开发：在可行性研究之后，分析、整理和提炼所收集到的用户需求，建立完整的 需求分析模型，编写软件需求规格说明。
软件设计：根据需求规格说明，确定软件体系结构，进一步设计每个系统部件的实现 算法、数据结构及其接口等。?
软件构造：概括地说是将软件设计转换成程序代码，这是一个复杂而迭代的过程，要求 根据设计模型进行程序设计以及正确而高效地编写和测试代码。
软件测试：检查和验证所开发的系统是否符合客户期望，主要包括单元测试、子系统 测试、集成测试和验收测试等活动。
软件维护：系统投入使用后对其进行改进，以适应不断变化的需求。完全从头开发的 系统很少，将软件系统的开发和维护看成是一个连续过程更有意义。
软件开发管理
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、 人员、进度、质量和风险进行控制和管理的活动。
软件配置管理是通过执行版本控制、变更控制的规程，并且使用合适的配置管理软件， 来保证所有产品配置项的完整性和可跟踪性。
?????????
4.2软件过程模型
软件过程模型
软件过程模型是对软件过程的抽象描述，是定义任务之间关系和规程和方法
本课程主要介绍了四种模型：瀑布模型、原型化模型、迭代式开发模型、可转换模型?
瀑布模型
将基本的开发活动看成是一系列界限分明的独立阶段，这是 一种计划驱动的软件过程，有利于规范软件开发活动。以预测性为原则 、以文档驱动开发过程 、以过程控制为核心。
原型化模型
?原型是一个部分开发的产品，用于加强对系统的理解，有助 于明确需求和选择可行的设计策略
迭代式开发模型
将描述、开发和验证等不同活动交织在一起，在开发过程中 建立一系列版本，将系统一部分一部分地逐步交付。
特点：
更快速地发布产品
追求产品创新
需求不确定性高
需要快速响应用户的变化
关注用户行为
增量模型：在每一个新的发布中逐步增加功能直到构造全部功能。
迭代模型：一开始提交一个完整系统，在后续发布中补充完善各子系统功能。
可转换模型?
利用自动化的手段，通过一系列转换将需求规格说明转化为 一个可交付使用的系统。
由于数学方法具有严密性和准确性，形式化方法所交付 的系统具有较少的缺陷和较高的安全性。 ? 特别适合于那些对安全性、可靠性和保密性要求极高的 软件系统，这些系统需要在投入运行前进行验证。
8.1需求工程师
需求工程师需要具有的能力
1. 分析问题和解决问题的能力
2. 人际沟通及交流能力
3. 软件工程知识和技能
4. 应用领域有关知识
5. 书面语言组织和表达能力
需求工程师需要做的
识别错误假设
确保一致性
提升依从性
减少彼此误解
提高支持速度和效率 ?
提升客户满意度
撰写优质需求文
需求工程师要避免的
干扰
沉默
过度规约
矛盾
含糊
向前引用
不切实际与一厢情愿
8.2需求定义
什么是需求
需求, 是人们要解决的某个问题或达到某种目的的需要。是系统 或其组成部分为满足某种书面规定（合同，标准，规范等）所要具 备的能力。需求将作为系统开发，测试，验收，提交的正式文档 依据。
需求包含哪些内容
需求是系统为满足客户期望的目标而完成的行为
需求要体现出对问题领域的清晰理解
给出系统的使用场景和上下文
存在问题的需求描述实例
?什么是好的需求
单个需求项的质量
准确、正确、明确、可行、可证
整个需求集合的质量
现实、精确、全面、一致
8.7撰写需求文档
需求文档规格说明
是具有一定法律效力的合同文档
清楚地描述软件在什么情况下，需要做什么，以及不能做什么
以输入/输出、输入到输出之间的转换方式来描述功能性需求
描述经过干系人磋商达成共识的非功能性需求
一般参考需求定义模板，覆盖标准模板中定义的所有条目
作为后续的软件评估依据和变更的基准
选择合适的需求规格文档说明
?用户手册大纲
介绍
????????产品总览及基本原理
????????术语和基本特征
????????展示格式与报表格式的总结
????????手册的大纲
开始
????????开始指令
????????帮助模式
????????样例运行
操作模式
????????命令行/对话框/报告
高级特性
命令语法和系统选项
高质量需求规格说明
是所有需求的集合
描述产品要提供的所有功能
是软件系统解决方案的商业合同的基础
是测试计划的基础
定义产品需求的度量标准
是产品需求跟踪的先决条件
影响开发产品的项目计划
高质量需求规格说明的评价标准
正确性 = 经过验证的
无歧义
完整的
可测试 = 可以证明的
可修改的
可跟踪的
易理解
一致的
有序的
项目或产品特定的其他特征
需求规格说明生成过程
创建任何类型的需求规格说明最优先的方式是通过需求数据库生成它
不直接修改规格说明，修改数据库中的需求并且重新生成规格说明
?IEEE-830 SRS模板大纲
?IEEE-830 SRS模板第三部分
SRS模板优缺点?
优点
模板提高效率
在有模板的情况下，面对一个完整的 大纲，不容易遗漏重要的信息
缺点
并非对于所有的系统，模板的章节设 计都是类似的
如果仅仅为了满足标准，而填写模板 的所有章节，在不相关的章节，会加 入一些没有意义的内容
读者很难将这些无意义的文字和真正 的需求分开
总结
尽快开始写需求
确定哪些属性将被用于分类和细化需求
产生一个初始版本来刺激反馈
询问用户往往比咨询专家更有用
撰写需求时需要遵循的法则：
使用简单、直接的语言
撰写可测试的需求
使用定义好的并达成共识的术语
一次只写一项需求
个人总结：
经过本次课程的学习，我认为重点首先是几个模型。以下是个人总结的几点拙见：
原型化和瀑布模型的区别在于尽快的制作出一款原型，来检验软件是否可行，而迭代式开发的本质其实就是通过多次制作原型来迭代出更符合要求的软件，这三者的本质区别在于制作原型的次数。而可转换模型则区别较大，它通过将无法直接测试的需求转换成可以直接测试的需求，保证了模型的安全、可靠、严密。
此外比较重要的一点就是需求文档的撰写。我觉得这个的撰写光靠阅读概念其实是不够的，应该需要阅读一些优秀的需求文档以及模仿优秀的需求文档实践才能够真正的掌握好撰写需求文档的技能。这一项技能我认为是非常重要的，不光是我们程序员需要掌握这一项技能，其实更多的其他专业的需要给计算机同学提出需求的同学们也应该需要掌握这一项技能，因为这会大大的减少不必要的麻烦。如果一位完全不知道需求文档应该如何撰写的朋友要为一个计算机专业的同学写需求文档的话，这个需求文档可能是不完整，不清晰的，外专业的同学可能不知道要写什么，写了一堆不重要的信息，而计算机的学生也没有办法理解外专业的学生到底想要做什么。这时候事情就会变得事倍功半，而如果是有幸外专业的同学来听一听软件工程课，了解一下需求文档应该怎么来写，那么相信，这对于合作双方都会是一段美好的回忆。