architecture review board team 9 city of los angeles public safety applicant resource center

Architecture Review BoardTeam 9

City of Los Angeles Public Safety Applicant Resource Center

Team MembersDivya Nalam: Operational Concept EngineerVaibhav Mathur: Project ManagerArijit Dey: Life Cycle PlannerPreethi Ramesh: Feasibility AnalystShreyas Devaraj: Requirements EngineerGaurav Mathur: BuilderRakesh Mathur: IIV & V, Quality Focal Point

ClientsDavid Lubely, Group Supervisor

Keith G GilesInformation Technology Manager

Kori ParragaLead Investigating Officer

InstructorsDr. Barry BoehmDr. Supannika KoolmanojwongNupul KukrejaDaniel Link

2

Outline• Requirements Engineering• Life Cycle Plan• Operational Concept Design• Feasibility Evidence• Architecture• Prototype Demo• Test Plan• Quality Focal Point• Team’s strong and weak points

Requirements Engineering

By Shreyas Devaraj

4

WC_2395 - As a Support staff I can enter the candidate information(Name, Last 4-digit SSN and the department) and email addresses of the references to generate emails to references quickly.

WC_2393 - As an investigator I can view reference letters

WC_2394 - As a Reference I can complete the reference letters online.

Most Significant Requirements(in the order of priority)

5

WC_2396 - As an Investigator, I can review candidates assigned to me.

WC_2454 - As a Manager I can easily see the list of candidates assigned to any Investigator.

WC_2402 - As an Investigator, I can securely log in to the system to review the references.

Most Significant Requirements(in the order of priority)

Life Cycle Plan

By Arijit Dey

7

Life Cycle PlanOutline• Introduction

• Purpose• Status

• Milestones and Products• Responsibilities• Approach

• Monitoring and Control• Methods, tools and Facilities• Project plan

• Resources• Estimation using COINCOMO • Iteration plan

8

INTRODUCTIONPurpose• The Life Cycle plan helps the stakeholders to get a clear picture of

– what are the objectives to be achieved, – when are the milestones & deadlines, – what are the products which needs to be delivered, – what are the responsibilities – what should be the approach towards it, – what resources we have, and – what are the assumptions in regard to this project.

Status– The present status of the project is at the end of Foundation phase. This LCP

presently contains the future plans, updated responsibilities for CSCI 577a and CSCI 577b teams, milestones to be encountered in the various phases, project plan and iterations to be performed. Also, an estimation of the project using COINCOMO is attached to analyze the project’s feasibility within 12 weeks.

9

Milestones and ProductsOverall Strategy• The City of Los Angeles Application Resource Center is an online

system which built following the architected agile process as we have to develop the project from scratch with minimum COTS involvement.

Products• Client Interaction Report• Valuation Commitment Package• Foundation Commitment Package• Development Commitment Package• Transition Readiness Review Package

10

ResponsibilitiesTeam members Role SkillsVaibhav Mathur Project Manager

PrototyperCurrent- ASP.Net, C#, Javascript

Arijit Dey Life Cycle PlannerRequirements Engineer

Current- JAVA, Oracle 10g, Visual Studio 2012 , HTML, UML.Required- C#, MySQL, DB2

Shreyas Devaraj PrototyperProject Manager

Current- JAVA, MySQL, JavaScriptRequired- ASP.Net, C#

Gaurav Mathur BuilderUML designer

Current-JAVA, C++,MySQLRequired-C#

Preethi Ramesh Feasibility Analyst

Requirement Engineer

Current-ASP.Net, C#

Divya Nalam Operational Concept EngineerUML designer

Current-C/C++, PythonRequired- ASP.Net, C#

Rakesh Mathur Validation and Verification of COTS Interoperability

Current- ASP.Net, C#, JavaScript

11

Skills required for team members in CSCI 577B

• C#• ASP.NET• DB2• UML• BUGZILLA• WINBOOK

12

Roles required for team members in CSCI 577B

• Project Manager• Life cycle planner• Builder• Operational Concept Engineer• Quality Focal Point• IIV & V• Tester

13

APPROACH

Monitoring and Control• Weekly meeting and after class sessions• Progress reports and project plans• BUGZILLA- To raise tasks• Emails- Reviewing• Discussions

14

APPROACH[Contd.]Methods, Tools and Facilities

Tools Usage ProviderVISUAL STUDIO 2012

Used for development of the project. MICROSOFT

SQL SERVER 2008

