软件项目技术方案

　　4.7 软件项目技术方案
　　
　　技术解决方案主要是研究关于软件设计、开发与实施方面的问题。解决解决方案的目的就是为设计、开发与实现需求的解决方案。
　　
　　技术解决方案过程域的事项主要有：
　　
　　（1） 对设计与解决方案进行评估，满足适当的配置需求；（2） 进行选定的解决方案进行细部的开发设计，细部涉及应该包括制造、程序制作以及产品设计或者产品组建需要的信息。（3） 实现产品的设计、产品或者产品组件。
　　
　　技术方案设计的内容比较多，这里主要针对 A 软件项目设计、软件编码以及软件测试进行分析。
　　
　　4.7.1 软件项目设计
　　
　　在软件设计阶段，涉及到的过程域包括技术解决方案（TS）、确认（VAL）、风险管理（RSKM）、过程与产品质量保证（PPQA）和配置管理（CM）。因此，需要作如下质量控制：
　　
　　4.7.1.1 设计
　　
　　从工程管理的角度看，软件设计分为概要设计和详细设计，根据项目实际情况，对详细设计作了裁剪，只进行概要设计。
　　
　　（1） 概要设计
　　
　　概要设计是将软件需求转化为数据结构和软件的系统结构，需要建立整个软件的体系结构，包括总体结构设计、子系统的划分、模块的划分、接口设计、界面总体设计、数据结构设计、系统出错设计、系统安全设计和维护设计等。
　　
　　（2） 编码规范制定及评审
　　
　　设计通过评审后，那么将进入到编码阶段。编码之前，需要制定编码规范，如果组织前期已经有某种计算机开发语言的编码规范，那么可以直接沿用；否则需要制定相应开发语言的编码规范，然后对其进行评审，通过评审后对项目成员进行编码规范的培训，要求项目成员在开发期间必须严格遵守规范进行编码。
　　
　　（3） 代码重用性分析
　　
　　软件复用是指在新软件的开发过程中，利用已有的、可复用的软件成分来构造和生成新的软件系统。软件复用是为了避免重复劳动而采取的一种解决方案，其出发点是应用系统的开发不再采用一切“从零开始”的模式，而是已有的工作为基础，充分利用过去其它项目开发中积累的知识和经验，从而将开发的重点集中在应用的特有构成成分上，提高了软件的开发效率。
　　
　　项目经理需要指定人员把需要重用的代码抽象出来，并以文档的形式加以说明，然后给项目各成员进行培训。
　　
　　4.7.1.2 设计评审
　　
　　概要设计评审分为两部分：
　　
　　（1） 同行评审
　　
　　同行评审是由一组与软件工作产品的作者处于同一级别的、具有类似工作（技术）经验的技术人员来进行。同行评审是设计过程中不可缺少的部分，同行评审使得设计缺陷能及早发现和排除，同时提出宝贵的修改意见和建议，为高质量产品提供强有力的保障。
　　
　　（2） 正式评审
　　
　　正式评审相对同行评审而言比较正式，一般采用会议的方式进行。首先作者逐项回复评审员同行评审发现的问题，评审组确认是否为缺陷；然后将已确认的缺陷记录到评审报告中，待评审对象浏览完毕后，作者复述记录的所有缺陷，评审组各成员对照工作产品核对记录的完整性、正确性；最后评审组长确定评审结论。
　　
　　在编写完概要设计之后，需要进行同行评审，对于 IPTV-BOSS 这个项目，其同行评审结果如图 4-6 所示（限于篇幅，只对列表作了截图）：
　　
　　QA 人员把设计评审发现的问题记录到概要设计评审报告中，过后跟踪这些问题的状态，直到这些问题全部解决为止，然后通知项目经理要求配置管理员把概要设计说明书和概要设计评审报告一同上传到配置库中。
　　
　　4.7.2 软件项目编码
　　
　　在软件编码阶段，涉及到的过程域包括验证（VER）、确认（VAL）、过程与产品质量保证（PPQA）和配置管理（CM）。因此，需要作如下质量控制：
　　
　　4.7.2.1 代码走查
　　
　　代码走查（code walkthrough）是一个开发人员与架构师集中参与讨论代码的过程。代码走查可以提高软件的质量，以及可维护性。这样就可以减少查找错误的时间，提高解决 bug 的效率，提高开发效率的同时降低后期的维护成本。其次，经过走查的代码是能够迅速被项目组其他成员看懂的，这样有利于项目其他成员更全面的了解业务，对于成员之间交流也有很好的促进作用，当其中负责某个模块的开发人员离职之后其他人员能够迅速的接手相关的开发，并能够尽快的培养新人弥补空缺。最后，代码走查的过程是总结提高的过程，也是交流的过程，可以有效的提高开发人员的技术水平以及业务素养，增强公司的竞争力，通过总结交流甚至可以从不同项目中提取共性，做出相关产品，从而形成公司自己的核心竞争力，做到行业领先。
　　
　　代码走查后把走查人员发现的缺陷数按不同等级划分，最后计算出相应的缺陷密度，从而可以衡量其代码质量。最后输出代码走查缺陷数据分析。
　　
　　根据程序代码走查规范，每周对各模块的开发人员编写的代码进行代码走查，同时把代码走查的情况记录到代码走查报告中，由 QA 人员跟踪处理。对于 A 项目，我们做了相应的代码走查，代码走查报告如图 4-7 所示（限于篇幅，只对列表作了截图）：
　　
　　最后对缺陷进行统计分析，具体信息如表 4-10 所示：
　　
　　根据设定的质量目标，代码走查的缺陷密度目标为 5,而当前走查发现的最大缺陷密度为 3.521,完全符合质量目标，因此，该项目代码质量合格。
　　
　　而对于未实施 CMM,相同的模块，相同的代码走查人员，其缺陷情况如表 4-11 所示：
　　
　　由此可见，未实施 CMM 前有两个模块（产品管理、合作伙伴管理）的缺陷密度超过了缺陷密度目标 5,因此质量达不到要求。
　　
　　4.7.3 软件项目测试
　　
　　在软件测试阶段，涉及到的过程域包括验证（VER）、确认（VAL）、过程与产品质量保证（PPQA）和配置管理（CM）。因此，需要作如下质量控制：
　　
　　4.7.3.1 测试计划的编写
　　
　　测试负责人需要根据项目的总体计划制定出测试计划，包括测试方案、测试工具的选型、测试通过准则、测试环境、测试资源安排及进度计划等内容。
　　
　　A 项目的测试用例评审报告如表 4-12 所示：
　　
　　QA 人员跟踪测试用例评审发现的问题，并记录到问题跟踪表中，随时跟进问题的状态，直到问题的全部解决为止，方能进入执行测试阶段。
　　
　　4.7.3.2 测试执行
　　
　　测试人员根据已经通过评审的测试用例进行测试。首先进行集成测试，分别对各模块进行黑盒测试，测试各个模块的功能是否已经实现，是否符合要求，各模块都已经通过测试之后，再进行至少两轮以上的系统测试，以便进行需求覆盖率的测试、各模块间的衔接以及与外部接口的联调测试等。在该项目中，要求测试人员把发现的问题提交到缺陷跟踪工具 Test Director 中，以便跟踪问题的状态。
　　
　　4.7.3.3 测试报告编写
　　
　　根据以上严格的集成测试、系统测试之后，需要测试部门拟出一份测试报告，报告中给出测试结果统计信息、缺陷统计信息以及测试结论等25.项目经理根据测试报告中发现的缺陷数量以及测试部门的测试结论作出决策，如果存在的缺陷不影响系统的正常运作，比如缺陷严重程度比较低的提示性问题，这样的情况不影响系统的发布；如果缺陷程度比较严重，直接影响系统的运行，那么必须进行修改，然后再度进行回归测试，直到问题解决为止，只有这样，才能保证交付产品的质量，才能满足客户的要求，从而才能提高客户的满意度。
　　
　　4.8 培训程序
　　
　　培训程序关键过程区域的目的是培育个人的技能和知识，使他们能有效地和效率高地履行其职责。每个软件项目的技能需求都可以作为未来项目的培训要求。某些技能可有效地和效率高地通过非正式的载体传递（例如在职培训和非正式指导），而某些技术能则需要较正式的培训载体（例如课堂培训和受指导的自学）才能有效地传递。在应用培训程序时必须选择和使用恰当的载体。培训活动是有计划的，是文档化的，是项目计划表的一部分。
　　
　　给予培训的老师和参加培训的学生也都要按照项目计划来定，保证人力资源合理利用。不过遇到变更时，培训计划也需要通过项目经理、培训组、软件工程组等各组间的协商，进行修改和管理。另外，为了保证培训的效果，培训要有记录和考核，并将记录文档化，作为未来项目的分析和借鉴。
　　
　　培训程序过程域在软件开发过程中的应用十分普遍。根据 A 项目存在的问题，为了避免因对配置管理工具的用法不了解导致的软件项目质量问题，培训部门采用课堂教学加上机辅助的方式，特别增加了针对没有用过配置管理工具的工程师的全套课程，和针对用过配置管理工具的工程师的更新课程。参加的人员根据之前的培训记录和项目经理来定，培训完成后则要更新培训记录。培训出席人员记录如图 4-8 所示。
　　
　　对于文档管理方面，由于技术性不是很强，反而侧重于工作流程，培训部门采用定期自学加考核的方式，要求所有项目人员完成相关网络课程。网络课程培训记录如图 4-10 所示。
　　
　　该课程不是针对项目中的某个角色制定，而是介绍了项目中所有角色在文档管理方面的职责和 ISO 质量管理体系的相关规定。这样的培训即能让被培训者了解自己的责任，又起到了项目成员之间互相监督的效果。同时，不固定上课时间的网络课程，也不会影响到项目的进度。
　　
　　4.9 组间协调
　　
　　组间协调的目的是建立软件工程组与其它工程组一起积极参与的方式，使得项目能够更有效地满足顾客的需要。组间协调员由项目工程组的代表担任。对外，组间协调员，应适时与客户和最终用户一起工作，参与建立系统层的需求、对象和计划，这些需求、对象和计划成为全部工程活动的基础，这样的工作方式对需求管理和项目计划过程域有进一步的帮助。而对内，组间协调员与项目经理合作，对组间的技术工作界面和相互作用加以计划和管理以保证整个系统的质量和统一性。各项目工程组的代表参与定期的技术评审和内部交流，以保证所有工程组都清楚各组的状态和计划，并保证系统和组间的问题受到恰当的关注。
　　
　　组间协调员与客户、最终用户的沟通，组间协调员与各组间的沟通协调如图 4-11 所示。
　　
　　针对 A 项目，组间协调员在与客户和最终用户一起工作是，通过邮件形式与项目组传递信息。并与项目经理保持每周一次的电话会议来传递信息，协调解决问题。
　　
　　为了保证组间工作时有效的通信和协调，应用组件协调过程域做了一些约定。
　　
　　（1） 对于组间传递的文档格式不兼容，无法读取的问题，约定，不管是数据库系统、报表软件、制图工具、库管理工具等，必须保证在不同的工程组间所用的工具是兼容的。A项目中，使用 AutoCAD 软件编辑工程设计图纸，使用 PDF 软件进行图纸的查阅、审批和交工，使用 Excel 制作报表，使用 Word 制作文档，使用。jpg 格式作为图片保存格式，使用SecureZip 来加密压缩文件。
　　
　　（2） 对于多个工程师对同一个数据库做软件开发时，工作的不一致或不同步而导致的重复工作，约定，在做软件开发前，先建立一个通用组态库，工程师在开发过程中必须引用该库内容来保证工作的一致性。当遇到库中内容不适用的情况，工程组应开会讨论得出共识的解决方法，来防止重复工作。A 项目的通用组态库结构如图 4-12 所示。
　　
　　（3） 对于组间沟通，约定，在项目执行阶段，各组必须参加周会，在会上讨论需要组间协调的工作。通过周会来及时的发现问题，解决问题，并形成周报，将其文档化，以便分析和追踪问题。A 项目的周报截图如图 4-13 所示。