软件工程--个人总结

Posted 2020-09-24

回想开学初对于软件工程这门课的期望，总结本课程对你带来的提升：

1.学习和使用的新软件

（1） Microsoft Visual Studio 2010

（2）Microsoft SQL Server 2005

（3）Dreamweaver CS5

 

2.学习和使用的新工具

(1)html      

(2)Coding  

(3)VS2010

(4)Git

(5)C#

3.学习和掌握的新语言、新平台

(1)html

(2)Vs.net

(3)博客园

(4)Coding代码管理

 

4.统计一下，你在这软件工程实践中，完成了多少行的代码

   大概1500行以上吧.

5.学习和掌握的新方法

(1)学会使用.PowerDesigner完成数据库设计；

(2)学会许多HTML语言，完成一些界面设计。

(3)数据库链接。

(4)对网页制作有了更进一步的了解。

总结与展望

1.记录自己在软件工程课程上的经验总结

这次的团队开发对于我们组来说是比较成功的的，这取决于大家团结合作，有事一起干的这种团队合作意识，虽然作业最后做出来无论是功能还是老师的满意度都不是很理想，但是我们团队感觉还好，而且也对我们的这份项目的后续也是寄予很大的期望。做这份作业大家花了很大的心血。因为底子薄，所以说最开始的时候，花了过多的时间在学习各方面的知识上，因为对于我们来说基本上都是0基础，像C#，ASP.net，还有CSS3,以前从来都没有接触到过，像HTML和VS还好，因为毕竟我们有过接触和学习，学起来不是那么的吃力。后期开发软件的时候，查了很多资料，而且查的这些资料也很抽象，不懂，而且听说有人已经完成作业，而自己一筹莫展的时候是比较毛糙的。但是我个人觉得，我们还是从中学到了不少的东西，我觉得我们之间的团队关系沟通还是不错的，还有就是比如像ASP.net等后端语言的学习，从中获取到了不少的东西。还有最后一点就是，一个好的团队对你完成这个项目是至关重要的。

2.对于下一届的学弟学妹你有什么建议和告知呢？

自己做的不是很好，所以也没有什么告诫的，最主要就是认定一件事情的时候就定下心去做吧，最后结果不重要，享受这其中自己付出过的努力而，还有已经做到某种程度的成就感就好。

3.分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》团队合作的阶段，你们团队经历过么？最后到达了哪一阶段？

(1)萌芽阶段：一直讨论应该做一个怎样的网站，需要哪些技术，各有各的想法，很难统一

(2)磨合阶段： 项目时间有限，不能一直僵持不下，大家有意见就提出来，通过交流沟通，得以确定项目原型。

(3)规范阶段：项目原型既已定，通过各自擅长并感兴趣的技术，合理分配各自工作内容，大家开始各司其职。

(4)创造阶段： 大家积极提出问题并讨论难题，将每一部分连接起来，齐心协力完成项目。

个人总结的补充

第一，如果我们要开发一个软件，如何准确捕捉用户的需求是我们第一步要做的事情，怎么事前调查客户需求，精准了解客户对我们的要求和我们目前的技术能否实现他们的需求是很重要的一步。书中第八章“需求分析”中第三节“获取用户需求--用户调研”的第四点“用户调查问卷”调研方法中列出了调查者一些常见的错误，但我对于书中给出的解决方式还是有困惑：

首先，关于全开放式问题，这个问题的答案五花八门，有很多不靠谱的回答，在后期处理过程中费时费力，虽然我们要尽量满足客户需求，做到最好，但有时候也会能力有限。

 第二，就是二项选择题，这个问题就是客户只能在两种选择对比中只能选其一，但是我们根据这个结果做出的产品无法胜于其他产品，因为我们对客户的需求了解的不够深入。

   以上两点问题之间有些矛盾，那么我们应该如何取得一个中立的方法来捕捉用户的需求呢？需要老师为我们讲解经验和建议。

答：关于调查客户需求，我们可以选择一个合适自己产品的方式来了解客户对我们的要求，有时候，我们也可以进行多种方式捕捉用户需求，然后进行各方面的综合考量，以此开发出既能满足用户需求又有创新的产品。

二.第五章“团队和流程”第二节“软件团队的模式”中为我们介绍了十种模式，我看过之后也有了一定的了解并选择出了适合自己团队的团队模式，关于开发模式不    是特别了解，书中第102页的课后题中也提到了，团队模式和团队的开发模式有什么关系？所以在这里想请教一下老师，团队的开发模式与团队模式有何关        系？

答：软件团队的模式包括以下几种：

（1）主治医师模式：一人为主，其他人为此人服务。

（2）明星模式：主治医师模式到达极致，一人的光芒掩盖所有人。

（3）社区模式：每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。

（4）业余剧团模式：在不同项目中每个人扮演着不同的角色，可能随着项目的改变，自己的角色也会发生变化。

（5）秘密团队模式：一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。

（6）特工团队模式：有一些有特殊技能的专业人士组成的团队。

（7）交响乐团模式：人员工具齐全，准备充足的团队。

（8）爵士乐模式：相对自由，有风险，人少且不靠谱。

（9）功能团队模式：具备不同能力的同事们平等协作，共同完成一个功能。

（10）官僚模式：层层领导的团队模式。

团队的开发模式包括以下几种：

（1）写了再改模式：和一窝蜂团队模式比较像。

（2）瀑布模型及其各种变形。

（3）RUP统一流程。

（4）老板驱动的流程。

