初识应用软件开发

什么是应用软件开发

要想理解什么是应用软件开发,我们必须理解什么是应用软件。

维基百科上对应用软件的解释是

An application software is computer software designed to perform a group of coordinated functions, tasks, or activities for the benefit of the user.

翻译一下就是 应用软件是被用于完成一系列相互协作的功能,任务或活动来满足用户需求的计算机软件,这句话中有几个关键词,一个是 coordinated,一个是 the benefit of the user

  • coordinated
    coordinated这个单词本意为协调的,这里我想了很久,最终翻译为相互协作的。这个单词想表达的意思是一个应用软件要实现的功能应当是有一定相互关联性的,一个应用软件同时被用于完成n件事,这样不仅会使得应用程序的稳定性降低,也会让程序显得臃肿,不够聚焦。但现在有很多厂商为了商业利益,一个软件提供了多个不相关的功能,给用户的体验十分不好。
  • the benefit of the user
    用户的利益,这里指的也就是用户需求。应用软件开发出来一定是为了满足用户的某个特定需求,可以解决用户的痛点。如果一个应用软件仅仅是开发人员凭空想象出来,并没有去真正的了解过用户是否需要这样的一款软件,那么这个应用软件极有可能就是失败的。

应用软件开发就是应用软件从想法诞生到废弃的整个过程。根据我目前的经验,这个过程被分为了需求获取,开发规划,需求分析和设计,交互和UI设计,编程实现,软件测试,软件发布,维护迭代和最终下线。很多开发人员对软件开发的理解仅仅停留在编程实现这一步上,这是不对的,相反,在整个开发流程中,编程实现仅仅是其中一部分,其他的部分也都需要开发人员的积极参与。这些过程中,限于本人当前的水平,部分过程我里了解不多,因此接下来仅选择和开发人员相关的几个步骤做一些说明,其他过程仅做简单介绍。

应用软件开发流程

需求获取

需求永远是应用软件开发的驱动力。需求的直接来源有用户,客户,市场人员,产品经理等。软件开发人员一般不需要参与到需求的获取中。

开发规划

这个阶段技术经理,项目经理,产品经理等根据需求的重要和紧急程度以及市场或客户的要求,对接下来的流程进行时间,人员,资源等方面的规划。

需求分析和设计

产品经理在收集到原始的需求和开发安排后,会对需求进行一系列的整理和分析,确定相关人员的工作安排。在产品经理对原始需求进行初步的分析后,一般会召集交互设计师,UI设计师和软件开发人员等进行需求评审。在需求评审中,作为软件开发人员,我们要重点去理解需求,根据自己以往的经验去判断需求点是否具有技术可行性,对于不可行或有缺陷的需求,我们应该尽早指出并说明原因或修改方法,否则越往后拖代价越大。

交互和UI设计

在需求明确后,交互设计师会根据需求,确定软件的交互逻辑。交互设计指的是确定用户与软件的接口,即用户如何去操作我们的软件。交互设计不好的软件,用户会觉得难用甚至抗拒使用。在这个阶段,交互设计师在完成初步的交互设计后,会召集产品经理,UI设计师,软件开发人员,测试人员等进行交互评审。作为软件开发人员,我们需要善于发掘交互设计中的问题,提出自己的意见和建议。对于不合理或难以实现的交互,我们也要及时的指出。

确定交互设计后,UI设计师会在交互的基础上,设计整个软件的界面效果。UI设计师也会在完成视觉设计后,召集举行产品经理,软件开发人员和测试人员进行视觉评审。我们在评审中需要重点去完成以下几件事:

  1. 确定视觉效果的可行性。对于某些难以实现的效果,我们可以跟UI设计师进行讨论
  2. 确定需要UI设计师提供的资源,包括图片,字体等。对于明显的图片等,UI设计师会直接给出,但有些控件或效果可能需要UI设计师提供特定的UI资源,我们可以向UI设计师提出我们的需求。如对于安卓工程师,他们实现按钮边框会要求UI设计师提供点九图,而对于PC应用软件开发工程师,可能就无法使用点九图。
  3. 指出视觉效果中不合理的地方。UI设计师在UI设计领域往往比我们会专业很多,但也存在他们会遗漏的点,对于看上去奇怪的地方,我们要大胆的提出。

在UI设计完成后,UI设计师会输出视觉文档给我们。一般来说主要包括视觉,标注和切图三部分。

  • 视觉往往是软件可能出现的界面的图片,是一个总体的概览。
  • 标注则一般是一个网页,网页上会对软件的各个控件的位置,效果等做出标记,这个也是下一步开发中最常使用的部分。
  • 切图,这里面主要是一些开发中需要用到的图片资源。如果开发中遇到缺少的,我们可以再和UI设计师沟通,获取我们所需要的资源。

编程实现

