软件开发项目实施方案

1、Word 软件开发项目实施方案篇：软件开发项目管理实施方案. 项目管理实施方案 作为一个项目管理者,如何要胜利的做好项目管理;首先必需先要明白的是在特定的领域中给予这个角色所要实现的目标、担当的职责、以及项目管理者的详细工作内容是什么? 从我个人的浅见和角度以及我们所从事的IT领域来分析回答以上三个问题。 第一:目标 作为一个项目的管理者,必需要明确的知道自己的工作目标;我个人认为项目管理者的目标无非就是以下两点: 1、就是清楚明确地了解项目利害关系者的需求和期望,努力做到满意项目利害关系者的不同需求;项目利害关系者包括:项目团队成员和项目团队外成员(比如各部门的部门负责人和市场人员,客户等。

2、 2、就是保证开发项目按需按时保质的完成。 其次:职责 作为项目的管理者,首先要端正态度,要明确知道自己的工作职责,熟悉到这份工作职责的本质。项目管理者不是来管人的,而是来支持人的,是来协调资源的,是来营造一个适合团队成员比较认同的工作环境和氛围的,是来为一个共同的目标和大家一起战斗共同成长的。可以也许概括成以下几点: 1、建立有效的工作流程保证项目的顺当进行。 2、制定具体周密的项目方案。 3、跟踪,推动项目按方案进行。 4、乐观解决项目过程中消失的问题和冲突。 5、调动开发团队的乐观性,制造力,推动团队成员在项目过程中不断成长。 6、项目风险识别、风险评估、风险解决和风险管理策略以及做好突

3、发风险的应急预案。 7、实现目标 第三:项目管理者的详细工作内容 最终一个是项目管理者的详细工作内容,作为项目管理者必需清楚的知道自己的工作范围和所要做的工作内容以及工作重心,分为以下六点: 1、项目前期阶段 对项目进行技术可行性分析、技术评估、成本评估以及风险评估。与需求提出方的代表进行需求争论,明确项目的目标、价值;确定项目范围、功能及优先级。组建项目团队,特殊要搞清晰项目的key person(对产品有打算权的人。项目启动会议,相关的 利害关系人员都必需参与。 该阶段完成后的成果:确认后的最终软件需求规格说明书文档。 2、分析设计阶段 依据确认后的软件需求规格说明书,制定项目进度方案,工

4、作任务分解(WBS;资源申请,项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源;数据库设计;系统设计;文档(包括Use Case、Demo系统原型、Test Case等;评审会议。 该阶段完成后的成果: A、User Case(系统用例; B、DEMO(系统原型; C、系统设计文档(概要设计和具体设计; D、数据库设计文档。 最终对完成的成果,包括User Case和设计文档等进行评审。 3、执行阶段(开发和测试 预备开发环境、测试环境;跟踪,推动项目按方案进行;以周报的形式通报项目的进展状况。对项目的阶段成果进行评估,以确保该阶段完成的质量,包括代码审核、SQL 审核等。对需求

5、变更进行掌握管理;对项目风险进行管理;测试阶段BUG FIXED及改进、收集反馈看法。 4、发布阶段 包括制定项目发布方案,用户培训,发布上线。 5、上线后监控 数据监控(日志、服务器状态,依据监控消失的问题,准时进行BUG FIXED及改进或做补丁升级。 6、结束阶段 产品交付,项目会。 第四:基于以上三个问题所做的应对细则 要做好项目管理,并能的确解决好以上三个问题,实现目标、履行职责、完成工作中的详细内容,从我个人这几年的工作阅历和面临的一些问题,还有所积累的一些项目管理中的 一些学问以及自己的观看和思索的角度看,应当要努力做好以下这几个方面的详细工作: 1、项目开发时间的估算 制定项目

6、进度时间表的时候,需要估算每个任务所需的时间,其中开发任务中模块的安排和时间估算是其中最主要的部分;在安排模块和估算开发时间时需要遵循的原则和目标: 1、保证项目整体的进度。 2、有助于确保开发编码的质量。 3、有助于提高开发编码的速度。 在公司现有的技术框架下,开发人员主要的工作是投入在详细的商业规律上。通常每个模块所需的开发时间取决于以下三个因素: 1、所负责模块的商业规律的简单程度。 2、开发人员的技术水平和对项目所在应用的熟识程度(包括对框架和应用的熟识程度。 3、该模块技术实现上是否有技术难点;这里所谓的技术难点定义是:在现有系统中还未实现的、开发人员自身也未没接触过的技术。对于这样

7、的难点,开发者没有相关的代码可以参考,自己也没有阅历,所以需要投入一些时间讨论解决。 模块安排和开发时间估算的步骤: 1、在划分好模块后,首先自己先估算一下每个模块所需要的开发时间。 2、然后召集全部开发人员,争论模块的安排和开发时间估算。将划分好的模块,让开发人员从中选择他们感爱好的模块。这样做可以提高开发人员的主动性和参加性。在安排模块的时候还需从以下几方面考虑,以确保开发的速度和质量: A、相同类似的模块由同一人负责开发,比如用户管理的增删改由同一开发者负责。 这样做的好处就是开发者对相关规律会更加熟识,同时接口的定义也会比较明确,沟通的成本比较低,同时功能实现的缺陷也相应的会降低。 B

8、、技术难度比较大的模块由技术水平比较高的人负责。 C、业务规律比较简单的由对这块规律比较了解的人负责。 3、模块安排完后,开发人员评估自己负责开发的模块所需要的时间。在此过程中最好做到要和开发者比较具体的争论每个模块的技术实现,以便使时间的估算更加精确 。 4、对开发人员估算的时间进行确认。在确认过程中作为项目管理者应参考以上提到的三个因素,同时将自己估算的时间和开发人员估算的时间进行比较。这其中的差异当然会存在的。对于那些差异比较大的,将与技术人员探讨其中的缘由。对于时间周期比较长的任务,尽量将任务通过再细分的手段细化任务,争取每个任务的最长时间不超过3天;时间周期越长的任务,不确定性越高,

9、风险也越高,越有可能成为项目的瓶颈,影响项目的进度。 2、Code Review Code Review是保证项目中代码质量特别重要的一个环节,在这一环中我们公司做的特别欠缺,把关不严格;这是导致每次测试后消失大量bug的主要缘由,这一环需要纳入绩效考核中,实行责任追究制,实施重点监控。消失这样的薄弱环节,造成这样的缘由,我想也是有许多因素造成的;比如开发人员对需求不是很明确,以自己比较主观的因素去完成任务的;还有对整个系统业务规律没有正确的清楚的熟悉的缘由,以及对项目组成员培训不到位的缘由等众多因素纠集在一起才产生的。 如何做好这方面的工作?首先编码要有“编码规范”文档,Code Revie

10、w要有“代码审 核规范”文档:记录代码实现应当遵循的标准。通过这两个文档来规范开发人员的代码实现,代码编写者必需要严格根据规范来进行;代码审核者依据这些标准来Code Review代码,同时在Code Review过程中不断完善该文档。 在做好这些前期工作的前提下,分以下几个步骤来实施: 1、检查开发者的代码实现是否遵循了编码规范。 2、从代码的易维护性、可扩展性角度考察代码的质量,提出修改建议。 3、代码编写者和代码审核者坐在一起,由代码编写者根据Use Case依次讲解自己负责 的代码和相关规律,从Web层-到Manage层再到Dao层; 4、代码审核者在此过程中可以随时提出自己的疑问,同

11、时乐观发觉隐蔽的bug;对这 些bug记录在案。 5、代码讲解完毕后,代码审核者给自己支配几个小时再对代码审核一遍。代码需要一 行一行静下心来看。同时代码又要全面的看,以确保代码整体上设计优良。 6、代码审核者依据审核的结果编写“代码审核报告”,“审核报告”中记录发觉的问题 及修改建议,然后把“审核报告”发送给相关人员。 7、代码编写者依据“代码审核报告”给出的修改看法,修改好代码,有不清晰的地方 可乐观向代码审核者提出。 8、代码编写者bug fixed完毕之后给出反馈。 9、代码审核者把Code Review中发觉的有价值的问题更新到代码审核规范的文档中, 对于特殊值得提示的问题可群发em

12、ail给全部技术人员。假如通过以上步骤,还由于是代码编写者的缘由而消失严峻的缺陷问题,将通过绩效考核来加深代码编写者的印象,并在周报会议上做通报批判。 3、需求变更管理 需求变更管理也是项目管理中最重要的一个环节,对需求变更管理的有效性将直接影响项目的胜利与否。 对待需求变更的态度: 1、需求变更是不行避开的。 2、需求变更要必需被管理。 3、乐观发觉引起变更的因素,促使变更尽可能早的消失,减低变更带来的风险。 需求变更管理的目标: 1、相关的干系人必需清晰地了解发生的变更。 2、变更处于有效的管理中。 3、尽量降低变更带来的风险。 通过制定需求变更的流程,确保项目中的需求变更有效地进行,实现

13、上述的目标。需求变更流程: 1、确定需求的基准线。将以User Case作为需求基准线,在User Case确认之后的任何需求转变,都需要走需求变更流程,这一环节我们基本没有,期间有时候使的工 作很混乱,也就是由于没有一个规范的变更流程而造成的;假如建立了这么一个流程规范和机制,需求变更没有走这个流程的将不被认可。 2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。 3、项目管理者评估该需求变更。针对接收到的需求变更的要求,召集相关人员争论该需求变更的合理性、可行性,实施的代价以及对项目的影响。包括可能影响的项目范围,进 度,

14、费用,质量等方案。项目管理者作为项目的负责人,对项目的胜利与否负有主要的责任。所以需求变更的决策者应当由项目管理者担当。 4、需求变更确认后由专人将需求变更记录下来,通知给项目中全部成员。其中以下人员对需求的变更是紧密相关的,他们必需知晓并认可此需求变更。包括(客户方,需求分析人员,测试人员,相关开发人员。需求变更记录格式如下: 序号变更提出时间变更描述变更类型(是 对原有需求 的修改还是 新增需求 缘由变更提出 者 开发人员对进度的 影响(工 作量 1 2 5、确定变更的负责人。担当需求变更的详细工作,比如基线掌握,对需求变更的记录,并通知相关人员。 6、相关人员接收到确认的需求变更后,做以

15、下事情。需求分析人员修改需求说明书和User Case的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部分。 7、根据变更后的方案实施项目,并进行检查,跟踪,对变更后的实施反馈和可能消失的问题准时沟通和处理。 8、需求冻结。项目越到后期,需求变更对项目的影响就越大,所以在肯定时候要进入需求冻结阶段,不再接收新需求或需求的变更。 4、风险管理 风险管理是项目管理者最重要的工作之一。风险管理是一个持续的过程,贯穿于整个项目过程中,风险管理包括风险识别、风险评估、风险解决以及风险管理策略。 在项目的实施过程中需要不断地识别和应对风险,并加以有效的掌握,风险管理的好与坏直接影响项目

16、的实施效果,从某种意义上讲,项目实施对于项目管理者就是识别、分析、应对、掌握风险的过程,使项目的约束性目标和质量目标朝有利的方向进展。 项目不同于日常任务,它有明确的起止时间和目标,要在明确的范围、时间和成本约束下,达到相应的质量标准,并取得用户的满足。影响项目成败的因素涉及方方面面,并且风险伴随着项目的始终,是客观存在的,作为一个项目管理者,应当具备良好的风险掌握意识,擅长识别风险并分析风险的影响,从中发觉影响目标的风险点,并施 加影响或实行应对措施,把风险的负面影响降到最低,并且风险掌握应当贯穿项目始终。 风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面,导致这些问题的因素

17、主要包括目标以及需求不明确、范围扩散以及需求变更、代码质量或返工风险、人员技能和资源的不足、缺乏良好的团队协作等。下面将具体描述一下这些问题以及消失这些问题时的应对方案: 1、目标以及需求不明确 为了市场竞争或内部管理决策的需要,业务部门提出的需求往往要求的时间比较紧迫,需求的提出大多停留在几张纸或口头的传达上,没有形成正式的业务需求文档,在没有明确的需求范围的状况下,有时为了迎合业务部门的口味匆忙开工,过程中用户不断地提出新的想法,技术人员开头疲于奔命和应付,很难保证项目的进度和质量,也难以取得业务部门的认可。所以,在项目的前期肯定要实行相应的手段或措施,与业务部门共同明确项目目标、需求范围

18、,充分考虑现有的时间和资源约束,将需求排定优先级, 对于关键的需求优先实现， 其他帮助性的依据过程中的详细状况进行滚动式方案， 并取 得业务部门的书面确认。在此过程中要注意挖掘用户的隐性需求，可以通过引导、系统 原型等手段让用户在前期充分暴露自己的想法和需求。 2、范围扩散以及需求变更 在有了明确的目标和需求范围的状况下， 需求的变更还是不行避开的， 业务部门在 看到详细系统的真实雏形之后，源源不断地要求、新想法随之产生，假如不对此加以控 制， 新的需求的加入通常会影响已实现的需求， 并且对项目进度和成本产生很大的影响。 项目管理者针对这种状况肯定要实行严格的变更掌握流程， 不能碍于面子， 否

19、则最终的 结果往往是出力不讨好。针对用户提出的新需求，根据正式流程提出变更申请，组织相 关团队成员进行分析及评估， 作为是否实施的依据， 变更掌握负责人依据分析结果推断 是否批准，假如批准，那项目组可以支配实施，否则，正式拒绝用户的恳求，当然实际 状况下可以实行一些软措施缓解冲突。 需求变更风险：需求已经打上了基线，但此后仍旧有变更 发生，对项目造成影响。 如何削减此类风险的发生？ 前期的需求争论要具体、充分。需求文档中需求的范围要明确、功能描述要清晰。 找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户，全部的需求要经 过他们的认可。客户在项目过程中的全程参加有助于降低此类风险。需

20、求争论、需求确 认、User Case 确认、测试阶段的客户验收等环节，都要要求客户参加。在发生需求变 更时， 严格根据需求变更流程执行。 在分析设计阶段的中的确认和评审也是降低此类风 险的重要手段。 3、代码质量或返工风险 质量风险主要指开发代码的质量。 如何提高开发人员开发的质量？在制定项目方案 时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响也很大。有 时开发人员为了赶进度在比较紧急的时间需要完成指定的任务， 可能就存在很大的开发 质量问题。开发要有一套严格可行的代码规范，编码时严格遵守，到现在为止，我们这 个方面做的不是很规范，做的也很不足，大家编写的代码随便性比较大

21、，代码编写者的 主观意识性比较强。要建立一套大家认可并且规范可行的编码规范和考核规范，code review 时严格考核。在编码前，开发人员要对框架娴熟把握；一份好的系统设计文档对 指导开发特别重要。 返工是项目组最不情愿看到的，既铺张人力、物力和财力，又影响团队乐观性。需 求不明确或范围没有有效掌握都可能造成返工， 另外造成返工的缘由是质量没有达到用 户要求。往往有这样一种状况，每个团队成员根据项目方案报告进度都是 100%完成， 但一到最终系统交互测试或集成的时候就会发觉一大堆问题， 不得不花费很大精力回头 排查、修改程序，造成这种状况的主要缘由是过程中质量保证没有做到位，把大部分问 题留

22、在了后面。 这就需要在项目实施过程中实行有效的措施来规避返工的风险， 通常的 做法有同行评审， 比如概要设计完成之后， 邀请其他项目组的技术专家进行技术评审以 发觉架构设计问题； 管理评审， 通过组织级的质量审计看产品以及实施过程是否满意质 量要求；代码走查，在编码过程中加入至少一次的代码走查，排查不符合规范或性能要 求的代码，走查通常能够发觉 50%-70%的错误；每日构建，这是一种特别有效的方法， 可以避开把各部分的集成问题拖到最终， 并且能够准时发觉相应的错误， 日构建一般在 项目的中后期开头，每天自动从版本服务器上猎取源代码进行自动编译和测试。 4、人员技能和资源的不足 项目实施过程中

23、由于人员技能欠缺造成的进 度延后和软件质量问题并不少见， 一个 娴熟的技术人员完成同样一个任务需要 3 天，但一个生手可能就需要 7-10 天。项目管 理者应当在前期就分析清晰项目所要采纳的技术以及相应的人员技能要求， 针对不同的 角色，准时实行相应的技能培训，以保证项目的顺当实施。假如对于项目中某些部分专 业性特殊强或新技术，短期内又不能快速建立技能的状况，可以考虑将该块任务外包， 借鉴合作商的力气降低实施风险，当然要进行外购人力成本与自建人力成本的效益分 析。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。如何削减 此类风险的发生？在项目开头前的技术评估阶段， 明确技术难点

24、， 提前支配人员进行攻 克。假如在可预期的时间内无法解决，假如可以，将向需求提出方要求变更需求或查找 可替代方案。 这样的风险应当在项目的前期阶段就应当解决在萌芽状态来避开这样的风 险在后期或中期消失。 项目所需人力资源无法按时到位， 导致资源风险。 如何削减此类风险的发生？这个 就需要在项目方案制定的时候提前申请确认资源，并在项目过程中不断沟通协调。 5、缺乏良好的团队协作 软件项目实施属于学问型，要发挥团队成员的制造力，不同于制造业计件生产，各 模块最终要集成在一起形成一个有机的整体， 这就需要各小组之间的亲密协作， 界定清 楚工作界面及接口关系， 并在实施过程中持续地沟通沟通和共享， 首

25、先团队要融为一体， 产出的软件才能融为一体。 这是一个团队的软实力， 团队之间的协作好坏也将是个潜在 的风险问题，在项目启动和团队组建的时候就应当加以规避这样的风险消失。 项目风险管理的要点： 1、上述我们所说的风险管理都是指可以预期将要发生的风险，那些不行预期将要发生 的风险不属于风险管理的范畴。这也将是考验一个项目管理者的阅历和学问对能否 管理好风险至关重要的内容。 2、对不行预期的风险，项目管理者要有潜在的风险意识评估，做好一些可操作性的预 案预备。 3、具体明确的项目方案、以及项目执行过程中每个要点的质量保证是降低项目风险的 必要条件。 4、风险报告是项目团队以及领导了解项目风险的一个

26、有效手段。 风险报告的格式： 序号 风险简介 对项目的影响 解决方案或对策 5、团队管理 团队就是一组个体为实现共同的目标而相互依靠、一起工作的共同体。 团队工作顾名思 义就是团队成员为实现这个共同的目标而付出的共同努力， 项目团队的工作是否有效直接关 系到 项目的成败。 团队管理是个渐进的过程。世界上只有完善的团队，没有完善的个人。好的高效的团队 不是管理出来的，而是营造出来的。团队成员需要有大家可认同的团队文化，这需要大家共 同的努力。 1、营造良好的工作环境和氛围。 2、建设优秀或鲜亮的团队文化。 3、保持高效的沟通。 6、项目会议 组织会议是项目管理者日常工作中一项特别重要的工作任务，

27、 项目过程中许多重要的决 定都是在会议中做出的，也有许多由于不胜利的会议而对项目本身造成了不好的影响。 首先看看不胜利的会议经常表现为哪些形式： 1、会议氛围不好，参加者发言不踊跃； 2、会议争论经常偏离主题； 3、会议没有取得预期的结果； 4、会议时间经常一拖再拖。 这些不胜利的会议最终的结果就是：既铺张了大家的珍贵时间又没有达到会议的目的， 许多人都对这样的会议都有抵触心情， 对此也是深恶痛绝。 以下是组织会议时应当留意的问 题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必需要清晰： 1、会议是否会取得胜利很大程度上取决于会议的组织者。只有组织得有力，会议才有 可能取得胜利，

28、这是会议胜利的充分条件。 2、会议的组织者和参加者的想法通常是不全都的，有时候甚至会大相径庭。所以不要 盼望会议的参加者和你一样，对会议有着如此的期盼，对大多数参加者而言，在会议中他只 是一个发表想法的人，他不用对会议的胜利担当责任。 3、以下十一条最佳实践是形式上的商定，详细的实施可以依据实际状况来做。 组织会议的十一条最佳实践： 1、只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。 2、提前发出会议议程，以便会议参加者知道他们来做什么。 3、请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确 保必要人物都在的状况下一次会议参加者越少效果越好。 4、提前预

29、约参加者的时间，以确保他们能按时到场。 5、会议的开场很重要。会议组织者要在开头前做好几件事情。通常我建议有几点要在 开场时说： A、再一次强调会议的目标，我们来做什么。 B、强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求争论会， 主要是争论做还是不做以及告知大家我们要做什么， 而不要把太多的精力放在争论 如何做上面。 C、说明一下会议的规章。如要发言，请举手；不要有小圈子争论；不要打断别人 的讲 话，等别人说完你再说等等。 6、会议过程中时刻留意引导和掌握会议，以确保会议根据目 标进行。一次会议的氛围 是否良好，争论是否充分，好的引导至关重要。比如多提一些开放式的问题。 7、

30、会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成 果之一。 8、会议要有结论。我们常在会议上听到有人说：大家争论了这么半天，结论呢？。 没有结论的会议是没有意义的。 9、会议后别忘发会议纪要，以及一些 Action，什么人什么时候做什么。 10、会议后的 action 执行状况的反馈很重要。反馈是对会议参加者的敬重，同时也告知 了会议的效果。 否则会让大家感觉到这是一个可无可无的会议， 大家以后参加的乐观性 也会降低。许多会议往往都不留意这一点。 11、按时结束的会议会受到全部人的欢迎。 7、版本掌握 版本掌握也是项目管理者的一个重要工作内容之一， 一个项目或产品的完成

31、不行能是一 步到位的，在项目完成的后期可能会有多个不同的版本的发布（开发版本，测试版本，发布 版本等） 。需要做好版本的管理和掌握。 8、项目总结 在项目完成后，总结整个完成项目的过程和经受，为下一次的项目启动供应参考阅历， 完善不足，避开在类似的项目中消失可能存在的相同的错误发生。 第2篇：软件开发实施方案 1 软件开发实施方案 系统开发严格根据软件工程的方法进行组织， 系统的开发过程按 照需求分析、系统分析与设计要求、系统编码、系统测试几个过程有 序推动。下表所示系统开发流程图，采纳原型及迭代方式开发，依据 用户需求持续改进，直到最终用户确认满足。 1.1 开发流程总述 如下图示流程定义了

32、我公司内部的软件开发过程， 以指导和规范软件项目中开发过程的定义和相应的实施。 该过程可划分为一系列子过程，包括：软件需求分析、设计、编 码、测试、验收、维护，每个子过程又由一系列任务和活动组成，如 设计过程又可分为结构设计和具体设计。 但是在实际开发项目中， 情 况仍旧会是千变万化的， 因此我们也并不是一成不变的死板执行一个 僵化的工作流程， 我们的原则是在一个规范流程的指导和约束下， 根 据详细工程项目的实际要求， 为每一个项目评估并制定真正能够最好 的满意该项目要求的开发流程。 开头 软件需求分析 Y N：改进 Y N：改进 Y N：改进 软件需求规格说明书（初稿） 系统测试方案系统测试

33、案例 （初稿） 用户手册（概要） 追溯表一 软件需求规格说明书 系统测试方案系统测试案例 个人评审记录 评审报告 同行评审 通过 结构设计 评审通过 结构设计说明书（初稿） 集成测试方案集成测试案例 （初稿） 用户手册（初稿） 追溯表一 结构设计说明书 集成测试方案集成测试案例 个人评审记录 评审报告 具体设计说明书（初稿） 单元测试方案单元测试案例 （初稿） 用户手册（修改稿） 追溯表一 具体设计说明书 单元测试方案单元测试案例 用户手册（修改稿） 个人评审记录 评审报告 源代码、源代码文件清单 单元测试报告（经过审批） 软件问题状态登记表 软件问题报告单 集成工作单 集成测试工作单 集成测

34、试报告（经过审批） 软件问题状态登记表 软件问题报告单 集成的软件系统 系统测试报告（经过审批） 软件问题状态登记表 软件问题报告单 系统管理员使用说明书 ( 经过审批) 安装手册（经过审批） 用户手册（经过审批 软件系统（系统测试通过） 验收测试报告 软件问题报告单 软件问题状态登记表 验收报告 可交付产品 软件需求规格说明书（升级版） 客户需求登记表 客户需求统计表 设计说明书（升级版） 软件问题报告单 软件问题状态登记表 软件维护实施方案 维护后的软件系统 具体设计 评审通过 编码 集成测试 系统测试 验收 维护 结束 图 1.1-1 软件开发流程总图 在应用系统软件开发项目中， 我们仍

35、将遵循这一思想， 这一点将在随后的项目开发实施方案部分有详细的体现， 在这里和下面的相关章节中，我们仍将围围着这个完整的开发流程来分析说明， 以此来阐明我们对项目开发的完整过程管理思想和相关实践。 下面我们对这个软件开发工作流程进行简要地分解说明。 1.2 软件需求分析 （1）概述 由于应用系统与众多相关应用软件需要进行交互， 因此需要先对这些应用系统进行分别梳理， 充分做好需求调研工作， 编写经项目单位认可并评审通过的系统需求规格说明书 。 软件需求分析是根据项目定义的软件开发过程， 依据系统安排给软件的需求（见 系统需求规格说明书），进行软件质量特性规格说明的过程。该过程包括进一步明确软件

36、运行环境， 明确对软件的功能、性能和数据要求，以及软件与硬件、软件与软件之间的接口要求等，并对软件需求进行验证和文档化， 即完成对软件需求的分析与规格定义。 本元素在整个过程中的位置如下图所示： 系统安排给软 件的需求 软件需求分析 结构设计 图示：软件需求分析在软件开发过程中的位置 （2）入口准则和出口准则 1）入口准则 要素 推断准则 客户需求（系统需求规格 已由 CCB批准为基线 说明书） 已进入配置库 2）出口准则 要素 推断准则 已经过审查 软件需求规格说明书 已批准为基线 已进入配置库 系统测试方案 已经过审查 已获得批准 系统测试案例 已进入配置库 用户手册（概要） 追溯表一 已

37、编写 已填写 （3）评审 评审软件需求规格说明书 ，详细评审过程见评审程序文件，对软件需求的评审准则包括： 系统需求和系统设计的可追溯性； 与系统需求的全都性； 内部全都性； 可测试性； 软件设计的可行性； 运作和维护的可行性。 对软件需求中的问题， 与系统工程组或客户一起确定和审查， 依据审查结果对软件需求进行适当的修改， 必要时按基线变更掌握的要求对客户需求进行相应的修改。 对软件需求规格说明书进行同行评审。 审查、批准软件需求规格说明书。 将软件需求规格说明书置于配置管理之下。 （ 4）工作产品 软件需求规格说明书 系统测试方案 系统测试案例 用户手册 追溯表 （ 5）职责 项目经理：负

38、责组建软件需求分析组；确定是否需要对有关 人员进行培训；负责软件需求规格说明书的审查和批准。 软件需求分析组：软件需求分析的主要担当者，负责完成本 过程元素要求产生的全部工作产品。 系统测试负责人：负责组织软件系统测试组对软件需求进行 分析，审查软件需求的可测试性；参加软件需求规格说明书 的审查和批准。 质量保证人员：参加工作产品的审查，统计缺陷，并对软件 需求分析过程进行审计。 系统开发组：协作处理涉及客户需求的软件需求问题。 客户：必要时参加软件需求规格说明书的审查和批准。 1.3 结构设计 （1）概述 结构设计是指根据软件需求规格说明书 ，设计软件系统的体系结构，即模块结构，定义每个模块

39、的主要功能和模块之间的联系 （即接口），并确定软件系统的数据体系结构。 本元素在整个过程中的位置如下图所示： 软件需求分析 结构设计 具体设计 图示：软件需求分析在软件开发过程中的位置图 （2）入口准则和出口准则 1）入口准则 要素 推断准则 软件需求规格说明书 经过审查 审查获得批准 进入配置库 2）出口准则 要素 结构设计说明书 集成测试方案 集成测试案例 用户手册（初稿） 推断准则 经过审查 审查获得批准 进入配置库 已完善 追溯表一 （ 3）评审 对结构设计说明书和集成测试方案进行同行评审。 对结构设计中的问题，与软件需求分析人员一起确定和审查， 并对结构设计进行适当的更改。 审查、批

40、准结构设计说明书，必要时，对其进行设计评审。 将结构设计说明书、集成测试方案 和集成测试案例 置于配置管理之下。 （ 4）工作产品 结构设计说明书 集成测试方案 集成测试案例 用户手册 追溯表 （ 5）职责 1）项目经理 负责选择合适的设计人员，组建结构设计工作组；负责结构设 计说明书和集成测试方案的审查和批准。 2）结构设计人员 结构设计阶段工作的主要担当者， 负责完成本过程元素产生的所 有工作产品。 3）系统分析员 协作处理涉及软件需求的问题。 4）系统开发负责人 负责组织系统工程组对结构设计进行分析， 审查结构设计的可测 试性；负责协调处理涉及软件需求的问题；参加结构设计说明书 和集成测

41、试方案的审查和批准。 5）软件测试负责人 负责组织软件测试组对结构设计进行分析， 审查结构设计的可测 试性；参加结构设计说明书和集成测试方案的审查和批准。 1.4 具体设计 （1）概述 具体设计是依据 结构设计说明书进行模块设计，将结构设计所获得的模块根据单元、程序、规程的挨次逐步细化。具体定义各个单元的数据结构、程序的实现算法以及程序、单元、模块之间的接口等，作为以后编码工作的依据。 本元素在整个过程中的位置如下图所示： 结构设计 具体设计 编码 图示：具体设计在软件开发过程中的位置 （2）入口准则和出口准则 1）入口准则 要素 推断准则 经过审查 审查获得批准 结构设计说明书 进入配置库

42、2）出口准则 要素 推断准则 要素 推断准则 经过审查 审查获得批准 具体设计说明书 进入配置库 （3）评审 对具体设计说明书和单元测试方案可进行走查或（和） 同行评审； 对具体设计中的问题， 与结构设计人员一起确定和审查， 并对具体设计做出适当的更改； 审查、批准具体设计说明书 ，必要时，对其进行设计评审；将具体设计说明书和单元测试方案置于配置管理之下。 （ 4）工作产品 具体设计说明书 单元测试方案 单元测试案例 用户手册 追溯表 （ 5）职责 1）项目经理 负责选择合适的设计人员，组建具体设计组；负责具体设计说 明书和单元测试方案的审查和批准。 2）具体设计人员 具体设计阶段工作的主要担

43、当者。 负责完成本过程元素产生的所 有工作产品。 3）系统分析员 协作处理涉及软件需求的问题。 4）系统开发负责人 负责组织系统工程组对具体设计进行分析， 审查具体设计的可测 试性；负责协调处理涉及软件需求的问题；参加具体设计说明书 和单元测试方案的审查和批准。 5）软件测试负责人 负责组织软件测试组对具体设计进行分析， 审查具体设计的可测 试性；参加具体设计说明书和单元测试方案的审查和批准。 1.5 编码 （1）概述 编码阶段主要完成的工作是依据具体设计说明书编写程序源代 码，包括必要的数据文件， 并进行单元测试，单元测试的内容包括模 块内程序的规律、功能、参数传递、变量引用、出错处理等方面

44、。 本元素在整个过程中的位置如下图所示： 具体设计 编码 集成测试 图示：编码阶段在软件开发过程中的位置 （2）入口准则和出口准则 1）入口准则 要素 推断准则 具体设计说明书 经过审查 单元测试方案 获得批准 进入配置库 2）出口准则 要素 推断准则 源代码文件 源代码文件获得批准 源代码文件清单 源代码文件进入配置库的源代码区 单元测试报告 提交测试负责人 软件问题报告单 提交问题管理渠道 （3）评审 对源代码文件进行同行评审， 主要的方法为对比具体设计说明书对代码进行查阅，也可依据编程者的阅历或程序的难度、重要程度，选择走查评审方式，但目的都是发觉程序存在的问题。 （ 4）工作产品 源代

45、码文件 单元测试报告 软件问题报告单 软件问题状态登记表 （ 5）职责 1）项目经理 建立编码组、测试组或相应岗位，并进行必要的培训；跟踪进度 和问题解决状态； 对提交的源代码进行批准 （或指定负责人进行批准 工作）。 2）程序员 编写程序代码；测试程序代码；修改程序代码；提交工作产品， 批准后将其导入配置区的源码库。 3）单元测试人员 测试源代码；提交测试报告和软件问题报告单。 4）评审人员 对指定源代码文件进行阅读，发觉缺陷和问题，填写评审报告。 1.6 模块集成测试 （1）概述 集成测试阶段主要完成的工作是集成和集成测试。 集成是参考结构设计说明书并依据具体说明书中规定的系统集成方案将不

46、同的经 测试的程序单元进行构造， 并逐步构造成一个完整的软件产品的过程；集成测试则是在集成完成之后， 对各单元、模块之间接口的正确性和集成后功能的正确性进行验证。 对于大型软件， 集成测试可以实行分步进行的方法， 可以先对各子系统进行集成测试，然后在子系统之间进行集成测试。 本元素在整个过程中的位置如下图所示： 编码 集成测试 系统测试 图示：集成测试在软件开发过程中的位置 （2）入口准则和出口准则 1）入口准则 要素 推断准则 经过审查 获得批准 进入配置库 结构设计说明书 具体设计说明书 集成测试方案 源代码文件 2）出口准则 要素 推断准则 获得批准 进入配置库 提交集成测试负责人 已进

47、入软件问题管理流程 集成的软件系统 （完整的源代码和目标代码） 集成测试报告 软件问题报告单 （3）审查阶段 核查集成状态和结果，并进行批准； 批准后，将目标程序和程序清单进入目标代码库。 （ 4）工作产品 集成后的系统目标代码 （包括文件清单），及相应的源代码 （包括文件清单） 集成测试报告 软件问题报告单 软件问题状态登记表 集成工作单 集成测试工作单 （5）职责 项目经理：建立集成组、集成测试组或相应岗位，并进行必 要的培训；跟踪进度和问题解决状态；对集成后的系统目标 码进行批准（或指定负责人进行批准工作） 。 集成负责人员：负责集成过程的实施。 集成人员：负责环境构建，集成的过程操作，

48、并将集成后的 目标代码提交批准。 程序员、设计人员：修改源码或设计，解决集成过程中消失 的与源码有关的问题。 测试人员：测试系统目标码，将测试报告和软件问题报告单 提交测试负责人。 1.7 系统测试 （1）概述 系统测试的主要任务是从系统需求的角度对系统运行的正确性和性能进行验证。系统测试的依据为系统测试方案。 本元素在整个过程中的位置如下图所示： 集成测试 系统测试 验收 图示：系统测试在软件开发过程中的位置 （2）入口准则和出口准则 1）入口准则 要素 推断准则 经过审查 系统需求 要素 推断准则 获得批准 进入配置库 编写完成 系统的目标代码 系统测试方案 用户手册 2）出口准则 要素

49、推断准则 获得批准 系统测试报告 软件问题报告单 （ 3）工作产品 系统测试报告 软件问题报告单 软件问题状态登记表 （ 4）职责 项目经理：负责建立系统测试组或相关的岗位，并进行必要 的培训；跟踪进度和问题解决状态；对最终的目标代码进行 批准（或指定负责人进行批准工作） 。 程序员、设计人员：修改源码或设计，解决集成过程中消失 的与源码有关的问题。 测试人员：测试系统目标码，将测试报告提交测试负责人， 将软件问题报告单提交问题管理渠道。 1.8 验收 （1）概述 验收阶段主要由验收测试、验收测试问题改正和验收三部分组成： 验收测试的主要目的是验证所开发的系统在用户的使用环境下 （或模拟的使用

50、环境下） 是否满意系统需求， 从用户的角度验证整个 系统运行的正确性。 验收测试问题改正是对验收测试中发觉的差异性问题进行修改。 验收则是在验收测试的基础上， 依据项目合同或项目任务书对项 目的完成状况进行综合评价。 本元素在整个过程中的位置如下图所示： 系统测试 验收 维护 图示：验收在软件开发过程中的位置 验收的三个组成部分视项目立项类型和客户的要求选择执行。 （2）入口准则和出口准则 1）入口准则 要素 推断准则 验收测试前完成评审。 验收测试方案（有验收测试要求 的项目） 测试（系统测试、集成测试、单 已完成 元测试） 2）出口准则 要素 推断准则 已提交 已关闭 已提交 验收测试报告

51、 验收测试问题报告单 验收报告 （3）工作产品 验收测试报告 软件问题报告单 软件问题状态登记表 验收报告 可交付产品 （ 4）职责 验收测试组：负责验收测试的各项活动。 开发组人员：负责验收测试中发觉问题的改正和测试帮助。 项目管理人员：负责指派验收测试责任和完成测试规程；确 保测试质量和进程；确保组间协调。 验收组：详细进行验收。 CCB：批准运行基线。 1.9 维护 （1）概述 维护期是指： 软件产品 / 系统验收后，进入软件运行 / 系统维护阶段，直至软件产品下一个版本的发布或系统维护期终止； 本元素在整个软件开发过程中的位置如下图所示： 验收 维护 图示：维护在软件开发过程中的位置

52、（2）入口准则和出口准则 1）入口准则 要素 推断准则 软件产品 / 系统 已验收 2）出口准则 要素 推断准则 软件产品 已退役 合同商定的维护期限 已到期 合同商定的维护范围 已超出，须另签协议 （3）工作产品 软件需求规格说明书 客户需求登记表 客户需求统计表 设计说明书 软件问题报告单 软件问题状态登记表 软件维护实施方案 维护后的软件系统 （4）职责 维护负责人：制定软件维护实施方案， 确认维护类型、需求范围，安排维护任务，追踪任务的完成状况及其他项目管理工作。 软件维护人员：负责进行软件维护任务的执行。 QA人员：负责帮助维护负责人依据实际状况剪裁标准流程。 第3篇：软件项目实施方

53、案 b 2.8 项目实施 2.8.1 项目实施概况 依据项目建设要求，对中山农情统计分析系统进行整体规划设计更新维护， 对系统运行的平安性、牢靠性、易用性以及稳健性进行全新设计， 并将全部的应 用系统进行部署实施和软件使用培训以及技术支持。项目组承诺项目自立完成， 不转包外包。 2.8.1.1 项目实施管理原则 项目开发维护的实施中，严格根据 ISO9001 国际质量体系进行掌握，保证为用户供应优质的产品、严密的工程实施、高效的服务支持。为此，要遵循下列工程实施管理原则和保证体系。 （1）有阅历、成熟的技术队伍是工程实施的前提条件 完成任何项目工程，必需拥有一支有阅历的、勇于探究的、高水平的、

54、具有严谨工作作风的技术队伍， 在工程实施的过程中发挥团队协作精神和用户亲密协作的力量。 （2）管理层次分明、职责清楚是工程实施的基础 建立层次分明的项目工程实施管理机构， 明晰各层的管理职责， 从组织管理的角度保证项目实施方案落到实处。 （3）确定过程掌握点，以过程质量保证整体工程质量 整体都是由局部和详细的细节构成， 项目由一个个过程环节组成， 只有仔细对待每一个过程细节，才能保证项目工程整体的实施质量。 （4）用户参加是项目工程胜利的保证 从项目开头到项目的结束， 每个阶段都强调用户的参加。 开发商只有和用户相结合才能使开发出的系统为用户所用， 发挥出系统的最大效益， 而用户的参加也是系统

55、顺当进行的保证。 对本项目短时间、大范围的配置安装来说， 假如有用户的高度参加，项目工程的实施将大大加快。 b b 2.8.1.2 项目组织结构 本项目是一项涉及面广、影响大、平安运行要求高，集数据处理、信息发布、资源整合于一体的政府信息化项目。为了更好的执行该项目，将实行统一指挥、并行实施、相互支援的实施方法。 为了使该项目能顺当实施， 便于项目的管理和协调， 使工作职责更加清楚明白，建立项目组织实施小组，建立由项目领导小组、项目管理办公室、项目监理公司、顾问询问组、项目经理、项目详细实施小组组成的实施管理掌握组织体系。 项目实施组织详细职责如下： （1）项目领导小组 负责项目实施过程中的重

56、大大事决策； 依据项目的进度、质量、技术、资源、风险等实行宏观监控； 负责组建验收小组，主持验收工作； 协调参加项目各方的工作关系。 （2）项目管理办公室 组织各方统一制定工程管理方案； 组织总体实施方案评审，组织测试验收； 负责项目进度方案与成本掌握； 协调解决项目实施过程中消失的各种问题。 （3）顾问询问组 1）人员组成 农业信息化相关领域的业务专家； 多年从事 IT 行业和展厅建设的信息技术专家。 2）主要职责 系统总体设计指导； 对各子系统深化设计进行审核并提出优化建议； 对各子系统进行技术协调； 帮助客户对系统的设备配置予以确认； 对现场系统安装、调试供应必要的技术支持服务； 工程文

57、档审核。 b b （4）项目经理 1)人员组成 项目经理由具有丰富项目管理阅历的高级工程师担当。 2）主要职责 制定项目方案：牵头制定项目方案。 项目执行：对总体方案设计及工程设计；配置确认；工程质量保证；系统设计、开发、测试、安装及调试；系统培训、验收。 项目检查：通过其下属各工作组供应的工程进展汇报，将项目进展状态与项目方案进度进行比较，发觉过程误差，提出整改措施。 项目掌握：审核项目进展状态，必要时调集各种备用资源，确保项目按方案进度实施。 项目协调：与客户、各分系统建设部门进行协调，解决工程组织接口及技术接口问题；定期主持系统建设协调会，准时解决各系统间消失的相关问题。 项目汇报：定期

58、向项目选购单位汇报整个项目的进展状况，汇报在系统建设过程中消失的重大问题，听取指导和建议。 （5）总体方案组 1）人员组成 由从事过多名基层电子政务项目的系统架构师、系统分析员和需求分析工程 师组成。 2）主要职责 对项目经理负责； 进行系统的需求分析调研； 负责系统的总体设计； 策划系统的模块功能结构； 协作业主方进行系统验收。 （6）软件开发组 对业主需求分析进行全面细致的了解或确认，深化描述软件的功能和性能， 划分系统的软件功能需求和硬件功能需求， 确定软件同其它系统元素的接口细节， b b 并与客户一起争论打算系统验收方案。 1）人员组成 高级程序员； 具有丰富产品开发阅历的产品开发设

59、计人员。 2）主要职责 负责项目应用软件的系统设计； 负责项目应用软件的程序编码； 负责项目应用软件的运行调试； 协作业主方进行系统验收。 （7）系统测试组 从使用者的角度完成系统操作步骤的设计， 在实施过程中监控测试系统是否达到最初制定的操作目标，并编写业主操作手册。检验系统开发质量，并进行功能测试。 当开头试运行阶段后，还要对项目的各个方面指标进行测试和评估。 （8）系统实施组 1）人员组成 由具有丰富阅历的系统工程师和参与系统开发的软件工程师组成。 2）主要职责 负责各个实施区域的实施方案的设计与建议； 组织系统安装及调试； 负责系统配置修改，安装技术支持； 2.8.1.3 项目团队 依

60、据上述项目组织结构和职能分解， 北京派得伟业科技进展有限公司方案投 入高级顾问 1 人，项目经理 2 人、技术负责人 1 人、实施经理 1 人、系统设计组 4 人、软件开发组 13 人、系统测试组 3 人、系统实施组 3 人。共计 28 人。形成 特地服务本项目的技术开发实施队伍。 随着开发层次的深化、开发量的增加， 北 京派得伟业科技进展有限公司投入的人力资源将随之增加和不断进行调整。 未经 招标人同意，项目总负责人及各分项目负责人在项目结束前不得变更。 b b 详细人员组成安排状况分别如下表所示： 表 1.项目实施人员一览表 序号 本项目职责 姓名 职务 公司副总、农业生产 本项目详细分工