同步课 / 软件过程（2014级1、2班）

如何在EA中将画好的模型图导出为图片？

打开要导出的模型图，然后如下图所示操作

保存时，建议图片格式选择为 *.jpg

愿景（内容摘自：《软件方法——上册》潘加宇）

愿景的定义：

在老大看来，引进这个系统的目的是什么？

老大：

老大也就是平时我们所说的“客户”，是最有“地位”的涉众，权衡系统的各种需求时，他的意见是最重要的。

为什么要说“老大”，不直接说“客户”呢？因为“客户”指的是一个组织或人群，不是具体的某个人。我们需要具体到老大——客户中针对此系统最有发言权的人，例如NB市国土资源局局长。

定位具体的组织（人群）

例：PS可乐公司不会放在重要的位置来考虑，因为PS可乐的目标客户群是年轻人。可惜，很多时候我问开发人员：“可乐卖给谁？”得到的回答大多是“卖给消费者”，“卖给想喝可乐的人”─对做出好卖的可乐没有帮助的、正确而无用的废话。

开发人员有时会觉得全世界人民都可以用我的产品，巴不得从每个组织、每个人、每只猫、每条狗、每块石头、每棵植物、每个僵尸都榨出金币。然而事实是：竞争使得产品分类越来越细，不再有针对所有人的产品了。需求要具体，想要的都还没有满足，去想其他的干什么？任务需求“漏掉”的想法是幼稚的。需求是一口深井，永远做不完。

寻找老大：要点和典型错误

要点：老大是买方。

典型错误：老大就是我们开发公司老总（或者研发总监、产品经理等）。

开发公司老总当他成为买方的时候如：购买一款开发工具，招聘一名开发人员，选择一次开发技术培训服务``````

要点：系统改善哪个组织的流程？老大就是该组织的负责人。

典型错误：老大是XX局信息中心主任李XX。

要点：系统好坏的度量指标藏在他的大脑里吗？

典型错误：老大是某位大领导（可能是集团董事长，也可能是省长，甚至是经理）。

可度量的目标

愿景是改善组织的指标，不是做某事。

有了老大，接下来要写出老大希望这个系统给组织带来改进的目标，而且是可以度量的目标。愿景指导功能，不能错把功能当愿景。

错例：把系统的功能当作愿景

描述的都是“做什么”，已经是系统的功能需求。愿景不是问系统有什么功能，而是回答买了这个系统，对组织有什么好处。如果回答不了这个问题，谁能相信开发人员拍脑袋得出的“本系统有××几大功能”有多少价值呢？

更恰当的愿景描述如下图：

揣摩目标度量

前面我们已经确定了老大，也确定了目标。有了目标，针对目标就得有个度量。不然老大拿什么来判断系统好不好？

开发人员需要通过各种手段揣摩老大心底里的度量指标，可以通过老大的讲话、报告，通过客户派来的接口人，也可以问本方老大─开发人员接触不到对方老大，本方老总接触对方老大总方便些吧？揣摩的技能每个人都有，我们每天都在揣摩上司、同事、配偶的意思，只不过现在要把它用在软件开发上。设想一下，如果不是开发软件，而是招待老大到澳门泰国的娱乐场所玩，老大说“帮我找个漂亮的技师”，您不也得从老大的角度揣摩“漂亮”的度量指标吗，老大更看重的是三围？脸蛋？年龄？

技术？切不可因为自己喜欢凤姐，就给老大带个凤姐回来。

涉众利益

愿景是老大针对系统的目标。

其他人的目标我们把它叫做涉众利益。涉众指受到系统影响的各种人。

拿拍电影做类比，涉众像电影观众，需求像电影

剧本。剧本只有一份，观众却是多种多样，不同观众的欣赏角度和口味不同。

用例使用“执行者”（Actor）和“涉众”代替了原来的“用户”，这是一个非常大的突破。“用户”

这个词混淆了演员和观众的界限，我认为开发人员之间的交流可以把“用户”废弃。

没有“用户”的系统，也一样有涉众。

可积累的财富

我们来看银行领域中的涉众利益：

储户─希望方便；担心权益受损

银行负责人─希望安全；希望节约运营成本

这些涉众利益，适用于清朝的钱庄柜台，适用于取款机，也适用于网上银行。现在手机银行又开始热门，背后的涉众利益变了吗？

涉众利益是团队可以积累的财富。

