做软件中的管理的思考大纲草稿

如何做软件项目

这里以企业应用管理型软件项目为基础考虑展开。

做软件项目的一般流程及包含步骤

一般包括需求调研，可行性分析，需求分析，设计，编码，测试，发布，培训，维护，改进升级等。

最开始从项目意向提出算起。

       项目负责人初步排定项目整体计划。

也有可能在其它步骤之后，比如需求调研之后再排定或修正项目整体计划。其它一些意外情况也有可能导致项目计划的调整。

       初步组建团队。

需求调研。

与有关用户开会沟通，了解用户需求，以及让用户培训讲解业务知识，形成一定的前期准备文档。

需求分析。

计划的排定，期限的给出，跟踪追查进度。

不一定很准确，但是可以在做计划过程中初步明确待做事项，能够初步控管进度。

需要采集需求分析相关任务实际执行的数据，比如实际执行时间，以及细化任务事项，比如做什么地方时花费了多少时间，细节一些当然好，不过需要权衡。这些东西都是经验数据，可以事后加以分析，然后可供以后类似事情的计划制定作参考。

如果发现遗漏的任务事项需要及时补充并调整计划。

业务流程梳理，可行性分析。

业务支持考虑，初步设计考虑，技术调研，对大体方案、架构、主要技术的选用确定。

业务步骤细化，业务所需数据分析整理（其实是初步进行了业务数据库设计），数据流图的整理，使业务数据的流向及如何使用比较清楚。

产出需求规格说明书，包括前面提到部分，以及对业务要点的支持规格或形式说明，一些指标的制定。

注意不光有业务需求，还有系统管理需求等。

必要时提供原型（这需要一定的开发技能），或者操作步骤大致说明文档。

在写需求书时要注意考虑，如何让用户很好的理解需求规格说明书。是采用规定式的语言，还是给出比较详细的操作界面或操作步骤，或是提供原型演示？另外，注意评审需求规格书的人分几类，有直接用户，用户的上级领导，自己的上级领导等，不同的人关注点不太一样。

需求分析中也需考虑到一些设计层面的东西，比如要规定说说明操作方式操作界面上的具体要求，则应该与当前（掌握到的）技术所能支持的程度基本一致，不然会给设计实现造成很大困扰，导致需求与设计实现严重脱节。要么就是不要对具体操作要求作出规定，只是规定要能做到什么，具体怎么做留给详细设计。如果要提供原型，倒是一定程度上能解决这个问题。

还有，需求分析中有无必要比较深入的到设计及实现层面去考虑问题，比如一些功能点能否支持实现？需求规格书一旦以合同的形式通过，到后面如果一些需求发现支持不了，如何能避免违约损失而纠正需求？（当然，合同条款如何制定也是很有技术含量的事情，但这里限于经验没法展开讨论。）这似乎要求一开始在作需求的时候就要想好大体设计实现，以免承诺无法实现的需求。如果是客户需求提得不够正确，也许还能说服客户。

让用户确认需求。

       可以考虑先把需求规格说明书通过邮件发给用户看。然后约定时间开会讨论评审。

       如果用户能够在会前及时给出反馈，可以再修改补充。这样开会的效率更高。

       开会评审需求规格说明书，或者通过原型等在会上向用户演示。

       一般一次开会难以形成最终需求书版本。这时还有一些修改，以及单独找相关用户讨论。

       修改后的需求规格说明书再通过邮件等发送给用户，如果用户能够确认下来即定稿。或者再开会讨论评审。反复进行，一般一两次即到最终定稿。

       其它可并行的事情。比如让组员了解需求或参与一定的需求分析。以及调研一些技术难点，或者做一些专业技术上的培训或学习。或者一些设计的并行启动。

设计。

计划的排定，期限的给出，跟踪追查进度。

不一定很准确，但是可以在做计划过程中初步明确待做事项，能够初步控管进度。

需要采集设计相关任务实际执行的数据，比如实际执行时间，以及细化任务事项，比如做什么地方时花费了多少时间。事后加以分析，得到经验供以后参考。

研究需求规格说明书，了解业务以及准备支持业务到什么程度。（如果做需求与做设计不是同一个人，就有必要）

对于业务支持的大体方案，业务架构，软件架构，软件实现所需主要技术的选用确定。

