[软件技术开发合同]软件开发技术方案

来源:合同范本 时间:2018-08-08 15:00:02 阅读:

【www.bbjkw.net--合同范本】

第一篇软件开发技术方案:软件项目开发计划书模板


  一份好的项目计划书的特点是:关注产品、敢于竞争、充分市场调研,有力资料说明、表明行动的方针、展示优秀团队、良好的财务预计等几点,从而使合作伙伴会更了解项目的整体情况及业务模型,也能让投资者判断该项目的可盈利性。以下是小编整理的关于软件项目开发计划书模板范文。欢迎大家参考!
  一、项目计划书格式

  根据《GB8567-88计算机软件产品开发文件编制指南》中项目开发计划的要求,结合实际情况调整后的《项目计划书》内容索引如下:(略)
  二、项目计划书的编写说明
  1引言
  1.1编写目的
  说明编写这份项目计划的目的,并指出预期的读者。
  作用:本节是为了说明编制“项目计划书”亦即本文档的意图和希望达到的效果。注意这里的“目的”不是“项目目标”,而是为了说明本文档的目的与作用。“项目目标”在2.1中说明。
  意义:使项目成员和项目干系人了解项目开发计划书的作用、希望达到的效果。开发计划书的作用一般都是“项目成员以及项目干系人之间的共识与约定,项目生命周期所有活动的行动基础,以便项目团队根据本计划书开展和检查项目工作。”
  例如可以这么写:为了保证项目团队按时保质地完成项目目标,便于项目团队成员更好地了解项目情况,使项目工作开展的各个过程合理有序,因此以文件化的形式,把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式,作为项目团队成员以及项目干系人之间的共识与约定,项目生命周期内的所有项目活动的行动基础,项目团队开展和检查项目工作的依据。
  常见的问题:把项目本身的“项目目标”误作编制项目开发计划的目的。
  1.2背景
  主要说明项目的来历,一些需要项目团队成员知道的相关情况。主要有以下内容:
  项目的名称:经过与客户商定或经过立项手续统一确定的项目名称,一般与所待开发的软件系统名称有较大的关系,如针对“XX系统”开发的项目名称是“XX系统开发”。
  项目的委托单位:如果是根据合同进行的软件开发项目,项目的委托单位就是合同中的甲方;如果是自行研发的软件产品,项目的委托单位就是本企业。
  项目的用户(单位):软件或网络的使用单位,可以泛指某个用户群。注意项目的用户或单位有时与项目的委托单位是同一个,有时是不一样的。如海关的报关软件、税务的报税软件,委托单位是海关或税务机关,但使用的用户或单位不仅有海关或税务机关,还包括需要报关、报税的企业单位。
  项目的任务提出者:本企业内部提出需要完成此项目的人员,一般是领导或商务人员;注意项目的任务提出者一般不同于项目的委托单位,前者一般是企业内部的人员。如果是内部开发项目,则两者的区别在于前者指人,后者指单位。
  项目的主要承担部门:有些企业根据行业方向或工作性质的不同把软件开发分成不同的部门(也有的分为不同事业部)。项目的特点就是其矩阵式组织,一般一个项目的项目成员可能由不同的部门组成,甚至可能由研发部门、开发部门、测试部门、集成部门、服务部门等等其中几个组成。需要根据项目所涉及的范围确定本项目的主要承担部门。
  项目建设背景:从政治环境上、业务环境上说明项目建设背景,说明项目的大环境、来龙去脉。这有利于项目成员更好地理解项目目标和各项任务。
  例句:根据《某部关于某建设工作的实施意见》精神,为了保障某建设工作的正常实施,必须加强监督考核,建立督查通报制度,某市某建设工作小组办公室把此项建设工作实施列入督查的重要内容,及时掌握进度,相关部门建立市某建设工作简报制度,及时反映全市某建设工作动态。
  目前对于某建设工作的工作主要采用计划部门手工编制年度计划、建设工作主管部门和建设工作实施单位联合手动编制进度计划,某建设工作单位手工上报建设工作进度情况的方式,而全市的建设工作有数百个,加上前期建设工作的数量和今后某市建设发展的趋势,建设工作的数量将越来越多,原来的工作模式已经越来越无法适应市委市政府的要求。因此,充分利用现代信息化、因特网的优势,建立“某市某建设工作信息报送反馈系统”,提高某建设工作信息报送反馈工作效率,提高信息的及时性、减轻各级相关工作人员的劳动强度是非常有必要和紧迫的任务。
  软件系统与其他系统的关系:说明与本系统有关的其他系统,说明它们之间的相互依赖关系。这些系统可以是这个系统的基础性系统(一些数据、环境等必须依靠这个系统才能运行),也可以是以这个系统为基础的系统,或者是两者兼而有之的关系、互相依赖的系统。例句:本系统中对外部办公部分如需要各个建设单位报送材料的子系统应当挂在市政府网站。
  软件系统与机构的关系:说明软件系统除了委托单位和使用单位,还与哪些机构组织有关系。例如一些系统需要遵守那些组织的标准、需要通过那些组织机构的测试才能使用等等、是否需要外包或与那些组织机构合作。
  1.3定义
  列出为正确理解本计划书所用到的专门术语的定义、外文缩写词的原词及中文解释。注意尽量不要对一些业界使用的通用术语进行另外的定义,使它的含义和通用术语的惯用含义不一致。
  1.4参考资料
  列出本计划书中所引用的及相关的文件资料和标准的作者、标题、编号、发表日期和出版单位,必要时说明得到这些文件资料和标准的途径。本节与下一节的“标准、条约和约定”互为补充,注意“参考资料”未必作为“标准、条约和约定”,因为“参考”的不一定是“必须遵守”的。常用资料如:
  本项目的合同、标书、上级机关有关通知、经过审批的项目任务书;
  属于本项目的其他已经发表的文件;
  本文档中各处引用的文件、资料,包括所要用到的软件开发标准。
  1.5标准、条约和约定
  列出在本项目开发过程中必须遵守的标准、条约和约定。例如:相应的《立项建议书》、《项目任务书》、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技术规范等。
  “参考资料”一般具有“物质”特性,一般要说明参照了什么,要说明在哪里可以获得;“标准、条约和约定”一般具有“精神”特性,一般是必须遵守的,不说明在哪里可以获得。参考资料的内容应该涵盖“标准、条约和约定”。
  2项目概述
  2.1项目目标
  设定项目目标就是把项目要完成的工作用清晰的语言描述出来,让项目团队每一个成员都有明确的概念。注意,不要简单地说成在什么什么时间完成开发什么什么软件系统或完成什么什么软件安装集成任务。注意“要完成一个系统”只是一个模糊的目标,它还不够具体和明确。明确的项目目标应该指出了服务对象,所开发软件系统最主要的功能和系统本身的比较深层次的社会目的或系统使用后所起到的社会效果。
  项目目标应当符合SMART原则:
  lSSpecific明确的陈述
  lMMeasurable可以衡量的结果
  lAAttainable可以达成的目标
  lRRealistic合理的,现实的或者说是能和实际工作相结合
  lTTrackable可以跟踪的
  项目目标可以进行横向的分解也可以进行纵向的分解。横向分解一般按照系统的功能或按照建设单位的不同业务要求,如分解为第一目标、第二目标等等;纵向的分解一般是指按照阶段,如分解为第一阶段目标、第二阶段目标等等,或近期目标、中期目标、远期目标等等。阶段目标一般应当说明目标实现的较为明确的时间。一般要在说明了总目标的基础上再说明分解目标,可加上“为实现项目的总目标,必须实现以下三个阶段目标······”
  2.2产品目标与范围
  根据项目输入(如合同、立项建议书、项目技术方案、标书等)说明此项目要实现的软件系统产品的目的与目标及简要的软件功能需求。对项目成果(软件系统)范围进行准确清晰的界定与说明是软件开发项目活动开展的基础和依据。软件系统产品目标应当从用户的角度说明开发这一软件系统是为了解决用户的那些问题。产品目标如“提高工作信息报送反馈工作效率,更好地进行工作信息报送的检查监督,提高信息的及时性、汇总统计信息的准确性,减轻各级相关工作人员的劳动强度。”
  2.3假设与约束
  对于项目必须遵守的各种约束(时间、人员、预算、设备等)进行说明。这些内容将限制你实现什么、怎样实现、什么时候实现、成本范围等种种制约条件。
  假设是通过努力可以直接解决的问题,而这些问题是一定要解决才能保证项目按计划完成。如:“系统分析员必须在3天内到位”或“用户必须在8月8日前确定对需求文档进行确认”
  约束一般是难以解决的问题,但可以通过其他途径回避或弥补、取舍,如人力资源的约束限制,就必须牺牲进度或质量等等。
  假设与约束是针对比较明确会出现的情况,如果问题的出现具有不确定性,则应该在风险分析中列出,分析其出现的可能性(概率)、造成的影响、应当采取的相应措施。
  2.4项目工作范围
  说明为实现项目的目标需要进行那些工作。在必要时,可描述与合作单位和用户的工作分工。
  注意产品范围与项目工作范围的不同含义。
  产品范围界定:软件系统产品本身范围的特征和功能范围。
  工作范围界定:为了能够按时保质交付一个有特殊的特征和功能的软件系统产品所要完成的那些工作任务。
  产品范围的完成情况是参照客户的需求来衡量的,而项目范围的完成情况则是参照计划来检验的。这两个范围管理模型间必须要有较好的统一性,以确保项目的具体工作成果,能按特定的产品要求准时交付。
  2.5应交付成果
  2.5.1需完成的软件
  列出需要完成的程序的名称、所用的编程语言及存储程序的媒体形式。其中软件对象可能包括:源程序、数据库对象创建语句、可执行程序、支撑系统的数据库数据、配置文件、第三方模块、界面文件、界面原稿文件、声音文件、安装软件、安装软件源程序文件等等。
  2.5.2需提交用户的文档
  列出需要移交给用户的每种文档的名称、内容要点及存储形式,如需求规格说明书、帮助手册等。此处需要移交用户的文档可参考合同中的规定。
  2.5.3须提交内部的文档
  可根据《GB8567-88计算机软件产品开发文件编制指南》附录O:“文件编制实施规定的实例(参考件)”结合各企业实际情况调整制定《软件开发文档编制裁减衡量因素表》。根据《因素表》确定项目对应的项目衡量因素取值,以确定本项目应完成的阶段成果。将不适用于本项目的内容裁减,以减少不必要的项目任务和资源。
  根据因素取值列出本项目应完成的阶段成果,说明本项目取值所在的区间,将其他因素值区间删除。
  2.5.4应当提供的服务
  根据合同或某重点建设工作需要,列出将向用户或委托单位提供的各种服务,例如培训、安装、维护和运行支持等。具体的工作计划如需要编制现场安装作业指导书、培训计划等,应当在本计划“4.3总体进度计划”中条列出。
  2.6项目开发环境
  说明开发本软件项目所需要的软硬件环境和版本、如操作系统、开发工具、数据库系统、配置管理工具、网络环境。环境可能不止一种,如开发工具可能需要针对Java的,也需要针对C++的。有些环境可能无法确定,需要在需求分析完成或设计完成后才能确定所需要的环境。
  2.7项目验收方式与依据
  说明项目内部验收和用户验收的方式,如验收包括交付前验收、交付后验收、试运行(初步)验收、最终验收、第三方验收、专家参与验收等等。项目验收依据主要有标书、合同、相关标准、项目文档(最主要是需求规格说明书)。
  3项目团队组织
  3.1组织结构
  说明项目团队的组织结构。项目的组织结构可以从所需角色和项目成员两个方面描述。所需角色主要说明为了完成本项目任务,项目团队需要哪些角色构成,如项目经理、计划经理、系统分析员(或小组)、构架设计师、设计组、程序组、测试组等等。组织结构可以用图形来表示,可以采用树形图,也可以采用矩阵式图形,同时说明团队成员来自于哪个部门。除了图形外,可以用文字简要说明各个角色应有的技术水平。
  注意虽然有一些通用的结构可以套用,但各种不同规模、不同形式的项目组织结构是不一样的。如产品研发项目可能就不需要实施人员(小组),但需要知识转移方面的人员(小组)。而软件编码外包的项目则不需要程序员,测试人员也可以适当地减少。
  3.2人员分工
  确定项目团队的的每个成员属于组织结构中的什么角色,他们的技术水平、项目中的分工与配置,可以用列表方式说明,具体编制时按照项目实际组织结构编写。以下是一个示例。
  3.3协作与沟通
  项目的沟通与协作首先应当确定协作与沟通的对象,就是与谁协作、沟通。沟通对象应该包括所有项目干系人,而项目干系人包括了所有项目团队成员、项目接口人员、项目团队外部相关人员等等。
  其次应当确定协作模式与沟通方式。沟通方式如会议、使用电话、QQ、内部邮件、外部邮件、QuickPlace、聊天室等等。其中邮件沟通应当说明主送人、抄送人,聊天室沟通方式应当约定时间周期。而协作模式主要说明在出现什么状况的时候各个角色应当(主动)采取什么措施,包括沟通,如何互相配合来共同完成某项任务。定期的沟通一般要包括项目阶段报告、项目阶段计划、阶段会议等
  3.3.1项目团队内部协作
  本节说明在项目开发过程中项目团队内部的协作模式和沟通方式、频次、沟通成果记录办法等内容。
  3.3.2项目接口人员
  应当说明接口工作的人员即他们的职责、联系方式、沟通方式、协作模式,包括:
  a、负责本项目同用户的接口人员;
  b、负责本项目同本企业各管理机构,如计划管理部门、合同管理部门、采购部门、质量管理部门、财务部门等的接口人员;
  c、负责本项目同分包方的接口人员。
  3.3.3项目团队外部沟通与协作模式
  项目团队外部包括企业内部管理协助部门、项目委托单位、客户等等。本节说明在项目开发过程中项目团队内部与接口人员、客户沟通的方式、频次、沟通成果记录办法等内容。明确最终用户、直接用户及其所在本企业/部门名称和联系电话。明确协作开发的有关部门的名称、经理姓名、承担的工作内容以及工作实施责任人的姓名、联系电话。确定有关的合作单位的名称、负责人姓名、承担的工作内容以及实施人的姓名、联系电话。
  4实施计划
  4.1风险评估及对策
  识别或预估项目进行过程中可能出现的风险。应该分析风险出现的可能性(概率)、造成的影响、根据影响应该采取的对策,采取的措施。风险识别包括识别内在风险及外在风险。内在风险是指项目工作组能加以控制和影响的风险,如人事任免和成本估计等。外在风险指超出项目工作组等控制力和影响力之外的风险,如市场转向或政府行为等
  风险的对策包括:避免:排除特定危胁往往靠排除危险起源;减缓:减少风险事件的预期资金投入来减低风险发生的概率,以及减少风险事件的风险系数;吸纳:接受一切后果,可以是积极的(如制定预防性计划来防备风险事件的发生),也可以是消极的(如某些费用超支则接受低于预期的利润)。
  对于软件开发项目而言,在分析、识别和管理风险上投入足够的时间和人力可以使项目进展过程更加平稳,提高项目跟踪和控制的能力,由于在问题发生之前已经做了周密计划,因而对项目的成功产生更加充分的信心。
  软件开发项目常见预估的风险:
  1)工程/规模/进度上的风险
  规模大,规模估算不精确甚至误差很大;就规模而言,用户要求交付期、费用很紧;预料外的工作(测试未完时的现场对应等);
  2)技术上的风险
  使用新的开发技术、新设备等,或是新的应用组合,没有经验;是新的行业或业务,没有经验;性能上的要求很严;
  3)用户体制上的问题
  用户管理不严,恐怕功能决定、验收不能顺利地完成(或者出现了延迟);或者恐怕功能会多次变更;与用户分担开发,恐怕工程会拖延(或者出现了延迟);用户或其他相关单位承担的工作有可能延误;
  4)其它:应该包含此处没有、但据推测有风险的项目。
  4.2工作流程
  说明项目采用什么样的工作流程进行。如瀑布法工作流程,原型法工作流程、螺旋型工作流程、迭代法工作流程,也可以是自己创建的工作流程。不同的流程将影响后面的工作计划的制定。必要时画出本项目采用的工作流程图及适当的文字说明。
  4.3总体进度计划
  这里所说的总体进度计划为高层计划。作为补充,应当分阶段制定项目的阶段计划,这些阶段计划不在这份文档中,当要以这份总体计划为依据。
  总体进度计划要依据确定的项目规模,列表项目阶段划分、阶段进度安排及每阶段应提交的阶段成果,在阶段时间安排中要考虑项目阶段成果完成、提交评审、修改的时间。
  对于项目计划、项目准备、需求调研、需求分析、构架设计或概要设计、编码实现、测试、移交、内部培训、用户培训、安装部署、试运行、验收等工作,给出每项工作任务的预定开始日期、完成日期及所需的资源,规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件(里程碑)。
  设计评审
  表格中检查点/里程碑等阶段划分为举例,实际作业阶段划分、阶段成果等请根据项目需要确定。
  制定软件项目进度计划可以使用一些专门的工具,最常用的是Microsoft的Project作为辅助工具,功能比较强大,比较适合于规模较大的项目,但无法完全代替项目计划书,特别是一些主要由文字来说明的部分。小规模的项目可简便地使用EXCEL作为辅助工具。关于如何使用这些工具不在此作详细说明。
  制定软件项目进度计划应当考虑以下一些因素:
  1)对于系统需求和项目目标的掌握程度。如开始时对于系统需求和项目目标只有比较数的了解,就只能制定出比较粗的进度计划,等到需求阶段或设计阶段结束,就应该进一步细化进度计划。
  2)软件系统规模和项目规模,这两个不是一个概念。软件系统规模往往是从功能点的估算或其他估算方式得来的,而项目规模还要考虑对文档数量与质量的要求,使用的开发工具、新技术、多少复用、沟通的方便程度、客户方的情况、需要遵守的标准规范等等等等。例如,完成一个大型的系统,在一定的时间内一个人或几个人的智力和体力是承受不了的。由于软件是逻辑、智力产品,盲目增加软件开发人员并不能成比例地提高软件开发能力。相反,随着人员数量的增加,人员的组织、协调、通信、培训和管理方面的问题将更为严重。
  3)软件系统复杂程度和项目复杂程度:和软件系统规模和项目规模一样,软件系统的复杂程度主要是考虑软件系统本身的功能、架构的复杂程度,而项目的复杂程度主要是指项目团队成员的构成、项目任务的复杂程度、项目干系人的复杂程度、需求调研的难易程度,多项目情况下资源保障的情况,等等等等。软件系统的规模与软件系统的复杂程度未必是成比例的关系;同样项目的规模与项目的复杂程度未必是成比例的关系。
  4)项目的工期要求,就是项目的紧急程度。有些项目规模大,却因为与顾客签订了合同,或者为了抢先占领市场,工期压缩得很紧,这时就要考虑如何更好地合理安排进度,多增加人选多采用加班的方式是一种万不得已的选择。增加人选除了增加人的成本外必定会增加沟通的成本(熟悉项目任务所需要的时间);加班如果处理不好会造成情绪上的问题,也可能会因为过于忙碌而无法顾及质量,造成质量的下滑。
  5)项目成员的能力。这些能力包括项目经理的管理能力,系统分析员的分析能力、系统设计人员的设计能力、程序员的编码能力、测试人员的测试能力,以及企业或项目团队激发出这些能力的能力。从另外一个角度看还有总体上对客户行业业务的熟悉程度;对于建模工具、开发工具、测试工具等技术的掌握程度;企业内部对行业业务知识和主要技术的知识积累。
  4.4项目控制计划
  4.4.1质量保证计划
  执行质量评审活动,对过程质量进行控制。规模较大的项目应当单独编写《软件开发项目质量计划》。根据GB/T12504计算机软件质量保证计划规范,内容包括:
  l引言(本章节包括质量计划的目的、定义、参考资料)
  l管理(描述负责软件质量管理的机构、任务及其相关的职责)
  l文档(列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档,并描述对文档进行评审与检查的准则)
  l标准、条例和约定(列出软件开发过程中要用到的标准、条例和约定,并列出监督和保证执行的措施)
  l评审和检查(规定所要进行的技术和管理两个方面的评审和检查工作,并编制或引用有关的评审和检查规程,以及通过与否的技术准则。至少要进行软件需求评审、概要设计评审、软件验证与确认评审、软件系统功能检查、程序和文档物理检查)
  l软件配置管理(编制有关配置管理条款,或在“4.4.4配置管理计划”中说明,或引用按照《GB/T12505计算机软件配置管理计划规范》单独制定的文档)
  l工具、技术和方法(指明用于支持特定软件项目质量管理工作的工具、技术和方法,指出它们的目的和用途)
  l媒体控制(说明保护计算机程序物理媒体的方法和设施,以免非法存取、意外损坏或自然老化)
  l对供货单位的控制(供货单位包括项目承办单位、软件销售单位、软件开发单位。规定对这些供货单位进行控制的规程,从而保证项目承办单位从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的需求。)
  l记录的收集、维护和保存(指明需要保存的软件质量保证活动的记录,并指出用于汇总、保护和维护这些记录的方法和设施,并指明要保存的期限)
  4.4.2进度控制计划
  (可直接引用以下描述或根据项目情况制定本节内容)
  本项目的进度监控执行本企业《项目管理规范》,由本企业过程控制部门如质量管理部统一进行监控,并保留在监控过程中产生的日常检查记录。
  4.4.3预算监控计划
  说明如何检查项目预算的使用情况。根据项目情况需要制定。
  4.4.4配置管理计划
  编制有关软件配置管理的条款,或引用按照GB/T12505单独制订《配置管理计划》文档。在这些条款或文档中,必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施;必须规定对所发现的软件问题进行报告、追踪和解决的步骤,并指出实现报告、追踪和解决软件问题的机构及其职责。
  5支持条件
  说明为了支持本项目的完成所需要的各种条件和设施。
  5.1内部支持
  逐项列出项目每阶段的支持需求(含人员、设备、软件、培训等)及其时间要求和用途。
  例如,设备、软件支持包括客户机、服务器、网络环境、外设、通讯设备、开发工具、操作系统、数据库管理系统、测试环境,逐项列出有关到货日期、使用时间的要求。
  5.2客户支持
  列出对项目而言需由客户承担的工作、完成期限和验收标准,包括需由客户提供的条件及提供时间。
  5.3外包(可选)
  列出需由外单位分合同承包者承担的工作、完成时间,包括需要由外单位提供的条件和提供的时间。
  6预算
  6.1人员成本
  列出产品/项目团队每一个人的预计工作月数。
  列出完成本项目所需要的劳务(包括人员的数量和时间)
  劳务费一般包括工资、奖金、补贴、住房基金、退休养老金、医疗保险金
  6.2设备成本
  设备成本包括:原材料费,设备购置及使用费
  列出拟购置的设备及其配置和所需的经费
  列出拟购置的软件及其版本和所需的经费
  使用的现有设备及其使用时间
  6.3其它经费预算
  列出完成本项目所需要的各项经费,包括差旅费、资料费、通行费、会议费、交通费、办公费、培训费、外包费等,包括:
  (1)差旅费(旅费、出租)(含补贴)
  (2)资料费(图书费、资料费、复印费、出版费)
  (3)通信费(市话长话费、移动通信费、上网费、邮资)
  (4)会议费(鉴定费、评审会、研讨费、外事费等)
  (5)办公费(购买办公用品)
  (6)协作费(业务协作招待费、项目团队加班伙食费)
  (7)培训费(培训资料编写费、资料印刷费、产地费、设备费)
  其他(检测、外加工费、维修费、消耗品、低易品、茶话会等)
  6.4项目合计经费预算
  列出完成本项目需要的所有经费预算(上述各项费用之和)。
  7关键问题
  逐项列出能够影响整个项目成败的关键问题、技术难点和风险,指出这些问题对项目成败的影响。
  8专题计划要点
  专题计划也就是因为项目的需要在本文档之外独立建立的计划,本节说明本项目开发中需要制定的各个专题计划的要点。专题计划可能包括分合同计划、分项目计划、项目团队成员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装部署计划。
