个人学期总结
个人学期总结
一、对第一次实验拟定的五个问题的回答如下：
1.什么是软件危机，为什么产生软件危机？
答：软件危机：落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。
产生软件危机的原因主要有两个方面：
（1）与软件本身的特点有关。软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件；软件样品即是产品，试制过程也就是生产过程；软件不会因使用时间过长而“老化”或“用坏”；软件具有可运行的行为特性，在写出程序代码并在计算机上试运行之前，软件开发过偶成的进展情况较难衡量，软件质量也较难评价，因此管理和控制软件开发过程十分困难；软件质量不是根据大量制造的相同实体的质量来度量，而是与每一个组成部分的不同实体的质量紧密相关，因此，在运行时所出现的软件错误几乎都是在开发时期就存在而一直未被发现的，改正这类错误通常意味着改正或修改原来的设计，这就在客观上使得软件维护远比硬件维护困难；软件是一种信息产品，具有可延展性，与通用性强的硬件相比，软件更具有多样化的特点，更加接近人们的应用问题。
（2）来自于软件开发人员的弱点。其一，软件产品是人的思维结果，因此软件生产水平最终在相当程度上取决于软件人员的教育、训练和经验的积累；其二，对于大型软件往往需要许多人开发合作，甚至要求软件开发人员深入应用领域的问题研究，这样就需要在用户与软件人员之间以及软件开发人员之间相互通讯，在此过程中难免发生理解的差异，从而导致后续错误的设计或实现，而要消除这些误解和错误往往需要付出巨大的代价；其三，由于计算机技术和应用发展迅速，知识更新加快，软件开发人员经常处在变化之中，不仅需要适应硬件更新的变化，而且还要涉及日益扩大的应用领域问题研究；软件开发人员所进行的每一项软件开发几乎都必须调整自身的知识结构以适应新的问题求解的需要，而这种调整是人所固有的学习行为，难以用工具来代替。
2.在设计人机界面设计的时候，如何考虑用户的使用因素，做到客户满意？
答：人机界面设计做到让客户满意，一般地可从信息、可交互性、数据输入、显示等方面考虑，：（1）保证信息显示方式与数据输入方式的协调一致，尽量减少用户输入的动作!隐藏当前状态下不可选用的命令，允许用户自选输入方式!能够删除无现实意义的输入，允许用户控制交互过程。 （2）对所有可能造成损害的动作!坚持要求用户确认，例如提问“你确定......”等，对大多数动作应允许恢复，对用户出错采取宽容的态度。 （3）在同一用户界面中，所有的命令输入、数据显示、菜单选择和其他功能应保持风格的一致性，风格一致的人机界面会给人一种和谐、简洁的美感。 （4）合理划分并高效使用显示屏。仅显示与上下文有关的信息，允许用户对可视环境进行维护，如放大、缩小图像，用窗口分隔不同种类的信息，只显示有意义的出错信息!避免因数据过于费解造成用户烦恼。 （5）人机界面应该提供上下文敏感的求助系统!让用户及时获得帮助!尽量用简短的动词和动词短语提示命令。 （6）用户界面应能对用户的决定做出及时的响应，提高思考、移动和对话的效率。最大可能的缩短鼠标移动距离，减少击键次数，避免使用户产生无所适从的感觉。
3.软件生命周期至少应分为哪几个时期，细分的话又分几个阶段？
答：软件生命周期至少应分为三个时期：软件定义、软件开发、软件维护。细分的话又分八个阶段：问题定义、可行性研究（可行性研究报告）、需求分析（软件需求规格说明书）、概要设计、详细设计、编码和单元测试、综合测试、运行维护
4.软件需求的是什么？获取的方法有哪些呢？
答：在IEEE软件工程标准词汇表（1997年）中定义软件需求为：（1）用户解决问题或达到目标所需的条件或能力。（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式 一般为文档形式。
获取方法有：（1）用户访谈 （2）用户调查 （3）现场观摩 （4）文档考古 （5）建立联合分析小组 （6）原型法 （7）模型驱动 （8）基于上下文的方法
5.软件开发的早期，可行性研究很重要吗，要从哪些方面来研究？
答： 可行性研究很重要也很有必要。进行可行性研究的目的是用最小的代价确定在问题定义阶段确定的系统目标和规模是否可实现，所确定的问题是否可以解决，该系统方案在经济上，技术上，使用上，法律上是否可以接受，不是解决问题，而是确定问题是否值得解决。
要从以下几个方面来研究： （1）.技术可行性：使用现有技术是否能实现该系统 。 （2）.经济可行性：系统的经济效益是否超过它的开发成本。 （3）.操作可行性：系统的操作方式是否能在该用户组织中可行。
二、完成课程的实践总结和给你带来的提升，包括以下内容：
1、统计你在软工课程实践中，完成了多少行的代码；
经过一学期的学习，完成了一万五左右。
2、软工实践的各次作业分别花了多少时间？累计花了多少个小时在软工实践上？平均每周花多少个小时？（做一个列表）
| 作业次数 | 实践时间/h | 平均 每周(十六周)所花时间/h |
| 第一次 | 3.5 | 7.375 |
| 第二次 | 4 | 7.375 |
| 第三次 | 7 | 7.375 |
| 第四次 | 8 | 7.375 |
| 第五次 | 7 | 7.375 |
| 第六次 | 8 | 7.375 |
| 第七次 | 9 | 7.375 |
| 第八次 | 7 | 7.375 |
| 第九次 | 8 | 7.375 |
| 第十次 | 8 | 7.375 |
| 第十一次 | 10 | 7.375 |
| 第十二次 | 9 | 7.375 |
3、哪一次作业让你印象最深刻？为什么？
最后一次的作业让我印象深刻，因为在那次作业我们团队总结完善高了所有的任务，系统也成功的做出来了，对以后的学习奠定了基础。
4、学习和使用的新工具：WBS工具、墨刀。
三、你认为目前的课程有哪些问题，你有什么更好的建议：
1、你认为本门课程需要在哪里进行改进，具体措施有哪些，包括：时间进度安排，项目难度等均可；
我认为没有什么改进的，作业任务以及时间都安排的合理，能和我们的学习紧紧地连接起来。
2、你认为助教／老师哪里做的不足，哪里限制太多等；
老师的安排合理。
3、你认为每次项目的评分标准存在哪些问题，你认为的合理评分准则是怎样的（个人／结对／团队算三个）
评分标准也合理，公平。
4、在结对项目中你是否真正体会到了结对的好处，是否真正严格进行了结对编程，双方的工作量是否相同；
体会到了结对对于我们的学习有很大的帮助，最重要的就是我们可以互帮互助，发现不足，共同学习。严格的进行了结对编程，工作量基本相同。
5、你的团队项目是否成功，如果重来一次你是否还会选择这个团队，为什么成功／失败；
我们团队是成功的，我们都很努力，如果重来一次我还会选择这个团队，因为我们都配合的很好，相互帮助，相互学习，共同进步。
6、总结一下你们团队在做项目时大家的时间安排情况。
每次作业团队中的每个组员都按时完成。
7、对下一届软工课实践教学的建议，或者对于开学初的你，对于大一的你，对于开学初的老师，你有什么想建议和告知的呢？对于后来人的期许。
努力努力再努力，不逼自己一下，就不会发现自己原来可以做的更好。
四、你还有什么想说得话
越努力越幸运。
