随笔分类 -  项目管理

摘要:摘要:怎么又变了?当初就应该让客户书面签字确认!你可能会经常发这样的牢骚,可是就算客户书面确认,客户还是会“赖账”的!软件项目的其中一项不变真理:人是会死的,需求是会变的!本章将会和你一起来体验软件需求分析工作的风风雨雨,找出需求分析工作的根本之道,了解UML如何帮助我们提升需求分析的水平。作者:张传波www.umlonline.orgwww.umlonline.org/school/本文来自新书《活用UML——需求分析高手》的第二章。第一章已经在博客园发布,文章名字叫:UML一篇文章就学通文章链接:http://www.cnblogs.com/umlonline/archive/2011/0 阅读全文
posted @ 2011-07-19 19:50 左正 阅读(318) 评论(0) 推荐(0) 编辑
摘要:参加了一个如何画好架构图的培训,总结下来有一下几点:  1.设计也死  2.做正确的架构,正确清晰的表达架构,将架构正确应用到系统  3.Rup 4+1 视图:逻辑视图、进程视图、实现视图、用例视图  4.逻辑视图里包含功能视图主要用于和领导交互  5.活动图展现具体业务逻辑,适合多角色协作的具体业务也叫泳道图  6.序列图和协作图用于沟通需求和类设计  7.数据库设计要做到第三范式  8.软件架构的驱动因素:软件功能、非功能需求、其它约束  9.画软件架构步骤: a 功能视图、用例图  b 组件图、部署图  c 软件架构概要因素:操作系统、数据库、浏览器、构件、语言 阅读全文
posted @ 2011-01-05 16:38 左正 编辑
摘要:系统架构图属于系统设计阶段,系统架构图只是这个阶段一个产物,要正确的、合理的画系统架构图需要全面的理解用户需求以及业务流程,当理解了这些东西后,剩下的就是如何进行表达了,一般而言,可以参照RUP的用例驱动来进行逻辑架构,开发架构等设计工作,你的系统架构图可以反应在各个视图里面,我估计你所说的系统架构图是属于逻辑架构里面,比如分多少层,每层分多少模块等。  至于,绘制的工具,有很多很多。可以选择微软的visio,或者EA,rose,power designer等UML建模工具,当然,你甚至可以用PPT,Word来绘制。  当然,系统架构不是一日之功,需长期努力,跟经验和技术都有很大关系。 阅读全文
posted @ 2011-01-05 16:32 左正 编辑
摘要:如何提高项目的生产率,保证项目按期交付是每个软件开发项目经理都需要面对的难题。关于这方面的研究,在《人月神话》、《人件》等书籍都有很详细的论述。研究表明,不同程序员之间的生产率最高差别在40倍以上。虽然笔者没有亲睹这种样例,但是笔者的开发和管理生涯中所发现的相同技术水平程序员之间的生产率最大差距可达4倍。这个数据就发生在笔者的一个项目中,这让笔者感到非常的震惊。如果说40倍的生产率差距可能会有技术能力、工作经验、熟悉程度诸多因素的影响。那么,笔者所发现的4倍生产率差距却更让笔者感到不可思议。  案例  程序员J:四年开发经验  程序员L:三年开发经验  程序员Y:五年开发经验  技术能力:Y 阅读全文
posted @ 2011-01-04 23:58 左正 编辑
摘要:到很多帖子上讲怎么样才能做好项目,这次就讲讲我的经验吧。  项目经理的能力,我觉得有两个,一个是基本的技能(技术、业务、项目管理),一个是形势分析和判断能力。前者还可以通过自学做到,后者自学的可能性微乎其微。  项目经理个人的基本技能只是有个相对的保证,但是如果不具备形势分析和判断的能力,大一点的项目,基本上可以断定项目失败,这是我的经验之谈,理论上我觉得是风险管理的能力不具备,项目经理没有能力去控制风险。  形势分析和判断的能力,一个是要有一定的资智,至少性格上要冷静,不能偏激。另一个是要跟着有经验的人去学习,去在具体的项目中看看别人怎么做。最后就是要实践,一刀一枪的打出来的。  判断和决策 阅读全文
posted @ 2011-01-04 23:43 左正 编辑
摘要:最近手头接了公司一个方案编写的任务,但一直没有好的思路,虽说以前也写过产品的一些方案,有一定的沉淀,但仔细想来,基于产品的解决方案和基于定制开发的方案应该有很大的不同。所以就通过网络和以前的朋友,找了一些方案,分析对比后,把个人的一些感受写下来,以供大家探讨。不妥之处,还望不吝指出,以便改进。  通过这次方案的编写,我个人有以下体会:  1、用户的需求把握很重要,要找到用户的关注点。  方案编写前,实际上有个用户需求调研的过程,要按咨询的一般流程,对用户目前的业务流程进行描述、分析,象医生之于病人一样,通过望、闻、问、切,找出问题所在,然后对症下药。但由于分工不同,往往我们拿到手的资料很有限, 阅读全文
posted @ 2011-01-04 23:21 左正 编辑
摘要:为了保证公司利益,特把客户名称以“客户公司”代替,软件公司以“供应商”代替。请各位谅解!  引 言 6  第一部分 客户公司集团需求分析 8  一、 项目背景介绍 8  二、 股份公司协同管理平台如何演进 8  三、 供应商对OA系统演化进程的理解 9  四、 客户公司信息化技术的应用现状分析与建议: 10  五、 针对客户公司的应用分析 13  六、 需求分析小结 14  第二部分 客户公司管理组织设计与协同管理平台技术路线 16  一、 客户公司协同管理平台的总体建设原则 16  二、 客户公司的协同管理平台的管理组织设计 17  1、 客户公司的组织结构分析 17  2、 客户公司需要运 阅读全文
posted @ 2011-01-03 23:44 左正 编辑
摘要:在公司作为一名售前工程师会有大量的方案策划落到头上,这些方案里小的有几十万,大的有上千万。如何写好方案一直是我们很关注的事情。  而我们基本上都是在方案提交前一两天接到写方案的任务,也不能不做,只好心里大骂一句,骂完后就打电话搞清楚别人的要求,边问就边构思整个方案的推导思路和结构提纲。  所以我其实也特别紧张,注意力也特别集中,大脑也高速反应,基本上几分钟电话或面谈完思路基本就有了,然后该干嘛干嘛,找一些零散的小时间把思路不断推导一下,然后到了一个比较安静和完整的时间前才开始写,这个时候基本上要写的话都想清楚了,只需要不断敲字,敲字的时候也是注意力也特别集中,大脑也高速反应,越写思路越开,很快 阅读全文
posted @ 2011-01-03 23:24 左正 编辑
摘要:提纲思路:  一、系统现状和背景  主要对系统和相关系统进行大体介绍,特点描述,系统限制  二、系统建设目标  主要按照层面进行系统划分描述(比如:基础数据,查询统计,分析对比,辅助决策)  三、系统建设原则  如:先进性原则、成熟性原则、可靠性原则、稳定性原则、安全性原则、灵活性与可扩展性原则  四、功能描述  根据用户需求和现状,按照层面展开进行功能描述  五、系统实施条件  介绍系统实施的前提条件,如果不满足条件时是否有其他解决方式  六、功能验证  以功能验证用户需求和现状 阅读全文
posted @ 2011-01-03 23:21 左正 编辑
摘要:作为客户希望提供解决方案的初衷是:(1)想知道自己系统将来是什么样子的?(2)可以对比几家公司,看哪一家性价比高。  从以上推测中,至少要注意以下几个问题:a.突出特色和以往典型案例。公司的优势在什么地方?其他公司这方面的劣势是什么?为什么选择我们?b.针对客户所关心的功能将其细化,最好能提供相应的功能图形。这样方便对比自己心里想要的是什么功能。由抽象的概念转变为现实的操作。c.注意系统的实施步骤(分布实施、迭代、后续维护软件保障、产品生命周期)。 阅读全文
posted @ 2011-01-03 23:18 左正 编辑