旅游管理程序软件项目管理大作业

1. 合同管理。

1.1 合同简介。

1.1.1项目名称。

静乐旅游。1.1.2合同双方。

甲方：静乐旅游公司。

乙方：it项目团队。

1.1.3协议形式。

技术合同。1.1.4**条件和维护协议。

**的软件：乙方为甲方提供所需的“静乐旅游”应用程序。

提供的服务：乙方为甲方提供所需的日常维护和服务器管理，同时对甲方用户提供使用指导。

提供的文档：乙方在交付软件时提供详细的软件规格说明书和使用文档。

安装服务：乙方为甲方提供软件安装。

公文处理：乙方负责将甲方提供的旅游项目输入系统并进行分类。

维护协议：当甲方在使用该产品时，在正常操作的情况下出现bug或系统错误，乙方免费为甲方提供修复服务以保障软件的正常使用。当由于甲方的错误使用等非软件原因导致出现故障，乙方同样提供修复服务。

由于甲方拥有该软件的源**所有权，因此甲方需要承担部分维修和进一步开发的责任。当软件需要新的功能拓展或改版升级时，由双方共同协商决定。

1.2 软件所有权。

该软件是由甲方该软件是由甲方向乙方定制，甲方拥有该软件的版权，乙方不能将该软件的任何版本卖个其他客户。软件提交时，项目源**的所有权自动移交到甲方，乙方不得擅自对源**进行修改。

1.3 环境与标准。

环境：乙方为甲方安装软件和进行员工培训时，需要由甲方提供住宿和膳食，乙方在规定时间内完成任务。甲方要保证安装软件的硬件设备和合同初始规定一致，乙方只保证软件和规定的硬件兼容。

由任何一方的单方面原因导致的延期产生的费用，由该方面支付。

标准：乙方在开发过程中必须遵守iso 12207关于软件生命周期和文档的标准。

1.4 客户承诺与验收规程。

客户承诺：乙方开发软件过程中，甲方通过人员协同乙方进行开发。该人员主要参与项目的规划设计和需求分析，阶段性验收和总体测试。

当项目出现需求变更时，对乙方进行详细的阐述说明。乙方不负责这些人员提供食宿和联系设备。

验收规程：2023年6月24日，乙方为甲方安装所需的软件。6月25日至6月31日甲方代表对产品进行验收测试，并根据需求在6月30日前对商品提出更正请求。

测试通过后，双方进行软件交付签字。乙方对甲方进行软件使用培训。

1.5 项目和质量管理。

甲乙双方前四个月每月初进行一次进展会议，后三个月每两周周末进行进展会议。会议内容为乙方向甲方提供最新进度的掩饰和下一阶段的工作安排和计划。甲方根据演示提出相应的整改意见，并对下一步工作进行提出意见和建议。

1.6 时间表。

详细时间表见项目进度。此处略。

1.7 **和付款方式。

软件总价为150万元整。合同签订后，甲方向乙方支付50万元定金。项目的第三个月，乙方按计划时间表完成需求分析、系统分析、设计和完成系统的基本框架后，甲方向乙方支付50万元。

该系统完成后，甲方进行验收测试，在签字验收完成后，甲方向乙方支付全款。

1.8 其他法律要求及违约处理。

由任何一方的过失导致出现损失后的赔偿由双方协商决定。

甲方法人代表：胡文静。

乙方法人代表：岚羽昕。

签约地点：静乐旅游公司项目管理主任办公室。

有效期限：2023年—2023年6月26号。

2.项目生存期。

确定该项目的生存期模型按如下步骤进行分析：评审、分析项目的特性；选择适合项目的生存期模型；标识生存期模型与项目不一致地方，并进行裁减。

静乐旅游”应用程序涉及到用户的隐私安全，因此很强调产品的性能和安全性。需保证产品能保持稳定运行，不会以为一定数量的用户同时登录注册等操作时挂机，以致宝贵的消息或操作无法及时运行。

