软件工程Software Engineering

廖清

liaoqing@hit.edu.cn

计算机科学与技术学院

1

课程简介

任课老师： 廖清， 信息楼1705室 liaoqing@hit.edu.cn 0755-86134382

课程网站 课件、作业要求、各类通知/消息均在此网站发布：liaoqing.me

教材及参考书 Rogers S. Pressman. Software Engineering: A Practitioner’s Approach (Seventh Edition). (《软件工程：实践者的研究方法，第8版》，机械工业出版社，2016年11月，ISBN 9787111548973)；

孙家广、刘强，《软件工程-理论、方法与实践》，高等教育出版社，2010年11月，ISBN 978-7-040-16308-7；

考试 平时作业10%、实践项目40%、期末考试50%

2

善用开源社区

助教 杨林：yanglincs17@foxmail.com,13580545033

郭颐冰：2932883823@qq.com,18224029837

李忠文: 2528509491@qq.com, 13602595139

苏伟俊：voygern@163.com，13651405017

Github上有注册用户2700万人

GitHub托管2000多万个开源软件，StackOverflow超过8600万条在线知识条目

3

教学目标

课程目标：从工程学角度认识软件在大型系统中的设计和应用，具备作为软件工程师从事工程实践所需的专业能力

4

转变对软件开发的认识：程序 系统

转变思维定式： 程序员 软件工程师

能力培养目标：• 需求定义与分析• 权衡和选择设计方案• 使用UML建模• 开发高质量软件• 运用软件工程工具• 团队协作开发• 谈判与沟通

实践项目

• 16学时，实验课上报告+课后实践。

• 学生每4-5人一组，选定一个来自实际需求的应用软件系统，利用所学软件工程知识进行需求分析、设计、开发、测试、过程与项目管理、源代码管理、版本控制。

• 期间组织4次口试(立项、需求分析、设计与开发、最终验收)。

• 不管是4人一组、5人一组、独立完成，组内成员均获得同样的成绩。

5

实践项目 40%

开题报告 10%

第一轮迭代 10%

第二轮迭代 10%

测试验收 10%

课程章节安排

•第一部分 软件工程概论

•第二部分 软件项目开发过程与管理

•第三部分 软件需求工程

•第四部分 软件设计

•第五部分 软件编码、测试与质量保障

•第六部分 软件实施、维护与演化

•实践项目

6

理论课：32学时

实践课：16学时

本章内容

需求规格说明书

7

需求规格说明书(SRS)

软件需求规格说明书SRS (Software Requirements Specification)：–需求开发的结果，精确的阐述一个软件系统必须提供的功能和性能，以及它所要考虑的限制条件。

–为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。

8

需求规格说明书(SRS)

• 是具有一定法律效力的合同文档

• 清楚地描述软件在什么情况下，需要做什么，以及不能做什么

• 以输入/输出、输入到输出之间的转换方式来描述功能性需求

• 描述经过干系人磋商达成共识的非功能性需求

• 一般参考需求定义模板，覆盖标准模板中定义的所有条目

• 作为后续的软件评估依据和变更的基准

9

需求规格说明书(SRS)

SRS作为软件开发各类人员之间进行理解和交流的手段：

–用户：通过SRS指定需求，检查需求描述是否满足期望；

–设计人员：了解软件需要开发的内容，将其作为软件设计的基本出发点；

–测试人员：制定测试计划、测试用例和测试过程；

–产品发布人员：编写用户手册和帮助信息；

–项目管理人员：规划软件开发过程、准确估计开发进度和成本、控制需求变更过程。

10

SRS应包含的内容

功能(Functionality)：– 该软件系统能够向用户提供何种服务？

外部接口(External interfaces)：– 该软件系统如何与用户、操作系统、硬件、其他软件系统进行交互？

性能(Performance)：– 软件系统在运行速度、可用性、响应时间、恢复时间等方面有哪些要求？

非功能属性(Non-Functional Attributes)：– 软件系统在可移植性、安全性、可靠性、可维护性等方面有哪些要求？

约束条件(Design constraints imposed on an implementation)：– 是否存在必要的标准、编程语言、运行环境、资源约束等因素？

11

SRS不应包含的内容

项目开发计划

–诸如成本、人员、进度、工具、方法等

产品保证计划

–诸如配置管理、验证与测试、质量保证等

软件设计细节

–需求通常用于表达“做什么”，而不描述“如何做”

12

选择合适的需求规格说明方式

• 考虑以下两个具体项目场景:1)小型项目， 1名程序猿， 2个月的开发周期

• 程序猿直接和用户对话，写了几页纸的备忘录

2)大型项目，50名程序猿，2年的开发周期

• 专门的团队进行需求建模与分析，撰写了500页的需求规格说明

13

好的SRS应具备的特点

正确性(Correct)无二义性(Unambiguous)完整性(Complete)一致性(Consistent)按重要度/稳定性排序(Ranked for importance and/or stability)可验证性(Verifiable)可修改性(Modifiable)可跟踪性(Traceable)

