软件工程实践报告

尝试着写一下子简单的可行性报告和需求分析说明书，有借鉴他人的，如有侵权，请及时联系本人。

可行性研究报告（可行性论证报告）
目录
1 引言 2
1.1 编写目的 2
1.2 背景 2
1.3 定义 2
1.4 参考材料 2
2 可行性研究的前提 2
2.1 要求 2
2.2 目标 2
2.3 条件、假定和限制 3
2.4 进行可行性研究的方法 3
2.5 评价尺度 3
3 对现有系统的分析 3
3.1 数据流程和处理流程 3
3.2 工作负荷 4
3.3 费用开支 4
3.4 人员 4
3.5 设备 4
3.6 局限性 4
4 所建议的系统 4
4.1 对所建议的系统的说明 4
4.2 数据流程和处理流程 5
4.3 改进之处 5
4.4 影响 5
4.5 局限性 5
4.6 技术条件方面的可行性 5
5 可选择的其他系统方案 6
5.1 可选择的其他系统 6
6 投资及收益分析 6
6.1 支出 6
6.2 收益 6
7 社会条件方面的可行性 6
7.1 法律方面的可行性 6

1 引言
1.1 编写目的
并非任何问题都有简单明显的解决办法，事实上，许多问题不可能在预定的系统规模或时间期限之内解决。该软件项目也是如此，为了避免在这项工程上花费的时间、人力、软硬件资源和经费的浪费。所以我们进行可行性研究，用最小的代价在尽可能短的时间内确定问题是否能够解决，并将研究的整个过程汇总成该报告。
1.2 背景
该项目开发的软件是火车票销售系统，鉴于当前人们出行流量大，但仍存在疫情中高风险地区，理应避免出行的矛盾状况构思出来的，该软件设计完成之后可用于全国人员的出行购票。通过网上的的购票环境减少人员因购票的聚集。也将购票过程规范化，便利化。
1.3 定义
设计一个全国范围的火车票销售系统，可以合理规划人们的出行路线，尽量避免进出疫情中高风险地区。
1.4 参考材料
《软件工程导论》 张海藩、牟永敏编著，清华大学出版社
2 可行性研究的前提
2.1 要求
A. 该软件的基本功能要求与功能是实现在网上销售火车票。
B. 数据的输入和输出处理流程都依靠数据库的支持
C. 软件的基本数据流动为用户数据输入，订单信息，旅客信息，车次信息等等。
D. 数据库基于MySQL 8.0数据库系统的数据管理。
E. 与软件相关的其他系统：该系统需要建立在其他系统之上，如疫情动态分析系统，以此来获得疫情信息，从避免车次出入疫情地区。
2.2 目标
该软件的设计目标必须尽量达到人力与设备费用的节省，并且使软件处理数据的速度提高，软件的整个设计过程必须通过生产能力的提高，人员工作效率的提高等等使软件开发成本最小化。实现保证软件质量的前提下的资金投入最小化。
2.3 条件、假定和限制
开发系统的资金主要由用户提供开发资金投入，故在设计开发中最大不能超过该限度，且软件完成交付用户使用后，应保证软件运行寿命至少达到用户的要求范围。且软件开发时间应基本控制在用户提出的要求范围内。
鉴于当前疫情常态化，且该软件并不是仅仅限于疫情时期使用，建议该软件的使用寿命在10年。
开发工具：JDK1.8，MySQL8.0
开发环境：Win10系统
运行环境：Win10系统和Win7系统
2.4 进行可行性研究的方法
实行软件的可行性研究方法主要有：系统流程图、数据流图、数据字典，成本/效益分析等方法具体详情见下。
2.5 评价尺度
本次可行性分析会从技术可行性、经济可行性、操作可行性、社会可行性四个尺度评价。
3 对现有系统的分析
3.1 数据流程和处理流程

