学渣眼中的软件工程
- 本人是一个地地道道的学渣,一般很少会有人这样去承认自己,但是我清楚地认识到自己确实是一个学渣,所以我需要给自己打打气,去写出自己认知下的软件工程。
- 软件工程的理解:
- 首先需要理解软件,书上是这样来定义软件的,软件是计算机系统中与硬件相互依存的另一部分,软件包括程序、数据及其相关文档的完整集合。
- 而在比较权威的书上首先介绍的是”软件危机”,软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。软件危机包含下述两方面的问题:如何开发软件,以满足对软件日益增长的需求;如何维护数量不断膨胀的已有软件。
- 软件危机的典型表现:
- 1、对软件开发成本和进度的估计常常很不准确。这个就比较好理解了,实际成本比估计成本有可能高出一个数量级,实际进度比预期进度拖延几个月甚至几年的现象并不罕见。这种现象降低了软件开发组织的信誉。而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量,从而不可避免地会引起用户的不满。
- 2、用户对”已完成的”软件系统不满意的现象经常发生。软件开发人员常常在对用户只有模糊的了解,甚至对所要解决的问题还没有确切认识的情况下,就匆忙着手编写程序。软件开发人员和用户之间的信息交流往往很不充分,“闭门造车”必然导致最终的产品不符合用户的实际需要。
- 3、软件产品的质量往往靠不住。软件可靠性和质量保证的确切的定量概念刚刚出现不久,软件质量保证技术(审查、复查、程序正确性证明和测试)还没有坚持不懈地应用到软件开发的全过程中,这些都导致软件产品发生质量问题。
- 4、软件常常不可维护的。很多程序中的错误是非常难以去改正的,实际上不可能使这些程序适应新的硬件环境,也不能根据用户的需要在原有程序中增加一些新的功能。”可重用软件”还是一个没有完全做到的、正在努力追求的目标。
- 5、软件通常没有适合的文档资料 。计算机软件不仅仅是程序,还应该有一套文档资料。这些文档资料应该是在软件开发过程中产生出来的,而且应该是”最新式的”(即和程序代码完全一致的)。而针对于不同的使用者具有不同的效果:
- 软件组织开发的管理者来说可以使用这些文档资料来管理和评价软件开发工程的进展状况;
- 软件开发人员可以利用它们作为通信工具,在软件开始过程中准确地交流信息;
- 软件维护人员这些文档资料是必不可少的。缺乏必要的文档资料或者文档资料不合格,必然给软件开发和维护带来许多严重的困难和问题。
- 6、软件成本在计算机系统总成本中所占的比例逐年上升。
- 7、软件开发生产率提高的速度,远远跟不上计算机应用迅速普及及深入的趋势。软件产品”供不应求“的现象使人类不能充分地利用计算机硬件提供的巨大潜力。
- 软件的生命周期:
- 软件的定义:定义时期的任务是确定软件开发工程必须完成的总目标;确定工程的可行性;导出实现工程目标应该采用的策略以及系统必须完成的功能;估计完成该项工程需要的资源和成本。
- 问题的定义:问题定义阶段必须要回答的关键问题是:”要解决的问题是什么?”如果不知道问题是什么就试图解决这个问题,显然是盲目的,只会白白浪费时间和金钱,最终得出的结果很可能是毫无意义的,尽管确切地定义问题的必要性是十分明显的。但是在实践中它却可能是最容易被忽视的一个步骤。
- 通过对客户的访问调查,系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告,经过讨论和必要的修改之后这份报告应该得到客户的确认。
- 软件的开发:软件的开发时期的主要任务就是解决“如何做”的问题。具体设计和实现前一个时期定义的软件。通常由概要设计、详细设计、编码和测试四个阶段组成。
- 运行维护:软件的维护时期的主要任务就是使软件持久地满足用户的需要。
- 软件的定义:定义时期的任务是确定软件开发工程必须完成的总目标;确定工程的可行性;导出实现工程目标应该采用的策略以及系统必须完成的功能;估计完成该项工程需要的资源和成本。
- 介绍玩软件的声明周期需要介绍一下软件的生存期模型:
- 瀑布模型:瀑布模型一直以来都是被广泛使用的模型。
- 瀑布模型的特点:
- 1、阶段间具有顺序性和依赖性。其中包括两重含义:
- 必须等到前一阶段的工作完成之后,才能开始后一阶段的工作。
- 前一阶段的输出文档就是后一阶段的输入文档。
- 2、推迟实现的观点。
- 瀑布模型在编码之前设置了系统分析和系统设计的各个阶段,分析与设计阶段的基本任务规定,在这两个阶段主要考虑目标系统的逻辑模型,不涉及软件的物理实现。
- 清楚地区分逻辑设计与物理设计,尽可能推迟程序的物理实现,是按照瀑布模型开发软件的一条重要的指导思想。
- 3、质量保证的观点。
- 每个阶段都必须完成规定的文档。没有交出合格的文档就是没有完成该阶段的任务。
- 每个阶段结束前都要对所完成的文档进行评审,以便尽早发现问题,改正错误。
- 瀑布模型的优点:
- 可强迫开发人员采用规范化的方法;
- 严格规定了每个阶段必须提交的文档;
- 要求每个阶段交出的所有产品都必须通过验证(评审)的。
- 瀑布模型的缺点:
- 由于瀑布模型几乎完全依赖于书面的规格说明,很可能导致最终开发处的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异,就会发生这种情况。
- 瀑布模型只适合用在项目开始时需求已确定的情况。
- 快速原型模型: 它是快速简历起来的可以在计算上运行的程序,它所能完成的功能往往是最终产品的一个子集。
- 优点:
- 有助于满足用户的真是需求;
- 原型系统已经通过与用户的交互而得到验证,据此产生的规格说明文档能够正确地描述用户需求。
- 软件产品的开发基本上是按线性顺序进行。
- 因为规格说明文档正确地描述了用户需求,因此,在开发过程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工。
- 开发人员通过建立原型系统已经学到了许多东西,因此,在设计和编码阶段发生错误的可能性也比较小,这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。
- 快速原型的本质是“快速”。开发人员应该尽可能快地建造出原型系统,以加速软件开发过程,节约软件开发成本。原型的用途是获知用户的真正需求,一旦需求确定了,原型可以抛弃,当然也可以在原型的基础上进行开发。
- 增量模型:增量模型也称为渐增模型。
- 优点:
- 能够在较短的时间内向用户提交一些有用的工作产品,即从第一个构件交付之日起,用户就能够做一些有用的工作。
- 逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品,从而减少全新的软件可能给用户组织带来的冲击。
- 项目失败的风险较低,虽然在某些增量构件中可能遇到一些问题,但其他增量构件将能够成功地交付给用户。
- 优先级最高的服务首先交付,然后再将其他增量构件逐次集成起来。一个必然的事实是:最重要的系统服务将接受最多的测试。这意味着系统最重要的部分一般不会遭遇失败。
- 需要注意的问题是:
- 在把每个新的增量构件集成到现有的软件体系结构中时,必须不破坏原来已经开发出来的产品。
- 软件体系结构体系必须是开放的,即向现有产品中加入新构件的过程简单、方便。
- 因此,增量模型需要比瀑布模型和快速模型更精心的设计准备。
- 螺旋模型:软件开发几乎总要冒一些风险,因此,在软件开发过程中必须及时识别和分析风险,并且采取适当措施以消除或减少风险的危害。
- 螺旋线上的四个活动:
- 目标设定——定义在该阶段的目标,弄清对过程和产品的限制条件,制定详细的管理计划,识别项目风险,可能还要计划与这些风险有关的对策。
- 风险评估与弱化——针对每个风险进行详细分析,设想弱化弱化风险的步骤。例如,若有一个风险是需求不合适,可以考虑开发一个原型系统。
- 开发与验证——评价风险之后选择系统开发模型。 例如,若用户界面风险的发生概率和影响相当严重,则可以采用演讲原型作为开发模型。若安全性风险是主要考虑因素,则可以采用形式化变换方法。若子系统集成为主要风险,则瀑布模型最合适。
- 计划——评价开发工作,确定是否继续进行螺旋线的下一个循环。如果确定要继续,则计划项目下一阶段的工作。
- 优点:
- 对可选方案和约束条件的强调有利于已有软件的重用, 也有助于把软件质量作为软件开发的一个重要目标。
- 减少了过多测试或测试不足所带来的风险。
- 在螺旋模型中,维护只是模型的另一个周期,因而在维护和开发之间并没有本质区别。
- 缺点:
- 螺旋模型是风险驱动的,因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识,否则将出现真正的风险:当项目实际上正在走向灾难时,开发人员可能还以为一切正常。
- 喷泉模型:
- 迭代是软件开发工程中的普遍存在的一种内在属性。经验表明,软件过程各个阶段之间的迭代或一个阶段内各个工作步骤之间的迭代,在面向对象方法中比在结构化方法中更常见。
UML
(Unified Modeling Language):- 统一过程的工作流:
- 业务建模:用商业用例为商业过程搭建文档。
- 需求工作流:描述系统应该做什么,确保开发人员构建正确的系统。为此,需明确系统的功能需求和非功能需求(约束)。
- 分析与设计:分析与细化需求,并建立分析模型和设计模型。
- 实现:用选择的实现语言实现目标信息系统。以分层的方式组织代码的结构,用构件的形式来实现类,对构件进行单元测试,将构件集成到可执行的系统中。
- 测试:执行集成测试,验证对象之间的交互,是否所有的构件都集成了,是否正确实现了所有需求,查错并改正。
- 部署:制作软件的外部版本,软件打包、分发,为用户提供帮助和支持。
- 统一工程的各个阶段:
- 初始阶段;
- 细化阶段;
- 构造阶段;
- 移交阶段。
JackDan9 Thinking