软件工程-笔记(未整理)

软件工程目的:主要解决人与人之间的问题

五大步骤:

1.communication 沟通
customer collaboration and requirement gathering
客户协作和需求收集
与客户沟通,判断客户态度与水平,知己知彼
收集客户信息
项目启动,需求获取
2.Planning 计划
establishes engineering work plan,describes technical risks,lists resource requirements,
work products produced,and defines work schedule
制定工程工作计划，描述技术风险，列出资源需求，
产生的工作产品，并定义工作计划
项目估算,进度计划
3.Modeling 建模
creation of models to help developers and customers understand the requires and software
design
创建模型以帮助开发人员和客户理解需求和软件设计
分析设计
做UE
4.Construction 开发
code generation and testing
开发,测试
5.Deployment 部署
software delivered for customer evaluation and feedback
交付资料,交付,支持反馈

CMMI The Capability Maturity Model Integration 能力成熟度模型
–by Software Engineering Institute (SEI) of Carnegle Mellon University(CMU) 软件工程研究所
评估公司级别.
level 0: Incomplete 草台班子,没有过程分工管理概念
level 1: Performed 开始有分工概念,但没有管理概念
level 2: Managed 有分工,有管理,有发言权的人(项目干系人),有过程监控,有评审
level 3: Defined 像一个公司,有规章制度,有文档,行为标准贯穿产品过程.组织过程资产
level 4: Quantitatively Managed 量化管理,有指标,像一个办法采集开发有关的数据,评估员工水平,代码 量,bug量.掌握进度,有意识的采集各种数据,分析得出结果
level 5: Optimizing 可以改进模型过程,创新模型,更好的模型保证质量.
考核内容:过程考核,做事情有没有规矩,严格程度.

Personal and Team Process Models 个人和团队过程模型

Personal Software Process (PSP)个人软件过程
Recommends five framework activities:
1.Planning 计划
2.High-level design 高级设计
3.High-level design review 高级设计审查
4.Development 开发
5.Postmortem 后期检查,教训总结
Team Software Process (TSP) 团队软件过程
管理模式
Prescriptive Models
Prescriptive process models advocate an orderly approach to software engineering
模型
1.Waterfall Model 瀑布模型
Communication
Planning
Modeling
Construction
Deployment
客户只有看到可用的产品时才会提出问题.
2.Incremental Process Models 增量过程模型
首先短时间开发核心功能(遵循瀑布模型)
短时间内先占领市场,然后不断升级
3.The Rapid Application Development(RAD) Model
n个模块,n个团队同时进行开发,最后合并.
与客户有没有有效的救火式的沟通机制.
4.Evolutionary Proces Models 进化过程模型
Prototyping 原型设计
快速了解需求,快速计划,快速原型设计 画UE
The Spiral Model 螺旋模型 没什么人用
The Concurrent Development Model
并发式
5.Specialized Process Models 专业流程模型
Component based development 基于组件开发
Formal methods
Aspect-Oriented Software Development
6.The Unified Process
uml,用户脚本,根据脚本设计架构.

Core Principles
1.Provide value to the customer and user.为用户提供价值
2.KISS–Keep It Simple,Stupid!越简单越好
3.Maintain the product and project “vision”.确保大方向正确
4.What you produce,others will consume.产品是给人用的
5.Be open to the future.

Requirements Engineering Tasks

