当前位置: 首页icon 软考首页 > >总线 软考 总线开发与测试

总线 软考 总线开发与测试

作者:mb62147e277964a2024-01-19 01:00:03
备考咨询 刷题指导
添加专属学姐
下载资料 2024上半年软考备考资料+考试大纲
下载按钮 下载
引号

1. 需求管理在进入正式开发之前,必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。在软件项目的开发过程中,需求变更贯穿了软件项目的整个生命周期,从软件的项目立项,研发,维护,用户的经验在增加,对使用软件的感受有变化,以及整个行业的新动态,都为软件带来不断完善功能 ,优化性能,提高用户友好性的要求。在软件项目管理过程中,项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更,项目

引号

1. 需求管理

在进入正式开发之前,必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。在软件项目的开发过程中,需求变更贯穿了软件项目的整个生命周期,从软件的项目立项,研发,维护,用户的经验在增加,对使用软件的感受有变化,以及整个行业的新动态,都为软件带来不断完善功能 ,优化性能,提高用户友好性的要求。在软件项目管理过程中,项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更,项目计划会一再调整,软件交付日期一再拖延,项目研发人员的士气将越来越低落,将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。

在整个开发周期中期望用户的需求一直保持不变是不大可能的,因为用户对于如何应用计算机软件并没有一个成熟的经验。需求变化的原因很多,如:

一开始没有调研全,需要增加需求;

客户需求发生了变化,需求必须变化;

需求错误;

需求不清楚。

基于上述的问题,必须对需求进行管理,使需求能够真正成为软件工程和管理的基线。 一种比较明智的方法是在签定开发合同(协议)时把用户需求的改动和经济利益挂钩,如果用户增加或改动了需求,那么软件的交付日期可以推迟,费用也应增加。

需求是一项复杂的工作,使用的方法也很多,不同的开发方式有不同的方法,这里简单介绍一些相关的方法:

可行性分析:在允许的成本、性能要求下,分析每项需求实施的可行性,提出需求实现相关风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。

快速原型:当用户自身对有的需求不十分清楚时,我们可以建立一个系统原型,用户通过评价原型更好地理解所要解决的问题。

图形分析模型:绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系,找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

数据字典:数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项,确保客户与开发小组是使用一致的定义和术语。

2. 设计管理

项目经理把功能模块分配给每个开发人员,每个开发人员把自己相关的功能模块收集起来,同时预估时间,其中主要包括写文档的时间、开发时间和单元测试的时间,一般要求精确到工作日。这些信息返回给项目经理,项目经理再把本小组人员的任务和预估时间发送给管理层,由管理层对此任务及进度进行评估审核,管理层会根据产品发布时间及客户需求、市场因素等方面作出选择,可能某些功能由于时间紧急会被推迟到下一个版本中去。若预估出来的时间同预计的产品发布时间有较大冲突,而且此功能是本版本中必须得做的,则开发小组会被要求重新预估时间,加快开发速度来达到这个要求。

虽然这个开发进度时间是一个大概的估计时间,但我们要尽力按照这个开发进度来执行。作为开发人员每个星期写一篇周记,描述自己本周所做的工作,根据自己的描述来评估我们自己的工作,每个人手上的工作是否按照这个进度在走,是否有人延后了,是否延误了别人的工作。在周记里每个人都要报告自己的进度,同时还要报告上个星期做了什么,正在做什么,以及下个星期打算做什么。通过这个周记,会让你觉得有人在监督你,无形之中迫使你不断地督促自己不要使任务延后,如果有延后的迹象也会尽早发现而赶上。若某些经过努力不能赶上,那也没有办法,只能修改原先的进度表,因为那是我们的估计与现实发生了偏差,我们必须使我们的进度表符合实际情况。

3. 编码管理

