29 一
2012

Posted in: 项目需求分析
By alex    No Comments

浅谈软件项目管理

项目管理是管理科学的一个分支, 同时又与项目相关的专业技术领域不可分割。项目管理是一个很宽泛的领域，他不仅包括软件项目管理，其他任何可以作为项目执行的事务，均可采用项目管理方法。

项目管理过程分为五类：

1) 启动。成立项目组开始项目或进入项目的新阶段。启动是一种认可过程，用来正式认可一个新项目或新阶段的存在。

2) 计划。定义和评估项目目标，选择实现项目目标的最佳策略，制定项目计划。

3) 执行。调动资源，执行项目计划。

4) 控制。监控和评估项目偏差，必要时采取纠正行动，保证项目计划的执行，实现项目目标。

5) 结束。正式验收项目或阶段，使其按程序结束。

每个管理过程包括输入、输出、所需工具和技术。各个过程通过各自的输入和输出相互联系，构成整个项目管理活动。

九个知识领域

1、项目集成管理(Project Integration Management)

项目整体管理是为了正确地协调项目所有各组成部分而进行的各个过程的集成, 是一个综合性过程。 其核心就是在多个互相冲突的目标和方案之间作出权衡, 以便满足项目利害关系者的要求。

2、项目范围管理(Project Scope Management)

项目范围管理就是确保项目不但完成全部规定要做的, 而且也仅仅是完成规定要做的工作，最终成功地达到项目的目的。基本内容是定义和控制列入或未列入项目的事项。

3、项目时间管理(Project Time Management)

其作用是保证在规定时间内完成项目。

4、项目费用管理(Project Cost Management)

项目费用管理, 是为了保证在批准的预算内完成项目所必需的诸过程的全体。

5、项目质量管理(Project Quality Management)

项目质量管理, 是为了保证项目能够满足原来设定的各种要求。

6、项目人力资源管理(Project Human Resource Management)

项目人力资源管理, 是为了保证最有效地使用参加项目者的个别能力。

7、项目沟通管理(Project Communications Management)

项目沟通管理, 是在人、思想和信息之间建立联系, 这些联系对于取得成功是必不可少的。参与项目的每一个人都必须准备用项目“语言”进行沟通, 并且要明白, 他们个人所参与的沟通将会如何影响到项目的整体。 项目沟通管理是保证项目信息及时、准确地提取、收集、传播、存贮以及最终进行处置。

8、项目风险管理(Project Risk Management)

项目风险管理, 需要的过程有识别、分析不确定的因素, 并对这些因素采取应对措施。 项目风险管理要把有利事件的积极结果尽量扩大, 而把不利事件的后果降低到最低程度。

9、项目采购管理(Project Procurement Management)

项目采购管理, 需要进行的过程都是为了从项目组织外部获取货物或服务。

项目管理试图获得对5个变量的控制：

• 时间
• 成本
• 质量
• 范围
• 风险

有三个变量可以由内部或者外部的客户提供。其余的变量则由项目经理，理想地基于一些可靠的估计技术来设定。这些变量的最终的值还需要在项目管理人员与客户的协商过程确定。通常，时间、成本、质量和范围将以合同的方式固定下来。

13 一
2012

Posted in: 网站架构
By alex    No Comments

程序前端模块化设计思路

模块化概念

模块化就是为了减少循环依赖，减少耦合，提高设计的效率。为了做到这一点，我们需要有一个设计规则，所有的模块都在这个规则下进行设计。良好的设计规则，会把耦合密集的设计参数进行归类作为一个模块，并以此划分工作任务。而模块之间彼此通过一个固定的接口（所谓的可见参数）进行交互，除此之外的内部实现（所谓的隐参数）则由模块的开发团队进行自由发挥。

程序模块化的目的：

减少循环依赖 减少耦合 提高设计效率

程序模块化的实施：

把耦合密集的归为一个模块 模块间通过固定的接口交互 模块内部实现自由发挥

HTML CSS Images的模块化设计

