A项目软件开发存在的问题,项目管理论文.docx

《A项目软件开发存在的问题,项目管理论文.docx》由会员分享，可在线阅读，更多相关《A项目软件开发存在的问题,项目管理论文.docx（15页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、A项目软件开发存在的问题,项目管理论文题目 第一章 第二章 3.1 3.2 3.3 3.4 A项目软件开发存在的问题4.1 - 4.3 4.4 - 4.6 4.7 - 4.9 第五章 结论/以下为参考文献 3.3 人员配置 A 项目的组织架构确定后，就需要对项目各岗位的详细职责进行具体的界定和划分，保证每项任务落实到每个人，做到精细化管理，职责界定和划分如下所示： 3.3.1 公司管理高层 高层管理者的支持是软件经过改良得以顺利施行的基本前提。高层管理者是施行 CMM的原动力，其对 CMM 的认识、决心以及推动都是至关重要的。假如高层管理者的重视只停留在口头上，没有做到身体力行，那将会很多实际

2、问题难以解决。由于经过管理不仅牵涉某些工作岗位、某些项目和部门，而且牵涉资源和组织架构的调整，牵涉到公司的方针、经过、规程的制定，任何一个项目经理或部门总监的权利都无法到达整个组织的所有范围。 因而，高层管理者对经过管理的推动力度是组织内部任何人都无法代替的。高层管理者需要明确地认识到软件质量的重要性，推广和监督质量管理活动，介入制定质量保证规范，将质量活动布置到位，在公司内部树立起全面质量管理TQM的意识，并构成企业文化。 3.3.2 质量保证QA组 QA 部门的主要职责是计划和施行项目的质量保证活动，保证软件经过和产品的开发步骤及标准得到遵守和执行。质量保证组独立于项目组，并有直接向高层经

3、理汇报的权利。 其详细职责如下： 1 制定并维护质量保证计划 QA 人员根据项目计划制定质量保证计划，并在项目计划更改时更新质量保证计划。 2 经过评审 QA 人员对项目已定义经过进行检查，若发现不符合项，则与项目经理或相关开发人员讨论发现的问题，并记录到问题跟踪表中进行跟踪，直到问题解决为止。 3 产品评审 QA 人员对软件项目或产品进行检查，若发现不符合项，则与项目经理或相关开发人员讨论发现的问题，并记录到问题跟踪表中进行跟踪，直到问题解决为止。 4 介入同行评审 QA 人员需要介入同行评审，并对同行评审经过和评审的项目或产品进行检查。 5 汇报评审情况 在项目或产品评审结束后，QA 人员

4、需要对评审结果进行复查、整理，构成评审报告，然后给项目组汇报项目或产品评审情况，包括符合和不符合项的情况汇总等信息。假如存在与项目组达不成一致意见，或者项目组对发现的问题没有在规定的时间内解决的，QA 人员能够直接向高层管理者汇报情况。QA 人员能够针对发现的问题，对其进行原因分析，然后直接汇报给高层领导。 由此可见，QA 工作在软件经过管理经过中起到了举足轻重的作用，经过管理的成败与否与 QA 的工作正常与否有着直接的关系。因而，QA 人员需要有较高的专业素质，包括熟悉软件工程、熟悉软件质量体系和其它专业知识如质量控制技术、统计学知识等，以及具有良好的沟通和协调能力。 3.3.3 工程经过组

5、EPG 工程经过组专门负责一个组织中软件经过改良方面的组织协调工作，推进组织所采用的软件经过的定义、维护和改良工作；支持但不直接负责软件开发和维护工作。这个小组的成员能够由全职和兼职人员组成。详细职责如下所示： 1 定义和维护标准经过工程经过组根据公司的业务流程定义出公司的标准经过，并定期地对标准经过进行维护。 2 辨别公司存在的缺乏 定期对公司的经过和项目进行评审，找出存在的问题。 3 制定经过改良计划 制定年度经过改良计划，该计划的内容需要包括定期发现公司的缺乏之处、QA 人员检查发现的问题、项目施行经过中发现的问题、项目的经历体验总结等。 4 建立并维护公司的财富库和度量库。 5 向高层

