怎样用ppt作项目开发计划时间表

一般来说，软件项目演示案例，应该是指你做的开发项目要进行演示，让别人了解它的功能和用法。

这种情况下，如果让你提交文档，应该用PPT会比较好，上面分别对开发的理念、功能、用法做阐述，并在PPT上加入你的软件界面截面和说明，最好有条理分功能制作。

简单的说，就是要对你的项目做好展示。

最后，建议你联系比赛有关机构，与其沟通了解对方的要求和目的，针对这些再做。

就如何利用面向对象的软件开发方法来开发软件心得体会

面向对象技术是软件技术的一次革命，在软件开发史上具有里程碑的意义。

随着OOP（面向对象编程）向OOD（面向对象设计）和OOA（面向对象分析）的发展，最终形成面向对象的软件开发方法 OMT(LbjectModellingTechnique)。

这是一种自底向上和自顶向下相结合的方法，而且它以对象建模为基础，从而不仅考虑了输入、 输出数据结构，实际上也包含了所有对象的数据结构。

所以OMT彻底实现了PAM没有完全实现的目标。

不仅如此，OO技术在需求分析、可维护性和可靠性这三 个软件开发的关键环节和质量 指标上有了实质性的突破，彻底地解决了在这些方面存在的严重问题，从而宣告了软件危机末日的来临。

自底向上的归纳 OMT的第一步是从问题的陈述入手，构造系统模型。

从真实系统导出类的体系，即对象模型包括类的属性，与子类、父类的继承关系，以及类之间的关 联。

类是具有相似属性和行为的一组具体实例（客观对象）的抽象，父类是若干子类的归纳。

因此这是一种自底向上的归纳过程。

在自底向上的归纳过程中，为使子 类能更合理地继承父类的属性和行为，可能需要自顶向下的修改，从而使整个类体系更加合理。

由于这种类体系的构造是从具体到抽象，再从抽象到具体，符合人类 的思维规律，因此能更快、更方便地完成任务。

这与自顶向下的Yourdon方法构成鲜明的对照。

在Yourdon方法中构造系统模型是最困难的一步，因为 自顶向下的“顶”是一个空中楼阁，缺乏坚实的基础，而且功能分解有相当大的任意性，因此需要开发人员有丰富的软件开发经验。

而在OMT中这一工作可由一般 开发人员较快地完成。

在对象模型建立后，很容易在这一基础上再导出动态模型和功能模型。

这三个模型一起构成要求解的系统模型。

自顶向下的分解 系统模型建立后的工作就是分解。

与Yourdon方法按功能分解不同，在OMT中通常按服务（Service）来分解。

服务是具有共同目标的相关 功能的集合，如I/O处理、图形处理等。

这一步的分解通常很明确，而这些子系统的进一步分解因有较具体的系统模型为依据，也相对容易。

所以OMT也具有自 顶向下方法的优点，即能有效地控制模块的复杂性，同时避免了Yourdon方法中功能分解的困难和不确定性。

OMT的基础是对象模型 每个对象类由数据结构（属性）和操作（行为）组成，有关的所有数据结构（包括输入、输出数据结构）都成了软件开发的依据。

因此Jackson方法 和PAM中输入、输出数据结构与整个系统之间的鸿沟在OMT中不再存在。

OMT不仅具有Jackson方法和PAM的优点，而且可以应用于大型系统。

更重 要的是，在Jackson方法和PAM方法中，当它们的出发点——输入、输出数据结构（即系统的边界）发生变化时，整个软件必须推倒重来。

但在OMT中系 统边界的改变只是增加或减少一些对象而已，整个系统改动极小。

需求分析彻底 需求分析不彻底是软件失败的主要原因之一。

即使在目前，这一危险依然存在。

传统的软件开发方法不允许在开发过程中用户的需求发生变化，从而导致种种问题。

正是由于这一原 因，人们提出了原型化方法，推出探索原型、实验原型和进化原型，积极鼓励用户改进需求。

在每次改进需求后又形成新的进化原型供用户试用，直到用户基本满意，大大提高了软件的 成功率。

但是它要求软件开发人员能迅速生成这些原型，这就要求有自动生成代码的工具的支持。

OMT彻底解决了这一问题。

因为需求分析过程已与系统模型的形成过程一致，开发人员与用户的讨论是从用户熟悉的具体实例（实体）开始的。

开发人员必须搞清现实系统才能导出系统模型，这就使用户与开发人员之间有了共同的语言，避免了传统需求分析中可能产生的种种问题。

可维护性大大改善 在OMT之前的软件开发方法都是基于功能分解的。

