用户登录
用户注册

分享至

软件工程需求分析er 在软件工程中什么是需求分析

  • 作者: 亖呉?盀
  • 来源: 51数据库
  • 2020-04-21

一。 确定对系统的综合要求

1. 功能需求

这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。

2. 性能需求

性能需求指定系统必须满足的定时约束或容量约束,通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。

3. 可靠性和可用性需求

可靠性需求定量地指定系统的可靠性。

可用性与可靠性密切相关,它量化了用户可以使用系统的程度。

4. 出错处理需求

这类需求说明系统对环境错误应该怎样响应。例如,如果它接收到从另一个系统发来的违反协议格式的消息,应该做什么?注意,上述这类错误并不是由该应用系统本身造成的。

5. 接口需求

接口需求描述应用系统与它的环境通信的格式。常见的接口需求有:用户接口需求;硬件接口需求;软件接口需求;通信接口需求。

6. 约束

设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。在需求分析阶段提出这类需求,并不是要取代设计(或实现)过程,只是说明用户或环境强加给项目的限制条件。常见的约束有:精度;工具和语言约束;设计约束;应该使用的标准;应该使用的硬件平台。

7. 逆向需求

逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求,我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。

8. 将来可能提出的要求

应该明确地列出那些虽然不属于当前系统开发范畴,但是据分析将来很可能会提出来的要求。

注意:举例让学生理解:这样做的目的是,在设计过程中对系统将来可能的扩充和修改预做准备,以便一旦确实需要时能比较容易地进行这种扩充和修改。

二 。分析系统的数据要求

任何一个软件系统本质上都是信息处理系统,系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌,对软件设计有深远影响,因此,必须分析系统的数据要求,这是软件需求分析的一个重要任务。

分析系统的数据要求通常采用建立数据模型的方法(举例)。

三。 导出系统的逻辑模型

综合上述两项分析的结果可以导出系统的详细的逻辑模型,通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。

四。 修正系统开发计划

根据在分析过程中获得的对系统的更深入更具体的了解,可以比较准确地估计系统的成本和进度,修正以前制定的开发计划。

软件工程 图书管理系统需求分析

引言

一直以来人们使用传统的人工方式管理图书馆的日常工作,对于图书馆的借书和还书过程,想必大家都已很熟悉。在计算机尚未在图书馆广泛使用之前,借书和还书过程主要依靠手工。一个最典型的手工处理还书过程就是:读者将要借的书和借阅证交给工作人员,工作人员将每本书上附带的描述书的信息的卡片和读者的借阅证放在一个小格栏里,并在借阅证和每本书贴的借阅条上填写借阅信息。这样借书过程就完成了。还书时,读者将要还的书交给工作人员,工作人员根据图书信息找到相应的书卡和借阅证,并填好相应的还书信息,这样还书过程就完成了。

以上所描述的手工过程的不足之处显而易见,首先处理借书、还书业务流程的效率很低,其次处理能力比较低,一段时间内,所能服务的读者人数是有限的。利用计算机来处理这些流程无疑会极大程度地提高效率和处理能力。我们将会看到排队等候借书、还书的队伍不再那么长,工作人员出错的概率也小了,读者可以花更多的时间在选择书和看书上。

为方便对图书馆书籍、读者资料、借还书等进行高效的管理,特编写该程序以提高图书馆的管理效率。使用该程序之后,工作人员可以查询某位读者、某种图书的借阅情况,还可以对当前图书借阅情况进行一些统计,给出统计表格,以便全面掌握图书的流通情况。

本次作业设计题目:“图书管理系统”主要目的是利用数据库软件编制一个管理软件,用以实现图书、读者以及日常工作等多项管理。同时对整个系统的分析、设计过程给出一个完整论证。

图书管理系统是一种基于集中统一规划的数据库数据管理新模式。在对图书、读者的管理,其实是对图书、读者数据的管理。本系统的建成无疑会为管理者对图书管理系统提供极大的帮助。

2 系统设计

2.1 系统指导思想和建设目标

2.1.1 系统指导思想

立足于校园实际,着眼于未来发展,建成符合标准化协议、通用性较强、实用的系统,以提高图书信息的现代化管理水平,实现信息资源的共享。

2.1.1 系统建设目标

(1)要解决的问题:(以某学校为参照) 随着办公自动化水平的不断提高,现在学校管理学生信息也逐步从手工转到计算机自动化信息处理阶段。设计一个功能完整、操作简便、界面友好的学生信息管理系统已经是势在必行的了。

(2)系统开发的目的:提高图书管理工作的效率,减少相关人员的工作量,使学校的图书管理工作真正做到科学、合理的规划,系统、高效的实施。

(3)系统名称:图书管理系统

2.2 总体功能设计

系统要能实现如下功能:

l 登录系统:注销用户、系统退出。

l 管理:用户管理、图书管理、读者管理、借阅管理。

l 查询:图书查询、读者查询、借阅查询。

l 报表打印:所有图书、借出图书、库存图书、所有读者。

l 帮助:使用说明、关于。

3 数据库设计

3.1 数据库系统的选择

本系统是一个中小型管理系统,运行环境是Windows2000 server,因此使用Windows环境下最容易使用且功能还可以的Microsoft Access 2000 作为后台的数据库系统。

3.2 需求分析

图3 图书流通数据流图

1.2

判断能

否借书

索书

信息

读 者

1.2

办理借

书手续

读者信息

查询结果

借书申请

被借图书

借书结果

借书信息

被借图书复本量

(b) 借书

借阅

3

读者

1

图书

5

1.1

图书

查询

借书信息

查询

4

判断

2

判断结果

索书

信息

图书信息

读 者

1

借书

2

还书

读 者

申请借书

还书申请

借书结果

还书结果

(a) 顶层数据流图

3

办借

书证

读者信息

办证信息

