流行软件工程理论的投票

zlwenny

其实，我最近也是刚参加过cmm应用培训。

没什么很深的印象，感觉里面的东西都是一些教条主义的东西。

枯燥、乏味，经常听着听着，就想瞌睡！

但是，cmm这种思考问题的方法和态度，值得我们每一个人学习。

比如，寻找一个项目进度延期的问题，每个人可能从各个角度去思考。但是cmm却是从头到尾的思索，提供一个方法，思考者根据这些设立的标签，确定影响项目进度的各个可能因素，然后确定重要因素。

zlwenny

这么久没有人来！有点怪怪的！

不过没有关系，希望大家快乐！

zlwenny

cmmi是很多人想要的东西！

收藏一下！

英文软件cmmiv1.02版.part1.rar

zlwenny

英文软件cmmiv1.02版.part2.rar

zlwenny

没人来看！我自己顶顶！

厨师

不错，不错，我漏了没看。

先下一个，以后给感想 ，呵呵

zlwenny

最初由 厨师 发布
[B]不错，不错，我漏了没看。

先下一个，以后给感想 ，呵呵 [/B]

走在管理的路上，不要忘了路旁思想的小花朵。;19 ;19

我可以把我这段时间的心得与大家分享！

希望大家能够以点带面的享受！

如下

（附：需要文档的话，可以pm我。）

zlwenny

项目进度计划延期的分析

以下仅为一家之言，言辞、分析不周之处，敬请原谅！！

在我个人看来，在众多公司的项目中，项目的进度估计虽然具有一定的依据，也参照了一定的依据，包括经验，也遵循了一定的流程，但是还是存在许多不足之处。
除了用户方的原因（在此不做讨论），在我看来主要问题出于以下几点：

1        软件开发计划制定中的几个问题

1.1        详细设计不彻底
详细设计的不彻底，导致开发计划制定后执行的空洞，从而无法真正实现计划的实现和监控，大多的情况是在不断的弥补，或者进度的追赶，从导致代码的质量无法保证，甚至亦无法保证功能的实现。
1.1.1        详细的设计的不足
很多开发人员在接到开发任务后，担心不能及时完成任务，在匆忙做完了概要设计（其实此时的概要设计可能根本不能满足需要），以没有时间为借口，直接进入到编码阶段，没有对软件系统进行更为详细的设计，从而导致了对开发中出现的问题没有做出相应的应对措施。而且在出现问题后，对问题认识的不足（包括担心问题的出现会使自己的技能被别人否定等），和解决方法的缺乏，从而导致了问题的堆积和时间的流失，到最后使得项目的进度不得不发生了延迟。

众多公司的项目和产品中普遍存在这个问题。

1.1.2        详细设计应该达到的地步
详细设计应该能够达到一个这样的地步，比如，在一个模块所需要实现的功能基础上，对此模块再次进行的详细设计，以至不可再分，甚至可以细化到可以实现的某一个具体的函数、类、属性等之上。而且不遗漏细节！


比如页面设计
可以以页面为单位进行详细设计，从而细化到每个页面大概需要实现的基本要素，包括多少个按钮、列表框、输入框等，以及每个页面中的功能点，包括需要连接的数据库等。这样每个页面的具体时间就能准确的确定，并被执行。
且需要做出一个网页的设计图样，共项目评审使用。

比如图形制作
可以以每幅图为单位进行详细设计，从而可以细化到每个可能需要实现的基本要素，包括道路等各项图形要素，以及功能点等。这样每副图形制作的具体时间就能准确的确定，并被执行。
亦可以做评审使用。
1.1.3        重物的称量

试想，我们需要称量一个重物，如果没有磅秤，只有弹簧称，那么我们只能将此重物进行分割，方能知道此重物的重量，而且需要保证在分割的过程中没有损耗。否则就需要进行一个定量的、适度的估算，比如百分比等，以弥补分割过程的损耗。

在这个比喻中，我们把重物看成是个项目，分割重物的人是项目经理或系统分析人员，称量的人则是实施开发的人员，分割过程则是项目开发过程。
如果在分割重物的人，没有具备分割的能力，重物的重量将会远远偏离其实际目标。
如果称量重物的人，没有具备称量的能力，重物的重量也会偏离其实际目标，只不过相对于分割重物的人的不称职，离目标可能会近些。

1.1.4        西瓜籽的计算

有时候我们开发项目的过程也想一个计算西瓜籽的过程。

