软件工程课程设计之过程Word文档格式.docx
《软件工程课程设计之过程Word文档格式.docx》由会员分享，可在线阅读，更多相关《软件工程课程设计之过程Word文档格式.docx（14页珍藏版）》请在冰点文库上搜索。
2.7软件维护11
2.7.1定义11
2.7.2维护特点11
2.7.3维护策略12
第三章辅助工具12
参考文献14
心得15
引言
软件工程过程是将用户需求转化为软件所需的软件工程活动的总集。
这个过程可能包括投入、需求分析、规格说明、设计、实施、验证、安装、使用支撑和文档化，还可能包括短长期的修复和升级以满足用户增长的需求。
因为维护没有被普遍接受，所以在这里没有包括进来。
在美国国防部（DoD）维护包括软件修复和升级，而在商业计算机领域它是指提供服务、修复软件缺陷但不包括升级。
关键字：
需求分析规格说明文档化软件修复
第一章软件过程的概述
1.1定义
ISO9000定义：
软件工程过程是把输入转化为输出的一组彼此相关的资源和活动。
1.2两个方面内涵
第一，软件工程过程是指为获得软件产品，在软件工具支持下由软件工程师完成的一些列软件工程活动。
基于这个方面，软件工程过程通常包含4种基本活动：
1.plan——软件规格说明。
规定软件的功能及其运行时的限制。
2.do——软件开发。
产生满足规格说明的软件。
3.check——软件确认。
确认软件能够满足客户提出的要求。
4.action——软件眼睛。
为满足客户的变更要求，软件必须在使用的过程中演进。
事实上，软件工程过程是一个软件开发机构针对某类软件产品为自己规定的工作步骤，它应当是科学的、合理的，否则必将影响软件产品的质量。
第二，从软件开发的观点看，它就是使用适当的资源（包括人员、硬软件工具、时间等），为开发软件进行的一组开发活动，在过程结束时将输入（用户要求）转化为输出（软件产品）。
所以，软件工程的过程是将软件工程的方法和工具综合起来，以达到合理、及时地进行计算机软件开发的目的。
软件工程过程应确定方法使用的顺序、要求交付的文档资料、为保证质量和适应变化所需要的管理、软件开发各个阶段完成的任务。
1.3三大类
基本过程类:
是构成软件生存周期主要部分的那些过程,包括获取,供应,开发,操作,维护等过程。
支持过程类:
可穿插到基本过程中提供支持的一系列过程,包括文档开发,配置管理,质量保证,验证,确认,联合评审,审计,问题解决等过程。
组织过程类:
一个组织用来建立,实施一种基础结构,并不断改进该基础结构的过程,包括管理,基础,改进,培训等过程。
第二章软件生命周期及过程
2.1问题的定义
此阶段必须回答的关键问题是：
“要解决什么样的问题？
”如不知道问题是什么就是图解决这个问题，显然是盲目的，只会白白浪费金钱，最终得到的结果可能是毫无意义的。
尽管确切地定义问题的必要性是十分明显的，但是在实践中可能是最容易被忽视的步骤。
通过调研，系统分析员应该提出关于问题性质、工程目标和工程规模的书面报告，并且需要得到用户对这份报告的确认。
2.2可行性研究过程
1.复查系统规模和目标
分析员访问关键的人员，认真解读分析资料，对问题定义方面的书面报告进行复查，改正含糊或不明确的叙述，清楚地描述对目标系统的所有限制和约束。
这实质上是为了确保分析员正在解决的问题确实是要求解决的问题。
2.研究目前正在使用的系统
现有的系统是信息的重要来源。
仔细阅读分析现有的系统文档资料和使用手册，也要实地考察现有的系统。
要知道没有一个系统是在“真空”中运行的，绝大多数系统都和其他系统有联系。
3.导出新系统的高层逻辑模型
通过前一步的工作，分析员对目标系统应具有的基本功能和所受的约束已有一定了解，能够使用数据流图，描绘数据在系统中的流动和处理的情况，从而概括的表达他对新系统的设想。
应有一个初步的数据字典，它和数据流图共同定义了新系统的逻辑模型，从这个模型可在后期设计出新系统。
4.进一步定义问题
分析员定义问题，分析这个问题，导出一个试探性的解；
在此基础上再次定义问题，再一次分析这个问题，修改这个解。
5.导出和评价供选择的解法
导出供选择的解法的最简单的途径，是从技术角度出发考虑解决问题的不同方案。
6.推荐行动方针
根据可行性研究结果应该做出的一个关键性决定是，是否继续进行这项开发工程。
7.草拟开发计划
分析员应该进一步为推荐的系统草拟一份开发计划，最后给出下一个阶段的详细进度表盒成本估计。
8.书写文档提交审查
应该把可行性研究的上述各个步骤的工作结果写成清晰的文档，请用户和使用部门的负责人仔细审查，以决定是否继续这项工程以及是否接受分析员的推荐方案。
2.3需求分析
1.确定对软件系统的综合要求（四个方面）
（1）、系统功能要求
应该划分出系统必须完成的所有功能。
（2）、系统性能
联机系统的响应时间，系统需要的存储容量以及后援存储，重新启动和安全性等方面的考虑都属于性能要求。
（3）、运行要求
集中表现为对系统运行时所处环境的要求。
（4）、将来可能提出的要求
明确的列出哪些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出的要求。
2.确定对系统的数据要求
软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌。
复杂的数据由很多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。
3.导出系统的逻辑模型
通常用数据流图，数据字典和主要的处理算法描述这个逻辑模型。
4.修正系统开发计划
根据在需求分析过程中获得的对软件系统更深入、更具体的认识，可以较准确的估计出系统的成本和进度，从而可以修正在前一个阶段所制定的开发计划。
5.开发原型系统
为使得通过实践获得关于未来的系统将怎样为他们工作的更直接更具体的概念，从而可以更准确的提出和确定他们对所开发的软件的要求。
2.3.2过程步骤
1.沿数据流图回溯
通常把分析过程中得到的有关数据元素的信息记录在数据字典中，把对算法的简明描述记录在IPO中。
通过分析儿补充的数据流、数据存储和处理，应该添加到适当的位置上。
2.请用户复查
用户对前一个分析步骤中得出的结果进行复查，复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。
3.细化数据流图
为了追踪更详细的数据流，分析员应该把数据流图扩展到更低的层次。
随着分析过程的进展，经过发现问题和解答问题的反复循环，分析员具体的定义了目标系统，最终得到对系统数据和供能需求的满意了解。
4.修正开发计划
经过需求分析阶段的工作，对目标系统有了更深入更具体的认识，在此基础上应该对开发计划进行修正。
5.书写文档
系统规格说明，主要描述目标系统的概貌、功能要求、性能要求、运行要求和将来可能提出的要求。
数据要求，包括数据字典以及描绘数据结构的层次方框图和Warnier图还有存储信息分析的结果。
6.审查和复查
分析过程的最后一步是按照需求分析阶段的结束标准，对本阶段的工作成果进行正式的技术审查和管理复查。
2.3.3与用户沟通方法
1.访谈
（1）、在某种程度上演示产品的行为，从而便于用户理解，同时进一步揭示一些分析员目前还不知道的需求。
（2）、由于情景分析便于用户理解，所以使用这种技术可以保证用户早需求分析中始终扮演一个积极主动的角色。
2.简易的应用规格说明技术
（1）、引言
A.编写目的
说明编写这份文档的目的，指出预期的读者。
B.背景
知名项目的委托单位，开发单位，主管部门和用户，说明所开发的软件系统与其他系统的关系。
C.定义
看出本文档中使用的专门术语的定义和缩写词的含义。
D.参考资料
列出与本项目，特别是与本文档有关的参考资料，应该列出这些参考资料的标题，文件编号，发表日期和出版单位，说明可得到这些资料的来源。
（2）、任务概述
A.目标
叙述该项软甲开发的意图，应该目标，作用范围以及与其他相关软件之间的关系。
B.用户特点
列出本软件的最终用户的特点，详细说明操作人员与维护人员的学历和技术专长，以及本软件的语气使用频度。
C.假定和约束
列出从事本软件开发工作的家丁和约束。
（3）、数据的逻辑描述
A.静态数据
在运行过程中主要作为参考的数据，他们在很长一段时间内不变化。
B.动态数据
在运行过程中药发生变化的所有数据，以及在运行中药输入或输出的数据。
C.数据库
说明本软件所使用的数据库的名称和类型。
D.数据字典
用数据字典定义本软件的数据。
E.数据采集
数据采集的要求和范围，指明采集数据的方法，说明数据采集工作的承担者，列出对数据采集和预处理过程的专门规定。
（4）、功能需求
A.功能分解
描述本软件应该具有每一个具体功能，用适当形式描述软件的整体结构及软件功能与其他系统元素的关系。
C.功能描述
描述对本软件所提出的功能要求，说明输入什么量、经过怎样的处理过程，得到什么结果。
（5）、性能需求
A.精度
说明对本软件的输入，输出数据精度的要求，必要时对还应说明对传输过程中精度的要求。
B.时间特征
说明对本软件的时间特性的要求。
C.灵活性
说明对本软件的灵活性的要求。
（6）、运行环境需求
A.设备
描述本软件所需的硬件设备。
B.支持软件
列出本软件的支撑软件，包括操作系统，编程等。
C.用户界面
说明需要的屏幕格式，报表格式，菜单格式，输入输出时间等。
D.硬件接口
说明本软件与硬件间的接口，数据通信的协议等。
E.软件接口
本软件与其他软件飞接口，数据通信协议。
（7）、其他专门需求
列出对安全保密、使用方便性、可维护性、可靠性、可维护性等方面的要求。
（8）、将来可能提出的需求
A.功能扩充
预期将来可能要求的增加功能。
B.性能提高
预期将来可能需要添加的性能要求。
C.其他需求
预期将来可能出现的其他要求。
（9）、确认标准
A）性能范围
列出用户可以接受的性能变化范围。
B）测试种类
为了确认本软件的功能，性能和约束符合用户需求，应该进行的测试类型。
C）预期的软件响应
预期本软件对每类测试的响应。
2.4软件设计
2.4.1概要设计
概要设计也称为总体设计和初步设计，这个设计阶段主要有两项任务。
（1）、设计现实软件的最佳方案
首先设想实现目标系统的各种可能的方案，然后分析员从设想出的这些供选择的方案中选择若干个合理方案。
最后分析员应该综合分析对比各种合理方案的利弊，从中选出一个最佳方案。
（2）、设计软件体系结构
此阶段确定软件系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系。
2.4.2详细设计
详细设计的根本目标是确定怎样具体的实现所要求的软件系统。
具体的说，详细设计主要有以下三项任务：
（1）、过程设计，即设计软件系统结构中所包含的每个模块的现实算法；
（2）、数据设计，即设计软件需要的数据结构；
（3）、接口设计，即设计软件内部各模块之间、软件与协作系统之间及软件与使用它的人之间的通信方式。
2.5编码
2.5.1选择适当的程序设计语言
（1）、系统用户的要求
如果所开发的系统由用户负责维护，用户通常要求用他们熟悉的语言书写程序。
（2）、可以使用的编译程序
运行目标系统的环境中可以提供的编译程序往往限制了可以选用的语言范围。
（3）、可以得到的软件工具
如果某种语言有支持程序开发的软件可以利用，则目标系统的实现和验证都变得比较容易。
（4）、工程规模
如果工程规模很庞大，现在的语言又不完全使用。
那么设计并实现一种供这个工程项目专用的程序设计语言，可能是一个真确的选择。
（5）、程序员的知识
虽然对于有经验的程序员来说，学习一种新语言并不困难，但是要完全掌握一种新语言却需要实践。
（6）、软件可移植性要求
（7）、软件的应用领域
2.5.2正确的编码风格
（1）、程序内部需要正确的文档
（2）、数据说明应便于查阅易于理解
（3）、语句应该尽量简单清晰
A.不要为了节省空间而把多个语句写在同一行；
B.尽量避免复杂的程序测试；
C.尽量减少对“非”条件的测试；
D.避免大量使用循环嵌套和条件嵌套；
E.利用括号逻辑表达或算术表达式的运算次序清晰直观。
（4）、正确的输入/输出风格
A.对所有输入数据都进行检验；
B.检查输入项重要组合的合法性；
C.保持输入格式简单；
D.使用数据结束标记，不要要求用户指定数据的数目；
E.明确提示交互式输入的请求；
F.当程序设计语言对格式有严格废要求时，应保持输入格式一致；
G.设计良好的输出报表；
H.给所有输出数据加标志。
（5）、不要盲目追求高效率
A.程序运行时间
B.储存器效率
C.输入/输出的效率
2.6测试
按照软件测试用例的设计方法而论，软件测试可以分为白盒测试法和黑盒测试法。
2.6.1黑盒测试
若测试规划是基于产品的功能，目的是检查程序各个功能是否能够实现，并检查其中的功能错误，则这种测试方法称为黑盒测试（Black-boxTesting）方法。
黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。
它是一种从用户观点出发的测试，一般被用来确认软件功能的正确性和可操作性。
黑盒测试主要根据规格说明书设计测试用例，并不涉及程序内部构造和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。
黑盒测试的特点
黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以使用。
黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。
若测试规划基于产品的内部结构进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分使用，则这种测试方法称为白盒测试（White-boxTesting）方法。
2.6.2白盒测试
白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试，一般用来分析程序的内部结构。
白盒测试要求是对某些程序的结构特性做到一定程度的覆盖，或者说这种测试是“基于覆盖率的测试”。
通常的程序结构覆盖有：
语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，路径覆盖。
2.6.3单元测试、集成测试、系统测试、验证测试和确认测试
按照软件测试的策略和过程来分类，软件测试可分为单元测试、集成测试、系统测试、验证测试和确认测试。
测试中的错误分类：
A类错误：
致命错误——引起程序异常中断或死机的错误等。
B类错误：
功能错误——业务功能实现错误、程序执行结果错误等。
C类错误：
功能缺陷——功能操作不方便、缺少操作提示等。
D类错误：
界面缺陷——界面设计不符合本系统的界面设计规范等。
E类错误：
测试正确——正确的测试项、测试结果与预期的一致等。
2.7软件维护
2.7.1定义
所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
。
我们可以通过描述软件交付使用后可能进行的下述四项活动，具体地定义软件维护。
2.7.2维护特点
（1）、改正性维护
通常，在软件开发过程中所进行的测试都是不完全、不彻底，其中必然会有一些潜伏的错误被带到运行阶段来。
这些潜伏的错误在某些特定的使用条件下就会暴露出来，用户将把问题报告给维护人员，要求解决。
我们把诊断性软件和改正软件错误的过程称为改正性维护。
（2）、适应性维护
计算机经常推出新的操作系统或旧系统的修改版本，时常增加或修改外部设备和其他系统部件；
另一方面，应用软件的使用寿命很容易超过十年，远远长于最初开发这个软件时的运行环境的寿命。
因此，适应性维护，，也就是为了和变化了的环境配合而进行的修改软件的活动。
（3）、完善性维护
在使用软件的过程中，用户往往提出增加新功能或改变某些已有功能的要求，为了满足这类要求而修改软件的活动，称为完善性维护。
（4）、预防性维护
当为了提高未来的可维护或可靠性，为了给未来的改进工作奠定更好的基础而修改软件时，就出现了预防性维护。
预防性维护的定义为“把今天的方法学应用于昨天的系统以满足明天的需要”。
2.7.3维护策略
（1）、降低改正性维护成本的策略
软件包含的错误越少，改正性维护的成本就越低，但是，要生成100%可靠地软件通常成本太高，并不一定合算。
通过使用先进技术仍然可以大大提高软件的可靠性，从而减少改正性维护的需求。
下面列出可提高软件可靠性的主要技术。
A.用数据库管理系统替代文件系统来存储需长期保存的信息；
B.用软件开发环境或程序自动生成系统来开发或自动生成程序；
C.用更高级的语言编写程序；
D.只要可能就用购买应用软件包的办法代替自己开发应用软件的办法；
E.使用结构化技术或面向对象技术，可以开发出更容易理解和测试的软件；
F.采用防错程序设计技术，把自检能力引入程序。
（2）、降低适应性维护成本的策略
这类维护是必然要进行的，但是采取适当的策略仍然能降低这类维护的需求。
A.在进行配置管理时，把硬件、操作系统和其他相关的环境因素的可能变化考虑在内，可以减少，某些适应性维护的工作量；
B.把与硬件、操作系统及其他外围设备有关的代码放到特定的程序的程序模式中，可以把因环境变化而修改的程序代码局限于某些特定的程序模块内；
C.使用内部程序列表、外部文件及例行处理程序包，可以为维护时修改程序提供方便。
（3）、降低完善性维护成本的策略
上述的减少前两类维护成本的策略，通常也能降低完善性维护的成本特别是数据库管理系统、程序自动生成系统、软件开发环境、第四代语言和应用软件包，可明显减少维护工作量。
此外在需求分析过程中准确地预测将来可能提出的需求，并且在设计时为将来可能提出的需求预先做准备，显然是降低完善性维护成本的有力措施。
第三章辅助工具
在进行软件开发的过程中，单纯的利用集成开发环境往往不够充分，而若能利用一些辅助软件则可以极大地方便软件的开发，提高开发的效率和质量。
下面列举几个辅助软件。
1、代码编辑工具--UltraEdit：
UltraEdit是能够满足你一切编辑需要的编辑器。
UltraEdit是一套功能强大的文本编辑器，可以编辑文本、十六进制、ASCII码，可以取代记事本，内建英文单字检查、C++及VB指令突显，可同时编辑多个文件，而且即使开启很大的文件速度也不会慢。
软件附有HTML标签颜色显示、搜寻替换以及无限制的还原功能，一般大家喜欢用其来修改EXE或DLL文件。
2、代码阅读工具--SourceInsight：
代码阅读工具SourceInsight，它的使用非常简单：
先选择Project菜单下的new，新建一个工程，输入工程名，接着把欲读的源代码加入（可以整个目录加），该软件会自动分析我们添加的源代码。
3、代码静态检查工具--PC-Lint：
PC-Lint是一种静态代码检测工具，它可以检查出那些虽然完全合乎语法要求，但很可能存在潜在的、不易发现的错误；
PC-lint可以在检查当前文件的同时检查所有与之相关的文件，从而从整个项目的角度来检测问题；
PC-lint支持几乎所有流行的编辑环境和编译器，比如BorlandC++、GCC、VC，VC.net、Sourceinsight等等，支持16/32/64的平台环境；
PC-lint支持ScottMeyes的名著（EffectiveC++/MoreEffectiveC++）中说描述的各种提高效率和防止错误的方法。
4、版本控制工具--CVS：
当一个团队进行软件开发时（甚至个人软件开发），我们需要进行版本控制，应用最广泛的版本控制软件是开放源代码的CVS。
CVS有UNIX和Windows版本的，本文仅介绍Windows版本的。
5、虚拟软件--VMware：
虚拟软件中最著名的是VMware公司的VMwareworkstation，它可以虚拟出新的计算机，可以在虚拟的计算机上安装DOS、Windows、Linux、Vxworks等操作系统。
使用VMware将使得用户象拥有多台电脑一样，对于Linux程序员来说，简直是无比方便。
用户从Windows上进入与退出Linux，根本不需要重新启动！
参考文献
[1]张海藩.软件工程导论（第三版）.清华大学出版社.1998
[2]张海藩.软件工程导论[M].北京：
清华大学出版社.2003
[3]张海藩，牟永敏.面向对象程序设计实用教材.清华大学出版社.2001
[4]张海藩.软件工程[M]北京：
人民邮电出版社.2011
心得
曾听老师说过，如果，某个科目的结束了，你做了一个课程设计或者小论文，只要是认真完成了。
那么你对这门课至少掌握了70%。
写完这个小论文，我深有感触。
曾经认为，软件就是写程序，一个软件工作组就是由程序员组成。
在这次写小论文的过程中，我了解到软件工程对于软件设计的重要性，因为软件是为了给用户使用而研发的，所以这其中必须有用户的需求分析，当知道开发方向后，还要知道这其中可能出现的问题，以及怎样解决这些问题。
之后就要设计出这个程序的大体框架，然后再写出程序，经过调试，纠错后交付使用。
后期需要大量的维护。
也许就像不了解软件的人永远想不通软件为什么要跟新一样，没有学过软件工程的人，是很难写出一个软件的，他们写出的只是程序，而不是一个可以使用的软件。
xxx
本次期末论文到此已经顺利结束，通过这次的期末论文,我学到了很多。
在以前的2年时间内我学习了很多的课程及编程语言，虽然通过学习对这些课程有所了解和掌握，但是始终处于理论知识的掌握阶段，并没有真正应用于实践设计开发，所以对知识的掌握还不够全面和熟练。
而且并不能真正独立的开发出一个完整的应用于实际的系统。
通过这次的小论文，我已经可以完成这一任务，对自身的编程能力也有了很大的提高。
整个写作过程对我来说是一次能力的真正提高的过程；
是一次将理论应用于实践的过程；
是将以前所学知识充分利用的过程，比如管理信息系统，数据库概论等等；
是一次真正的实践过程。
总体说来，这次我真正学到了很多有用的东西，是一些在课堂内所学不到的知识，收获很大。
通过此次学习，我对软件工程有了进一步的了解。
它需要经过定义、开发、使用和维护这样一个漫长的过程，需配置程序、文档和数据等成分。
在软件开发的过程中，传统的生命周期方法学和对象方法学是应用的最广泛的软件工程方法，我们既要要求每一步的正确性又要确定每一步的精简性，根据生命周期全过程中应完成的任务性质，在概念上分为问题定义、可行性研究、需求分析、概要分析、详细设计、编码和单元测试、综合测试以及维护等，这其实实质性的证明我以前对软件工程完全错误认识，它不是简单指编码程序。
它是经管理和技术相结合，由一组组织良好、管理严密、各类人员协调配合完成的工程项目。
升级会员 