Used as Database for developing Prototype. MICROSOFT

DB2 Used as Database for developing Project. IBMASP.NET Framework used to develop the Project. MICROSOFTWHATSAPP Used to communicate minute information between

team member.WHATSAPP

SKYPE Screen Sharing tools are used for remote team meetings and desktop sharing

SKYPE / MICROSOFT

15

Project Plan•To track the project’s progress and future increments or events.

16

Project Plan [Contd.]

17

Project Plan [Contd.]

18

Project Plan [Contd.]

19

Project Plan [Contd.]

20

Project Plan [Contd.]

21

RESOURCESThe following is module listed in the system and itsestimated size with Source Lines of Code (SLOC)No. Module Name Brief Description SLO

CREVL

1 Login Functionality Login to the system to access it. 200 8%2 Support Staff module Enter applicant details and add

references600 8%

3 Investigator Module View list of applicants, references and responses

800 5%

4 Reference Module Ability to login and fill up the reference form

300 5%

5 Manager Module Check applicants, investigators and support staff

1000 8%

6 Email Generation Generate automated emails to the references.

200 5%

22

RESOURCES[Contd.]

According to COCOMO II Estimates for CSCI577, one team member effort = 1.67 COCOMO II person months. The total effort put forward by a team of 7 members is 7*1.67=11.69 person months, which is less than the most likely effort. The pessimistic effort from the COCOMO estimation above is 16.37, so the total team members need for this project = 16.37/1.67 = 8.6NOTE:- The scale factor and cost driver details are mentioned in the LCP.

23

ITERATION PLANConstruction Phase• Iteration 1

- Focus on Capabilities with HIGH Prioritya. Email Generationb. Reference Letter Completionc. Reviewing Reference Letters

• Iteration 2- Focus on Capabilities with MEDIUM Prioritya. Reminder Email Sendingb. Manager Modulec. Assignment of Investigators

24

• Iteration3-Focus on Capabilities with LOW Prioritya. Add, Delete or Update Investigator

• Capabilities to be Tested in Iteration 3a. Email Generationb. Reference Letter Completionc. Reviewing Reference Letters

ITERATION PLAN [Contd.]

25

ITERATION PLAN [Contd.]

• Transition Phase– Perform Core Capability Drive through– Improve the System based on Client’s Feedback– Test for other low priority Capabilities

Operational Concept Design

By Divya Nalam

27

PROGRAM MODELAssumptions: The new system will be accepted by the staff of City.

Stakeholders Initiatives Value Propositions Beneficiaries References

Support Staff

Investigators

Managers

City IT staff

Developers

Develop the web based system for reference processing

Provide training to the City staff to use the new system

Maintain the web based system

• Decrease time spent on requesting and processing references

• Decrease number of personnel involved in processing reference letters

• Decrease administrative costs

• Decrease paperwork

Applicants

Supports staff

Investigators

Managers

Costs Benefits

Time spent by client in giving inputs to development team, evaluating prototypes and training staff.

Developer time

Maintenance costs (IT staff)

Hardware Costs:

i) Web Server running Windows Operating System with IIS6 or above

ii) Web Server Hosting on the World Wide Web

iii) DB2 (or SQL Server) Database (Licenses plus hardware/software)”

Decreased costs (postal charges avoided)

Decreased time in sending reference requests and receiving responses

Decreased effort for staff due to avoiding paper work and managers due to electronic monitoring of reference process

Increased efficiency of reference processing

28

BENEFIT CHAIN DIAGRAM

Increased efficiency of

reference processing

Reduced time

Reduced effort

Reduced postal cost

Developer Develop the web application

Maintain the system

Provide training to the staff

Support staff Manager Investigator

Send reference request emails

through the web application

Review investigator

assignments and references online

Review reference letter

online

Send reminder emails through

the web application

Reference

Complete reference form

online  

City IT staff

Manual Work Reduced

29

SYSTEM BOUNDARY AND ENVIRONMENT

Applications: Automated Email Reference letter completion Reference letter viewing Investigator assignment

Support Infrastructure: ASP.net Visual Studio Express DB2 Structured Query Language 

Reference

Investigators 

Managers

Support staff

Email link to reference form

City IT staff

LA Public Safety internal network

(intranet)

Internet

Feasibility Analysis

By Preethi Ramesh

31

Business Case Analysis• Activities

Time Spent (Hours)• Exploration Phase

