基于瀑布模型的图书馆项目过程管理

1、 基于瀑布模型的图书馆项目过程管理 学 院 名 称： 电子与信息工程学院 专 业： 计算机科学与技术 班 级： 07软件一班 定稿日期：2010 年 12 月 20 日1. 软件过程概述软件过程为一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。 软件过程（Software Process）是指一套关于项目的阶段、状态、方法、技术和开发、维护软件的人员以及相关Artifacts（计划、文档、模型、编码、测试、手册等）组成。目前有三种方法：UP（the unified process），The OPEN Process，

2、OOSP(The Object-Oriented Software Process)。 软件过程(Software Procedure)是指软件生存周期所涉及的一系列相关过程。过程是活动的集合；活动是任务的集合；任务要起着把输入进行加工然后输出的作用。活动的执行可以是顺序的、重复的、并行的、嵌套的或者是有条件地引发的。 软件过程可概括为三类：基本过程类、支持过程类和组织过程类。基本过程类包括获取过程、供应过程、开发过程、运作过程、维护过程和管理过程。支持过程类包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及问题解决过程。组织过程类包括基础设施过程、改进过

3、程以及培训过程。 软件过程主要针对软件生产和管理进行研究。为了获得满足工程目标的软件，不仅涉及工程开发，而且还涉及工程支持和工程管理。对于一个特定的项目，可以通过剪裁过程定义所需的活动和任务，并可使活动并发执行。与软件有关的单位，根据需要和目标，可采用不同的过程、活动和任务。2. 瀑布软件过程模型瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也

4、是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。2.1传统瀑布模型图2-1传统瀑布模型2.2实际瀑布模型图2-1实际瀑布模型2.3瀑布模型各阶段分析在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。需求分析阶段需求分析：虽然是第一步，但是这一步至关重要，因为它包含了获取客户需求与定义的信息，以及对需要解决的问题所能达到的最清晰的描述。分析包含了理解客户的商业环境与约束，产品必需实现的

5、功能，产品必需达到的性能水平，以及必需实现兼容的外部系统。在这一阶段所使用的技术包括采访客户、使用案例和软件特色的“购物清单”。分析阶段的结果通常是一份正式的需求说明书，这也是下一阶段的起始信息资料。设计阶段设计：这一步包括了“定义硬件和软件架构、组件、模块、界面和数据等来满足指定的需求(Wikipedia)。”它包括了硬件和软件架构的定义，确定性能和安全参数，设计数据存储容器和限制，选择集成开发环境（IDE）和编程语言，并指定异常处理、资源管理和界面连接性的策略。这一阶段还强调了用户接口的设计，包括与浏览和可用性相关的问题，这一阶段的输出结果是一份或多份设计说明书，这些说明书将在下一阶段使用

6、实现阶段实现：这一步包含了根据设计说明书来构建产品，通常，这一阶段是由开发团队来执行的，开发团队包括了程序员、界面设计师和其他的专家，他们使用的工具包括编译软件、调试软件、解释软件和媒体编辑软件。这一阶段将生成一个或多个产品组件，它们是根据每一条编码标准而编写的，并且经过了调试、测试并进行集成以满足系统架构的需求。对于大型开发团队而言，我建议使用版本控制工具来追踪代码树的变化，这样在出现问题的时候可以还原以前的版本。测试阶段测试：在这一阶段，独立的组件和集成后的组件都将进行系统性验证以确保没有错误并且完全符合第一阶段所制定的需求。一个独立的质量保证小组将定义“测试实例”来评估产品是完全实现了需

7、求还是只有部分满足。有三种测试方法可以使用：对独立的代码模块进行单元测试；对集成产品进行系统测试；以及客户参与的验收测试。如果发现了缺陷，将会对问题进行记录并向开发团队反馈以进行修正。在这一阶段，还有产品文档会经过准备、评估并发布，比如用户手册等。维护阶段维护：这一阶段发生在安装之后，包括了对整个系统或某个组件进行修改以改变属性或者提升性能，这些修改可能源于客户的需求变化或者系统使用中没有覆盖到的缺陷，通常，在维护阶段对产品的修改都会被记录下来并产生新的发布版本（称作“维护版本”并伴随升级了的版本号）以确保客户可以从升级中获益。2.4瀑布模型的特点：阶段间具有顺序性和依赖性。推迟程序的物理实现

8、。质量保证：每个阶段必须完成规定的文档；每个阶段结束前完成文档审查,及早改正错误。易于组织，易于管理：因为你可以预先完成所有计划。是一种严格线性的、按阶段顺序的、逐步细化的过程模型（开发模式）适用场合：当有一个稳定的产品定义和很容易被理解的技术解决方案时，纯瀑布模型特别合适。当你对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上，瀑布模型也特别合适。对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序方法处理问题。在质量需求高于成本需求和进度需求的时候，它尤为出色。当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适合。 3.基于瀑布软件过程模型的图书馆项目开