6、领导汇报经过改良情况。 3.3.4 项目经理PM 项目经理负责项目的策划，介入需求调研和需求分析，组织人员进行系统的架构设计、概要设计和具体设计，在项目的施行经过中对项目进行监督和控制，以保证项目按计划开展。对项目而言，项目经理的主要职责是对整个项目的总体业务负责，指导、控制、管理整个项目的开发经过；对客户而言，是公司的接口人，负责与客户需求变更确实定、项目验收、合同的签订等工作。同时，项目经理需要定期向高层管理者汇报项目状态和进展情况。因而，项目经理应该具备如下素质： 1 基本项目管理知识和技术能力，熟悉项目管理 9 大知识领域；2 组织协调能力；3 领导能力；4 指挥能力；5 人际交往能力

7、；6 鼓励能力。 3.3.5 各相关组人员配置 3.3.5.1 配置管理CM组 配置管理组主要负责策划、协调和施行公司、部门和项目的配置管理活动，对公司的资料、数据等各种文档进行配置管理。主要职责有： 1 制定并维护配置管理计划配置管理组人员根据项目计划制定相应的配置管理计划，并在项目计划变更时更新配置管理计划。 2 定期汇报配置管理状态。 3 进行软件的版本控制在软件开发经过中，需要对程序代码进行版本控制。对每次完成的回归测试进行一次版本升级，需要配置管理员CMO对相应版本代码进行复制或同步处理；在该版本发布时，需要把该版本的最新代码同步到主干的代码目录中，构成发布版本。这部分工作相当重要。

8、否则，由于代码不同步引起的程序不一致，会导致功能缺失或错漏的情况，直接影响系统的正常运行。 4 进行配置审计 对准备检入配置库的文档进行物理检查，逐一检查文档能否存在，文档的命名能否规范以及途径能否一致。这样，就保证了配置项的完好性和一致性。 3.3.5.2 评审组 评审组的成员一般是临时性小组，通常来历自各部门的业务专家或技术资深的人员组成。评审组人员负责对各个阶段的评审进行业务或技术把关，每个阶段通常要进行同行的预评审和正式的会议评审。比方，开发计划、需求分析、概要设计、具体设计、测试用例等都要进行评审。可见，评审组对软件质量的保证起到了非常重要的把关作用。 3.3.5.3 系统分析组 系

9、统分析组人员通常被称为系统分析师，其主要职责有： 1 介入项目的需求调研，进行需求分析，编写技术方案；2 负责项目的概要设计，包括功能子系统划分、模型设计、数据库构造设计等；3 核心、关键模块的算法设计，指导具体设计和开发；4 关键、核心的算法或功能编码实现；5 修正设计、编码发现的错误直至系统能正确、正常运行；6 介入项目的质量把关及验收工作。 3.3.5.4 软件开发组 软件开发组成员是指软件工程师，通常根据计算机开发语言对软件工程师进行划分。如，DCS 软件工程师、ifix 软件工程师、PLC 软件工程师等。其主要职责是根据项目经理分配的工作任务，进行程序代码的编写、单元测试、程序调优等

10、工作。 3.3.5.5 软件测试组 测试并不仅仅仅是为了找出错误，通过分析错误产生的原因和错误的发生趋势，能够帮助项目管理者发现当下软件开发经过中的缺陷，以便及时改良。软件测试组人员的主要职责有： 1 根据项目文档制定测试计划与测试方案；2 准备测试数据，搭建测试环境，进行项目测试工作；3 编写测试用例，及时总结和汇报测试中发现的问题，提交测试报告。 软件测试人员通过集成测试、系统测试、回归测试、压力测试、性能测试等测试方式方法发现程序问题，保证软件系统在交付给客户使用前出错率降到最低限度。 3.4 A 项目软件开发存在的问题 H 公司的软件项目开发经过根据 CMM 软件成熟度模型关键经过域的

11、测量、评估标准来看，属于 2 级可重复级往 3 级已定义级的过渡阶段。根据 CMM 关键经过域的测量、分析和验证等量化指标，H 公司的软件项目在开发经过中，具体表现出了有纪律组织经过，基本项目管理经过进行成本、进度和功能跟踪，经过域基本涵盖了 CMM 模型 2 级关键经过域中的需求管理、软件项目计划、软件项目跟踪与监控、软件质量保证和软件配置管理。同时，开发经过在管理和工程方面趋于标准化，经过域牵涉到组织经过定义、组件协调、同行评审。然而，开发经过中存在的问题也不少。 3.4.1 用户需求和变更管理不完善 在任何一个软件开发经过中，都要充分地强调需求管理的重要性。因而，在项目初期，相对花比拟多

