软件文档写作课件.pptVIP

辩论赛步骤 1、主持人介绍参赛队及其所持立场 2、队员依次做自我介绍，每人30秒钟 3、由正反方一辩陈词立论，时间3分钟 4、质辩阶段： 正方二辩发问，指定对方任意选手回答，时间2分钟； 反方二辩发问，指定对方任意选手回答，时间2分钟； 正方三辩发问，指定对方任意选手回答，时间2分钟； 反方三辩发问，指定对方任意选手回答，时间2分钟； 双方二辩或三辩进行质辩小结，时间2分钟。 5、自由辩论阶段：双方辩手进行自由辩论，时间5分钟 6、总结陈词：双方一辩进行总结陈词，时间3分钟 课程总结－－课内内容 软件文档是软件项目关系人之间的通用语言和文字，为关系人之间的有效沟通提供了可能。 目前业界最权威的软件工程标准化体系是CMM/CMMI 软件管理文档是项目经理进行项目管理的主要手段，是保证项目成功的关键要素 项目工作规范、工作计划和总结报告是相对比较重要的三个软件管理文档 用户文档是帮助用户更好的理解和使用软件的重要手段，好的用户文档可以帮助项目组节省成本，提高效率 软件技术文档是软件项目成果的核心组成部分，也是在项目关键关系人之间进行信息传递的主要载体 项目可行性报告和软件需求规格说明书是相对比较重要的软件技术文档 文档评审是否通过是项目能否进入下一阶段的核心依据，也是发现问题，解决问题，提出预防措施的重要环节 文档跟踪是保证项目各个阶段协调一致的重要手段，也是确保项目的各项工作符合用户需求的关键措施 课程总结－－课外内容 区域最佳 国内最佳 世界最佳 论文 题目：论软件文档在软件工程及项目管理中的作用 提交时间：结课之前，统一发电子邮件到课代表那里 内容要求：立论新颖，观点明确，论据充分，语言规范，文字简炼，内容真实可信。字数在5000字到8000字之间。 格式要求： 评分标准： 格式：15% 整体思路：30% 研究深度：20% 真实感受：20% 文字表达：15% 论 文 模 板 课程结束，谢谢大家！ 技术、资源、运营三位一体 故宫vs林肯纪念堂，月亮代表我的心 《项目可行性报告》编写目的 论证项目是否可行 为项目实施争取领导支持和必要的资源 对项目实施方案进行初步规划 识别项目风险，提前加以防范 3 4 5 2 1 《项目可行性报告》的内容和编制 项目可行性报告 3 4 5 2 1 软件需求问题是软件项目失败的祸首 特别的需求管理 模糊和不精确的交流 脆弱的架构 过度复杂 未检测出需求，设计和实现中的不一致 测试不足 对项目状况的估计过于乐观 未解决存在的风险 无法控制变化的传播 自动化程度不足 注：源自美国Rational软件工程公司的首席科学家?Grady Booch 3 4 5 2 1 软件需求工程的主要困难 3 4 5 2 1 软件需求工程的主要困难与对策 知识技能问题 应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。 当需求分析员缺乏应用域知识时，他该怎么办？ 首先他要有勇气做事，否则连实践的机会都没有。 其次他应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。 如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。 3 4 5 2 1 隔行如隔山 3 4 5 2 1 软件需求工程的主要困难与对策 态度问题 相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为： 需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。 用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。 软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。 3 4 5 2 1 合作关系 如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。 倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法： 我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧?…… 或者这个客户根本不希望把这个系统做好…… 对于软件产品而非项目的需求开发工作尤为困难。目标用户未必会买你的产品，他不会投