• 软件开发模型之一 万祖归宗是瀑布


    案例

    案例一

    某公司承接了一个电子政务平台的项目,该项目主要分“政务办公”与“政务公开” 两大部分。甲方很配合,协助整理了国家电子政务管理规范与相当文档。沟通拟定的开发周期也相对宽松。

    甲方聘请了监理;三方各*代表成立项目控制委员会(CCB)。公司也在项目*队中*了长驻QA小组,协助项目管理。

    但是,电子政务并不是公司的主营业务,整个研发*队是公司临时招聘组建,约六人左右,大多是应届毕业,除了项目经理之外,最有经验的也不过两三年开发经历。

    针对这种情况,作为项目经理,应该采用哪种开发模式比较合理? 

     案例二

    当项目刚开始不久,甲方接到通知,要在当年国庆前后参加全国电子政务网站评比,当地主管领导希望能在九月份先进行本地区评比。准备充足后,再备战全国评比。而此时,刚过五一,总计用于研发时间也就四个月左右。

    项目主管在了解情况后,向CCB提出项目变更申请,考虑先做前端功能,后端仅做现阶段需要的模块。同时,向公司申请从其它项目组,抽调技术骨干到该项目组协助。

    经各方协商,以上方案得到支持,项目范围、开发计划的变更得到认可;公司抽调三名有多年协作经验的老员工,到该*队参与开发。

    在这种情况下,作为项目经理,应该采用哪种开发模式?

     案例三

    最终,该电子政务平台项目完满成功。*队成员觉得可以考虑将该项目转化为产品,作为一项稳定业务看待,向公司建议后,得到公司高层支持,公司内部通过评审,确定以上思路。项目经理转为产品研发经理,从事产品化工作。

    在评审过程中,也顾虑到很多问题,具体如下:

    研发经理考虑到在项目开发中,由于工期限制,程序架构不够灵活,产品化后调整工作量会比较大,存在技术风险;

    公司高层认为,市场定位依然不够明晰,大幅投资不太现实,现阶段仅限尝试。

    在这种情况下,该研发经理,应该采用哪种开发模式?

     分析

    当然在实际开发中,情况各不相同,在同一个开发周期内,使用多个开发模型也是很正常的。在这里,为了方便讲解,我仅列举主要的开发模型。

     案例一

    第一种情况,首选瀑布模型

    几乎在所有软件开发模型中(除了瀑布模型),都会说,“由于传统的瀑布式开发……”,然后都是它的一堆问题。我们听了它太多的不足,却很少有人关注它的优势了。几乎在所有的软件工程章节中,介绍软件开发模型时,无一例外第一个就是“瀑布”,可见瀑布模型的重要性。我可以这么说,软件开发模型万祖归宗是“瀑布”。其它的开发模型都是为了解决瀑布模型的缺陷而产生的,没有哪个可以颠覆瀑布模型。

    我们看看上述项目情况,最大的不利之处是项目*队不成熟,技术强弱先不说,新*队沟通肯定存在障碍,而且成员稳定性有待考验,越是新人离职率越高。

    说一句名言,“新*队,用新技术,开发新产品,成功率接近零”。而对一个新*队来说,当务之急是规范化管理,瀑布模型是比较容易实施规范的。虽然它应对需求变化时不够灵活,但在上述情况上,需求范围相对明确,开发周期相对宽松,虽然细节还需要沟通,但可以用时间弥补变更影响。

    另一方面,甲方聘请监理,监理会遵循成熟的项目过程管理的方法,CMMI将是他的首先理论依据。虽然程序员会认为文档是形式化的东西,但是监理一定会要。

    文档驱动是瀑布模型的最大特点,是它的优势,也是它的劣势。

     案例二 

    第二种情况 可以采用RUP模型

    当研发周期被缩短后,并不代表监理将不再监管项目。他依然会按照项目过程管理的方法来监管,只是有可能要求的不那么严格了。

    新增加的三名老员工,不仅提升了技术力量,也有效弥补了沟通上的不足。在开发人力上,九名成员已经相当充沛了。虽然需求细节不明确,但需求范围是比较明确的。所以,*队成员面临的最大问题是如何应对需求不明晰带来的影响。

    *队成员决定,尽可能把各项工作提前。例如,哪些需求明确了,就开始设计哪些;哪些设计了,就开始开发哪些;哪些开发了,哪些开始测试……,整体仍然按瀑布式的方式走,但各个环节相互交叠,通过迭代 逐渐精化各个环节。总之,搞清楚哪些就先做哪些。这个理念是不是很像敏捷开发?不,它不是,这种开发模型是RUP(统一过程)。

    敏捷开发与RUP还是有区别的,以后再说。

     案例三

    第三种情况 建议采用螺旋模型

    当项目转为产品时,会面临很多问题。首先是“技术债务”,快速开发会造成大量垃圾代码,虽然公司提倡重构,但项目结束后,骨干力量被抽走,个别成员离职,等等原因,很难会有机会、有人再对项目进行重构。只能在以后的工作日,逐渐改善。这其中就隐含了技术风险。

    再加上产品化的市场定位问题,营销的不确定性,经营风险也会被公司权衡。公司会考虑,先做一段试试,如果做得好,就继续做,如果不行就另做打算。

    在这种情况下,风险的控制是当前开发中的最大问题,而螺旋模型就是针对此类问题而生。

    每个螺旋过程,首先是风险分析、需求确定、计划、实施、评测;达到一个阶段后,再进行风险分析,如果可行,就进入下一个螺旋。

    要注意的是,每一个螺旋,就是一个小瀑布。 

    后记:精义入神,以致用

    上述案例只是为了方便大家理解开发模型的特点,还有很多细节未能涉及。关键是,理解了它,才能更加有效的利用它。不同的开发模型,针对不同的问题有特效,我在前文中用粗体标识出了。在我看过的大多数软件工程书中,这三种开发模型都是在列的,很具典型性。

    除了上述三种开发模型,还有喷泉模型、V型、微软开发模型等等,甚至还有原型开发模型,但我个人认为欠妥 ,原型开发不能算模型,它就像敏捷开发一样,只能算开发方法。

    “精义入神,以致用(引自《周易》)”

  • 相关阅读:
    python 内存泄漏——使用pymssql模块的讨论 free(): corrupted unsorted chunks
    Python的gc模块
    使用多线程——线程池
    sqlserver 数据库连接池
    drf response——简单封装
    邮箱找回密码实现
    阿里云 oss 服务 —— 上传图片,获取url
    dajngo-apscheduler 实现定时任务
    kubernetes基础概念
    Path must be a string.
  • 原文地址:https://www.cnblogs.com/2hill/p/2623677.html
Copyright © 2020-2023  润新知