页面模块化的实施，这里指的是针对除去JavaScript部分的页面代码进行模块化实施。通过html css 图片进行模块化。

页面模块化的实施思路是高度耦合的页面片段封装，模块布局作为公开接口，高度耦合的页面进行封装，使用独立的css文件，高度耦合的图片进行封装，给某类相关性强的图片建立文件夹。

页面模块化的目的是，实现多人协同开发页面，提高页面研发速度和降低维护难度。研发速度的提升体现在多人协同并行开发， 维护难度体现在减少版本的混乱，根据模块区分版本降低版本间代码冲突和文件错误覆盖。

　　拆分页面模块，从小到大的分解

1. 拆分页面模块

一个页面有很多个小单元模块组成，他来自有原始需求文档，比如logo，导航，内容1，内容2，内容3，内容4，尾部导 航，版权信息等等。根据他们就可以拆分出基本的模块。

2. 拆分网站模块

将整个网站安排频道或者分类进行拆分，比如首页，内容页，文字列表页，图片列表页，频道1页面，频道2页面，分类1页面，分类2页面，后台管理页面，等等。

3. 每个网站作为一个模块。比如商城站，支付站，论坛，三个站独立为三个大模块。

　　模块化实现

1. 高度耦合提取为一个模块，用模块代码作用域进行控制

代码1. 非继承模块，通过后代选择符方式控制作用域

<div>
<h3>title</h3>
<div>
        con
    </div>

    <a>more</a>
</div>

.mod {}
.mod .title {}
.mod .con {}
.mod .more {}

<div>
<ul>
<li><a href="" title="">关于</a></li>
<li><a href="" title="">合作</a></li>
<li><a href="" title="">招聘</a></li>
</ul>

Copyright © 2009 某公司 版权所有
</div>

.footer {}
.footer ul {}
.footer p {}

代码2. 继承模块，提取众多模块中公共部分，具体模块通过优先级进行处理。继承模块方面整站某些模块的批量修改处理，也提高复用性，降低代码重复。

.mod {}
.mod .title {}
.mod .con {}
.mod .more {}

.note {}
.note .title {}
.note .con {}
.note .more {}

<div>
<h3>title</h3>
<div>
        con
    </div>

    <a>more</a>
</div>

2. 页面模块

页面模块代码作用域的控制通过css文件来控制。某类具有高度耦合的页面使用自身的css文件。

3. 模块间的公开接口

上面是模块的封装，公开的接口在页面中表现为什么？

首先是reset，base，可继承模块，这些代码是开放接口，必须根据这些代码进行页面代码开发，也就是你的页面代码必须在以上代码基础上开发。

其次是css文件，css文件名称和它作用于那些页面。

再次是布局、模块class，id命名，模块在页面的哪个位置。在CSS中的表现就是定位，布局，和部分盒模型。float、position、 width、height等等。布局通常使用css作为接口实现，如果布局具有高度的逻辑性，完全可以通过html和css组合进行，比如960 Grid System，或者采用YUI grid.css。模块class和id的命名用于区分模块，不能在一个页面的所有css中出现不同模块同用一个class和id名。

规划整站模块

上文提到的基本的原理，真正实施起来还是存在很多问题，模块粒度问题，公共模块与普通模块的区分，继承模块是否值得继承等等，页面模块如何划分。

首先，了解你的项目，通过画网站树状图了解你网站的总体结构和页面模块。

其次，理清结构逻辑和视觉逻辑，结构逻辑就是看你的页面由那些模块组成，视觉逻辑了解可继承模块，布局逻辑（网格布局或者非网格布局）

11 一
2012

Posted in: 项目需求分析
By alex    No Comments

WBS:工作分解结构（Work Breakdown Structure）

WBS：工作分解结构（Work Breakdown Structure） 创建WBS：创建WBS是把项目可交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。

一、WBS的定义

WBS（工作分解结构）是Work Breakdown Structure的英文缩写，是项目管理重要的专业术语之一。WBS的基本定义 ：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。无论在项目管理实践中，还是在PMP，IPMP考试中，工作分解结构(WBS)都是最重要的内容之一。WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。