总而言之该项目的性能安全性为主，可操作性次之，界面美观度最末。虽然项目的需求可能会因领导“挑剔”的口味而一再改变，不过大体的需求是明确的。而且又考虑到项目安全性能的首要要求，以v模型为基础的生存期最为合适。

同时参杂增量模型生存期的一些特点以应对可能会随时添加的功能需求。

项目生存期模型如下：该生存期模型将v模型除最后的项目规划和验收测试以外的过程做一复制，套用增量模型在首先完成基本功能的基础上增加功能。

3.需求管理。

3.1软件需求管理过程。

静乐旅游公司提出需求如下：

设计开发、安装调试并后期满足需求的“静乐旅游”应用程序。需要该程序为桌面应用程序，进入程序后需要弹出旅游介绍界面，该旅游介绍界面需与计算机自身系统分离，不得覆盖，具有独立窗口。

该系统实现了管理员通过对景点信息、订票信息、酒店信息、保险信息、会员信息维护，实现了会员**预订景区景点旅游的功能。其模块介绍如下：

后台：后台是整个信息系统中最重要复杂的部分。管理员通过此处对**内容进行管理。后台管理共分为景点管理、订票管理、酒店管理、保险管理、会员管理、系统管理。

1.景点管理。

对景点信息进行添加、修改、删除和查询操作；对会员的景点订单信息进行确认。

2.订票管理。

添加新的航向信息，修改、删除和查询票务信息操作；对会员的票务订单信息进行确认。

3.酒店管理。

添加新的酒店信息，修改、删除和查询酒店信息操作；对会员的酒店订单信息进行确认。

4.保险管理。

添加新的保险信息，修改、删除和查询保险信息操作；对会员的保险订单信息进行确认。

5.会员管理。

添加新的会员信息，修改、删除和查询会员信息操作。

6.系统管理。

可以通过链接进入后台主页、前台主页，修改密码以及退出系统操作。

综上所述，系统后台的功能需求可以通过图3.1 简要表示。

图3.1 系统后台的功能需求。

前台：前台部分就是用户浏览、选择景点的地方，需根据所需旅游线路安排布局，照顾用户浏览习惯，简化流程，使会员能迅速找到旅游景区景点，真正做到“简洁高效流畅”的环境。

1.注册会员。

用户可以预定旅游景区景点信息，但是用户必须通过注册成为会员才具有这些权限。

2.修改用户信息。

会员可以对自己的信息进行修改。

3.收藏夹。

会员可以将中意的旅游景区景点信息放入收藏夹，并对该信息进行删除或生成订单操作。

4.我的订单。

可以查看生成旅游景区景点的订单信息，并对已经确认的订单信息进行相应的明细信息的酒店选择，订票、保险的购买等。

5.景区景点。

用户可以通过选择景点城市查看**中的景区景点信息。

6.周边酒店。

用户可以通过输入城市、**或名称以及选择星级查询相应的酒店信息。

7.票务信息

用户可以通过输入出发地或目的地以及选择类型查询相应的票务信息。

8.保险信息

用户可以通过输入名称或选择类型查询相应的保险信息。

综上所述，系统的前台功能需求可以通过图3.2 简要表示。

图3.2 系统前台的功能需求。

3.2需求规格。

3.2.1需求规格说明书（简略版）

系统定义：“静乐旅游”应用程序。

应用环境：windows2000；windows xp；windows vista；windows 7；linux；ios etc.

功能规格：后台（景点管理、订票管理、酒店管理、保险管理、会员管理、系统管理）

前台（注册会员、修改用户信息、收藏夹、我的订单、景区景点、周边酒店、票务信息、保险信息）

性能需求：保证用户同时登录服务器时也不会因处理的信息量过大大而导致系统瘫痪。另必须保证系统的安全性，可以禁得住一般的黑客袭击和内部作假。

对账户有足够的保护措施以防账户被盗。操作简单明了，提示明显，界面美观且生动。

旅游管理程序软件项目管理大作业

旅游管理程序软件项目管理大作业

旅游管理系统程序软件项目管理系统大作业

软件项目管理大作业

其他用户还读了