软件开发及管理

,软件开发及管理PreparedbyMichael,我的一些经验,管理分为两三个方面和客户的沟通需求管理周期争取经费支持等和部门管理层的沟通人员的配置其他方面的支持、销售人员的帮助等。和项目团队的沟通谁去做；什么时候完成；完成什么工作；怎么样才算完成了要求。要确保每一个组员都知道，每天需要做什么、完成什么。,目录,整体流程开发项目组职责开发概要开发计划软件开发管理方法软件设计软件测试软件维护致谢,设计工程,测试工程,FDD功能设计,UT,FT,ST,BD,FD,UT,FT,ST,CD,DD,维护,维护,确认开发概要,项目开发策划,设计输入评审,设计审查,出品判定,产品交付,整体流程,质量管理方法,项目组长（GL）,设计员,质量部门,程序员,测试员,客户需求,Coding,第三方检查,功能测试,软件设计,经理,项目开发策划,单体测试,项目负责人（PL）,项目开发组,Group进度、质量监控,经理,确保资源/下达开发任务书/任命项目组织,质质量数据分析/记录控制,系统测试,项目周报,项目监控,Project进度、质量监控,定单审核,客户需求：概要书评审,设计review,设计审查,CDInspection,出品判定,软件支持维护,项目监控,项目组成员职责,项目组成员按照工作职责分工为设计员、程序员、测试员（只是角色分工）；负责承担开发项目的设计、编码、测试、维护等具体实施；负责按照有关质量体系文件的要求，达到所承担任务的进度和质量要求；,开发项目组职责,开发项目组是软件产品开发的实体，是为一个开发项目建立的组织。负责软件开发项目的需求调查、设计、编码、测试及交付、维护全过程。,开发概要,1开发概要书内容要点开发概要书是描述客户需求的书面文件。一般包含下列内容：项目名客户的公司名部门名地址客户方的项目管理者名及其联系方法（电话FAXE-mail地址）项目委托业务内容客户方估算的工作量（开发规模、工时等）开发期间及交货期工作必需的软、硬件环境客户财产（资料、软件、硬件）及提供日期进度、质量管理方法预定提交的成果物一览。验收检查及验收条件,开发概要,1开发概要书作成要点作成者：客户/项目经理内容要与客户一一确认按照模板要求的内容作成，缺少的项目写出理由或“无”，不要空项客户提出的要求说明书、RFP等只要符合要求的内容，也可以作为开发概要书使用客户以口头、电话或mail形式提出开发概要书时，项目经理应整理成开发概要书，内容也应与客户一一确认,开发计划,1项目策划项目策划的中心，应该是决定为满足客户的要求，应投入哪些资源，设置怎样的管理体制和开发过程，如何进行质量、进度管理，如何保证项目交付期，以及节约成本、控制风险等。策划的依据：开发概要书项目报价书在项目策划的基础上作成Project开发计划书项目策划由经理和项目负责人负责,开发计划,2项目策划的主要内容（1）确定作业形态及开发过程模型1）确定作业形态：新开发改造项目移植项目维护项目其他项目2）确定开发过程模型：开发过程模型瀑布型（Waterfall）快速原型（Prototyping）螺旋型（Spiral）移植（porting）标准提供基本的开发过程模型，作为开发过程设计的参考根据产品特性，可选择适合的模型。3）划分开发工程阶段根据作业形态和开发模型，决定本项目划分的工程阶段。同时，决定适用于每个设计和开发工程阶段的评审、验证和确认工程。（必须有UT，无DD说明理由）,开发计划,2项目策划的主要内容（2）开发体制确定必须的人力资源每个成员的角色（项目经理、组长、设计员、程序员、测试员）确定其工作内容（按功能或模块划分）确定组织及领导的关系（如管理、报告的对象等）,开发计划,2项目策划的主要内容（4）资源开发环境和设备（软、硬件）的需求所需的开发工具和测试软件使用测试软件时，应充分评估其适用性。只有经评估适用的测试软件才能使用。鼓励研究发掘新的项目管理和实施辅助工具。（5）开发日程计划日程计划应作成线表，并设定重要的milestone必须明确制定日程计划的依据，用相关的数据说明可行性日程计划的主要项目：各开发工程或阶段的起始日期、开发作业整体的完成日期中间成果物和最终成果物及提交日期进行设计审查及交付验收的日程,开发计划,2项目策划的主要内容（6）质量计划1）产品的质量目标和保证措施依据公司的质量目标和部门的分解目标，制定项目的质量目标制定具体的保证措施2）适用标准和质量记录客户有明确要求，优先采用客户要求的质量管理标准和记录表格客户没有明确要求，适用本公司质量管理标准规定及其质量记录表格3）确定各开发工程完成的判定基准客户有明确要求，优先采用客户的基准客户没有明确要求，根据项目特点项目组确定移行基准4）交付基准客户有明确要求，优先使用客户的验收条件客户没有明确要求，项目组应制定满足用户隐含条件的交付基准,开发计划,2项目策划的主要内容（7）进度管理及沟通方式个人或项目组进度报告的内容、格式、提交期间、提交方式、发布范围等与客户进行技术讨论的方式、语言、时间间隔等项目进度会议召开周期、报告方式等与其他相关部门或项目组的联络窗口、沟通方式等小组会议项目组会议，通常以周会形式定期实施具体报告项目实施的情况和进度状况,开发计划,2项目策划的主要内容（8）配置管理决定软件配置管理的内容、方法、工具，以及软件产品版本的标识方法。*策划内容总结*（1）确定作业形态及开发过程模型（2）设计输入和设计输出（3）开发体制（4）资源（5）开发日程计划（6）质量计划（7）进度管理及沟通方式（8）配置管理,开发计划,3开发计划书3-1作成、审批每个项目必须作成开发计划书，详略程度可适应项目实际情况根据客户要求决定是否提交客户由项目组长作成，项目负责人查阅、部门经理承认。3-2内容除了项目策划的主要内容外，还有成果物交付、客户的验收条件、技术学习计划、风险管理、对客户的要求。3-3改版修订Project开发计划书改版修订的目的是为了使Project开发计划书中的安排能充分的控制项目的品质和进度，如果计划书中的日程、人员等安排，已经不能很好的对项目的进度和品质进行管理时，就需要进行改版修订。,开发计划,Project开发计划书变更的内容需要取得客户同意时，应与客户充分协商，客户同意后方可改版。发生下述情况之一时，需要进行改版：由于开发概要书改版或合同变更，必须调整开发内容和日程；由于不可预测的原因，必须调整开发内容或日程；本计划书中记载的交付日期发生的变更，包括中间版本的交付日期；4质量记录Project开发计划书（QR-B08-01）进度报告（QR-B08-02）注：指项目组的进度报告，格式可自定,软件开发管理方法,开发作业,与计划比较是否有问题？,问题点的分析,采取必要的对策,调整计划,对策充分吗,计划有必要调整吗,No,Yes,Yes,No,Yes,No,流程要点1对照实绩与开发计划设定的目标值2尽早发现问题并制定对策3必要时调整目标值4必要时改版Project开发计划书5调整后的目标值，记入项目开发履历表,1开发管理的流程,DCAP,软件开发管理方法,2品质目标管理概要,设计工程,TEST工程,项目计划设计工程TEST工程验收验收后,新开发改造留用移植,潜在Bug预测设定摘出目标,Bug摘出进度管理设计工程品质评价摘出目标重新评价,Bug摘出进度管理TEST工程品质评价摘出目标重新评价,验收品质评价,验收后品质评价,软件开发管理方法,3分析过程,制定目标值/计划值,目标值/计划值的妥当性评价,定量分析（差异分析）定性分析,没有问题,存在问题,查明直接原因并实施对策查明真正的原因并实施对策,存在问题,设计工程测试工程,继续开发,没有问题,软件开发管理方法,4品质数据分析的方法（1）设定Bug摘出目标值依据潜在Bug预测值，制定各工程阶段的Bug摘出目标值，记入项目开发履历表潜在Bug值的预测方法：根据同类项目经验值预测根据潜在Bug预测值的公式计算潜在Bug预测值的分布如：FD：40%DD：20%CD：40%Bug摘出目标值设定的目标：本工程摘出Bug预测值的70%，下一工程摘出其余的30%设计工程摘出Bug预测值的70%以上，TEST工程摘出其余的30%,软件开发管理方法,Bug目标值设定的示例,软件开发管理方法,4品质数据分析的方法（2）数据收集应注意真实性、有效性、必要性（3）数据分析时点设计工程设计工程结束建议：每个工程结束时都要进行分析TEST工程TEST工程结束建议：TEST工程进展中（4）数据分析的方法（5）Bug分析,软件设计,1职责1-1开发项目组完成软件基本设计，功能设计，详细设计，编码进行各项设计Review进行设计审查测试及交付、维护,软件设计,1-2设计员进行软件设计，负责作成、更改基本设计书，功能设计书详细设计书参加BDReview，FDReview，DDReview参加设计审查参加CDInspection1-3程序员根据设计书完成编码，使其通过编译参加CDInspection，并修正CDI发现的Bug修改测试工程中发现的Bug,软件设计,3设计工程3-1各设计工程要点(1)基本设计要点1）根据客户的需求以及基本调查、基本分析进行设计2）把握开发的目的、背景和效果3）明确产品的功能、性能及资源等的实现目标4）决定主要功能的实现方式。5）明确对产品评价的项目及其目标，可能的评价项目包括：功能性、操作性、可靠性、可维护性、可移植性等BD工程的输出是：基本设计书-ST测试设计书（也可在测试前完成）,软件设计,（2）功能设计要点本工程的设计输入是：基本设计书1）明确本次开发的内容、目的及对其他Component的影响2）明确地定义从外部看到的程序仕样说明3）详细描述外部interface4）明确定义程序具体的运行及操作方法，包括运行环境的目录结构等5）使用面向对象的语言进行开发时，也常常把Object、Method等作为功能概要、操作方法的设计内容FD工程的设计输出是：-功能设计书-功能测试设计书（可在测试前作成）,软件设计,（3）详细设计要点本工程的设计输入是：功能设计书1）程序逻辑设计（根据功能构造分解为模块）2）模块设计（模块的内部逻辑、外部接口等）3）数据设计（数据结构设计）4）外部文件设计5）制定各种规约，包括：命名规则，开发环境的目录结构设计规则、错误处理规则、出错代码设计，debug开关规则等DD工程的设计输出：-详细设计书-UT测试设计书（可在测试前作成）,软件设计,4Reviewreview开始的时点设计书草稿完成后程序编译通过后review的形式有会议、传阅、交叉review等方式必须对公共部分及核心部分实施会议形式的reviewreview工数注意：修改review发现的Bug所用的工数，不计算在review工数中，仅计算在该设计阶段的工数中。例：,CD工数,修改Bug工数,Review工数,软件设计,5设计审查5-1设计审查的要点功能上能否满足客户的要求性能上能否满足客户的要求操作性上能否满足客户的要求与其他公司的产品/功能相比是否有优势是否有面向客户的销售优势设计作业整体的一致性确认（设计分阶段进行时）项目的开发计划有无调整的必要针对存在问题提出改善措施,软件设计,6设计变更的管理6-1变更管理的注意注意事项变更容易引起错误变更后容易忽略其review、评审面对的客户式样变更增多,软件设计,6-2设计变更管理流程项目组讨论进行设计变更的内容、必要性及影响程度承认者根据讨论内容及自己的判断，必要时征求客户的意见，决定是否批准对设计书的修改。获得批准后，设计员对设计书进行更新改版。由原查阅、承认者或同级别的人员查阅、承认。因设计变更引起源程序修改时，应进行覆盖设计更改内容的设计验证测试。测试结果要经过项目组长确认。将设计更改的内容及时通知相关的部门和本项目组全体人员。必要时，修改后的设计应再次进行review和设计评审设计变更要经过批准，要有记录，不能随便修改,软件设计,6-3设计书修改方法填写改版履历应保留原来的版本，并作成完整的改版后的设计书客户特殊要求时，可采用在设计书后添加记述了更改位置和更改后内容的附加页,软件测试,功能式样的理解测试要点用例的做成和检查测试的实施Bug的管理进度管理,功能式样的理解,了解系统需求设立测试环境调整测试工具确定工作分工如果可能，与功能式样理解相关的工作可以在测试开始前就大致处理完毕，以提高工作效率并节约需方的费用。,测试要点和用例,根据设计文档提取测试要点形成树形大纲为每个要点做成测试用例检验大纲的完整性检查用例的正确性要点分配测试文档和版本管理每千行代码，预估单元测试项目数在100120、功能测试项目数在6080、系统测试项目数在20上下。根据不同的项目类型，会有不同。,测试的实施,分工到人测试组长监督进度使用测试管理工具进行严格管理及时反馈测试信息小组例会每千行代码，预估单元测试发现Bug数在10个左右、功能测试发现Bug数在4个左右、系统测试发现Bug数在1个左右。根据不同的项目类型，会有不同。,Bug的管理,Bug生命周期控制方法的作用Bug状态Bug生命周期模型Bug生命周期模型说明Bug类型和级别Bug的查询事件提示,Bug生命周期控制方法的作用,Bug生命周期控制方法是测试员、程序员、管理者一起参与、协同测试的过程。Bug状态不仅表示出Bug被修改、终结的进程，同时还标明了测试员、程序员、管理者的职责。这种方法分工明确，责任到人，它使每一个管理者和测试员、程序员都明确：尽快终结Bug，是他们共同奋斗的目标，团队精神将他们紧紧地结合在一起，使他们能够相互促进、相互制约、团结协作，因此Bug一旦发生，便进入测试员、程序员、管理者的严密监控之中，直至终结，这样即可保证在较短的时间内高效率地终结所有的Bug，缩短软件测试的进程，提高软件质量，减少开发和维护成本。,Bug状态,BUG状态：我们将BUG的生命周期划分为6种状态：Open态、Working态、Verify态、Close态、Cancel态、Defer态；Open态：表示测试员新发现的BUG、或验证未通过需重新修改的BUG；Working态：表示程序员正在修改的BUG；Verify态：表示程序员修改完毕，等待测试员验证的BUG；Close态：表示经测试员验证、确认软件Bug已被改正而关闭的BUG；Cancel态：表示经测试员验证、确认属于误报或重报、或由于开发环境Bug所致不能修改的BUG；Defer态：表示项目经理同意延期修改或追踪的BUG；活动态BUG：包括Open、Working、Verify态的BUG；终结态BUG：包括Close、Cancel、Defer态的BUG；,Bug生命周期模型,本模型中，箭头所指方向为所转向状态,Bug生命周期模型说明,典型的Bug生命历程:Open态Working态Verify态Open态/Close态/Cancel态;Open态Close态/Cancel态;Open态Defer态;三个活动状态Open/Working/Verify三个终结状态（也称为非活动状态）Close/Cancel/Defer,Bug类型,Bug类型：测试员报告Bug时判断Bug属性、选择Bug类型：功能错误、用户界面错误、边界值相关错误、初始化错误、计算错误、内存相关错误、硬件相关错误、文档错误错误类型：程序员修改BUG后分析错误原因、选择错误类型：编程错误、设计错误、需求分析错误、模块接口错误、其他；,Bug级别,严重级别：表示Bug的严重性，设置4个等级：1级:错误导致了整个系统失败（“崩溃”）或没法操作；2级:错误导致了一个特性（功能）不能运行，并且不可能有替代方案；3级:错误导致了一个特性（功能）不能运行，但有一个替代方案；4级:错误是表面化的或微小的；优先级别：表示BUG修改的优先度，设置4个等级：1级：在交付下一测试版本前必须修正，否则影响测试进程和BUG修改进度；2级：本测试阶段结束前必须修正；3级：如果时间允许就修正；,测试结束后的工作,统计分析测试总结报告,统计分析,Bug一览表Bug状态统计严重等级统计优先级别统计Bug曲线测试结果汇总表遗留问题一览表,Bug一览表,Bug状态统计,根据项目当前各个Bug所处的状态进行统计,严重等级统计,根据项目当前各个Bug严重级别进行统计,优先等级统计,根据项目当前各个Bug的优先级别进行统计,Bug曲线,一般在测试初期，活动态的Bug数会急剧上升，随着程序员、测试员的处理逐渐转为终结态。当所有软件Bug的状态都转变为终结态，且在一段时间内没有被打开，也没有新的Bug发生，即意味着测试可以结束或告一段落。在以下Bug状态随时间变化的曲线图中表现为累计报告的Bug曲线（BUG总数曲线）和累计终结的Bug曲线(已终结BUG曲线)收敛在一起。,测试结果汇总表,Bug状态分布和比率CLOSE态的BUG类型分布和比率CLOSE态的BUG错误类型分布和比率CLOSE态BUG发现阶段分布和比率CANCEL理由和比率DEFER理由和比率,测试结果汇总表-1,测试结果汇总表-2,遗留问题一览表,软件维护,1.合同相关1-1在合同维护期内对本公司所开发的产品，在出品后继续进行的维护工作接受客户委托，对属于客户的产品进行的维护工作1-2合同维护期结束后合同维护期结束后客户提出的维护工作要求，应签定新的合同,超过保修期喽！,软件维护,2.职责2-1项目负责人批准排除故障的软件产品是否可提交给客户如客户提出进一步的问题，应负责妥善解决，直到客户满意在部门会议上报告日常维护工作进展的状况以及出现的问题如果发现的故障对产品使用者有重大影响，项目负责人应立即向部门经理或助理进行报告承认设计变更功能追加的计划,软件维护,2-2项目组长作成维护工作的project开发计划书负责通知客户故障的原因及处理结果2-3维护工作担当分析故障发生的原因对故障进行处理，并修正出现类似问题的地方原因及处理结果填写在维护工作故障报告书中必要时应采取纠正措施，防止类似的故障再次发生对修改的设计书或源程序进行标识,软件维护,2-4维护工作担当根据客户提出的问题