DOOM_buaascse

摘要： 由于每个组员的得分不能有相同的，所以改动如下李忠47分，陈伯雄34分，刘宇翔32分，张孝祖26分，潘学28分，苏若19分 阅读全文

摘要： 测试产品：Upload/Download; Search of this site测试目的：功能测试测试方法：黑箱测试时间：2012.11.18测试员：刘宇翔测试设计说明书（TDS）（1） 产品功能： Upload/Download：正确上传和下载文件 Search of this site：正确完成搜索功能（2） 测试内容：测试能否正确上传和下载文件、完成搜索功能；预期内容：上传文件是否正确进入数据库，添加倒排表和能被正确搜索；正确下载；搜索结果是否正确、人性化。（3） 测试方法：黑箱测试。提前准备好测试用例。（4） 人工分类测试验证功能正确性。测试用例(Test Case)具体测试用例见演 阅读全文

摘要： 根据之前我们小组的评分标准，下面给出每个组员的得分如下：（1）团队总分为180，分配给不同组员（2）我们的初始得分：PM（李忠）：180*10%=18分析员（陈伯雄）：180*10%=18测试员（刘宇翔）：180*10%=18程序员1（张孝祖）：180*5%=9程序员2（潘学）：180*5%=9程序员3（苏若）：180*5%=9（3）每个人的工作量：组员初始得分分配结束后，还剩下99分，用于按劳分配。下面是我们组内讨论得出的工作量（占总工作量的百分比）PM（李忠）：30%分析员（陈伯雄）：15%测试员（刘宇翔）：15%程序员1（张孝祖）：15%程序员2（潘学）：15%程序员3（苏若）：10%（ 阅读全文

摘要： 测试周遇到的问题还是比较多的，主要是在建倒排表和查询数据库上，由于之前编写的代码测试都是没有连数据库，这周加入数据库后，我们的程序第一次跑毫不犹豫地就崩溃了。。。下面是对软件工程过程的一点感想（1）软件工程的确是一个不断的迭代的过程，随着整个“学霸”系统的完善，我们的小组项目设计不断的更新，组员们都表示我们的代码已经完全和之前的不一样了，最初的设计好像都见不到影了。（2）不同模块小组的沟通是很重要很重要的，我们小组就为此付出了不少的代价，我们小组的数据库开始约好是用第二大组pipleLine，最初设计search部分的时候就是按他们的数据库模式设计的，但是在昨天我们三个UI整合的时候，讨论决. 阅读全文

摘要： 这个礼拜的工作到现在还没有完全完成，我们的主要问题出在和其他组的整合上面，之前我们用的数据库模式是第二组的数据库模式，后来我们UI三个小组的讨论决定我们要建一个数据库，所以现在我们的search和倒排表的建立要从新翻工一遍，伤精动骨啊。。。中文分词程序在整合时候发现不好用，我今天上午又从新写了一个新的中文分词程序。128篇文档已经找到了，我们的测试数据主要还是靠自己编，第二组没有给我们数据，为了和其他两个UI小组整合好，我们的项目测试周工作比之前两周似乎大了好多，可能是之前各个小组没有沟通好的原因吧。 阅读全文

摘要： 今天中午，我们小组开了一个会议讨论了下项目测试的工作，我们进行了工作分配：（1）刘宇翔和潘学：测试search of this site部分，用各种边界条件和各种可能的情况进行测试，最后写出项目测试文档；（2）李忠、张孝祖、陈伯雄和苏若：找128篇文档来测试UploadContent和DownloadContent的部分的功能正确性。以上是今天进行的工作分配，我们的组员都已经开始了工作，争取下周一的展示的成功。fighting！！！ 阅读全文

摘要： 在大伙都在吹捧“市集”开发软件的方式的大浪潮下，作者看到了其中的不当之处，发现其中有许多的问题，因此写下这篇文章给予吹捧“市集”的人一个提醒，甚至警告。 在该文章里，作者认为“市集”里的“农民”不可能建造出和“大教堂”一样宏伟的“建筑”，那些“市集”里开发软件的人，会把软件搞得一团糟，“代码越重用，浪费越严重”，作者觉得这种局面应该改一改了。 我觉得作者在文章里的观点有些偏激了，不能一味的吹捧“市集”也不能否定“市集”，不能小看那些“农民”的能力，互联网的时代，“市集”是必然的，现在不 是流行叫“地球村”，一个村庄里，不能只有教堂，还要有市集。不能说“农民”基础不行就不让人家卖“农产品”了，“ 阅读全文

摘要： 这篇文章主要是介绍了“瀑布模型”。作者总结了自己在软件开发中的经验，提出了一个软件项目的开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统 需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈。他给出了固定的顺序，将生存期活动从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得 到所开发的软件产品，投入使用，这也许就是我们后来人称之为“瀑布模型”的原因吧。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 每个 阅读全文

摘要： 在敏捷开发提出到现在，到处都在说软件开发的敏捷开发，作者在文章里对传统软件开发方法和敏捷开发方法进行了比较。作者首先是介绍了敏捷开发方法的产生， 在这之前，软件开发者认为软件项目开发就是把软件分成不同的模块，在各个模块都完成后，把这些模块组合起来就行了，但是随着软件项目规模的增大，软件开发 者往往发现这种传统的开发方法会面临bug的不断“侵扰”，bug数量会是非线性的增长；在面临这种困境后，软件开发者提出了以计划驱动的敏捷开发方法。 敏捷开发方法相对于传统的软件开发方法的一个明显的不同就是敏捷开发是与代码为主的，强调代码是文档的主要部分。相对于传统的软件开发方法，敏捷开发方法有以下的特点：（1 阅读全文

摘要： 这篇文章首先是介绍了软件工程要面临的固有的不可避免的问题，主要是复杂性（complexity），软件整合（conformity），可变性（changeability）和不可见性（invisibility）。下面是对文章里这些问题观点的整理：（1）复杂性（complexity）。软件要增加规模不仅仅是简单地增加相同内容的规模，还要增 加新的内容，这就使得随着软件规模的增加其复杂度的增加是非线性的，整体复杂性的增加可能比线性增加要大得多。软件的复杂性的这个特征给软件的开发带来了 不少的困难，它会给软件项目组里的组员之间交流带来困难，从而导致产品的瑕疵、开支过多和时间耽搁；这样的复杂性给我们穷举所有 阅读全文