构建之法 随笔

软件需求分析在软件开发过程中十分重要,过去人们一直认为需求分析是整个软件工程中的一个简单的步骤,“软件危机” 爆发之后,人们才逐渐认识到需求分析是软件开发过程中最关键的一个工程。由此可见需求分析的重要性。很多时候用户并不知道自己确切的需求,或者不愿意表达完整的需求,软件团队需要设身处地,替用户着想,引导出需求。听说过一句话,如果你不了解事物本身,你一定做不好(软件)。我很赞同作者的这个说法,让大学生暂时放下自己所学的许多高端技术,走到真实的世界中去,也许会看到并理解来自普通用户的真实需求。我们首先要知道并且很了解用户所说的是什么,才能懂得需求。

软件需求分析起初是获取和引导需求,软件团队找到软件的利益相关者,了解和挖掘他们对软件的需求,引导他们表达出真正的需求。然后分析和定义需求,对从各个方面获得的需求进行规整,定义需求的内涵,从各个角度将需求量化。然后验证需求,最后在软件产品生命周期中管理需求。

时间: 2024-10-05 04:45:35

构建之法 随笔的相关文章

构建之法随笔

1: 结对开发如同人+项目+人的三明治模型.团队开发有很多模式,各模式有其独特的优势,但也有其固有的缺陷,有没有其他较合适的开发模式适用于整个软件的开发过程?抑或是综合多种模式在不同阶段采用不同的软件团队模式,取长补短? 2:敏捷开发类似于先实现一个“饼”的基本轮廓,然后根据优先级依次补充,最终完成一个“饼”的制作过程,其开发过程中,小幅度的改来改去和现状的设计师的改来改去有什么不同?如果一样,为什么要采用敏捷开发? 3:项目经理的作用既然是对一个项目的资源进行分配进而减少成本支出,那么对于一个

《构建之法》第三次随笔

从<构建之法>前两章的阅读学习中,我了解到了软件工程的概论,知道了"软件=程序+软件工程",明白了个人技术和流程.阅读了第三章之后,我体会到了软件工程师的成长. 软件工程包括了开发.运营.维护软件的过程中的很多技术.做法.习惯和思想.软件开发流程不光指团队的流程,还包括个人开发流程,因为软件团队是由个人组成的,个人在团队中也有独立的流程.软件团队和团队中的工程师也是这样,软件系统的绝大部分模块都是由个人开发或维护的,在软件工程的术语中,我们把这些单个的成员叫做Individ

《构建之法》第一章读后随笔

<构建之法>第一章首先提出了“软件=程序+软件工程”的观点,然后介绍了软件开发的不同阶段,最后阐述了软件工程是什么的问题.这让我对软件工程有了新的认识,也对构建之法的重要性有了更为深刻的理解. 其实很多工科的很多道理都是相通的.不光是在软件工程,几乎的所有工程中,当工程规模到达了一定的数量级,就不可能是由一个人的一己之力能够完成的,这就需要相互协作,每个人只能做自己的一部分工作.如何能够让别人理解自己的工作的作用,如何能让每个人的工作都能融入一个系统,这就需要模块化,需要集成,话句话说,就是需

《构建之法》第七次随笔

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

读《构建之法》的第一次随笔

在收到纸质书籍到手之前,我简单的看了一些多看阅读上的试读章节.第一章开始便以程序猿们编程遇到的各种问题引出了软件工程的重要性.在一个工程的进展过程中,各种的不确定性因素会以多种不同的方式阻碍项目的正常运转,例如,软件的质量提升,特殊需求的引入,文档.流程和工具的正确性等都会蚕食项目的工期和质量.如果不加以控制和规范化,越是大型的项目,导致失败潜在的危机越是巨大. 根据多年的工作经验学习以及前人留下的案例,作者邹欣老师也总结了程序(算法.数据结构)是基本功,但在算法和数据之上,软件工程决定了软件的

《构建之法》第四次随笔

这半个月我阅读了<构建之法>第六章,第七章,第八章. 第六章主要讲的是敏捷流程.敏捷流程是一系列价值观和方法论的集合.敏捷对团队的要求很简单:自主管理,自我组织,多功能型.但是这很困难,如果团队要变成敏捷流程,要做这些改变.多次总结改进才能使团队走上正轨. 敏捷实质是一股思潮,或者说是一种价值观,它涵盖了好几种软件开发的方法论,这些方法论又是建立在许多行之有效的最佳实践方法之上的.. 第七章讲的是MSF--微软解决方案框架,也就是微软推荐的软件开发方法.MSF有一套思想框架--9条基本原则.

《构建之法》随笔一

我是上海海洋大学的一名学生,就读于信息学院的软件工程专业.在翻开这本书之前,我对这个专业一直是很模糊的概念.除了学校的小学期,也没有契机,能让我去编写一个小程序,对于一些编程技巧和方法还是比较陌生. 所以,在这个周末,我学习了<构建之法>的第一章.一开始我以为是很枯燥的教科书类的题材,只有系统的代码教学之类的内容,但是翻了几页后,竟然出乎我的意料,编者的语言相当幽默有趣,引人入胜.于是,我津津有味的读了下去. "软件=程序+软件工程"这句名言,几乎所有的程序员都知道,但是大

邹欣老师的《构建之法》第一章“概论”学习笔记与自我随笔

刚读完了邹欣老师的<构建之法>第一章“概论”,四个字形容:酣畅淋漓. 概论将自己的一些模糊的认识清晰化,用准确的文字描述了出来,填补了脑海里的一些灰色地带. 总结一下:概论通俗地阐述了编程.软件.计算机科学.软件工程的联系与区别,简单说,编程是一项具体动作,软件是供人使用的产品,具体有很多种类型,而计算机科学是偏向理论研究,软件工程就像其他工程学一样,是在一定条件下合理配置资源达到生产软件的目的. 本人作为一名从小对编程.软件.计算机感兴趣的Nerd,虽然大学专业与此无关,但刚毕业时签了一份软

随笔之读《构建之法》(作业一)

自从拜读了邹欣老师的力作<构建之法>后,感触颇深.从书中不难看出邹老师是一个才华横溢.卓尔不群的人.<构建之法>言辞精辟,引人入胜.虽然只是浅读了<构建之法>的部分章节,但是对其中的一些内容我也有自己的看法,在这里和大家分享我的5个问题. ①邹老师用航空飞机举例子,这个真的恰当吗?我认为提出给为恰当的例子更好,只是我才疏学浅,实在想不出还有什么更好的例子.我曾经参加过学校的辩论队,我是二辩选手.在辩论赛比赛的过程中,我经常举一些例子来反驳对手,但是很多时候所举的例子不是