Silverlight3发布大会演示作品-全国首例Silverlight企业级开发实例讲解4-我们是如何选择项目生命周期的

 

概要：
1首先我会讲解软件工程领域项目生命周期的一些知识，

后面我会把我参考的资料给大家以链接或者下载的方法予

以提供！

2讲解项目管理中要考虑的元素：需求，时间，风险，人力，质量，技

术，配置，源代码等

3讲解我们是如何根据以上几个要素来决定我们项目最后采用了迭代式，敏

捷软件开发！
 
第一：软件生命周期


我主要将其分成三个部分:

软件生命周期概念

软件生命周期模型

软件生命周期方法


第一:软件生命周期的概念


      概要:

从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分

析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少

维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle 

Model）。 

 

　软件生命周期官方定义：
软件生命周期官方定义：

 

 
　软件生命周期(SDLC)的六个阶段


第二：软件生命周期模型（不要和软件生命周期混淆了哦）

典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型

瀑布模型（Waterfall Model）（也可以理解为文档驱动模型）
瀑布模型

 

增量迭代式模型

迭代和增量模型


由于瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来，为了解决这些问题的风险是巨大的。"在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。"（RUP）


第三 软件生命周期方法：

原型法
　原型法基本理论

原型法基本思想

   

原型法凭借着系统分析人员对用户要求的理解，在强有力的软件环境支持下，快速地给出一个实实在在的模型（或称原型、雏形），然

后与用户反复协商修改,最终形成实际系统

 

原型法（Prototyping）开发过程

    首先用户提出开发要求，开发人员识别和归纳用户要求，根据识别、归纳结果，构造出一个原型（即程序模块），然后同用户一道评

价这个原型。如果不行，则再对原型进行修改，直到用户满意为止。


 

从原型向最终系统的转换

  

  原型经过反复的使用、评价和修改以后，即可转入最终系统(或称正式系统)的开发，如图4-3-9所示。从原型向正式系统的转换方式有三种。


 

 1.程序一次性使用(只利用需求和规格)

    该方法对原型研制限定在传统软件生命周期的某一阶段，例如，需求定义阶段，正如我们在本章第3节所介绍的那样。该阶段工作结束

后，原型随之作废。该方式可用于验证、完善系统需求和人机接口的原型开发。

    2．程序嵌入(作为核心部分利用)

    程序嵌入方式是将完成了的原型体作为正式系统的核心部分。事实上这是一种附加策略，对应于我们在本章所介绍的演化型的开发形式，把原型作为核心，逐步添加新功能，发展成为最终系统。在抛弃策略中，原型与最终系统的开发可以采用不同的高级语言。而在附加策略中，因原型将作为最终系统的一部分，所以必须采用与最终系统相同的开发语言。

    3.程序自动变换

    采用该方法时，原型体用高级语言开发，并自动将原型体变换成比最终系统的语言更低的中间语言，使得嵌入在最终系统中的原型体

的运行效率比变换前大大提高。程序自动变换法尚存在一些未解决的问题，例如不同语言之间的自动变换的困难，后程序的性能不能保障

等。因此，该方法目前还处在研究阶段，并未达到实用化程度。

  原型法优缺点和适用范围

 

原型法的使用范围

 

 

我们项目中的原型举例：
 

      
     在silverlight开发中，因为我们只有开发人员，而没有设计人员，所以微软便推荐了一家设计公司（微软金牌合作伙伴）。
所以前期“三人帮”就出现了：客户，开发人员，设计公司共同合作来设计出前台界面。可以用 PS画出来，可以用PPT文档设计出来。
首先：客户提出需求（其实这个时候我们已经形成需求文档），大家共同讨论，刚开始一定要让设计人员自由发挥，不要限制他们的思维，当差不多了，然后再提出一些限制。当设计公司用PPT设计出相应的界面后（一般是三个版本，供客户选择），客户选择一个自己喜欢的，或者全盘否定，由设计公司重新设计，经过不断的协商，最后客户选定一款。
第二：客户选定一款后，这个时候只是确定了框架的整个外貌，然后还要针对其中的小细节继续商量，设计公司然后不断完善，最终达到客户的要求。然后设计公司根据PPT用xaml的矩形或者简单的东西组织出来，并且打到和PPT一样的效果。
第三：客户满意之后，然后是我们开发人员了，我们会提出一些技术难题，尽量让设计公司制作的前台能够降低我们的开发难度。
比如：
1设计公司原来给们设计的xaml，datagrid是用矩形堆积出来的，我们立刻要求他们在datagrid的基础上进行样式的制作，并且打到客户要求的水平。
2我们要求所有的空间全部用样式去做，并且要有一个样式的详细说明书。等等
下面是早期的一些我们开发人员提出的问题：
我们开发人员向设计公司提出的建议
第四：当三方都协商之后，设计公司根据要求设计出来前台（一般就是用基本控件堆积出来的）。

我们是用页面数量来计算资金的，为了达到降低成本，我们不可能要求设计公司设计每一个页面，而是挑出公共的。
这样设计出来的产品就是符合三方利益的原型。我们之后的开发都是基于这个设计开发的。

第五：需求人员和客户还要商量一些逻辑，就是点击某个button需要出现什么样的效果。也就是面向开发人员的用户操作手册。

