项目流程及阶段工作

软件开发流程软件开发流程〔Softwaredevelopmentprocess〕1首先看一下根本软件工程开发流程图其中：首先看一下根本软件工程开发流程图其中：1.需求分析：1.需求分析：通过对客户业务的了解和与客户对流程的争论对需求进展根本建模，最终形成需求规格说明书。2.总体设计：通过分析需求信息，对系统的外部条件及内部业务需求进展抽象建模，最终形成概要设计说明文档。3.具体设计：此局部在对需求和概要设计的根底上进展系统的具体设计〔也包含局部代码说明〕。对系统进展代码编写。测试分析与系统整合：对全部功能模块进展模拟数据测试及其它相关性测试并整合全部模块功能。现场支持：系统上线试运行进呈现场问题记录、解答。系统运行支持：系统正式推产后，对系统进展必要的维护和BUG修改需求分析是怎样做的？需求分析是构建软件系统的一个重要过程。一般，把需求类型分成三个类型：1、业务需求〔businessrequirement〕反映了组织机构或客户对系统、产品高层次的目的要求，它们在工程视图与范围文档中予以说明。2、用户需求(userrequirement)文档描述了用户使用产品必需要完成的任务说明。3、功能需求(functionalrequirement)求。业务需求和用户需求是软件需求分析的根底，也是软件构建的前提。

开发编程系统分析员通过对业务需求和用户需求的分解，将其转换成可以形式化描述的软件功能需求。开发软件系统最为困难的局部，就是准确说明开发什么。这就需要在开发的过程中不断的与用户进展沟通与探讨,使系统更加详尽,准确到位。这就需要确定用户是否需要这样的产品类型以及猎取每个用户类的需求。户自己的冲突之中。客户的负面影响可能对于能够在预算内按时完成工程产生很大的影响。尽管客户需要时候，即使客户不会追究开发方的责任，就软件工程本身而言，也已经是失败的。总结：良好的需求分析是软件成功的根底。在软件工程整个过程中系统分析员主动进展沟通，提出指导性意见。当软件融合了客户和系统分析员双方才智，其质量将会进一步得以提高。、治理标准软件开发治理标准流程图软件开发治理标准流程图摘工程治理的根本目的是按时、保质、保量完成预期交付的成果。工程治理要让整个于工程实施的支持与帮助，通过以制度化治理来组织合理安排员工的工作职责和角色转换。于工程实施的支持与帮助，通过以制度化治理来组织合理安排员工的工作职责和角色转换。〔文档治理〕”。2、启动阶段这个阶段的工作目的是打算一个工程是否需要启动。为了到达这个目的，首先要明确这个阶段的工作目的是打算一个工程是否需要启动。为了到达这个目的，首先要明确这些代表了对整个工程目标从战略角度和宏观层次所进展的分析目意向总结书的通过及工程被批准上马形成了这个工程的起始点。、产品领域争论争论产品所在领域的状况，为工程论证供给依据。争论内容包括：产品领域的现状和前景争论产品所在领域的状况，为工程论证供给依据。争论内容包括：产品领域的现状和前景产品领域的商业模式和业务流程产品的价值和盈利空间产品的特性和简洁度、技术可行性争论争论产品的实现技术，总结技术可行性。争论内容包括：类似产品的当前实现技术和技术趋势争论产品的实现技术，总结技术可行性。争论内容包括：类似产品的当前实现技术和技术趋势实现技术的候选方案各个方案的优点、本钱和风险开发团队与实现技术的匹配状况开发团队与实现技术的匹配状况、工程论证则进一步论证工程的总体方案。论证的内容包括：商业可行性技术可行性当前产品与类似产品的比较工程收益和前景工程的本钱和风险工程的总体方案、确定工程目标和范围工程开头时，全部相关人员必需对工程的目标和范围达成共识，形成共同的工程愿景。工程开头时，全部相关人员必需对工程的目标和范围达成共识，形成共同的工程愿景。概概述 用三到五张图表来描述产品目标、功能、平台、客户、进度表和开发职责高级功能 用一个段落来综述产品，再用一个段落来描述每个重要的功能不实现的功能 用一个段落来描述每个对产品有用的但本工程不实现的功能涉众 用一个段落来明确每个重要的涉众群体和他们的风险股本工程需求 用一个段落来表达每个重要的工程需求工程风险 按风险暴露量对每个重要的工程风险都用一个段落来争论工程回报 用一个段落综述产品的回报，其后再对每个重要的工程回报都用一个段落来争论总结为什么这个工程会成功并把愿景表达为《工程开发大纲》向相关人员传达。《工程开发大纲》的内容包括：并把愿景表达为《工程开发大纲》向相关人员传达。《工程开发大纲》的内容包括：3、打算阶段这个阶段的工作是为整个工程做打算。工程开头后，首先要确定工程的具体范围，明确定出工程到底要做什么，总结、归纳并定出产品的功能。然后进一步制定工程的打算，列这个阶段的工作是为整个工程做打算。工程开头后，首先要确定工程的具体范围，明确定出工程到底要做什么，总结、归纳并定出产品的功能。然后进一步制定工程的打算，列依据人员的配置和力气设定各项工作和整个工程的完成时间表。围绕各项打算的制定工作对工程的规模、工作量等进展评估，评估的内容包括：围绕各项打算的制定工作对工程的规模、工作量等进展评估，评估的内容包括：模块数量与简洁度输入、输出和对外接口等数量与简洁度SLOC和功能点非生产性的支持工作量非生产性的支持工作量开发工作量〔人月〕进度与里程碑进度风险、定制工程开发打算工程开发打算表达了工程组对整个开发周期的预期，指定了工程开发的总体方针。与实际状况修改打算并重公布。《工程开发打算》的内容包括：用三到五张图表来描述产品目标、功能、平台、客户、进度表和开发职责。〔《工程开发打算》的概述局部应当是《工程开发大纲》中概述局部的拷贝。当工程概述 时，修订《工程开发打算》的概述局部而不是修订《工程开发大纲》。这样，以后在进展工程评价时，通过比较《工程开发大纲》和《工程开发打算》的概述，就能看出工程是如何转变的〕用一到五页的篇幅来概述产品的功能，其中，要包括这些功能的附加信息〔开发者需高级功能

