1 / 14
文档名称:

软件工程知识总结.docx

格式:docx   大小:55KB   页数:14页
下载后只包含 1 个 DOCX 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

软件工程知识总结.docx

上传人:86979448 2017/12/17 文件大小:55 KB

下载得到文件列表

软件工程知识总结.docx

相关文档

文档介绍

文档介绍:一、关于软件工程
、实用的和高质量的软件学科。
软件工程= 技术+管理
,即形成软件产品的一些列步骤,包括中间产品、资源、角色及过程中采取的方法、工具等范畴。
软件工程三要素= 过程+方法+工具
软件工程是目标,软件过程是步骤,方法和工具是辅助。
:瀑布模型、RUP、Scrum敏捷开发、ICONIX
:
优点:为项目提供了按阶段划分的检查点;当前一阶段完成后,只需关注后续阶段。
缺点:各个阶段之间极少反馈;只有在项目生命周期的后期才能看到结果;通过过多的强制完成日期和里程碑来跟踪各个项目阶段;不适应用户需求变化
5.(Rational Unified Process,统一软件开发过程,统一软件过程)是一个面向对象且基于网络的程序开发方法论。
二、敏捷开发
、迭代、循序渐进的开发方法。
:适应性(非预设性)、面向人(非面向过程) “以人为核心”
:
个人和互动高于流程和工具
工作软件高于理解文档
客户协作高于合同协商
变化响应高于计划遵循
:Sprint计划会议、每日例会、Sprint评审会议、Sprint回顾会议
三、项目提出阶段
项目的背景:
a. 找到项目的主要服务对象
客户:系统的购买者
用户:系统的使用者
b. 项目的目标-愿景:所向往的前景
愿景可以激励潜能,指导方向。
如何找到软件项目的愿景:
找到老大;找到老大购买系统的目的。老大就是要改善的组织中最有权力的干系人。来自于客户。
三部曲:

(愿景)

c. 项目的商业价值
(通俗讲:商业模式是项目通过什么途径或方式来赚钱。)解决别人愿意花钱解决
的问题,就是商业价值。
d. 项目的服务对象细分-用户建模
用户建模原因:
*良好的用户建模,可以保证不同用户都能方便地访问其功能,使用产品后也更容易获得其特定的价值;
*找到哪些用户可能来使用产品或访问网站
*他们为解决哪些问题而来,为达到哪些目的而来
注意角色权限合理:不可过大或过小
头脑风暴:
PO(project owner)主持,借助团队进行,必须有必要的记录人员
用户建模四步:
;
(购买决策者、主要使用者);
3. 分类、合并次要用户;

虚拟用户:假想的用户角色的代表。(找一个人去代表一类人)
极端用户:很可能让你编写出原本可能遗漏的故事。
书友网:
---------------------------------------------------------------------------------------------------------------------------------
借书者、图书拥有者、借书提供者、管理者、浏览者过客、寻觅知音者、没有书的人、有书比较多的人、监视者
关键用户:借书者和提供者
分类、合并:
借书者
自己没书去借书的人、自己有书有需要借书的人。
提供者
自己有书有需要借书的人、不需要借书只提供给别人书的人。
既不借书也不提供书
浏览者、寻觅书友知音的人
管理者
开发维护人员、平台信息管理人员
虚拟和极端用户:
虚拟用户:
张三,软件学院学生,拥有软件工程专业图书10本,暂时自己没有阅读。资金匮乏,希望能借到一些文学类的图籍。
李四,大学教授,知识渊博,愿意同他人分享图书,拥有文学历史类图书若干,想寻找一起读书的书友,共同交流心得。
极端用户
四、产品定义:编写产品功能列表
:
产品backlog(代办事务)是Scrum的核心,是一切的起源
一个需求或特性组成的列表
按照重要性的级别进行了排序
包含客户想要的东西
用客户的术语加以描述(非专业性术语)
:功能需求、性能需求(非功能性)等(有时候还包含不能实现的功能)。
写成用户故事形式。
来自客户或者PO(对于自主研发的)。
:ID标示符、Name标题、Story故事、Priority重要初始估计等
主要是PO编写、Team也有权利,最终由PO取舍
4. 用户故事和需求说明书的区别:用户故事是一种敏捷的需求挖掘方式,其侧重点不是将需求书写出来,而是将需求讨论出来,是一种需求探索的方式。需求说明书是一个阶段的