LCO ARB Team14

1
LCO ARB (Team-14)

• Bhaven Somaiya Project Manager
• Gaurav Rawal Operational Concept
• Vaibhav Bora Software Architect
• Saurabh Kotkar Life Cycle Plan
• Gaurav Mittal Requirement Analyst
• Abhishek Sabnis Prototype Developer
• Tu Lam IVV
• Yilei Jia IVV

2
Topics

• Operational Concept Description (OCD)
• Prototype
• System and Software Requirements Definition
  (SSRD)
• System and Software Architecture Definition
  (SSAD)
• Life Cycle Plan (LCP)
• Feasibility Rationale Description (FRD)

3
Operational Concept Description

• Gaurav Rawal

4
Overview

• Shared Vision
• System Capabilities
• Expected Benefits
• Benefits Chain
• Key Stakeholders
• System Boundary
• Operational Concept

5
Shared Vision

• Organizations need an efficient method to count
  lines of code to estimate the cost and schedule
  for a project.
• Currently, there are variations in how different
  organizations count the SLOC size of the software
  system. We plan to provide a standardized way to
  count the SLOC size so as to minimize any
  inconsistencies.
• This estimate could then be used as the input to
  calculate the cost/schedule estimates using
  COCOMO.
• It would be easy enough so that any person with
  even basic technical knowledge would be able to
  use it.

6
Benefits Chain
7
Shared Vision

• Key Stakeholders
• Client
• Northrop Grumman
• Aerospace Corporation
• USC - CSE
• Developers
• CSCI 577a Team 14 (Including IV V)
• Users (System Maintainer)
• Northrop Grumman
• Aerospace Corporation
• USC - CSE

8
System Boundary
Client Organization
CODE COUNT FAMILY
COCOMO II TOOL

• XML CodeCount
• Process Input XML Files
• Report Generation

REPORT ANALYSIS TOOLS
MANUAL CODE COUNT SYSTEM
9
Proposed New Operational Concept
10
Prototype

• Abhishek Sabnis

11
Prototype

• Importance of Prototyping.
• Demo.
• Conclusion and future prototypes.

12
Prototype

• Importance of prototype
• Bridge the gap between the developers view and
  the clients view.
• Improve the design and share ideas.

13
Prototype

• Demo

14
Prototype

• Output for correctly formatted, valid XML files.

15
Prototype

• Output for invalid file

16
Prototype

• Case 1 The xml file is not properly formatted.

17
Prototype

• Case 2 The xml file is missing/not found.

18
Prototype

• Conclusions and further prototype
• The error processing abilities for the existing
  CodeCounters that have to be enhanced and
  incorporated in our CodeCounter.
• We will decide which environment variables are
  required by the user for viewing the output in a
  particular format.
• How we will produce the output as a .csv file.
• The ability of the CodeCounter to count embedded
  code ( eg. Javascript embedded within XML).

19
System and Software Requirements Definition

• Gaurav Mittal

20
System and Software Requirements Definition

• Outline
• Project Requirements
• Capability (Functional) Requirements
• System Interface Requirements
• Level Of Service Requirements
• Version, States and modes
• Evolutionary Requirements

21
Project Requirements
22
Project Requirements
23
Project Requirements
24
Project Requirements
25
Project Requirements
26
Capability Requirements
27
Capability Requirements...
28
Capability Requirements
29
System Interface Requirements
30
Level Of Service Requirements
31
Version, State and Mode

• Version must change as the software is updated.
• Only Operational Mode.

32
Evolutionary Requirements
33
System and Software Architecture Definition

• Vaibhav Bora

34
System and Software Architecture Definition

• Use Cases
• System Static Structure
• System Artifacts
• CodeCount Process Details
• Hardware Software Classifier Models

35
Use Cases
36
Static Structure
37
System Artifacts
38
CodeCount Process
39
Hardware Classifier Model
40
Software Classifier Model
41
Life Cycle Plan

• Saurabh Kotkar

42
Overview

• Introduction
• Assumptions
• Life Cycle Strategy
• Developer Roles
• Monitoring and Control
• Effort Estimation

43
Introduction

• LCP serves as a basis for monitoring and
  controlling projects progress.
• Helps make best use of resources throughout the
  systems life cycle.
• Helps to plan major life cycle issues in advance.

44
Assumptions

• 24-week schedule, 12 weeks for Engineering Stage
  and 12 weeks for Production Stage.
• Requirements remain fairly static during the
  Elaboration and Construction Phase.

45
Life Cycle Strategy

• Overall Life Cycle Strategy would be based on Win
  Win Spiral Model.
• Major Milestones and their completion dates
  constructed using MS Project Plan.
• Heres a snapshot of MS Project Plan.

46
Life Cycle Strategy
47
Life Cycle Strategy

• The deliverables at the end of Engineering Stage
  would comprise of the LCO and LCA versions of
  OCD,SSRD,SSAD,LCP and FRD.
• These documents form the architectural basis of
  the system to be built during the Construction
  phase.

48
Developer Roles
49
Monitoring and Control

• Weekly Effort Report
• Weekly Progress Report
• Weekly MS Project Plan
• DART for risk assessment
• Tri-Weekly Team meeting
• Agile Internal Reviews

50
Effort Estimation

• COCOMO II has been used to calculate the overall
  efforts required for the project.
• The snapshot of the COCOMO results as well as the
  scale and cost driver values are as follows

51
Effort Estimation
52
Effort Estimation
Scale Factors
53
Effort Estimation
Cost Drivers
54
Effort Estimation
Cost Drivers
55
Effort Estimation
56
Feasibility Rationale Description

• Bhaven Somaiya

57
OUTLINE

• Purpose
• Business Case Analysis
• Level of Service Feasibility
• Process Model Decision
• Risk Assessment

58
Purpose of Feasibility Rationale Description

• To give an understanding of whether all the
  artifacts (like OCD, SSRD, SSAD, LCP) are
  consistent with the project and are
  non-conflicting with one another.

59
Business Case Analysis

• Cost Analysis

60
Benefits Analysis

• Mutual Win-Win for all the stakeholders of the
  project.
• No direct monetary benefits
• Generic Code Counter
• Documentation using MBASE guidelines

61
Return On Investment
ROI analysis
62
Break-even Analysis
63
Level of Service Feasibility
64
Process Model Decision Table
65
Risk Assessment

• Critical Risks
• Requirement mismatch
• Change in User Requirements
• Non-Critical Risks
• Lack of Personal Continuity
• Risk of going over schedule

66
Thank you