软件开发管理与质量控制(二)

3.5   开发人员技术结构
宏观上讲,软件开发机构基本可分为二种角色,管理角色和技术角色。不同角色各有其不同的发展方向,如图7所示。
 
不论是走技术路线还是管理路线,不存在那种角色地位更高的问题。高级架构设计师与部门经理具有同等的地位与待遇。
4. 软件开发的阶段划分及目标
软件开发进行阶段划分主要有以下三方面优点:
1) 有利于软件质量控制;
2) 便于项目进度控制与管理;
3) 有利于项目成本费用控制;
4.1 软件开发的阶段划分
虽然软件开发与工程设计有其相似之处,但由于其所处的领域不同,发展历史与人文环境也有一定的差别,完全照搬工程设计的管理模式也存在一些弊端。下面就国外流行的软件开发模式与工程设计理论及原始的软件开发做以简单比较,见图8。
原始的软件开发模式很是简单,有些项目连需求分析都不完整,软件测试只是相当于模块集成一级的测试,没有规范的软件测试。软件质量取决于编程者个人的技术水平,质量无法保证,也很难控制。在满足用户需求方面取决于编程者个人的理解,软件交付后经常发生大面积的修改。项目似乎完成得很快,交付后大面积的修改经常导致延误工期,修改后的软件缺乏必要的测试手段,往往导致极大的售后服务支持成本。造成项目表面赢利、实际亏损的局面。
软件工程理论指导下的软件开发管理模式也存在一定的问题,那就是有些环节的可操作性较差,主要表现在需求分析到总体设计这个环节。需求分析是文档性的描述,一般是软件开发人员对用户需求的一种理解,这种文字描述一般很难精确可视地展现未来软件的情况,而用户也很难说清楚自己的需求,这就使得用户很难鉴别需求分析的精确性。往往导致软件交付后的大量修改。有一篇“Client / Server软件开发常犯错误”的文章说得好,“用户不知自己需要什么样的系统,但知道不要什么样的系统”。
为避免软件开发中需求分析到总体设计这个环节的歧异性问题,目前,国际流行的软件开发模式中增加了FS+UI(功能规范和用户界面)这个环节,这个环节不但解决了用户在需求分析理解上的困难,同时也解决了软件开发过程各种角色人员的并行工作问题,便于软件开发工期的缩短,有利软件开发质量与成本的控制 [ FS+UI(功能规范和用户界面)见后面章节 ]。
4.2  软件开发各阶段目标
以下就软件开发阶段划分的各阶段的任务与目标做以简单描述,这是软件公司进行质量控制的基础。
1) 可行性分析
可行性分析是软件项目立项的必要阶段,对于项目型软件开发,可行性分析一般由用户自行完成,软件公司基本在技术上给予必要的支持。对于产品型软件开发,可行性分析是非常重要的一环,产品采用的技术、市场定位与销售策略等直接关系着产品的生存与发展。
可行性分析基本包括如下几个方面的内容,
A. 项目定义:项目定义主要是对产品定位有一个大致的描述,钩画出该软件产品的运行环境、产品功能、用户特征以及制约因数进行全面的描述,以便下一步工作的展开。
B. 技术分析: 此处的技术主要包括软件的开发环境与运行环境所涉及的各方面技术,在此应对这些技术的发展状况,成熟情况及未来的技术走势应有细致的阐述。
C. 市场分析: 包括国内外行业发展现状、市场格局、发展趋势,在市场容量统计数据的基础上,推测我们产品可能的市场占有率及销售情况。
D. 产品策略: 产品策略包括产品的技术策略与产品的市场策略。
E. 投资与回报分析:项目投资总额、项目成本核算、项目收益、投资回报等。
F. 已有资源分析:包括资金资源、人力资源、技术资源等的分析。
G. 其它应考虑的因素
2) 需求分析
需求分析是软件项目正式实施开始的第一个阶段,需求分析应该遵循可行性分析确定的基调,包括技术路线、产品基本功能、产品运行环境及市场定位。需求分析主要应完成对用户应用流程的描述,即完成商业逻辑分析。并根据商业逻辑的需要确定软件的功能列表及描述。
3) FS+UI
A. 总体描述,包括应用平台及应用限制,...
B. 功能列表
C. 用户界面
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) 里程碑过程模型的特征:
A. 里程碑过程:软件开发过程是由指导开发进程的外内部里程碑所驱动的。
B. 明确责权关系:过程模型将每个里程碑与开发组的责任角色相关联。
C. 风险驱动的计划安排:高风险部件应尽早完成。
D. 评估说明:评估说明直接影响着项目的计划与管理,在整个软件开发过程中致关重要。
2) 里程碑的制定
里程碑也可以称作项目实施计划。对于软件开发项目而言,一但项目立项确定,需要做的第一件事情就是确定项目实施的里程碑。根据前面我们确定的软件开发阶段划分,在里程碑中应清楚地定义每一个阶段的开始时间、结束时间、负责人,阶段的提交成果由各阶段的软件开发规范确定。里程碑是公司对进行项目控制的主要依据。里程碑一旦确定,各相应负责人应确保按时交付任务。
对于各不同里程碑阶段可以根据需要制定阶段里程碑,阶段里程碑一般由开发组织内部确定以便于更好管理与控制项目的进程。达到某个里程碑表明对此负有主要责任的角色完策任务。便于明确各个角色责权范围、有利于按时完成任。
软件开发里程碑主要包括如下阶段:
3) CMO 软件配置管理
为确保软件及其文档的一致性,进行软件配置的管理是必要的。