12、的时间做需求的搜集和跟踪，完善业务人员和技术人员的沟通机制是很重要的。这会减少大量的由于误解需求导致软件不符合用户需求进而返工造成的人力和物力的浪费。但是，A 软件项目开发管理经过中，却还存在着用户需求和变更管理不完善，导致开发出来的软件与用户的需求不匹配的情况存在。这主要表如今三个方面存在的问题： 1 从项目的需求搜集开场，业务专家搜集和提出基于整个业务的需求体系。但是，在从初始的需求转化为软件特性和功能的经过中，由于业务专家和技术人员的沟通不充分或者需求描绘叙述不完善，导致技术人员对需求的理解产生误解，进而影响该软件完成后，存在部分不符合用户提出的真实需求。 2 从初始的业务需求转化为软件

13、特性的经过中，缺乏有效的跟踪和管理，导致软件功能特性与用户需求脱节。 3 在项目经过中，用户提出改良的需求或者增加软件功能和特性。项目组在了解需求后，对软件架构进行调整或者重构。但是，如此频繁的重复下来，需求来源不清楚，软件规格书未及时反响需求变化，或者接受需求但未调整项目的整体进度，导致一些混乱情况的发生。 CMM 等级 2 中的需求管理，要求在顾客和将处理顾客需求的软件项目之间通过约定、活动和定量验证，来建立对顾客诉求的共同理解。每当改变分配给软件系统的需求是，都要调整遭到影响的软件计划，工作产品和活动，使其与更新后的需求保持一致。而 H 公司在常规软件开发经过中，由于上述情况，没有知足需

14、求管理的要求。同时，CMM 等级 5 中的技术变更管理能够辨别出新技术即工具、方式方法和经过，并以有序的方式将其引进到组织中。当 H 公司的软件开场经过认证等级相对提高时，技术变更管理这个经过域对解决此类问题更有效果。 3.4.2 软件配置管理问题 软件配置管理占据了越来越重要的角色，对文档、图形、代码和各种项目数据进行分类管理，并对不同的人拥有的权限进行控制，方便技术人员对其负责的配置项进行开创建立，提交和修改，提高项目整体的运作效率。但是，在软件配置管理中也存在着一些问题： 首先，没有制定好文档、图形、代码应放的位置，配置项命名比拟随意，无权限控制，造成各配置项存放混乱，寻找不易。在大型项

15、目中，由于各种文档，代码等非常多，假如不能进行正确的配置管理，很有可能被弄得一团糟。因而，在项目启动后，经过技术人员之间的讨论，在配置项的命名规定，目录构造，存放位置等达成共鸣，由于这些在详细使用上还和开发工具，开发语言等是密切相关的，在讨论的时候也应充分考虑这些因素，给技术人员在使用它们的时候提供最大的便利。当然，为了安全起见，大型项目中，权限的控制也是很重要的。另外，在一些情况下，假如没有权限控制，项目成员能够随意修改其它文件，这样可能会导致一些混乱情况的发生。 其次，培训和支持不充分，对配置管理工具的用法不了解。当前配置管理工具很多，比方大家常用的 Microsoft Project、A

16、utoCAD、Visio、Access 等，可能相比照较熟悉一些。但是诸如 iFix、ActivePerl 和 DOORs 等工具，由于软件功能非常复杂，并且对国内用户来讲易用性比拟差，固然功能强大，但是没有真正派上用场。 CMM 等级 2 中的软件配置管理要求建立和维护在项目的整个软件生存周期中软件项目产品的完好性。能够通过建立一个软件基线库，当软件基线构成时就将它们纳入该库，并通过更改控制和配置审计，来系统地控制基线的更改和相关产品的发布。这点在 H 公司在常规软件开发经过中没有具体表现出。另外，CMM 等级 3 中的培训程序，可以以避免因对配置管理工具的用法不了解，导致的软件项目质量问题

