软件项目开发工作流程

大家都知道,整个手机应用程序设计和开发是一个巨大的工程。想开发一个相对好的应用。至少3到6个月。

如果你想做一个应用程序,必须提前沟通,初步结果证明这个程序实施的有效性,并确定应用程序属于哪个类型。在功能和实现价值基本敲定的情况下，开始进入项目评估阶段。这个时候产品经理会根据之前商定的功能进行价格和工期的评估，确立一个初步的项目排期。在系列的前期工作得到客户认可的情况下，签订合同正式开始项目。项目开始各个部门就开始项目的碰头会议，设计部门开始设计UI（产品界面）和UE（用户体验），针对产品开展创意设计，形成初步的效果图，经过首次客户的确认。

研究和开发APP需要经过一段时间,当形成基本产品后,然后进行测试。测试合格后,与客户沟通确保没有错误,开始验收。由客户进行测试，提出修改意见。客户验收合格满意后，开发者会将app交付客户，客户根据APP预估的访问量、用户数量等来进行服务器的选择，服务器可以自己购买管理，也可以购买后托管，也可以直接租赁。服务器的好坏也直接影响APP用户体验的好坏。

开发APP需要很多的流程，多个分工，由此看来不是一件简单的事。

IT 的管理者很清楚的知道，在不远的未来信息化将成为业务的运营中心，问题是信息化自身又该如何运营管理。

IT 团队需要了解业务部门的需求，然后设计并开发一个个的信息系统。这些信息系统就像工厂里的生产线一样，将生产出真正对业务有所帮助的数据和信息。

IT 的管理者就像是这个工厂的厂长，需要能够敏锐的 发现 业务需求，经过系统化的 设计 并且有效的 协调 人员去实施。此外，还需要高效率的运维 保障 已上线的信息系统稳定运行。

这些要求可不少，IT管理工作看起来就像是在运营一个工厂，并且在这个信息化正在逐步走向成熟的年代，可以说每一个IT管理者都是一个创业者。

管理IT，就像管理一家企业或医院一样，没有什么本质的区别。需要面对的都是那些像幽灵一样，隐藏在各个环节中的问题。我们不太可能真的去一个一个的解决这些看起来千头万绪的问题，因为这些问题很有可能是环环相扣的。

但很快会发现，肯定有那么几个问题是元凶，是导致这千头万绪的根源，只要解决这几个问题，剩下的症状就会自然的全部消失。而问题的关键是，你怎么找到这些根源。

即使问题再难缠，只要能够摆在面前，相信总有办法解决。但是这些问题总是像丛林中的幽灵一样，若隐若现，躲闪在丛林之间。

这些问题似乎就在那里，又若隐若现，有时还会投鼠忌器，所以请允许我用幽灵来形容这些管理上的问题。但是这个世界上肯定不存在幽灵，其实是我们对整体工作的认知不够系统化，所以才给了幽灵们能够躲藏，能够隐蔽的角落。为了找到这些“幽灵”，IT管理者们需要一个系统化的方式。需要一个系统化的方式去认知IT管理工作，否则幽灵们就会出现。

曾经信息化技术有着一些神秘 的技术色彩，甚至对很多人来说还有一些魔法般的神奇。但是，现在这些都不重要了，因为人们不再关心是你怎么实现的，而是关心你究竟能给我带来了什么。

之所以没有像吉普赛人的巫术一样消失，是因为信息化技术真的能够给人们带来价值，要么是提高了业务的效率，要么是减少了浪费。所以，IT为什么存在？答案只有一个，就是为业务创造价值。

IT 的运营是一个为业务创造价值的过程，这个增值的过程是IT团队一系列的输入、转换和输出的行动集合。每个行动都对业务客户产生增值行为，从而最终为业务客户创造价值。

让我们用这样一个脉络去认知IT的运营过程，方向是：首先得了解为谁创造价值。输出是：价值是承载在输出上。过程是：输出是被怎样一个过程创造出来的。输入是：需要输入什么样的原料才能满足过程。所需要的资源是：像生产过程一样，IT的运营过程同样需要投入资源。要遵守的规则是：在这个过程中，需要遵守的规则有哪些。

                           

方向：IT的运营是一个为业务创造价值的过程，重复一下，是 为业务创造价值 。所以，现在创造价值的方向就非常清晰了，要以业务客户为核心。有两点具体的体现：第一是增值的过程是以业务的需求为源头，进行设计和规划。第二是对IT工作的测量指标有很多，但是最高级别测量是客户的满意度。

