为什么软件开发周期是预估的2~3倍

1、软件开发生命周期
软件生命周期由软件定义、软件开发和运行维护3个时期组成，每个阶段又进一步划分为若干个阶段。

软件定义时期的任务是：确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表。这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划分成3个阶段，即问题定义、可行性研究和需求分析。
开发时期具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：总体设计，详细设计、编码和单元测试，综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。
维护时期的主要任务是使软件持久地满足用户的需要。具体地说，当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件以满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。
2、软件生命周期每个阶段的基本任务
问题定义
      问题定义必须要回答的关键问题是“要解决的问题是什么？”，週过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户时确认。

可行性研究
        这个阶段要回答的关键问题是：“对于上一个阶段所确定的问题有行得通的解决办法吗？“”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计过程，也就是在较抽象的高层次上进行的分析和设计过程。可行性研究应该比较简短，这程个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。

      可行性研究的结果是客户作出是否继续进行这项工程的决定的重要依据，一股说来，只有扱资可能取得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投人更多的人力物力。及时终止不值得投资的工程项目，可以避免更大的浪费。需求分析

需求分析
      这个阶段的任务仍然不是具体地解决间题，而是准确地确定”为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。用户了解他们所面对的问题，知道必须做什么。但是通常不能完整准确地表达出他们的要求，史不知道怎样利用计算机解决他们的问题；软件开发人员知道怎样用软件实现人们的要求，但是对特定用户的具体要求并不完全清楚。因此，系统分析员在需求分析阶段必须和用户密切配合，充分交流信息．以得出经过用户确认的系统逻辑模型。通常用数据流图、数据学典和简要的算法表ボ系统的逻辑模型。

     在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础，因此必须试准确完整地体现用户的要求。这个阶段的一项重要任务，是用正式文档准确地记录对目标系统的需求，这份文档通常称为规格说明书（ specification )。

总体设计
这个阶段必须回答的关键问题是：“概括地说，应该怎样实现目标系统？”总体设计义称为概要设计。首先，应该设计出实现目标系统的几种可能的方案。通常至少应该设计出低成本、中等成本和高成本3种方案。软件工程师应该用适当的表达工具描述每种方案，分析每种方案的优缺点，并在充分权衡各种方案的利弊的基础上，推荐一个最佳方案。此外，应该制定出实现最佳方案的详细计划。如果客户接受所推荐的方案，则应该进一步完成卜述的另一项主要任务。

上述设计工作确定了解决问题的策略及目标系统中应包含的程序，但是，怎样设计这些程序呢？软件设计的一条基本原理就是，程序应该模块化，也就是说，一个程序应该由若干个规模适中的模块按合理的层次结构组织而成。因此，总体设计的另一项主要任务就是设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系。

详细设计
总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化，也就是回答下面这个关键问题：“应该怎样具体地实现这个系统呢？”这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。
详细设计也称为模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。

编码和单元测试
这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。
程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时用汇编语言），把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。

综合测试
这个阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的
安求。最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试，）谓验收测试则是铵照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积参加下）对目标系统进行验收）
必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。
为了使用户能够积极参加验收测试，并且在系统投人生产性运行以后能够正确有效地使用这个系统，通常需要以正式的或非正式的方式对用户进行培训。
通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求，也可以决定测试和调试过程什么时候可以结束。应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，作为软件配置的一个组成部分。

软件维护
    虽然没有把维护阶段进一步划分成更小的阶段，但是实际上每一项维护活动都应该是经过提出维护要求（或报告问题），分析维护要求，提出维护方案，审批维护方案，确定维护以用2计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软件定义和开发的全过程。每一项护活动都应该准确地记录下来，作为正式的文档资料加以保存。

3.为什么软件开发周期总是预估的2~3倍？
理想很美好，现实很骨感，这是效率的问题还是能力的缺失，要认真设计出来一个系统进行软件开发是一个漫长且复杂的过程，不仅包含需求分析、设计、编码、测试、实施、维护等不同的过程，还涉及到开发工具、开发人员、项目管理、风险等众多因素，不同因素会对周期预估产生不同的影响。当低估项目周期时，会造成人力低估、成本预算低估、日程过短，最终人力资源耗尽，成本超出预算，为完成项目不得不赶工，影响项目质量。而项目周期估计过长，也会带来成本估计过高，人力资源利用不充分效率低下的后果。所以，过长过短的预估周期都是不好的。我们知道在软件开发的过程中总有可能出现各种各样的问题，比如需求分析中软件的功能可能达不到客户的需求，就像文章中所以提到的：看上去前方道路多曲折啊。走40英里路只能到「月亮湾」的一半。这么一看，整趟路途不是原来的400英里，而是500英里! 又或者是编码时一个小小的错误没有被检查出来，又或者是项目经理没有规划好任务的时间分配，导致有的模块时间太长，有的模块时间完全不够用，计划总是赶不上变化的。这些意外都是不可避免的，我们要做的是尽可能的减少损失，冷静分析我们的遇到的问题，所以，团队之间要相互合作，及时沟通，提高开发的效率；软件开发团队的经验不足，遇到问题时不能快速有效地解决。

4.我觉得产生软件开发周期总是预估的2~3倍的原因
1.需求的不断变化与理解的差异,用户表达的是这样的，而程序员的理解是这样的，且客户需求不定，增加需求，组织协调不畅。
2.在需求分析阶段出现了错误,构造软件框架时做的东西没有也无法全量覆盖 ，导致与实际落地产品差距甚大。
3.项目经理没有处理好任务的时间分配。有的任务分配时间过长，浪费了时间，有的任务分配时间过短，没时间去完成。
4.开发人员对实现目标的可能出现的问题，估计不足，往往会低估问题的复杂程度。风险意识不足，没有意识到风险或者意识到风险响应错误不及时。
5.程序员大多是乐观的，而事实经常相反。
人的因素，技术因素，管理因素，分配因素等诸多因素的综合影响下,造成了开发周期的推迟。