软件开发论文

　
　　关键词：需求分析；系统分析；复用；分而治之；建模；逻辑视图；并发视图；组件视图
　　
　　1 软件工程的理解
　　尽管笔者在将近2O年从事的基础技术工作中，曾经用传统开发工具及流程化的编程思想编写实现过某一项功能的程序，还从传统开发思路实现面向对象开发思路的转变，有成功和失败，有奇思怪想，也解决过一些实际工作中的问题，但依然感觉自己只知些皮毛。于是静下来时笔者也会经常反省，同时查阅各类相关文章，与同行经验交流，和关注相关软件技术发展的新闻报道。
　　
　　软件工程从概念提出至今已经近40年了，但是客观地说，软件工程还处于摸索发展阶段。软件工程主要讲述软件开发的道理，基本上是软件实践者的成功经验和失败教训的总结。软件工程的观念、方法、策略和规范都是朴实无华的，平凡之人皆可领会，关键在于运用。我们不可以把软件工程方法看成是诸葛亮的锦囊妙计—— 在出了问题后才打开来看看，而应该事先掌握、预料将要出现的问题，控制每个实践环节，并防患于未然。研究软件工程永远做不到理论家那么潇洒：定理证明了，就完事。
　　
　　软件工程以后的发展可能会变成一个广义的“软件工程”，而它却不再完全属于工程化的范畴。开发软件，人的因素会越来越重要，因为开发软件不能像汽车制造那样完全的流水化，除非软件完全产品化，但事实上很多软件都是项目化的，项目化的特点就是需求多变，有个性，只有开发软件的人运用其丰富的经验和智慧才能去适应这种多变的需求。
　　
　　软件工程思想将软件开发分成多个阶段，没有一定之规，说法也不尽相同，但总体完成的工作都是雷同的。笔者暂且按照5个阶段谈谈认识，这5个阶段是需求分析阶段、系统分析阶段、系统实现阶段、测试阶段和维护再生阶段。5个阶段需要投入的技术力量平分秋色，如今面向对象的开发思路使得代码编写已经不再是高手的事情，而每个阶段的文档编写一定是技术人员需要细致严谨的编写才可以达到工作的循环和进步，并提供给他人复用。
2 5个阶段工作的认识
　　在介绍我对5个阶段工作的认识之前，我首先敷述几个基本观念。软件工程的目标是提高软件质量，质量因素有正确性、性能、可靠性、容错性、易用性、灵活性、可扩充性、可理解性、可维护性等等。开发常用模型有：线性模型、渐增式模型、螺旋模型、快速原型模型、形式化描述模型等等。“套用固定的模型不是程序员的聪明之举”。比如“程序设计”与“测试”之间的关系，习惯上总以为程序设计在先，测试在后而对于一些复杂的程序，将测试分为同步测试与总测试更有效。
　　
　　软件开发中的3种基本策略：“复用”、“分而治之”、“优化—— 折衷”。软件复用是将具有一定集成度并可以重复使用的软件组成单元称为软构件(Software Compo—nent)。分而治之是指把一个复杂的问题分解成若干个简单的问题，然后逐个解决。软件的优化是指优化软件的各个质量因素，如提高运行速度，提高对内存资源的利用率，使用户界面更加友好等等。优化工作的复杂之处是很多目标存在千丝万缕的关系，当不能够使所有的目标都得到优化时，就需要“折衷”策略。软件中的折衷策略是指通过协调各个质量因素，实现整体质量的最优。软件折衷的重要原则是不能使某一方损失关键的职能，更不可以像“舍鱼而取熊掌”那样抛弃一方。
　　
　　其次，笔者从需求分析、系统分析、系统实现、测试与改错、维护与再生这5个方面总结了一点心得体会。工作在第一线的软件开发人员是程序员和程序负责人，他们决定着软件的命运。程序负责人应是程序员队伍中经验丰富的，熟悉每个阶段的工作，能够把握判断决策，有人格魅力，程序员要对编程感兴趣，程序员不能是临时的。
　　
　　制定进度表的人最好就是项目负责人，他最了解项目和开发人员。进度安排并不一定要符合逻辑顺序。开发一个大的软件项目，应该将进度表分为若干个里程碑。一个里程碑之内的多个任务可以同步进行。进度表中必须留有缓冲时间，并将缓冲时间用到不确定的事情上。
2．1 需求分析阶段
　　需求分析是项目成败与否的第一步，对需求把握得越准确，软件的修修补补就越少。有些需求在一开始时很难确定，在开发过程中要不断地加以改正。软件修改越早代价越少，修改越晚代价越大。需求分析要关注到每一个最终使用者，避免遗漏使用方的需求。需求分析尽量从多个角度进行。需求分析需要与使用者进行多次反复沟通，开发者做到真正领会使用者的需求。做可行性分析不能以偏盖全，也不可以什么鸡毛蒜皮的细节都加以权衡。可行性分析必须为决策提供有价值的证据。
　　
　　需要分析的工作要点有：① 完成问题整理、收集；② 走访使用部门，进行询问、沟通；③ 交流中的心态定位是我们在为编辑、为业务工作；④ 我们要为用户考虑。让用户意识到我们的每一句话都是在为他们考虑；⑤采用适当的交流语言。勾画出思路清晰用户易懂的流程图 ，清晰明了的表格，形象美观的图形，必不可少的文字；⑥ 保留交流的记录和整理汇总的文档；⑦ 技术人员自己要提出用户易用性需求、系统功能需求、系统维护需求；⑧ 响应变更需求，拒绝不合理要求；⑨业务建模。通过UML绘制的模型来完整、适当地对需求进行描述；⑩ 分析绘制业务流程图和数据流程图，总结出各级操作人员，识别系统中的所有用例和角色；分析各角色和用例之间的联系，使用UML建模工具画出系统的用例图；最后勾画系统的概念层模型，借助UML建模工具描述概念层的类图和活动图。
2．2 系统分析阶段
　　系统分析阶段完成系统设计。系统设计是把需求转化为软件系统的最重要的环节，决定一套软件系统的健壮性、可扩展性、易开发性等。系统设计的优劣在根本上决定了软件系统的质量。这个阶段要确定系统结构，系统结构的稳定性决定应用软件的使用寿命。
　　
　　有了上一阶段需求的把控和需求建模，系统分析阶段就要完成结构设计、模块设计和数据结构设计。模块设计的组件单元尽可能小，可让每个程序员承担很少的开发部分，各部分之间不受牵制，强内聚、弱耦合，使单元组件可以随时重新开发，而对整体的开发不造成瓶颈。该阶段还要设计系统运行平台的架构，部署系统物理平台，制定系统备份恢复机制。
　　
　　2．3 系统实现阶段
　　这个阶段选择通用的编程工具，按照需求建模和系统设计中不同模块拆分给不同的技术人员，并实现进度控制。
　　
　　2．4 测试阶段
　　这个阶段是系统上线前的关键期，是对需求分析和理解的验证阶段，在这个阶段可以发现结构设计的合理性，进而可能回退到分析设计阶段进行系统重构。可以按照黑盒测试、正确性测试、容错性测试、性能与效率测试、易用性测试和文档测试这6个方面进行分组测试。开发过程中进行同步测试。针对测试中发现的问题，进行程序修改。之后再进行分组测试，如此往复。最后，进行总测试，直至成品。
　　
　　2．5 维护再生阶段
　　通常开发人员会忽略维护与再生这个环节。对于一个优秀的程序员来说，这个环节非常关键。在这个环节中，程序员可以积累很多运行中存在的问题，将这些问题总结成为系统性能需求，然后将系统性能需求转入到再生工程中进行升级改造。再生工程与维护的共同之处是都没有抛弃原有的软件。如果把维护比作“修修补补”，那么再生工程就算是“痛改前非”。
3 运用建模工具完成5个阶段工作
　　下面是运用软件开发系统建模工具与面向对象的开发模式结合来完成几个阶段的工作。我们可以用建模工具创建5种视图，用例视图、逻辑视图、组件视图、并发视图、配置视图。用例视图是软件需求分析到最终实现的第一步。这个视图是开发人员与使用人员之间的交流视图。在做需求分析的过程中，除了传统的调研方式和调研之后的归纳整理工作之外，还再增加一项工作，就是运用建模工具生成用例视图。看似增加了一项工作，但却是生成逻辑视图、并发视图、组件视图的基础，运用建模工具可以将建模工具语言转化成相应的面向对象的编程语言，从而减少软件编写的开发量，大大提高开发效率，缩短开发周期。也就是前面所说，软件开发不再局限在高手，而经验和分析贯穿每个阶段，经验和分析的重要性更加突出。
　　
　　根据逻辑视图、并发视图、组件视图可以将软件开发分块，切割给不同的团队或者不同编程风格的人去实现，总体开发进度不会因个别部分或个别人受到重大影响。逻辑视图使用者主要是设计人员和开发人员。并发视图使用者是开发人员和系统集成人员，组件视图使用者主要是开发人员。配置视图用于系统资源配置，是与软件开发的维护再生阶段密切相关的。逻辑视图、并发视图、组件视图完成后，和系统运行密切相关的就是配置视图，它的使用者是开发人员、系统集成人员、测试人员，这个直接影响到系统运行平台的稳定性和可持续性。