校园论坛软件工程设计报告(软件工程设计报告案例)

2023-04-02 06:39:02舞蹈060

今天给各位分享校园论坛软件工程设计报告的知识，其中也会对软件工程设计报告案例进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

1、一个软件的设计总结报告一般加些什么参考资料
2、国标软件开发设计报告,或软件开发技术报告的模板
3、软件工程开题报告范文
4、求软件工程课程设计一份

一个软件的设计总结报告一般加些什么参考资料

分析一下需求的具体内容：·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系客户的需求观客户与开发人员交流需要好的 *** 。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。1、分析人员要使用符合客户语言习惯的表达需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。2、分析人员要了解客户的业务及目标只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。3、分析人员必须编写软件需求报告分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决 *** 和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。4、要求得到需求工作结果的解释说明分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。5、开发人员要尊重客户的意见如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。6、开发人员要对需求及产品实施提出建议和解决方案通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决 *** 中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进 *** ，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。7、描述产品使用特性客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。8、允许重用已有的软件组件需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。9、要求对变更的代价提供真实可靠的评估有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。10、获得满足客户功能和质量要求的系统每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。11、给分析人员讲解您的业务分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。12、抽出时间清楚地说明并完善需求客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。13、准确而详细地说明需求编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的更佳人选，否则，就只好靠开发人员去正确猜测了。在需求分析中暂时加上“待定”标志是个 *** 。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。14、及时作出决定分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理 *** 或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。15、尊重开发人员的需求可行性及成本评估所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。16、划分需求的优先级绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。17、评审需求文档和原型客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。18、需求变更要立即联系不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。19、遵照开发小组处理需求变更的过程为将变更带来的负面影响减少到更低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。20、尊重开发人员采用的需求分析过程软件开发中更具挑战性的莫过于收集需求并确定其正确性，分析人员采用的 *** 有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。“需求确认”意味着什么在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确 *** ，所以我们必须明白签字意味着什么。对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。参考资料： *** 收集

国标软件开发设计报告,或软件开发技术报告的模板

软件开发环境(Software Development Environment，SDE)是指在基本硬件和宿至软件的基础上，为支持系统软件和应用软件的工程化开发和维护而使用的一组软件，简称SDE。它由软件工具和环境集成机制构成，前者用以支持软件开发的相关过程、活动和任务，后者为工具集成和软件的开发、维护及管理提供统一的支持。

SDE在欧洲又叫集成式项目支援环境（Integrated Project Support Environment，IPSE）。

软件开发环境的主要组成成分是软件工具。人机界面是软件开发环境与用户之间的一个统一的交互式对话系统，它是软件开发环境的重要质量标志。存储各种软件工具加工所产生的软件产品或半成品（如源代码、测试数据和各种文档资料等）的软件环境数据库是软件开发环境的核心。工具间的联系和相互理解都是通过存储在信息库中的共享数据得以实现的。

软件开发环境数据库是面向软件工作者的知识型信息数据库，其数据对象是多元化、带有智能性质的。软件开发数据库用来支撑各种软件工具，尤其是自动设计工具、编译程序等的主动或被动的工作。

较初级的SDE数据库一般包含通用子程序库、可重组的程序加工信息库、模块描述与接口信息库、软件测试与纠错依据信息库等；较完整的SDE数据库还应包括可行性与需求信息档案、阶段设计详细档案、测试驱动数据库、软件维护档案等。更进一步的要求是面向软件规划到实现、维护全过程的自动进行，这要求SDE数据库系统是具有智能的，其中比较基本的智能结果是软件编码的自动实现和优化、软件工程项目的多方面不同角度的自我分析与总结。这种智能结果还应主动地被重新改造、学习，以丰富SDE数据库的知识、信息和软件积累。这时候，软件开发环境在软件工程人员的恰当的外部控制或帮助下逐步向高度智能与自动化迈进。

