1

NEW APPROACH

TO STREAMLINING

ETRIKS USER REQUIREMENTS

DOWN TO EFFECTIVE

DELIVERY

INTRO OF FDT-LEADS 13-jan-2014

E. Van der Stuyft, P. Rice

2

Agenda Intro

◦ Current delivery package process assessed◦ Proposed alternative approach◦ Key process components and supportive framework

Next steps to get on top of◦ Agree on a FDT working model◦ Agree on functional domain delineation◦ Break up consolidated requirements into functional

building blocks to distribute across FDTs

Getting ready for Annual meeting and further follow up

Feedback - Questions

Proposed focus of this meeting: Bringing the concept across.

Proposed focus of next meeting: feedback+ start working

3

Current delivery package process assessed

◦ Last resource team meeting Provided some visibility to IMI project status and needs from a user perspective Resulted in high level user requirements

bundled in consolidated features requests list

◦ Sowtware devt-related progress on delivery packages since then Many delivery package owners

see very little if any progress Have no clue as to what eTRIKS-sponsored tranSMART development resources worked

on Have no clue on how to get traction on them from a delivery package owner perspective

Even after extensive efforts by some

◦ Assessing the root of the problem Core questions as to how to effectively funnel URS -> delivery not resolved

How can we ensure overlapping needs across projects don’t lead to fragmentation and redundancy?

How do we articulate URS so developers can work on what users effectively need? What info is needed before cost/benefit-based prioritization makes any sense? What ‘URS -> devt -> acceptance -> rollout’- process is adapted in this space? How can we orient different stakeholders to contribute effectively to an environment

that requires delivery-oriented, focused, disciplined development? How can we deal with a workload that is quite beyond what 6(?) eTRIKS developers can

do?

4

Proposed alternative approachIMI projects to support in

eTRIKS

Funct

ional n

eed s

pace

How to handle?URS overlapping cross-project?

◦Project driven - overlapping code?

◦Driven by distinct ‘Functional Domain Teams’ interacting with ‘Delivery Package Owners’

URS to code streamlining?◦Ad hoc betw user reps & dvlprs?

◦ Iterative process driven by FDT-user rep:

Articulation, prioritization, user acceptance

FDT –dvlr rep: Design/architecture,

estimation, development, unit testing

Focus and critical mass◦Practical arrangements on key

stakeholder focus and discipline

◦Encouraged to look for pragmatic collab formulas beyond eTRIKS

Cfr tranSMART-NGS-data working group

◦ IMI-projects with specific priorities are encouraged to integrate resources/budget in team process

Supporting framework◦Link to initial frame

Data Modelling

Functional domains

Data curation and Loading

Analysis and Visualization

Browsing and Querying

Core

D

evelo

pm

en

t Long-T

erm

D

evelo

pm

en

t

UB

IOP

RED

ON

CO

TR

AC

K

OTH

ER

PR

OJE

CTS

...

AB

IRIS

K

Link to functional domain team organization

Key process components and supportive framework

Deliv Package(s) owned by DPO

Functional ref doc

(see example)

List of Functional

Feature Modules (FFM)

for X-FDT

List of Functional

Feature Modules (FFM)

for X-FDT

List of Functional

Feature Modules (FFM)

for X-FDT(see example)

Breakdown,

estimate, prioritize

Develop

Send for release by

CD-FDT

Accept

URS to FFM map owned by

DPO(see example)

User scenario owned by DPO(see example)

DPO+ FDT- user reps break up user scenario in high level functions

and associate each with spec FDTDPO- managed

Backlog managed by FDT-user rep

• Managed within FDTs• Regular interaction FDT-leads• Regular interaction DPOs – FDT-user reps• Regular interaction betw FDTs and ‘world’• Governance (Resource Team Meeting)

Actively look for resourcing extension

(cmmty, IMI project spec priorities,..)

All of that supported via the eTRIKS Requirements Streamlining wiki

How can I work with it?

6

Agenda Intro

◦ Current delivery package process assessed◦ Proposed alternative approach◦ Key process components and supportive framework

Next steps to get on top of◦ Agree on a FDT working model◦ Agree on functional domain delineation◦ Break up consolidated requirements into functional

