CPT203 软件工程开发 笔记

Software Engineering
By Prof. Fazal Rehman Shamil
可以在这个 站速览概念x

Activity Diagram

活动图
菱形表示OR，黑心粗线表AND也表同时开始
黑圆点表程序开始，黑圆点外套圈表程序结束
上方泳道表示不同执行者

解题注意所有动词，副词

形如：

虚线include箭头三角端表示一定被包含在内的活动。

Class Diagram

类图
去除某些潜在类的理由：

Not Retained information，如果潜在类是环境等“Bank，Store”不存储任何信息的对象，则Failed。
Not Needed services，
Single attribute，如果潜在类可为其他类的属性，则Failed，画图时写在类的属性栏里
Synonym，潜在类是别的类的同义词

实心箭头直线端是三角端的子类。

解题步骤先筛选潜在类Potential Classes，再写关系Relationship，最后画图

形如：

Sequence Diagram

老师说期末不考这个
实心箭头表主动，虚线箭头表相应
竖着的虚线表示准备着，竖着的粗线表活动时期

形如：

week1

介绍课程

week1总览
什么是软件工程：
“Computer software is the product that software professionals build and then support over the long term. It encompasses computer programs and associated documentation that execute within a computer of any size and architecture . Software products may be developed for a particular customer or may be developed for a general market.”

两种软件工程：
Generic software products 大众化的通用产品
Customized software products 定制产品

软件工程的四种性质：
Maintainability
Dependability and security
Efficiency
Acceptability

SOFTWARE DETERIORATION软件退化
按理说软件不会产生物理器械那种机械磨损，但是软件与需求紧密相关，随着时间过去，可能有部分设计理念或功能不符合新环境，造成Failure rate的徒增。这使得我们要持续地去维护一个软件

软件工程的开发周期（Software Process）：
Software specification
Software development
Software validation
Software evolution

然后说了开发软件工程很复杂
Software engineering is a systematic approach to the production of software that takes into
account practical cost, schedule, and dependability issues, as well as the needs of software
customers and producers.

最后谈论了道德问题，数据之类的

week2 Software Process

什么是Software Process软件过程：

A software process is a set of related activities that leads to the production of a software product所有软件过程都包含以下活动

1. Fundamental process activities功能性活动：
   Software specification (Requirement engineering)
   Software design and implementation (Software development)
   Software validation (Software testing)
   Software evolution
2. Supporting activities支持性活动：
   Documentation
   Software configuration management
   Risk management

进行以上活动的两种方法：
Sequential approach： specification→development→validation→evolution
Iterative approach：需求什么去做什么，version1.0→2.0→3.0

2 major types of systems：
Critical systems（多指操作系统，采用sequential approach，指需求很明确的那些系统，往往是计划型）
Business systems （采用iterative approach，业务灵活变换，对于这些系统，灵活的process更有效，往往是敏捷型）

2 major types of software process
Plan-driven：计划型 “All process activities are planned in advance”，，采用sequential approach
Agile processes：反应型，“Planning and development is incremental and iterativei” ， 采用terative approach

如何选择相应的方法和模型：
需求是否了解（未来是否会增加新的需求），需求是否会经常变更，迭代版本是否困难（Embedded嵌入式产品迭代成本大），是否有可用的重组模块，开发周期是否紧迫。

Software process models

将项目的进程转换为肉眼可见的软件开发模型，使得对项目的进度和表现更直观，利于管理。
What is software process models/strong>

1. Waterfall model
2. Incremental development
3. Reuse-oriented software engineering
   模型间可以互相组合

Waterfall model瀑布模型

瀑布模型
Plan-driven processes计划型开发，每个环节完成后才进入下一个环节，每个环节都有相应的document使得管理者能更直观的掌握进度，如果环节出问题则返回上一个环节（例如系统测试环节出现问题就返回上一个环节重新测试单元）。在最终环节之后，软件投入正式使用，同时收集错误和新的用户需求，系统必须不断发展，某些更新可能会重复之前的过程。

因为文档的生成和批准成本和大量返工成本，进行少量迭代后可将部分环节冻结（如第一个环节），节约不必要耗费的资源。（但是过早冻结部分环节会使系统无法实施部分用户需求）。

优点：

1. 当委托别的公司开发软件时，瀑布模型很有用，可以提供formal and complete documentation,发生纠纷时很好用。
2. for large,complex, long-lifetime systems 对于长期维护的项目，documentation能提供长久的维护支持

缺点：

1. the inflexible partitioning of the project into distinct stages.
2. Commitments must be made at an early stage in the process, which makes it difficult to respond to changing customer requirements.

In principle, the waterfall model should only be used when the requirements are well
understood and unlikely to change radically during system development.

Reuse-oriented software engineering 面向复用的软件开发

译文：面向复用的软件开发
原文：software reuse oriented software engineering

使用可重用组件(reusable component)和集成框架进行改造（继承、适配）、配置、拼装、组合等手段完成软件的局部功能开发。

因为大部分组件是由第三方开发，所以第三环节需要对原本的需求进行修订

可复用组件的三大分类：

1. Web services that are developed according to service standards and which are available for remote invocation.
2. Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE.
3. Stand-alone software systems that are configured for use in a particular environment.

优点：

1. reducing the amount of software to be developed and so reducing cost and risks.
2. usually also leads to faster delivery of the software.

缺点：

1. requirements compromises are inevitable and this may lead to a system that does not meet the real needs of users.

2. Software Design and Implementation
   定义：the process of converting a system specification into an executable system将软件规范转换为可执行软件
   目标：A software design is a description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used.

