软件工程第五次作业:个人总结

回想开学初对于软件工程这门课的期望,总结本课程对我带来的提升:

  • 学习和使用的新软件:API-cloud
    这次制作这款物业管理App软件,我们使用的软件是API-cloud,APICloud是中国领先的“云端一体”的移动应用云服务提供商。[1]APICloud为开发者提供一站式高效APP开发和管理平台,覆盖APP全生命周期,包括开发、API集成、测试、渠道打包、运营管理等。我们通过这个软件来实现我们的App,而且这个软件兼顾实现后台数据库连接,第三方软件接口等功能。
    API
  • 学习和使用的工具:云数据库
    这次制作我主要负责的是云数据库的建立与连接。我们班大多数人都使用的本地数据库,但是我们使用的是云数据库。云数据库相比于本地数据库有很大的优势:
    1、用户能够在云数据库控制台轻松的完成数据库申请和创建,云数据库实例在几分钟内就可以准备就绪并投入使用。用户通过云数据库提供的功能完善的控制台,对所有实例进行统一管理。
    高可靠
    2、云数据库具有故障自动单点切换、数据库自动备份等功能,保证云数据库实例高可用和数据安全。云数据库免费提供7天数据备份,可恢复或回滚至7天内任意备份点。
    低成本
    3、云数据库支付的费用远低于自建数据库所需的成本,用户可以根据自己的需求选择不同套餐,使用很低的价格得到一整套专业的数据库支持服务。
    DNS
  • 学习和掌握的新语言、新平台:js和html、css
    以前我们都对js有误解,以为它只可以写前端。但是在API中,我们恰恰用的js来实现的与后台数据库的连接。html不仅可以实现界面的编写,而且可以通过与js进行交互从而实现html页面之间的参数传递。JavaScript 被数百万计的网页用来改进设计、验证表单、检测浏览器、创建cookies,以及更多的应用。新平台是API,API(Application Programming Interface,应用程序编程接口)是一些预先定义的函数,目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力,而又无需访问源码,或理解内部工作机制的细节。API与系统调用的区别:系统调用代码都处于内核态,API是操作系统提供的一组函数,通常以库的形式存在,供用户调用,所以,API代码可能是完全是用户空间代码,也有的API调用了系统调用。
  • 统计一下,你在这软件工程实践中,完成了多少行的代码
    经统计,我一共完成了后台数据库建立、后台数据库连接、登录界面以及修改密码界面的编写,共完成大约2000行左右代码编写。
  • 学习和掌握的新方法;
    1、在软工方面,我学会了最基本的用例图、类图、er图的画法,数据字典的撰写。
    2、在专业方面,
    (1)我对js的用法进行了探究,并掌握了其中函数的编写方法,函数库中主要函数的调用。
    (2)了解了html的布局方法、名称作用,以及html与js之间通过cookie的交互。并了解了我们校园网登录是用了cookie编写。
    (3)学习了云数据库的建立方式与交互方式,并通过js语言实现了与云数据库的交互。

总结与展望:

  • 记录自己在软件工程课程上的经验总结
    总结在软工课上的经验,我的答案是有志者,事竟成。在进行前端与数据库交互的时候,我遇到了前所未有的困难,甚至想放弃云数据库。但是在我的坚持和其他成员的鼓励下,在晚上八点半的时候终于实现了数据库的连接,并且可以把数据直接传到后台数据库。人只要用心,没有什么事情是不可能的。所以这一学期软工课给我最大的教育就是要坚持,坚持到底,就会取得自己想要的成绩。
  • 对于下一届的学弟学妹你有什么建议和告知呢?
    我想说:
    1、在选题的时候一定要慎重,尽量选择比较实用的题目,做起来容易查找资料,对自己很有益。很偏的题目资料很难查找。
    2、在制作的时候一定要有计划,循序渐进,一步一步稳扎稳打。大不能一口吃成个大胖子,这样不能保证质量也不能保证效果。而且根据我们的制作经验,最好是把每个时段做的东西及时传到网上,并进行记录,方便我们对自己的错误进行查找和评判。
    3、测试的时候一定不要放过细节,只有每个细节也做好了才能达到真正的完美。
  • 分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。你们团队经历过么?最后到达了哪一阶段?
    在我们制作软件的过程中,委实遇到了每个团队必须遇到的问题,我们有过争吵,有过开心,经历过风雨之后,我们最终成功了:
    1、萌芽阶段:
    在刚刚开始的几个星期里,我们信心满满,外加上外面的老师鼓励,商家支持,我们决心一定要做出可以在西宁市推行的一款软件,这是我们最终明确的目标。大家都积极发表自己的看法,积极的提出了自己的建议,并进行了初步规划,大家都在给自己揽活,积极性也非常高,这样的情况大约持续了一个月。
    2、磨合阶段:
    在接下来的时间里,大家开始产生了分歧并且开始逐步磨合。因为各种作业的原因,以及社团活动,有些小伙伴没能按时完成自己的一部分事情,有了争吵与不理解,我们内部不断有一些不愉快的声音发出,包括一些伙伴不满足于自己的工作量过多,有一些能力较低的伙伴有心无力。但是,这是每个团队必须都有的阶段,我们还是没有放弃,转而在自己身上找原因,慢慢的,我们总能把问题暴露在空气中并且能够如期得到解决。我们的团队归于和谐,项目也得以如期的进行下去。
    3、规范阶段
    还好还好,我们并没有散伙,项目制作也如火如荼的开展下去。我们找到了一些打好代码的渠道和乐趣,大家开始乐此不疲的去进行交流,互帮互助,学有余力的时候也会不满足于自身,尽心尽力的去帮助能力较差的队友进行个人的工作。这个阶段最好的就是我们之间开始有了交流,制作的冲突点也几乎为0。我们尽最大的努力实现了自己的一部分,即便做不出来,我们相互之间也只有鼓励与帮助,没有责骂,因为我们知道,属于我们的时间不多了!
    4、创造阶段
    我们的项目初步完成了,再进一步测试完善我们的现有功能的同时,我们开始创新一些新的功能。当然这些功能是由大家一起商议并一起实施进行制作。当然制作还是会有相互的意见,但是大家已经是一股绳了,我们创新了许多功能,比如:实现第三方登录的接口并赋予登录权限,实现购买时的价格相加相减,对自己个人信息表的更改等一系列新的功能,在我们的欢声笑语中完成了对软件的制作。
  • 个性发挥,包括图文、照片和创意等
    总结;学软件制作我的体会是真的太累了、还折磨人,如果没有强大的毅力和动力是很难坚持下来的,有可能半途而废。不服输的我牙一咬,豁出去了,就是这么坚持下来的。学软件制作这两年来,我放弃了自己非常喜欢的爱好—玩游戏(当然了,不是一点不玩,玩的只是少多了)。所以在以后的日子里,包括考研的时候,都要继续发扬这种精神吧。谢谢这次经验啦!
  • 对作业一的五个问题回答:

我对我问题的回答是:

1、对于7.3MSF团队模型,7.2.6保持敏捷,预期和适应变化,中的“我们是预期变化,不是期望变化”我们如何让自己的软件处于不断的变化之中?换言之,我们如果推出了一款软件之后,如何给软件预留足够的更新空间,这些空间的具体位置我们如何得知呢?
:要使自己的软件能适应不断变化之中,就要不断创新。就比如说,我们可以根据市场需求和民众需求来对自己的项目进行一步一步的更新。而且我们可以根据这些需求进行预判,我们预留出来的更新位置恰恰是这些市场需求啊。

2、9.3PM的作用:经过阅读PM的作用和能力之后,我想问,在我们学校的生活中,制作一款软件也需要PM吗?PM不是所有人都可以胜任的,一个团队中如果没有PM,还能按照正常的顺序运作吗?在学习生活中碰到风险我们应该如何处理呢?
:我觉得,火车跑得快,全凭车头带。每个团队都必须有一个PM,虽为群龙,亦俱无首所以一个好的PM会带领会规划好我们的项目制作规划和计划,提醒大家,鼓励大家,把大家拧成一股绳,并能带领团队走向更大的胜利。就像我们团队队长就带领我们,提醒我们,才不至于耽误软件的制作。

3、我阅读了8.4节的竞争性需求分析的框架之后,我对NABCD模型产生了兴趣,这个模型在分析玩需求之后直接索取做法,我觉得有些突兀,因为这时候我们应该确定的是功能,即“电梯演说”中的办法,而不是软件的做法,我们用考虑好的功能来应对好处与竞争,从而不断的完善功能后,再找到实现这些功能的最简便的做法和工具,待产品出来之后经过现在很火的比如内测之后,再进行发布会不会效果更好?
:经过亲身经历软件制作的时候,我才知道,自己的测试并不能完全的吧软件的bug找出来,正所谓金无足赤,人无完人,单凭几个人的力量并不能达到理想的效果,所以,经过完整的内测之后我们尽可能的就把软件发布到市场当中,让民众一起在使用的过程中不断提出意见,人多力量大,总能达到事半功倍的效果。然后在进行进一步的改进,就会达到理想的水准。

4、11.4.2开发人员的标准工作流程具体流向是什么,新建缺陷完成后每一步的发现bug是如何发现的?发现以后又是如何处理的?
:11.4.2具体开发流程就是,在每个过程中发现的bug都会交由技术人员进行处理,当时没有看明白是因为上面没有注明每个环节都可能会发现bug。

5、结对编程:根据结对编程的内容,正如79页两人合作的不同阶段和技巧所言,根据所学的人类心理学来说,很多人到了磨合阶段就会土崩瓦解,尤其是两个性格强势的人,那现在所说的结对编程还会变成单人编程。是不是出现第三个人调节会更好呢,三个人的团队复审效益会不会大于两个人的伙伴复审呢?而且对于编程来说,两人同时编程时程序质量会符合能力高的人的能力,那能力低的人对能力高的人的代码进行复审的时候会不会因为自身能力不足而无法判断出程序所存在的漏洞呢?
:土崩瓦解之后就瓦解,说明两个人不适合在一起做软件,不适合结对编程。这是这本书给我的答案。在制作软件的时候不单是要提升自身的能力,最重要的还是要找对正确的人,可以和我们一起进行软件的编写与开发。至于能力方面,两个人本来能力就不一样,分工自然不同,而且大多数的bug不是相互检查代码就能检查出来的,大多数都是在代码运行的时候检测出来的,所以能力高低并不妨碍两人结对。

原文地址:https://www.cnblogs.com/xuchunxiao119/p/7076250.html