《2019年软件工程实验心得体会范文》由会员分享，可在线阅读，更多相关《2019年软件工程实验心得体会范文（5页珍藏版）》请在金锄头文库上搜索。
1、软件工程实验心得体会范文 经过这学期软件工程实验的学习深深感到用户需求对软件的重要性成功的软件产品是建立在成功的需求基础之上的而高质量的需求来源于用户与开发人员之间有效的沟通与合作当用户有一个问题可以用计算机系统来解决而开发人员开始帮助用户解决这个问题沟通就开始了 需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动对需求的获取往往有错误的认识：用户知道需求我们所要做的就是和他们交谈从他们那里得到需求只要问用户系统的目标特征什么是要完成的什么样的系统能适合商业需要就可以了但是实际上需求获取并不是想象的这样简单这条沟通之路布满了荆棘首先需求获取要定义问题范围系统的边界往往是很难明确的用户
2、不了解技术实现的细节这样造成了系统目标的混淆 其次是对问题的理解用户对计算机系统的能力和限制缺乏了解任何一个系统都会有很多的用户或者不同类型的用户每个用户只知道自己需要的系统而不知道系统的整体情况他们不知道系统作为一个整体样工作效率更好也不太清楚那些工作可以交给软件完成他们不清楚需求或者说如何以一种精确的方式来描述需求他们需要开发人员的协助和指导但是用户与开发人员之间的交流很容易出现障碍忽略了那些被认为是很明显的信息最后是需求的确认因为需求的不稳定性往往随着时间的推移产生变动使之难以确认为了克服以上的问题必须有组织的执行需求的获取活动 需求获取活动要完成的任务或者步骤的过程如下： 1、编写项目
3、视图和范围文档 系统的需求包括四个不同的层次：业务需求、用户需求和功能需求、非功能性需求业务需求说明了提供给用户新系统的最初利益,反映了组织机构或用户对系统、产品高层次的目标要求它们在项目视图与范围文档中予以说明用户需求文档描述了用户使用产品必须要完成的任务这在使用实例文档或方案脚本说明中予以说明功能需求定义了开发人员必须实现的软件功能使得用户能完成他们的任务从而满足了业务需求 非功能性需求是用户对系统良好运作提出的期望包括了易用性、反应速度、容错性、健壮性等等质量属性需求获取就是根据系统业务需求去获得系统用户需求然后通过需求分析得到系统的功能需求和非功能需求项目视图和范围文档就是从高层次上描
4、述系统的业务需求应该包括高层的产品业务目标评估问题解决方案的商业和技术可行性,所有的使用实例和功能需求都必须遵从的标准而范围文档定义了项目产品所包括的所有工作及产生产品所用的过程项目相关人员对项目的目标和范围能达成共识,整个项目组都应该把注意力集中在项目目标和范围上 2、用户群分类 系统用户在很多方面存在着差异例如：使用系统的频度和程度、应用领域和计算机系统知识、所使用的系统特性、所进行的业务过程、访问权限、地理上的布局以及个人的素质和喜好等等根据这些差异你可以把这些不同的用户分成不同的用户类与ulm中usecase的actor概念一样用户类不一定都指人也可以包括其他应用系统、接口或者硬件这样
5、做使得与系统边界外的接口也成为系统需求将用户群分类并归纳各自特点并详细描述出它们的个性特点及任务状况将有助于需求的获取和系统设计 3、建立核心队 通常用户和开发人员不自觉的都有一种我们和他们的想法产生一种对立关系把彼此放在对立面每一方都定义自己的边界只想自己的利益而忽略对方的想法他们通过文档、记录和对话来沟通而不是作为一个合作的整体去识别和确定需求完成任务实践证明这样的方法是不正确的不会给双方带来一点益处,良好的沟通关系没有建立导致了误解和忽略重要的信息只有当双方参与者都明白要成功自己需要什么同时也知道要成功对方需要什么时才能建立起一种合作关系 为了建立合作关系通常采取一种组队的方式来获取需求
6、建立一个由用户代表和开发人员组成的联合小组作为需求获取的核心队伍联合小组将负责识别需求、分析解决方案和协商分歧小组成员可以采用会议、电子邮件、综合办公系统等方式进行交流但交流时应注意以下原则：小组会议应该由中立方来组织和主持用户和开发人员都要参加;交流预先要确定准备和参与的规则;议题要明确并覆盖所有关键点但信息来源应该自由;交流目标要明确并告知所有的成员 4、确定使用实例 从用户代表处收集他们将使用系统完成所需任务的描述讨论用户与系统间的交互方式和对话要求这就是使用实例一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序使用实例方法给需求获取带来的好处来自于该方法是用以任务为中心
7、和以用户为中心的观点比起使用以功能为中心和以开发者为中心的方法使用实例方法可以使用户更清楚地理解和认识到新系统允许他们做什么和做描写使用实例的时候要注意使用简洁直白的表述尽量使用主动语态用系统或者用户作为主语比如用户提交用户密码系统验证用户密码是否正确还有一点在描述中不要设计界面细节比如用户从下拉框中选择产品类型使用实例为以后写用例场景描述中的基本路径和扩展路径提供了素材 5、分析用户工作流程 分析用户工作流程观察用户执行业务任务的过程通过分析使用实例得到系统的用例图编制用例图文档将有助于明确系统的使用实例和功能需求统一建模语言的使用有助于与用户进一步交流每个用例的描述应包括：编号,为每个用例
8、分配一个唯一的编号为需求的追溯提供了方便;参与者与这个用例交互的actor;前置条件开始用例前所必须具备的系统状态;后置条件用例完成后系统达到的状态;基本路径用例完成的关键路径也是用户期望的路径;扩展点基本路径的分枝表示意外情况;字段说明路径中名称的进一步分解说明对以后类属性的定义和数据库字段设计起作用;设计约束实现用例的非功能约束 6、检查问题报告 通过检查当前已经运行系统的问题报告来进一步完善需求客户的问题报告及补充需求为新系统或新版本提供了大量丰富的改进及增加特性的想法负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息 7、需求重用 如果客户要求的功能与已有的系统很相似则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件业务建模和领域建模式需求重用的最好方法像分析模式和设计模式一样需求也有自己的模式 总结：经过一学期的软工实验深刻感到其重要性的同时也学到了不少的东西将对我在今后的软件开发过程中起极大的作用 o:p