需求分析是数据库设计首先要做的工作,通过需求分析,我们作出了图书管理系统的各层数据流图,图3是图书流通数据流图(图中省略了“还书”和“办理借书证”的数据流图)。

在数据流图的基础上,定义数据字典。数据字典是关于数据库中数据的描述,它的作用是在软件分析和设计过程中为有关人员提供关于数据描述信息的查询,以保证数据的一致性。下面在图3的基础上举例说明数据字典的定义。

图3中涉及很多数据项,其中数据项“读者编号”可以描述如下:

数据项名:读者编号

别名:读者条码

含义:唯一标识每个读者

类型:字符型

取值范围:00000000至99999999

取值含义:顺序编号

“读者”一个数据结构,它可以描述如下:

数据结构名:读者

含义说明:是图书管理系统的数据结构之一,定义了一个读者的有关信息

组成:读者编号,姓名,性别,单位

数据流“借阅记录”可描述如下:

数据流名:借阅记录

说明:读者的借书记录

数据来源:办理借阅手续

数据去向:借阅

数据结构:读者编号、图书馆藏号、借阅日期

数据存储“借阅”可以描述如下:

数据存储名:借阅

说明:记录读者的借书情况

流出数据流:借阅记录

流入数据流:借阅记录

数据描述:读者编号、图书馆藏号、借阅日期

数据量:每年5000条以上

存取方式:随机存取

处理过程“判断能否借书”可描述如下:

处理过程“判断能否借书”

说明:根据读者的已借书情况可被借图书的馆藏情况判断读者能否借书

输入:借阅记录、读者信息、被借图书信息

输出:能否借书的标志

处理:读者提出借书请求后,先判断该读者以前的借书量是否达到了10本,如果达到了10本,则不能再借书,如果没有达到10本,则再判断读者要借的图书的可借量是否为0,如果不为0,则该书可以借出。

3.3 数据库设计

在图书管理系统中,数据库设计占重要位置,数据库设计质量的优劣,可直接影响到数据库数据的冗余度、数据的一致性、数据丢失等问题。下面就系统数据库规范化设计进行说明。

3.3.1 数据库设计的理论指导

数据库设计的理论指导是范式理论,其主要内容如下:

1)如果关系模式R,其所有的域为单纯域则称R是规范化的关系,或称第一范式 (1NF)

2)如果关系模式R为第一范式,且每个非主属性完全函数依赖于码,则模式R为第二范式(2NF)。

3) 如果关系模式R为第二范式,且每个非主属性非传递依赖于码,则称关系模式R为第三范式(3NF)。

4)关系模式R为第一范式,满足函数依赖集合F,X和A均为R的属性集合,且X不包含A,如果R满足X->A且X必包含R的码,称关系模式R为BCNF范式。

3.3.2 数据库设计

图书管理系统数据库常常要设计含有如下数据项:借书证号、姓名、单位、馆藏号(馆藏号为每本书上的条形码号)、书名、分类号、作者、价格等。如何进行模式的设计呢?下面以图书流通模块所涉及的数据库为例来说明。

图 书

读 者

借阅

m

n

借阅时间

馆藏号

书名

分类号

作者

价格

借书证号

姓名

性别

图4 图书流通的E-R图

属于

单 位

1

n

单位名称

单位编号

先设计图书流通的实体-关系图(E-R图)。E-R图由3个相关联的部分构成,即实体、实体与实体之间的关系以及实体和关系的属性。图书流通过程中实体“图书”与“读者”之间的关系是借阅和被借阅的关系,实体“读者”与“单位”之间的关系是属于和被属于的关系,“图书”的属性有“馆藏号”、“书名”、“分类号”、“作者”、“价格”,“读者”的属性有“借书证号”、“姓名”、“性别”,“单位”的属性有“单位编号”和“单位名称”,“借阅”属性“借书日期”,由此得出E-R图如图4。

从图中可以知道:

①“借书证号”是唯一的,所以“借书证号”决定“姓名”,每位读者应只属于一个性别,所以“借书证号”也决定“性别”;

②“馆藏号”是唯一的,所以“馆藏号”决定“书名”、“分类号”、“作者”、“价格”;

③ “单位编号”是唯一的,所以“单位编号”决定“单位名称”;

④ 每位读者在一个时间只能借一本书,所以“借书证号” +“馆藏号”决定“借阅时间”。

如果将这些数据项置于一个关系模式中,根据范式理论,该关系模式属于1NF(第一范式),它存在删除异常和冗余等问题,不是理想的模式,因此要把它分解成满足3NF或BCNF的关系模式。根据范式理论和E-R图转换成关系模型的规则,上面的E-R图可转换为4个关系模式:①图书(馆藏号、书名、分类号、作者、价格);②读者(借书证号、姓名、性别、单位编号);③借阅(借书证号、馆藏号、借阅时间),④单位(单位编码、单位名称),其中打下划线的为码,这样就解决了插入、删除和数据冗余等问题。

我们对数据的结构进行详细的分析,按照上述的设计思想,共设计了读者表,书目表,馆藏表,流通表等百余张数据表,然后创建视图和存储过程。下面举例说明:

读者表:借书证号、姓名、单位、读者类别、职称等字段;

书目表:馆藏号、ISBN、题名、作者、出版社、复本数、语种、文献类型、版次等字段;

馆藏表:馆藏号、索书号、分类号、种次号、馆藏位置、单价、出版日期等字段;

流通表:借书证号、馆藏号、借期、还期、续借、应还期、操作员等字段;

借阅规则表:读者类别编码、图书类别编码、限借册数、每期天数、续借天数、过期日期、罚金等字段。

读者类别表:读者类别编码、读者类别等字段。

图书类别表:图书类别编码、图书类别等字段。

3.4 数据库索引

建立索引是加快查询速度的有效手段,数据库的每一个表建立了主键,主键由一个或几个字段组成,每一个表都按主键建立了索引,部分表为了满足查询和排序的需要,除建立主索引外,还建立了次索引。例如在查询时要用到“馆藏号”、“作者”、“题名”等条件来查找图书,因此,在书目表上除了对主键“馆藏号”建立了主索引外,也对“作者”、“书名”等建立了次索引。

