软件过程的改进计划(上)

 1:软件过程思想
1.1:什么是过程

过程的定义很多书上都给出了不同的答案。可能是这些给出的定义所关注的方向不同,因此会忽视一些其他方面,造成很难给过程一个明确的定义。在这里引用一个比较全面的定义来阐述过程。“过程事实上有三方面的特性:首先,过程应被定义,因此过程的第一个方面就是过程的定义,通常是将过程所包含的活动及程序文档化;第二,应将关于过程的知识传授给需要执行过程的每一个人,所以第二个方面就是过程的学习。也就是说应让过程的知识深入到每个过程执行者的头脑中去,并以此驱动他们的行为与活动;就像产品的形成是经过一系列的工序处理后的结果一样,通过执行过程中的活动才能获得最终的过程结果,这就是过程的第三方面。”***[引用自《软件过程改进 Sami Zahran著》第一章1.2.2]

 

其实简单的理解,过程的定义可以描述为:什么人正在做什么事情,什么时候去完成这件事,并且如何去完成这件事的一个特定目标。

1.2:软件过程

1.2.1:软件过程定义

软件过程广义来将就是指:不仅仅包括软件开发和管理的过程,并且还包括软件合同的管理,软件维护,软件支持及整个软件组织的管理等的全部活动。而狭义的软件过程则指:软件开发过程,包括软件开发过程中的全部活动:需求分析,设计,编码,测试。这些过程可以是增量的交替的开发,或者可以采用迭代的开发。

我们这里所要讨论的软件过程可以定义为:对软件开发过程的管理,软件生命周期的管理与工程化过程支持的规范说明。而此软件过程的使用者为公司的软件工程师和项目经理,最终的结果就是软件程序,系统及文档。

1.2.2:为何要使用高效的软件过程

什么是高效的、好的软件过程?要回答这个问题,我们就必须说一说低效的、差的软件过程有些什么症状。

对于一些企业可能存在着如下的问题:

1. 软件开发过程中执行的任务比较模糊。开发项目组中成员的职责说明不明确。文档不完善,无指导意义。

2. 软件开发过程的执行缺乏监控,无法保证与企业管理目标的一致。开发项目中的每个成员喜欢用自己的过程去完成开发,极大的削弱了团队的能力。

3. 整个企业崇尚技术为主,认为只要技术高了就能提高开发效益。极大忽略了过程的管理。

4. 缺乏软件开发过程的规范化文档,进来的新人无法得到规范的指导和培训。

5. 企业原本有自己的一套规范的软件过程,但时间久了缺乏改进,也不花精力去研究新的过程,造成旧过程逐渐失效。同时这样的过程也失去了对新技术和新趋势的支持。

6. 上级领导只关心结果,不重视过程的使用和管理。整个企业的运作环境也无法支持过程的使用或改进,造成过程成为企业的负担,无法和企业目标相一致。

以上这些问题都是低效的软件过程的一些特征,低效的软件过程可能拖慢企业的开发效率,同时也无法很好的支持企业的运作,无法给企业带来更多的效益。

在理解了一些低效过程的特点后,就更加肯定了软件企业必须有个高效的软件过程支持才能为企业本身带来更多的效益,也能更快的提高项目的开发效率,保证项目的质量。因为对于软件开发项目来说,在整个开发生命周期中能保证有一个高效的过程机制去支持开发,那对于整个项目的管理是很重要的。高效的过程能够让企业的开发项目组的职责明确化,便于管理。过程目标与企业目标一致,这样可以对项目成员实行激励。高效的过程结果是规范的制度,规范的文档。这些都可以很方便的运用到对新进员工的培训中去,使新成员能更快的融入到项目组中,提高团队合作能力。

1.3:小结

一个好的软件过程只有被定义、培训、遵守、职责明确、有足够的支持去执行才能成为真正有效的过程。

软件过程不仅仅是我们所看到的一堆文档,这些文档所包含的内容才是真正的过程产品。通过这些规范的文档可以有效的,快速的指导整个软件开发,给项目管理一个指导性的大纲。在有了正确的管理,高效的开发过程后才能为企业和组织带来更多,更快的效益。

2.软件过程实践

下面就一个开发零售百货业ERP项目的公司作为例子来研究一下软件过程的实践,包括分析企业开发过程的现状,制定改进计划,实施和评估。

2.1.分析企业现有软件过程的现状

2.1.1.业务分析及企业背景

  • 这个开发零售百货业ERP系统的公司是一个由35人组成的小型企业,是隶属于某大型卖场的开发团队。
  • 拥有一批对零售业务具备多年经验的需求,开发和测试人员。
  • 公司内部组织分成四个独立项目组:需求组、开发组、测试组、系统组。
  • 各个项目组职责明确。
  • 使用J2EE架构,JAVA、JSP语言进行WEB页面开发。
  • 使用SYBASE数据库/数据仓库产品进行数据存储及处理,可支持大数据量。
  • 在开发过程中使用CVS、Bugzilla Bug追踪系统及自主研发的更新工具支持项目开发。
  • 行业领域比较专业,有很多公式、业务规则、合同规则来指导开发工作。
  • 具有稳定的客户群,分布全国都有客户分店,但是零售业客户的需求不断变化、新需求层出不穷。
  • 整个软件产品对客户的管理工作起到决定性作用。客户的订单、进退货、财务、付款、合同等管理流程全部需要由软件来完成,因此直接关系到客户的经济效益。
  • 软件质量和开发效率极其重要,直接影响公司的命运。
  • 已经有成功发布并运行正常的软件产品。

