| 软件工程 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1 |
|---|---|
|
作业要求 |
https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1/homework/10863 |
| 团队名称 | 可可爱爱没有脑袋 |
| 作业的目标 | 团队作业事后总结 |
| 作业正文 | 如下 |
| 其他参考文献 | 百度 |
团队成员
| 学号 | 姓名 | 博客地址 |
| 20177703 | 罗剪梅 | https://www.cnblogs.com/sweetsecret |
| 20177697 | 许思慧 | https://www.cnblogs.com/mao-liu/ |
| 20177730 | 袁瑞 | https://www.cnblogs.com/Iwannseeyouagain |
| 20177702 | 周海涛 | https://www.cnblogs.com/zht6 |
| 20177704 | 陈怡涛 | https://www.cnblogs.com/chenyitao/ |
| 20177657 | 刘智鑫 | https://www.cnblogs.com/liuzhixin599445/ |
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们软件要解决的是针对在校学生寻找和联系摄影师的问题。定义还算清楚。对典型用户和典型场景有清晰的描述。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
基本达到了目标。原计划功能做到了七个，新增功能五个。按照原计划交付时间交付。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
团队软件工程的质量提高了，上一阶段我们主要是注重代码的编写，这个阶段更加注重界面的设计，和数据的采集设计。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户对重要功能的接受程度一般，与我们事先预想的有出入，还有待提高界面的美观。离目标更近了。
计划
1. 是否有充足的时间来做计划?
是的，我们有大量的时间来做计划，但我们的计划不够完整。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们进行投票的方式，采取少数服从多数的原则。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有做完，因为前期在做计划时没有考虑到后期的代码实现，所以在很多地方都没有实现。
4.有没有发现你做了一些事后看来没必要或没多大价值的事?
有，有时候会跟队员讨论一些设想，但是在后面实现的时候又觉得不行。
5. 是否每一项任务都有清楚定义和衡量的交付件?
很多地方都没有，我们在确定任务时不知道什么情况才算最好，对于部分的任务有清楚的定义，但是没有衡量的交付件。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目并没有按照计划进行，由于前期的考虑欠佳，我们项目的很多功能由于我们能力有限没有做出来。比如摄影师模块的功能，我们前期查找的资料太少，没有想到这部分功能的难点。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
有缓冲区，原来认为没有必要，后来发现还是有用的。主要是各人进度不一，有些模块不断地有一些小问题，队员之间的意见有时也不相同。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
在项目开始前查找到足够的资料，确定好哪些功能我们能实现。
资源
1. 我们有足够的资源来完成各项任务么?
没有，在配置运行环境跟连接数据库是花了太多的时间。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
项目跟其他资源我们大概的估计了一下，随着时间的推移，我们就不怎么关注这一块。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
足够。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
有时候会感觉，觉得自己的能力有限，很多事很吃力，也许其他的队友来做会更有效率。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
是的，当项目做出调整后我们都会在群里发布消息。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们以能简则简的方式决定。先把最主要的列出来确定为”必须实现“的功能，再把无关紧要的设为”推迟“功能。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
没有，我们一般是把某个功能块实现了就叫“做好了”。
4. 对于可能的变更是否能制定应急计划?
没有，因为人本来就不多，一般哪里出了问题就团队的两个主力来解决。
5. 员工是否能够有效地处理意料之外的工作请求？
一般都可以，团队队员接受能力都蛮强的。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作是在学期中下旬的时候，大家一起分工完成的，是合适的时间，但不一定是合适的人选。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
设计时我们经常会出现某个小型的功能到底要不要实现，一般我们是经过讨论后，考虑它是不是必要的功能，如果是不必要功能则舍弃。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
运用了单元测试、UML工具。工具很有效，作用很大。项目开始的UML文档相较于现在的状态少了一些管理员的部分，现在的状态也有部分功能没有实现而在UML文档中有。区别的产生主要还是因为在开发过程中忽视了UML文档的重要性。需要更新UML文档。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
管理员界面的输入框产生的bug最多。代码问题。当开始传不进数据，后面发现输入框联动展示历史输入，总是不对，会有其他输入框的历史记录。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们代码复审进行的是结对编程方法。严格执行了代码规范。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
有，但计划目前还只进行到一半的阶段。
2. 是否进行了正式的验收测试？
是。验收测试，还有一些验收标准还没修改。
3. 团队是否有测试工具来帮助测试？
有，Junit和手动测试。
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
目前还没进行到这一步。
5. 在发布的过程中发现了哪些意外问题？
目前还没有。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
角色的分工是每个组员根据自身能力情况来进行分工，每个人各司其职。
2. 团队成员之间有互相帮助么？
经常互帮互助，我们团队的每个人能力都略显薄弱，很多时候靠自己完成不了，一般需要团队帮忙一起完成。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
一般出现分歧时，都是通过团队内部进行探讨，然后进行投票选择谁的方案或想法。
4.每个成员明确公开地表示对成员帮助的感谢
许思慧
感谢 ______罗剪梅、魏博硕______对我的帮助，
因为某个具体的事情:
罗剪梅，经常一起写博客园，也帮忙上传GitHub 。
魏博硕，很多编码上不懂的问题都是魏博硕帮忙解答的。
袁瑞
感谢 ______罗剪梅、许思慧_____对我的帮助，
因为某个具体的事情:
罗剪梅帮我检查代码的错误，教会我如何在gitub上面迁入代码。
许思慧在我想要放弃的时候，鼓励我帮助我，我们一起完成博客园上面的作业，一起完成代码和各种文档的编写。
非常感谢他们对我的帮助，如果没有她们，我自己的任务可能就无法完成 。在此，致以我最诚挚的感谢。
罗剪梅
感谢 许思慧、魏博硕 对我的帮助，
因为某个具体的事情:
许思慧在项目最开始直到项目快结束的时候，每当我有问题解决不了时都会去找她给意见，在设计界面时也给我提出来很多的建议。
魏博硕在我们项目后期编写代码时给出了很多的建议，还帮助我们解决了很多环境配置的问题。
周海涛
感谢 ______罗剪梅、许思慧、袁瑞、陈怡涛_____对我的帮助，
因为某个具体的事情:
对罗剪梅后端代码和部分前端界面设计、UI界面设计的风格的提出对我代码的设计思想有所提高。
对袁瑞的领导队友一起做事的能力和分工的领导能力的吸取经验。
对许思慧PPT美观、用例图、类图都可以寻找到我们没有发现的细节。
对陈怡涛绘图工具的使用灵活给让我学会了部分绘图。
陈怡涛
感谢 罗剪梅、许思慧 对我的帮助
刘智鑫
感谢 ______许思慧_____对我的帮助，
总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
目前状态属于CMM/CMMI中的初始级。
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段。
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
队员们能够快速的统一战线，想法达成一致。
4.你觉得目前最需要改进的一个方面是什么?
团队的管理与分工，我们之前一般是在每个阶段开始后确定好一个大任务然后再将大任务平均分配给每个队员。
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
少数服从多数原则，当时在做界面设计时，由于每个同学有每个同学的想法，所以设计出来的东西千奇百怪，最后采取投票，少数服从多数确定界面设计样式。
6. 正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
在团队管理时做到规范，任务分工更加明确。
发布博客时，要附上全组讨论的照片。