3.5 视图

视图是从一个或几个基本表导出的表,它是定义在基本表之上的,它是一个虚表,数据库中只存放视图的定义,而不存放视图对应的数据,数据仍然存放在原来的基本表中。通过定义视图,可以使用户眼中的数据库结构简单、清晰,并可以简化用户的数据查询操作。由于本系统数据表较多,表中的字段多,为了简化对表的操作,我们创建了图书_按书名查询、期刊_按刊名查询、期刊_按编辑部查询、借阅规则查询、待还书查询、超期记录查询等30余个视图。

3.6 存储过程

存储过程是一段经过编译的程序代码,存放在数据库服务器端。通过调用适当的存储过程,可在服务器端处理大量数据,再将处理结果送到客户端。这样可减少数据在网络上的传送,消除网络阻塞现象;例如:要查询某条记录,若该记录在表中的顺序号是10000,不采用存储过程,服务器将从1至于10000条记录数据逐条送至客户端,采用存储过程后,由于过程是经过编译的并且是在本地,不需要通过网络,因此能很快查出所需记录并将结果送到客户端,大大减少了网上数据传输量。存储过程另一好处是可供不同的开发工具调用,如PB、VB、ASP、Delphi等开发工具均可调用。在流通模块和WEB查询模块上均有图书检索功能,实际上调用同一存储过程完成的。本系统建立了60多个存储过程,实现诸如借还书处理、新书入库统计、编目入馆藏、读者统计、生成索书号等功能。

3.7 数据库调用

采用ODBC接口实现数据库的调用,采用ADO接口调用。

4 条形码的使用

条形码具有唯一性和一次输入后就可反复使用的优点,利用条形码技术作为信息快速输入的手段可迅速且不易发生错误地处理图书管理业务。本系统使用条形码作为图书和读者的标识,实现标识的唯一性。

使用条码后,能够使图书管理工作更加简单、快捷、不易出错。例如,当一本书具有唯一条形码标识,每位读者也具有唯一条形码标识时,图书的借阅、查询就十分便捷了。应用条形码取代了以往填写书袋卡、借书证,核对借阅时间等繁琐的手工劳动。读者在借书时只要将借书证给工作人员,工作人员只需登录借书系统,用条形码阅读器扫描读者借书证上的条形码,屏幕就会显示出该读者的信息,包括读者姓名、单位、可借几本书、已借几本书、是否过期、有无罚款等。如可以借书,工作人员只需用条形码阅读器扫描该读者所需借的书上的条形码符号后,该书的书名和条形码等信息都从数据库中调出显示在屏幕上,自动记录在该读者的借阅档案中,借书工作即告完成。一般借一本书仅需 1至 2秒钟。操作完后,计算机自动地将该借阅者和借阅的图书号码输入对应数据库中,并自动提示借阅期限

软件需求分析是软件工程过程中几交换意见最频繁的步骤.为什么交换意见的途径会经常阻塞

软件需求包括三个不同的层次—业务需求,用户需求和功能需求—也包括非功能需求.

业务需求( business requirement)反映了组织机构或客户对系统,产品高层次的目标要求,它

们在项目视图与范围文档中予以说明.

用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务,这在使用实例( use case)文档或方案脚本( scenario)说明中予以说明.

需求的层次

