敏捷方法在软件项目开发中的实践
－2772－
0引言目前国内很多企业都成立信息技术部，主要承担企业内中小型软件项目的开发和维护，面临开发时间紧迫、人手不足、需求不断变化的困难，传统的重量级的软件开发方法常常无法应对这样的挑战。面临的问题举例如下：
(1)业务人员尽管非常清楚业务流程，但却无法清楚地描述自己的需求。开发人员尽管完成大量的需求分析和项目文档的规范编写，但由于经验不足，对业务流程不熟悉，沟通中存在偏差，最后导致完成的项目很难满足实际的需要；
(2)项目开发过程中，出现技术人员离职的情况，由于新招聘的开发人员必须读懂大量的开发文档才能进行后续的开发工作，这常常影响了项目开发的进程；
(3)软件运行后，常常根据反馈意见改善某些使用不便的功能或根据业务的变化新增加某些功能，在这过程中常由于时间紧凑，并不进行严格的测试就投入使用，一旦出现问题，在复杂的运行环境下修正错误需要较长的时间，影响了技术部门的反应速度。
1敏捷方法的观点与原则[1~4]
敏捷方法是基于实践的方法，通过非常短的迭代周期来
应对需求的变化，为解决以上这些问题提供了轻量级的项目管理和开发、维护的思路。敏捷方法是20世纪90年代后期，面临在需求和技术的不断变化，软件行业借鉴了制造业“敏捷制造”的思想，逐渐形成的软件开发模式。2001年著名的敏捷宣言的提出，标志着敏捷方法的思想逐步走向成熟。
敏捷方法的整体目标以人为主和欢迎变化。敏捷方法是“适应性”而非“预测性”的，目的是成为适应变化的过程。而传统重量级软件开发方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发，在计划制定完成后拒绝变化。敏捷方法是“面向人”的而非“面向过程”的，强调软件开发应当是一项愉快的活动，试图使软件开发工作能够利用人的特点，充分发挥人的创造能力。
敏捷方法主要有以下4个观点：①个体和交互胜过过程和工具。软件开发需要开发团队和客户有效地工作在一起；②可以工作的软件胜过面面俱到的文档。满足需求的软件比
收稿日期：2006-06-12E-mail ：zjdandyjt@https://www.sodocs.net/doc/9e15627195.html,
作者简介：赵剑冬(1977－)，男，广东湛江人，博士研究生，研究方向为管理系统仿真和管理信息系统、计算机网络；林健(1958－)，男，福建福州人，博士，博士生导师，研究方向为复杂管理系统仿真、管理信息系统。
敏捷方法在软件项目开发中的实践
赵剑冬，林
健
(华南理工大学工商管理学院，广东广州510641)
摘
要：目前很多企业内中小型软件项目面临开发时间紧迫、人手不足、需求不断变化的困难，传统重量级的软件开发方法无法应对这样的挑战。敏捷方法是基于实践的软件开发方法学，为解决这类轻量级项目管理和开发所碰到的问题提供了新的思路。通过分析敏捷方法的主要目标、观点和原则，并结合一个实际的管理信息系统项目开发，从项目计划、项目文档、重构的改进和项目维护的4个方面探讨了敏捷方法的实践应用。实践证明，采用敏捷方法的观点和原则进行必要的改进，能取得项目开发的成功。
关键词：项目管理;敏捷方法;管理信息系统;重构;迭代中图法分类号：TP311
文献标识码：A
文章编号：1000-7024(2007)12-2772-03
Practices for agile methodology in software project development
ZHAO Jian-dong,
LIN Jian
(School of Business Administration,South China University of Technology,Guangzhou 510641,China )
Abstract ：Many enterprises face difficulties,such as urgent task,insufficient manpower and demand change,in software project de-velopments.The traditional heavy development methodology can not meet that challenge.Agile methodology is a software development methodology based on practice,which brings a new way for small and middle scale project management and development.The main objects,standpoints and principles of agile methodology and how to apply it in developing management information system are introduced.Project plan,document management,refactoring and project maintenance are discussed in the application of agile methodology.The practice proves that the applying of agile methodology and improvement on it can lead to success of project development.Key words ：project management;agile methodology;management information system;refactoring;iteration
2007年6月计算机工程与设计
June 2007
第28卷第12期Vol.28
No.12
Computer Engineering and Design
文档更重要；③客户合作胜过合同谈判。开发过程就应及时与客户互动和沟通；④响应变化胜过遵循计划。业务环境在变化，技术随着时间也在变化，变化是软件开发的现实。除此外，敏捷方法还包含了实践中总结出来的开发计划、团队模式等方面的12条重要经验原则。但敏捷方法并不包含具体操作指导，所以我们结合一个管理信息系统的实际项目开发流程，对敏捷方法的具体实践作了一些探讨。该项目是一个集团销售综合管理系统，包括行政系统、生产系统、研发系统、物流系统、结算系统、直销系统、分销系统、专卖系统、会员系统、代销系统、电子商务销售系统和经销系统12个子系统，60多个模块。而开发团队仅仅包括2名编码人员和1名美工。
2敏捷方法在软件项目开发中的实践
2.1迭代式项目计划
敏捷方法的一个重要观点是迭代、循序渐进的开发方法[5]。在敏捷开发中，软件项目的构建被划分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简而言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
在该项目中我们的做法是在基本的需求分析后，根据从简单到复杂和实现功能的依赖关系给出的迭代开发计划如表1所示。在第1个版本时，首先设计一个小型的可供演示的原型，给用户一个初步的印象，将要开发的系统是什么样子的，以便在细化阶段设计出完整的用户界面原型。得到用户初步肯定后，进行第1个版本的开发。在此阶段，用户在第1个版本基础上准备第2个版本的基本想法。完成第1个版本后，用户进行使用。如果存在问题，进行修改并再使用。最后，审核通过后才进行第2个版本的开发，同时用户准备第3个版本的基本想法。如此类推，完成项目的开发。在开发在该项目中，我们切实体会到，用户对自己的系统的需求不明确，他们知道应该如何做，但很难将需求表述出来。通过界面来与用户交流，使用户较好地表达了自己的需求。通过迭代式的项目开发计划，用户的意见可以不断反馈到开发中，及时进行调整，这也符合敏捷方法中欢迎客户的参与这一主要观点。
2.2项目文档
敏捷方法强调可以工作的软件胜过面面俱到的文档。没有文档的软件是一种灾难，但过多的文档比过少的文档更糟糕。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导[6]。对于敏捷方法来说，编写并维护系统原理和数据结构方面的文档将总是一个好主意。
在该项目中我们的做法是保持系统说明书和数据库说明书这两种关键的文档在开发过程中及时地更新和修正。系统说明书包括基本的需求分析、系统的高层结构和概括的设计原理、系统的架构设计、模块划分等。通过阅读该文档可以对整个项目有基本的了解，熟悉整体的系统架构。在该系统说明书中，我们较多采用Visio设计的界面图案，这比单纯文字描述直观。数据库说明书的样式如图1所示，通过该说明书可以对整个项目涉及的数据有清晰的了解。在数据库数据备份丢失的时候，数据库说明书作为最原始的设计文档，可以参考地用来恢复数据库表初始结构。
除此以外，要求在程序源码的开头加注该源码的基本功能介绍及其它备注信息，比较难懂的程序部分加以注释，保证源码和其它辅助项目信息成为一体，并不产生额外的项目文档。
通过以上的步骤，大大减轻开发人员的文档编写工作量，提高了项目的开发速度。出现技术人员离职时，新增人员通过系统说明书和数据库说明书，结合系统界面和源码注释，能较快地理解前任的工作，迅速投入到后续开发工作中去。
2.3重构的改进
敏捷方法的一个重要原则就是重构[7]。重构是在不改变代码行为的前提下，对其进行一系列小的改造，旨在改进系统结构的实践活动。实践中，重构改进代码质量的同时，也会新产生一些错误，敏捷方法的建议是在每次细微改造后，运行单元测试以确保改造没有造成任何破坏，然后再做下一次改造[8]。
由于系统越来越复杂，单元测试并不保证整个系统最终是正常运行的。我们从系统的整体出发，在重构中引入基于异常处理的系统日志机制。在每次重构后充分利用系统日志的功能监控系统的运行，及时找出错误源。具体包括两步，第1步在系统框架层必须定义一个系统日志写入的接口Clog类，其中包含AddLog方法，供所有其它的代码调用。下面这段C#代码是记录日志的方法，注意到代码中捕捉异常但不处理。
public static int AddLog(string p_buf){
String logfile="serverlog\\"+DateTime.Now.ToShortDate-
表1项目开发计划
版本计划版本1版本2版本3版本4时间安排10工作日15工作日18工作日25工作日
实现功能企业基本信息管理，
系统功能管理
雇员管理，客户
管理，目标管理
采购管理，库存管理资金管理，财务管理，统计分析
详细模块公告发布，收发信
息，基本资料，日志
管理，权限管理等
人事信息维护账工作业绩，
薪酬福利，客户资料录入，客
户拜访记录，客户投诉等
采购申请，申请资金安排，采购
订单，采购收货，请货单，调拨
单，退货申请单，盘点等
费用支出单，其它收入，内部转账，会计科目，记账凭账，待摊
费用，固定资产，现金日记账，银行日记账，研发费用分析、分
担表，生产企业效应核算分析表，行政费用分析、分担统计表等
数据表：XXX建表日期：200X年X月X日
字段名称标识名称数据类型空否默认值说明
Product_ID产品编号Int N
－2773－
String()+".txt";
//如果没有serverlog目录则创建该目录
if(!Directory.Exists("serverlog"))Directory.CreateDirec-tory("serverlog");
try{
StreamWriter streamwriter=new StreamWriter(logfile, true);
String temp=p_buf+"at"+DateTime.Now.ToLongTime-String();
streamwriter.WriteLine(temp);
streamwriter.Close();
}catch(Exception){
return-1;
}
return0;
}
第2步对于业务实现层的每一个公有的方法，应该在其开始和结束、异常出现时记录日志，其内容可包括时间、类名、方法名、异常信息和操作参数等内容。以下我们假设业务类Product的一个Sell的方法，对应的C#程序框架如下：public string sell(string p_Parameter){
代码A//变量定义
Try{
Clog.AddLog(“Product_Sell_Start”);
代码B//业务处理逻辑代码
}catch(Exception e){
Clog.AddLog("Product类_Sell方法处理"+p_Parameter+ "参数错误,错误信息："+e.Message);
}finally{
Clog.AddLog(“Product_Sell_Stop”);
}
}
代码B中的业务处理逻辑代码涉及较多的是数据库操作，我们用数据库事务集中连续的数据操作，错误时进行回滚。对应的C#程序框架如下：
SqlConnection myConnection=new SqlConnection(数据库连接串);
myConnection.Open();
SqlTransaction myTrans=myConnection.BeginTransaction(); //使用New新生成一个事务
SqlCommand myCommand=new SqlCommand();
myCommand.Transaction=myTrans;
try{
https://www.sodocs.net/doc/9e15627195.html,mandText=需要执行的SQL语句;
myCommand.ExecuteNonQuery();
代码C//0-n个数据操作
https://www.sodocs.net/doc/9e15627195.html,mit();//提交事务
}catch(Exception e){
myTrans.Rollback();//事务回滚
}finally{
myConnection.Close();
}
每次重构后，碰到错误，通过系统日志记录的类名、方法名和异常信息内容就可以立刻准确定位错误源。异常处理机制则确保程序仍然能稳定运行，数据库事务的回滚机制保证数据库数据的正确。软件开发完成后，可以对方法开始和结束的日志记录程序行进行屏蔽，保留捕捉异常的日志记录。在系统的实际部署中，应配置系统日志的大小限制，以防系统日志的无限增长，影响系统的性能。
2.4项目的运行维护
软件投入使用后，我们确定一个试运行期，例如2周到3个月。在试运行期每天查看系统产生的日志，通过记录的异常信息及时地修改程序的错误。实践中证明，当基本不产生异常错误日志的时候，系统就处于稳定运行状态了。
在软件日常维护中，由于管理信息系统的开发是一个在维护中不断改进和完善的过程，会不断地进行功能和模块的扩展和变更，以便适应业务环境变化的需要。新增或变更功能模块时，如果发生程序错误，基于异常处理的系统日志机制也能迅速记录系统异常的地方。通过系统日志，技术人员能在复杂运行环境中迅速定位错误源，不需要重新再现错误的发生，再进行调试，极大地方便了软件的维护工作。
3结束语
在广州历隆有限公司技术部门(6个人编制)承担的多个项目的实践中，我们初步贯彻了敏捷方法的一些项目管理原则和开发方法，取得了项目开发的成功。在软件运行的日常维护中，尽管出现技术人员流动的情况，新招聘的技术人员也能较快接受这些项目管理原则和开发方法，熟悉前任开发人员的软件程序架构，承担起后续的软件开发和维护工作。实践中，中小企业信息部门的团队项目开发应该灵活采用敏捷方法的观点和原则，甚至必要的改进，使项目开发获得更大成功。
参考文献:
[1]Robert C.Martin.Agile software development:Principles,pat-
terns,and practices[M].北京:中国电力出版社,2003.
[2]沈雷,沈备军.敏捷方法的研究与实践[J].计算机工程,2005,
31(7):219-221.
[3]邓靖颖,黄穗.敏捷开发：极限编程在管理信息系统开发中的
实践探讨[J].计算机工程,2004,30(24):189-191.
[4]沈备军,陈诚,居德华.敏捷软件过程的研究[J].计算机研究与
发展,2002,39(11):1456-14563.
[5]李航.敏捷型软件开发方法与极限编程概述[J].计算机工程与
设计,2003,24(10):116-118.
[6]何坚,何鸿肃.工程项目中文档的科学管理[J].工业工程,2002,
5(5):53-55.
[7]李艳红,李思志.信息系统快速响应变化的能力——敏捷性研
究[J].计算机应用,2005,25(6):1430-1431.
[8]Larman Craig.Agile and iterative development:A manager's
guide[M].北京:中国电力出版社,2004.
－2774－
软件项目开发各阶段
目录
1. 范围 本指南用于指导软件开发者为南京市交通局开发软件项目的过程，通过规范软件项目承担单位的开发过程达到提高软件质量，降低维护成本的目的。开发者应根据本指南进行软件开发和编制软件开发文档。本指南是对软件项目承担单位的基本要求。 2. 总体要求 2.1 总体功能要求 网络应用环境以Internet/Intranet技术为核心。 开发者应在充分分析需求的基础上，选择采用B/S结构或者C/S结构。 软件系统的数据库应依照《南京市交通局信息化数据库建设规范》进行设计和建设。 本指南中没有规定开发者采用何种具体的软件工程开发方法，开发者可根据项目具体特点、自身擅长来选择采用面向过程的方法、面向对象的方法或面向数据的方法，但建议开发商使用面向对象软件工程的方法，如：采用目前被广泛使用的RUP(Rational Unified Process)方法来进行分析、设计和开发。 2.2 软件开发平台要求 数据库管理系统： Oracle 9i以上版本 开发工具系统： Microsoft Visual Studio 2010 OS系统： Windows 2003 完全支持TCP/IP协议 2.3 软件项目的开发实施过程管理要求 2.3.1 软件项目实施过程总体要求 （一）开发者提交软件开发工作大纲，交通局组织专家组对工作大纲进行评审，并提出整改意见。 （二）通过评审后，开发者根据整改意见完善工作大纲，经过交通局认可后组织项目组进行软件开发。软件开发工作按照需求分析、概要设计、详细设计、编码、测试等几个阶段进行，在开发过程中，开发者需分阶段提交相关文档。 （三）在软件开发工作完成后，开发者应向交通局提交完整的软件文档，交通局组织
软件开发流程图.docx
软件开发流程图 项目前期 需 求 变 化项目启动 需 要系统实变现 更系统调测 开始 获取用户需 编制初步方 编制进度 / 跟踪 需求基本确定 编制详细预 配置内部资 分配开发任 系统实现 控制/调 无需变更 技术调测 PM：获取 EU主要的关键性需求 PM：根据 GM安排编制简略 / 详细的建设方案 PM：基于内部预算对 EU提供费用报价 PM：与 EU确认需求变动及方案、费用调整 PM：完成详细内部预算并提交给GM PM：通过内部项目管理系统配置详细人员、进度安排 PM：移交 EU需求给PG，安排 PG开发任务 PG：根据 EU需求及 PM要求，执行开发任务 PM：通过内部项目管理系统审核PG工作日志， 确认 EU需求变动，执行进度控制，必要时变 更人员安排及内部预算 PG：技术调测及修改；根据TE 测试文档调试修改集成测
部署试
TE：进行集成测试，编制测试文档，提交PM，送达PG 未 通 过通过 通过项目后期 系统验收 结束PG：部署至外部服务器 PM：系统初验 EU：试用 PG ： 部署正式上线，编制开发字典，提交PM M 获得试用意见 TE：编制系统操作手册、功能列表，提交PM PM：提交开发字典、操作手册、功能列表给EU,通过内部项目管理系统结项，向 GM汇报 备注： PM (Project Manager)：项目经理PG (Programmer)：程序员EU (End-User)：最终用户TE (Test Engineer)：测试工程师GM (General Manager)：总经理 硬件开发流程图
产品调研 / 新产品立设计开发执行子项目分支执 首样评审业务部主导 研发部 研发部主导 业务部 研发部主导 研发部主导 业务部 采购部 研发部主导 业务部 工程部 1、资料搜集并拟定产品需求表 ① 预期的用途，特定的功能、性能和安全要求； ② 类似产品的名称，型号或参考实物样板； ③ 细化客户对产品的外观、功能、价格等要求； ④拟定《产品需求表》展开评审会议 , 并形成《技术可行性分 析报告》同时交总经理审批。 2、研发经理组织结构、电子与ID 协调定义，进行3D 图形设计 与修改，形成《产品外观效果图》《产品3D 图》、《产品规 格书》会同业务、总经理展开评审会议，若评审通过，由业 务形成《立案通知书》和《产品研发任务书》交总经 理审批，输出交研发部进行设计开发工作。 注： B 类项目可直接评估形成《产品研发任务书》 3、研发部签收《产品研发任务书》 , 项目负责人根据《产品外 观效果图》、《产品 3D 图》、《产品规格书》、《产品研发 任务书》的要求对设计工作进行策划形成《项目进度表》，包括： ① 设计过程中各阶段时间和工作内容的安排； ② 设计评审、设计验证、设计确认的安排； ③ 设计过程中各项工作的分工及各小组之间的接口及工 作顺序等； 4、项目负责人根据《项目进度表》推进设计，每设计阶段 必须与研发部经理进行设计评审，设计评审完成后研发部 完成硬件打样，首样制作由该项目各负责工程师共同制作， 并完成《样机测试记录表》、《操作说明》、《首样评审表》， 并填写《线路板通知书》、《开模申请表》交研发经理审核。研发 部根据设计评审结论编制 BOM、电路原理图、贴片图的PDF电子 版、结构爆炸图、《样机测试记录表》、《软件测试 记录表》、《样机测试记录表》并存档。 5、结构电子依《首样评审表》内容，对需要做设计变更的 尤其产品外观改动的，需经总经理批准的《设计变更表》， 才能对其模具设计修改，并填写《改模记录表》。首样评审完 成修改通过后，发放至工程部由工程部汇总完成《工程 样机测试汇总表》，3 个工作日后由项目负责人组织电子、 结构、工程、品质、业务进行项目首样评审。
软件开发流程
快视信息软件开发流程规范： 用户需求：软件项目首先由客户经理(CM，Custom Management)接洽客户的较大的需求。这时的需求叫市场需求（或叫用户需求），客户经理会进行各个项目的安排，即对项目的启动时间和发布时间进行规划和设置。 项目经理(PM，Project Management)对客户经理负责。项目经理的需求是根据客户经理给的，项目经理不和用户（客户）直接接触（通过客户经理接触），负责和用户进行需求洽谈和沟通的是客户经理。一个项目的需求在一般情况下是不准变更的，如果有需求理解方面的不清楚可以进行沟通，但是需求是不变更的。如果用户有新的需求，一般规划在下一个版本中。因为需求变更了，这个目的时间就要进行调整，就不能按计划进行和完成。客户经理提交给项目经理的是需求规格说明书。 一、项目开工会 在项目经理领到客户经理分配给的需求后，做项目计划，具体做项目人员的确定、需求的分解（需求分解到每个人）、代码量的估计，项目各个阶段时间的划分和工作量的计划、质量指标的设定。这时项目经理需要输出的文档是项目需求分解任务书、项目计划PPT、及做好整个项目需要填写的一系列表格。然后组织项目组成员和客户经理CM、QA(质量审计经理)进行项目开工会。这时这个项目就算真正启动，计算工作量时，即计算这个项目总共花了多少个工时，工时是项目经理做计划的时间也算在内，再加上项目开工会和后续各个阶段总共花的总工时数，还有各个阶段开会所花的时间。在项目开工会上，各个成员就明确了这个项目是属于增强型项目，还是其他项目的项目性质，增强型项目的意思是说在原来上一版本的基础上又根据新的需求进行增强型开发。还有要明确项目最后开发出的新增代码量有多少，最后要明确每个人的需求任务，接下来着手进行SRS的写作。 二、SRS阶段：System/Software Requirment Specification 软件需求规格说明 在项目开工会后，项目组就开始按照在项目开工会上项目经理的需求任务分解的任务开始进行SRS的写作。 一般项目经理给你的一个子需求任务，你这时需要分解为更小的需求。一般一个需求的写作是按这样进行的。先简单介绍这个需求，然后把这个需求设计成黑盒的形式，即输入，处理过程、输出。这些都需要写详细，任何一个需求都写成这种形式，输入是什么，处理过程是什么，输出结果是什么。处理过程需要用Visio或者PPT画出处理流程图，流程图要很详细。每一步的各种情况都要表示和考虑到。对异常情况也要考虑和进行处理。还有要说明在原来的基础上怎么改动，具体方法要进行说明。设计的数据库表结构，要给出脚本，SQL语句，表结构需说明每个字段，哪些是主键，你在这个需求处理过程中哪里使用了哪些表，需要进行哪些操作，都需要说明。这里需要设计和编制《数据库设计说明书》文档。该文档中描述该系统中设计出的所有的数据库表结构和各字段类型。还有多个操作对象要画序列图表示出按时序的处理过程。这个SRS文档就相当于我们平时毕业设计或者一个题目的详细设计阶段达到的水平，甚至比它更详细。每个项目组成员都把自己的需求的SRS文档写出来之后放到配置库中，然后每个人对项目组其他成员的（非自己的）SRS文档进行Review（评审）,对每个SRS文档在每页发现或者纠正的错误数不能低于一定的数目，而且要保留批注记录，经过Review的（保留批注的）文档要放到配置库的Review文件夹下，这是进行项目质量指标收集的重要依据，是QA 进行调阅和审计的资料。项目经理要对SRS文档、SRS Review文档进行汇总。在汇总后组织项目组全体成员进行SRS阶段会议，对每个人写的SRS进行评审会议（讨论和提意见），对别人给你提的修改意见你要一一进行说明，说明为什么不改，怎么改的，是什么问题，问题严重程度属于什么级别，而且都要填表，也是QA进行审计的内容。开完会后如果每个人完成的都差不多，然后安排半天或者一天的时间进行返工，主要是进行修改文档，按在会上讨论的结果和别人给你的Review 文档结果（评审结果）进行准一修改和完善。然后再进行SRS阶段开会，如果都做的比较到位和具体、符合要求，即关闭SRS阶段。这时SRS阶段的花费的工时数和一些质量活动指标就出来了，比如你这个SRS文档写了几页，每页的错误数是多少，返工修改用了多少时间，然后这些这个比率也会自动计算出来。进而可以判断这个阶段的质量。每个项目组成员在每天工作完毕后都要进行Time Sheet 的填写，必须具体到半个小时，这是统计和分析的需要。填写必须真实。 三、UTP、STP阶段（UTP、STP写作） UTP Unit Test Plan 单元测试计划 STP System Test Plan
浅谈敏捷项目管理在软件开发中的应用
浅谈敏捷项目管理在软件开发中的应用 摘要：本文先介绍了使用传统项目管理技术管理软件开发项目的方法，然后介绍了使用敏捷项目管理的初步实践，通过两者比较，提出了使用敏捷项目管理进行软件开发的方法。 一、使用传统项目管理技术管理软件开发项目的方法 按照《人月神话》的说法，软件开发是个焦油坑，书店里关于软件开发管理的书籍林良满目，各个软件开发组织也在尝试和应用不同的软件开发管理办法，希望寻找到“软件开发的银弹”。 在软件开发管理中，引入项目管理的办法，已经得到广大软件开发管理人员的一致认同，但对于具体实施何种项目管理办法，各个软件开发组织都有不同的答案，更多的迷茫，因为引入的项目管理办法不能从根本上解决软件开发项目面临的进度拖后、费用超支等问题，软件开发的银弹到底在哪里？ 以下是笔者对国内软件开发组织不同项目管理成熟度的归纳和总结，大概可以分如下几类;1)小作坊、混沌形的，这样的组织还处在接单求生存的阶段，管理者还根本没有项目的意识，以满足客户需求、定制开发和回款为第一要务；2）尝试按照项目管理的思路与方法管理软件开发项目，但发现推
行困难，不得要领，目前很多中小型的软件开发组织都处于这个阶段；3）大型的软件企业，已经通过CMM|ISO认证、有足够的资源做保障，实行规范的项目管理做法，如一些软件外包工厂。 本文主要讲述处于第二个层次的软件开发组织的项目管理问题。软件开发项目管理涉及非常多的内容，从软件开发本身的业务出发，有需求管理、变更控制、配置管理、测试管理、系统分析与设计等；从项目管理的知识领域角度，有范围管理、时间管理、沟通管理、人力资源管理等内容。 按照传统的经典项目管理方法，通过一定的项目管理模板与IT工具，总结多个项目的经验，笔者总结有如下经典步骤来完成项目管理的计划编制与进度控制过程： 计划编制的经典步骤： ①建立企业和项目资源库：这个是进行项目管理的基础工作。 ②设置项目日历、资源日历。 ③设置项目的主要里程碑点。 ④在WBS（工作包）下列出工作清单（Task，Activity）。工作分解结构（WBS）和作业是进行项目范围管理的途径。 ⑤对每个Task估计工期。 ⑥连接每个Task间的逻辑关系（SS，FS，FS，FF，延时）。
软件开发项目实施方案
软件开发项目实施方案-CAL-FENGHAI-(2020YEAR-YICAI)_JINGBIAN
软件开发项目实施方案 篇一：软件项目实施方案范文 一、软件项目实施方案概述 软件产品，特别是行业解决方案软件产品不同于一般的商品，用户购买软件产品之后，不能立即进行使用，需要软件公司的技术人员在软件技术、软件功能、软件操作等方面进行系统调试、软件功能实现、人员培训、软件上线使用、后期维护等一系列的工作，我们将这一系列的工作称为软件项目实施。大量的软件公司项目实施案例证明，软件项目是否成功、用户的软件使用情况是否顺利、是否提高了用户的工作效率和管理水平，不仅取决于软件产品本身的质量，软件项目实施的质量效果也对后期用户应用的情况起到非常重要的影响。项目实施规范主要包括项目启动阶段、需求调研确认阶段、软件功能实现确认阶段、数据标准化初装阶段、系统培训阶段、系统安装测试及试运行阶段、总体验收阶段、系统交接阶段
等八个阶段工作内容，每个阶段下面有不同的工作事项，各个阶段之间都是承上启下关系，上一阶段的顺利完成是保证下一阶段的工作开展的基础。下面将按照每个项目实施阶段分别介绍。 二、软件项目实施方案介绍 （一）项目启动阶段 此阶段处于整个项目实施工作的最前期，由成立项目组、前期调研、编制总体项目计划、启动会四个阶段组成。 此阶段主任务： 公司： 在合同签定后，指定项目经理，成立项目组，授权项目组织完成项目目标。公司项目组：进行前期项目调研，与用户共同成立项目实施组织，编制《总体项目计划》，召开项目启动会。 商务经理： 配合公司项目组，将积累的项目和用户信息转交给项目组。将项目组正式介绍给用户，配合项目组建立与用户的联系。
软件项目工作流程图
售前准备 利水新华（北京）科技有限公司质量记录 软件项目开发流程图 开始 售 前 项 目 实 销售立项 软件组 综合组 商务 技 术 支 持 任 务 书 销售立项报告 合同评审记录表 签订合同 工 程 立 项 任 务 书 施 设计开发 开发任务书 需求分析 工程立项报告书 实施策划 测试记录及问题处理表 进度管理表 集成测试 安装调试 申请表 安装调试 培训 评估表 用户 测试 测 试 记 录 项目移交 申请表 初验 报验申请表 试运行 及 表理处题问 项 目 服 项目移交 接收内容 登记表 项目维护 终验申请 终验 终验报告 质保期维护 务 服 务 及 维 护 记 录 结束 1
实施策划利水新华（北京）科技有限公司质量记录 实施流程图（一） 售前控制 编写立项报告?工程立项报告书立项评审 N ?评审记录 客户Y评审 通过?立项通知?变更申请 需求分析 Y 客户沟通、交流 编写软件需求规格说明书 ?软件需求规格说明书 ?测试用例 N 需求评审 编制项目 测试用例 编制项目进度 评审 通过 Y 任务分发 ?交流纪要 ?变更记录 ?进度管理表 ?客供财产清单 ?开发任务书 ?空间数据或美工处理任务书 ?采购申请 ?进度报告 ?评审记录 ?变更申请 系统设计 2
实施流程图（二） 需求分析 系 统 设 计 编写 需求解读 软件设计说明书 数据库设计说明书 ?软件设计说明书 ?数据库设计说明书 N 设计评审评审 通过 Y ?评审记录?进度管理表?进度报告 编制开发进度?变更申请 具体任务分配 软 件 编 码实单元测试 代码编写?安装维护手册 ?用户手册 ?软件程序编写规范 ?源代码 现 代码修改 测试问题修手册编写 ?测试记录及问题处理表 ?进度管理表 ?进度报告 ?变更申请 改 项?测试计划 目 测 试 项目集成测试编写测试报告编制培训大纲 安装调试 3?用户培训大纲（教材）?测试分析报告 ?测试记录及问题处理表?进度管理表 ?进度报告 ?变更申请
敏捷开发流程详解
敏捷开发流程详解by yangdl 1敏捷开发流程 ?敏捷软件开发核心是迭代式开发，增量交付。 ?每一次迭代都建立在稳定的质量基础上，并作为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈。 ?迭代型的方法就是将整个软件生命周期分成多个小的迭代，每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。 ?迭代建议采用固定的周期（1-4）周，可以每个迭代周期不一定要相同，但迭代内工作不能完成，应该缩减交付范围而不是延长周期。 1.1敏捷流程详解图-敏捷流程图 1.2敏捷流程三种角色及其职责
1.3敏捷开发流程详解 1.3.1流程图详解步骤 1.制定产品需求列表 ?PO收集来自客户、市场、领导等渠道的信息，从业务角度和市场价值编制一份按优先级排序的、明确的、可度量的、合理的产品需求列表； 2.召开计划会议 ?PO召集TM和SM（也可邀请其他利益相关者参加）召开计划会议（发布计划会议和冲刺会议一块开），发布计划主要是说明产品完整交付给客户的计划时间和交付物， ?冲刺计划就是确定该冲刺阶的长度（建议冲刺长度1-4周）、目标和冲刺任务单及其工作量估算
（以理想人天manday=7.5h估算，单位为小时计算），会议时间建议不要超过6h时间； ?在计划会议上就需要进行确认，是否需要使用持续集成；若使用持续集成，团队需要每天下班前至少提交一次私有构建成功的代码到服务器，并且要求写详细的日志信息；若不使用持续集 成，团队每天有完成任务单的情况，都需要在svn上以增量形式发包并通知到相关人员； ?项目计划会议上可以确定每天站立会时间及其规则要求（建议会议时间在15-20分钟左右），每个人回答3个问题：昨天做了什么，遇到什么问题，今天要做什么。具体问题讨论及其解决， 在私下进行沟通，不要在会议上讨论。站立会上只有TM人员有发言权，其他人员不要干预，SM 主要是维护秩序、规则及其引导作用。 3.需求分析、设计、编码和测试： ?计划会议结束后，TM获取各自的冲刺任务单进行后面的需求分析、设计、编码和测试； ?这里特别要说明的是，开发和测试是并行工作，必要的文档还是需要输出（如：讨论次数较多的功能点、备选方案很多但最后确认一种、重要功能、业务逻辑复杂的等等）。具体情况，需要 项目组根据实际情况决定，但客户要求交付的文档必须要输出； 4.冲刺任务单和燃尽图更新 每天SM需要根据每日站立会上TM反馈的情况，进行更新冲刺任务单和燃尽图或SM和TM之间达成共识，TM各自完成后进行更改状态，这里涉及到的文档都会有相对应的模板供参考使用。 5.迭代周期结束点 ?已到迭代周期结束点，只有哪些经过测试通过的冲刺需求列表才能算是真正的完成，其他未经过测试或测试不通过的不能算是完成。 ?这里要特别注意，所谓的测试通过不是说要把所有的问题都解决才算是通过，这个要根据项目具体的要求和规定来定。还没有达到迭代结束点，该冲刺任务需求列表就完成，可以从产品需 求列表中挑选优先级高的进行开发。 6.冲刺评审会议 ?TM需要召开冲刺评审会议，邀请PO、客户或客户代表来参加，由这些客户或客户代表来表决是否满足需求和期望目标。一般会议时间建议不要超过2个小时，参加人员除PO及其相关利益 人来参加外，TM全体成员，也可以邀请其他相关人员参加。 7.冲刺回顾会议 ?迭代输出的增量交付可能会引起原产品需求列表的改变，可能需要更新原产品需求列表；最后TM需要开展本次迭代的好的实践和不足的改进机会，最终稿由SM整理汇总，作为下一次的迭 代的经验参考。回顾会议建议时间不用太长，一般15-30分钟即可，全体人员都需要参加，包括：
中小型软件项目开发的管理方法
2012年第12期 ／目前，有些企业只考虑如何降低成本，认为中小型软件项目开发不需要严格的管理。事实恰恰相反，中小型软件项目不仅需要进行项目管理，而且还应结合项目的特点，采取适合项目要求的管理方法。 中小型软件项目开发中存在的问题 与大型软件项目相比，中小型软件项目具有灵活性高、项目功能和开发人员较少、开发周期较短的特点。这些特点使得软件项目看起来较简单，容易成功实现，因而企业往往忽视了对项目进行科学管理，在项目开发中出现一些问题。 １．项目管理中的问题 （１ ）项目进度难以估计。因将要开发的项目较小，企业对其没有足够的认识，无法确定项目的规模及开发各阶段需要的时间，更无法制定出能切实起到指导和控制项目进度作用的日程表，结果实际完成时间与估计完成时间有较大差别，致使项目开发陷入困境。 （２）项目组成员职责划分不明确。因参与开发的项目组成员较少，各成员职责划分不明确，所有成员都把主要精力放在编码上，由此造成两个问题：一是在项目开发中许多其他工作没有专人负责，包括开发环境的选择、相关工具的选择和有效应用、版本控制、变更管理和缺陷管理等。二是在项目开发过程中，许多工作产生“扯皮” 现象，如对测试中发现的缺陷相互推诿。２．项目开发过程中的问题 （１）项目需求分析不充分。对软件开发的需求分析不重视，不能详尽描述其具体功能，不了解用户的重要需求和新需求。在未充分进行需求分析的情况下，就开始项目设计和编码，导致在项目开发过程中不断有新的用户需求出现，致使项目开发没有明确的方向，甚至用户不认可开发出的产品。 （２）设计过程不规范。开发人员少，意味着不同人员在程序之间交互、接口相对少；开发周期短，意味着同样几个人员从头到尾负责一个项目。这两者虽然是小项目的优势，但是却让人容易犯错误。比如，在开发过程中，往往是几个人粗略讨论基本的数据结构、函数接口， 未建立正式的文档。缺少文档资料或文档资料不规范，是中小型软件项目管理普遍存在的问题。这种问题会造成危险：一是有的人员可能会对软件的接口、结构在理解上有偏差，而这种偏差可能会造成以后返工。二是因在讨论时忽略了某些情况，等大家都按当时的分工完成各自的工作后，才发现各个模块组合起来却形不成一个完整的系统。其原因在于系统设计不充分， 没有一个负责协调的人员监控整个开发过程。 三是一旦有人中途退出开发小组，新来的人员就难以理解别人做好的代码，索性自己从头做起。四是未建立相关文档，日后软件维护和版本升级都较困难。 （３）软件测试过程敷衍了事。在软件项目开发过程中，不经过单元测试而直接进入系统测试的现象屡有发生，其原因是虽然每个模块相对较简单，但是为了测试一个模块需要建立测试程序。比如， 测试一个函数是否正确，应该用测试数据调用该函数，需要编写测试数据，而有的开发人员嫌麻烦，认为其他模块很快就出来了，直接用真正的数据运行几次即可。 其实这种方法的效率较低，将大量时间用在了模块上的一个错误定位。另外，由于这种测试不完全，因此某些边界情况容易被忽视。 （４）软件缺陷无法控制。软件项目开发中容易产生项目分析、设计和编码等各阶段的缺陷。因对各个阶段缺少必要的测试、 复查和审查，导致产生一些缺陷。在修改缺陷过程中还不断产生新的缺陷，使缺陷很难弥补、产品很难集成，浪费了大量的时间和精力。 以上问题常常导致项目工期延长、资金投入增加，引起用户的不满，甚至造成项目开发失败。 中小型软件项目开发的管理方法 软件项目管理是为了使该项目能够按照预定的成本、 进度、质量顺利完成，通过计划、组织、控制等，合理配置和使用各种资源，对成本、人员、进度、质量、风险等进行分析和管理，以达到既定目标的过程。软件项目管理包括收集项目信息和计划、成本、质量、配置、开发人员等管理。规模较大的软件项目开发主要分为六个阶段：需求分析、 概要设计、详细设计、编码、测试、安装、维中小型软件项目开发的管理方法 ■广东东莞／潘玉茹 61
软件项目开发过程与思想
计算机软件尤其是数据库软件，成为了当代计算机应用的主流。因此软件开发人员就必须掌握正确的开发手段，了解软件开发的主要过程，这样心中对软件项目才有清醒的认识，才能达到事半功倍的效果。本文就软件开发过程中的一些方法，结合本人开发过的一些软件项目做一些详细论述。 1 开发前的准备工作 一般软件项目在开发前都有系统任务书，主要规定软件的开发目标、主要任务、功能、性能指标及研制人员和经费、进度等安排，作为系统设计开发和检验的基本依据。 系统任务书的基本框架如下： （1）引言 包括编写目的，背景，参考资料。 （2）系统的目标及任务 包括系统建设目标，系统的主要任务，系统性能指标，系统标准化要求。 （3）系统的结构及功能 包括系统应用组成及结构，系统主要功能。 （4）系统的规模及进度要求 包括系统规模，系统研制进度，人员计划。 但是系统任务书只是这个软件项目的一个基本要求，针对具体情况，软件开发人员和需求分析人员就要联合对软件项目的细节进行具体分析，必要时还要进行实地调研，然后共同商讨写出系统的需求分析，需求分析的编写目的在于： a. 说明系统在军事方面、技术方面、经济方面和社会条件方面实现的可行性和必要性； b. 分析原系统（工作环境）现状,描述待开发系统的详细需求，提供用户和开发人员之间沟通的基础，提供项目设计的基本信息。 需求分析报告的基本框架如下： （1）概述 包括编写目的，背景，参考资料，术语及缩写词。 （2）对现有系统的分析 （3）待开发系统的详细需求
包括功能需求，使用范围，业务流程，用户界面，输出要求，故障处理。 （4）使用环境 包括网络环境，硬件环境，软件环境，与其他系统的关系，安全与保密。 （5）可行性分析 包括技术可行性分析，经济可行性分析，人员可行性分析，影响待开发系统的主要因素。 （6）结论意见 2 软件开发过程 有了系统任务书和需求分析报告，软件设计人员就要对软件项目的实现进行系统分析，系统分析包括系统的总体方案，系统的设计说明，作为软件设计的依据。具体说明如下。 2.1 系统总体方案 在系统开发单位和用户充分交互、理解的基础上，提出系统的技术构架，对系统功能、性能等主要指标作描述，对实现方法和要求作规定，是系统进行详细设计的依据。 系统总体方案基本框架包括： （1）引言 包括：编写目的，背景，参考资料，术语及定义。 （2）项目概述 包括： --项目的主要内容 --系统需求分析：①用户需求调查分析②现行系统的现状调查分析。 --系统功能：①系统的功能要求②系统主要技术性能。 --系统的数据要求：①基础数据②业务数据③交换数据④其它数据。 --系统的设计要求：①技术结构要求②系统划分及其接口要求③系统运行环境要求④系统标准化综合要求。 （3）实施总计划 包括：进度，预算，问题和措施。
软件项目集成开发流程及文档
软件项目集成开发 一、项目组织架构 Ａ 项目经理 负责分析、设计和协调工作。随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等，同时给每个开发人员明确的任务书。 在项目周期内项目经理最好不要更换。大项目需要配备专门的系统分析师和系统设计师。 Ｂ 开发人员 熟悉针对软件开发的编程工具，并具有丰富的编程经验，负责完成不同层与模块的编程工作。 开发人员数量视系统模块数量和开发难度而定。 Ｃ 业务需求人员 熟悉业务工作流程，有丰富的业务经验。 业务需求人员的选择应覆盖系统所服务的业务部门。 Ｄ 文档整理人员 随时整理系统开发过程中相关的技术文档。 作为业务支撑，文档整理人员需熟悉软件开发的流程、文档管理、文档模板。 项目组织架构 项目经理 开发人员 业务需求人员 文档整理人员 测试工程师
Ｅ测试工程师 专门进行代码的测试工作，并且计划和执行源代码复审，负责有关返工的任何反馈意见（有条件可配置）。
二、项目流程管理 系统开发的过程必须符合IT 项目开发流程的规律，整个过程应包含但不仅限于以下环节： 需求调研是软件开发的最初阶段。需求调研的结果确立了软件开发的方向。软件设计是后续开发步骤及软件维护工作的基础。 在项目实施的过程中，项目实施者大多把精力放在了编码阶段，而需求调研和系统设计往往不被重视。没有严格的需求调研和分析，最终的软件产品会偏离用户的真正需求。如果没有设计，只能建立一个不稳定的系统结构。如下图所示：
在项目实施过程中，以上各个流程都不应该被忽略（重大项目更是如此），任何一个环节的遗失都可能引起项目方向的偏差，甚至失败。项目管理者可以在此基础上，完善项目管理流程，以降低项目实施的风险。 三、项目文档管理 项目管理者必须在系统开发过程中做好项目文档管理。项目文档是项目实施的依据，也是项目设计、编码、测试、修正、培训和验收的依据。 根据以上项目流程，项目实施过程中应包含以下所必须的文档：
软件开发部规章制度及软件项目管理方法
软件开发部规章制度及软件项目管理方法 第一部分：软件开发部规章制度 一、日常工作制度： 1、关于休假、加班： 严格遵守公司的考勤制度，如有事，提前书面形式填写请假申请，批准后方可休假，如情况紧急不能提前填写请假申请，要电话请示上级领导，并在休假后补办请假手续。 开发部人员在项目紧张时尽量不提出请假申请。 研发人员原则上不安排加班，研发进度根据公司要求结合项目实际由项目组长负责制定，项目组长协调安排工作。项目组长根据进度需要安排的加班，加班费用由项目奖金中支出。公司工作需要硬性安排的加班，加班费有公司支出。相关标准按照国家相关制度执行。 2、开发部员工守则： 遵纪守法，忠于职守，克己奉公。 维护公司声誉，保护公司利益。 服从领导，关心下属，团结互助。 爱护公物，节约开支，杜绝浪费。 努力学习，提高水平，精通业务。 积极进取，勇于开拓，创新贡献。 3、员工工作日志： ●工作日志制度的目的是形成严格的工作跟踪和积累习惯，要求部门中项目负责人以下 人员按要求每日记录。 ●工作日志是部门员工的工作记录载体，起到部分绩效考核和浮动工资的确定依据的作 用。 ●工作日志包含每日计划和完成情况，每日工作始终时间，每日工作饱和度（5为最高， 1为最低，如为请假，请注明“事假”或“病假”），次周计划，以及问题、意见和建议。 ●工作日志严格要求每日填写，绝不允许在上交前统一填写。填写时注意清空原有内容。 如发现某些栏目多周雷同的情况，将进行警告。 ●每日工作内容如无特殊情况，至少需要写3条以上。叙述工作内容要求尽可能说明清 楚。不允许简单的如“修改错误”的描述。 ●工作日志严格要求在次周上午10:00前提交。不提交工作周报将适当予以惩罚。对于 未提交日志的人员，部门经理保证当周内口头通知。 ●工作日志以Email形式提交给项目负责人和部门经理。部门经理收到后保证第一时间
软件项目开发工作流程
软件项目开发工作流程 一、简述 对于一个新项目，从可行性研究到产品交货整个生存阶段将经历如下十大流程： 1、项目可行性研究阶段 2、立项阶段 3、需求分析阶段 4、开发策划阶段 5、设计阶段 6、编码实现阶段 7、测试阶段 8、验收阶段 9、产品交付使用 10、维护阶段 二、项目组基本组成及岗位职责 新项目立项时会成立项目组，不同的项目组成员有不同的职责，一个项目组成员也可以身兼多职，但不可身兼全职。 a项目负责人：负责项目的管理、组织、对技术、进度、质量全面负责。 b质量保证人员：负责质量保证工作计划的落实和软件的质量保证。 C配臵管理人员：负责本项目的配臵管理工作，对本项目的文档、程序是否符合规程文件的要求进行形式化的检查。 D分析人员：主要负责本项目的需求分析工作。 E设计人员：主要负责本项目的设计工作。 F程序员：按设计要求和有关标准进行编程工作。 G测试人员：负责单元测试、组合测试和总装测试工作。 H文档人员：负责本项目有关文档的编写工作。 I产品经理：协助进行产品研制计划制定、产品发布与产品推广等,在产品开发中，充分代表用户的利益，提供建议,负责在产品功能与出品日期二者之间的权衡;负责产品市场营销、产品销售和市场推广过程。（通常由营销部门或中试部门人员担任） 三、软件开发流程 3．1 可行性研究阶段 如果是公司自主开发项目，可行性研究通常是由公司技术负责人根据公司产品规划和市场需求，在要开展新项目前通过部门负责人指定人员进行的前期调研工作，可行性研究负责人员对产品的市场需求、技术发展、市场定位、功能需
求、经济效益、进度需求、风险分析等进行可行性研究，提供产品立项建议，拟制可行性研究报告，由部门负责人指定营销部门配合可行性分析人员，技术负责人协助安排。可行性分析完毕后由总工办组织对可行性研究报告进行评审，评审通过后，总工办组织进行立项工作。 如果是系统集成部外接的系统集成项目，在系统集成部与客户签订合同之前，均应对将签项目进行资源、技术、市场的可行性分析，可行性分析通过后、签订合同前由总工办组织相关人员对合同条款进行评审，评审通过后，总工办组织进行立项工作。 本阶段提交的文档：项目可行性研究任务书（技术负责人或部门负责人下达） 项目可行性研究报告（可行性研究人员编写） 系统集成项目合同 质量记录：可行性分析评审报告 3．2立项阶段 可行性分析评审通过后，由开发部门经理下达立项任务，指定相关人员填写立项申请报告报批。报批通过后，由部门经理与技术负责人协商，下达开发任务书，经技术负责人审核确认后，报公司批准。批准立项后项目进度应以立项申请报告中的阶段进度为准，如果进度要调整，需填写进度调整申请报告报批。 本阶段提交的文档：项目立项申请报告 开发任务书 3．3 需求分析阶段 承办单位根据交办单位提出的技术要求和相应的软件任务书以及其它有关文件，与交办单位协作，确定详细的软件需求，该阶段完成的软件需求规格说明经审定和批准后将作为整个软件开发工作的基础列入配臵管理的基线，在本阶段可利用快速原型法使比较含糊的具有不确定性的软件需求（主要是功能）明确化。能给本公司开发的软件的“需求基线”确定提供一个讨论、进一步完善的基础。在本阶段，由产品经理负责，其他人员配合，编写产品规格说明书，此说明书面向最终用户和领导，主要描绘产品的形状以及功能、性能、功能特性、性能特性。由项目经理负责编写系统技术方案书，描述公司初次使用的技术的详细解决方案。本阶段完毕后对需求分析进行评审，出具需求分析评审报告。 本阶段提交的文档：软件需求规格说明书。 原型分析说明书 产品规格说明书 系统技术方案书 质量记录：需求分析评审报告 提交的软件：产品的原型（注：如果时间有限，可以只编写原型分析说明书而不作原型） 3．4开发策化阶段
一个完整的软件开发流程
一个完整的软件开发流程 一、开发流程图 二、过程产物及要求 本表主要列出开发阶段需要输出的过程产物，包括产物名称、成果描述、负责人及备注，即谁、在什么时间、应该提供什么内容、提供内容的基本方向和形式是什么。 三、过程说明 (一)项目启动 1、产品经理和项目干系人确定项目方向，产品型项目的干系人包括公司领导、产品总监、技术总监等，项目的话则包括客户方领导、主要执行人等。
2、公司领导确认项目组团队组成，包括产品经理、研发项目经理、研发工程师、测试团队等。 3、明确项目管理制度，每个阶段的成果产物需要进行相应的评审，评审有相应的《会议纪要》;从项目启动起，研发项目经理每周提供《项目研发周报》;测试阶段，测试工程师每周提供《项目测试周报》。 4、产品经理进行需求调研，输出《需求调研》文档。需求调研的方式主要有背景资料调查和访谈。 5、产品经理完成《业务梳理》。首先，明确每个项目的目标;其次，梳理项目涉及的角色;再来，每个角色要进行的事项;最后，再梳理整个系统分哪些端口，要有哪些业务模块，每个模块再包含哪些功能。 (二)需求阶段 1、进入可视化产物的输出阶段，产品经理提供最简单也最接近成品的《产品原型》，线框图形式即可。在这个过程中还可能产生的包括业务流程图和页面跳转流程图。业务流程图侧重在不同节点不同角色所进行的操作，页面跳转流程图主要指不同界面间的跳转关系。项目管理者联盟 2、产品经理面向整个团队，进行需求的讲解。 3、研发项目经理根据需求及项目要求，明确《项目里程碑》。根据项目里程表，完成《产品开发计划》，明确详细阶段的时间点，最后根据开发计划，进行《项目任务分解》，完成项目的分工。 4、研发工程师按照各自的分工，进入概要需求阶段。《概要需求》旨在让研发工程师初步理解业务，评估技术可行性。 (三)设计阶段 1、UI设计师根据产品的原型，输出《界面效果图》，并提供界面的标注，最后根据主要的界面，提供一套《UI设计规范》。UI设计规范主要是明确常用界面形式尺寸等，方便研发快速开发。UI设计常涵盖交互的内容。 2、研发工程师在界面效果图，输出《需求规格》，需求规格应包含最终要实现的内容的一切要素。 3、研发工程师完成《概要设计》、《通讯协议》及《表结构设计》，及完成正式编码前的一系列研发设计工作。 (四)开发阶段项目经理博客 1、研发工程师正式进入编码阶段，这个过程虽然大部分时间用来写代码，但是可能还需要进行技术预研、进行需求确认。
敏捷软件开发
敏捷软件开发:SRP单一职责原则 (2009-03-24 20:30:24) 转载 标签： it 这条原则实际就是体现内聚性原则的体现，一个模块的组成元素之间的功能相关性。把内聚性概念扩展一下：把内聚性和引起一个模块或者类改变的作用力联系起来。 一个类应该只有一个发生变化的原因。若Game类有2个不同的职责，一个是记录当前轮，另一个式计算分数，最后要把这两个职责分离到两个类中。为何把这两个职责分在单独的类中呢？因为每个职责都是变化的一个轴线，当需求变化会反映为类的职责的变化。如果一个类承担了多于一个职责，那么引起它变化的原因就会有多个。 如果一个类承担的职责太多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或抑制这个类完成其他职责的能力，这种耦合或导致脆弱的设计，当变化发生时，设计会遭受到预想不到的破坏。 定义职责：如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，有时候我们很难注意到这点，我们习惯以组的形式去考虑职责。 public interface Modem{ public void Dial(String pno); public void Handup(); public void Send(char c); public char Recv(); } 接口包括了2个职责，第一个职责是连接管理，第二个职责是数据通信。 如果应用程序的变化方式总是导致这两个职责同时变化，那么就不要分离他们，分开他们就会有不必要的复杂性味道。仅当变化发生时，变化的轴线才有实际意义，如果没有征兆，那么应用SRP或者任何其他原则都是比明智的。 分离耦合的职责：经常会有一些和硬件或者操作系统的细节有关的原因，迫使我们把不愿意耦合在一起的东西欧和在一起了。然而，对于应用的其余部分来说，通过分离他们的接口我们已经解耦概念。 如果ModenImplementation implemet DataChannel,Conection。ModenImplementation看起来是一个混杂物，或者有缺陷的类，所有的依赖关系都是从它发出来的。谁都不需要依赖它，谁都不需要知道它的存在。因此，我们已经把丑陋的部分隐藏起来了。其丑陋性不会泄露出来，污染应用程序的其它部分。 持久化：如Emplyee:CalculatePay,Store,Emplyee类包括了业务规则和对于持久化的控制，这两个职责在大多数情况下绝不应该混合在一起。业务规则往往会频繁地变化，而持久化的方式却不会如此频繁的变化，并且变化的原因也不一样。把持久化系统和业务规则绑定在一起是自讨苦吃的做法。如果发现这种情况存在了，应该使用FACADE、dao或者proxy模式对设计进行重构，分离这两个原则。 SRP是所有原则中最简单的原则之一，也是最难正确运用的原则之一。
IT软件系统开发方案说明
IT软件系统开发方案
一、软件项目实施方案概述 软件产品用户购买软件产品之后，不能立即进行使用，需要软件公司的技术人员在软件技术、软件功能、软件操作等方面进行系统调试、软件功能实现、人员培训、软件上线使用、后期维护等一系列的工作，我们将这一系列的工作称为软件项目实施。大量的软件公司项目实施案例证明，软件项目是否成功、用户的软件使用情况是否顺利、是否提高了用户的工作效率和管理水平，不仅取决于软件产品本身的质量，软件项目实施的质量效果也对后期用户应用的情况起到非常重要的影响。 项目实施规范主要包括项目启动阶段、需求调研确认阶段、软件功能实现确认阶段、数据标准化初装阶段、系统培训阶段、系统安装测试及试运行阶段、总体验收阶段、系统交接阶段等八个阶段工作内容。下面将分别介绍每个项目实施阶段。 二、软件项目实施方案 （一）项目启动阶段 此阶段处于整个项目实施工作的最前期，由成立项目组、前期调研、编制总体项目计划、启动会四个阶段组成。 阶段主任务 1、成立项目组：
部门经理接到实施申请后，任命项目经理，指定项目目标，由部门经理及项目经理一起指定项目组成员及成员任务，并报总经理签署《项目任务书》。 2、前期调研： 项目经理及项目组成员，在商务人员配合下，建立与用户的联系，对合同、用户进行调研。填写《用户及合同信息表》。在项目商务谈判中，商务经理积累了大量的信息，项目组首先应收集商务和合同信息，并与商务经理一起识别哪些个体和组织是项目的干系人，确定他们的需求和期望，以确保项目开发顺利。 3、编制《项目总体计划》： 《项目总体计划》主要包括以下几方面内容：项目描述，项目目标、主要项目阶段、里程碑、可交付成果等。 4、启动会： 项目组与用户共同召开的宣布项目实施正式开始的会议。会程安排如下： ?共同组建项目实施组织，实施组织的权利和职责；双方签署《项目实施协议》；?项目组介绍《项目总体计划》和《项目实施协议》，包括以下内容：项目目标、主要项目阶段、里程碑、可交付成果及计划的职责分配（包括用户的）； ?项目实施中项目管理的必要性和如何进行项目管理，项目的质量如何控制；?项目实施中用户的参与和领导的支持的重要作用； ?阶段验收、技术交接和项目结束后如何对用户提供后续服务。 （二）需求调研确认阶段 此阶段的主要工作是软件公司的项目实施人员向用户调查用户对系统的需求，包括管理流程调研、功能需求调研、报表要求调研、查询需求调研等，实施人员调研完成后，会编写《需求调研分析手册》，并交付用户进行确认，待用户对《需求调研分析手册》上所提到的需求确认完毕后，项目实施人员将以此为依据进行软件功能的实现。如果用户又提出新的需求，实施人员将分析需求的难度及对整个系统的影响程度来确定是否给予实现。 需求调研阶段具体包括如下内容： 1、进行需求调研准备 2、编制《需求调研计划》
开发一个项目需要那几个步骤
本人在两个中小型软件开发企业工作过几年，也做过几年的项目管理工作。走过一些弯路也得出一些项目管理方面的体会，在此进行总结，希望能够与其他一些项目管理人员或对项目管理有兴趣的同事共同探讨一些中小型项目管理的问题及方法。 大部分中小型软件开发企业的软件项目经常遇到的一些问题可能包括：项目时间紧、项目组成员经常加班；项目需求变更频繁；项目进行过程中可能就有项目团队成员离职或调离到其他项目组；项目重复性建设问题严重，每个项目都需要从框架开始重新开发，难以重用已有项目的成果等等。我觉得通过较好的规划和管理能够在一定程度上提高项目的成功率或者说提高项目的质量，降低开发成本，缩短项目开发时间。 我理解项目管理有两个大的划分方法一是通用的项目管理体系，也就是PMP中所说的5个项目管理过程组9个知识领域44个项目管理过程；二是具体业务领域的按项目生命期划分的各阶段的管理。本文主要从项目生命期各阶段的管理方面进行总结。 我个人分析一个软件项目生命期大体需要经过的流程（这只是我个人的一个划分，有可能不是很全面）：可行性分析、需求、设计、开发、测试、实施、维护、总结。 下面我针对每个阶段谈一下自己的体会。 一、可行性分析 一般的项目都是通过外部招标的形式得到的。对于有些公司在应标的时候对项目就要有个取舍。如果在特殊时期为了生存可能只要不是太赔的项目都会尽量承接。 但是一般项目在承接前最好在经济、技术等方面进行可行性分析，而且这种可行性分析最好是管理者、市场、技术等人员都参与，因为市场人员一般不懂（或不通）技术，技术不懂（或不通）市场，因此只有大家在一起共同分析讨论才能够得出比较可行的结果。可行性分析的结果一方面可以作为是否承接项目的依据，另一方面也可以作为承接项目方式或与客户谈判的依据。比如经分析项目工作量很大，如果按标书金额开发有可能会赔，那么可以与用户探讨是否将来能有个二期的项目；另外如果用户要求的时间比较紧，可是经分析很难按标书时间完成，那么也可以和用户同共探讨是否可以在正式签定合同时延长系统交付时间等。当然这些与用户的探讨工作一般是需要公司高层领导出面协调的，有时单独靠项目组是没有能力达成理想的结果的。 另外在此阶段最好对项目的成本和需要的资源进行一下估算。 二、需求 需求实际要细分为需求调研、需求分析、需求确认、需求管理等。 因为对于需求要想说清楚可能需要较长的篇幅，所以在此不进行展开。 在此只是先强调一下需要相当重要，如果早期需求做的不够仔细会给项目的后期工作带来很多的隐患。 而且我建议每个项目无论多大也无论项目时间要求多紧急一定要有一个比较详细的需求文档。 在需求比较确定之后建议再对项目成本进行估算。同时对需要的资源及相关里程碑进行说明。 三、设计 对于大部分中小型项目因为时间和人力的问题加上需求变更比较频繁，所以有时很难书写一个比较详细的设计文档。但是如果没有设计文档一是为后期维护可能会带来一些问题，尤其是当原来开发人员或主力开发人员离职或调离到其他项目组时；另外没有经过详细设计