您的位置:首页 > 其它

成功项目的特征

2016-09-16 14:23 549 查看
成功的软件项目应该是满足提交的产物满足或超出客户预期的项目 ,而且开发过程符合时间与费用上的要求,结果在面对变化和调整时有弹性。它应该有以下的几个特征:

1、存在很强的架构愿景。

2、应用了管理良好的迭代、增量式开发生命周期。

很强的架构愿景:

良好的架构愿景,几乎是所有成功的面向对象系统所共有的特点。那么什么是“架构”呢?“架构”可以认为就是系统的基本组织结构,包括它的组件、组件之间的相互关系、环境,以及设计和演进的指导原则。大多数定义都表明,架构关注系统的结构和行为,只关注于重要的决定,可能符合某种架构风格,受到涉众和环境的影响,包含理性的决定。

良好架构的系统是具有概念完整性的系统,某种程度上来说,系统的架构基本上与系统的最终用户无关。但是对于构建可理解,可扩展,可重构,可维护和可测试的系统来说,拥有“清晰的内部结构”是很关键的。对系统架构有清晰的感觉,才可能发现共同的抽象和机制。

一个好的系统架构,从本质上来说,应该是面向对象的,由组件构成。通常来说应该具有以下一些共性。

1、由定义良好的抽象层构成,每个层都代表了一种内聚的抽象,提供了定义良好的,受控的接口,并且建立在同样定义良好的,受控的底层抽象设施之上。

2、在每一层的接口和实现之间有清晰的分离关注,让我们能够改变一个层的实现而不会破坏它的客户对它的假定。

3、架构简单,共同的行为是通过共同的抽象和共同的机制来实现的。

以面向对象组织的架构会降低复杂性,更为健壮和可靠。也能更有效的复用。

敏捷开发更加倾向于降低早期建立构架的重要性。相反,它们描述了简单设计,突发设计,重构和“偶然发现的”架构等概念。在这种的过程中,架构随时间而演进。对于“追求理性的开发过程”来说,你所选择的方式取决于你的具体情况。在任何情况下,架构在生命周期的何时完成,如何完成都不会降低拥有架构愿景的重要性。如果没有这样的愿景,系统很难随时间演进,也很难维护。

迭代和增量式开发生命周期:

软件开发和任何要求创造和创新的人类活动一样,也需要一个迭代和增量式的过程,并且这个过程依赖于每个团队成员的经验,智慧和天分。

迭代和增量式开发是以连续系列的发布版本(迭代)的方式开发系统的功能,完成度不断增加(增量)。发布版本可以是面向客户的,也可以是公司内部的。每次迭代选择实现哪些功能是由缓解项目风险来决定的,最重要的风险先处理。作为一次迭代的结果,得到的经验和产物将应用于下一次迭代。通过每次迭代,可以逐渐优化战略和战术决策,最后得到一个满足用户真实需求的解决方案。

迭代和增量的方式是大多数现代软件开发方法的核心,包括像极限编程(XP)和迭代式增量软件开发过程(SCRUM)这样的方法。

扩展:

敏捷方法之极限编程(XP)和迭代式增量软件开发过程(SCRUM)的区别:

1、迭代长度不一样,XP一般是(1-2周),而SCRUM是(2-4周)。

2、在迭代过程中,如果一个需求还没有实现,那么XP是可以考虑用例外的需求来替换的,只要时间一致即可。而SCRUM是不允许的, 一旦开始迭代,任何需求都是不被允许添加进来。

3、在迭代过程中,XP一定是遵循优先级原则来进行开发,而SCRUM则要更加灵活些,不一定非要执行优先级最高的。

4、Scrum没有对软件的整个实施过程开出工程实践的处方,要求开发者自觉保证。但XP对整个流程方法定义非常严格,规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为。

使用迭代式开发方式的好处:

1、允许需求变更,每次迭代关注一组具体的需求。

2、每次迭代都包括当前版本中元素的集成,集成是渐进的,持续的,不会出现在项目结束时的“大爆炸式”的集成工作。

