软件生命周期

软件生命周期

简介：

本文主要介绍软件在从无到有的整个过程当中，需要经历过的几个重要阶段，软件是如何从想做一款软件到软件可以被用户使用的产出过程。把软件从无到有再到衰亡看作一个完整的生命周期，可以将之划分为若干阶段，每个阶段会有不同的核心任务。与以往的软件生命周期不同的是当下很多企业将“迭代”概念又融入到了项目中去，这样在局部上看似乎整个周期被打乱的毫无章法，但从整体观察却仍然是有章可循。

阶段：

一：需求调研

这里的需求是指最原始的用户需求，要求产品经理与客户进行直接沟通交流，弄清三点问题：

1、要做什么，要解决什么问题
2、这些需求是在什么背景、情况下提出来的
3、软件的适应范围和目标群体是什么

二：可行性分析

当拿到客户的原始需求以后，产品经理需要对原始需求进行可行性分析，可行性分析一般包括成本、技术、法律等等方面的可行性评估，分析是否可以做、是否有能力做、是否值得做。

三：需求分析

当可行性评估结果满足的情况下，下一步将对需求进行详细的拆分，并编写 《需求规格说明书》和初步的 《用户手册》用于需求评审，需求拆分则大致可以划分为以下几类：

1、基础功能性需求
功能性需求指的是软件在力求满足客户提出的业务需求基础上，所必备的一些基础功能，例如对CRM系统来讲账号登陆、权限认证、操作日志等等这些是客户不必提出来，但对于系统来说又必不可少的功能，我们将之称为功能性需求。

2、业务性需求

业务需求主要指从软件使用者那里收集来的关于软件本身需要满足的业务能力和操作习惯有哪些，比如商城系统，客户要求能支持微信和支付宝的支付方式、商品上架要支持批量上架的能力，那么我们将这些非基础的功能需求叫做业务需求

3、性能需求

软件需要满足的并发访问量、数据量、响应速度等等软件性能方面的需求称之为性能需求

4、技术需求

这部分需求相对来讲并不多，一般出现在政府机关、金融类项目当中，比如要求不可以使用Oracle数据库、不允许使用开源框架等等奇葩的需求。这些需求往往是由于一些政策的限制导致。

5、安全需求

这部分需求相对来讲也并不多，一般是一些互联网项目，软件使用环境不可控的的情况下，比如必须有防注入、CSRF攻击的能力等出于安全角度考虑的需求。

四：需求评审

主要针对产品经理所拆分出来的详细需求点进行评审，这里需要客户的参与，以保证需求的准确性。

五：同产品方案研究

在需求评审通过以后，我们需要收集、分析市场上同类软件项目及设计方案。通过对同类产品及设计方案的研究，可进一步了解我们软件该达到的效果是什么样子的，甚至是市场竞争情况。最终决定是自研还是二次开发甚至是直接订制第三方公司产品。

六：架构设计

这里说的架构设计事实上非常宽泛，不仅仅是指软件本身的架构，而是软件涉及到的所有方面架构设计，比如web项目当中的系统集成架构、JAVA架构甚至小到前端架构，里面涵盖技术选型、前后端框架搭建、服务器数据库缓存、消息队列、任务调度等等方面的设计。而这一部分往往是制约项目进度的关键所在，例如技术选型在复杂度上面存在问题，很可能导致开发人员接受慢、难点暴露频繁、阻塞性问题频繁等等导致项目延期。所以在技术选型方面我们需要考虑以下几点：

1. 成本
2. 可伸缩性
3. 可靠性
4. 复杂性
5. 运维
6. 安全性
7. 成熟度
8. 维护成本

七、需求管理

分析需求优先级和依赖关系、规划版本、里程碑。

八、功能设计

把需求点转化为功能点，这里的设计包括数据库模型、软件UI、UE设计、流程结构、对外接口方面的设计等等，这部分涉及到的文档主要为概要 《设计说明书》与 《数据字典》等。