3.2 工作负荷
由于同一张票会有多个用户去购买，所以整个系统的并发量使非常大的，同时也要兼顾退票与购票，防止有超卖一类的现象出现。
3.3 费用开支
由于现有系统的工作负荷严重超载，在现有系统上投入的人力，设备，空间，材料，等等与其他的一系列支持性服务越来越大，导致开发费用支出巨大，严重影响系统的可用性，急需改进。
3.4 人员
鉴于原有系统的技术性含量比较低，高技术人员不足，无法做出支持当前访问量的系统。
3.5 设备
设备可支持的访问量比较低，并没有达到预期的并发量。
3.6 局限性
经过严谨的分析，可知原有的系统存在很大的局限性，比如技术的过于陈旧，人员工作负荷大，系统维护及费用支出巨大，人员与设备技术量低等等一系列缺点，所有这些都明确了需要一个新的信息化时代的高科技的系统，所以开发这个系统还是很有必要的。
4 所建议的系统
4.1 对所建议的系统的说明
新系统再原有系统之上提高了访问量，同时新增了再疫情期间的路线规划。且使用了先进的数据库技术以提高软件整体的速度。
4.2 数据流程和处理流程

4.3 改进之处
很明显，新系统增加了专门为解决疫情问题的查询功能，可以尽量避免出行路线中有疫情中高风险地区。同时还采用了技术含量更高的设备来支持该系统，解决以往访问量不足的问题。
4.4 影响
A. 采用了更为高级的设备，其系统采用的软件技术也要进一步提高，软硬件必须一致提升。
B. 需要雇佣技术含量更高的技术人员，其投入的资金也会增加
4.5 局限性
只是提高了原有系统的并发量以及疫情时期的功能拓展，新的系统功能还是较为单调，且疫情功能并不需要长久存在。
4.6 技术条件方面的可行性
对于购票系统本身，实现的技术并不高，很容易达成，而高并发的处理，国内也有了成功的先例，所以说，该项目再技术方面是可行的。对于新增加的疫情功能，也可以通过现有的疫情分析系统进行处理，增加路径选择的算法，合理规划出用户的出行路线，技术上也是可以实现的。
5 可选择的其他系统方案
5.1 可选择的其他系统
由于本次项目的开发参与人员过少，所以并没有提供其他的可选择的方案。
6 投资及收益分析
6.1 支出
该系统主要支出在于设备的购买、一些服务的购买和开发人员的雇佣等资金的投入，大概估算需要投入163000人民币。
6.2 收益
预计软件的开发时长在6个月，根据货币的时间价值以及投资回收期，可以评判出该工程的的价值是很可观的。
7 社会条件方面的可行性
7.1 法律方面的可行性
法律方面，该软件主体采用的是比较广泛的体系，且新增的疫情功能是创新性的添加，所以不存在侵权等一系列问题，本软件产品也没有存在违反法律的问题。
结论：
该软件经过可行性研究论证之后，认定该系统是可行的。

需求分析（需求规格说明书）
目录

1 引言 8
1.1 编写目的 8
1.2 背景 8
1.3 定义 9
1.4 参考材料 9
2 任务概述 9
2.1 目标 9
2.2 用户特点 9
2.3 假定和约束 9
3 需求规定 9
3.1 对功能的规定 9
3.2 对性能的规定 10
3.3 输入和输出的要求 10
3.4 数据管理能力的要求 10
3.5 故障处理要求 10
3.6 其他专门的要求 10
4 运行环境规定 10
4.1 设备 11
4.2 接口 11

1 引言
1.1 编写目的
该说明书是为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提条件，不论人们把设计和编码工作做得如何出色，不能满足用户需求的程序只会令用户失望，给开发者带来烦恼
1.2 背景
该项目开发的软件是火车票销售系统，鉴于当前人们出行流量大，但仍存在疫情中高风险地区，理应避免出行的矛盾状况构思出来的，该软件设计完成之后可用于全国人员的出行购票。通过网上的的购票环境减少人员因购票的聚集。也将购票过程规范化，便利化。
1.3 定义
静态数据----系统固化在内的描述系统实现功能的一部分数据
动态数据----在软件运行过程中用户输入后系统输出给用户的一部分数据，也就是系统要处理的数据。
数据字典----数据字典中的名字都是一些属性于内容的抽象和概括，他们的特点是数据的“严密性”和“精确性”，没有半点含糊性。
1.4 参考材料
《软件工程导论》 张海藩，牟永敏编著，清华大学出版社
2 任务概述
2.1 目标
软件需求分析阶段有以下几个目标：