猜您想看:
1.大学生创业项目计划书模板
2.蛋糕店创新创业项目计划书模板
3.2017房地产项目开发计划书模板
4.经典项目开发计划书模板
5.企业项目计划书模板
6.咖啡厅创业项目计划书模板
7.项目计划书模板

第二篇软件开发技术方案:新项目开发计划书

  任何新项目从立项到诞生都不是一帆风顺的,下面就是小编为您收集整理的新项目开发计划书的相关文章,希望可以帮到您,如果你觉得不错的话可以分享给更多小伙伴哦!
  新项目开发计划书一
  前言:
  我们要从房地产整体的开发、运营、管理、企划、宣传、推广、销售等发展过程的各个环节来考虑我们产品的服务特点卖点及存在的重要性!
  服务-业主
  解决-业主
  创新-业主
  掌控-业主
  利益平衡点-业主、开发商、物业公司、广告商、用户
  市场情况:
  现在房地产行情,未来形势走向,业主心理调查
  产品概述:
  本产品诞生契机:
  随着当今社会智能手机的普及和人们的生活水平不断提高,大家对于生活的质量要求也不断增加,同时对于社区的物业服务质量也特别注重,目前国内住宅小区物业服务水平参差不齐,物业服务管理单一化,不能给住户提供一些物业附加值。而智能社区APP项目可以很好的改变现状,综合小区业主的生活需求和互联网移动发展的趋势,智能社区的理念也因此孕育而生。通过社区APP平台的搭建,以“住”为主,延伸到“衣、食、行”这些人生生活所必须的领域,这种智能化社区也是目前各大开发公司着重研究发展的方向。 市场机会存在意义:
  1、2013 年,中国消费市场受经济增速放缓、需求疲软、控制三公消费等因素叠加影响继续下行,相对而言,黄金珠宝、家电等消费品类表现较好,而服装、日用品等欠佳;网购继续保持高速增长(2013年前3 季度42%),直接分流线下;同时2013年也是传统零售商觉醒的一年,触网成为必然趋势。
  2013年中国的社会零售总额达到24万亿。目前来看,虽然电子商务所占的比例不大,约8%,但按当前增长势头,预计到2020年,也就是7~8年之后,中国的零售总额即将达到50万亿,通过电子商务完成的可能大概能占到36%-40%,也就是20万亿来自电子商务。
  线上电子商务市场的快速增长,将给国内商业地产市场带来巨大冲击。
  2、随着移动终端的发达,以及移动互联网的日趋成熟,在未来,无线互联营销有望成为主流营销之一,广告移动化成为一大趋势。传统互联网与互联网企业都做了很多实质性的探索,有为行业搭建平台,让互联网营销充满无限的预期,同时越来越多的广告主也认可移动营销,这方面的广告投入也逐年增加;
  发展长远性:
  地产公司为何要在物业管理上下如此功夫?据业内专家介绍,房地产行业目前面临着不小的困难,之前的“拿地———开发———卖房”的粗放发展模式已经受到挑战。开发商要迈过这道“坎”,向业主提供更好的配套和服务,充分挖掘业主需求,并提供相应的增值服务,将是未来的发展方向之一。
  App终端软件,互联网官网,线下客户服务
  形成行销一体的初始模式
  定位:
  市场定位:
  1、商业及住宅全业主专属自控服务管理平台
  2、租买用户便捷、查询、联系、交易、管理平台
  3、开发商企划营销初期宣传推广定制服务
  4、物业公司高端智能管理代理合作产品
  5、广告商精准营销的直接全业主客群
  产品定位:
  1、针对于商业及住宅全业主及持有用户的房屋物业全能操控管理、高端电子配套服务平台的app终端软件。
  2、对业主形成真实的信任、便利与利益的深度诱惑。
  3、对新盘开发商前期形象宣传、中期营销推广、售后服务保障起到添彩辅助性的重要作用。
  4、对物业管理公司服务管理增值服务,对征费困难的有效解脱。
  5、对各行业广告商产品精准营销的投放平台。
  品牌:
  业主控(暂定名:优生活)——房产智能app服务管控软件
  研发概念:商业及住宅查询、沟通、交易、管理、维护等用途的业主自主操控软件产品 传播述求:便捷、即时,全面,省心,安全,意外收获……
  产品理念:全能服务,自主管控,实时查阅,得心应手。
  服务类目:(先进性,差异化,附加值)
  新-自控神器,得心应手。
  奇-软件设计,奇特管理。
  特-服务全面,便捷周到。
  1、商业或住宅楼盘基础信息(电子楼书):区域,位置,开发商,产权,户型,周边业态,配套设施,区间房价……
  2、理财系统:缴费代收、所有收费项总览,统计提醒,合理分配支付方案。
  3、咨询维修:电话咨询服务,房屋损坏自拍上报,安排解决时间。
  4、便民服务:衣食住行用,室内装饰、家电维修、餐饮外卖、快递服务、干洗保洁、商场超市,教育培训等等综合服务。
  5、“小强快跑”懒人即时定制雇佣服务:餐饮外卖及用具采买、机票车票代买,酒店预订、接送、搬运、代驾、安保……
  6、即时通知:政府及居委会及物业管理的政策、活动等新消息即时通知发布。
  7、行业信息分享定制:地产行情分析,新盘推荐、汽车、金融……商户及业主论坛
  8、投诉解决:
  9、租售系统:(业主自行发布租售信息含房屋平面图实拍照片等,租户买主可像滴滴打车一样搜寻目标区域房屋及商铺位置,挑选房型价格,费用运营商代收,这样对甲乙方相互可免除中介费用“租售不操心,寻房不折腾”)
  10、随身管家:显示楼盘周边业态服务配套设施,商场,酒店,旅游,餐饮,停车,加油站,银行,办公,行政,派出所……用户不论走到哪里都即时提醒周围情况。如:用户到三餐时间点击用餐服务:如清晨跑步,显示周围早餐店铺;中午及晚上向用户推荐周边各个餐馆的推荐最新菜品和送餐电话;
  11、招商信息:
  12、电子商务:
  13、一目了然功能:所有信息统计明细,扫描诊断,解决方案
  14、其他增值服务:
  服务流程图:app分业主版(隐私数据管理),用户版(目标信息查询,查看联系交易)。 软件下载安装—注册绑定手机或微信—真实数据验证—上传发布信息—即时查阅—管理维护—定制服务
  产品核心价值(技术说明):分层级管控,最顶层全业主数据资源直接掌控,服务模式复制及扩散力强,
  市场同类产品情况:
  1、做的比较成熟的是花样年彩之云社区APP,其功能模块包含:物业缴费、停车缴费、投诉保修、小区通知、生活超市、旅游酒店、火车票、招商加盟等等。虽然其提供的服务内容全面,但是它面临的客
  户群体还是比较单一性,主要是针对其小区的住户。
  2、万科也推出了“住这儿”APP。这款软件更倾向于互动,业主可以在这里参与社区活动,促进邻里沟通,也可以实现报修、房租租售、投诉、物业账单查询、快递领取等物业服务,另外还可以寻找周边商家优惠等
  3、龙湖地产也将推出“龙湖社区通”APP,业主登陆平台后,甚至可以通过手机预订早餐、控制家中空调、远程视频监控等服务。此外,还有绿城、炎华置信等公司推出或即将推出自己的社区物业APP。 风险利弊分析:
  (一)、开发企业自行开发:
  1、优势:资金掌控透明、管理方便、收益独享;
  2、劣势:开发成本高、需要大量人力、整合各方资源;
  (二)、优生活APP与其他社区APP分析:
  1、其他社区APP:主要针对的人群是住宅小区的业主。
  优势:目标客群相对高端,消费能力强;
  劣势:(1)、目标客群只针对社区业主,客户群体单一,广告投放业主选择性有限;(2)、小区覆盖面少,目前只是针对自己开发的住宅 相对较麻烦;
  2、优生活APP:主要是针对三种客户群:1、住宅小区业主;2、办公写字楼白领;3、在校学生。
  优势:1、目标客群全面;2、广告投放主可选择性全;3、广告投放人群更加精准;4、大数据更加全面;
  新项目开发计划书二
  一、目录
  1引言
  1、1编写目的
  1、2背景
  1、3定义
  1、4参考资料
  1、5标准、条约和约定
  2项目概述
  2、1项目目标
  2、2产品目标与范围
  2、3假设与约束
  2、4项目工作范围
  2、5应交付成果
  2、5、1需完成的软件
  2、5、2需提交用户的文档
  2、5、3须提交内部的文档
  2、5、4应当提供的服务
  2、6项目开发环境
  2、7项目验收方式与依据
  3项目团队组织
  3、1组织结构
  3、2人员分工
  3、3协作与沟通
  3、3、1内部协作
  3、3、2外部沟通
  4实施计划
  4、1风险评估及对策
  4、2工作流程
  4、3总体进度计划
  4、4项目监控
  4、4、1质量控制计划
  4、4、2进度监控计划
  4、4、3预算监控计划
  4、4、4配置管理计划
  二、项目计划书的编写说明
  1引言
  1、1编写目的
  说明编写这份项目计划的目的,并指出预期的读者。
  作用本节是为了说明编制“项目计划书”亦即本文档的意图和希望达到的效果。注意这里的“目的”不是“项目目标”,而是为了说明本文档的目的与作用。“项目目标”在2、1中说明。
  意义使项目成员和项目干系人了解项目开发计划书的作用、希望达到的效果。开发计划书的作用一般都是“项目成员以及项目干系人之间的共识与约定,项目生命周期所有活动的行动基础,以便项目团队根据本计划书开展和检查项目工作。”
  例如可以这么写为了保证项目团队按时保质地完成项目目标,便于项目团队成员更好地了解项目情况,使项目工作开展的各个过程合理有序,因此以文件化的形式,把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式,作为项目团队成员以及项目干系人之间的共识与约定,项目生命周期内的所有项目活动的行动基础,项目团队开展和检查项目工作的依据。
  常见的问题把项目本身的“项目目标”误作编制项目开发计划的目的。
  1、2背景
  主要说明项目的来历,一些需要项目团队成员知道的相关情况。主要有以下内容
  项目的名称经过与客户商定或经过立项手续统一确定的项目名称,一般与所待开发的软件系统名称有较大的关系,如针对“XX系统”开发的项目名称是“XX系统开发”。
  项目的委托单位如果是根据合同进行的软件开发项目,项目的委托单位就是合同中的甲方;如果是自行研发的软件产品,项目的委托单位就是本企业。
  项目的用户(单位)软件或网络的使用单位,可以泛指某个用户群。注意项目的用户或单位有时与项目的委托单位是同一个,有时是不一样的。如海关的报关软件、税务的报税软件,委托单位是海关或税务机关,但使用的用户或单位不仅有海关或税务机关,还包括需要报关、报税的企业单位。
  项目的任务提出者本企业内部提出需要完成此项目的人员,一般是领导或商务人员;注意项目的任务提出者一般不同于项目的委托单位,前者一般是企业内部的人员。如果是内部开发项目,则两者的区别在于前者指人,后者指单位。
  项目的主要承担部门有些企业根据行业方向或工作性质的不同把软件开发分成不同的部门(也有的分为不同事业部)。项目的特点就是其矩阵式组织,一般一个项目的项目成员可能由不同的部门组成,甚至可能由研发部门、开发部门、测试部门、集成部门、服务部门等等其中几个组成。需要根据项目所涉及的范围确定本项目的主要承担部门。
  项目建设背景从政治环境上、业务环境上说明项目建设背景,说明项目的大环境、来龙去脉。这有利于项目成员更好地理解项目目标和各项任务。
  例句根据《某部关于某建设工作的实施意见》精神,为了保障某建设工作的正常实施,必须加强监督考核,建立督查通报制度,某市某建设工作小组办公室把此项建设工作实施列入督查的重要内容,及时掌握进度,相关部门建立市某建设工作简报制度,及时反映全市某建设工作动态。
  目前对于某建设工作的工作主要采用计划部门手工编制年度计划、建设工作主管部门和建设工作实施单位联合手动编制进度计划,某建设工作单位手工上报建设工作进度情况的方式,而全市的建设工作有数百个,加上前期建设工作的数量和今后某市建设发展的趋势,建设工作的数量将越来越多,原来的工作模式已经越来越无法适应市委市政府的要求。因此,充分利用现代信息化、因特网的优势,建立“某市某建设工作信息报送反馈系统”,提高某建设工作信息报送反馈工作效率,提高信息的及时性、减轻各级相关工作人员的劳动强度是非常有必要和紧迫的任务。
  软件系统与其他系统的关系说明与本系统有关的其他系统,说明它们之间的相互依赖关系。这些系统可以是这个系统的基础性系统(一些数据、环境等必须依靠这个系统才能运行),也可以是以这个系统为基础的系统,或者是两者兼而有之的关系、互相依赖的系统。例句本系统中对外部办公部分如需要各个建设单位报送材料的子系统应当挂在网站。
  软件系统与机构的关系说明软件系统除了委托单位和使用单位,还与哪些机构组织有关系。例如一些系统需要遵守那些组织的标准、需要通过那些组织机构的测试才能使用等等、是否需要外包或与那些组织机构合作。
  1、3定义
  列出为正确理解本计划书所用到的专门术语的定义、外文缩写词的原词及中文解释。注意尽量不要对一些业界使用的通用术语进行另外的定义,使它的含义和通用术语的惯用含义不一致。
  1、4参考资料
  列出本计划书中所引用的及相关的文件资料和标准的作者、标题、编号、发表日期和出版单位,必要时说明得到这些文件资料和标准的途径。本节与下一节的“标准、条约和约定”互为补充,注意“参考资料”未必作为“标准、条约和约定”,因为“参考”的不一定是“必须遵守”的。常用资料如
  本项目的合同、标书、上级机关有关通知、经过审批的项目任务书;
  属于本项目的其他已经发表的文件;
  本文档中各处引用的文件、资料,包括所要用到的软件开发标准。
  1、5标准、条约和约定
  列出在本项目开发过程中必须遵守的标准、条约和约定。例如相应的《立项建议书》、《项目任务书》、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技术规范等。
  “参考资料”一般具有“物质”特性,一般要说明参照了什么,要说明在哪里可以获得;“标准、条约和约定”一般具有“精神”特性,一般是必须遵守的,不说明在哪里可以获得。参考资料的内容应该涵盖“标准、条约和约定”。
  2项目概述
  2、1项目目标
  设定项目目标就是把项目要完成的工作用清晰的语言描述出来,让项目团队每一个成员都有明确的概念。注意,不要简单地说成在什么什么时间完成开发什么什么软件系统或完成什么什么软件安装集成任务。注意“要完成一个系统”只是一个凝的目标,它还不够具体和明确。明确的项目目标应该指出了服务对象,所开发软件系统最主要的功能和系统本身的比较深层次的社会目的或系统使用后所起到的社会效果。
  项目目标应当符合SMART原则
  SSpecific明确的陈述
  MMeasurabe可以衡量的结果
  AAttainabe可以达成的目标
  RReaistic合理的,现实的或者说是能和实际工作相结合
  TTrackabe可以跟踪的
  项目目标可以进行横向的分解也可以进行纵向的分解♂向分解一般按照系统的功能或按照建设单位的不同业务要求,如分解为第一目标、第二目标等等;纵向的分解一般是指按照阶段,如分解为第一阶段目标、第二阶段目标等等,或近期目标、中期目标、远期目标等等。阶段目标一般应当说明目标实现的较为明确的时间。一般要在说明了总目标的基础上再说明分解目标,可加上“为实现项目的总目标,必须实现以下三个阶段目标?”
  2、2产品目标与范围
  根据项目输入(如合同、立项建议书、项目技术方案、标书等)说明此项目要实现的软件系统产品的目的与目标及简要的软件功能需求。对项目成果(软件系统)范围进行准确清晰的界定与说明是软件开发项目活动开展的基础和依据。软件系统产品目标应当从用户的角度说明开发这一软件系统是为了解决用户的那些问题。产品目标如“提高工作信息报送反馈工作效率,更好地进行工作信息报送的检查监督,提高信息的及时性、汇总统计信息的准确性,减轻各级相关工作人员的劳动强度。”
  2、3假设与约束
  对于项目必须遵守的各种约束(时间、人员、预算、设备等)进行说明。这些内容将限制你实现什么、怎样实现、什么时候实现、成本范围等种种制约条件。
  假设是通过努力可以直接解决的问题,而这些问题是一定要解决才能保证项目按计划完成。如“系统分析员必须在3天内到位”或“用户必须在8月8日前确定对需求文档进行确认”
  约束一般是难以解决的问题,但可以通过其他途径回避或弥补、取舍,如人力资源的约束限制,就必须牺牲进度或质量等等。
  假设与约束是针对比较明确会出现的情况,如果问题的出现具有不确定性,则应该在风险分析中列出,分析其出现的可能性(概率)、造成的影响、应当采取的相应措施。
  2、4项目工作范围
  说明为实现项目的目标需要进行那些工作。在必要时,可描述与合作单位和用户的工作分工。
  注意产品范围与项目工作范围的不同含义。
  产品范围界定软件系统产品本身范围的特征和功能范围。
  工作范围界定为了能够按时保质交付一个有特殊的特征和功能的软件系统产品所要完成的那些工作任务。
  产品范围的完成情况是参照客户的需求来衡量的,而项目范围的完成情况则是参照计划来检验的。这两个范围管理模型间必须要有较好的统一性,以确保项目的具体工作成果,能按特定的产品要求准时交付。
  2、5应交付成果
  2、5、1需完成的软件
  列出需要完成的程序的名称、所用的编程语言及存储程序的媒体形式。其中软件对象可能包括源程序、数据库对象创建语句、可执行程序、支撑系统的数据库数据、配置文件、第三方模块、界面文件、界面原稿文件、声音文件、安装软件、安装软件源程序文件等等。
  2、5、2需提交用户的文档
  列出需要移交给用户的每种文档的名称、内容要点及存储形式,如需求规格说明书、帮助手册等。此处需要移交用户的文档可参考合同中的规定。
  2、5、3须提交内部的文档
  可根据《GB8567-88计算机软件产品开发文件编制指南》附录O“文件编制实施规定的实例(参考件)”结合各企业实际情况调整制定《软件开发文档编制裁减衡量因素表》。根据《因素表》确定项目对应的项目衡量因素取值,以确定本项目应完成的阶段成果。将不适用于本项目的内容裁减,以减少不必要的项目任务和资源。
  根据因素取值列出本项目应完成的阶段成果,说明本项目取值所在的区间,将其他因素值区间删除。
  2、5、4应当提供的服务
  根据合同或某重点建设工作需要,列出将向用户或委托单位提供的各种服务,例如培训、安装、维护和运行支持等。具体的工作计划如需要编制现场安装作业指导书、培训计划等,应当在本计划“4、3总体进度计划”中条列出。
  2、6项目开发环境
  说明开发本软件项目所需要的软硬件环境和版本、如操作系统、开发工具、数据库系统、配置管理工具、网络环境。环境可能不止一种,如开发工具可能需要针对Java的,也需要针对C++的。有些环境可能无法确定,需要在需求分析完成或设计完成后才能确定所需要的环境。
  2、7项目验收方式与依据
  说明项目内部验收和用户验收的方式,如验收包括交付前验收、交付后验收、试运行(初步)验收、最终验收、第三方验收、专家参与验收等等。项目验收依据主要有标书、合同、相关标准、项目文档(最主要是需求规格说明书)。
  3项目团队组织
  3、1组织结构
  说明项目团队的组织结构。项目的组织结构可以从所需角色和项目成员两个方面描述。所需角色主要说明为了完成本项目任务,项目团队需要哪些角色构成,如项目经理、计划经理、系统分析员(或小组)、构架设计师、设计组、程序组、测试组等等。组织结构可以用图形来表示,可以采用树形图,也可以采用矩阵式图形,同时说明团队成员来自于哪个部门。除了图形外,可以用文字简要说明各个角色应有的技术水平。
  注意虽然有一些通用的结构可以套用,但各种不同规模、不同形式的项目组织结构是不一样的。如产品研发项目可能就不需要实施人员(小组),但需要知识转移方面的人员(小组)。而软件编码外包的项目则不需要程序员,测试人员也可以适当地减少。
  3、2人员分工
  确定项目团队的的每个成员属于组织结构中的什么角色,他们的技术水平、项目中的分工与配置,可以用列表方式说明,具体编制时按照项目实际组织结构编写。以下是一个示例。
  3、3协作与沟通
  项目的沟通与协作首先应当确定协作与沟通的对象,就是与谁协作、沟通。沟通对象应该包括所有项目干系人,而项目干系人包括了所有项目团队成员、项目接口人员、项目团队外部相关人员等等。
  其次应当确定协作模式与沟通方式。沟通方式如会议、使用电话、QQ、内部邮件、外部邮件、QuickPace、聊天室等等。其中邮件沟通应当说明主送人、抄送人,聊天室沟通方式应当约定时间周期。而协作模式主要说明在出现什么状况的时候各个角色应当(主动)采取什么措施,包括沟通,如何互相配合来共同完成某项任务。定期的沟通一般要包括项目阶段报告、项目阶段计划、阶段会议等
  3、3、1项目团队内部协作
  本节说明在项目开发过程中项目团队内部的协作模式和沟通方式、频次、沟通成果记录办法等内容。
  3、3、2项目接口人员
  应当说明接口工作的人员即他们的职责、联系方式、沟通方式、协作模式,包括
  a、负责本项目同用户的接口人员;
  b、负责本项目同本企业各管理机构,如计划管理部门、合同管理部门、采购部门、质量管理部门、财务部门等的接口人员;
  c、负责本项目同分包方的接口人员。
  3、3、3项目团队外部沟通与协作模式
  项目团队外部包括企业内部管理协助部门、项目委托单位、客户等等。本节说明在项目开发过程中项目团队内部与接口人员、客户沟通的方式、频次、沟通成果记录办法等内容。明确最终用户、直接用户及其所在本企业/部门名称和联系电话。明确协作开发的有关部门的名称、经理姓名、承担的工作内容以及工作实施责任人的姓名、联系电话。确定有关的合作单位的名称、负责人姓名、承担的工作内容以及实施人的姓名、联系电话。
  4实施计划
  4、1风险评估及对策
  识别或预估项目进行过程中可能出现的风险。应该分析风险出现的可能性(概率)、造成的影响、根据影响应该采取的对策,采取的措施。风险识别包括识别内在风险及外在风险。内在风险是指项目工作组能加以控制和影响的风险,如人事任免和成本估计等。外在风险指超出项目工作组等控制力和影响力之外的风险,如市场转向或政府行为等
  风险的对策包括避免排除特定危胁往往靠排除危险起源;减缓减少风险事件的预期资金投入来减低风险发生的概率,以及减少风险事件的风险系数;吸纳接受一切后果,可以是积极的(如制定预防性计划来防备风险事件的发生),也可以是消极的(如某些费用超支则接受低于预期的利润)。
  对于软件开发项目而言,在分析、识别和管理风险上投入足够的时间和人力可以使项目进展过程更加平稳,提高项目跟踪和控制的能力,由于在问题发生之前已经做了周密计划,因而对项目的成功产生更加充分的信心。
  软件开发项目常见预估的风险
  1)工程/规模/进度上的风险
  规模大,规模估算不精确甚至误差很大;就规模而言,用户要求交付期、费用很紧;预料外的工作(测试未完时的现场对应等);
  2)技术上的风险
  使用新的开发技术、新设备等,或是新的应用组合,没有经验;是新的行业或业务,没有经验;性能上的要求很严;
  3)用户体制上的问题
  用户管理不严,恐怕功能决定、验收不能顺利地完成(或者出现了延迟);或者恐怕功能会多次变更;与用户分担开发,恐怕工程会拖延(或者出现了延迟);用户或其他相关单位承担的工作有可能延误;
  4)其它应该包含此处没有、但据推测有风险的项目。
  4、2工作流程
  说明项目采用什么样的工作流程进行。如瀑布法工作流程,原型法工作流程、螺旋型工作流程、迭代法工作流程,也可以是自己创建的工作流程。不同的流程将影响后面的工作计划的制定。必要时画出本项目采用的工作流程图及适当的文字说明。
  4、3总体进度计划
  这里所说的总体进度计划为高层计划。作为补充,应当分阶段制定项目的阶段计划,这些阶段计划不在这份文档中,当要以这份总体计划为依据。
  总体进度计划要依据确定的项目规模,列表项目阶段划分、阶段进度安排及每阶段应提交的阶段成果,在阶段时间安排中要考虑项目阶段成果完成、提交评审、修改的时间。
  对于项目计划、项目准备、需求调研、需求分析、构架设计或概要设计、编码实现、测试、移交、内部培训、用户培训、安装部署、试运行、验收等工作,给出每项工作任务的预定开始日期、完成日期及所需的资源,规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件(里程碑)。
  例如
  需求评审
  设计评审
  表格中检查点/里程碑等阶段划分为举例,实际作业阶段划分、阶段成果等请根据项目需要确定。
  制定软件项目进度计划可以使用一些专门的工具,最常用的是Microsoft的Project作为辅助工具,功能比较强大,比较适合于规模较大的项目,但无法完全代替项目计划书,特别是一些主要由文字来说明的部分。小规模的项目可简便地使用EXCEL作为辅助工具。关于如何使用这些工具不在此作详细说明。
  制定软件项目进度计划应当考虑以下一些因素:
  1)对于系统需求和项目目标的掌握程度。如开始时对于系统需求和项目目标只有比较数的了解,就只能制定出比较粗的进度计划,等到需求阶段或设计阶段结束,就应该进一步细化进度计划。
  2)软件系统规耐项目规模,这两个不是一个概念。软件系统规模往往是从功能点的估算或其他估算方式得来的,而项目规模还要考虑对文档数量与质量的要求,使用的开发工具、新技术、多少复用、沟通的方便程度、客户方的情况、需要遵守的标准规范等等等等。例如,完成一个大型的系统,在一定的时间内一个人或几个人的智力和体力是承受不了的。由于软件是逻辑、智力产品,盲目增加软件开发人员并不能成比例地提高软件开发能力。相反,随着人员数量的增加,人员的组织、协调、通信、培训和管理方面的问题将更为严重。
  3)软件系统复杂程度和项目复杂程度和软件系统规耐项目规模一样,软件系统的复杂程度主要是考虑软件系统本身的功能、架构的复杂程度,而项目的复杂程度主要是指项目团队成员的构成、项目任务的复杂程度、项目干系人的复杂程度、需求调研的难易程度,多项目情况下资源保障的情况,等等等等。软件系统的规模与软件系统的复杂程度未必是成比例的关系;同样项目的规模与项目的复杂程度未必是成比例的关系。
  4)项目的工期要求,就是项目的紧急程度。有些项目规模大,却因为与顾客签订了合同,或者为了抢先占领市场,工期压缩得很紧,这时就要考虑如何更好地合理安排进度,多增加人选多采用加班的方式是一种万不得已的选择。增加人选除了增加人的成本外必定会增加沟通的成本(熟悉项目任务所需要的时间);加班如果处理不好会造成情绪上的问题,也可能会因为过于忙碌而无法顾及质量,造成质量的下滑。
  5)项目成员的能力。这些能力包括项目经理的管理能力,系统分析员的分析能力、系统设计人员的设计能力、程序员的编码能力、测试人员的测试能力,以及企业或项目团队激发出这些能力的能力。从另外一个角度看还有总体上对客户行业业务的熟悉程度;对于建模工具、开发工具、测试工具等技术的掌握程度;企业内部对行业业务知识和主要技术的知识积累。
  4、4项目控制计划
  4、4、1质量保证计划
  执行质量评审活动,对过程质量进行控制。规模较大的项目应当单独编写《软件开发项目质量计划》。根据GB/T12504计算机软件质量保证计划规范,内容包括
  引言(本章节包括质量计划的目的、定义、参考资料)
  管理(描述负责软件质量管理的机构、任务及其相关的职责)
  文档(列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档,并描述对文档进行评审与检查的准则)
  标准、条例和约定(列出软件开发过程中要用到的标准、条例和约定,并列出监督和保证执行的措施)
  评审和检查(规定所要进行的技术和管理两个方面的评审和检查工作,并编制或引用有关的评审和检查规程,以及通过与否的技术准则。至少要进行软件需求评审、概要设计评审、软件验证与确认评审、软件系统功能检查、程序和文档物理检查)
  软件配置管理(编制有关配置管理条款,或在“4、4、4配置管理计划”中说明,或引用按照《GB/T12505计算机软件配置管理计划规范》单独制定的文档)
  工具、技术和方法(指明用于支持特定软件项目质量管理工作的工具、技术和方法,指出它们的目的和用途)
  媒体控制(说明保护计算机程序物理媒体的方法和设施,以免非法存取、意外损坏或自然老化)
  对供货单位的控制(供货单位包括项目承办单位、软件销售单位、软件开发单位。规定对这些供货单位进行控制的规程,从而保证项目承办单位从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的需求。)
  记录的收集、维护和保存(指明需要保存的软件质量保证活动的记录,并指出用于汇总、保护和维护这些记录的方法和设施,并指明要保存的期限)
  4、4、2进度控制计划
  (可直接引用以下描述或根据项目情况制定本节内容)
  本项目的进度监控执行本企业《项目管理规范》,由本企业过程控制部门如质量管理部统一进行监控,并保留在监控过程中产生的日常检查记录。
  4、4、3预算监控计划
  说明如何检查项目预算的使用情况。根据项目情况需要制定。

