IT入门知识第三部分《软件开发》（3/10）

IT入门知识大纲第三部分《软件开发》

1. 软件开发生命周期（SDLC）

1.1 需求分析

1.2 软件设计

1.3 程序编码

1.4 软件测试

1.5 项目部署

1.6 运行维护

2. 软件开发方法论

2.1 瀑布模型

2.2 敏捷开发

2.2.1 Scrum

2.2.2 Kanban

2.3 DevOps

3. 版本控制系统

3.1 Git

3.1.1 分布式架构

3.1.2 快速合并

3.1.3 支持离线工作

3.2 SVN

3.2.1 集中式架构

3.2.2 原子提交

3.2.3 对二进制文件的支持

4.结语

IT入门知识博客文章大纲第三部分《软件开发》

在当今数字化时代，软件开发已成为推动创新和企业发展的核心动力。本文将深入探讨软件开发的生命周期、方法论以及版本控制系统，为读者提供全面的软件开发知识。

1. 软件开发生命周期（SDLC）

软件开发生命周期（Software Development Life Cycle，SDLC）是指软件开发从提出、实现、使用维护到停止使用退役的过程。这个过程包括多个阶段，每个阶段都有明确的目标和任务，以确保软件项目的成功完成。软件开发生命周期是一套标准化的流程，用于指导软件从概念化到最终交付的全过程。以下是SDLC的主要阶段：

1.1 需求分析

需求分析是软件开发的第一步，目的是收集和分析用户需求，确定软件的目标和功能。这一阶段的输出通常是需求规格说明书，为后续开发提供明确的指导。

1.2 软件设计

设计阶段包括系统架构设计、用户界面设计和数据库设计。设计的目标是将需求转化为软件架构和详细设计文档。

1.3 程序编码

编码阶段是将设计文档转化为可执行代码的过程。开发者需要遵循编码规范，确保代码的质量和可维护性。

1.4 软件测试

测试是验证软件是否满足需求和质量标准的过程。测试包括单元测试、集成测试、系统测试和验收测试等多个层次。

1.5 项目部署

部署阶段是将软件发布到生产环境，供用户使用。部署策略的选择对软件的可用性和稳定性至关重要。

1.6 运行维护

维护阶段是软件生命周期的持续过程，包括错误修复、功能更新和性能优化等。

软件生命周期(Software Life Cycle,SLC)是软件的产生直到报废或停止使用的生命周期。软件生命周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，也有将以上阶段的活动组合在内的迭代阶段，即迭代作为生命周期的阶段。

软件开发生命周期的发展历程中，不同的生命周期模型被提出和实践，如瀑布模型、快速原型模型、迭代模型等，以满足不同项目和团队的需求。敏捷软件开发是近年来给软件生命周期带来最多活力的方法之一，它强调短迭代开发，以更好地响应变化和迎接竞争。

2. 软件开发方法论

软件开发方法论提供了不同的框架和流程，以确保软件开发的效率和质量。

2.1 瀑布模型

瀑布模型（Waterfall Model）是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。

瀑布模型是一种线性顺序的软件开发方法，它将软件开发过程划分为一系列阶段性的活动，每个阶段完成后才能进入下一个阶段。这种方法的优点在于其结构清晰，但缺点是不够灵活，难以适应需求的快速变化。

2.2 敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发是一种以人为核心、迭代、增量的软件开发方法论。它强调团队协作、客户反馈和快速响应变化。敏捷开发的核心是人和交互，以及快速、灵活的响应变化的能力。它通常采用如Scrum或Kanban等框架来指导开发过程。关于敏捷开发我专门写了一篇文章详细介绍，感兴趣可前往阅读：敏捷开发：拥抱变化，持续交付价值的艺术_产品敏捷开发-CSDN博客

三大角色
产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，制定软件的发布日期和交付的内容，同时有权利接收或拒绝开发团队的工作成功。
流程管理员（Scrum Master）
主要负责整个Scrum流程再项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5-10人左右，每个成员可能负责不同的技术方面，但要求每个成员必须要有很强的自我管理能力。同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

四个仪式
Sprint计划会（Sprint Planning Meeting）：在每个Sprint开始时召开，由全体人员参加。这个会议主要有两件事情要确定。①确定当前Sprint的目标 ②选定当前Sprint要处理的最具价值的用户故事，创建Sprint Backlog（需求列表）

每日站会（Daily Scrum Meeting）：一般在15分钟以内。团队成员相互交流任务的进展，计划以及遇到的困难。

Sprint评审会（Sprint Review Meeting）：又叫Sprint演示会、Sprint展示会等，是团队用来展示当前Sprint开发成果的会议。

Sprint回顾会（Sprint Retrospective Meeting）：用来回顾在当前结束的Sprint中的工作、进行经验总结、反思，并拟定响应的改进措施。

2.2.1 Scrum

Scrum是一种敏捷框架，通过定期的迭代（称为Sprint）来完成产品开发。Scrum强调团队自组织、透明沟通和持续改进。

2.2.2 Kanban

