软件开发中的人员与过程.ppt

第二章,软件开发中的人员与过程_2,上节回顾,软件的三要素： 程序、数据、文档 软件工程师应具备的素质要求： 智力、个人素质、技术能力、共同合作能力、危机感 软件工程师职责要求与任职条件： 程序员、软件工程师、系统分析师、项目经理 软件工程师的“武器”： 编程语言、开发工具/平台、数据库管理系统、操作系统、软件工程,本节目标,软件工程师需养成的习惯： 编码习惯与规范、撰写文档能力 、源代码管理习惯 、主动沟通与反馈 、计划与总结的习惯 、测试习惯 软件开发生命周期介绍 需求分析、系统设计、编码实现介绍与难点分析,软件工程师需养成的习惯,编码习惯与规范 编码规范 编码风格 编码误区 文档撰写能力 源代码管理习惯 主动沟通与反馈 计划与总结的习惯 测试习惯,编码规范1,编码习惯与规范 作为一名合格的软件工程师，代码必须按一定规范编写，Martin Fowler曾经说过“任何一个傻瓜都能写出计算机可以理解的代码，未有写出人类容易理解的代码，才是一个优秀的程序员”。,编码规范 2,编码规范是公司或团体对代码编写的一个规定和约定，目的是使程序代码具有更好的一致性与可读性。 写代码首先要遵循一定的编码规范。“没有规矩，不成方圆”。作为专业的软件工程师，即使在程序设计工作中总能创造性地奇思妙想，也必须遵守一定的规则和限制。 现代软件项目的开发往往需要团队协作，那么所编写的代码就不仅仅是给自己阅读的。况且，代码风格的简单一致通常会减少bug；相反，对于风格糟糕的代码，软件工程师往往宁愿重起炉灶，也不愿去阅读和维护。,编码规范 3,代码本身也可能会进行合作开发或后期维护，一个软件的生命周期中，80%的花费在于系统维护，而且几乎没有一个软件，在其整个开发生命周期中，由最初的程序员维护旧代码，若代码按规范编写，可以让维护者尽快理解代码要表现的意图。 规范无所谓“好”与“不好”，同一门编程语言，可能会有多种编程规范，各公司所用规范也不完全相同，但是为了执行规范，每个软件开发人员必须一致遵守编码规范。,编码风格,代码是给人看的，除了遵循编码规范外，还需要有良好的代编码风格。好的代码应该简明扼要、平实易懂。 首先，要求代码条例清晰，顺着代码，很容易看出作者的逻辑思路。要传达什么信息，要求什么样的结果，直截了当，没有岐义。 其次要求代码平实简明，不要简单问题复杂化，不要在代码中卖弄编程技巧，smiple is the best。,编码误区 1,飞流直下三千尺，疑是银河落九天 这里用来形容象瀑布一样的代码，一个函数或类写上千行，甚至上万行，有人将这样的类或函数为“上帝类”或“上帝函数”，意思来戏称它们是“万能的”。 一个函数行数太多，不符合人类的认知习惯，一般来讲，一个函数或功能模块代码不要超过一屏幕，最好保持在30行以内。 如果把一个函数类比喻成文章中的一个段落的话，那么一个上千行的函数就是一个跨度为几页的一个长段落。可以想象，没有人愿意读这种长段落。 把一个很长的函数分化成很多很小的子函数或者子函数的子函数，不仅可读性会变好，而且总体的代码量也会也会减少。因为很长的函数中往往伴随着重复代码，变大为小的过程，我们称之为“重构”的过程。 如果一个类中定义了太多的属性与方法，也说明它有可能需要改进。这时候可以考虑分拆成多个类，或者抽象父类等方法。,编码误区 2,为人性僻耽佳句，语不惊人死不休 诗人写诗可以打破常规，追求新奇，但是代码绝对不能这样。在代码中，我们要按照常规的手法来写，不要出“奇招”、“怪招”，因为稀奇古怪的代码容易引起隐含的bug，另外可读性也不好。 千呼万唤始出来，犹抱琵琶半遮面 这里指函数与变量的命名要见名知意。例如：function1（int i1，int i2）这样的函数，我们很难知道它的作用，以及参数的意义。 在实际的命名中，不要怕费事，长一点的函数与变量名可以提高代码的可读性。 犹抱琵琶半遮面的不仅仅是变量命名，迂回曲折的逻辑同样让人糊涂，我们在编写代码时，不论变量还是逻辑，都要以清晰易懂为佳。,编码误区 3,为赋新词强说愁 这里指有些软件工程师为了显示水平而套用一些不必要的结构和定势做法。尤其是在对面向对象与设计模式不太理解的情况下，抽象出不必要的类结构和继承关系。 把代码及其表达的逻辑分散到太多的类中，在代码管理和阅读理解上都会造成困难，同时对于系统性能，也有负面影响。,文档撰写能力,多数的软件工程师的代码水平好于其写文档水平，软件是文档的重要组成部分，这要求软件工程师必须具备文档书写能力。 文档的书写，一是要按文档模板完成，各公司均提供各种文档模板，二是要求文档易读、直白，采用书面语书写。,源代码管理习惯,绝大多数软件工程师都经历过源代码丢失，或者旧版本覆盖新版本的问题，防止这种情形发生的一个好的方式就是采取版本控制工具。 关于版本控制工具的配置及使用，我们将在第二阶段的软件素养课程里面具体介绍。,主动沟通与反馈,一个项目组由多名软件工程师组成，我们要学会积极主动地与其他成员沟通与交流，保证项目组成员对问题理解地一致性。遇到自己无法解决的技术难题，要多与其他成员讨论，用最短的时间解决问题。,计划与总结的习惯,项目有项目计划，项目组每个软件工程师需要根据项目计划制定自己的工作进度，如何准确估量自己的工作进度，按项目计划安排好自己的工作计划，这个需要软件工程师有经常性的计划习惯。 要做好计划，需要有好的时间管理计划及学会使用时间管理工具，例如甘特图。 总结是学习与工作过程中一个重要的环节。善于学习的人必然善于总结。总结能够将自己零散的收获条理化，变成自己的知识与经验的积累。,测试习惯,鉴别软件工程师优秀与否的一个方面就是看其提交的代码bug是否足够少。这必然要求软件工程师在提交代码之前，先要自己测试无误。 作为一些商业化正规化的开发而言，专职的测试工程师是不可少的。 问题发现的越早，解决的代价就越低。 开发人员在每段代码，每个子模块完成后进行认真的测试，就可以尽量将一些潜在的问题最早的发现和解决，这样对整体系统建设的效率和可靠性就有了最大的保证。,软件生命周期概述 1,一个人要经过胎儿、儿童、青年、中年、老年，直到最终死亡的生命周期。 一个软件同样有一个从定义、开发、使用和维护，直到最终被废弃的生命周期。 在软件的生命周期中，需要完成许多性质各异的工作，这就要求把软件生命周期划分成若干个阶段，并相应地制定出切实可行的计划，然后按照计划对软件的开发与维护工作进行管理。,软件生命周期概述 2,软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程称为软件生命周期。 软件工程是把软件生命周期依此划分为若干个阶段，每个阶段有相对独立的任务，然后对每一阶段进行严格管理。 把软件生命周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；在软件生命周期的每个阶段都采用科学的管理技术和良好的技术方法，使得软件开发的全过程以一种有条不紊的方式进行，这样，能保证软件的质量，特别是提高软件的可维护性。,软件生命周期概述 3,软件的生命周期通常划分为五个阶段： 需求分析 系统设计 编码实现 软件测试 运行维护,需求分析概述,需求分析是解决“做什么”的问题，即我们需要做一个什么样的系统。 系统分析阶段的基本任务是：系统分析员与用户在一起交流，充分了解用户的要求，并把双方的理解用系统方案书表达出来。,需求分析可行性分析,在进行具体需求分析之前，还需要对项目进行可行性分析，可行性分析是解决“做与不做”的问题。即我们能否做这个项目。 从理论上讲，只要资源和时间不加限制，所有的项目都是可行的。然而，由于资源缺乏和交付时间限制的困扰以及项目是否能够盈利，对软件项目的可行性做出细致而谨慎的评估是十分必要的。如果在制定计划阶段及早发现将来可能在开发过程中遇到的问题，及早做出决定，可以避免大量的人力、财力、时间上的浪费。 可行性分析内容主要包括：市场可行性分析、政策可行性分析、技术可行性分析、成本效益分析、SWOT分析等几个方面。,需求分析SWOT分析 1,SWOT分析即“强弱机威”综合分析法，是一种企业项目竞争态势分析方法，通过评价项目的： 优点(Strengths) 弱点(Weaknesses) 竞争市场上的机会(Opportunities) 威胁(Threats) 通过SWOT用以在决定企业项目前对企业项目进行深入全面的分析以及竞争优势的定位。,需求分析SWOT分析 2,分析出项目的SWOT后进而需用USED技巧来产出解决方案，USED是下列四个方向的重点缩写，如用中文的四个关键字，会是用、停、成、御。USED分别是： How can we Use each Strength ? 如何善用每个优势？ How can we Stop each Weakness ? 如何停止每个劣势？ How can we Exploit each Opportunity ? 如何成就每个机会？ How can we Defend against each Threat ? 如何抵御每个威胁？,需求分析难点解析 1,开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。 需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。,需求分析难点解析 2,需求分析难点解析 3,把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。,需求分析难点解析 4,行业知识匮乏 软件工程师一般技术比较在行，但是业务知识不一定理解。假如对用户所在的行业不了解，则不能很好地与用户沟通，需求也难以详细调查清楚。例如，需要为客户做一套财务软件，若是需求调查人员根本不懂财务知识，则与用户交流都很困难。 此时应当赶紧补习应用域知识，不论是通过自学还是培训的方式，如果可能的话，开发方最好请既懂软件又懂应用域知识的行业专家来帮忙。,需求分析难点解析 5,用户说不清需求 用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。其实这个并不能怪用户，试想，假如我们去买鞋子，我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状。通常拿鞋子去试，试穿时感觉到舒服才会买鞋。 需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。 无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是分析人员的职责，也是职业的挑战。,需求分析阶段成果,可行性研究报告 软件系统需求说明书。,系统设计,系统设计要回答的中心问题是系统“怎么做”，即如何实现产品需求规格说明书规定的系统功能。 依据“分而治之”的思想，我们把系统设计过程划分为两个阶段： 高层设计阶段 详细设计阶段。 高层设计阶段的重点是体系结构设计。 详细设计阶段的重点是用户界面设计、数据库设计、模块设计、数据结构与算法设计等。,系统设计过程 1,系统设计过程 2,体系结构如同人的骨架，决定着我们整个项目的主体架构。 用户界面如同人的外表，我们在设计软件时不要沉迷于技术，而要多多思考什么样的界面才能让用户更加喜欢。 数据库是存储和处理数据用的。人体的数据库是大脑，知识相当于数据，存储在大脑里。 模块如同人的器官。每个器官都具有特定的功能，器官们依附在骨架上。模块是软件系统的部件，它们安插在体系结构上。 数据结构与算法如同人的神经和肌肉，它分布在全身，让器官具有生命并能发挥功能。,体系结构设计难点分析,体系结构是指软件系统的基本和主体的形态，也就是软件系统中“最本质”的东西。一个软件系统的体系结构设计得好不好，可以用“合适性、结构稳定性、可扩展性、可复用性”这些特征量来评估。 对于软件系统而言，能够满足需求的设计方案可能有很多种，究竟该选哪一种？此时商业目标是决策依据，即选择能够为开发方和客户带来最大利益的那个设计方案。大部分软件开发人员天生有使用新技术的倾向，而这种倾向对开发商业产品而言可能是不利的。 体系结构一旦设计完成，应当在一定的时间内保持稳定不变，只有这样才能使后续工作顺利开展。如果体系结构经常变动，那么建筑在体系结构之上的用户界面、数据库、模块、数据结构等等也跟着经常变动，这将导致项目发生混乱。,用户界面设计难点分析,通俗地讲，用户界面“好不好”主要看它是否“容易使用”和“美观”。 易用性是指用户使用软件的容易程度，是否简单容易上手，不要有太高的学习曲线。 除了要求软件易用之外，人们还希望用户界面美观。 一般来讲，我们开发应用系统，其界面应该与Windows界面保持一致性。,数据库设计难点分析,数据库是存储和处理数据用的。数据库设计的主要工作是：设计数据库的表（数据就存在表里面），表的结构就是数据的存储结构；对这些表中的数据进行操作，常见操作如查询、插入、修改、删除等。 数据库设计一般要经历“逻辑设计物理设计安全性设计性能优化”等步骤，通常要迭代进行。,模块设计难点分析,对于软件而言，我们习惯从功能角度描述模块。所以模块泛指软件系统的功能部件。在软件的体系结构设计完成之际，我们就已经确定了所有模块的功能，并且把模块们安放在体系结构的恰当位置上。 “模块化”（Modularization）是指：将系统分解为一系列功能模块，然后逐一实现这些模块，最后把所有的模块集成为原来的系统。这样做的好处是能够大大降低系统的开发难度。 每个模块都具有特定的、明确的功能。我们在设计模块时应当尽量使模块的功能独立，因为功能独立的模块可以降低开发、测试、维护的代价。但是功能独立并不意味着模块是绝对孤立的。所有的模块应当能够被集成为一个系统，所以模块之间必定要交流信息、相互配合。,系统设计阶段成果,体系结构设计报告 用户界面设计报告 数据库设计报告 模块设计报告,编码实现,软件实现是将“软件设计”的结果变换成用程序设计语言编写的计算机能识别的程序。 系统实现是在系统分析、系统设计的基础上，将系统设计的每一个细节，用计算机语言（或开发工具）完整地表达出来，在计算机上应用该系统。系统的实现既是对系统分析、系统设计阶段工作的检验，又是取得用户对系统信任的关键阶段。系统的规模越大，系统的实现就越复杂。为此，程序设计人员要具有比较丰富的程序设计经验，具有良好的程序设计风格和丰富的编程技巧。 系统实现的主要任务是进行编程语言的选择、程序的编写与调试。,编码实现难点解析 1,编程语言的选择 选择开发人员最熟悉的，最合适的编程语言，而不是最新的，最COOL的语言。 对于编程语言的选择，要根据具体项目的要求，选择最合适的编程语言，例如，C/S架构的项目，可以选用Delphi或Winform或PB，小型WEB应用项目，没有必要选择Java。 采用新技术总是机遇与风险并存。风险主要体现在：新技术大家都不熟，开发起来效率不如用我们熟悉的技术高，新技术可能某些方面不成熟，会对我们的项目造成影响。,编码实现难点解析 2,按规范编码 正规项目，不管用什么语言