5.2  质量控制体系
软件开发阶段划分的目的是为了便于形成基于里程碑的软件开发质量控制体系,每个里程碑都是一个质量控制结点,这些质量控制结点贯穿于整个软件开发全过程,从而构成软件开发的质量控制体系。
基于里程碑的软件开发质量控制体系可以用图11表示。

图12表示软件开发阶段目标与质量控制的关系

每个具体的里程碑与软件开发组某一具体的角色相关联,不同的角色则隶属于不同的业务部门,而人员业绩的评估与管理归属各自的业务部门,因此,基于里程碑的软件质量控制必然会演变成对角色的质量控制,这样才能真正达到对软件质量的控制。基于角色的质量控制体系详见图13

在软件开发的六种角色中,一般规模的软件公司都会将其做以归类,图13是基于常见的软件开发任务划分方式形成的基于角色的质量控制模型。
5.3 
根据软件开发的阶段划分及基于里程碑的项目管理模式,贯穿于整个软件生命周期中的软件开发规范基本包括如下规范:
1) 可行性分析规范 (FS)
2) 需求分析规范 (RS)
3) 功能说明规范 (FSS)
4) 用户界面规范 (UIS)
5) 总体设计规范 (GDS)
6) 详细设计规范 (DDS)
7) 程序编码规范 (CS)
8) 软件测试规范 (TS)
以上规范在软件开发阶段划分章节已有简单描述,此处不再介绍。
5.4  阶段审核制
软件开发阶段审核制是采用基于里程碑管理模式的必然产物。在每个里程碑结束时公司质量控制机构(QA)根据相应的软件开发管理规范及应用要求对阶段成果进行评议控制,确保应用开发的顺利进行,及交付的应用系统能够满足用户的使用需要,确保交付的系统能够代表公司的整体技术水平。同时也有利于规避软件开发风险。

6. 软件维护与版本控制
无论是项目型软件开发还是产品型软件开发,软件的维护与版本控制都是必须值得重视的。因为任何一个软件产品或一个应用软件开发项目或多或少存在一些值得改进的问题,这些问题可能是程序的Bug,也可能是因不能满足用户需要迫切需要改进的地方,对于交付运行的软件进行后期维护成为软件公司必不可少的工作。而由于后期维护所造成对已定版软件的修改的管理是致关重要的。
6.1  软件维护与版本控制的意义
软件维护与版本控制的目的有三点:
1). 解决由于问题处理带来对已定版软件的版本升级等管理问题,确保可以提供某一特定时间的版本,为用户提供满意的售后服务。
2). 解决软件开发过程中的版本控制问题,有利于团队开发的协同工作问题,也有利于公司对开发项目的版本控制及知识产权的保护。
3). 良好的版本控制与管理,有利于新版软件的开发工作的进行。确保软件产品循环渐进,逐步提高。
6.2 开发过程的版本控制
软件开发过程中的版本控制一般都是基于特定的开发工具和特定的版本控制管理工具,现在绝大部分的软件开发工具均提供这方面的功能。如Microsoft Visual Source Safe (简称VSS),IBM Visual 系列开发工具等,版本控制的原理大同小异,以下以VSS为例介绍软件开发过程的版本控制模型。