2.1.2.项目风险分析

  • 客户需求不断变化,给开发过程的进度控制带来很大困难
  • 业务范围广、流程复杂、专业程度高(例如财务方面的业务分析及建模),需要具备一定的行业知识。
  • 客户的数据安全性、完整性、可靠性、正确性需要得到百分百保证。
  • 系统分为总部和全国各分店系统,需要通过网络交换数据,网络安全需要考虑。
  • 服务器访问量大,需要硬件支持。

2.1.3.内部环境

  • 内部组织结构
    • 公司内部分成四个项目组:需求组、开发组、测试组、系统组。
      根据开发的模块大小从需求组、开发组、测试组抽调部分组员组成模块开发小组。
      系统组负责环境架设、程序更新等工作。
    • 公司拥有一批业务经验、行业知识丰富的人员。
    • 公司拥有多名开发经验超过5年的开发人员。
  • 开发过程
    • 使用比较传统的开发过程:需求分析—》设计开发—》系统测试—》发布新版本。
    • 基本类似于瀑布式开发过程,其中会使用些增量式开发。
    • 测试方面依据业务流程做黑盒测试,主要依靠业务经验来测试产品,无自动测试工具。
    • 需求阶段有详细的需求文档作为开发依据,
    • 开发过程中没有规范的设计文档,很多情况下仅仅是根据需求文档直接做开发。
    • 有些设计文档是开发项目结束后才补写的。
    • 没有固定去做测试计划,有时仅仅是开发完成后就开始分工测试。
    • 有做测试案例但没有固定的规范约束,测试案例交由开发和需求人员确认。
    • 有BUG系统追踪需求变更及BUG处理情况,但无系统的测试报告给开发人员参考,大部分情况下是口头和开发/需求人员沟通BUG的问题点。
  • 支持工具
    • WINCVS
    • Bugzilla Bug追踪系统
    • 自主研发的更新工具

2.1.4.产品特点

项目比较庞大,一般拆分成模块进行开发。一个模块的开发人员为3~5人左右。

项目开发完成的软件是作为商业应用的一个ERP系统,包括零售百货业的所有流程管理、物流管理、财务管理等。

软件的使用周期一般可以在10~20年,维护周期长,需要有高可靠性的质量保证。涉及到有很多商业及财务数据需要保存,安全性很重要。访问用户比较多,响应速度要快。

技术复杂程度参差不齐,有些模块比较简单技术要求不高,有些模块比较复杂,需要不断更新新技术。总体来说由于对于行业的业务分析要求严谨,又是使用比较新的开发技术,所以技术复杂程度和管理程度相对都要高一点。下图给出了一个技术与管理程度的比较:

Technical vs. Management Complexity

2.1.5.分析总结

通过以上四节对该公司的一个现状分析可以得出以下一些结论。

优势:

  • 该公司是大型企业的专有开发公司,业务客户稳定,项目市场风险小。不需要考虑市场推广及销售策略。
  • 公司的组织架构较灵活,可以整个公司作为一个开发团队开发大型项目。也可以从各组中抽调部分组员进行临时组队开发小型模块。这样对于用户变化多端的需求可以并行进行处理提高效率。
  • 公司的内部组织分工、职责比较明确。适合进行过程改进。
  • 公司使用的技术及存储产品比较主流,可以支持大、中、小各种类型项目。
  • 公司已经有使用过程支持工具,并且有版本管理工具,需求变更追踪管理。
  • 公司具备一批精通零售行业业务知识的需求、开发、测试人员,同时也具备多名开发经验超过5年的开发人员。
  • 需求文档比较完善。
  • 有成功发布并使用正常的软件产品。

问题点:

  • 客户新需求量大、需求变化快。
  • 开发过程比较落后,没有使用较先进的方法论进行改进或支持。
  • 没有专门的过程实施、监控小组。没有过程专家。
  • 无详细的设计文档,或是仅仅在开发完成后补写设计文档。
  • 测试方面仅仅依靠测试人员的业务经验进行测试,无相关方法论的支持,没有使用专业的自动化测试工具。
  • 没有明确的测试计划来管理整个测试过程。

测试报告不全面,没有固定格式,不能指导开发人员修改BUG。

Stakeholders方面存在一些需要关注的地方:业务范围广、流程复杂、专业程度高(例如财务方面的业务分析及建模),需要具备一定的行业知识。客户的数据安全性、完整性、可靠性、正确性需要得到百分百保证。系统分为总部和全国各分店系统,需要通过网络交换数据,网络安全需要考虑。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值