zoukankan      html  css  js  c++  java
  • 快速软件开发 学习笔记 之二

    第3章 软件开发的基础性实践

    人们经常劝导你要采用标准的软件工程实践,因为它们是“正确”的或者它们会提高产品的质量。但是,采用软件开发的基础性实践的原因不在于它们“正确”,而在于它们可以切实减少费用和缩短产品面市时间。软件开发的基础性实践分为管理实践、技术实践和质量保证实践。

    3.1 管理的基础性实践

    3.1.1 Planning(项目规划)

    软件业界的最佳完成项目都具有这个鲜明特征:强有力的前期规划。软件项目的规划包括以下的内容:

     

    3-1 规划软件项目

    软件项目的规划活动

    进一步参考

    Estimation(项目估算)和scheduling(制定进度计划)

    7章和第8

    确定项目团队人数、所需技术技能、人员到位时间和具体人选

    11

    确定团队结构

    12

    确定项目采用的生命期模型

    6

    管理风险

    4

    3.1.2 Tracking(项目跟踪)

    项目跟踪是一个基本的软件管理行为。你如果不跟踪一个项目,你就绝不会知道你做的项目规划是否被贯彻执行了。项目跟踪包括对项目的进度、成本和质量目标的检查,以提供项目状况的可视性,避免项目失控。

    典型的管理层面跟踪手段包括:

    l  task list

    l  status meeting

    l  status report

    l  milestone review

    l  budget report

    l  management by walking around

    典型的技术层面跟踪手段包括:

    l  technical audit

    l  technical review

    l  milestone quality gate

    l  issue tracking system

     

    最佳实践:Issue Tracking System

    给整个项目乃至整个公司选择一个issue tracking system。这个issue tracking system可以是商业软件系统(如ClearQuest),也可以是免费软件。只有在issue tracking system就绪之后,才开始启动你的项目。

    3.1.2.1 Miniature Milestones(小型里程碑)

    软件项目存在major milestones,它们是为项目设定总方向的长间隔里程碑。这种里程碑通常以“月”作为间隔。Major milestone对于设定方向很有帮助,但它们的间隔过长,以至于不能提供很好的项目控制。而miniature milestone则是一种进行项目跟踪和控制的精细方法,它能很好地提供项目状况的可视性。把major milestoneminor milestone组合会有很好的效果,major milestone提供项目的策略目标,而miniature milestone则提供实现每个目标的战术方法。

    最佳实践:Miniature Milestone(小型里程碑)

    1.       及早设立小型里程碑。先紧后松优于先松后紧。

    2.       让开发人员建立他们自己的mini milestone。软件经理让员工定义他们自己的小型里程碑,也就是允许他们控制其工作细节。软件经理所要做的是要求员工告知其工作细节,这有助于员工全心投入工作,也避免了经理们的过度管理(macro-management)。

    3.       确保mini milestone12天内可到达。这也就要求单个mini milestone内的任务应该是明确的和细分的,而不是模糊的或笼统的。

    4.       确保mini milestone的二义性。小型里程碑只有“done”和“not done”两种状态,而不存在“90% done”这类的说法。软件经理或Tech Lead应该细致地跟踪项目进展状况,要每天都同开发人员一道对照设定的mini milestone来评估项目进展情况。一定要确保当一个mini milestone被标记为“done”时,它是真正100%被完成了。

    5.       mini milestone用于短期规划,而非长期规划。

    6.       如果发现经常不能按期到达mini milestone,则可以停下来,分析无法到达的原因(例如:开发人员需要培训、单个mini milestone内的任务过多、开发人员常受到杂务的干扰等)。找准原因之后,应该对原有的mini milestone规划进行调整,或者重新制定规划。

     

    3.1.3 Measurement(度量)

    使软件企业长期进步的一个关键是收集measurement data以分析软件质量和生产率。为了使开发更为高效,软件从业人员需要具有软件度量方面的基本知识,也需要理解与收集度量数据有关的问题,还需要理解某些度量数据以便用于分析项目的状况、质量和生产率。

    最佳实践:度量

    7.       以表3-1为基础,建立自己的度量数据表格。注意:收集过多的数据会让人淹没在不知其义的海量数据中。对于刚开始采用度量实践的软件团队和组织来说,可尝试最多收集12种不同的度量数据。即使是有丰富度量实践经验的组织,也最多收集24种度量数据。

    8.       在项目进行过程中,每到一个major milestone,更新度量数据表格中的相应数据。

    9.       在项目结束之后,再次汇总数据。

    10.   由原始数据获得一些组合数据,例如:

    l  已修复的缺陷数 vs. 被发现的缺陷总数(有助于评价产品质量)

    l  尚未修复的缺陷数 vs. 被发现的缺陷总数(有助于预测项目发布日期)

    l  通过inspection发现的缺陷数目 vs. 通过execution testing发现的缺陷数目(有助于规划质量保证任务)

    l  估算项目剩余天数 vs. 实际项目剩余天数(有助于跟踪和改进估算准确度)

    l  按编程语言统计每人每月的平均代码行数(有助于估算和规划编码任务)

    l  按编程语言统计每人每月的平均功能点数目(有助于估算和规划编码任务)

    l  按缺陷严重程度、按子系统或按缺陷潜入时间来统计修复一个缺陷所用的平均时间(有助于规划纠正缺陷的任务)

    l  生成一页文档的平均小时数(有助于规划文档任务)

    11.   花较多的时间分析和整理得到的度量数据。可以采用下面任何一种方法:

    12.   把收集的试题数据和分析结果反馈给开发人员和软件经理,并讨论试题数据表格是否需要增加或删减表项,以供下一个项目使用。

     

    3-2 常用度量数据

    成本和资源

    l  activity、按phase或按人员类型来统计的工作量

    l  计算机资源

    l  日历时间

    变更与缺陷

    l  按不同分类法(严重程度、子系统、潜入时间、出错原因,解决手段)统计的缺陷数目

    l  缺陷检出方法(reviewinspectiontest,等等)

    l  检出并修复每个缺陷所用的工作量

    过程

    l  process definitiondesign method、编程语言、review method,等等)

    l  估算完成时间

    l  milestone progress

    l  随时间的代码增加量

    l  随时间的代码修改量

    l  随时间的需求变更量

    产品

    l  开发日期

    l  总工作量

    l  项目种类(内部业务软件、商用盒装软件、或系统软件)

    l  项目中的函数数目或object数目

    l  以代码行数或功能点数衡量的项目规模

    l  文档的规模

    l  编程语言

     

    度量是有用的,但它也不能包治百病。应该记住度量存在的局限性:

    l  收集的数据是有误差的。试题过程中会有很多误差,因此收集的数据并不准确。

    l  警惕过分依赖度量数据的倾向。度量数据能够为我们提供软件项目的历史数据,对度量数据的分析也能够为我们提供一定的项目洞察力,但是,它只是起参考作用而不能被过分依赖。

    3.2 技术的基础性实践

    3.2.1 Requirements Management(需求管理)

    需求管理是一个完整的过程,它包括:收集需求;把需求记录为文档、电邮、UI storyboardexecutable prototype或其它形式;依据需求跟踪软件设计与编码;在项目进行过程中管理需求变更。

    需求管理的成功取决于理解各种不同的实践,以便为特定的项目选择最合适的实践。下面是需求管理的基础性实践:

    l  需求分析方法论(结构化分析,数据结构分析,面向对象分析)

    l  系统建模实践(类图,数据流图,实体-关系图,数据-字典表示法,状态转移图)

    l  沟通实践(Joint Application Developmentuser-interface prototyping,常规会谈实践)

    l  需求管理与不同的生命期模式的关系

    需求管理在两个方面对加快开发速度发挥着巨大的影响:

    l  requirements gathering往往比其它软件开发任务完成得要从容些。如果能加快需求收集的速度但又不伤及质量,那么就能缩短总的开发时间。

    l  从项目一开始就把需求弄清楚的成本,比起直到构建阶段或维护阶段再把需求弄清楚的成本,要少50200倍。

    3.2.2 软件设计

    软件架构与设计的基础性实践包括:

    l  总体设计风格(对象设计,结构化设计,数据结构设计)

    l  基础性的设计概念(information hidingmodularityabstractionencapsulationcohesioncouplinghierarchyinheritancepolymorphismbasic algorithmbasic data structure

    l  对典型性困难问题的标准解决方法(exception handlinginternationalizationlocalizationportabilitymemory managementdatabase designperformancereuse

    l  针对应用领域的独有设计思考(财务应用,科学应用,嵌入式系统,实时系统,安全攸关的系统)

    l  系统架构方案(subsystem organizationlayeringsubsystem communication styles,典型的系统架构)

    l  设计工具的应用

    3.2.3 Construction(软件构建)

    软件构建的基础性实践包括:

    l  编码实践(变量和函数命名,代码布局,注释)

    l  与数据相关的概念(scopepersistencebinding time

    l  特定数据类型使用方针(一般的数字,整数,浮点数,字符,字符串,布尔值,枚举,具名常量,数组,指针)

    l  与控制相关的概念(组织直线型代码,使用判断式,控制循环,使用布尔表达式,控制复杂度,使用gotoreturn和递归函数等较少用的控制结构)

    l  断言和其它以代码为中心的检错实践

    l  把代码组织成函数、模块、类和文件的规则

    l  单元测试和调试实践

    l  集成策略(增量式集成,大爆炸式集成)

    l  代码优化与实践

    l  所使用的特定编程语言的细节

    l  软件构建工具的使用(编程环境,对团队工作的支持,代码库,代码生成器)

     

    最佳实践:Daily Build(每日生成)和Smoke Test(冒烟测试)

    1.       每日生成和冒烟测试背后的思想很简单:每天都要对整个产品buildtest一次。这意味着每天都要将每个文件编译、链接,并组成可执行程序,产品再通过一个相对简单的自动化测试,以检验其是否具有最基本的可用性。

    2.       daily buildsmoke test就绪之前,不要开始任何construction任务。

    3.       Daily buildSmoke test依赖于一些基础设施和前期准备,包括:

    (1)     一台联网的专用build machine(可以是PC,也可以是服务器),用于生成产品和完成冒烟测试。

    (2)     build machine安装必要的支持软件,包括版本控制系统客户端,编译环境,自动化编译工具,邮件系统,自动化测试工具等。

    (3)     build machine及相关软件工具进行测试,确认build machine可以用于自动化的每日生成和冒烟测试与报告广播。

    4.       从项目进入construction阶段的第一天起,就每天进行daily buildsmoke test。过程如下:

    (1)     build machine在每天晚上的10点,从版本控制系统中check out最新的项目源代码树,进行编译、链接,并把生成的程序和log文件放入与当天日期对应的路径下。一个好的daily build应该是成功地编译、链接所有的文件、库和组件,并且没有严重级别的编译告警和链接告警。

    (2)     build machine上对刚生成的程序运行自动化的冒烟测试,并把测试结果log文件放入与当天日期对应的路径下。程序应该通过冒烟测试中的所有测试才算成功。

    (3)     build machine上的邮件系统向指定的干系人发送电邮,告知当天daily buildsmoke test的结果。

    (4)     干系人在第二天早上检查昨天的daily buildsmoke test的结果。如果发现错误,应停下手头工作,立即进行改正。冒烟测试是execution testing中的第一道关口,所以必须被赋予最高优先级。

    (5)     上述过程,每天进行,周而复始,直到项目交付。即使项目的进度压力大,也必须坚持本实践。

    5.       冒烟测试随着产品代码的增加而增加。坚持为产品代码编写测试代码,看似花时间,但实际却是为项目真正地节约时间。

    6.       Daily build失败或通不过smoke test应该是罕见的例外,而不应该是常态。如果频繁出现这种情况,那就应该好好思考一下为什么会这样了。

     

    3.3 质量保证的基础性实践

    大多数公司都认为:最好从一开始就远离错误。远离错误的关键就是从第一天起就注意运用质量保证的基础性实践。高的软件质量与短的开发时间是相辅相成的,下图给出了两者的关系。

    clip_image002[6]

    由图可见:95%附近的一些点很重要,因为能做到大约95%的被发现缺陷被修复的项目通常能实现最短的进度,最少的工作量和最高的用户满意度。

    下面是一些质量保证的基础性实践:

    l  Error-prone module。对易错模块(error-prone module)的质量保证是软件特别重要的一个方面。易错模块通常指错误率达到“10个缺陷/1000代码行”的模块。鉴别出易错模块,对其进行review以决定是否需要重新设计或重新实现。对于易错模块,推倒重来有时比东修西补更省时。

    l  Testing。最常见的质量保证实践无疑是execution testing。两种基本的测试方法是单元测试和系统测试

    l  Technical reviewTechnical review用于检查requirementsdesigncodetest cases或其它project artifact中存在的缺陷。Technical review是对execution testing的重要补充,是每个软件项目的关键组成部分。常见的technical review方式包括informal walkthroughcode readinginspection

  • 相关阅读:
    Laravel路由除了根目录全报404错误
    jQuery源码分析之整体框架
    JS进阶系列之this
    JS进阶系列之原型、原型链
    原生JavaScript实现的贪吃蛇
    html文档流和事件流
    (转)mysql执行计划分析
    (转)重定向和转发区别
    el表达式取值优先级
    (转)性能测试基本指标
  • 原文地址:https://www.cnblogs.com/lijia821130/p/2426283.html
Copyright © 2011-2022 走看看