85关于软件开发的环节

Posted 2020-09-20

 

针对软件开发，无论是瀑布模型还是敏捷模型，还是任何开发模式，永远都是软件工程所说的步骤，即在开发计划的指引下，按照需求、设计、开发、测试四个环节，完成应用系统的交付。只是各个环节所用的技术不同、框架不同、以及粒度不同。

 

1、需求获取、需求分析和需求管理

 

需求获取是问客户想要什么？需求的分析是知道客户的需求是什么，并且解决做什么，最后形成需求规格说明书，需求的管理就是保证需求到被实现的过程的完整性，变更是规范的，保证项目范围不偏离。

 

例如在传统的软件开发过程中，实际的软件项目需求规格说明书的编写过程中，是存在两种需求规格说明书的，一种是用户需求说明书，一种是软件需求规格说明书，软件需求规格说明书是基于用户需求说明书编写的，其格式取决于所采用的开发和管理方式，例如按流程开发的方式、面对对象的开发方式和敏捷项目所采用的需求规格说明书是不同的。在需求规格书说明书的编写中，是和业务需求分析紧密结合在一起的，最简单的包括需求的分类，满足业务域或业务类别，还有一些业务改进和过程改进的内容，还有一些内容是行为分析的内容。虽然需求不是设计，但需求多多少少还有一些系统最终实现后的影子，为此有一些功能性需求的编写过程中已经对功能结构进行了初步的组织。需求不一定一定要用用例图来描述，采用灵活清晰的规格化的文档描述来编写具体的需求，但避免过于复杂，例如出现很多分支。如果在需求规格说明书中放入系统原型，则是对系统界面的实现进行约束。

 

在敏捷的软件开发过程中，需求就是经过分析后的用户故事。无论哪一种方式，需求都是要经过评审、需要确认的。

 

2、设计

 

在开展软件设计前，最重要的事情是是应用系统是基于什么平台进行设计和开发，或者利用什么框架进行开发，甚至是利用过去的那一个项目框架进行开发，这直接影响后续的工作，选择不同类型的开发框架，工作量，人员投入是完全不同的。在当前技术环境下，几乎很少的软件会从零开发，都是利用已有的框架进行的。

 

在传统的软件开发过程中，是根据需求规格说明书的要求，利用概要设计、详细设计和数据库设计三种设计来完成软件应用的设计的，概要设计关注流程和功能，详细设计关注于类的代码的实现，数据库设计关注于数据库和表。将设计任务分配下去，不同的人完成不同的模块的设计方案，方案由流程图、类图等组成。利用敏捷开发方法，则省去很多步骤，不再形成规模巨大的文档，而是围绕着用户故事进行设计、开发和测试的，目标是快速交付成果。无论什么形式的设计，也都需要通过不停的优化和评审，最后形成正确有效的开发方案。

 

3、开发代码

 

开发代码是一个非常具体的工作，通过一个个键盘上的字母完成整个系统的交付，就和作家爬格子完成长篇小说一样。每个人的开发效率不同，能力不同，根据自己的能力做好估算，否则不能完成任务。开发代码前，也是需要有一些设计的，因为具体的代码实现和设计还是存在差异的。存在无数开发技巧和方法，例如开发的时候注意使用已有的类库进行代码重用，少用全局变量等等，总之，代码要清晰，增加注释。作为程序员，注释就是一切文档。

 

开发代码时，要利用配置管理系统进行版本控制，此外，不懂就问、互联网搜索是加快开发速度的关键。此外，代码也是需要进行评审的，通过评审还能够优化代码。

 

4、测试

 

测试的目的是发现软件的缺陷，保证交付的应用系统满足需求，测试是非常关键的，甚至测试的时间比开发的时间还要长，并且越是在开发末期发现的缺陷，修复缺陷所付出的成本是越多的。敏捷开发是测试驱动的，开发时就是包括测试工作的，这样才能迅速交付能用的系统。相比之下，传统模式就复杂得多，首先编写测试用例，然后开始单元测试、功能测试、集成测试、验收测试等，按部就班，发现测试问题再周期性去完善开发，周期比较长，某环节问题较多的情况下，容易让项目延期。测试还包括接口测试、性能测试、压力测试、界面测试、安全测试、安装测试等，这些都是根据不同的项目类型进行选择，如果合同中提到或者需求中提到，就需要去完成这个测试。

 

测试需要工具，自动化工具让测试事半功倍，测试出的缺陷，需要跟纪录、审查、跟踪、修改、验证、关闭、整理、分析、汇总等很多状态管理，无论过程有多么复杂，测试工作都需要去完成，毕竟，交付一个少缺陷的高质量的软件是每一个IT人的梦想。