规范.txt

常用子程序-61个-4.2M.zip

随着人才流动的加快和研发周期的缩短，我们个人需要快速高效的完成自己的设计，维护和升级，公司需要人走不影响项目进度、新员工很快就能接手。这就需要：一个系统设计完成以后，它不应该仅仅是一些源代码，还应该包括各种各样的开发文档。（这对以后自己对系统的维护和升级都有很好的参考作用。而且能最大情况的避免一种情况：你改了一个BUG，却发现又出现了很多个BUG。）一个系统开发完成，它究竟应该包含那些文档，这些文档一般是怎么完成的，应该包含哪些内容？这就是系统开发的规范化问题。系统开发的规范化不仅有利于自己，也有利于公司，更有利于新手。规范化的设计让工程师工作更高效，这已经是不用争论的事实。现在在大型软件工程开发方面，这已经做得相当好。但在单片机和嵌入式系统的开发方面，规范化的工作却有待我们共同探讨。一个不容否认的事实是：国内的大部分小系统开发工程师从来不写文档，一开始就是以功能完成为中心进行代码设计。

在香港的一些公司也是这样一种设计模式。在国内，一些公司的研发管理人员也有一种误导——快写代码，快让我看见功能，不要你做其他的，完成功能就好。这些都把我们的设计导入一种误区：大部分时间都在写代码，改代码。

在此提出系统开发的规范化问题，也是我个人的一点想法而已。仅供参考。不过，一切还得从实际出发，倒没有必要硬要把设计从写某些文档开始，太教条了不好。如果你感觉写某些文档是浪费时间，那就别写吧。

在这里，我给出一个小系统大致包括的文档，仅作参考。

PRODUCT SPECIFICATION 一般是市场部或者是客户提供的
PRODUCT SPECIFICATION ——》 PROJECT LEADER
PROJECT LEADER 给工程师分配方案
SOFTWARE  SPECIFICATION  ——》 HARDWARE ENGINEERS
HARDWARE  SPECIFICATION ——》 SOFTWARE ENGINEERS
MECHANICAL SPECIFICATION ——》 MECHANICAL ENGINEER

一、    硬件工程师的芯片选择，原理图的设计

硬件工程师根据HARDWARE SPECIFICATION 来选择芯片（也可能是PROJECT LEADER 早已为你定了），再根据芯片说明来设计各功能模块电路。出一份文档
HARDWARE IMPLEMENTATION 
并进行SCHEMATIC DESIGN 
再把这些资料提供给SOFTWARE ENGINEER。
PCB LAYER 当然不需要文档了。
但有跟随的HARDWARE UPDATE REPORT
包括调试修改和最后的软硬联调，所做的任何工作都要出相应的说明。
（呵，呵，你自己保存一表格天天填吧，改动地方，修改原因，就两项，不难写的）

软件工程师得到芯片和电路资料，开始根据SOFTWARE SPECIFICATION 进行设计

首先我们应该出一文档：

SOFTWARE IMPLEMENTATION 这里大致包括软件采用的芯片，软件的功能模块及使用系统端口功能情况，仿真系统，原始数据资料，自己用其他语言写的数据处理工具。

在此文档完成后，我们进入了详细设计阶段：

MODULE DESIGN 开始写各模块的实现，包括各模块所要实现的功能，用到的系统资源（包括变量的定义，常量的定义），与其他模块的联系（*对系统的维护和升级很重要的）和时间间隔图（有固定时间点用固定时间点，没有固定时间点，就用时间间隔 ，用来设计主循环的）。这里表现的其实是你的思路，如果你思路清晰，做起事情来自然是事半功倍了。

MAINLOOP DESIGN：
主要是根据时间间隔图和各模块的重要性及响应优先级进行主监控程序的设计，确保各功能能顺利完成。

MIAN CHART FLOW
画出程序流程图

SOURCE CODE DESIGN。
这一部分才是代码的实现，要是你前面写得很详细了，这里你的思路很清晰，按照MAINLOOP DESIGN直接做就是了。当然，我们需要按照我们自己的〈编程语言规范〉来设计源程序。这是软件工程师的基本，我就不提了。

