扩大
缩小

欢迎来到李寻欢的博客

人生三从境界:昨夜西风凋碧树,独上高楼,望尽天涯路。 衣带渐宽终不悔,为伊消得人憔悴。 众里寻他千百度,蓦然回首,那人却在灯火阑珊处。

软工实践寒假作业(2/2)

这个作业属于哪个课程 2021春/S班
这个作业要求在哪里 软工实践寒假作业(2/2)
这个作业的目标 阅读《构建之法》提出5-10个问题,提出软工发展过程冷知识,编写WordCount程序,学习使用GitHub
作业正文 作业正文
其他参考文献 GitHub、CSDN、博客园

GitHub链接:https://github.com/lidaming1
项目链接:https://github.com/lidaming1/PersonalProject-C

任务一

阅读完《构建之法》提出的几个问题:

问题一:
第三章提到过早扩大化/泛化会使整个软件变得四不像最后只能让后人来完善,怎样才能避免陷入这种误区,又应该在什么阶段对软件进行扩大化/泛化,使得程序更加完善?
我认为扩大化的前提是软件所需的基本功能基本完善的时候才进行考虑的,避免过早扩大化就应该先立足于当前的工作,而非在软件刚开始时就想着对软件进行优化,运用更好的框架进行设计。
问题二:
第四章提到结对编程使用同一机器一同完成工作,那么应该如何根据各自的特长分配两个人的任务范围以取得更高的投入产出比?
有较高编程经验或管理经验的成员应该对任务的进程加以规划,为另一个队友提供相关的帮助。
问题三:
第五章中提到为解决瀑布模型的问题提出了生鱼片模型和大瀑布带着小瀑布模型,分别有什么优缺点,这两种模型分别适应与哪种开发场景?
大瀑布带着小瀑布模型:当子系统的所要求的的难度不同,任务相差较大时,有利于区别对待每个项目,分不同层次的投入,但各个解决步骤分离。
生鱼片模型:各个步骤关联度较高时更适用于生鱼片模型,解决各个步骤分离的缺点,但不如大瀑布带着小瀑布灵活。
问题四:
第六章中提到Scrum/Sprint能成功实施的关键在于Scrum Master,那么应该如何判断一个人能否胜任Scrum Master的工作?
scrum master是负责一个team按照scrum方式运行的角色。Scrum Master通过以身作则、尊重及对敏捷团队组织和效益的有效影响力来领导团队。Scrum Master也通过价值观、勇气、承诺及固执来引领团队。固执地拥有强烈的信仰、拥有强烈的改变组织的意愿。
问题五:
第九章介绍的PM对团队起着重要作用,但应该如何处理好与团队成员的关系,了解成员的状态,合理分配工作来提高项目的完成效率何工作质量?
PM要对小组成员以往承担的项目进行了解和分析,根据每个成员的能力和特长进行工作的分配,通过分析以前项目的进度和当前项目的进度来制定合适的工作目标,以免由于过多的任务导致成员的激愤。

软件工程发展的过程中有趣的冷知识和故事

1975年,艾伦和盖茨给Altair 8800计算机写了个BASIC解释器卖给MITS,他们很快完成了解释器,甚至包括自己的IO系统和编辑器,一共只需要4k内存。 不过最后他们发现还需要一个引导程序将这些东西从外存整进去。 Paul Allen在飞机航班上完成了这项工作。这是1975年,没有笔记本。他用的是纸笔。写的是8080机器码。(来源于知乎)

任务二

PSP表格

