项目开发流程概述
- 格式:doc
- 大小:3.93 MB
- 文档页数:38
项目开发流程概述
1、项目实训意义
通过项目实训,你可以获得:
最新技术和经验:Struts+Spring+Hibernate, Web Services,Wireless Application Protocol等
先进的开发流程:Rational Unified Process,CMM等等
公司式的开发环境与管理:编程规范,CVS, Project Management等等
团队合作精神和职业素质拓展
2、项目开发流程概述
我们首先介绍一些项目开发的背景知识。
2.1 项目开发流程
项目开发并不是一个简单的过程,我们需要遵循一些开发流程。一个项目的开发会被分成很多步骤来实现,每一个步骤都有自己的起点和终点。也正如此使得开发过程中的每个步骤起点和终点在不同的软件项目中出现不同难度的“坎”,使其难于达到该步骤开始或是终结的条件,开发过程也就不会一帆风顺。
不同的开发模式其实就是将步骤的起点和终点重新定义,甚至重新组合排列,虽然任何一个开发模式最终目的都是完成软件项目的开发,但期间所经历的过程不一样,过程步骤之间的起点和终点的的定义不同所带来的“坎”也就不一样,项目周期自然各不相同。因此,根据软件项目的实际情况选择一个适合的开发模式能减少开发周期中“坎”的出现次数与难度,可以很大程度地缩短开发周期。
我们首先了解一下传统瀑布式开发流程。见图2-1
图2-1 瀑布式(Waterfall)开发流程 亚思晟科技教学大纲
第 2 页 共 38 页 瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型,在瀑布模型中,开发被认为是按照需求分析,设计,实现,测试 (确认), 集成,和维护坚定地顺畅地进行。线性模型太理想化,太单纯,以至很多人认为瀑布模型已不再适合现代的软件开发模式,几乎被业界抛弃。
我们向大家推荐的是统一开发流程RUP(Rational Unified Process)。它是目前最流行的一套项目开发流程模式。它的基本特征是通过多次迭代完成一个项目的开发,每次迭代会带来项目整体的递增,如图2-2所示。
图2-2 RUP流程
从纵向来看,项目的生命周期或工作流包括项目需求分析、系统分析和设计、实现、测试和维护。从横向来看,项目开发可以分为四个阶段:起始(Inception),细化(Elaboration),建造(Construction)和移交(transition)。每个阶段都包括一次或者多次的迭代。在每次迭代中,您根据不同的要求或工作流(如需求、分析和设计等)投入不同的工作量。也就是说,在不同阶段的每次迭代中,生命周期的每个步骤是同步进行的,但权重不同。
项目生命周期
1.项目需求分析
需求分析阶段的活动包括:定义潜在的角色(角色指使用系统的人,以及与系统相互作用的软、硬件环境);识别问题域中的对象和关系,以及基于需求规范说明和角色的需要发现用例(use case)和详细描述用例。
2.系统分析和设计
系统分析阶段是基于问题和用户需求的描述,建立现实世界的计算机实现模型。系统设计是结合问题域的知识和目标系统的体系结构(求解域),将目标系统分解为子系统;之后基于分析模型添加细节,完成系统设计 亚思晟科技教学大纲
第 3 页 共 38 页 3.实现
又称编码或开发阶段,也就是将设计转换为特定的编程语言或硬件,同时保持先进性、灵活性和可扩展性。在这个阶段,设计阶段的类被转换为使用面向对象编程语言编制(不推荐使用过程语言)的实际代码。这一任务可能比较困难,也可能比较容易,主要取决于所使用的编程语言本身的能力。
4.测试和维护
测试是检验系统是否满足用户功能需求以便增加用户对系统的信心。系统经过测试后整个开发流程告一段落,进入运行维护或新的功能扩展时期。
项目开发阶段
1.起始阶段(The Inception Phase):对于新的开发项目来说,起始阶段是很重要的。在项目继续进行前,我们必须处理重要的业务与需求风险。对于那些增强现有系统的项目,起始阶段是比较短暂的,但是其目的仍是确定该项目的实施价值及可行性。
起始阶段有4个重要活动:
制定项目的范围
计划并准备业务案例
综合分析,得出备选构架
准备项目环境
2.细化阶段(The Elaboration Phase)细化阶段的目标是为系统构架设立基线(baseline),为在构建阶段开展的大量的设计与实施工作打下坚实的基础。构架是通过考虑最重要的需求与评估风险演进而来的。构架的稳定性是通过一个或多个构架原型(prototype)进行评估的。
3.构建阶段(The Construction Phase)构建阶段的目标是完成系统开发。构建阶段从某种意义上来看是一个制造过程,其中重点工作就是管理资源、控制操作,以优化成本、日程和质量。因此,在此阶段,管理理念应该进行一个转换:从起始阶段和细化阶段的知识产品开发转换到构建和交付阶段的部署产品的开发。
构建阶段的每次迭代都具有三个关键活动:
管理资源与控制过程
开发与测试组件
对迭代进行评估
4.交付阶段(The Transition Phase)
交付阶段的焦点就是确保软件对于最终用户是可用的。交付阶段包括为发布应用而进行的产品测试,在用户反馈的基础上做微小的调整等内容。在生命周期的这个时刻,用户反馈主要集中在精确调整产品、配置、安装,以及可用性等问题上。
交付阶段的关键活动如下:
确定最终用户支持资料
在用户的环境中测试可交付的产品
基于用户反馈精确调整产品 亚思晟科技教学大纲
第 4 页 共 38 页 向最终用户交付最终产品
最后,作为补充,我们再简单介绍一种新的开发流程:敏捷开发和极限编程。
2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则,他们称自己为敏捷联盟。敏捷开发过程的方法很多,主要有:SCRUM,Crystal,特征驱动软件开发(Feature Driven Development,简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(eXtreme
Programming,简称XP)。
极限编程是一套能快速开发高质量软件所需的价值观、原则和活动的集合,使软件能以尽可能快的速度开发出来并向客户提供最高的效益。XP在很多方面都和传统意义上得软件工程不同,同时,它也和传统得管理和项目计划得方法不同。这些方法在软件工程和其他管理活动中都有借鉴意义。
XP具有12个过程,只有完全使用12个过程才是真正使用了XP,只是简单使用了其中一个方法并不代表使用了XP。
现场客户(On-site Customer)
计划博弈(Planning Game)
系统隐喻(System Design)
简化设计(Simple Design)
集体拥有代码(Collective Code Ownership)
结对编程(Pair Programming)
测试驱动(Test-driver)
小型发布(Small Release)
重构(Refactoring)
持续集成(Continous integration)
每周40小时工作制(40-hour Weeks)
代码规范(Coding Standards)
下面是极限编程的有效实践:
完整团队 XP项目的所有参与者(开发人员、客户、测试人员等)一起工作在一个开放的场所中,他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
计划游戏计划是持续的、循序渐进的。每2周,开发人员就为下2周估算候选特性的成本,而客户则根据成本和商务价值来选择要实现的特性。
客户测试作为选择每个所期望的特性的一部分,客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试,不包含任何重复,表达出了编写者想表达的所有东西,并且包含尽可能少的代码。
结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
测试驱动开发编写单元测试是一个验证行为,更是一个设计行为。同样,它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环,尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作,他们先增加一个失败的测试,然后使之通过。
改进设计随时利用重构方法改进已经腐化的代码,保持代码尽可能的干净、具有表达力。
持续集成团队总是使系统完整地被集成。一个人拆入(Check in)后,其它所有人责任代码集成。
集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责,每个人都可以参与任何其它方面的开发。
编码标准 系统中所有的代码看起来就好像是被单独一人编写的。 亚思晟科技教学大纲
第 5 页 共 38 页 隐喻 将整个系统联系在一起的全局视图;它是系统的未来影像,是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符,那么你就知道该模块是错误的。
可持续的速度 团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑。 极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法,项目团队可以拿来直接采用,也可以增加一些实践,或者对其中的一些实践进行修改后再采用。
2.2 UML概述
UML(Unified Modeling Language)是实现项目开发流程的一个重要工具。它是一套可视化建模语言,由各种图来表达。图就是用来显示各种模型元素符号的实际图形,这些元素经过特定的排列组合来阐明系统的某个特定部分或方面。一般来说,一个系统模型拥有多个不同类型的图。一个图是某个特定视图的一部分。通常,图是被分配给视图来绘制的。另外,根据图中显示的内容,某些图可以是多个不同视图的组成部分。
图具体分为静态模型和动态模型两大类。其中静态模型包括:
用例图(Use case Diagrams)
类图(Class Diagrams)
对象图(Object Diagrams)
组件图(Component Diagrams)
部署图(Deployment Diagrams)
动态模型包括:
序列图(Sequence Diagrams)
协作图(Collaboration Diagrams)
状态图(State Chart Diagrams)
行为图(Activity Diagrams)
2.2.1 用例图
用例图(Use-case Diagram)显示多个外部参与者,以及他们与系统之间的交互和连接,如图2-3所示。一个用例是对系统提供的某个功能(该系统的一个特定用法)的描述。虽然实际的用例通常用普通文本来描述,但是也可以利用一个活动图来描述用例。用例仅仅描述系统参与者从外部通过对系统的观察而得到的那些功能,并不描述这些功能在系统内部是如何实现的。也就是说,用例定义系统的功能需求。