软件工程导论作业一

一：软件生命周期模型：
概括的说，软件生命周期由软件定义、软件开发和运行维护3个时期组成，每个时期又进一步分成若干个阶段。
1：问题定义：
问题定义阶段必须回答的关键是：“要解决的问题是什么？”如果不知道问题是什么就试图解决这个问题，显然是盲目的，只有白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切的定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。
通过对客户的访问调查，系统分析员扼要地写出关于问题性质，工程目标和工程规模的书面报告，经过讨论何必要的修改之后这份报告应该得到客户的确认。
2：可行性研究：
这个阶段要回答的关键是:”对于上一个阶段所确定的问题有行得通的解决办法么？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了得系统分析和设计过程，也就是在比较抽象的高层次上进行的分析和设计过程。可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究这个问题是否值得去解决，是否有可行的解决办法。
可行性研究的结果是客户做出是否继续进行这项工程的决定的重要依据，一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投入更多的人力物力。及时终止不值得投资的项目，可以避免更多的浪费。
3：需求分析：
这个阶段的任务依然不是具体解决问题，而是准确的确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须要具备哪些功能。
用户了解他们所面对的问题，知道必须要做什么，但是通常不能完整准确的表达出他们的要求，更不知道怎么利用计算机解决问题，软件开发人员知道怎么用软件实现人们的要求，但是对待定的用户的具体要求并不完全清楚。因此，系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数字流图，数据字典和简要的算法表示系统的逻辑模型。
4：总体设计：
这个阶段必须要回答的关键问题是：”概括的说，应该怎么实现目标系统？”总体设计又称为概要设计。
首先，应该设计出实现目标系统的几种可能的方案。通常至少应该设计出低成本，中等成本和高成本3中方案。软件工程师应该用适当的表达工具描述每种方案，分析每种方案的优缺点，并在充分权衡各种方案的利弊的基础上，推荐一个最佳的方案。此外，还应该制定出实现最佳方案的详细计划，如果客户接受所推荐的方案，则应该进一步完成下述的主要任务。
上述设计工作确定了解决问题的策略及目标系统中应包含的程序，但是，怎么设计这些程序呢？软件设计的一条基本原理就是，程序应该模块化，也就是说，一个程序应该由若干个规模按合理的层次结构组织而成。因此，总体设计的另一项主要任务就是设计程序的体系结构，也就是确定有哪些模块组成以及模块间的关系。
5：详细设计：
总体设计阶段以比较抽象概括的方式提出了解决问题的办法，详细设计阶段的任务就是把解决具体化，也就是回答下面这个关键问题：“应该怎么样具体的实现这个系统呢？”
这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明，这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，他们应该包含必要的细节，程序员可以根据他们写出实际的程序代码。
详细设计也成为模块化设计，在这个阶段将详细的设计每个模块，确定实现模块功能所需要的算法和数据结构。
6：编码和单元测试：
这个阶段的关键任务是写出正确的容易理解，容易维护的程序模块。
程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序员设计语言，把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编出的每一个模块。
7：综合测试：
这个阶段的关键任务是通过各种类型的测试使软件达到预定的要求。
最基本的测试是集成测试和验收测试，所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试，所谓验收测试则是按照规格说明书的规定有用户对目标系统进行验收。
通过对软件测试结果的分析可以预测软件的可靠性，反之，根据对软件可靠性的要求，也可以决定测试和调试过程什么时候可以结束。
应该用正式的文档资料把测试计划，详细测试方案以及实际测试结果保存下来，作为软件配置的一个组成部分。
8：软件维护：
维护阶段的关建任务是，通过各种必要的维护活动使系统持久的满足用户的需要。
通常有4类维护活动：改正性维护也就是诊断和改正在使用过程中发现的软件错误，适应性维护，及修改软件以适应环境的变化，完善性维护，即根据用户的要求改进或扩充软件使他更完善，预防性维护及修改软件为将来的维护活动预先做准备。
瀑布模型：
可强迫开发人员采用规范的方法；严格的规定了每一个阶段必须要提交的文档要求每一个阶段交出所有的产品都必须经过质量保证小组的仔细验证。“瀑布模型是由文档驱动的”这个事实也是他的一个主要缺点，在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的，但是，仅仅通过写在纸上的静态的规格说明，很难全面正确的认识动态的软件产品，而且事实证明，一旦一个用户开始使用一个软件，在他的头脑中关于该软件应该做什么的想法就会或多或少的发生变化，这就是使得最初的需求变得不完全试用了，事实上，要求用户不经过实践就提出完整准确的需求，在许多情况下都是不切实际的，总之，由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发的软件产品不能真正满足用户的需求。
快速原型模型：
软件产品的开发基本上是线性顺序进行的，能基本上做到线性顺序开发。开发人员通过建立原型系统已经学到了许多东西，因此，再设计和编码阶段发生错误的可能性比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。
增量模型：
目标都是一次就把一个满足所有需求的产品提交给用户。增量模型则与之相反，他分批的逐步提交产品，整个软件产品被分解成许多个增量构建，开发人员一个构建借一个构件的向用户提交产品，从第一个构建交付之日起，用户就能做一些有用的工作，显然，能在较短时间内向用户提交可完成部分工作的产品，是增量模型的一个优点。
螺旋模型：
对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标，减少了过多测试或测试不足所带来的风险，更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。螺旋模型的主要优势在于，他是风险驱动的，但是，这也可能是他的一个弱点，除非软件开发人员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险，当项目实际上正在走向灾难时，开发人员可能还认为一切正常。