尽管软件工程学在可维护方面作出了极大的努力，使软件的可维护性有较大的改进。

但从本质上讲，基于功能分解的软件是不易 维护的。

因为功能一旦有变化都会使开发的软件系统产生较大的变化，甚至推倒重来。

更严重的是，在这种软件系统中，修改是困难的。

由于种种原因，即使是微小的修改也可能引入 新的错误。

所以传统开发方法很可能会引起软件成本增长失控、软件质量得不到保证等一系列严重问题。

正是OMT才使软件的可维护性有了质的改善。

OMT的基础是目标系统的对象模型，而不是功能的分解。

功能是对象的使用，它依赖于应用的细节，并在开发过程中不断变化。

由于对象是客观存在的，因此当需求变化时对象的性质要比对象的使用更为稳定，从而使建立在对象结构上的软件系统也更为稳定。

更重要的是OMT彻底解决了软件的可维护性。

在OO语言中，子类不仅可以继承父类的属性和行为，而且也可以重载父类的某个行为（虚函数）。

利用这 一特点，我们可以方便地进行功能修改：引入某类的一个子类，对要修改的一些行为（即虚函数或虚方法）进行重载，也就是对它们重新定义。

由于不再在原来的程 序模块中引入修改，所以彻底解决了软件的可修改性，从而也彻底解决了软件的可维护性。

OO技术还提高了软件的可靠性和健壮性。

软件设计有哪些心得？

曾经看过一本书叫《道法自然》，内容略记得一二，但我最欣赏的是它的书名。

软件设计没什么太神秘有东西，只要用心体会，其实一切都很自然。

软件的设计之“道”，也不在于设计有多么的华丽、精巧，而在于其朴实、自然，最终达到“以无招胜有招”，进入一个全新的境界。

一、软件设计理论的层次 以我的拙见，软件设计领域中的各种概念，可以分为以下几个层次来进行理解： 1、软件设计的目的：重用性、扩展性。

这是最高的层次，是应对软件危机的需要。

2、设计原则：低耦合、高聚合。

各种软件设计的原则，如依赖倒置原则、单一职则原则、面向接口等，以及各种设计模式，其根本的目的其实只是为了降低耦合这么简单。

因为只有低耦合才能更好的适应变化，更好的重用和扩展。

3、实现方法：运用设计模式封装变化、降低耦合。

设计模式只是用来“封装变化、降低耦合”的工具而已。

它是面向对象设计时代的产物，其本质就是充分运用面向对象的三个特性，即：封装、继承和多态，进行灵活的组合运用。

二、关于耦合 1、耦合的粒度 耦合无论如何也是不可避免的。

当我们实现接口、继承父类的时候，就会不可避免的产生耦合。

耦合是有不同粒度的，我们解耦到什么粒度为止，我认为应以模块的重用粒度为准。

尽量解除重用模块或对象之间的耦合。

而重用模块之内的耦合，应属于聚合的范畴，所以不要盲目的去解耦，否则就陷入了误区。

2、解耦的原理 怎样才能解耦呢，或者说为什么各种设计模式能达到解耦的目的呢？我觉得有以下几个思路： （1）将具体的东西抽象处理 （2）将分散的东西集中处理 而面向对象中的接口、继承正为我们提供了这样的一种机制。

通过访问接口或基类或抽象类，而不是具体的实现类，从而与具体的实现类达到了解耦的目的。

我们还可以设计一些控制类，像润滑剂一样，协调各实现类之间的访问，也可以达到耦的目的。

事实上，各种设计模式的基本思想也就是这样。

创建型模式是为了解除创建对象时产生的耦合，实际上是解除对类称名的依赖，而结构型和行为型是为了解除对象属性或方法的直接调用。

不管什么设计模式，都是将对具体实现类的访问提升为对接口、基类或用于协调的控制类的访问。

三、关于接口 这一节更具体，谈一谈接口，因为使用接口是软件设计的重要手段，但已经不属于“道”了~

软件开发项目中,过程管理文档包括哪些

在软件项目开发过程中，应该按软件开发要求撰写十三类文档，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性！ 需求阶段 1、可行性分析报告 说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。

2、项目开发计划 为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。

3、软件需求说明书（软件规格说明书） 对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。

它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。

该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。

设计阶段 4、概要设计说明书 该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。

5、详细设计说明书 着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。

开发阶段 6、开发进度月报 该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。

测试阶段 7、测试计划 为做好集成测试和验收测试，需为如何组织测试制订实施计划。

计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。

8、测试分析报告 测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。

