无锡上海码力兄弟告诉你软件开发的一些要点,软件开发,软件开发公司

分析  

软件需求分析就是对开发什么样的软件的一个系统的分析与设想。它是一个对用户的需求进行去粗取精、去伪存真、正确理解，然后把它用软件工程开发语言（形式功能规约，即需求规格说明书）表达出来的过程。本阶段的基本任务是和用户一起确定要解决的问题，建立软件的逻辑模型，编写需求规格说明书文档并较终得到用户的认可。需求分析的主要方法有结构化分析方法、数据流程图和数据字典等方法。本阶段的工作是根据需求说明书的要求，设计建立相应的软件系统的体系结构，并将整个系统分解成若干个子系统或模块，定义子系统或模块间的接口关系，对各子系统进行具体设计定义，编写软件概要设计和详细设计说明书，数据库或数据结构设计说明书，组装测试计划。在任何软件或系统开发的初始阶段必须先完全掌握用户需求，以期能将紧随的系统开发过程中哪些功能应该落实、采取何种规格以及设定哪些限制**加以定位。系统工程师较终将据此完成设计方案，软件开发公司，在此基础上对随后的程序开发、系统功能和性能的描述及限制作出定义。

软件开发流程

需求分析

1.相关系统分析员向用户初步了解需求，然后用word列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。

2.系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚列出系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。

3.系统分析员向用户再次确认需求。

概要设计

首先，开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。

详细设计

在概要设计的基础上，开发者需要进行软件系统的详细设计。在详细设计中，描述实 现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编码。

编码

在软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。在规范化的研发流程中，编码工作在整个项目流程里较多不会**过1/2，通常在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会较大提高，编码时不同模块之间的进度协调和协作是较需要小心的，也许一个小模块的问题就可能影响了整体进度，让很多程序员因此被迫停下工作等待，这种问题在很多研发过程中都出现过。编码时的相互沟通和应急的解决手段都是相当重要的，对于程序员而言，bug永远存在，你必须永远面对这个问题，软件开发公司，大名鼎鼎的微软，可曾有连续三个月不发补丁的时候吗？从来没有！

测试

测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。软件测试有很多种：按照测试执行方，可以分为内部测试和外部测试；按照测试范围，可以分为模块测试和整体联调；按照测试条件，可以分为正常操作情况测试和异常情况测试；按照测试的输入范围，可以分为全覆盖测试和抽样测试。以上都很好理解，不再解释。总之，测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会又不可预料的问题存在。完成测试后，完成验收并完成较后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营状况并持续修补升级，直到这个软件被彻底淘汰为止。

软件交付

在软件测试证明软件达到要求后，软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。

《用户安装手册》应详细介绍安装软件对运行环境的要求、安装软件的定义和内容、在客户端、服务器端及中间件的具体安装步骤、安装后的系统配置。

《用户使用指南》应包括软件各项功能的使用流程、操作步骤、相应业务介绍、特殊提示和注意事项等方面的内容，在需要时还应举例说明。

验收

用户验收。

维护

根据用户需求的变化或环境的变化，对应用程序进行全部货部分的修改。

时间的碎片化是软件开发过程的危害之一。码力兄弟分析了时间碎片化的原因和结果，并试图给出修正此管理缺陷的方式方法。

为什么讨论时间的碎片化 ？

产生有效成果的智力活动，总是需要连续的时间来保证。许多忘我思考的典故都证明了这一点。 码力兄弟认为软件开发是一种智力活动，因此也遵循这一道理。 打断某人的工作，不论是智力工作还是体力工作，对工作的效率和产出总会产生负面影响。 只不过与体力劳动不同， 智力劳动受到这方面的负面影响要大得多。 对一名建筑工人，如果他连续工作的60分钟被打断成3个不连续的20分钟， 其产出与连续工作60分钟相比，是基本一致的。而对一名软件开发人员，3个不连续的20分钟内的工作成果，恐怕只能相当连续的40分钟的成果。有20分钟的时间被丢失了。 为什么会这样？ 谁偷走了他的时间？下文试图给出解释。

时间如何破碎 ？

