开题报告-项目控制软件的设计与实现

1、毕业设计（论文）材料之二（2）本科毕业设计（论文）开题报告题目：项目控制软件的设计与实现Design and Implementation of Project Control 课 题 类 型：设计 实验研究 论文学 生 姓 名： 杨 芳 文 学 号： 3070701320 专 业 班 级： 计算机081班学 院： 计算机与信息学院 指 导 教 师： 王 勇开 题 时 间： 2012年 2月2012 年 2月 16日一、本课题的研究意义、研究现状和发展趋势随着互联网的发展，以及Web 2.0概念的逐步为大众所接受，各种以“用户生成内容 (User Generated Content, UGC)

2、”为核心理念、强调个人之间的互联与分享、建立在良好的用户体验上的新一代网站如雨后春笋涌现出来。其中，以“软件即服务(Software as a Service, SaaS)”为主导理念的网站是比较特别的一支。软件即服务倡导的是将软件部署为托管服务并通过 互联网进行访问，也就是我们通常听到的把桌面软件网络化。由此，各种基于Web的项目控制软件应运而生。项目控制的作用就是为了保证项目按照预期的项目目标进行，必须对项目的运行情况和输出进行持续的跟踪监控，收集各种项目进展信息，对收集的信息进行分析，与预期的项目目标进行比较。在出现偏差时及时分析偏差原因，制定有效的纠正预防措施，落实纠正预防措施。项目的

3、特点是渐进明晰的，特别地软件开发项目更因为其结果的无形性、需求难以明确性、劳动密集性和智力密集性，“渐进明晰”这一特点更加显著。在项目的初期，项目经理或项目成员基本上不可能像建设一栋有形的建筑一样，预想出项目实施过程中的所有情况（对于建筑行业来说，不可预见的主要是一些不可抗力，如天气、人员的流失、供货的及时性）。所以，尽管已经尽可能明确制定了项目目标，并以此为目标制定了尽可能周密的计划，如果没有对照项目计划进行严密的监控，并及时调整计划，不断使计划明晰化并符合实际，以尽可能地保证项目按照基准计划实施，并使计划的变更尽可能地减少，那么项目就很难达到原先计划中制定的目标。这些目标要同时兼顾进度、质

4、量、成本。 所以不仅要制定出好的项目计划，更要进行严密的项目控制。项目控制是项目经理的一项重要职责，也是项目控制部门、项目成员、项目干系人的重要职责。 项目控制是IT行业的一个富有创新意义的领域，是针对特定的项目需求，以团队运作的形式，有效地组织项目资源，通过对项目的管理和控制，实现项目的目标。在我国IT行业起步较晚，但发展迅速，项目控制在IT行业的应用还很不成熟，一般的、常规的组织管理方式已很难适应，这是软件开发中项目控制面临的最大挑战。在项目实施中往往会出现如下问题：1、对项目控制认识和重视不够项目经理或管理人员不十分了解项目控制的知识体系，所以在实际工作中没有项目控制知识的指导，完全依靠

5、个人现有的知识技能，管理工作的随意性、盲目性比较大。在软件企业中，项目经理主要是因为他们能够在技术上独当一面，而管理方面特别是项目控制方面的知识比较缺乏。希望尽快推行和实施软件项目经理知识技能资格制度，各方面都能充分认识项目控制的重要性，让项目经理自觉学习项目控制的知识和一些常用工具和方法。2、对项目的系统性把握不够在软件企业一些项目控制人员对项目总体计划、阶段计划的作用认识不足。项目经理认为计划不如变化快，项目中也有很多不确定的因素，做计划是走过场，因此制定总体计划时比较随意，造成计划与控制管理脱节，无法进行有效的进度控制管理。其实制定计划的过程就是一个对项目逐渐了解掌握的过程，通过认真地制

