导航↓ 相册|收藏博客|加入友情链接|给博主留言
我要啦免费统计阅读使人充实,会谈使人敏捷,写作与笔记使人精确。史鉴使人明智;诗歌使人巧慧;数学使人精细;博物使人深沉;伦理之学使人庄重;逻辑与修辞使人善辩。-培根
黑猫大队长
2018-1-15 21:46

™™™
2017-10-18 10:12
™™™
2017-10-18 10:11
™™™
2017-10-18 9:52
Z浪迹天涯
2017-10-16 1:3
sunnyrl
2017-9-13 12:2
pangdan2007
2017-7-10 19:54
  • 创建:2007/2/23
  • 文章:973
  • 评论:5127
  • 访问:954950
  •  

什么是交互设计(Interaction Design)

在使用网站,软件,消费产品,各种服务的时候(实际上是在同它们交互),使用过程中的感觉就是一种交互体验。随着网络和新技术的发展,各种新产品和交互方 式越来越多,人们也越来越重视对交互的体验。当大型计算机刚刚研制出来的时候,可能为当初的使用者本身就是该行业的专家,没有人去关注使用者的感觉;相 反,一切都围绕机器的需要来组织,程序员通过打孔卡片来输入机器语言,输出结果也是机器语言,那个时候同计算机交互的重心是机器本身。当计算机系统的用户 越来越由普通大众组成的时候,对交互体验的关注也越来越迫切了。


因此交互设计(Interaction Design)作为一门关注交互体验的新学科在二十世纪八十年代产生了,它由IDEO的一位创始人比尔"莫格里奇在1984年一次设计会议上提出,他一开始给它命名为“软面(Soft Face)”,由于这个名字容易让人想起和当时流行的玩具“椰菜娃娃(Cabbage Patch doll)”,他后来把它更名为“Interaction Design”―交互设计。

 
从用户角度来说,交互设计是一种如何让产品易用,有效而让人愉悦的技术,它致力于了解目标用户和他们的期望,了解 用户在同产品交互时彼此的行为,了解“人”本身的心理和行为特点,同时,还包括了解各种有效的交互方式,并对它们进行增强和扩充。交互设计还涉及到多个学 科,以及和多领域多背景人员的沟通。通过对产品的界面和行为进行交互设计,让产品和它的使用者之间建立一种有机关系,从而可以有效达到使用者的目标,这就 是交互设计的目的。
 
交互设计和界面设计
 
界面设计是交互设计的很小一部分。界面设计是死的,关注的是个体U……
编辑 | 阅读全文(3079) | 回复(5),人月&神话 发表于 2008-1-3 19:54

2007-7-17 13:20 | 个体软件过程

      PSP (Personal Software Process) 是一种可用于控制、管理和改进个人工作方式的自我持续改进过程,是一个包括软件开发表格、指南和规程的结构化框架。PSP与具体的技术(程序设计语言、工具或者设计方法)相对独立,其原则能够应用到几乎任何的软件工程任务之中。PSP能够说明个体软件过程的原则; 帮助软件工程师作出准确的计划;确定软件工程师为改善产品质量要采取的步骤;建立度量个体软件过程改善的基准;确定过程的改变对软件工程师能力的影响。[51CMM]
 
      做了几年的软件设计和开发,自己的设计开发生产率究竟如何,完成一个项目的时候用于实际开发时间,解决问题和查找资料的时间,沟通的时间,修复BUG和维护时间究竟比例是如何的,每完成一个项目自己对自己整个项目阶段活动是否进行了评估了总结,确认自己的技能提升和改进点,相信这些内容往往仅仅在我们头脑里面有个模糊的概念而没有一个确切的数据支持,这样的话这些概念就很难去指导我们个人的行动和改进计划。
 
      当不考虑个人的因素和创造力时候,我们过程改进的推动思路是从组织级推动到项目和个人。但最终人不是机器,所以过程改进更需要有个人推广到项目再推广到组织级,个体在实际工作总真正的数据收集才是最准确和可以参考的经验数据,只有项目中的每个成员知识和技能都得到提高和达到了要求才能真正的保证项目的成功,而我们往往常犯的错误是项目一开始就直接假设了项目成员知识和技能都达到了要求,不考虑个体的差异,认为一个工作任务不论交给谁来完成都是需要估算的工作量时间。
 
    &nbs……
编辑 | 阅读全文(2085) | 回复(0),人月&神话 发表于 2007-7-17 13:20