软件配置管理包括软件开发过程中的文档管理与程序管理,软件开发中的文档主要包括如下文档:
* 可行性分析报告
* 需求分析文档
* 功能规范及界面文档
* 总体设计文档
* 详细设计文档
* 编码设计文档(包括模块测试计划及结果文档)
* 测试计划文档
* 测试用例
* 测试评估文档(包括问题报告)
* 用户手册
* 在线帮助文档
与CMO软件配置管理相关的文档一般包括:
* 工作报告(编码期间协同工作文档)
* 问题报告文档 (编码期间协同工作文档)
* 问题处理报告 (编码期间协同工作文档)
* CMO每日报告(为程序经理提供每日项目变化报告)
不同配置管理软件的功能大同小异,总体来说,配置管理软件的安全性较差,为确保软件开发过程中代码与文档的安全,制定一个合理的系统备份策略是必要的。

7. 开发工具与技术积累
7.1  开发工具的选择
开发工具是开发人员进行软件开发所必备工具,选择合适的开发工具有利于产品的开发与软件公司的健康发展。选择开发工具时应考虑以下几方面的因素:
1) 开发工具的功能与技术先进性
开发工具的功能必须能够满足应用开发的需要,同时具备行业领先优势。这是选择开发工具必须首先应考率的。
2) 供应商的技术经济实力
开发工具供应商的技术经济实力是第二个应考虑的因素。雄厚的技术经济实力是开发工具在激烈的市场竞争中生存发展的基础,频繁更换开发工具意味着建立其上的技术积累将付之东流,不利于软件公司的发展。
3) 对行业标准的支持与左右程度
对行业标准的支持也是选择开发工具应加以考虑的因素,软件开发工具中各种标准发展迅速,开发工具对各种标准应有良好的支持。制定与左右标准的制定是公司技术实力的象征,每一新的标准的产生必然提高软件开发及程序运行的效率。有利于应用开发的进行。
4) 开发工具的市场占有率
市场占有率越高,意味着市场上可供选择的控件越多,选择成熟的控件是降低软件开发成本、提高软件可靠性的重要手段。应尽可能选择市场占有率高的开发工具。
5) 适应快速应用软件开发
适应快速应用软件开发是应用开发的需要,也是选择开发工具应考虑的因素。
7.2 技术积累
技术积累历来是公司发展的基础,对于软件公司尤其如此。这种技术积累一般包含三方面的含义。其一是人员技术素质及能力的提高;其二是公司在公共模块方面的积累;其三是对新技术的跟踪发展方面;
对于软件公司而言,人员的稳定是技术积累的主体,人员作为技术的载体在技术积累方面占有重要的位置,频繁的人员变动不利于软件公司的发展。
公共模块方面的积累主要取决于公司的发展方向,不同的公司有不同的积累方式与方向。公共模块的积累有利于后来项目开发的速度于质量,也是在激烈的市场竞争中求得生存发展得重要保证。
对于新技术得跟踪可以确保公司在技术上处于领先地位,适应日新月异技术得发展,确保公司不被淘汰。
7.3  对用户负责
用户是软件生命周期中重要的一环。软件开发的最终目的是为了满足用户的需求,同时用户的积极参与也是产品提高的基础,也是软件公司发展的前提。因此在软件开发过程中,应把用户的利益放在第一位。确保用户的利益不被侵犯。
结束语
一个良好的可操作的应用软件开发管理模式是确保应用软件开发达到预期目的的最基本保证,有利于降低软件开发与维护成本,降低软件开发风险。建立合理的软件开发管理模式、制定与完善相关软件开发标准是国内大部分软件公司与系统集成公司迫切需要解决的问题。希望本文在这方面能够给予一些启示。
  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1 主题内容与适用范围 本规范规定了在制订软件质量保证计划时应该遵循的统一的基本要求。 本规范适用于软件特别是重要软件质量保证计划的制订工作。对于非重要软件或已经开发好的软件,可以采用本规范规定的要求的子集。 2 引用标准 GB/T 11457 软件工程术语 GB 8566 计算机软件开发规范 GB 8567 计算机软件产品开发文件编制指南 GB/T 12505 计算机软件配置管理计划规范 3 术语 下面给出本规范中用到的一些术语的定义,其他术语的定义按GB/T 11457。 3.1 项目委托单位 project entrust organization 项目委托单位是指为产品开发提供资金并通常也是(但有时也未必)确定产品需求的单位或个人。 3.2 项目承办单位 project undertaking organization 项目承办单位是指为项目委托单位开发、购置或选用软件产品的单位或个人。 3.3 软件开发单位 software development organization 软件开发单位是指直接或间接受项目委托单位委托而直接负责开发软件的单位或个人。 3.4 用户 user 用户是指实际使用软件来完成某项计算、控制或数据处理等任务的单位或个人。 3.5 软件 software 软件是指计算机程序及其有关的数据和文档,也包括固化了的程序。 3.6 重要软件 critical software 重要软件是指它的故障会影响到人身安全会导致重大经济损失或社会损失的软件。 3.7 软件生存周期 software life cycle 软件生存周期是指从系统设计对计算机软件系统提出应用需求开始,经过开发,产生一个满足需求的计算机软件系统,然后投入运行,直至该软件系统退役为止。其间经历系统分析与软件定义、软件开发以及系统的运行与维护第三个阶段。其中软件开发阶段一般又划分成需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试以及安装与验收等六个阶段。 3.8 验证 verification 验证是指确定软件开发周期中的一个给定阶段的产品是否达到上一阶段确立的需求的过程。 3.9 确认 validation 确认是指在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。 3.10 测试 testing 测试是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。 3.11 软件质量 software quality 软件质量是指软件产品中能满足给定需求的各种特性的总和。这些特性称做质量特性,它包括功能度、可靠性、易使用性、时间经济性、资源经济性、可维护性和可移植性等。 3.12 质量保证 quality assurance 质量保证是指为使软件产品符合规定需求所进行的一系列有计划的必要工作。 4 软件质量保证计划编制大纲 项目承办单位(或软件开发单位)中负责软件质量保证的机构或个人,必须制订一个包括以下各章内容的软件质量保证计划(以下简称计划)。各章应以所给出的顺序排列;如果某章中没有相应的内容,则在该章标题之后必须注明“本章无内容”的字样,并附上相应的理由;如果需要,可以在后面增加章条;如果某些材料已经出现在其他文档中,则在该计划中应引用那些文档。计划的封面必须标明计划名和该计划所属的项目名,并必须由项目委托单位和项目承办单位(或软件开发单位)的代表共同签字、批准。计划的目次是: 引言 管理 文档 标准、条例和约定 评审和检查 软件配置管理 工具、技术和方法 媒体控制 对供货单位的控制 记录的收集、维护和保存 下面给出软件质量保证计划的各个章条必须具有的内容。 4.1 引言 4.1.1 目的 本条必须指出特定的软件质量保证计划的具体目的。还必须指出该计划所针对的软件项目(及其所属的各个子项目)的名称和用途。 4.1.2 定义和缩写词 本条应该列出计划正文中需要解释的而在GB/T 11457中尚未包含的术语的定义,必要时,还要给出这些定义的英文单词及其缩写词。 4.1.3 参考资料 本条必须列出计划正文中所引用资料的名称、代号、编号、出版机构和出版年月。 4.2 管理 必须描述负责软件质量保证的机构,任务及其有关的职责。 4.2.1 机构 本条必须描述与软件质量保证有关的机构的组成。还必须清楚地描述来自项目委托单位、项目承办单位、软件开发单位或用户中负责软件质量保证的各个成员在机构中的西相互关系。 4.2.2 任务 本条必须描述计划所涉及的软件生存周期中有关阶段的任务,特别要把重点放在描述这些阶段所应进行的软件质量保证活动上。 4.2.3 职责 本条必
