SAFe Workshop SDP Ferdl Graser SDP Systems Engineer 2 October 2017.

Slides:



Advertisements
Similar presentations
How to commence the IT Modernization Process?
Advertisements

GE Healthcare UK Performance Solutions
Designing an Architecture 1.Design Strategy Decomposition Designing to Architecturally Significant Requirements Generate and Test This generate-and test.
S Y S T E M S E N G I N E E R I N G.
Virtual University - Human Computer Interaction 1 © Imran Hussain | UMT Imran Hussain University of Management and Technology (UMT) Lecture 16 HCI PROCESS.
Project management Project manager must;
ITIL: Service Transition
Dynamic Systems Development Method (DSDM)
Object-oriented Analysis and Design
4. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Explain the elements of project management and the responsibilities of a.
I n t e g r a t I n g C S S Practitioner Module 4 1 Module 4: CSS in Corridor and Sub-area Planning.
Process: A Generic View
The Software Development Life Cycle: An Overview
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Unified Software Development Process (UP) Also known as software engineering process SEP describes how requirements are turned into software Defines who,
Software Development *Life-Cycle Phases* Compiled by: Dharya Dharya Daisy Daisy
OSF/ISD Project Portfolio Management Framework January 17, 2011.
Improvements to Service Provisioning Platform Deployment Process Master’s Thesis – Matti Jylhä Supervisor: Professor Jorma Jormakka.
BSBPMG502A Manage Project Scope Manage Project Scope Project Scope Processes Part 1 Diploma of Project Management Qualification Code BSB51507 Unit.
Business Systems Development SDLC and introduction to the Microsoft Solutions Framework Team and Process Models.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
What’s a Project? AD642. Why the Emphasis on Project Management? Copyright 2011 John Wiley & Sons, Inc. 1-2  Many tasks do not fit neatly into business-as-usual.
Industrial Software Project Management Some views on project managing industrial and business software projects.
Centro de Estudos e Sistemas Avançados do Recife PMBOK - Chapter 4 Project Integration Management.
Ocean Observatories Initiative OOI CI Release 3 (Scope To Complete) Kick-Off Tim Ampe: System Development Manager Release 3 Kick-off La Jolla, CA October.
1 5.1 Software Engineering Practice  Provide value to the user  KIS—keep it simple!  Maintain the product and project “vision”  What you produce,
1 Chapter 5 Software Engineering Practice. 2 What is “Practice”? Practice is a broad array of concepts, principles, methods, and tools that you must consider.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Fifth Lecture Hour 9:30 – 10:20 am, September 9, 2001 Framework for a Software Management Process – Life Cycle Phases (Part II, Chapter 5 of Royce’ book)
Develop Project Charter
Rational Unified Process Fundamentals Module 3: Disciplines I.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
CSPC 464 Fall 2014 Son Nguyen. 1. The Process of Software Architecting, Peter Eeles, Peter Cripss 2. Software Architecture for Developers, Simon Brown.
Lecture 2 System Development Lifecycles. Building a house Definition phase Analysis phase Design phase Programming phase System Test phase Acceptance.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
PI2134 Software Engineering IT Telkom.  Layered technology  Software Process  Generic Process (by Pressman)  Fundamental activities (by Sommerville)
Meghe Group of Institutions Department for Technology Enhanced Learning 1.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
1 Lecture 2.4a: SEF SE Planning and the SEP (SEF Ch 16) Dr. John MacCarthy UMBC CMSC 615 Fall, 2006.
Software Architecture Architecture represents different things from use cases –Use cases deal primarily with functional properties –Architecture deals.
Object oriented analysis and design 1 Software Development Life Cycle (SDLC)
International Data Centre October 2015Page 1 Progressive Commissioning Jerry Carter, Senior Scientist W. Randy Bell, Director Gerhard Graham, Coordinator.
Software Engineering cosc 4359 Spring 2017.
TK2023 Object-Oriented Software Engineering
Process 4 Hours.
ITIL: Service Transition
Sample Fit-Gap Kick-off
Appendix B Agile Methodologies
CS 389 – Software Engineering
Project Integration Management
Project Management Lifecycle Phases
SAFe Workshop - Oct 17 Presenter: Ray Brederode
PM view of SAFe SAFe Construction Planning Workshop A J Casson
SAFe® for the SKA Nick Rees and Ian Spence 2 October 2017.
Request for Proposal (RFP)
Chapter 2 – Software Processes
Management Breakout: MREFC Budget Summary Victor L
Project Management Process Groups
Systems Engineering for Mission-Driven Modeling
Baisc Of Software Testing
For University Use Only
CS310 Software Engineering Lecturer Dr.Doaa Sami
Software Engineering Practice: A Generic View
Mumtaz Ali Rajput +92 – SOFTWARE PROJECTMANAGMENT– WEEK 4 Mumtaz Ali Rajput +92 – 301-
Appendix B Agile Methodologies
SAFe Construction Planning Workshop
SOFTWARE PROJECT MANAGEMENT KEY TOPICS
Presentation transcript:

SAFe Workshop SDP Ferdl Graser SDP Systems Engineer 2 October 2017

SAFe defines 3 types of milestones PI milestones: objectively evaluate progress towards the technical or business hypothesis. Occur at PI cadence. Fixed-date milestones: milestones driven by external events, third-party deliverables, external constraints, etc. These often call for fixed-date milestones that are distinct from the development cadence. Learning milestones: demonstrate evidence of the viability of the current in-process solution.

PI & Learning Milestones Provide objective evidence of working systems Performance Verification milestones Risk driven step-wise performance evaluation of SDP at scale Evaluation of alternative design options (set-based design) The specific date at which these milestones occur is not important, rather the value added by objective measurement of a working system.

Milestone background: No reviews, sign-offs or formal baselines Milestones Milestone background: No reviews, sign-offs or formal baselines Minimal Viable Product as early as possible Incremental build-up of content Working and tested systems plan/milestones will change Based on output of learning milestones Continuous improvement: removing waste (non value adding activities)

2 track approach: SDP Commissioning & AIV support system - To support commissioning & AIV activities as required - on-site system (ITF, MID & LOW) SDP Operational System - MVP in 9 months – first significant solution level integration - Performance Verification testing ~6 months

Construction pre-meeting material

Construction Plan Vision SAFe is essential for SDP construction Risk driven Balance lifetime cost against performance Requires close stakeholder (SKAO) interaction to do trade-offs Lots of unknowns Construction Plan has been designed to minimise cost and risk SDP Cost Estimate is based on the same principles and plan Based on experience and risk register from SDP pre-construction

Construction Plan Vision 2 track s/w construction approach SDP Commissioning and AIV support system SDP Operational System Minimal viable product established early on Functionality and performance added according to WSJF (driven by science value) Set-based design and construction elements Execution Frameworks Continued architecture refinement and detailed design through to product delivery

Construction Plan Vision Verification and testing approach Bulk of functional verification will be done via System Demos Performance verification will be larger tests, see performance verification milestones Transition between Construction and Operations can be a soft transition

Program Solution Intent Solution intent is the repository for storing, managing, and communicating the knowledge of current and intended Solution behavior. Where required, this includes documented, fixed, and variable specifications and designs; reference to applicable standards, system models, functional and nonfunctional tests; and traceability. Specifications: L2 requirements (incl ASRs), ICDs Design: Architecture documentation (views & beyond) & supporting documentation, analysis, etc. Tests: functional & performance verification/testing documentation