2007-7-17 13:20 | IT知识体系结构图

用Excel描述的IT知识结构。黄色为Level1的内容,绿色为Level2的内容,暗红色为Level3的内容,体系知识的层次关系。
 
知识按软件生命周期各阶段进行了划分,各生命周期相关阶段知识存在重叠。
 
 
用MindManager画的思维导图:
 
 
 
编辑 | 阅读全文(4937) | 回复(1),人月&神话 发表于 2007-7-17 13:20

2007-7-17 13:20 | 老贴-侯捷东软讲座

2002年10月,东软邀请台湾著名学者侯捷先生发表了以“自其不变而观之”为主题的演讲,演讲活动分别在沈阳、大连两地举行。侯捷先生作为IT资深专家,已先后出版了40余本专著、译著,在业界享有很高的知名度,因此演讲活动受到员工的热烈欢迎,两地共有600余名员工参加了演讲会。演讲中,侯捷先生通过讲述其个人的发展历程,就软件技术人员的职业发展、技术成长等方面问题与东软员工进行了交流,并建议大家在职业发展道路上一定要做到以下几方面:
 
1.以兴趣为要
侯捷先生认为虽然很多人在选择职业时受到家庭、环境等方面因素的影响,不一定能从事自己非常感兴趣的工作,但是如果可能的话,一定要以兴趣为要,这样在工作时会很开心,在个人发展方面也会取得很好的成就。因为只有兴趣才能使你乐在其中,乐在其中你才会产生热情,充满热情才能使你做到卓越。
 
2.正确的认知
侯捷先生将认知的重要性归纳为“认知影响态度,态度决定一切”。他认为一个人在选择发展道路时尤其重要的是要对自己有一个正确的认知。每个人的兴趣可能会变,有些人看到某个行业有发展,有前途,因此对这个行业业、这条路产生很大兴趣,这是非常可能的。但是每个人的本质基本不变,你是否甘于寂寞,是否能够与寂寞为伍?你的抗压性怎么样?你的毅力强不强?你的心理素质如何?这些特质都是不宜改变的,而且只有你自己才能给出这些问题的准确答案。只有对自己有了正确的认知后才能决定往哪个方向发展。他认为做IT产业非常寂寞,也非常辛苦,大家可能在周末的晚上都要加班,这就要求从事该产业的人必须甘于寂寞,具备一定的忍耐力。侯捷先生在年轻的时候非常努力,曾被称为部门的“门神”,通常都是最早来,最晚走!他认为如果一个人喜欢交际应酬,喜欢公关,就应该尽早离开这个行业,因为选择道路一定要忠实于你的本质、你的兴趣。
 
3.EQ比IQ更重要
侯捷先生认为有能力读……
编辑 | 阅读全文(1618) | 回复(0),人月&神话 发表于 2007-7-17 13:20

2007-7-17 13:20 | IT人员能力成熟度

编辑 | 阅读全文(1516) | 回复(0),人月&神话 发表于 2007-7-17 13:20
方法论的英文为Methodology,词典中的解释为"A series of related methods or techniques"我们可以把它定义为软件开发(针对软件开发)的一整套方法、过程、规则、实践、技术。关于方法论的出现的问题,我很赞同Alistair Cockburn的一句话,"方法论源于恐惧。"出于对项目的超期、成本失控等等因素的恐惧,项目经理们从以前的经验出发,制定出了一些控制、监测项目的方法、技巧。这就是方法论产生的原因。

在Agile Software Development一书中,作者提到了方法论的十三个要素,基本能够函盖方法论的各个方面:
角色(Roles)
个性(Personality)
技能(Skills)
团队(Teams)
技术(Techniques)
活动(Activities)
过程(Process)
工件(Work products)
里程碑(Milestones)
标准(Standards)
质量(Quality)
工具(Tools)
团队价值(Team Values)
 
管理,被称为科学和艺术的融合体,而管理的艺术性部分很大程度的体现为人的管理上。我说,方法学,一样是科学和艺术的融合体。这是有依据的,其实方法论和管理学是近亲关系,管理学中有一门分支是项目管理,而在软件组织中,项目管理是非常重要的,方法学就是一种针对软件开发的一种特定的项目管理(或是项目管理的一个子集)。
 