软件开发的全面质量管理是指在软件开发过程中,从项目启动到软件发布和维护的全过程中,对软件的各个方面进行质量管理,包括需求管理、设计管理、编码管理测试管理配置管理、项目管理质量保障等。全面质量管理的目标是确保软件质量,提高软件的可靠性、可维护性和可扩展性,降低软件开发和维护的成本,提高客户满意度。 全面质量管理包括以下几个方面: 1.需求管理:要求对用户需求进行全面的收集、分析和管理,确保需求的准确性、完整性和一致性,并及时响应用户的变更请求。 2.设计管理:要求在软件设计过程中,对软件架构、模块设计、接口设计等进行全面的规划和管理,确保设计的可靠性、可维护性和可扩展性。 3.编码管理:要求在编码过程中,对代码质量进行全面的管理和监控,确保代码的规范性、可读性和可维护性,并采用合适的编码工具和技术进行支持。 4.测试管理:要求对软件的各个测试阶段进行全面的管理和监控,包括功能测试、性能测试、安全测试、兼容性测试等,确保软件质量和稳定性。 5.配置管理:要求对软件的版本控制文档管理、问题跟踪等进行全面的管理和监控,确保软件的可追溯性和稳定性。 6.项目管理:要求对软件开发过程进行全面的管理和监控,包括进度管理、资源管理、风险管理等,确保项目的顺利完成和客户满意度。 7.质量保障:要求对软件质量进行全面的保障,包括质量评估、质量审查、质量度量等,确保软件的高质量和可靠性。 总之,全面质量管理软件开发过程中不可或缺的一部分,它可以提高软件质量和稳定性,降低软件开发和维护的成本,满足用户的需求和期望。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值