myIMD Status

Get Started. It's Free
or sign up with your email address
Rocket clouds
myIMD Status by Mind Map: myIMD Status

1. Release Plan

1.1. Risks (2014-01-16)

1.1.1. List

1.1.1.1. 1. We will be able to put in place a valid (LinkedIn compatible) SSO technology by the given deadline.

1.1.1.1.1. One alternative is to drop our SSO technology, but this has some disadvantages

1.1.1.2. 2. We will be able to use the allocated IT team without interruptions, according to the transition plan (Shane transitions to next PC mid-Feb and Richard leaves project 1st April)

1.1.1.2.1. The resource allocation plan was validated in meeting of 2014-01-16 but we are missing a Project Coordinator

1.1.1.3. 3. We will get a guaranteed 20% of Infrastructure team member (which we currently don’t have) for the rest of the project in 2014.

1.1.1.3.1. This is needed to avoid some of the bottlenecks we have experienced in waiting for an Infra resource to be available. This project has a high requirement of infrastructure – development back and forth and hence is hard to execute effectively without some form of dedicated Infrastructure involvement.

1.1.1.4. 4. We will be given a responsive UI design and html that we can integrate into myIMD site in time

1.1.1.4.1. We are currently unable to get validation of the first bunch of wireframes without some PC firepower

1.1.1.5. 5. The stakeholders agree to the current requirements and continue in the same direction

1.1.1.5.1. The current direction of the project hasn't been followed due to the lack of Project Coordinator

1.2. Proposal

1.2.1. Sprint 1 (30 Sept to 12 Dec)

1.2.1.1. SSO integration

1.2.1.2. SSO + LinkedIn spike

1.2.1.3. SSO replaces CF authentication for myIMD

1.2.2. Sprint 2 (6 Jan to 24 Jan)

1.2.2.1. Series of spikes

1.2.2.1.1. webapi

1.2.2.1.2. bootstrap

1.2.2.1.3. backend process

1.2.2.1.4. ...

1.2.2.2. User registration

1.2.2.2.1. https://jira.imd.ch/browse/IMD-479

1.2.2.3. LinkedIn priming

1.2.2.3.1. https://jira.imd.ch/browse/IMD-491

1.2.2.3.2. not needed due to migration to openAM

1.2.2.4. Retrospective conclusion

1.2.2.4.1. Comment: we suspect that test and prod infra setups are not the same (to prove/disprove)

1.2.2.4.2. release management

1.2.3. Sprint 3 (24 Jan to 14 Feb)

1.2.3.1. Account activation

1.2.3.1.1. https://jira.imd.ch/browse/IMD-480

1.2.3.1.2. https://jira.imd.ch/browse/IMD-481

1.2.3.1.3. https://jira.imd.ch/browse/IMD-483

1.2.3.2. Login workflow

1.2.3.2.1. https://jira.imd.ch/browse/IMD-484

1.2.3.3. Retrospective conclusion

1.2.3.3.1. need more involvement from Infra as we are often blocked and waiting on there assistance

1.2.3.3.2. look at removing iframe => use

1.2.4. Sprint 4 (14 Feb to 7 Mar)

1.2.4.1. LinkedIn profile pulling

1.2.4.1.1. https://jira.imd.ch/browse/IMD-488

1.2.4.1.2. See Fred for 'special' access to richer LinkedIn API

1.2.4.2. Password reset

1.2.4.2.1. https://jira.imd.ch/browse/IMD-482

1.2.4.3. Login workflow

1.2.4.3.1. https://jira.imd.ch/browse/IMD-487

1.2.4.3.2. https://jira.imd.ch/browse/IMD-485

1.2.5. Parallel work

1.2.5.1. 16 Jan to 7 Mar

1.2.5.1.1. Integration of OpenAM SSO technology

1.2.5.2. 20 Jan to 7 Mar

1.2.5.2.1. SQLI UI/UX work and creation of html/css

