概要设计应该包括哪些内容

转自:http://learnsoftwareprocesses.com/2007/09/20/high-level-design-document-template/

The High Level Design Document is a pretty important document for a project, covering at a high level the overall design of the solution. If one were to try and present a very succinct summary of the High Level Document, it could be something like this:
– Detailed use case scenarios of key process flows of the application
– The class model and relationships
– The sequence diagrams which outline key use case scenarios
– The data/object model with relational table design
– User interface style and design

High-level design is the transitional step between WHAT [requirements for sub-systems] the system does,
and HOW [architecture and interfaces] the system will be implemented to meet the system requirements.
This process includes the decomposition of system requirements into alternative project architectures and
 then the evaluation of these project architectures for optimum performance, functionality, cost, and other issues
[technical and non-technical]. Stakeholder involvement is critical for this activity. In this step,
internal and external interfaces are identified along with the needed industry standards.
These interfaces are then managed throughout the development process.

Some examples of a High Level Document available at these links:
Link 1, Link 2, Link 3, Link 4

来自支付宝架构师的一些体会

来自支付宝架构师的一些体会,主要来源是支付宝架构师blog和dbanotes。记录一些有启发的架构细节和成长体会,让自己能够更准确的找到自身提升的方向方法。

今天的支付宝已经是一个用户超过2亿用户,每天交易笔数超过400万笔,交易量超过7亿的庞大平台。

现在,程立的团队依然保持着每周一次的发布速度,坚持每周系统更新。在准确性和时效性方面都要受到挑战。“技术是一个相对枯燥的部门,但是一旦沉进去之后却发现这真的是很有意思的一个部门,因为有挑战,所以有意思。”程立表示。

对于技术人才的成长,程立认为技术人员必须把自己的发展和公司的发展结合在一起。刚进公司的时候,他简单地认为只要愿意加班或者负责好自己的事情,就是敬业,但后来他才明白,做好一件事情并不代表敬业,敬业还要考虑做的这件事情的背后的意义是什么,公司和客户真正想要达到的结果是什么。将被动的工作转为主动,每个人都会发现自己有很多潜力可以去挖掘。

的确,支付宝的数据堪称海量,但相比之下,主要的压力还是来自对交易事务的处理上。我们也有一些密集型的后台计算,但相对规模不算特别大,当前的计算能力足以支撑, Continue reading “来自支付宝架构师的一些体会”

某对架构师的要求

从网上看到的某架构师的招聘要求:

The Senior Solution Architect (Systems) has a broad range of technical skills on systems solution. He/she involves leading the architecting and designing of systems solution consisting of Server, Blades, cluster, and management.

The Architect has overall responsibility for gathering customer’s business requirements, translating those requirements into cost-effective solution, strategies, architectures, and guiding the implementation of those solutions to deliver high quality outcomes to meet or exceed customer expectations in a timely manner.
Responsibilities and Accountabilities:
-Develop trusted advisor status with customers and provide technical leadership in architecting technical solution for customers.

-Act as lead architect, or as a member of a team of Architects to lead and oversee solution implementation and project delivery, including creation of detailed designs of storage solution. Continue reading “某对架构师的要求”

互联网知名公司项目经理面试中常被问到的问题

转载
以下是典型的项目管理面试中通常会问到的问题(期望的回答):很多的问题的答案是主观的,面试官想知道你的观点是否和他们的及公司一致。问题的构成如下:
1. 项目管理软件工具知识
2. 编制项目计划的技术
3. 人员管理技能
4. 沟通技能
5. 原理体系知识(标准开发生命周期和项目管理)。
项目管理软件工具知识
问题1:工期和工作量之间的差异是什么?
答案1:工期是商业/日历上的天数,与人数和工作量无关。工作量是与日历天数无关的人的工作。例如: 一天的工作量对于一个一只花50%在时间在上面的人来说,他的工期就是两天。如果两个人全职工作,工期是1天,而工作量是两个工作日。

问题2:怎样和为什么要在编制项目计划时考虑依赖关系?
答案2:根据使用的软件包,依赖关系可以通过将任务及其后续任务的标识符进行关联来表示。依赖关系说明了任务之间关联/并列的要求。依赖关系可以是指在另 一个任务能开始之前有一个任务必须完成。例如,逻辑模型必须在物理模型前完成。但测试并不是要在所有编程工作完成之后才开始,如果没有完成的程序对线性测 试没有影响。项目计划加入依赖关系,就能找出项目的关键路径并且能够确定它对项目工期的影响。

问题3:你怎样将人的工作步调与计划结合?
Continue reading “互联网知名公司项目经理面试中常被问到的问题”

话剧 – 疯狂的疯狂


今天陪老婆去上海话剧中心看了《疯狂的疯狂》,郑恺的版本。因为之前没有看过话剧,而且听说是和疯狂赛车同一个剧本而疯狂的赛车一直也没有提起兴趣看,所以也就没抱什么很大的期望。权当是支持话剧艺术了。

不过看到第一幕结束时候,我已经笑了n次了。不得不佩服这帮人的创意以及“杂烩”的能力,虽然没看过黄渤版的,但是可以肯定的说绝对和郑恺是两种风格 – 很简单,因为一个是帅哥,一个是丑角,说起来尤其是黄渤的发型,每次看到甚至想到这个发型我都要习惯性地摇摇头 – 尤其是在《石头》里的那一甩,让我等这些石头迷真是顶礼膜拜呀!扯远了。

其实剧里最出彩的不是主角郑恺饰演的赛车手耿浩,而是雷佳音饰演的刘小道,包括那个饰演16岁刘小道的演员。尤其是回忆郝浩捡肉夹馍那段扮演风中的小女孩的造型,哈哈,现在想起来都tm兜不住。不知道刘桦饰演的小道是什么样子。

这样的话剧还是值得一看的。

摘些经典台词:

1.用的单词都是四级—-以下

2.别煽情了,又不是鲁豫有约

3.你的眼里充满了血丝

采女孩的老蘑菇,哈哈!

还是关于看板(kanban)

还是关于看板,其实看板是一个很通用的概念
可以理解为简化的mpp,它只关注任务的生命周期,通过简化的资源分配来达到精益化,时刻跟踪生产进度和物料使用情况。其实软件过程也同样适用,说到底他还是一种任务调度、资源分配并跟踪的方法。无论他的形式是通过看板、mpp还是备忘录。只是相比之下,看板所要关注的总是第一线的生产,而不是很虚幻的项目管理,规划。

可以说,看板,或者lean和agile有很大的相似之处。二者同样偏重于delivery,强化第一线生产的重要,并通过一系列的措施确保产品质量 – 比如资源耗用,人员调整的跟踪,以及deadline-driven。都是偏重执行情况的track。

也许应该有一个通用的看板应用出现。目前还需要足够多的试错来验证看板的重要性。

深入阅读(来自infoq的几篇文章):
The Current Direction of Agile

Lean and Agile: Marriage Made in Heaven or Oxymoron?

Kanban Applied to Software Development: from Agile to Lean