价值和输出：所谓“输出”指的是增值过程最终输出的产品或服务，而价值一定是被输出承载的。价值一定是摸得着，看得见的，就像人们认宝马的汽车 *** 控性很好的时候，宝马公司的价值是依托于该公司最终提供给你的宝马汽车之上。信息化的价值是通过为业务部门提供了一个一个的信息系统以及服务而体现的。

过程： 为客户创造最终价值的，不是一个活动，也不是一个流程，而是由各个流程组合在一起的整体价值链。 例如、需求分析、审批、设计、开发、测试、部署。又如、申告记录、分派、处理、满意度调查。

输入：根据输出和价值的要求，IT团队需要外部提供什么样的资源输入。

资源：IT的增值过程需要投入直接的资源，包括：人、资金、软件、硬件、数据。当这些资源不足的时候，则直接体现为增值活动的产能不足。

规则：在很多行业中都有相应的规则要求，例如、银监会对商业银行的IT管理要求、保监会对保险公司的IT管理要求。对于这些政策性的管理规则，等于是给IT管理工作圈定了一个范围，任何设计和规划不能超越这个范围。

需求就像原材料一样，不断的被分析、被加工，直到最后形成服务提供给业务客户为止。IT团队可根据价值链，对各项作业进行计划和管控，同时价值链也是生命周期的档案链，是信息传递及追溯的基本逻辑。此外，IT管理者可根据价值链，分析引起交付质量波动的各项作业，并分析其上下环节的原因。

我为什么要在这里特别放一个章节来描述价值，因为我们后续谈的所有内容都是围绕价值创造来开展的。最怕的是过于专注于方法和过程，而忘记了最根本的核心问题--为业务创造价值。IT团队是以流程的方式利用资源，为客户提供服务，从而创造价值。因此流程只是创造价值的方式，但是在不清晰价值的时候，设计流程等于是一种盲目行为。

从客户的角度看，IT服务的价值有两部分组成：效用（Utility）和保障（Warranty）。任意一个都可以增加客户获得的价值，但两个都是必要条件，两个都不能单独构成充分条件。

价值的源泉：效用

效用（Utility）是一个经济学名词，任何产品和服务的价值首先取决于满足用户的期望程度，而用户的期望往往是模糊的，无法直接度量，所以只能间接的衡量由欲望产生的现象。在经济学中以一个人为了实现或满足他的愿望而愿意付出的价格来衡量效用（Utility），所以效用是价值的源泉。

如果把效用简单的进行叙述就是，某个服务或产品使得业务客户在使用后，能够减少多少以前的负面状况，或增加多少正面的状况。

我们可以用这样的逻辑尝试去叙述：利用了……功 能，解除了……谁的，……什么，使得…谁节省了，或增加了……什么。例如、利用数据化的管理，解除了文档无法统计的限制，使客户得到了有效的统计信息，也节省了得到信息的时间。

这就像我们后面要说到的需求管理中“用户故事”一样，用户故事是力求通过简短的语言是从用户的角度来来解读和描述用户渴望得到一些功能。所遵循的逻辑是：As a, Iwant to, so that也就是作为一个<角色>, 我想要<活动>, 以便于<商业价值>。

价值的基础：保障

信息系统发挥效益是建立在其稳定运行的基础上，需要其五个方面的保障： 可用性的保障 、 容量和性能的保障 、安全性的保障、连续性的保障、服务响应时间的保障。

根据最终交付的价值，IT团队的主要工作有两个方面，一是对信息系统的运维保障，二是通过建设和优化信息系统，为业务创造效用。

如果说这两个工作是有着根本的区别，那就是在对外界变化的影响上。运维保障工作受到外界的变化影响小，而为业务创造效用的工作相对受到外界的变化影响大。

运维保障工作的目标不会总是发生变化，也不需要频繁的去和客户讨论目标的变化。IT团队不会天天跑去问客户，你看今天咱们这个信息系统要保障到什么程度？消防队不需要天天问市民，如果今天你家发生火灾我们几分钟到场合适。对信息系统的保障要求对于各个行业来说虽然不一样，成本也不一样。但是，有一点是一样的，就是一旦确定了保障的目标以后，该目标不会频繁的发生变化。那么，我们可以确定为运维保障的目标是基本稳定的。既然目标已经确定，那么重要的是两点，一是如何达到目标，二是如何更加合理的利用资源，更加高效的达到目标。精益的运维管理，也就是一套以达到目标为基本要求，如何更加合理的利用软硬件资源，利用人力资源，利用时间的管理机制。 为业务创造效用的工作则是需要更加敏捷的方式，这是因为业务本身需要更加敏捷的响应市场，所以IT也需要更加敏捷的支持业务。这要考验IT的运作能力，虽然从字面上看敏捷有快速的意思，但是仅仅是速度并不等于敏捷。速度再快，最后的输出不满足业务需求，也是白搭。所以首先是把事做对，也就是满足业务需求的高质量交付，然后是把事做快，因为需求也有保鲜期，我们交付的服务如果过于缓慢，可能需求已经发生了变化。