building blocks to distribute across FDTs

Getting ready for Annual meeting and further follow up

Feedback - Questions

7

Agree on a ‘cross-FDT’ working model

◦ Need a recurring joint meeting platform for FDTs and DPOs To sync on any relevant topics across stakeholders and across the process

chain Priority setting/resource dedication High level functional breakup of requirements Visibility and impact on functional drill down by DPOs Other touchpoints between FDTs to discuss more in detail Transparant exposure of ongoing development (eg prototype reviewing,...) ....

Reserve timeslot of 1-1.5 hr per week With clear agenda items and sub-timeslots to gradually reserve ahead of time So people can select what’s relevant for them Aim for closing early if no relevant topics!

Logistics support Meeting setup and project mgt support With possibility to tap into off line: Minutes, presentation sharing, recording support

where relevant? (Potential for parallel breakout sessions if needed? )

Link with WP2/WP6 meeting? Also with DP meetings? eg 1hour FDT; 30 mins support : as long as disciplined and pre-set Relevance filter on support stuff shared by WP2/WP6 representative to FDT part?

Conclusions – when?

8

Agree on a ‘within-FDT’ working model◦ Teams have considerable freedom to operate as they feel works

best Some areas to possibly think about

Resources and logistics Agree with stakeholders on expected focus and bandwidth

I will personally commit to min 0.2 FTE and provide transparant evidence of it For me to remain committed, I will expect at least 1 FTE of steadily dedicated developer effort I will actively look for pragmatically collaborating with the broader community

Agree on meeting frequency and work format (eg 1 hour per week)

Priority setting Pragmatic (vs ‘analyse paralyze’) decisionmaking

Picking universally useful base needs from ‘consolidated feature requests’ first DPOs can create room for specific IMI project needs

By drawing in dedicated resources to operate within framework By making adequately trained resources available By providing budget for such resourcing By drawing in resources from the open source community

Pragmatic modularity Functionality with touchpoints to other funct. domains will always be discussed in a timely way with the

relevant FDT Every function we build will have a clear definition level (all ‘what’-info which the outside world needs to

know), with the ‘how’ modularly wrapped inside

We will focus on interoperability, meaning base query functions will be exposed to both int and ext modules GUI functions will always build on top of underlying base functions

9

Agenda Intro

◦ Current delivery package process assessed◦ Proposed alternative approach◦ Key process components and supportive framework

Next steps to get on top of◦ Agree on a FDT working model◦ Agree on functional domain delineation◦ Break up consolidated requirements into functional

building blocks to distribute across FDTs

Getting ready for Annual meeting and further follow up

Feedback - Questions

10

Proposed ‘querying/browsing FD’ delineation

◦ Querying/browsing Functional Domain (FD) In charge of bringing right data together intelligently

Data as modelled into tranSMART by data modelling FD And as uploaded into tranSMART by data curation and loading FD

Output data as fed back by analysis functions for cascaded reuse Doing so by means of two key resources

Dynamic querying capabilities Bridging the full landscape, incl subject types, phenotypical (lv1), difft molec profiling

data types (lv 2)And drill down to file types (lv3) – wherever TM data model allows

The grid view and associated lists generation and mgt capabilities In this way providing support to analysis/visualization FD

For analysis/visualization functionality integrated into tranSMART Pragmatic API-based data input and output-for-reuse support (focus on interoperability)

For analysis/visualization functionality outside of tranSMART Support for file-based data export

Potentially via dynamic queries, including ‘drill down into file level’ queries (query level 3)

Potentially starting from a selection of what’s available in the grid view Support for handing down selected files to associated viewing/analysis applications via

grid view

In touch with core devt FD for deployment of created capabilities Referring to long-term devt FD on features requiring fundamental

changes

Proposed initial focus of iterative development

Depending on focus of DAV-FDT, agreements could be made as to where GUI capabilities are handled.

This underlines the criticality of a modular approach!

11

Agenda Intro

◦ Current delivery package process assessed◦ Proposed alternative approach◦ Key process components and supportive framework

