软件项目开发的步骤（心得）

一、编写目的

    本文档的编写旨在探寻规范的软件开发流程、加快软件开发速度、提高软件开发质量、降低项目综合成本。
     IT界有一句格言：
"You can do it right; you can do it fast; you can do it cheap. Pick two." 而我们要做的就是：提供优质服务、项目周期短、成本低廉。

二、总体说明

     项目从用户需求说明书的提出，到系统的第一个完整版本的交付使用经历了若干或复杂或简单的过程，但不管项目大小如何一般需要经历以下几个步骤：
     1． 需求分析
     2． 撰写需求规格说明书
     3． 总体设计
     4． 详细设计
     5． 编码实现
     6． 测试、试运行、上线
     7． 验收
     8． 日常维护
     9． （下一个版本的循环开发）
	 在以上各步骤中尤其重要的是系统分析和撰写需求规格说明书。当定义好《需求规格说明书》后需要用户签字确认，以此作为项目验收的依据，在中大型项目中尤其重要。
   失败的项目原因很多但以下几点比较普遍：（1）商务运作中为了拉住“单子”对客户的众多纷繁复杂的要求一味的妥协让步满口答应。项目开发计划、时间表等完全依照客户意见，不以具体项目的客观事实为依据，不做认真细致严格的项目复杂度、项目工作量的评估。（2） 不做细致的用户需求分析导致项目后期的需求变更较大不能按期完成项目。

三、项目开发经历的各阶段

 在项目开发的各阶段时间比例方面，中小项目一般控制在
 1： 40% 设计
 2： 40% 编码
 3： 20% 总体设计/试运行

3．1 需求分析阶段

   研究客户需求，从中找出需求中模糊不清的地方，反复讨论确认。在不断的确认中，包括需求的总体认知、需求边界定义、目前技术条件下的可实现需求、用户界面等。通过项目组内讨论、与客户（直接客户、间接客户）讨论等方式不断清晰客户真正的需求，从而撰写《需求规格说明书》，在取得客户认可后签字，以此做为项目开发的第一个里程碑。在项目验收时以此作为验收的主要依据。
   在系统分析阶段与客户的沟通方式可以通过：（1）项目静态图、项目静态界面DEMO（2） 系统用例图（例如：rose软件的用例图） 等方式与客户沟通。

   本阶段要完成的工作有：1．撰写项目需求分析报告，本报告主要目的是项目分析人员提出需求的疑难不清问题，为与客户有效、准确沟通准备必要的材料。2．画用例图 ，描述系统各个不同用户类型与本系统及其他系统等的交互过程。3．建立项目静态界面DEMO，使得用户在项目初期就可以看到项目上线实施后的使用界面和使用方法等4． 做必要的技术预研等。

3．2撰写需求规格说明书

   需求规格说明书的撰写主要目的是把客户天马行空、纷繁复杂、凭想象等的理想需求中变成在一定时间段、一定技术条件下可实现的需求。不然项目会很难满足客户的理想需求，永远被客户的理想需求所限制，陷入一种非常被动的状态。

3．3总体设计

   在完成项目需求规格说明书后，就进入项目总体设计的阶段。
   在总体设计阶段需要完成的文档有：
   1． 《项目总体设计---概要设计说明书》
   2． 《数据库设计报告》
   3． 《项目总体开发时间表》
  在此阶段应该建立项目的正式开发环境、项目测试环境、建立项目基本开发框架且导入项目管理配置工具中（例如：CVS、VSS等）等
  在项目的以上阶段完成后，建议进行项目总体设计和总体开发准备情况的评审工作。在公司、集团专家组评审通过后本阶段结束，这算做项目的第二个里程碑。
  在进行下一阶段前，目前项目组可以对SCCB（软件变更控制委员会）提交的资料有：
  1：《需求规格说明书》
  2：《项目总体设计概要说明书》
  3：《项目界面设计说明书》（及界面DEMO）
  4：《项目数据库设计说明书》等
  5：《项目总体开发时间表》

3．4详细设计

  在项目完成总体设计和搭建完毕开发环境后，就可以进行项目的详细设计。在项目中建议详细设计由项目编写“后台”程序的资深人员编写。主要完成每个负责的业务模块从界面到业务实现到数据库连接操作的主要步骤和数据库的实现SQL。最好在条件允许的情况下编写模块单元测试程序，在整个模块编码阶段完成后进行程序单元测试工作（“测试驱动”的开发理念）。
  详细设计目的是在不编写代码和少量代码的情况下，完成项目模块的模拟编程实现。在详细设计阶段可以对项目某模块做准确的工作量统计，依此为依据整个项目比较准确的工作量就可以被统计出来。

3．5 编码实现

3．6 测试、试运行、上线

