软工第一次作业

项目 内容
本次作业所属课程 2020春季计算机学院软件工程(罗杰 任健)
本次作业要求 个人博客作业
我在本课程的目标 学有所用,学以致用
本次作业的帮助 阅读教材,对课程内容有了全面粗略的了解

一.快速看完整部教材,列出你仍然不懂的5到10个问题

  • 问题1
    原文出处:2.1.2 好的单元测试标准
    这里作者给出了7条非常好的单元测试标准,但是在实际测试中,软件各色各样,难免会有其中两条标准之间无法很好的平衡。例如,一个庞大的软件工程,一方面要追求测试的全面行,一方面又要保障测试的速度,那么两者之间如何权衡。

  • 问题2
    原文出处:我还建议,把所有开发过程的附加物件,像设计文档,都扔掉······SCRUM依赖于团队人员面对面,高容量的交流和合作;每个人独立的小隔间,没有必要的文档都增加了疏离和误解的可能性。
    其中本书作者提到了如果团队成员在不同时区工作,就需要文档等辅助手段来达到敏捷的目的,但是敏捷原则中提到了“每天共同工作”,“保持简明,简化工作量”。我认为为了尽早并且持续的交付软件,文档的存在是会延误工程的推进的,撰写过程和阅读过程都是耗费时间的。这与敏捷原则相悖,所以我还是认为文档是不应当存在于敏捷流程的,而这种无法共同工作的成员也是不应当存在的。否则这种团队与非敏捷流程的区别又在哪里呢?

  • 问题3
    原文出处:16.1.2 迷思之二 大家都喜欢创新
    作者给出了与标题相反的观点,在看完之后,我茅塞顿开。回想从古至今,几乎各行各业,从皇帝到百姓,在创新时都会有触及到部分人了利益,想要让自己的创新得以实现,就要付出惨痛的代价。换而言之,大家不是都喜欢创新,而是喜欢能够对自己有利的创新。难道创新真的敌不过在前人基础上的线性扩展吗?
    在查找资料后发现,这个时代,想要在某些领域有突破性的进展几乎时不可能的,创新和改良已经逐渐同化,所有的创新几乎都是在巨人的肩膀上迈出的小小一步。

  • 问题4
    原文出处:16.1.4 迷思之四 创新者都是一马当先。
    作者告诉我们几乎所有的先行者都葬身在了自己所探索的那片大海里,那还会有人愿意去进行创新吗?
    虽然创新的代价巨大,但不是说创新者永远都成不了领导者,创新者不但要有创新的勇气,更要有能沉下心好好观察的耐心,成功者不单单是靠着一腔热血。

  • 问题5
    原文出处:16.1.7 迷思之七 成功的团队更能创新。
    作者告诉我们成功的团队需要满足董事会的需求,要不断的提升自己的业绩,但是身为行业的领导者,他们不会轻易的去冒险创新,将自己置于极大的不确定之中。那么成功的公司四如何在两者之间进行权衡。
    成功的团队在看到机会时不会大脑发热就冲上去,而时在等其他团队厮杀完之后将潜力股收购,这样时风险最小的,也是成功团队在风险和收益中权衡的办法。

二.请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人?

  • 软件
    1953年Richard R.Carhart在备忘录中首次使用软件(software)一词,在1958年美国数学家Tukey发表的论文“The Teaching of Concrete Mathematics”中最早发表。
  • 软件工程
    1968年北大西洋公约组织在前联邦德国着急了近50名一六的编程人员、计算机科学家和工业界巨头,讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程(software engineering)这个概念。数学与电脑科学先锋- Margaret Hamilton在阿波罗登月计划期间首次提出“软件工程”一词。

三.【附加题】:大家知道了软件和软件工程的起源,请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事?

第一款数字化电脑游戏从未带来任何利润回报

现在的视频游戏已经成为了最受瞩目的程序开发成果,然而历史上第一款数字计算机游戏则遭遇巨大失败。第一个电脑游戏出现于1962年,由麻省理工学院的计算机程序员Steve Russell与其团队一同编写,这款名为《太空大战》的游戏耗费了他们近200个小时。该游戏允许两名玩家分别控制两艘飞船,目标是击中并摧毁对方飞船,并且玩家还需要躲避屏幕中代表星球的小白点。如果玩家撞上这些星球,则游戏失败。虽然Russell和他的团队从未在这个游戏说的任何收益,但必须承认如果没有这一突破我们可能永远不会拥有如今蓬勃发展的视频游戏产业。

四.上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些, 各有什么优缺点?

0.github ----->最流行

Git是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理.有着巨大的使用人群,资料多。
Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

1.CVS --------〉开源奇葩

CVS是开发源代码的配置管理工具,其源代码和安装文件都可以免费下载。
CVS是源于unix的版本控制工具,对于CVS的安装和使用最好对unix的系统有所了解能更容易学习,CVS的服务器管理需要进行各种命令行操作。目前,CVS的客户端有winCVS的图形化界面,服务器端也有CVSNT的版本,易用性正在提高。

2.SVN --------〉中坚级

SVN与CVS一样,是一个跨平台的软件,支持大多数常见的操作系统。作为一个开源的版本控制系统,Subversion 管理着随时间改变的数据。 这些数据放置在一个中央资料档案库中。 这个档案库很像一个普通的文件服务器, 不过它会记住每一次文件的变动。 这样你就可以把档案恢复到旧的版本, 或是浏览文件的变动历史。Subversion 是一个通用的系统, 可用来管理任何类型的文件, 其中包括了程序源码。

3.Visual SourceSafe --------〉元老级

VSS是美国微软公司的产品,目前常用的版本为6.0版。VSS是配置管理的一种很好的入门级的工具。
易学易用是VSS的强项,VSS采用标准的windows操作界面,只要对微软的产品熟悉,就能很快上手。VSS的安装和配置非常简单,对于该产品,不需要外部的培训。只要参考微软完备的随机文档,就可以很快的用到实际的工程当中。
缺点是VSS不能提供对异地团队开发的支持,安全性不高。

4.StarTeam --------〉元老级

StarTeam是Borland公司的配置管理工具,StarTeam属于高端的工具,在易用性,功能和安全性等方面都很不错。
StarTeam的用户界面同VSS的类似,它的所有的操作都可通过图形用户界面来完成,同时,对于习惯使用命令方式的用户,StarTeam也提供命令集进行支持。StarTeam的随机文档也非常详细,同时有独立的安全管理机制。

五、软件实践部分

  • git
  • github

    -使用看法
    在之前的很多次科目都使用到了这两个工具,给我的计算机学习带来了很多方便。
原文地址:https://www.cnblogs.com/ybwnb/p/12420302.html