软件产品
基于硬件运行的程序应用
是一种逻辑产品,具有无形性
没有明显的产生过程
不会磨损与老化
软件产品构成
包装
源程序
相关文档(安装说明,帮助文档,使用手册)
软件产品开发产生的文档
需求分析 软件需求文档 用户需求文档 需求可行性分许文档 开发计划文档
设计 概要设计 详细设计 数据库设计
开发 源程序 安装部署说明 帮助文档 使用说明
测试 测试计划 测试方案 测试用例 测试报告 测试总结
总结 项目总结
软件完成的角色
项目经理(PM): 驱动整个项目的运转,负责制定计划,安排人力,管理进度,协调 团队,进行重大决策;
需求分析工程师(BA): 对产品\项目的需求进行调研与分析,输出产品需求规格说明书;
架构师 (FD)/ 系统工程师(SE): 技术专家,经验丰富,负责整个系统的体系架构的设计以及关键模块的设计;
程序员 / 开发人员(PG):设计、编写软件,并修复软件中的缺陷;
测试工程师(TE):负责找出软件产品存在的问题并报告;
项目管理工程师(QA):负责在研项目开发过程的流程质量监管;
配置管理员(CMO):负责代码和项目相关资料的管理,以及进行编译、打包,组合成一个软件包;
软件工程
将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护上
流程范围
覆盖了需求、设计、开发、测试、维护等活动
作用
提高软件开发的效率和质量,使软件开发标准化,工业化.
软件开发过程
从最初构思到正式发布的整个过程.
开发模型
项目可管理 进度可控制
降低开发成本
瀑布模型
流程不可逆
适用需求明确不更变的大型软件开发
V模型
不可逆
不符合越早测,反复测原则
W模型
不可逆
符合越早测反复测原则
不支持迭代 自发性变更
快速原型模型
适用需求变更频繁
可逆修改
敏捷迭代模型
及早给予企业价值
可持续改善增强软件功能
敏捷迭代-WBS 将其分解为可以执行的任务
敏捷迭代-Scrum
三个角色
产品负责人(Product Owner) 主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。
流程管理员(Scrum Master) 主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。
开发团队(Scrum Team) 主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在8~15人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。
四个仪式
Sprint计划会议
1.决定项目分几个迭代完成,第一次迭代需要完成哪些工作?
2.各成员任务的安排及时间节点。
每日Scrum会议
每日Scrum会议,即团队每日例会,条件允许的话,每天都应该在同样的时间和地点,组织所有成员站立进行。
最好是每天早晨开,一般15分钟左右,时间比较短,也有利于团队成员安排好当天的工作。 只有团队成员可以在例会上发言,其他人员有兴趣可以参加,但只能旁听,不能发言。
每日Scrum会议由Scrum Master主持, Scrum团队所有成员轮流回答以下3个问题:
昨天我完成了什么工作?
今天我打算做什么?
我在工作中遇到了什么困难?
Sprint回顾会议
团队的定期自我检视,发现什么是好的,什么是不好的。
一般控制在15-30分钟
每个Sprint都要做
全体参加
Scrum Master
产品负责人
团队
可能的客户或其它干系人
三个物件
产品需求列表(Product Backlog)
一个需求的列表,由Product Owner 负责
一般情况使用用户故事来表示backlog条目
理想情况每个需求项都对产品的客户或用户有价值
Backlog条目按照商业价值排列优先级
优先级由产品负责人来排列
在每个Sprint结束的时候要更新优先级的排列
冲刺订单 (Sprint Backlog)
通过计划会挑选出一个Story作为本次迭代的目标,周期1个月左右,然后把这个Story进行细化,形成一个Sprint Backlog,由Scrum Team完成
燃尽图 (Burdown Chart)
燃尽图的全称,应该是“总剩余时间的燃尽图”,就是本次迭代中,所有故事(或拆分的任务,以下仅称故事)的剩余时间总和,随日期的变化而逐日递减的图。
软件开发过程模型的目的
保证最终产品满足用户需求;
提高产品质量,降低产品开发成本;
保证项目可管理,进度可控制;
作为测试人员的职责,是在所处项目的开发模式中,尽量运用自身的知识和技能,创造出尽量完善的软件。
软件的生命周期
软件生命周期是指一个软件从提出开发要求开始,直到软件报废为止的整个时期.
需求(可行性分析,需求分析)-------设计(概要设计,详细设计,数据库设计)------编码-------测试-------维护-----升级-------废弃
软件测试流程
测试计划-----测试要点分析-----测试方案-----测试用例-----测试执行------测试报告------测试总结
质量:反映实体满足明确或隐含需求的能力的特性总和
软件质量模型
内部质量:它是从内部观点出发的软件产品特性的总体。内部质量是针对内部质量需求被测量和评价的质量。
外部质量:外部质量是从外部观点出发的软件产品特性的总体。它是当软件执行时,更典型地是使用外部度量在模拟环境中, 用模拟数据测试时,所被测量和评价的质量。
使用质量:是从用户观点出发,来看待软件产品用于特定环境和条件下的质量。它测量用户在特定环境中达到其任务目标的程度,而不是测量软件自身的性质.
内部外部质量:功能性 可靠性 易用性 效率 可维护性 可移植性
功能性(Functionality):
1、适合性:用户所需要的功能软件系统已提供
2、准确性:提供的功能是否满足用户对功能的精确度要求
3、互操作性:产品与产品之间交互数据的能力
4、保密安全性:软件产品保护信息和数据的能力。(例如:数据库加密与备份,IP访问限制,登陆次数限制、用户权限管理等 )
可靠性(Reliability):
产品在规定的条件下,在规定的时间内完成规定功能的能力 三要素:规定的环境,规定的时间,规定的性能
1、成熟性:内部接口防范-防止内部错误导致软件失效的能力
2、容错性:外部接口防范-软件出现故障,自我处理能力
3、易恢复性:失效情况下的恢复能力(程序与速度)
4、可靠性的依从性:国际/国家/行业/企业 标准规范一致性
易用性(Usability):
在指定使用条件下,产品被理解、学习、使用和吸引用户的能力。
1、易理解性:提示信息准确、清晰、易懂
2、易学性:提供相关辅助手段,帮助用户学习使用系统(用户手册、在线帮助)
3、易操作性:方便用户操作
4、吸引性:界面美观、功能新颖
效率性(efficiency):
在规定条件下,相对于所用资源的数量,软件产品可提供适当性能的能力
1、时间特性:平均事务响应时间,吞吐率,
2、资源利用性: 例:CPU、 内存 、磁盘 IO 、网络带宽 、队列 、共享内存
3、效率依从性:国际/国家/行业/企业 标准规范一致性
可维护性(maintainability):
"四规", 在规定条件下,规定的时间内,使用规定的工具或方法修复规定功能的能力
1、易分析性: 失效原因定位成本-分析定位问题的难易程度
2、易改变性:对软件缺陷的修复容易被实现的能力(高内聚,低 耦合)
3、稳定性:防止意外修改导致程序失效
4、易测试性:降低发现缺陷的成本--使已修改软件能被确认的能力
5、维护性的依从性:国际/国家/行业/企业 标准规范一致性
软件可移植性(Portability):
从一种环境迁移到另一种环境的能力
1、适应性:无需做相应变动就能适应不同的平台
2、易安装性:被安装的能力
3、共存性:与第三方软件的兼容性
4、易替换性:软件系统的升级能力(在线升级、打补丁升级等 )
5、可移植性的依从性:国际/国家/行业/企业 标准规范一致性
使用质量:
使用质量的属性分为四个特性:有效性、生产率、安全性和满意度
1、有效性:软件产品在指定的使用环境下,使用户能达到与准确性和完备 性相关的规定目标的能力
2、生产率:在指定的使用环境下,使用户为达到有效性而消耗适当数量的资源的能力
3、安全性:在指定使用环境下,达到对人类、业务、软件、财产或环境造成损害的可接受的风险级别的能力
4、满意度:使用户满意的能力。
质量保证者:QA和QC
QA偏重于质量管理体系的建立和维护,客户和认证机构质量体系审核工作,质量培训工作等.
QC主要集中在质量检验和控制方面
软件质量最权威的体系:CMMI 和 ISO9000质量标准体系
CMMI是专门针对软件产品开发和服务,而ISO9000涉及的范围则相当宽(非软件行业采用居多)。
CMMI强调软件开发过程的成熟度,即过程的不断改进和提高。
ISO9000则强调可接收的质量体系的最低标准。
C M M I 等级
1.初始级
2.已定义级
3.以管理级
4.量化管理级
5.可持续优化级
如何提高软件质量
软件在没有发布之前的开发过程主要分为需求分析、设计、编码和验证四个阶段,最终的软件质量与这四个阶段的各自质量之间有密切的关系。
1.完备的需求分析
2.通过设计方法找出软件实现更好的方法
3.开发人员要有良好的编程习惯(合理添加注释、遵守编码规范等)
4.测试人员要做好各个环节的测试工作
(1)高质量用例:
1.1 引入合适的测试用例设计方法
1.2 引入测试用例评审机制
(2)良好的测试执行
2.1 要求用例执行率达到100%,多次的测试轮次
2.2 引入测试工具,让测试可以做得更深入(通过查看日志,查数据库)
(3)良好的缺陷管理
3.1 良好的缺陷写作和过Bug机制(缺陷修复效率可以提高,修复率也更高)
3.2 引入合适的缺陷管理工具和缺陷管理流程
(4)良好的测试流程
4.1 引入更合适的测试流程和测试方法
4.2 采用更多的非功能测试,不要忽略非功能测试
5.遵守软件开发必要的流程
6.选择合适的工具
7.输出高质量的开发文档