1、在数据库模型设计过程中需要充分考虑模型对性能的影响，对分库分表、表结构、字段、索引、主键生成等等方面都需要充分的考虑，存在同类产品的情况下一定要首先分析其数据模型的构建方式，避免闭门造车，数据模型的改动会在开发过程中带来相当大的影响。

2、流程结构的设计一般公司很难遵循，功能需求来了直接上手就做，这种情况下会导致逻辑出错，bug频频，流程结构设计是为了让开发人员更快的理解需求、理清思路，尽可能的避免后期代码逻辑上的低级错误。

3、对外接口设计遵循少而精的思想，比如查询接口，可能查询情况非常之多，很多企业会把他划分成多少查询就多少接口的设计，这样带来的后果就是维护工作量特别的大，甚至牵一发而动全身，一个改处处改，而应当将接口尽可能的收缩，把多个相近业务查询尽量融在一起，这样对接口使用者来讲不需要学习太多的接口使用，对内接口改动方面也会让开发人员更加专注于一点快速解决问题。

八、排期

根据功能点及开发团队情况，划分阶段性开发任务以及具体的任务分配，排期结果需要经过上报，在出现人员风险、技术风险情况下，需要在排期过程中预留风险解决时间或解决方案，应以3天为最大原子任务完成时间，以每两周为一次计划跟踪修正时间点，每两周做一次排期跟进，保证排期计划的准确性，以及保证规定时间内完成上线计划。那么这里在按人员分配任务的时候需要根据开发人员的能力不同，分配不同程度的开发任务，任务完成时间要通过与开发人员沟通，确定具体完成时间，大于三天的任务要再次划分。任务与任务之间一定要避免关联，避免出现你那边任务没开发完，我这边没法开发的状况。公有功能、相似功能尽量抽出交由单独人员来做，这里就可能涉及到跨业务的问题。

八、开发

根据选定的技术完成源程序编码，开发方面要求开发人员不急于敲代码，而是先摸清框架、了解透彻自己负责的业务以及相关的流程结构图，再进行开发。对于大型开发团队来说应该有单独的框架维护小组，专门对框架出现的问题及新功能新难点提供最及时的解决，保证框架本身不影响开发进度。框架部分的bug开发人员直接抛出，任务暂时挂起转至下一个开发任务，直至框架专职人员解决。

九、功能测试

测试小组根据《需求规格说明书》编写测试用例，针对每个功能点的业务、操作、目标效果要驾轻就熟。这里要强调一点，web项目当中很多测试人员居然不懂浏览器清除缓存，导致在程序更新时不是bug的bug被暴漏出来，浪费时间和人力去排查结果半天查不出结果，所以测试方面人员一定要足够专业，最起码低级的错误不要犯。这一阶段的测试强度，会直接影响上线后的维护压力。

十、性能测试

性能测试就是所谓的” 压测“，压力测试，那么这一部分测试往往会被测试人员忽略，比如一个批量业务，处理一个可以，处理一万个系统就响应超时了，这个情况时非常常见的。所以性能测试会把隐藏较深的bug全部挖掘出来。

十一、文档

系统开发测试结束以后，需要编写 《操作手册》，操作手册的编写一定要抛开技术，说白了就是让人看得懂。避免出现一些看上去高大上的技术名词，让客户感觉是在看天书。

十二、上线

十三、验收

需要列出上线功能清单，交给客户逐一功能验证、确认。

十四、维护

包括四个方面

1，改正性维护：在软件交付使用后，由于开发测试时的不彻底、不完全、必然会有一部分隐藏的错误被带到运行阶段，这些隐藏的错误在某些特定的使用环境下就会暴露。
2，适应性维护：是为适应环境的变化而修改软件的活动。
3，完善性维护：是根据用户在使用过程中提出的一些建设性意见而进行的维护活动。
4，预防性维护：是为了进一步改善软件系统的可维护性和可靠性，并为以后的改进奠定基础。