14

软件需求问题：不一致

15

对同一内容大家理解和认识不一样，需要达成一致 课程类别：有些人认为需要，有些人认为不需要

软件需求问题：模糊不准确

16

某项内容没有清晰的描述，需要细化或者准确化 学院类别：按照学院编号还是学院的名称

软件需求问题：不完整

17

漏掉了某些重要的软件需求，需要补充完整 学期：按照学期来浏览可选修的课程（暑期/秋季）

SRS模板

18

SRS的三大组成部分

1.引言(introduction)

2. 整体描述(overall description)

3. 需求描述(specific requirements)

19

概要描述本SRS，便于

读者理解文档如何编写、

如何阅读和解释

概述正在定义的软件产品以及它所运行的环境、使用产品的用户、已知的限

制/假设/依赖等

每一项需求的详细定义(输入、输出、业务逻辑等)，这也是SRS

的主体。

SRS的三大部分：“1. 引言”

1.引言(introduction)1.目的(purpose)2.范围(scope)3.术语表(definitions, acronyms, and abbreviations)4.参考文献(references)5.整体结构(overview)

2.整体描述(overall description)3.需求描述(specific requirements)

20

SRS的三大部分：“2. 整体描述”

1.引言(introduction)2.整体描述(overall description)1. 产品上下文环境(product perspective)2. 产品外部接口(external interface)3. 产品功能(product functions)4. 用户类和特征(user characteristics)5. 设计和实现上的约束(constraints)6. 运行环境(environment)7. 假设和依赖(assumptions and dependencies)8. 未来的需求(future requirements)

3.需求描述(specific requirements)21

SRS的三大部分：“3. 需求描述”

1.引言(introduction)2.整体描述(overall description)3.需求描述(specific requirements)1.各项功能的详细描述

(根据“2.3 产品功能”中所列出的各项功能来组织章节)2.非功能需求

22

随时准备迎接需求变化

• 这是一种态度

• 越多的干系人参与，将获得越多的需求特征

• 但不能通过减少干系人的方法来解决这个问题

• 干系人有改变他们想法的权利

• 不要问：“这是你最终的需求吗?”

• 请将变化看成机会，而非威胁

23

需求小结

什么是“软件需求”需求通常用于表达“做什么”，而不描述“如何做”。 学生选课系统需求

– 某大学希望采用计算机管理学生的选课

– 学生可以在一个学期开始之前选择该学期开设的某些课程

– 老师可以使用选课系统获得选课学生的名单，并登记学生的课程学习成绩

– 学生不希望自己的学习成绩被他人查阅

– ……(你可以补充吗？)

以下描述是否属于需求？为什么？

– 系统通过JDBC与Oracle数据库CourseDB建立连接，并使用T-SQL 语句从CourseOffering数据表中获得课程的开设信息。

24

需求小结

需求分类• 功能性需求

• 非功能性需求

功能性需求• 系统的功能性需求是指满足系统需求需要提供的功能

• 有时，功能需求也被称为“行为需求”

非功能性需求• 定义软件系统以及软件开发过程为满足系统功能需求要满足的其他约束条件

25

功能性需求(FR)vs.非功能性需求（NFR）

功能性需求(FR)

– 描述了系统与其独立于系统实现环境之间的交互。

– 环境包括用户和任何其他与该系统进行交互的外部系统。

非功能性需求（NFR）

– 描述了不直接关联到系统功能行为的系统的方方面面。从各个角度对系统进行约束和限制，反映了客户对软件系统质量和性能的额外要求，如响应时间、数据精度、可靠性等。

– 可用性(Usability):是一种用户可以学会的操作、输入准备、解释一个系统或者构件输出的状况。

– 可靠性(Reliability):是系统或构件在给定时间内、指定条件下，完成其要求功能的能力。

– 性能(Performance):需求要考虑系统的定量属性，比如响应时间，吞吐量、有效性和准确性。

– 可支持性(Supportability):需求关注于在进行部署后系统的变化状况，比如包括可适配性、可维护性、可移植性等。

26

一个例子：拼写检查器

业务需求：“用户能有效地纠正文档中的拼写错误”

用户需求：“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”

功能性需求：

– 找到拼写错误的单词并以高亮度提示

– 显示提供替换词的对话框

– 实现整个文档范围的替换

非功能性需求：

– 正确的找到至少95%以上的错词并100%的加以正确替换

– 拼写检查的速度应至少达到5000词/秒。

27

需求小结

• 需求工程的总体流程

28

需求获取 需求分析 规格说明 需求验证

调研资料用例模型

分析模型需求规格

说明书

审核通过的

规格说明书

活动

需求管理

产出物

需求开发

需求小结

• 需求获取目标：主动与干系人协同工作，找出他们的需求，识别潜在的

冲突，磋商解决矛盾，系统边界的定义

