destiny珍

导航

 

1.学习和使用的新软件

Mockplus原型设计软件,用于制作项目初期的原型设计

2.学习和使用的新工具

Enterprise Architect UML分析和设计工具,绘制用例图,类图
EPP php编译工具
My sql 数据库管理系统

3.学习和掌握的新语言、新平台

语言:HTML、PHP
平台: 新浪云

4.在这次软件工程项目中,个人应该差不多完成了1000行左右的代码

5.学习和掌握的新方法

接触了很多上课时没有接触过的东西,了解了如何进行原型设计,自学掌握了PHP语言,能够结合HTML,编写出简单的动态网页,知道了如何进行项目测试,数据库连接。

6.总结与展望

(1)记录自己在软件工程上课程上的经验总结
首先,小组成员必须要有明确的分工,有各自要负责的模块,小组成员一起努力,争取完成项目,其次,项目的前期工作一定要准备充分,该做的步骤,比如需求分析,UML建模,典型用户分析,原型设计都要提前进行。这样才能根据所做准备编写代码,然后进行软件测试。每一步都是为以后的设计打下基础,不能有任何偷懒,否则在后期还要进行完善,最后项目完成之后要进行软件测试,在测试的过程中有可能发现以前没有注意到的领域,可以进行及时的完善。通过软件工程这门课,我收获了很多,掌握了新的语言,了解了新的平台,这将会是一次难忘的经历,通过小组成员的共同努力,我学会了如何欣赏、沟通和学习。
(2)对于下一届的学弟学妹的建议和告知。
选择的选题必须是以自己的能力为基础,不能空口说白话,还要选择自己有兴趣的选题,编写代码时一定要仔细,戒骄戒躁,总会有解决的方法。
如果学弟学妹选择我们这个项目进行开发,可以进行页面的美化,以及各种功能的完善,还可以实现线上交易,总之,我们的项目还有很大的发展空间。
(3)分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》团队合作的阶段,你们团队经历过么?最后到达了哪一阶段?
由于团队中并没有学霸级别的人物存在,在此次项目的开发中,我们都是一步步慢慢体会,总结,其中还走了不少的弯路,好在到最后我们尽力实现了所有的功能,可能有些界面并不美观,比较单一,但是由于是初学,时间,经验,能力有限,所以能做成目前的状态,个人感觉还是满足的,我们还需要在以后进行美化。在此次软件工程实践中,我们小组大致经历了萌芽,磨合,规范以及创造阶段。项目初期,大家都还没有明确自己的目标,也不知道自己的分工,所以进展很慢,后来磨合了一段时间之后,才开始着手于自己的任务,其中也有意见不统一的时候,但是最后大家还是会选择出一种最合理的 办法。总之,此次实践中小组成员齐心协力,共同进步。当项目完成后,每个人内心的成就感是无法言表的,自己亲手做出来的东西才更加有说服力。
(4)个性发挥,包括图文、照片和创意等

这是我们小组二手交易平台的微信公众号二维码,期待大家的关注与建议。

另附平台首页,想要的精彩绝对不止这些。

7.个人总结的补充

(1)我看了这一段文字 (软件工程的目标—创造足够好的软件,所谓好软件,就是软件没有缺陷,所谓软件工程就是把软件中的bug都消灭掉的过程),有这个问题 (当想做的项目规模很大时基本上不可能做到没有bug,并且作为一个初学者总会忽略很多,所以我们如何才能把握好这个度?)。 我查了资料,有这些说法(满足用户的需求;合理进度、成本、功能关系;具备扩展性和灵活性,能够适应一定程度的需求变化;能够有效的处理例外的情况;保持成本和性能的平衡),根据我的实践,我得到这些经验(我们应该尽可能的减少bug,bug的多少直接衡量一个软件的开发效率,用户满意度,可靠性和可维护性)。 但是我还是不太懂,我的困惑是(如何能够客观,合理的去评判一个软件的质量?)。

回答: 软件质量直接影响着软件的使用和维护 ,通过软件工程这门课的学习以及实验总结,我得出以下经验:

              (1)软件需求是衡量软件质量的基础,不符合需求的软件就不具备质量;
              (2)软件应在功能、性能等方面都符合要求,并能可靠地运行;
              (3)软件结构良好,易读、易于理解,并易于修改、维护;
              (4)软件系统具有友好的用户界面,便于用户使用。

(2)我看了书上两人合作的不同阶段和技巧,对书中描述的5个阶段:萌芽,磨合,规范,创造,解体阶段有了一定的了解,但是4.6.2小节—如何正确地给予反馈,作者将反馈分为最外层(行为和后果)、中间层(习惯和动机)和最内层(本质和固有属性),不同层次的反馈给人不同的感受。如果将反馈上升到最内层,说不定两人合作将从磨合阶段直接到解体阶段...由于自己只是初学,并且没有太多的经验,所以对这三个层次我还是存在困惑,在工作中或学习中,我们如何才能对同伴选择正确的层次进行反馈。

回答:在做项目时应该从小的方面做起,提供鼓励和安慰,最重要的是实践。而且必须是自己实践,同时也要为其他人创造最有可能的实践方式,还要做到关心同组成员的发展和成长,为成员提供他们在该项目上所需要的支持和工具。

(3)我看了 (第二章《个人技术和流程》,本章的实质是在说明,一个合格的软件工程师是怎样的,他应该具备哪些技能。读完本章,一个合格的工程师在开发时需要同时考虑质量和效率,与之同时需要具备的技能包括:单元测试、效能分析、个人研发流程)),有这个问题 (软件是需要单元测试的,之前对这个没什么概念,而且单元测试要跟软件更新同步,单元测试要覆盖所有代码路径,如何才能实现单元测试,减少隐患?)。 我查了资料,有这些说法(
1 单元测试应该在最低的功能/参数上验证程序的正确性

2 单元测试必须由最熟悉代码的人(作者)来写

3 单元测试过后,机器状态保持不变

4 单元测试要快(一个测试用例的运行时间是几秒钟)

5 独立性—测试的运行/通过/失败不依赖于别的测试

6 覆盖所有代码路径

7 单元测试应该集成到自动化测试的框架中

8 单元测试必须和产品代码一起保存和维护

), 但是我还是不太懂,我的困惑是(我们应该如何才能实现一个有效的单元测试)。

回答:通过理论课的学习,我明白单元测试应该一条线测试完毕,只有测试才能够准确反应出代码是如何运行的,包括读取数据库部分。而且测试需要的数据应该是可重复使用的,最主要的是任何测试都可以独立运行,同一个测试多次执行的效果应该是一致的,测试的执行速度应该尽可能快。

(4)在阅读第5章《团队和流程》中,我了解到了各种的团队合作模式,但是在开发流程这一块,对于瀑布模型以及其的各种变形的认知感觉有一定的难度,我学到了要完成一个复杂的软件项目,团队的各种成员要在不同的阶段做不同的事情,主要有:业务建模,需求,分析和设计,实现,测试,部署,配置和变更管理,项目管理以及环境等各个阶段。但是我还是感到困惑,在一个团队项目中,工作量如何分配?对此,我查找了资料,但仍然是一头雾水,对于我们目前组成的团队,在我们小组分工的时候完全把握不到这个度,甚至都不清楚都需要做什么工作,个人能力的认知上可能也有缺陷,所以我想知道怎样才能合理分工,组成一个有效的项目团队。