仔细观察我们每天的工作时间花费就不难发现，存在**的时间断点把我们本来连续的工作时间碎片化。午休、倒咖啡、去洗手间等等。除此之外，一些偶发的事件也能打断我们的思绪，比如一个电话，一个邮件提醒，或一个 MSN 消息。 我们不是古庙里的僧侣， 因此尘世中的干扰总是存在。 但这些不是本文讨论的内容。 我想讨论的， 是在软件开发管理中不合理的做法导致的时间碎片化。

我认为以下做法是不合理的。

1. 一人多任务
2. 过分强调面对面沟通
3. 过多的全体会议

一人多任务

有些管理者喜欢让开发人员同时在几个任务上展开工作，而不是顺序地完成它们。 这样做可能基于以下理解：

1. 任务越早展开，越能尽早暴露问题，从而便于及时解决，降低管理上的风险。
2. 开发任务紧，多任务安排可以增大开发人员的负荷，防止他们偷懒。
3. 多个任务具有相同的**级，而且彼此之间没有依赖关系，因而应该同时展开。

任务启动的早，并不能消除问题，只是把问题提前了。从这个角度讲，问题的总量并不会减少。既然这样，过早地暴露出问题有什么好处呢？ 在项目的可用资源（人力、时间）一定的情况下， 我看不到这样做的好处。 如果项目资源可以增加， 一人多任务的情况就不会出现，也就没必要讨论了。

通过多任务来提高开发人员的工作强度并防止他们偷懒的做法，我认为是幼稚的。管理者应努力和开发人员建立起信任关系，并通过其他方式激发他们的干劲。 当他们像负重的骆驼一样被对待时，作为会说话的智能生物，开发人员知道如何把**额的重物放在原地，而令管理者觉得他们在负重前行一样。

一人多任务的安排的问题在于，人不是多核系统。 他只能采用交替工作的方式来“同时”展开多项任务。当他在不同任务间切换时，特定任务上的工作时间就不再连续了。就像单核CPU执行多任务一样，这是让开发人员的大脑应用 TDM 技术。不幸，人脑不是 TDM 设备。

无论如何，一人多任务的安排都应该努力避免。 如果仅仅因为**级相同，那这些任务可以随机地顺序安排。

*[TDM]: Time-division multiplexing，即时分多路复用。

过分强调面对面沟通

面对面沟通是敏捷开发实践中强调的一个重点。许多管理者据此在整个组织内鼓励面对面的交流。我不认为这是一个好的做法。敏捷开发队伍是由 自组织 （self-organized）的小团队构成。敏捷开发中面对面沟通是指自组织团队内部的沟通。这种内部的沟通，被证明是有效的。 但是，把这种方式推广到自组织团队的边界之外，则是糟糕的做法。外部的沟通以受控的、相对正式的方式进行，是对自组织的团队的保护，使之免受干扰。自组织团队就像封装良好的软件组件。它应该是内聚的，外部只能通过定义良好的接口与之交互。

很多时候，面对面交流，仅仅是提高了交流发起者的效率而已。（甚至这一点也值得怀疑，因为经过仔细斟酌写下的文字，通常要比现场发挥的言语表达的更清楚）。当你礼貌地找某人谈话时，你已经礼貌地打碎了他的时间。你在损害他的效率。

说到这里，请读者不要误解。我不是在鼓励开发人员成为像患有自闭症一样的程序怪人。我只是想强调，过多的当面交流会导致时间的碎片化，从而影响整个团队的效率。 有其他沟通方式（比如邮件），能把对他人的干扰降低。

过多的全体会议

喜欢召开全体会议的团队**者，软件开发公司，在召开全体会议前请思考，会议内容是否是每个人都必须知道的？ 是否是必须口头传达给每个人的 ？ 如果是一场讨论会，是否这些人都需要参与到讨论中来？ 由于全体会议打断了每个参与者的时间，时间碎片化效果扩展到了全体，因而影响更大。

时间碎片化的后果

时间碎片化有两个主要后果，即有效工作时间的减少和发生缺陷的可能性增大。

有效工作时间的减少