功能需求(functional requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求.

所谓特性( f e a t u r e )是指逻辑上相关的功能需求的集合,给用户提供处理能力并满足业务需求.软件需求各组成部分之间的关系如图所示

什么是需求工程

把所有与需求直接相关的活动通称为需求工程.

需求工程中的活动可分为两大类:

一类属于需求开发,

另一类属于需求管理.

需求工程的结构图

"用户"(user)是一种泛称,它可细分为"客户"(customer),"最终用户"(the end user)和"间接用户"(或称为关系人).

掏钱买软件的用户称为客户,而真正操作软件的用户叫最终用户.客户与最终用户可能是同一个人也可能不是同一个人.

几个基本概念

用户在需求工程中的"权利"

1. 有权要求开发方派遣资质合格的需求分析员和相关人员.

2. 有权要求开发方采用用户熟悉的语言来描述需求,即开发方必须提供用户看得懂得需求文档

3. 有权审查需求文档,并对有争议的需求作出决策.如果认为需求文档不能准确地反映用户真实的意愿,可以拒绝在需求文档上签字.

4. 如果用户想要变更需求,有权要求开发方对该变更将产生的影响作出真实可信的评估,以便用户决定是否变更需求.

用户在需求工程中的"义务"

1. 以积极友善的态度与开发方人员交流,协作,尽可能地为开发方人员提供工作和生活上的便利.

2. 乐意接受需求分析员的采访,在不泄漏机密的前提下尽可能地回答需求分析员的问题.

3. 在不泄漏机密的前提下,尽可能地向需求分析员提供与需求相关的材料.

4. 与需求分析员共同评审需求文档,确保需求文档准确地反映用户真实的意愿.

求一份数据库课程设计 有需求分析 E-R图 代码

可以通过百度Hi告诉我你的问题

有时间可以搞定你面临的问题

如果你有相近的要求也可以示意我

ES:\\D5118DEB19D427863A6EC318BF46053C

交易提醒:预付定金是诈骗

交易提醒:百度名中包含联系方式勿轻信来自:求助得到的回答

系统开放与软件工程的两个质量模型是什么

软件工程(Software Engineering,简称为SE)是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言,数据库,软件开发工具,系统平台,标准,设计模式等方面。

在现代社会中,软件应用于多个方面。典型的软件比如有电子邮件,嵌入式系统,人机界面,办公套件,操作系统,编译器,数据库,游戏等。同时,各个行业几乎都有计算机软件的应用,比如工业,农业,银行,航空,政府部门等。这些应用促进了经济和社会的发展,使得人们的工作更加高效,同时提高了生活质量。

软件工程师是对应用软件创造软件的人们的统称,软件工程师按照所处的领域不同可以分为系统分析员,软件设计师,系统架构师,程序员,测试员等等。人们也常常用程序员来泛指各种软件工程师。

软件工程(SoftWare Engineering)的框架可概括为:目标、过程和原则。

(1)软件工程目标:生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题,它们形成了对过程、过程模型及工程方法选取的约束。

(2)软件工程过程:生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义,又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构,包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明,包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程,实现完成后的确认,保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程,还有管理过程、支持过程、培训过程等。

(3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。

一、软件工程概述

概念:应需而生

软件工程是一类工程。工程是将理论和知识应用于实践的科学。就软件工程而言,它借鉴了传统工程的原则和方法,以求高效地开发高质量软件。其中应用了计算机科学、数学和管理科学。计算机科学和数学用于构造模型与算法,工程科学用于制定规范、设计范型、评估成本及确定权衡,管理科学用于计划、资源、质量和成本的管理。

软件工程这一概念,主要是针对20世纪60年代“软件危机”而提出的。它首次出现在1968年NATO(北大西洋公约组织)会议上。自这一概念提出以来,围绕软件项目,开展了有关开发模型、方法以及支持工具的研究。其主要成果有:提出了瀑布模型,开发了一些结构化程序设计语言(例如PASCAL语言,Ada语言)、结构化方法等。并且围绕项目管理提出了费用估算、文档复审等方法和工具。综观60年代末至80年代初,其主要特征是,前期着重研究系统实现技术,后期开始强调开发管理和软件质量。

70年代初,自“软件工厂”这一概念提出以来,主要围绕软件过程以及软件复用,开展了有关软件生产技术和软件生产管理的研究与实践。其主要成果有:提出了应用广泛的面向对象语言以及相关的面向对象方法,大力开展了计算机辅助软件工程的研究与实践。尤其是近几年来,针对软件复用及软件生产,软件构件技术以及软件质量控制技术、质量保证技术得到了广泛的应用。目前各个软件企业都十分重视资质认证,并想通过这些工作进行企业管理和技术的提升。软件工程所涉及的要素可概括如下:

根据这一框架,可以看出:软件工程涉及了软件工程的目标、软件工程原则和软件工程活动。

目标:我的眼里只有“产品”

软件工程的主要目标是:生产具有正确性、可用性以及开销合宜的产品。正确性意指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜性是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多问题有待解决,它们形成了对过程、过程模型及工程方法选取的约束。

软件工程活动是“生产一个最终满足需求且达到工程目标的软件产品所需要的步骤”。主要包括需求、设计、实现、确认以及支持等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义,又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件体系结构,包括子系统、模块以及相关层次的说明、每一模块接口定义。详细设计产生程序员可用的模块说明,包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程,实现完成后的确认,保证最终产品满足用户的要求。支持活动包括修改和完善。伴随以上活动,还有管理过程、支持过程、培训过程等。

框架:四项基本原则是基石

软件工程围绕工程设计、工程支持以及工程管理,提出了以下四项基本原则:

第一,选取适宜开发范型。该原则与系统设计有关。在系统设计中,软件需求、硬件需求以及其他因素之间是相互制约、相互影响的,经常需要权衡。因此,必须认识需求定义的易变性,采用适宜的开发范型予以控制,以保证软件产品满足用户的要求。

第二,采用合适的设计方法。在软件设计中,通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现,以达到软件工程的目标。

第三,提供高质量的工程支持。“工欲善其事,必先利其器”。在软件工程中,软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。

第四,重视开发过程的管理。软件工程的管理,直接影响可用资源的有效利用,生产满足目标的软件产品,提高软件组织的生产能力等问题。因此,仅当软件过程得以有效管理时,才能实现有效的软件工程。

这一软件工程框架告诉我们,软件工程的目标是可用性、正确性和合算性;实施一个软件工程要选取适宜的开发范型,要采用合适的设计方法,要提供高质量的工程支撑,要实行开发过程的有效管理;软件工程活动主要包括需求、设计、实现、确认和支持等活动,每一活动可根据特定的软件工程,采用合适的开发范型、设计方法、支持过程以及过程管理。根据软件工程这一框架,软件工程学科的研究内容主要包括:软件开发范型、软件开发方法、软件过程、软件工具、软件开发环境、计算机辅助软件工程(CASE) 及软件经济学等。

作用:高效开发高质量软件

自从软件工程概念提出以来,经过30多年的研究与实践,虽然“软件危机”没得到彻底解决,但在软件开发方法和技术方面已经有了很大的进步。尤其应该指出的是,自80年代中期,美国工业界和政府部门开始认识到,在软件开发中,最关键的问题是软件开发组织不能很好地定义和管理其软件过程,从而使一些好的开发方法和技术都起不到所期望的作用。也就是说,在没有很好定义和管理软件过程的软件开发中,开发组织不可能在好的软件方法和工具中获益。

根据调查,中国的现状几乎和美国10多年前的情况一样,软件开发过程没有明确规定,文档不完整,也不规范,软件项目的成功往往归功于软件开发组的一些杰出个人或小组的努力。这种依赖于个别人员上的成功并不能为全组织的软件生产率和质量的提高奠定有效的基础,只有通过建立全组织的过程改善,采用严格的软件工程方法和管理,并且坚持不懈地付诸实践,才能取得全组织的软件过程能力的不断提高。

这一事实告诉我们,只有坚持软件工程的四条基本原则,既重视软件技术的应用,又重视软件工程的支持和管理,并在实践中贯彻实施,才能高效地开发出高质量的软件。

二、软件工程的七条基本原理

自从1968年提出“软件工程”这一术语以来,研究软件工程的专家学者们陆续 提出了100多条关于软件工程的准则或信条。 美国著名的软件工程专家 Boehm 综合这些专家的意见,并总结了TRW公司多年的开发软件的经验,于1983年提出了软件工程的七条基本原理。

Boehm 认为,着七条原理是确保软件产品质量和开发效率的原理的最小集合。

它们是相互独立的,是缺一不可的最小集合;同时,它们又是相当完备的。

人们当然不能用数学方法严格证明它们是一个完备的集合,但是可以证明,在此之前已经提出的100多条软件工程准则都可以有这七条原理的任意组合蕴含或派生。

下面简要介绍软件工程的七条原理:

1 用分阶段的生命周期计划严格管理

这一条是吸取前人的教训而提出来的。统计表明,50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中,需要完成许多性质各异的工作。这条原理意味着,应该把软件生命周期分成若干阶段,并相应制定出切实可行的计划,然后严格按照计划对软件的开发和维护进行管理。 Boehm 认为,在整个软件生命周期中应指定并严格执行6类计划:项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。

2 坚持进行阶段评审

统计结果显示: 大部分错误是在编码之前造成的,大约占63%; <2> 错误发现的越晚,改正它要付出的代价就越大,要差2到3个数量级。 因此,软件的质量保证工作不能等到编码结束之后再进行,应坚持进行严格的阶段评审,以便尽早发现错误。

3 实行严格的产品控制

开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们,需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制,又叫基准配置管理。当需求变动时,其它各个阶段的文档或代码随之相应变动,以保证软件的一致性。

4 采纳现代程序设计技术

从六、七时年代的结构化软件开发技术,到最近的面向对象技术,从第一、第二代语言,到第四代语言,人们已经充分认识到:方法大似气力。采用先进的技术即可以提高软件开发的效率,又可以减少软件维护的成本。

5 结果应能清楚地审查

软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差,难于评价和管理。为更好地进行管理,应根据软件开发的总目标及完成期限, 尽量明确地规定开发小组的责任和产品标准,从而使所得到的标准能清楚地审查。

6 开发小组的人员应少而精

开发人员的素质和数量是影响软件质量和开发效率的重要因素,应该少而精。

这一条基于两点原因:高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍,开发工作中犯的错误也要少的多; 当开发小组为N人时,可能的通讯信道为N(N-1)/2, 可见随着人数N的增大,通讯开销将急剧增大。

7 承认不断改进软件工程实践的必要性

遵从上述六条基本原理,就能够较好地实现软件的工程化生产。但是,它们只是对现有的经验的总结和归纳,并不能保证赶上技术不断前进发展的步伐。因此,Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理。根据这条原理,不仅要积极采纳新的软件开发技术,还要注意不断总结经验,收集进度和消耗等数据,进行出错类型和问题报告统计。这些数据既可以用来评估新的 软件技术的效果,也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。

面向方面的编程(Aspect Oriented Programming,简称AOP)被认为是近年来软件工程的另外一个重要发展。这里的方面指的是完成一个功能的对象和函数的集合。在这一方面相关的内容有泛型编程(Generic Programming)和模板。

参考

胡昆山,《中国软件产业发展现状与人才需求》,2003年9月1日,

三、软件工程的目标与常用模型

软件工程的目标是提高软件的质量与生产率,最终实现软件的工业化生产。质量是软件需求方最关心的问题,用户即使不图物美价廉,也要求个货真价实。生产率是软件供应方最关心的问题,老板和员工都想用更少的时间挣更多的钱。质量与生产率之间有着内在的联系,高生产率必须以质量合格为前提。如果质量不合格,对供需双方都是坏事情。从短期效益看,追求高质量会延长软件开发时间并且增大费用,似乎降低了生产率。从长期效益看,高质量将保证软件开发的全过程更加规范流畅,大大降低了软件的维护代价,实质上是提高了生产率,同时可获得很好的信誉。质量与生产率之间不存在根本的对立,好的软件工程方法可以同时提高质量与生产率。

软件供需双方的代表能在餐桌上谈笑风生,归功于第一线开发人员的辛勤工作。质量与生产率的提高就指望程序员与程序经理。对开发人员而言,如果非得在质量与生产率之间分个主次不可,那么应该是质量第一,生产率第二。这是因为:(1)质量直接体现在软件的每段程序中,高质量自然是开发人员的技术追求,也是职业道德的要求。(2)高质量对所有的用户都有价值,而高生产率只对开发方有意义。(3)如果一开始就追求高生产率,容易使人急功近利,留下隐患。宁可进度慢些,也要保证每个环节的质量,以图长远利益。

软件的质量因素很多,如正确性,性能、可靠性、容错性、易用性、灵活性、可扩充性、可理解性、可维护性等等。有些因素相互重叠,有些则相抵触,真要提高质量可不容易啊!

软件工程的主要环节有:人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试、维护等,如图1.1所示。

软件工程模型建议用一定的流程将各个环节连接起来,并可用规范的方式操作全过程,如同工厂的生产线。常见的软件工程模型有:线性模型(图1.2),渐增式模型(图1.3),螺旋模型,快速原型模型,形式化描述模型等等 [Pressmam 1999, Sommerville 1992]。

最早出现的软件工程模型是线性模型(又称瀑布模型)。线性模型太理想化,太单纯,已不再适合现代的软件开发模式,几乎被业界抛弃。偶而被人提起,都属于被贬对象,未被留一丝惋惜。但我们应该认识到,“线性”是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的“非线性”问题时,总是千方百计地将其分解或转化为一系列简单的线性问题,然后逐个解决。一个软件系统的整体可能是复杂的,而单个子程序总是简单的,可以用线性的方式来实现,否则干活就太累了。线性是一种简洁,简洁就是美。当我们领会了线性的精神,就不要再呆板地套用线性模型的外表,而应该用活它。例如渐增式模型实质就是分段的线性模型,如图1.3所示。螺旋模型则是接连的弯曲了的线性模型。在其它模型中都能够找到线性模型的影子。

套用固定的模型不是程序员的聪明之举。比如“程序设计”与“测试”之间的关系,习惯上总以为程序设计在先,测试在后,如图1.4(a)所示。而对于一些复杂的程序,将测试分为同步测试与总测试更有效,如图1.4(b)所示。

不论是什么软件工程模型,总是少不了图1.1中的各个环节。本书擗开具体的软件工程模型,顺序讲述人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试,以及维护与再生工程。其中程序设计部分以C++/C语言为例。

四、软件体系结构和工具的选择

软件体系结构表示了一个软件系统的高层结构,主要特点有:1)软件系统结构是一个高层次上的抽象,它并不涉及具体的系统结构(比如B/S还是C/S),也不关心具体的实现。2)软件体系结构必须支持系统所要求的功能,在设计软件体系结构的时候,必须考虑系统的动态行为。3)在设计软件体系结构的时候,必须考虑有现有系统的兼容性、安全性和可靠性。同时还要考虑系统以后的扩展性和伸缩性。所以有时候必须在多个不同方向的目标中进行决策。