1.2.5.3. Others

1.2.5.3.1. Ensure legality of LinkedIn usage

1.2.5.3.2. Internal communication/training coordination

1.2.5.3.3. Dependencies

1.2.5.3.4. Graphical/Editoral work

1.2.5.3.5. NFRs

1.2.5.3.6. QA

1.2.5.3.7. Dev environment

1.2.5.3.8. Security audit?

1.2.5.3.9. New landing page technology?

1.2.5.3.10. Support tool revision

1.2.6. Sprint 5 (7 Mar to 27 Mar)

1.2.6.1. Context dependent additions

1.2.6.1.1. https://jira.imd.ch/browse/IMD-490

1.2.6.1.2. no longer needed

1.2.6.2. Redo myIMD home

1.2.6.2.1. estimate

1.2.6.2.2. the idea is to timebox this activity, so it doesn't get out of control

1.2.6.3. Change password

1.2.6.3.1. https://jira.imd.ch/browse/IMD-489

1.2.6.4. UAT

1.2.7. Sprint 6 (27 Mar to 17 Apr)

1.2.7.1. Edit profile

1.2.7.1.1. https://jira.imd.ch/browse/IMD-498

1.2.7.2. Block account

1.2.7.2.1. https://jira.imd.ch/browse/IMD-486

1.2.7.3. Modify support tool

1.2.7.3.1. estimate

1.2.7.4. UAT

1.2.7.5. the above features could be dropped according to squeeze

1.2.7.6. the above features could be dropped according to squeeze

1.2.8. Warranty period (17 Apr to 15 May)

1.3. Proposal 2014-03-18

1.3.1. Stage 0 - Preparation and delivery of appropriate infrastructure and environments from IMD Infrastructure team

1.3.1.1. LDAP integration (unknown around separating realms)

1.3.1.2. test single point of failure

1.3.1.3. test prod environment

1.3.1.4. unknowns around performances

1.3.2. Stage 1 - Integration of OpenAM authentication solution using current look and feel of the existing CAS authentication in use at present.

1.3.2.1. Extend and test .NET client with LDAP parameters

1.3.2.2. Intensive tests scenarios with QA to avoid regression bugs on Website

1.3.2.3. Unknown about openAM behaviour vs CAS behaviour on role management for Alumni’s

1.3.2.4. Unknown about performances

1.3.2.5. Unknown about http/https in iframe mode

1.3.2.6. Unknown about external providers like Kulu and Qualtrics ability to switch to use openAM vs CAS

1.3.2.7. Roadmap for migration with providers has yet to be defined

1.3.3. Stage 2 - Integration of LinkedIn login (using First name, Last Name, email) – Use of new forms / UI utilising OpenAM delivery from Step 1 – Requires validation of wireframes

1.3.3.1. We need to find a way to do develop a post authentication plug-in that allows OpenAm to bootstrap an LDAP account or at least a VIP if we want all external providers to work correctly. The planned .NET plug in is not going to be sufficient.

1.3.3.2. We don’t have a consensus on the architecture between technical people. We need to organise brainstorm sessions, document and decide on the role process (ldap centralized vs role proxy)

1.3.3.3. The wireframe may be delayed again waiting on a consensus

1.3.3.4. features to implement:

1.3.3.4.1. login

1.3.3.4.2. registration (account activation)

1.3.3.4.3. password reset

1.3.3.4.4. edit profile

1.3.3.4.5. linkedin profile pulling

1.3.4. Stage 3 - Integration of solution within iPad apps

1.3.4.1. We need do decide on architecture after analysing SAML 2.0 vs oAuth2 for the Ipad

1.3.4.2. Then plan a roadmap to adapt if needed (Apps API, VC API, Magazine, Docs & People)

2. Budget

2.1. 2013

2.1.1. Project Coordinator

2.1.1.1. 65%

2.1.1.1.1. Shane Sendall

2.1.2. Web Solution Architect

