软件开发项目实施方案

软件开发项目实施方案项目管理实施方案作为一个项目管理者，如何要成功的做好项目管理;首先必须先要明白的是在特定的领域中赋予这个角色所要实现的目标、承担的职责、以及项目管理者的具体工作内容是什么？从我个人的浅见和角度以及我们所从事的IT领域来分析回答以上三个问题。第一：目标作为一个项目的管理者，必须要明确的知道自己的工作目标;我个人认为项目管理者的冃标无非就是以下两点：1、 就是清晰明确地了解项目利害关系者的需求和期望，努力做到满足项目利害关系者的不同需求;项目利害关系者包括：项目团队成员和项目团队外成员（比如各部门的部门负责人和市场人员，客户等。2、 就是保证开发项目按需按时保质的完成。第二：职责作为项目的管理者，首先要端正态度，耍明确知道自己的工作职责，认识到这份工作职责的本质。项目管理者不是来管人的，而是来支持人的，是来协调资源的，是来营造一个适合团队成员比较认同的工作环境和氛围的，是来为一个共同的目标和大家一起战斗共同成长的。能够大概概括成以下几点：1、 建立有效的工作流程保证项冃的顺利进行。2、 制定详细周密的项目计划。3、 跟踪，推动项目按计划进行。4、 积极解决项目过程中出现的问题和冲突。5、 调动开发团队的积极性，创造力，推动团队成员在项目过程中不断成长。6、 项目风险识别、风险评估、风险解决和风险管理策略以及做好突发风险的应急预案。7、 实现目标第三：项目管理者的具体工作内容最后一个是项目管理者的具体工作内容，作为项冃管理者必须清晰的知道自己的工作范围和所要做的工作内容以及工作重心，分为以下六点：1、 项冃前期阶段对项目进行技术可行性分析、技术评估、成本评估以及风险评估。与需求提岀方的代表进行需求讨论，明确项目的目标、价值;确定项目范围、功能及优先级。组建项目团队，特别要搞清楚项目的keyperson（对产品有决定权的人。项目启动会议，相关的利害关系人员都必须参加。该阶段完成后的成果：确认后的最终软件需求规格说明书文档。2、 分析设计阶段根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解（WBS;资源申请，项目涉及到的开发资源、测试资源、设计资源（包括人员和软硬件资源；数据库设计;系统设计;文档（包括UseCase、Dem。系统原型、TestCase等;评审会议。该阶段完成后的成果：A、UserCase（系统用例;B、DEMO（系统原型；C、系统设计文档（概要设计和详细设计;D、数据库设计文档。最后对完成的成果，包括UserCase和设计文档等进行评审。3、 执行阶段（开发和测试准备开发环境、测试环境;跟踪，推动项目按计划进行；以周报的形式通报项目的进展情况。对项目的阶段成果进行评估，以确保该阶段完成的质量，包括代码审核、SQL审核等。对需求变更进行控制管理;对项目风险进行管理;测试阶段BUGFIXED及改进、收集反馈意见。4、 发布阶段包括制定项目发布计划，用户培训，发布上线。5、 上线后监控数据监控（日志、服务器状态，根据监控出现的问题，及时进行BUGFIXED及改进或做补丁升级。6、 结束阶段产品交付，项目总结会。第四：基于以上三个问题所做的应对细则要做好项目管理，并能确实解决好以上三个问题，实现目标、履行职责、完成工作中的具体内容，从我个人这几年的工作经验和面临的一些问题，还有所积累的一些项冃管理中的一些知识以及自己的观察和思考的角度看，应该要努力做好以下这几个方面的具体工作：1、项冃开发时间的估算制定项目进度时间表的时候，需要估算每个任务所需的时间，其中开发任务中模块的分配和时间估算是其中最主要的部分;在分配模块和估算开发时间时需要遵循的原则和目标：1、 保证项冃整体的进度。2、 有助于确保开发编码的质量。3、 有助于提高开发编码的速度。在公司现有的技术框架下，开发人员主要的工作是投入在具体的商业逻辑上。通常每个模块所需的开发时间取决于以下三个因素：1、 所负责模块的商业逻辑的复杂程度。2、 开发人员的技术水平和对项目所在应用的熟悉程度（包括对框架和应用的熟悉程度。3、 该模块技术实现上是否有技术难点;这里技术难点定义是：在现有系统中还未实现的、开发人员自身也未没接触过的技术。对于这样的难点，开发者没有相关的代码能够参考，自己也没有经验，所以需要投入一些时间研究解决。模块分配和开发时间估算的步骤：1、 在划分好模块后，首先自己先估算一下每个模块所需耍的开发时间。2、 然后召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块,让开发人员从中挑选他们感兴趣的模块。这样做能够提高开发人员的主动性和参与性。在分配模块的时候还需从以下几方面考虑，以确保开发的速度和质量：A、相同类似的模块由同一人负责开发，比如用户管理的增删改由同一开发者负责。这样做的好处就是开发者对相关逻辑会更加熟悉，同时接口的定义也会比较明确,沟通的成本比较低，同时功能实现的缺陷也相对应的会降低。B、 技术难度比较大的模块由技术水平比较高的人负责。C、 业务逻辑比较复杂的由对这块逻辑比较了解的人负责。3、 模块分配完后，开发人员评估自己负责开发的模块所需要的时间。在此过程中最好做到要和开发者比较详细的讨论每个模块的技术实现，以便使时间的估算更加准确。4、 对开发人员估算的时间进行确认。在确认过程中作为项冃管理者应参考以上提到的三个因素，同时将自己估算的时间和开发人员估算的时间进行比较。这其中的差异当然会存在的。对于那些差异比较大的，将与技术人员探讨其中的缘由。对于时间周期比较长的任务，尽量将任务通过再细分的手段细化任务，争取每个任务的最长时间不超过3天;时间周期越长的任务，不确定性越高，风险也越高，越有可能成为项目的瓶颈，影响项冃的进度。2、CodeReviewCodeReview是保证项目中代码质量非常重要的一个环节，在这个环中我们公司做的非常欠缺，把关不严格；这是导致每次测试后出现大量bug的主要原因，这个环需要纳入绩效考核中，实行责任追究制，实施重点监控。出现这样的薄弱环节，造成这样的原因，我想也是有很多因素造成的；比如开发人员对需求不是很明确，以自己比较主观的因素去完成任务的；还有对整个系统业务逻辑没有正确的清晰的认识的原因，以及对项目组成员培训不到位的原因等众多因素纠集在一起才产生的。如何做好这方面的工作?首先编码要有“编码规范”文档,CodeReview要有“代码审核规范”文档：记录代码实现应该遵循的标准。通过这两个文档来规范开发人员的代码实现，代码编写者必须要严格按照规范来进行；代码审核者根据这些标准来CodeReview代码，同时在CodeReview过程中不断完善该文档。在做好这些前期工作的前提下，分以下几个步骤来实施：1、 检查开发者的代码实现是否遵循了编码规范。2、 从代码的易维护性、可扩展性角度考察代码的质量，提出修改建议。3、 代码编写者和代码审核者坐在一起，由代码编写者按照UseCase依次讲解自己负责的代码和相关逻辑，从Web层-到Manage层再到Dao层；4、 代码审核者在此过程中能够随时提出自己的疑问，同时积极发现隐藏的bug;对这些bug记录在案。5、 代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。代码需要一行一行静下心来看。同时代码又要全面的看，以确保代码整体上设计优良。6、 代码审核者根据审核的结果编写“代码审核报告”，“审核报告”中记录发现的问题及修改建议,然后把“审核报告”发送给相关人员。7、 代码编写者根据“代码审核报告”给出的修改意见，修改好代码，有不清楚的地方可积极向代码审核者提出。8、 代码编写者bugfixed完毕之后给出反馈。9、 代码审核者把CodeReview中发现的有价值的问题更新到”代码审核规范”的文档中，对于特别值得提醒的问题可群发email给所有技术人员。如果通过以上步骤，还因为是代码编写者的原因而出现严重的缺陷问题，将通过绩效考核来加深代码编写者的印象，并在周报会议上做通报批评。3、需求变更管理需求变更管理也是项目管理中最重要的一个环节，对需求变更管理的有效性将直接影响项冃的成功与否。对待需求变更的态度：1、 需求变更是不可避免的。2、 需求变更要必须被管理。3、 积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。需求变更管理的目标：1、 相关的干系人必须清楚地了解发生的变更。2、 变更处于有效的管理中。3、 尽量降低变更带来的风险。通过制定需求变更的流程，确保项目中的需求变更有效地进行，实现上述的冃标。需求变更流程：1、确定需求的基准线。将以UserCase作为需求基准线，在UserCase确认之后的任何需求改变，都需要走需求变更流程，这个环节我们基本没有，期间有时候使的工作很混乱，也就是因为没有一个规范的变更流程而造成的；如果建立了这么一个流程规范和机制，需求变更没有走这个流程的将不被认可。2、 项目管理者接收到需求变更的要求。需求变更的提出者能够是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。3、 项目管理者评估该需求变更。针对接收到的需求变更的要求，召集相关人员讨论该需求变更的合理性、可行性，实施的代价以及对项目的影响。包括可能影响的项冃范围，进度，费用，质量等计划。项冃管理者作为项冃的负责人，对项冃的成功与否负有主要的责任。所以需求变更的决策者应该由项冃管理者承担。4、 需求变更确认后由专人将需求变更记录下来，通知给项目中所有成员。其中以下人员对需求的变更是紧密相关的，他们必须知晓并认可此需求变更。包括（客户方,需求分析人员，测试人员，相关开发人员。需求变更记录格式如下：序号变更提出时间变更描述变更类型（是对原有需求的修改还是新增需求原因变更提出者开发人员对进度的影响（工作量125、 确定变更的负责人。承担需求变更的具体工作，比如基线控制，对需求变更的记录，并通知相关人员。6、 相关人员接收到确认的需求变更后，做以下事情。需求分析人员修改需求说明书和UserCase的相关内容。测试人员修改测试用例的相关内容。开发人员修改代码中的相关部分。7、 按照变更后的计划实施项目，并进行检查，跟踪，对变更后的实施反馈和可能出现的问题及时沟通和处理。8、 需求冻结。项目越到后期，需求变更对项目的影响就越大,所以在一定时候要进入需求冻结阶段，不再接收新需求或需求的变更。4、风险管理风险管理是项目管理者最重要的工作之一。风险管理是一个持续的过程，贯穿于整个项目过程中，风险管理包括风险识别、风险评估、风险解决以及风险管理策略。在项冃的实施过程中需要不断地识别和应对风险，并加以有效的控制，风险管理的好与坏直接影响项目的实施效果，从某种意义上讲，项目实施对于项目管理者就是识别、分析、应对、控制风险的过程，使项目的约束性目标和质量目标朝有利的方向发展。项目不同于日常任务，它有明确的起止时间和目标，要在明确的范围、时间和成本约束下，达到相对应的质量标准，并取得用户的满意。影响项目成败的因素涉及方方面面，并且风险伴随着项目的始终，是客观存在的，作为一个项目管理者，应该具备良好的风险控制意识，善于识别风险并分析风险的影响，从中发现影响目标的风险点,并施加影响或釆取应对措施，把风险的负面影响降到最低，并且风险控制应该贯穿项目始终。风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面，导致这些问题的因素主要包括目标以及需求不明确、范围蔓延以及需求变更、代码质量或返工风险、人员技能和资源的不足、缺乏良好的团队协作等。下面将详细描述一下这些问题以及出现这些问题时的应对方案：1、目标以及需求不明确为了市场竞争或内部管理决策的需要，业务部门提出的需求往往要求的时间比较紧迫，需求的提出大多停留在几张纸或口头的传达上，没有形成正式的业务需求文档,在没有明确的需求范围的情况下，有时为了迎合业务部门的口味匆匆开工，过程中用户不断地提出新的想法，技术人员开始疲于奔命和应付，很难保证项目的进度和质量,也难以取得业务部门的认可。所以，在项目的前期一定要采取相对应的手段或措施，与业务部门共同明确项目目标、需求范围，充分考虑现有的时间和资源约束，将需求排定优先级，对于关键的需求优先实现，其他辅助性的根据过程中的具体情况进行滚动式计划，并取得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，能够通过引导、系统原型等手段让用户在前期充分暴露自己的想法和需求。2、范围蔓延以及需求变更在有了明确的目标和需求范围的情况下，需求的变更还是不可避免的，业务部门在看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控制，新的需求的加入通常会影响已实现的需求，并且对项目进度和成本产生很大的影响。项目管理者针对这种情况一定要采取严格的变更控制流程，不能碍于面子，否则最终的结果往往是出力不讨好。针对用户提岀的新需求，按照正式流程提出变更申请,组织相关团队成员进行分析及评估，作为是否实施的依据，变更控制负责人根据分析结果判断是否批准，如果批准，那项目组能够安排实施，否则，正式拒绝用户的请求,当然实际情况下能够采取一些软措施缓解矛盾。需求变更风险：需求己经打上了基线，但此后仍然有变更发生，对项目造成影响。如何减少此类风险的发生？前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。找出项目中需求的决策者（通常会是产品经理、相关职能主管、客户，所有的需求要经过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确认、Usercase确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变更时，严格按照需求变更流程执行。在分析设计阶段的中的确认和评审也是降低此类风险的重要手段。3、代码质量或返工风险质量风险主要指开发代码的质量。如何提高开发人员开发的质量？在制定项目计划时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响也很大。有时开发人员为了赶进度在比较紧张的时间需要完成指定的任务，可能就存在很大的开发质量问题。开发要有一套严格可行的代码规范，编码时严格遵守，到现在为止，我们这个方面做的不是很规范，做的也很不足，大家编写的代码随意性比较大，代码编写者的主观意识性比较强。要建立一套大家认可并且规范可行的编码规范和考核规范，codereview时严格考核。在编码前，开发人员要对框架熟练掌握；一份好的系统设计文档对指导开发非常重要。返工是项目组最不愿意看到的，既浪费人力、物力和财力，又影响团队积极性。需求不明确或范围没有有效控制都可能造成返工，另外造成返工的原因是质量没有达到用户要求。往往有这样一种情况，每个团队成员按照项目计划报告进度都是100%完成，但一到最后系统交互测试或集成的时候就会发现一大堆问题，不得不花费很大精力回头排查、修改程序，造成这种情况的主要原因是过程中质量保证没有做到位，把大多数问题留在了后面。这就需要在项目实施过程中采取有效的措施来规避返工的风险，通常的做法有同行评审，比如概要设计完成之后，邀请其他项目组的技术专家进行技术评审以发现架构设计问题；管理评审，通过组织级的质量审计看产品以及实施过程是否满足质量要求；代码走査，在编码过程中加入至少一次的代码走査，排查不符合规范或性能要求的代码，走査通常能够发现50%-70%的错误；每日构建，这是一种非常有效的方法，能够避免把各部分的集成问题拖到最后，并且能够及时发现相对应的错误，日构建一般在项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。4、 人员技能和资源的不足项目实施过程中因为人员技能欠缺造成的进度延后和软件质量问题并很多见，一个熟练的技术人员完成同样一个任务需耍3天，但一个生手可能就需要7・10天。项目管理者应该在前期就分析清楚项目所要釆用的技术以及相对应的人员技能要求，针对不同的角色，及时采取相对应的技能培训，以保证项目的顺利实施。如果对于项目中某些部分专业性特别强或新技术，短期内又不能快速建立技能的情况，能够考虑将该块任务外包，借鉴合作商的力量降低实施风险，当然要进行外购人力成本与自建人力成本的效益分析。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。如何减少此类风险的发生？在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。如果在可预期的时间内无法解决，如果能够，将向需求提岀方要求变更需求或寻找可替代方案。这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风险在后期或中期出现。项目所需人力资源无法按时到位，导致资源风险。如何减少此类风险的发生？这个就需要在项冃计划制定的时候提前申请确认资源,并在项目过程中不断沟通协调。5、 缺乏良好的团队协作软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清楚工作界面及接口关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融为一体。这是一个团队的软实力，团队之间的协作好坏也将是个潜在的风险问题，在项冃启动和团队组建的时候就应该加以规避这样的风险出现。项目风险管理的要点：1、 上述我们所说的风险管理都是指能够预期将要发生的风险，那些不可预期将要发生的风险不属于风险管理的范畴。这也将是考验一个项目管理者的经验和知识对能否管理好风险至关重要的内容。2、 对不可预期的风险，项冃管理者要有潜在的风险意识评估，做好一些可操作性的预案准备。3、 详细明确的项目计划、以及项冃执行过程中每个要点的质量保证是降低项冃风险的必要条件。4、 风险报告是项目团队以及领导了解项目风险的一个有效手段。风险报告的格式：序号风险简介对项目的影响解决方案或对策5、 团队管理团队就是一组个体为实现共同的目标而相互依赖、一起工作的共同体。团队工作顾名思义就是团队成员为实现这个共同的目标而付出的共同努力，项冃团队的工作是否有效直接关系到项目的成败。团队管理是个渐进的过程。世界上只有完美的团队，没有完美的个人。好的髙效的团队不是管理出来的，而是营造出来的。团队成员需要有大家可认同的团队文化，这需要大家共同的努力。1、 营造良好的工作环境和氛围。2、 建设优秀或鲜明的团队文化。3、 保持高效的沟通。6、 项目会议组织会议是项冃管理者EI常工作中一项非常重要的工作任务，项冃过程中很多重要的决定都是在会议中做出的，也有很多因为不成功的会议而对项目本身造成了影响。首先看看不成功的会议常常表现为哪些形式：1、 会议氛围不好，参与者发言不踊跃；2、 会议讨论常常偏离主题；3、 会议没有取得预期的结果；4、 会议时间常常一拖再拖。这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的冃的，很多人都对这样的会议都有抵触情绪，对此也是深恶痛绝。以下是组织会议时应该注意的问题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必须要清楚：1、 会议是否会取得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有可能取得成功，这是会议成功的充分条件。2、 会议的组织者和参与者的想法通常是不一致的，有时候甚至会大相径庭。所以不要希望会议的参与者和你一样，对会议有着如此的期待，对大多数参与者而言，在会议中他仅仅一个发表想法的人，他不用对会议的成功承担责任。3、 以下十一条最佳实践是形式上的约定，具体的实施能够根据实际情况来做。组织会议的十一条最佳实践：1、 只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。2、 提前发出会议议程，以便会议参与者知道他们来做什么。3、 请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确保必要人物都在的情况下一次会议参与者越少效果越好。4、 提前预约参与者的时间，以确保他们能按时到场。5、 会议的开场很重要。会议组织者要在开始前做好几件事情。通常我建议有几点要在开场时说：A、 再一次强调会议的目标，我们来做什么。B、 强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求讨论会，主要是讨论做还是不做以及告知大家我们要做什么，而不要把太多的精力放在讨论如何做上面。c、说明一下会议的规则。如要发言，请举手；不要有小圈子讨论；不耍打断别人的讲话，等别人说完你再说等等。6、 会议过程中时刻注意引导和控制会议，以确保会议按照目标进行。一次会议的氛围是否良好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。7、 会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成果之一。8、 会议要有结论。我们常在会议上听到有人说：”大家讨论了这么半天，结论呢？”。没有结论的会议是没有意义的。9、 会议后别忘发会议纪要，以及一些Action,什么人什么时候做什么。10、 会议后的action执行情况的反馈很重要。反馈是对会议参与者的尊重，同时也告知了会议的效果。否则会让大家感觉到这是一个可无可无的会议，大家以后参与的积极性也会降低。很多会议往往都不注意这个点。11、 按时结束的会议会受到所有人的欢迎。7、 版本控制版本控制也是项目管理者的一个重要工作内容之一，一个项目或产品的完成不可能是一步到位的，在项目完成的后期可能会有多个不同的版本的发布（开发版本，测试版本，发布版本等）。需要做好版本的管理和控制。8、 项目总结在项目完成后，总结整个完成项目的过程和经历，为下一次的项目启动提供参考经验，完善不足，避免在类似的项目中出现可能存在的相同的错误发生。1软件开发实施方案系统开发严格按照软件工程的方法进行组织，系统的开发过程按照需求分析、系统分析与设计要求、系统编码、系统测试几个过程有序推进。下表所示系统开发流程图，采用原型及迭代方式开发，根据用户需求持续改进，直到最终用户确认满意。1.1开发流程总述如下图示流程定义了我公司内部的软件开发过程，以指导和规范软件项目中开发过程的定义和相对应的实施。该过程可划分为一系列子过程，包括：软件需求分析、设计、编码、测试、验收、维护，每个子过程又由一系列任务和活动组成，如设计过程又可分为结构设计和详细设计。但是在实际开发项目中，情况仍然会是千变万化的，所以我们也并不是一成不变的死板执行一个僵化的工作流程，我们的原则是在一个规范流程的指导和约束下，根据具体工程项目的实际要求，为每一个项目评估并制定真正能够最好的满足该项目要求的开发流程。开始软件需求分析YN：改进YN：改进YN：改进《软件需求规格说明书》（初稿）《系统测试计划》《系统测试案例》（初稿）《用户手册》（概要）《追溯表一》《软件需求规格说明书》《系统测试计划》《系统测试案例》《个人评审记录》《评审报告》同行评审通过结构设计评审通过《结构设计说明书》（初稿）《集成测试计划》《集成测试案例》（初稿）《用户手册》（初稿）《追溯表一》《结构设计说明书》《集成测试计划》《集成测试案例》《个人评审记录》《评审报告》《详细设计说明书》（初稿）《单元测试计划》《单元测试案例》（初稿）《用户手册》（修改稿）《追溯表一》《详细设计说明书》《单元测试计划》《单元测试案例》《用户手册》（修改稿）《个人评审记录》《评审报告》源代码、源代码文件清单《单元测试报告》（经过审批）《软件问题状态登记表》《软件问题报告单》《集成工作单》《集成测试工作单》《集成测试报告》（经过审批）《软件问题状态登记表》《软件问题报告单》集成的软件系统《系统测试报告》（经过审批）《软件问题状态登记表》《软件问题报告单》《系统管理员使用说明书》（经过审批）《安装手册》（经过审批）《用户手册》（经过审批软件系统（系统测试通过）验收测试报告《软件问题报告单》《软件问题状态登记表》验收报告可交付产品《软件需求规格说明书》（升级版）《客户需求登记表》《客户需求统计表》《设计说明书》（升级版）《软件问题报告单》《软件问题状态登记表》《软件维护实施计划》维护后的软件系统详细设计评审通过编码集成测试系统测试验收维护结束图1.1-1软件开发流程总图在应用系统软件开发项目中，我们仍将遵循这个思想，这个点将在随后的项目开发实施计划部分有具体的体现，在这里和下面的相关章节中，我们仍将围绕着这个完整的开发流程来分析说明，以此来阐明我们对项目开发的完整过程管理思想和相关实践。下面我们对这个软件开发工作流程进行简要地分解说明。1.2软件需求分析（1）概述因为应用系统与众多相关应用软件需要进行交互，所以需要先对这些应用系统进行分别梳理，充分做好需求调研工作，编写经项目单位认可并评审通过的《系统需求规格说明书》。软件需求分析是按照项目定义的软件开发过程，根据系统分配给软件的需求（见《系统需求规格说明书》），进行软件质量特性规格说明的过程。该过程包括进一步明确软件运行环境，明确对软件的功能、性能和数据要求，以及软件与硬件、软件与软件之间的接口要求等，并对软件需求进行验证和文档化，即完成对软件需求的分析与规格定义。本元素在整个过程中的位置如下图所示：系统分配给软件的需求软件需求分析结构设计图示：软件需求分析在软件开发过程中的位置（2）入口准则和出口准则1） 入口准则要素判断准则客户需求（《系统需求规格已由CCB批准为基线说明书》）已进入配置库2） 岀口准则要素判断准则已经过审査软件需求规格说明书已批准为基线已进入配置库系统测试计划已经过审査己获得批准系统测试案例己进入配置库用户手册(概要)追溯表一已编写已填写评审评审《软件需求规格说明书》，具体评审过程见《评审程序文件》，对软件需求的评审准则包括：•系统需求和系统设计的可追溯性；•与系统需求的一致性：•内部一致性；•可测试性；•软件设计的可行性；•运作和维护的可行性。对软件需求中的问题，与系统工程组或客户一起确定和审查，根据审査结果对软件需求进行适当的修改，必要时按基线变更控制的要求对客户需求进行相对应的修改。对软件需求规格说明书进行同行评审。审查、批准软件需求规格说明书。将软件需求规格说明书置于配置管理之下。工作产品-《软件需求规格说明书》-《系统测试计划》-《系统测试案例》-《用户手册》-《追溯表》(5)职责•项目经理：负责组建软件需求分析组；确定是否需要对有关人员进行培训；负责软件需求规格说明书的审査和批准。•软件需求分析组：软件需求分析的主要承担者，负责完成本过程元素要求产生的所有工作产品。•系统测试负责人：负责组织软件系统测试组对软件需求进行分析，审查软件需求的可测试性；参与软件需求规格说明书的审查和批准。•质量保证人员：参与工作产品的审查，统计缺陷，并对软件需求分析过程进行审计。•系统开发组：配合处理涉及客户需求的软件需求问题。•客户：必要时参与软件需求规格说明书的审査和批准。1.3结构设计（1） 概述结构设计是指按照《软件需求规格说明书》，设计软件系统的体系结构，即模块结构，定义每个模块的主要功能和模块之间的联系（即接口），并确定软件系统的数据体系结构。本元素在整个过程中的位置如下图所示：软件需求分析结构设计详细设计图示：软件需求分析在软件开发过程中的位置图（2） 入口准则和出口准则1） 入口准则要素判断准则软件需求规格说明书经过审查审查获得批准进入配置库2） 出口准则要素结构设计说明书集成测试计划集成测试案例用户手册（初稿）判断准则经过审查审查获得批准进入配置库追溯表一（3） 评审•对《结构设计说明书》和《集成测试计划》进行同行评审。•对结构设计中的问题，与软件需求分析人员一起确定和审查，并对结构设计进行适当的更改。•审查、批准《结构设计说明书》，必要时，对其进行设计评审。•将《结构设计说明书》、《集成测试计划》和《集成测试案例》置于配置管理之下。（4） 工作产品•《结构设计说明书》-《集成测试计划》-《集成测试案例》•《用户手册》-《追溯表》（5）职责1） 项目经理负责选择合适的设计人员，组建结构设计工作组；负责《结构设计说明书》和《集成测试计划》的审査和批准。2） 结构设计人员结构设计阶段工作的主要承担者，负责完成本过程元素产生的所有工作产品。3） 系统分析员配合处理涉及软件需求的问题。4） 系统开发负责人负责组织系统工程组对结构设计进行分析，审查结构设计的可测试性；负责协调处理涉及软件需求的问题；参与《结构设计说明书》和《集成测试计划》的审查和批准。软件测试负责人负责组织软件测试组对结构设计进行分析，审查结构设计的可测试性；参与《结构设计说明书》和《集成测试计划》的审査和批准。1.4详细设计概述详细设计是根据《结构设计说明书》进行模块设计，将结构设计所获得的模块按照单元、程序、规程的顺序逐步细化。详细定义各个单元的数据结构、程序的实现算法以及程序、单元、模块之间的接口等，作为以后编码工作的依据。本元素在整个过程中的位置如下图所示：结构设计详细设计编码图示：详细设计在软件开发过程中的位置入口准则和出口准则入口准则要素判断准则经过审查审查获得批准结构设计说明书进入配置库出口准则要素判断准则要素判断准则经过审查审查获得批准详细设计说明书进入配置库评审对《详细设计说明书》和《单元测试计划》可进行走査或(和)同行评审；对详细设计中的问题，与结构设计人员一起确定和审查，并对详细设计做出适当的更改；审査、批准《详细设计说明书》，必要时，对其进行设计评审；将《详细设计说明书》和《单元测试计划》置于配置管理之下。（4）工作产品-《详细设计说明书》-《单元测试计划》-《单元测试案例》-《用户手册》-《追溯表》（5）职责1） 项目经理负责选择合适的设计人员，组建详细设计组；负责《详细设计说明书》和《单元测试计划》的审查和批准。2） 详细设计人员详细设计阶段工作的主要承担者。负责完成本过程元素产生的所有工作产品。3） 系统分析员配合处理涉及软件需求的问题。4） 系统开发负责人负责组织系统工程组对详细设计进行分析，审查详细设计的可测试性；负责协调处理涉及软件需求的问题；参与《详细设计说明书》和《单元测试计划》的审查和批准。5） 软件测试负责人负责组织软件测试组对详细设计进行分析，审查详细设计的可测试性；参与《详细设计说明书》和《单元测试计划》的审査和批准。1.5编码概述编码阶段主要完成的工作是根据详细设计说明书编写程序源代码，包括必要的数据文件，并进行单元测试，单元测试的内容包括模块内程序的逻辑、功能、参数传递、变量引用、出错处理等方面。本元素在整个过程中的位置如下图所示：详细设计编码集成测试图示：编码阶段在软件开发过程中的位置入口准则和出口准则入口准则要素判断准则详细设计说明书经过审査单元测试计划获得批准进入配置库出口准则要素判断准则源代码文件源代码文件获得批准源代码文件清单源代码文件进入配置库的源代码区单元测试报告提交测试负责人软件问题报告单提交问题管理渠道评审对源代码文件进行同行评审，主要的方法为对照详细设计说明书对代码进行查阅，也可根据编程者的经验或程序的难度、重要程度，选择走查评审方式，但目的都是发现程序存在的问题。（4）工作产品•源代码文件-《单元测试报告》-《软件问题报告单》-《软件问题状态登记表》（5）职责1） 项目经理建立编码组、测试组或相对应岗位，并进行必要的培训：跟踪进度和问题解决状态；对提交的源代码进行批准（或指定负责人进行批准工作）O2） 程序员编写程序代码；测试程序代码；修改程序代码；提交工作产品，批准后将其导入配置区的源码库。3） 单元测试人员测试源代码；提交测试报告和软件问题报告单。4） 评审人员对指定源代码文件进行阅读，发现缺陷和问题，填写评审报告。1.6模块集成测试（1）概述集成测试阶段主要完成的工作是集成和集成测试。集成是参考结构设计说明书并根据详细说明书中规定的系统集成方案将不同的经测试的程序单元进行构造，并逐步构造成一个完整的软件产品的过程；集成测试则是在集成完成之后，对各单元、模块之间接口的正确性和集成后功能的正确性进行验证。对于大型软件，集成测试能够釆取分步进行的方法，能够先对各子系统进行集成测试，然后在子系统之间进行集成测试。本元素在整个过程中的位置如下图所示：编码集成测试系统测试图示：集成测试在软件开发过程中的位置（2） 入口准则和出口准则1） 入口准则要素判断准则经过审查获得批准进入配置库结构设计说明书详细设计说明书集成测试计划源代码文件2） 出口准则要素判断准则获得批准进入配置库提交集成测试负责人巳进入软件问题管理流程集成的软件系统（完整的源代码和目标代码）集成测试报告软件问题报告单（3） 审查阶段核查集成状态和结果，并进行批准；批准后，将目标程序和程序清单进入目标代码库。（4） 工作产品•集成后的系统目标代码（包括文件清单），及相对应的源代码（包括文件清单）•集成测试报告-《软件问题报告单》•《软件问题状态登记表》-《集成工作单》-《集成测试工作单》（5）职责•项目经理：建立集成组、集成测试组或相对应岗位，并进行必要的培训；跟踪进度和问题解决状态；对集成后的系统目标码进行批准（或指定负责人进行批准工作）。•集成负责人员：负责集成过程的实施。•集成人员：负责环境构建，集成的过程操作，并将集成后的目标代码提交批准。•程序员、设计人员：修改源码或设计，解决集成过程中出现的与源码有关的问题。•测试人员：测试系统目标码，将测试报告和软件问题报告单提交测试负责人。1.7系统测试（1） 概述系统测试的主要任务是从系统需求的角度对系统运行的正确性和性能进行验证。系统测试的依据为系统测试计划。本元素在整个过程中的位置如下图所示：集成测试系统测试验收图示：系统测试在软件开发过程中的位置（2） 入口准则和出口准则1）入口准则要素判断准则经过审查系统需求要素判断准则获得批准进入配置库编写完成系统的目标代码系统测试计划用户手册2）岀口准则要素判断准则获得批准系统测试报告软件问题报告单（3）工作产品-《系统测试报告》•《软件问题报告单》-《软件问题状态登记表》（4）职•项目经理：负责建立系统测试组或相关的岗位，并进行必要的培训；跟踪进度和问题解决状态；对最终的目标代码进行批准（或指定负责人进行批准工作）。•程序员、设计人员：修改源码或设计，解决集成过程中出现的与源码有关的问题。•测试人员：测试系统目标码，将测试报告提交测试负责人，将软件问题报告单提交问题管理渠道。1.8验收（1）概述验收阶段主要由验收测试、验收测试问题改正和验收三部分组成：验收测试的主要目的是验证所开发的系统在用户的使用环境下（或模拟的使用环境下）是否满足系统需求，从用户的角度验证整个系统运行的正确性。验收测试问题改正是对验收测试中发现的差异性问题进行修改。验收则是在验收测试的基础上，依据项目合同或项目任务书对项目的完成情况进行综合评价。本元素在整个过程中的位置如下图所示：系统测试验收维护图示：验收在软件开发过程中的位置验收的三个组成部分视项目立项类型和客户的要求选择执行。（2） 入口准则和出口准则1） 入口准则要素判断准则验收测试前完成评审。验收测试计划（有验收测试要求的项目）测试（系统测试、集成测试、单己完成元测试）2） 出口准则要素判断准则已提交已关闭已提交验收测试报告验收测试问题报告单验收报告（3） 工作产品•验收测试报告-《软件问题报告单》-《软件问题状态登记表》•验收报告•可交付产品（4） 职责•验收测试组：负责验收测试的各项活动。项目执行计划：九个月。第一阶段：调研和需求分析：第1个月［1］调研中山市农业信息化基础设施建设运行现状，掌握土肥业务需求，编制需求分析报告［2］ 在需求分析报告的基础上，结合项目建设目标和要求，制定详细的项目实施方案。第二阶段：技术方案设计：第2-3个月［1］平台各系统各部分功能的需求分析与详细设计［2］建立平台各应用系统的数据列表和数据库表结构［3］软硬件技术、数据库系统的选型和开发环境的搭建［4］建立完善的开发环境，做好开发前准备工作第三阶段：应用系统的建设及网络测试：第4-7个月［1］开发土肥信息管理服务平台各应用系统［2］完成系统集成工作［3］ 应用系统的测试、调试工作第四阶段：应用系统的完善、安装使用与培训：第8个月［1］ 安装部署应用系统［2］ 应用系统使用培训，进入试运行。［3］ 根据用户反馈的意见对系统进行完善，形成稳定的产品第五阶段：应用系统试运行：第9个月［1］ 试运行期间系统进一步修改和完善［2］ 整理文档，撰写项目竣工报告，完成项目的验收工作［3］系统交接项0总体实施进度如下图所示：月度时间（天）任务名称需求调研收集资料制定开发技术方案XXXX101212序号123bb456789101112系统功能概要设计系统功能详细设计数据库设计系统开发应用系统测试、调试安装部署系统应用及培训试运行、修改与完善准备验收材料与验收15125731575325图1.总体实施进度计划图2.8.3人员培训为了保证系统建成以后良好的运行，制定完善的培训计划。2.8.3.1培训内容对开发的应用系统软件的使用和数据维护进行培训，使业务人员能够熟练使用系统，进行数据的管理维护和业务分析，实现决策、共享和信息发布等操作任务，使软件系统发挥应有的作用。2.8.3.2培训方式培训使用建设中跟随培训和建设后集中培训两个方式。建设中培训：中山市农科推广中心在建设阶段积极参与各系统的建设，参与系统设计、系统实施，随时熟悉系统设备和软件的使用方法和内容；建设后培训：系统建设完成后，对中山市农科推广中心管理人员进行集中的系统使用和维护培训，使业务管理人员从整体和局部上掌握系统的使用。提供完整的用户手册，作为培训的材料。bb8.4项目验收2.8.4.1项目验收本项目由经信局组织专家进行会议评审验收，验收前需对平台各系统的功能进行测试，并进行72小时稳定性测试。验收后由经信局出具中山市土肥信息管理服务平台建设项目的验收报告。2.8.4.2项目交付项说明项目任务完成后，投标方根据合同应提交给招标方的货物、服务以及交接文件、用户手册等，并附上相对应的交付时间计划表。投标方交给中山市农业科技推广中心的中山市土肥信息管理服务平台的代码，必须是系统应用系统所有模块不加密的、明文的、标准的源代码。2.8.4.3项冃付款本项冃以总价承包方式釆购，采用分期付款方式。1、 合同签订后，投标人提交项目实施方案并通过釆购单位审核之日起个工作日内，釆购单位启动支付流程向乙方支付合同总额的20%；102、 系统完成设计、开发、测试、安装部署，釆购单位签字同意进入试运行之日起10个工作日内，釆购单位启动支付流程向投标人支付合同总价的3、 项目实施完成并通过经信局组织的专家终验之日起购单位启动支付流程向投标人支付合同总价的40%。30%O10个工作日内，采4、 投标人按照采购单位要求完成质保工作，项目质保期结束之日起工作日，采购单位启动支付流程向投标人支付合同总价的10个10%o2.8.5售后服务针对本项目的售后及技术支持服务，派得伟业公司承诺如下：北京派得伟业科技发展有限公司设置专门人员，为本项目售后及技术支持提bb供优质、高效的服务；质量保证期：系统验收后12个月。质保期内，投标人所有服务不得收取任何费用；投标人有责任解决所提供产品或服务及其附件、安装介质的任何故障。投标人必须在8小时内对业主所提岀的维护要求做出实质性反应，并提供应急响应策略。系统运行过程中如果出现技术故障（如硬件故障、软件故障、配置丢失等），在此期间按紧急预案处置，确保系统最大限度地不中断运行。投标人应保证8小时内解决此类问题，以恢复故障使得系统得以正常运行。质保期外，投标人为建设方提供有偿技术支持和服务，考虑系统维护服务等工作量情况，适当向建设方收取一定费用。如果有幸中标，我们将在建设、实施以及今后的运行维护中安排专门人员，针对本系统的特点结合我们在不同项目中的维护经验，制订高效完整的维护方案，提供高质量和全方位的支持和服务。我们的主要服务措施有：在北京派得伟业科技发展有限公司建立专门的技术服务小组；在客户许可的情况下，维护人员将通过电话、邮件或者即时通讯工具，提供实时在线指导维护，排除系统故障；设立专门的客户协调经理，负责聆听客户的需求，定期对客户进行现场访问，加强与客户的沟通交流，调查系统运行情况，为客户提供有预见性的建议与计划，传达公司产品发展状况等信息。设立专门的技术支持经理，在项目实施结束后，设立专门的技术支持经理，负责各项售后服务工作：针对应用软件本身出现的问题，积极组织人力查找原因，及时给出解决方案，并在版本升级后彻底避免此类问题的发生；对于非北京派得伟业科技发展有限公司应用软件的问题，而是因为其他因素影响用户的正常使用，北京派得伟业科技发展有限公司将会积极配合用户查找问题原因。2.8.5.1常规支持服务从试运行期结束后算起，系统开始正式运行，北京派得伟业科技发展有限公bb司承诺向用户提供一年免费的标准支持服务，在免费服务期内，为用户提供免费的现场技术支持服务，免费的现场软件安装调试、保修和升级，维护人员的免费现场培训和技术指导等，针对软件应用中出现的问题在1小时内提供应急相对应方案，若软件系统出现无法远程指导解决的故障，派得伟业公司技术人员上门服务，根据实际情况最迟在48小时以内修复。同时，北京派得伟业科技发展有限公司承诺本系统的知识产权归用户方所有。在免费技术支持服务期内，除提供正常的工作时间热线电话支持外，还提供8*24小时的值班手机支持服务，对于用户关于软件应用以及相关内容的咨询和问题提供解答和解决方案。免费技术支持服务期结束后，北京派得伟业科技发展有限公司将继续提供优质的支持服务，定期对系统进行维护査询，对用户提出的维护请求，通过电话指导，E-mail、即时通讯工具和传真等方式及时响应和处理用户反馈的问题和系统运行的故障。对用户需要的系统软件和应用软件的现场维护，包括现场的安装调具体的收试和重装，应用软件升级服务，派得伟业公司将收取一定的成本费用，费由双方协议后决定。2.8.5.2故障等级与响应时间（1）故障等级定义紧急故障：系统己无法使用，导致用户业务活动中止：系统频繁出错，频繁产生完全错误的处理结果。严重故障：系统仍在维持状态运行，但性能下降；系统能够维持运行，但有多个功能无法工作，或某一功能不正常己严重影响系统的运行。中等故障：系统能够工作，但个别非核心功能出现异常，对使用的方便性产生不良影响。轻度故障：系统工作基本正常，但偶然岀现个别非核心功能异常，可通过简单的系统重启或改变配置得到恢复。（2） 服务请求响应时间表2.故障等级与请求响应时间故障等级电话/传真回复响应b提出现场响应计划b紧急0.5小时1小时4小时4小时1小时严重2小时8小时8小时中等轻度（3） 故障修复时间表3.故障等级与故障修复时间故障等级紧急24小时严重24小时中等30小时时间故障修复时间，指技术支持服务人员到达用户现场并且修复故障所需要的时间，从以传真或E-Mail正式确认需要现场服务请求起开始计时。出发地为北京派得伟业科技发展有限公司2.8.6项目保障措施为了保障项目的顺利实施，采用项目经理负责制，由项目承建方制定的项目经理全权负责项目所有问题。同时，对项目实施过程的各个方面设置专门的负责人，项目承建方需在园区派驻常驻联络员，八小时随时待命，保证随时问题随时反馈，即时沟通，快速解决。2.8.6.1组织保障体系为了保证项目的成功实施，在组织管理方面要制定严密细致的组织保障体系，建议成立以中山市农科推广中心领导和项冃承建方领导组成的项冃领导组，主要负责项目组织和实施过程中有关问题的协调和决策，并对项目进行宏观指导。项目领导小组下设项目管理办公室，由中山市农科推广中心的有关管理人员和项目承建方相关部门人员组成，负责项目实施的具体管理和协调工作，检查和监督项目的进展。在项目领导组的指导下，成立项目的顾问咨询组，由项目管理办公室聘请农业信息化、物联网、计算机等领域的专家组成，参与项目的咨询、论证、评估，bb检查、监督，指导项冃的技术发展。同时，积极探索项目的运行管理机制，加强项目目标管理与过程管理结合，加强实施过程中的规范管理和动态的监督、检査，确保工作质量，为项目提供完善的管理体系和组织保障体系。2.8.6.2技术保障体系只有具有成功实施过类似项目经验的技术队伍，才能保证本项目的成功。项目承建方耍集中一批有经验的实施技术人才参加项目组。这些技术工程人员，除了自身具有独立解决问题的能力之外，还能具有良好的协作能力和相互支援的作风。为保证项冃的高质量实施，建立由项目总负责人（项目经理）负责，系统总设计师技术把关，专业分组，具有成熟案例开发经验的软件工程师开发，监控的质量技术体系。从工程整体实施过程来看，每一个开发阶段的实施，都由有项目经验的资深技术人员进行实施和全面管理控制。有过成功的经验，才能准确把握项目的技术关键和难点，把问题消灭在产生之前或萌芽中，充分保证项冃实施的成功率。有了成功实施的技术队伍，才能保证项目的质量和性能。2.8.6.