| SG's profileGreen的共享空间BlogListsNetwork |  Tools  Help |
Green的共享空间 |
|||||||||||||||||||||||||||
|
January 07 收获2009年1月5日，a special day,for all of us.对于做demo的人，他们展示了软件的最终成果。对于我，从他们的demo中学习到了很多。
软件的制作过程不是只会写代码就可以的，还有许多东西需要学习。例如，要学习一些和这个软件类似的软件，了解那些软件的实现。有那么多好的软件，用户为什么不选择那些软件而选择我们的软件呢？这是个非常值得考虑的问题。team4提到了他们要制作绘图软件，花了一段时间学习和使用了mspaint等软件。
team1,tank又有了新的变化，现在tank的行走不会显得不连续了，而且设计了几种tank的外形供选择，不知道外形不同的tank在各性能指标上有没有什么区别呢？
team3, 我最好奇的就是他们的界面做得怎么会这么漂亮，和ms一个风格，现在知道了，原来是他们用了microsoft的资源。iHunter要实现download,所以安全问题很重要。
team5，可以换皮肤，界面很漂亮，有天气预报，想得很周到。
在一个有时间限制的情况下要实现一个功能驱动的软件需要合理的安排时间，每个阶段都要有个明确的vision.即使到最后会和最初的构想不一样，但是如果没有计划会变得更糟。而且，要合理的分工。
在软件的实现中会有很多突发的事件，这时该怎样处理是很重要的。比如说，team1遇到disagree时选择了vote,是个很好的方法。
软件的工作量不能只用代码的行数来衡量，not everything is as it seems,用起来很方便的功能实现起来可能需要很深的算法。即使一个只有2000行的程序段，实现的算法的工作量可能是非常大的。
测试很重要，TFS很好，大家可以通过这个把软件的bug返回给设计者，可以使他们尽快的修复。有几个组修复了很多TFS上提出的bug.
软件实现出来，最重要的是得有人用，所以在把基本的设计出来后就要考虑如何使自己的软件变得popular，team4反馈了用户的使用信息，这个很好。软件实现的目的就是要解决用户的pain，只有真正解决才达到目的，所以要及时得到用户的反馈信息，然后及时完善软件。
软件实现出来之后，如何做宣传，如何去争取更多的用户也是很重要的。
January 01 TM 1.0发布感想课程快要结束了，回想起整个课程来，和最初的设想差别的确很大，我也没有想到我们这组的进展会如此的不顺利。用一句话来说，“很受伤”。我前段时间和一个J40的师兄（Mr. 8）聊天，他说他最近在看一本软件工程的书，书中提到了一个“人件”的概念，和“硬件”“软件”并列。他很黯然的对我说，软件工程其实就是“人”的问题，当时我就有“相见恨晚”的感觉，因为我当时也很黯然。还是一点一点来说吧。 首先，这门课程的确讲授了软件工程方面很多很实际的知识，同时课程也设计的循序渐进，一个学期下来，虽然失败了，但是我收获很多。以前不知道软件为何物，单纯的认为软件是代码堆起来的金字塔，现在看来软件工程中方法要比写代码重要，一个有效的方法可以有效的减少废代码的数量。 但是这么课最大的问题并不在于知识的讲授，而使如何在软件开发过程中处理人与人之间的关系。在现实的软件设计过程中，大家都约束在一定的权利和利益的关系之中，所以各个角色能够各司其职，各尽其能。但是在我们的课堂上，我们都是平等的，所以大家只是被约束在一个一文不值的“道义”之中，一旦涉及自己的根本利益，比如“玩的时间”，“排练的时间”，“陪女朋友的时间”，那么让“道义”见鬼去吧。有人提出让PM掌握一定的给分权利来约束大家，实际上没有从本质上解决这个问题，毕竟PM的地位和组员是一样的，甚至是至交关系，谁也不愿意看到自己的同学因为自己而挂了（虽然这是由于他没干活造成的），所以这个约束作用也是会大打折扣的。如何在软件工程这门课上模拟出类似真实软件开发的环境，还是需要“大智慧”的人去发现。 实际上周老师说一开始我们组是最安全的，着实把我吓了一跳，说的我都有点相信了。但是如果是我们班的同学应该知道我们组的成员是一种什么样的情况，某些人自己心里也是明白的。所以即使是设计过程说的多么天花烂醉，一旦到实现的时候总会出现很多掉链子的情况，因为在设计过程中他根本没有去考虑自己的利益，但是一旦实现了，那么他就开始后悔了，推三拖四的。其实我们组是最好的例证，虽然我们的计划是11月定的，但是我们组的代码大部分都是12月中旬写的，更不用说连调了，这其中就是因为有些人没有干活。还好，这些人不是很冥顽不化，在我的“悉心劝说”之下还是动手了，以至于我们的工作得以完成。 其次，我们组，应该说是我对软件的需求认识不够，在软件设计的过程中提到了自以为合理的需求，实现的时候却发现无比的艰难，后来我们的组员根据前面的设计进行了改进和简化，才使得我们的项目得以顺利进展下去。在很多软件工程的书中都提到过这种现象，不知道是不是叫做“软件黑洞”，如果对软件需求定义的不合理，会毁掉一个软件，但谁才能知道“合理”的真正含义？ 剩下的一些问题则是能力问题，比如语言不通，不懂C#，不懂Wpf，不懂Boost，不懂MySql，好像我们几乎没有使用什么以前会的东西来编程，不过现在这些应该都算弄明白了，也是一个不小的收获。又比如方法不通，很多人都没有学过设计模式，软件的可扩展性极差，可维护性野很差，给我的映像是，“我们始终在改代码”。 最后说一下这门课程的评分，其实作为一个大四的人，已经么有什么追求了，所以只要能够给我通过的话，我不是很在意我得了多少分。但是这么课程的给分还是有点不合理。首先PProject就像一个笑话，前前后后折腾了半个学期，还没有什么很好的结果（很多DEv都倒在了Test的手中），评测过程也极其的不透明（自己的程序怎么挂的不知道，Test甚至不通知一声），评测标准也很不合理（不知道是Test的方法错了还是Dev设计有问题，同时分别Test给分和Dev的给分本来就不公平）。其次是T Project用工业界的你死我活的方法（在P Project中也用了）来给我们评分，也就是说即使有时你很努力，但是你还是什么都得不到。但这只是一门课程，这样做使得这么课的性质就变了。 好吧，就写这么多吧~~ 有谁想拍就拍吧~~~~
------ by Hu Wei Troup Manager 1.0 ReleaseTroup Manager 1.0终于还是被干出来了，虽然过程坎坷了点，结果没有预想的好，有些功能尚未实现，但是软件在设计初的基本架构和基本功能都实现了。TM 1.0已经上传到了TFS上面，文件夹下面有一个ReadMe.txt提供了编译和运行的方法，不过要求比较苛刻，可能大多数人不能搭建起来，需要测试的请联系我们组的组员王乃峥同学和金石飞同学，他们的Email联系方式在Blog下面的列表中列出来了。我这段时间有点事情，所以不能帮组进行测试。 下面是目前版本的信息，其实在ReadMe.txt中的内容。
接下来则是晒一下几个GUI的截图（注：这个GUI不是最终版本，因为很多色彩和结构还未作精心的设计，所以看上去有点山寨） 登陆界面
浏览界面，可以看到评论和一些基本操作（浏览服装资源）
个人信息页面
FTP文件上传（图片）
实际上，目前的界面的很多元素都未做细调，界面的背景色是一直在变的，但是很巧的是每次的截图都是很难看的大红大紫，诸位就将就一下了。 ------- by Hu Wei 由分数引发的感想大家都很在乎分数，同样，我也在乎。尊重是自己赢得的，同样，分数也是自己赢得的。这个道理在软工这门课中体现得淋漓尽致。
我这学期刚刚来清华，一切都是新的，一切都要重新学起，一切都要重新适应。第一个走进的清华课堂就是“Adcanced Software Engineering”,让我流泪最多的就是软工这门课，让我笑得最多的也是软工这门课！第一次走进这样的课堂，一个词--“喜欢”！从来没有上过这么有意思的课！啊啊，原来可以这么开心的上课！啊啊，原来认为不公平可以和老师argue!最开眼界的是这门课，收获最多的也是这门课！最开心的是这门课，最头疼的也是这门课。当我看到IProject成绩排名中一个一个2005XXXXXX时我才知道，我居然糊里糊涂的跨年级选了软件实验班的课。大三的课就够我觉得难了，软工这门课对我来说更是难上加难！当我遇到IProject时，当我遇到PProject时，只有一个词可以形容我的心情--“茫然”！C#？What's this?我从来没有接触过！去图书馆看书，上网查资料，IProject终于过关！可PProject?......我真的曾经想过要把这门课退掉，好难呀！不是我能承受的！可是我怎么舍得？邹老师是唯一一个下课会问我听得怎么样的，会发email问我最近programming进展如何的！当我彷徨无助时，是贝帮我解决了大难题！当我编程遇到问题时，是胡巍教我该怎样写程序，该怎样调程序，该怎样养成编程的好习惯！听说一只小鸡很容易死掉，我很庆幸孤身一人在这里的我还可以活得好好的！软工课老师和同学的帮助和照顾是我生活的脊梁，my favorite course,my favorite teacher,my favorite TA,my favorite classmates都在这里，没有你们这趟清华来得就没有意义！第一次听说从来不翘课也会担心挂科的！即使分数对我来说很重要，但此时对我来说更重要的是我的收获！通过这门课我真的觉得我的编程能力提高了！
下面我来谈谈我对PM给分的看法吧。我觉得这部分最为难的不是我们，而是PM，即使是不干活的组员，可能PM也不会忍心或是不好给0分。胡巍我想对你说：“看到你写的几千几万行程序，我真的很惭愧！我们的TProject中没有一行代码是我写的。请给我0分或少给我一些分吧！看到你熬夜编代码，我却可以安稳的睡觉，我也觉得很不公平！怎么可以这样？我们是同一个team！我实在不能让自己和你们得同样的分数！”即使我被挂掉，那也只能是我的宿命！我不是不想为我们的TProject做事，而是这么难的代码我真的不会编！不过剩余的时间里我会为我们的TProject做一些我力所能及的事！大家也能做什么就做些什么吧！Team's score is our score !
最后我建议大家都主动的跟PM提出应该给自己多少分吧，不要让PM为难了。
------by Wen Yue 谈谈测试软件已经写得差不多了，下一步主要的工作就是测试了。下面来谈谈测试吧。
首先要搞清楚我们测试的目的到底是什么？该采用怎样的步骤及原则来测试？测试的结束点是什么？
测试的目的：
站在用户的立场，他们比较希望通过测试来暴露软件中隐藏的错误和缺陷，来考虑是否接受该软件。而站在软件开发者的立场，他们更希望软件不存在问题，并已基本满足用户的需求。Grenford J.Myers said: “测试是程序的执行过程，目的在于发现错误；一个好的测试用例在于能发现至今未发现的错误；一个成功的测试是发现了至今未发现的错误的测试。”
测试的步骤及原则：
正如邹老师在移山之道中说的，测试不能盲目的进行，要有计划的进行测试，要遵循一定的步骤及原则。 1.首先要写测试计划说明书，说明软件的功能是什么，要测试哪些方面？有哪些预期bug比较多的地方？如何去测试？。。。。。。 2.在具体的测试中，测试用例要包括合理输入和不合理输入以及在各种输入状态下的预期结果。因为在软件的实际运行中，用户很有可能会进行一些意外的误操作，如果软件遇到这样的问题时不能做出适当的反应，将会产生故障，轻则返回错误数据，重则整个软件都会废掉。
3.发现bug时要写出具体的错误报告，以便程序员能够很快的解决问题。
4.对于任何一个程序员来说，都不希望自己的软件有问题，而且也对自己的软件倍感信心，所以在测试时可能就会选择一些很小概率出现问题的test cases,而逃避选择那些易于暴露程序错误的test cases。因此在内部测试中最好的方法就是找同组的其他人来测，尽量避免自己测试自己的部分。 5.由于软件的复杂性，开发各阶段的多样性等因素，软件应尽早的进行测试。
6.要妥善保管测试计划，测试用例，错误报告，为软件维护提供方便。
测试的结束点：
按照错误的严重程度大致可分为：严重错误，主要错误，次要错误，一般错误，较小错误。确定测试结束时，首先要保证严重错误以及主要错误已经完全被解决，次要错误以及一般错误已经85%以上被解决，较小错误70%以上被解决，少量缺陷可以留到后面版本再解决。
结束语： 这一部分的工作是尤为重要的，如果我们的软件连我们自己测试的这一关都过不了的话，就根本过不了千奇百怪的用户这一关，就会是个不稳定的软件，就会是个不受欢迎的软件，就会是个逐渐走向灭亡的软件，所以我们要尤其重视这部分的工作。
----- by Wen Yue
GUI编程
组员
|
||||||||||||||||||||||||||
|
|