6、定计划，项目控制人员可以知道哪些要素是明确和重要的，哪些要素是要逐渐明确和次要的，通过渐近明细不断完善项目计划。制定计划的过程，也是在进度、资源、范围之间寻求一种平衡的过程。因此，提高项目控制人员的计划意识，加强对开发计划、阶段计划的有效性，并进行事前事后的评估。3、管理思想贯彻不到位 项目经理如果没有从总体上去把握管理整个项目，而是埋头于具体的技术工作，造成项目组成员之间任务不均、资源浪费。在软件企业中，项目经理大多是技术骨干，技术方面的知识比较深厚，但无论是项目控制知识，还是项目控制必备的技能、项目控制必备的素质都有待补充和提高。同时由于工作分解结构设计的缺乏合理性，项目任务无法有效、合理

7、地分配给相关成员，以达到“负载均衡”。因此加强项目经理在项目控制知识方面的培训和考核，引导项目经理更好地做好项目控制工作。 4、沟通的效率不高在项目中一些重要信息没有进行充分和有效的沟通。在制定计划、意见反馈、情况通报、技术问题或成果等方面与相关人员的沟通不足，造成各做各事、重复劳动，甚至造成不必要的损失。在项目沟通管理方面：管理者要用70的时间用于与人沟通，而项目经理需要花费90或更多的时间来沟通。所以项目控制人员不但自己要把工作重点放在沟通上，而且要善于沟通，以提高沟通意识和沟通的效率。5、对付风险的策略不成熟 项目控制人员没有充分分析可能的风险，对付风险的策略考虑比较简单。有些项目控制人

8、员没有充分意识到风险管理的重要性，对计划书中风险管理的章节简单应付了事，随便列出几个风险和一些简单的对策，对于后面的风险防范起不到一定指导作用。项目风险管理是对项目潜在的意外损失进行规划、识别、估计、评价、应对和监控的过程，是对项目目标的主动控制手段。因此通过学习项目控制知识，掌握风险识别、量化、对策研究、反应控制的工具和方法，加强对项目规划中风险管理计划的审核，提高项目组的风险管理意识。以上对软件开发项目控制中容易出现的问题的分析可能还不够深入，无法列举所有遇到或将遇到的问题，解决办法也只能在际情况中把握。 我国的许多软件企业按项目方式运作已有多年，在这期间，我国软件企业进行了不懈地探索，有

9、成功的经验，也有失败的教训，其中主要体现在以下几个方面： 1、客户满意作为项目控制的最终目标 客户是项目的委托方，也是项目的受用方，如何使客户对项目的最终结果感到满意，是项目控制的一个核心问题。为让客户满意项目组要树立以客户为中心的观念，项目控制的整个生命周期都要面向客户，并把客户满意度作为衡量项目成败的一个重要指标，使项目组的利益与客户的利益紧密地联系在一起。项目的需求就是客户的需求，它应包括客户的现实需求和潜在需求。信息技术的迅速发展，导致IT行业客户需求的多样性、多变性、不确定性和个性化。软件产品或解决方案需要企业与客户在充分沟通的基础上，共同提取、挖掘，从而不断逼近客户的真正需求，客户

10、与企业之间体现出很强的互动性。2项目控制要面向结果，首先要面向人 项目控制要以人为本，项目经理首先是人力资源经理，对于知识密集型的软件企业来说，尤其如此。通过项目为员工提供平台，通过员工的发展目标与项目目标的有机结合，使员工在项目的平台上实现自我的价值。3项目控制的挑战性和推动力项目控制的实施，特别是全面推行项目控制，对于软件企业而言，不是一改变，而是一种变革，是一项长期性、艰巨性的任务。因此，企业首先要有开放的心态，要勇于改革，并能以长远的眼光和勇气正确对待项目开发中出现的问题，不因暂时的困难和挫折而放弃。其次要有务实的态度，要有相应的措施和落实的力度，推动项目的进程和开发效率的提高。 目前

11、，我国软件开发和项目控制水平与美国、印度等国家相比还不高。而国外水平比较高的软件公司软件开发流程和项目控制十分规范，随着世界范围软件业的发展，在我国已有越来越多的软件公司重视流程和项目控制，软件业的春天一定会来临。二、研究方案及工作计划设计目标：搭建一个在线项目管理协作平台，方便项目负责人对于项目的规划、管理、任务分配和整体的把握，成员之间协作、沟通、分享资料和互相通知，以适应项目和团队的快速变化和远程协作。功能描述：在线项目控制系统是部署于WEB服务器上的B/S架构应用系统。系统用户可以使用设定的帐号登录系统。系统提供项目管理、人员管理、任务列表和消息板功能。由项目管理员创建或是添加项目，添

