"你说的很好，因为他是个通用模型，所以我无法在这个模型图形中将所有的里程碑写出来，因为不同的生命周期里程碑是不一样的，所以我只能用数字标识了。"晨落解释道。"首先你觉得这个模型图你能否理解？"
"不能，请你详细解释。"
"一个软件开发过程，应该至少有三个架构和一个生命周期组成（图0-1中间部分），技术框架是软件开发过程的重要组成部分（图0-1中右面部份），他所关注的是生命周期中生命周期实现的方法，我们经常所说的方法包括：分析方法等。"晨落喝了口咖啡继续说道："管理框架。图0-1中左面部分是从软件工程的视角对生命周期中的每个里程碑进行评价的框架，他按照项目管理和评价体系对项目中的里程碑进行评价，保证软件高质量完成，技术框架和管理框架是相辅相成，二者缺一不可的。支撑平台是项目能够正常运作的基础，包括公司的人事管理制度、绩效考核制度等，因为项目经理或其他项目管理人员具有项目的考核权，而没有执行权。这样需要公司管理层面给予支持，所以支撑平台非常重要，支撑平台的关键人物就是公司的管理层，比如总经理徐杰。"晨落说完后，看着徐杰笑了笑。
徐杰说道："这个图你这样解释我就看懂了，但是，我们公司目前的状态是，每一个框架都做的很差，你这样一说我知道应该关注那些框架了，但是，如何关注我就又不知道了，如何能够提高团队开发能力就不知道了。"
晨落说道："这个没关系，只要你积极配合，我会有告诉你如何培训的。将我们公司所有项目进行培训是不现实的，我们可以考虑选择其中一个项目，针对这个项目进行培训和指导，采取案例式培训方法，这样才能够保证培训质量。"
"我赞成，我打算先对投核保系统开发团队进行培训，计划从其他项目组抽调一些人员，组成新的开发团队，然后由您来对这些项目组成员进行现场培训，采取项目的里程碑方式进行培训，遇到什么问题，进行具体培训。我邀请您全程参与到我们项目中来。"
"这个没有问题，但是，在培训之前，我必须对公司软件团队现状进行调研。你打算指定谁来承担投核保系统的项目经理？"晨落问道。
徐杰说道："徐杰，她是有多年项目经验的项目经理，组织能力也很强，技术也很过硬。"
"我们围绕着刚才那个模型，针对不同框架逐一分析，了解一下目前的状态。"晨落说道
徐杰说道："现在就可以吗？核心是徐杰没有到现场呀。"
晨落说道："通过QQ即可。"
说着，徐杰通过QQ按照三个框架分别从徐杰那里了解到项目的状况。
关于管理架构方面，徐杰的反馈是：目前只用到项目管理过程，其他过程没有考虑过，主要是因为没有人力资源来负责这项工作，同时也不知道如何管理。
关于技术架构方面，徐杰的：分析和设计方法采取面向对象的分析和设计方法；软件架构建模语言使用UML语言；数据库设计采取PowerDesigner，开发语言采用Java语言；框架方面目前计划采取SSH（Struts+Spring+Hibernate）框架。其他方面目前没有考虑到。
关于生命周期方面：采取传统的瀑布模型。
关于人力资源方面：系统分析员有一名，毕业四年；架构师两名，毕业三年，数据库架构师1名，毕业两年；程序员多名。
晨落看了看徐杰反馈的信息，想了想说道："管理框架按道理来说非常重要，但是，现在我们尽然没有在我们的项目中应用到，这个你觉得重要吗？"
"是的，是非常重要，但是，说实话，这样会使我们的项目进度变得很慢，客户项目经常是非常急，我知道写文档，搞评审会占用大部分时间。我尝试着做过，但是，放弃了。"徐杰说道。
"你刚才不是说过吗，项目进度总是延期，说明项目延期不是因为应用管理框架导致的，其实管理框架的应用并不会影响我们的进度，只能是让我们的工作效率更高。当然在开始阶段，可能从表面上看进度慢了，但是，如果质量能够提高了，后期的返工自然就少了，延期也就不可能发生了。"晨落喝了口咖啡说道："如果我们不对管理框架进行培训，其他方面的培训只能是治表不治本。团队技术水平如何高，如果没有很好的管理配合，项目依然无法成功。你说呢？"
徐杰："我知道，但是，说实话我真的不知道如何去做才好。"
晨落："这刚好是个时机，因为投核保系统开发团队是你的新团队，这个团队所有的一切都从零开始，我们可以通过这个项目，对开发人员进行不同层次的分角色培训，并且就结合投核保系统具体案例来培训，我全程参与，按照确定的生命周期，项目执行到那个步骤，我们针对具体情况进行具体培训。"
徐杰低低头然后问道："你的思路是什么？"
晨落想了想，然后在纸上勾画出如下培训体系图。
晨落解释道："培训体系图是在软件开发模型的基础上，结合项目具体情况而设计的。它包含了软件开发模型的三大框架。"
"那些框架？这些框架是如何体现的？"徐杰看着图问道。
"是这样的，我的思路是从业务调研开始到代码结束进行分阶段培训。无论软件生命周期如何定义，如何采取敏捷开发方法也罢，其他方法也罢，但是肯定不会少于这几个流程，业务调研、需求分析、软件架构、数据架构、软件实现、数据库实现这些流程，我们将这些流程称为里程碑。针对每个里程碑根据技术需求技术框架的培训。这个不知道你能否理解？"晨落说道。
徐杰："这个可以理解。我们对每个里程碑需要进行必要的评审，对于这些评审我们目前的团队没有这个人力资源，但是，我觉得有必要把这个管理框架组织组建起来。然后结合项目状况具体培训，并且直接应用到项目中来。"
晨落："很好，这也是我想到的，英雄所见略同！"
"技术框架部分我从项目经理那里已经知道大概的培训内容，那么管理框架方面您是如何计划的？"徐杰问道。
"在投核保系统中，我打算将需求管理、项目管理、质量保证、软件测试、配置管理这几个过程域执行到位。按照项目不同里程碑，分别对这几个过程域进行详细培训。"晨落道。
徐杰："我同意，培训内容是如何组织的呢？"
晨落："这个需要给我点时间，通过与项目经理沟通后在做详细计划，到时候我会将计划呈报给你的。"
徐杰："那好的，谢谢您了，我全力支持您的工作，我会积极配合的。"
编写本系列书的思路
在企业培训中，以软件生命周期为主线，将技术框架和管理架构的培训融入到项目中来是一种行之有效的培训方法。我的朋友多次建议我把我的培训思想和方法整理成书籍肯定有读者。但是，我心里明白写书并非是一件容易的事，在忐忑中开始了写书的漫长历程。初期阶段我计划写一本关于UML方面的书，但是，我发现UML仅仅是一种描述语言，是软件系统分析与设计的表现形式，是软件技术人员灵魂的体现。单纯的写UML显得有点单薄，没有办法将软件分析与设计的思想灵魂体现出来。于是有点像笨媳妇和面，水多了加面，面多了加水，然后水又多了，然后面又多了。通过多次反复思考和论证，最终将本系列书的格调定了下来。
格调是：以投核保系统为本系列书唯一案例，按照软件工程的基本生命周期，分别从软件需求开发、软件架构、数据架构、数据实现和软件实现等几个阶段，采取较为科学且适用的思想设计方法完成系统的分析、设计、系统实现。用UML、Powerdesigner等工具表现出来。较为全面的将软件开发全部流程展现给读者。
关于软件架构和UML等书籍可以说为数不少，根据本人观察，在这些书籍中不同的书籍在讲着不同的案例，甚至同一书本中也有不同的案例，这就出现了一个现象，读者无法将所有的技术点有效的结合起来，对技术点的理解依然处于零散状态，无法形成一个整体。所以，本系列书在案例应用方面，全部系列书采用一个案例，全系列书总共二本八篇组成，全部采用投核保系统作为唯一案例，然后从业务调研开始，代码实现结束。采取"逐步求解，步步为营"的方法完成案例实现。本系列书将业务调研报告作为本系列书的开始点，以编程报告为本系列书的结束点。在解读业务调研报告的基础上，都是围绕着需求分析报告内容进行讲解的，解读业务调研报告，实现需求分析报告相关内容设计。软件架构部分是以投核保系统需求分析报告为全篇开始，以架构设计报告为结束。数据架构、数据实现、软件实现、软件开发过程以及软件测试管理都是采取同样的思路。
关于情景再现方面，本系列书将昂特拉软件公司投核保系统开发过程作为本书的唯一情景演练案例，将软件生命周期中关键过程域的评审会情景再现给读者，通过对话方式讨论技术点的应用场景等。
本系列书的内容，既不是对工具的独立讲解，也不是对独立软件工程的讲解，而是将二者有机的融合起来。采取的思路是，技术点讲解，技术点应用场景分析，技术点实现方法，最后将技术点应用到唯一的案例中，全面地展现给读者。
本系列书的文字组织，尽量避免采用学术性语言描述，采用情景再现的方式，通过通俗语言介绍软件架构中的关键概念，将软件开发流程中的关键环节展现给读者，让读者融入到软件开发的整个流程体验中来。
关于案例的选择，我在编写本系列书的过程中，有些朋友认为这个系列书籍中的案例不具有广泛的代表性，特别是业务部分很少有读者接触过保险公司业务。但是，本人坚持选择本案例，如果希望将软件开发的全部过程体现出来，能够覆盖软件开发的全部过程，必须选择一个有一定复杂度的案例，只有这样才能够将软件开发的整体流程全面展现给读者。
本文选自《软件是这样"炼"成的--从软件需求分析到软件架构设计》引言，本站经作者的授权。
版权声明：51Testing软件测试网获作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
