同济大学软件工程实习总结报告资料

生产实习报告

实习日程安排我从2004.8到2004.11在这家公司公司进行实习。刚开始的几个星期，公司经理安排我学习一些有关游戏方面的技术，帮我快速的对游戏行业入门。接下来的时间，经理安排我进行一些实战开发，难度从简单到难。所进行开发的项目我会在实习收获和体会这段中具体阐述。实习收获和体会我在公司主要开发了一个图形转换器，制作一个InstallShiled安装程序和关于3D处理的MMX技术，下面我将介绍我的工作情况和工作收获。图形转换器：1.设计文档 一：功能描述：此软件能将TGA，BMP等图形格式转换为任意制定的格式功能细化：能显示指定的图片（TGA,RGBA等格式）能显示指定图片的参数（长度，宽度，图片的格式）进行转换的时候能检查该图片长，宽是否为2的幂次，如果不是则发出通知信息具有批处理功能，给定一个文件目录，能将该目录下的所有图片转换为DDS格式转换为DDS时候可以指定MipMap值二：模块划分：UI界面+转换模块转换模块：以DLL的形式，针对不同的平台各写一个其接口为：boolChangeTo(constchar*SrcName,constchar*DestName,TYPEtype)enumTYPE{BMP=1,JPEG=2,DDS=3}；constchar*SrcName,constchar*DestName应该换成一个结构体SrcName：指定的图片名字DestName:转换的图片名字UI界面：采取多文档视图结构三：重要结构structDDS_PIXELFORMAT{DWORDdwSize;DWORDdwFlags;DWORDdwFourCC;DWORDdwRGBBitCount;DWORDdwRBitMask;DWORDdwGBitMask;DWORDdwBBitMask;DWORDdwABitMask;};structDDS_HEADER{DWORDdwSize;DWORDdwHeaderFlags;DWORDdwHeight;DWORDdwWidth;DWORDdwPitchOrLinearSize;DWORDdwDepth;DWORDdwMipMapCount;DWORDdwReserved1[11];DDS_PIXELFORMATddspf;DWORDdwSurfaceFlags;DWORDdwCubemapFlags;DWORDdwReserved2[3];};四：开发平台VC6.0+DX9.02.接口文档接口说明一接口代码：classIImageChange{public: virtualboolChangeTo(ImageInfo*pImageInfo)=0; virtualchar*GetDllName()=0; virtualvoidSetDirectory(constchar*szDirName)=0;};上面是一个接口类，这里模仿COM的方法，设计一个抽象类。任何ImageChangeDLL必须继承以上接口类。Example:classCImageChangeToDDS:publicIImageChange{public: CImagaChangeToDDS(); ~CImageChangeToDDS(); virtualboolChangeTo(ImageInfo*pImageInfo); virtualchar*GetDllName(); virtualvoidSetDirectory(constchar*szDirName);};二接口类成员函数说明：virtualboolChangeTo(ImageInfo*pImageInfo)=0;该接口函数传入一个ImageInfo结构的指针(ImageInfo是中间图象数据类型，详见《中间数据结构文档》)。用户可以在自己类中override该函数，该函数可以按自己意愿任意转换为自己想要的格式。virtualchar*GetDllName()=0;该接口函数返回一个代表该该接口的字串，可以说明该接口类的功能和版本。virtualvoidSetDirectory(constchar*szDirName)=0;该接口函数设置批处理转换功能时的目的文件夹。三DLL说明：DLL一共导出2个函数：extern"C"{ IImageChange*CreateInstance();}extern"C"{ voidReleaseInstance(IImageChange*pObj);}IImageChange*CreateInstance()产生一个派生自IimageChange的实例，该实例导入到应用程序进程中。voidReleaseInstance(IImageChange*pObj);释放从CreateInstance()产生的实例资源。三接口实现#defineFILENAMELEN128#definePALNUM256typedefunsignedcharIMG_BYTE;typedefunsignedshortIMG_WORD;typedefunsignedlongIMG_DWORD;typedeflongIMG_LONG;typedefboolIMG_BOOL;typedefDWORDIMG_ARGB;typedefvoid*IMG_LPVOID;enumIMAGE_DATA_TYPE{ //depth32bit IDT_A8R8G8B8=1, IDT_X8B8G8R8=2, //depth24bit IDT_R8G8B8=3, //depth16bit IDT_R5G6B5=4, IDT_X1R5G5B5=5, IDT_A4R4G4B4=6, IDT_X4R4G4B4=7, //depth8bit IDT_A1R2G3B2=8, IDT_R3G3B2=9, IDT_INDEX8=10, //depth4bit IDT_A1R1G1B1=11, IDT_X1R1G1B1 =12, IDT_INDEX4=13, //depth1bit IDT_C1=14,//monochrome0:BLACK1：WHITE IDT_INDEX1 =15, IDT_UNKNOWN=-1,};structImageHeader{ IMG_DWORDdwSize; IMG_LONGlWidth; IMG_LONGlHeight; IMG_BYTEbDepth;//象素的深度 IMG_BYTEbReserve1[3]; IMAGE_DATA_TYPEIDT_TYPE; IMG_WORDwPlanes;//MustBeZero IMG_WORDwReserve2; IMG_DWORDdwReserve;//保留字，可以填充任意数据，如：指向用户分配的一段内存 IMG_DWORDdwPalClrNum;//调色板的颜色数，如果为-1，则不存在调色板；若为1，4，8，16 //代表调色板的颜色总数 IMG_ARGBPalColors[PALNUM];//调色板的数据，dwPalClrNum如果为-1，则该数据无效};structImageInfo{ DWORDdwSize; LONGlOffset;//该结构与数据的偏移，以BYTE为单位 ImageHeaderiiInfo; LPVOID*pData;};转换模块：以DLL的形式，针对不同的平台各写一个其接口为：boolChangeImage(ImageHeader*pImageHeader)3.中间数据格式说明一中间数据格式：structImageInfo{ DWORDdwSize; //ImageInfo结构大小 LONGlOffset; //该结构与数据的偏移，以BYTE为单位 TCHARFileName[FILENAMELEN];//源图形文件名 ImageHeaderheader;//图形中间数据的头信息 LONGlDataSize; //图形的数据区大小 LPVOIDpData;//图形的数据区指针};structImageHeader{ DWORDdwSize;//ImageHeader结构大小 LONGlWidth;//位图的宽度,单位：pixel LONGlHeight;//位图的高度,单位：pixel WORDwDepth;//象素的深度，代表一个象素占多少位 WORDwReserve1;//MustBeZero IMAGE_DATA_TYPEIDT_TYPE;//位图数据存储类型 WORDwPlanes; //MustBeZero WORDwReserve2;//MustBeZero DWORDdwReserve;//保留字，可以填充任意数据，如：指向用户分配的一段内存 DWORDdwPalClrNum;//调色板的颜色数，如果为0，则不存在调色板；若为1，4，//代表调色板的颜色总数 ARGBPalColors[PALNUM];//调色板的数据dwPalClrNum如果为0，则该数据无效};enumIMAGE_DATA_TYPE{ //depth32bit IDT_A8R8G8B8 =1, IDT_X8B8G8R8 =2, //depth24bit IDT_R8G8B8 =3, //depth16bit IDT_R5G6B5 =4, IDT_X1R5G5B5 =5, IDT_A1R5G5B5 =6, IDT_A4R4G4B4 =7, IDT_X4R4G4B4 =8, //depth8bit IDT_R3G3B2 =9, IDT_INDEX8 =10, //depth4bit //IDT_A1R1G1B1=11, //IDT_X1R1G1B1=12, IDT_INDEX4 =13, //depth1bit IDT_INDEX1 =14, IDT_UNKNOWN=-1,};二.使用InstallShield制作安装程序修改InstallShield对话框的过程：一：改变InstallShield自带的对话框的方法1.首先用VC.NET打开_isres.dll资源DLL,该DLL是InstallShield自带的DLL,里面存放了InstallShield中所有自带对话框模板。2.在VC.NET中修改对话框（对话框ID可以通过DialogSampler工具得到）3.保存修改。注意：修改InstallShield自带的对话框只能修改一些文本，和一些控件的相对位置，不能修改控件的ID和增加一些控件，不然会导致控件消息映射不正确。二：自制可以在InstallShield对话框：1.首先用VS.NET打开<InstallShieldlocation>\Examples\CustomDialog\VC++4Project\_isuser.rc，这是一个模板资源，可供用户任意编辑.2.生成自己的对话框，保存DLL.3.写对话框处理函数（跟windows下的对话框处理函数类似）注意：一定要保存所有的控件ID-ValueInstallShield总结文档：1.制作自己的对话框作为自己的主界面（修改-isuser.dll,路径为：C:\ProgramFiles\InstallShield\Professional-StandardEdition\Redistributable\CompressedFiles\0009-English\Intel32）2.设置背景图3.按照InstallShield默认的流程进行安装（也可以按照自己实际需求改动，比如加入自己的对话框）如果InstallShield提供的对话框不符合用户要求，可以修改_isres.dll,（路径为C:\ProgramFiles\InstallShield\Professional-StandardEdition\Redistributable\CompressedFiles\0009-English\Intel32）一些技巧：1.在修改InstallShield自带的对话框时，我们可以用DialogSampler工具查看所要修改对话框的ID2.用InstallShield写注册表时，首先必须要调用RegDBSetDefaultRoot来设置rootkey3.如果要手工控制进度条，可以用SetStatusWindow和StatusUpdate函数来控制4.InstallShield函数调用顺序：OnBegin-->OnFirstUIBefore-->OnMainUIBefore-->OnMoving-->OnInstallingFile-->OnUninstallingFile-->OnMoved-->OnFirstUIAfter-->OnMainUIAfter-->OnEnd5.反安装程序制作：反安装程序的路径放在注册表中（可在MSDN中搜索Uninstall可以查的该路径），所以只要写一个windows程序去调用这个反安装程序。