软件实现的根据是计算机语言。时至今日，计算机语言发展为算法语言、数据库语言、智能模拟语言等多种门类，在几十种重要的算法语言中，CC++语言日益成为广大计算机软件工作人员的亲密伙伴，这不仅因为它功能强大、构造灵活，更在于它提供了高度结构化的语法、简单而统一的软件构造方式，使得以它为主构造的SDE数据库的基础成分——子程序库的设计与建设显得异常的方便。

事实上，以CC++为背景建立的SDE子程序库能为软件工作者提供比较有效、灵活、方便、友好的自动编码基础，尤其是C++的封装等特性，更适合大项目的开发管理和维护。

软件开发环境可按以下几种角度分类：

(1)按软件开发模型及开发 *** 分类，有支持瀑布模型、演化模型、螺旋模型、喷泉模型以及结构化 *** 、信息模型 *** 、面向对象 *** 等不同模型及 *** 的软件开发环境。

(2)按功能及结构特点分类，有单体型、协同型、分散型和并发型等多种类型的软件开发环境。

(3)按应用范围分类，有通用型和专用型软件开发环境。其中专用型软件开发环境与应用领域有关，故又软件开发 *** (Software Development Method)是指软件开发过程所遵循的办法和步骤。软件开发活动的目的是有效地得到一些工作产物，也就是一个运行的系统及其支持文档，并且满足有关的质量要求。软件开发是一种非常复杂的脑力劳动，所以经常更多讨论的是软件开发 *** 学，指的是规则、 *** 和工具的集成，既支持开发，也支持以后的演变过程(交付运行后，系统还会变化，或是为了改错，或是为了功能的增减)。

关于组成软件开发和系统演化的活动有着各种模型(参见软件生存周期，软件开发模型，软件过程)，但是典型地都包含了以下的过程或活动：分析、设计、实现、确认(测试验收)、演化(维护)。

有些软件开发 *** 是专门针对某一开发阶段的，属于局部性的软件开发 *** 。特别是软件开发的实践表明，在开发的早期阶段多做努力，在后来的测试和维护阶段就会使费用较大地得以缩减。因此，针对分析和设计阶段的软件开发 *** 特别受到重视。其它阶段的 *** ，从程序设计发展的初期起就是研究的重点，已经发展得比较成熟(参见程序设计，维护过程)。除了分阶段的局部性软件开发 *** 之外，还有覆盖开发全过程的全局性 *** ，尤为软件开发 *** 学注意的重点。

对软件开发 *** 的一般要求：当提出一种软件开发 *** 时，应该考虑许多因素，包括：①覆盖开发全过程，并且便于在各阶段间的过渡；②便于在开发各阶段中有关人员之间的通信；③支持有效的解决问题的技术；④支持系统设计和开发的各种不同途径；⑤在开发过程中支持软件正确性的校验和验证；⑥便于在系统需求中列入设计、实际和性能的约束；⑦支持设计师和其他技术人员的智力劳动；⑧在系统的整个生存周期都支持它的演化；⑨受自动化工具的支持。此外，在开发的所有阶段，有关的软件产物都应该是可见和可控的；软件开发 *** 应该可教学、可转移，还应该是开放的，即可以容纳新的技术、管理 *** 和新工具，并且与已有的标准相适应可称为应用型软件开发环境。

⑷按开发阶段分类，有前端开发环境(支持系统规划、分析、设计等阶段的活动)、后端开发环境(支持编程、测试等阶段的活动)、软件维护环境和逆向工程环境等。此类环境往往可通过对功能较全的环境进行剪裁而得到。软件开发环境由工具集和集成机制两部分构成，工具集和集成机制间的关系犹如“插件”和“插槽”间的关系。

工具集：软件开发环境中的工具可包括：支持特定过程模型和开发 *** 的工具，如支持瀑布模型及数据流 *** 的分析工具、设计工具、编码工具、测试工具、维护工具，支持面向对象 *** 的OOA工具、OOD工具和OOP工具等；独立于模型和 *** 的工具，如界面辅助生成工具和文档出版工具；亦可包括管理类工具和针对特定领域的应用类工具。