12、加邀请项目成员加入到相应的项目中，查看项目信息以及结束项目。 在人员管理功能模块下项目管理员可以添加用户，修改用户基本信息，给用户赋角色查看用户信息，按角色查看用户。 任务列表模块则可以对任务进行管理，如新建任务列表，在任务列表下添加任务，将任务分配给某个成员，设置任务的优先级，设置任务的为完成，对任务进行评论，按任务所有者过滤任务。 消息板模块主要是实现成员间交流共享信息。成员可以发送消息，并选择通知的成员，添加消息类别，添加消息评论，按类别查看消息。应用系统角色和用户：在线项目控制系统的角色分为部门经理、项目经理、小组长、项目成员。系统包括各功能模块如表1所示：表1 功能模块说明模块名称子

13、模块功能描述项目管理 申请项目申请启动一个项目项目审核高层决定是否启动项目添加项目添加一个新项目结束项目 将一个项目设置为终结 查看项目信息查看项目完成情况，项目内容 邀请成员 邀请成员加入到项目中 人员管理 查看用户信息查看已存在用户信息用户信息维护修改用户信息添加用户 添加新用户给用户赋角色 对已存在用户赋予角色 分角色查看用户 按不同的角色查看用户 任务列表 新建任务列表 创建一个新的任务列表到项目中 在任务列表中添加任务 在任务类表中添加任务 设置任务优先级 对任务设置优先级 设置任务完成对任务进行评论 分配任务 分配任务给成员消息板添加消息类别 添加消息 选择消息通知成员选择Emai

14、l通知 按类别查看消息 发表消息评论 针对该项目的任务量和完成时限，具体工作计划如下：周次任务说明第1周查阅资料，了解课题收集和阅读相关资料文献，确定相关开发技术第2周第3周撰写开题报告第4周第5周需求分析完成用例图、数据流图、数据字典、ER图等相关内容。第6周第7周概要设计完成系统总体功能设计、数据库设计第8周第9周详细设计完成后台编码设计和前台页面设计，对每个模块进行单元测试第10周第11周第12周第13周测试与优化完善、优化系统，对项目进行集成测试，使系统工作在最佳状态第14周第15周第16周撰写毕业设计论文第17周第18周准备答辩和答辩第19周三、主要参考文献1 罗铁清,王莹,王如龙.

15、 软件项目管理流程分析与设计J. 计算技术与自动化,2005,(03)2 朱利娜,周宁. 软件项目管理的思考J. 平原大学学报,2007,(02)3 杨智明. 软件项目管理过程J. 科教文汇(下半月),2006,(09)4 陆伟. 软件项目管理及其在中小规模开发中的实施J. 电脑知识与技术, 2005,(08)5 郭国印,张秀伟,赵政文. 软件项目管理技术分析研究J. 微处理机,2007,(05)6 周慧. 论软件项目管理J. 现代电子技术,2003,(18)7 邓杰超. 软件项目管理探析J. 华南金融电脑,2007,(01)8 窦燕. 影响软件项目管理关键因素的探讨J. 燕山大学报,2004

16、,(04)9 李凌. 软件项目管理中的进度控制问题研究J. 中国科技信息,2005,(17) 10 陈丽杰. 浅析软件项目管理中的需求管理J. 科技资讯, 2007,(14)11 席相霖.解析项目管理J.中国计算机用户,2002,(11)12 武映峰.项目管理全接触J.软件工程师,2002,(04)13 Johanna Rothman. Manage It!M. 人民邮电出版社,200914 Frederick P.Brooks.Jr. The Mythical Man-Month. 清华大学出版社,2007外文文献选译The Mythical Man-MonthGood cooking fa

17、kes time. If you are made to wait, it is to serve you better, and to please you.MENU OF RESTAURANT ANTOINE. NEW ORLEANSMore software projects have gone awry for lack of calendar timethan for all other causes combined. Why is this cause of disaster so common?First, our techniques of estimating are po

18、orly developed. More seriously, they reflect an unvoiced assumption which is quite untrue,i.e., that all will go well.Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.Third, because we are uncertain of our esti

