今天给各位分享详解软件项目管理流程的每一步的知识，其中也会对详解软件项目管理流程的每一步进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
详解软件项目管理流程的每一步的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于详解软件项目管理流程的每一步、详解软件项目管理流程的每一步的信息别忘了在本站进行查找喔。
本文导读目录：
1、项目管理中10大优秀项目跟踪软件，以及必须关注的9大流程节点
2、程序员一定要会的软件项目管理评估方案，不做只会敲代码的码农！（建议收藏）
拥有正确的项目管理工具集来处理分析、需求、变更和项目进展将帮助项目经理以最佳状态做出执行任务。 据悉，由于能够给企业经营性项目带来竞争力、知识和能力，顶级项目经理的需求量很大。但是，不要忘了拥有正确的工具集对于项目管理的成功也是至关重要的，毕竟巧妇难为无米之炊。 项目管理工具和模板不仅提高了团队的生产力和效率，而且为组织应对高影响项目带来的变化做好了准备。为了达到最佳状态，项目经理需要充分利用针对业务智能和分析、业务需求、变更管理和项目管理以及大量表单和模板的工具。 根据Gartner的2019项目和投资组合管理魔力象限，在决定什么对企业的业务最有利时，以下能力是必不可少的：项目需求管理项目规划和管理时间管理资源管理资源容量规划项目组合管理项目协作项目管理报表服务安全和用户管理集成可用性 在这里，我们整理出了国内外项目经理最常用的工具包，以帮助企业计划、执行、监视并成功地完成其下一个具有高影响力的项目。 项目管理工具对于确保团队能够在整个项目生命周期中进行沟通和协作至关重要。其中许多工具使项目经理能够共享想法；分配、计划并跟踪任务和里程碑进度；制定和跟踪预算；维护项目细节；跟踪质量；识别风险和问题。 这是国内国内的一款知名研发项目管理软件，曾在2021年，被知名媒体36氪评为：2021年国内研发项目管理榜单第一的研发项目管理系统。 PingCode 的优势在于：它是一款覆盖研发全生命周期的项目管理系统，被广泛用于需求收集、需求管理、需求优先级、产品路线图、项目管理（含敏捷/kanban/瀑布）、测试管理、缺陷追踪、文档管理、效能度量等领域。并且集成了github、gitlab、jinkens、企微、飞书等主流工具，也就是说我们能在需求下面关联代码，关联集成信息，在飞书查看通知等。 对比其他产品它具有简单易上手、开箱即用的特点，避免了Jira、禅道等使用上的辅助配置流程。 针对25人以下团队推出了免费版本，除此以外 PingCode 支持私有部署、定制开发、SAAS等版本；价格仅是Jira的30%-40%。PingCode 全功能体验通道 这款项目软件在国内拥有50万企业用户，可能是国内使用最为广泛的项目管理系统，多年频繁入选国内各大项目管理工具榜单前三。 在功能上，Worktile 具备OKR目标管理、项目管理、项目集管理、项目计划、项目风险、项目成本管理、企业网盘、审批、简报等能力。被广泛用于电商、市场活动、律所项目、生产制造、行政、财务、设计、工程、教育、科研等几乎包含所有类型的项目。 Worktile 为10人以下的小型团队提供了基础的免费版本。其最大优点就在于具备强大的自定义能力，能够配置出符合各种项目团队的流程、表单、字段、数据报表，以及丰富的模板市场。 Worktile 同样支持私有部署、定制开发、SAAS等版本。Worktile 全功能体验通道 Asana是小型团队的理想项目管理软件。它有三种不同版本Free、Premium和Enterprise。 特征：免费工具允许管理多达15个团队成员。它还提供基本的仪表板和搜索高级版提供无限制的仪表板，自定义字段，高级搜索和报告企业版允许使用服务帐户和SAML等高级管理控制来管理团队成员 下载链接： https://asana.com/ Microsoft 项目集成规划工具可帮助您无缝地跟踪项目。该工具提供了一种功能强大，视觉上增强的方式，可以有效地管理各种项目和程序。 特征：该工具为处理多个项目提供了完全可见性它连接到各种Microsoft产品，如Excel，Word，Skype等它非常直观，可用性和复杂性之间取得了很好的平衡 下载链接： https ://products.office.com/en-in/project/project-and-portfolio-management-software?tab=tabs-1 Clickup 是为所有类型的用户创建的项目管理系统。它可以帮助您使用分层方法组织项目。它结合了所有业务流程销售，营销，设计和开发的核心功能 特征：ClickUp集中了所有内容，可以从一个仪表板有效地工作人们可以通过不同的方式查看他们的任务和项目它提供机器学习功能。这有助于项目经理创建准确，切合实际的估算和时间表来管理他们的项目 下载链接： https://clickup.com/ Taiga 是一个免费开源，而且功能非常强大的项目管理平台，用于初创企业和敏捷开发团队。提供一个简单、漂亮的项目管理工具。Taiga 采用 Python Django 框架开发，前端基于 AngularJS 实现。 下载地址：https://www.oschina.net/p/taiga OmniPlan是适用于 macOS的最流行的原生 Mac 桌面项目管理应用程序之一。它来自 Omni Group，该团队创建了出色的图表软件Omnigraffle，这是Mac上 Microsoft Visio的流行替代品。Omni Group 产品专为Mac 等Apple 设备制造，没有 Windows 版本。 OmniPlan 比 Microsoft Project 更易于使用，可以导入 MS Project 文件（尽管最多只能到 MS Project 2016）并且在 Mac 上看起来很棒，因为它是专为 macOS 设计的。它使用清晰的甘特图布局，让你非常清楚地了解需要完成的工作。你还可以下载并试用 OmniPlan for Mac的全功能免费 14 天试用版。 缺点就是，昂贵的前期成本 【官网： https://www.omnigroup.com/omniplan/ 】 MeisterTask 是专为喜欢Kanban的用户量身定制的，这个项目管理软件工具让Kanban更加实用。您的任务，注释，笔记，截止日期等都像Kanban一样，设置在同一个地方。它具有灵活的项目板，是基于云的项目管理工具。 在免费版的MeisterTask中你能够享受以下功能：比如无限的项目和用户、与Slack和Zendesk两个软件集成、清单，注释，标签，任务和时间跟踪功能、用户友好的界面、文件共享和附件（最多支持20MB）等。 【官网： https://www.meistertask.com/ 】 Jira 可能是国内最知名的海外IT项目管理系统之一。 它被最早被广泛用于缺陷跟踪和敏捷项目管理，后来逐渐发展成覆盖研发全生命周期的IT项目管理系统，在国内Jira以成熟、个性化的项目管理能力，以及强大的外部工具集成而著称。但最近几年开始，停止在国内支持私有部署版本，从而导致越来越多的用户将项目迁移至PingCode等成熟的替代方案。 官网：http://Atlassian.com Teambition 是国内比较知名的一款项目管理软件，它集成了项目管理、文档管理、资源管理、流程管理、沟通协作等工具，支持不同的业务场景、不同的项目管理方式；其优点是深度嵌入钉钉，对同时使用钉钉的用户来说非常友好； 其缺点就是：为了追求的“简单易用”，牺牲了项目目标和分层分级权限管理——整体适用场景较为局限，难以实现项目的闭环管理（缺少目标、网盘管理能力）。自定义能力不强，无法很好的满足团队的个性化需求；按职能划分的项目模板，且核心为研发管理，场景较单一。不具备项目集管理能力、报表类型只支持两种、甘特图不支持导出Excel； 总结而言Teambiton最佳使用人数是10人以下。 官网： https://www.teambition.com/ 有了项目管理软件，项目进度管理就不再是难事。但作为项目经理，首先要关注的就是以下九个关键的流程点。 项目要开始了，先给项目来个定义吧。不管你如何并为何要进行描述，你要对你的项目进行书面定义，让相关方和项目组随时参考。 项目定义的价值在于，项目主管方和其他相关方传达了他们对项目的期待。 清晰的项目定义包括以下方面：项目目标项目回报 对项目范围进行定义，列出所有预期的项目成果成本和时间预算目标重大困难和假设描述该项目对其他项目的依赖高风险、所需的新技术、项目中的重大问题 将尽可能多的具体信息囊括在项目描述或章程中，并使其在相关方处获得认可，进而生效。 不管你在你公司里有多大的影响力和权力，对分包商项目成员影响都会比较小。 建立成功的外包关系需要时间和精力，为了不误项目工期，你要及时把所有细节做到位，所有合同及时签订；你打算外包哪部分项目，对这部分工作的细化就是你实施项目控制的着手点；记录这些细化的内容、评估和接收标准、所有相关要求、必要时间规划。 项目定义信息一定要包括在合同之内，相关责任尽早确定。和所有你考虑到的供应商讨论这些要求，这样你的项目期望才会在各方之间明晰。 作为项目经理，通过制定有力的规划、跟踪、执行流程，你可以建立项目控制的基础。让项目组成员参与规划和跟踪活动，可以争取大家的支持并提高积极性。资深的项目经理往往大范围地鼓励成员参与，并通过流程汇聚大家的力量。 当大家看到自己的努力以及对项目的贡献被肯定的时候，项目很快就从“他们的项目”变成“我们的项目”。当项目成员视项目工作为己任的时候，项目控制就会简单得多。 技术项目中最多的问题就是缺少对变更的管理控制。要解决这个问题，需要在项目各方面启用有效的变更管理流程。 制定好受各方认可的变更流程图，这提醒了项目相关方，变更在被接受之前会进行细致地考察，并且提高了变更提案的门槛。 审查变更提案的时候，要注意该提案是否对变更有清晰到位的描述，如果描述得不清不楚，就要打回去；对于技术方面的变更，要多打几个问号，因为提案人也许不能全面地判断问题。 风险管理的流程能让你制定出全面的规划，找出潜在的麻烦，根除严重的问题。 风险管理要做到事半功倍，就要与项目规划同时进行。进行项目工作分解时，注意对项目活动的不恰当理解；分配项目任务和开展评估时，寻找风险；资源匮乏或项目资源不足，或项目工作依赖于某一个人时，要知道风险的存在…… 分析项目工作将遇到的困难，鼓励所有参与规划的人设想最坏的情况和潜在困难。 项目质量的标准分两类：行业内实行的全球质量标准，公司或项目独有的质量标准。 如果你的公司实行或接受了质量标准，要注意该标准对你和团队有何要求。具体而言，这些标准会包括ISO 9000标准或六西格玛，进而确定质检清单、质控流程及相关要求，并将其与你的项目规划进行整合。 项目必须遵守的书面步骤、报告、评估，对团队成员是强有力的推动，标准比你的临时要求更有效。 项目开展过程中问题的出现不可避免。在项目初期，要为项目的问题管理确定流程。建立跟踪流程，记录当前问题。 对于没有太多权力的项目经理而言，问题跟踪流程的价值在于把握问题状态和进度的实时息。 一旦问题责任人承诺了问题解决的时限，你可以任意公布问题解决过程中的变数。不管问题责任人是本项目成员，还是其他项目或部门的成员，谁都不乐意随时将自己的大名置于人们质疑的目光中。问题清单的公开使得掌握该清单的人获得一定的影响力和控制力。 项目管理时时有决策，快速得当的决策对于项目控制至关重要。即使项目经理很有控制权，集体决策仍然裨益颇多，因为共同决策能获得更多内部支持，效果自然会更好。 尽早和项目组一起设立决策流程，流程应该包括以下步骤： 清楚地陈述要解决的问题。吸纳所有需要参与决策的人，以及将会受决策影响的成员参与，以争取团队支持。与项目组一起重审项目陈述，让大家获得一致认识。针对决策标准（如：成本、时间、有效性、完整性、可行性）开展讨论。与项目组一起确定各标准的权重设定决策的时限开展头脑风暴，在规定时间内尽可能多地产生决策想法。通过集体投票的方法进行筛选，并按照权重进行排序。尽量采用排在第一位的结果。如果没有异议，结束讨论并开始实施决策。将决策写入文件，并与团队成员及项目相关方面沟通决策结果。 信息是非常关键的资源，如何管理值得仔细思考。有的项目使用信息管理系统进行项目信息的存储；有的项目则使用群件来维护项目文件，用邮件作为辅助。 不管你用何种方式存储项目数据，要保证所有项目成员能随时获得所需信息。将最新的项目文件存储在方便查找的位置，进行清楚地标记，及时删除过时信息。 以上就是项目管理中，项目经理会经常使用到的10大项目进度追踪管理工具，其中包含免费项目管理系统、开源项目软件、付费saas项目管理软件等等，希望对大家项目管理有所帮助。 软件项目管理是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程，是在软件开发过程中，对开发工作进行全方位评估的有效措施。 Hello！我是灰小猿，一个有故事、爱分享、没技术的程序猿， 今天大灰狼来和大家聊聊除了软件编码，在软件项目管理阶段所需要进行哪些工作。提前祝大家从技术佬晋升产品总监！ 很多刚步入软件行业或者正在学习的小伙伴都有这样的感觉，觉得编码阶段是软件开发中的关键步骤，但其实不然，如果我们把软件开发的过程比作建造一座大桥的话，编码阶段只不过是建筑工人添砖加瓦的建造过程，更多的方面则是软件的设计、管理、维护等阶段的进行，同样这也是一个软件开发过程中必不可少的阶段和流程。 软件项目管理阶段所需要进行的工作分别是：软件规模评估、工作量评估、进度计划、人员组织、质量保证、软件配置管理、能力成熟度模型七个阶段。 下面大灰狼和大家聊一下每个阶段的任务和评估方法，（文章较长，小伙伴们可以收藏以后慢慢学习） 首先，什么是软件项目管理？ 所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。 软件项目管理先于任何技术活动之前开始，并且贯穿于软件的整个生命周期之中。 软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算。 为了估算项目的工作量和完成期限，首先需要估算软件的规模。 常用的软件规模评估的办法是代码行技术和功能点技术。这两种评估方法各有利弊，接下来大灰狼和大家分别分析一下： 代码行技术是比较简单的定量估算软件规模的方法。 依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。 当有以往开发类似产品的历史数据可供参考时，估计出的数值还是比较准确的。把实现每个功能所需要的源程序行数累加起来，就可得到实现整个软件所需要的源程序行数。 估算方法： 由多名有经验的软件工程师分别做出估计。 每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)。 分别算出这3种规模的平均值、和之后，再用下式计算程序规模的估计值： 单位：LOC或KLOC。 代码行技术的优点： 代码行技术的缺点： 功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。 这种方法用功能点(FP)为单位度量软件规模。 1. 信息域特性 功能点技术定义了信息域的5个特性： 每个特征根据其复杂程度分配一个功能点数，即信息域特征系数a1，a2，a3，a4，a5，见下表。 2. 估算功能点的步骤 (1) 计算未调整的功能点数UFP 首先，把产品信息域的每个特性都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数。 然后，用下式计算未调整的功能点数UFP： UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf 其中，ai(1≤i≤5)是信息域特性系数，其值由相应特性的复杂级别决定，如表13.1所示。 (2) 计算技术复杂性因子TCF 这一步骤度量14种技术因素对软件规模的影响程度。在表13.2中列出了全部技术因素，并用Fi(1≤i≤14)代表这些因素。 根据软件的特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。 然后，用下式计算技术因素对软件规模的综合影响程度DI： 技术复杂性因子TCF由下式计算： TCF = 0.65 + 0.01 × DI 因为DI的值在0~70之间，所以TCF的值在0.65~1.35之间。 (3) 计算功能点数FP FP = UFP × TCF 功能点技术优点： 与所用的编程语言无关，比代码行技术更合理。 功能点技术缺点： 在判断信息域特性复杂级别和技术因素的影响程度时主观因素较大，对经验依赖性较强。 工作量的评估通常有：静态单变量模型、动态多变量模型、COCOMO2模型， 值得注意的是，大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的。 没有一个估算模型可以适用于所有类型的软件和开发环境。 明确了以上两点之后，接下来就是各个模型的评估方法了， 总体结构形式如下： E = A + B × (ev) C 其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量（KLOC或FP）。1. 面向KLOC的估算模型 (1)Walston_Felix模型 E=5.2×(KLOC)0.91 (2)Bailey_Basili模型 E=5.5+0.73×(KLOC)1.16 (3)Boehm简单模型 E=3.2×(KLOC)1.05 (4)Doty模型（在KLOC>9时适用） E=5.288×(KLOC)1.0472. 面向FP的估算模型 (1)Albrecht & Gaffney模型 E=-13.39+0.0545FP (2)Maston,Barnett和Mellichamp模型 E=585.7+15.12FP 动态多变量模型也称为软件方程式，该模型把工作量看作是软件规模和开发时间这两个变量的函数。 动态多变量估算模型的形式如下： E=(LOC×B0.333/P)3×(1/t)4 其中E 是以人月或人年为单位的工作量；t 是以月或年为单位的项目持续时间；B 是特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=5~15），B=0.16,对于超过70 KLOC的程序，B=0.39； P是生产率参数，它反映了下述因素对工作量的影响： 开发实时嵌入式软件时，P的典型值为2000；开发电信系统和系统软件时，P=10000；对于商业应用系统来说，P=28000。可以从历史数据导出适用于当前项目的生产率参数值。 COCOMO是构造性成本模型（constructive cost model)的英文缩写。 1981年Boehm在《软件工程经济学》中首次提出了COCOMO模型。 1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修订版，它反映了十多年来在成本估计方面所积累的经验。 COCOMO2给出了3个层次的软件开发工作量估算模型，这3个层次的模型在估算工作量时，对软件细节考虑的详尽程度逐级增加。 3个层次的估算模型分别是： 应用系统组成模型：这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。 早期设计模型：这个模型适用于体系结构设计阶段。 后体系结构模型：这个模型适用于完成体系结构设计之后的软件开发阶段。 该模型把软件开发工作量表示成代码行数（KLOC）的非线性函数： 其中，E是开发工作量（以人月为单位），a是模型系数，KLOC是估计的源代码行数，b是模型指数，fi (i=1~17)是成本因素。 每个成本因素都根据它的重要程度和对工作量影响大小被赋予一定数值（称为工作量系数）。 与原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述变化。 为了确定工作量方程中模型指数b的值，COCOMO2采用了更加精细得多的b分级模型，这个模型使用5个分级因素Wi(1≤i≤5),其中每个因素都划分成从甚低（Wi=5)到特高（Wi=0)的6个级别，然后用下式计算b的数值： 因此，b的取值范围为1.01~1.26。显然，这种分级模式比原始COCOMO模型的分级模式更精细、更灵活。 COCOMO2使用的5个分级因素如下所述： 项目先例性：这个分级因素指出，对于开发组织来说该项目的新奇程度。 开发灵活性：这个分级因素反映出，为了实现预先确定的外部接口需求及为了及早开发出产品而需要增加的工作量。 风险排除度：这个分级因素反映了重大风险已被消除的比例。 项目组凝聚力：这个分级因素表明了开发人员相互协作时可能存在的困难。 过程成熟度：这个分级因素反映了按照能力成熟度模型度量出的项目组织的过程成熟度。 软件项目的进度安排通过把工作量分配给特定的软件工程任务并规定完成各项任务的起止日期，从而将估算出的项目工作量分布于计划好的项目持续期内。 进度计划将随着时间的流逝而不断演化。 各种模型估算开发时间的方程很相似，例如： T=2.5E0.35 T=2.5E0.38 T=3.0E0.33+0.2×(b-1.01) T=2.4E1/3 其中，E是开发工作量（以人月为单位），T是开发时间（以月为单位）。 经验告诉我们，随着开发小组规模扩大，个人生产率将下降，以致开发时间与从事开发工作的人数并不成反比关系。出现这种现象主要有下述两个原因： 当小组变得更大时，每个人需要用更多时间与组内其他成员讨论问题、协调工作，因此增加了通信开销。 如果在开发过程中增加小组人员，则最初一段时间内项目组总生产率不仅不会提高反而会下降。 Brooks规律：向一个已经延期的项目增加人力，只会使得它更加延期。 存在一个最佳的项目组规模Popt，这个规模的项目组其总生产率最高。项目组的最佳规模是5.5人，即Popt=5.5。 Gantt(甘特)图是历史悠久、应用广泛的制定进度计划的工具。 例子： 旧木板房刷漆工程(15名工人，工具各5把) Gantt图的主要优点： Gantt图的3个主要缺点： 工程网络是制定进度计划时另一种常用的图形工具，它同样能描绘任务分解情况以及每项作业的开始时间和结束时间。 它能显式地描绘各个作业彼此间的依赖关系。 工程网络是系统分析和系统设计的强有力的工具。 符号： 工程网络必要的信息： 每个作业估计需要使用的时间：箭头长度和它代表的作业持续时间没有关系，箭头仅表示依赖关系，它上方的数字才表示作业的持续时间。 最早时刻EET：该事件可以发生的最早时间。 最迟时刻LET：在不影响竣工时间的前提下，该事件最晚可以发生的时刻。 机动时间：实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些，而并不影响工程的结束时间。 最早时刻的计算： 事件的最早时刻是该事件可以发生的最早时间。 通常工程网络中第一个事件的最早时刻定义为零，其他事件的最早时刻在工程网络上从左至右按事件发生顺序计算。 计算最早时刻EET使用下述3条简单规则： ■考虑进入该事件的所有作业； ■对于每个作业都计算它的持续时间与起始事件的EET之和； ■选取上述和数中的最大值作为该事件的最早时刻EET。 最迟时刻的计算： 事件的最迟时刻是在不影响工程竣工时间的前提下，该事件最晚可以发生的时刻。 按惯例，最后一个事件(工程结束)的最迟时刻就是它的最早时刻。其他事件的最迟时刻在工程网络上从右至左按逆作业流的方向计算。 计算最迟时刻LET使用下述3条规则： ■考虑离开该事件的所有作业； ■从每个作业的结束事件的最迟时刻中减去该作业的持续时间； ■选取上述差数中的最小值作为该事件的最迟时刻LET。 某些作业有一定程度的机动余地——实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些，而并不影响工程的结束时间。 机动时间=(LET)结束－(EET)开始－持续时间=右下角－左上角－持续时间 在制定进度计划时仔细考虑和利用工程网络中的机动时间，往往能够安排出既节省资源又不影响最终竣工时间的进度表。 最早时刻和最迟时刻相同的事件(机动时间为0的作业)定义了关键路径，在图中关键路径用粗线箭头表示。 关键路径上的事件(关键事件)必须准时发生，组成关键路径的作业(关键作业)的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。 为了成功地完成软件开发工作，项目组成员必须以一种有意义且有效的方式交互和通信。 管理者应该合理地组织项目组，使项目组有较高生产率，能够按预定的进度计划完成所承担的工作。 除了追求更好的组织方式之外，每个管理者的目标都是建立有凝聚力的项目组。 一个有高度凝聚力的小组由一批团结得非常紧密的人组成，他们的整体力量大于个体力量的总和。 民主制程序员组的一个重要特点是，小组成员完全平等，享有充分民主，通过协商做出技术决策。因此，小组成员之间的通信是平行的，如果小组内有n个成员，则可能的通信信道共有n(n-1)/2条。 程序设计小组的人数不能太多，否则组员间彼此通信的时间将多于程序设计时间。 民主制程序员组通常采用非正式的组织方式，也就是说，虽然名义上有一个组长，但是他和组内其他成员完成同样的任务。 民主制程序员组的优点： ■组员们对发现错误抱着积极的态度，有助于更快地发现错误，导致高质量的代码； ■小组成员享有充分民主，有高度凝聚力，学术空气浓厚，利于攻克技术难关； ■若组内多数成员经验丰富，那么本组织方式会非常成功。 民主制程序员组的缺点： 如果组内多数成员技术水平不高，或是缺乏经验的新手，由于没有明确的权威指导开发工程的进行，组员间将缺乏必要的协调，最终可能导致工程失败。 采用这种组织方式的原因： 软件开发人员多数比较缺乏经验； 程序设计过程中有许多事务性的工作，例如，大量信息的存储和更新； 多渠道通信很费时间，将降低程序员的生产率。 主程序员组的两个重要特性： 1、专业化。该组每名成员仅完成他们受过专业训练的那些工作。 2、层次性。主程序员指挥成员工作并全面负责。 典型的主程序员组由主程序员、后备程序员、编程秘书以及1~3名程序员组成。 主程序员组核心人员的分工： 主程序员既是成功的管理人员又是经验丰富、技术好、能力强的高级程序员，负责体系结构设计和关键部分的详细设计，并且负责指导其他程序员完成详细设计和编码工作。 后备程序员也应该技术熟练而且富于经验，他协助主程序员工作并且在必要时（例如，主程序员生病、出差或“跳槽”）接替主程序员的工作。 编程秘书负责完成与项目有关的全部事务性工作，例如，维护项目资料库和项目文档，编译、链接、执行源程序和测试用例。 主程序员组的组织方式不切实际： 首先，主程序员应该是高级程序员和优秀管理者的结合体。通常，既缺乏成功的管理者也缺乏技术熟练的程序员。 其次，后备程序员更难找。 第三，编程秘书也很难找到。 实际的“主程序员”应该由两个人共同担任： 一个技术负责人，负责小组的技术活动，参与全部代码审查工作，因为他要对代码的各方面质量负责； 一个行政负责人，负责所有非技术性事务的管理决策，不可以参与代码审查工作，因为他的职责是对程序员的业绩进行评价。行政组长应该在常规调度会议上了解每名组员的技术能力和工作业绩。 由于程序员组成员人数不宜过多，当软件项目规模较大时，应该把程序员分成若干个小组。该图描绘的是技术管理组织结构，非技术管理组织结构与此类似。 把民主制程序员组和主程序员组的优点结合起来的另一种方法，是在合适的地方采用分散做决定的方法。有利于形成畅通的通信渠道，以便充分发挥每个程序员的积极性和主动性，集思广益攻克技术难关。 概括地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。 软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。 定义强调了下述的3个要点： ■软件需求是度量软件质量的基础，与需求不一致就是质量不高。 ■指定的开发标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致软件质量不高。 ■通常，有一组没有显式描述的隐含需求。如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。 影响软件质量的主要因素，是从管理角度对软件质量的度量。可以把这些质量因素分成3组，分别反映用户在使用软件产品时的3种不同倾向或观点。这3种倾向是：产品运行、产品修改和产品转移。 软件质量保证（software quality assurance,SQA）的措施主要有： ■基于非执行的测试（复审或评审），主要用来保证在编码之前各阶段产生的文档的质量； ■基于执行的测试（软件测试），需要在程序编写出来之后进行，它是保证软件质量的最后一道防线； ■程序正确性证明，使用数学方法严格验证程序是否与对它的说明完全一致。 1. 技术复审的必要性 正式技术复审的显著优点是，能够较早发现软件错误，从而可防止错误被传播到软件过程的后续阶段。 统计数字表明，在大型软件产品中检测出的错误，60%~70%属于规格说明错误或设计错误，而正式技术复审在发现规格说明错误和设计错误方面的有效性高达75%。由于能够检测出并排除掉绝大部分这类错误，复审可大大降低后续开发和维护阶段的成本。 正式技术复审是软件质量保证措施的一种，包括走查（walkthrough)和审查（inspection）等具体方法。走查的步骤比审查少，而且没有审查正规。 2. 走查 走查组由4~6名成员组成。走查组组长引导该组成员走查文档，力求发现尽可能多的错误。 走查组的任务仅仅是标记出错误而不是改正错误，改正错误的工作应该由该文档的编写组完成。 走查的时间最长不要超过2小时，这段时间应该用来发现和标记错误，而不是改正错误。 走查主要有下述两种方式： ■参与者驱动法 ■文档驱动法3. 审查 ■综述：由负责编写文档的一名成员向审查组综述该文档。 ■准备：评审员仔细阅读文档。 ■审查：评审组仔细走查整个文档。 ■返工：文档的作者负责解决在审查报告中列出的所有错误及问题。 ■跟踪：组长必须确保所提出的每个问题都得到了圆满的解决。 通常，审查组由4人组成。组长既是审查组的管理人员又是技术负责人。审查过程不仅步数比走查多，而且每个步骤都是正规的。4. 程序正确性证明 在20世纪60年代初期，人们已经开始研究程序正确性证明的技术，提出了许多不同的技术方法。 人工证明程序正确性，对于评价小程序可能有些价值，但是在证明大型软件的正确性时，不仅工作量太大，更主要的是在证明的过程中很容易包含错误，因此是不实用的。为了实用的目的，必须研究能证明程序正确性的自动系统。 目前已经研究出证明PASCAL和LISP程序正确性的程序系统，正在对这些系统进行评价和改进。现在这些系统还只能对较小的程序进行评价。 软件配置管理是在软件的整个生命期内管理变化的一组活动。 具体地说，这组活动用来：①标识变化；②控制变化；③确保适当地实现了变化；④向需要知道这类信息的人报告变化。 软件配置管理的目标是，使变化更正确且更容易被适应，在必须变化时减少所需花费的工作量。 1. 软件配置项 软件过程的输出信息可以分为3类： ■计算机程序（源代码和可执行程序）； ■描述计算机程序的文档（供技术人员或用户使用）； ■数据（程序内包含的或在程序外的）。 上述这些项组成了在软件过程中产生的全部信息，我们把它们统称为软件配置，而这些项就是软件配置项。2. 基线 基线是一个软件配置管理概念，有助于我们在不严重妨碍合理变化的前提下控制变化。 IEEE把基线定义为：已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。 简而言之，基线就是通过了正式复审的软件配置项。 具体来说，软件配置管理主要有5项任务：标识、版本控制、变化控制、配置审计和报告。1. 标识软件配置中的对象 为了控制和管理软件配置项，必须单独命名每个配置项，然后用面向对象方法组织它们。可以标识出两类对象： ■基本对象，是软件工程师在分析、设计、编码或测试过程中创建出来的“文本单元”。 ■聚集对象，是基本对象和其他聚集对象的集合。2. 版本控制 版本控制联合使用规程和工具，以管理在软件工程过程中所创建的配置对象的不同版本。 借助于版本控制技术，用户能够通过选择适当的版本来指定软件系统的配置。3. 变化控制 典型的变化控制过程如下： ■首先评估该变化在技术方面的得失、可能产生的副作用、对其他配置对象和系统功能的整体影响以及估算出的修改成本。 ■为每个被批准的变化都生成一个“工程变化命令” 。把要修改的对象从项目数据库中“提取”出来，进行修改并应用适当的SQA活动。 ■最后，把修改后的对象“提交”进数据库，并用适当的版本控制机制创建该软件的下一个版本。4. 配置审计 通常从下述两方面采取措施： ■正式的技术复审，关注被修改后的配置对象的技术正确性。 ■软件配置审计，通过评估配置对象那些通常不在复审过程中考虑的特征，是对正式技术复审的补充。5. 状态报告 书写配置状态报告回答下述问题： ■发生了什么事？ ■谁做的这件事？ ■这件事是什么时候发生的？ ■它将影响哪些其他事物？ 美国卡内基梅隆大学软件工程研究所在美国国防部资助下于20世纪80年代末建立的能力成熟度模型（capability maturity model，CMM)，是用于评价软件机构的软件过程能力成熟度的模型。 CMM的定义：CMM是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。 多种基于CMM的模型，构成了一个CMM族： 能力成熟度模型的基本思想是，由于问题是由我们管理软件过程的方法不当引起的，所以新软件技术的运用并不会自动提高软件的生产率和质量。能力成熟度模型有助于软件开发机构建立一个有规律的、成熟的软件过程。 对软件过程的改进，是在完成一个又一个小的改进步骤基础上不断进行的渐进过程，而不是一蹴而就的彻底革命。CMM把软件过程从无序到有序的进化过程分成5个阶段，并把这些阶段排序，形成5个逐层提高的等级。 CMM包括以下组成部分： CMM的用途： 软件过程评估，借助CMM分析软件组织当前软件过程的状态，明确其强项和弱项 软件过程改进，软件开发组织用它来改进开发和维护软件的过程，根据评估结果，从低级逐极向更高级发展，制定软件过程改进的策略。 软件能力评价，政府或商业企业用它来评价与一个特定的软件公司签订软件项目合同的风险。 1. 初始级 软件过程的特征是无序的，有时甚至是混乱的。几乎没有什么过程是经过定义的（即没有一个定型的过程模型），项目能否成功完全取决于开发人员的个人能力。 处于这个最低成熟度等级的软件机构，基本上没有健全的软件工程管理制度，其软件过程完全取决于项目组的人员配备，所以具有不可预测性，人员变了过程也随之改变。 2. 可重复级 软件机构建立了基本的项目管理过程(过程模型)，可跟踪成本、进度、功能和质量。已经建立起必要的过程规范，对新项目的策划和管理过程是基于以前类似项目的实践经验，使得有类似应用经验的软件项目能够再次取得成功。 处于2级成熟度的软件机构的过程能力可以概括为，软件项目的策划和跟踪是稳定的，已经为一个有纪律的管理过程提供了可重复以前成功实践的项目环境。软件项目工程活动处于项目管理体系的有效控制之下，执行着基于以前项目的准则且合乎现实的计划。 3. 已定义级 软件机构已经定义了完整的软件过程（过程模型），软件过程已经文档化和标准化。所有项目组都使用文档化的、经过批准的过程来开发和维护软件。这一级包含了第2级的全部特征。 处于3级成熟度的软件机构的过程能力可以概括为，无论是管理活动还是工程活动都是稳定的。软件开发的成本和进度以及产品的功能和质量都受到控制，而且软件产品的质量具有可追溯性。这种能力是基于在软件机构中对已定义的过程模型的活动、人员和职责都有共同的理解。 4. 已管理级 软件机构对软件过程（过程模型和过程实例）和软件产品都建立了定量的质量目标，所有项目的重要的过程活动都是可度量的。该软件机构收集了过程度量和产品度量的方法并加以运用，可以定量地了解和控制软件过程和软件产品，并为评定项目的过程质量和产品质量奠定了基础。这一级包含了第3级的全部特征。 处于4级成熟度的软件机构的过程能力可以概括为，软件过程是可度量的，软件过程在可度量的范围内运行。这一级的过程能力允许软件机构在定量的范围内预测过程和产品质量趋势，在发生偏离时可以及时采取措施予以纠正，并且可以预期软件产品是高质量的。 5. 优化级 软件机构集中精力持续不断地改进软件过程。这一级的软件机构是一个以防止出现缺陷为目标的机构，它有能力识别软件过程要素的薄弱环节，并有足够的手段改进它们。在这样的机构中，可以获得关于软件过程有效性的统计数据，利用这些数据可以对新技术进行成本/效益分析，并可以优化出在软件工程实践中能够采用的最佳新技术。这一级包含了第4级的全部特征。 处于5级成熟度的软件机构的过程能力可以概括为，软件过程是可优化的。这一级的软件机构能够持续不断地改进其过程能力，既对现行的过程实例不断地改进和优化，又借助于所采用的新技术和新方法来实现未来的过程改进。 以上就是进行软件项目管理阶段的七大阶段的主要任务和评估方法，有不足的地方还希望大家及时提出以便更正。 觉得不错记得点赞关注大灰狼哟！ 一、项目启动（项目开工会） 了解项目干系人及其利害关系。 所有项目组成员是否到位，如到位则拿到项目开发人员的简历，详细了解每个开发人员的情况（可能会组织到客户方面试）。 根据项目需求规格列出项目功能列表，并根据开发人员技术等情况创建WBS。 根据项目时间、资源等情况规划项目初步开发计划（各里程碑时间点的粗略计划，每个时间段投入多少人力等）。 确定各种软硬件需求，如：版本控制服务器、数据库服务器、开发服务器、缺陷管理软件服务器、开发工具等。 参与人员： 项目经理、项目总监、全体项目组成员、用户方领导、用户方参与人员、其它主要项目干系人 项目启动会议的目标： 让整个项目组的成员相互认识 建立项目的工作关系和沟通关系 让大家明确团队的工作目标 让大家了解项目的当前状态 一起审阅项目计划 找出项目的难点或可能出问题的环节 分配小组和个人的角色与责任 获得小组和个人的承诺 实施建议： 对立项管理过程域产生的所有有价值的文档如《立项建议书》、《立项调查报告》、《立项可行性分析报告》、《立项评审报告》进行配置管理。 做好必要的保密工作。 由于每个项目都要占用机构的资金和资源，立项评审一定要严格。建议对机构高层管理人员进行必要的立项管理培训。 输出文档包括： 项目风险管理计划、工作任务分解结构（WBS）、项目进度计划、配置管理计划、质量保证计划、TimeSheet、开发规范文档、测试计划 二、需求分析 需求调研：与客户就其所需要的功能、流程、操作等需要为基础，而且需求决策者必须是项目经理或部门负责人。 列一个需求管理（包括详细的沟通计划及要求沟通）计划，考虑需求沟通中的人员、资源、时间的要求。 虽然有些因素是客户方造成的，但应该站在其角度上，为其考虑一些存在的客观及主观因素。 注意与项目成员之间的沟通方式及对团队的建设。 把握需求分析的进度及质量是否符合要求。 根据交互设计原型与客户交流需求分析是否达到要求及功能点是否有遗漏。 有哪些文档或数据是由客户提供的，这些数据是否需要在新开发的系统中维护等。 实施建议： 先对项目成员进行培训，让他们掌握必要的需求开发技能。(比如需求开发要做什么，做到什么程度，需要注意哪些问题等) 对需求开发过程域产生的所有有价值的文档进行配置管理。 需求的建模分析有较高的技术难度，项目成员应当根据自身水平进行取舍。 交互设计中应以用户的易用性为前提然后考虑在这样设计的前提下技术上实现是否有难度或者工作量超过前期设计的百分之二十. （多用TAB形式，尽量让客户的某个角色的任务可以在一个页面中完成，一般用上下文菜单，避免用系统的菜单，一个功能块一般只需要一个入口） 输出文档包括： 产品需求分析说明书、数据流程图、系统应用架构图、交互设计原型、需求分析模型(RQM) 三、概要设计 确定影响系统设计的约束因素：本系统应当遵循的标准或规范、软件、硬件环境（包括运行环境和开发环境）的约束、接口/协议的约束、软件质量的约束、隐含约束等。 确定设计策略：扩展策略、复用策略、折衷策略。 系统分解与设计：将系统分解为若干子系统，确定每个子系统的功能以及子系统之间的关系；将子系统分解为若干模块，确定每个模块的功能以及模块之间的关系。 数据库概要设计。 输出文档： 产品概要设计说明书、数据概要设计模型(CDM) 四、详细设计 确定功能模块的参与者、数据库表、输入参数说明、前置条件、基本流程、异常流程、日志等信息。 各层次结构的接口定义 数据库设计：逻辑设计—>物理设计－>安全性设计－>优化 实施建议： 先对系统设计人员进行“专题”培训，让他们掌握必要的系统设计技能。 由于国内绝大多数的大学不开设“用户界面设计课程”，这导致大部分软件开发人员不善于设计用户界面。项目开发小组应当设法邀请用户界面设计专家参与（或指导）本软件的 界面设计。 对系统设计过程中产生的所有有价值的文档进行配置管理。 输出文档： 产品详细设计说明书、数据物理设计模型(PDM)、自定义数据类型及BO数据类型文件、数据字典、系统测试用例、对象模型(OOM) 五、Coding 软件编码，各接口的实现。 单元测试。 实施建议： 对开发人员进行“高质量程序设计”培训，让他们掌握编写高质量程序的技能。 对开发人员进行“版本控制、代码审查、测试、改错”等方面的培训，提高他们的工作效率。 开发小组根据项目的资源、时间等限制因素，可以适当地减少测试的工作量。 对实现与测试过程中产生的所有代码和有价值的文档进行配置管理。 输出： 单元测试报告、代码评审报告 六、集成测试 根据系统测试用例测试系统的功能性需求，保证系统的正常功能处理及异常处理是否正确。 用户界面测试，重点是测试软件系统的易用性和视觉效果等。 健壮性测试,测试软件系统在异常情况下能否正常运行的能力。(容错能力和恢复能力) 安全性测试(这种测试一般能通过建行的fortify 软件评测即可) 如果产品需要安装，那么还得经过安装与反安装测试 实施建议： 对系统测试人员进行必要的培训，提高他们的测试效率。 项目经理和测试小组根据项目的资源、时间等限制因素，设法合理地减少测试的工作量，例如减少“冗余或无效”的测试。 系统测试小组根据产品的特征，可以适当地修改本规范的各种文档模板。 对系统测试过程中产生的所有代码和有价值的文档进行配置管理。 为了调动测试者的积极性，建议企业或项目设立奖励机制，例如：根据缺陷的危害程度把奖金分等级，每个新缺陷对应一份奖金，把奖金发给第一个发现该缺陷的人。 输出： 系统测试报告、缺陷管理报告、操作手册 七、客户验收 成果审查。验收人员审查开发方应当交付的成果，如代码、文档等等。确保这些成果是完整的并且是正确有效的。 验收测试。验收人员对交付的产品进行全面的测试，确保产品功能、质量符合需求。 及时解决客户方发现的问题。 输出： 客户验收计划、验收测试用例、客户验收报告、验收操作手册 实施建议： 在客户验收之前，开发方对验收人员进行必要的产品培训。 开发方可以将系统测试用例给验收人员参考，以减少设计测试用例的时间。 开发方人员应当热情地协助验收人员。对验收人员发现的软件缺陷马上予以纠正；对于复杂的问题应当立即请示有关领导，不可拖延。在验收期间不可与客户争吵，给客户留下很 好的印象。 对验收过程中产生的所有有价值的文档进行配置管理。 八、结项 计划与实际情况对比:产品功能、工作成果、产品质量、投入人员、工作量、成本等 申请结项理由和项目自我评价 对项目进行综合评估，总结经验教训。 有价值的结项管理至少包括三项内容： 一、对项目的有形资产和无形资产进行清算，既要防止资产流失，又要及时地利用这些资产。 二、对项目进行综合评估。例如评估项目完成情况、项目质量、投入产出分析、项目的市场价值、项目对企业的贡献等等。该评估报告可以作为考核项目人员业绩的重要依据。 三、总结经验教训，使整个机构受益。 实施建议: 对结项管理过程域产生的所有有价值的文档进行配置管理。 做好必要的保密工作。 结项评审工作不能简化。 对结项评审委员会进行必要的培训，使他们树立正确的观念，从而严格把关 输出： 结项申请书、结项评审报告 下面是这些核心工具的运用经验： 1.必须建立源代码的版本控制系统，就是cvs，基本的代码提交原则： 1)程序员尽量每天只在下班前提交一次; 2)提交的代码必须是在自己的机器上是正常运行的； 3)每次提交都必须用简短的话说明自己提交代码的功能描述。 2.建立错误追踪系统，用Bugzilla就很好，配置好邮件系统，使Bugzilla成为测试人员与开发人员沟通的桥梁。 3.用BAT和Perl脚本，以cvs中的源代码为核心实现简单的每日编译工具，将这个自己写的自动化工具放到一台专门的编译机器上，在每天的半夜开始自动下载代码，自动编译代码，自动打包安装程序，自动记录各种编译日志，自动将安装程序放置到一个固定的以日期为目录名的公共区。（用cvs2cl.pl得到程序员上传的代码更新日志，以便测试人员参考） 4.测试人员的第二天，应该到公共区取得头天的最新版本，并根据ChangeLog进行新版本的测试。并将测试中发现的Bug，通过Bugzilla反馈给程序员。程序员可以根据自己的情况或公司的规定来决定修改这些Bug的时间。并将这些Bug的修改情况，在代码提交时，写入代码日志。 5.开发人员的第二天，应该到公共区查看编译日志，看看自己的模块是否正常编译，及时更正，看看自己的邮箱有没有Bug报告，及时修改。 6.管理人员的第二天，在综合项目需求与头天版本进度的上，可以判断产品的发展方向，如果有偏航或理解错误或有新需求时，可以根据当前情况及时调整。 这样，通过 cvs => bugzilla => daily-build，就能将程序员与测试员，进行互动，各施其责。减少沟通与人为的麻烦。对于管理层，也能做到心中有数：因为每天都有新版本， 随时掌握产品的走向。。。等等详解软件项目管理流程的每一步的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于详解软件项目管理流程的每一步、详解软件项目管理流程的每一步的信息别忘了在本站进行查找喔。
未经允许不得转载！ 作者:谁是谁的谁，转载或复制请以超链接形式并注明出处。
原文地址：http://www.idifang.com/post/23758.html发布于：2026-04-15