软件开发工作是剧烈的脑力活动。象引擎一样，人的大脑在进入高速运转前，需要一个预热和启动过程。让我姑且称这里消耗的时间为“思维引导时间”（ Mind Bootstrap Time ， MBT ）。这一时间的长短，取决于你面对问题的复杂性（和昨晚的睡眠质量？）。 比如， 某人的谈话如果被打断后，他可能会问“我刚才讲到哪里了？”。要继续之前的谈话，他就需要重新思考交谈的内容并从被打断处开始。这里花费的时间，就是 MBT 。 对一段谈话来讲， MBT 可能只需几秒钟。对软件开发活动，则可能需要好几分钟。

现在已经不再是一个文本编辑器解决所有问题的软件开发时代了。比如对一个典型的 JEE 开发项目，我们应该很容易理解一个程序员早上写下首行代码前所做的以下操作：

1. 打开 Eclipse IDE 。在 Eclipse 欢迎界面下的滚动条努力向前的时候，
2. 启动开发用数据库服务（比如 HSQLDB ）。在数据库服务启动日志还在 DOS 窗口翻滚的时候， 他
3. 打开数据库 GUI 客户端。接着，
4. 启动 tomcat 。
5. 在 Eclipse中打开昨天工作中的Java源文件，开始编写今天的首行代码。

我把这一过程所花费的时间，称作“环境准备时间”，即Environment Preparation Time（EPT） 。 如果连续的开发时间被打断，开发人员可能需要重复这一过程。 EPT 会因开发环境的不同而长短不同，但这部分时间总是存在的。

让我把 MBT 和 EPT 称作断点时间。 断点时间不是有效的工作时间，因为它们不能带来直接的产出。 这里想强调的是， 有效工作时间是必需的消耗，而断点时间总是可以通过减少时间碎片来减少或避免的。如果时间连续性已经被打断， 断点时间还能被消除吗？ 我认为答案是否定的。

碎片化的时间， 就像被田埂分割的土地。分割的越多，实际可种植面积就越少，不论田埂修的多狭窄。

*[MBT]: 思维引导时间，即 Mind Bootstrap Time。 
*[EPT]: 环境准备时间，即Environment Preparation Time。 
*[JEE]: Java Enterprise Edition 。 Java开发企业应用软件的一套规范、工具、以及框架。 
*[IDE]: Integrated Development Environment，即集成开发环境。 
*[Eclipse]: 一款流行的 Java 集成开发工具。 
*[tomcat]: 一款流行的java web（servlet）服务器。 
*[HSQLDB]: 一款Java开发的轻量的关系数据库系统。

发生缺陷的可能性增大

打碎的玻璃杯子被重新粘合后可恢复完整并继续使用。但粘合的痕迹让它不再美观。更重要的是，重新粘合可能引入缺陷：接缝处未对齐的话会产生缝隙；粘合材料和杯子本身材质的不同会使整个杯子的应力不均，从而使它比以前更容易炸裂。

通过重新进入状态并找到上次离开时的工作点，开发人员可以接续之前被打断的工作。但就象重新粘合的杯子一样，这里不仅有直接的有效工作时间损失，更有可能引入后续问题。 “我刚才写到哪一行了？”，重新回到代码前的程序员可能会这样问自己。通过回想，他找到了离开时正在完成的switch结构并继续编写下一个case子句。不幸的是，**个case子句遗漏了本该有的break。一个bug就这样产生了。修复此bug的时间可能是撰写这部分代码的数倍[1]。

这个引入bug的例子很容易应用到其他开发工作上，比如需求分析、系统设计、测试等。简单讲，时间的碎片化使得开发过程中发生缺陷的可能性增大。人脑虽然比电脑复杂的多，但在断点管理方面，可比后者差很多。

结束语

码力兄弟认为时间碎片化是开发工作直接的危害之一。虽然很多时间断点无法避免，但管理方式的改进能减轻这方面的危害。减少对开发人员的干扰，提高他们工作时间的连续性，是管理的必要手段之一。理解了这一点，把团队拉到偏远的酒店或关到一个单独的房间进行所谓的“封闭式”开发，就显得不是那么必要了。