这是我们软件开发人员最熟悉的一步。在这一步,我们会根据产品经理的需求,交互设计师的交互和UI设计师的UI,实现出具体的软件产品。针对三方的需求,我一般会把我的开发也分为三个阶段。

  1. 功能实现
    在这个阶段,我会去实现软件的关键功能,并不关注界面。这个时候更类似于开发SDK,可能仅有一个简陋的界面甚至是一个命令行程序。这样做的好处是我们可以在需求评审完成后就可以着手去进行这一部分,而不必等到UI确定后再开始。
  2. 交互实现
    这个阶段主要去实现一个界面的操作逻辑,如按钮点击效果,页面跳转等。这个阶段我不会去关注UI,不去关注复杂的控件效果,只使用UI框架提供的最原始的控件,这样可以让我们更专注程序的逻辑。
  3. UI美化
    这个阶段就需要根据UI设计师提供的视觉文档,去实现界面效果。我们可能会利用诸如Qt中的QSS等技术去对控件视觉效果做调整,对于部分复杂的控件,我们还需要去实现各种自定义控件去替换掉上一阶段的占位控件。这个阶段根据开发人员的水平和经验,耗费时间差距会很大。

除了软件的代码编写以外,我们还需要完成以下工作。

  • 程序的自动构建。为了便于持续集成和发布,我们需要利用Jenkins等工具,对我们的程序进行自动构建。
  • 国际化翻译。对于大部分企业应用软件,面向的用户范围会很广,其中一个点就是用户可能会来自多个国家。因此国际化翻译是很有必要的一个步骤。我们一定要力求翻译准确,这一点对于绝大部分软件开发人员都比较难。部分公司会有专门的文案人员负责这一块的工作。如果没有文案人员,我们可以去寻求产品经理等的帮助,切忌自己随意翻译。同时我们还需要考虑不同语言文本长度导致的界面问题。
  • 安装包制作。很少程序会以一个压缩包的形式发布,更多的是下载一个安装包进行安装使用,因此我们需要利用nsis等工具制作程序的安装包。
  • 功能和UI检视。在程序开发完成后,我们需要通知产品经理和UI设计师进行功能和视觉效果的确认,确保实现与他们的预期一致。

软件测试

一个软件开发完成后,为了保证用户使用过程中的稳定和正常,我们需要先将软件送交给测试人员进行测试。一般来说,测试人员在参加交互评审和UI评审后便会编写测试用例。

在送测前,我们需要对功能点进行自测,确保基本功能可用,测试人员将会对我们的软件进行一个更加全面,强度更大的测试。自测通过后,我们需要在jira等平台上填写送测申请,写明送测软件,测试范围,测试环境等信息。在测试开始前,我们必须提前告知测试人员在发现bug时需要记录的现场信息,一般包括日志文件,crashdump文件等,并告知如何获取这些现场信息。

在测试过程中,测试人员会将发现的问题记录在Jira等平台上,当我们收到测试人员反馈时,最好第一时间前往查看bug现象。对于测试人员描述不清楚的地方,及时与测试人员沟通或请求测试人员进行现场复现,便于我们分析和定位问题。测试人员在完成所有测试用例的测试后,会通过邮件等方式通知我们送测情况。

对于测试人员反馈的问题,我们首先要进行分析,确定问题模块,需要的话请求相关人员的协助,但切忌随意甩锅。对于部分难以复现的bug,我们也可以寻求测试人员的帮助,让他们进一步明确复现路径或在复现时第一时间通知我们前往现场。若反馈的问题较多时,我们需要根据任务的重要和难易程度进行合理安排,优先解决简单的,再集中精力处理重要且复杂的,对于不重要且复杂的,我们甚至可以和相关人员进行协商,讨论下是否有其他代替方案或取消。在处理问题的过程中,我们需要及时对问题进行更新,包括设置问题的状态,对问题进展进行记录等。

在问题修复后,我们需要将问题状态修改为测试中,交给测试人员在下一轮测试中对问题进行验证。若问题确实无法复现,测试人员会将问题标记为已解决,否则会重新打回,我们需要再次验证,查看是否错误理解测试人员的意思,或还有其他原因导致这个问题未彻底解决。

软件发布

若我们的软件在经过若干轮的送测后测试通过了或无严重问题时,那么便需要进行交付和发布。我们通知发布人员在发布前需要自己要发布的版本,我们可能需要对这个版本进行一个长期保留,以便后期用户反馈问题时能找到出问题的版本信息,进行问题修复。

维护迭代

软件发布后,便会有各种用户在各种环境下使用我们的软件,不可避免的会发生一些bug。我们可能会经常受到来自于客户或市场人员的问题反馈。我们在收到用户或市场人员的反馈后,需要及时和反馈人员沟通,详细记录问题发生的现象,环境等信息,必要时可能还需要用户提供问问题发生时的硬件设备。对于部分紧急或疑难问题,我们可能还需要出差去用户使用现场进行问题排查。在修复问题后需要通过OTA等方式为用户升级软件。

除了问题以外,用户等也会反馈一些新需求,这就需要再次进行需求分析,交互和UI设计,编码实现,软件测试等一系列步骤,进行版本的迭代开发。

最终下线

在经过一段时间后,软件可能已经不再被需要或需要开发新的产品进行替代,这时软件就需要进行下线。很多软件的下线可能是悄无声息的,也有部分软件下线会由运营人员发布一个通告。

小结

由于本人工作时间也不长,经验不足,很多过程仅能简述一下,无法深入讲解。但我们还是能发现,整个软件开发流程中,很多过程都需要软件开发人员的参与,也需要和很多人员进行沟通协作,我们需要理解并明确我们在每一个过程中的角色和职责,这样才能推动项目的有序进行。