看下面的过程，根据西瓜向阳一面多籽的特性，确立西瓜的中心线，然后将西瓜籽分解成阳面、阴面的两部分，再根据中心线与阳面、阴面的距离，将西瓜进行多次分块，直到我们能够较容易得数出西瓜中的西瓜籽。这样我们可以对所有的西瓜块进行分类，这样就能够很快的得出西瓜籽的数量。如果我们对西瓜的结构很是了解，那么即使有些误差，但也会相差无几。

在这里，西瓜是我们需要建立的系统，西瓜籽是我们所需要实现的功能，西瓜籽的数目则是我们的时间，对西瓜的分块和分类则是我们的进度安排。

而我们只有采用科学的方法，才能快捷的获得一个较为准确的项目进度计划。

另外，还有一个含义，就是如果想要知道西瓜籽的数量，我们必须切开西瓜，才能知道。
而且分得越细越准确。
具体所需要分的块数也取决于西瓜的大小和切西瓜的人的经验。

1.2        开发技能的估计不足
开发技能的不足也经常阻止了计划的顺利执行。
1.2.1        非项目小组成员
在很多项目进行开发之前，项目组成员采纳项目评审小组意见的时候，非项目小组成员并非真正、彻底的了解该项目的实际内容，或者了解不彻底，因此他们的经验和意见使得项目组在决定项目将要使用到的开发工具和技术的时候容易估计不足，也可能导致项目的进度延期。
1.2.2        掌握的新技术和技能
在项目中，项目组成员如果不能满足对工具的熟练程度，那么项目的开发计划是需要及时跟进的。如果进度不能如期进行，或者开发人员在额定的时间内，掌握的新技术和技能不能满足要求，需要重新且及时的进行分析。
1.2.3        开发人员技能汇报
如果不及时跟进开发人员技能的掌握程度，而且直接开发人员也不及时进行汇报，将会导致项目进度延期的无法抗拒。

不仅仅技能不满足要求时沟通不够，也有其他方面的沟通不足，也会导致项目的进度也可能受到影响。

1.3        关键技术分析不透彻
在一个项目中，如果对关键技术分析不够透彻，用一种模糊的观点，抱着试试看的心态，也可能导致项目计划执行难度较大。

这个与“详细设计不彻底”有些相通之处，但不完全相同。

比如，yyyyy项目，它就存在一个对关键技术分析不透彻的问题，也存在“详细设计不彻底”的问题。因此，拟定的计划是模糊的，不可执行的。
开发人员凭着自己的经验和智慧，解决开发当中遇到的问题。

1.4        开发经验总结不足

对于同样的一个项目，同样的一个功能，在进行多次的复用后，其技术应该已经较为成熟，其功能的实现也应该较为容易，出错率也应该较低，我们进度应该比较有把握，但事实情况并非如此！

那我想，也许是我们对开发的经验总结不够！

我们是否可以做一个这样的统计：
在一个我们现有的项目开发过程中，我们进行了多长时间的编码工作，其中没有任何修改操作的时间为多长，因为用户需求的更改而导致的代码修改时间为多长，因为设计的修改而导致的代码修改时间为多长，因为功能实现的错误而进行的代码修改时间为多长。

如下表，进行一些数据的统计。
        所有时间的综合        在没有进行修改的情况下项目所花费的时间        引起代码修改的原因        用户需求更改的情况下项目所花费的时间        设计发生修改的情况下项目所花费的时间        功能实现的错误的情况下项目所花费的时间        测试发现错误的情况下项目所花费的时间
花费的时间                                                       

也可以做出图表。

从这样一些统计和总结中，也许我们可以看出，我们进度的延期最主要的因素是什么；除了客户因素之外，我们还可以做那些努力；我们不可忽略的因素是什么。
2        软件过程调整
根据以上的分析，我们可以对软件过程进行适当调整，尤其是针对开发中采用C/A/S结构的系统，从而来改变我们增强需求获取的目的性，而且需求获取也会变得较为明显和容易。

对公司已经经历过的软件过程进行分析从而决定在下一个项目中将要采用的软件过程。例如，对采用B/A/S结构的系统可以采用直接从界面和数据进行概要设计的方式，并以此来计算页面设计时间和数据库设计时间。而对于其中所需要实现的其他的功能，则在每个界面当中进行详细设计，此时对每一个功能实现所需要的时间进行估算，这样就能够计算出整个项目的一个较为可靠的时间，根据用户的需要和需求功能实现的关联就能对项目进度有一个适度的安排。

