【软件开发过程所有文档获取—>关注，私信】
1 概述
软件生命周期包括软件定义、软件开发、软件维护三个过程。
2 可行性分析
目的： 该软件项目是否该做。
分析角度：
社会可行性：是否符合法律法规，是否有益社会发展，短时间内不被淘汰。
经济可行性：项目成本预算，能否带来收益。
技术可行性：该项目中涉及到的技术难点，当前技术能否完成该软件项目。
产物：可行性分析报告或者白皮书。
3 需求分析
目的：了解客户需求，明确客户对软件项目的要求。
分析内容：
功能需求：描述系统功能，一般来说会细化到每一个小的功能点，小到开发人员可以实现。
界面需求：界面整体布局、色彩、字体字号、系统皮肤、可视化大屏/app功能排版。
性能需求：系统并发能力、系统吞吐量、界面响应时间、系统高可用。
安全需求：敏感数据保护、密码复杂度要求、数据备份与恢复、网络安全策略、数据加密传输。
其他需求：不同角色拥有不同的功能权限和数据权限。
工具：脑图、EXCEL功能表、数据流图。
产物：需求规格说明书。
4 概要设计
目的：完成软件项目的大概设计。
设计内容：
功能表：详细的功能表格，包括核心字段描述及工期安排。
技术选型：选择项目开发所使用的技术，包括编程语言、数据库、框架、sdk。
架构图：总体逻辑架构图、核心业务流程图、系统之间交互时序图、系统部署架构图、网络拓扑图。
接口梳理：对内接口梳理、对外接口梳理，接口规范制定（数据格式、权限认证、数据安全传输）。
界面设计：界面展示内容、界面操作、界面跳转、数据权限（本阶段可用EXCEL完成）。
工具：EXCEL功能表、UML建模工具(亿图图示)。
产物：概要设计说明书。
5 详细设计
目的：完成软件项目功能实现的详细做法。
设计内容：
数据库设计：数据库ER图、数据库建表语句、数据库索引约束。
接口文档：定义接口请求地址、请求方式、请求参数数据结构、响应结果数据结构。
算法规范：复杂的接口需要梳理算法逻辑，必要时需要编写伪代码或者示例代码来描述。
界面设计：特殊界面需要设计界面原型图。
工具：ER图、Apipost接口文档编辑工具、原型工具。
产物：详细设计说明书。
6 编码实现
目的：根据详细设计说明书，选择编程设计语言，完成编码工作。
心得：初级开发人员在接到编码工作时，没有根据相关的设计文档进行深入的业务梳理，急于完成任务导致考虑不周，使编码工作不能适应需求的扩展、变化，这样做会导致编码逻辑不清、代码冗余、系统性能差等种种问题；即使完成工作任务，后期维护起来非常费劲；此外一旦编码有了一定进展，对于大多数人来说，就失去了重构的勇气了。研发人员需要在业务梳理和思路设计上多花时间，正所谓，工欲善其事，必先利其器。积极使用应用软件开发设计原则，提高系统内聚，降低系统耦合，增加代码复用，减少代码冗余，勤加注释，易于维护。
7 测试
目的：发现软件项目中尚未发现的问题。
方法：
黑盒测试：又叫功能性测试，只关注功能，不关注算法；包括边界值分析和等价类划分。
白盒测试：又叫结构性测试，关注内部算法是否正确；包括路径覆盖、条件覆盖、语句覆盖等。
灰盒测试：结合白盒测试和黑盒测试，既关注内部逻辑，又关注总终结果。
阶段：
单元测试：最小功能模块，是否满足正常需求。
集成测试：对某个单元模块集成接口的测试。
系统测试：对整体软件系统的功能、性能的测试。
验收测试：对软件项目进行交付前的最后测试，对照需求规格说明书和交付标准，演示软件项目功能是否满足用户需求和验收标准；（用户参与、数据真实）。
产物：测试分析报告、用户操作手册。
8 运行维护
目的：提供软件产品交付之后的售后服务，保证软件产品能够持续工作。
分类：
正确性维护：发现软件测试阶段未发现的错误，维持软件产品功能的正常运作。
适应性维护：软件适应信息技术变化和管理需求变化而进行的修改。
完善性维护：增加新的系统功能和需求。
预防性维护：前瞻性的将一些将来会用到的功能加入到系统中，预防系统被淘汰。
产物：程序维护手册。
9 软件生命周期模型
概念：软件生命周期同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生命周期（软件生存周期）。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。软件生命周期(SDLC，软件生存周期)是软件的产生直到报废的生命周期。为了使规模大、结构复杂和管理复杂的软件开发变的容易控制和管理，人们把整个软件生命周期划分为若干阶段，使得每个阶段有明确的任务，整理出软件生命周期模型。
常用模型：
瀑布模型
原型模型
V模型
敏捷开发模型
9.1 瀑布模型
模型说明：自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
特点：顺序性、依赖性、周期长。
劣势：项目回溯成本高、效率低、不灵活。
瀑布模型
9.2 原型模型
模型说明：允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，需要迅速创建一个可以运行的软件系统原型。
优势：解决需求不明确和需求理解不一致问题。
劣势：时间仓促，不断修改，导致产品质量比较差。
原型模型
9.3 V模型
模型说明：软件开发过程中的一个重要模型，由于其模型构图形似字母V，故称为V模型。
优势：提高效率，缩短项目周期，节约时间。
劣势：阶段有顺序性，并未实质提高测试的地位。
v模型
9.4 敏捷开发模型
模型说明：敏捷开发以用户的需求进化为核心，采用迭代，循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子系统，各个子系统的成果都经过测试，具备可视，可集成和可运行使用的特征。换言之，就是把一个大的项目分为多个相互联系，但也可以独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发模型
价值观：在每项对比中，后者并非全无价值，但我们更看重前者！
—–个体和互动 高于 流程和工具。
—– 可用的软件 高于 详细的文档。
—– 客户协作 高于 合同谈判。
—– 响应变化 高于 遵循计划。
敏捷原则
1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2.欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3.要持续交付可用的软件，周期从几周到几个月不等，且越短越好。
4.项目过程中，业务人员与开发人员必须在一起工作。
5.要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6.无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7.可用的软件是衡量进度的主要指标。
8.敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9.对技术的精益求精以及对设计的不断完善将提升敏捷性。
10.要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11.最佳的架构、需求和设计出自于自组织的团队。
12.团队要定期反思如何能够做到更有效，并相应地调整团队的行为。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。