当前已经有一些关于规范化软件体系结构,比如:ISO的开放系统互联模型、X Window系统等等。软件系统的结构通常被定义为两个部分:一个是计算部件。另一个就是部件之间的交互。如果把软件系统看成一幅图的话,计算部件就是其中的节点,而部件之间的交互就是节点之间的弧线。部件之间的连接可以被认为是一种连接器,比如过程调用、事件广播、数据库查询等等。正确的体系结构设计是软件系统成功的关键。

我们理解了软件工程的重要性以后,我们没有相应的工具,我们也很难很好的完成一个系统。在需求分析和设计阶段,我们需要什么样的工具呢?

当然最好是基于UML的CASE工具。当前比较流行的就是Rose,它是一个很好的分析和建立对象和对象关系的工具。在具体编码的时候,我们需要版本控制工具,MS的SourceSafe就是一个很好的版本管理工具和项目管理工具。具体的开发工具当然很多,但是如果你是一个对VC侵淫了多年的程序员,你一定会选择它,因为它会让你感到什么是真正的面向对象的编程,而你在用VB,PowerBuilder,Delphi时很少会有同样的感受。至于数据库模式构建,我一向是采用Sybase的S-Design,更好的工具就不知道了。

另外需要注意的是,我们需要建立文档编写的若干模板,以便开发人员按照这个模板编写规范的技术和说明文档。帮助文档可以用微软的HTML Help Workshop(hhw.exe)制作,你也可以编译成.chm格式,它打包了文本和图形,只有一个文件,使用和分发比较方便。最后,如果开发人员不是集中在一个地方的话,最好建立一个邮件列表,开发人员可以通过邮件系统讨论开发中的各项事宜。