重型方法最大的一个问题就在于他不清楚或忽略了艺术这个层次,忽视了人的因素,把人做为一……
编辑 | 阅读全文(2247) | 回复(0),人月&神话 发表于 2007-7-17 13:20
可视化项目管理一书也提到了V型模型,重点也是强调产品整个生产过程中都附带着产品的确认和验证过程;
 
我们正向可以通过评审和代码走查来发现缺陷,逆向一般通过测试环节来保障。
 
CMMI两个关键过程域,一个是确认(Verify),一个是验证(Validate).我的理解是确认更多的是希望你正向发现问题,而验证则是逆向发现问题。正向发现问题,发现各阶段的缺陷,减少缺陷泄漏率,是最佳降低成本和工作量的方式。
 
编辑 | 阅读全文(1360) | 回复(0),人月&神话 发表于 2007-7-17 13:20

2007-7-17 13:19 | 源代码就是设计-摘录

实际的软件运行于计算机之中。它是存储在某种磁介质中的0和1的序列。它不是使用C++语言(或者其他任何编程语言)编写的程序。

程序清单是代表软件设计的文档。实际上把软件设计构建出来的是编译器和连接器。
 
构建实际软件设计的廉价程度是令人难以置信的,并且它始终随着计算机速度的加快而变得更加廉价。

设计实际软件的昂贵程度是令人难以置信的,之所以如此,是因为软件的复杂性是令人难以置信的,并且软件项目的几乎所有步骤都是设计过程的一部分。

编程是一种设计活动——好的软件设计过程认可这一点,并且在编码显得有意义时,就会毫不犹豫的去编码。

编码要比我们所认为的更频繁地显现出它的意义。通常,在代码中表现设计的过程会揭示出一些疏漏以及额外的设计需要。这发生的越早,设计就会越好。

因为软件构建起来非常廉价,所以正规的工程验证方法在实际的软件开发中没有多大用处。仅仅建造设计并测试它要比试图去证明它更简单、更廉价。

测试和调试是设计活动——对于软件来说,它们就相当于其他工程学科中的设计验证和改进过程。好的软件设计过程认可这一点,并且不会试图去减少这些步骤。

还有一些其他的设计活动——称它们为高层设计、模块设计、结构设计、构架设计或者诸如此类的东西。好的软件设计过程认可这一点,并且慎重地包含这些步骤。
 
所有的设计活动都是相互影响的。好的软件设计过程认可这一点,并且当不同的设计步骤显示出有必要时,它会允许设计改变,有时甚至是根本上的改变

许多不同的软件设计符号可能是有用的——它们可以作为辅助文档以及工具来帮助简化设计过程。它们不是软件设计。

软件开发仍然还是一门工艺,而不是一个工程学科。主要是因为缺乏验证和改善设计的关键过程中所需的严格性。

最后,软件开发的真正进步依赖于编程技术的进步,而这又意味着编程语言……
编辑 | 阅读全文(1667) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 编程规则-转载

规则一 这世界上唯一的真理就是不要盲目相信真理
从某种意义看,原则、规矩这类东西就是用来打破的。所谓原则,就是对历史上某种经验的总结。如果我们踏入的河流和前人非常接近,我们可以参考前人的经验。我们是主动地拿来,而不是被动的遵守。
 
规则二 未蕴而变,自欺也;知律而变,智者之道也
这句话谈的是学词,必须先了解格律,然后才谈得上变化,否则就是自欺欺人了。在编程上,也是一样。在有资格打破一条原则前,首先要了解这条原则。先了解事物的规律,然后才是变化和灵活的应用。不要打倒自己不了解的东西。
 
规则三 寻找结构和成本的平衡点。当结构不能容纳变化时,重构代码到新的平衡点
开闭原则要求:一个软件实体应该对扩展开放,对修改关闭。即软件的结构要达到:允许在不修改软件的前提下扩展软件功能。
但好结构是要花成本的。程序员总是在折衷,寻找结构和成本的平衡点。我们会放一些余量,让结构能承受一定的变化。
 
规则四 要针对接口编程,不要针对应用编程
前面谈过了。我们总希望通过工作得到一些收获,积累一些经验。只有将代码分解成尽可能独立的模块,然后针对接口编程,才能保护我们的成果,让我们有所积累。
 
规则五 最少知识原则:模块对外界的了解应当尽可能少
前面也谈过了。所谓“圣人之治”,经常是“虚其心,实其腹;弱其志,强其骨,常使民无知无欲”。让被管理的对象尽可能得弱,对象间的关系尽可能得简单,可以降低管理的成本。
在面向对象编程中“组合优于继承”,就是因为继承将基类的实现细节暴露给子类,两者的耦合性太强了。另外,继承的实现是静态的,而组合可以更灵活地实现。
 
