软件开发的认识

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

、如何开发一个成功的软件产品?

要成功的开发一个软件产品,需要满足如下两个条件

1、完美的开发团队

2、开发过程合理控制

2.1 完美的开发团队

软件产品不需要原料,软件团队是软件产品生产的最重要资源了。如何成就一个完美的开发团队,意见如下:

1、具有软件开发必备角色,包括需求、系统分析、技术攻关、代码编写、软件测试等。

2、具有自己文档、代码规范标准,以便于维护集成。

3、具有自己资源库。

4、具有和谐的团队关系、正确的沟通方式

5、具有英明的项目经理

2.1.1 具有软件开发必备角色

一个软件开发团队,必须具备软件工程中应有的角色,包括需求分析、系统分析、技术攻关、代码编写、软件测试等,这里不再赘述。

2.1.2 具有自己文档、代码规范标准

软件开发周期的各个阶段都应该有相应的文档,软件工程等相关学科都有很大篇幅讲文档的重要性。软件开发团队对文档处理各有千秋,主要可分为如下三种情况:

1、开发团队不重视文档,往往事后根据需要再追加文档,这类开发

团队一般规模较小,属于作坊式的

2、开发团队迎合软件工程中文档教条,不联系自己实际情况写文档,

文档格式形式化,这种开发团队一般是吃大锅饭的,文档在这种团队

被作为形象展示的工具

3、开发团队把文档作为产品的一部分,基于软件工程理论写文档,

利用文档对项目进行控制跟踪,真正的发挥了文档的功用。

但是一个优秀的开发团队除了按上面第三种方式处理文档外,还应该具有自己的文档、代码规范标准,所有成员都要遵循这个标准编写文档或代码,而不是各自按自己的习惯处理文档或者代码。

我们知道程序编写人员都不愿意解读别人的代码,其实主要原因不是代码复杂度问题,而是他们写代码的规范不一致,注释不规范或者不明确。所以团队如

果有了自己的代码规范,所有成员都遵循这个规范,那么在程序对接、移交以及维护等方面效率会很高。

2.1.3 具有自己的资源库

资源库是自己通俗的说法,它应该包括文档、技术文献、问题分析及解决方案、源代码和控件等。这些资源应该用以一种方式管理(比如以数据库的方式存储),以资源平台的方式向团队所有成员开放,便于检索查询重用。

一个技术团队,资源库是非常重要的,它是团队所有成员在实践中经验的积累、技术的总结,是团队成员技术共享的纽带。

软件产品的成本基本上只有人力资源,资源库的存在很大程度上节省了人力资源,假设我们把一个新的开发项目的功能细化后,很多功能模块都可以从资源库中直接调出来使用、当我们遇到一个很久以前花费很大精力解决的技术性问题,我们可以直接从资源库中检索出该问题及解决方案,当程序员A需要写一个链表类时,可以通过资源库参考程序员B曾经编写的链表类…….这将是多么愉快的事情。

2.1.4具有和谐的团队关系、正确的沟通方式

技术人员是软件公司的支柱,技术人员之间关系的和谐就显的非常重要。另外由于软件产品的特性就是复杂度高,软件产品生产过程就是一批技术人员沟通、执行的过程。所以和谐的团队关系及正确的沟通方式都非常重要。关于如何做好这一点,有如下看法:

和谐的关系上,队员之间要作到理解、尊重、宽容,这不但是关系发展的前提,也是关系健康向上发展的基础。

有了和谐的关系,沟通就显得顺利多了,个人认为沟通主要做到如下三点:

1、要有所准备:沟通就是因为有问题需要讨论,那么就有问题的提出方和解决问题的一方,这就需要问题的提出方根据实际情况(问题复杂性、重要性、参与讨论的角色和专业方向)做出充分的准备,比如如何描述问题才能让参与讨论的不同角色的人在相对短时间内对问题有深刻的理解并给出好的建议。那么对于技术性非常强的讨论或者讲座、就需要参与讨论的成员事先至少对该技术性的话题有一个宏观的认识,比如技术讲座,如果技术性很强,最好就是听讲座的成员先对讲座的内容有一个了解,然后才能更好的在听讲过程中受益并发挥。毕竟不是小学生上课,我们的技术讲座也不该是照本宣科,应该事先了解、然后在听与讨论中掌握知识。

2、要学会聆听,这不仅是对别人的尊重,也确实能使自己受益(只要对方不是虚无缥缈、话不中的、夸夸其谈的长篇大论),不要别人刚刚开口,咱就来个,你不知道、你不懂,这是不对的,三人行、必有我师。相互的聆听是理解问题的基础,是讨论问题得出正确方案的前提。

3、要换位思考,工作中我们要学会换位思考、不要主观的臆断。特别是团队协作的时候,要站到我们搭档的角度去看问题、思考问题,理解你的搭档、尊重你的搭档,才能得到正确的讨论结果或解决方案。

2.1.5具有英明的项目经理

不讨论项目经理职业、心理、知识、经验等条款化的素质。也不讨论决策、沟通等项目经理应该必备的能力,只从自己角度,谈下自己的几点看法。

1、要有一定的权利,从实出发对待问题。很多软件公司会出现项目

经理责任高、权利小的现象。也很多项目经理由于某些缘故,在方案

决策处理方面不能从实对待问题,这种现象往往出现在项目经理的上

级领导对项目过多干预的情况下。

2、中肯,谦虚,尊重队员。能认真听取所有成员的技术观点、意见。

这点很重要,俗话说“三个臭皮匠,顶个诸葛亮”,技术的追求是无

止境的,项目经理不可能掌握全部技术的新动向。

3、有亲和力和一定的人格魅力,能站到所有团队成员的角度思考问

题。化解技术合作或者日常生活上不和谐的情绪。项目经理毕竟不是

技术骨干,只是懂得决策、懂得技术是不行的。

2.2 开发过程合理控制

软件产品工程化之后,软件开发周期就被划分为很多阶段,如制订计划、需求分析和定义、软件设计、程序编写、软件测试、运行和维护等,还提出了很多软件开发模型作为这些阶段行为参考。关于这方面的资料非常多,这里不理论教条化的对这些内容讨论,只是结合工作经验,从软件定义、软件开发和软件维护三个角度简短的谈些自己的看法。

2.2.1软件定义

这个阶段主要就是通过需求分析来确定最终做出怎么样的一个软件产品,是至关重要的。项目组应该做到:

1、全员参与,不仅仅是项目经理和需求分析人员,包括编码、测试人员等

都要参与进来。比如需求分析人员由于技术专业不理想,根据用户需求

设计的软件定义没有考虑到某个技术障碍,导致编码人员在开发过程中

不可逾越,临时调整方案不但极大降低质量、还严重的影响了项目进度。

2、给该阶段预留更多的时间,不厌其烦的与客户沟通。隔行如隔山,用户

与开发人员之间的交流很难。有时候用户很难明确的提出他的需求,这

时候就需要项目分析人员理解并牵引。有时候用某些需求用户也提不出,直道编码甚至维护阶段才提出来,分析人员应该做出足够的思考,以便

软件定义时候预留相应的接口。

2.2.2软件开发

这个阶段主要完成概要设计、详细设计、编码及测试。最重要的莫过于概要设计时合理的划分功能模块了。划分模块原则如下:

相关文档
最新文档