2.1.2.1. 30%

2.1.2.1.1. Philippe Gudemann

2.1.3. Web Developer (external)

2.1.3.1. 100%

2.1.3.1.1. Richard Everett

2.1.4. Web Developer

2.1.4.1. 50%

2.1.4.1.1. NikolayNikolov

2.1.5. QA tester

2.1.5.1. 60%

2.1.5.1.1. Petya Yorgova

2.1.6. QA tester (internal consultant)

2.1.6.1. 15 md

2.1.6.1.1. Atanas Radkov

2.1.7. Siebel integration expert

2.1.7.1. 10 md

2.1.7.1.1. SabyBasinac

2.1.8. System Admin (combined)

2.1.8.1. 15 md

2.1.8.1.1. Robert Von Bismarck

2.1.9. iPad Developer

2.1.9.1. 5 md

2.1.9.1.1. Alex McArthur or another member

2.2. Requested/desired for 2014

2.2.1. People

2.2.1.1. 1 x 20% Sys admin

2.2.1.1.1. Robert Von Bismarck

2.2.1.2. 3 x 100% .Net dev

2.2.1.2.1. Richard Everett

2.2.1.2.2. Luka Kurelic

2.2.1.2.3. 50%

2.2.1.2.4. Missing 50%

2.2.1.3. 1x 100% QA

2.2.1.3.1. Petya Yorgova 50%

2.2.1.4. 1 x 30% BA

2.2.1.4.1. Shane Sendall

2.2.1.5. 1 x 20% SM

2.2.1.5.1. Shane Sendall

2.2.1.6. 1 x 25% PC

2.2.1.6.1. Shane Sendall

2.2.1.7. 1x 30% Arch

2.2.1.7.1. Philippe Gudemann

2.2.1.8. 1 x 10% Ux/UI specialist

2.2.1.8.1. SQLi

2.2.1.9. 1x 30% Front-end dev

2.2.1.9.1. Nickolay Markov

2.2.1.10. A few days of CRM specialist

2.2.1.10.1. Saby Basinac

2.2.1.11. 1 x 20% Business Project Manager

2.2.1.11.1. Claudio Crivelli

2.2.1.12. OpenAM Specialist

2.2.1.12.1. SmartWave

2.3. Actual

2.3.1. People

2.3.1.1. ?% Sys admin

2.3.1.1.1. Robert Von Bismarck

2.3.1.2. 150% .Net dev

2.3.1.2.1. Richard Everett

2.3.1.2.2. 50%

2.3.1.3. 100% QA

2.3.1.3.1. Atanas Radkov

2.3.1.4. 30% BA

2.3.1.4.1. ??

2.3.1.5. 20% SM

2.3.1.5.1. ??

2.3.1.6. 25% PC

2.3.1.6.1. ??

2.3.1.7. 20% Arch

2.3.1.7.1. Philippe Gudemann

2.3.1.8. Ux/UI specialist

2.3.1.8.1. SQLi

2.3.1.9. Front-end specialist

2.3.1.9.1. Nickolay Markov

2.3.1.10. A few days of CRM specialist

2.3.1.10.1. Saby Basinac

2.3.1.11. Business Project Manager

2.3.1.11.1. Claudio Crivelli

2.3.1.12. OpenAM Specialist

2.3.1.12.1. SmartWave

3. Features

3.1. Account Management (in and out of scope)

3.1.1. WBS

3.1.1.1. Features

3.1.1.1.1. User-facing

3.1.1.1.2. Support-facing

3.1.1.1.3. Business-facing

3.1.1.2. Plugin service foundations

3.1.1.2.1. Quest

3.1.1.2.2. Online Database

3.1.1.2.3. Apply Online

3.1.1.2.4. GLI

3.1.1.2.5. Alumni Online Offerings

3.1.1.3. Front-end integration

3.1.1.3.1. Responsive design?

3.1.1.3.2. myimd.imd.org

3.1.1.3.3. device types