集成机制：对工具的集成及用户软件的开发、维护及管理提供统一的支持。按功能可划分为环境信息库、过程控制及消息服务器、环境用户界面三个部分。

环境信息库：是软件开发环境的核心，用以储存与系统开发有关的信息并支持信息的交流与共享。库中储存两类信息，一类是开发过程中产生的有关被开发系统的信息，如分析文档、设计文档、测试报告等；另一类是环境提供的支持信息，如文档模板、系统配置、过程模型、可复用构件等。

过程控制和消息服务器：是实现过程集成及控制集成的基础。过程集成是按照具体软件开发过程的要求进行工具的选择与组合，控制集成并行工具之间的通信和协同工作。

环境用户界面：包括环境总界面和由它实行统一控制的各环境部件及工具的界面。统一的、具有一致视感(Look Feel)的用户界面是软件开发环境的重要特征，是充分发挥环境的优越性、高效地使用工具并减轻用户的学习负担的保证。

较完善的软件开发环境通常具有如下功能：

(1)软件开发的一致性及完整性维护；

(2)配置管理及版本控制；

(3)数据的多种表示形式及其在不同形式之间自动转换；

(4)信息的自动检索及更新；

(5)项目控制和管理；

(6)对 *** 学的支持。

校园论坛软件工程设计报告(软件工程设计报告案例),第1张

软件工程开题报告范文

一、课题的意义

选择一个适合的产品开发过程对于成功完成产品开发有着至关重要的作用。一个定义良好的过程，可以有效地指导和监控产品开发实践活动，提高产品开发的效率、质量和可预测性。但是，如果过程定义不合理，却会反过来制约我们的工作，导致挫折、低效、低质量甚至失败。

产品开发是一个多学科综合的过程。以消费电子产品为例，在产品开发过程中，软件、硬件、结构件和定制件等各个学科和专业小组的活动互相依赖、交叉并行。传统的产品开发过程往往采用串行、离散、重量级的 *** ，存在着以下问题：

串行的产品开发过程不能有效支持产品开发的迭代本质，项目的风险往往在后期集中爆发，导致项目进度失控或产品草率交付。

传统产品开发过程把各个学科和专业小组的活动视为一系列静态的、离散的过程，对于多学科交叉并行活动缺少有效综合与协调。

传统产品开发过程采用的重量级 *** 导致大量的文档工作和漫长的开发周期，难以快速交付高质量的产品。

随着产品的智能化、自动化和信息化程度越来越高，产品的功能和结构日趋复杂，其开发难度也不断增大。同时，技术和工艺水平的飞速提高，以及激烈的市场竞争导致产品的更新换代更加频繁，也使得开发时间日益缩短。在开发难度提高和开发时间缩短的双重压力下，传统的产品开发过程已经不能满足消费电子产品开发的需要。因此，建立一个高效的产品开发过程有着重大的意义。

二、国内外现状分析

为了解决传统串行的产品开发过程导致的产品设计改动量大、开发周期长、成本高、质量差等问题，人们提出了并行工程(Cocurret Egieerig)与集成产品和过程开发(Itegrated Product ad Process Developmet, IPPD)的思想，这些思想对于建立产品开发过程有着重要的指导意义。但是并行工程与IPPD本身并没给出具体的产品开发过程定义，尤其是对于产品开发的迭代本质和多学科交叉并行特性缺乏具体的过程 *** 予以支持。

在产品开发中，系统工程(Systems Egieerig)起着统领全局，综合、协调各个学科和专业小组的关键作用。对于产品开发过程 *** 的研究和实践，是系统工程的重要组成部分。在系统工程领域，现有的各种系统生命周期模型和系统工程过程模型从各个不同的方面对产品开发过程进行了描述，现有的重量级的产品开发过程大多数正是在这些模型的基础上建立起来的。但这些模型本身比较抽象化和一般化，不足以作为产品开发过程定义。同时，由于系统工程长期以来主要应用于大型/超大型系统(如武器系统、航天飞机等)，在应用这些模型进行产品过程定义时必须非常小心，否则容易产生过于重量级的过程。

反观软件工程(Sofare Egieerig)领域，对于软件开发过程的研究和实践近年取得了很大的进展，迭代开发正取代传统的瀑布模型逐渐成为软件过程 *** 的主流。基于迭代开发的产品化的软件开发过程——RUP的出现，标志着迭代开发 *** 的成熟。以迭代开发为核心的一批敏捷 *** (Agile Methods)，代表着软件开发过程研究和实践中极为活跃的部分。但是这些过程和 *** 主要关注于软件开发过程，对于其他学科的活动通常只是作为软件开发过程的外部环境加以考虑，而不是从全局上予以综合和协调。

产品开发、系统工程、软件工程3个领域的过程 *** 各有所长，但都满足不了消费电子产品开发过程的要求，尤其对于多学科综合的迭代开发 *** 都缺乏具体的解决方案。

三、研究目标和内容

本课题的研究目标是为消费电子产品建立一个能够有效支持产品开发迭代本质、有效综合与协调多学科交叉并行活动、轻量级的产品开发过程。

由于现有的过程 *** 都满足不了消费电子产品开发过程的要求，尤其对于多学科综合的迭代开发 *** 都缺乏具体的解决方案。因此，我们在综合产品开发、系统工程、软件工程等领域先进的过程 *** 的基础上，提出了一个适合于消费电子产品的、基于迭代开发 *** 的、多学科综合的开发过程——多学科集成迭代过程(Multidiscipliary Itegrated Iterative Process, MIIP)。在这里：

“多学科”是指MIIP能够有效综合与协调多学科交叉并行的开发活动;

“集成”有两方面的含义，一是MIIP在产品开发过程中集成了各个学科和专业小组的活动，二是MIIP在过程 *** 上集成了RUP、敏捷 *** 、系统工程、并行工程、IPPD等多种过程 *** 的先进思想和经典实践;

“迭代”是指MIIP基于迭代开发 *** 。

本课题的研究内容主要包括：

1. 分析消费电子产品开发的多学科集成迭代特征，并为之建立合适的过程;

2. 研究迭代过程在多学科交叉并行情况下存在的问题，并寻求解决方案;

3. 将多学科集成迭代过程应用到具体的项目中，在实践中检验和完善;

4. 总结多学科集成迭代过程应用的经验教训，为企业乃至整个行业的过程改进提供经典实践。

[注:一般研究内容3-6个，每个研究内容要展开来陈述一下]

四、关键技术研究

[注: 关键技术研究是指要解决的关键问题，不是要使用的主要技术]

多学科集成迭代过程(MIIP)以软件工程领域的RUP和敏捷 *** 为基础，将其扩展到系统工程领域，同时吸收了并行工程与IPPD的思想。MIIP的研究需要深入分析并解决好以下几个问题：

1. 消费电子产品开发过程具备什么样的过程特征?

2. 如何为消费电子产品开发过程建立合适的过程?

3. 对于消费电子产品，产品开发过程应具备什么程度的敏捷性?

4. 软件开发的迭代过程是否同样适用于硬件、结构件和定制件等其他学科的产品组件的开发?

5. 在多学科交叉并行的情况下如何进行迭代?

6. 各个学科如何在迭代之间进行协同?

7. 各个学科在独立并行和同步协调之间如何进行权衡?

8. 在实践中，产品开发如何实现从传统的串行过程到迭代过程的转变?

[注:关键问题3个以上，并建议每个问题要展开来陈述一下]

五、研究方案

本课题的研究 *** 主要包括：

1. 文献阅读：大量阅读文献，了解业界成熟的过程理论、经典实践和最新研究进展，建立充实的理论基础。

2. 过程资产分析：分析Z公司(一个大型的消费电子产品提供商)过程资产库中的现有过程定义文档，并将其与实际执行结果相比较。

3. 项目历史数据分析：分析Z公司项目历史数据，特别是项目计划、监控、度量结果和技术类工作产品，了解项目的实际执行过程。