– Win-Win Negotiation Meetings (2 people * 4 hours + 3 people * 4 hours) 20

– Communication with development team (2 people * 2 hour)4

• Valuation Phase– ARB Meeting to review Progress

2

– Identify missing scope or requirements with Development Team10

– Commit to Hardware/Software Costs of Project – meetings plus Communication10

• Foundations Phase– Assess Prototype and give feedback about Prototype

5

– Plan for Development and Deployment of Project 40

32

Business Case Analysis• Development Phase

– Develop Release Plan with Development Team 20

– Develop Training Plan with Development Team 20

– Perform Core Capability Drive-Through 2

– Give Feedback to Development Team about Development iteration 10

– Deployment of Web System plus database Connectivity with Developer Team 30

– Provide Training for Support Staff & Background Investigators 40

– Maintenance of Database plus Web Application (recurring cost) per year 104

( 2 hours/week * 1 person * 52 weeks)

Total (for one time costs) 213

33

Hardware and Software Costs

Total Cost $0

Type Cost RationaleHosting Web Server running Windows Server with IIS 0 This is the server where the code will reside and where the users (both

internal and external) will access the System

DMZ (De-Militarized Zone) 0 Network Security Setup needed (personnel cost for setting up subnet for Web Server)

Database Back-End DB2 instance which will allow for multiple connections

0 This is the database where all data will be stored.

Disk Space to store Database Back-End DB2 data 0 This is the disk space that will be needed to store database data

Hosting Environment with connectivity to the Internet and World Wide Web

0 Networking and Internet Services Provider costs

34

Quantitative Benefits

Total Cost 3200 hours/ year

Current Activities & Resources Used % Reduce

Time Saved (Hours/Year)

For each candidate, create (type and print) one or multiple ‘Reference Request’ letters Assuming 30 minutes for each application type and print, 2000* 30 minutes = 6000 hours per year 100 1000

Post each letter by mail to the ReferenceAssuming 15 minutes to put reference form into envelope and carrying to be posted, 2000 * 15 minutes

= 500 hours per year100 500

Gather (printed) Reference Request Responses in candidate physical folder Assuming 15 minutes to open reference and properly file it, 2000* 15 minutes = 500 hours per year 100 500

Track References and Reference Letters for candidates in candidate physical folderAssuming 15 minutes to find candidate folder and find reference in folder by Background Investigator,

2000*15 minutes = 500 hours per year 100 500

Assigning Candidates to Background InvestigatorsAssuming 10 minutes to assign candidates and noting assignment in Excel Spreadsheets, 2000*10

minutes, but since assignment still needs to be done, saving is 50 % of that which is 50/100 * (2000*10 minutes) = 167 hours

50 167

Management of Background Investigators and Candidates (done by Managers)Assuming 20 minutes to change/re-assign candidates by looking up physical file and Excel Spreadsheets,

2000*20 minutes, but since re-assignment decisions still need to be made, saving is 80 % of that which is 80/100 * (2000*20 minutes) = 533 hours 80 533

35

Cost Benefit Analysis Worksheet• In our Win-Win negotiations, the Dept. of Public Safety estimated that they process 2000 (two

thousand) applications per year. The values for the benefits derived are based on this number.• Nonrecurring Costs

– System Development & Deployment $8520

($40 per hour, total costs = 213 * 40 = $8520)

• Recurring Costs– Server Maintenance Personnel Cost

$4160 per year

(104 hours per year * $40 per hour = $4160 per year)

● Tangible Benefits – Cost Avoidance

$48000 per year

(3200) * $15 / hr on average = $48000 per year

36

ROI AnalysisYear Cost Benefit

(Effort Saved) Cumulative Cost Cumulative Benefit ROI

2013 8520 0 8520 0 -1

2014 4160 48000 12680 48000 2.78548896

2015 4576 48000 17256 96000 4.56328234

2016 5033.6 48000 22290 144000 5.46041203

2013 2014 2015 2016

-2

-1

0

1

2

3

4

5

6

-1

2.78548896

4.56328234

5.46041203

ROI

Year

ROI

37

Risk Assessment

RisksRisk Exposure

Risk MitigationPotential Magnitude

Probability of Loss

Risk Exposure

Developers not continuing course next semester 10 10 100

This risk cannot be addressed. The project is very likely to be terminated at the end of the Fall Semester.

Schedules for Fall Semester Deliverables 10 7 70Incremental development, negotiate what is deliverable with the client at the end of Fall Semester