3.1.1.4. Deal with legacy

3.1.1.4.1. existing myIMD services

3.1.1.5. iPad POC

3.1.1.5.1. token/cookie storing

3.1.1.6. Security

3.1.1.6.1. audit

3.1.1.7. Legal investigation (LinkedIn)

3.1.1.7.1. Stefan Giellieron

3.1.1.8. UI/UX

3.1.1.8.1. 4 x UX labs

3.1.1.8.2. Account management pages

3.1.1.9. BA

3.1.1.9.1. Email replaces username login

3.1.1.9.2. Depreciation of memory aide

3.1.1.9.3. Modified backend business process

3.1.1.9.4. RMS <=> Siebel sync

3.1.1.9.5. Support/Program Admin

3.1.1.9.6. Chase future service owners needing myIMD

3.1.1.10. Infrastructure

3.1.1.10.1. Migration to RMS

3.1.1.10.2. Add Customer Roles to Ldap

3.1.1.10.3. consolidate Directories to single Ldap as ext

3.1.1.10.4. Clean up of duplicate accounts? (Unique email constraint)

3.1.1.10.5. SSO

3.1.1.10.6. new myIMD website

3.2. Backlog

3.2.1. Integration of "Using" services

3.2.1.1. GLI

3.2.1.2. Quest book site

3.2.1.3. Online Database

3.2.2. Entitlement Engine

3.2.3. Programs

3.2.4. Content

3.2.5. Personalization

3.2.6. Yammer-like networking tool

3.2.7. ...

4. Current open Issues

5. Principal Stakeholders

5.1. Business Owner

5.1.1. James Henderson

5.2. Business Project Manager

5.2.1. Claudio Crivelli

5.3. IT Project Coordinator

5.3.1. ??

5.4. Signatory Stakeholders

5.4.1. BOULIANNE, Michael

5.4.2. COOKE, Iain

5.4.3. CRIVELLI, Claudio

5.4.4. DESA, Edwin

5.4.5. DOMENJOZ, Charles

5.4.6. GUDEMANN, Philippe

5.4.7. HENDERSON, James

5.4.8. LYOEN, Sylvain

5.4.9. SENDALL, Shane

6. Scrum

6.1. Open issues

6.2. Team "Definition of Done" List

6.2.1. Done with a Story/Task

6.2.1.1. All code checked in

6.2.1.2. All regression tests passing

6.2.1.3. code reviewed by opposite pair (Richard/Niki)

6.2.2. Done with a Sprint

6.2.2.1. All story criteria plus

6.2.2.1.1. all p0 and p1 bugs resolved

6.2.2.1.2. CI server passing

6.2.2.1.3. All acceptance tests identified, written and passing

6.2.2.1.4. Architectural review performed by Philippe

6.2.2.1.5. All API changes/definitions are documented

6.2.3. Done with release to Staging

6.2.3.1. All sprint criteria plus

6.2.3.1.1. QA review performed

6.2.4. Done with release to Production

6.2.4.1. All staging criteria plus

6.2.4.1.1. UAT performed

6.3. Meetings

6.3.1. Stand-ups

6.3.1.1. Everyday

6.3.1.1.1. < 1 min per question

6.3.1.1.2. < 15 mins total

6.3.2. Clearance meetings

6.3.2.1. 1 hr every Wednesday

6.3.2.2. Goals:

6.3.2.2.1. a chance for each member to:

6.3.2.2.2. a chance for the team to:

6.3.3. QA

6.3.3.1. define testing plan

6.3.3.1.1. covers

6.3.3.2. execute test plan and test system before release

6.3.3.3. execute test plan and prod system after release

6.3.3.4. create automated tests for as much of test plan as reasonable

6.3.3.5. goal: each automated test goes into continuous integration server (run with each git push)

6.4. Sprints

6.4.1. Sprint 1

6.4.1.1. goal: myIMD using SSO

7. Admin

7.1. change request