3、风险尽早得到关注,早期的迭代缓解了关键的风险,允许在生命周期的更早时候确定新的风险,更容易处理风险。

4、可以实现对产品的战术改变,为了针对竞争者的动作,可以对产品或产品的早期版本进行改变。

5、促进了复用。架构的关键组件在极早期建立,更容易确定可复用的组件以及利用已有组件。

6、缺陷可以更早被发现并修正。每次迭代都需要执行测试,缺陷就可以在早期时间被发现,并在下一次迭代中被修正,而不是等到项目的后期才发现。

7、迭代式开发方式充分利用团队成员的经验,工作更有效,团队成员在迭代中承担不同角色。

8、团队成员可以在迭代中不断的学习,每次迭代都让团队成员有机会从过去的经验中学习。一次迭代的问题可以在后面的迭代中解决。

9、开发过程可以被优化和改进。每次迭代都会过程和组织方式中有效和无效的部分进行评估,用于改进下一次迭代的过程。

追求理性的开发过程:

对于一个系统而言,重要的是拥有管理良好的迭代增量式生命周期--管理良好是指过程可控并可测量,同时又不至于太严格,不会丧失鼓励创造和创新所需要的自由度。

如今的时代,存在很多软件开发过程可以选择--瀑布模型,XP,SCRUM……,选择哪一种软件开发过程将对如何规划和开发软件项目产生深远的影响,甚至可能决定这些项目的成败。对于敏捷过程来说,其主要目标是在短时间内向客户提交满足他们需求的系统。过程只是实现目标的一种手段,敏捷过程大致有以下特征:

1、轻量级,松散式,不太正式(典型的只做绝对需要做的事情);

2、依赖于团队成员的隐世知识(而不是有良好文档的过程);

3、关注战术超过关注战略(不为将来而构建,因为将来是不可知的);

4、迭代式和增量式(在几个周期中提供系统的一些部分);

5、严重依赖于客户的协作(客户积极参与需求确定和验证);

6、自组织和管理(团队想出最好的工作方法);

7、突发式而不是预先确定(在实际执行过程中让过程演进,而不是事先计划或确定)。

敏捷过程让软件开发团队免于遵循一组严格的步骤,使开发者能够将他们的创造力集中于被开发的系统上。

而对于计划驱动的过程来说,除了在可接受的时间框架内向客户提交期望的系统之外,另一个重要的目标是定义和验证一个可预测,可重复的软件开发过程。除了客户要求的系统之外,软件开发过程本身及其工件都是关键产物。计划驱动的过程大致特点如下:

1、较重量级,较正式(按照规定的活动得到文档齐全的工件);

2、依赖于有良好文档的过程(而不是项目团队的隐世知识);

3、关注战略超过关注战术(建立起强大的架构框架,可以包容将来的变化);

4、依赖于客户的合约(制定合约并达成一致意见,合约描述了构建内容);

5、受管理的,受控制的(遵守详细的计划,无论是团队内部还是团队之间都包括明确的里程碑和验证点);

6、事先定义然后持续改进(包括明确的过程改进流程和机制)。

在项目中,到底选择哪种适合项目的软件开发过程,可以根据如下条件来做权衡:



虽然定义了过程,但是与过程有关的工作并不意味着结束了,随着开发生命周期中发现的问题,应该不断的优化过程(最好是在每次迭代之后)。效果很好的过程活动应该保留,效果不好的过程活动应该去除。(然后,继续并重复这一过程)根据过程执行的实际经验对过程进行持续改进应该是我们的目标。

软件开发过程主要是考虑到两部分,整体软件开发生命周期(宏观过程)和分析设计过程(微观过程)。宏观过程实际是为微观过程设定一个上下文,宏观过程和微观过程实际上两者的关注点不一样,宏观过程主要关注的是总体软件开发生命周期,而微观过程关注的是具体的分析和设计技术,也就是需求到实现过程中使用的技术。

生命周期风格(瀑布式,迭代式,敏捷,计划驱动等)的选择将影响宏观过程,分析和设计技术(如结构化,面向对象等)的选择会影响到微观过程。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: