码迷,mamicode.com
首页 > 其他好文 > 详细

M1/M2项目阶段总结

时间:2016-01-12 13:43:28      阅读:306      评论:0      收藏:0      [点我收藏+]

标签:

1.M1/M2总结

我们这学期完成了学霸项目。

在M1阶段,我们首先进行了分工,完成了一个系统的计划,然后是对学长代码的移植和优化。在优化代码的过程中,我们遇到了不少问题,比如一些代码的冗余以及指向性混乱,数据方面的处理也是没有系统,没有结构。由于大家之前接触的语言都是C,C+和Java,而且只知道git,没有用过TFS,好在大家勤勤恳恳,努力学习了C#,JSON,TFS,并对代码中的错误进行修改,在此过程中付出了极大的辛苦,才得以将M1版本开发出来。

M2阶段是在与很多科目的竞争中做出来的,当时不少科目期末考试和大作业,于是团队中课程较少的人更加辛苦一些,抽出更多时间,前端与后端不断沟通交流,才将M2完成。

2.链接到以前的博客

http://www.cnblogs.com/zhangbolong/p/4830941.html

问题一:如何判断一个软件是值得维护的?抑或如何评价一个软件的发展潜力?

一个软件是否值得维护依赖于它对用户的满足度和对开发者的预期目的的实现。比如说,它是否可以覆盖开发者预定的测试需求?例如,对于一个质量非常好的软件产品,存在的软件缺陷异乎寻常的少,测试用例设计人员准备了大量的测试用例,已经完全覆盖了测试需求,但是只有很少一部分测试用例在执行时发现了缺陷,而其他用例都顺利通过了。那么在它满足于用户的目的的情况下,就可以认为它是值得维护的。对于一个即熟悉测试工作,又熟悉被测应用的测试人员,应当可以花费很少的时间就可以理解测试用例中表达的测试思路,并可以很快的执行完这个测试用例。当开发过程中的某些因素影响了测试需求,测试用例的作者或其他测试设计人员,应该可以花费很少的时间就完成定位并维护所有相关测试用例的工作。

问题二:是软件本身的实用价值重要还是用户的使用价值更重要?

软件从无到有的设计、研发,一直到推送到用户的面前,中间经历了很多复杂的流程和步骤,并不是简单的一句话就能描述清楚的,显然软件的成功也并不能靠一两句话去解释。
软件的成功是数种、甚至数十种因素综合作用的结果,有的得益于依托于庞大的资源、有的依托于畅通的渠道、有的依托于政策优势、甚至有的仅仅是因为运气好...所以很难通过一两个软件去判断。
软件价值和用户体验是一个什么样的关系呢?软件的主要价值在于满足人们的某种需求,这也是它最重要的一点,如果它不能满足用户的需求,用户就不会去使用,就失去了存在的意义。围绕它的所有盈利方式也就无从谈起。它对用户的价值是得以立足的基础,也是一切商业行为的基础。
价值大于用户体验:一个没有价值的产品就像无根之萍。      
用户体验决定产品成败:在多个有价值的同类产品中,综合体验好的会更接近成功。

问题三:多人项目中,如何合理的取得平衡点并使效率最大化?

在学生时代,还是更多依赖于不同人的开发水平,我认为,对于结对编程(以及两人以上的编程),团队成员中,尤其是负责开发和测试的程序员,他们之间的水平不能差距过大。差距过大会使团队中每个人的积极性都打折扣。而且在水平差不多的团队中,往往更加协调。其次,在分工时,应该根据每个人的擅长及能力分工。

问题四:如何预先避免不同软件运行时带来的冲突?

我的原意是指软件对于不同平台的兼容性,而非不同软件厂商恶意竞争。移动领域的开发,目前面临不同操作系统需不同开发语言,同一操作系统存在不同版本,同一版本存在不同机型等难题,给移动开发增加了很大难度。PhoneGap,Titanium,SenCha是目前比较主流的跨平台开发技术。

问题五:如何预见用户需求?

在需求分析阶段,利用符合客户语言习惯的表达,了解客户的业务及目标。

3.阅读以前文章,新的体会

在实际的开发阶段,以往文章中的许多模式,比如瀑布模型,是很不适用的。在M1阶段,客户往往很难清楚地给出所有的需求,而该模型却要求如此。在M2阶段,实际的项目开发很难严格按该模型进行。

需求阶段:分词器,TFS,XML

设计阶段:文本关键词的提取和翻译

实现阶段:黑盒功能测试,代码审查

发布阶段:软件工程中项目整合的方法

维护阶段:根据测试结果判断维护代价

 

M1/M2项目阶段总结

标签:

原文地址:http://www.cnblogs.com/zhangbolong/p/5123993.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!