构建之法阶段小记七

在之前学习了需求分析和项目经理的职责及素质后,本周学习了构建之法的第10章。这么久过去了,在长时间的理论学习之后学业上也临近学期期末了,学习第十章之后对几门课程的期末大作业也有一定的帮助。

第十章在需求分析的基础上进一步提出并解释了两个概念——典型用户和典型场景,并提出了针对不同用户进行功能开发的概念。满足一些典型用户和典型场景中产生的需求可以很大程度上使得我们的软件功能得到比较完备的实现。

用例一次在之前的学习中也多次接触过,现在算是对它有了进一步的认识。在认识并利用用例进行系统需求分析的时候要注意两种规格说明书的整理,其一是软件功能说明书,其二是软件技术说明书。

在订立功能说明书的时候首要任务是定义好相关概念,再者要规范好一些假设。同时要避免一些可能产生的误解,界定一些边界条件,同时还要参照典型用户等例子描述主流的用户/软件交互步骤,也要写清楚好的功能和可能的副作用。最后,要清楚地进行服务质量的说明。功能说明书介绍的是软件实现的功能如何使用以及如何与用户进行交互,在这一层面上软件相当于一个看不到内部的黑盒。相对的,技术说明书则是详细的介绍软件如何实现,因此又被称为设计文档。在根据这两者进行实际开发的时候,多半都可以遵循以下几个步骤直至最终产生可用的成品,首先是构造总体模型,而后构造功能列表,接下来制定开发计划,计划确立后就相当于进入实际实现阶段了,开始实现后要先进行功能设计,最后才到实现具体的功能。

因为事情较多,专业方向上的诸多事物今后可能需要放一放。

时间: 2024-12-16 17:13:11

构建之法阶段小记七的相关文章

构建之法阶段小记六

本周学习了构建之法的第8.9章,总算是接触到了久闻未见的软件工程中的重中之重--项目需求分析,以及对需求和团队进行管理的重要角色--PM 我们都知道软件是由人手一行行代码写出来的,软件的存在也是为了满足人工作生活中的各种需要.如果软件开发没有目标,那写出来的代码不过就是26个字母及其大小写加上空格和一些特殊符号的随机组合罢了,没有实用意义.所以,代码的诞生一定是为了实现某个或某些具体的目标,也即这些代码最终成型后要实现怎样的功能.为了确立这样一个目标,我们就需要对最终使用到这些代码的人做需求分析

构建之法阶段小记五

本周学习了构建之法的第6.7章,在先前两人结对编程和团队开发流程的基础上对于软件项目有了更进一步的了解. 第6章以许多浅显的描述介绍了敏捷流程的一系列理论及其原则,最重要的即 找出完成产品需要做的事情.决定当前的冲刺需要解决的事情.冲刺及每日例会和最终发布版本给用户并在此基础上进一步计划增量的新功能和改进.开发过程中成员与外界的交流及成员自身注意力的集中往往会产生一定矛盾,在开发时团队成员一般不能直接被外部人士打扰,因而产生了"Scrum Master"这样的一个角色来进行成员及外界的

构建之法阶段小记四

转眼已是十一周,距离期末已很近了.加上有任务在手,渐渐地可能会忙起来,因而决定加快读书进度以期尽早完成基本内容的学习,在这样的环境下本周阅读了书中的第4.5章. 有句俗话说得好,众人拾柴火焰高.无论从事什么活动或者工作,多数情况下合作得到的结果都是1+1>2的.第4.5章就分别从两人的结对编程和大型的团队项目着眼介绍了软件的开发经历.软件开发的过程是复杂的,一个人单独开发一个软件的情形已经非常少见了.绝大多数的软件都是在相互合作中完成的,合作很大程度上实现了个体的优势互补,譬如有人擅长界面设计,

构建之法阶段小记三

本周已是学期的第十周,这周内通过书中第三章的介绍对如何成为一个合格的软件工程师及软件工程师在个体.团队中应具备的素养有了一些基本的了解. 软件开发流程不光是团队的流程,还包括个人开发流程.书中以足球队做类比,阐明了一个非常重要的概念就是--软件团队是由个人组成的,在团队的大流程中,是每一个具体的个人在做开发.测试.用户界面设计.管理.交流等工作.因此,个人能力的衡量与发展在团队合作中也非常重要,书中也介绍了几种比较妥当的个人评价标准. 软件工程师应该在不同阶段有以下几种成长:积累软件开发相关的知

构建之法阶段小记二

本周因几门课结课,加上参加了普通话水平测试,总的来讲有些忙碌.忙里偷闲,把上周看了少量的第二章作了补全,第三章也简简单单开了个头. 第二章中,仅凭简单朴实的文字,说来重点也不过几句寥寥,却让人了解到了软件开发中非常重要的几个环节:测试及能效分析.简单来讲,测试又分为几个模块.其中,单元测试又涵盖几个要求:好的单元测试应该在最基本的功能/参数上验证程序的正确性.必须由最熟悉的人(即代码作者)来写.单元测试过后,机器状态应保持不变,且测试要快,应该产生可重复.一致的结果.另外,单元测试的运行/通过/

《构建之法》第七八章读后感

读<构建之法>第七八章有感 今天我读了<构建之法>的第七八章,对MSF模型和开发模式,以及需求分析有了进一步的认识. 其中第七章主要讲了一些MSF方面的知识.MSF是微软公司关于软件开发的方法论——微软解决方案框架,是微软推荐的软件开发方法.而且MSF有自己的基本原则.1>推动信息共享与沟通,这就是说把所有信息保留并公开. 2>为共同的远景而工作,要做到这一点,就要确定一个明确的目标,并且这个目标对成员每天的工作有指导作用 3>充分授权和信任,这就要我们团队成员之

《构建之法》第七次随笔

这周,我学习了<构建之法>第十四十五章. 第十四章主要讲的是软件的质量. 软件质量等于程序质量加软件工程质量.程序的质量体现在软件外在功能的质量.衡量软件的功能,基本的判断可以用是.否来判定.软件的开发过程有三个主要的特性:好,便宜,快,通俗的理解是软件在功能,成本,实践三方面满足利益相关者的需求.软件工程的质量体现在几个方面:1.软件开发过程的可见性 2.软件开发过程的风险控制 3.软件内部模块,项目中间的交付质量,项目管理工具的因素 4.软件开发成本的控制 5.内部质量指标的完成情况.达成

构建之法第六七八章

第六章 敏捷流程 敏捷流程开发原则 1.尽早并持续的交付有价值的软件以满足顾客需求 2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 4.业务人员和开发人员在项目开发过程中应该每天共同工作 5.以有进取心的人为项目核心,充分支持信任他们 6.无论团队内外,面对面的交流始终是最有效的沟通方式 7.可用的软件是衡量项目进展的主要指标 8.敏捷流程应能保持可持续的发展.领导.团队和用户应该能按照目前的步骤持续合作下去 9.只有

构建之法(第七章 MSF)

第六章主要讲了 1.MSF的原则,MSF团队模型和开发模式,MSF和CMMI 2.各种软件工程原则的异同,如何在学生团队实施软件工程的原则 1.MSF的基本原则 1.1推动信息共享与沟通 所有信息都保留并公开,讨论要包括所有涉及的角色,决定要公开并告知所有人.当然,对牵涉到技术机密.安全性等信息要采取必要的把握措施. 使用Alert来提醒何事发生了变化:所有的信息都保留并公开,不能删除工作项. 1.2为共同的远景而工作 这个目标必须是明确的,没有二义性. 这个目标不是当前就能达到,必须是通过努力