1.Inception 大概摸清情况
–ask a set of questions that establish 问一系列的问题
–basic understanding of the problem对问题的基本认识
–the people who want a solution 谁想解决问题
–the nature of the solution that is desired,and 期望的解决方案
–the effectiveness of preliminary communication and
collaboration between the customer and the developer
初步沟通的有效性和客户和开发人员之间的协作,可以期待的沟通方便程度
Identify stakeholders 把相关的人找齐,谈话
who else do you think I should talk to?
Recognize multiple points of view 各种可能的观点,多找几个人从各种角度问做的什么
Working toward collaboration 营造合作关系,多大程度客户配合我,让客户觉得他有义务配合我
The first set of context-free questions
Who is behind the request for this work? 你的直接上级是谁
Who will use the solution?谁会用你的东西
What will be the economic benefit of a successful solution?
你这个东西做出来以后会在经济上带来什么效益,什么好处?
Is there another source for the solution that you need?
我是你唯一找的人吗?
The next set of questions
–customer’s perceptions about a solution客户的脑海里要什么样的东西,画出来
The final set of questions
–effectiveness of the communication activity itself
想要了解你的业务时可以找谁,这个人帮我们理解业务拿不拿工资,客户能配合到什么程度
2.Elicitation/Eliciting Requirements 诱导 --elicit requirements from all stakeholders
启发客户,提出真正的需求.
开会,坐到一起开会,目的,搞清楚问题是什么,有哪些解决方案,有几部分,解决途径投票,给出一个初步的需求,未细化.
Collaborative Requirements Gathering
Goal:
Identify the problem
Propose Elements of the solution
Negotiate different approaches
Specify a preliminary set of solution requirements
Meetings are conducted and attended by both software engineers and customers.
开会:用户要参加,组员要参加
Rules for preparation are established
An agenda is suggested
A facilitator(can be a sustomer, a developer, or anoutsider) controls the meeting
A defiinition mechanism(can be work sheets,flip charts, or wall stickers or an electronic bulletin board,chat room or virtual forum)is used
定个规矩,什么人必须来,尤其是客户,协商开会是是否必须到.
请哪些人,确定这些人一定到,会议议程,几点开会,几个议题,每个议题大概多长时间,总时间.
要有会议主持人,议题时间到了必须到下一个议题.管好每个人的时间,看好时间.
有工具记录会议内容,有投影/黑板写东西
Quality Function Deployment(QFD)
策略,吧用户想要的东西转换成技术理解的需求
以客户满意度最大化为目标做事情,客户满意度
把每一个功能搞清楚,给每一个功能打分,重要程度,满意度
确定数据输入输出
需求打分,normal expected exciting,先保证normal,expected最好有,exciting有余力做(加钱)
User Scenarios
Elicitation Work Products
可行性分析报告
范围,通讯录,技术环境,功能清单,限制条件,最好有原型设计
3.Elaboration 细化,–create an analysis model that identifies data, function and behavioral requirements 真正落实到纸上
4.Negotiation --agree on a deliverable system that is realistic for developers and customers搞清楚做什么,成本底线,deadline怎么设
5.Specification --can be any one(or more) of the following
– A written document
– A set of models
– A formal mathematical
– A collection of user scenarios(use-cases)
– A prototype
写清楚哪些指标达到了可以验收,验收标准,用合同约定.
保留证据.写清楚验收条件.
6. Validation 审核–a review mechanism that looks for
errors in content or interpretation
areas where clarification may be required
missing information
inconsistencies(a major problem when large products or systems are engineered)
conflicting or unrealistic(unachievable) requirements
7.Requirements management --identify,control,and track requirements and changes torequirements at any time
Developing Use-Cases
Actor 演员/角色
根据演员设定操作行为,用户脚本.
开发用例,伪代码.
Building The Analysis Model
Negotiating Requirements
谈判,先知道谁会参加谈判,达成双赢目标,搞清楚对方什么时候是win,不能双赢,失败几率很大.
谈判不是辩论赛,不是要赢谁.谈判是一门妥协的艺术.
谈判要有策略.要非常了解对方,计划好,少说多听.
谈判忌讳说对自己有什么好处,要站在对方立场上,说对对方有什么好处.
做事情专业一点,不要人身攻击,忌讳翻老账,就事论事,对事不对人.
如果大家都卡死了,不能协调时,跳出来.
说出去的话要兑现,不能随便忽悠.说话要小心.
确信写出来的东西是有意义的.如果没有必要就不要写.
保留领域知识,开发其他软件可以重用.
收集相关领域的知识,
可能重用的东西
重用标准

2.3需求分析与模型建立

8.1Requirements Analysis
1.Objectives
需求描述清楚,主要给客户看,同时也给技术看
有一定技术性
描述清楚什么情况可以交付
客户给system description
技术通过我做的analysis model生成design model
2.经验:Rules of Thumb
1.不要想太多细节/用什么技术
2.确认每一件事情都是为了帮助大家更好理解的
3.非功能性的考虑放到后面.
4.划分系统时尽可能不要有太多关联
5.要对所有的人有价值
6.尽可能简单
3.Domain Analysis
领域知识,尽肯能保留项目涉及的领域知识,下一个项目可以重用,对领域熟悉可以获得相应的项目
8.2Analysis Modeling Approaches
Structured Analysis
Object-Oriented Analysis
8.3Data Modeling Concepts
建立数据模型,客户可以看懂的数据模型
搞清楚数据模型之间的关系
What is a Data Object?
What are Data Attributes?
What is a Relationship?
推测不出来,只能明确告知的关系
8.4Object Oriented Analysis
面向对象:
什么是面向对象.Object Oriented
有继承,有封装/包装
c和c++的区别,C里面数据和操作分开,C++是绑在一起的.
Key concepts:
– Classes and objects
– Attributes and operations
– Encapsulation and instantiation
– Inheritance
• Tasks
– Basic requirements must be communicated
– Classes (attribute and method) must be identified
– A class hierarchy is defined
– Object relationship should be represented
– Object behavior must be modeled
– Above tasks are reapplied iteratively
封装,外部只能通过methods改attributes.
Encapsulation
封装有什么好处,
外部专注于业务实现,只需要调用方法
不混乱,只需要按照封装好的方法调用就好,不必写其他的方法.
Inheritance,继承,
安全的重用
Multiple inheritance
8.5Scenario-Based Modeling
use-case 用户手册
1.首先把所有角色列出来
2.每个角色要做什么事情
3.使用的过程中有没有什么特殊情况
时序图
Activity diagram.流程图
Swimlane diagram.时序图
8.6 Flow-Oriented Modeling 数据流图
input process output
数据怎么从输入变成输出的
8.7 Class-Based Modeling
Class Diagram UML
CRC Modeling
8.8 Creating a Behavioral Model
描述系统的动态
落实到纸面上
分层次展示
统一名词
缩写第一次出现必须给出全称
有目录,注释
尽量简单
站在第三方的角度要看懂.
9 Design Engineering 设计概念与原则
9.1 Design within the Context of SE
数据设计,架构设计,界面设计