8. Archive

8.1. Release Plan

8.1.1. Proposal 2

8.1.1.1. Sprint 1 (30 Sept to 12 Dec)

8.1.1.1.1. SSO integration

8.1.1.1.2. SSO + LinkedIn spike

8.1.1.1.3. SSO replaces CF authentication for myIMD

8.1.1.2. Sprint 2 (6 Jan to 24 Jan)

8.1.1.2.1. Series of spikes

8.1.1.2.2. User registration

8.1.1.2.3. LinkedIn priming

8.1.1.3. Sprint 3 (24 Jan to 14 Feb)

8.1.1.3.1. Account activation

8.1.1.3.2. Login workflow

8.1.1.3.3. LinkedIn profile pulling

8.1.1.4. Sprint 4 (14 Feb to 7 Mar)

8.1.1.4.1. Login workflow

8.1.1.4.2. Context dependent additions

8.1.1.4.3. Account activation

8.1.1.5. Sprint 5 (7 Mar to 27 Mar)

8.1.1.5.1. Password reset

8.1.1.5.2. Change password

8.1.1.5.3. Block account

8.1.1.6. Sprint 6 (27 Mar to 17 Apr)

8.1.1.6.1. Edit profile

8.1.1.6.2. Security audit?

8.1.1.6.3. UAT

8.1.1.7. Warranty period (17 Apr to 15 May)

8.1.1.8. Parallel work

8.1.1.8.1. 6 Jan to 14 Feb

8.1.1.8.2. 23 Dec to 14 Feb

8.2. Risks_Oct 2013

8.2.1. Inability to deliver LinkedIn integration due to experimental technology;

8.2.1.1. mitigation

8.2.1.2. contingency

8.2.2. Inability to deliver and integrate html/css of SQLi in a timely manner

8.2.2.1. mitigation

8.2.2.2. contingency

8.2.3. If the stakeholders don't agree on the requirements then delays will be propagated

8.2.3.1. mitigation

8.2.3.2. contingency

8.3. Risks (2014-01-16)

8.3.1. List

8.3.1.1. 1. We will be able to put in place a valid (LinkedIn compatible) SSO technology by the given deadline.

8.3.1.1.1. One alternative is to drop our SSO technology, but this has some disadvantages

8.3.1.2. 2. Our requirements will be validated by our Infrastruture team (which is not able to happen before mid-Jan 2014);

8.3.1.2.1. this includes the validity of setting the username to be the email address of all new myIMD accounts and other infrastructure consequences that we haven’t thought about.

8.3.1.3. 3. If we go for the OpenAM SSO technology, we will be able to get additional resources to be able to put this in place in parallel to our development work and the external resources will be able to meet our tight deadlines.

8.3.1.3.1. As an IT team, we recommend redirecting our effort on this new SSO technology for a number of reasons (better security, better support, easier development and maintenance).

8.3.1.4. 4. We will be able to use the current allocated IT team without interruptions.

8.3.1.4.1. I bring up this point as I’ve been informed that myIMD will be under the VCC business stream, which will be different to the stream of the currently allocated team (“IMD on the Web” business stream) and hence the allocation of a new team would require additional time to perform a transition to the team of VCC

8.3.1.5. 5. We will get a guaranteed 20% of Infrastructure team member (which we currently don’t have) for the rest of the project in 2014.

8.3.1.5.1. This is needed to avoid some of the bottlenecks we have experienced in waiting for an Infra resource to be available. This project has a high requirement of infrastructure – development back and forth and hence is hard to execute effectively without some form of dedicated Infrastructure involvement.

8.3.1.6. 6. We will be given a responsive UI design and html that we can integrate into myIMD site in time

8.3.1.6.1. This means SQLi will be able to meet the deadlines described

8.3.1.7. 7. The stakeholders agree to the current requirements and continue in the same direction

8.3.1.7.1. Any changes to the current requirements base will clearly require a reevaluation of effort