实质：了解待解决的问题及其所属领域

关键：确保该问题的解决是有商业价值的

29

需求小结

30

需求小结

• 需求分析 目标：对产品及其与环境的交互进行更深入的了解，识别系统

需求，设计软件体系结构，建立需求与体系结构组件间的关联，在体系结构设计实现过程中进一步识别矛盾冲突，并通过干系人之间的协调磋商解决问题。

实质：概念建模—选择常用的建模语言，进行功能建模和信息建模

关键：体系结构设计与需求分配

31

需求小结

• 需求建模

32

需求小结

• 需求规格说明

• 系统与软件需求的文档化，以便于后续的需求及系统的正式评审，而准备的规范化文档。

• 单个需求项的质量• 准确（Concise）• 正确（Correct）• 明确（Non-ambiguous）• 可行（Feasible）• 可证（Verifiable）

• 整个需求集合的质量• 现实（Realistic）• 精确（Concise）• 全面（Complete）• 一致（Consistent）

33

需求小结

• 需求验证

34

需求小结

• 需求管理

35

需求管理

变更控制 版本控制 需求跟踪 需求状态跟踪

• 建议变更• 分析影响• 做出决策• 交流• 合并• 测量需求稳定性

• 确定需求文档版本

• 定义对其他需求的连接链

• 定义对其他系统元素的连接链

• 定义需求状态• 跟踪需求状态

需求小结

• User Story

36

• Card [优先级：xx 工作量估算：]作为一个视频制作者，我希望上传视频到网页，以便于任何其他用户能够在网页上看到这个视频。

•Conversation“上传按钮”会出现在这个网站的每一个网页上视频不能大于100MB或者长于10分钟视频的格式包括.flv,.mov,.mp4,.avi和.mpg能够实时显示上传进度

需求小结

• User Story

37

•Confirmation检查“上传”按钮上传视频的具体操作

1. 检查.flv,.mov,.mp4,.avi和.mpg视频文件是否能上传2. 检查其它视频文件是否不能上传3. 检查视频大于100MB时是否会报错4. 检查视频长于10分钟时是否会报错

检查“上传视频”按钮检查是否能够实时显示上传进度

图书管理系统

建立图书信息管理系统，系统要求实现以下功能：用户管理功能，包括读者信息的录入、修改、更新以及登录书籍管理功能，如书籍的添加、修改、更新、删除等数据维护功能，还可以根据读者借阅书籍的要求随时更新图书馆的书籍数据库书籍的借阅、归还管理、如借还进行详细登记，更新书籍数据库。同时提供图书预定功能信息查询功能，如图书信息查询、用户借书、还书信息查询、书籍库存情况查询等

请根据以上描述，确定执行者及用例，建立系统的用例模型。 38

图书管理系统

• 参与者：管理员和读者；管理员=后台信息维护管理员+图书管理员

• 读者可以查询书籍获得书籍信息。

• 读者可以通过管理员来进行图书的借、还操作

• 图书管理员可以执行借书和还书操作，需要用管理员账号进行登录。

• 信息维护管理员可以进行书籍信息维护和读者信息维护，需要用管理员账号进行登录。

• 书籍信息维护主要包括添加书籍、修改书籍和删除书籍

• 读者信息维护主要包括添加新读者、读者信息修改和读者注销

39

图书管理系统用例图

40

修改书籍

删除书籍

添加书籍

书籍信息维护

信息管理员

读者信息维护

读者修改

读者注销

添加读者

登录

查询书籍

还书

借书

收取罚款

检查读者信息

图书管理员

读者

《include》

《extend》《use》《use》

《use》

《use》

《use》

《use》

用例详细描述

41

用例：登记借书

1. 目标：

本用例允许图书管理员登记普通读者的借书记录

2事件流：

1. 常规流程

当读者希望借书、图书管理员准备登记有关的借书记录时，本用例开始执行。

(1)系统要求管理员输入读者的注册号和所借图书号；(2)图书管理员输入信息后，系统产生一个唯一的借书记录号；(3)系统显示新生成的借书记录；(4)图书管理员确认后，系统增加一个新的借书记录

2. 扩展流程

(1)读者没有注册

在主流程中，如果系统没有读者的注册信息，系统将显示错误信息，用例结束；

(2)所借图书不存在

在主流程中，如果所借图书已被借出或者系统中无该图书，系统将显示错误信息，用例结束。

3前置条件：用例开始前，图书管理员必须在系统登录成功；

4后置条件：如果用例执行成功，该读者的借书记录被更新，否则，系统状态不变。

最终用例模型的提交物

1 用例模型

2 每个用例的详细描述

3 术语表：所用到的术语说明

4 补充规约：非功能性需求的说明

42

用例模型

参与者

用例

...

用例规约

项目作业

•依照“文档模板：软件需求规格说明书”持续更新小组项目规格说明书（10th, October, 2019）

43