重点难点的设计思路，一些算法的给出。

对象关系图或类图设计的重要性如何？

数据库设计，分业务和系统管理等方面。（参见下面的通用功能或目标）（重点是业务数据方面，系统管理方面可以抽其它时间并行处理）

同时审视需求文档，看看有无考虑漏掉或错误的需要反馈。

详细设计。

一些业务功能在具体操作及界面上如何支持，以及给出实现思路的伪码逻辑描述。rational rose中的序列图的表现能力还是差了些。

       给出这些业务功能的伪码逻辑意味着一件事情，编码者或开发者的水平有限，不能根据较高层次的成果很好的开展工作。

伪码逻辑描述要细到什么程度，以及要不要所有的功能都给出实现思路伪码，这需要根据编码者的水平而定，另外也需要权衡。

基础数据设计准备。

老的业务数据的转换考虑。

设计成果评审。

其它可并行的事情。比如让组员熟悉需求文档，了解业务，准备技术。有技术能力强的人还可以做做代码架构搭建。以及进行一些通用功能的开发。或者一定程度参与设计工作，比如可以做自己所可能负责模块的伪码逻辑。

编码相关的设计

       计划制定？一般实现数据的采集还是有必要的。

       要注意考虑可重用性的问题，包括源代码层次的以及dll层次的。

       代码框架的搭建。

划分纵向层次关系，（以利于减少冗余，提高复用性），比如从粗的来说就有基础通用公共层，数据访问层，业务逻辑层，界面层等。对功能业务还要划分模块，（以利于团队并行开发）。

数据访问的技术的选用确定及架构或使用方式设计，公共类及方法的提取，写点实用例子给定使用方式的模式。

搭建界面框架以利于后面的团队并行开发。

如果是CS程序，一些公共参数的获取方式或传递方式的考虑，各个界面部分如何联系考虑。BS程序在界面上的各个部分联系得稍微少一点，简单一点。

一些像自动菜单生成的功能可能需要预先开发。

其它一些需要考虑之处，参见下面的通用功能或目标。

如果能够有一个比较成熟的代码架构，直接套用，是最好的一种方式。

       一些成熟的（在其它项目中经过实际使用检验过的）公共函数及数据结构等基础类库搬过来，从源代码级到二进制级的利用。

给出代码规范。

       对代码架构给出说明文档，说明各个模块负责的功能范围，说明一些技术怎么利用实现，必要时给出例子。说明公共类及函数及常量的放置规则。

组员在此时的并行任务考虑，可以做些什么事情？可以阅读设计文档，以及阅读代码架构说明文档及源代码，学习必要的开发技术或测试技术，培训等价类的划分思路，以及针对可能分给他（她）的功能进行从界面安排组织到实现思路的考虑。（这时也需要初步排定开发任务）。

编码开发。

计划的排定，期限的给出。

              列出开发相关功能清单，估计工作量，安排任务到人，注意考虑难度和任务本身的逻辑先后的问题，规定好任务实现的先后顺序。任务安排细节清单回顾调整，注意关联顺序，以便流畅开发，也为测试考虑。

另外，进度如何保证，是每个任务都去追查呢，还是一批任务给一个期限，后一种似乎更可取。

还有，任务的工作量包括哪些方面的内容的问题，是只包括开发时间和自己测试时间，还是说改bug的时间也考虑在内？另外，注意改bug的时间必然是有分段，不连续的，这样完成任务以什么为标识，是否应该考虑得很细，比如初次开发完成所用时间，最后测试通过所用时间，里程碑如何划分？……

团队开发。

       注意团队开发前的准备工作，参见前面的设计中的一些工作。以及可能要给出一点典型功能的比较完整实现的例子，如果担心编码者水平的话，本来一般来说给出代码片段例子再辅以说明文档是够用的。

跟踪追查进度，检查数据的采集。组员的每日进度汇报，详细到任务段，需采集的数据的填写。这需要任务管理工具作支持。

每日编译，源代码版本及时管理。

及时进行代码检查，同时对功能大概进行检查。一般每人开发的第一二个功能检查，后面的功能抽查，重难点功能检查。

个人自己测试的测试用例思路检查或抽查。

