软件开发实习心得 本文关键词：实习，心得，开发，软件
软件开发实习心得 本文简介：软件开发实习心得一直以来期望从事自己喜欢的事业的我，对软件开发有者及大的兴趣，可由说种种原因使我从事工作以来走了好几年弯路，心中的梦想迟迟不能得以实现，可程序员的梦想从来没有从我的心中抹去，但这扇大门好像并没有向我敞开，今天，贵公司给了我敲开这扇大门的机会，让我真实体验了程序员的诞生过程。早就听说，
软件开发实习心得 本文内容：
软件开发实习心得
一直以来期望从事自己喜欢的事业的我，对软件开发有者及大的兴趣，可由说种种原因使我从事工作以来走了好几年弯路，心中的梦想迟迟不能得以实现，可程序员的梦想从来没有从我的心中抹去，但这扇大门好像并没有向我敞开，今天，贵公司给了我敲开这扇大门的机会，让我真实体验了程序员的诞生过程。早就听说，程序员的前几个月是最苦的，可从来没有感受到，海马实习基地让我提前感受到了刚刚进入软件行业的压力和困惑，再也没有在自己家里随便写段小程序后的那种“自豪”感了。要面对每天必须面对的问题，再也不可能以“逃避”而了之了。也让我感觉到做为一个程序员所应该具备的基本素质在这不到一个月的实习过程中也让我深深体会到了作为一个合格的程序员应该具备的基本素质。
团队精神和协作能力是程序员应该具备的基本素质，最近的工作中让我深深休会到了这一点，由于小组成员配合不好，使本来很方便的cvs给自己的工作带来的及大的麻烦，一不小心自己写的的东西就会被小组别的成员在上传文件的时候给覆盖掉，一整天的工作可能就这样被反工，我们小组这次就是因为协作不好，导致各模块之间不法连接，给工作带来了及大的麻烦，消耗了大量的劳动力还没有提高工作效率。这使我深深的体会到：一个成功商业性软件的开发必须有一个有强大凝聚力的团队，个人的力量是有限的，团队精神和良好的协作会使我们做出优秀的软件。
良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30％的工作时间写技术文档是很正常的，缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。这次的这个小小的项目，就因为文档上的一点点理解错误让我们花了很大的工夫去改代码，改页面。很庆幸的是，这是一个小项目，要是大项目，这种问题可能就会导致大量的代码修改，可见文档在一个项目中起者巨大的做用。
此外，良好的代码编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。作为一个程序员，对需求的理解能力也是很重要的，只有真正理解了一个模块的作用，才会写出高效率的代码，才能使整个软件项目作出来更加优秀，具备更好的安全性和稳定性，我在写代码的过程中就遇到了需求理解上的问题，使得写出来的代码功能不全，幸好不是给客户发现在，要不，这个软件的商业价值可能就会打折扣了。单元测试对于一个程序员来说是不可不做的一项工作，不做好测试就会给后期的集成工作带来麻烦，往往为了一个小问题会让我们查找好多模块，给后期工作带来很大麻烦。
这一段时间的工作也让我明白了一点：一个优秀的程序员必须不断的学习，随时总结，找到自己的不足，这样逐步提高，才能让自己很快的成长起来。
建站侠客
发表于
2008-4-28
10:19
对软件开发的一点心得体会
一、前期规划：
我理解的前期规划是：在市场人员们汇总一个需求提交给产品专家带领的产品经理团队，然后经过这个团队根据公司具体情况再次分析和规划出一个最终需求文档。
这个需求文档应当首先提交给技术研发部门的负责人以及核心开发人员。由开发团队对其进行技术和风险分析。如果对此需求统一有异议的地方，需要返回给产品团队，重新修正需求。反复如此，直至需求完善准确，细致，清晰。
前期规划就像高楼的地基，如果马马虎虎，就算是一块砖块没摆好都可能导致整个高楼建设的失败。在规划中我认为，交流永远是需要双方积极主动，能认真听取每个人的建议。前期工作思维不慎重，不细致，不认真，不够完善，将产生连锁效应直接导致整个工程和项目的失败。
这种失败可能表现为：第一种，软件按需求实现但是功能根本不能满足用户需要。第二种，功能都有了，软件没有达到可用性、易用性。
对于第一种，当然是因为前期规划疏漏了某些细小功能，没能把需求文档做完善。应该是规划工作做的还不够认真和细致。
对于第二种情况，我认为更多是在产品设计规划方面经验还不够成熟。这种问题应该是很难避免的。因为每种新产品对产品团队来说都很陌生。即使以前做过类似的东西，也难免面面俱到。这只能通过不断努力和认真的态度来弥补。
前期规划的交流涉及了市场、产品和技术研发等多个团队之间。需要的不仅是团队内部的交流，更多需要协调好团队之间的交流。可能有时候需要公司高层和中层参与协调。
目前，很多开发人员深感项目的需求文档写的都很单薄。大家可以想一想，如果没有好的开始，怎么会有好的结束呢？需求文档单薄，不够细致，由谁来继续完善呢？难道让程序员们自己去完善。我想程序员也可能没有这种能力。对于程序员能把代码写的很健壮很稳定就已经是很不容易的事情了。
二、概要设计：
我理解的概要设计步骤：（以项目为中心的开发流程）
1〉
项目经理仔细阅读项目需求文档。
2〉
项目经理召集项目开发成员，开项目启动会议。具体商议项目的开发任务和责任分配。
3〉
核心开发人员开发确定，以及各模块开发人员确定。
4〉
由系统分析员和核心开发人员仔细阅读需求文档，对系统整个架构分析和做技术规划。
5〉
系统分析员整理和书写最终的系统架构和概要设计文档。
6〉
系统分析员在文档提交日，提交给项目经理。项目经理确认文档并审批。
7〉
项目经理召集项目开发成员，开一个概要设计以及系统架构确定的会议。向每个成员分发文档，并讨论确定最终概要设计文档。
8〉开始详细设计文档的工作
三、详细设计：
1〉
项目经理组织成立各个模块的开发小组，并确定开发小组组长（程序经理）。
2〉
各开发组长书写各自模块的详细设计文档，开发成员需要协助，配合。
3〉
在指定提交日，开发组长提交文档给系统分析员。由系统分析员审批。
4〉
系统分析员组织召开一个详细设计文档确认的会议。
5〉
然后开发组长分发各自模块的详细设计文档给程序员，程序员在指定时间内完成。
6〉
程序员做内部测试。开发组长协调并配合。
7〉
确认无bug提交给开发组组长。
8〉
所有模块整合工作，由整个开发组成员参与完成。由所有开发组长和系统分析员负责主要部分工作。程序员协助和配合。
9〉
对整合后工程做详细测试。
10〉
确认测试通过后，开发组长根据开发成员表现以及提交成果填写绩效考核表。然后提交给项目经理。
11〉
项目经理会召开项目总结会，同时向优秀成员颁奖。同时鼓励所有成员继续努力。对不能按时完成导致项目能按时提交，以及对导致失败的关键人员给与惩罚处理。
当然，以上只是一个简单的开发流程，一定是有很多不足的地方。希望能起到抛砖引玉的作用。大家都明白，流程和制度是死的，但人是活的，所以如何按流程做得好，关键还是在人本身了。没有一个流程和制度，一个团队也必将是一盘散沙。正所谓“无规矩无以成方圆”。这句话说得很有道理。
四、具体编码：
开发几个项目之后，对编写程序有了更进一步的了解。
好的程序应该具有:
易读性，易扩展性，容错性。
易读性:
所有变量和函数以及类名用简单易懂易记忆的命名方式。所有类和函数甚至变量都有关键的注释说明。这点很重要，也是最基础的。如果代码书写不够美观和易懂，我想自己以后也不想再看。就更别谈功能的扩展和新版本开发了。
易扩展性:
整体系统架构逻辑简单清晰。模块与模块之间尽量做到互不影响，也就是尽可能的独立。这部分工作主要体现在前期设计工作中，需要掌握好的设计经验和方法才能够做得比较好。
容错性:
对数据流和指针以及数组都做数据有效性检查；对第三方接口的调用失败的容错性。对所有代码都做调用失败后的错误处理。以及在大的工程中加入trace文件输出，把关键的数据流和关键处理部分的操作信息输出。以便对工程异常情况产生条件的定位，及时解决问题。
我觉得程序员能在这三方面做得很好就算一个优秀的programmer了。
五、调试、跟踪与测试：
1
测试需要注意的：
对每个模块的接口做测试，数据边界的检查。在对整个模块做测试。
主要测试稳定性，效率以及功能是否正常。
确认单个模块完全正常后，再加入工程。
在系统架构设计的时候，可能会引入原型参考。要对原型做完成测试后，确认没有问题后，才可使用。
2
可以采用VC自带Trace或者将信息输出为文本文件的方式跟踪程序并输出关键信息，以便定位程序异常的原因。
3
对于通信模块的测试，特别注意服务端和客户端的数据流。可以针对性的写一个客户端或服务端的测试程序，检验通讯过程是否正常。
4
在用VC做开发中，一定先要让Debug版本正常运行，保证没有任何异常，内存泄漏和Assert等调试警告信息。如果用到其他Lib,一定要保证Lib本身不存在问题。
这里只是提到一些自己容易忽略的东西，希望能对大家有所帮助，欢迎指正！谢谢。
篇2：RUP中文模板软件开发计划
RUP中文模板软件开发计划 本文关键词：中文，模板，计划，开发，软件
RUP中文模板软件开发计划 本文简介：软件开发计划版本[注：以下提供的模板用于RationalUnifiedProcess。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=BodyText）。][要定制Micro
RUP中文模板软件开发计划 本文内容：
软件开发计划
版本
[注：以下提供的模板用于
Rational
Unified
Process。其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。按此样式输入的段落将被自动设置为普通样式（样式=Body
Text）。]
[要定制
Microsoft
Word
中的自动字段（选中时显示灰色背景），请选择
File>Properties，然后将
Title、Subject
和
Company
等字段替换为此文档的相应信息。关闭该对话框后，通过选择
Edit>Select
All（或
Ctrl-A）并按
F9，或只是在字段上单击并按
F9，可以在整个文档中更新自动字段。对于页眉和页脚，这一操作必须单独进行。按
Alt-F9，将在显示字段名称和字段内容之间切换。有关字段处理的详细信息，请参见
Word
帮助。]
Version:
软件开发计划
Date:
修订历史记录
日期
版本
说明
作者
目录
1.简介5
1.1目的5
1.2范围5
1.3定义、首字母缩写词和缩略语5
1.4参考资料5
1.5概述6
2.项目概述6
2.1项目的目的、规模和目标6
2.2假设与约束6
2.3项目的可交付工件6
2.4软件开发计划的演进6
3.项目组织6
3.1组织结构6
3.2对外联系6
4.管理流程6
4.1项目估计6
4.2项目计划6
4.2.1阶段计划6
4.2.2迭代目标7
4.2.3发布版7
4.2.4项目时间表7
4.2.5项目资源分配7
4.2.6预算7
4.3迭代计划7
4.4项目监测与控制7
4.4.1需求管理计划7
4.4.2进度控制计划7
4.4.3预算控制计划7
4.4.4质量控制计划7
4.4.5报告计划7
4.4.6评测计划8
4.5风险管理计划8
4.6收尾计划8
5.技术流程计划8
5.1开发案例8
5.2方法、工具和技巧8
5.3基础设施计划8
5.4产品验收计划8
6.支持流程计划8
6.1配置管理计划8
6.2评估计划8
6.3文档计划8
6.4质量保证计划9
6.5问题解决计划9
6.6分包商管理计划9
6.7流程改进计划9
7.其他计划9
8.附录9
9.索引9
软件开发计划
1.
简介
软件开发计划的简介应提供整个文档的概述。它应包括此软件开发计划的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。]
1.1
目的
[阐明此软件开发计划的目的。]
1.2
范围
[简要说明此软件开发计划的范围：它的相关项目，以及受到此文档影响的任何其他事物。]
1.3
定义、首字母缩写词和缩略语
[本小节应提供正确解释此软件开发计划所需的全部术语的定义、首字母缩写词和缩略语。这些信息可以通过引用项目词汇表来提供。]
1.4
参考资料
[本小节应完整列出此软件开发计划中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过对附录或其他文档的引用来提供。
对于软件开发计划，引用工件的列表中应包括：
·
迭代计划
·
需求管理计划
·
评测计划
·
风险管理计划
·
开发案例
·
业务建模指南
·
用户界面指南
·
用例建模指南
·
设计指南
·
编程指南
·
测试指南
·
手册风格指南
·
基础设施计划
·
产品验收计划
·
配置管理计划
·
评估计划（仅当该计划是单独的计划时，但它通常是
SDP
的第
6.2
节。）
·
文档计划
·
质量保证计划
·
问题解决计划
·
分包商管理计划
·
流程改进计划]
1.5
概述
[本小节应说明此软件开发计划其他部分所包含的内容，并解释文档的组织方式。]
2.
项目概述
2.1
项目的目的、规模和目标
[简要说明此项目的目的与目标，以及此项目将要交付的可交付工件。]
2.2
假设与约束
[列出此计划所依据的假设和项目所受到的所有约束（如预算、人员、设备、时间表等）。]
2.3
项目的可交付工件
[以表格的形式列出将在项目中创建的工件，并包括预定交付日期。]
2.4
软件开发计划的演进
[以表格的形式列出软件开发计划的提议版本，以及在计划外修订与重新发行此计划需符合的标准。]
3.
项目组织
3.1
组织结构
[说明项目团队（包括管理部门和其他复审权威部门）的组织结构。]
3.2
对外联系
[说明项目与外部组织的联系方式。
对于每个外部组织，应确定其内部和外部联系人的姓名。]
角色与职责
[确定将负责各个核心工作流程、工作流程明细和支持流程的项目组织单位。]
4.
管理流程
4.1
项目估计
[提供估计的项目成本与进度、这些估计所依据的基础，以及在何时和什么情况下需要对项目进行重新估计。]
4.2
项目计划
4.2.1
阶段计划
[应包括以下内容：
·
工作细分结构
(WBS)
·
显示项目各阶段或迭代的时间分配情况的时间线或甘特图
·
确定主要里程碑及其实现标准
确定所有重要的发布点和演示]
4.2.2
迭代目标
[列出每次迭代将要实现的目标。]
4.2.3
发布版
[简要说明每个软件发布版，并指出它是否是演示版、Beta
版等。]
4.2.4
项目时间表
[用图或表显示完成迭代与阶段、发布点、演示以及其他里程碑的预定日期。]
4.2.5
项目资源分配
4.2.5.1
人员配备计划
[在此处确定所需人员的数目和类型，以及项目阶段或迭代所需的任何特殊技能或经验。]
4.2.5.2
资源获取计划
[说明您将如何发现并招募项目所需的人员。]
4.2.5.3
培训计划
[列出项目团队成员所需的所有特殊培训，以及完成这些培训的预定日期。]
4.2.6
预算
[按照
WBS
和阶段计划分摊成本。]
4.3
迭代计划
[各项迭代计划将通过引用附加在本节中。]
4.4
项目监测与控制
4.4.1
需求管理计划
[通过引用附加。]
4.4.2
进度控制计划
[说明以何种方法按照设定的时间表监控项目进展，以及如何在需要时采取纠正措施。]
4.4.3
预算控制计划
[说明以何种方法监控项目预算开支，以及如何在需要时采取纠正措施。]
4.4.4
质量控制计划
[说明将在何时利用何种方法来控制项目可交付工件的质量，以及如何在需要时采取纠正措施。]
4.4.5
报告计划
[说明将生成的内部和外部报告，以及报告发布的频率和范围。]
4.4.6
评测计划
[通过引用附加。]
4.5
风险管理计划
[通过引用附加。]
4.6
收尾计划
[说明有序地完成项目时所执行的活动，其中包括人员重新分配、项目材料存档、事后汇报及报告等。]
5.
技术流程计划
5.1
开发案例
[通过引用附加。]
5.2
方法、工具和技巧
[通过引用列出所记录的项目技术标准等内容，包括：
·
业务建模指南
·
用户界面指南
·
用例建模指南
·
设计指南
·
编程指南
·
测试指南
·
手册风格指南]
5.3
基础设施计划
[通过引用附加。]
5.4
产品验收计划
[通过引用附加。]
6.
支持流程计划
6.1
配置管理计划
[通过引用附加。]
6.2
评估计划
[作为软件开发计划的一部分，本节说明项目的产品评估计划，并介绍评估所使用的方法、标准、指标和过程，这就会涉及到走查、检查和复审。请注意，评估计划是对测试计划的补充，但软件开发计划中并不包括测试计划。]
6.3
文档计划
[通过引用附加。]
6.4
质量保证计划
[通过引用附加。]
6.5
问题解决计划
[通过引用附加。]
6.6
分包商管理计划
[通过引用附加。]
6.7
流程改进计划
[通过引用附加。]
7.
其他计划
[列出合同或法规所要求的其他计划。]
8.
附录
[供
SDP
读者使用的其他材料。]
9.
索引
Confidential
ó,2000
Page
9
of
9
篇3：工行个人消费信贷项目软件开发计划
工行个人消费信贷项目软件开发计划 本文关键词：工行，消费信贷，计划，项目，开发
工行个人消费信贷项目软件开发计划 本文简介：软件开发计划编写指南软件开发计划编写指南（文档编号：FO-QR-19-01）方正奥德计算机系统有限公司文档管理信息表主题：软件开发计划编写指南版本：1．0．0内容：规范软件开发计划的内容、格式关键字参考文档：创建时间：2002年10月6日创建人：杜磊最新发布日期：文档修改记录表修改人修改时间修改内容
工行个人消费信贷项目软件开发计划 本文内容：
软件开发计划编写指南
软件开发计划编写指南
（文档编号：FO-QR-19-01）
方正奥德计算机系统有限公司
文档管理信息表
主题：
软件开发计划编写指南
版本：
1．0．0
内容：
规范软件开发计划的内容、格式
关键字
参考文档：
创建时间：
2002年10月6日
创建人：
杜
磊
最新发布日期：
文档修改记录表
修改人
修改时间
修改内容
目
录
1、
项目资源4
1.1、项目人员分工、职责与权限4
1.2、设备与工具4
2、
开发阶段划分5
3、
进度安排5
3.1、合同进度安排：5
4、
工具和技术6
4.1、个贷的使用工具包括：6
4.2、总行个贷移植的使用技术方法包括：7
5、
规则、惯例和约定7
5.1、项目实施中项目管理文档样本7
5.1.1、各阶段应提交的文档7
5.1.2、程序开发约定9
9
1、
项目资源
1.1、
项目人员分工、职责与权限
工行个贷移植人员分工:
项目经理：杜
磊
开发经理：杜
磊
需求分析：杜
磊、刘黎明
系统分析：杜
磊，徐加星，王俊山
软件编码：杜
磊，徐加星，王俊山，倪勇飙
软件测试：杜
磊，徐加星
数据库管理：杜磊
配置管理：杜磊
系统配置/调优：
系统集成：
网页制作：
实施总控：
技术总控：
行业咨询：
1.2、
设备与工具
3台Aix
M80分别作为：测试机，生产机，数据库服务器
软件设备：
数据库服务器
Oracle
8.05
中间件服务器
WebSphere
3.5
程序编辑器
UltraEdit-32,Webspere
studio3.5
压力测试工具
E_test
Java程序编译包
Java1.3.1
2、
开发阶段划分
明确项目开发主要的阶段，包括阶段的划分、阶段的输入、输出及验证准则。
规定开发过程至少应包括设计、实现（编码）、测试三个阶段。
里程碑即项目重要阶段的完成标志。里程碑控制方法的原理是：一个项目阶段的输出即下一个项目阶段的输入，在重要项目阶段结束时，审查控制项目阶段的输出质量就是项目质量的一个重要保证。个贷移植项目的重要里程碑的划分如下图示：
里程碑1：完成需求分析
里程碑2：完成详细设计
里程碑3：完成编码计划和配置项计划清单
里程碑4：完成软件测试
里程碑5：完成系统安装与调试
里程碑6：完成系统试运行
在以上每个里程碑进行后，通过总控组成员的审核控制，保证本阶段成功完成，下一个阶段能够展开。
3、
进度安排
3.1、
合同进度安排：
规定组成项目开发的各阶段任务实施的时间表、相互的进展顺序以及不同任务和阶段对资源的要求。
各个阶段的时间安排和人员分工如下表所示：项目计划使用Microsoft
Project
2000编写
4、
工具和技术
4.1、
个贷的使用工具包括：
硬件设备：
数据库服务器
AIX
M80
软件设备：
数据库服务器
Oracle
8.0.5
中间件服务器
Websphere
3.5
程序编辑器
UltraEdit-32
Websphere
studio
3.5
压力测试工具
E_test
Java程序编译包
Java1.3.1
Java集成编译包
Websphere
studio
3.5
页面开发工具
Websphere
studio
3.5
4.2、
总行个贷移植的使用技术方法包括：
Web三层结构技术。
Oracle8数据库技术。
JSP
+
servlert
+
JDBC
+
DataBase技术。
PL/SQL
VB/ADO
5、
规则、惯例和约定
描述本项目中使用到的规则、惯例和约定，特别是本项目中使用的由本项目组或所属部门制定的内部规定，质量记录表格等。
5.1、
项目实施中项目管理文档样本
方正奥德公司提供项目管理阶段控制文件样本，以及以往客户项目文档样本。
5.1.1、
各阶段应提交的文档
项目立项阶段
《开发立项报告》
《开发立项报告审批表》
项目开发计划
《软件开发计划》（含软件开发进度）
《软件开发计划审批表》
《项目变更记录》（如果有变更）
项目质量计划
《软件质量计划》
《软件质量计划审批表》
《软件质量计划变更记录》（如果有变更）
项目需求分析
《需求分析说明书》
《需求分析说明书审批表》
《需求内容变更表》
《系统初步手册》
项目设计
《软件设计说明书》
《软件设计说明书审批表》
《设计内容变更表》（如果有变更）
（注：其中《软件设计说明书》中包括：
应用软件逻辑设计文档、
系统结构设计文档
数据库设计文档
接口需求说明书
接口设计文档
程序详细设计说明书、
应用软件模块设计文档、
软件故障处理流程文档等部分。）
项目实施阶段（即软件实现阶段）
《编码工作计划》
《代码抽查验证表》
《模块测试提交表》
《完成情况表》
《用户手册验证审核表》
《开发人员工作周报》
《系统代码》
《用户手册》
系统测试阶段
《软件测试计划》
《软件测试计划审批表》
《软件测试大纲》
《软件测试记录表》
《软件测试问题记录表》
《模块测试报告》
《系统测试报告》
《模块测试通过标准》
《系统测试通过标准》
系统发版阶段
《软件产品发版申请单》
《软件产品发版通知书》
《软件产品发版移交单》（包括提交的文档和母盘）
系统维护阶段
《软件产品维护计划》
另外，在项目开发过程中，还需要做日常技术支持活动，提交如下主要文档：
《配置管理计划》
《软件配置项清单》
《软件配置项实际清单》
《软件配置项修改记录》
《软件配置项修改统计》
《软件度量程序》
《软件产品度量报告》
《软件过程度量报告》
《规则、惯例和约定评审表》
《工具软件使用记录》
《评审会议记录表》等。
5.1.2、
程序开发约定
5.1.2.1、
Java
开发语言规范
同Java语言开发规范。