这样在概要设计中，主要对界面和数据库设计进行评估；而在详细设计中对功能的设计和实现进行评估。
3        市场人员交流的技巧
我并不知道市场人员在交流的时候使用了什么样的技巧，但是市场人员的营销技巧和交流技巧确实对我们在争取项目的主动权上有着至关重要的作用。

如果能够充分掌握开发人员的相关因素和公司现状，那么在前期获得客户沟通、需求获取、和项目的时间把握等上，后期的产品交付、验收等问题上，都可以获得一定的余地！

在这儿要需要说明！
不管你是公司的技术人员，还是市场人员，与用户交流的时候，你就是一个与用户在进行交流的市场人员，同理，不管是懂技术的客户，还是不懂技术的客户，他都是提供用户需求的客户！

市场人员交流是需要一定的技巧的，而掌握这些技巧就需要市场人员掌握相关技能。
对于技能和技巧的掌握，没有人天生就会，只有不停的进行锻炼，并经过相关的培训和实践。

思考以下几个问题：
为什么用户需求总是在发生变化？是我们不理解用户的需求吗？还是我们低估了用户？还是我们分析不到位？
如果用户的需求超出了我们的期望值，我们处理好了吗？我们是在敷衍，还是继续努力，让用户理解我们？

我们获得的与开发人员所需要的需求差别在哪里？我们了解我们的开发人员及其所拥有的技能？

不尽之处，多多！        请您点拨——

                                                                                                                                               
;13 ;13 ;13

zlwenny

软件过程改进建议

以下仅为一家之言，言辞、分析不周之处，敬请原谅！！

1        改进用户需求过程
1.1        改进用户需求的获取方式
1)        研究用户特点
2)        成立需求调查小组
1.2        改进获取用户需求的态度
1)        正式的外部文档方式
2)        正式的提交过程
1.3        改进用户需求内容准备工作
1)        专业的用户需求调查表单，力求取得用户的配合，由用户或需求调查人员填写表单
1.4        改进用户需求的内外部沟通
1)        用户需求的分析、总结，须及时反馈到用户方，以取得及时而有效、满意但不多余的需求
2        改进需求分析方式
1)        改进需求分析的前提条件——正确的获取用户的需求
2)        针对不同类型的系统采用不同的需求方式和模型，更有助于界定需求的范畴
3)        及时总结、改进需求分析方式和模型，形成需求分析模式库
4)        复用和改进需求分析模式库
5)        加载有效的、适用的、先进的需求分析理论于经验分析基础之上
6)        改进项目组内需求分析的沟通和流通
7)        在需求分析初始，尽早分析需求的可行性，并作备案
8)        对不适当需求，与用户沟通，以取得理解和信任
9)        对不合理需求，协调用户，以降低成本
10)        需求一旦获得认定，尽快进行系统分析和设计
11)        及时有效的控制需求的变化，防止对需求随意的更改和增删
3        改进系统分析和设计原则
1)        以最小的代价实现系统
2)        以开发人员最熟悉的方法、技术和工具实现系统
3)        尽量采用先进的方法和理论，以适应发展的需求
4)        在系统的相关处，与具体的实施人员进行及时有效的沟通，寻求实现的最佳途径
5)        以简单、易懂的方式进行分析和设计
6)        以简单、易懂的方式表现系统
7)        系统分析的方式要易于复用，并及时进行调整、改进，系统系统分析库
8)        对系统的分析、设计加以控制、遵守，防止系统结构的随意更改
4        改进系统的实施和验证
1)        确保在取得共同的理解后才进行系统的实施和验证
2)        系统的实施和验证遵循一定的流程，以约定的方式进行沟通
3)        系统的变化能够以多种不同方式进行沟通，以确保变化被告知、并被认可
4)        确保在系统的实施和验证过程中，所采用的方式和方法是易于理解的，且不易发生变化
5)        系统的实施和验证完成标识明显，易于被相关人员识别
5        改进用户验收被动局面
1)        理解和支持用户的行为
2)        取得用户的理解和支持
3)        对系统进行充分的验证
4)        提高系统安装的成功率和速度
5)        改进系统界面，使系统直观、有效
6)        保证进度，提高诚信度
6        改进系统维护过程
1)        对用户进行有效的培训
2)        快捷、有效、合理的处理用户的问题
3)        跟踪问题，形成问题库


不尽之处，多多！        请您点拨一下——

厨师

多谢zlwenny，支持+感谢，呵呵。

英文软件cmmiv1.02版.pdf没看懂，但cmwhitbook2.pdf不错，学习中，谢谢