回答:首先,成员必须了解自己的优点和缺点,另外,成员要了解项目盲点和难点,应该提出意见,帮助修改,协同完成项目,计划才能高效而合理。再者,成员是被组织的对象,但是成员肯定特性各异,要形成和谐而高效的组织,不能光靠组长的英明决策,成员还得自告奋勇、出谋划策,给组长提供决策支持,当然成员还是得作出自我牺牲,积极融入组织。其次成员首先要自觉,积极高效的完成任务,同时,要以团队利益为重,主动配合别人的工作。最后,成员得把握好分寸的服从组长。既不能阳奉阴违,也不能唯唯诺诺,最好是能提出建设性的意见,总而言之,要做一个卓有成效的团队成员,就得以大局为重,将心比心,为他人着想,既配合又指导,既服从又协同,如此,项目团队成员自然是有效的,而且是高效的。

(5)怎样在计划中体现依赖关系呢? 我查了资料,有这些说法(每天跟踪三个时间值:实际剩余时间,预估剩余时间,实际花费时间。这样才能在实践中脱颖而出。一个敏捷的团队要怎么衡量,包括下面的条件:1.自主管理。2.自我组织。3.多功能型。但是一个团队只有在团队很强的基础上才能转变为敏捷团队。),根据我的实践,我得到这些经验(在开发的过程中,我们会遇到很多问题,所以我们要不断地进行自我总结。首先要学会把一个任务从产品层级的描述逐步细化到技术实现层面,是很需要技术能力和交流能力的,我们要在实践中学会根据我们每个人的能力分配给每个人不同的任务以保证能够取得更高的效率;其次是每时每刻确定好自己的任务,一个坚定的目标,犹如一盏指路明灯,有了它,才能顺利地完成每一项任务;最后,是一项长期任务,更是一个冲刺阶段,在这个时候,我们要不断地修复软件中的bug,学会如何测试,是检验一个程序员是否优秀的唯一标准,在这个过程中,我们可以不断完善自己的程序,改进原来的计划,从而制作出更好的软件。)。 但是我还是不太懂,我的困惑是(看了很多的方法以及理论知识,我们到底应该在遇到什么情况时才是适合敏捷开发的)。

回答:

通过此次团队作业,我有了深刻的体会,然后对于此问题我又进行了资源查找,资料显示如下:(1)产品复杂,不断有新的需求加入。当产品的开发受市场影响较大时,业务需求的变动就十分常见了,为了不影响项目开发进度,需求管理必不可少。有些团队会一个个排需求、做需求,而敏捷开发是通过任务分解把工作拆分为半天到几天的工作量,然后制定里程碑时间点,将复杂的需求细化成一个个小任务,再根据轻重缓急梳理优先级,简单快捷地帮助开发人员化繁为简,提高效率。(2)团队庞大,沟通协作效率低。有时一款新产品的开发,需要多部门联动协作,然而每个成员的岗位和职责不同,所以每个人关注的项目信息不一样,关注信息的频率其实也不一样,有的比较频繁,有的则可能整个项目过程就只需沟通两三次。由于每个人的习惯不同,所以他们获取信息的手段也不太一样,有些人喜欢微信、QQ,有些人喜欢邮件,还有些人喜欢以会议的形式获取信息。这就导致了团队内部沟通效率低下,许多重要的信息难以实时传递。
(3)希望高效地管理开发进度。产品经理为了掌握项目的进展,掌握各项工作的状况,就必须对项目过程进行监控和跟踪。只有这样,出现了问题,才能及时进行资源调整和进度计划调整,重新规划某一个任务开始和结束的时间,并记录实际的进度情况。

结合以上资料以及自身经验,我总结出敏捷开发适合以下场景:

(1)为了保证项目的开发进度,一般会选择敏捷开发,因为它会把任务分解,将需求细化。

(2)当选取的产品比较复杂,而且不断有新的需求加入时,一般会采取敏捷开发。

(3)当一个项目比较庞大,里面包含许多成员,而且每个成员的岗位和职责不同,这就造成每个人关注的项目信息不一样,许多重要的信息难以进行传递,导致团队内部沟通效率低下时选择敏捷开发。

总之,敏捷开发比较适合于那些很紧急并且非常复杂及比较新颖的项目。

posted on 2017-06-23 20:15  destiny珍  阅读(379)  评论(4)    收藏  举报