注意地方：
1.需求获取与分析
a)不要在需求获取和分析过程中吝啬你的时间，对需求的明确可以减少你以后设计和开发的改动，提高你所开发软件的可用性。你对它的轻视只可能换来对你的产品修改、计划延迟等方面的惩罚。
b)要使尽各种办法，尽量多的获取客户的需求，主要的方法包括：仔细阅读合同标书和市场资料、与客户直接的谈话交流、让用户观看或使用原型界面提出意见。另外不要忽略内部客户的一些合理需求如测试人员等。
c)进行正规的需求管理，如建立需求文档或使用需求管理数据库等。在文档或数据库中要保留每个需求的详细描述及其来源，最好还能记录一些其他细节信息（如用户的一些原始描述等），另外别忘了确定每个需求的优先级。
d)在设计前组织你的设计人员开会进行需求理解和讨论。由于阅读文字性的信息容易造成一些误解和歧义，最好让需求制定者组织会议，给相关人员（如各子系统设计人员）讲解需求并进行设计讨论。这样做有两个好处，一是避免设计与需求出现偏差，二是激发设计人员产生初步的设计想法。

2.确定结构及系统设计
a)顶层设计必须要有多人及专家参与。一个好的设计方案不可能完全出自一个人的脑袋，它往往是经历多次讨论甚至争论、多次改进与融合而最终形成的一个有创造性的妥协产物。但你要避免争论的过分激烈而导致的负面效果。转贴于：中国项目管理资源网
b)一个好的设计应包含简单的框架，细节隐藏其下。组块和模块是一个好的设计所具有的特征，在顶层设计里人们看到的是简捷的框架和功能明确的组快，在每个组快内部又能发现一个简单的框架和其他一些自包含的的组块或模块。
c)在系统设计时想想你的用户将怎样使用你的软件工作。很多时候设计人员会习惯性地从技术角度考虑系统地布局和划分，可这种技术上地合理有时可能跟使用上的合理是冲突的，所以此时考虑一下你的用户将降低你今后修改的风险。

3.有关详细设计
a)详细设计没有必要过于精细准确。目前对有关底层详细设计是否需要以及它该详细到何种程度还存在一定的争论，但认为可以不要和必须写得非常精确这两种极端思想都是有害的。详细设计的作用在于开发人员编码前整理思路，同时让别人通过审核详细设计文档检验你的思路是否正确，防止出现错误。

4.测试问题
a)繁杂但极富成效的单元测试。如果想将你的软件质量提高到一个新的档次，对开发的软件模块进行完整的单元测试是一个很好的途径，它能使开发者对自己的代码成果更加有信心。虽然一些软件项目单元测试做的很少甚至没有，并且产品在最终测试后也运行的不错，但它只能保证在与最终测试环境类似的环境中运行是安全的，超出这样一种环境范围则可能充满雷区。
b)必不可少的最终测试。如果你的项目受时间、人力等资源影响没法进行过多的单元测试，那最终测试就成了你软件产品的唯一质量保证，千万别把这一保证也丢了，没有它你的软件产品就毫无质量可言。最终测试的另一大用处是通过它可以发现一些单元测试的漏洞，完善单元测试用例。
c)根据你的软件特性选择自动测试。自动测试如果能在你的项目中使用上，将是个不错的消息，虽然目前的自动测试工具对一些特殊情况和特殊数据的细节处理略显笨拙，但用它来检验产品的基本可用性和代码修改的影响却是高效的。有时自动测试还可能帮你发现手工测试几乎不可能出现的错误情况，例如极短时间内触发多个操作造成的冲突等。

5.有关重构
a)顶层结构的重新设计。通常当你的项目出现这种情况是非常不幸的，出现的原因一般是由于原来的结构不能支持新补充的特性而不得不进行修改。这种重新设计要注意两点，一是时机最好选择在一个大的工作阶段开始时，二是在新结构中尽量移动原有代码而不是编写新代码。
b)底层模块的改进。由于当初编写时的仓猝或考虑不周使得现有模块存在这样或那样的问题并且难于理解，这种情况下进行重构改进是很有必要的。修改的方法通常为对已有代码进行整理和注释，增加模块的封闭性和稳健性。

6.新技术的运用
a)评估新技术，确定它是否可以给项目带来好处。合适的新技术可以提高产品开发效率和质量，判断某一新技术对你的项目是否合适通常需要派专人或一个小组进行小范围考察和验证。采用新技术的时机最好选择在项目开始时或项目的某些重要阶段开始时，另外千万别忘了培训你的开发人员使用它。
b)避免几种使用新技术的动机。一是为了学习新技术而在项目中使用新技术，这样只能使你的项目变成一个实验田，项目产品最终也成了实验产品。二是不要指望使用新技术能拯救陷入困境的项目，如果一个项目陷入困境，它通常需要的是清晰和稳定，未知的新技术很可能导致更大的混乱。