Administrator Requirements incomplete - - - Based on top two risks this risk is now moot.

Architecture Diagrams

By Gaurav Mathur

39

Outline• System Context Diagram• Behavior Diagram• Sequence Diagram• Artifacts Diagram• Deployment Diagram• Hardware Component Diagram• Software Component Diagram

40

System Context Diagram

41

Behaviour Diagram

42

SEQUENCE DIAGRAMINVESTIGATOR MODULE

43

Sequence Diagram MANAGER MODULE

44

Sequence Diagram SUPPORT STAFF MODULE

45

Sequence Diagram REFERENCE MODULE

46

Artifacts and Information Diagram

47

Deployment Diagram

48

Hardware Component Design

49

Software Component Design

Prototype Demo

By Vaibhav Mathur

51

Win-Conditions addressed in Functional Prototype

• As a Support staff I can enter the candidate information and email addresses of the references to generate emails to references quickly.

• As a Reference I can complete the reference letters online.

• As an investigator I can view reference letters• As an investigator I can identify the email that were not

responded to and resend the reminder emails.

52

53

54

55

56

Test Plan and Test Cases

By Rakesh Mathur

58

Test Plan• Combination of Code Inspection and Test Plan with Cases is being

used to test the application. • Inspection of the code was done in Buddy/Peer review • Test Plan and Cases were developed based on Functional

Requirements of Project (included in our Test Plan & Cases document)

• Testing done so far is mostly inspection on the code: • Method: Data – Driven tests to test functionality• Levels: Unit Testing and Integration Testing (Big Bang) *• We have not reached the stage of Systems and Acceptance

Testing yet

59

Test Plan (Contd.)

• Strategy used was ‘Requirements-test traceability’, each MMF (Minimum Marketable Feature) was mapped to corresponding Capability Goals (OC) and then Test Cases for those Capability Goals were created.

• Prioritization of Test Cases is Value – Neutral

60

Requirements/ Capability goals Verification Type Test Case ID (if applicable)

WC-2395 Testing TC-1: Email generation

WC-2394 Testing TC-2: Reference response submission

WC-2393 Testing TC-3: Reference response retrieval

WC-2393 Testing TC-4: Reference status review – investigator

WC-2404 Testing TC-5: Reminder sending to reference

WC-2454, WC-2583 Inspection TC-6: Manager reviews

WC-2586 Inspection TC-7: Assignment information submission

WC-2453 Inspection TC-8: Investigator table update

OC-8: Language options Inspection TC-9: Language option for references

Requirements Traceability

61

Test IdentificationTC-1: Email GenerationTC-2: Reference response submissionTC-3: Reference response retrievalTC-4: Reference status reviewTC-5: Reminder sending to referenceTC-6: Manager reviewsTC-7: Assignment information submissionTC-8: Investigator table updateTC-9: Language option for references

62

Example Test Case Test Case Number TC-01-01 Check candidate details update

Test Item The Support staff module is tested by this case. The feature that is tested is the provision for support staff to add new candidate details to the database.

Test Priority M

Pre-conditions The user should be logged in as support staff

Post-conditions The candidate details should be updated in the Candidate Table.

Input Specifications - Candidate first name, last name and last four digits of SSN are should be entered in the support staff homepage.

- Submit button needs to be clicked.

Expected Output Specifications - The candidate details submitted will appear in non-editable form on the screen.- Provision for adding more references to the candidate will be displayed on the screen.

Pass/Fail Criteria Pass criteria: - The candidate details are added to the candidate table if not already present.Fail criteria:- Database update fails and the new candidate details are not added to the Candidate table.

Assumptions and Constraints The user submits only after filling all the fields on the home page.

Dependencies

Traceability WC-2395

63

Traceability MatrixOperational Capability Requirements/ Win Conditions Architecture (SSAD) Test Case

OC-1 WC_2395 UC – Support Staff Module TC-1ATF – Reference Tracking System, ATF – Support Staff

OC-2 WC_2394, WC_2407 UC – Reference USCD TC-2ATF – Reference, ATF – Reference Tracking System, ATF – Reference Form

OC-3 WC_2393 UC - Investigator Module TC-3, TC-4ATF – Investigator, ATF – Reference Tracking System

OC-4 WC_2404 UC - Investigator Module TC-5ATF – Investigator, ATF – Reference Tracking System

OC-5 WC_2583, WC_2454 UC – Manager Module TC-6ATF – Manager, ATF – Reference Tracking System

