系统工程

“二十一世纪提供了一个令人兴奋的机会对于系统工程。增加技术复杂性导致建筑新的挑战,网络,硬件和软件工程和人类系统集成”。- - - - - -横切系统工程指南

系统工程国际会议(INCOSE)注册一个“敏捷工作小组“完善ISO / IEC / IEEE 15288 - 2015系统工程过程反映敏捷原则。发展,指导和最佳实践,努力将和表达在国防部的背景下。

在敏捷环境中,系统工程要求定制方法和流程交付增量的能力,因此需要一个严格的方法来协调并行细化和优先级的需求,技术开发、操作和维护活动。系统工程师在操作起着关键作用,技术,和编程集成,表达了在敏捷软件开发的核心宗旨,积极开发人员之间的协作,用户和其他利益相关者。项目领导人必须鼓励系统工程师参与开发人员、测试人员、用户和其他利益相关者在他们训练有素的工程过程。

使更快,更小的交付能力,敏捷开发需要主动集成在企业架构,平台架构,及相关开发工作,每个利益相关者群体的贡献问题和机会从他们选区的好成功的发布和系统交付。之间找到合适的平衡结构和必要的灵活性提供可用的功能与用户需求一致,项目应进行连续跨学科按照系统工程的评论多迪5000.02要求。然而,如下图所示,程序应该取代全面初步设计评审(一同)和关键设计评审(CDRs)更频繁和增量式设计评论在发布计划阶段。演示功能,并提供洞察项目的进展,这些评论应该关注发布的相对较小的范围,以及它如何将企业架构。类似的技术评审可以分解释放的水平。

过渡大正式技术评审更小、更频繁,迭代的评论

虽然敏捷系统工程包括频繁的非正式技术和程序性审查,这种不太正式的方法不等于不严谨。相反,更大的频率允许关键决策者和其他利益相关者更加熟悉和适应过程,系统和操作注意事项在敏捷环境中,使一个更具协作性的和富有成效的审查过程。是强调在上面的部分中,全面参与关键决策者和用户是敏捷方法的基础。

一些关键的系统工程实践在敏捷环境中考虑包括:

• 提供所有关键利益相关者在一个一致的信息,定期的基础上,通过设计评审或项目评审和使用一个集成的数据环境等利益相关者共同开发承包商(s)和政府。提高政府透明度,增加团队的理解,并且降低了需要正式合同数据交付。
• 使用发布计划和sprint示威机会带来用户、开发人员和利益相关者在一起面对面的会议来推动合作和加强合作安排。
• 确保一旦一个清晰的架构,系统工程师继续完善它,因为他们学习更多从开发冲刺和版本。团队负责开发、更新和协作体系结构和共享系统假设不断在整个敏捷过程。
• 独立的发布,定期审查技术评审大史诗,创建战略计划,梳理项目待办事项列表,管理资源,形成项目的方向。
• 捕获系统工程分析和技术管理流程和相关内容的组合层次系统工程广泛使用的计划。个人发布可以捕获细节在小范围附录批准在低水平。

”定义了所需的技术努力开发的范围,领域,并维持系统以及提供关键量化输入计划规划和生命周期成本估算。它为项目经理和系统工程师提供了一个框架来完成共同的技术活动提高产品成熟度和知识,减少技术风险。”它是系统工程的基础计划和其他计划和成本文件支持发展。
- - - - - -国防采购指南

在敏捷环境中,技术规划是一个持续的,增量整个收购过程生命周期。技术计划的早期阶段的程序提供了一个框架以更大程度的优先需求的细节完成在最初几个版本。敏捷项目不会花大量的时间开发大型技术计划,而是开始发展提供一个基础版本,通常包括多个供应商在技术成熟和如何减少风险降低风险的努力(TMRR)阶段。每个版本和sprint始于计划,列出有多少用户故事基于可用的时间和资源来完成。例如,如果团队正在配置COTS协作系统中,用户故事可以识别所需的功能,如:

作为最终用户,我希望能够与大家分享数据即时在线会议。

日常会议回顾一下每个团队成员完成前一天,计划在目前的天,和遇到的任何障碍。Sprint和发布评论让团队反思工作,没有什么工作,使持续改进。团队的不断梳理和sprint积压有助于优化和完善发展。早期和积极的风险管理技术规划过程中起着关键作用。

技术规划发生在几个水平和时间框架内的开发过程。例如,开发团队通常在频繁的基础上进行技术规划,通常在每日站立会议。开发团队通常与产品负责人每月工作,或者在每一次冲刺的开始,进行技术规划在sprint的水平。产品所有者通常与释放团队一起工作,进行技术规划版本级别上,应与释放每6 - 12个月的时间。一般来说,打破技术规划分成更小、更频繁的各级活动将更好地支持敏捷开发过程以确保它符合发展的优先事项,用户反馈,程序层次的变化。

“决策分析过程大致陈述决策机会转换成一个跟踪,可防御的,和可操作的计划。它包含一个或多个离散分析在一个或多个元素(例如,系统)水平较低和聚合成一个高级视图(例如,系统“计分卡”)相关决策者和其他利益相关者。”

- - - - - -国防采购指南

