软件工程实践Review

软件工程实践Review

目录：

1. 软件工程介绍
2. 软件过程综述
3. 过程模型
4. 软件需求工程
5. 构建分析模型
6. 设计工程
7. 启发式测试

1. 软件工程介绍

概念： 计算机软件是由专业人员开发并长期维护的软件产品。

重要性：在我们生活中无处不在，并且普遍深入到商业、文化和日常生活多个方面。

软件产品：从软件工程观点来看，最终产品是计算机软件（包括程序、内容—数据和文档）。

软件角色的演化：

软件技术具有产品和产品生成载体的双重作用

软件扮演着信息转换的角色-生成、管理、查询、修改、现实或者传递各种不同的信息

软件开发人员面临的问题：

为什么软件需要如此长的开发时间

为什么开发成本居高不下

软件开发人员面临的问题：

为什么软件需要如此长的开发时间

为什么开发成本居高不下

Software Crisis：

7个症状（成本&进度、客户需求不满意、质量不过关、维护度低、无适当的文档、成本不断提高、生产率赶不上硬件和人民的需求）

导致危机的原因-Relative to the unsuitable method of software development and maintenance ;The specific features of software

Software Features：

是开发的不是制造的；柔性；不磨损；成本昂贵；

软件工程的定义：

（1）把系统的、规范的、 可度量的途径应用于软件开发、运行和 维护过程，也就是把工程应用于软件；

（2）研究（1）中提到的途径

两个显著特征：
关注normalization; 关注documenting

传统方法学特点：
面向对象方法学特点：
软件生命周期：

软件实践规则：The Reason It All Exists/Keep it Simple, Stupid/Maintain the Vision/What you produce, Other Will Consume/Be Open to the Future/Plan Ahead for Reuse/Think

2. 软件过程综述

什么是软件过程：as a framework for the tasks that are required to build high-quality software

A Layered Technology

软件过程：是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

过程的重要性：

They impose consistency and structure on a set of activities

They enable us to capture our experiences and pass them along to others

框架活动：
Communication
Planning
Modeling
Analysis of requirements
Design
Construction
Code generation
Testing
Deployment
Umbrella Activities：Software project management
Formal technical reviews
Software quality assurance
Software configuration management
Work product preparation and production
Reusability management
Measurement
Risk management

3. 过程模型

为什么要过程建模：

Help the team understand the gap between what should be and what is.
Form a common understanding of the activities, resource, and constraints involved in software development.
Help the team find inconsistencies, redundancies, and omissions in the process and in its constituent parts.
Help the team evaluate candidate activities for their appropriateness in addressing these goals.
Help the team understand where that tailoring is to occur.

Prescriptive Models
Waterfall Model
Prototyping Model

抛弃型原型
演化型原型
敏捷过程

Operational Specification Model
Transformational Model
Incremental model
Spiral Model
Unified Process
UP Phases

无论哪种软件过程模型，软件开发过程都要经历三个典型阶段：

定义 Definition

开发 Development

维护 Maintenance

4.需求工程

To introduce the concepts of user and system requirements

To describe functional and non-functional requirements

To explain how software requirements may be organized in a requirements document

需求分析为什么困难 ：

（1）客户说不清楚需求；

（2）需求自身经常变动；

（3）分析人员或客户理解有误。 

需求工程涉及人员：

Types of requirement：

User requirements
System requirements
Functional and non-functional requirements：
Functional requirements
Non-functional requirements
Domain requirements

为什么要用工具来描述需求

描述需求的工具(方法)有：

Structured presentation
Form-based node specification
Tabular specification
Graphical models
Interface specification

The requirements document is the official statement of what is required of the system developers.
Should include both a definition of user requirements and a specification of the system requirements.
It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it

一个软件系统 的需求描述了系统应该做什么以及定义系统运行时和实现时的约束。
功能需求是有关系统一定要提供的服务或者是必须执行的计算的描述。领域需求是起源于其应用领域特性的功能需求。
非功能需求约束所开发的系统和所采用的开发过程.它们可能是产品需求、机构需求或者是外部需求。这些需求与系统的总体特性相关，且作用于系统整体。
用户需求是为面向购买和使用系统的用户而写的。应该使用自然语言、表格或图标的形式给出，以便用户理解。