提交功能集合给测试方，等返回bug分配修改，并行进行开发。

       修改bug的一些数据的采集的填写及检查或抽查。

临时情况导致的任务调整或追加。

测试。

       （限于经验没有详细展开。）

       计划的排定。（需要一定程度依赖于开发计划）

       测试用例编写。

       测试基础数据的准备。

       自动测试工具如何使用？

       开发组分批提交功能测试而具体进行测试。

       开发组改bug及提交其它新功能进行测试。

       测试任务的执行记录的数据采集，以及进度跟踪控制。

       测试计划的调整。

       集成测试。

       性能测试。

       其他测试，比如兼容性，安装，升级脚本测试。

用户培训。

       使用说明书的编写。

       培训计划的安排。

              安排专人准备演示系统。

发布。

       （计划在前面排定或调整。）

       准备安装程序，或写发布时的详细操作手册。

       写使用说明书。作培训计划及安排。

       发布最初系统或发布升级系统。

       用户培训。

       用户试用或正式使用。

维护，补丁版及升级版的项目启动。

       用户反馈bug，或提出修改意见，或新的需求。

       再排计划。

       改bug。

       针对新需求，从需求分析、设计、开发、测试，一步步下来。最后发布升级版本。

其它

       版本库的管理，文件的搁放位置规定。

              代码及文档的版本控管

       经验知识的整理及管理

       计划安排，进度控管

业务软件的一些通用功能或目标

组织架构等基础数据的设计，组织架构变迁的考虑及支持程度。

功能权限设计、数据权限设计、权限使用。

根据权限自动生成菜单。

一些系统性业务数据的列表或树形的通用维护。

身份验证，加密技术，安全性考虑。

版权控制，用户数控制。代码的安全控制（如反反编译）。软件版权方面的法律。

自动更新。

以及注意新版代码与新版数据结构的配套设计或安排。

还要注意数据内容中包含数据结构的，如何在前期设计能够向下兼容，从而在新版代码中能够向上兼容。要特别注意序列化类对象导致固化版本的后果。比如一个旧的类对象被序列化为数据存储起来，而又反序列化为新版的类对象的后果会是如何。

安装部署。

打印支持，报表工具。

       导出数据，如果界面上列表控件不支持“复制——粘贴”的话。

简单消息，邮件通知。

       简单消息指纯粹通知，可能加上很有限的跳转。

各种分辨率的设计支持。

异常、提示、日志

对于错误及异常的提示消息的友好及有效性。

达到自包含帮助的层次。能够指导用户正确完成操作，或让用户知道该找别的用户完成先决条件的操作，尽量减少用户对技术支持人员的依赖。

异常处理机制的设计，对一般错误的通用简单处理。错误消息提示可能要制定一点标准规范。

支持运行时查错。

尽量使运行时出错易分析追踪。因为一般来说，这样的bug一般难于重现或发现，而且也不太可能在正式的服务器上进行调试。这时只能依赖详细的运行时日志记录了。

这里的日志记录是程序级的（而不是用户操作级的，下面会提到）。

程序级日志记录的标准规范，当出错时哪些信息要写入日志，除了Exception中的消息及堆栈，引发Exception的调用处的重要变量的值的情况如何记录。（特定地方的日志记录细致程度。）

其它错误相关：

       容错问题，

不要为一点错误数据影响其它，比如一个错误导致系统的正常业务流程都走不下去了，或者允许修改，改正错误后正常进行。

其他提示相关：

       用户提示的友好性，

              比如遇到耗时操作，能够提示用户耐心等待，而不至于让用户感觉系统崩溃。

其他日志相关：

       用户操作级的日志的记录详细程度的设计或规定。什么用户，什么时间，什么模块、功能、操作，操作了哪些数据行，对于各数据行中的哪些数据列进行了操作。      

支持调试性

       至少在Visual Studio .Net 2005中的C#开发中，如果没有异常处理，则出错时IDE会自动定位到出错语句，而如果给包含出错语句的某段代码在任何外面层级加了try—catch语句，则出错时IDE会自动定位到catch语句处，反而不方便调试，这个需要研究如何既有异常处理，又能充分利用IDE的调试功能。

支持测试性。

       方便开发人员自己测试，方便测试人员手动测试及自动测试。