敏捷发生在重点发展决策分析问题出现时,开发团队必须决定开发步骤和设计基于风险的理解和选择。这可能是一个挑战,因为一个优化设计和实现解决方案通常是未知的,在许多情况下,“不可知”由于固有的复杂性,在程序的开始。团队应该抵制过度工程化的冲动或事先设计一个最优解;相反,团队应该进行基于优先方向,然后评估进展课程正确分析的基础上具体的经验。典型的敏捷决策中心调整用户故事的分组,确定哪些冲刺发布给用户,调整和分裂的设计和实现为独立的故事,和删除从需求积压需求的影响。

“技术评估过程允许系统工程师比较实现结果与定义的标准提供一个基于事实的理解当前的产品知识水平、技术成熟度、程序状态,和技术风险。这一评估结果在更好的理解程序的健康和成熟,给项目经理项目决策良好的技术基础。”- - - - - -国防采购指南。

技术评估在敏捷的环境中与其他程序使用的过程:它基于一组评估进展信息和指标。在项目使用敏捷方法,指标反映的关键元素的开发方法,通常专注于用户故事,包括用户故事的数量由开发团队,执行和多快完成。输入可能包括“燃尽图”显示进步的实现用户故事和减少需求积压或“速度”——速率用户团队实现用户故事。系统工程师,而不是只参加重大项目评审,将积极参与sprint审查评估进展,示威游行,和即将到来的计划。使用工具自动生成的燃尽图和其他指标评估可能导致大量的时间储蓄和技术评估提供更多信息。

企业架构的显式描述当前和预期的业务和管理流程之间的关系。它描述了“目标”情况的机构希望创建和维护管理其投资组合。- - - - - -富兰克林·d·雷恩斯,前管理预算办公室主任

在今天的环境中,它不再程序可以独立运作;相反,他们必须接口和整个国防部与其他系统进行通信。随着国防部继续进化朝着一个共同的操作环境与企业平台,它计划将通过一系列应用程序或web服务的功能。因此,IT系统必须设计、开发和维护与企业架构。企业架构是策划的核心技术集成和展望未来系统应该如何操作。

一个有效的体系结构是一个环境显然是理解和利益相关者了解他们如何连接到企业。架构应该突出技术和整个企业的运营流程和结构。它应该考虑现有和计划的基础设施和系统——从他们目前提供的能力差距,必须和其他系统所需的接口。

企业架构获取大量的信息;然而,在开发和维护中央指导架构在敏捷环境保持简单。建筑的价值随着其复杂性增加,减少大量的文档和工件使参与者很难理解。

它收购整个生命周期中,企业架构师作为重要项目的团队成员,帮助有效范围、结构、和分析选择为作战人员提供功能。他们确保体系结构捕获操作和技术环境以及当前流程、组件、接口和其他特性。作为整个项目团队学习所需的功能如何实现军事目标,团队成员还必须了解项目将结合现有和计划工作在整个企业,而且必须为建筑师提供更新程序,这样他们就可以不断地管理和更新的架构。企业架构师必须确保程序有效地消化和集添加到架构和档案过期的元素。频繁的合作是成功的关键。

当程序开发新软件,例如一个新的应用程序,或定制现有的COTS产品——它必须建立一个初始架构指导设计和集成方面的项目。体系结构将有助于确定如何优先需求提供最初的功能。

程序中使用敏捷,最初的设计架构和基础设施平台通常是独立于软件开发部分创建的。Scrum方法论,这种前期架构和基础设施设计和制造被称为“Sprint 0。”

接口与外部系统和变化由企业架构的管理通常故事项目积压。例如,如果一个新的业务流程引入企业架构,然后适当的用户故事需要被添加到积压应对这些变化的影响。接口必须分解成许多故事,但管理作为一个主题或史诗。敏捷方法的专家建议使用常见的(理想情况下开源)平台,标准、接口和应用程序编程接口(api)在昂贵的点对点接口。

额外的引用:

• 敏捷企业架构
• 企业架构训练有素的敏捷交付

在大多数大型收购,许多系统工程过程是由承包商执行(s)构建解决方案。这些过程重叠与政府责任在某些情况下,所以重要的是要理解这些活动是否有效地完成。根据INCOSE系统工程手册(第四版),这些过程包括):

• 技术流程:
  • 设计的定义——总体系统设计,应随时间而变化,但重要的是,所有的利益相关者参与设计决策。
  • 系统分析-这是一个持续的过程,以确保解决方案的增量开发仍然是稳定的,一致的,与利益相关者的需求。
  • 验证和确认——发布过程必须不断验证构建作品-验证和满足需求的验证(即。,满足用户故事)。
  • 过渡受的增量解决方案到操作必须注意避免来完成“更新疲劳”的用户同时仍然允许解决方案发展。
  • 操作在敏捷环境中,发展继续初始发行版被使用在实际操作时。监视和测量的性能是很重要的交付增量和有一个机制来应对“真实”用户的反馈。
  • 维护部署系统可能打破。维护活动应该输入产品待办事项列表,并相应地优先。后续版本在技术上“升级”应该通过用户的管理现有的能力和维护过程。
  • 处理——新功能添加到部署,逐步开发系统,遗留系统最终可能需要从服务中移除,有时候早期功能的新系统可能需要退休时,取而代之的是一种改进的功能或不再需要。
• 技术管理流程
  • 质量保证——不仅仅是测试好的软件工程实践是重要的保持代码的可移植性更好的让未来无法预料的变化到部署系统。