三.关于3D处理的MMX技术 具有MMX™技术的处理器的在片高速缓存子系统，是由两个16K的4路线长为32字节的关联高速缓存体构成。高速缓存具有一个回写机制和一个伪LRU的置换算法。数据的高速缓存由八个按四字节边界交错的存贮体构成。

在具有MMX™技术的奔腾处理器上，只要引用的数据不在同一个高速缓存体上，就可以被一条读取指令和一条存贮指令同时访问。在具有MMX™技术的奔腾处理器上，高速缓存访问失败的迟延为8个内部时钟周期。在具有MMX™技术的动态执行处理器中，最小迟延是10个内部时钟周期。具有MMX™技术的奔腾处理器和动态执行处理器在分支预测方面，除一个较小的异常处理外(本书2.3.1节中讨论)，在功能上完全一样。

分支目标缓冲区(BTB)存贮了预先所见的分支和它们的目标。当一个分支被预取后，BTB将目标地址直接填入到指令读取单元(IFU)。一旦分支被执行，BTB将随着目标地址而改变。使用分支目标缓存时，预先所见的分支被动态预告。分支目标缓存的预测算法包括了模式匹配和每目标多达4位的预测历史位。例如，一个具有4个迭代长度的循环将百分之百地被正确预测到。遵循下列原则将提高预测性能：

编写条件分支(除循环外)可将最常执行的分支紧接在分支指令后(即失败)。

另外，具有MMX™技术的处理器有一个堆栈返回缓存(RSB,ReturnStackBuffer)，可以连续地为不同地址上调用的过程正确地预测其返回地址，进一步为展开具有函数调用的循环带来了益处，并删除了某些需要in-line的过程。另外，在具有MMX™技术的奔腾处理器上，如果两个分支指令的最后一个字节在同一个按四字节对齐的内存段内，则分支不可预测。如下图所示：图2-5相连分支的例子这种情况，发生在两个相连分支间没有间隔指令且第二个指令只有两个字节长的情况下(如+/-128字节的相对跳转指令)。

为避免这种无法预测的情况，应使第二分支加长，在分支指令中用16位的相对位移代替8位的相对位移。具有MMX™技术的处理器具有4个写缓存(相对无MMX™技术的奔腾处理器的两个写缓存)。另外，写缓存可以被U管道使用，也可以被V管道使用(相对无MMX™技术的奔腾处理器的一个写缓存对应一个管道的情况)。通过对内存写操作进行安排调度，可以提高关键循环的性能。如果你不想看到写未命中，每组指令不能安排多于4条写指令。并在安排另外的写指令前调度其它指令。Intel的MMX™技术是对Intel体系结构(IA)指令集的扩展。该技术使用了单指令多数据技术(SIMD)技术，以并行方式处理多个数据元素，从而提高了多媒体和通讯软件的运行速度。MMX™指令集增加了57条新的操作码和一个新的64位四字数据类型。这种新的64位数据保持了可供MMX™指令操作的成组数据值……

MMX技术在16位高彩和24位真彩数据方面作的并不是最好。封装好的加，乘逻辑运算符实际上已使得24位成了最具有吸引力的运算方式。它包含了3个8位（红，绿，兰）元素或？位固定点（48位是给RGB的）。完成运算之后（像Gouraud阴影，alpha，等），算法转化成RGB16（555或565）以来更新缓存。MMX技术并没有内置的算法，也没有为5位而封装的块。

24位的内部运算符使得能提供用8位调色板无法得到的高质量的色彩。包括：

为雾化，透明化的alpha混合

为橙色火光的RGB（多色彩）的光亮，等等

拟镜的加亮区

瞬间在屏幕上显示多于256种颜色

真正平滑的阴影，随意的混合色彩

少量（或没有）抖动色彩

与其它应用的调色板没有冲突或不协调

与高彩的容量和色彩可媲美，接近于HW加速器

当然，系统的图像存储器的容量决定了是能用16位还是24位彩色。对于1MB的显卡，只能使用8位的调色板（640*480*2字节需要600KB，如果没有双倍缓冲，或后备缓冲在存储系统中，这只能适应于1MB）。对于2MB或4MB的显卡，16位就很诱人了。640*480双倍缓冲后，占用1.2M，仍留下800KB给字符缓存或Z-缓冲。

8位色准许使用一个简单的MOVQ指令来同时以东8个点。如果有了MMX技术的执行单元和“pairing”指令，它也准许16个点的同时比较或（和）混合。不幸的是，8位的调色器处理需要在同一时间内从调色板中读出一个字节。

一直以来，老式处理器的8位处理代码在新的CPU上实际上是扮演着“速度绊脚石”的角色来降低性能。为了奔腾处理器和DynamicExecution（TM）处理的高速度，这应被避免。例子如下：

自修改代码，它用新的地址或即时值重写了部分指令流。这使得避免使用其它注册者来得到数据。在新的CPU中，每个被修改的指令会浪费许多的时钟周期。因为深层的管道必须被清空，而且缓存必须要重写重取。

随机（不是顺序）进入存储区，作为乘法查找的结果，颜色变幻，阴影化或抖动

经常的数据独立分支，尤其当他们的顺区不规则时

与8位或16位（AL，AH，AX，BL….）一样，32位的注册是很优秀的，将8位像素点的乘法和简单的32位写或0溢出单独字节结合起来

使用MMX指令开发时候需要注意的调整代码，一般情况下不使用向前条件分支，通常使用向后的条件分支。按16字节边界条件对齐频繁执行的分支目标。将循环展开来调度指令。使用软件方式来安排流水线以调度迟延和功能单元。必须成对使用CALL和RET(return)指令。避免使用自修改代码。避免把数据放在代码段。尽可能快地计算出存贮地址。应避免使用包含三个或三个以上微操作代码或指令长度超过7个字节的指令。如果可能，使用只有一个微操作的指令。不要使用两个8位读取指令来进行16位的读取。在调用被调用保存(callee—save)过程前，先清除部分寄存器的内容。解决阻塞条件，如存贮地址，尽可能地避免可能引起阻塞的读取。一般情况下，一个可以直接由处理器支持的N-字节的数据(8位的字节，16值的字，32位的双字，32位、64位及80位浮点数)应该对齐在下一个最高的2的乘方边界处，避免未对齐的数据。

——按任意边界对齐8位数据。

——在已对齐的4-字节字数据内对齐16位数据。

——以4的任意倍数为边界，对齐32位数据。

——以8的任意倍数为边界，对齐64位数据。

——以128位为边界(即16字节的倍数)，对齐80位数据。合理化建议 我觉得学院开的很多课程的顺序不对，而且有的课程能放在实习结束后再上效果可能会更好，比如：软件工程，软件测试等，实习前只要将一些基础的课程学好就行了。附录1:软件测试本人目前所在的项目组没有专门的软件测试人员，因此我们充当了双重角色，即是开发人员也是测试人员，本人因此对测试有了更多更深入的了解，在实践方面，除了做最基本的单元测试，功能测试外，还参与了集成测试，系统测试，用户验收测试。下面先介绍一些软件测试的相关概念和方法，再结合本人的实践谈谈我们是如何做软件测试的，以及心得体会。软件测试的基本概念和方法 软件测试方法在不同的书籍中可能有不同的分类，不同的叫法和不同的解释。比如，从测试人员角度看，可分为手动测试和自动测试。从源代码的角度可分为单元测试和功能测试。从理论定义来分，可分为黑箱测试，白箱测试和灰箱测试。而实际项目主要侧重于软件功能的黑箱测试方法：功能测试（FunctionalityTest），验收测试（AcceptanceTest），用户界面(Userinterface)测试，性能测试（PerformanceTest），压力测试（StressTest）。下面就简单介绍一下这些测试方法的概念。 白箱测试：通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。 黑箱测试：通过使用整个软件或某种软件功能来严格地测试，而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。 灰箱测试：就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。 功能测试：验证测试软件功能能否正常按照它的设计工作。看运行软件时的期望行为是否符合原设计。 验收测试：是在把测试的版本交付测试部门大范围测试以前进行的对最基本功能的简单测试。因为在把测试的版本交付测试部门大范围测试以前应该先验证该版本对于所测试的功能基本上比较稳定。必须满足一些最低要求 用户界面测试：分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息（Menu和Helpcontent）等方面的测试。 性能测试：通常验证软件的性能在正常环境和系统条件下重复使用是否还能满足性能指标。或者执行同样任务时新版本不比旧版本慢。一般还检查系统内存在运行程序时会不会泄漏。比如，验证程序保存一个巨大的文件新版本不比旧版本慢。 压力测试：它通常验证软件的性能在各种极端的环境和系统条件下是否还能正常工作。或者说是验证软件的性能在各种极端环境和系统条件下的承受能力。软件测试的重要性 软件测试是保证软件产品质量的重要手段之一。它是测量、评估软件产品特点和能力的活动。现在，国内一些软件企业对于软件测试的重视程度还很不够，认为测试工作非常简单，只是简单地操作所测的软件产品而已。这种错误的思想严重影响了国内软件质量，应该引起我们的高度重视。 下面就看一个例子。微软公司是软件行业的老大，他们对软件测试的重视程度是许多同行无法比拟的。在微软内部，软件测试人员与软件开发人员的比率一般为1.5--2.5左右，微软软件开发的实践过程已经证明了这种人员结构的合理性与正确性。国内公司显然很难达到这种比率，没关系我们刚刚起步，人多人少不是问题所在，关键在于观念与态度，国内软件业和国外相比，最大的差异也许就在于产品质量和质量控制。而软件测试才能为产品质量和质量控制提供保证。心得体会 本人觉得一个好的软件测试员，应该培养以下一些素质：怀疑精神。世界上没有绝对正确的，总有错误的地方，软件也是。所以在测试时，不要轻易对自己说“这里肯定没问题”。打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来。测试不像开发，很明显有任务要去完成，测试似乎更具神秘性，需要你去发现，糟糕的心情无法让你静下心来，也就很难做好测试。

