软件工程——个人总结

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

1.学习和使用的新软件

•       Microsoft Visual Studio 2010
•       Microsoft SQL Server 2008
•       Dreamweaver CS5

2.学习和使用的新工具

•      HTML      
•     Coding  
•     asp.NET
•     Git

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

•      html
•      vs.net
•      C#
•      博客园
•      Coding代码管理

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

• 400以上

5.学习和掌握的新方法

• 网页制作
• 网站开发基本技术
• 数据库链接

总结与展望

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

• 理论与实践结合，平常需要多加练习
• 不懂的可以上网搜索，会有各种解答方法
• 管理好一个团队确实有一定的难度，团队之间的沟通很重要

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

• 学习不能马虎，课堂认真听讲，课后多加练习真的很重要
• 团队合作比一个人的努力有用的多，但做重要的是要有一个好的管理者
• 老师能传授的知识有限，但实际中要用到的不止那些，所以平常自己要通过网络多学习计算机其他技术。

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

• 萌芽阶段：一直讨论应该做一个怎样的网站，需要哪些技术，各有各的想法，很难统一
• 磨合阶段： 项目时间有限，不能一直僵持不下，大家有意见就提出来，通过交流沟通，得以确定项目原型。
• 规范阶段：项目原型既已定，通过各自擅长并感兴趣的技术，合理分配各自工作内容，大家开始各司其职。
• 创造阶段： 大家积极提出问题并讨论难题，将每一部分连接起来，齐心协力完成项目。

4.个性发挥，包括图文、照片和创意等

• 团队合作过程确实有一定的难度，从开始的意见分歧到最终的项目成功，大家都付出了很多，希望合作的小伙伴都能学业有成。
• 

个人总结的补充

• 请大家回顾我们软件工程第一次作业，通过本学期的学习，对第一次作业中的5个问题重新回答。

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

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

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

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

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

  二.第五章“团队和流程”第二节“软件团队的模式”中为我们介绍了十种模式，我看过之后也有了一定的了解并选择出了适合自己团队的团队模式，关于开发模式不    是特别了解，书中第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. 对于复审的结果，双方必须达成一致的意见。