项目开发报告
一、 报告的目的
通过反映此次项目开发中各层面存在的问题,以及对项目开发中造成的影响,来反映项目开发中规范化的必要性,以及开发文档的重要性。规范化软件开发流程控制是为了使整个软件产品在开发各个阶段清晰、要求明确、任务具体,便于规范化、系统化及工程化,利于提高软件生命周期的控制及管理,提高所开发软件的质量,缩短开发时间,减少开发和维护的费用,使软件开发活动更科学、更成效。
二、存在的问题
1. 委托开发合同上的不足:
1) 开发合同上本次项目开发的要求不明确。一般项目开发前
应确认包括项目目标和技术方案。项目目标是指项目应达到业务需求、项目目的、以及解决什么样的问题;技术方案是指描述开发软件的主要技术内容,可以以附件的形式详细描述技术方案,并作为合同的组成部分。
2) 没有明确的开发计划说明、每个阶段需要提交文档及代码
以及验收标准(测试文档)。开发计划一般要包含如下内容:需求分析阶段,设计实现阶段,初验阶段,试运行阶段,终验阶段,质保期阶段(维护)。
3) 合同双方就此次软件开发中的分工界面不明确,不能清晰
界定双方的责权利。分工界面是指甲乙双方在此次项目开
发过程中各自扮演的角色,以及在整个开发中的具体工作界定。如:委托方提供需求文档等相关资料,开发方制定开发规范、详细开发计划、以及开发里程碑,甲乙双方成立项目负责组监管开发过程等。
4) 项目开发交付内容不明确。就试运行标准没有达成共识,
一般试运行应该是在委托方收到开发方出具的项目初验报告以后,根据初验报告验收标准判断是否达到试运行标准后,再同意试运行才是试运行的标志。
5) 验收内容和标准不详,没有一套完整的验收流程。在整个
项目开发中各个阶段最好都要由开发方提起申请,委托方给予答复这样一个流程来监管和规范项目的开发,使项目能稳定规范的进行。
6) 最终交付产品和版权不明确。注明是否需要源代码以及说
明版权归属方。
2. 开发流程上的缺陷
1) 项目开发各个阶段都应该有完整的开发计划和开发流程。
为了保证项目在开发过程中不至于无序而使开发陷入混乱甚至僵死的状态,明确各阶段的任务、标准和流程是相当重要的。
2) 首先要由项目负责人制定项目开发计划。在项目计划中要
对项目的目标和时间要求给出明确的定义,要规定项目的组织和管理规则,项目的开发过程和输出要求,项目对资
源的需求和分配等。
3) 由项目负责人要组织编写《XXX系统开发规范》(此规范可
以在项目开发过程中进行完善,但是必须双方认可),其中包括:
a. 阐述项目采用的技术路线;
b.
c. 采用的软件开发方法和使用的软件辅助开发工具; 制定需求分析阶段,设计阶段,编程阶段中文档编写
规则,模型表示规则,命名约定等在开发过程中需协调一致的规则。
4) 需求分析阶段:需求分析员应通过各种方式收集和获得所
开发项目的业务需求,并对获取的需求和系统应具有的隐含需求进行分析,以建立系统的软件需求。必须编写《软件需求说明书》,最好编写初步的《系统指南》。该《软件需求说明书》得到用户确认后,需提交评审。
5) 概要设计阶段:系统设计员应建立一个高层的软件体系结
构,该体系结构应体现系统的需求。该体系结构应描述软件的顶层结构和定义其主要部分。必须编写《概要设计说明书》和《数据库设计说明书》,最后修改完善《系统指南》并将《概要设计说明书》和《数据库设计说明书》提交评审。
6) 详细设计阶段:系统设计人员要深刻理解《概要设计说明
书》,保证详细设计与概要设计相一致,为编码提供详尽
的依据。细化和描述每一个功能模块,确定实现各个模块功能的具体算法、内部数据结构和外部接口方式。若功能模块涉及到用户界面,还要具体描绘出用户界面以及操作流程。必须编写《详细设计说明书》,最后修改完善《系统指南》并提交详细设计评审。
7) 设计实现阶段:程序员应严格按照详细设计的说明,保证
最终程序与详细设计相一致。编码过程中应遵循《XXX系统开发规范》的命名规则和注释等规定保证程序的清晰、易读。要对编写的程序进行调试,使程序不仅通过编译的语法检查,而且在功能和性能等方面达到设计的要求。必须编写《用户操作手册》,最后修改《系统指南》。由系统设计员最终完成《系统指南》。
8) 内部测试阶段:项目负责人应组织系统的内部测试,内部
测试由项目组内包括单元测试,集成测试和构造测试。项目组内的测试员负责编写系统内部测试的《测试计划》和《测试实例》,实施测试,填写《测试报告》。最后由测试部提供支持。
9) 系统测试阶段:项目负责人应向测试部提请系统测试。测
试部负责编写系统测试的《测试计划》,《测试实例》,实施测试,填写《测试报告》。由项目测试员提供配合。
10) 初验阶段:验收小组需要根据验收内容逐项进行相关验
收。软件功能的验收:由软件使用部门根据需求或验收内
容和标准,对软件系统功能进行详细验证测试,验收小组监督和汇总测试情况。软件性能的验收:由信息技术部从技术的角度,对系统进行性能等技术测试,验收小组监督和汇总测试情况。开发资料文档的验收:由验收小组根据验收准备阶段的要求逐项核对资料的提交情况,资料包括合同中要求的程序源代码、操作手册、培训资料、测试报告、过程数据等。最后验收小组将根据综合评议情况,判断是否验收合格,对于不合格的部分提出整改意见。如果本次验收通过,验收小组将检验初步验收涉及的各阶段验收是否完成,如果初步验收完成,将进入正式运行阶段;
11) 终验阶段:当系统运行一段时间(一般在合同中明确)后,
验收小组将汇总各使用部门的验证情况或验收小组组织全面的验收,将根据验收情况出具验收结论。不合格则提出整改意见,合格则进入最后报告总结。验收小组将根据验收情况撰写验收报告,验收报告不仅需要包括本次项目验收的情况总结,也需要总结本次验收工作的得与失。最后领导审批,归档。
3. 人员的缺失(需要有明确的工作职责为整个项目负责):
1) 项目负责人:负责制订《项目计划》、协调项目内外各方
的关系、控制项目进度并保证项目计划的实施和完成。
2) 需求分析员:作为开发方的代表,负责沟通用户和开发人
员的认识和见解,明确及准确地编写《软件需求说明书》
和初步的《系统指南》。
3) 系统设计员:负责把软件需求变换成可表示的可实现的软
件形式,为设计实现提供可行的依据。并在设计过程中要负责编写《概要设计说明书》、《数据库设计说明书》、《详细设计说明书》,完成《系统指南》的编写。
4) 程序员:按设计要求把软件的详细设计变换成可执行的源
程序,进行调试。完成相应的文档,编写《用户操作手册》。
5) 测试人员:负责制定测试计划,设计测试方案,测试用例,
并实施测试。
6) 配置管理人员:负责对开发库中软件配置项的管理和维
护。
7) 监管人员:开发双方包括客户方负责整个开发项目过程中
各个阶段的规范和督导。
4.标准规范的缺失(主要体现在需求文档里面,下面几点不是所有项目都有,可以根据项目的规模范围来调整):
1) 功能需求:描述软件系统必须实现的业务流程(使用实例),以及根据每个业务流程分解出来的详细的功能需求。
2) 性能需求:软件性能需求通常包括以下方面:
i.同时支持的最大用户数、同时支持操作的个数、某时
刻能承受的最大数据量、数据最大存储量、对系统运行时允许占用的系统资源要求;
ii.系统持续运行时间、响应时间、数据更新处理时间、
数据间的转换和传输时间、界面刷新处理时间的要求; iii.在不同安装/运行环境、不同操作方式下,或者与其它子系统接口发生改变时,某些数据和参数可以允许的变化范围。
3) 系统安全:说明与系统安全性、完整性和保密性相关的需求,明确产品必须满足的安全保密策略。
4) 质量要求:可靠性(软件能够无故障的运行一段时间的概率)、可维护性(对软件进行修改的难易程度——修改所用时间、修复的比率)、有效性(软件正常运行时间/总时间)、可用性(掌握软件操作的难易程度)、重用性、可测试性(查找缺陷的难易程度)、可移植性等。
5) 安全和保密:说明与系统安全性、完整性和保密性相关的需求,明确产品必须满足的安全保密策略。
6) 需求变更:需要有变更控制,版本控制,需求跟踪,状态跟踪等规范,明确产品的基线、复审对基线的变更、最后批准、否决变更或延期执行的控制,。
7) 网络要求:描述与本软件所使用的通信功能相关的需求。 电子邮件、Web 浏览器、网络通信标准或协议及电子表格等等。 包括对消息格式、通信安全或加密问题、数据传输速率和同步通信机制等要求。
8) 接口要求:对本软件与其它系统软件的每个接口进行描述,包括软件之间的交换数据或信息及其作用(注意说明哪些是
共享数据)、需要的服务、内部通信性质。
9) 其他要求:安装与操作,维护等。
5.需求变更管理的不足:
需求调研分析过程是一个由粗到细、渐进明晰、持续完善的过程。在指导后面系统设计,编码阶段时都应当不断完善修改需求文档,因此需求管理非常重要。需求管理包括在工程进展过程中维持需求约定集成型和精确性的所有活动:
(1) 定义需求基线(需求文档的主体);
(2) 评审提出的需求变更申请、评估每项变更可能的影响,从而决定是否实施变更;
(3) 以一种可控的方式将需求变更融入到项目中;
(4) 使当前的项目计划与需求保持一致;
(5) 分析变更所产生的影响并在此基础上协商出新的约定;
(6) 使每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪;
(7) 在整个项目过程中跟踪需求状态及其变更情况。 6.开发文档和报告的缺失(不一定全部都需要可以根据实际开发来调整):
因为没有指明负责人,所以各个阶段没有形成申请、报告、汇报和变更等文档。没有数据库数据字典文档,没有测试计划文档,没有验收文档等。一般文档应该包括(因项目开发的不同部分文档可以没有):《XXX系统开发规范》《软件需求说明
书》《概要设计说明书》《数据库设计说明书》《详细设计说明书》《系统指南》《用户操作手册》
三、软件开发的重点
一个软件开发项目的进行,一般需要在人力和自动化资源等方面作重大的投资。为了保证项目开发的顺利进行与成功,最经济地花费这些投资,并且便于运行和维护,在开发工作的每一个阶段都需要编制一定的文档。这些文档连同计算机程序及数据一起才算是构成整个计算机的软件。文档的作用是相当重要的,是整个开发流程中规范化进行的重要保障。文档还有其他很多作用:
1) 作为开发人员在一定阶段内的工作成果和结束标
志。
2) 向管理人员提供软件开发过程中的进展和情况,
把软件开发过程中的一些“不可见的”事物转 换
成“可见的”文字资料。以便管理人员在各个阶
段检查开发计划的实施进展,使之能够判断原定
目标是 否已达到,还将继续耗用资源的种类和数
量。
3) 记录开发过程中的技术信息,便于协调以后的软
件开发、使用和修改;
4) 提供对软件的有关运行、维护和培训的信息,便
于管理人员、开发人员、操作人员和用户之间相
互了解彼此的工作;
5) 向潜在用户报导软件的功能和性能,使他们能判
定该软件能否服务于自己的需要。
另外文档模板有很多可以根据开发项目的总体要求来选择合适的文档制定要求来规范文档,使在整个开发中能更好的诠释项目,保障项目的顺利进行。
四、关于绩效考核软件开发的汇报
开发人员在整个开发过程中尽职尽责,经常加班,为整个项目开发尽了全力。项目开发中出现了一些问题,导致开发延后,其中最主要的原因有两点:第一,项目开发过程中客户方因为工作人事的变动,调整了绩效考核负责人,从而在项目功能上的需求变动比较大,而且客户方在细节功能需求上一直没有一个明确的定性要求。第二,项目从开始制定实施以来,没有完善的一套开发流程控制计划,最重要的是在合同上的很多不足,使整个开发没有可控性和规范化。虽然经过开发人员一段时间的努力,最终完成了整个项目的开发,但是由于各个文档的不足,软件还有些不足的地方,在今后的客户试用中还会出现一些问题,可以让开发方负责整改。为了以后更多软件项目能更高效,顺利的进展,希望能有自己的监管部门或者人员参与到整个项目中来,从头到尾的协助开发人员进行项目规范化进行,监管、申请、审批、文档都是必不可少的部分。
第二篇:java项目开发规范
项目开发规范:
1、开发人员分工:每人负责一个模块的开发,由后端一直到前端。实现所
有功能。
2、每个人每天必须写出项目进度总结。
3、数据库管理所有数据表格必须一致。也就是保持数据的一致性。 4、必须遵循命名规范。能重用的类应尽可能的使用。 5、遵守以下代码规范:
1. JAVA 程序编写规范
1.1命名规则
1.1.1 文件的命名规则
请参考各模块相关设计文档。
1.1.2变量的命名规则
变量的格式:变量的前缀+变量描述
1) 变量描述的第一个字符必须大写,与前缀区分开,前缀必须小写。 2) 数组变量的定义格式,要把数组的前缀放在前面,格式如下: 数组前缀+变量的前缀+描述
如:NodeList[] arrNLTemp[3] 表示节点列表数组。
3) 变量的定义,必须在程序的首部或函数的首部,不允许任意定义变量。 4) 变量必须在定义时初始化。
5) 变量表达尽量使用英文单词全称,每一单词首字母使用大写。
1.1.3常量的命名规则
全部使用大写的字母,不需要前缀,但是每一描述名用下划线隔开。 如:private final int TRACE_FILE_NAME=12345
1.1.4 函数的命名规则
建议函数名称用体现功能的英文单词组成(可以是缩写的组合),第一个单词的首字母必须小写, 后面的每一个单词的首字母必须大写。如:setMsg, removeMsg。
总之,对于常量、变量和函数等标识符的命名,应该做到“见名知意”,即选有含义的英文单词(或缩写)标识符。除数值运算程序外,不要用代数符号(如:a,b等),以增加程序的可读性。
1.2注释
1.2.1需要注释地方
? ? ? ?
程序文件的首部。 方法定义之前。 程序的关键地方。 每个主要结构处。
如:if 结构,while结构,switch结构,及结构内的关键语句处。 ? 每个变量说明语句。
? 空出来准备将来添加代码的地方。 ? 每个特殊的或容易引起误解地方。
1.2.2注释编写规范
? 注释符号“/** */”,“/* */”or “// ”,注释语句于注释符号之间要有1
个或 1个以上的空格。如:
? /** This is the comment */ ? /* This is the comment */ ? // This is the comment.
? 如果注释单独起一行,被注释的语句是紧跟其后的语句,单起一行的注释要与
被注释的语句垂直对齐,被注释的语句不能与注释语句之间有空行,注释要与前面的语句有个空行。单独起行的注释使用“//“。多行注释使用“/* */”。格式说明:
A.上、下、左边框与注释语句首部垂直对齐。 B.左边框的第一行用符号“/*”,最后一行用“*/”,其他行用符号“*”左边框所有“*”必须垂直对齐。 C.注释语句上下各有一空行。
D.注释语句与“*”之间要间隔1个空格。
? 程序某一语句之后的注释,要与语句本身之间保留4个空格的位置(注意不要
用TAB),原则是尽量容易区分开程序的语句与注释。如: 语句1 /* this is the comment */ 语句2 // this is the comment. ? 函数的注释
关于方法定义的注释格式如下: /**
* function name: * statement: * @param * @return * @exception * @call function * Note */ 格式说明:
a.注释语句的上下左边框必须对齐。
b.注释语句(除第一行少一个空格)与上边框各保留一个空行。 例如: /**
* function name:KillComma () * statement:去掉字符串中的“,”
* @param char[] arr_cTemp 传入字符串 * @return char [] arr_cA * Note: 字符串不能为空。 */
? 程序文件的注释
对每一个程序文件,在文件头部必须有注释,注释符号的形式与方法的注释符号的形式相同,注释语句必须包括如下: /**
* Project: * Filename: * Description: * Methods: * Author: * Date:
* -------------------------------------------------------------------- * Modify 1
* UpdateBy: * Update Date:
* Update Description:
* -------------------------------------------------------------------- * Modify 2 * UpdateBy: * Update Date:
* Update Description: */
1.3行宽、缩进与对齐
1.3.1行宽
为了程序在屏幕中不需要通过滑动条就能更好把程序的语句看到。程序每行的宽度不得超过100个字符,超过100个字符必须折行显示。 注意:
如果语句需要换行,换行的位置要合适,一般在逗号,算术符号等处,不要在变量的中间换行。同一行不要写2条或2条以上的语句。 例如:
If (req.getParameter (“submit”)! =null &&
! Ret.getParameter (“submit”). Equals (“”)){ 语句1; 语句2; }
1.3.2对齐
? 对齐是指垂直左对齐。 ? ? ? ?
函数的定义与函数的注释,必须顶头写。 同一层次的相对语句必须对齐。(例如:函数,操作语句,结构体定义等)。 在不同行的左花括号“{”和与相对应的右花括号“}”必须对齐。 单独起行的注释与被注释语句对齐。
1.3.3缩进
? 缩进是指与上一条语句相比向右推进4个空格(注意不要使用TAB)。 ? 被派生出来的语句需要缩进。例如:
for (int i=0;i<10;i++){ 语句1; 语句2; }
? 有派生关系的语句还有:if语句,函数头与主体,循环条件与循环体,结构
体的定义语句与结构体变量说明语句。
? 当一条语句需要换行时,下一行相对需要缩进。
1.3.4缩进与对齐的例子:
/**
* comment line1 * comment line2 * comment line3 */
import java.io.*; import java.util.*;
public class HelloWorldApp{
int a=1; // comment line
/**
* function name:printString () * statement:
* @param int iTemp process flag * @return void
* Note: input parameter iTemp can not be null. */
private void printString (int iTemp) { 语句1; 语句2; ? } }
1.4花括号
花括号一般要另起一行,下列情况例外。
数组初始化,例如:int[] arrant={1,2,3}; 另起一行的花括号要符合对齐规范。
1.5空行、空格
空行只容许一行。必须空行的地方如下:
函数体与其它语句之间,以及函数与函数之间。 预编译命令与函数定义之间。 相对独立的小节之间。
主程序内,不同类型变量声明;以及变量声明与程序语句之间。
除语法规定要加空格的地方与缩进加空格以外,程序的其它地方不能加空格。