软件开发流程

软件开发流程/生命周期

软件生命周期

软件定义(需求讨论确定、原型效果图制作)、开发实施、测试与bug修复、上线、服务与更新、停服。

以我当前的经验或者认知,软件服务公司给别人做产品的具体流程大致应该是这这样的:

  1. 需求分析阶段(第一版功能、不可缺少的必要功能)。//沟通,与确定。考虑产出需求文档让客户签字确认。

  2. 仿真原型的设计制作。方便展示大致的界面和交互效果。

    • 原型通知到领导并交由客户进行查看复审(该有的功能是否都有体现,有没有漏的,有没有明显不需要的或者流程错误的),然后提出修改意见。
    • 技术人员有选择的修改原型并跟用户达成共识顺便通知领导。
    • 原型最终确认并可以同时开始数据库表规划,技术方案设计。
  3. 效果图设计与确定,即软件界面的定义。

    用户确认效果图或提出修改意见(仅涉及元素显示效果变动,如果涉及功能的修改添加请和老板沟通)

  4. 开发阶段

  5. 内部公测阶段。

    • 内部测试后,再与客户共同体验测试。
    • 对发现和提出的问题进行修改优化再测试。
  6. 宣布正式开服,开始服务。

  7. 维护、迭代

  8. 停止更新

  9. 停止服务

以上,最重要的是多和客户沟通,有选择地遵从客户意愿,原型/效果图,在经过前后端技术人员确认后,必须让客户看到,确认达成共识以便有共同的产品期望

1、人们为了解决现实社会和生活中的各种问题,要求助于软件。软件开发团队为了做出能解决问题方便他人的软件,则需要了解人们的需求。

2、软件团队和客户代表要在需求阶段,要把需求的方方面面定义清楚,不出现模棱两可的情况,起码要清楚软件必须实现哪些功能。

3、软件开发前,必须要弄清楚:软件的相关角色想从软件中得到什么。

4、软件开发的过程,就是“用户最需要的东西”在下面这一链条中传送、转换、实现、扭曲或丢失的过程:

image-20210427154605257

5、与其坐在办公室里想象如何给老年人设计手机,不如去和老年人生活几天,从生活中得到体会和需求。开发人员自己开发的产品一定要在产品上线后,自己在实际环境中,作为一名普通用户亲身体验一把,这样也许就能发现许多待优化的地方,或者别的什么新发现。

6、不要让用户在各种菜单中幽幽暗暗反反复复地寻找某个功能,软件界面的目标之一是让用户在使用中“平平淡淡从从容容才是真”。

7、大众浏览网页时的眼球移动轨迹或叫视野专注区域变动轨迹:F模式。

参见:https://baike.baidu.com/item/F形状网页浏览模式/15686166?fr=aladdin

原文:https://www.zdnet.com/article/eye-tracking-web-usability/

软件产品的原型

原型反应了产品能做什么、不做什么,页面元素显示什么、不显示什么,具体某一功能上的交互逻辑或顺序是怎么的;这是最直观形象的“需求文档”展现形式。

原型和效果图都是对软件产品未来样子的描述表达。通常原型可以不那么逼真,只是页面展示信息和交互的大概模拟,效果图即产品最终的样子。软件产品比较简单的话,原型这一步非必须,可以直接由需求文档,制作效果图。

常用的原型制作工具:墨刀。

在需求沟通确立阶段,需要大伙儿一起明确需求、交换意见、希望各方对目标产品达成统一的认识与期待。但这只是口头或者脑袋里交换意见达成一致,太过抽象,而且交流过程中,每个人脑子里对所讨论东西的想象,很可能与对方表达出来的东西、或者已经商量好的共识是有较大差距的,因此,有必要将这些抽象反映到实实在在的可视化原型上。

有了她,大家就能更清晰直观的认识到需求在软件产品上到底是怎么体现的,因为是唯一可视化的。又或者发现跟自己想象的有什么不一样的地方,或者发现自己或者别人有漏洞的地方,进而促进团队之间达成更进一步的统一。如果产品功能简单,界面内容并没什么复杂的,也许一个对大家共识的记录文档或者思维导图就OK了。即使需要原型,这些文档或者思维导图也是必要的,起码能起到备忘或者说原型出来前的再次讨论记录不是吗?

软件产品的界面设计,即制作效果图

效果图即产品最终的样子。前端开发人员严格依此来进行工作。

效果图制作就是在这个软件产品原型的基础上打造用户视觉体验,如背景色,按钮大小形状,文字大小颜色等,即在“显示什么,不显示什么,做什么,不做什么”的限制内,发光发热,打造更优美、更流畅的用户视觉体验和交互体验。
原型出来后,必须由前后端人员审查确定、领导审阅、客户审阅通过后,再交给界面设计人员进行效果图设计。

效果图出来并经公司和客户确定后,前端就可以开始工作了。(后端可能要开始的更早)

效果图要保证没有没有数据或交互上走不通不合理的地方,如果原型不能导致后端正常开展工作,那项目经理和产品(或UI)之前的沟通工作需要质疑。