五、软件开发方法综述

国外大的软件公司和机构一直在研究软件开发方法这个概念性的东西,而且也提出了很多实际的开发方法,比如:生命周期法、原型化方法、面向对象方法等等。下面介绍几种流行的开发方法:

1、结构化方法

结构化开发方法是由E.Yourdon 和 L.L.Constantine 提出的,即所谓的SASD 方 法, 也可称为面向功能的软件开发方法或面向数据流的软件开发方法。Yourdon方法是80年代 使用最广泛的软件开发方法。它首先用结构化分析(SA)对软件进行需求分析,然后用结构化设计(SD)方法进行总体设计,最后是结构化编程(SP)。它给出了两类典型的软件结构(变换型和事务型)使软件开发的成功率大大提高。

2、面向数据结构的软件开发方法

Jackson方法是最典型的面向数据结构的软件开发方法,Jackson方法把问题分解为可由三种基本结构形式表示的各部分的层次结构。三种基本的结构形式就是顺序、选择和重复。三种数据结构可以进行组合,形成复杂的结构体系。这一方法从目标系统的输入、输出数据结构入手,导出程序框架结构,再补充其它细节,就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效,如商业应用中的文件表格处理。该方法也可与其它方法结合,用于模块的详细设计。

3、 面向问题的分析法

PAM(Problem Analysis Method)是80年代末由日立公司提出的一种软件开发方法。 它的基本思想是考虑到输入、输出数据结构,指导系统的分解,在系统分析指导下逐步综 合。这一方法的具体步骤是:从输入、输出数据结构导出基本处理框;分析这些处理框之间的先后关系;按先后关系逐步综合处理框,直到画出整个系统的PAD图。这一方法本质上是综合的自底向上的方法,但在逐步综合之前已进行了有目的的分解,这个目的就是充分考虑系统的输入、输出数据结构。PAM方法的另一个优点是使用PAD图。这是一种二维树形结构图,是到目前为止最好的详细设计表示方法之一。当然由于在输入、输出数据结构与整个系统之间同样存在着鸿沟,这一方法仍只适用于中小型问题。

4、原型化方法

产生原型化方法的原因很多,主要随着我们系统开发经验的增多,我们也发现并非所有的需求都能够预先定义而且反复修改是不可避免的。当然能够采用原型化方法是因为开发工具的快速发展,比如用VB,DELPHI等工具我们可以迅速的开发出一个可以让用户看的见、摸的着的系统框架,这样,对于计算机不是很熟悉的用户就可以根据这个样板提出自己的需求。

开发原型化系统一般由以下几个阶段:

(1) 确定用户需求

(2) 开发原始模型

(3) 征求用户对初始原型的改进意见

(4) 修改原型。

原型化开发比较适合于用户需求不清、业务理论不确定、需求经常变化的情况。当系统规模不是很大也不太复杂时采用该方法是比较好的。

5、面向对象的软件开发方法

当前计算机业界最流行的几个单词就是分布式、并行和面向对象这几个术语。由此可以看到面向对象这个概念在当前计算机业界的地位。比如当前流行的两大面向对象技术DCOM和CORBA就是例子。当然我们实际用到的还是面向对象的编程语言,比如C++。不可否认,面向对象技术是软件技术的一次革命,在软件开发史上具有里程碑的意义。