Requirements engineering process:
Feasibility studies 可行性研究
Requirements elicitation and analysis 需求导出和分析
Requirements validation 需求有效性验证
Requirements management 需求管理

1. Requirements discovery
需求发现
2. Requirements classification and organization
需求分类和组织
3. Prioritization and negotiation
优先排序和冲突解决
4. Requirements documentation
需求文档的编制

在建模过程中了解系统
通过抽象降低复杂性
有助于回忆所有的细节
有助于开发小组间的交流
有助于与用户的交流
为系统的维护提供文档

通常建立的三种形式的模型：

描述系统数据结构的对象模型(最核心。类和对象之间的关系。)

描述系统控制结构的动态模型

描述系统功能的功能模型

分析模型

对象模型: 描述静态结构, 定义做事情的实体

功能模型: 描述处理(数据变换), 指明系统应“做什么”

动态模型: 描述交互过程, 规定什么时候做


步骤：

(1)找出对象及其关联

(2)赋予类及关联的属性数据

(3)组织类的结构

5. 构建分析模型

关键概念Key concepts：

类、对象Classes and objects
属性、操作Attributes and operations
封装、实例化Encapsulation and instantiation
继承Inheritance
基于场景的建模：（用例，活动，泳道）

【用例】是一种定义了系统以外所存在的(参与者)和系统怎样相应(用例)的辅助方法。
(1) What should we write about?
(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description?


一个场景描述了一个系统的“使用线索”
参与者代表了使用系统某些功能的人或者设备
actors represent roles people or devices play as the system functions
针对某一个给定的场景用户能扮演多个角色
users can play a number of different roles for a given scenario


参与者所扮演的主要任务或者功能是什么？
系统的那些信息将被参与者获取、处理、变更？
是否参与者必须通知系统关于外部环境的变化？
参与者希望从系统到什么信息？
是否参与者希望被告知意外的变更？


基于类的建模（类图）
通过检查问题的陈诉，识别分析类
使用“语法分析”分理出潜在类
识别每一个类的属性
识别这些属性的操作
CRC建模
行为建模(状态图、时序图)
撰写需求规格说明书

6. 设计工程

Conceptual Design and Technical Design
Software Engineering Design
Characteristics of Good Design
Design Process & Design Quality
Design Concepts
Design Model
Pattern-Based Software Design


Conceptual design tells the customer what the system will do
Technical design tells the programmers what the system will do
Characteristics of good conceptual design
in customer language with no technical jargon
describes system functions
independent of implementation
linked to requirements
Technical design Includes:
major hardware components and their function
hierarchy and function of software components
data structures
data flow

abstraction—data, procedure, control
architecture—the overall structure of the software
patterns—”conveys the essence” of a proven design solution
modularity—compartmentalization of data and function
hiding—controlled interfaces
functional independence—single-minded function and low coupling
refinement—elaboration of detail for all abstractions
refactoring—a reorganization technique that simplifies the design


Data Abstraction
Procedural Abstraction
Architecture
Patterns
Decomposition and Modularity


Five ways to create designs:
Modular decomposition
based on assigning functions to components
Data-oriented decomposition
Based on external data structure.
Event-oriented decomposition
Based on DFD
Outside-in design
Based on user inputs to the system
Object-oriented design


Information Hiding
Stepwise Refinement
Functional Independence


目标：

high cohesion, low coupling
高内聚，低耦合


Three design levels:
Architecture: associates system components with capabilities
Code design: specifies algorithms and data structures for each component
Executable design: lowest level of design, including memory allocation, data formats


OO Design Concepts：
Design classes
Entity classes
Boundary classes
Controller classes
Inheritance—all responsibilities of a superclass is immediately inherited by all subclasses
Messages—stimulate some behavior to occur in the receiving object
Polymorphism—a characteristic that greatly reduces the effort required to extend the design

7. 启发式测试

什么是一个好的测试？

A good test has a high probability of finding an error
A good test is not redundant.
A good test should be “best of breed”
A good test should be neither too simple nor too complex