摘要:软考系统架构设计师属于软考中的一项高级资格考试,考试分综合知识、案例分析和论文3个科目。系统架构设计师考试作为一项高级资格考试,有一定的考试难度,那么该如何备考才能顺利通过考试呢?面对系统架构设计师教程无从下手的同学,希赛软考学院为您准备了几个重要的教程章节知识点精讲,希望对您的学习有所帮助。
软考系统架构设计师属于软考中的一项高级资格考试,考试分综合知识、案例分析和论文3个科目。系统架构设计师考试作为一项高级资格考试,有一定的考试难度,那么该如何备考才能顺利通过考试呢?面对系统架构设计师教程无从下手的同学,希赛软考网为您准备了几个重要的教程章节知识点精讲,希望对您的学习有所帮助。
4.1.5软件系统工具
按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。
软件开发工具有:需求分析工具、设计工具、编码与排错工具、测试工具等。
需求分析工具,生成完整的、清晰的、一致的功能规范。功能规范是软件开发者和用户间的契约,也是软件设计者的和实现者的依据。正确、完整表达清晰的、无歧义的。
需求分析工具分为基于自然语言或图形描述的工具,基于形式化需求定义语言的工具。
项目管理工具:项目的计划、调度、通信、成本估算、资源分配、质量控制等。
4.2需求管理
需求最终文档经过评审批准后,则定义了需求基线Baseline;构筑了功能需求和非功能需求的一个约定Agreement。约定是需求开发和需求管理之间的桥梁。
需求管理是一个对系统需求变更、了解和控制的过程,初始需求导出的同时就启动了需求管理规划。
4.2.1需求管理原则
过程能力成熟度模型CMM,指导软件过程改进,5个成熟级别,6个关键过程域KPA。
一旦需求文档化了,开发组和有关团队需要评审文档。发现问题应与客户或者其他需求源协商解决。软件开发计划是基于已确认的需求。
绝不要承诺任何无法实现的事。
关键处理领域通过版本控制和变更控制来管理需求文档。确保与新的需求保持一致。
4.2.2需求规格说明的版本控制
版本控制是管理需求的一个必要方面,必须统一确定需求文档的每一个版本,当需求发生变更时,及时通知所有涉及人员。
为了尽量减少困惑、冲突、误传,应该仅允许指定的人员来更新需求。
清楚地区分草稿和文档定稿版本。
4.2.3需求变更
迟到的需求变更会对已进行的工作产生非常大的影响。
如果每一个建议的需求变更都采用,该项目将可能永远无法完成。
需求文档应该精确描述要交付的产品。
项目负责人在信息充分的条件下做出决策。
变更成本计算应该包括需求文档的修改、系统修改的设计、实现的成本。
变更控制过程并不是给变更设置障碍,相反,它是一个渠道和过滤器,确保采纳最合适的变更,使变更产生的负面影响降到最低,变更过程应该做成文档。
绝不能删除或者修改变更请求的原始文档。
变更控制委员会只要能决定合适的人做正确的事就足够了,在保证性的前提下应尽可能精简人员。
对每个变更权衡利弊做出决定。
“利”包括节省资金或额外收入、客户满意度、竞争优势、减少上市时间;
“弊”是指增加开发费用、推迟交付日期、产品质量下降、减少功能、用户不满意。
变更总是有代价的,即使拒绝的变更也因为决策行为而耗费资源。
接受了重要的需求变更时,为了适应变更情况要与管理部门和客户重新协商约定。推迟交货时间、增加人手、推迟实现尚未实现的较低优先级的需求,或质量上进行折中。
要是不能获得一些约定的调整,应该把面临的风险写进风险计划中。
4.2.4需求跟踪
需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档等。
跟踪能力(联系)链(traceability link)是优秀需求规格说明书的一个特征,确保软件需求规格说明包括所有客户需求。
跟踪能力联系链记录了单个需求之间的父层、互连、依赖的关系。
不必拥有所有种类的跟踪能力联系链,要根据具体情况调整。
4.2.5需求变更的代价和风险
只有在知道变更成本后才能做出理智的选择,一个表面上很简单的变更也可能转变成很复杂的局面。
影响分析确定对现有系统做出是修改或者抛弃的决定,创建新系统以及评估每个任务的工作量,进行影响分析的能力依赖于跟踪能力、数据的质量、完整性。
希赛软考网,拥有十四年软考培训经验,希赛网一直坚持自主研发,将丰富的软考培训经验有效融入教程研发过程,自成体系的软考在线题库(软考历年真题)、软考培训教材和软考视频教程,多样的培训方式包括在线辅导、面授、和,使考生的学习更具系统性,辅导更具针对性。采用全程督学机制,,软考平均通过率在全国。
软考备考资料免费领取
去领取