系统分析与设计001

1、简单题

• 软件工程的定义

From Wikipedia

Software Engineering is the application of engineering to the development of software in a systematic method.
软件工程是以系统的方法将软件应用于软件开发的工程。

From IEEE Systems and software engineering

Software Engineering is the systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software.
软件工程是系统地将科学技术知识、方法和经验应用于软件的设计、实现、测试和文档化的工程。

From IEEE Standard Glossary of Software Engineering Terminology(PPT 中的描述)

Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.
将系统化、规范化、可度量的方法应用与软件的开发、运行和维护的过程，即将工程化应用于软件中，（以及对其的研究）。

• 阅读经典名著“人月神话”等资料，解释 software crisis、COCOMO 模型。

software crisis

Software crisis is a term used in the early days of computing science for the difficulty of writing useful and efficient computer programs in the required time. The software crisis was due to the rapid increases in computer power and the complexity of the problems that could not be tackled. With the increase in the complexity of the software, many software problems arose because existing methods were insufficient.
软件危机是计算机科学早期的一个术语，用于表达在规定的时间内编写有用和高效的计算机程序的难度。软件危机是由于计算机能力的迅速增长和无法解决的问题的复杂性造成的。随着软件复杂性的增加，现有的软件生产方式不足以满足解决这些复杂问题，许多软件问题就会出现。
The main cause is that improvements in computing power had outpaced the ability of programmers to effectively utilize those capabilities.
主要原因是计算能力的提高超过了程序员有效利用这些能力的能力。

COCOMO

The Constructive Cost Model (COCOMO) is a procedural software cost estimation model developed by Barry W. Boehm.
构造性成本模型是一个由Barry W. Boehm开发的程序的软件成本估算模型。
Basic COCOMO compute software development effort (and cost) as a function of program size. Program size is expressed in estimated thousands of source lines of code.
基本COCOMO模型用以程序规模作为输入的函数，来计算软件的开发工作（和成本）。程序规模用千源代码行表示。
其基本公式为：
EffortApplied(E)=ab(KLOC)bb[man−months] E f f o r t A p p l i e d ( E ) = a b ( K L O C ) b b [ m a n − m o n t h s ]
DevelopmentTime(D)=cb(EffortApplied)db[months] D e v e l o p m e n t T i m e ( D ) = c b ( E f f o r t A p p l i e d ) d b [ m o n t h s ]
Peoplerequired(P)=EffortApplied/DevelopmentTime[count] P e o p l e r e q u i r e d ( P ) = E f f o r t A p p l i e d / D e v e l o p m e n t T i m e [ c o u n t ]
Intermediate COCOMO computes software development effort as function of program size and a set of “cost drivers” that include subjective assessment of product, hardware, personnel and project attributes.
中级COCOMO模型用以程序规模和一组“成本动因”作为输入的函数，包括产品、主观评价硬件、人员和项目属性，来计算软件的开发工作（和成本）。

软件生命周期。

从时间角度，把整个周期划分为若干个阶段。划分的原则：各阶段的任务彼此间尽可能相对独立，同一个阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂性，简化不同阶段之间的联系，有利于软件开发过程的组织管理。受软件规模、性质、种类、开发方法等因素的影响。典型划分阶段：
1）软件分析时期：问题定义、可行性研究、需求分析
2）软件设计时期：总体设计、详细设计
3）编码与测试时期：编码、测试
4）运行与维护时期

• 按照 SWEBok 的 KA 划分，本课程关注哪些 KA 或 知识领域？
  Software requirements 软件需求
  Software design 软件设计
  Software construction 软件构造
  Software engineering process 软件工程过程
  Software engineering models and methods 软件工程模型和方法

• 解释 CMMI 的五个级别。
  Level 1 - Initial：无序，自发生产模式，过程不可预测，控制和反应不好。
  Level 2 - Managed：可管理级，建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
  Level 3 - Defined：已定义级。已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
  Level 4 - Quantitatively Managed：量化管理级。分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个做出结论的客观依据，管理能够在定量的范围内预测性能。
  Level 5 - Optimizing：优化管理级。过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。

• 用自己语言简述 SWEBok 或 CMMI （约200字）
  CMMI用于评估软件生产过程，通过分析诸多的指标，来评估当前软件生产过程属于哪一个等级，再查看下一个等级的要求，就可以进行相应的管理和改进方面的变化，以增强开发与改进能力。

2、解释 PSP 各项指标及技能要求：

阅读《现代软件工程》的 PSP: Personal Software Process 章节 。
按表格 PSP 2.1， 了解一个软件工程师在接到一个任务之后要做什么，需要哪些技能，解释你打算如何统计每项数据？ （期末考核，每人按开发阶段提交这个表）

PSP2.1
Planning * Estimate Development * Analysis * Design Spec * Design Review * Coding Standard * Design * Coding * Code Review * Test Record Time Spent Test Report Size Measurement Postmortem Process Improvement Plan	计划 * 估计这个任务需要多少时间 开发 * 分析需求 * 生成设计文档 * 设计复审 (和同事审核设计文档) * 代码规范 (为目前的开发制定合适的规范) * 具体设计 * 具体编码 * 代码复审 * 测试（包括自我测试，修改代码，提交修改） 记录时间花费 测试报告 计算工作量 事后总结 提出过程改进计划

我打算如何统计每项数据：
需求分析：一开始确定初步需求分析，开发过程中若有修改则在原需求分析文档后增加修改日志
设计文档：需求分析文档生成后确定，大的设计框架不改变，在开发过程中可以有小的设计更改
代码规范：确定一种代码规范并执行
测试报告：测试文档包括测试设计，测试样例，测试结果等
时间花费：记录实际开发时长，包括需求分析到测试的各个阶段
计算工作量：可用开发时间和代码量计算
事后总结：总结
过程改进计划：在开发过程中记录改进计划和改进结果