这个操作手册按照需求模块来分类。分配任务的时候，方便开发人员查阅。
最后就形成了设计搞和操作手册。这个是我们开发人员开始开发的原型。

下面是部分设计demo和操作手册内容。

设计公司前台（PPT文档或者PS图形效果）：



设计公司XAML语言：
 
Code
也就是用一些简单的东西堆积 出来 。
 
用户操作手册：
 
以注册功能为例，看看根据设计公司demo形成的操作手册（图形来自设计公司的第一次设计的demo），也是我们开发人员参考的文档：

4.    注册
功能简介：
    系统的用户主要分为三大类，（外网）企业用户、总部精算人员、各中心精算人员，其中总部精算人员和各中
 
心精算人员通过公司内部网络及内部登录系统来访问精算咨询系统；外网企业用户通过互联网登录首页，并注册成
为系统用户，才可以登录到系统。

操作流程：

1、    点击[马上注册]，进入注册免责说明界面，如图：

 
2、勾选‘我已阅读并同意以上条填款’，点击[下一步]进入注册信息界面，填写完成后，点击[保存]，注册成功。如图:
 
5.    忘记密码
功能简介：
    如果用户忘记密码，可以通过此功能，通过正确回答注册时设置的问题的答案，重新设置新的密码。
操作流程：
1、    点击[忘记密码]，提示输入账户，如图：
 
2、    点击[下一步]，进入提示问题界面，如图：
 
3、    输入正确的问题答案后，点[下一步]，进入设定密码界面。
4、    两次输入密码后（两次输入的密码必须相同）点击[确定]，密码设置成功。
 
 
 
我们就是根据上面形成的原型进行开发的。
 
 
 
快速和敏捷开发

我们一般将快速和敏捷开发做为方法论,而很少将其做为一种软件开发生命周期模型.敏捷的目的是减少繁重和不必要的工件的输出,提高效率.而不是要我们去挑阶段或过程,不是分析设计都还没有做就去做开发.因此对于瀑布,增量迭代或原型我们都可以借鉴敏捷方法论中的一些好的实践,这些实践都是对传统的生命周期模型很好的补充.对于敏捷方法论在此不再做过多的叙述.

关于选择生命周期模型的最后的总结

1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.
2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.
3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型
4.在需求不稳定情况下尽量采用增量迭代模型
5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布
6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型
7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.
8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型.
9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则.

 

 

 

我们是如何进行需求管理的：

 

现实世界是在不断变化的，而且变化的速度是越来越快，IT领域唯一不变的就是“变化”。

一个项目是否能够成功，对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功，如果需求出现偏差，仍然是南辕北辙。

项目开发过程中能够与客户建立有效快速的沟通渠道，是项目成功的关键。
我们的需求管理：
1需求跟踪，定时更新。
2架构师，项目经理根据变化的需要讨论，分解，形成任务分配下去。
 
我们是如何进行进度管理的：
 
保 证项目进度不出现大的偏差的前提是制定一个好的项目计划。必须根据项目规模，成员情况，技术难度等多方面考虑整个项目计划。如果项目的deadline已经确定，则必须采用一些方法来保障项目计划的完成。首先是选择符合项目的软件开发生命周期。通常情况下，并不建议采用瀑布开发方式。最佳的办法，应该是 RUP或者敏捷开发，然后结合原型法制订项目计划。这样可以规避因为需求变更产生的风险。

其次，要每日跟踪项目的进展情况。可以通过晨会、周会以及项目日报、项目周报了解项目进展情况。同时，需要为各个小组指定进度跟踪人，根据各个小组长的日报，判断实际的进度是否与计划出现偏差。
要制定项目进度偏差的应对方法。一旦项目进度出现了偏差，必须采取相应错误解决问题。或者通过加班、增加人手、申请项目进度等方法及时作出响应。

及时向项目成员汇报项目进度情况。只有让各个项目成员了解到项目现状，才能够给每个成员增加压力，不至于松懈。同时，也能够使得每个成员能有一个目标，而不至于茫然失措。


我们是如何进行人员变更管理的：
 
人员变更。如果不控制好，两者对项目的进展都会带来灾难性的后果。需求变更在前面已经叙述，而EAS项目中发现人员变更的情况也非常严重，因此这里重点介绍关于人员变更的管理。

如果发生人员进入的情况，那么对项目带来的通常都会是好的影响。但我们也必须注意如何让新成员更快地融入团队。整体上讲，如果需要新成员加入，发生变更的最佳时机是项目前期。如果在项目中后期加入新成员，无疑则意味着项目出现了灾难性的后果。而新增加的成员，由于不熟悉项目，所能带来好的影响也是有限的。如果不处理好新成员与老成员之间的合作关系，反而会带来负面影响。

人员的退出很多时候是不可控的，同时对项目带来的影响也是不可估计的。为了将这些影响降到最低，就必须在项目开始之初就要确立编码规范。同时，还应该重视对文档的维护与更新。而在人员退出时，必须做好交接工作。同时，还应对这种变更进行合理的评估，并及时报告项目管理部，并与客户及时沟通。如果对项目进度有严重影响，应争取最大的努力取得客户的理解，提出项目延期的申请。
 
 
风险管理
 
posted @ 2012-04-20 11:01  书奎  阅读(483)  评论(1)  编辑  收藏  举报