19、mates, software managers often lack the courteous stubbornness of Antoine's chef.Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.Fifth, when schedule slippage is recognized, t

20、he natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster.Schedule monitoring will be the subject of a separate essay.Let us consider

21、 other aspects of the problem in more detail.OptimismAll programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy godmothers.Perhaps the hundreds of nitty frustrations drive away allbut those who habitually focus on the end goal. Perhaps

22、 it ismerely that computers are young, programmers are younger, andthe young are always optimists. But however the selection processworks, the result is indisputable: "This time it will surely run," or"I just found the last bug."So the first false assumption that underlies the sc

23、heduling of systems programming is that all will go well, i.e., that each task will hike only as long as it "ought" to take.The pervasiveness of optimism among programmers deserves more than a flip analysis. Dorothy Sayers, in her excellent book,The Mind of the Maker, divides creative acti

24、vity into three stages:the idea, the implementation, and the interaction. A book, then,or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mindof the author. It is realized in time and space, by pen, ink, andpaper, or by wir

25、e, silicon, and ferrite. The creation is completewhen someone reads the book, uses the computer, or runs theprogram, thereby interacting with the mind of the maker.This description, which Miss Sayers uses to illuminate notonly human creative activity but also the Christian doctrine of the Trinity, w

26、ill help us in our present task. For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. Thus it is that writing,experimentation, "working out" are essential disciplines for the theoretician.In many creative activities

27、the medium of execution is intractable.Lumber splits; paints smear; electrical circuits ring. These physical limitations of the medium constrain the ideas that may be expressed, and they also create unexpected difficulties in theimplementation.Implementation, then, takes time and sweat both because

28、of the physical media and because of the inadequacies of the underlying ideas. We tend to blame the physical media for most of our implement-tation difficulties; for the media are not "ours" in the way the ideas are, and our pride colors our judgment.Computer programming, however, creates

29、with an exceedingly tractable medium. The programmer builds from pure thought-stuff: concepts and very flexible representations thereof.Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we have bugs; hence our o

30、ptimism is unjustified.In a single task, the assumption that all will go well has a probabilistic effect on the schedule. It might indeed go as planned.for there is a probability distribution for the delay that will be encountered, and "no delay" has a finite probability. A large programmi

31、ng effort, however, consists of many tasks, some chained end-to-end. The probability that each will go well becomes vanishingly small.The'Man-MonthThe second fallacious thought mode is expressed in the very unit of effort used in estimating and scheduling: the man-month. Cost does indeed vary as

32、 the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.Men and months are interchangeable commodities only when a task can be pa

33、rtitioned among many workers with no communication among them (Fig. 2.1). This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.Fig. 2.1 Time versus number of workersperfectly partitionable taskWhen a task cannot be partitioned because of sequentia

34、l constraints,the application of more effort has no effect on the schedule(Fig. 2.2). The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have thischaracteristic because of the sequential nature of debugging.Fig. 2.2 Time versus number of workersunpar

35、titionable taskIn tasks that can be partitioned but which require communication among the subtasks, the effort of communication must be added to the amount of work to be done. Therefore the best that can be done is somewhat poorer than an even trade of men for months (Fig. 2.3).Fig. 2.3 Time versus

36、number of workerspartitionable task requiring communicationThe added burden of communication is made up of two parts,training and inter- communication. Each worker must be trained in the technology, the goals of the effort, the overall strategy, and theplan of work. This training cannot be partition

37、ed, so this part ofthe added effort varies linearly with the number of workers.1Intercommunication is worse. If each part of the task must be separately coordinated with each other part/ the effort increases as n(n-I)/2. Three workers require three times as much pairwiseintercommunication as two; fo

38、ur require six times as much as two.If, moreover, there need to be conferences among three, four, etc.,workers to resolve things jointly, matters get worse yet. The addedeffort of communicating may fully counteract the division of theoriginal task and bring us to the situation of Fig. 2.4.Fig. 2.4 T

39、ime versus number of workerstask with complex interrelationshipsSince software construction is inherently a systems effortanexercise in complex interrelationshipscommunication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more me

