软件工程-课后讨论题

?????1-1软件工程概论

一、软件的基本概念、分类与基本特征。

 二、软件工程产生的根源/h2>

三、软件工程的基本概念/h2>

四、阅读布鲁克斯(Brooks, F. P.)的著作：《人月神话》、《没有银弹》等著作，结合以前的学习和实践，谈一下体会， 独立撰写不低于3000字的总结 告。（第三周交电子版）

1-2 软件工程核心思想

一、软件工程的本质/h2>

 二、软件工程关注的目标/h2>

三、软件开发中的不同角色/h2>

四、IBM RUP最佳实践原则/h2>

五、软件工程的核心概念

2-1 软件过程模型

一、什么是软件过程件过程包括哪些基本内容/h2>

二、典型的软件过程模型析一下每一种模型的优缺点/h2>

三、分析给出的案例，针对不同情况选择哪些合适的模型为什么/h2>

 四、结合以前的学习和实践，你用过哪些模型何体会/h2>

2-2 敏捷过程与方法

第二次作业

2-3 软件项目管理

项目管理的关键要素/h2>

答案：

              人员、过程、产品和工具等

项目管理通常使用“产品结构分解(Product Breakdown Structure, PBS)”作为产品分解的工具，其基本原理是什么/h2>

PBS：通过分层的树型结构来定义和组织项目范围内的所有产出物(产品)，自顶向下，逐级细分；

产出物：项目结束时需要提交的最终产品，在项目之初就可以准确的预计。

 

项目管理的主要关注点和任务有哪些/h2>

项目关注的四个方面

1. 1. 范围(Scope)
   2. 时间(Time)
   3. 成本(Cost)
   4. 质量(Quality)

项目管理的主要任务

1. 1. 项目可行性分析与估算
   2. 项目进度安排
   3. 项目风险管理
   4. 项目质量管理
   5. 项目跟踪与控制

 

项目管理的基本原则有哪些/h2>

项目管理通常采用何种方式来描述任务的进度安排/h2>

软件项目质量管理的核心要素有哪些/h2>

1. 项目质量管理的核心要素

（1）功能性；

（2）可信性（可靠性、可用性、安全性、保密性）；

（3）易使用性；

（4）可维护性

（5）可移植性

如果由你作为BOSS负责一个项目，怎么选择 “合适” 的团队模式不同的团队模式如何影响团结绩效的评估据什么来评估每个团队成员的产出/h2>

2-4 软件演化与配置管理

第四次作业

3-1 代码评审分析与优化

无

3-2 软件测试

第五次作业

4-1 软件设计与架构概论

什么是软件设计件设计在SE中所处哪个位置/h2>

软件设计：为问题域的外部可见行为的规约增添实际的计算机系统实现所需的细节，包括关于人机交互、任务管理和数据管理的细节。

软件设计的主要内容包括哪些/h2>

微服务架构的基本标准有哪些/h2>

微服务的基本标准

1、分布式服务组成的系统；

2、按照业务，而不是技术来划分组织；

3、做有生命的产品而不是仅仅针对项目；

4、强服务个体和弱通信（ Smart endpoints and dumb pipes ）；

5、自动化运维（ DevOps ）；

6、高度容错性；

7、快速演化和迭代。

四、请介绍一下软件架构的核心概念/h2>

五、软件架构的核心思想有哪些/h2>

4-3 基本架构风格

• 软件架构风格划分为哪几个层次/li>

软件方面的架构风格（模式）

分为三个层次：代码模式、设计模式、架构模式。

代码模式也可以说是编码时的套路，一些技巧,是最低层次的套路。只能影响某一方法或类中的一些细节。

设计模式解决了一般性的设计问题，影响一个模块内部,是中等层次的重用策略。

架构模式最高层层次的重用策略，实现定义好一些子系统、层，指定他们的责任，并给出把它们组织在一起的法则和指南。

• C/S+B/S混合模式遵循的原则/li>

不管用户处于企业内外什么位置(局域 或Internet)，凡是需要对数据进行更新操作的(Add, Delete, Update)，都需要使用C/S结构；如果只是执行一般的查询与浏览操作(Read/Query)， 则使用B/S结构。

