软件开发生命周期的每个阶段（软件生命周期开发过程的四个阶段）
本篇文章给大家谈谈软件开发生命周期的每个阶段，以及软件生命周期开发过程的四个阶段对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
软件生命周期七个阶段
第一阶段：假想阶段
在本阶段需要反复验证这个假想的可行性，成本，收益；如果行业内已有类似的可参考的软件那么就会简单一些，如果没有就只能利用一些模拟和预测的方法来帮忙了。在假想确定要实施的时候一定要组织一次启动会议，参会人员包括所有的利益相关方，由总裁级别的领导宣布这个项目的正式启动；目的就是给大家一个前进的方向和希望各方通力合作。
第二阶段：需求开发阶段
软件的5个特性中的易用性在本阶段要重点考虑。本阶段可能是争议最多的阶段，对于同一种业务功能需求会有多种解决方案，每一种解决方案会有一套详细的软件功能描述，不同的解决方案所需要的成本一定是不一样的，易用性也会不一样。如果站在业务部门的角度一定是易用性越好越满意，但是站在信息部门的角度如果成本超出了预算就不得不追加预算，如果不能批准就不得不和业务部门反复探讨协商了。信息部门各个方面的项目负责人一定要参与到这个阶段的讨论中，如果在某个方面的成本超出了预算一定要及时提出，包括开发方面，测试方面，硬件方面。通常见一些公司只有一个项目经理或者销售人员代表信息部门参与到这个阶段的讨论中，接受了很多成本远超出预算的业务需求，殊不知这一个人怎能精通各个方面，怎能准确地计算出成本。不知这些公司的上层领导们是怎样想的。如果是一个乙方公司这样不专业的做法通常的结果就是亏本买卖，唯一的解决办法就是不断压榨一线的技术人员。在国内这种不正常的现象很普遍。作为一个信息行业的从业人员真希望这种现象会尽快好转，多给技术人员一些尊重和成长的机会，最终形成良性循环。
通常在这个阶段一线的技术人员不会参与进来，对于参与的技术人员负责人要求比较高，他要熟悉公司的现有技术架构，使用或者复用时的成本；具有较强的沟通协调能力；对于公司财务部门，预算部门，采购部门的工作流程比较熟悉；所有的素质要求都是为了能够深刻理解和把握开篇提到的那个三角形标示出来的三个要素和高质量的标准。
站在整个项目的负责人的角度看平衡各方利害通常是很有挑战性的任务，作者曾经参加过竞越公司开办的一门叫做思维技术的课程，其中提到过从一个问题的多个解决方案中选出最适合各个利益相关方的的方法论。作者认为完全可以把这个方法论使用在本阶段争议比较多的焦点上。
如果本阶段没有争议是不正常的现象，本阶段的争议越多后面阶段的争议相对就少，站在整个项目的角度看成功率就相对高，总成本就相对低。
第三阶段：设计阶段
在上一个阶段的工作做得足够充分之后本阶段的工作才更加有意义和价值。本阶段的工作至关重要，承上启下。
软件方面：作者主张需求开发阶段参与的技术负责人，设计阶段的负责人，实现阶段的负责人，以及软件在运行期间的第三层运维支持负责人是同一个人。这四个负责人可以分开，但是要保证下一个阶段的负责人能够充分理解上一个阶段负责人的工作输出的想法并且是认可的。如果四个责任人分开会面临以下几个管理问题：
1.由于上一个阶段的负责人并不继续向下负责，所以可能出现不认真或者输出结果不达标的问题；下一个阶段的负责人可能会出现同样的问题，以至于问题一直留到最后解决，甚至于无法解决，成本高到远远超出预算。
2.知识传递的问题，如果下一个阶段的负责人不能理解上一个阶段的负责人的理念，那么就需要两位负责人在一起充分沟通达成共识，但是如果两位负责人不能达成共识又会引起另外的问题。
但是如果四个负责人都是同一个人，也许有人会质疑说一个人的精力有限，对于一个大项目来说一个人无法胜任。在这里作者必须声明作者是个敏捷开发主义者，实际工作过程中通常都是一个月或者两个月发布一次版本，测试通过就上线运行。这样一个人的精力有限问题就解决了，实际上也就是把在开篇提到的那个三角形中的范围因素设定为正好适合一个负责人能够胜任的界限。这种做法最大的好处不言而喻，项目成功率高，风险度低，也可以尽快实现软件的价值-为业务服务。也许还有人会质疑如果每一次发布的版本的新增功能太少，在架构设计方面可能会有偏差，会需要不断重新设计架构。作者一直以来的理解是软件的架构和软件的源代码是可以分开考虑的。举个形象的例子就是架构和源代码的关系就像书架和书的关系，可以在开始就准备一个大书架，然后一本一本添加书籍，很长时间都不需要换书架。如果开始准备的是一个小书架，书籍很快就会把书架填满，这时一个小书架就不够用了，解决办法可以增加一个小书架，也可以换成一个大书架。增加一个小书架就相当于增加一个子系统，换成一个大书架就相当于重新设计架构，然后增加新的模块。但是作者不能确定在开始是用一个小书架好还是用一个大书架好，如果一定要给一个观点，作者主张把书架设计成可以由一个人就能够灵活添加或者减少书架体积的模式。这时架构设计们的价值就明显地展示出来了。放书的工作就相对简单多了。
硬件方面和测试方面的道理应该是类似的。
第四阶段：实现阶段
有了质量标准，有了设计方案，接下来的工作就是加工实现了。在实现的过程中要不断检查质量是否达标，是否是按照设计方案来实现的。如果这个阶段的负责人是设计阶段的负责人和将来的第三层运维支持负责人，那么这两项检查工作会很顺利。软件方面一定要有一个源代码管理工具。硬件方面一定要有一个配置管理工具。
第五阶段：质量检查阶段
实现阶段的质量检查属于内检，本阶段的质量检查属于外检，换成专业的质量检查人员从另外的角度看问题，看是否能够达到质量标准。作者主张需求开发阶段参与的技术负责人，设计阶段的负责人，质量检查阶段的负责人和运维期间的重复质量检查负责人都由同一个人来担当。
本阶段还面临一个管理问题就是质量检查人员和开发人员之间的沟通问题，所以缺陷管理工具和完善的质量报告是很必要的。对于软件上线运行后出现的事故，调查事故原因如果是一个未发现的软件缺陷，如果一定要有惩罚措施，作者主张开发方面负责承担60%的责任，质量检查方面负责40%的责任。作者不主张奖惩措施，主张主人翁精神的培养。因为很多时候功与过实在是难以划定清楚，必然会引起不公平现象的出现；但是让大家明白公司业绩好了，奖金就会多，福利就会提升以及公司存在个人的工作就会存在这样的道理却很容易。但是主人翁精神的培养是个太过高级的话题，超出了作者的工作经历所覆盖的范围，只是有一点深刻体会就是公司要给予员工家的感觉，只要是一如既往全心全意为公司服务，那么公司就没有抛弃这位家人的理由，每年工资的提升至少不少于通货膨胀率。作者认为这样的家人应该会有比较强的主人翁精神的。
第六阶段：部署阶段
这个阶段实现了软件和硬件的结合。作者能够提到的几点就是：
1.本阶段可以使用自动化部署工具。
2.可以把软件的部署分为应用程序层和数据库层。
3.如果使用的是Windows服务器和域管理，应用程序到数据库之间的连接一定要使用集成身份验证。
4.应用程序池的账号一定要使用服务账号，密码要使用密码管理工具。
5.服务账号只能用在应用程序池用来连接应用程序和数据库，不能远程登录服务器和使用在连接数据库的客户端软件上。
6.如果不是域管理能够做到的，那么所有的密码都应该使用加密功能。
软件开发分为什么阶段？
软件的生命周期中，通常分为三大阶段，每个阶段又分若干子阶段：
⑴ 计划阶段：分为问题定义、可行性研究（是决定软件项目是否开发的关键）。
⑵ 开发阶段：在开发前期分为需求分析、总体设计、详细设计三个子阶段，在开发后期分为编码、测试两个子阶段。前期必须形成的文档有：软件需求说明书，软件设计规格说明书。
⑶ 运行阶段：主要任务是软件维护。为了排除软件系统中仍然可能隐含的错误，扩充软件功能。
.软件生命周期分为哪几个阶段?简要说明各阶段的主要任务
软件生命周期分为问题定义、可行性研究、需求分析、开发阶段、维护这5个阶段。各个阶段的主要任务是如下。
1、问题定义
要求系统分析员与用户进行交流，弄清“用户需要计算机解决什么问题”然后提出关于“系统目标与范围的说明”，提交用户审查和确认。
2、可行性研究
一方面在于把待开发的系统的目标以明确的语言描述出来，另一方面从经济、技术、法律等多方面进行可行性分析。
3、需求分析
弄清用户对软件系统的全部需求，编写需求规格说明书和初步的用户手册，提交评审。
4、开发阶段
开发阶段由四个阶段组成：概要设计、详细设计、实现、测试
五、维护
维护包括四个方面：
（1）改正性维护：在软件交付使用后，由于开发测试时的不彻底、不完全、必然会有一部分隐藏的错误被带到运行阶段，这些隐藏的错误在某些特定的使用环境下就会暴露。
（2）适应性维护：是为适应环境的变化而修改软件的活动。
（3）完善性维护：是根据用户在使用过程中提出的一些建设性意见而进行的维护活动。
（4）预防性维护：是为了进一步改善软件系统的可维护性和可靠性，并为以后的改进奠定基础。
扩展资料：
软件常见周期模型：
1、瀑布模型
瀑布模型首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段?可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。
瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。
2、迭代式模型
迭代式模型是RUP推荐的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。
所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。
3、快速原型模型
快速原型模型在功能上等价于产品的一个子集。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。
它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原型将被抛弃。
因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。至于保留原型方面，也是有一种叫做增量模型是这么做的，但这种模型并不为大家所接受的。
参考资料来源：百度百科-软件生命周期
软件生命周期划分成哪些阶段?
软件计划与可行性研究阶段、需求分析阶段、软件设计阶段、软件编码阶段、软件测试阶段和软件运行与维护阶段。
1、软件计划与可行性研究阶段：此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
2、需求分析阶段：在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，也是在整个软件开发过程中不断变化和深入的阶段，能够为整个软件开发项目的成功打下良好的基础。
3、软件设计阶段（概要设计和详细设计）：主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。
4、软件编码阶段：是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
5、软件测试阶段：在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。
6、软件运行和维护阶段：是软件生命周期中持续时间最长的阶段，包括纠错性维护和改进性维护两个方面。
扩展资料
早期的软件生命周期往往是说“软件从计划、需求开始，经历分析设计、实现、部署、维护，直到最后逐渐消亡的”。
这是受到了第一个软件生命周期模型---瀑布模型影响，上述语句实质上简要的描述了瀑布型生命周期。
软件生命周期不再只考虑瀑布型生命周期，另外常见的软件生命周期模型有原型模型、螺旋模型、迭代模型。所以软件生命周期说明应当不再包括瀑布型生命周期中的典型阶段。
因此，对软件生命周期及软件生命周期模型采用如下定义：
1、软件生命周期是指软件的产生直到成熟的全部过程。
2、软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。
参考资料来源：百度百科--软件生命周期
软件生命周期包括哪六个阶段
软件生命周期包括问题的定义及规划、 需求分析、软件设计、程序编码、软件测试、运行维护这六个阶段。
1、问题的定义及规划。
此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
2、 需求分析。
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。
3、软件设计。
此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。
4、程序编码。
此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。
5、软件测试。
在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。
6、运行维护。
软件维护是软件生命周期中持续时间最长的阶段。软件的维护包括纠错性维护和改进性维护两个方面。
软件开发生命周期的每个阶段的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于软件生命周期开发过程的四个阶段、软件开发生命周期的每个阶段的信息别忘了在本站进行查找喔。