（5）渐进交付的流程。

（6）TSP的原则。

至于团队模式和团队的开发模式的关系，我的理解是一群人在一起做软件开发，总是要一些方式方法。而这里团队模式就是这一群人的定性，团队的开发模式则是这群人使用的方法的定性。

三.第六章“敏捷流程”第五节“敏捷的问答”（书116页）中提到敏捷的方法论有三种，分别是FDD-Feature Driven Design,SCRUM以及XP，那么这三种方法论具       体是怎样的呢?我们是否可以把他们放到实践中呢？它们是否是最佳的实践方法呢？它们是分别适用于怎样的情况呢？

答：FDD是一个模型驱动( model-driven)、短期遍历(short-iteration)的过程. 注意，FDD是一个开发过程，过程总是有起点和终点，FDD的起点是起源于创建一个全局的模型轮廓（不要求很精确，大概模样就可以），然后大概是两周的一系列的"design by feature, build by feature"的迭代，逐渐丰富模型功能内容，features是指小的、以软件用户的视角看是有用的特征功能。

     Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums.

     极限编程（Extreme Programming，XP）是一门针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。它是以符合客户需要的软件为目标而产生的一种方法论，XP使开发者能够更有效的响应客户的需求变化，哪怕是在软件生命周期的后期。它强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接。关于是否是最佳的实践方法，主要还是看实践内容。

四.还是想问一下老师关于第六节练习与讨论中提出的第一个问题“什么时候适合选择敏捷？”我在书中看到，他说敏捷对团队的要求很简单，但是团队项目各式各     样，就算团队为了要变成敏捷流程，做出了敏捷对团队的要求，但是敏捷也不是万能的，它还是有它最适用的范围，那么这个范围是那些？我们什么时候选择     敏捷呢？

答：敏捷过程的适用范围 软件需求经常变化或者需求变化比较大； 项目团队与用户之间进行沟通比较容易； 项目的开发风险比较高； 规模比较小，一般项目组成员在50 人之内； 项目团队的成员能力比较强，而且具有责任感； 项目的可测试性比较好。

五.我看了第13章“软件测试”，这一章中列举了许多种不同种类的测试方法。看过课本之后，我们知道，在软件测试阶段，可能遇到的问题可能比开发过程中遇到的问题还要多，在这么多的测试方法中，我们应该如何选择最合适的测试方法，为了确保产品质量，我们是否应该选择尽可能多的测试方法进行测试？怎么处理好在测试阶段中的问题，怎么运用不同的测试方法进行测试，需要老师为我们指导和讲解。

答：在测试项目之初就要制定相应的测试计划。接下来是如何编写测试计划问题。首先了解以下几个问题：

1． 为什么要编写测试计划？
      1）领导能够根据测试计划做宏观调控，进行相应资源配置等；
      2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；
      3）便于其他人员了解测试人员的工作内容，进行有关配合工作

2． 什么时间开始编写测试计划？
    （测试需求分析前总体测试计划书/测试需求分析后详细测试计划书）

3． 由谁来编写测试计划？
      具有丰富经验的项目测试负责人

4． 测试计划编写6要素？（5W1H）
     1）why——为什么要进行这些测试；
     2) what—测试哪些方面，不同阶段的工作内容；
     3) when—测试不同阶段的起止时间；
    4) where—相应文档，缺陷的存放位置，测试环境等；
    5) who—项目有关人员组成，安排哪些测试人员进行测试
    6) how—如何去做，使用哪些测试工具以及测试方法进行测试。

六.我看了第四章“两人合作”的第四节“代码复审”，关于代码应该如何进行复审这一问题，我还是不太懂。复审过程中牵涉的人员众多，理解度不一等等各类问题，我们应该怎样做才能更有效的进行复审呢？

答：在复审前 ：

1. 代码必须成功地编译，在所有要求的平台上，同时要编译 Debug | Retail 版本。编译要用团队规定的最严格的编译警告等级。

2. 程序员必须测试过代码。什么叫测试过？最好的方法是在调试器中单步执行。

3. 程序员必须提供新的代码，以及文件差异分析工具。

4. 复审者可以选择面对面的复审、独立复审或其他方式。

5. 在面对面的复审中，一般是开发者控制流程，讲述修改的前因后果。但是复审者有权在任何时候打断叙述，提出自己的意见。

6. 复审者必须逐一提供反馈意见。注意，复审者有权提出很多看似吹毛求疵的问 题，复审者不必每一件事都要亲自调查，开发者有义务给出详尽的回答。

7. 开发者必须负责让所有的问题都得到满意的解释或解答，或者在 TFS 中创建新的工作项以确保这些问题会得到处理。

8. 对于复审的结果，双方必须达成一致的意见。

1） 打回去 — 复审发现致命问题，这些问题在解决之前不能签入代码；

2） 有条件地同意 — 发现了一些小问题，在这些问题得到解决或记录之后，代码可以签入，不需要再次复审；

3） 放行 — 代码可以不加新的改动，签入源码控制服务器。要注意避免不必要的繁文缛节，我们做代码复审的目的是为了减少错误的发生，而不是找一个人来对着你的代码点头。一些简单的修改不是非得要一个复审者来走一遍形式。在项目开发的早期斤斤计较于一些细枝末节（例如：帮助文件里的拼写错误，数据文件格式不够最优化等）也是于大局无补的，但是，这些问题并不是不用处理了，我们可以建立一些优先级较低的工作项来跟踪处理。