WBS是由3个关键元素构成的名词：工作（work)–可以产生有形结果的工作任务；分解(breakdown)–是一种逐步细分和分类的层级结构；结构(structure)–按照一定的模式组织各部分。根据这些概念，WBS有相应的构成因子与其对应：

26 十二
2011

Posted in: 软件框架架构
By alex    No Comments

软件架构的作用

软件架构对新产品开发、产品线开发、软件维护以及软件升级都有很重要的作用。

软件架构对新产品开发的作用：软件架构是沟通现实世界和计算机世界的一座桥。

1.       上乘业务目标。软件架构担负着为完成业务目标而进行大局规划的职责。

2.       下接技术决策。将面向业务的需求转向面向技术的软件架构设计方案，为后面的技术开发工作提供切实的指导和限制。

3.       控制复杂性。基于‘分而治之’的思想，控制问题的复杂性。

4.       组织开发。

5.       利用迭代开发和增量交付。

6.       提高质量。

软件架构对软件产品线开发的作用

1.       固化核心知识。

2.       提供可重用资产。

3.       缩短推出产品周期。

4.       降低开发和维护总成本。

5.       提高产品质量。

6.       支持批量定制。

什么是软件产品线架构：针对一个公司或者组织内部一系列产品而设计的通用架构。这一系列产品具有很多相似性，从而它们可以共享同一个架构和部分具体实现，提高生产率。

软件产品线架构的特点

1.       必须考虑一系列明确许可的变化。

2.       一定要文档化。

3.       必须提供‘产品创建者指南’，描述架构的实例化过程。

软件架构对软件维护的作用

维护工作的两个来源：Bug和需求变更。

一个Bug的修复或者一个新功能的增加，往往涉及架构中的一条‘模块协作链’，因此谅解架构将有利于维护工作；反之，不了解架构而盲目修改程序，可能违背架构设计的思路，使整个系统的架构慢慢变得混乱，并可能引发出其他莫名其妙的Bug和问题。

软件架构对软件升级的作用

软件架构对这对软件系统不断修改，也需要进行重构，在以下两种情况，需要进行重构：

1.       架构太混乱，以致进行一个小的改动都会牵动全身。

2.       将要进行的软件升级力度很大，原先的架构已不再适应新的需求。

软件架构重构属于‘再工程’的一种情况，一般会经过逆向工程、重新规划和正向工程3个步骤。

参考文献：

《软件架构设计》  温昱

23 十二
2011

Posted in: 产品运营
By alex    No Comments

产品管理(product management)

什么是产品管理

对产品管理的一个通常的定义是：把企业的一部分(通常是一个系列的产品)拿出来当作“虚拟企业”来管理。

从过程来看，产品管理是对产品进行全生命周期管理。按顺序，它应该包括四个环节，即产品战略管理、产品市场管理(或称产品营销管理)、产品研发管理和产品生命周期管理。

从本质上看，产品管理是一种授权下的责任机制，类似我们经常提到的“承包责任制”。

从组织模式看，产品管理是一种横向的矩阵组织结构。它需要充分依靠和利用纵向的资源部门和专业能力。

对产品管理还可以有其它不同角度的理解。

产品管理的内容

产品管理通过全方位的资源统筹，最有效率和最有效果的满足客户需求。所以，产品管理应当包含以下几个方面的内容：

第一，对产品的管理；第二，对产品生产与研发资源的管理；第三，对于产品研发与生产人员的管理；第四，对产品研发与生产过程的管理；第五，对产品环境的管理。

仅仅对于这些内容进行管理，绝对无法完成产品管理所要达到的使得公司效益显著提高的要求。因此，产品管理的核心内容，就是要管理这种使产品研发、生产与销售行为得以实现并为企业取得效益的能力。这种能力是一个企业获得产品竞争优势的核心竞争力。 Read more >>

12 十二
2011

Posted in: 项目需求分析
By alex    2 Comments