进入编码工作之后,可能会发现前面分析或设计阶段的某些错误,这时应返回到前面的阶段进行必要的修改。由于我们用asp.net(c#)语言进行开发,因此我们借助了VS2005工具。关于代码风格,我们基本上套用VS2005中自动的代码格式编排。良好的编码习惯有利于我们提高整个团对的开发效率,比如变量的命名、写代码时要对类及函数提供详细的注释及说明等,基本做到看它们的说明就能知道这个变量、类或函数的功能以及主要算法的实现原理。在开发过程中对主要的模块要编写单元测试,同时要单元测试先行,当所有的单元测试代码通过时,此功能也就基本上完成了。

我们采用VSS进行代码管理控制,其中存放了此产品的所有源代码,各个部分存放在不同的目录中。每天早上要求开发人员从VSS中获取最新的源代码,然后进行编译并开始一天的工作。在下班之前理论上要求员工签入所有当天修改的代码,在签入之前要保证编译是能通过的。若有谁签入的代码导致运行失败则会被要求某些惩罚措施或警告。有时我们编写的代码涉及到多个文件,而且此改动是比较复杂需要花费多天的工作量,如果现在签入进去可能会导致项目测试通不过,因为有些代码没有完全完成,而之前的代码能测试通过,而且这些代码基本上不会涉及到他人,在这种情况下可以不签入进去,直到全部代码完成能提交测试时再一起签入进去。

我们的开发是基于网络的,在互联网高速发展的今天,代码的安全也是一个不容忽视的问题,我们要注意代码的泄漏和丢失,除了掌握一些基本的安全知识以外,还要进行代码的备份(局域网备份和存储设备备份),这样在出现意外的情况下可以及时的恢复系统的正常运行。

4. 测试管理

在开发人员完成了功能模块后,测试人员开始了测试规划,确定需要测试哪些方面,如何测试及进度安排。测试人员需要写许多测试用例、测试报告等,有些测试代码需要集成测试,有些可能需要进行单独的测试,目的都是为了使产品符合要求,使开发人员容易找出问题所在并改正。产品功能是否符合了要求,是否能被发布是由测试人员决定的,因此测试人员也比较辛苦,责任重大。通过了每天的测试,还有一些性能测试、兼容性测试、灾难测试等需要在产品发布前进行。在完成这些测试之后由测试人员决定本产品是否能发布出去了。

由于我们每天进行着测试,因此经常有BUG被测试人员发现,一旦发现了新的BUG,就会被添加进测试报告中,同时注明紧急程度,以便开发人员可以及时进行错误BUG的修改。需要指出的是我们对BUG的定义比较广泛,一些新功能也可以作为BUG被提出,只不过这些BUG级别比较低,让它们进入到下一个版本中去实现。因此BUG的创建者也可以是技术支持人员、市场人员甚至开发人员本身。关于开发人员本身,因为他可能会找出一些BUG,有些是其他开发者的,有些可能是此开发者本身的,把这个BUG添加进测试报告中可以帮助开发人员在以后产生新问题时或类似的BUG时有一个借鉴和思路。

5. 维护管理

后期的软件维护和管理也是一个非常重要的任务。定期的升级服务和培训会让客户对软件有个良好的映像。

6. 组织(团队)管理

软件项目开发过程中注重的是团队精神的发挥,我们的目标是一个软件、系统而不是几个模块的简单组合。在软件开发管理中,不能采用明令制度的方式来要求何限制开发人员,必须要有办法激励人的内动力,而激励人的内动力最好的办法是将付出和收益紧密的结合。团队精神的凝聚主要的是信任与尊重。正所谓“用人不疑,疑人不用”,如果没有基本的尊重与信任,哪里来的凝聚力,何谓团队精神?

软件项目开发人员应该本着态度第一、效率优先的工作原则,在平时的日常工作和生活中,大脑的休息和充足的睡眠可以保证开发人员有个良好的心态和精力。也许在IT行业来说,程序员加班已经成为一种佳话,一种习俗,但我们要制止长期的加班和无效率的加班,在项目不紧张或者无项目的情况下可以适当的放松、休息来调节个人的情绪和精力。

作为软件开发人员的大部分时间是在公司里度过的,因此公司的生活成了大家主要组成部分。员工之间关系的融洽,交流的畅通显得非常重要,同时大家也不想自己的生活这样枯燥乏味,一直同机器打交道。沟通无处不在,交流随时发生,有许多关系是在工作之外建立起来的。软件公司内是很容易产生各种矛盾的,因为这是由你的工作性质所决定的,比如测试人员或用户会对你的实现不满意,提出各种要求时,我相信你有时会有所抱怨的,无形之中就产生了对立,发展到后来会有抵触心理。我相信大部分人都会有此感受,这不是你的错,这主要是由我们的工作性质决定的。如果你的工作是把财富带给对方,则对方会非常欢迎你的到来,把你奉为财神爷来对待,同你的关系会非常融洽友好。因此我们需要在工作之外来消除这种对立矛盾的关系,建立一种融洽的工作氛围。我们在平时吃饭的时候饭桌上大家互相聊天沟通,说一些幽默笑话之类的,给我们紧张的工作增加点轻松的氛围。隔断时间大家可以组织一下活动,增加了公司的凝聚力。一个产品发布后组织一次活动,让绷紧的神经松弛一下,更好地迎接下一个挑战。

团队的每个成员都会养成写Blog的习惯。经常写写Blog,一是可以让大家都知道自己在做什么事情,二是项目结束时方便写最后的工作总结(许多工作自己当时不纪录也忘记了),三是利于提高自己的水平(工作和学习写点总结会系统的总结和归纳思路,进步很快)。

代理合作学习群