其他分享
首页 > 其他分享> > 尾声

尾声

作者:互联网

这个作业属于哪个课程 2021春软件工程实践
这个作业要求在哪里 作业要求
这个作业的目标 课程回顾与总结 个人技术总结

第一部分:课程回顾与总结

问题回顾
问题一:

“不局限于某一种软件技术(如编程语言),而是着眼于软件开发的流程,这样,开发不同应用的软件工程师可以互相比较。”
我不认同这个说法。对于不同应用的开发不应该只着眼于开发流程,而不重视软件技术。如果使用框架技术在设计的阶段就能剩下大量时间,代码编写和报告编写时间也能相应缩短,所以我认为软件技术也应该重视

问题二:

在4.5.2章节中提到
在开发层次,结对编程能提供更好的设计质量和代码质量,两人合作解决问题的能力更强。两人合作,还有相互激励的作用,工程师看到别人的思路和技能,得到实时的讲解,受到激励,从而努力提高自己的水平,提出更多创意。
我想到的是如果一方由此产生了对“伙伴总能找到bug”的依赖感而怠惰;或是两人的讨论无法取得统一意见而拖累项目进度,对双方的提升也不能有效体现,这是否也是结对编程的“双刃剑”呢

问题三:

“不分主次,想解决所有依赖问题:另一种极端是过于积极,想马上动手修复所有主要和次要的依赖问题,然后就可以“完美地”达成最初设定的目标,而不是根据现有条件找到一个“足够好”的方案。”
我想到的是,平时在写代码时,发现了bug不都是立马排除、解决的吗?如果只解决主要问题,那么剩下的问题将来产生的隐患或许更加危险。
在查找相关资料时也看到这样一句话,我认为所表达出的意思应该是相同的:
“很多时候对软件造成的影响可能由一系列相关或者不相关的程序缺陷等综合因素积累导致。”

问题四:

在博客《项目管理的目标和细节》有这段话
“项目管理的最高目标并不是要保证让 “ideal” 和 “actual” 的线吻合, 因为项目中出现意外和需求的变化是很正常的事。 项目管理的目标是处理这些意外和变化, 让软件能如期发布, 尽量满足客户的要求。
这段话的意思是项目管理的目标是最终让软件如期发布就好了吗?若在开发过程中发生意外或需求变化,管理者处理之时发现剩余的开发时间不足以让软件如期发布。
为了避免这种情况,管理者如何保证项目在最低的“ideal”标准,与“actual”最好地匹配?

问题五:

问题五
博客《用户体验和质量》提到
“好的用户体验当然是所有人都想要的, 如果它和产品的质量有冲突, 怎么办? 牺牲质量去追求用户体验, 能变成利润么?”
这句话在原文是应该更加关注与用户体验的意思。(在博客后文的例子中可以看出)
我想到的是:用户的体验与产品质量的比重在从 软件发布到后期维护更新 的比重是否应该有变化?
新上架的应用应当尽量偏向于功能质量,以实用性来吸引用户,而在之后的更新时则优化用户的操作,维护好用户的体验。

在各个阶段的收获

需求

需求分析是直接点出软件要解决的问题,要服务的人群,是一个实质性的分析过程,在这个阶段需要慎重仔细的分析用户群体和软件功能的交集。

设计

项目界面是直接展示在用户眼前的,设计阶段最好还是要有有设计技术经验的人员来主要负责设计,像axure这样的专业设计软件必须要使用上,一些界面布局的规则(内边距等)也最好都定下来。

实现

实现项目的技术需要实打实的掌握,在开发中我们也都学到了在实践中学习知识这项能力。

测试

一个项目阶段性的进行整体的测试修复,编写完一个部分的功能模块就同步去测试,尽量避免bug的累积

发布

这个阶段主要是收集用户的调查反馈报告再进行修改,能够让项目更贴近用户。

心得:

在这门课程的学习中,先是个人开发,再结对开发,团队开发,自己也学到了很多技术上的新知识,但更多的是感觉自己对于合作的了解更多了,团队的合作让问题一个个的解决,和团队一起成长,一起进步。

第二部分:个人技术总结
使用Retrofit进行网络请求

标签:结对,项目,尾声,用户,问题,开发,软件
来源: https://www.cnblogs.com/hanma/p/14942816.html