要这样的信息来了解实现需求〕。概述这个工程中所应用的软件过程。〔具体内容可在《质量保证打算》中定义〕概述这个工程中所应用的软件工程方法和技术。〔具体内容可在《质量保证打算》中定义〕这一局部要表达出整个工程进度和工作量的估量。其中要包括：

对固定不变的里程碑和同步点的解释在评估中的设想状况、评估中的不准确性的可能来源随着工程的进展如何更评估〔具体进度表内容可在《开发进度表》中定义〕

概述这个工程中风险治理打算。〕概述这个工程中要收集的测量。软件工具软件工具工程支持列出要使用的每一项软件工具，以及该工具所支持的任务。软件支持明确所需的软件，包括需要猎取、安装或升级的软件件。人力支持由哪个人、部门或团队为开发组的哪项任务供给支持。、定制风险治理打算风险治理任务包括：风险识别、风险分析、确定风险优先级、定制风险化解方案、风险化解和风险监控《风险治理打算》定义这些任务的执行流程和人员安排。《风险治理打算》的内容包括：《风险治理打算》的内容包括：概概述 用文字和图表概述风险治理任务的总体执行流程。风险识别 具体说明“风险识别”任务的实施细节和各项工作的负责人。风险分析 具体说明“风险分析”任务的实施细节和各项工作的负责人。确定风险优先级 具体说明“确定风险优先级”任务的实施细节和各项工作的负责人。定制风险化解方案 定制风险处理方案”任务的实施细节和各项工作的负责人。当风险发生时，需要实行相应的措施化解风险。风险化解这局部的内容是描述风险化解工作的操作标准和流程。风险监控 具体说明风险监控任务的实施细节和各项工作的负责人。风险治理中通常会用到《TopN风险列表》，风险列表依据风险暴露量排序列出当前工程中主要的N个风险，《TopN风险列表》的内容包括：本周的排名〔假设本周已被完全化解用“”表示〕假设是识别的风险用“”表示〕该风险已上表的周数风险的名称或简述风险类型〔只针对进度相关的风险〕：打算编制承包商外部环境开发环境暴露量风险发生的百分比概率〔工作日或工作周〕发生概率X损失程度风险的当前状态：未发生、已发生、已化解简述风险的化解方案，假设有具体的化解方案文档则链接到相应文档对已发生的风险，简述化解进度〔未发生的风险用“”表示〕、定制质量保证打算保证工作质量的一个重要步骤是制定一套合理的质量保证打算并贯彻执行。《质量保证打算》的内容包括：工作标准