40、n then lengthens, not shortens, the schedule.Systems TestNo parts of the schedule are so thoroughly affected by sequential constraints as component debugging and system test. Furthermore,the time required depends on the number and subtlety of the errors encountered. Theoretically this number should

41、be zero.Because of optimism, we usually expect the number of bugs to be smaller than it turns out to be. Therefore testing is usually the most mis-scheduled part of programming.For some years I have been successfully using the following rule of thumb for scheduling a software task:l/3 planningl/6 co

42、dingl/4 component test and early system testl/4 system test, all components in hand.This differs from conventional scheduling in several importantways:1. The fraction devoted to planning is larger than normal. Even so, it is barely enough to produce a detailed and solid specification,and not enough

43、to include research or exploration of totally new techniques.2. The half of the schedule devoted to debugging of completed code is much larger than normal.3. The part that is easy to estimate, i.e., coding, is given only one-sixth of the schedule.In examining conventionally scheduled projects, I hav

44、e found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose. Many of these were on schedule until and except in system testing.2Failure to allow enough time for system test, in particular, is peculiarly disastro

45、us. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date. Bad news, late and without warning, is unsettling to customers and to managers.Furthermore, delay at this point has unusually severe financial,as well as psychological, repercuss

46、ions. The project is fully staffed, and cost-per-day is maximum. More seriously, the software is to support other business effort (shipping of computers, operation of new facilities, etc.) and the secondary costs of delaying these are very high, for it is almost time for software shipment.Indeed, th

47、ese secondary costs may far outweigh all others. It is therefore very important to allow enough system test time in the original schedule.Gutless EstimatingObserve that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot gover

48、n the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choiceswait or eat it raw. Software customers have had the same choices.The cook has another choice; he can turn up the heat. The result is

49、 often an omelette nothing can saveburned in one part, raw in another.Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers.But false scheduling to match the patron's desired date ismuch more common in our discipline than els

50、ewhere in engineering.It is very difficult to make a vigorous, plausible, and jobriskingdefense of an estimate that is derived by no quantitativemethod, supported by little data, and certified chiefly by thehunches of the managers.Clearly two solutions are needed. We need to develop and publicize pr

51、oductivity figures, bug-incidence figures, estimating rules, and so on. The whole prof ession can only profit from sharing such data.Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches

52、are better than wishderived estimates.Regenerative Schedule DisasterWhat does one do when an essential software project is behind schedule? Add manpower, naturally. As Figs. 2.1 through 2.4 suggest, this may or may not help.Let us consider an example.3 Suppose a task is estimated at 12 man-months an

53、d assigned to three men for four months, and that there are measurable mileposts A, B, C, D, which are scheduled to fall at the end of each month (Fig. 2.5).Now suppose the first milepost is not reached until two months have elapsed (Fig. 2.6). What are the alternatives facing the manager?1. Assume

54、that the task must be done on time. Assume that only the first part of the task was misestimated, so Fig. 2.6 tells the story accurately. Then 9 man-months of effort remain, and two months, so 4V£ men will be needed. Add 2 men to the 3 assigned.2.Assume that the task must be done on time. Assum

55、e that the whole estimate was uniformly low, so that Fig. 2.7 really describes the situation. Then 18 man-months of effort remain,and two months, so 9 men will be needed. Add 6 men to the assigned.Figure 2.5Figure 2,6Figure 2.73.Reschedule. I like the advice given by P. Fagg, an experienced hardware

56、 engineer, "Take no small slips." That is, allow enough time in the new schedule to ensure that the work can be carefully and thoroughly done, and that rescheduling will not have to be done again.4.Trim the task. In practice this tends to happen anyway, once the team observes schedule slip

57、page. Where the secondary costs of delay are very high, this is the only feasible action.The manager's only alternatives are to trim it formally and carefully, to reschedule, or to watch the task get silently trimmed by hasty design and incomplete testing.In the first two cases, insisting that t

58、he unaltered task be completed in four months is disastrous. Consider the regenerative effects, for example, for the first alternative (Fig. 2.8). The two new men, however competent and however quickly recruited, will requiretraining in the task by one of the experienced men. If this takes a month, 3 man-months will have been devoted to work not in the original estimate. Furthermo