最后是软硬联调，需要两个人配合的，基本不出什么文档，但如果你作了什么修改，请记录在案，最后要更新你前面的设计文档。

最后是出FIRST SAMPLE ，MECHANICAL ENGINEER 会根据要求修改自己的设计。并出IMPLEMENTATION 和 UPDATE ME REPORT。

整个系统开发流程的规范化还应该包括项目的会审，软硬协调，成本的控制，货源的规划，测试规划，等等，由于我这里不是介绍一个现代研发部的研发流程，只想对系统软件规范化说得详细一点（这些可能是我们目前规范化面临的最大的问题吧），其他我都省掉了。

    这里写的不详细，还没贴出实际的文档式样，仅为抛砖引玉而已，希望有经验的各位同行修改补充。如有不明之处或者需要一些资料的，请给我留言。


按照CMM规范开展工作后，到目前为止，公司的运营成本是增加了——因为要增加管理人员、撰写文档也需要人手——但从长远看，其会带来降低成本、提高质量、提高用户满意度等好处。对此，我们确信不疑。 

与国外相比，我们在软件工程管理方面的差距不仅表现为管理体制、管理方法、管理思想的陈旧，整个软件业的落后才是根源。 

个人英雄主义情结、喜欢单打独斗是我们的民族性之一，其在软件人才身上表现得尤为明显，已成为中国软件企业做大的一个瓶颈。造成这种状况的原因，除了国内软件业的发展水平不高、软件项目规模不大和软件企业管理者自身素质不高外，还有很重要的一点，即与软件工程管理有关的教育内容几乎没有。在国外，PSP和GSP均为软件专业学生的必修课，可在国内，这两门课在学校里至今还没有开起来。国外施行的是定岗培训，比如撰写文档就是一门专业课，专门有人修它，毕业后拿它来“安身立命”，国内则是大家过独木桥，统统都学写程序。应该说，目前国内同行对软件工程管理的重要性已有了一定的认识，但在相关人员的培训上下的力气仍远远不够。 

其实人才才是最关键的。现在软件业最缺的人才之一就是产品经理，他们是软件工程管理的主角。产品经理必须具备以下素质：具有长期的软件开发经验——般来讲，要在8年以上；了解用户的需求；对产品熟、对市场熟——他可以不了解一个产品的底层技术，但必须了解其功能，能把握其发展方向；具有协调能力。总之，产品经理并不一定非常聪明，并不需要在某一方面特别突出，但要八面玲珑。这样的人才太难找了。东方通的产品经理都是自己培养的。 

CMM规范并非只适用于大型软件企业，其也适用于中小型企业。CMM规范只是一个框架、纲要性质的东西。企业在落实它时要细化一次；企业将其落实到具体的某个项目时，要再细化一次；中小企业可以不像大型企业那样将CMM规范细化得那么细，够用就好，不要教条。 

实施CMM规范、通过CMM认证有如下一些好处：确定工作流程和方式，从而使产品的质量和开发的可延续性有了保证；可以提高企业在用户中的信誉度，增加企业与强势公司竞争的筹码；可以承接国际大公司的外包项目———美国公司愿意找印度公司来承接其外包项目，就是因为印度公司对CMM规范普遍比较重视，通过CMM认证的软件企业也多；公司不再受制于人，人走了，事照做，这是一个公司成熟的表现。 


软件商业化的必要手段

谈文明（北京瑞星科技股份有限公司研发部经理） 

中国软件产业发展时间不长，虽然已有部分技术达到国际水平，但由于商业环境还不够完善，在软件技术的商业化与软件工程管理等方面，与国际同行相比，还存在差距。 

只有率先将技术先进的产品推向市场的公司才会赢得利润。在瑞星，技术商品化已被当作一种制度，它有助于提高整个企业的素质。 