OC-6 WC_2586, WC_2396, WC_2402 UC – Investigator Module TC-7ATF – Investigator, ATF – Reference Tracking System

OC-7 WC_2453 UC – Manager Module TC-8ATF – Manager, ATF – Reference Tracking System

OC-8 WC_2840

QFP

By Rakesh Mathur

65

Two Sets of Metrics (Burndown Chart)

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 820

10

20

30

40

50

60

Burndown Chart

Completed TasksRemaining TasksIdeal Burndown

Win-Win Negotiation Session 1

FCR ARB

Win-Win Negotiation Session 2

66

Two Sets of Metrics – (Burndown Chart)

The Burndown chart plots “Number of tasks remaining” vs. the week in which the task was completed. The tasks were taken from Bugzilla and each task corresponds to a ‘bug’ in

Bugzilla. The tasks are of all types: defect, enhancement, task, Team Activity etc.

The chart starts at maximum number of tasks, even though tickets were not all opened at the beginning of week 5

A ‘step’ pattern is observed, the size of steps points to how much progress was made in that week.

Inputs: data from Bugzilla report from the Bugzilla online tool Outputs: Expect to know progress week – by – week Benefits: Map progress to figure out where improvements can be made.

67

Two Sets of Metrics (Time Spent on Activity)

05

1015202530

Operational Concept Development

010203040506070

System and Software Requirements De-velopment

05

101520253035

System and Software Architecture Devel-opment

Wk3 Wk 4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10 Wk11 Wk12 Wk13 Wk140

5

10

15

20

Life Cycle Planning

Hour

s spe

nt b

y Te

am

68

Two Sets of Metrics (Time Spent on Activity)

05

10152025

Feasibility Evidence Description

0

5

10

15

20

Quality Management

020406080

100

Implementation

Wk3 Wk 4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10 Wk11 Wk12 Wk13 Wk14012345

Testing

Hour

s spe

nt b

y Te

am

69

Two Sets of Metrics (Time Spent on Activity)

Wk3 Wk 4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10 Wk11 Wk12 Wk13 Wk1405

10152025

Project Administration

Wk3 Wk 4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10 Wk11 Wk12 Wk13 Wk140

20

40

60

80

100

120

Total

Hour

s spe

nt b

y Te

am

70

Two Sets of Metrics (Time Spent on Activity)

The Time Spent on Activity chart plots the time (in hours) spent by our Team on each Activity weekly. The tasks were taken from the Weekly Effort Report submitted by all team members. Charts indicate how our efforts for various activities have changed over the course of

the semester Milestones:

VC Package: 9/27 (Week 4) FCR ARB: 10/17 (Week 8) DC Package: 10/23 (Week 9) DCR ARB: 12/5 (Week 15)

Inputs: data from the Effort Reporting online tool Outputs: graphs show change in effort based on weekly progression over semester Benefits: Graphs indicate effort that has been spent and can be used to figure out whether

we can focusing on the appropriate activities based on the phase we are in.

71

Technical DebtDebt accumulated for web application developed so far• Debt Accumulated

– Use of text string for database queries and updates in ASP.NET instead of SQL Data Layer objects

– Use of SQL queries instead of stored procedures which results in compilation overhead and need for validation of SQL statements using ASP.NET C# code.

– Not using ‘Master page’ in ASP.NET framework thereby having to re-code UI for all pages

• Type: Intentional Technical Debt• Cause: Pressure to complete possible features for delivery by

end of Fall Semester, 2013

Team’s strong points

By Rakesh Mathur

73

Team Strong and Weak PointsTeam Strengths

– Fairly cohesive and highly focused on completing deliverables

– Better communication between Developers and Client

Team Weaknesses– Scheduling issues due to larger team & varying class

schedules– Time Management – finishing work close to deadline

74

Project Concerns

Technical ConcernsAbility to deliver working code without Systems Testing

Solution: Test the functionality while we are developing it which is what we have been doing.

Operational ConcernsNone of the current set of students are continuing with the course next

semester. Solution: This two semester project most likely will not be developed by another team in the Spring of 2014. This risk is not addressable.

75

Project ConcernsSources of Observation

– Client Interaction– Client Site Visits– Team Meetings– Team Communication– Evaluation of FC package

• FED (Feasibility Evidence Description)• OCD (Operational Concept Description)• LCP (Life Cycle Plan)• SSAD (System & Software Architecture Description)

Thank you!