附录2:软件配置当今计算机信息技术产业的迅猛发展，促进了国内的软件开发在先进技术和产品方面的广泛应用。但是，在先进的操作系统，开发工具为企业带来高效益的同时，另一方面也使得我们的开发环境日趋复杂化而难以管理。如：团队沟通困难，软件重用率低下，代码冗余度高，文档不健全等，结果造成数据丢失，开发周期漫长，产品可靠性差，质量低劣，软件维护困难，用户抱怨使用不便，项目风险增加等。

事实已经表明，随着整个软件业的迅速发展，没有得到有效管理的软件开发过程中所出现的风险和挑战将越来越突出。加强软件开发管理，通过管理和追踪软件开发环境中产生的变更，建立规范化的软件开发环境，已成为软件产业化的必要条件。软件配置管理作为软件开发过程中一个重要过程已经逐渐受到各软件企业的重视。

软件配置管理（SoftwareConfigurationManagement），是一个控制软件系统演变的学科。在IEEE标准729-1983中，软件配置管理的定义包括：配置标识——产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。版本控制——通过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。例如，它将解决哪些修改会在该产品的最新版本中实现的问题。状态统计——记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。例如，它将解决修改这个错误会影响多少个文件的问题。审计和审查——确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合。例如，它将解决目前发布的产品所用的文件的版本是否正确的问题。生产——对产品的生产进行优化管理。它将解决最新发布的产品应由哪些版本的文件和工具来生成的问题。过程管理——确保软件组织的规程、方针和软件周期得以正确贯彻执行。它将解决要交付给用户的产品是否经过测试和质量检查的问题。小组协作——控制开发统一产品的多个开发人员之间的协作。例如，它将解决是否所有本地程序员所做的修改都已被加入到新版本的产品中的问题。 软件配置管理的解决方案涉及面很广，将影响软件开发环境、软件过程模型、配置管理系统的使用者、软件产品的质量和用户的组织机构。 软件组织应该提出不同层次的配置管理视角，这些层次包括：公司级、项目级、程序员级和应用级。公司级视角提供组织的全貌图和配置管理过程的描述；项目级视角是与项目相关的各项目组可以使用不同的配置管理方案；程序员级视角是专门为程序员提供的且具有某些特定的配置管理功能；应用级视角关心的是配置管理如何应用到具体的问题中去。软件配置管理（SoftwareConfigurationManagement(SCM)），它为软件开发提供了一套管理办法和活动原则，成为贯穿软件开发始终的重要质量保证活动。需要说明的是，从学术上讲，软件配置管理（SCM）只是变更管理（ChangeManagement(CM)）的一个方面；但从SCM工具的发展来看，越来越多的SCM工具开始集成变更管理（CM）的功能，甚至问题跟踪（DefectTracking）的功能。附录3:团队软件开发实践喜欢足球的朋友应该非常清楚一件事情，那就是在一场足球赛中假如球员之间缺少默契的配合或教练的指导思想执行不到位等情况下，那场比赛多半是以失败告终的，因为这支球队并不是优秀的球队。开发软件项目就象一场进行中的足球赛，是靠项目管理、系统分析设计、程序编制、测试、市场营销等不同角色人员共同协作完成的，不同角色的人执行的工作相互促进和制约着其它角色的人的工作，因此一个高效的软件开发团队是高质量软件项目或产品的保证，可如何才能营造高效软件开发团队呢？从以下几个方面来说明：一、高效软件开发团队的特征

高效的软件开发团队是建立在合理的开发流程及团队成员密切的合作的基础之上的，成员共同的迎接挑战、有效的计划、协调和管理各自的工作以至完成明确的目标，高效的开发团队具有如下特征：

1、具有明确且有挑战性的共同目标

一个具有明确的而且有挑战性目标的团队比目标不明确或不具有很大的挑战性目标的团队效率高得多，通常技术人员往往会因为完成了某个明确的任务，而且这个任务的完成具有挑战性的意义而感到自豪，反过来团队成员为了获取这种自豪的感觉而更加积极的工作从而带来团队开发的高效率，如作为系统设计人员很清楚的知道在什么时候要做到什么，什么时候开始做，什么时候必须完成，为了完成工作必须面临哪些挑战，怎么解决这些困难等为设计出一个高质量的软件项目提供了重要保证，而模模糊糊的去设计一个系统或模模糊糊的就去编写代码是非常危险的，而且会为此付出高昂代价，因此高效的软件开发团队具有挑战性的共同目标。2、团队具有很强的凝聚力

