1-6个核心过程
1.确定问题或需求,并获得批准以向前推进。
2.计划和监控项目----做什么,怎么做以及谁来做。
3.发现和理解问题或者需求的细节。
4.设计能解决问题或者满足需求的系统组件。
5.建立,测试和整合系统组件。
6.完成系统测试并部署解决方案。
2-敏捷开发
敏捷开发的基本原理是团队成员和用户都不能完全理解新系统的问题和复杂性。
3-迭代开发
首先开发核心组成部分,然后再把其他组成部分加进去。之所以称为迭代,是因为六种
核心开发过程在一遍又一遍的重复,以增加整个系统的额外功能。
5-分析活动(发现和理解细节)
1.收集细节信息2.定义需求3.需求的优先级划分4.开发用户界面对话框5.与用户一起评
估需求
6-收集细节信息
他们获取其他信息的途径是回顾计划文件和政策声明,分析员也会研究现有的系统,包
括它们的参考资料。
7-定义需求
分析员会使用从用户和文件中收集到的信息来为新系统定义需求,定义需求不仅仅是记
下事实和数据分析员会创建模型来记录需求。
8-需求的优先级划分
因为资源总是有限的,而且分析员必须时刻准备去证明系统的范围是合理的。
9-开发用户界面对话框
一个界面的用户验证工作是很简单且很可靠的。因为用户能看到和感知系统对大多数用
户来说,用户界面可以影响一切,因此,开发用户界面对话框是一个有力的工具,它可
以引出和记录需求。
10-与用户一起评估需求
理论上来说,与用户一起评估需求和需求文档化是同时进行的。
11-什么是需求
系统需求是这个系统必须执行或者支持的所有活动和必须满足的约束条件。分析员会将
系统需求分为两类:功能需求和非功能需求。
功能需求是系统必须执行的活动。非功能需求是这个系统的固有特征。
需求 | FURPS+ | 举例 |
功能需求 | 功能 | 业务规则和流程 |
非功能需求 | 可用性 可靠性 性能 安全 +设计约束条件 实施 接口 物理 可支持性
| 用户界面,易用性 失误率,回收法 响应时间,生产力 访问控制,加密 硬件和支持的软件 开发工具,协议 数据交换格式 尺寸,重量,能量消耗 安装和更新 |
12-信息收集技术
1.与用户其他利益相关者进行访谈。2.发放和收集调查问卷3.检查输入,输出和文档。
4.观察和记录业务流程5.研究供应商的解决方案。6.收集活跃的用户评论和建议。
13-推荐两种定义用例的技术
(用例是系统执行的一个活动)用户目标技术与事件分解技术。另一种称为CRUD的技术
也经常用于确认和增加用例列表。
14-基本业务流程(EBP)
用来确定用例的合适细节级别的是基本业务流程。基本业务流程是由一个人在特定地点
为了影响交易事件所执行的一项任务,他增加了可衡量的业务价值,保持了系统与数据
的稳定和一致。
15-事件类型
外部事件,临时事件,状态事件(内部事件)
16-CRUD的含义
CRUD是创建(Creat),读取(Read)(或者报告(Report)),更新(Update)与删除(Delete)的首
字母组合。
17-能定义问题域中的重要事物的技术
头脑风暴法和名词技术。
18-完全展开描述是记录用例的最正式的方式。
19-顺序图是对系统顺序图的扩展,并记录了类中控制和执行的流程。
20--技术环境不仅包括硬件。另外一种重要的组件是由操作系统,通讯协议和系统以及其支持软件(即中间件)组成的。
21- 设计应用程序结构通常是自上而下的处理过程
以用户为中心的设计,它强调以下三个重要原则:
1及早关注用户及其工作 2.评价系统以确保其可用性 3使用迭代开发方法
22-用户界面设计概念
1提示性与可视性 2一致性 3快捷方式 4反转 5完整对话 6错误处理 7撤销动作 8减轻短期记忆负担
23-报表类型:
1详细报表 2汇总报表 3异常包表 4执行报告
24-辅助工具包括:方法,模型,工具,技术
25-一些用在系统中的工具:
1项目管理应用程序 2制图/图形应用程序 3字处理器/文本编辑器 4Visual建模工具 5集成开发环境 6数据库管理应用程序
7反向工程工具 8代码生成工具
26-程序模块应该设计成耦合松散或高度内聚
27-.敏捷软件开发宣言核心理论:
1快速响应响应凌驾于原有计划的价值 2个体和交流凌驾于程序和工具的价值 3执行软件凌驾于综合文档的价值
4顾客合作凌驾于合同协商的价值
28-项目经理的角色:控制项目进展 项目管理是组织和指导他人按照先前确定的进度和预算实现计划结果。
29-对项目管理有重要影响的维度是正式程度,有时称为仪式
30-快速应用程序开发(RAD)这样的技术通过使用少量的正式。统一过程就是相当正式的,并且带有高质量的仪式
31-有四种类型的设计类被看作标准的设计类:实体类,控制类,边界类和数据访问类。
较少的导航可见性箭头说明系统更容易理解和和维护
32-设计中基本的准则是变量保护
33-第二种用于执行单元测试的测试模型类型称为桩程序,桩程序可以模仿一个尚未编写方法的行为。
34-构造和冒烟测试时日常执行或每周执行几次的系统测试,系统被完全编译和连接(构造),然后执行一组测试来检查一个明显的路径上是否存在故障(冒烟)。
35-性能测试也称强化测试,它要确保系统或子系统是否满足时间方面的性能条件,如响应时间或吞吐量。
36-系统文档-----系统需求,结构和构建细节的描述。
用户文档-----如何与系统交互,如何使用系统的描述。
37-最常用的部署方法是:
1:直接部署2:并行部署3:阶段部署
38-版本:为简化测试,部署和支持的工作,复杂系统的开发安装和维护是在一系列的版本中进行的。
alpha版本是一个未完成的但是已经准备好接受严格的集成化或可用性测试的系统,alpha版本的生命周期很短------几天或几周。
beta版本是一个足够稳定的系统,可以接受最终用户一段时间的测试。beta版本是在一个或多个版本测试完毕后
隐喻 | 描述 | 例子 |
直接操纵 | 操纵显示器上的物理对象 或能代表它们的对象 | 用户拖动一个文件夹图标到一个回收站或垃圾桶这个图片中可以删除一整个集合的文档 |
桌面隐喻 | 在边线中间和工具栏图标集中的地方用大量的空置工作区来组织视觉显示的不同区域 | 在计算机启动时,Windows用户会看到桌面,上面有时钟,日历,记事本,收件箱和即时贴的图标 |
文档隐喻 | 像页面或表格那样显示文档中的数据 | 用户要为自己购买的产品填写表格,制造商的网站上会找出并以Adobe Acrobat文档的形式显示产品手册,这份手册中包含一个内容的超链接列表和能连接到相关文档的嵌入式连接 |
对话隐喻 | 用户和计算机通过使用文本声音或工具(如带标签的按钮)来参与交流或对话并完成任务 | 用户单击标记为”troublesshoot”的按钮,说明打印机不能工作了,计算机会在显示器上膳食这些问题,并且用户要通过输入答复或从打印列表中选择恢复来进行响应。 |