第一小组软件工程汇报.ppt

第一小组软件工程汇报
二、小组成员分工
姓名
负责内容
陈铿（主要负责人）
搭建SVN，负责文档的版本管理，总结各版本的文档，处理成员提交的更表格，撰写项目总结，组织小组两次会议。
春梅（主要负责人）
制定软件项目的概述性文字组织和后期的画图均由其他人负责，而系统的架构和MVC模型的构想由我来负责，版本的统一只通过我来实现，她们把修改或增加的内容发于我QQ或邮箱，然后由我同意修改，每次修改均保存版本，.。如若出现特殊情况则按照第一版本重新编写。
22
四、文档
数据字典文档
修改编号
时间
简要说明
1

主要内容完成
2

细节内容添加
3

细节内容完成
4

整体完成
文档管理总结
如今，软件开发越来越复杂，软件功能也越来越丰富。而几乎所有成熟的商业软件，都是靠一个开发团队齐心协力的血汗结晶。“罗马不是一天建成的！”，当我们震撼于Microsoft   Windows的惊世巨著的同时，也道听途说了微软公司软件工程是如何的完善规范。的确，集数百名员工几年的共同努力之大成，软件项目管理的成败是控制开发成本的关键环节。这里面，少不了贯穿其中的重要步骤----软件文档。
在此次作业中的数据字典文档版本管理如下所示：
初期，我做的数据字典文档主要完成了一些主要的数据的定义，数据库的设计等的描述。在细节问题上仔细的说明。
第二期的时候，先在大体上再改进一下，再在细节描述上进行认真仔细的说明，如一些图表（数据表，视图等）。
最后，进行整体的检查之后，形成了第三期的成品。然后完成。
23
四、文档
软件界面规范文档
文档管理总结
大学三年第一次大作业在文档上花的时间比实际动手多，文字上的卖弄虽看似比实操简单，实则未必。一份文档要写得好，除了文字，图片的单纯叠加，还要预先阅览大量文字，并且要十分熟悉自己所负责的部分。
本次大作业试用了利用SVN搭建的平台，但由于服务器是在内网搭建，而该文档的参与者的拉AD，所以不能充分地利用SVN的版本管理服务，对本次小组合作作了相对应的进度记录。详细的进度记录既能对我们每个时间段的工作作出记录，也能更好的敦促我们对项目的修改。
24
25
四、文档
编码规范文档
文档管理小结
这次我们小组使用SVN,即subversion来作为我们小组的版本控制工具。我所负责的编码规范文档是根据需求分析和概要设计所编写的。我在工作编写编码规范时，根据需要，一天之内不定期地上传自己的文档，然后在一个阶段结束后，上交进度汇报表和当前阶段所完成的工作，即初步版本的编码规范文档。由于我负责的编码规范文档比较简单，编写时较为谨慎，所以后期没有变更，所以没有提交变更报告表。
经过这次编写编码规范文档，我了解到了文档管理和版本控制的重要性。加入了文档管理，方便了小组对文档的查找和修改，同时能做到有效分工，不会变乱。版本控制能帮小组恢复因错误修改的文档和方便小组各成员了解互相的进度，以此激励成员。
但在这次工作中，我发现我的管理工作还是有不到位的地方，首先贪求方便，没有按照要求定时上传保存文档，其次虽加入了版本控制，但没有定下版本的序号，以及进度的编号，导致个人自己命名版本号，使文档看起来有的高版本，有的低版本，没有正确反映文档的进度情况。
26
四、文档
测试文档
测试分析报告
测试规划与用例设计
文档管理小结
本人负责测试的项目。成员还包括邱淑敏。
测试首先对整个测试做了规划，然后花了大部分时间在测试用例设计上。由于单元测试比较多，测试用例也比较多，所以 在进行测试用例设计时，会感觉不耐烦， 很浮躁，思想就会松懈。觉得测试是最磨练人的意志的，它需要认真，仔细，耐心，静心，还需要忍。，尤其是长期测试，这时就需要测试人员，静下心来，仔细分析研究测试用例，以及相关的说明书存在的遗漏。总之，测试人员要保持一颗良好积极的心态。
不足地方在于对测试工具的使用不熟悉，测试很多方面技术没掌握好，很多时候还是进行手工测试。测试做了计划,但是没有按照步骤来进行。由于对测试项目不熟悉,工作有所延误，为了确保能按时完成工作进度,有些测试过程也给简化了。
27
四、文档
附录一 项目进度表
附录二 需求更改表

例子
28
Outline
目 录
一、小组作业进度安排
三、版本控制