随着OOP(面向对象编程)向OOD(面向对象设计)和OOA(面向对象分析)的发展,最终形成面向对象的软件开发方法OMT (Object Modeling Technique)。这是一种自底向上和自顶向下相结合的方法,而且它以对象建模为基础,从而不仅考虑了输入、输出数据结构,实际上也包含了所有对象的数据结构。所以OMT彻底实现了PAM没有完全实现的目标。不仅如此,OO技术在需求分析、可维护性和可靠性这三个软件开发的关键环节和质量指标上有了实质性的突破,基本地解决了在这些方面存在的严重问题。

综上所述,面向对象系统采用了自底向上的归纳、自顶向下的分解的方法,它通过对对象模型的建立,能够真正建立基于用户的需求,而且系统的可维护性大大改善。当前业界关于面向对象建模的标准是UML(Unified Modeling Language)。

这里我们需要谈一下微软的MSF(Microsoft Solutions Framework)的框架,它简单的把系统设计分成三个阶段:概念设计、逻辑设计和物理设计。概念设计阶段就是从用户的角度出发可以得到多少个对象,并且以对象为主体,画出业务框架。逻辑设计阶段就是对概念设计阶段的对象进行再分析、细分、整合、删除。并建立各个对象的方法属性以及对象之间的关系。而物理设计实际上就是要确定我们实际需要的组件、服务和采用的框架结构、具体的编程语言等。MCF整个结构比较清楚是基于对象开发的一个比较好的可操作的框架系统。

6、可视化开发方法

其实可视化开发并不能单独的作为一种开发方法,更加贴切的说可以认为它是一种辅助工具,比如用过SYBASE的S-Design的人都知道,用这个工具可以进行显示的图形化的数据库模式的建立,并可以导入到不同的数据库中去。当然用过S-Design的人不一定很多,但用过VB,DELPHI,C++ Builder等开发工具的人一定不少,实际上你就是在使用可视化开发工具。

当然,不可否认的是,你只是在编程这个环节上用了可视化,而不是在系统分析和系统设计这个高层次上用了可视化的方法。实际上,建立系统分析和系统设计的可视化工具是一个很好的卖点,国外有很多工具都致力于这方面产品的设计。比如Business Object就是一个非常好的数据库可视化分析工具。

可视化开发使我们把注意力集中在业务逻辑和业务流程上,用户界面可以用可视化工具方便的构成。通过操作界面元素,诸如菜单、按钮、对话框、编辑框、单选框、复选框、 列表框和滚动条等,由可视开发工具自动生成应用软件。

六、怎样培养软件工程的思维与方法

作为软件开发人员的一个通病是在项目初期的时候,就喜欢谈论实现的细节,并且乐此不疲。我们更喜欢讨论如何用灵活而简短的代码来实现一个特定的功能,而忽略了对整个系统架构的考虑。所以作为一个开发人员,尤其是一个有经验的开发人员,应该把自己从代码中解脱出来,更多的时候在我们的脑子里甚至暂时要放弃去考虑如何实现的问题,而从项目或产品的总体去考虑一个软件产品。

以下是我个人的一些经验:

1.考虑整个项目或者产品的市场前景。作为一个真正的系统分析人员,不仅要从技术的角度来考虑问题,而且还要从市场的角度去考虑问题。也就是说我们同时需要考虑我们产品的用户群是谁,当我们产品投放到市场上的时候,是否具有生命力。比如即使我们采用最好的技术实现了一个单进程的操作系统,其市场前景也一定是不容乐观的。

2.从用户的角度来考虑问题。比如一些操作对于开发人员来讲是非常显而易见的问题。但是对于一般的用户来说可能就非常难于掌握,也就是说,有时候,我们不得不在灵活性和易用性方面进行折中。另外,在功能实现上,我们也需要进行综合考虑,尽管一些功能十分强大,但是如果用户几乎不怎么使用它的话,就不一定在产品的第一版的时候就推出。从用户的角度考虑,也就是说用户认可的才是好的,并不是开发人员觉的好才好。

3.从技术的角度考

学习《软件工程》心得和体会

软件工程学习心得

在本学期的软件工程课程的学习中,我们学习了十一章的内容。第一章软件与软件工程的概念,这一章主要讲解的是一些概念性和基础性的内容,例如软件的概念、特性,软件危机的主要表现,软件工程的概念以及软件生存期、典型生存期模型等等。第二章软件工程方法与工具,这一章主要对软件工程方法进行介绍,包括三种方法:传统方法、面向对象方法、形式化方法。还引出了工具UML。第三章软件需求获取与结构化分析方法,本章详细介绍了需求获取与需求分析阶段的任务以及结构化分析方法,画分层的数据流图、E-R图以及状态图式本节的重点。第四章结构化分析方法,这一章重点讲解了使用变换型映射方法和事务型映射方法生成初始的模块结构以及模块结构的改进。第五章编码,这一章重点讲解了编码的风格及规范,还告诉我们编码规范说带来的好处,并告诫我们将来一点要形成好的编码风格。第六章软件测试方法,本章讲解了软件测试相关的概念及重要性,软件测试与开发各个阶段的关系;还介绍了白盒测试技术以及黑河测试技术。第七章统一建模语言UML概述,本章详细介绍了UML的基本模式、事物、关系及建模时用到的各种图进行了介绍。第八章面向对象分析,这一章主要讲解了面向对象分析的3种模型,包括功能模型、静态模型和动态模型。第九章软件体系结构与设计模式,本章对软件体系结构的基本概念、典型风格等进行了讲解。第十章面向对象设计,本章的重点是对面向对象分析时建立的对象模型进行调整和细化。第十一章软件维护,本章主要介绍软件维护的任务、软件维护活动以及软件维护方法进行了介绍。