瑞星意识到在充满竞争的环境中要获得成功，天才人物是必不可少的，但他们并不是全部。目前，一个软件工程的成功更多地要依靠科学家、工程师、制造人员和销售人员的协同努力。 

在软件商业化的过程之中，建立规范化的易于操作的软件开发行为规范是首先要做的工作。针对杀毒软件的特点，瑞星专门设计了瀑布模型结合增量模型的开发方式，即将项目分阶段来实现。首先实现市场最需求的核心功能，然后在此基础上继续开发，每个单独的阶段都采用瀑布模型的开发方式。 

具体地说，一个基本的软件开发流程包括需求阶段、系统设计阶段、详细设计阶段、编码阶段、单元测试阶段、集成测试阶段、系统测试阶段、软件发布软件维护阶段。其中决定软件开发成功与否的关键阶段是：软件需求管理、软件计划管理、软件质量管理和软件配置管理。 

为了在用户和处理用户需求的软件项目组之间达成共识（用户由最终用户、高层领导、销售人员和市场调研人员组成），“软件需求规格说明书”是必不可少的。经过正式的评审和确认，其将成为后续工作的基础。 

软件项目的实施过程是根据软件项目的资源、约束条件和执行能力确定的，因此需要制定合理的软件工程管理计划，这是项目经理的职责之一。项目经理应定期检查“项目开发计划书”，按照当前项目开发的实际情况，对其进行调整。 

为了保证每一个软件产品都合乎需求，需要设立一个负责项目监督和协调的SQA。其会对软件产品是否符合定义好的软件过程中的相应部分进行审查、复审和测试。公司高层主管应该定期参与、评审SQA的活动。 

软件配置管理是指在整个工程期间对项目的所有软件配置项进行规范化管理。如采用版本控制软件对软件配置项版本进行版本控制，采用基线管理方法对变化进行控制，即在遵循软件工程标准的基础上对整个软件进行控制和管理，维护其完整性、一致性和可跟踪性。 

瑞星努力营造的是一个广泛的网络，研发、制造、销售、分销和服务，连续进行。围绕着产品、市场和开发阶段而不是单纯的技术来组织各项工作。为了这个目的，标准操作是必不可少的。 

附录：开思公司《产品部开发规范》　（摘要）

说明：第一部分为《目录》，从中可以看出开思公司《产品部开发规范》的整体架构；第二部分为《开发规范概述》，从中可以看出开思公司在软件项目管理方面的一些具体做法。 

1　　目　录 

1　目的 

2　开发规范概述 

2．1　应用项目管理管理开发过程 

2．2　标准的阶段性开发工作 

2．2．1　总体规划 

2．2．2　项目立项 

2．2．3　需求分析 

2．2．4　系统分析 

2．2．5　系统设计 

2．2．6　编码实现 

2．2．7　项目测试 

2．2．8　文档制作 

2．2．9　项目验收 

2．2．10　项目版本化发布 

2．3　项目组织 

3　开发工作规范 

3．1　总体规划阶段 

3．1．1　项目需求报告 

3．1．1．1　工作定义 

3．1．1．2　前序工作及输入成果 

3．1．1．3　具体工作内容 

3．1．1．3．1　资料收集（可选） 

3．1．1．3．2　资料研究（可选） 

3．1．1．3．3　项目需求报告编制 

3．1．1．3．4项目需求报告讨论准备 

3．1．1．3．5　项目需求报告讨论 

3．1．1．3．6　项目需求报告修改 

3．1．1．3．7　项目需求报告验收 

3．1．1．4　参与者及职责 

3．1．1．5　输出成果及后序工作 

3．1．2　技术可行性实验（可选） 

3．1．3　项目计划书 

3．2　项目立项 

3．2．1　立项申请 

3．2．2　项目立项评估 

3．2．3　项目进度计划 

3．2．4　项目立项审批 

3．3　需求分析 

3．3．1　资料收集 

3．3．2　需求分析编制 

3．3．3　讨论准备 

3．3．4　需求分析讨论 

3．3．5　需求分析修改 

3．3．6　需求分析验收