收尾阶段 9、用户操作手册 本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解，为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。

10、项目开发总结报告 软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。

11、软件维护手册 主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。

维护阶段 12、软件问题报告 指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软 件修改提供准备文档。

13、软件修改报告 软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。

如何写软件开发人员的简历项目经验 详细？？

近接触的一些学习Java 的学生在简历中，往往项目经验及描述都只能寥寥几笔完事，这样的简历肯定是不吸引招聘企业HR 的。

用在了那一行业？为这个行业提高了多少效率吗？实际上对方需要知道的无外乎以下几点：2、你在项目组中的位置、是否能独立解决问题；3、你的业务知识与团队合作能力等。

技术显然是最重要的，但你需要非常用心的描述整个项目的技术框架，让招聘人员知道你从对宏观上架构很熟悉，然后突出你解决的技术问题。

下面我们参考一种项目描述：“本项目采用JSP + JavaBean + Struts 开发，采用了MVC 模式，表现层与业务层分离，易于维护、扩展”不用JSP 吗？难道能不MVC 吗？可维护性本该是描述的重点，可是只有简单的一句“表现层与业务层分离”？？？？下面是我写的一段项目描述（虚拟的）：“本项目结构上分为表现层、业务层和数据访问层，层次间的依赖关系自下到上。

采用的技术有Struts,Spring,Hibernate,Log4J,JDom 等。

其中表现层采用Struts 框架开发；业务层封装业务流程，为适应业务的变更，每一业务模块均有专门的接口及实现类，利用Spring的IoC 功能将实现类注入给表现层的Action；数据访问层借助于Hibernate 实现，代码简洁且可适应不同的数据库。

事务部分利用Spring 的声明式事务管理。

为提高性能，采用ServletFilter 实现了缓存代理”这段项目经验描述简单的勾划出了系统的结构，也表现出你非常熟悉 Struts,Spring,Hiberante 这几种技术。

同时可以注意到，其中一些重要环节描述的十分简略，比如事务、缓存代理，这其实是故意的。

面试的时候很多人都怕对方突然问一个自己没有准备的问题，往往缺乏应变能力。

一方面你需要多进行专门的练习，另一方面要知道面试时你并不总是被动的，等待对方发问。

如果你给对方的只是一份普普通通的简历，里面只提到了大家都会提及的 JSP,Struts，那你只好等待对方随机的问题了。

但是如果你的项目经验和描述像刚才那么写，对方就很可能这时你已经变被动为主动啦？？？？当然，前提是你写的这些技术要点一定是自己掌握的，事先总之写好个人简历中项目经验中项目描述也是求职方法的一种。

...

软件开发项目需求的前期工作如何进行？

万事开头难。

能否作好需求分析是一个项目成败的关键。

需求分析初始工作的好坏对后续影响极大不可不查。

我在这里提几点看法，不一定正确，算是抛砖引玉吧。

第一步：请客吃饭。

看起来很庸俗，但却是非常有效的手段，通常客户方的中高级领导工作都很繁忙，在饭局上才有时间能够摸清楚他们真正关心的和反对的，弄清楚之后，需求的方向性才不会出错。

通常来说政府机关的领导比较关心政绩，企业老板比较关心成本与销售。

第二步：摸清楚对方项目实施负责人的心态与兴趣爱好。

一般来说，客户方会指定一名懂技术的人员作为项目实施负责人，如果能够争取到他的积极配合，会在以后的工作中带来许多方便，特别是在验收的时候。

第三步：跟对方的实际操作人员（他们是软件真正的用户）交谈，观察他们的业务，记录下他们每天的工作，并要了解他们的工作是如何被考核的。

在这里不要怕花时间，你如果在这里“节约”一天时候，到头来可能会浪费一个星期也许是半个月的时间。

第四步：准备好一张纸一支笔，画系统分析图。

不要计算机，因为它会限制你想象力的发挥。

另外，当客户提出一个需求之后，都要问一个为什么他会提出这种需求，要能够分析客户需求的背景及真正原因。

否则，等软件完成之后，客户会指责缺这个少那个功能，而开发人员则会抱怨客户的需求多变，为什么当时不提出来。

几年单片机项目开发心得总结

自己好好总结下，解决的方法途径有哪些。

你从中收获了能些能力这种东西还要百度啊。

自己这么多年做了哪些项目。

能写的东西很多。

做一个项目的流程是怎么样的，一定有收获，谈谈在做项目中遇到的困难，还有是怎么解决的，其他人又不知道你做了什么。

写写你学到了哪些知识，肯定能学到不少东西啊，只要你自己动手做过的...