离开水的鱼未必不能活! 方法?-------->进化 进化进行中~~~~~~~~~~~~~

发布新日志

  • (转摘)产品开发模型IPD

    2008-06-09 14:46:05

    集成产品开发(Integrated Product Development, 简称IPD)是一套产品开发的模式、理念与方法。
    最先将IPD付诸实践的是IBM公司,后期的美国波音公司和深圳华为公司。

    IPD核心思想和框架
        .新产品开发是一项投资决策
       IPD强调要对产品开发进行有效的投资组合分析,并在开发过程设置检查点,通过阶段性评审来决定项目是继续、暂停、种植还是改变方向。
      · 基于市场的开发
       IPD强调产品创新一定是基于市场需求和竞争分析的创新。为此,IPD把正确定义产品概念、市场需求作为流程的第一步,开始就把事情做正确。
      · 跨企业、部门、跨系统的协同团队
       采用跨部门的产品开发团队(PDT:Product Development Team),通过有效的沟通、协调以及决策,达到尽快将产品推向市场的目的。
      · 异步开发模式,也称并行工程。
       就是通过严密的计划、准确的接口设计,把原来的许多后续活动提前进行,这样可以缩短产品上市时间。
      · 重用性
       采用公用构建模块(CBB:Common Building Block)提高产品开发的效率。
      · 结构化的流程
       产品开发项目的相对不确定性,要求开发流程在非结构化与过于结构化之间找到平衡。

    结构化流程

      IPD产品开发流程被明确地划分为概念、计划、开发、验证、发布、生命周期六个阶段,并且在流程中有定义清晰的决策评审点。这些评审点上的评审已不是技术评审,而是业务评审,更关注产品的市场定位及盈利情况。决策评审点有一致的衡量标准,只有完成了规定的工作才能够由一个决策点进入下一个决策点。下面是典型的产品开发流程:

      a) 在概念阶段初期,一旦IPMT认为新产品、新服务和新市场的思想有价值,他们将组建并任命PDT成员。

      b) PDT了解未来市场、收集信息、制定业务计划。业务计划主要包括市场分析、产品概述、竞争分析、生产和供应计划、市场计划、客户服务支持计划、项目时间安排和资源计划、风险评估和风险管理、财务概述等方面信息,所有这些信息都要从业务的角度来思考和确定,保证企业最终能够盈利。

      c) 业务计划完成之后,进行概念决策评审。IPMT审视这些项目并决定哪些项目可以进入计划阶段。

      d) 在计划阶段,PDT综合考虑组织、资源、时间、费用等因素,形成一个总体、详细、具有较高正确性的业务计划。

      e) 完成详细业务计划以后,PDT提交该计划给IPMT评审。如果评审通过,项目进入开发阶段。PDT负责管理从计划评审点直到将产品推向市场的整个开发过程,PDT小组成员负责落实相关部门的支持。

      f) 在产品开发全过程中,就每一活动所需要的时间及费用,不同层次人员、部门之间依次做出承诺


    产品重整

      IPD提高开发效率的手段是产品重整。产品重整主要关注于异步开发和共用基础模块(CBB)。

      1、异步开发

      异步开发模式的基本思想是将产品开发在纵向分为不同的层次,如技术层、子系统层、平台层等。不同层次工作由不同的团队并行地异步开发完成,从而减少下层对上层工作的制约,每个层次都直接面向市场。

      通常,在产品开发过程中,由于上层技术或系统通常依赖于下层的技术,因此,开发层次之间的工作具有相互依赖性,如果一个层次的工作延迟了,将会造成整个时间的延长,这是导致产品开发延误的主要原因。 通过减弱各开发层次间的依赖关系,可以实现所有层次任务的异步开发。

      为了实现异步开发,建立可重用的共用基础模块是非常重要的。

      2、共用基础模块

      共用基础模块(Common Building Blocks, CBB)指那些可以在不同产品、系统之间共用的零部件、模块、技术及其他相关的设计成果。由于部门之间共享已有成果的程度很低,随着产品种类的不断增长,零部件、支持系统、供应商也在持续增长,这将导致一系列问题。 事实上,不同产品、系统之间,存在许多可以共用的零部件、模块和技术,如果产品在开发中尽可能多地采用了这些成熟的共用基础模块和技术,无疑这一产品的质量、进度和成本会得到很好的控制和保证,产品开发中的技术风险也将大为降低。因此,通过产品重整,建立CBB数据库,实现技术、模块、子系统、零部件在不同产品之间的重用和共享,可以缩短产品开发周期、降低产品成本。 CBB策略的实施需要组织结构和衡量标准的保证。

      不管是异步开发还是共用基础模块的实现,都需要很高水平的系统划分和接口标准制订,需要企业级的构架师进行规划。

  • (转)软件开发过程模型RUP

    2008-06-09 14:33:28

    RUP的二维开发模型
      
      RUP可以用二维坐标来描述。横轴通过时间组织,是过程展开的生命周期特征,体现开发过程的动态结构,用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone);纵轴以内容来组织为自然的逻辑活动,体现开发过程的静态结构,用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。如图1:
      
     
      图1 RUP的二维开发模型

      
    开发过程中的各个阶段和里程碑
      
      RUP中的软件生命周期在时间上被分解为四个顺序的阶段,分别是:初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones);每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个阶段。
      
      1.初始阶段
      
      初始阶段有时也称先启阶段。初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体,在较高层次上定义交互的特性。本阶段具有非常重要的意义,在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲,初始阶段可能很短。
      
      初始阶段结束时是第一个重要的里程碑:生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存能力。
      
      2.细化阶段
      
      细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。为了达到该目的,必须在理解整个系统的基础上,对体系结构作出决策,包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境,包括创建开发案例,创建模板、准则并准备工具。
      
      细化阶段结束时第二个重要的里程碑:生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻,要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。
      
      3.构造阶段
      
      在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详细测试。从某种意义上说,构建阶段是一个制造过程,其重点放在管理资源及控制运作以优化成本、进度和质量。
      
      构建阶段结束时是第三个重要的里程碑:初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻,要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。
      
      4.交付阶段
      
      交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代,包括为发布做准备的产品测试,基于用户反馈的少量的调整。在生命周期的这一点上,用户反馈应主要集中在产品调整,设置、安装和可用性问题,所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。
      
      在交付阶段的终点是第四个里程碑:产品发布(Product Release)里程碑。此时,要确定目标是否实现,是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。
      
    RUP的核心工作流(Core Workflows)
      
      RUP中有9个核心工作流,分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段,但应注意迭代过程中的阶段是完全不同的,这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用,在每一次迭代中以不同的重点和强度重复。
      
      1.商业建模(Business Modeling)
      
      商业建模工作流描述了如何为新的目标组织开发一个构想,并基于这个构想在商业用例模型和商业对象模型中定义组织的过程,角色和责任。
      
      2.需求(Requirements)
      
      需求工作流的目标是描述系统应该做什么,并使开发人员和用户就这一描述达成共识。为了达到该目标,要对需要的功能和约束进行提取、组织、文档化;最重要的是理解系统所解决问题的定义和范围。
      
      3.分析和设计(Analysis & Design)
      
      分析和设计工作流将需求转化成未来系统的设计,为系统开发一个健壮的结构并调整设计使其与实现环境相匹配,优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象,由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem),而描述则体现了类的对象如何协同工作实现用例的功能。
      
      设计活动以体系结构设计为中心,体系结构由若干结构视图来表达,结构视图是整个设计的抽象和简化,该视图中省略了一些细节,使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介,而且在系统的开发中能提高被创建模型的质量。
      
      4.实现(Implementation)
      
      实现工作流的目的包括以层次化的子系统形式定义代码的组织结构;以组件的形式(源文件、二进制文件、可执行文件)实现类和对象;将开发出的组件作为单元进行测试以及集成由单个开发者(或小组)所产生的结果,使其成为可执行的系统。
      
      5.测试(Test)
      
      测试工作流要验证对象间的交互作用,验证软件中所有组件的正确集成,检验所有的需求已被正确的实现, 识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法,意味着在整个项目中进行测试,从而尽可能早地发现缺陷,从根本上降低了修改缺陷的成本。测试类似于三维模型,分别从可靠性、功能性和系统性能来进行。
      
      6.部署(Deployment)
      
      部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动,包括:软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下,还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。
      
      7.配置和变更管理(Configuration & Change Management)
      
      配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体,跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。
      
      8.项目管理(Project Management)
      
      软件项目管理平衡各种可能产生冲突的目标,管理风险,克服各种约束并成功交付使用户满意的产品。其目标包括:为项目的管理提供框架,为计划、人员配备、执行和监控项目提供实用的准则,为管理风险提供框架等。
      
      9.环境(Environment)
      
      环境工作流的目的是向软件开发组织提供软件开发环境,包括过程和工具。环境工作流集中于配置项目过程中所需要的活动,同样也支持开发项目规范的活动,提供了逐步的指导手册并介绍了如何在组织中实现过程。
      
    RUP的迭代开发模式
      
      RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环,产生一个可执行的产品版本,是最终产品的一个子集,它增量式地发展,从一个迭代过程到另一个迭代过程到成为最终的系统。
      
      传统上的项目组织是顺序通过每个工作流,每个工作流只有一次,也就是我们熟悉的瀑布生命周期。这样做的结果是到实现末期产品完成并开始测试,在分析、设计和实现阶段所遗留的隐藏问题会大量出现,项目可能要停止并开始一个漫长的错误修正周期。
      
     
      图2 RUP的迭代开发模式

      
      一种更灵活,风险更小的方法是多次通过不同的开发工作流,这样可以更好的理解需求,构造一个健壮的体系结构,并最终交付一系列逐步完成的版本。
  • BS与CS的各自应用和区别及二者的'融合体CTBS'(转载)

    2008-06-01 16:07:39

    C/SClient/Server的缩写。服务器通常采用高性能的PC、工作站或小型机,并采用大型数据库系统,如Oracle、Sybase、Informix或 SQL Server。客户端需要安装专用的客户端软件。 如普通的网络游戏。
    B/SBrower/Server的缩写,客户机上只要安装一个浏览器(Browser),如Netscape Navigator或Internet Explorer,服务器安装Oracle、Sybase、Informix或 SQL Server等数据库。在这种结构下,用户界面完全通过WWW浏览器实现,一部分事务逻辑在前端(Browser)实现,但是主要事务逻辑在服务器端(server)实现,即所谓的3-tier结构。浏览器通过Web Server 同数据库进行数据交互。

    C/S 与 B/S 区别:
    1.硬件环境不同:
    C/S 一般建立在专用的网络上, 小范围里的网络环境, 局域网之间再通过专门服务器提供连接和数据交换服务.
    B/S 建立在广域网之上的, 不必是专门的网络硬件环境,例与电话上网, 租用设备. 信息自己管理. 有比C/S更强的适应范围, 一般只要有操作系统和浏览器就行

    2.对安全要求不同
    C/S 一般面向相对固定的用户群, 对信息安全的控制能力很强. 一般高度机密的信息系统采用C/S 结构适宜. 可以通过B/S发布部分可公开信息.
    B/S 建立在广域网之上, 对安全的控制能力相对弱, 可能面向不可知的用户。

    3.对程序架构要求不同
    C/S 程序可以更加注重流程, 可以对权限多层次校验, 对系统运行速度可以较少考虑.
    B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上. 比C/S有更高的要求 B/S结构的程序架构是发展的趋势, 从MS的.Net系列的BizTalk 2000 Exchange 2000等, 全面支持网络的构件搭建的系统. SUN 和IBM推的JavaBean 构件技术等,使 B/S更加成熟.

    4.软件重用不同
    C/S 程序可以不可避免的整体性考虑, 构件的重用性不如在B/S要求下的构件的重用性好.
    B/S 对的多重结构,要求构件相对独立的功能. 能够相对较好的重用.就入买来的餐桌可以再利用,而不是做在墙上的石头桌子

    5.系统维护不同
    C/S 程序由于整体性, 必须整体考察, 处理出现的问题以及系统升级. 升级难. 可能是再做一个全新的系统,维护费用较高
    B/S 构件组成,方面构件个别的更换,实现系统的无缝升级. 系统维护开销减到最小.用户从网上自己下载安装就可以实现升级.

    6.处理问题不同
    C/S 程序可以处理用户面固定, 并且在相同区域, 安全要求高需求, 与操作系统相关. 应该都是相同的系统
    B/S 建立在广域网上, 面向不同的用户群, 分散地域, 这是C/S无法作到的. 与操作系统平台关系最小.

    7.用户接口不同
    C/S 多是建立的Window平台上,表现方法有限,对程序员普遍要求较高
    B/S 建立在浏览器上, 有更加丰富和生动的表现方式与用户交流. 并且大部分难度减低,减低开发成本.

    8.信息流不同
    C/S 程序一般是典型的中央集权的机械式处理, 交互性相对低
    B/S 信息流向可变化, B-B B-C B-G等信息、流向的变化, 更像交易中心。

    9.开发语言不同:
    B/S一般用asp,asp.net,php等
    C/S一般用VC

    10.用户界面 处理速度
    C/S用户界面个性化。B/S人机交互界面比较差,远程打印功能薄弱,容易出现串打或无法打印现象。

    CTBS架构
    无论是C/S还是B/S架构,都无法满足用户的所有要求,于是谋求将C/S架构与B/S架构相结合的新技术开始受到追捧。这就是远程接入平台产品或者说基于服务器计算模式的瘦客户机(thin client)技术。在这方面处于领先地位的厂商当然首推世界IT架构巨头CITRIX(思杰)。但CITRIX高端的定位,昂贵的价格阻挡了大多数中小型企业应用的步伐。而国内最大的远程接入平台提供商沟通科技从05年开始迅速崛起,推出的国内首款中文版的远程接入平台套件CTBS,填补了这个市场的空白。下面以CTBS为例简单介绍一下这种全新接入架构的工作原理。

       作为国内首款远程接入平台产品,CTBS以基于服务器计算模式的技术为核心(SBC,server based computing),将C/S架构软件WEB化,从而实现了C/S向B/S架构的平滑转化。这种架构的好处是将所有的应用都部署在服务器端,所有的计算都在服务器端进行,远程客户端只显示最终的计算结果。系统管理员将C/S应用程序发布到CTBS平台,并设置好相关的访问权限后,远程的所有获得授权的终端用户(包括分支机构人员、移动办公人员、合作伙伴等)都可使用标准的浏览器远程访问相关的应用,获得与局域网内部使用几乎相同的应用效果。这种计算模式既发挥了C/S架构功能丰富、界面个性化等优点,又吸收了B/S 架构集中部署与管理的优点,所有的升级与维护全部在服务器进行,远程客户端无须作任何安装与设置,将企业在系统维护方面的开销降至最低值。

       举例说明,某企业应用了用友U8或金蝶K/3等典型的C/S系统,为了解决其总部与分支机构的连接问题,应用了沟通CTBS平台。通过CTBS平台将U8或K/3发布以后,远程用户的电脑上无须再安装U8或者K/3的客户端,只要打开IE浏览器,输入CTBS服务器网址,通过身份认证之后,就可以远程使用K/3或者U8系统,而且所有的维护和升级全部在总部的服务器上完成,企业的网管人员也不再需要亲自下到各办事处去维护和升级系统,从而简化了工作环节,大大地减少了维护人员的工作量,解决了以往C/S应用部署难的问题。值得一提的是,企业是在不改变现有任何的网络结构,也不改变任何应用代码的前提下实现C/S转B/S,不仅极大地缩短了部署的周期,也大大降低了系统迁移带来的风险。

       CTBS平台在打印方面具有非常明显的优势,甚至超越了“老大哥”CITRIX在这方面的表现。远程打印最大的挑战来自于接入平台往往无法直接识别远程客户端的打印机,而CTBS的企业版能够默认识别远程的打印机,而且内置了强大的打印驱动程序库,从而无需下载专用的打印驱动,大大提升打印的准确性和速度。

       系统的安全性是另一个最受关注的问题。许多用户担心自己的核心信息发布到公网之后,如果服务器被人攻击或重要信息被截获,后果将不堪设想。对于这些远程接入的厂商们而言,他们必须拿出一个让客户足够放心的安全解决方案。在安全方面,沟通科技推出了远程接入整体解决方案TAS,为用户提供多样化的安全策略:对于一般安全要求的客户,可以通过用户身份认证和数据加密来保证;对于特殊安全要求的用户,则通过指纹识别和SSL 应用安全网关平台来确保数据的万无一失。

数据统计

  • 访问量: 8469
  • 日志数: 22
  • 图片数: 3
  • 文件数: 2
  • 建立时间: 2008-05-25
  • 更新时间: 2008-06-26

RSS订阅

Open Toolbar