Middle of Semester Presentation

1
Middle of Semester Presentation

• Sultans of Sim
• Presented by Nitin Aby Prasant
• 20 October 2006

2
Stakeholders

• Team
• Yaron Roni Burd Uma Menon
• Sean Duggan Nitin Aby Prasant
• Matthew Weyant

Mentors John Robert Cliff Huff Anthony
Lattanze Lucia de Lascurain
Client L3 Communications Mathew DeLaquil Dr.
Jerry Fudge
3
Agenda

• Project Overview
• Present Status
• Planned (This Semester)
• Proposed Approach
• Planned Milestones
• Reflection
• Questions

4
Project Overview 1

• Business Goals/Drivers
• L-3 Communications wishes to apply scientific
  simulation methods to the problem of deploying
  the optimum allocation of resources for search
  and resource with the highest probability of
  detecting victims and the lowest cost
• L-3 Communications believes that supplying
  decision-makers in the field with sufficient
  knowledge of simulated search and rescue
  operations will empower field commanders to make
  a well-informed decision quickly

5
Project Overview 2
6
Project Overview 3
Simulation Engineer
Cost Benefit Analyst
7
Project Overview 4

• Proposed deliverables
• Simulation engine
• GUI based configuration tool
• GUI based output viewer
• User manual
• Developer manual

8
Present Status 1

• Defined Roles
• Managing Engineer
• Matthew Weyant
• Requirements Engineer, Client Liaison
• Sean Duggan
• Planning Engineer, Chief Architect
• Yaron Roni Burd
• Documentation Engineer
• Uma Menon
• Process Engineer, Support Engineer
• Nitin Aby Prasant

9
Present Status 2

• Multiple drafts of all proposals
• Second draft of SOW
• Temporary Team Wiki
• Working on second version of the RF model
• Working requirements list
• Excel based

10
Present Status 3

• Activities in place
• Meeting process
• Document templates
• Communication process
• Knowledge sharing
• Scheduling and allocation
• Tracking (Time Action Items)

11
Planned (This Semester) 1

• Identify scope
• Creating an informal SRS document
• Sharing the SRS with the customer
• Identifying the functional and quality attributes
  of the final deliverables, from the SRS
• Signed SOW
• Metrics
• Deciding what to collect and why
• Aid in tracking, estimation and quality activities

12
Planned (This Semester) 2

• Finalize the RF model with client
• Implement document review process
• Identify risks and establish risk management
  process
• Develop a change management process for
  requirements
• Estimate tasks
• Implement version management for documents

13
Proposed Approach - 1

• Use ACDM for the requirements engineering and
  design phases
• Discover Architectural Drivers
• Establish Project Scope
• Use Top down approach for planning
• Activity diagram (WBS)
• Critical Path Analysis

14
Proposed Approach - 2

• Use Scrum to meet short term goals
• Sprints will be two weeks long
• 3 sprints remaining in this semester

15
Key Planned Milestones

• Discover Architectural Drivers (ACDM Stage 1) -
  Nov 8, 2006
• Draft SRS Nov 16, 2006
• Draft SOW to customer Nov 16, 2006
• Establish Project Scope (ACDM Stage 2) - Nov 22,
  2006
• First iteration of Notional Architecture (ACDM
  Stage 3) - Dec 8, 2006
• Signed SOW Dec 2, 2006

16
Reflection

• Writing the proposals
• Helped to define the problem
• Made us think about our goals
• Indicated the need for processes
• Provided overall direction to the project
• Launch meeting was very valuable
• Analyzed and selected processes
• Analyzed different management practices
• Ad-hoc vs. formal planning

17
Questions To Mentors

• What are the pros and cons of having a plan
  oriented management (activity diagrams, critical
  path) at high level and a goal oriented
  management (Scrum) at low level?
• How do you mitigate the risks involved with
  Scrum?
• Which other estimation technique besides WBD can
  be used for estimation of tasks in the
  requirements engineering phase?
• What about the visibility of work within the
  team? Should every team member be aware of each
  others tasks and their status or is it enough if
  the Team Lead has the information?