具体说明这个工程中所应用的软件过程。具体说明这个工程中所应用的软件工程方法和技术。工作任务包括：常规开发活动〕会议〕评审〕测量〕其他活动〔技能培训、资料收集、内部流、客户沟通等〕、定制开发进度打算基于当前对工程的规模和工作量评估，定制初步的开发进度表，作为工程开发打算的基于当前对工程的规模和工作量评估，定制初步的开发进度表，作为工程开发打算的组成局部。《开发进度表》的内容包括：工程的开头和完毕时间工程各个阶段的开头和完毕时间每个阶段的工作任务及其开头和完毕时间每个工作任务的子任务的及其开头和完毕时间里程碑和同步点里程碑和同步点角色的定义和任务安排作为跟踪工程进度的重要依据，进度表在工程推动过程中需要不断细化。另外，当实作为跟踪工程进度的重要依据，进度表在工程推动过程中需要不断细化。另外，当实际进度与打算进度消灭偏差时，需要修改进度表并重公布。4、执行阶段如：人员、设备、费用、技术、信息，由治理者领导全体工程参与者开展各项工作。同时跟踪各项具体工作和整个工程的进度，定期向全体工程人员及工程的发起人报告工程状态。、需求分析分析产品的关键需求、对架构设计有影响的需求和风险较高的需求，直到分析的程度能开展足界面原型设计和架构设计工作。《需求规格说明书》的内容包括：客户提出的要求或赢得市场竞争所必需实现的功能、性能、质量等要求。商业或业务需求 1. 做什么做的范围对结果的要求从客户对软件产品或系统使用方案的角度动身，描述和总结使用者利用该软件产品或功能需求性能需求

系统能够做的事或能够完成的任务。能。运行速度、容量、并发性能对资源的利用率对外界输入的反响速度和准确性对过失的负荷力气必需适应的运行环境的要求〔包括运行平台、网络及其他硬件要求〕系统需求

与其他系统兼容的要求〔包括与操作系统、数据库、扫瞄器及其他应用软件的兼容要求〕质量需求其他需求

与外部其他系统和组件的接口要求对用户重要的质量标志〔牢靠性、效率性、灵敏性、安全性、互操作性、稳定性、健全性、可用性〕对开发者重要的质量标志〔可维护性、多用转换性、重复使用性、可测试性〕不属于上述需求范围的，但受到其他环境和商业合同影响的要求。国家或地区的任何特别的标准软件使用界面的特别要求与学问产权有关的要求软件所面对的市场和行业的标准客户的特别要求对开发的成功与否起很大影响的因素，是开发力气的局限：人员的局限技术的制约和局限客户的特别要求部接口需求”、“质量属性需求”和“需求约束”。部接口需求”、“质量属性需求”和“需求约束”。明确了系统的关键需求后，就可以进展界面原型设计工作，猎取用户的反响，尽快确明确了系统的关键需求后，就可以进展界面原型设计工作，猎取用户的反响，尽快确导。《界面设计概要》的内容包括：设计的理念理念的来源或参考设计的要点与类似产品界面的比照、架构设计架构设计从关键需求开头，建立概念性的架构，并逐步细化和验证。最终生成架构设架构设计从关键需求开头，建立概念性的架构，并逐步细化和验证。最终生成架构设计说明书和架构基线代码。架构设计的方法：可以从几个不同的视角进展架构设计，然后汇总综合得出完整的设计。《架构设计说明书》的内容包括：《架构设计说明书》的内容包括：概述 写的目的、适用范围以及设计原则等。关注功能。其设计着重考虑功能需求。细化功能单元规律架构 2. 觉察通用机制细化领域模型确定子系统接口和交互机制理解性和易测试性等。开发架构

确定要开发或直接利用的程序包之间的依靠关系确定承受的技术、框架等关注长期化数据的存储方案。其设计着重考虑“数据需求”。数据架构 1. 长期化数据存储方案2. 数据传递、数据、数据同步等策略重考虑运行期质量属性，例如性能、可伸缩性、持续可用性和安全性等。确定引入哪些进程与线程运行架构