比如一些树状数据是折叠的，要检查数据内容的正确性需要全部展开，而业务要求又是折叠的，即开发者测试者的需求跟用户的需求稍有差别时，从而可以考虑用参数配置等解决这个问题。

       这有待有更多经验后再讨论。

系统数据的一致性的保持的设计考虑。在各种可能出错的场合。

性能支持问题，分页技术，数据库访问技术及方式的综合考虑。

集成性考虑。集成其它系统或被其它系统集成，或为其它系统提供接口。

多数据库支持。

国际化考虑，多语言支持，多货币支持，时区支持。

脱机处理及数据导入，分布式设计考虑及数据整合。

热更新程序版本。

多操作系统支持，可移植性。

用户的自定义习惯的保存。如查询条件，每页大小，界面布局，等等。

可配置性，（哪些东西需要配置需要具体问题具体分析）。

代码相关

       架构设计相关

              可扩展性。功能需求增加的方便性，不至于改个地方伤筋动骨。

              可重用性，从源代码层次到可执行代码层次。

       重用也导致精简。

       代码的精简性（尽量减少冗余，把重复代码都合理划分，提出具有或多或少公共性的函数）。

       代码的短小性（不要一个函数包含太长的代码，一些代码块可以根据功能意义提成一个函数，也可备以后重用）（或者就在详细设计时进行划分？）

       代码的可读性，自包含文档度（从函数，参数，变量等的取名，到一定的注释）。

       可维护性，   

易使用性。

       比如输入时进行校验，或者提供选择数据方式使用户能输入正确的数据。业务规则的友好提示，达到通过提示信息就能引导用户能够正确输入数据。

       粘贴复制的支持。

       方便用户输入有相关性的数据。以及批量输入及修改数据。

支持工具

版本管理工具

进度安排及跟踪工具

bug管理工具

写文档工具

做需求的支持工具

做设计的支持工具

              实体——对象建模工具

开发工具

       集成开发环境

测试工具

       自动测试工具

       性能测试工具

对人的技能及素质的要求

分情况考虑，按角色分：需求分析师，设计师，代码架构师，开发组长，开发组员，测试组长，测试组员。待以后补充。

一些定性定量指标

不一定只指软件系统，一般指软硬件结合的系统。待丰富完善。

内在质量方面

       正确性。

              设计逻辑的正确性，程序实现上的正确性。

              可靠性。……

              业务周密性。

                     一些细致的功能会不会在设计时被漏掉，到具体用的时候才发现没有，导致没法用或用起来很麻烦。

                     界面操作上的改错能力。比如输入错误的数据，能够通过系统提供的操作进行改正，而不是改正不了。

              数据完整性的可靠性。比如断电或并发性操作导致数据完整性被或多或少破坏。

       性能方面

              一定硬件配置条件下的并发用户数，操作的吞吐量，响应时间。

              数据量上限支持，预计可使用寿命。

              性能扩展支持。最大并发用户数，操作的吞吐量。

              稳定性。比如可以一直运行不必重启。

       安全性。

              操作方面的权限设计周密，没有漏洞。

              程序实现的内在安全，能够防止黑客侵入系统或直接侵入数据或窃取密码。

              程序布署管理上的安全。比如一些带有密码的配置信息是加密的，不会被机器管理员所轻易取到。

              操作上的可追查性，如果出了事故能够根据操作记录追查到责任人。

功能方面：

       可配置性。

              能够通过参数，配置界面，脚本等丰富系统功能，或者具有强大的二次开发支持。可以适应业务在相当大范围内的发展变更。比如自定义各种报表，自定义业务流程，等等。           业务发展的支持寿命。

              通过配置能够支持一个最大业务范围，在当前业务发展到这个范围之外预计需要时间的量。

       脱机处理支持

       分布式支持。

       并发性控制问题。比如两个人同时操作一份数据会出现什么情况。可不可能两个人同时操作一份数据。

       各种显示设备的支持能力。比如不同分辨率。

用户使用方面

       用户友好度。界面及提示自包含帮助，让用户能够不经专门培训即能使用系统。

       界面操作的方便程度，比如支持键盘鼠标及其他输入设备，支持拷贝粘贴，批量操作，……。

       界面美观程度。

       相关数据的输入的操作的简便。