18
Questions?
19
Backup Slides

• From next slide onwards

20
Problem Defn. Proposal - 1

• Gathering high level requirements
• Question-based approach
• Use Cases
• Vision Diagrams
• Physics model to client
• Examples of calculations

21
Problem Defn. Proposal - 2

• Gathering low level requirements
• Allocation of domain experts
• ACDM approach notional architecture
• Experiments (Prototypes)
• Informal SRS

22
Problem Defn. Proposal - 3

• Analysis techniques being considered
• QAW
• Remote client
• Affinity diagrams
• Detailed use cases
• Conflict with ACDM ?

23
Operations Proposal - 1

• Meeting process
• Meeting types
• Meeting roles
• Analysis
• Did the meeting meet its objective?
• Were time limits respected?
• Were there topics that were not covered?

24
Operations Proposal - 2

• Training process
• Knowledge sharing sessions to distribute domain
  expertise
• Basics of RF propagation
• Training sessions to fill in gaps in
  understanding
• Analysis
• Was a need for training identified?
• Did the training address a gap in understanding?
• Was a training goal defined?

25
Operations Proposal - 3

• Task tracking
• Tools
• Long term tasks MS Project
• Short term tasks ScrumWorks
• Action items Action Item database
• Analysis
• Were all tasks entered into the project
  management system?
• Have all tasks that are completed or closed
  according to the tracking system been verified as
  completed or closed?

26
Operations Proposal - 4

• Configuration management
• Defines what types of artifacts will be
  maintained in what tools
• Wiki
• Subversion
• Analysis
• Have all artifacts been stored using the
  appropriate tool?
• Is the most recent version of an artifact
  available?
• Is the first out-dated version of an artifact
  available?

27
Operations Proposal - 5

• Risk management
• Propose using a Pareto N approach
• Identify and prioritize list
• Analysis
• For each risk identified in the Top N list, does
  a risk mitigation plan exist?

28
Planning Proposal - 1

• Estimation
• Propose to use FP/COCOMO for implementation-relate
  d estimation
• Will use Wideband Delphi until we have more
  historical data
• Analysis
• Was each major task broken down into smaller
  tasks?
• Was each smaller task accurately estimated?
• How accurate was each estimate?
• What was the delta between the estimate and the
  actual effort?

29
Planning Proposal - 2

• Time tracking
• CC Managing Engineer on weekly studio timesheets
• Provides visibility into time spent in studio as
  well as other classes
• Should alert us to resource saturation
• Analysis
• Were timesheets turned in?
• Was time recorded accurately?
• Did availability of time have an overall effect
  on the work produced?

30
Planning Proposal - 3

• Advantages of Scrum
• Separates the work into manageable tasks
• Enforces constant meeetings to monitor progress
  and problems
• Offers flexibility to meet changing requirements
  and priorities
• Enables team members to re-estimate tasks
• Allows the team members to concentrate on
  immediate tasks
• Provides team management with frequent benchmarks
  of progress
• Alerts team management to problems so they can be
  quickly mitigated
• Provides us with an opportunity to explore a new
  management technique

31
Planning Proposal - 4

• Disadvantages of Scrum
• Scrum focuses on short-term rather than long-term
  goals
• There is no mechanism to ensure that tasks on the
  critical path are not removed from a sprint and
  placed in the backlog.
• Scrum is a management technique, not a
  development process.

32
Planning Proposal - 5

• Overcoming Scrum disadvantages
• At the beginning of each semester
• Define overall milestones and deliverables
• Define high level items and estimate
• Break down the items into work blocks and
  estimate
• Assign priorities
• Add work blocks into backlog item
• Add work blocks to the Sprint
• Split work blocks into tasks and estimate
• Assign team member
• Launch the sprint
• Sprint review

33
Current Risks

• Ill-defined scope leads to untenable SOW
• Changing requirements do not converge pushing
  back design
• Domain knowledge is held by single person
• Scrum will prevent us from looking at the bigger
  picture