第三篇软件开发技术方案:软件开发的心得

  篇一:软件开发心得体会
  受某文化公司委托,开发一款用于视频和图像处理的软件,开发难度高,高到从未搞过,开发周期长,长到是我以前项目监控最长开发周期的两倍,开发成本之底,让我觉得程序员成了高级打字员。首先是需求分析书、产品规格说明书、设计说明书、代码规范说明书、测试计划,光文稿就不知道熬了多久才做完。
  紧接着,遇到一系列问题,首先是语言选择,vc++和c#都是可以保证开发完成的选择,但是vc++内存容易报错,界面很难修改,而客户要求的界面质量甚至比程序的功能更严格,没办法,客户就是上帝,上帝做事一定有他的道理。c#语言易于开发,而且图形界面绘制也易于修改,可以做出客户体验很好的界面,但是在资源的消耗上,让我很吃惊。做到第二个月,大概的界面已经完成时,出现界面刷新的问题,刷新时开始卡,界面不流畅。没办法,改。
  开会,总结,技术骨干找问题,拿出解决方案,力争第一次做软件把它做好: 重新做软件开发进度计划和软件测试计划,并且让独立功能demo制作和测试先行;
  用direct draw、direct 3d或者opengl中的一个替代c#本身的gdi绘图,将在接下来的开发任务中加入进去。
  事无巨细,当我满意的看着界面流畅,功能也已实现时,发现软件在低分辨率或者小本上根本乱到没法看,甚至是界面功能按钮错位,重叠等等。没办法,改。毕竟软件的多分辨率兼容和操作系统兼容是必须要做的。
  接下来一大堆的麻烦找了上来,软件出现各种各样想都想不到的问题,总算是按时将第一个版本发布出去,并且开始接下来的升级开发任务。
  最后,给刚刚接手软件开发项目的朋友一些忠告:
  一、相关的文档不是给别人看的,而是给自己看的,相关文档一定要齐备,而且让所有涉及开发的人员都清楚的知道你文档里所要表达的意思;
  二、一定要注意多做demo,多做实验,一个demo程序员几个钟头就可以完成,甚至更少,但是不做demo,核心程序没有做实验,其他的东西都围绕核心程序做了上去,到时候耽误的可不是几个钟头
  三、程序设计要注重用户体验,当初客户对我要开发软件提出近乎苛刻的要求时我不在意,但是当我自己反复使用软件时有了很多体会,流畅美观的界面带给人心理的快感的确能替代一些尚未开发完整的功能带给用户的遗憾。
  四、测试计划多次进行,分批进行,不要全部开发完成再对软件做测试。 还要坚持三个月,软件马上发布,希望大家的支持,谢谢!!!
  软件开发心得体会(2):
  作为pm,有时需要招聘软件开发人员。这几年也一直在想,如何能在短短的30分钟或1小时内,快速识别出,坐在你对面的应聘人员,是否适合你的team。这几年也一直在观察和反思,经历过的team和现在team中的软件开发人员。有几点小的心得。
  1. 倾向于招什么样的软件开发人员
  - 经历过历练的人
  吃过苦的,比如以前工作,经常被外派出差,又如曾在业内都知道以加班多而著称的公司呆过,还有些,留过学,但都是自己边打工边读书的,等等。 这些人员,入职后,通常都是能干活,能作为骨干。
  篇二:软件开发工作总结
  1、 分享第一条经验:学历代表过去、能力代表现在、学习力代表未来。其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要:重要的道理明白太晚将抱憾终生!所以放在每一条,让刚刚毕业的朋友们早点看到哈!
  2、 一定要确定自己的发展方向,并为此目的制定可行的计划。不要说什么,我刚毕业,还不知道将来可能做什么?,跟着感觉走,先做做看。因为,这样的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术,将来成为专家级人物?向管理方向走,成为职业经理人?先熟悉行业和领域,将来自立门户?还是先在行业里面混混,过几年转行做点别的?这很重要,它将决定你近几年、十年内做什么事情才是在做正确的事情!。
  3、 软件开发团队中,技术不是万能的,但没有技术是万万不能的!在技术型团队中,技术与人品同等重要,当然长相也比较重要哈,尤其在mm比较多的团队中。在软件项目团队中,技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码,还是产品管理、测试、文档、实施、维护,多少你都要有技术基础。算我孤陋寡闻,我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目,哪怕就一个,也没有看到。倒是曾经看到过一个高学历的牛人(非技术型)带一堆人做完过一个项目,项目交付的第二天,项目组成员扔下一句再也受不了啦!四分五裂、各奔东西。那个项目的成功度大家可想而知了。
  4、 详细制定自己软件开发专业知识学习计划,并注意及时修正和调整(软件开发技术变化实在太快)。请牢记:如果一个软件开发人员在1、2年内都没有更新过自己的知识,那么,其实他已经不再属于这个行业了。不要告诉自己没有时间。来自时间管理领域的著名的三八原则告诫我们:另外的那8小时如何使用将决定你的人生成败!本人自毕业以来,平均每天实际学习时间超过2小时。
  5、 书籍是人类进步的阶梯,对软件开发人员尤其如此。书籍是学习知识的最有效途径,不要过多地指望在工作中能遇到世外高人,并不厌其烦地教你。对于花钱买书,我个人经验是:千万别买国内那帮人出的书!我买的那些家伙出的书,!00%全部后悔了,无一本例外。更气愤的是,这些书在二手市场的地摊上都很难卖掉。拥有书籍并不表示拥有知识;拥有知识并不表示拥有技能;拥有技能并不表示拥有文化;拥有文化并不表示拥有智慧。只有将书本变成的自己智慧,才算是真正拥有了它。 6、 不要仅局限于对某项技术的表面使用上,哪怕你只是偶尔用一、二次。对任何事物不究就里是任何行业的工程师所不应该具备的素质。开发windows应用程序,看看windows程序的设计、加载、执行原理,分析一下pe文件格式,试试用sdk开发从头开发一个windows应用程序;用vc++、delphi、java、net开发应用程序,花时间去研究一下mfc、vcl、j2ee、net它们框架设计或者源码;除了会用j2ee、jboss、spring、hibernate等等优秀的开源产品或者框架,抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。试着这样做做,你以后的工作将会少遇到一些让你不明就里、一头雾水的问题,因为,很多东西你知其然且知其所以然!
  7、 在一种语言上编程,但别为其束缚了思想。代码大全中说:深入一门语言编程,不要浮于表面。深入一门语言开发还远远不足,任何编程语言的存在都有其自身的理由,所以也没有哪门语言是包治百病的灵丹妙药。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。我的经验是:用面对对象工具开发某些关键模块时,为什么不可以借鉴c、c51、汇编的模块化封装方式?用传统的桌面开发工具(目前主要有vc++、delphi)进行系统体统结构设计时,为什么不可以参考来自java社区的ioc、aop设计思想,甚至借鉴像spring、hibernate、jboss等等优秀的开源框架?在进行类似于实时通信、数据采集等功能的设计、实现时,为什么不可以引用来自实时系统、嵌入式系统的优秀的体系框架与模式?为什么一切都必须以个人、团队在当然开发语言上的传统或者经验来解决问题???他山之石、可以攻玉。
  8、 养成总结与反思的习惯,并有意识地提炼日常工作成果,形成自己的个人源码库、解决某类问题的通用系统体系结构、甚至进化为框架。众所周知,对软件开发人员而言,有、无经验的一个显著区别是:无经验者完成任何任务时都从头开始,而有经验者往往通过重组自己的可复用模块、类库来解决问题(其实这个结论不应该被局限在软件开发领域、可以延伸到很多方面)。这并不是说,所有可复用的东西都必须自己实现,别人成熟的通过测试的成果也可以收集、整理、集成到自己的知识库中。但是,最好还是自己实现,这样没有知识产权、版权等问题,关键是自己实现后能真正掌握这个知识点,拥有这个技能。
  9、 理论与实践并重,内外双修。工程师的内涵是:以工程师的眼光观察、分析事物和世界。一个合格的软件工程师,是真正理解了软件产品的本质及软件产品研发的思想精髓的人(个人观点、欢迎探讨)。掌握软件开发语言、应用语言工具解决工作中的具体问题、完成目标任务是软件工程师的主要工作,但从软件工程师这个角度来看,这只是外在的东西,并非重要的、本质的工作。学习、掌握软件产品开发理论知识、软件开发方法论,并在实践中理解、应用软件产品的分析、设计、实现思想来解决具体的软件产品研发问题,才是真正的软件工程师的工作。站在成熟理论与可靠方法论的高度思考、分析、解决问题,并在具体实践中验证和修正这些思想与方式,最终形成自己的理论体系和实用方法论。
  10、心态有多开放,视野就有多开阔。不要抱着自己的技术和成果,等到它们都已经过时变成垃圾了,才拿出来丢人现眼。请及时发布自己的研究成果:开发的产品、有创意的设计或代码,公布出来让大家交流或者使用,你的成果才有进化和升华的机会。想想自己xx年间开发的那些windows系统工具,5、6年之后的今天,还是那个样子,今天流行的好多windows系统工具都比自己的晚,但进化得很好,且有那么多用户在使用。并且,不要保守自己的技术和思想,尽可能地与人交流与分享,或者传授给开发团队的成员。与人交换苹果之后,每个人还是只有一个苹果;但交换思想之后,每个人都拥有两种思想,道理大家都懂,但有多少人真正能做到呢? 11、尽量参加开源项目的开发、或者与朋友共同研制一些自己的产品,千万不要因为没有钱赚而不做。网络早已不再只是虚拟世界,网上有很多的开源项目、合作开发项目、外包项目,这都是涉猎工作以外的知识的绝好机会,并且能够结识更广的人缘。不要因为工作是做erp,就不去学习和了解嵌入式、实时、通信、网络等方面的技术,反过来也是一样。如果当他别人拿着合同找你合作,你却这也不会,那也不熟时,你将后悔莫及。
  12、书到用时方恨少,不要将自己的知识面仅仅局限于技术方面。诺贝尔经济学奖得主西蒙教授的研究结果表明: 对于一个有一定基础的人来说,他只要真正肯下功夫,在6个月内就可以掌握任何一门学问。教育心理学界为感谢西蒙教授的研究成果,故命名为西蒙学习法。可见,掌握一门陌生的学问远远没有想想的那么高难、深奥。多方吸取、广泛涉猎。极力夯实自己的影响圈、尽量扩大自己的关注圈。财务、经济、税务、管理等等知识,有空花时间看看,韬光养晦、未雨绸缪。
  13、本文的总结与反思: a:不要去做技术上的高手,除非你的目标如此。虽然本文是关于提高软件开发知识的建议,做技术的高手是我一向都不赞同的。你可以提高自己的专业知识,但能胜任工作即止。 b:提高软件知识和技术只是问题的表面,本质是要提高自己认识问题、分析问题、解决问题的思想高度。软件专业知识的很多方法和原理,可以很容易地延伸、应用到生活的其它方面。 c:在能胜任工作的基础上,立即去涉猎其它领域的专业知识,丰富自己的知识体系、提高自己的综合素质,尤其是那些目标不在技术方面的朋友。

本文来源:https://www.bbjkw.net/fanwen181841/

推荐访问:软件技术开发合同
扩展阅读文章
热门阅读文章