4. 人员访谈：访谈Z公司项目经理、开发人员和过程改进人员，了解现有过程模型存在的问题及其根源和人们的期望。

5. 过程定义：在分析消费电子产品开发过程的特征之后，建立与之相适应的多学科集成迭代过程。

6. 讨论和评审：在新过程的设计过程中定期与相关专业人员进行讨论和评审，集思广益。

7. 过程试点：在Z公司选择一个现有项目进行试点，在实践中检验和完善过程定义。

8. 试点总结：总结多学科集成迭代过程应用的经验教训，为Z公司乃至整个行业的过程改进提供经典实践。

本课题的技术路线：

1. 基于复用定义软件总线架构

2. 面向快速软件服务的个体敏捷过程拟包括以下子过程：

a) 需求与组件池的匹配过程

b) 派生组件的开发过程

c) 需求的验证过程

d) 快速服务交付过程

e) 组件反馈维护过程

3. 借鉴CMMI和PSP来建立面向快速软件服务的个体能力成熟度模型，并进行评估

[注:如果是开发系统，则可画个系统结构图，并说明开发语言、工具、框架等]

本课题的研究经费来自Z公司的过程改进费用，Z公司有一支专职的过程改进队伍，并且已经具备一定的过程资产和项目历史数据，过程的试点项目已经选定，多学科集成迭代过程的核心思想已经开始在该项目中应用。课题研究各方面的资源已基本具备，可以支持研究工作的开展。

六、计划进度

[注:一般从开题到答辩是一年时间]

2005.10 开题

2005.12 定义面向快速软件服务的个体敏捷过程

2006.03 定义面向快速软件服务的个体敏捷过程中个人能力成熟程度

2006.04 选择2-3个专业服务项目进行推广试点

2006.06 对试点专业服务项目进行评估与改进

2006.07 撰写学术论文

2006.08 部门内部推广

2006.10 学位论文定稿和答辩准备

参考文献

[1] Product Developmet Maagemet Associatio. The PDMA Glossary for ew Product Developmet. , 2004

[2] 熊光楞，徐文胜，张和明，范文慧。并行工程的理论与实践。清华大学出版社，施普林格出版社，2001

[3] 傅立丰，张耀宗，刘长红。并行工程的发展及应用。机械加工与自动化，2003(9)

[4] R. Wier, J. PeeU, H. Bertrad, M. Slusarczuk. The Role of Cocurret Egieerig i Weapos System Acquisitio. IDA Report R-338, Istitute for Defese Aalyses, 1988

[5] 朱焕立，刘玉宾。并行工程的产生、应用及研究现状。中州大学学报，2003(4)

[6] 万立，郑霞，刘清华。产品全生命周期管理平台的集成产品开发流程实现研究。计算机辅助工程，2005(6)

[7] Iteratioal Coucil o Systems Egieerig. Systems Egieerig Hadbook, Versio 2a. ICOSE, 2004

[8] The Istitute for Systems Research. A itroductio to systems egieerig.

[9] Iteratioal Coucil o Systems Egieerig. Guide to the Systems Egieerig Body of Kowledge. g2sebok.icose/

[10] Alexader Kossiakoff, William . Sweet. Systems Egieerig Priciples ad Practice. Wiley-Itersciece, 2003

[11] Systems Thikig ad Systems Egieerig.

[12] Watts S. Humphrey. Maagig the sofare process. Addiso-Wesley, 1989

[13] Wito Royce. Maagig the Developmet of Large Sofare Systems. Proceedigs of IEEE Westco, 1970

[14] Frederich P. Brooks Jr.. The Mythical Ma-Moth. Addiso Wesley Logma, 1995

[15] Roger S. Pres *** a. Sofare Egieerig: A Practitioer’s Approach, Fifth Editio. McGraw-Hill Compaies, Ic., 2001

[16] Steve McCoell. Rapid Developmet: Tamig Wild Sofare Schedules. Micosoft Press, 1996