在一个高效的软件开发团队中，成员们凝聚为一个整体共同进行工作，他们是相互支持、互相交流、互相尊重的，而不是相互推卸责任、保守、相互指责的，在一些散乱的开发团队中往往存在这样的问题，一些程序员是比较保守的，明明知道另外的模块中需要用到一段与自己已经编写完成但有些难度的程序代码，他也不愿拿出来给其它程序员共享，不愿与系统设计人员交流，这样给项目的进度造成了些不可度量的因素。3、具有融洽的交流环境

在一个开发团队中，每个人行使自己的职责，如需求分析人员制定需求规格说明、系统设计人员做系统概要设计和详细设计、项目经理配置项目开发环境并且制定项目计划等，但每个人的工作不可能做到完美的，如系统概要设计的文档可能有个别地方词不达意，做详细设计的时候就可能会造成误解，项目经理制定计划时可能忽略了某种风险的存在而造成执行者过于紧张的压力等等情况都需要大家通过交流、反馈的手段然后协商解决的，因此高效的软件开发团队是具有融洽的交流环境的，而不是那种简单的命令执行式的。4、具有共同的工作规范和框架

高效软件开发团队具有规范性及共同框架的工作，对于项目管理具有规范的项目开发计划，对于分析设计具有规范和统一框架的文档及审评标准，对于代码具有程序规范条例，对于测试有规范且可推理的测试计划及测试报告等等。并且所有成员都明白自己的职责，知道必须完成什么计划？由谁来完成？什么时候开始？什么时候结束？按什么顺序？等，总之一个高效的开发团队无论是工作内容还是工作流程都具有不同程度的规范性和标准风格的框架。5、采用合理的开发过程

软件的开发不同于一般商品的研发和生产，开发过程中会面临着各种难以预测的风险，比如需求的变化、人员的异动、技术的瓶颈、同行的竞争等，高效的软件开发团队往往是采用了合理的开发过程去控制开发过程中的风险、提高软件的质量、降低开发费用，这样的团队会根据自身的必要程度决定要执行哪些工作？如配置管理、资源管理、版本控制、代码控制等，团队还合理的分划并定义开发过程的里程碑，决定每项活动内容的底线和审评标准，决定各项活动的先后关系或迭代的关系等。总之高效的软件开发团队的开发过程的原则是高效率、高质量、低成本。

二、目前国内软件开发团队容易存在的问题由于传统的旧体制下的管理思想的沿袭、大部分中国人传统的思维习惯及软件行业在中国发展的处于初期阶段等原因，使国内的许多软件开发团队在领导、合作、质量、参与等方面存在一些问题，具体如下：

1、领导不力

有效的领导是高效率软件开发团队的基本要求，如果领导不力，工作计划就不一定会合理，团队成员也不一定会投入工作的热情，使团队的凝聚力大打折扣；如果领导不力，就不一定有明确且具有挑战性的目标，团队成员就无法完成高质量的项目产品，无法投入信心和激情。传统的旧体制下的管理思想的沿袭，是部分领导还具有老大爷的心态，于是贪功、推卸责任、明则保身等一系列现象也相继而生；如果领导不力，就无法营造融洽的交流环境，团队的工作便是死板的没有生气的；如果领导不力，就不知道采用什么样的开发过程是合理的，就不可能高效率、高质量的完成软件项目。领导不力还可能导致其它问题的出现。2、缺少必要的信心和激情

也许你会发现周围的一些同事仅仅是为了薪水而工作，在执行工作的时候即使发现了上层领导忽略的问题依然照糊涂画瓢也不反馈问题所在，即便他是个天才，但成功不会属于他的，因为成功垂青于有激情的人才，其实这些同事并不是一开始就缺少激情的，原因也许是失去了信心，而暂时做"糊涂人"而已，无论如何，缺少信心和激情的团队，只会是一盘散沙。3、软件质量的价值观念模糊

软