EagleBear2002 的博客

本文主要内容来自 SpriCoder的博客，更换了更清晰的图片并对原文的疏漏做了补充和修正。

内聚和耦合概念重要

1. 内聚：内聚表达的是一个模块内部的联系的紧密型：包括信息内聚、功能内聚、通信内聚、过程内聚、时间内聚、逻辑内聚和偶然内聚。

1
2
3
4
5

public class Rous {
    public static int findPattern(String text, String pattern)
    public static int average(Vector numbers)
    public static OutputStream openFile(String fileName)
}

2. 耦合：耦合描述的是两个模块之间关系的复杂程度：包括内容耦合，公共耦合，重复耦合，控制耦合，印记耦合，数据耦合

本文主要内容来自 SpriCoder的博客，更换了更清晰的图片并对原文的疏漏做了补充和修正。

详细设计基础

1. 详细设计的出发点：软件详细设计是在软件体系结构设计之后进行，以需求开发的结果（需求规格说明和需求分析模型）和软件体系结构的结果（软件体系结构设计方案与原型）为出发点。

什么是详细设计

1. 中层设计是对特定的模块的，以及针对特定模块的对象/类的低级设计

本文主要内容来自 SpriCoder的博客，更换了更清晰的图片并对原文的疏漏做了补充和修正。

用户和不好的设计

1. 系统用户通常通过系统界面而非功能来判断系统：用户界面的设计应与预期用户的技能，经验和期望相匹配。
2. 界面设计不当会导致用户发生灾难性错误：不好的 UI 的设计往往是很多软件系统不被使用的原因。
3. IPAD 的良好的体验感和可操作性，而早期的 Andriod 操作系统则主要是从工程师角度出发的操作系统。
4. 比如医院书写病历：老医生打字困难，所以我们我们应该针对性的进行设计。

什么是人机交互设计（HCI)

本文主要内容来自 SpriCoder的博客，更换了更清晰的图片并对原文的疏漏做了补充和修正。

体系结构设计过程（简略步骤） 重要

1. 分析关键需求和项目约束：分析用例文档和需求规格说明书（包含需求规格和项目约束）。注意既要考虑功能性需求，又要考虑非功能性需求，甚至很大意义上体系结构设计是为了满足非功能性需求。
2. 通过选择体系结构风格：选择分层风格（信息系统、并行开发、非 web 应用），进行评审。
3. 进行软件体系结构逻辑（抽象）设计：产生逻辑包图
4. 依赖逻辑设计进行软件体系结构（实现）设计：产生物理类图
5. 完善体系结构设计：关键类图，持久化数据格式的定义等
6. 添加构件接口：包、重要文件的创建，定义接口
7. 迭代过程 3-6

1. 步骤 1-3 是逻辑设计，步骤 4-7 是物理设计
2. 本文接下来的部分将要按照这个思路进行下去

第一步：分析关键需求和项目约束

本文主要内容来自 SpriCoder的博客，更换了更清晰的图片并对原文的疏漏做了补充和修正。

软件体系结构

1. 1969 年出现软件体系结构
2. 历史部分了解即可

Until the late 1980 直到 1980 年底

1. 从那时到 1980 年代后期，“体系结构”一词的使用主要是指系统体系结构（即计算机系统的物理结构），或者有时是指给定的一系列计算机指令集的狭义含义。
2. 有关软件系统组织的主要信息来自 1975 年的 Fred Brooks，1983 年的 Butler Lampson，1972 年至 1986 年的 David Parnas 以及 1985 年的 John Mills（其文章着眼于架构的过程和实用性）。

本文主要内容来自 SpriCoder的博客，更换了更清晰的图片并对原文的疏漏做了补充和修正。

什么是软件设计

软件设计重要

1. 软件设计是指关于软件对象的设计，是一种设计活动。软件设计既指软件对象实现的规格说明，又指这个规格说明产生的过程。
2. 软件设计活动以需求开发的制品（需求规格说明和分析模型）为基础，构建软件设计方案描述和原型，为后期的构造活动提供规划或蓝图。
3. 软件设计兼具工程性和艺术性，由于软件系统的可变性，软件设计具有演化性，也因为软件设计的过程实际上就是一系列决策发生的过程，软件设计具有决策性。

软件设计的核心思想

本文主要内容来自 SpriCoder的博客，更换了更清晰的图片并对原文的疏漏做了补充和修正。

为什么文档化需求

1. 方便团队工作和沟通
2. 方便项目管理
3. 更加明确的体系架构
4. 方便软件设计
5. 方便编码
6. 方便维护

为什么建立需求规格说明？结合试验说明重要

1. 方便交流，软件开发过程中，子任务与人员之间存在错综复杂的关系，存在大量的沟通和交流，所以要编写软件开发中要编写不同类型的文档，每种文档都是针对项目中需要广泛交流的内容。因为软件需求需要进行广泛交流，所以要把需求文档化。
2. 需求规格说明是在软件产品的角度以系统级需求列表的方式描述软件系统解决方案，书写需求规格说明，可以建立管理控制的基线，方便任务分配，制定工作计划，进行跟踪和度量。
3. 在实验中，需求规格的重要性不只体现在结果上，还包括中间过程，在书写需求规格过程中，才真正把问题域的问题和分析模型的成果转化为系统级需求，方便小组成员真正明确需求，个人认为在这个阶段包含一部分的需求在发现和完整化。

本文主要内容来自 SpriCoder的博客，更换了更清晰的图片并对原文的疏漏做了补充和修正。

用例文档的格式情况

需求分析基础

为什么要需求分析

本文主要内容来自 SpriCoder的博客，更换了更清晰的图片并对原文的疏漏做了补充和修正。

软件需求是一个连接现实世界与计算机世界的活动:它既需要从问题出发，分析问题域，研究解决问题所需要的互动效应。

一个产品的开发过程

1. 客户想要什么
2. 产品经理理解
3. 设计师分析
4. 程序员进行编写
5. 交给测试人员测试
6. 商业人员描述这个产品
7. 项目的文档
8. 如何进行部署
9. 价格像过山车一样变化
10. 如何进行支持运维
11. 进行广告宣传
12. 最后使用用户需要什么

需求工程的内容

本文主要内容来自 SpriCoder的博客，更换了更清晰的图片并对原文的疏漏做了补充和修正。

项目和项目管理

项目的核心是计划：计划包括项目需要的资源、活动，以及在项目中需要产生的中间交付产品。

项目

1. 项目是具有下列特征的一系列活动和任务[Kerzner2009]
   • 具有一个明确的目标；
   • 有限定的开始和结束日期；
   • 有成本限制；
   • 消耗人力和非人力资源；
   • 多工种合作。
2. 项目管理的目标
   • 在限定时间内；
   • 在一定的成本内；
   • 在要求的质量水平上；
   • 高效使用资源；
   • 获得客户认可。
3. 过程组：项目启动、项目计划、项目执行，项目跟踪与控制和项目收尾
4. 活动：计划制定、团队管理、成本控制、质量保障、度量、过程管理、进度跟踪与控制、风险管理、配置管理