这是我参与「第五届青训营 」伴学笔记创作活动的第9天！
本篇文章主要就软件工程基础、需求、系统设计三个维度回顾整理课堂笔记。
一、软工基础知识
1.1 软工基本原理
用分阶段的生命周期计划严格管理、坚持进行阶段评审、实现严格的产品控制、采用现代程序设计技术、结果应能清楚的审查、开发小组的人员应少而精、承认不断改进软件工程实践的必要性。
1.2 软工的基本要素 ⭐
方法、工具、过程。
1.3 什么是信息系统生命周期？
- 系统规划：撰写可行性研究报告、系统设计任务书。
- 系统分析：撰写系统说明书。
- 系统设计：撰写系统设计说明书（概要设计、详细设计说明书）⭐
- 系统实施：撰写实施进展报告、系统测试分析报告。⭐
- 系统运行和维护：系统投入运行后，需要经常进行维护和评价，记录系统运行的情况，根据一定的 规则对系统进行必要的修改，评价系统的工作质量和经济效益。
1.4 软件生存周期
可行性分析与项目开发计划、需求分析、概要设计(选择系统解决方案，规划子系统)、详细设计(设计子系统内部具体实现)、编码、测试、维护。
二、软件开发方法
2.1 结构化方法主要特点
结构是指系统内各个组成要素之间的相互联系、相互作用的框架。结构化方法也称为生命周期法，是一种传统的信息系统开发方法，由结构化分析(Structured Analysis,SA)、结构化设计(StructuredDesign, SD) 和 结构化程序设计(Structured Programming,SP) 三部分有机组合而成，其精髓是自顶向下、逐步求精和模块化设计。
- 开发目标清晰化。结构化方法的系统开发遵循"用户第一"的原则。
- 开发工作阶段化。每个阶段工作完成后，要根据阶段工作目标和要求进行审查，这使各阶段工作有条不紊地进行，便于项目管理与控制。
- 开发文档规范化。结构化方法每个阶段工作完成后，要按照要求完成相应的文档，以保证各个工作阶段的衔接与系统维护工作的遍历。
- 设计方法结构化。在系统分析与设计时，从整体和全局考虑，自顶向下地分解;在系统实现时，根据设 计的要求，先编写各个具体的功能模块，然后自底向上逐步实现整个系统。
2.2 结构化方法的不足和局限
- 开发周期长: 按顺序经历各个阶段，直到实施阶段结束后，用户才能使用系统。
- 难以适应需求变化: 不适用于需求不明确或经常变更的项目。
- 很少考虑数据结构: 结构化方法是一种面向数据流的开发方法，很少考虑数据结构。
2.3 结构化方法常用工具
结构化方法一般利用图形表达用户需求，常用工具有数据流图、数据字典、结构化语言、判定表以及判定树等。
2.4 面向对象方法特点
面向对象( Object-Oriented, OO )方法认为，客观世界是由各种对象组成的，任何事物都是对象，每个对象都有自己的运动规律和内部状态，都属于某个对象类，是该对象类的一个元素。复杂的对象可由相对简单的各种对象以某种方式而构成，不同对象的组合及相互作用就构成了系统。
- 使用 OO 方法构造的系统具有更好的复用性，其关键在于建立一个全面、合理、统一的模型（用例模型 和分析模型)。
- OO 方法也划分阶段，但其中的系统分析、系统设计和系统实现三个阶段之间已经没有"缝隙"。也就是说，这三个阶段的界限变得不明确，某项工作既可以在前一个阶段完成，也可以在后一个阶段完成;前一个阶段工作做得不够细，在后一个阶段可以补充。
- 面向对象方法可以普遍适用于各类信息系统的开发。
2.5 面向对象方法的不足之处
必须依靠一定的面向对象技术支持，在大型项目的开发上具有一定的局限性，不能涉足系统分析以前的开发环节。
当前，一些大型信息系统的开发，通常是将结构化方法和 OO 方法结合起来。首先，使用结构化方法进行自顶向下的整体划分;然后，自底向上地采用 OO 方法进行开发。因此，结构化方法和 oo 方法仍是两种在系统开发领域中相互依存的、不可替代的方法。
2.6 软件系统工具
1. 按软件过程活动将软件工具分为:
- 软件开发工具:需求分析工具、设计工具、编码与排错工具。
- 软件维护工具:版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
- 软件管理和软件支持工具:项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。
2.7 需求的层次⭐⭐
- 业务需求: 反映企业或客户对系统高层次的目标要求，通常来自项目投资人、客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。
- 用户需求: 描述的是用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。
- 系统需求: 从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
- 功能需求: 也称为行为需求，规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。
- 非功能需求:指系统必须具备的属性或品质，又可以细分为软件质量属性（如可维护性、可靠性、效率等）和其他非功能需求。
- 设计约束:也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在 UNIX 操作系统之下等。
2.8 需求分析
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
需求分析的任务:
- 绘制系统上下文范围关系图。
- 创建用户界面原型战。
- 分析需求的可行性。
- 确定需求的优先级。
- 为需求建立模型。
- 创建数据字典。
- 使用 QFD (质量功能部署)。
结构化的需求分析⭐⭐⭐
- 结构化特点: 自顶向下，逐步分解，面向数据。
- 三大模型︰功能模型（数据流图)、行为模型（状态转换图)、数据模型(E-R图)以及数据字典。
三、系统设计
3.1 业务流程建模
- 标杆瞄准:以行业领先的标杆企业为目标，结合本企业情况分析建模。
- IDEF(一系列建模、分析和仿真方法的统称)。
- DEMO(组织动态本质建模法)。
- Petri 网。
- 业务流程建模语言: BPEL 、 BPML 、 BPMN 、XPD L。
- 基于服务的 BPM : 基于 web 服务的思想对业务流程进行建模。
3.1.1 流程表示工具⭐
- 程序流程图(Program Flow Diagram，PFD)用一些图框表示各种操作，它独立于任何一种程序设计语言，比较直观、清晰，易于学习掌握。任何复杂的程序流程图都应该由顺序、选择和循环结构组合或嵌套而成。
- IPO 图也是流程描述工具，用来描述构成软件系统的每个模块的输入、输出和数据加工。
- N-S 图容易表示嵌套和层次关系，并具有强烈的结构化特征。但是当问题很复杂时，N-S 图可能很大，因此不适合于复杂程序的设计。
- 问题分析图( PAD )是一种支持结构化程序设计的图形工具。 PAD 具有清晰的逻辑结构、标准化的图形等优点，更重要的是，它引导设计人员使用结构化程序设计方法，从而提高程序的质量。
3.2 系统设计
主要目的：为系统制定蓝图
- 在各种技术和实施方法中权衡利弊。
- 精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方法。
3.2.1 方法⭐
结构化设计方法，面向对象设计方法。
3.2.2主要内容⭐⭐⭐⭐
- 概要设计:又称为系统总体结构设计，是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。
- 详细设计:模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计(代码、输入/输出格式、用户界面)、编写详细设计说明书、评审。
3.3系统设计基本原理⭐
- 抽象化;
- 自顶而下，逐步求精:微衣信息隐蔽;
- 模块独立(高内聚，低耦合)。
3.4 系统设计原则⭐
- 保持模块的大小适中;
- 尽可能减少调用的深度;
- 多扇入，少扇出;
- 单入口，单出口;
- 模块的作用域应该在模块之内;
- 功能应该是可预测的。
3.5 人机界面设计
3.5.1 三大原则⭐
1. 置于用户控制之下
- 以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式;
- 提供灵活的交互;
- 允许用户交互可以被中断和取消;
- 当技能级别增加时可以使交互流水化并允许定制交互;
- 使用户隔离内部技术细节;
- 设计应允许用户和出现在屏幕上的对象直接交互。
2.减少用户的记忆负担
- 减少对短期记忆的要求;
- 建立有意义的缺省;
- 定义直觉性的捷径;
- 界面的视觉布局应该基于真实世界的隐喻;
- 以不断进展的方式揭示信息。
3.保持界面的一致性。
- 允许用户将当前任务放入有意义的语境;
- 在应用系列内保持一致性
- 如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要去改变它。
结尾
软件工程的原理思想一定要牢记，做好这一步后来的路就会顺畅很多，还需要花时间去梳理软件设计的条例框架。
综上，今天又是学习的一天！😊