9、发3.1图书馆信息系统开发计划项目管理是建立在项目开发计划基础之上的。计划是管理的路线图，管理是计划执行的保证。路线图需要管理者去跟踪、监督、评审、审计和修正。管理信息系统是一种需求不断变化，不确定因素较多，风险较大的工程项目。因此，对它的开发必须进行有效的计划和控制，即项目管理。项目开发计划，是通过项目每个阶段的开始时间和提交时间所制定的实施任务,利用任务驱动,以便有效的落实分工和责任,使每位成员都能分工到位，并在限定的时间内完成自己的任务,及时在各个阶段结束后交付文档、进行总结，为下一个阶段工作的开展做好准备。3.2图书馆信息系统需求分析现针对图书馆信息系统对图书馆的组织结构、业务流程、用

10、户角色职能、系统数据流进行分析。我们利用了结构化分析和UML中的用例况从大到小，从粗到细进行系统建模。组织结构调查系统的组织结构，是单位内部各个部门的划分和它们之间的关系。系统的组织结构关系调查，是从总的方面对系统进行宏观的了解和分析。信息的流动关系是以组织结构为背景，而且总是伴随着组织部门之间的资金流和物流的传递而产生的。图-2是图书馆的内部组织结构图。系统用户分析图书馆信息系统是针对图书借阅次数的大量处理工作而开发的管理软件。有三种用户：管理员、操作员和读者。图3-1 图书馆内部组织结构图信息系统数据流分析3.3图书馆信息系统概要设计 系统模块的划分概要设计的核心问题是确定系统总体架构和模

11、块划分。系统功能要层层划分，直到每一个模块可以作为一个可以执行的程序单元为止。功能模块的划分最终的结果，是系统功能结构图图3-3是图书馆信息系统的功能架构图 图3-4系统处理基本流程图3.3图书馆信息系统详细设计登录窗体功能 操作员选择自己用户名并输入正确密码登录系统，如图所示。 1. 输入项 用户名以及该用户所对应的密码。 2. 输出项相应的系统登录提示信息。3. 界面设计 用 户 名：【cmbox用户名】 密 码：【 txt 密码 】 【确认 cmdok】 【取消 cmdexit】 4.测试要点三次密码错误是否退出程序。 3.3.2数据库物理设计 数据库物理设

12、计是指设计出数据库的物理数据模型，是数据库在物理设备上的具体实现，即数据库服务器物理空间上的表空间、表、字段、索引、视图、储存过程、触发器，以及相应的数据字典设计。主要功能模块设计增加删除用户 书籍信息管理 修改书籍资料 查询书籍资料 读者信息管理 借书管理 还书管理 续借管理 3.4图书馆信息系统系统测试 下面以读书类别管理为例，说明测试思路：读者类别管理 frmreaderstyle.frml 测试要点 1）能否在“读者类别表”和当前表格中正确显示所输入的信息,且“读者类别”是唯一的； 2）当借书信息表中存在该类别的读者时，不能删除该类别的记录。l 测试列表如图所示。4

13、.课程设计总结瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。若对于经常变化的项目而言，瀑布模型毫无价值。4.1瀑布模型优点：每个阶段都有指定的起点和终点，过程最终可以被客户和开发者识别（通过使用里程碑），在编写第一行代码之前充分强调了需求和设计，这避免了时间的浪费以及跳票的风险，同时还可以尽可能地保证实现客户的预期需求。提取需求和设计

14、提高了产品质量，因为在设计阶段捕获并修正可能存在的漏洞要比测试阶段容易很多，毕竟在组件集成之后来追踪特定的错误要复杂很多。最后，因为前两个阶段生成了规范的说明书，当团队成员分散在不同地点的时候，瀑布模型可以帮助实现有效的知识传递。 4.2瀑布模型缺点：通常客户一开始并不知道他们需要的是什么，而是在整个项目进程中通过双向交互不断明确的；而瀑布模型是强调捕获需求和设计的，但在这种情况下，现实世界的反复无偿就显得瀑布模型有些不切实际了。除此以外，即使给定了客户需求，根据这些需求在一定的精确性范围内（瀑布模型所建议的）估算时间和成本是非常困难的。因此，建议在客户需求可以在最初阶段明确的情况下并且相对稳定的项目中使用瀑布模型。另外的批评指出瀑布模型还假定设计可以被转换为真实的产品，这往往导致开发者在工作时陷入困境，通常，看上去合理可行的设计方案在现实中往往代价昂贵或者异常艰难，从而需要重新设计，这样就破坏了传统瀑布模型中清晰的阶段