1. 给出软件系统的数据流程图与数据结构，构造一个完全的系统逻辑模型
2. 提出详细的功能说明，确定设计限定条件，规定性能要求
3. 密切与用户的联系，使用户明确自己的任务，以便实现上述两项目标
   2.2 用户特点
   主要用户是火车站点，对业务逻辑较为熟悉，但对于编程不熟。
   2.3 假定和约束
   由于系统本身的大体实现并不难，且在Windows系统下开发，故在Windows环境下基本没有什么约束
   3 需求规定
   3.1 对功能的规定
   本系统的主要功能是用于销售火车票，主要的功能包括查询车票，订购车票以及退票，初次之外还应该有疫情时候特殊处理的系统。底层主要就是对数据库的增删改查。
   3.2 对性能的规定
    精度要求：由于采用数据库技术并且用户的应用领域对数据精确度并没有太高的要求，所以这点在系统中表现得比较少，但是对于用户得数据一定要保证正确性。
    时间特性要求：因为产品可能会处于高并发得状态，同时也存在着类似秒杀的场景，所以对响应时间的要求非常高
    灵活性：该软件是使用JDK８和Win10系统下完成的，而运行的环境主要是win7和win10，所以该软件的具有较好的灵活性。
   3.3 输入和输出的要求

3.4 数据管理能力的要求
涉及到的数据，多数为字符数据，同时采用数据库技术，则对数据管理能力不做出太高的要求，但是要确保用户在使用过程中不能存在信息泄漏的问题。同时也要确保数据在处理的时候的可靠性，而且要具有短时间处理大量数据的能力。
3.5 故障处理要求
由于该系统用于大范围的出行，所以对于故障的处理，理应迅速响应并解决，不能出现影响使用的状况。即故障一旦出现，就应该即刻解决。
3.6 其他专门的要求
对疫情模块的构建，需要能够准确的得出结果，对路径的选择算法要求严格。
4 运行环境规定
4.1 设备
运行在win10和win7操作系统的个人电脑之上
4.2 接口
软件中会涉及到大量的数据，并且需要较高的响应速度，所以对于接口要采用传输速率大的，同时也需要。

软件设计（软件设计说明书）
目录

1 引言 12
1.1 编写目的 12
1.2 项目背景 12
1.3 定义 12
1.4 参考材料 12
2 项目概述 12
2.1 工作内容 12
2.2 条件与限制 12
2.3 产品 12
2.4 服务 13
2.5 验收标准 13
3 实施计划 13
3.1 任务分解 13
3.2 进度 13
3.3 预算 13
3.4 关键问题 14
3.5 人员组织与分工 14
3.6 交付期限 14
4 具体实现 14
4.1 底层业务逻辑设计 14

1 引言
1.1 编写目的
该计划书的主要目的是确定应该怎样具体地实现所要求的系统，也就是说，经过这个阶段的设计工作，应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成某种程序设计语言书写的程序。
1.2 项目背景
该项目开发的软件是火车票销售系统，鉴于当前人们出行流量大，但仍存在疫情中高风险地区，理应避免出行的矛盾状况构思出来的，该软件设计完成之后可用于全国人员的出行购票。通过网上的的购票环境减少人员因购票的聚集。也将购票过程规范化，便利化。
1.3 定义
“软件计划书”是一份比较简短的文件，有关专门术语与缩略词省略。
1.4 参考材料
《软件工程导论》张海藩，牟永敏编著，清华大学出版社。
2 项目概述
2.1 工作内容
设计一个全国范围的火车票销售系统，可以合理规划人们的出行路线，尽量避免进出疫情中高风险地区。与此同时，书写好相关文档。搭建好整个架构。
2.2 条件与限制
由于本产品是在原有系统上进行创新和升级，所以所需要的技术和经济条件都已经具备，所以唯一的限制就是时间。
2.3 产品
1） 程序：
设计具有四个模块功能的订票系统，分别是订票、查询、退票以及疫情特别功能。
2） 文档：
与软件一同交付的文档，包括但不仅限于软件的说明书。
2.4 服务
开发单位可向用户提供包括人员培训在内的一系列有关服务，但鉴于本系统简单，只要由一点Windows操作经验的人员就可以使用，故省去培训的服务，另外开发单位还为该软件的用户提供安装、保修，以及系统的免费维护等等以及其他一些运行支持。
2.5 验收标准
软件的验收标准完全由用户提出的软件需求制定，能保证软件的基本符合用户的要求。
3 实施计划
3.1 任务分解
鉴于该系统的功能简单，先将四个功能分解开来，依次完成，最后在整合在一块，并进行相关的优化。
3.2 进度
对于该系统，具体开发进度如下：