规则六 尊重习惯
在任何领域编程,应该尽量了解这个领域的习惯,尽量符合这些习惯。这样,别人可以更容易地理解和使用我们……
编辑 | 阅读全文(1398) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | RUP过程误解清单

您认为起始阶段 = 需求;细化阶段 = 设计;构造阶段 = 实现。
 
您认为细化阶段的目的是为了完整细致地定义模型,并在构造阶段将它翻译成代码。
 
您认为在细化阶段只需创建原型(事实上,应该在细化阶段针对高风险的架构元素编程实现具有产品级质量的核心子系统)。
 
您试图在开始设计或实现之前定义绝大部分的需求,或者在开始实现之前完成绝大部分的设计。
 
您认为一个合适的迭代长度只能以月为单位来计算,而不是周。
 
您认为编程之前的 UML 绘图和设计活动阶段是为了完整地、精确地定义极其详尽的设计与模型,认为编程只是简单、机械地把模型翻译成代码。
 
您企图从头至尾详细地计划一个项目,然后把工作分配到每一个迭代;竭尽全力地企图预测所有的迭代以及在每一个迭代中发生的情况。
 
一个组织在进入细化阶段之前,就要求获得可信的计划和估算。
 
一个组织认为实施 RUP 就意味着从事尽可能多的活动或创建大量的文档,把 RUP 当作一个有许多步骤需要遵循的规范过程来运用。
编辑 | 阅读全文(1753) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 软件开发过程法则

Software is a knowledge medium.
软件是知识的载体
 
The "product" is the knowledge contained in the software.
我们真正创造的产品不是软件本身,而是蕴涵在软件中的知识和学问。
 
The activity of developing software is the activity of acquiring specific types of knowledge and translating that knowledge into a specific language form known as "code."
软件开发的过程就是我们去获取特定类型知识的过程。而我们所知的编码活动就是将我们获取的知识转化为系统中的一个功能或表单。
 
求知的五重境界
0OI: I have the answer. Developing a system is simply a matter of transcribing what I already know, into the appropriate programming instructions
我知道答案,开发系统简单的仅仅是将我所知道的东西翻译为适当的程序指令。
 
