软件工程实践总结&个人技术博客
软件工程实践总结&个人技术博客
作业摘要
| 这个作业属于哪个课程 | 2021春软件工程实践|S班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 总结软件工程实践 |
| 作业正文 | 作业正文 |
| 其他参考文献 | CSDN |
目录：
第一部分 课程回顾与总结
回顾问题
阶段收获
理解与心得
第二部分 个人技术总结
个人技术博客
第一部分 课程回顾与总结
回顾问题
问题一：
| 文字引用 | 对产品功能性需求：要求产品必须实现某些功能。 综合需求：有些需求并不是单单一个软件模块就能满足，例如，“购物网站必须在24小时内把货物发送到用户手中”，这个需求牵涉到软件系统、货物派送系统、送货部门、监控系统等不同部门的功能和执行能力。 |
|---|---|
| 问题描述 | 有定义来看，一个需求可以即归为产品的功能性需求又归为综合需求吧，这种的情况下应该归为哪一个分类？（书本P159） |
| 说法引用 | 网络上的定义和书本不同，百度百科中将软件需求做如下定义：需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。中度系统故障，造成软件使用障碍 |
| 尝试解答 | 在实现的过程中把重叠的部分归为综合需求，这样这个需求可以被实现的更全面。 |
| 继续分析 | 实际的小组开发中发现，我们的沟通时很灵活的，当提出一个需求时，大家会对此进行技术层面的构想，所以不应该将功能性和综合需求框定的太死 |
| 新问题 | 讨论需求时对产品涉及的各个系统应该就规划好，之后再进行需求扩充反而更现实？ |
问题二：
| 文字引用 | 主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他 |
|---|---|
| 问题描述 | 主治医师模式可以理解为只有一个“明星”，这是不是说明一般情况下明星模式优于主治医师模式？P98 |
| 说法引用 | 主治医师模式缺点：在一些学校的软工课上，这种模式逐渐退化成“一个学生干活，其他学生打酱油” 明星模式缺点：团队模式强调的是团队的作用，而不是个人的独角戏，这种模式显然违背了团队模式的初衷，效率也很低 |
| 尝试解答 | 两者其实很像，但由于明星模式表现突出的人更多，我觉得只要“明星们”团结一致，大概率下会优于主治医师模式 |
| 继续分析 | 明星模式也并不意味着表现突出的人更多，如果主治医师和助理们达成默契，也能成功 |
| 新问题 | 无 |
问题三：
| 文字引用 | 明星也是人，也会受伤，犯错误，如何让团队的利益最大化，而不是明星利益最大化？如何让团队的价值在明星陨落之后仍然能够保持？是这个模式要解决的问题。 |
|---|---|
| 问题描述 | 明星利益最大化是不是很能帮助团队利益的最大化，还是这个模式下明星利益化反而会降低团队的利益？ |
| 说法引用 | 明星模式优点：对“明星”个人的成长进步可能会有所帮助。 明星模式缺点：团队模式强调的是团队的作用，而不是个人的独角戏，这种模式显然违背了团队模式的初衷，效率也很低 |
| 尝试解答 | 以我的经验，我们开展团队合作时的模式其实可以近似为“明星模式”，一些大佬来完成重要的工作，其他人来协助完成，也就是所谓的打杂。所以我认为影响这个模式的反而是”大佬“和其他人之间的关系，如果明星利益太大，会使其他人发言权大大降低，所以应该采取一种“中庸”的状态。 |
| 继续分析 | 开发中应该考虑多个因素，在这种模式下的人团队团结度和工作热情度很重要 |
| 新问题 | 明星模式中，采取一种较均匀的任务分配方法，但是技术好的人会较快的完成自己的任务来做指导和支撑作用来实现团队利益最大化是否可行？ |
问题四：
| 文字引用 | PM通常也能写代码，能玩转Excel、PPT、Visio、甘特图，会PS，有文字功底，写的博客有人爱读，反正，总得有几招绝活吧！不用说还要有大量的阅读，对IT行业、用户心理、社会都要有广泛的了解。 |
|---|---|
| 问题描述 | PM的能力要求太广泛了，做好一个初级PM的切入点是什么？P198 |
| 说法引用 | 初学PM的建议： 1.基础的东西已经具备 2.要实实在在的参与一个产品的迭代 3.要多参考竞品 4.每增加一个功能，必须要问自己为什么 5.把每一个功能拆分到很细，比如登陆，账号用手机还是邮箱，为什么要用手机？为什么要用邮箱，你自己要搞清楚，虽然现在很多产品都首选手机做账号，但不是所有的都适合；密码字段，是用字符窜还是用纯数字，还是字符串+纯数字，是几个字节，需不需要特殊字符？大小写区不区分? 6.业务逻辑要清楚的列出来，你自己清楚了，才能给开发和测试提供炮弹 7.需求，大家都在讲需求，我就不强调，每个人有自己获取需求的渠道以及判断 |
| 尝试解答 | 之前我有参与西二的PM小组，PM开发项目是有一些固定的需求文档，每个公司也会有自己的一些模板，如果想当然的填补文档的内容就会偏离正确内容，所以我觉得PM这个职业的新手需要多注意细节，不能想当然。至于切入点可能要学习一些前辈的实际经验。 |
| 继续分析 | 经历一些实际的项目有助于PM整体能力的提升，而文档类的实践有助于对产品的分析，从文档切入也是个蛮好的开始 |
| 新问题 | 无 |
问题五：
| 文字引用 | 场景怎么写？首先针对每一个场景，设计一个场景入口（描述场景如何开始）。接着描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）。然后给场景划分优先级，按优先级排序写场景。 |
|---|---|
| 问题描述 | 对场景的重要性如何排序？P219 |
| 说法引用 | 基本型需求>期望性需求>兴奋型需求 使用需求的金字塔法则来表达，金字塔的最底层是基本型的需求，往上是期望型需求，最上面一层是兴奋型需求。 |
| 尝试解答 | 之前写过一些需求文档，虽然也是按照规则进行书写，但是我觉得还是参杂了许多的主观看法。 |
| 继续分析 | 无 |
| 新问题 | 是否可以按照覆盖用户面积大小以第一元素来分类，覆盖面积大的就更为主要 |
问题六：
| 文字引用 | 团队在Bug数量上上下下的过程中，要注意消灭族老的问题，让老的Bug数量为0，以防止一些问题拖而未解决，有可能掩盖深层次的设计问题，要尽早把这些问题暴露出来，一个招数是，划定一个时间期限，一定要解决在此之前发现的Bug。 |
|---|---|
| 问题描述 | 一些bug可以被认为不予解决,会不会因此出现Bounce问题？P335 |
| 说法引用 | 解决bug流程： 1、找产品经理确认 2、不予解决，关闭 3、要解决，写明原因给开发 |
| 尝试解答 | 我的理解是应该要有前瞻性，可能出现Bounce问题的bug就不能不被解决，但是也不排除判断出错的可能 |
| 继续分析 | 考虑现实条件的情况下，应该要解决所有能被解决的问题，实际开发会在ddl前按重要程度进行解决 |
| 新问题 | 无 |
阶段收获
1.需求阶段
需求阶段我们小组进行了很高效讨论，因为我是之后调配进入的逐梦校友圈小组，当时已经确定好要做什么项目，给出的功能大致如下：能让大学生有认同感的“校友圈"微信小程序，通过组队自习、拼车、拼单等搅局项目让同学之间快速融入，拉近彼此的距离，增加对学校的归属感。但是确定的功能板块应该越详细越好，比如我们打算设置“人品值”，根据用户的人品值来规范他在我们小程序的行为，这样这项人品值所牵涉的如何增值如何扣分所牵涉到的各个板块都应该提前商定好；还有消息聊天模块，我们根据自己的实际情况，认为是可以实现的，但是要付出很多的精力在这一项上，所以在需求阶段就有所保留（最后是成功实现了）。
2.设计阶段
设计阶段是我参与感很强的一项，因为之前我在西二的美工组呆过一段时间，就和几位小伙伴承担起了原型设计+UI设计的任务，因为时间有限，具体的设计参照了些很经典的设计模板，但是整体的色彩搭配花了些时间，经过这次实践，我可以说对原型和UI设计比较上手了。
3.实现阶段
这是我收获最大的一项，整体的设计要很有“方向感”才能有高效率，这次的开发历程对于我这个新手来说十分新鲜。我被分到了前端组，也是我比较感兴趣的方向，实现阶段我对整体页面布局和js比相比之前了解了很多。因为是大的项目，及时的和队友交流十分重要，我们不仅每晚都进行线上or线下的开会，还启动了github和雀语等多项工具，大家都彼此信任和鼓励完成了逐梦校友圈的实现。
4.测试阶段
这学期我们学习了软件质量测试，虽然我们对微信小程序的测试不算是很了解，但刚开始也不至于是没方向。我们进行了对接口核对模块的测试，还专门做了一个测试用数据库。单元测试确实很难设计，用例很繁杂，但是我们通过它找到了程序的Bug。更值得一提的是，这阶段我们实行的是面对面编程，效率确实很高。
5.发布阶段
这一阶段也并不轻松，因为微信小程序的上线需要企业证明之类的证件，这也意味着我们基本不可能在整个平台上线，所以我们只能扫描体验，这部分我参与的较少，除了上线问题也没有大问题存在。
理解与心得
在α阶段我对一个其他专业的人说“等软件工程实践这门课结束后，我一定会很珍惜自由的生活”，但发现结束后就是期末考了也无法自由。最后一次答辩后，我意识到逐梦校友圈这个项目的完成度是出乎我意料的高，这离不开我们每个人的付出。我们组好像真的没有偷懒过，在α和β阶段我们每天十点都会准时进行线上or线下的开会，然后明确第二天任务后，又投入开发。刚开始，我对于整体开发几乎什么都不懂，分到任务后就自己开始微信小程序的前端的学习，并且边学边打代码，这种学习效率确实很高。期间前端的队友们都给予了我很多的鼓励与帮助，让我觉得放手去做就好。
