• 软件工程——个人总结


    个人总结

    团队名称:

    _源计划

    项目名称:

    毕业设计互选系统

    学习和使用的新工具:

    • Dreamweaver CS6
    • Microsoft SQL Server Management Studio 17

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

    • ASP vbscript
      它是asp动态网页默认的编程语言,配合asp内建对象和ADO对象
    • html5
      html作为网站的前端开发是必不可少的,我们所需要的页面设计均适用html
    • 墨刀
    • Markdown语法
    • Dreamweaver网页制作平台

    统计一下,你在这软件工程实践中,完成了多少行的代码

    教师端的功能,除去部分框架的内容,编写代码1300+

    学习和掌握的新方法

    • Markdown排版
    • 如何在dreamware中建立站点
    • 如何在自己建立的网站中链接数据库
    • 如何配置自己电脑的iis配置

    总结与展望

    记录自己在软件工程课程上的经验总结:

    在这个学期的软件工程上面,因为是团队作业,所以感觉到了团队的力量,如果说一个人的能力有多优秀那么也是没用的,只有大家一起出力,劲往一起使,才可以有更好的东西出现,就像我们这次的团队作业,最开始团队里面的每一个人都有不同的想法,所以更加需要沟通,当解决这些问题的时候一切问题都迎刃而解了。

    对于下一届的学弟学妹你有什么建议和告知呢?

    • 在选择项目的时候,需要根据自己的实力进行选择,如果选择的过难,那么可能会出现无法完成的状况,而选择的太简单,则无法体现自己的实力,所以在选题时要慎重。
    • 选择好自己的项目初期,一定要多和自己小组的成员一起讨论,沟通彼此的想法,从而找到一个最优策略。不会在后期推倒自己前期所做的东西。
    • 确定好自己怎么做项目以后,就要努力去做,不要三天打鱼两天晒网,否则一旦到需要答辩的时候,会很紧张,时间不够等。

    分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》团队合作的阶段,你们团队经历过么?最后到达了哪一阶段?

    • 萌芽阶段
      在最开始接触到这个项目的时候,大家因为比较有礼貌,所以不会轻易的表达自己的想法,尽量保持着中立的想法。同时自己都有自己的盘算,并且想法各异。
    • 磨合阶段
      经历了最开始的萌芽阶段后,大家变得熟识,开始大胆表达自己的想法,组长则开始总结大家的各种想法,从而去找到最好的办法。
    • 规范阶段
      大家开始经过讨论找到最优解决办法,并开始做自己的工作。
    • 创造阶段
      大家开始完成自己的工作,并自己进行完善,不在需要一一指导。

    补充

    1.在看到96页的代码复审的时候,像书上所说的那样如果进行复审的目的之一为找到可能需要改进的地方的话 ,查了有关资料(反复审查当然是为了确保质量,保证不出现更多的错误和异常,软件复审就是以对质量保证为目的的。软件复审包括了对需求文档、详细设计、数据库设计、功能设计、编码功能实现及质量、错误跟踪等的审查,以避免使用过程中出现更多的差错)那么我们每个人都有自己的想法,是不是会产生一些矛盾或者因为想法不同而导致功能不同(就像1000个人有1000个哈姆雷特),虽然最终可能都满足顾客的需要,但是思考的方向却不一样,是不是会造成团队内部一次次的修改,一次次的改变,从而资源浪费呢?本来是可以一个人做的,但现在需要五个人一起来,不一定做的会比一个人快。

    每一个人他对于这个项目的考察方式不一样,他会处于不同的角度去考虑这件事,或者是考虑这个东西是否是有前景的,以及他有那些问题,虽然说每个人的想法不一样,但是经过讨论后,会有隐藏的点被发现。

    2.在看到书上面94页的瀑布模型的时候,举到的例子(顾客在安装整体出来后还想要添加另一项功能)查了资料发现(瀑布模型有以下缺点:1.各个阶段的划分完全固定,阶段之

    间产生大量的文档,极大地增加了工作量。2.由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。3.通过过多的强制完成日期和里程碑来跟踪各个项目阶段。4.瀑布模型的突出缺点是不适应用户需求的变化。)如果按着客户的需求设计一个软件,那么就像书上的例子一样可能会在交付最终版本的时候,客户想起来还有遗忘的东西没有加进去,是不是就有代表这整个要重新设计或者小部分重新设计?这是不是也说明在做需求分析的时候不到位?如果在事先就考虑到这些问题是不是就不需要返工了?那瀑布模型是不是完全不可取?
    在最开始的时候,设计这个产品的人是听了客户需求,由此对这个产品进行设计,可能在这个过程中开发人员会根据自己的理解来补全这个项目,瀑布模型更加适合一些比较不灵活变动的项目,并不是说他一无可取。

    3.在看到书上第106页中说道“如果团队成员能主导任务的估计和分配,他们的能动性得到较大的发挥”,那么在团队里有组长,还有组员,如果每一个人他们的想法不同是不是会造成一些分歧,并且在位团队的一员怎么才能做到主导任务的估计和分配?但我认为有的时候由组长统一调配的话,组长会清楚怎么样的整体布局才是最好的,甚至让每一个人起到最大的最用。就好比一个建筑队,如果没有队长的整体布局,那么即使每一个工人想让自己干什么,但因为合作不顺利反而会推迟工期。

    在一个团队组建好以后,每一个人都应该明确知道自己想干什么,自己能干什么,向大家表达自己的想法,人员如果全部由组长决定的话,如果有人分到了自己不会的,或者是说自己不了解的领域,可能会因此做不下去。由此只有每个人融入进去,才有更大的收获。

    4.在书本257页上面写道“按测试的目的分类有:功能测试、非功能测试”那么一个软件有千百种功能,如果对已经差不多的软件进行测试,怎么才能具体的将基本功能和非基本功能进行区别?

    根据团队对于这个项目的定义以及想法,逐步确定。

    5.再看到书本183页上面写着“PM要能够分析重点,找到优先级,做判断,做决定……”那么作为一个PM,怎么才能更好的分析出重点?有些问题可能在你看来很重要,但是别人却不这样认为。(比如你饿了,你认为吃饭很重要,但别人是饱的,他不需要吃饭,那他就会认为吃饭这件事情不重要。)每一个人的想法是不一样的,那么怎么能保证一件事情的重要程度或者紧急程度是一样的呢?

    当碰到团队的意见不一致的时候,更多的是需要交流,作为一个团队,不可能在不交流的情况下就完成一个项目,最开始每个团队肯定都有磨合阶段,我们所有的东西不肯能一蹴而就,我们需要的是讨论,以及达标自己的意见。

    总体想法

    个人的力量,有限
    大家的力量,无限

  • 相关阅读:
    论文连接
    MySQL中的datetime与timestamp比较
    查看挂载情况
    insertable = false, updatable = false的使用
    umount: /home: device is busy
    LVM
    erase-credentials配置
    <T> List<T>前面<T>的意思
    Java 内部类 this
    AuthenticationManager, ProviderManager 和 AuthenticationProvider
  • 原文地址:https://www.cnblogs.com/erdai/p/7061665.html
Copyright © 2020-2023  润新知