PSP2.1 Personal Software Process Stages 预估耗时(分钟) 实际耗时(分钟)
Planning 计划 20 20
• Estimate • 估计这个任务需要多少时间 790 890
Development 开发 690 790
• Analysis • 需求分析 (包括学习新技术) 40 60
• Design Spec • 生成设计文档 20 20
• Design Review • 设计复审 15 15
• Coding Standard • 代码规范 (为目前的开发制定合适的规范) 40 40
• Design • 具体设计 30 35
• Coding • 具体编码 450 500
• Code Review • 代码复审 35 40
• Test • 测试(自我测试,修改代码,提交修改) 60 80
Reporting 报告 80 100
• Test Repor • 测试报告 35 45
• Size Measurement • 计算工作量 15 15
• Postmortem & Process Improvement Plan • 事后总结, 并提出过程改进计划 30 40
合计 790 890

解题思路

需求分析

统计文件的字符数

这个功能十分简单,只需要逐个字符读取文本就可以统计了。

统计文件的单词总数

单词的定义在作业描述里面写的十分明确:至少以4个英文字母开头,跟上字母数字符号,单词以分隔符分割,不区分大小写,只需要按照定义把单词取出来从文本中统计即可。

统计文件的有效行数

有效行数的定义是包含非空白字符的行,这里的非空白字符指的是 ASCII 码:32~126,逐行读取文本之后再对每一行逐个字符判断即可。

统计文件中各单词的出现次数,最终只输出频率最高的10个,频率相同的单词,优先输出字典序靠前的单词。

在统计文件的单词总数的时候每当判断得到一个单词就先保存,之后再使用排序算法得到频率最高的10个单词。

计算模块接口的设计与实现过程

主要分为两个类,一个类为文件流的输入输出,有两个主要函数,另一个类为对文件数据的处理,有五个主要函数。
文件读取函数过滤掉ascll外的字符,计算字符数时直接获取数据流长度就可以。
计算行数时,每次读取一行,判断该行是否存在可视字符,若存在则有效行数加一。

        for (int i = 0; i < linesBuf.size(); i++)
	{
		for (string::iterator it = linesBuf[i].begin(); it != linesBuf[i].end(); it++)
		{
			if (*it >= 32&& *it <= 126)  //可打印字符(32~126)
			{
				lineCount++;
				break;
			}
		}
	}

在计算单词数时,可以同时将单词存到map中,以便在统计单词频率时使用。

统计频率前十单词数代码:

        int WordMapSize = int(WordMap.size());
	for (int i = 0; i < WordMapSize && i < 10; i++)
	{
		auto maxFreWord = WordMap.begin();
		for (map<string, int>::iterator it = WordMap.begin(); it != WordMap.end(); it++)
		{
			if (it->second > maxFreWord->second)
			{
				maxFreWord = it;
			}
		}
		Top10Word.push_back(maxFreWord);
		maxFreWord->second = -maxFreWord->second;
	}

单元测试

经过测试发现读取字符流函数所耗费的时间最长,这也是因为我为安字符读取,每个字符都进行判断处理,当文件数据较多时就会导致这个函数的耗时占比较高。

心路历程与收获

这次的作业总体上不难,大多是以前学过的知识,通过CSDN、博客园上的内容以及以前的程序复习后就有了较清晰的思路。由于以前用java就写过了类似的功能,于是就根据写过的程序修改成C++程序(当时想着好久没写过C++了就写一次)。虽然有着java程序的参照,但由于语言的不同也出现了很大的麻烦,由于该程序中需要注意的细节较多,因此在编写过程中也出现了较多的bug。由于整行读取一直会出现丢字符的情况(暂时也不知道是什么原因),于是我干脆就直接以字符形式读取文件进行字符串处理和存储,也方便过滤掉ascll码外的字符。
收获:这次的作业让我重新学习了C++,捡回了不少C++的相关知识,也让我知道我对C++的陌生,为我敲响了警钟。在出bug的时候与同学的讨论,与学长的讨论也让我学习了不少新的解题思路、对bug的排查与处理,在当局者迷的时候往往旁观者能更好的看出你的漏洞。学会了GitHub的基本使用,让注册了许久的账号开始工作。

posted @ 2021-02-28 18:30  mybky2021  阅读(117)  评论(2编辑  收藏  举报
Live2D