对于从零开始的团队，可以把“愿景”作为第一个引进的概念，团队先对“为什么要开发这个系统”达成共识。另一个需要建立的概念是“涉众”，我在写的这些代码影响到谁的利益？这个时候开发团队即使还是没有正式的需求工程，没有改进分析设计，在开发过程中，把这两个概念记在心中，愿景和涉众的概念也能起到潜移默化的作用。

案例

第一章PPT

uml 简介【转】

一.UML自我介绍

         统一建模语言(Unified Modeling Language,UML)是一种编制软蓝图的标准化语言,它提供了描述软件系统

模型的概念和图形的表示方法,以及语言的扩展机制和对象约束语言.

         UML是在著名的BOOch方法,OMT方法,OOSE方法基础上,广泛民主的发展而形成的.UML支持面向对象的技

术而后方法,能够准确的方便地表达面向对像的概念,体现面向对象的分析和设计风格.

        想更多了解自我介绍,请关注权威解释:

                1.百度百科:http://baike.baidu.com/view/23396.htm

                2.维基百科:http://zh.wikipedia.org/wiki/UML

二,UML的表示方法

          UML 由视图(View),图(Diagram),模型元素(Model Element)和公共机制(Common Mechanism)等部分组

成.

1.视图

        从多个不同的角度描述一个系统,可以得到多个视图.从其中一个角度描述一个系统可以得到系统的一个视

图,每个视图都是整个系统描述的投影,说明系统的一个侧面,如干个不同的视图可以完整地描述整个系统.

       其中视图又包括以下五种.

     1)用例视图(Use Case View)表示系统的功能性需求,用例视图使用用例图来描述,用活动图来进一步描述其中

的用例.

    2)逻辑视图(Logical View)表示系统的概念设计和子系统结构等,用类图,对象图描述系统静态结构,用状态图,时

序图,协作图和活动图描述系统动态行为.逻辑视图又被称为结构模型视图.

    3)进程视图(Process View)表示系统的动态行为及其并发性,使用状态图,时序图,协作图,活动图,组件图和部署

图来描述动态行为,又称为行为模型视图.

   4)实现图(Implementation View)表示系统实现的代码结构和行为特征,组件视图用组件图来描述,又称为组件视

图.

   5)部署视图(Deployment View)用于定义硬件节点的物理结构.表示实现环境和组件被部署都物理结构中的映

射,部署视图用部署图来描述.

上述的5个视图被称为"4+1"视图如图所示:

 2.图

        图用来表示一个视图的内容,在一般情况下,一个视图又多张图组成.UML中共定义了9中不同的图,它们分别

是:用类图(Use Case Diagram),顺序图(Sequence Diagram),协作图(Collaboration Diagram),类图(Class

Diagram),对象图(Object Diagram),状态图(Statechar Diagram),活动图(Activity Diagram),组件图(Component

Diagram),部署图(Deployment Diagram).

3,模型元素

        包括用例,类,对象,消息和关系等可以在图中使用的概念统称为模型元素.模型元素在图中用相应的视图元素

即图形符号表示.一个模型元素可在多个不同的图中出现,但具有相同的符号表示和相同的含义.

4.公共机制

        使用公共机制可以为图附加额外的信息,使UML中的图含义更加明确,直观.在公共机制中还可以提供扩展机

制,以满足用户使用新的模型特征和表示法,或wie模型添加某些非语义信息.

三.UML的构成

  1.UML中的三类主要元素

  1)基本构造模块(Basic Bulding Block)

     基本构造模块有包括三种类型:

   ( 1)事物:构成模型图的基本图示符号

点击图查看大图

(2)关系

        在UML中有4种关系,即依赖(Dependency),关联(Association),泛化(Generalization),实现(Realization):

它们的表示方式为:

点击图查看大图

(3) 图

点击图查看大图  

2)规则(Rule)

UML 用于描述事物的语义规则为:

1.  命名为事物,关系和图起名
2. 范围给一个名称一特定含义的语境
3. 可见性怎么让其他人使用或看见名称
4. 完整性事物如何正确,一致地相互联系
5. 执行运行或模拟动态模型的含义是什么

 3)公共机制(Common Mechanism)

1.    规格说明

2.    修饰

UML表示法中的每一个元素都有一个基本符号,可以把各种修饰细节加到这个符号上,

例如:

3.    通用
4. 划分

     通用划分有两种划分方式,分别是:

类/对象二分法(class/object dichotomy)

接口/实现二分法(Interface/realization dichotomy)

4.    扩展机制

        对UML 图示符号的扩展,包括:构造性Stereotype,标注值Tagged value ,约束 Constraint

   对于UML 的构成,用文字描述看着挺多的,现在我们用张思维导图来理理我们的思路:

点击图查看大图

一篇文章看懂互联网公司职位架构

那么，今天我就简单说说各项职能下，各个职位可能重点落在哪些事务上。

1、产品助理

「产品助理」是一个在大公司里才会出现的岗位。这个职位设立的初衷，是解放产品经理，让产品经理从繁杂的会议、扯皮、文档写作中解放出来，专心做需求分析和产品设计。

2、产品经理

「产品经理」的具体职能是落在对用户需求的深刻理解上的，并且通过逻辑思维和体验优化来让客户的需求得到满足。

显然不是随便一个什么人就可以去做「产品经理」

他需要对用户理解，对生活了解

是需要阅历和沉淀的职位

而产品经理这个角色

在大公司和小公司的职责是完全不同的

因为大公司会多出很多事务性的工作

所以这些事务性的工作就会交由「产品助理」来完成

有一些产品助理，是可以随着时间的推移去升级的

如果你是应届毕业生，希望做产品工作，那么可以考虑一下从大公司的「产品助理」做起。当然，如果你天赋异禀，我觉得直接做「产品经理」也挺好。只是这种天赋异禀的人，毕竟少。

3设计师

随着互联网的发达，对职位的职能有了非常细致的重新分配。于是有了各种「设计师」，UI、UE、交互、动画……对于「设计师」这样的职位，大家在投递之前，需要看清楚业务职责。

很多人对运营和营销的概念有些混淆，那到底他们的区别在哪里呢？

从A点到B点，这段路程。

运营就是负责好车的维修，司机的安全，各个人员的调配，规划好时间跟最短的行程；

营销就是负责好外部的品牌形象，以推广为主，分析好路线的短的同时要注意路上的人量还有是否适合等等.下面就比较系统的解释运营跟营销的区别。

运营岗位通常共性的要求有：

头脑灵活，有创意。能够创造出精品内容，或者设计出有意思的活动。

对数据非常敏感。能够发现数据波动，并找出数据波动的原因，从运营端进行各种调整与优化。

较强的沟通能力。能够通过沟通去推进并解决问题。

执行力。说到、做到、做好。

1架构师

通常需要多年的经验，能够设计系统架构，并保证架构的稳定性、可扩展性、性能等多项指标的可用性与优越性。一般的毕业生是不可能拿到这个职位的Offer的，多年经验的开发工程师也未必能够拿到这个职位。

2前端工程师

直接面向用户编程，是最接近用户的编程者，负责亲手把产品交给用户。某种程度上兼具产品和用户体验设计的部分职责，最后把关产品的设计。

3开发工程师

实现功能开发，让功能可用、易用，「码农」是最直接的描述，写代码的牛人或者普通人，偏向于后端。

4测试工程师

在规模中等及以上的公司里，会有专门的测试工程师，他们就是专门从事开发完成后的测试工作，找出Bug，写出报告，负责回归，确保上线前产品没有影响使用的重大Bug，甚至零Bug状态上线。

1渠道

主要是维系各类渠道，确保能够拿到渠道资源。

2推广

这个词儿比较宽泛，看公司如何定位「推广」的职责与范围，如果是App，那么渠道和推广可能是同一个职能，甚至合并起来的职位；如果是PC端，那么推广可能还需要考量广告投放、ROI等相关事项。

3商务合作

主要是去找寻外部可以合作的商户和资源，达成合作，可能涉及联合活动之类的业务。

EA建模软件安装包下载地址：http://pan.baidu.com/s/1dFibfED 密码: wrfd

仅供研究学习使用，切勿用于商业用途，你懂的！

欢迎大家踏上《软件过程》神奇而虐心的学习之路，这门课程需要我们打开视野，在更加广阔的层面看待世界，学习一些久经验证的优秀方法，解决真正的软件问题，为用户创造有价值的软件产品。学习这门课程，需要耐心和信心：大量反复地实践练习会消磨你的耐心，跨上更高的思维层面需要坚信自己能做到，这既是知识学习，也是品格磨练，唯勇者可行。