确定主动对象、被动对象，以及把握关系处理进程线程的创立、销毁、通信机制、资源争用等协议设计关注软件系统最终如何安装或部署到物理机器。其设计着重考虑“安装和部署需求”。物理架构 1. 确定物理配置方案2. 确定如何将目标程序映射到物理节点总结 基于上述的设计进展总结，并描述架构基线。全部工程工程工程名目构造软件包构造全部工程工程工程名目构造软件包构造导入全部依靠包根底公共代码架构框架代码架构框架例如代码和测试代码数据库框架呈现了软件架构师的工作和成功的软件架构设计包含的内容：软件架构师的工作成功的软件架构设计、软件构建软件可以分阶段进展构建，每个阶段可以使用增量的方式开发，用通过假设干个Build软件可以分阶段进展构建，每个阶段可以使用增量的方式开发，用通过假设干个Build构建，最终公布阶段性产品成果。〔留意：在这里，名词“阶段”的含义和本文其他地方的含义不一样〕阶段打算构建阶段打算的内容包括：确定本阶段要实现的功能列出阶段任务打算Build构建数量细化《开发进度表》中本阶段的工作内容BuildBuild构建以增量的方式执行阶段的开发任务，每个Build构建的周期一般不超过两星期，每一次BuildBuildBuild《Build本次BuildBuild本次Build的工作任务要解决的遗留Bug本应由以前的Build实现的，但推迟到本次Build实现的功能要实现的功能其他工作任务工作任务安排需求细化依据《Build打算》，细化本次Build要实现的需求，细化到能进展具体设计为止。有Build《测试打算》的内容包括：功能测试要测试的功能：测试时间测试方式验收标准其他测试〔性能测试、边界测试、使用界面测试、可用性测试、安全性测试等〕要测试的内容：测试时间测试方式验收标准。。。。。。界面设计依据细化的需求设计用户界面，当界面确定后即可编写测试用例。《测试用例》的内容包括：测试用例对应的功能模块测试用例的性质〔功能测试用例、性能测试用例、。。。。。。〕输入〔或操作步骤〕期望输出实际输出〔执行测试后再填写〕是否通过〔执行测试后再填写〕具体设计具体实际每项需求的实现方法，对于重要的设计决策、算法、公共模块和外部接口等必需以模块设计文档的形式进展记录。《模块设计文档》的内容包括：模块名称设计思想设计图表〔类图、流程图等〕要点描述〔包、接口、类、方法、算法、设计模式〕测试方式编码、单元测试遵守以下准则：遵守编码标准编码前必需充分理解相关的需求编码前先进展设计，把流程理顺留意设计方法和设计模式的灵敏运用总体考虑问题，使代码遵从架构并简洁测试设计时要充分考虑特别状况和临界条件严禁Copy-Paste，留意提取公共代码，在编码过程中实现重构特别处理必需记录日志，严禁草率地直接打印特别信息灵敏运用ASSERT/VERIFY等断言来帮助调试程序单元测试是程序员的工作，所以编码完成后必需对代码严格测试4编译代码，保证编译通过〔不运行程序〕对代码进展全面检查用调试模式启动程序，一行一行单步执行代码，并留意调试输出转变条件，让代码尽可能走遍全部程序分支CheckInBuild代码集成公布前需冻结代码，全部人把要提交的代码CheckIn，并保证编译后的程序能在测试效劳器上正常启动，界面能正常翻开。同时还要提交Build《BuildBuild版本号和日期Bug修改的功能实现的功能其他说明集成测试依据《测试打算》针对《Build清单》执行《测试用例》，测试完成后编写测试报告。《测试报告》的内容包括：测试用例汇总〔用例数量、通过的用例数量、未通过的用例数量等〕Bug汇总〔Bug总数、增Bug数量、关闭Bug数量、Bug趋势图表等〕测试打算执行状况测试总结阶段产品公布《公布清单》的内容包括：《公布清单》的内容包括：产品版本号和日期改正的Bug修改的功能实现的功能其他说明《阶段总结报告》的内容包括：阶段任务的完成状况进度打算的执行状况用户的反响状况本阶段遇到的主要问题下一阶段的改进建议5、把握阶段这个阶段的工作是确证工程工作的结果符合工程的打算。它通过对工程结果的衡量和这个阶段的工作是确证工程工作的结果符合工程的打算。它通过对工程结果的衡量和审核，与工程打算所期望的结果进展比较，找出实际结果与打算的差异，并制定处理措施。这个阶段的工作还包括对工程进程中消灭的任何更改要求进展审核和批准先级或挨次的修订。、风险治理开发期间要对风险进展监控，定期检查、更和公布《风险列表》。开发期间要对风险进展监控，定期检查、更和公布《风险列表》。、质量治理1〕 评审1〕 评审评审是质量保证的重要环节，原则上每个重要的工作任务或阶段完毕前都必需经过评审，如：方案评审、打算评审、需求评审、设计评审和代码评审等，工作是否被通过、是否需要修改或重做均由评审结果打算，评审结果以《评审报告》的形式公布。《评审报告》的内容包括：根本信息评审主题、时间、提交者、评审者等评审内容的列表和简述评审过程中重要的问答记录整个评审的结果，如：评审结论完全通过，无需修改根本通过，需要作小量修改，但不必再评审大体通过，需要作一些修改，之后再评审大体通过，需要作一些修改，之后再评审不通过，需要作大幅修改，之后必需重评审评审意见针对评审结论提出的意见和建议2〕 测试测试是对被构建产品最直接有效的质量保证措施，测试完毕后需要提交《测试报告》。、变更治理开发过程中常常会消灭多种变更，如：需求变更、设计变更或人员变更等。这些变更通开发过程中常常会消灭多种变更，如：需求变更、设计变更或人员变更等。这些变更通《变更处理报告》的内容包括：根本信息变更主题、发生时间等变更的具体描述变更的处理结果变更对工程造成的影响、进度监控题并打算下一步工作：《工作报告》的内容包括：根本信息： 报告者、汇报时间、工作时间段等工作状况： 已完成的工作、未完成的工作遇到的问题：工作中遇到的阻碍工作打算： 下一步的工作打算为进度表调整和资源调配供给重要依据。、测量在工程开发过程中，收集一些关键的测量，对了解工程状态和进展工程决策很有帮助，在工程开发过程中，收集一些关键的测量，对了解工程状态和进展工程决策很有帮助，同时也为以后的工程供给历史数据参考。每个测量都要生成测量报告并存档。《测量报告》的内容包括：根本信息，包括测量主题、测量时间、测量者等测量内容和测量值测量分析6、完毕阶段这个阶段的工作是确保工程的最终结果或提交物到达打算的要求这个阶段的工作是确保工程的最终结果或提交物到达打算的要求档，用户培训等。、产品测试严格，当产品的质量到达公布的要求后才能公布。产品的质量由《测试报告》表达。、RC公布公布RC版本让用户体验并收集反响意见，为产品验收作预备。RC版本公布后，产品不应当有大改动，一般只是界面的局部调整。、编制用户文档南》，对一般用户需要编制《产品使用手册》。《安装、维护指南》的内容包括：产品各组件的说明产品各组件的说明产品部署架构安装、配置和卸载等步骤启动、停顿和重启等操作其它操作：日志、备份、复原等《产品使用手册》的内容包括：产品介绍各个功能的介绍通过实际案例介绍各个功能的使用方式和操作步骤、产品使用培训要部署好操作环境，编写培训资料，然后组织培训会议。、产品验收验收时，用户通常会执行验收测试案例。、最终修订在产品验收通过后，正式公布前对产品作最终的修订，可能包括：在产品验收通过后，正式公布前对产品作最终的修订，可能包括：开发文档修订用户文档修订用户文档修订代码整理、正式版公布做一些预备工作，如：数据迁移和环境配置等。、工程总结归档为《工程总结报告》。《工程总结报告》的内容包括：总体评价本钱、收益汇总重要心得治理总结技术总结7、总结审，保证任务的质量。通制度是软件工程成功的重要保障。、工程方案汇总列出几种比较普遍的角色和任务划分方案：职责和角色不清楚往往是造成软件工程团队治理混乱的一个重要缘由队必需依据团队规模的不同和工程本身的特点对工程成员的角色和岗位进展明确的划分样团队中的每个成员才可能有清楚的责任和目标。划分后每个岗位成员可以兼职多个角色。形成相关的角色岗位矩阵。方案一工程负责人总览全局需求->软件需求->总体设计的全部工作。同时还需要做到整个团队进度规划，质量保证，能往往打算了整个软件工程的成败。我们这里指的小型团队并不是只一个人单打独斗的工程责人一般有较强的技术力气，所以工程负责人可以担当工程中要使用的一些技术的争论，工程中一些疑难问题的解决等相关工作行Review，对觉察的标准性，性能，复用差等问题跟工程成员确认，并写入到工程开发标准中。方案二工程负责人和开发负责人分别在这种方案下工程负责人和开发负责人在软件需求和架构上的工作是重叠的位的人员共同来确认工程的总体方案和架构跟踪和协调，开发负责人重点放在工程内部，而避开过多去和外部干系人沟通和协调。方案三测试的专职化对于工程团队进展到5-10一般测试人员的配置比例为4-6个开发人员需要配置一名专职化的测试人员。测试人员站在第三方和模拟使用者角度来进展系统的测试，可以更好的觉察系统的BUG和相关问题，有效的保证系统的质量。重点放在工程内外的沟通协调和整个工程进度打算的安排上对整个系统的