【图文】软件工程导论10_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
软件工程导论10
上传于||文档简介
&&软​件​工​程​导​论​ ​课​件​ ​张​海​藩​版​的
大小：524.00KB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢【图文】软件工程10_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
软件工程10
上传于||暂无简介
大小：294.00KB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢俗话说，自己写的代码，6个月后也是别人的代码&&复习！复习！复习！涉及的知识点如下：
软件工程概念
敏捷开发过程scrum
一、什么是软件工程？请用一句话描述。
　　软件工程是一门研究性的学科：它用工程化的方法（联系建筑工程&&），构建和维护有效的、实用的，和高质量的软件。简单来说，软件工程有三要素：过程+方法+工具，而软件工程是目标，软件过程是步骤，方法和工具是辅助。
二、那么，软件过程又是什么？
　　软件过程：首先它是一个框架或者说步骤，它是一个为建造高质量软件而所需要完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。
三、常用的软件开发过程（开发框架）都有什么？选一种做简单介绍。
　　1、瀑布模型（Waterfall Model）：开发过程是通过设计一系列阶段顺序展开的，过程如下：先明确要做的是什么，然后看用户的需求是什么，分析需求之后简单得出一个demo（画出原型图，草图等），然后进行架构分析和设计，总结出设计文档，之后讨论详细的开发细节，而后实现，最后测试&&如图：
　　瀑布模型的优点：　　&为项目提供了按阶段划分的检查点　　&当前一阶段完成后，您只需要去关注后续阶段　　瀑布模型有以下缺点：
　　&各个阶段之间极少有反馈　　&只有在项目生命周期的后期才能看到结果　　&通过过多的强制完成日期和里程碑来跟踪各个项目阶段　　&不适应用户需求的变化
　　2、scrum敏捷方法，Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球，Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。
　　3、ICONIX过程，包括愿景分析、业务建模、需求分析、健壮性分析、关键设计、最终设计、实现&&
四、什么是敏捷开发过程？
　　敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。说白了就是更加灵活！面向人的需求为核心！是一个逐步适应性的过程！敏捷是一种思想！敏捷和瀑布模型比较：
那么敏捷是不是就是万能的呢？其他过程都不好？不是的，一定澄清几个误区，对敏捷开发的误解：敏捷固然好，但是其他方法不是都没用。遵循敏捷过程的常见软件开发模型有scrum，xp（极限编程）&&其中比较流行的是scrum。
五、scrum概念
　　Scrum是一个框架，顾名思义scrum是橄榄球运动里带球过人，争球的含义，而带球过人需要计划！在球场上，在比赛每段的开始，双方都要摆开阵势，教练和队长都可以参考计划。而在软件开发公司。敏捷方法的每个迭代的开始，团队领导者都应该做好本迭代的计划，尤其是需求条目的优先级排序、选择本迭代的工作、设定必须完成的内容等。且带球过人需要灵活应变！在球场上，哨声响起，尽管队员们努力按照计划推进，但场上瞬息万发，队员不可能实时按照教练指令亦步亦趋地行事，而是靠平时训练中形成的素养见机行事，达成目标，在软件开发公司，在每个迭代开始后，团队领导不可能也不必需要事必躬亲，而是应该由具体执行的人选择如何去做。团队领导要做好的是协调资源、解决困难、提供指导，以达成目标。
　　1、敏捷开发的角色
　　产品负责人PO，负责产品的需求提炼、条目化，优先级排序，PO直接和用户以及其他关系人交互。scrum过程管理者scrum master，负责维护scrum方法的秩序，并协调解决非技术问题。最后是team团队，自组织的相对扁平化的管理方式进行项目的开发工作。
　　scrum团队结构：
　　名词解释：每个迭代的冲刺周期过程又叫sprint，其中贯穿了很多活动&&
　　sprint计划会议：每次迭代之前召开，时间充足（4-8小时或者&&），po，sm，team&&都参加po从backlog积压的产品列表里找高优先级任务，并和team商量需要完成多少功能，po把功能分解为小的功能模块，而team要详细讨论如何完成&&预估时间。
　　backlog（积压的待处理事务）：产品的backlog包括了所有需要交付的内容，内容根据业务的需求价值顺序排列，更加需求变化动态的增长或者减少。既定产品的backlog是一个迭代中的产物，定义了team接受的工作量，整个sprint中不变，sprint backlog涵盖了最终版本的既定产品backlog的任务，团队通过它来协调开发进度，障碍backlog列举了所有团队内部和相关的和阻碍项目进度的问题，sm需要确保所有的障碍backlog问题都已经分配并且可以得到解决。
　　每日立会：早上开比较好，与会人员站立而开，10几分钟足以，任何人都可以参加，sm主持，但只有team能做相关任务的发言，每个team要问三个问题&&昨天做了什么？今天要做什么？遇到了哪些问题？然后更新燃尽图。
　　sprint评审会议：每次sprint结束时召开，时间一般2个小时内控制，team展示本轮迭代完成的任务，不需要ppt，展示demo！此会，客户，po，管理层&&都能参与，目的是让po去断定项目开发的进度和迭代目标是否一致。
　　sprint回顾会议：sprint结束之后召开，时间一般1-3个小时左右，po，sm，team都参加，目的是对刚刚接受的sprint进行总结，反思，提高适应能力。需要总结分析成功经验和解决的困难。
　　2、Scrum主要特征：快速开发尽快交付，团队合作适应变化。
　　3、Scrum的适用场景：
&7人，+or-2&偏小一些会更适合&最好能坐在一起&客户参度不高&快速移动互联网项目&自主性研发的产品
六、scrum开发方法的具体流程
项目的提出（项目的背景，项目的主要朋务对象，目标&愿景，商业价值，服务对象的细分）以Project Owner为主要提出者，team辅助！
　　项目的背景：&大数据时代已到，数据越来越具有价值，没有数据寸步难行，有了数据可以在诸多领域干很多事，比如互联网金融。从互联网上爬来自己想要的数据，是数据的一个重要来源，而且往往是必不可少的来源。所以&&要能稳定的、高效的和实时的带来数据&&&。
　　项目的主要服务对象：区分客户和用户！客户是系统的购买者，用户则是系统的使用者。知乎爬虫系统服务对象：某论坛-客户
　　项目的目标（愿景）：愿景就是向往的前景，是人们为止持续奋斗而希望达到的图景！比如社会主义接班人要奋斗终生去努力实现共产主义&没有阶级、没有压迫、没有贫穷、没有失业、人人幸福的共产主义社会！福特汽车让每个家庭都有一辆汽车，微软让每个桌面都有一台计算机&&故可以认为：伟大的愿景能成就伟大的事业！具体到软件的愿景，要想找到软件的愿景就要找到项目购买人&&老大（专业术语），先找到老大，再得到老大购买该系统的目的，PO去做&&我们已经知道软件项目是为了改善某个组织的某些方面，而购买软件的人（老大）毫无例外就是这个组织中最有话语权的干系人。比如企业的财务主管需要提高财务工作的效率，某企业的领导需要占领市场，领先对手，某官员需要彰显政绩&&知乎爬虫系统的愿景就是根据论坛主需要，多样化，精确化丰富论坛内容（这里学习为主，模拟为主，故不考虑版权，但实际工作必须有版权意识！），
　　项目的商业价值（难分析，很重要）：先回答什么是商业价值？通俗地讲，商业模式就是项目通过什么途径或方式来赚钱。而解决别人愿意花钱解决的问题，就是商业价值。po主持挖掘商业价值，如果没挖掘出来&&好吧，放弃该项目！
　　服务对象细分：也就是用户角色建模，良好的用户建模，可以保证不同用户都能方便地访问其功能 ，使用产品后也更容易获得其特定的价值，一般由project owner主持，借助团队的力量进行头脑风暴！
哪些用户可能来使用产品(或访问网站)
他们为解决哪些问题而来，or 为达到哪些目的而来
用户建模的步骤，四步曲
尽可能多的列出用户
找出关键用户&&购买的决策者，主要的使用者
分类，合并次要用户
添加虚拟的和极端的用户，虚拟用户&&假想的用户角色的代表。比如 &&Mario在SpeedyNetworks的人事部门负责招聘工作，该公司是一个高端网络组件制造商。他已经在该公司工作了6年。Mario有弹性的时间安排，每周周五他在家工作。Mario对电脑相当在行，他觉得对于自己所使用的软件产品，他几乎都是超级用户。Mario的妻子Kim，正在斯坦福大学化学系攻读博士。由于SpeedyNetworks几乎一直在扩张，Mario总是在物色优秀工程师。&&极端用户&&很可能让你编写出原本可能遗漏的故事。
　　2、产品功能列表的定义，所谓产品功能列表是一个需求、or 特性等组成的列表-产品backlog是Scrum的核心，是一切的起源，按照重要性的级别进行了排序，里面包含的是客户想要的东西，使用用户客户的术语加以描述。产品功能列表主要是Product Owner写，Team也有权利，但最终由PO进行取舍。
　　产品功能列表写成什么形式&&用户故事user stroy的形式！因为在产品定义阶段我们很难全面描述出来我们项目的需求，我们需要一种方法去探讨需求&&用户故事。传统的需求说明书是这个阶段的结果。　　PS：产品功能列表格式
ID（统一标识符）
Name（标题）&简短的、描述性的故事名
Story（故事）&故事内容描述
Priority（重要性）&产品负责人评出一个数值，指示这个故事有多重要
Initial estimate（初始估计）&团队的初步估算，表示和其他故事相比，完成该故事所需的工作量
How to demo（如何做演示）&它大略描述了这个故事应该如何在sprint 演示上进行示范
Notes（注解）&相关信息、解释说明和对其它资料的引用等等
额外的字段（非必需）
&Track（类别）&当前故事的大致分类&Components（组件）&通常在Excel文档中用&复选框&实现&Requestor（请求者）&这项需求的提出者&Bug tracking ID（Bug跟踪ID）&故事与bug间的直接联系
　　那么用户故事又是什么鬼？　　用户故事是一种敏捷的需求挖掘方式，其侧重点不是将需求书写出来，而是将需求讨论出来。基本的叙述格式为：&作为一个&&，可以&&，以便&&& 的样式和思路写成的用户需求，就是用户故事。作为一个网站站长，我希望能通过xx爬虫系统抓取xx数据，以便于我的网站用户能方便的得到某些信息、作为一个网上商城的买家，我希望通过QQ号可以登录商城，以便于买东西&&
　　用户故事三要素：角色、功能、客户价值，角色来源于用户角色建模的结果！功能使用主语-谓语叙述原则，动宾词组原则.比如针对显示xx数据：作为一个系统管理员，我希望可以显示xxx数据，以便vip用户&&注意：角色和功能之间是主语-谓语关系；功能本身是动宾词组。我们一般把用户故事的标题写为功能的形式。关于客户价值，看似简单，其实很难写，我们先体验一下；&作为一个网友，我希望能够有个快速通知可以提醒我有新的新闻更新，以便于节省我浏览网站寻找新闻的时间，从而有更多时间做其他的事情。&、&作为一个站长，我希望爬虫系统能有效，快速的抓取xxx数据，并进行一些列分析&&以便于我得到xxx信息。&
　　用户故事也是用来被卖掉的东西，看不到价值的故事不是用户故事。
& & &让故事停留在业务层面，避免技术性故事，Eg:给xxxx表添加索引，它的真正目标是什么？当然是为了提高在后台系统中搜索事件表单的响应速度，最开始的技术描述只会作为一个注解存在（&为事件表添加索引可能会解决这个问题&）
　　好故事的准则
　　&独立的（Independ）避免故事间的相互依赖性。
&用户可以用Visa信用卡充值。&用户可以用万事达信用卡充值。&用户可以用美国运通卡充值。　　思考：如何消除依赖？
合并故事&&用户可以用信用卡充值。
通过不同的维度分割故事！&&用户可以用一种信用卡充值，用户可以用另外两种信用卡充值。
　　&可讨论的（Negotiable）不要包含过多的细节
　　&对用户or客户有价值的（Valuable）　　&可估计的（Estimatable）一般有以下3个原因会导致故事不可估计
&开发人员缺少领域知识。&开发人员缺少技术知识。&故事太大了。　　解决方案&PO讲解/和客户讨论。&分解为更小的故事
　　&小的（Small）刚刚好的，比如：用户可以完成一次购物&&大故事不好！
　　&可测试的（Testable）故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。通常，不可测试的故事发生在一些非功能性的需求上，这些需求和软件有关，但不直接和功能有关。
&用户必须觉得软件很好用。&用户绝不需要花很长时间等待窗口出现。在95%的情况下，新窗口会在2秒内打开
　　用户故事的好处　　&用户故事强调对话交流而不是书面沟通。　　&用户故事可以同时被po和开发人员理解。　　&用户故事的大小适合做计划。　　&用户故事适用迭代开发。
　　3、产品发布和迭代周期：常见两种方式
　　每次迭代发布，移动互联网项目，自主性研发产品&&
　　多次迭代发布，传统项目、大型项目
　　前面说了，迭代之前要开sprint计划会议，但是在冲刺计划会议之前要：
确保产品 backlog 的井然有序，产品 backlog必须存在，只能有一个产品 backlog和一个产品负责人，重要的 backlog 条目都已经根据重要性被评过分，PO应当理解每个故事的含义！
确定Sprint 计划会议日程-13:00 & 17:00 （每小时休息 10分钟）-13:00 & 13:30。产品负责人对 sprint 目标进行总体介绍，概括产品 backlog。定下演示的时间地点-13:30 & 15:00。团队估算时间，在必要的情况下拆分 backlog条目。产品负责人在必要时修改重要性评分。-15:00 & 16:00。团队选择要放入 sprint 中的故事-16:00 & 17:00。为每日 scrum会议安排固定的时间地点
会议由Product Owner、Scrum Master、Scrum Team参加，产品负责人必须参加
确保质量不能让步：外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣，内部质量一般指用户看不到的要素，它们对系统的可维护性有深进影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。
　　在冲刺计划会议中
确定Sprint目标及长度，半死不活的目标也比啥都没有强。
讲解Story：讲解故事就是要明确故事内容，决定spring包含的故事，使用故事索引卡，哪些故事需要从产品 backlog 拷贝到sprint backlog 中，在sprint中包含多少故事由团队决定 ，而不是产品负责人or其他人
估算时间；估算时间就是对故事的估算，估算的单位&&故事点（理想化的人-天），可以使用计划牌
　　我们在这里使用以下几种技术：　　&本能反应　　&昨日天气，昨日天气（yesterday&s weather）&&查看团队的历史
　　&生产率计算：用生产率计算来估算，这项技术包括步骤如下：
&参考实际生产率&得出投入程度&得出估算生产率&计算在不超出估算生产率的情况下可以加入多少故事。
　　实际生产率：把上一个 sprint 中完成的所有故事的原始估算加起来，得到的和就是实际生产率
　　　　&投入程度（focus factor）&，以上一个例子为基础，团队的投入程度为：
　　　　估算生产率:Eg：假设下个Sprint我们有30个人天，则生产率=30&36%=10个故事点
　　　　一些其他问题：如果没有历史数据怎么办？在新团队中使用的&默认&投入程度通常是 70%。
　　　　　　　　　　　实际过程中我们用的是哪种估算技术？一般我们都是结合起来用
　　　　　　　　　　　　&审视上个sprint的投入程度和实际生产率　　　　　　　　　　　　&估算一个投入程度　　　　　　　　　　　　&再进行&直觉反应&的检查
　　　　　　　　　　　产品负责人如何对 sprint 放哪些故事产生影响？　　　　　　　　　　　　　调整优先级
　　　　　　　　　　　　　缩小范围
任务分解；&任务&和&故事&的区别是什么呢？&&故事是可以交付的东西，任务是不可以交付的东西
　　spring计划会议中：定下每日例会的时间地点，一般是9:00，9:30 or 10:00，必须是每个人都能完全接受的时间。定义&完成&，产品负责人和团队需要对&完成&有一致的定义，
　　Sprint计划会议之后:Sprint 计划会议会产生一些实实在在的成果
　　　　&sprint目标　　　　&团队成员名单（以及他们的投入程度，如果不是 100%的话）　　　　&sprint backlog（即 sprint 中包括的故事列表）　　　　&确定好 sprint 演示日期　　　　&确定好时间地点，供丼行每日 scrum会议
　　　　&让别人了解我们的Sprint　　　　&sprint信息页；sprint 目标和演示日期
　　　　&经过团队认可、要添加到这个 sprint 中的故事列表　　　　&Sprint 中每个故事的估算值　　　　&明确每日例会固定丼行的时间地点　　　　&把故事拆分成任务
　　4、scrum每次sprint设计的过程
　　不好的,引发风险,产品不能满足客户需求变化，bug率标高，代码质量堪忧
　　好的：
先界面原型设计，PO主持，那什么是界面原型？
　　界面原型指使用工具根据客户需求及软件分析人员的理解，将头脑中的界面快速的反映到介质上。将需求转化为可视画面以及人与系统的交互！
　　界面原型的好处：Prototype不仅仅可确定需求，它更可赢得顺客的心&阿伦 M.戴维斯 和 迪安 A. 莱芬韦尔，《用需求管理快速交付高质量的软件》的作者（Rational软件公司/IBM）
　　界面原型的目的:　　　　&尽早验证需求　　　　&尽早明确不确定性的因素　　　　&方便便沟通交流　　　　&为后续界面设计提供基础
　　　　　　界面原型的目的是需求验证，不必太纠结细节。
　　如果原型设计都没通过，就没有必要进行下去，如图：
　　画界面原型的工具;白纸、铅笔、橡皮、橡皮+铅笔+白纸、Axure、MS OFFICE、PS、Viso&&工具只是工具，任何一种方法or工具都是为我们开发、生产过程服务的，我们不能成为工具的奴隶。根据实际以及环境选择合适的工具绘制。
　　2、数据库设计。这里主要讲解范式&&&数据库的三范式
　　　　&第一范式　　　　　　&关系R中的属性都是不可分割的项.　　　　&第二范式　　　　　　&在1N的基础上,每个非主属性完全函数依赖码.　　　　&第三范式　　　　　　&在2N的基础上,每一个非主属性既不部分依赖码也不传递依赖码.
　　从1范式到2范式　　&1N | 消除非主属性对码的部分凼数依赖 2N　　&假定选课关系表为　　　　&SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)　　　　&存在如下决定关系： (学号, 课程名称) & (姓名, 年龄, 成绩, 学分)　　　　&规范化 学生：Student(学号, 姓名, 年龄)； 课程：Course(课程名称, 学分)； 选课关系：SelectCourse(学号, 课程名称, 成绩)。
&　　从2范式到3范式
　　&2N | 消除非主属性对码的传递凼数依赖 3N　　&假定学生表为　　　　&Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)　　　　&规范化 学生：(学号, 姓名, 年龄, 所在学院)； 学院：(学院, 地点, 电话)。
　　对于三范式的理解　　　　&每一列只有一个值　　　　&每一行都能区分。　　　　&每一个表都不包含其他表已经包含的非主关键字信息
　　3、系统设计
　　5、产品实施（监控过程），管理sprint backlog最有效的形式&挂在墙上的任务板！在每日例会的时候（or 会议开始前）更新任务板
　　　　在首次每日例会以后，任务板可能会变成这样
　　　　几天以后，任务板可能会变成这样
　　还有使用燃尽图（burn down chart）：是在项目完成之前，对需要完成的工作的一种可视化表示。Sprint燃尽图和迭代燃尽图，Sprint燃尽图展示了以故事点表示的在本轮迭代中剩余的工作量;
-y:预估剩下的故事点&x:日期（非工作日除外）&y/x=生产率
&　　计划速率和实际速率:监测实际速率和计划速率的偏差
　　还有累计故事点图：表明了在每轮迭代结束时总共完成的故事点数。
　　每日燃尽图显示了团队在某轮迭代中的进度，你可以用这个信息判断计划的工作能否在迭代结束时都能完成。
阅读(...) 评论()软件工程试题与答案 (16)_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
软件工程试题与答案 (16)
上传于||暂无简介
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，查找使用更方便
还剩6页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢君，已阅读到文档的结尾了呢~~
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
软件工程课后习题参考答案
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口