软件开发的详细流程 文档在线提供Word下载.docx
《软件开发的详细流程 文档在线提供Word下载.docx》由会员分享，可在线阅读，更多相关《软件开发的详细流程 文档在线提供Word下载.docx（19页珍藏版）》请在冰豆网上搜索。
软件需求规格说明的书写原则
任务概述：
软硬件环境、条件和限制（软件的使用条件和限制）。
数据描述：
输入数据、输出数据、数据库设计和建立数据词典。
功能需求：
功能划分和功能描述
性能需求：
数据精度、时间特性、适应性（操作方式、与其他软件的接口、开发计划变化时，软件应具有的适应能力。
）。
运行要求：
用户界面、硬件接口（如：
连接打印机）、软件接口（如：
是否为其他项目的子项目）、故障处理。
其他需求：
可使用性、安全保密性、可维护性、可移植性等。
●模板参考
第一页：
教务管理软件文档编号001
版本号Ver1.0
需求规格说明书
课表编排系统
屈艳
编写：
刘楠、叶艺、赵春、马燕时间：
2005-2-14
审核：
屈艳时间：
2005-2-16
批准：
王湘桃时间：
2005-2-20
开发单位：
冰雪五人组
第二页之后的内容：
编写目的：
编写该文档是为了分析人工状态下课表编排的工作流程，把人工模式抽象为可在计算机上处理的自动模式。
便于开发小组成员对系统整体功能的认识。
项目背景：
高校的课表编排一直是一个烦琐的工作，为了解决这个问题，某某高校教务处委托我们开发该软件。
该软件是高校教务软件的一个子系统。
该子系统与专业规划子系统和教师管理软件有一定的关系。
参考资料：
1．郑人杰实用软件工程（第二版）北京：
清华大学出版社，1997
硬件环境：
CPU的型号为PentiumIII以上，内存256M，及其兼容机
软件环境：
Win98/2000/xp、VB/VC/VF/DeLphi等。
软件的使用条件和限制：
教室的数量能满足排课的需求；
一个教师只能代两门课；
修改课表有安全级别。
用户提供的资料：
计划书和教师、教室情况
用户对软件的要求：
输入计划书，系统自动按班级排课表，并可查询打印课表。
静态数据：
教室信息（编号、名称、类型（普通/多媒体）、规模等）。
动态数据：
计划书（课程名称，专业年级，人数，学时，讲课（周次），实验周次，教师姓名，对教室的要求等。
）、教师信息（编号、姓名、学院、职称）
数据流图：
数据流图的图符含义为：
圆圈表示加工，矩形框表示结果，箭头表示数据流向。
课表编排系统的数据流图如下：
计划书中的数据有：
学生所在学院、专业年级、班级、人数、课程名称、总学时、周学时、周次、教师姓名、教室类型等信息。
教室数据有：
教室编号、教室类型、教室的规模（60人/90人）、周一到周五各个时间段的使用情况等信息
一级课表数据有：
专业年级、班级、周一至周五每天五个时间段（12节，34节，56节，78节，90节）、课程名称、教室编号、教师姓名、课程起始周次或间断的周次。
注：
对计划书中的数据和教室数据的加工处理，形成一级课表所需要的数据。
计划
教室信息
约束信息
信息课表冲突
一级课表
二级课表
数据库描述及数据词典：
班级表banji
字段名称
字段类型
字段大小
班级编号
文本
6
班级
2
年级
4
所属学院
20
所属专业
教室表jiaoshi
编号
自动编号
递增
名称
30
类型
规模
星期
1
节12
节34
节56
节78
节90
课程表kecheng
课程编号
8
课程名称
所属年级
计划表jihua
学生人数
总学时
周学时
周次
教师姓名
教室类型
课程类型
优先级
临时表linshi
教室
任教老师
16
节次
临时表linshi2
输出结果表result
周一
50
周二
周三
周四
周五
周六
功能划分：
基本信息输入模块、计划书信息输入模块、课表自动生成模块、备份删除数据模块。
功能描述：
基本信息输入模块的功能：
建立良好的用户输入界面，输入基本信息（教师信息和教室信息）。
计划信息输入模块的功能：
输入计划书中的信息。
课表自动生成模块的功能：
根据输入的基本信息，自动生成一级课表。
（具体算法在详细设计中查询）。
备份删除数据模块的功能：
课表编排系统将在多学期使用，一个学期结束后，应备份数据，并将旧数据删除，产生新的课表数据。
数据精确度：
整数
时间特性：
无特殊要求
适应性：
有一定的适应能力，可将数据导入导出。
运行需求：
用户界面：
简单
硬件接口：
标准接口（打印机接口）
软件接口：
无，该软件暂时独立使用。
故障处理：
重新安装该软件。
可使用性：
良好
安全保密性：
有安全保密性。
课表编排必须由教务管理人员进行，课表修改要设定权限。
可维护性：
可以进行简单的维护，
可移植性：
适用于各种操作系统。
实习二软件详细设计
对本书第四章的内容做进一步的掌握，写出软件详细设计说明书。
二、实习内容
确定软件的总体结构，设计每个模块的细节。
总体设计：
画软件系统的结构图
程序描述：
每个模块给出以下说明
功能、性能、输入项目、输出项目、算法、限制条件、测试要点（模块的主要测试要求）。
三、实习指导
提交文档的格式如下：
教务管理软件文档编号002
软件详细设计说明书
叶艺、赵春、马燕、刘楠时间：
2005-3-14
2005-3-16
2005-3-20
编写详细设计是为了上程序员在写程序时有一个依据。
程序员根据详细设计写出符合设计要求的程序。
详细设计的设计思路由教务管理科的管理人员提供，经过设计人员的加工处理，形成可在计算机上实现的算法。
开始
do
输入信息
保存信息
是否继续输入？
Y
N
结束
课表编排系统的总体结构图：
主界面
基本信息录入模块
备份删除数据模块
计划信息录入模块
自动排课打印模块
基本信息输入模块：
功能：
完成基本信息的输入，并将信息保存在数据库中，供自动排课模块使用。
基本信息有（教师信息，教室信息）。
输入项：
有9项，具体项目见测试用例列表。
输出项：
有9项，同上。
算法：
（可以用程序流程图或算法语言）见右上程序流程图
测试用例：
教师信息：
姓名
性别
年龄
职称
承担课程
研究方向
李红
女
讲师
软件工程
教室信息：
12
34
56
78
90
信M1
多媒体
90人
1-5
空
信M2
信M3
60人
3106
普通
3117
3118
计划信息录入模块：
完成计划书的信息输入，并保存在数据库中，供自动排课模块使用。
有9项，具体见测试用例。
算法同基本信息输入模块。
计划书信息
学生学院
专业年级
人数
课程名
教师名
信息学院
计算机02
1-3
编译原理
60
李长悦
王湘桃
自动排课模块：
该模块根据计划书信息，完成各个班级的一级课表的编排。
从计划书信息库和教室信息库中获的信息。
班级的课表
DO1
在计划书数据库取一条信息（某个专业年级，班级）
DO2
在教室数据库取一个教室信息
if教室类型满足then
if教室规模满足then
if教室空且时间合适then
占用教室
exitDO2
endif
endif
LOOPUNTILEOF（教室信息库）
LOOPUNTILEOF（计划书）
如果某个计划书不能找到合适的教室，则该计划书转入手动排课。
信息学院02级计算机1-3班的计划书为例。
教室为信息学院的专业教室。
备份删除数据模块：
（省略）
实验三原型软件设计
我们对系统进行一次分析，不可能很清楚的完成软件的需求规格说明书，我们通常是先对系统进行简单的需求分析之后，设计一个原型软件。
原型软件是一个看起来像真软件，具有真软件的简单功能，但不具有真软件的强大的功能。
客户通过使用原型软件可以很容易发现未来的软件包是否满足需要、或者还应作什么修改。
对原型软件不断的修该，使它成为一个真正意义上的软件。
1、题目：
原型软件设计
2、要求：
设计原型软件的界面和主要功能模块。
3、完成形式：
进行简单的输入，软件可以运行。
1、高级程序设计语言的选择
2、编写主界面程序代码（按照实验二的详细设计说明书进行代码编写）。
3、编写主要功能程序代码（按照实验二的详细设计说明书进行代码编写）。
4、对编写好的程序进行测试（使用实验二提供的测试用例测试程序）。
实验四软件测试用例设计和测试
对软件进行测试是为了得到安全可靠的软件产品。
软件测试常用的方法有两个：
白盒法和黑盒法。
不论是白盒法还是黑盒法都不能完全找到软件的错误（bug），所以要设计软件的测试用例，希望尽可能多的发现软件中存在的错误。
对实习三设计的软件进行测试
选择两个软件单元，一个用白盒法进行测试，一个用黑盒法进行测试。
写出测试用例及测试结果。
对测试结果进行分析，评价软件的可靠程度。
1、对所选择的白盒法测试软件单元进行逻辑分析，画出逻辑流程图。
2、根据逻辑流程图设计测试用例。
记录测试结果，并对测试结果进行分析。
3、确定黑盒法测试的软件单元。
4、设计黑盒法的测试用例。
教务管理软件文档编号003
测试用例的设计
赵春、马燕、刘楠、叶艺时间：
2005-4-14
2005-4-16
2005-4-20
为了在测试软件的过程中思路清晰，测试的目标明确。
该测试计划供测试人员使用。
要测试的程序模块名：
教室信息输入模块和自动排课模块。
测试用例1：
教室信息输入模块的测试用例：
另外：
对运行程序的过程中，程序提出的问题：
是否继续输入，回答一次Yes，回答一次No。
测试结果：
数据库中的信息与用户输入的信息一致。
软件评价：
该模块运行正确。
测试用例2：
自动排课模块的测试用例：
以信息学院计算机02级1-3班的计划书为例。
运行自动排课模块。
网络
韩宏
接口技术
54
黄道君
通讯原理
40
刘晴蕊
Linux
鱼晓
数学建模
边宽江
图形学
宁纪锋
对程序过程中的判定语句进行单独测试。
判定的真假各测试一次。
对不能排课的计划书转入手动排课系统（即手工调整课表）。
形成一张计算机02级1-3班的课表。
基本完成设计要求。
实验五软件提交与维护
软件开发成功后，将交付用户使用，在用户使用前，要对用户进行培训。
并要求写出详细的使用说明书和维护手册，待后续修改和维护。
否则，软件的使用将受到限制，软件寿命将缩短，成本会增高。
对开发该软件的所有资料进行整理
从软件需求分析规格说明书到使用说明书的所有资料进行收集和整理。
将所有文档编辑成册。
1、根据用户的要求写出软件的使用说明书
2、根据开发的限制条件，写出软件的维护手册
系统说明：
系统具备的功能，输入和输出。
操作环境：
系统的设备配置及其特性。
列出系统使用的所有支持软件（名称和版本号）。
维护过程：
约定（所有标识和助记符的使用规则）。
列出出错状态和纠正方法。
修改错误，并详细描述修改。
附录1：
1.问：
在软件工程中文档为什么重要，内文档和外文档各起什么作用。
各有什么特点？
答：
内文档写在文件（例如一个源代码文件）内，故要精简，外文档是专门用来组织软件的，故应详细。
但二者都必须有文件名称、作者及联系方式等最起码信息。
如：
软件需求规格说明书为外文档。
2.问：
为什么要注意文档形式？
首先软件文档是技术文件，读起来本来就费劲，如果再五号字密密麻麻地挤在一起，看起来容易使人疲劳，所以软件使用说明书现在都很注意形式，如加大字号、注意采用缩进、变换字体、突现重点。
插入图、表、曲线等以增加可读性。
3.问：
软件开发中首先遇到的困难是什么？
软件开发中的最大错误是什么？
答：
软件开发中首先遇到的困难是理解所遇到的问题！
客户清楚地知道他让你做什么吗?
回答一般是No.你能一上来就清楚地知道客户叫你做什么吗，回答一般也是No.软件开发中的最大错误是没有弄清客户的需求，从而造成开发的软件功能不能满足客户所需，造成大浪费、大返工这是软件开发中的最大错误。
4.问：
如何防止开发的软件不能满足客户所需这种情况发生？
和客户讨论，初步明确客户叫你做什么。
先写一个原型软件（只是在界面上看起来像真软件，具有真软件的简单功能），请客户看看，使大家对要开发什么样的软件有共识。
5.问：
可以把原型软件扔掉从新开发吗？
可以，原型软件即可以改进发展成为真软件，也可以把它仅作为参考重新开发出真软件。
6.问：
应该怎么写原型软件呢？
首先必须明白软件是写给谁的，谁说好算好。
软件是写给客户和使用者的，客户的满意是判断软件好坏的最重要标准。
动手之前要充分征求客户和使用者的意见、把客户和使用者的意见分析归纳上升、再征求客户和使用者的意见，再动手，反复多次，争取原型软件一次基本成功。
7.问：
如何根据客户和使用者的要求写原型软件呢？
一般说他们的意见是感性的、模糊的、散乱的。
不可能叫客户提出界面应怎么写。
软件工程人员应把客户和使用者的要求进行分析、抽象、归纳整理成文，经客户确认。
据此开发原型软件。
8.问：
如何缩短工期？
工程中的并行活动愈多，同一工程量的工程所需的工期就愈短。
缩短工期的方法就是把串行活动改造成并行活动。
例如A、B、C是串行活动，如果先确定了A与B，B与C的接口关系，A、B、C就由串行活动变成并行活动。
9.问：
工程管理应特别注意什么？
。
每一工程活动必须有明确的结束标志，不然没法进行工程管理，这是要特别注意的地方。
10.问：
一个工程活动的工期如何确定？
它由过去的经验判断得到。
如无经验，也可先作几个典型的活动得到有关数据。
再估算各个工程活动的工期，这是构造工程图的基础。
11.问：
如果我们第一周找出了20个错误、第二周找出了16个错误、第三周找出了10个错误、第四周找出了3个错误、第五周找出了8个错误、第六周找出了2个错误、第七周找出了0个错误，我们是否确实找完了全部的错误。
很难肯定，因为我们不知道软件中原来有多少错误，
12.问：
如何测估软件中的错误个数。
测估软件中的错误个数方法之一是下种方法。
如果另一组人给软件包制造（种下）了100个错误，经过一段时间的工作测试组发现了其中的50个，还发现了不是种下去的错误80个（即软件包原来就有的错误），请回答在测试开始前软件包原有错误为个。
测估软件中的错误个数方法之二是双组测试法。
如果测试组A发现了100个错误，而测试组B发现了80个错误，其中50个是共同的，请估算在测试开始前软件包原有错误为个。
提示：
以上估算都用到了等探测几率的假定，即一个测试组在一个测试阶段对错误，不论是在软件包开发时造成的还是后来人为造成的，探测几率都一样。
由此知在上述二例中，软件包原有的错误都是约有160个。
13.问：
假定有一个软件包经上述方法测估，有160个错误，经过一段测试发现了158个错误，是否就一定还有二个错误。
不那么肯定。
我们只能说错误基本发现完了，因为上面讲的方法测估的结果是大致的而不是严格的，有一定的统计误差。
再问：
还有一个软件包经上述方法测估，有140个错误，经过一段测试发现了140个错误，是否就一定没有任何错误了？
同样不那么肯定。
14.问：
软件可信度如何测估？
根据当前种下的S个错误全发现，而没有发现别的错误，软件的可信度C=S/（S+1）这一论断。
如果给一个软件包种下了S=9个错误，经过一段测试，找出了全部9个错误而没有发现别的错误，该软件包的可信度C=0.9。
同样为了证明软件包的可信度C=0.95,应给该软件包种下S=20个错误，经过一段测试，
升级会员 