要学习软件工程,学会如何系统的思考,以及养成良好的编码习惯,想学好软件工程,就必须知道软件工程的目标、过程和原则:

软件工程目标:生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题,它们形成了对过程、过程模型及工程方法选取的约束。

软件工程过程:生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义,又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构,包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明,包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程,实现完成后的确认,保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程,还有管理过程、支持过程、培训过程等。

软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。

我们学习了详细设计的方法,其原则是过程描述是否易于理解、复审和维护,进而过程描述能够自然地转换成代码,并保证详细设计与代码完全一致。包括程序流程图、N-S图、PAD图、HIPO图

程序流程图:程序流程图又称之为程序框图,它是软件开发者最熟悉的一种算法表达工具。它独立于任何一种程序设计语言,比较直观和清晰地描述过程的控制流程,易于学习掌握。在流程图中只能使用下述的五种基本控制结构:顺序型;选择型;while型循环;until型循环;多情况型选择。

N-S图:一种符合结构化程序设计原则的图形描述工具,称为盒图,又称为N-S图。在N-S图中,为了表示五种基本控制结构,规定了五种图形构件。顺序型;选择型;WHILE重复型;UNTIL重复型;多分支选择型。

PAD图:它是用结构化程序设计思想表现程序逻辑结构的图形工具。PAD也设置了五种基本控制结构的图示,并允许递归使用。

HIPO图:HIPO图是由一组IPO图加一张HC图组成。它是美国IBM公司在软件设计中使用的主要表达工具。

HC图既是层次图,用于表示软件的分层结构。HC图中的每一个模块,均可用一张IPO图来描述。IPO 图由输入、处理和输出三个框组成,需要时还可以增加一个数据文件框,这种图形的优点,是能够直观地显示输入—处理—输出三者之间的联系。

还有测试方法:按照测试过程是否在实际应用环境中来分,有静态分析与动态测试。测试方法有分析方法(包括静态分析法与白盒法)与非分析方法(称黑盒法)。

静态分析技术:不执行被测软件,可对需求分析说明书、软件设计说明书、源程序做结构检查、流程分析、符号执行来找出软件错误。

动态测试技术:当把程序作为一个函数,输入的全体称为函数的定义域,输出的全体称为函数的值域,函数则描述了输入的定义域与输出值域的关系。

还学习了其他很多工具、语言、方法等,虽然不是都学得很透彻,但我相信在今后的学习中一定会慢慢的完善的。

软件工程对于初学者来说,知识基础较薄弱,对一些应用操作、概念、工具方法等理解起来较为困难,要能从整体概念上较好地理解和把握、学好软件工程,不是仅仅把几本专业书籍细致地看几遍,然后上机练习几次就可以成功,学习过程中要注意多看多练要注意结合实际,更要多思考,面对错误不要一范就问,要尝试自己去解决。但是还要注意什么都学,肯定是什么都学不透的,要集中精力打攻坚战,学习软件工程首先要明白自己的学习目标究竟是什么,根据自己的实际工作出发,有针对性的在相应的学习方向上进行提高,制定出详细的学习规划。还要注意与其他科目的相辅相成,就像我们在学习面向对象分析的时候要结合大一学习的面向对象及其方法学这一专业科目进行研究拓展;在学习语言时,要看看与C语言的联系,多思多想,把从各个科目学到的知识通汇贯通。

在软件工程的学习中,我了解到了软件并非是一些代码这么简单,在开发软件的过程中,编写代码的工作量其实只占不到所有工程量的30%,而后期的管理和维护更是占了60%到80%之多。一个完整的项目规划须包括,软件的定义,可行性分析报告,项目开发计划,软件需求说明书,概要设计说明书,详细设计说明书,用户操作手册,测试计划,测试分析报告,开发进度报告,项目开发总结报告,软件维护手册,软件问题报告,软件修改报告,等多个文档,每个文档都要上级验收审查,而文档数量众多,要做好这点真的不是很容易,而恰恰写好文档正能保证完成软件工程其中一个目的的关键,既研究如何用最小的开销做出生存期较长的软件,再加上各个阶段都要进行周密的策划、详细的分工部署和人员安排,且各阶段要据具体情况不断的反复才能达成,所以代码只是开发软件这个浩大的工程的一个小小的过程。

而编码的学习中,我更了解到形成自己独特的规范的编码风格是非常重要的事。因为这影响到了软件后期繁重的维护,大家都要阅读你的程序,如果你写的程序毫无规范可言,那么别人怎么能读懂你的程序?读不懂程序,维护又从何谈起呢?所以,我们在今后的学习中,一定要注意这方面的培养,在写程序的过程中,要逐步的在规范的基础上形成属于自己的风格,即方便自己的修改,也方便日后他人的阅读。

在学习中,我们还要注意比较三种方法的优缺点,例如:传统方法虽然使软件摆脱了混乱和无序,但其在适应需求变化的方面不够灵活,而且传统方法要么面向行为,要么面向数据,缺乏两者的有机结合。而面向对象方法的程序设计和问题求解更符合人们日常自然的思维习惯,适合大型、复杂及交互性比较强的系统。形式化方法则是一中基于形式化数学变换的软件开发方法,它可将系统的规格说明转换为可执行的程序。

在今后的学习中要注意多读书、多思考、多练习、多讨论,不断熟悉书本的基础,并以此为基础将其扩散开来,应用于今后的实践。不断锻炼自己,向一名合格的程序设计师迈进。

软件工程中《软件需求规格说明书》和《详细设计说明书》区别。

需求规格说明书在前,详细设计说明书在后.

需求规格说明书要界定用户的最终需求,建立软件的功能框架.

详细设计说明书在概要设计的基础上要深化设计,接口\内容都要具体化.

转载请注明出处51数据库 » 软件工程需求分析er 在软件工程中什么是需求分析

软件
前端设计
程序设计
Java相关