• 简要介绍事件系统的基本构成与实现策略。

事件风格的实现策略之一：选择广播式，有目的广播，只发送给那些已经注册过的订阅者。

事件风格的实现策略之二：观察者模式，发布-订阅模式（Publish/Subscribe）

4-4 面向NFR的架构设计思想与案例

MMO课后讨论

5-1 软件需求与需求获取

• 软件需求有哪些作用/li>

●充分理解现实中的业务问题，并作为软件设计的基础;

●为软件项目的成本、时间、风险估计提供准确的依据;

●减少开发工作量，避免将时间与资源浪费在设计与实现错误的需求上;

●通过提供需求文档和需求基线，来有效的管理系统演化与变更;

●作为顾客与开发团队之间正式合同的一部分;

●为最终的验收测试提供标准和依据;

• 软件需求有哪些/li>

• 产生不合格需求的原因有哪些/li>

答案：

无用户参与；

用户需求的不断增加；

模棱两可的需求；

不必要的特性；

过于精简的规格说明；

忽略了用户分类；

不准确的计划

…….

• 简要介绍需求获取的基本步骤/li>

• 第1步：了解相关背景和领域/行业的知识，确定产品所期望的用户类；
• 第2步：与客户企业或组织的高层人员进行交流，了解实际用户任务和目标以及这些任务所支持的业务需求；
• 第3步：与客户企业或组织的底层人员进行交流，获取每个用户类的详细的用户需求；
• 第4步：整理需求纪要，发现新问题，并重复1-3步；
• 第5步：需求分类和组织，以区别功能需求、非功能需求、约束条件、业务规则、外部接口需求、建议解决方法和附加信息；
• 第6步：优先排序和冲突解决；
• 第7步：得到最终需求清单，并与客户做最终签字确认。

5-2 用户故事与用例建模

• 什么是用户故事户故事的由哪些内容构成/li>

用户故事：

从用户的角度来描述用户渴望得到的功能：角色(谁要使用这个功能)、目标/活动(需要完成什么样的功能)、商业价值(为什么需要这个功能，这个功能带来什么样的价值)。

三个组成部分：（3C）

Card（卡片）简要的文本陈述

Conversation（交谈）用户如何与系统交互

Confirmation（确认）如何验证和测试。

• 好的用户故事具备哪些特征/li>

好的用户故事应具备的特征：INVEST

• Independent – 尽可能独立；
• Negotiable – 可讨论的。它不是一个合同，没有详细的规约，后续开发阶段可以不断协商和改进；
• Valuable – 对用户/客户有价值的，以用户可理解的语言书写，是系统的“特性”而非“开发任务”；
• Estimatable – 其工作量可以估计；
• Small – 小，而不是大；
• Testable – 可测试的、可验证的。

• 面向对象软件开发方法中的用例具有哪些特征/li>

四大特征：

• 1. 行为序列(sequences of actions)：一个用例由一组可产生某些特定结果的行为构成，这些行为是不可再分解的(接收用户输入、执行、产生结果)
  2. 系统执行(system performs)：系统为外部角色提供服务；
  3. 可观测到的、有价值的结果(observable result of value)：用例必须对用户产生价值；
  4. 特定的角色(particular actor)：某人、某台设备、某外部系统、等等，能够触发某些行为。
• 用例模型由哪些元素构成/li>

用例模型主要由以下模型元素构成：

• 1. 参与者(Actor) ：存在于被定义系统外部并与该系统发生交互的人或其他系统，代表系统的使用者或使用环境。
  2. 用例(Use Case)
  3. 通讯关联(Communication Association) ：用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务(用例)、系统所提供的服务(用例)是被哪些参与者所使用的。
• 简要阐述用例建模的基本过程/li>

Step 1：识别并描述参与者(actor)；

Step 2：识别用例(use case)，并给出简要描述；

Step 3：识别参与者与角色之间的通讯关联(Association)；

Step 4：给出每一个用例的详细描述

Step 5：细化用例模型

6-1 面向对象的基本概念

已知知识

6-2 面向对象的分析与设计

第七次作业

6-3 面向NFR的OO设计原则

没啥东西