需求分析之六大原则

需求分析的六个原则（一）永远不要显得比客户更聪明

1、需求分析第一个原则：永远不要显得比客户更聪明。
聪明反被聪明误，这样的事情太多了，我们产品经理都是有智慧的人，而不是耍小聪明的人。
2、原则第一点：了解需求，而不是去批评客户。
产品经理不是批评家，心理上要重视客户，行动上要尊重客户，平等对待每一个客户。
3、 原则第二点：客户比你更熟悉业务的环境。
产品经理熟悉的仅仅是产品本身，但是，产品经理要做的却不仅仅是产品本身。
4、原则第三点：真正的问题只有客户知 道，我们要做的就是让客户愿意说出来。
客户会给你反馈，但是这些反馈有些是真实的，有些是敷衍的，你希望真实还是敷衍，请参考原则第一点。

需求分析的六个原则（二）尊重用户的现实选择

1、需求分析第二个原则：尊重用户的现实 选择。
产品是客观的，用户是客观的，使用是客观的，需求也是客观的，一切都是现实的。
2、 原则第一点：客户永远是对的。
客户不是我们的敌人，客户不会害我们，客户提出的需求看似在为难我们，但本质上是为了让客户自己更好的使用产品，因此，客户不会为难自己。
3、 原则第二点：提供最合适的解决方案，而非最好或最贵的方案。
我们能够做的不一定是最好的，我们不想做的有时候往往是客户最需要的，找到最合适客户的，而不是最合适我们的。
4、 原则第三点：不要把客户当傻瓜。
这个世界上没有傻瓜，自以为对方是傻瓜的人才真的是傻瓜，不要忽悠客户，不要欺骗客户，如果非要在这个前面加上一个期限的话，我希望是“永远”。 Read more >>

10 十二
2011

Posted in: 软件框架架构
By alex    No Comments

Zachman企业架构框架

早在1987年，John Zachman就提出： “为了避免企业分崩离析，信息系统架构已经不再是一个可有可无的选择，而是企业的必需”。 从那时起，Zachman的企业架构理论就开始逐渐发展起来， 它现已成为许多大公司用来理解、表述企业信息基础设施的一个直观模型， 为企业现在的以及未来的信息基础设施建设提供了蓝图和架构。
Zachman的企业架构是一个全新的模型，为企业信息基础设施提供一种可以理解的信息表述。 这个框架得到广泛的认同，Zachman 自然而然就成为 ZachmanFramework 之父。其大意是说，对同一个信息系统，不同的人看同一个问题，其结果是不同的。
Zachman没有把企业的流程简单视作一系列步骤，而是综合考虑不同角色的不同观点，提出了一个多视角、多维度的企业架构。
企业架构中的不同角色
·企业拥有者
·业务管理者
·系统分析者
·系统设计者
·系统建设者
·系统本身
下图的各行内容即反映了不同角色的不同关注点（角度）。
Zachman同时承认每个角色均关注相同的信息类别（维度），即下图各列内容：

企业架构的信息类别
数据（什么？）
功能（怎样？）
网络（哪里？）
时间（何时？）
角色（谁？）
动机（为何？）
企业架构理论术语
“企业”（Enterprise）是指由一整套可识别的、互为作用的业务功能构成的商业组织。 它有能力作为独立实体经营运作。 根据这一定义，就应该存在企业内的企业。 只要企业内部的事业部门能够独立运作，它或许就可以被当作一个企业。 在这里，这一企业概念也可以被看作为“扩展企业”（Extended Enterprise），它意味着企业架构框架也包括了企业与外部实体的相互关系。 例如： 供应商、商业伙伴和客户。
“架构”（Architecture）提供基础框架， 它定义和描述了企业实现经营目的和商业愿景的平台。 “架构”可以被具体定义为： 与企业经营战略、信息需求紧密相连的一整套原则、方针、政策、模型、标准以及流程，它结合企业未来发展方向，为企业各项解决方案的设计、选择和执行提供指导。