开发人员的个人流程

  1. 理解问题或任务
  2. 提出多种解决办法并估计工作量
  3. 其中包括寻找以前的解决方案,因为很多工作是重复性的 (模式)– 例如实现某些类似的web页面。
  4. 与相关角色交流解决问题的提案, 决定最终方案。
  5. 执行, 把想法变成实际中能工作的代码。
  6. 修复缺陷, 对结果负责。

团队有什么特征

  • 团队有一致的集体目标, 团队要一起完成这目标。
  • 团队成员有各自的分工, 互相依赖合作, 共同完成任务。

在团队工作中, 稳定、一致的交付时间是衡量一个员工能力的重要方面。

PM

Product Manger:产品经理——正确的做产品。核心要求是,根据市场和用户需求,协调各部门资源,正确地把握产品定位和方向,解决用户的痛点,持续优化问题。

Project Manage:项目经理——正确的做流程。对项目流程负责,即项目从立项到上线按时完成。正确的协调团队;内部外部,调配各部门资源和时间,有效进行风险管理,保证一个项目顺利按计划结项,是一个项目经理的核心价值。

Program Manger:微软的职位名称。微软产品团队三组鼎立的角色分配就是PM、开发、测试。PM做开发和测试之外的所有事情。PM要在整个项目的生命周期管理风险。PM经常和人、管理流程打交道,经常处理“不确定性”,在反复多次对“不确定性”进行处理的过程中,一个团长的风格和习惯就慢慢养成了。PM要有能够理解别人的处境、心理、动机的能力——同理心,能突然把自己变成一个完全不懂技术的菜鸟用户,从用户的角度来看问题。如果一定要说专业能力的话,PM的专业能力就是理解和表达。PM要能够分析出重点,找到优先级、做判断、做决定……PM 有一个任务就是:创建并维护软件的规格说明书,让它编程开发/测试人员及时准确的指导,而不是障碍。

PM的出现使得有专人负责开发/测试之外的许多事务和项目进度的管理,让开发和测试人员专注于技术方面的工作。总之,PM做开发和测试之外的所有事情。

项目的大小怎么统计呢?

我感觉用功能点比较好。//感觉功能点划分要尽可能小,小到很具体,具体到不能再拆分。

不用时间是因为,软件时间的估计,事实上是多个估计值的乘除法(估计的需求,估计的需求复杂度,估计的技术难度,估计的人员能力),如果这些估计都差一两个数量级,那么我们最终的结果就会偏离十万八千里。

论一个项目周期中的各种文档

需求文档

面向软件开发团队,以及软件最终所有者。不管什么文档类型,要能说明,开发的是什么,有什么功能,功能描述不要模棱两可,一定要清晰没有争议。

建议每个项目的需求文档,都保持最新的,持续维护的。不然一个老旧的需求文档,可能造成的问题,比如某天口头上,A主导定下了一个需求,B理解记忆的和C理解记忆的不一致,且当时以为都是一致的,那后期出现不一致,没有个公共的参考判定。这就导致可能又得各自回顾梳理一遍。又或者,开发完成后,测试时,发现有个功能和 “当初说好的” 不一致,但是【当初】的这个东西要是没个文档记录,这就很难受了。

软件功能说明书(functional spec)

面向软件用户(使用者)。主要用来说明软件的外部功能, 和用户的交互情况 (把软件当作一个黑盒子)。

用户的角度描述软件产品的功能, 输入,输出,界面, 功能的边界问题, 功能的效率问题(对用户而言), 国际化, 本地化异常情况, 等; 不涉及软件内部的实现细节。

软件技术说明书/设计文档(technical spec/design doc)

面相开发运维人员。主要用来说明软件内部的设计 (把软件当作一个透明的箱子)。

数据库表结构说明文档

文档类型:.txt、markdown、pdf、doc,都行。

存在的意义或用处:

  1. 展示有那些table,即系统涉及的数据以及相关关系。
  2. 记录各数据表的结构即有哪些列名或属性,后续可以按此文档建立完整的数据库。

接口(API)文档

系统提供的用于获取数据,更新数据的接口。

文档类型不限,也可以是线上接口文档地址。

如何衡量一个软件工程师的专业水平?

绝大部分软件工程师的工作成果都是可以公开的,你参与的产品用户评价如何?市场占有率如何?对用户有多大价值?你在其中起来什么作用?行胜于言,这些实际的工作成果,是最重要的评价标准。

工程师应该在实际工作中不断学习和不断成长,根据自己的情况选择在哪个方面追求“专和精”,在哪几个方面达到“知道就好”的水平。

那么怎样提高技能呢?答案很简单,通过不断的练习,把那些低层次的问题都解决了,变成不用经过大脑的自动操作,然后才有时间和脑力来解决较高层次的问题。


部分摘录自:《构建之法》


更新于:2023.5.26

posted @ 2023-05-26 10:57  AI大胜  阅读(47)  评论(1编辑  收藏  举报