精益思想和敏捷思想，在IT团队的工作中需要有效的结合， 一个成功的组合策略基于将需求模式分为基础需求和波动需求两种需求，也就是“基础需求和波动需求的分离”，一般来说，基础需求是相对稳定的，如业务对可用性和容量的需求或者对服务请求的响应时间，换句话说都是IT团队预先承诺在日常服务范围以内的支持性工作；而波动需求则和新建系统和创新应用联系在一起，这种需求一般不能预测，具有很大的灵活性。 以客户需求作为切入点，在切入点之前交付的是无个性特征的保障性目标，采用精益思想，也就是推动式的精益运维。在切入点以后，要依据客户需求的实际情况而定（未见得是被需求，可能是引领需求），采用敏捷思想。

软件开发流程可份为8步

一：需求分析

1相关系统分析员向用户初步了解需求，然后用相关的工具软件列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。

2系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚列出系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。

3系统分析员向用户再次确认需求。

二：概要设计

首先，开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。

三：详细设计

在概要设计的基础上，开发者需要进行软件系统的详细设计。在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编码。

四：编码

在软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。

五：测试

测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会有不可预料的问题存在。完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营状况并持续修补升级，直到这个软件被彻底淘汰为止。

六：软件交付

在软件测试证明软件达到要求后，软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。

七：验收

用户验收。

八：维护

根据用户需求的变化或环境的变化，对应用程序进行全部或部分的修改。

　第一步：需求调研分析

软件开发流程

软件开发流程

1相关系统分析员向用户初步了解需求，然后用word列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。

2 系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚列出系统大致的大功能模块，大功能模块有哪些小功能模块，并且还列出相关的界面和界面功能。

3 系统分析员向用户再次确认需求。

第二步：概要设计

首先，开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。

第三步：详细设计

在概要设计的基础上，开发者需要进行软件系统的详细设计。在详细设计中，描述实 现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细，能够根据详细设计报告进行编码。

第四步：编码

在软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。　

第五步：测试

测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。

软件开发的生命周期一般分为6个阶段：计划、需求分析、逻辑设计、程序编制、调试、运行和维护

软件生命周期分为软件定义、软件开发及软件运行维护三个阶段：

软件定义阶段

制定计划：确定总目标；可行性研究；探讨解决方案；制定开发计划。

需求分析：对待开发软件提出的需求进行分析并给出详细的定义。

软件开发阶段

软件设计：分为概要设计和详细设计两个部分 

软件实现：把软件设计转换成计算机可以接受的程序代码

软件测试：在设计测试用例的基础上检验软件的各个组成部分

软件运行维护阶段

软件投入运行，并在使用中不断地维护，进行必要的扩充和删改。

1问题定义

问题定义阶段必须回答的关键问题：“要解决的问题是什么？”如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间和金钱，最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。

通过问题定义阶段的工作，系统分析员应该提出关于问题性质、工程目标和规模的书面报告。通过对系统的实际用户和使用部门负责人的访问调查，分析员扼要地写出他对问题的理解，并在用户和使用部门负责人的会议上认真讨论这份书面报告，澄清含糊不精的地方，改正理解不正确的地方，最后得出一份双方都满意的文档。

问题定义阶段是软件生存周期中最简短的阶段，一般只需要一天甚至更少的时间。

2可行性研究

这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程，也就是在较抽象的高层次上进行的分析和设计的过程。

可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。

在问题定义阶段提出的对工程目标和规模的报告通常比较含糊。可行性研究阶段应该导出系统的高层逻辑模型（通常用数据流图表示），并且在此基础上更准确、更具体地确定工程规模和目标。然后分析员更准确地估计系统的成本和效益，对建议的系统进行仔细的成本／效益分析是这个阶段的主要任务之一。