设计的输出因模型和系统而异，如果是critical system，因该编写详细的文档和系统描述；如果使用了model-driven，设计结果可能是图表；如果使用agile methods，设计结果可能体现在代码中

4. Software Evolution
   硬件的更改要比软件的更改更加复杂
   人们认为软件开发software development和软件维护software evolution (software maintenance)是分开的。
   总之，与其分开考虑，还是考虑软件工程更为现实。

week3 Agile Framework敏捷开发

什么是RAPID SOFTWARE DEVELOPMENT：

• The software is not developed as a single unit but as a series of increments,
  with each increment including new system functionality.
  .
  Fundamental characteristics功能特性：
  The processes are interleaved交错.
  Minimum documentation极少的文档，而不是没有文档
  Developed in a series of versions, or increments, with system stakeholders involvement.
  System user interfaces are often developed using an interactive development system that allows the interface design to be quickly created

为什么需要RAPID SOFTWARE DEVELOPMENT：

• Businesses now operate in a global, rapidly changing environment. They have to respond to new opportunities and markets, changing economic conditions, and the emergence of competing products and services
  简单来说就是快速做出雏形，快速部署到实际应用，让客户知道软件的作用效果，根具实际体验得到的改进建议和问题改进

之前研究的计划驱动过于冗长，不适应这种需要快速出效果的软件：
PLAN-DRIVEN DEVELOPMENT APPROACH计划驱动实现
适用于大型长期维护软件，如需要多团队合作研发；需要研发出一个严格系统；有许多不同的人参加维护
Large, long lived software – careful project planning, formalized quality assurance, the use of analysis and design methods supported by CASE tools, and controlled and rigorous software development processes

AGILE METHODS 敏捷开发方法

1. 更专注于软件，而不是设计和文档
2. 普遍依赖于incremental approach
3. 非常适合于需求在开发周期内频繁变化的情况，欢迎变更需求
4. 目的在于快速交出第一代软件，收到新的需求和回馈后，应用到系统迭代中

Agile manifesto 敏捷宣言：（br> Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

敏捷开发在施行时会遇到的不如人意之处：

1. 理想中的客户是乐于花时间和开发团队交换意见的，并且可以掌大权(represent all system stakeholders)
2. 个体开发人员要经验充足，同时确保设计和程序和质量
3. 更新优先级很难抉择，尤其是权力分散的客户(没法一语成谶）
4. 保持简化需要额外工作(最简单的是最难的）
5. 客户可能需要的是完整的，有文档的，设计明确的开发流程和产品
6. 软件需求文档是大多合同要求之一
7. 增量方法是敏捷开发固有的，合同会比较难写
8. 敏捷开发必须依赖于合同，费用应该算上开发所用时间，而不是一组特定的需求
9. 如果出现问题，很难追查责任人

如何考虑是否使用敏捷开发：

1. Are systems that are developed using an agile approach maintainable, given the emphasis in the development process of minimizing formal documentation/li>
2. Can agile methods be used effectively for evolving a system in response to customer change requests/li>

敏捷开发的维护：

1. 敏捷开发支持者认为文档不重要
2. 重要的是代码的质量和易读性
3. 系统需求文档是关键文档，可以告诉工程师系统应该做到什么
4. 客户需要投入维护
5. 没有详细文档，代码理解会基于团队成员本身的理解。当人员发生变动，新人员很难理解系统

混合使用计划型驱动和敏捷开发（这个问 忒抽象了

(PPT 上的ForecastCommitment不是这学期内容）

Product Backlog{

product owner负责根据团队和利益相关人的消息，然后确定和管理工程（product backlog items）的顺序，以优先级列表prioritized list的形式表现，称为product backlog。

product backlog grooming：
创建和细化(询问详细)产品待办事项、对其进行评估并确定其优先级的活动称为梳理
The activity of creating and refining product backlog items, estimating them, and prioritizing them is known as grooming
因为需求会变，所以一开始的梳理只梳理顶层

PBI Example{
用户说的需求，用户的描述，验收标准
product owner需要对以下PBI排列优先级并告知达成这个需求需要的时间

}

Sprint Planning{在sprint开始前

1. PBI可能代表数周或数月的工作。为了完成PBI中的所有项目，需要进行一系列的sprint
2. 为了确定要在下一个sprint中构建的最重要的PBI子集，product owner、开发团队和ScrumMaster执行sprint规划
3. 在sprint规划期间，product owner和开发团队就sprint目标达成一致，该目标定义了即将到来的sprint应该实现的目标
4. 基于sprint目标，开发团队审查PBI，并确定团队可以在即将到来的sprint中以可持续的速度实际完成的高优先级项目
5. 许多团队将每个目标拆分成小任务，这些小任务被称为sprint backlog
1. Functional requirements： These are statements of services the system should provide. How the services should react and behave in certain condition. In some cases, the functional requirements may also explicitly state what the system should not do。
2. Non-functional requirements These are constraints on the services or functions offered by the system. Non-functional requirements often apply to the system as a whole, rather than individual system features or services.

Non-functional Requirement

1. Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific services delivered by the system to its users.非功能性需求是与系统提供的服务不直接相关的需求
• System properties系统属性： such as reliability, response time, and store occupancy.
• Constraints on the system implementation系统评估标准： such as performance, security, or availability.
2. 通常将系统作为约束评估的整体，实现非功能性需求往往比实现单个具体功能更关键，未达成某一个非功能性需求可能会使整个系统不可用
3. The implementation of non-functional requirements may be intricately disperse throughout the system.
   非功能性需求的实现分散
   They may affect the overall architecture of a system rather than the individual components.影响整个架构
   A single non-functional requirement may generate a number of related functional requirements.会牵扯出大量相关性的功能性需求