项目开始 项目结束
3.3 预算
目前软件资金投入较少，具体预算分配省略。
3.4 关键问题
使用目前的设备与现有技术完全可以开发出该系统，但是创新性的疫情模块则需要更大的精力，同时，为了可以支持全国范围的使用，且响应速度和数据的准确性的保证都是需要重点解决的问题。也是该系统的技术难点。
3.5 人员组织与分工
鉴于当前人员的数量，我们采用一人领导他人辅助的策略，然后逐一模块进行工作，最后再一起整合。而高并发以及创新模块的添加，都要求领导者需要较高的技术以及管理能力。
3.6 交付期限
所有开发工作用户要求要在6个月内完成。
4 具体实现
4.1 底层业务逻辑设计

4. 退票系统

软件测试（黑盒白盒测试技术实践）
目录

1 引言 19
1.1 编写目的 19
1.2 项目背景 19
1.3 定义 19
1.4 参考材料 19
2 任务概述 19
2.1 目标 20
2.2 测试环境 20
3 计划 20
3.1 测试方案 20
3.2 测试项目 20
4 测试分析 20
4.1 计划执行情况 20
4.2 评价 20

1 引言
1.1 编写目的
表面看来，软件测试的目的是与软件工程所有阶段的目的相反，软件工程的其他阶段都是“建设性”的：软件工程师力图从抽象的概念出发，逐步设计出具体的软件系统，知道用一种适当的程序设计语言写出可以执行的程序代码。但是在测试阶段测试人员努力设计一系列测试方案，目的确实为了“破坏”已经建造好的软件系统——竭力证明程序中由错误，不能按照预定要求正确工作。
当然，这种反常仅仅是表面的，或者说是心理上的。暴露问题并不是软件测试的最终目的，发现问题是为了解决问题。
1.2 项目背景
该项目开发的软件是火车票销售系统，鉴于当前人们出行流量大，但仍存在疫情中高风险地区，理应避免出行的矛盾状况构思出来的，该软件设计完成之后可用于全国人员的出行购票。通过网上的的购票环境减少人员因购票的聚集。也将购票过程规范化，便利化
1.3 定义
白盒测试----又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，即清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。
黑盒测试----黑盒测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
1.4 参考材料
《软件工程导论》张海藩，牟永敏编著，清华大学出版社
2 任务概述
2.1 目标
检测该软件系统订票模块、查询系统、退票系统和疫情模块是否可以在正常情况和一些极端情况下是否会出现问题，如果出现问题，应及时解决。
2.2 测试环境
在win10以win7系统上进行测试。
3 计划
3.1 测试方案
先检测整个测试逻辑上是否可以运行，我们采用逻辑覆盖的手段进行测试，对于重点代码，应该多次测试，以确保逻辑结构没有问题，然后，在进行黑盒测试，对于每一部分功能模块，我们采用不同的数据来进行测试，与此同时，在整体运行过程中，我们也要对系统是否可以承担高访问量的测试。
3.2 测试项目
 订票功能：检测是否会出现重复付款，检测是否会出现车票重复订购等
 查询功能：检测是否会出现信息错误的情况等
 退票功能：检测是否会出现退款异常的问题等
 疫情功能：检测算法结果是否是最优解等
4 测试分析
4.1 计划执行情况
测试结果均在可接受范围之内，但是高并发的效果还是需要提高
4.2 评价
测试通过，但仍需要进一步的提升，以提高用户的使用体验。