1OI: I have the question, and I either know how to get the answer to it (I have 0OI about the activity of answer acquisition) or I do not know how to get the answer (I have 1OI about answer acquisiti……
编辑 | 阅读全文(1624) | 回复(0),人月&神话 发表于 2007-7-17 13:19
注:该文未经允许不要随便转载
 
虽写明该文不允许转载,但仍然被CSDN随意转载,在此将该文删除。
需要学习敏捷开发的推荐看该文作者翻译的《敏捷软件开发-原则模式与实践》一书。
 
 
 
 
编辑 | 阅读全文(1315) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 软件架构师-转载自IBM

在电影制作术语中,软件项目经理被称作制作人,因为他们决定需要做什么事情。而软件构架师就是导演,他来决定所作的事情是否正确,并且他要保证产品符合投资人的要求。下面这篇文章就是描述软件构架师的。 illustration这篇文章是关于软件构架的系列文章(共四篇)中的第二篇。上个月,这个系列文章中的第一篇给构架作了一个定义。因此现在我们可以把注意力集中到创建构架的人员——构架师身上。软件构架师被证明是软件开发项目过程中最具挑战性的角色。软件构架师是项目的技术领袖,并且从技术角度来讲,他承担了项目成败的责任。
下面是电气及电子工程师协会给“构架师”做的定义:
软件构架师是技术主管
首先,软件构架师是技术主管,这意味着除了他要有技术上的技能外,还要有很好的领导才能。构架师的领导能力在团队中和项目质量控制中起着十分重要的作用。
在团队中,构架师是项目的技术总管,他需要有丰富的知识背景,以便作出技术上的决定。相对于构架师来说,项目经理是来管理项目的资源,时间进度和花费的。使用电影制作来做类比的话,项目经理就是制片人(他要确定工作被完成了),而构架师是导演(他需要确定工作被正确的完成)。由于他们在项目中所处的位置,构架师和项目经理是公众人物,在一个团队中,他们是整个项目所涉及的所有人员的联系枢纽。构架师应该为建立软件构架争取投资,并且要明确建立软件构架能给组织带来的价值。
构架师还要把团队组织在构架周围,并且要积极地投入到计划活动上,因为要把构架转化成为完成任务的先后顺序,这样才能及时地确定在什么位置需要什么技术。有一点需要注意,由于构架师能否成功与团队的整体水平有很大关系,所以构架师应该参与团队新成员录用的面试。
根据构架师所拥有的能力,他可以同时参与其他团队的工作。构架师需要根据具体的实例情况来做领导决定,并且在决定过程中要展现出足够的自信。一个成……
编辑 | 阅读全文(2290) | 回复(1),人月&神话 发表于 2007-7-17 13:19
你们的项目组使用源代码管理工具了么?
采用ClearCase进行源代码管理,同时启用开发,测试,集成三个分支,对于Bug分支根据版本实际情况确认是否启用。
 
你们的项目组使用缺陷管理系统了么?
使用ClearQuest管理缺陷和变更
 
你们的测试组还在用Word写测试用例么?
采用TestManager写测试用例和管理测试用例,必要配合Excel进行。
 
你们的项目组有没有建立一个门户网站?
项目有专门的讨论工作室。
 
你们的项目组用了你能买到最好的工具么?
能够买到。主要是VS.Net和PL/SQl Developer.其它辅助工具全部用开源工具。如打包采用Nant,反翻译采用Reflector,单元测试采用Nunit.
 
你们的程序员工作在安静的环境里么?
是的,有独立安静空间。
 
你们的员工每个人都有一部电话么?
一般两人一部电话,还可以通过RTX进行沟通。
 
你们每个人都知道出了问题应该找谁么?
知道
 
你遇到过有人说“我以为…”么?
有时候会遇到,但情况不多。
 
你们的项目组中所有的人都坐在一起么?
没有。全部座来分开,通过RTX即时通讯,邮件,电话进行沟通。
 
你们的进度表是否反映最新开发进展情况?
有及时准确的进度表,但不是每个项目成员都很容易看到。进度表有专门的基线和里程碑的定义。
 
你们的工作量是先由每个人自己估算的么?
不是开发人员自己估算,是有项目的估算小组进行估算。估算时候会适当考虑个体差异。
 
你们的开发人员从项目一开始就加班么?
基本不会。
 
你们的项目计划中Buffer Time是加在每个小任务后面的么?
不是……
编辑 | 阅读全文(1370) | 回复(0),人月&神话 发表于 2007-7-17 13:19

2007-7-17 13:19 | 软件开发管理模式

SCRUM
由Ken Schwaber和Jeff Sutherland提出和倡导
是一种极为轻型的灵活性模式的翻版
非完整的:没有整个流程的定义
采用所谓的"sprints",即一般是一个月为周期,来进行循环式的短期性的开发和发行管理
每天进行15分钟的团队“scrum会议”
采用每天进行项目的最新状态汇报,发表“burn down graph”
适合于整个开发团队在同一个大房间里一块工作
scrum本意是指橄榄球在开赛前的手拉手聚在一起商议进攻方案,在这里是指项目管理的模式,指每天在开始工作前要所有团队成员在一起开会,商讨当天的工作和遇到的问题。
 
Adaptive Software Development(ASD)
由Jim Highsmith提出和倡导
也是一种轻型的灵活性模式,强调在混乱的边缘上争取平衡
不要求执行者完全按照流程规则来做
在项目周期里安排一个学习阶段,具体解决哪些是重要的开发任务
将项目的历程分成3个阶段:思索、合作、学习(speculate,collaborate,and learn)
讲究在合作阶段进行循环式的重复渐进,采取“时间盒”(TimeBoxed)的方法
 
Crystal
由Alistaire Cockburn提出和倡导
灵活性模式的一种,尊重不同大小的项目在管理上需要有不同程度的正式性管理规章,强调在完成目前的开发项目的同时,要将眼光放在开发团队和企业未来的位置
使用几个不同的管理方式:透明、黄色、桔黄、红色等模式
采用轻型化的规章制度
比较注重项目文档的用途,要求管理人员使用各种文件来帮助管理
 
eXtreme Programming(XP)
由Kent Beck,Ward Cunningham,Ron Jeffries提出和倡导
……
编辑 | 阅读全文(2372) | 回复(0),人月&神话 发表于 2007-7-17 13:19
(共 99 条) 上一页 1 2 3 ... 6 7 翻页至

仅列出标题