维护升级方面

       可扩展性，易扩展性。

              在哪些方面扩展，世界范围内使用，多语言，多货币，多数据库。增加功能，增加要求，……。

       可维护性，易维护性。

              文档的完备及详细，接口丰富，支持二次开发。或者模块代码组织划分得好，可读性强，支持源代码级修改升级。

       可集成性，

              能够集成其他系统数据或支持被其他系统集成，也是一种扩展了。

       可复用性，通用性，模块性

       可移植性，

其它

       耗费时间量，耗费工作量，耗费成本，

       程序规模，按代码行或功能点来算。单位规模程序耗费量

       程序价值，单位耗费产出价值

如何控管以及统计数据

如何计划安排任务及控管

Project软件中的计划时间与实际完成时间不分的原理？

可能需要两份project档，一份制定计划，一份记录完成，然后拿计划安排与完成情况来对比。

另外project档中能够记录的东西不太方面，需要专门有系统或excel档来记录任务完成的详细信息。

如何尽可能高效的监管控管

重点难点的特别关注，找准重点难点。设计实现思路的掌控。

进度跟踪，发现耗时不正常的地方及时了解情况，了解原因，给出对策。

专人对某些方面进行专门检查。比如设立专门的质量小组。

分级检查。比如组长检查老兵，老兵检查新人。抽查。

及时的代码回顾。

每日编译。

每次检查的文档记录。经验总结。

如何评价项目成果及做事的人的绩效

如何评价项目

       参见前面的指标部分。

项目代价的统计

       需要统计出所有参与者在这个项目中总共投入的工作量以及等待的时间量。从而得到项目的两个代价，一个是实际耗费总代价，一个是实际耗费有效代价。

如何评价人：

       可以根据其完成任务的情况来衡量。包括量及质量等。

       每个参与者，做了多少任务，完成了多少标准工作量，实际付出了多少工作量，公司实际付出了多少成本，个人做事的质量如何，对于个人的其他指标的评价。

       任务有一个标准工作量，考虑用经验方法给出或者别的方法给出。如果统计得足够详细，可以得出一个开发者彻底完成一个任务的工作量，一般包括开发时间量和改bug时间量。还可以得出这个任务总共耗费工作量，即开发者实际耗费工作量加上测试者耗费工作量。测试者要得出测试这个任务的单次全面测试工作量以及由于出现bug的追加测试工作量。

       另外，对于任务的完成在开发方还有一个内行质量的评价，具体指标参数待定。可以想到的有代码的规范性，可读性，代码的自注释程度，代码的精简程度，代码的复用程度，代码的冗余程度，功能函数的提取程度，正确性，等等。

              另外，这些代码的指标总体上与个人的开发效率有联系。而质量及正确性则与改bug的工作量有联系。

              再有，可以考虑抓某种bug率来督促个人提高开发质量。比如标准工作量与改bug工作量的加权计算后的值之比。

       得到这些数据后，可以用开发者对其负责的那些任务的实际完成工作量总和与标准工作量总和的绝对值以及比例来对其绩效作出一定量化的衡量。

       另外，还可以把开发者导致的追加的测试工作量考虑进来以量化其绩效。还可以把开发者完成任务的质量得分考虑进来影响绩效计算。      

不过，标准工作量的公平给定是个很难的问题。毕竟，不同任务有不同难度，水平低于某难度要求的开发者耗费再多时间也难以完成任务。这需要另外一套评价估量体系。

还有一种考虑角度，是把工作量不用时间来量度，而用金钱来量度，如何评价一个任务的货币价值，也是很难的。

需要采集哪些数据

每个人处理单个任务的时间量，实际处理可能分几段。还要分类型。是初次开发还是由于改bug。一个任务改了几个bug，每个bug改了几次。

任务的标准量的给出。

任务完成质量的分数的给出。指标待定。

其他

对于面向对象的批驳：

       现实中，最容易想到的是数据集合，数据流图等东西，而如何划分数据集合，使思路清晰，减少冗余数据，应该因地制宜，使用最合适的方法，而一味套用面向对象的思路则是生搬硬套。

另外，如何抓住要点用最好的方式向别人（比如用户）解释说明清楚一些东西，所使用的方式也是因地制宜的，用rational rose中的那一套也是生搬硬套。