17、。 3.4.3 缺陷管理问题 一般缺陷的生命周期必然要经历 提交、打开、解决、关闭 这四个阶段。但问题是，H 公司对诸如 Clear Quest 的缺陷管理工具，进行了一些定制和二次开发，制定了一套严格的流程，缺陷的生命周期变得愈加复杂化了。但是，在执行的时候，开发人员往往仅在缺陷提交后，匆匆修正了缺陷，然后，置为解决状态，等待测试人员来关闭它。因而，这些情况下，缺陷状态的很多阶段都显得有些多余。但是，有人以为，在缺陷生命周期阶段多的情况下，能够让关注该缺陷的人员，更准确地了解该缺陷当前的状态。如何化解矛盾呢？ 事实上，给缺陷定义太多的生命周期阶段是不必要的。开发人员不愿意在解决缺陷的经过中，

18、不断地更新该缺陷的状态，另外，有些缺陷实际上很快就能解决的。太多的步骤反而降低效率，浪费时间。因而，从统计和了解缺陷数量和状态，这样的做法是好的。但是，从现实的角度来看，在施行的经过中缺乏可操作性。 此类问题在 CMM 模型不同等级的关键经过域中都有具体表现出。在等级 2 中的软件项目跟踪和监督就要求建立对项目实际进展的可视性，以便管理者在软件项目明显偏离软件计划是采取有效措施。在软件质量保证中则通过评审和审计软件产品和活动，来验证他们能否符适宜用的规程和标准。在等级 5 优化级中，缺陷预防经过域更能够鉴别缺陷的原因并防止它们再出现。 3.4.4 文档管理问题 1 文档问题 国内进行软件开发从

19、最初的完全不重视文档，到后来汲取无数的经历体验教训后，对文档的重视又被提高到史无前例的地步。但是，不少公司对应该写多少文档，怎么写文档不能把握好。由于，技术人员往往对文档方面的任务是抵触的，以为不如多抽点时间专注在技术方面，写文档纯粹是浪费时间。H 公司在文档管理方面要求一向严格，技术人员仍有抵触情绪，以为太多的文档是不必要的。 但是，文档却是必不可少的。应该如何处理好这种矛盾呢？ 事实上，这种矛盾天生就是难以化解的。由于，技术人员对技术和相关情况最了解，其它人很难撰写这些文档。项目经理所需要做的是，通过斟密的项目进度布置，给技术人员留出一些时间来书写文档在工作时间而不是在加班时间里完成，否则

20、难免会有怨言的，并在规定的进度下进行评审。 2 周报和月报问题 H 公司要求开发人员填写周报和月报，以便在项目周会，月总结上了解每个人任务的进展情况和对人员进行考核。但是，技术人员总是对此类工作不胜其烦，往往敷衍了事，填几个比拟大的任务如开发 XX 系统等，而且一连几周都是如此，这样对了解项目进展和对人员考核的参考作用就失去了意义。固然，技术人员比拟反感写这类东西，但是，周报月报还是必需要写的。应该如何化解此类矛盾呢？实际上，这类任务主要是人的因素在发挥作用。要想到达有效性的目的，对项目成员进行一定程度的指导和培训是必要的。文档的有效管理牵涉到 CMM 等级 2 中的软件质量保证，并且等级 3

21、 中的培训程序可以以对解决此类问题起到积极的作用。 3.4.5 工作包一致性问题 在软件开发经过中，不断有新的工作包产生，而且有些工作包随着一些变更的发生，就需要进行更新，但工作包数量过多，一则维护更新不容易，另外有些工作包只是项目结束后参考性的资源，立即更新也不必要，求大求全则会一定程度上占用项目资源，耽搁进度。 因而，一个建设性的建议就是，对必要的工作包，如需求规格书，产品定义书，概要设计书，具体设计书等，是一定要根据项目和评审情况立即进行修订和更新的。但是，对另外一些衍生的工作包，如用户指南等，固然在开发流程中，可能是在每个阶段都必要写的，但是却能够在评审进行前，集中进行更新一些，避免频繁修订造成的资源占用和进度延迟。 此类问题牵涉多个 CMM 关键经过域，华而不实尤其突出的是等级 2 中的软件项目计划、软件项目跟踪与监控和等级 3 中的组间协调。组间协调的目的是建立软件工程组和其它工程组一起积极介入的方式，使得项目更能有效地沟通协作来知足顾客的需求。