Next steps to get on top of◦ Agree on a FDT working model◦ Agree on functional domain delineation◦ Break up consolidated requirements into functional

building blocks to distribute across FDTs

Getting ready for Annual meeting and further follow up

Feedback - Questions

12

LTD-FDT?

Querying variation patterns in the large diversity of molecular building blocks – a functional ref doc example

Defining a limited number of models to capture at a summary level◦ The identity of a specific molecular building block◦ Core features of interest about that molecular building block

In such a way that A broad range of data types can be flexibly uploaded into a fitting model Versatility and performance on querying is adequately facilitated for

Providing a querying frameworkIn analogy with cohort select query fcty at phenotypical level◦ To reach exactly into the molecular building blocks of interest

from the overall picture via a concept tree-like paradigm Iteratively extending reach into new data models are these are being added by DM-FDT

◦ To apply the appropriate filters on features of these building blocks◦ To combine the above components with adequate boolean logic◦ To pass on relevant query results to the cohort selection list◦ To save query definitions for later reuse

DM-FDT

BQ-FDT

DCL-FDT

DM-FDT?

13

Agenda Intro

◦ Current delivery package process assessed◦ Proposed alternative approach◦ Key process components and supportive framework

Next steps to get on top of◦ Agree on a FDT working model◦ Agree on functional domain delineation◦ Break up consolidated requirements into functional building

blocks to distribute across FDTs

Getting ready for Annual meeting and further follow up

Feedback - Questions

14

Proposed resource team mtg activities◦ Alternative approach explained to stakeholders (DPOs,

Developers,...)(1 hour-allowing for interaction) Adapted presentation What wiki resources are available to DPOs and other

stakeholders? Who are driving FDTs and how are these FDTs delineated? Prioritization rationale and how DPOs can affect what effectively

gets done

◦ Extensive joint worksession with DPOs and FDT-leads(as much time as we can getAvoid pushback by other item running out; plus actively shift from ‘items that just fill up time’ to ‘pushing forward’?) To translate as many DPs into Functional Ref doc as possible

Will ask FDT-user reps to prepare for that (volunteering approach)(link to consolidated IMI project user requirements overview )

This exercise will also allow people to step into the proposed mindset

15

HomeworkNow: decide on main recurring meetingNext meeting before annual meeting

◦ Key feedback to sync on ◦ Functional Domain delineation and pragmatic

priorities Before Annual meeting

◦ Prep functional reference doc facilitation for areas (see list)

◦ Get set and started as a teamFrom there:

◦ Work down into Functional Feature Mapping per FDT◦ First for priority topics to get started on

get developers started soon

16

Prep 4 funct ref doc homework

Automated Data Checking post ETLFabien, Yannis

Features identified as foundational to support OncoTrack Emmanuel/Chris

eTRIKS Export Emmanuel, Jay Custom annotation files ?ETL? Multiple Cohorts Mansoor/Chris eTRIKS Security Jay Support for longitudinal studies

Chris/Anthony Reproducible Research Datasets (ver

sioning / provenance) Mansoor, Chris

GUI Mansoor Fail safe data loading / error handling

Fabien, Yannis Statistical Test Selection Mansoor,

Yannis

Project Workspace Mansoor, Anthony Automated Hypothesis Generation

Mansoor, Jay Gene Signature/List (Automated Gene

mapping and annotation) Emmanuel, Fabien

Performance (especially ETL) Anthony/Fabien/Chris

Quickly accessing end point (leaves) Emmanuel/Mansoor, Anthony

Easy box plot creation/manipulation Mansoor, David Peyruc

Date isn't a date Jay, Robin Munro Robust R interface Mansoor/Emmanuel,

Jay Imaging Support Emmanuel, Yannis consolidated environment for TM/

eTRIKS Jay, Peter Zoom in and out on genomic data

Mansoor, Peter

17

Agenda Intro

◦ Current delivery package process assessed◦ Proposed alternative approach◦ Key process components and supportive framework

Next steps to get on top of◦ Agree on a FDT working model◦ Agree on functional domain delineation◦ Break up consolidated requirements into functional building

blocks to distribute across FDTs

Getting ready for Annual meeting and further follow up

Feedback - Questions