精华内容
下载资源
问答
  • 项目开发流程

    2018-03-30 09:15:50
    项目开发并不是一个简单的过程,我们需要遵循一些开发流程。一个项目的开发会被分成很多步骤来实现,每一个步骤都有自己的起点和终点。也正如此使得开发过程中的每个步骤起点和终点在不同的软件项目中出现不同难度的...
  • 项目管理中用于团队建设过程中所需要规范的团队章程,及绩效考核办法,明确责任。
  • 本资源包是一个用思维导图设计的非常详细的项目开发流程图,从七个模块进行了描述:立项,项目开发计划,需求分析,系统设计,程序编码,程序测试以及成果发布七个方面。
  • 项目开发流程及开发模式

    万次阅读 2019-01-08 11:16:07
    项目开发阶段 整体阶段:需求分析、设计、编码、测试、维护。 需求阶段:通常定义系统的需求,明白系统的目标。 设计阶段:通常确定系统使用什么数据库,系统模块的划分,各个模块的功能。 编码阶段:用编程语言对...

    项目开发阶段


    整体阶段:需求分析、设计、编码、测试、维护。
    需求阶段:通常定义系统的需求,明白系统的目标。
    设计阶段:通常确定系统使用什么数据库,系统模块的划分,各个模块的功能。
    编码阶段:用编程语言对设计阶段的实现。
    测试阶段:分黑盒测试,白盒测试。测试系统的功能是否实现,是否准确。
    维护阶段:是根据用户新的需要重新修改系统,使系统更加稳定,更符合用户的要求。
    需求阶段:其工作是否到位是整个系统开发的关键,在需求阶段有很多方式可以帮助自己完成工作,例如与客户畅所欲言,跟随客户参与业务过程等等。不管任何一种方法,任何一种方式,在需求阶段首先确定系统边界,确定组织边界,然后摸清企业为消费者创造的价值,看清企业的价值链,摸清价值链上的实体。最后要平衡价值链上各个实体之间的利益,争取系统做到大家都满意这个理想的状态。


    开发模式


    A:瀑布式开发
    (1)老旧的,过时的计算机软件开发方法。
    (2)最典型的预见性的方法,严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等。
    瀑布式开发存在的问题
    主要问题是它的严格分级导致自由度降低,项目早期即作出承诺导致对后期需求的变化难以调整,代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。(项目早期即作出承诺导致对后期需求的变化难以调整)有论文统计他是造成70%软件开发失败的原因,代价高昂。
    B.螺旋式开发
    巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”,瀑布模型+快速原型模型结合,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。
    螺旋式开发流程
    制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;
    风险分析:分析评估所选方案,考虑如何识别和消除风险;
    实施工程:实施软件开发和验证;
    客户评估:评价开发工作,提出修正建议,制定下一步计划。
    核心:就在于需求人员不需要在刚开始的时候就把所有事情都定义的清清楚楚,轻松上阵,定义最重要的功能,开发人员实现它。然后听取客户的意见,之后再进入到下一个阶段。如此不断轮回重复,直到得到您满意的最终产品。
    特点:是一种风险驱动的方法体系,在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。
    C.迭代式开发
    迭代式开发特点:
    (1)降低风险
      (2)得到早期用户反馈
      (3)持续的测试和集成
      (4)使用变更
      (5)提高复用性
    什么是迭代式开发:(迭代增量式开发或迭代进化式开发。)
    每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发, 每次设计和实现一个阶段叫做一个迭代.
    在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。
    D.敏捷开发
    什么是敏捷开发:
    是一种应对快速变化的需求的一种软件开发能力。其具体名称、理念、过程、术语都不尽相同,相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。
    采用这种方法,开发工作可以在需求被完整地确定之前启动,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求,并开始新一轮的迭代。

    敏捷开发特点:
    (1)以人为核心、迭代、循序渐进
    (2)系统切割(类似于分布式开发),各个子项目(可以独立运行)的成果(软件一直处于可使用状态)都经过测试,具备集成和可运行的特征
    (3)人和交互 重于过程和工具
    (4)可以工作的软件 重于求全而完备的文档。
    (5)客户协作重于合同谈判,随时应对变化重于循规蹈矩。

    项目的敏捷开发:
    敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果;
    关注业务优先级; 检查与调整。
    最重要的因素恐怕是项目规模。规模增长,面对面的沟通就愈加困难,
    因此敏捷方法更适用于较小的队伍,40、30、20、10人或者更少。
    大规模的敏捷软件开发尚处于积极研究的领域。


    项目开发流程


    1. 项目立项(确认需求)
         -- 市场调研(运营团队)(自主研发产品)
    	 -- 完成甲方的需求(外包公司)
    	     --人员外包
    		 --项目外包
    		 
    2. 确认需求(PM project manager)
        -- 需求评审(pm主导会议)
    	    -- 运营团队
    		-- 产品
    		-- 开发人员
    		    -- 后端
    			-- 前端
    			-- UI
    		-- 测试
    	-- 确认需求
    	
    3.开发阶段
         -- 需求: 憋坏(继续优化)
    	 -- 开发人员
    	    -- UI:切图 设计项目需要的图标
    		-- 前端:
    		    -- 技术选型(vue.js angular.js)
    			-- 布局完成静态页以及一些js特效
    			-- 自测(moke.js)
    			-- 打包部署
    	    -- 后端:
    		    -- 技术选型
    			-- 根据需求数据库设计
    			-- 生成项目组织架构
    			-- 根据需求完成接口
    			-- 自测(Junit)
    			-- 写接口文档
    			     -- 接口名称
    				 -- 接口url
    				 -- 参数
    				      -- 有
    					      -- 参数是否必填
    					  -- 没有
    				 -- 调用demo
    				     ajax
    				 -- 返回结果
    				     result:[data:{},state:{}]
    			-- 把项目打包部署到开发环境
    			
    		 -- 如果发现问题
    		    前后端联调(本地联调)
    			
    	    -- 测试人员
    		    -- 根据需求写测试用例
    		         测试用例
    				 如果进行...操作,然后出现...结果
    		
    4.测试阶段
        --前后端人员及时跟进测试结果,准备随时修改bug	
    	--提交测试报告
    	
    
    5.上线部署
        -- 后端
    	     -- 准备上线的相关资源给运维
    		    --提交一个上线申请
    			  -- jar
    			  -- xxx.sql
        -- 运维人员
    	     -- 操作Linux 把相关相关的项目部署
    		 
    	-- 有可能会通宵
    		 
    6.对项目的维护和更新
        -- 备用服务器
        .......
    
    展开全文
  • 软件项目开发流程

    万次阅读 多人点赞 2019-10-08 05:30:56
    首先 看一下基本软件项目开发流程图 其中 1.需求分析: 通过对客户业务的了解和与客户对流程的讨论对需求进行基本建模,最终形成需求规格说明书。 2.总体设计: 通过分析需求信息,对系统的外部条件及内部...

     

     

     

     软件开发流程(Software development process)

     首先 看一下基本软件项目开发流程图

    其中

    1.需求分析:
      通过对客户业务的了解和与客户对流程的讨论对需求进行基本建模,最终形成需求规格说明书。
    2.总体设计:
      通过分析需求信息,对系统的外部条件及内部业务需求进行抽象建模,最终形成概要设计说明文档。
    3.详细设计:
      此部分在对需求和概要设计的基础上进行系统的详细设计(也包含部分代码说明)。
    4.开发编程:
      对系统进行代码编写。
    5.测试分析与系统整合:
      对所有功能模块进行模拟数据测试及其它相关性测试并整合所有模块功能。
    6.现场支持:
      系统上线试运行进行现场问题记录、解答。
    7.系统运行支持:
      系统正式推产后,对系统进行必要的维护和BUG修改

     

     

    需求分析是怎样做的?

    需求分析是构建软件系统的一个重要过程。 一般,把需求类型分成三个类型: 

    1、业务需求(business requirement)
      反映了组织机构或客户对系统、产品高层次的目的要求,它们在项目视图与范围文档中予以说明。 
    2、用户需求(user requirement) 
      文档描述了用户使用产品必须要完成的任务,这在使用实例文档或方案脚本说明中予以说明。 3、功能需求(functional requirement)
      定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。

     

    业务需求和用户需求是软件需求分析的基础,也是软件构建的前提。
    系统分析员通过对业务需求和用户需求的分解,将其转换成可以形式化描述的软件功能需求。
    开发软件系统最为困难的部分,就是准确说明开发什么。这就需要在开发的过程中不断的与用户进行交流与探讨,使系统更加详尽,准确到位。这就需要确定用户是否需要这样的产品类型以及获取每个用户类的需求。

      客户也经常是矛盾的。事实上,很少有客户能够明确的知道怎样的一个系统对自己是最有益处的,他们往往在集中方案之间徘徊,于是经常产生需求的变动。生产厂商经常陷入客户自己的矛盾之中。
      客户的负面影响可能对于能够在预算内按时完成项目产生很大的影响。尽管客户需要对需求的质量负责任,但是,当一个软件项目因为客户事先没有预料到的情况而导致失败的时候,即使客户不会追究开发方的责任,就软件项目本身而言,也已经是失败的。
     
    总结: 
    良好的需求分析是软件成功的基础。
    在软件项目整个过程中系统分析员主动进行沟通,提出指导性意见。当软件融合了客户和系统分析员双方智慧,其质量将会进一步得以提高。

     

     

    软件开发管理规范流程图

      摘项目管理的根本目的是按时、保质、保量完成预期交付的成果。项目管理要让整个组织能清楚理解项目实施的目的、影响、进度,应做到项目组所有员工都应理解项目实施的原因、意义及客户的要求。在项目管理中还能看到公司高层领导通过实际行动表现出来的对于项目实施的支持与帮助,通过以制度化管理来组织合理安排员工的工作职责和角色转换。为满足上述要求,就必须让员工、企业、客户能接受并适应新的“软件项目开发管理规范”。

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     


     

    1.启动阶段

      这个阶段的工作目的是决定一个项目是否需要启动。为了达到这个目的,首先要明确项目的总体战略目标,对项目的需要建立认同。即确定到底需要做什么、开发什么产品或提供什么服务,以及需要解决什么样的问题和需要满足客户或市场的什么要求等,同时还要总结项目工作的范围、所需资源、大约开支、各种风险,以及该项目不执行的其他替代选择等。这些代表了对整个项目目标从战略角度和宏观层次所进行的分析,通过项目的意向书总结出来,由此确证客户或项目发起人和赞助者的要求与期望,并帮助他们判定项目是否上马。项目意向总结书的通过及项目被批准上马形成了这个项目的起始点。

    • 产品领域研究

      研究产品所在领域的状况,为项目论证提供依据。研究内容包括:

    产品领域的现状和前景
    产品领域的商业模式和业务流程
    产品的价值和盈利空间
    产品的特性和复杂度

     

     

    • 技术可行性研究

      研究产品的实现技术,总结技术可行性。研究内容包括:

    类似产品的当前实现技术和技术趋势
    实现技术的候选方案
    各个方案的优点、成本和风险
    开发团队与实现技术的匹配情况

     

     

     

    • 项目论证

      基于商业和技术等方面对项目的可行性进行论证,确定项目是否开展。如果开展项目,则进一步论证项目的总体方案。

      论证的内容包括:

    商业可行性
    技术可行性
    当前产品与类似产品的比较
    项目收益和前景
    项目的成本和风险
    项目的总体方案

     

     

    • 确定项目目标和范围

      项目开始时,所有相关人员必须对项目的目标和范围达成共识,形成共同的项目愿景。并把愿景叙述为《项目开发大纲》向相关人员传达。

    《项目开发大纲》的内容包括:

     

    概 

    用三到五张图表来描述产品目标、功能、平台、客户、进度表和开发职责

    高级功能

    用一个段落来综述产品,再用一个段落来描述每个重要的功能

    不实现的功能

    用一个段落来描述每个对产品有用的但本项目不实现的功能

    涉 

    用一个段落来明确每个重要的涉众群体和他们的风险股本

    项目需求

    用一个段落来讲述每个重要的项目需求

    项目风险

    按风险暴露量对每个重要的项目风险都用一个段落来讨论

    项目回报

    用一个段落综述产品的回报,其后再对每个重要的项目回报都用一个段落来讨论

    结 

    用一到三个段落将上述所有部分联系起来,明确项目的需求和风险,再用论点和论据来总结为什么这个项目会成功

     

     

     

    2.计划阶段

      这个阶段的工作是为整个项目做计划。项目开始后,首先要确定项目的具体范围,明确定出项目到底要做什么,总结、归纳并定出产品的功能。然后进一步制定项目的计划,列出每项具体工作,并建立所有工作任务的重要性及顺序;确定每项工作的执行人和所需资源;根据人员的配置和能力设定各项工作和整个项目的完成时间表。

    • 规模、工作量评估

      围绕各项计划的制定工作对项目的规模、工作量等进行评估,评估的内容包括:

    模块数量与复杂度
    输入、输出和对外接口等数量与复杂度
    SLOC和功能点
    非生产性的支持工作量
    开发工作量(人月)
    进度与里程碑
    进度风险

     

     

    • 定制项目开发计划

      项目开发计划体现了项目组对整个开发周期的预期,指定了项目开发的总体方针。与其他计划一样,项目开发计划不是固定不变的,在执行过程中要对计划进行监控,可能会根据实际情况修改计划并重新发布。

    《项目开发计划》的内容包括: 

    概 

    用三到五张图表来描述产品目标、功能、平台、客户、进度表和开发职责。

    (《项目开发计划》的概述部分应该是《项目开发大纲》中概述部分的拷贝。当项目计划改变时,修订《项目开发计划》的概述部分而不是修订《项目开发大纲》。这样,以后在进行项目评价时,通过比较《项目开发大纲》和《项目开发计划》的概述,就能看出项目是如何改变的)

    高级功能

    用一到五页的篇幅来概述产品的功能,其中,要包括这些功能的附加信息(开发者需要这样的信息来了解实现需求)。

    项目成员

    确定软件工程职能角色,以及分配到这些角色的人员数量。

    软件过程

    概述这个项目中所应用的软件过程。

    (具体内容可在《质量保证计划》中定义)

    软件工程方法

    概述这个项目中所应用的软件工程方法和技术。

    (具体内容可在《质量保证计划》中定义)

    进度和工作量

    这一部分要表达出整个项目进度和工作量的估计。其中要包括:

    • 对固定不变的里程碑和同步点的解释
    • 在评估中的设想情况、评估中的不准确性的可能来源
    • 随着项目的进展如何更新评估

    (具体进度表内容可在《开发进度表》中定义)

    风险管理计划

    概述这个项目中风险管理计划。

    (具体内容可在《风险管理计划》中定义)

    测 

    概述这个项目中要收集的测量。

    软件工具

    列出要使用的每一项软件工具,以及该工具所支持的任务。

    项目支持

    硬件支持 明确所需的硬件,包括那些需要移动、获取或升级的硬件。

    软件支持 明确所需的软件,包括需要获取、安装或升级的软件件。

    人力支持 由哪个人、部门或团队为开发组的哪项任务提供支持。

     

     

    • 定制风险管理计划

      风险管理任务包括:风险识别、风险分析、确定风险优先级、定制风险化解方案、风险化解和风险监控

     《风险管理计划》定义这些任务的执行流程和人员分配。

      《风险管理计划》的内容包括:

     

    概 

    用文字和图表概述风险管理任务的总体执行流程。

    风险识别

    详细说明“风险识别”任务的实施细节和各项工作的负责人。

    风险分析

    详细说明“风险分析”任务的实施细节和各项工作的负责人。

    确定风险优先级

    详细说明“确定风险优先级”任务的实施细节和各项工作的负责人。

    定制风险化解方案

    详细说明“定制风险处理方案”任务的实施细节和各项工作的负责人。

    风险化解

    当风险发生时,需要采取相应的措施化解风险。

    这部分的内容是描述风险化解工作的操作规范和流程。

    风险监控

    详细说明风险监控任务的实施细节和各项工作的负责人。

     

     

     

      风险管理中通常会用到《Top N 风险列表》,风险列表按照风险暴露量排序列出当前项目中主要的N个风险,《Top N 风险列表》的内容包括:

     

    本周排名

    本周的排名(如果本周已被完全化解用“---”表示)

    上周排名

    上周排名(如果是新识别的风险用“---”表示)

    上表周数

    该风险已上表的周数

    风 

    风险的名称或简述

    类 

    风险类型(只针对进度相关的风险):

    • 计划编制
    • 组织和管理
    • 设计和实现
    • 客户和需求
    • 承包商
    • 产品
    • 人员
    • 过程
    • 技术
    • 外部环境
    • 开发环境

    发生概率

    风险发生的百分比概率

    损失程度

    风险发生时损失的进度(工作日或工作周)

    暴露量

    发生概率 X 损失程度

    状 

    风险的当前状态:未发生、已发生、已化解

    化解方案

    简述风险的化解方案,如果有具体的化解方案文档则链接到相应文档

    化解进度

    对已发生的风险,简述化解进度(未发生的风险用“---”表示) 

     

    • 定制质量保证计划 

      保证工作质量的一个重要步骤是制定一套合理的质量保证计划并贯彻执行。

      《质量保证计划》的内容包括:

    概 

    说明编写的目的、适用范围以及对相关人员的要求等

    软件过程

    详细说明这个项目中所应用的软件过程。

    软件工程方法

    详细说明这个项目中所应用的软件工程方法和技术。

    工作规范

    对工程方法中的各种工作任务进行规范,明确执行的时机、流程和准则等。这些工作任务包括:

     

    常规开发活动

    (需求分析、架构设计、详细设计、编码和测试、发布和实施等)

    会议

    (工作例会、进度会议、审查会议等)

    评审

    (方案评审、技术评审、质量评审等)

    测量

    (产品规模测量、进度测量、缺陷率测量、测试覆盖率测量等)

    其他活动

    (技能培训、资料收集、内部流、客户沟通等)

     

     

    • 定制开发进度计划

      基于当前对项目的规模和工作量评估,定制初步的开发进度表,作为项目开发计划的组成部分。

      《开发进度表》的内容包括:

    项目的开始和结束时间
    项目各个阶段的开始和结束时间
    每个阶段的工作任务及其开始和结束时间
    每个工作任务的子任务的及其开始和结束时间
    里程碑和同步点
    角色的定义和任务分配

     

       作为跟踪项目进度的重要依据,进度表在项目推进过程中需要不断细化。另外,当实际进度与计划进度出现偏差时,需要修改进度表并重新发布。

     

     

     

    3.执行阶段

      这个阶段的工作是通过执行项目的计划来完成项目的任务。它包括落实一切所需资源,如:人员、设备、费用、技术、信息,由管理者领导全体项目参与者开展各项工作。同时跟踪各项具体工作和整个项目的进度,定期向全体项目人员及项目的发起人报告项目状态。

    • 需求分析

      分析产品的关键需求、对架构设计有影响的需求和风险较高的需求,直到分析的程度能开展足界面原型设计和架构设计工作。

      《需求规格说明书》的内容包括:

     

    商业或业务需求

    从商业或业务角度宏观上对产品或系统的要求。它主要在宏观的层面归纳总结为满足客户提出的要求或赢得市场竞争所必须实现的功能、性能、质量等要求。

    1. 做什么
    2. 做的范围
    3. 对结果的要求

    使用者需求

    从客户对软件产品或系统使用方案的角度出发,描述和总结使用者利用该软件产品或系统能够做的事或能够完成的任务。

    功能需求

    根据上述使用者需求列出的使用方案,列出开发者必须为软件产品或系统实现的功能。

    性能需求

    1. 运行速度、容量、并发性能
    2. 对资源的利用率
    3. 对外界输入的反馈速度和准确性
    4. 对差错的负荷能力

    系统需求

    • 必须适应的运行环境的要求

    (包括运行平台、网络及其他硬件要求)

    • 与其他系统兼容的要求

    (包括与操作系统、数据库、浏览器及其他应用软件的兼容要求)

    • 与外部其他系统和组件的接口要求

    质量需求

    • 对用户重要的质量标志

    (可靠性、效率性、灵活性、安全性、互操作性、稳定性、健全性、可用性)

    • 对开发者重要的质量标志

    (可维护性、多用转换性、重复使用性、可测试性)

    其他需求

    不属于上述需求范围的,但受到其他环境和商业合同影响的要求。

    1. 国家或地区的任何特别的标准
    2. 软件使用界面的特别要求
    3. 与知识产权有关的要求
    4. 软件所面对的市场和行业的规范
    5. 客户的特别要求

    开发的局限

    对开发的成功与否起很大影响的因素,是开发能力的局限:

    1. 人员的局限
    2. 技术的制约和局限
    3. 客户的特别要求

    《需求分析报告》的编制方式可以是多样的,例如把所有“非功能性需求”组织成“外部接口需求”、“质量属性需求”和“需求约束”。

    • 界面原型设计

      明确了系统的关键需求后,就可以进行界面原型设计工作,获取用户的反馈,尽快确定产品的界面基调。同时要编写一份《界面设计概要》文档,作为后续的界面设计工作的指导。

      《界面设计概要》的内容包括:

    • 设计的理念
    • 理念的来源或参考
    • 设计的要点
    • 与类似产品界面的对比

     

    • 架构设计

      架构设计从关键需求开始,建立概念性的架构,并逐步细化和验证。最终生成架构设计说明书和架构基线代码。

      架构设计的方法:可以从几个不同的视角进行架构设计,然后汇总综合得出完整的设计。

    《架构设计说明书》的内容包括:

     

    概 

    说明编写的目的、适用范围以及设计原则等。

    逻辑架构

    关注功能。其设计着重考虑功能需求。

    1. 细化功能单元
    2. 发现通用机制
    3. 细化领域模型
    4. 确定子系统接口和交互机制

    开发架构

    关注程序包。其设计着重考虑开发期质量属性,如可扩展性、可重用性、可移植性、易理解性和易测试性等。

    1. 确定要开发或直接利用的程序包之间的依赖关系
    2. 确定采用的技术、框架等

    数据架构

    关注持久化数据的存储方案。其设计着重考虑“数据需求”。

    1. 持久化数据存储方案
    2. 数据传递、数据复制、数据同步等策略

    运行架构

    关注进程、线程、对象等运行时概念,以及相关的并发、同步、通信等问题。其设计着重考虑运行期质量属性,例如性能、可伸缩性、持续可用性和安全性等。

    1. 确定引入哪些进程与线程
    2. 确定主动对象、被动对象,以及控制关系
    3. 处理进程线程的创建、销毁、通信机制、资源争用等
    4. 协议设计

    物理架构

    关注软件系统最终如何安装或部署到物理机器。其设计着重考虑“安装和部署需求”。

    1. 确定物理配置方案
    2. 确定如何将目标程序映射到物理节点

    总 

    基于上述的设计进行总结,并描述架构基线。

     

     架构设计的另一个重要任务是编写架构基线代码,基线代码表述和验证架构,同时也是指导后续开发的基础代码。架构基线代码的内容包括:

    所有工程项目
    工程目录结构
    软件包结构
    导入所有依赖包
    基础公共代码
    架构框架代码
    架构框架示例代码和测试代码
    数据库框架

    展示了软件架构师的工作和成功的软件架构设计包含的内容:

    软件架构师的工作

    成功的软件架构设计

      软件构建

       软件可以分阶段进行构建,每个阶段可以使用增量的方式开发,用通过若干个Build构建,最后发布阶段性产品成果。

      (注意:在这里 ,名词“阶段”的含义和本文其他地方的含义不一样)

     

    • 阶段计划

      构建阶段计划的内容包括:

    确定本阶段要实现的功能
    列出阶段任务
    计划Build构建数量
    细化《开发进度表》中本阶段的工作内容

     

     

    • Build 构建

       Build构建以增量的方式执行阶段的开发任务,每个Build构建的周期一般不超过两星期,每一次Build构建都会发布为一个内部版本,并提交测试。测试发现的问题留待以后的Build构建解决。

     

    • Build计划

      《Build计划》的内容包括:

    本次Build的版本号
    本次Build的历时
    本次Build的工作任务
      要解决的遗留Bug
      本应由以前的Build实现的,但推迟到本次Build实现的功能
      要实现的新功能
      其他工作任务
    工作任务分配

     

     

    • 需求细化

      根据《Build计划》,细化本次Build要实现的需求,细化到能进行详细设计为止。有了细化的需求后就编写本次Build的测试计划。

      《测试计划》的内容包括:

    • 功能测试
      要测试的功能
      测试时间
      测试方式
      验收标准

       

    • 其他测试(性能测试、边界测试、使用界面测试、可用性测试、安全性测试等)
      要测试的内容
      测试时间
      测试方式
      验收标准

       

    • 。。。。。。

     

    • 界面设计

      根据细化的需求设计用户界面,当界面确定后即可编写测试用例。

      《测试用例》的内容包括:

    测试用例对应的功能模块
    测试用例的性质(功能测试用例、性能测试用例、。。。。。。)
    输入(或操作步骤)
    期望输出
    实际输出(执行测试后再填写)
    是否通过(执行测试后再填写)

     

     

    • 详细设计

      详细实际每项需求的实现方法,对于重要的设计决策、算法、公共模块和外部接口等必须以模块设计文档的形式进行记录。《模块设计文档》的内容包括:

    模块名称
    设计思想
    设计图表(类图、流程图等)
    要点描述(包、接口、类、方法、算法、设计模式)
    测试方式

     

     

    • 编码、单元测试

      编码和单元测试是开发人员的工作,对于重要的代码都必须进行单元测试,编写代码必须遵守下列准则:

    遵守编码规范
    编码前必须充分理解相关的需求
    编码前先进行设计,把流程理顺
    注意设计方法和设计模式的灵活运用
    总体考虑问题,使代码遵从架构并容易测试
    设计时要充分考虑异常情况和临界条件
    严禁Copy-Paste,注意提取公共代码,在编码过程中实现重构
    异常处理必须记录日志,严禁草率地直接打印异常信息
    灵活运用ASSERT() / VERIFY()等断言来帮助调试程序
    单元测试是程序员的工作,所以编码完成后必须对代码严格测试
    功能代码完成后必须先做以下4件事情:
      编译代码,保证编译通过
      (不运行程序)对代码进行全面检查
      用调试模式启动程序,一行一行单步执行代码,并注意调试输出
      改变条件,让代码尽可能走遍所有程序分支
    Check In代码前必须保证能编译通过

     

     

    •  创建Build

      代码集成发布前需冻结代码,所有人把要提交的代码Check In,并保证编译后的程序能在测试服务器上正常启动,界面能正常打开。同时还要提交Build清单。

      《Build清单》的内容包括:

    Build版本号和日期
    改正的Bug
    修改的功能
    实现的新功能
    其他说明

     

     

    • 集成测试

      按照《测试计划》针对《Build清单》执行《测试用例》,测试完成后编写测试报告。

      《测试报告》的内容包括:

    测试用例汇总(用例数量、通过的用例数量、未通过的用例数量等)
    Bug汇总(Bug总数、新增Bug数量、关闭Bug数量、Bug趋势图表等)
    测试计划执行情况
    测试总结

     

     

     

    • 阶段产品发布

      构建阶段完成后发布阶段产品成果,向用户展示并接受用户反馈,同时做好阶段总结。

      《发布清单》的内容包括:

    产品版本号和日期
    改正的Bug
    修改的功能
    实现的新功能
    其他说明

     

      《阶段总结报告》的内容包括:

    阶段任务的完成情况
    进度计划的执行情况
    用户的反馈情况
    本阶段碰到的主要问题
    下一阶段的改进建议

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    4.控制阶段

      这个阶段的工作是确证项目工作的结果符合项目的计划。它通过对项目结果的衡量和审核,与项目计划所期望的结果进行比较,找出实际结果与计划的差别,并制定处理措施。这个阶段的工作还包括对项目进程中出现的任何更改要求进行审核和批准。同时调解项目进程中出现的各种问题,如:对缺乏的资源的补偿调节;对项目的进度表及各项具体工作的优先级或顺序的修订。

    • 风险管理

      开发期间要对风险进行监控,定期检查、更新和发布《风险列表》。

     

    • 质量管理

      1)  评审

      评审是质量保证的重要环节,原则上每个重要的工作任务或阶段结束前都必须经过评审,如:方案评审、计划评审、需求评审、设计评审和代码评审等,工作是否被通过、是否需要修改或重做均由评审结果决定,评审结果以《评审报告》的形式发布。

      《评审报告》的内容包括:

     

    基本信息

    评审主题、时间、提交者、评审者等

    评审内容

    评审内容的列表和简述

    问答记录

    评审过程中重要的问答记录

    评审结论

    整个评审的结果,如:

    1. 完全通过,无需修改
    2. 基本通过,需要作小量修改,但不必再评审
    3. 大体通过,需要作一些修改,之后再评审
    4. 不通过,需要作大幅修改,之后必须重新评审

    评审意见

    针对评审结论提出的意见和建议

     

     

     2)  测试

      测试是对被构建产品最直接有效的质量保证措施,测试结束后需要提交《测试报告》。

     

    • 变更管理

      开发过程中经常会出现多种变更,如:需求变更、设计变更或人员变更等。这些变更通常会对开发进度造成影响,因此要对变更及其处理过程进行跟踪,最后报告变更的处理结果。

      《变更处理报告》的内容包括:

     

    基本信息

    变更主题、发生时间等

    详细信息

    变更的详细描述

    变更处理

    变更的处理方式和步骤

    处理结果

    变更的处理结果

    变更影响

    变更对项目造成的影响

     

    • 进度监控

      项目进度会议是了解项目实际进度的有效措施,在会议中评审工作报告,解决遇到的问题并计划下一步工作:

      《工作报告》的内容包括:

    基本信息:  报告者、汇报时间、工作时间段等
    工作情况:  已完成的工作、未完成的工作
    遇到的问题:工作中碰到的阻碍
    工作计划:  下一步的工作计划

     

     

      项目进度会议的另一个重要议题是审查进度表,了解项目实际进度与计划进度的差异。为进度表调整和资源调配提供重要依据。

     

    • 测量

      在项目开发过程中,收集一些关键的测量,对了解项目状态和进行项目决策很有帮助,同时也为以后的项目提供历史数据参考。每个测量都要生成测量报告并存档。

      《测量报告》的内容包括:

    基本信息,包括测量主题、测量时间、测量者等
    测量内容和测量值
    测量分析

     

     

     

     

    5.结束阶段

      这个阶段的工作是确保项目的最终结果或提交物达到计划的要求,并对完成的结果作可接受的确认。还包括在项目完成之后的收尾工作,对整个项目的经历进行总结,修订项目文档,用户培训等。

    • 产品测试

      因为产品即将验收和发布,所以必须对产品进行完整测试,产品测试比其他测试要求更严格,当产品的质量达到发布的要求后才能发布。产品的质量由《测试报告》体现。

     

    • RC版本发布

      发布RC版本让用户体验并收集反馈意见,为产品验收作准备。RC版本发布后,产品不应该有大改动,一般只是界面的局部调整。

     

    • 编制用户文档

      针对不同的使用者角色,编制相应的用户文档,对管理者用户需要提供《安装、维护指南》,对普通用户需要编制《产品使用手册》。

      《安装、维护指南》的内容包括:

    产品各组件的说明
    产品部署架构
    安装、配置和卸载等步骤
    启动、停止和重启等操作
    其它操作:日志、备份、还原等

     

     

      《产品使用手册》的内容包括:

    产品介绍
    各个功能的介绍
    通过实际案例介绍各个功能的使用方式和操作步骤

     

     

    • 产品使用培训

      对于为特定客户开发的软件产品,在发布前需要对用户进行产品的使用培训。培训前需要部署好操作环境,编写培训资料,然后组织培训会议。

     

    • 产品验收

      对于为特定客户开发的软件产品,通常根据签订的开发合同和产品方案等条款逐项验收,验收时,用户通常会执行验收测试案例。

     

    • 最后修订

      在产品验收通过后,正式发布前对产品作最后的修订,可能包括:

    开发文档修订
    用户文档修订
    代码整理

     

     

    • 正式版发布

      正式版的发布标志着开发阶段的结束,产品从此时起进入维护阶段,正式发布前可能要做一些准备工作,如:数据迁移和环境配置等。

          

    • 项目总结

      项目结束后需要对整个项目开发阶段的工作进行总结,交流心得,吸取经验和教训,并归档为《项目总结报告》。

      《项目总结报告》的内容包括:

    总体评价
    成本、收益汇总
    重要心得
    管理总结
    技术总结

     

     

    6,总结

      软件项目开发经历多个阶段,每个阶段包含多个任务,每个任务会产生相应的工件。需要相应的质量保证措施对任务进行监控,保证任务的执行。任务完成后也需要对任务进行评审,保证任务的质量。

      这些工作均由开发团队和相关人员按照工作流程执行。因此,合理的角色任务分配和沟通制度是软件项目成功的重要保障。

     

     列出几种比较普遍的角色和任务划分方案:

    职责和角色不清楚往往是造成软件项目团队管理混乱的一个重要原因,一个好的软件团队必须根据团队规模的不同和项目本身的特点对项目成员的角色和岗位进行明确的划分,这样团队中的每个成员才可能有清晰的责任和目标。

      软件开发不管采用哪种生命周期模型和开发方法论,整个过程都会包含需求,设计,开发,测试,配置管理等各项活动。而这些活动会对应到项目中的不同角色,项目中进行岗位划分后每个岗位成员可以兼职多个角色。形成相关的角色岗位矩阵。

     

      方案一 项目负责人总览全局

      对于小作坊的软件开发团队,可以由一个项目负责人总览全局。项目负责人承担从用户需求->软件需求->总体设计的所有工作。同时还需要做到整个团队进度规划,质量保证,配置管理和沟通协调等相关工作。所以小型项目团队对项目负责人的业务,技术和沟通管理等技能都要求较高,项目负责人是项目中的总体方案确认者和架构师。项目负责人能力和技能往往决定了整个软件项目的成败。

      我们这里指的小型团队并不是只一个人单打独斗的项目,所以项目负责人最好不要介入到模块设计和编码活动中,而是应该把重点放在进度的控制和质量的保证上面。由于项目负责人一般有较强的技术能力,所以项目负责人可以承担项目中要使用的一些新技术的研究,项目中一些疑难问题的解决等相关工作。项目负责人还应该有计划的设计开发人员的代码进行Review,对发现的规范性,性能,复用差等问题跟项目成员确认,并写入到项目开发规范中。

     

      方案二 项目负责人和开发负责人分离

      在这种方案下项目负责人和开发负责人在软件需求和架构上的工作是重叠的。这两个岗位的人员共同来确认项目的总体方案和架构。项目负责人的重点在项目管理和与客户交流沟通上,只有确认清楚第一手的用户需求,才能开发出用户满意度高的软件。对于很多小型项目往往是用户需求都没有搞清楚就开工,项目成员完全凭借着自己的感觉在做系统,过程中又不注意与用户及时反馈和迭代,导致开发出完全不能使用的系统;开发负责人的重点是对整个开发过程负责,包括对项目经理确认的进度目标进行任务的进一步分解,安排后续的增量和迭代计划。方案二的重点是第一次解放项目经理,架构的核心移动到了开发负责人,而项目经理仅仅是参与讨论和评审。而单独剥离出开发负责人后,可以更好的对开发过程进行跟踪和协调,开发负责人重点放在项目内部,而避免过多去和外部干系人沟通和协调。

     

      方案三 测试的专职化

      对于项目团队发展到5-10的时候,项目中的测试工作必须专职化的由测试人员来完成。一般测试人员的配置比例为4-6个开发人员需要配置一名专职化的测试人员。测试人员站在第三方和模拟使用者角度来进行系统的测试,可以更好的发现系统的BUG和相关问题,有效的保证系统的质量。

      方案三中项目经理工作进一步清晰,项目经理不在承担软件需求和架构的相关工作。而重点放在项目内外的沟通协调和整个项目进度计划的安排上。这个时候项目中的设计负责人对整个系统的总体设计方案和架构负责,而且设计负责人也将不在参与具体的功能模块的设计和开发工作。设计负责人的重点转化到的软件需求的开发和总体设计上面(如涉及到RUP中的用例建模,用例分析,架构设计,组件接口复用)。

     

      方案四 项目经理和需求角色分离

      当项目团队的规模发展到12-20人的时候,项目团队基本上可以算做中小型的项目团队。这个时候项目经理完全专职化做项目管理的工作。包括项目进度计划制定,项目跟踪监控,风险分析和控制,项目度量分析和决策等相关内容。对于需求活动设置专门的需求工程师岗位来完成需求的开发。同时项目中设置专门的架构设计人员,架构设计人员不再负责需求的开发工作,而重点在于系统总体设计方案的确定,系统的4+1视图的分析,同时架构人员要考虑整个系统的集成方案的确定和具体功能单元和模块的集成。

      由于项目规模的扩大,项目的配置项更加复杂,项目也需要同时起开发,测试,集成和BugFix等多个分支。因此需要设置专门的配置管理员来进行项目的配置管理。

      对于项目同时需要开发新版本,又需要对已经发布的维护版本进行功能改进的时候,项目中要考虑设置专门的维护人员。由维护人员来完成项目小功能的改进和BUG的修复。这样新版本设计开发人员可以更专注的进行新功能的开发。

     

     

     

     

     

     

     

    阶段完成标志

      在项目开发过程中,当一个阶段完成后才会开展下一个阶段的工作;另外,“某个阶段完成”通常被定义为项目的一个里程碑,里程碑标识了项目的进度,它是项目开发和控制的重要参考,对整个项目有重要的意义。因此,“确证某个阶段是否已经完成”的工作非常有重要。

     

    • 每一个阶段的结束以它特定任务的完成为象征

      只有当某个阶段中被规定的所有工作任务都完成了,这个阶段才算真正结束,整个项目才可以进入到下一个阶段中去。反过来说,要是阶段中某个任务没有全部完成,按照项目的定义,整个阶段就不能算是完成,因此项目就不能进入到下一个阶段去。

    • 衡量阶段结束的工作结果必须是实在的交付品

      阶段中的任务是否完成是透过任务活动中产生的交付品来体现的,交付品必须是可交付的、非抽象的、实质的并且可以通过用衡量的方法来判断是否真正地完成了的具体事物。如:某一阶段的完成是以建造一个样品或完成某分文件作为象征。任何项目阶段的结束,都应该有这样的实质性东西的完成作为象征。

    • 跨阶段的进程以阶段结尾的合格验证和审核来决定

      当一个阶段结束时,在进入到下一个阶段之前所需要做的工作应包括对交付品进行合格验证,并检查这一阶段的工作质量和效率,由此判断是否可以进入到下一个阶段。这些检验象征了一个阶段的结尾终点,表示项目的进程离开了上一个阶段而进入了下一个阶段。

     

     

     

     

     

         1 相关系统分析员和用户初步了解需求,然后用WORD列出要开发的系统的大功能模块,每个大功能模块有哪些小功能模块,对于有些需求比较明确相关的界面时,在这一步里面可以初步定义好少量的界面。 
      2 系统分析员深入了解和分析需求,根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚例用系统大致的大功能模块,大功能模块有哪些小功能模块,并且还例出相关的界面和界面功能。 
      3 系统分析员和用户再次确认需求。 
      4 系统分析员根据确认的需求文档所例用的界面和功能需求,用迭代的方式对每个界面或功能做系统的概要设计。 
      5 系统分析员把写好的概要设计文档给程序员,程序员根据所例出的功能一个一个的编写。 
      6 测试编写好的系统。交给用户使用,用户使用后一个一个的确认每个功能,然后验收。 


      举个例子来看: 
      1 某公司想找人订做一套人事管理软件,从某种渠道上得知我们有提供这种服务,所以联系上了我们。 \
      2 我们会派专门的软件工程师到他们那里去了解我们要设计一个什么的东西给他们用,然后回来做个方案给他们,其中方案的内容包括:我们开发出来的软件大概的界面是怎样?方便什么人使用?什么人可以使用什么功能?方便到什么程度?大概的硬件要求是怎样等? 
      3 他们看了方案后,确定他们就是要做一套这样的软件,我就开始开发这套软件。 
      4 我们把开发出来的软件交用他们使用,其中在使用的过程中哪里使用不方便或哪里达不到要求,我们会第第一时间修改这些功能,直到他们要求的所有功能都能很完美的解决掉。









     

    转载于:https://www.cnblogs.com/hwaggLee/p/4483720.html

    展开全文
  • 项目开发流程(简述)

    千次阅读 2021-06-02 20:39:23
    编写项目计划书 系统设计 系统目标 系统功能结构 系统流程开发环境 文件夹组织结构 搭建lamp环境 数据库设计 数据库分析 数据库概念设计 使用PowerDesigner建模 创建数据库及数据表 ...
    •     软件开发流程,是指软件开发、设计的一般性过程,包括软件总体结构、模块构成、功能的设计,以及程序的编写、调试、程序联调、测试等等过程。

          软件开发必须要遵从一定的流程、技术开发规范,软件开发团队中的每个成员都遵照统一的规范部署去设计、开发、测试、沟通,才能提高开发的效率,提高项目开发的质量。软件开发流程一般有以下八个阶段:

       软件开发流程

      1、项目开发目的分析与确定

          软件开发流程的这一阶段,主要是在在软件开发商将开发项目确定下来之后,需要与需求方进行讨论,确定需求方对于软件开发的需要实现目标及其具体需要的功能等等,并确定是否可达成。

      2、需求分析

          这是软件开发流程的第二个阶段,也是为软件开发的正常进行确定具体思路的阶段。在确定软件开发可进行后,必须要对客户需要实现的软件功能需求进行具体详细的分析。同时应当考虑在开发过程中可能出现的变化情况,制定需求变更计划随时应对特殊情况的发生,保证软件开发流程的顺畅进行。

      3、设计

          软件设计要根据上一阶段对软件功能需求分析的结果,来设计软件系统的框架结构、功能模块和数据库等等。分为总体设计和详细设计两个部分,

      4、编程

          软件开发流程中每上一个阶段都是下一个阶段的实施进行的基础。编程也是根据对软件设计,将软件设计的各部分需求通计算机程序代码来实现运行,编程有统一、规范的程序编写规则,保证软件程序的易懂性、易维护性。

      5、软件测试

          在根据设计将客户软件需用编程代码来实现之后,也就是软件程序完成之后,需要对编写的程序,形成整体构架、功能进行单元、组装、系统三阶段的测试,以测试程序编写的正确性,以及对客户需求功能满足的充分性,以此来确定软件是否达到开发要求,同时也是一个发现问题、纠正问题的过程。

      6、软件交付

          软件开发流程通过以上核心环节完成了软件开发,接下来就是在软件开发达到客户需求之后,开发者将软件系统交予客户,并将软件安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等产物交付给客户,同时指导客户进行软件安装、以及安装技巧,提醒客户注意软件运行状况、环境、服务器及相关中间件的检测与注意事项,知道客户软件的实际操作方法、使用流程等等问题,实现合同规定任务。

      7、验收

          用户在接收开发商交付的软件开发结果,并进行实际操作、测试运行,实现满意结果之后,对开发出来的软件进行验收。

      8、维护

          定制开发的软件通常都需要提供售后服务,定期对软件进行维护,或者根据用户出现的新需求,进行应用软件程序的修改,使之不断满足客户实际需求。

    • 网站测试
    • 发布网站
    展开全文
  • 项目开发流程

    千次阅读 2019-11-01 09:55:11
    项目开发流程图    抽空总结了下项目开发流程,大多数公司应该都沿用这个流程方式。

    项目开发流程图

       抽空总结了下项目开发流程,大多数公司应该都沿用这个流程方式。
    在这里插入图片描述

    展开全文
  • 完整的 汽车项目管理新产品开发流程, 汽车项目管理新产品开发流程, 汽车项目管理新产品开发流程, 汽车项目管理新产品开发流程, 汽车项目管理新产品开发流程, 汽车项目管理新产品开发流程, 汽车项目管理新产品...
  • 软件项目开发文档大全 软件项目管理文档大全 软件项目文档模板 大公司软件项目文档模板 文档内容有详细介绍,文档内容规范全面,参考价值明显
  • 嵌入式项目开发流程概述

    千次阅读 2019-02-20 16:10:06
    一、嵌入式项目开发流程 1、在做某一个完整的嵌入式项目时,应该先结合着数据手册,把项目中需要用的的底层资源写好,配置好各个相应的寄存器。 2、当所有的底层驱动都调试完成后,就可以开始着手构思整个项目的...
  • 一个完整的软件项目开发流程

    万次阅读 2019-03-08 12:33:28
    《IT项目管理与职业生涯规划大型论坛》中国.苏州 免费报名:http://www.hdb.com/party/b8an2.html?hdb_pos=manager_info 在我转产品之前,虽然我混迹IT行业,做过实施和售前,也跟研发打过交道,但我一直都不知道...
  • IT项目开发流程

    万次阅读 多人点赞 2019-06-01 11:48:24
    项目开发流程: 一、需求分析: 相关系统分析员向用户初步了解需求,然后用相关的工具软件列出要开发的系统的大功能模块,每个大功能模块有哪些小功能模块,对于有些需求比较明确相关的界面时,在这一步里面可以...
  • 要具体掌握的话就是可以用51开发产品,那其实大部分工作不在51上,而在项目业务实现上 比如你要做室内温湿度显示器 1.首先你得先设计硬件选型,这个得看模块参数,比如温度模板,湿度模板,显示器选择,电源选择,...
  • 国内IT项目开发流程

    千次阅读 2019-10-16 08:19:08
    参考 1、IT项目开发流程
  • 沃尔沃汽车产品开发流程及整车项目计划 车厂培训教材
  • 团队项目开发流程总结

    千次阅读 2020-07-29 22:35:42
    1、开发流程 在确定好开发人员和项目需求之后,就需要进行任务分配和项目排期,团队成员需要根据个人的情况去理性的评估完成任务内容自己所需要花费的天数。所谓承诺即交付,项目团队开发成员在确定过任务完成日期...
  • 项目开发过程中遇到的问题

    千次阅读 2019-05-10 09:37:24
    1、逻辑问题:结构、处理流程的设计有问题,尤其在多线程操作同一个对象时; 2、接口定义和使用问题:例如接口结构或返回情况改了,未及时编译或更改其他模块的调用; 3、对接问题:对讲问题不是你的问题,就是我的...
  • 程序流程图 程序流程图又称程序框图,是...产品开发项目建议流程图,主要对市场进行详细系统的分析,确定研发产品类型、规格参数、性能指标、安全性能等信息以及新产品研发的可行性评估。在有一些比较复杂的流程的时候.
  • 结合本人参加实际项目的经验和大学期间的课程所学,总结了项目开发的一般流程(面向对象),以图文形式表述了出来,希望给大家进行交流,有不足的地方也请大家补充、交流……
  • 嵌入式项目开发过程嵌入式项目开发过程嵌入式项目开发过程嵌入式项目开发过程嵌入式项目开发过程嵌入式项目开发过程嵌入式项目开发过程嵌入式项目开发过程嵌入式项目开发过程嵌入式项目开发过程嵌入式项目开发过程...
  • 完整的.NET三层架构开发项目,包含sqlserver数据库文件,值得好好学习。
  • 项目开发的完整流程(详解版)

    千次阅读 2021-04-08 11:30:24
    项目开发的完整流程 前言 一般情况下,企业开发软件时会按照基线和定制两块并行方式执行项目开发工作。无论什么公司,都需要遵从一套成熟的产品研发过程体系,才能做出质量较好的产品。因此,如果出现项目较多的...
  • 基于Java的项目开发过程

    千次阅读 2018-01-31 16:49:59
    完整项目开发过程 原型的设计有产品经理负责。 界面的美化有专门的美工负责。 前端有专门的前端开发人员负责。 研发:研发主要工作就是根据项目的需求文档设计系统架构、设计数据库、编写调试程序代码。对于...
  • 一、工作中的一些形式和岗位 上班的形式: 1、自研:A公司面试、A公司签合同,最后去A公司上班 ...1、项目经理:主要和甲方对接,起到甲方和技术人员之间承上启下的作用,并且把控整个项目开发流程进度
  • 通用汽车公司IT部门的软件项目开发流程,要求所有参与通用汽车软件开发的公司按照流程规范执行,实际上是CMMI体系在通用汽车公司的实践

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,480,086
精华内容 592,034
关键字:

项目开发流程