Kanban是一种可视化的项目管理方法，通过限制在制品（WIP）来优化流程效率。Kanban适用于那些需要快速响应和持续交付的软件开发项目。

Kanban板的介绍： Kanban是一种可视化的项目管理方法，它帮助团队成员理解工作流程，并管理任务和流程。Kanban板通常是一个看板，上面有多个列，代表工作的不同阶段。

流动和限制理论：

流动：工作项在系统中从一个阶段移动到另一个阶段。
限制：识别和管理工作流程中的瓶颈，以优化整体效率。

2.3 DevOps

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。

DevOps是一组实践，旨在自动化和整合软件开发（Dev）和信息技术运维（Ops）的过程，以便更快地构建、测试、发布软件。DevOps的核心在于文化变革，强调开发和运维团队之间的协作和通信。

DevOps包含development和operations，是开发和运营维护的总称。软件设计过程中，应对开发部门、运维部门进行协调，确保各项工作流程与方法高效使用，为项目管理工作提供可靠参考。基于devops软件开发源于2009年欧洲传统IT模式，对解决运维管理问题起到关键作用。为巩固软件设计与开发结果，将开发、运维与测试结合一起，形成了DevOps软件开发管理模式。

基于DevOps软件开发可对测试环境进行应用，同时可将数据包融入到软件环境中。DevOps立足全局角度，对开发效果进行分析，加强人员之间的合作与交流也是软件开发设计工作重点，应对其进行合理安排。在devops框架下，对软件进行开发可实现自动化操作，使得人机交互方案应用具有可行性。

传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法（例如敏捷软件开发），这是一个重要的课题：按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而却需要极其紧密的多部门协作。然而DevOps考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法。

需要频繁交付的企业可能更需要对DevOps有一个大致的了解。Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署，并且经常与精益创业方法联系起来。从2009年起，相关的工作组、专业组织和博客快速涌现。

DevOps的引入能对产品交付、测试、功能开发和维护（包括──曾经罕见但如今已屡见不鲜的──“热补丁”）起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。

以下几方面因素可能促使一个组织引入DevOps：

1、使用敏捷或其他软件开发过程与方法

2、业务负责人要求加快产品交付的速率

3、虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍

4、数据中心自动化技术和配置管理工具的普及

5、有一种观点认为，占主导地位的“传统”美国式管理风格（“斯隆模型 vs 丰田模型”）会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。

DevOps经常被描述为“开发团队与运营团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。

DevOps对应用程序发布的影响

在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下 [1]：

（1）减少变更范围

与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。

（2）加强发布协调

靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议、即时消息、企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。

（3）自动化

强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）

3. 版本控制系统

版本控制系统（version control system）,是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。版本控制系统不仅可以应用于软件源代码的文本文件，而且可以对任何类型的文件进行版本控制。用的比较多的如svn，git等。版本控制系统（VCS）是软件开发中不可或缺的工具，它帮助开发者管理代码的变更历史，促进团队协作。

3.1 Git

Git（读音为/gɪt/）是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。也是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。

Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper

Git是目前最流行的分布式版本控制系统。它以其速度、效率和强大的分支管理功能而受到开发者的青睐。Git支持离线工作，易于合并代码，并且能够处理大型项目。Git 代码提交注释管理规范请参考我往期文章：Git 代码提交注释管理规范_git提交备注规范-CSDN博客

3.1.1 分布式架构

Git的分布式架构允许每个开发者在本地拥有完整的代码库，包括所有分支和标签。这为团队协作提供了极大的灵活性。

3.1.2 快速合并

Git的合并操作非常快速，即使是在大型项目中也能轻松处理代码合并。

3.1.3 支持离线工作

Git允许开发者在没有网络连接的情况下工作，这对于移动开发者或网络不稳定的环境非常有用。

Git官网地址：Githttps://git-scm.com/

3.2 SVN

SVN是subversion的缩写，是一个开放源代码的版本控制系统，通过采用分支管理系统的高效管理，简而言之就是用于多个人共同开发同一个项目，实现共享资源，实现最终集中式的管理。

SVN（Subversion）是一个集中式版本控制系统，它允许开发者在单一的服务器上管理项目。SVN易于使用，对二进制文件友好，适合需要集中控制的项目。

3.2.1 集中式架构

SVN的集中式架构使得项目的所有历史和状态都存储在中央服务器上，这有助于集中管理和控制。

3.2.2 原子提交

SVN的原子提交确保了每次提交都是完整的，避免了部分提交的问题。

3.2.3 对二进制文件的支持

SVN对二进制文件的支持较好，适合需要管理大量二进制资源的项目。

4.结语

软件开发是一个不断进化的领域，随着技术的不断进步，新的工具和方法论层出不穷。理解并掌握软件开发生命周期、方法论和版本控制系统，对于任何软件开发团队来说都是至关重要的。通过这些工具和实践，我们可以更高效地构建高质量的软件，满足用户的需求并推动技术的发展。随着DevOps文化的普及和敏捷实践的深入，软件开发的未来将更加注重协作、自动化和持续交付。让我们拥抱变化，不断学习和创新，共同塑造软件开发的新篇章。