可行性研究的结果是使用部门负责人做出是否继续进行这项工程的决定的重要依据，一般说来，只有投资可能取得较大效益的那些工程项目才值得继续进行下去。可行性研究以后的那些阶段将需要投入要多的人力物力。及时中止不值得投资的工程项目，可以避免更大的浪费。

3需求分析

这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。

用户了解他们所面对的问题，知道必须做什么，但是通常不能完整准确地表达出他们的要求，更不知道怎样利用计算机解决他们的问题；软件开发人员知道怎样使用软件实现人们的要求，但是对特定用户的具体要求并不完全清楚。因此系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法描述表示系统的逻辑模型。

在需求分析阶段确定的系统逻辑模型是以后设计和实现目标系统的基础，因此必须准确完整地体现用户的要求。系统分析员通常都是计算机软件专家，技术专家一般都喜欢很快着手进行具体设计，然而，一旦分析员开始谈论程序设计的细节，就会脱离用户，使他们不能继续提出他们的要求和建议。较件工程使用的结构分析设计的方法为每个阶段都规定了特定的结束标准，需求分析阶段必须提供完整准确的系统逻辑模型，经过用户确认之后才能进入下一个阶段，这就可以有效地防止和克服急于着手进行具体设计的倾向。

4总体设计

这个阶段必须回答的关键问题是：“概括地说，应该如何解决这个问题？”

首先，应该考虑几种可能的解决方案。列如，目标系统的一些主要功能是用计算机自动完成还是用人工完成；如果使用计算机，那么是使用批处理方式还是人机交互方式；信息存储使用传统的文件系统还是数据库……。通常至少应该考虑下述几类可能的方案：

低成本的解决方案。系统只能完成最必要的工作，不能多做一点额处的工作。

中等成本的解决方案。这样的系统不仅能够很好地完成预定的任务，使用起来很方便，而且可能还具有用户没有具体指定的某些功能和特点。虽然用户没有提出这些具体要求，但是系统分析员根据自己的知识和经验断定，这些附加的能力在实践中将证明是很有价值的。

高成本的“十全十美”的系统。这样的系统具有用户可能希望有的所有功能和特点。

系统分析员应该使用系统流程图或其他工具描述每种可能的系统，估计每种方案的成本和效益，还应该在充分权衡各种方案的利弊的基础上,推荐一个较好的系统 (最佳方案),并且制定实现所推荐的系统的详细计划。如果用户接受分析员推荐的系统，则可以着手完成本阶段的另一项主要工作。

上面的工作确定了解决问题的策略以及目标系统需要哪些程序，但是，怎样设计这些程序呢？结构设计的一条基本原理就是程序应该模块化，也就是一个大程序应该由许多规模适中的模块按合理的层次结构组织而成。总体设计阶段的第二项主要任务就是设计软件的结构，也就是确定程序由哪些模块组成以及模块间的关系。通常用层次图或结构图描绘软件的结构。

5详细设计

总体设计阶段以比较抽象概括的方式提出了解决问题的办法。详细设计阶段的任务就是把解法具体化，也就是回答下面这个关键问题：“应该怎样具体地实现这个系统呢？”

这个阶段的任务还不是编写程序，而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图，它们应该包含必要的细节，程序员可以根据它们写出实际的程序代码。

通常用HIPO图（层次图加输入／处理／输出图）或PDL语言（过程设计语言）描述详细设计的结果。

6编码和单元测试

这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。

程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时用汇编语言），把说细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。

7综合测试

这个阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的要求。

最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。所谓验收测试则是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积极参加下）对目标系统进行验收。

必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。

为了使用户能够积极参加验收测试，并且在系统投入生产性运行以后能够正确有效地使用这个系统，通常需要以正式的或非正式的方式对用户进行培训。

通过对软件测试结果的分析可以预测软件的可靠性；反之，根据对软件可靠性的要求也可以决定测试和调试过程什么时候可以结束。

应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来，做为软件配置的一个组成成分。

8软件维护

维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。

通常有四类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。

虽然没有把维护阶段进一步划分成更小的阶段，但是实际上每一项维护活动都应该经过提出维护要求（或报告问题），分析维护要求，提出维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软件定义和开发的全过程。

都应该经过提出维护要求（或报告问题），分析维护要求，提出维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此实质上是经历了一次压缩和简化了的软件定义和开发的全过程

以上就是关于如何开发app，app开发的流程是如何的全部的内容，包括:如何开发app，app开发的流程是如何的、IT运营的过程、软件项目开发工作流程等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！