| UML软件工程组织 | |||
| |
|||
|
|||
软件开发管理与质量控制
作者：jiangxinyu的专栏 来源：csdn
| 前 言 随着市场经济的进一步完善及全球经济一体化进程加快，企事业单位面临着激烈的市场竞争，企业内部、外部信息交流已成为企业发展、参与市场经济竞争的迫切需要。企业引入先进的信息处理技术，增加信息共享程度，不仅会提高工作效率、降低成本，而且也会提高企业管理的科学性和自动化程度。信息已成为企业生存与发展的基础。 计算机和通信技术的迅速发展，特别是Internet 技术的发展与普及，为企业内部、企业与外部提供了快速、准确可靠的信息交流渠道，信息高速公路改变了企业与企业、企业与客户、企业内部各级决策者与管理人员以及管理人员之间的信息交流方式，有效地促进了企业各部门之间以客户为中心的协作，为企业实现经营方式、管理模式的改变奠定了坚实的基础。信息化企业运作管理系统已成为企事业单位参与全球市场竞争的必备的支持系统。 正是由于这样市场需求与技术发展现状，为我国的IT行业带来了空前发展的机遇，特别是软件行业。软件企业能否抓住这样一个难得的发展机会需要多方面的努力，其中软件开发管理与质量控制在其发展中占有重要的位置。本文试图在这方面进行初浅的分析，可供业内人士参考。
1. 国内软件行业发展概况 1.1 发展现状 在我国，随着信息技术产业的迅速发展及软件版权意识的提高，软件越来越受到了人们的关注与重视，越来越多的人把目光投到了充满风险与利益的软件行业。加之我国风险投资机构的逐渐形成，都将促进软件行业以比以往更快的速度发展。 人们往往把IT（信息技术）产业看作风险行业，原因可能有几个方面， 其一： 这是一个飞速发展的行业，说她飞速也并不过分，只有二十几年发展历史的IT行业，在世界500强企业中占有重要的位置，而当今世界上最具财富的也是IT类企业。高额的回报吸引大批企业的介入，一个企业要想在这个行业有所作为没有一个灵活而有利的团队加之一定的规模是难以生存的。 其二： 这是一个高科技领域，这个行业的技术的生命周期一般为一年到二年，高速的技术发展势必要求大量的科研开发经费，而科研开发是有风险的，成功与失败只是咫尺之遥。一旦失败，无投资残值可言。 其三： 这是一个知识密集型领域，知识就是财富也意味着笼络一批人才需要付出一定的代价。 但实实在在讲IT行业确实是一个高速增长的行业，虽然计算机的发明已有五十几年的历史，IT做为一个行业的历史也只有二十几年，而当今世界上最具财富的是IT类的公司，足见其成长的速度。我国软件行业大约有十年的发展史，到现在应该说也还是个很小的行业，虽然它在国民经济中所占的份额很小，但他对我国经济的发展，社会的进步起着很重要的作用。目前已形成一批具有一定规模的软件公司，如以财务软件为代表的“用友”、“金蝶”、“安易”等，及以项目开发型为特色的“东大阿而派”、“联想系统集成”、“北大方正”等企业。软件收入已占有一定的市场份额。发展速度惊人。 1.2. 存在的问题 我国软件行业发展的历史较短，加之IT行业技术发展速度快，软件开发工具层出不穷。我国的软件行业自身发展方面确实存在一些问题。归纳起来，有以下几方面的问题：
1). 软件开发管理不规范 目前大部分软件公司，无论是产品型公司还是项目型公司，大部分公司没有形成适合自己公司特点的软件开发管理模式，虽然有些公司根据软件工程理论建立了一些软件开发管理规范，但并没有从根本上解决软件开发的质量控制问题。这样导致软件产品质量不稳定，软件后期的维护、升级出现麻烦，同时最终也会损害用户的利益。 同时，随着软件开发规模及开发队伍的逐渐增大，软件开发不再是向过去那样一二个开发人员即可解决的事情。迫切需要一种开发规范来规范每个开发人员、测试人员与支持人员的工作，每个项目组成员按约定的规则准时完成自己的工作。同时采用规范化管理，专业分工也可以降低对开发人员的要求，从而降低产品研发成本。 2). 缺乏高素质的研发管理人员和研发人员 目前，我国软件市场还处于起步与发展阶段，真正称得上商品的软件很少，绝大多数的软件公司的规模很小，国内软件开发人员超过100人的公司很少。软件公司的用户几乎全是国内用户，加之国内软件专业的学校教育与实际软件开发脱节严重，开发人员工作不稳定，以及技术的高速发展以及开发工具的变更，导致软件开发人员缺乏必要的技术积累，表现为整体素质偏低。同时，由于没有合适的内部与外部环境也很难造就高水平的研发管理人员，从软件开发到开发管理都不能适应市场的要求。 3). 缺乏合格的产品经理 产品经理在软件产品的发展过程中起着至关重要的作用，产品经理负责产品的定位与发展方向。这就要求产品经理对产品市场、用户需求有深刻的认识与理解，需要有一定的悟性、管理经验与能力。同时，产品经理必须了解当今IT技术的发展状况及发展趋势，对相关开发工具与技术应有比较深刻的理解。对于大型应用软件的产品经理还要求其对网络技术、电子商务及各种硬件设备有全面的了解。这样才能保证在决定产品特性，产品框架结构、市场销售策略与服务策略时作出合理决策。从某种程度上讲，产品经理是否称职关系着其产品的存亡。目前软件行业急需而又缺乏正是这种产品经理。 4). 软件产品孤立、零散，缺乏整合性； 国产软件目前称得上产品的主要以财务软件、防病毒软件、家庭教学软件及一些初级的工具软件。总的说来基本为专用型产品、满足特定功能，即便是专用型产品其各专项子系统大多也缺乏整体考虑。大多厂家产品不具备构成大型应用系统的整合能力，目前一些公司已开始进行这方面工作。 项目型公司大多以项目为主，产品化程度比较低。不具备推广的条件，经济效益较差，影响公司的发展。 5). 软件公司规模过小； 目前我国软件市场还处于起步与发展阶段，绝大多数的软件公司的规模较小，国内软件开发人员超过100人的公司很少。软件公司的用户几乎全是国内用户。但软件作为一个行业，他需要市场的拖动，也需要外部资金的介入，外部资金的介入给它带来的不仅仅是金钱，更重要的是也带来了一种管理与思维方式，这也是国内软件公司需要的。 2 工程设计与软件开发 将软件开发作为工程来对待是有其存在意义的，在谈软件开发管理与质量控制之前，我们先看一下工程项目的整个过程。 2.1 工程设计的阶段划分 工程项目从可行性研究到最后项目建成基本包括如下八个阶段。最后二个阶段主要是考虑与软件开发比较而划分的，在实际的项目实施过程一般不将其作为独立阶段考虑。因此，一般的工程项目只包括六个阶段。（这里所指的工程项目可以是新建一间工厂，也可以是一个建筑工程项目） 但真正属于工程设计阶段的只是前四部分，以下以化工类工厂设计为例就属于工程设计的几个阶段的要求做以简单扼要的介绍，希望能软件开发管理有所帮助。
1) 可行性研究 在可行性研究阶段一般应完成如下几方面的工作： 2) 方案设计 方案设计可以说是可行性研究中技术可行性的扩展。方案设计级段主要完成如下几方面的工作： 3) 初步设计 初步设计是详细设计的前提，其目的是要根据具体项目的要求，初步确定技术实现的一些细节信息，主要完成如下几方面的工作： 初步设计是项目设计单位与用户交流的基础。 4) 详细设计 详细设计是以初步设计为基础，完成所有的技术细节工作。 详细设计是项目实施的基础。 5) 工程实施 项目详细设计是工程实施的基础，按照设计要求施工是最基本的要求。同时，在项目的实施过程中还会发现详细设计中存在的问题，可以通过向设计单位提出修改设计要求，由设计单位完成设计修改工作。项目工程实施也可采用项目监理的方式，监督施工单位按设计图纸及施工规范施工，确保施工质量。 6) 试运行 工程实施完成后便是投产试车，解决其中存在的问题，便可开始项目的试运行。 在以上工程项目的各个阶段中，可行性研究一般由设计单位或用户自行完成，也可委托具有该类项目评估经验的项目咨询机构完成。方案设计、初步设计、详细设计由工程设计单位完成，工程实施由工程施工单位完成。
2.2. 工程设计的质量控制 工程项目设计从设计单位接受用户委托，进行工程项目设计到设计任务完成，用户在几个环节均有参与项目质量的控制的机会，同时设计单位有严格的质量控制体系确保项目设计符合相关的标准与规范。
在以上的工程设计质量控制体系中，在每一设计阶段结束时用户均有机会参与对工程设计质量的监督与控制，设计单位与用户沟通的媒介是工程设计图纸及相关的设计文档，双方有交换意见的共同基础。设计单位会根据用户的意见与建议及时调整设计，以便更好的满足用户的需要。多年的设计经验证明，上述的工程设计质量控制体系是科学合理的。 2.3 软件开发与工程设计之比较 按照软件工程理论，软件开发过程基本可以划分为如下几个阶段： 从上面的软件开发阶段划分不难看出，软件开发与工程项目设计虽然看上是二类不同的工作，但他们本质上是相同的。不妨将软件开发与工程设计的阶段加以比较，不难得出上述的结论。 由图3不难可以看出软件开发与工程项目设计之间的相似性，因此将软件开发作为工程来管理是完全可行的。 2.4 软件开发与工程设计的差异 虽然软件开发与工程设计有其相似之处，但由于其所处的领域不同，发展历史与人文环境也有一定的差别，完全照搬工程设计的管理模式并不可取。首先比较一下工程设计与软件开发目前各自的现状。 1). 工程设计 2). 软件开发 正是由于工程设计与软件开发存在上述背景差异，应此在借鉴工程设计经验的同时，必须针对软件开发自身的特点，制定出符合企业自身的软件开发管理模式与相应的软件开发管理规范。这样才有利于我国软件行业的健康发展。 3 . 软件开发的组织机构 无论是项目型公司还是产品型公司，从事软件开发的组织或公司应该有一定的软件开发组织结构。一个合理的软件开发组织结构是确保软件开发质量的最基本保证，各个组织各负其责，可以确保软件开发按拟订的质量控制规则与软件开发计划进行，有利于软件公司软件质量与成本的控制。 3.1 软件开发组织机构设置 一般而言，对于产品型软件公司，其公司内部均会有一个类似与产品管理小组这样的一个组织，一个专门负责产品发展的产品经理部门。而项目型公司则相对简单一些，主要是针对项目进行定制开发，一般对项目的发展方向不做控制。但从项目开发演变为可推广产品的另当别论。一般来讲，下图4是一个典型的软件公司软件开发的组织机构设置。 3.2 组织机构的职责分工 在上述的组织机构中，各职能组织有各自明确的责权范围，完成各自的本职工作，各组织相互协调完成相应的软件开发与维护工作。 公司产品管理组：对于产品型软件公司而言，软件产品是其生存与发展的基础，公司对新产品立项、现有产品的发展方向及有关产品发展的重大决定均需由公司产品管理组来决定。 公司产品管理组一般由公司的执行总裁、技术总监、市场总监、产品经理、研发经理及其他必要人员。 产品管理部门 ：产品管理部门是界于研发部与市场部之间的一个桥梁部门。产品管理部门的主要职责是负责产品发展策略的制定与执行，这里的执行包括软件开发前期的市场及需求调研，完成可行性分析报告，制定产品规格。参与软件开发项目组，并完成相关工作。 * 软件开发前期：用户需求分析、功能描述、运行平台与环境、市场定位、销量预测与售价； 研 发 部 门：研发部是软件开发的主体，主要任务是完成软件或的项目的开发工作。其工作内容通过各职能组实现。主要包括： Architecture & QA：是软件开发的质量控制机构，主要职责是负责软件开发过程的质量控制。在软件开发的各个阶段，根据软件开发设计规范对阶段设计结果进行质量控制。及时发现问题、解决问题，确保进入下一阶段的设计符合设计规范要求。实现软件开发全程监控。 Architecture & QA为非常设机构，主要由研发经理、产品经理、资深系统分析远、测试经理等人员组成。根据项目进展需要，由研发经理召集进行项目阶段评审。 软 件开 发 组： 主要由各种角色的开发人员构成，完成开发任务。 CMO：（Configuration Management Officer）软件配置管理，对于一个具有一定规模的软件公司都会有一个软件配置管理机构，对于小型公司一般由项目经理带管，CMO的主要职责是进行软件开发过程中的软件配置管理，以及软件定版后的维护管理。在软件开发过程中，由于多个开发人员协同工作，需要对其工作协同管理，确保协同工作的顺利进行。同时，由专人进行配置管理，使得大部分开发人员不会得到全部原代码，也有利于软件公司的安全保密工作。在软件定版后，由于软件的Bugs，功能的完善及各种原因导致的对软件的修改，版本的控制就显得极为重要，软件配置管理可以确保得到不同时间的软件版本。 软 件 测 试 组 ：软件是软件工程的重要组成部分，软件测试组承担的工作主要是α测试。测试模块与集成测试由软件开发人员完成。对于项目软件开发，用户的计算机技术人员参加到软件测试与支持工作组，使用户参与整个软件的测试工作中。确保交付的应用系统是用户可信赖的系统。 在以上的软件开发组织机构中，不论公司规模的大小，以上的各个职能应该是健全的。明确的责任分工有利于软件开发的顺利进行于质量控制，同时，也必将有利于公司的成本控制，降低软件开发风险。 3.3 软件开发项目组的角色 一般来讲，一个软件开发项目组是由多个不同角色的人员构成，每种角色在软件开发中起不同的作用，各个不同角色的人员协同工作，完成软件开发工作。 典型的软件开发项目组由下列角色构成，如图5所示 在软件开发项目组中一般有六种角色，他们是： ①．产品管理 在大型软件开发项目中，可以将每个角色赋予不同的个人。对小型项目，一个人可以肩负多个不同的角色。每种角色的人员在项目中起着同等重要的作用。每种角色都有其特定的任务及技能要求。 产品管理：产品经理负责建立及更新项目的商业模型，在确定及设置项目目标方面起关键作用。产品经理应确保项目成员清楚理解项目商业目的，并根据商业需求的优先级确定功能规范。同时，产品经理负责高层的项目沟通，如：商业项目的成本核算、合同洽谈，及向相关人员通报项目进展等。 程序管理：程序经理负责确定软件特色及功能规范，根据软件开发标准协调日常开发工作确保及时交付开发任务。协助产品经理完成项目需求文档，并根据需求文档起草软件功能规范。同时负责与系统分析、规范及框架结构有关的各种活动。管理与协调与外部标准与系统的互操作性，控制项目进度。程序经理是项目组成员间沟通与协调的核心。 程序开发：开发队伍负责交付符合功能规范的软件系统。开发队伍应积极参与功能规范的制定，在建立项目原型时开发人员与程序经理可以同步进行并提供技术可行性。在功能规范确立后，开发人员必须与程序经理就如何解决重大疑难问题达成一致。 测试与质量保证：测试与质量保证是保证系统符合功能规范的保证。为保证“零误码”测试/QA人员应积极参与开发过程，确保开发出交付符合功能规范的软件系统。测试/QA人员负责准备测试计划、测试用例、自动测试程序、执行测试工作、管理并跟踪Bug。测试工作与开发工作是独立并行的。 用户培训：培训人员负责设计编写离线及在线培训文档，包括演示材料。用户培训人员应参与用户界面和系统的设计与构造，并参与安装程序与安装过程的设计。参与系统的可用性测试及设计改进，与程序管理与开发有密切的关系，并确保系统的变化及时反映到文档中去。 后勤支援：后勤支援包括确保项目顺利进行的各方面工作。 3.4 开发组人员构成 根据软件开发项目组织的角色划分，对于中等以下规模的软件开发项目组基本包括如下几类人员： 一般而言，产品管理人员同时担负用户培训的角色。程序管理角色一般由项目经理承担，而队后勤支持角色一般由研发部和公司统一承担，或由公司的信息系统管理人员协助完成。图6表示项目组的人员结构及承担的相关工作。
3.5 开发人员技术结构 宏观上讲，软件开发机构基本可分为二种角色，管理角色和技术角色。不同角色各有其不同的发展方向，如图7所示。
不论是走技术路线还是管理路线，不存在那种角色地位更高的问题。高级架构设计师与部门经理具有同等的地位与待遇。 4. 软件开发的阶段划分及目标 软件开发进行阶段划分主要有以下三方面优点： 4.1 软件开发的阶段划分 虽然软件开发与工程设计有其相似之处，但由于其所处的领域不同，发展历史与人文环境也有一定的差别，完全照搬工程设计的管理模式也存在一些弊端。下面就国外流行的软件开发模式与工程设计理论及原始的软件开发做以简单比较，见图8。
原始的软件开发模式很是简单，有些项目连需求分析都不完整，软件测试只是相当于模块集成一级的测试，没有规范的软件测试。软件质量取决于编程者个人的技术水平，质量无法保证，也很难控制。在满足用户需求方面取决于编程者个人的理解，软件交付后经常发生大面积的修改。项目似乎完成得很快，交付后大面积的修改经常导致延误工期，修改后的软件缺乏必要的测试手段，往往导致极大的售后服务支持成本。造成项目表面赢利、实际亏损的局面。 软件工程理论指导下的软件开发管理模式也存在一定的问题，那就是有些环节的可操作性较差，主要表现在需求分析到总体设计这个环节。需求分析是文档性的描述，一般是软件开发人员对用户需求的一种理解，这种文字描述一般很难精确可视地展现未来软件的情况，而用户也很难说清楚自己的需求，这就使得用户很难鉴别需求分析的精确性。往往导致软件交付后的大量修改。有一篇“Client / Server软件开发常犯错误”的文章说得好，“用户不知自己需要什么样的系统，但知道不要什么样的系统”。 为避免软件开发中需求分析到总体设计这个环节的歧异性问题，目前，国际流行的软件开发模式中增加了FS+UI（功能规范和用户界面）这个环节，这个环节不但解决了用户在需求分析理解上的困难，同时也解决了软件开发过程各种角色人员的并行工作问题，便于软件开发工期的缩短，有利软件开发质量与成本的控制 [ FS+UI（功能规范和用户界面）见后面章节 ]。 4.2 软件开发各阶段目标 以下就软件开发阶段划分的各阶段的任务与目标做以简单描述，这是软件公司进行质量控制的基础。 1) 可行性分析 可行性分析是软件项目立项的必要阶段，对于项目型软件开发，可行性分析一般由用户自行完成，软件公司基本在技术上给予必要的支持。对于产品型软件开发，可行性分析是非常重要的一环，产品采用的技术、市场定位与销售策略等直接关系着产品的生存与发展。 可行性分析基本包括如下几个方面的内容， A. 项目定义：项目定义主要是对产品定位有一个大致的描述，钩画出该软件产品的运行环境、产品功能、用户特征以及制约因数进行全面的描述，以便下一步工作的展开。 B. 技术分析： 此处的技术主要包括软件的开发环境与运行环境所涉及的各方面技术，在此应对这些技术的发展状况，成熟情况及未来的技术走势应有细致的阐述。 C. 市场分析： 包括国内外行业发展现状、市场格局、发展趋势，在市场容量统计数据的基础上，推测我们产品可能的市场占有率及销售情况。 D. 产品策略： 产品策略包括产品的技术策略与产品的市场策略。 E. 投资与回报分析：项目投资总额、项目成本核算、项目收益、投资回报等。 F. 已有资源分析：包括资金资源、人力资源、技术资源等的分析。 G. 其它应考虑的因素 2) 需求分析 需求分析是软件项目正式实施开始的第一个阶段，需求分析应该遵循可行性分析确定的基调，包括技术路线、产品基本功能、产品运行环境及市场定位。需求分析主要应完成对用户应用流程的描述，即完成商业逻辑分析。并根据商业逻辑的需要确定软件的功能列表及描述。 3) FS+UI FS+UI是产品管理部门与软件开发部门的接口，对于项目型开发是软件开发商与用户责任划分的重要依据，FS+UI不同于需求分析，它提供给用户的是一个清晰可见的用户界面与完整的功能说明，方便用户的理解与确认。软件开发据此进行下一步工作就有了坚实的基础，避免软件交付后的大量修改工作，有利于软件质量与进度的控制。同时，便于软件开发并行工作的展开。 FS+UI是软件总体设计及软件α测试的基础。 4) 总体设计 总体设计的依据是FS+UI文档，其目的是根据FS+UI要求，依据具体采用的开发工具与技术平台确定软件实现的对象关系与数据库结构。并非项目组每个成员均参加总体设计，一般来讲，一般中小项目总体设计为一到二个人，中大型项目一般为一个总体设计小组，由项目总设计师负责将项目进行分解为可操作的大小，交由不同设计小组完成相关功能的总体设计，总设计师负责协调各子项之间的协调关系，从而完成大型的总体设计。 总体设计设计深度情况直接影响下一步的详细设计。过细的总体设计也是不必要的，少量的人员进行过细的设计必然影响整个项目的设计周期，而过粗的总体设计当然也不利于详细设计设计任务的分配与设计展开。 5) 详细设计 详细设计是总体设计的继续，主要目的是完成总体设计完成的对象内部的商业逻辑的实现设计，在总体设计完成后可以将不同的设计对象交由不同的设计人员来完成。原则上讲，在开始软件编码之前应完成所有的设计细节，避免在编码中进行设计工作。 详细设计是编码及软件模块测试的基础。 6) 编码 编码是软件详细设计的一种再现，编码中最重要的是要遵从相关开发工具的设计规范及数据库设计规范，另外，养成一个良好的编程习惯是一个软件公司和软件编程人员最基本的职业素质。 对于软件应用可靠性要求严格的案例，所有软件模块必须通过模块测试，对一般应用软件中的重要模块也应进行模块测试。 7) 集成 集成是软件开发中重要的一环，集成测试的依据是软件的总体设计。如果缺乏前期的模块测试，必然会导致集成时间的加长，同时也会加重后期的α测试及问题处理的工作量。 8) α测试 α测试是在软件集成结束后软件开发进入的下一个环节，它标志着软件开发从设计级段进入软件测试阶段。一般情况下，软件开发从设计进入测试是通过CMO来完成这一过程。 为完成α测试，测试部门一般包括如下几个方面的工作。 一般而言，测试工作基本上可以分为如下几个轮回：
α测试是软件公司对自身产品的一次自我测试，α测试结束后，测试部门会提供一个软件测试评价报告，这个评价报告在某种程度上决定了该软件是否适应商业销售。 一般来讲，软件通过测试并不意味着软件没有任何问题，只是意味软件通过了可接受测试条件。软件测试的问题报告是软件公司售后服务与产品升级的重要参考因素之一。 9) 问题处理与设计文档改进 问题处理是软件开发组交付测试后的重要任务之一，及时解决软件测试过程中发现的问题，以便进行下一轮测试。 10) IRL内部定版 测试合格的软件在软件开发部内部定版，进入产品的组装或β测试，及产品销售。对项目型软件开发，则进入系统的实施级段。
5 过程管理与质量控制标准化 5.1 软件开发过程管理 传统的软件开发一般遵循的是瀑布过程模型,一个阶段的结束是下一个阶段的开始。这种模型不适合基于对象、分布式的企业应用开发。部件的开发具有并行性，而非顺序性。另外,瀑布进程模型缺乏灵活性，不适应快速原型开发工具的要求。 基于里程碑的过程模型引进迭代过程模型，允许开发任务的重叠和反复，可以很好适应基于部件的软件开发。基于里程碑的过程模型便于团队模型中责权的划分。便于风险评定，鼓励快速交货。 1) 里程碑过程模型的特征： 2) 里程碑的制定 里程碑也可以称作项目实施计划。对于软件开发项目而言，一但项目立项确定，需要做的第一件事情就是确定项目实施的里程碑。根据前面我们确定的软件开发阶段划分，在里程碑中应清楚地定义每一个阶段的开始时间、结束时间、负责人，阶段的提交成果由各阶段的软件开发规范确定。里程碑是公司对进行项目控制的主要依据。里程碑一旦确定，各相应负责人应确保按时交付任务。 对于各不同里程碑阶段可以根据需要制定阶段里程碑，阶段里程碑一般由开发组织内部确定以便于更好管理与控制项目的进程。达到某个里程碑表明对此负有主要责任的角色完策任务。便于明确各个角色责权范围、有利于按时完成任。 软件开发里程碑主要包括如下阶段：
3) CMO 软件配置管理 为确保软件及其文档的一致性，进行软件配置的管理是必要的。
5.2 质量控制体系 软件开发阶段划分的目的是为了便于形成基于里程碑的软件开发质量控制体系，每个里程碑都是一个质量控制结点，这些质量控制结点贯穿于整个软件开发全过程，从而构成软件开发的质量控制体系。 基于里程碑的软件开发质量控制体系可以用图11表示。
图12表示软件开发阶段目标与质量控制的关系 每个具体的里程碑与软件开发组某一具体的角色相关联，不同的角色则隶属于不同的业务部门，而人员业绩的评估与管理归属各自的业务部门，因此，基于里程碑的软件质量控制必然会演变成对角色的质量控制，这样才能真正达到对软件质量的控制。基于角色的质量控制体系详见图13 在软件开发的六种角色中，一般规模的软件公司都会将其做以归类，图13是基于常见的软件开发任务划分方式形成的基于角色的质量控制模型。 5.3 根据软件开发的阶段划分及基于里程碑的项目管理模式，贯穿于整个软件生命周期中的软件开发规范基本包括如下规范： 5.4 阶段审核制 软件开发阶段审核制是采用基于里程碑管理模式的必然产物。在每个里程碑结束时公司质量控制机构（QA）根据相应的软件开发管理规范及应用要求对阶段成果进行评议控制，确保应用开发的顺利进行，及交付的应用系统能够满足用户的使用需要，确保交付的系统能够代表公司的整体技术水平。同时也有利于规避软件开发风险。
6. 软件维护与版本控制 无论是项目型软件开发还是产品型软件开发，软件的维护与版本控制都是必须值得重视的。因为任何一个软件产品或一个应用软件开发项目或多或少存在一些值得改进的问题，这些问题可能是程序的Bug，也可能是因不能满足用户需要迫切需要改进的地方，对于交付运行的软件进行后期维护成为软件公司必不可少的工作。而由于后期维护所造成对已定版软件的修改的管理是致关重要的。 6.1 软件维护与版本控制的意义 软件维护与版本控制的目的有三点： 1). 解决由于问题处理带来对已定版软件的版本升级等管理问题，确保可以提供某一特定时间的版本，为用户提供满意的售后服务。 2). 解决软件开发过程中的版本控制问题，有利于团队开发的协同工作问题，也有利于公司对开发项目的版本控制及知识产权的保护。 ). 良好的版本控制与管理，有利于新版软件的开发工作的进行。确保软件产品循环渐进，逐步提高。 6.2 开发过程的版本控制 软件开发过程中的版本控制一般都是基于特定的开发工具和特定的版本控制管理工具，现在绝大部分的软件开发工具均提供这方面的功能。如Microsoft Visual Source Safe （简称VSS），IBM Visual 系列开发工具等，版本控制的原理大同小异，以下以VSS为例介绍软件开发过程的版本控制模型。 软件配置管理包括软件开发过程中的文档管理与程序管理，软件开发中的文档主要包括如下文档： 与CMO软件配置管理相关的文档一般包括： 不同配置管理软件的功能大同小异，总体来说，配置管理软件的安全性较差，为确保软件开发过程中代码与文档的安全，制定一个合理的系统备份策略是必要的。 7. 开发工具与技术积累 7.1 开发工具的选择 开发工具是开发人员进行软件开发所必备工具，选择合适的开发工具有利于产品的开发与软件公司的健康发展。选择开发工具时应考虑以下几方面的因素： 1) 开发工具的功能与技术先进性 开发工具的功能必须能够满足应用开发的需要，同时具备行业领先优势。这是选择开发工具必须首先应考率的。 2) 供应商的技术经济实力 开发工具供应商的技术经济实力是第二个应考虑的因素。雄厚的技术经济实力是开发工具在激烈的市场竞争中生存发展的基础，频繁更换开发工具意味着建立其上的技术积累将付之东流，不利于软件公司的发展。 3) 对行业标准的支持与左右程度 对行业标准的支持也是选择开发工具应加以考虑的因素，软件开发工具中各种标准发展迅速，开发工具对各种标准应有良好的支持。制定与左右标准的制定是公司技术实力的象征，每一新的标准的产生必然提高软件开发及程序运行的效率。有利于应用开发的进行。 4) 开发工具的市场占有率 市场占有率越高，意味着市场上可供选择的控件越多，选择成熟的控件是降低软件开发成本、提高软件可靠性的重要手段。应尽可能选择市场占有率高的开发工具。 5) 适应快速应用软件开发 适应快速应用软件开发是应用开发的需要，也是选择开发工具应考虑的因素。 7.2 技术积累 技术积累历来是公司发展的基础，对于软件公司尤其如此。这种技术积累一般包含三方面的含义。其一是人员技术素质及能力的提高；其二是公司在公共模块方面的积累；其三是对新技术的跟踪发展方面； 对于软件公司而言，人员的稳定是技术积累的主体，人员作为技术的载体在技术积累方面占有重要的位置，频繁的人员变动不利于软件公司的发展。 公共模块方面的积累主要取决于公司的发展方向，不同的公司有不同的积累方式与方向。公共模块的积累有利于后来项目开发的速度于质量，也是在激烈的市场竞争中求得生存发展得重要保证。 对于新技术得跟踪可以确保公司在技术上处于领先地位，适应日新月异技术得发展，确保公司不被淘汰。 7.3 对用户负责 用户是软件生命周期中重要的一环。软件开发的最终目的是为了满足用户的需求，同时用户的积极参与也是产品提高的基础，也是软件公司发展的前提。因此在软件开发过程中，应把用户的利益放在第一位。确保用户的利益不被侵犯。 结束语 一个良好的可操作的应用软件开发管理模式是确保应用软件开发达到预期目的的最基本保证，有利于降低软件开发与维护成本，降低软件开发风险。建立合理的软件开发管理模式、制定与完善相关软件开发标准是国内大部分软件公司与系统集成公司迫切需要解决的问题。希望本文在这方面能够给予一些启示。 |
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
