architecture review boards foundation commitment review

University of Southern CaliforniaCenter for Systems and Software Engineering

Architecture Review BoardsFoundation Commitment Review

Fall 2012 Team 3Nov. 2nd , 2012

Web Based Product Configurator

And Data Service System


2

Internal Independent Verification and Validation

JORDAN PADAMS


3


• Team Strong/Weak Points• Technical Concerns and Solutions• Operational Risks• WinWin Shaping Status• Project Evaluation

Agenda


4


• Operational View– Dev Team and Client Communication

• Technical View– Prototype development

Team Strong Points


5


• Operational View– Separation of concerns

• Technical View– Experience

• Web development• Embedded systems• Cellular technologies

Team Weak Points


6


• Unknown requirements surrounding sensor telecom module– Prerequisite for data ingest service– Unsure what will/will not be included with

module– Could effect requirements

• Solution– Client understands risks– Leverage incremental commitment model– Prototype potential data ingest services

Technical Concerns


7


• Future System Maintainer Unknown– May not be web savvy

• Mitigations– WYSIWYG interface for maintaining web content– Extensive documentation for system

Operational Risks


8


• 10 Open WinCs– Known nice-to-have features– Evolutionary

• 11 Agreed WinCs without issues• 7 Agreed WinCs with issues

WinWin Shaping Status


9


• SCS – Highly involved, enthusiastic• Precedentedness – Low/Nominal• Communication

– Email– Telecons– join.me

• Skills and experience are adequate

Project Evaluation


10

Operational Concept Description

JIZHOU LU


11


• System purpose• Shared vision -Benefit-chain diagram -System boundary• Proposed new system• Desired capabilities and goals

Agenda


12


• Our client Somatis, a start-up company• They sell hardware solutions in the

robotic and sensor industry• The sales and After-sale service need

support by our system• To increase customer satisfaction,

company reputation, sales and profits

System Purpose


13

Operational Concept DescriptionBenefit-Chain Diagram – Part

I


14

Operational Concept DescriptionBenefit-Chain Diagram – Part

II


15


System Boundary


16

Operational Concept DescriptionCurrent Company Business

Workflow


17


Proposed New Business Workflow – Part I


18


Proposed New Business Workflow – Part II


19

Operational Concept DescriptionDesired Capability

GoalsCapability Goals Priority level

Sensor Configurator: allows customer to customize product and place the order.

Must have

Sensor Data Service: inputs data from customers' sensor and provides an interface to manage the sensor data.

Must have

Website Improvement: - User Forum - Notification Service - Social Media - Content Update - Checkout

Must have Must have Potentially have Potentially have Potentially have Potentially have


20

Operational Concept DescriptionDesired Level of Service

GoalsLevel of Service Goals Priority

Multi browser support 9

Maximum 50% down time for the website and sensor configurator

8

Maximum down time of 2 hours/month for the sensor data service.

8

At least 1 person can access sensor data service any time, possible 10 people in the future.

10


21


• Increase profits for the company.• Increase data availability of sensor data

service.• Further increase efficiency of data

management.• Increase flexibility of sensor module

features, strengthen the communication with the system.

• Create marketing tools

Desired Organizational Goals


22

Requirements

QIUYANG LIU


23

Requirements

Requirements for Three Major Components

• Sensor Data Service– Data Ingestion Module– Data Manipulation Module

• Sensor Configurator• Website Improvement

Agenda


24

RequirementsData Ingestion Module• System can store incoming data to

database

• Customer have X MB data for free, and is able to purchase more

• Notification to users based on sensor events


25

RequirementsData Manipulation Module• Export data to external files, i.e. CSV

• View, Search and Manage Data


26

RequirementsSensor Configurator• Customer login by personal username

and password• Novice:

– Customer s will be guided by list of questions– Most suitable combination will be selected

• Expert:– All of the sensor parts will be listed with detail

specs– Customer will be able to tailor the product at will

• Notification to sales department• Order confirmation emails


27

RequirementsWebsite Improvement• Dynamic / Static Content update

• Social Media Integration

• User Forum– Customer Service– Discussion for products


28

RequirementsMiscellaneous• $2500 Budget• 2 Hours/month downtime for database• 10 concurrent user • Maximum 50% downtime for website• Support major browsers (IE, Chrome, Firefox

and Safari)


29

Prototype

XIANAN FAN


Agenda• Website Mock-up Design• Wordpress Based Homepage• Initial Configurator Prototype• Initial Data Ingest Service

Prototype

30


Balsamiq Mock-up

31

Homepage

Win Conditions:• View Dynamic

Content

• View Static Content


Balsamiq Mock-up

32

Data Manager PageWin Conditions:• View and

Search Ingested Data

• Manage Data

• Export Data to External Files


Balsamiq Mock-up

33

Mode Selection PageWin Conditions:• Customize

Product based on Expertise

• Provide Different Customization Path (i.e. Questions VS. Detailed Specs)


Balsamiq Mock-up

34

Novice ModeWin Conditions:• Guided by

Questions in Novice Mode

• Be able to Config Sensor, Com, Power Supply and Services


Balsamiq Mock-up

35

Expert ModeWin Conditions:• Detailed Specs

are Shown to Help Selection

• Be able to Config Sensor, Com, Power Supply and Services


Wordpress Based Homepage

36

Homepage Prototype

Implemented in Wordpress• Unified theme

Features:• YouTube Integration

for Company Introduction

• Live Facebook Posts Support

Other Pages in Progress


Configurator

37

Configurator Prototype

Features:• Summary

Updated in Real Time

• Tabbed View

• Animation


Data Ingest Service

38

Data Ingest Service Prototype

Features:• Pub/Sub model for handle incoming data

• POSIX for multi-thread

• Python mock data


DEMO

39


40


41

Architecture

DIAN PENG


42

ArchitectureAgenda• Top Level Overview• NDI/COTS Selection

–CMS Platform - Website–Configurator

• Newly Developed Code• Physical Deployment


Top Level Overview

43

• The system has 3 sub-systems• The system connects with clients through

Internet


NDI/COTS Selection

44

• Take advantage of existing codebase for website improvement and sensor configurator

• However, NDI/COTS can’t meet all requirements of the above 2 sub-systems

• Possible NDI candidates for these 2 sub-system are WordPress and Joomla


NDI/COTS SelectionCMS Selection - Wordpress

45

WordPress

Content UpdateModule

Account

ModuleProductConfigu

ratorModule

Pub/Sub

ModuleUser Forum

100%0%

0% 90%

100%

SocialMedia

100%


NDI/COTS Selection

46

Advantages:1. Very flexible way to extend the codebase.2. Good community supporting and huge amounts of

third party plugins.3. Easy to use and user friendly interface.4. Complete documentation.5. Light-weight and good for content heavy website.Disadvantages:6. Lacks good account security coping mechanism.7. Lacks direct support for CMS like Joomla.

Pro and Con of Wordpress


NDI/COTS SelectionCMS Selection -

Joomla

47

Joomla

Content UpdateModule

Account

ModuleProductConfigu

ratorModule

Pub/Sub

ModuleUser Forum

70%10%

0% 90%

80%

SocialMedia

0%


NDI/COTS Selection

48

Advantages:1. Very easy and flexible to build a new website2. Attractive website templates and many great

extensions.3. Good documentation.4. Good community support.5. Fit for large company website developing.Disadvantages:6. Joomla is not easy to use compared to WordPress.7. Joomla development task more effort than WordPress.8. Joomla contains too many functionality which is

useless for our project.

Pro and Con of Joomla


NDI/COTS Selection

49

Targets:1. Clients requires the website easy to maintain and update ,since

he is not the web technology expert.2. The development team hopes the developing stage to be agile

and without too heavy testing.3. The schedule does not allow us to use too complicated

technology.

Value Based Decision Making

Reasoning:1. WordPress is easy to tailor and easy to maintain by none-expert person.2. WordPress is fit for middle and small scale website , even with complex

requirements for e-commerce and content management.3. Even later we find out that WordPress is not fit for the development , the

existed WordPress codebase can be imported into Joomla by importer

WordPress


Newly Developed Code

50

• No NDI/COTS available• Requirements:

– It should use private protocol built on TCP/IP to communicate with sensor for security reason.

– It should handle evolution and QOS requirement properly.– It is the most significant module in the system and has

highest priority.• Current Prototype:

– Use multi-thread and multi-process architecture.– Develop by pure C language.– Make the server software cross-platform.

Data Ingestion Service


Physical Deployment

51


Life Cycle Plan

52

FEI QU


53

Life Cycle Plan

Agenda• Life Cycle Strategy• Key Stakeholders’ Responsibilities• Project Plan• Resource Estimation


Life Cycle Strategy

54

• Duration: 11/03/12- 12/12/12 • Concept: Design system architecture,

improve prototypes based on feedback from the client, plan for the development phase.

• Deliverables: DC Package• Milestone: Development Commitment

Review• Strategy: Incremented Commitment Model

for Architected Agile Process

Foundation Phase


Key Stakeholders’ Responsibilities

55

Team Member/Role ResponsibilitiesFei Qu:Project Manager Life Cycle Planer

• Make the project plan.• Track the project progress.• Design the architecture of the

data manipulation module of sensor data service.

Jizhou LuOperational Concept EngineerFeasibility Analyst

• Analyze the project feasibility.

Xianan FanPrototyper

• Improve the prototype based on the client’s feedback.

• Help the client with the prerequisite module.


Key Stakeholders’ Responsibilities

56

Team Member/Role ResponsibilitiesDian PengSystem Architect

• Design the architecture of the data ingest module of sensor data service.

• Design the architecture of the current website improvement module.

• Polish the prototype which listens to the sensor data.

Qiuyang LiuRequirements Engineer

• Update winbook when requirements change.

• Design the architecture of the sensor configurator module.

Jordan PadamsIIV&V

• Review artifacts. • Facilitate the meeting

with the client every week.

Nick Wettels:Client

• Provide a solution to the prerequisite module.

• Have weekly meeting with dev team.


Project Plan

57


Resource Estimation

58

• Estimated CSCI577a Effort : 6 team members at 9 hrs/week for 12 weeks

• Estimated CSCI577b Effort : 6 team members at 9 hrs/week for 12 weeks

• Total estimated effort: 9.2PM• Budget information: $2500• Project duration: 24 weeks• Component modules in your development project:

Sensor Data Service(Data Ingest Module, Data Manipulation Module), Sensor Configurator, Current Website Improvement

• Programming language used: PHP, Java, C

Overview


Resource Estimation

59

COCOMO Scale Driver

Scale Driver Value RationalePREC LO Data ingestion

module is uncommon. FLEX NOM We have some

relaxation. RESL NOM Since we don’t have

hands-on experience on some parts of the project, there maybe some redesign.

TEAM NOM We cooperate well, but there’s still some room to improve.

PMAT NOM CMM Level 2


Resource Estimation

60

COCOMO Cost Driver – Configuration ModuleCost Driver Value RationaleRELY NOM Reliability is important, but

most problems won’t cause severe consequence.

DATA NOM 10 <= D/P <=100DOCU NOM Our document just has the right

size for lifecycle needs. CPLX NOM We are using wordpress for this

module, but there’re still some parts uncovered by the CMS.

RUSE LO Across project is enough for this project.


Resource Estimation

61

COCOMO Cost Driver – Configuration Module Cont’dCost Driver Value RationaleTIME NOM No big time constrain for this

project. STOR NOM We may need to buy extra

storage space, but after that, everything should be fine.

PVOL LO No frequent big change to our platform.

ACAP NOM Our analysis capability is decent.

PCAP NOM Although not many of us programmed in industry before, but we have solid programming skills.

PCON HI It’s very likely all of us will continue to take csci577b.


Resource Estimation

62

COCOMO Cost Driver – Configuration Module Cont’dCost Driver Value RationaleAPEX LO Although some of us have

experience with e-commerce app, none of us has developed a website for a real company.

LTEX LO None of us used wordpress before and not all of us is experienced with PHP.

PLEX NOM We are experienced with the platform we use here.

TOOL NOM We’re going to use wordpress, it can make our life easier.

SITE VHI It’s fully collocated and it’s an e-commerce website.


Resource Estimation

63

COCOMO Cost Driver – Data Ingestion Service

Cost Driver Value RationaleRELY NOM Reliability is important, but

most problems won’t cause severe consequence.

DATA NOM 10 <= D/P <=100DOCU NOM Our document just has the

right size for lifecycle needs. CPLX HI This module is the most

complex one in the project. We need to write a daemon.



Resource Estimation

64

COCOMO Cost Driver – Data Ingestion Service Cont’dCost Driver Value RationaleTIME NOM No big time constrain for this

project. STOR NOM We may need to buy extra storage

space, but after that, everything should be fine.


ACAP NOM Our analysis capability is decent. PCAP NOM Although not many of us

programmed in industry before, but we have solid programming skills.



Resource Estimation

65

COCOMO Cost Driver – Data Ingestion Service Cont’dCost Driver Value Rationale

APEX VLO This module is totally new to all of us.

LTEX NOM We’ll use C or Java which we are kind of familiar with.


TOOL LO Not much some powerful tools there we can use.



Resource Estimation

66

COCOMO Cost Driver – Data Manipulation ModuleCost Driver Value RationaleRELY NOM Reliability is important, but most

problems won’t cause severe consequence.

DATA NOM 10 <= D/P <=100DOCU NOM Our document just has the right

size for lifecycle needs. CPLX NOM Search part seems to be a little

tricky, but there should be some tool out there.



Resource Estimation

67

COCOMO Cost Driver – Data Manipulation Module Cont’dCost Driver Value RationaleTIME NOM No big time constrain for this project. STOR NOM We may need to buy extra storage







Resource Estimation

68

COCOMO Cost Driver – Data Manipulation Module Cont’dCost Driver Value RationaleAPEX LO We have some experience on web

app, but not a product for a real company. Also search part is new to us.

LTEX NOM PHP and Java shouldn’t be a problem for us.


TOOL NOM We’ll use WordPress. SITE VHI It’s fully collocated and it’s an e-

commerce website.


Resource Estimation

69

COCOMO Cost Driver – Website ImprovementCost Driver Value RationaleRELY NOM Reliability is important, but most

problems won’t cause severe consequence.

DATA NOM 10 <= D/P <=100DOCU NOM Our document just has the right size

for lifecycle needs. CPLX LO Most features needed here are partially

provided by wordpress. RUSE LO Across project is enough for this

project.


Resource Estimation

70

COCOMO Cost Driver – Website Improvement Cont’dCost Driver Value RationaleTIME NOM No big time constrain for this

project. STOR NOM We may need to buy extra storage







Resource Estimation

71

COCOMO Cost Driver – Website Improvement Cont’dCost Driver Value Rationale

APEX NOM Some basic operations out there.

LTEX LO WordPress is new to us.


TOOL NOM We’ll use WordPress.



Resource Estimation

72

Screenshot of COCOMO Result


Resource Estimation

73

Analysis of COCOMO Result

• Given full-time project personnel generally spend about 110 work hours per person month, and a CS577 developer will spend 12 hours/week times 15 weeks or 180 work hours, 6 of us as a team can put effort 6*180/110 = 9.82 person month. It’s slightly higher than the most likely person month by COCOMO, but in the pessimistic situation, we may not be able to finish, so we should focus on core features first. If time allows, we’ll go back to lower-priority features.


74

Feasibility Evidence Description

DIAN PENG


75


Agenda• Current Business Workflow• What We Can Provide and Benefits• NDI/COTS Benefits And Limitations• Major Risks and Mitigation Plan


76


Current Business WorkflowCurrent Business Case:• The customers make phone calls to the company

to order the sensor productAnalysis of Current Business Case: • Slow , not efficient.• Can not provide sensor data service which should

be the major profits source of the company.• Not able to handle large customers requests.• Lacking customer service facilitators.• Not an e-commerce company.


77


What We Can Provide1. Provide customer service

facilitators.• The system we

built will meet the customer service requirements. We will provide forum , social media for the customer.

2. Provide additional data

service for company.

• The system we deliver can handle sensor data service and provide user a web-based data viewer.

3. Entirely change the

original business flow.

• The system we provided will allow all the current business flow shift to the web-based business environment. The customer can purchase the product in the browser.

• We also provide graphical user interface for user to configure their product.


78


Benefits from Our Work

Reduce complexity for purchasing customized sensor products.Increase availability for data remotely.

Maintain current level of service

Increase system availability for customer

Decrease data monitoring efforts.


79


Benefits of NDI/COTS

NDI can help team develop prototype for websites thus

helping eliciting the hidden

requirements.

NDI can help team develop the front-end UI for the websites ,

since all the team developer are not professional web

UI designer .

NDI can reduce the risks of UI

design problem which may be

caused by developer lacking ability to do the right UI design.


80


Limitations of NDI/COTS• NDI can not help us develop sensor data service

subsystems.• Although certain middleware provides such

functionality , they are very expensive which ruins the requirements of budget.

• This part is the major profits source , the security requirements should be considered at highest priority .

• Building from scratch should be valid choice given the budget and security requirements.


81


Major Risks

• Large scale concurrent sensor data ingesting

requests.

• Unclear target hardware information.

• Storage availability for sensor data service.


82


Mitigation Plan• Large concurrent problem can be handled by

facilitating multi-process plus multi-thread architecture.

• Much more client interaction and prototype can reduce the risk.

• Clouding storage provider should be considered since the fee for clouding storage is typically very low and grow linearly.


83

Quality Focal Point

JORDAN PADAMS


84

Quality Focal Point

Agenda• Traceability Matrix• Defect Identification• Defect Injection and Removal


85

Quality Focal Point

Traceability MatrixOCD WinWin

Agreement SSAD Test Case

OC-1WC_1432 WC_1433 WC_1434 WC_1435 WC_1436 WC_1437 WC_1438

UC-17 UC-18 N/A

OC-2 WC_1431 WC_1430 WC_1429

UC-1 UC-2 UC-3 UC-7 N/A

OC-3WC_1423 WC_1424 WC_1425 WC_1426 WC_1427 WC_1428 WC_1505

UC-15 UC-16 N/A

OC-4 N/A N/A N/AOC-5 WC_1422 UC-10 UC-11

UC-20 N/AOC-6 WC_1421 N/A N/AOC-7 WC_1418 WC_1419

WC_1420 UC-5 UC-22 N/A

OC-8 WC_1415 WC_1416 WC_1417

UC-19 UC-4UC-6 N/A


86

Quality Focal Point

Defect Identification• Peer reviews

– Informal• Dropbox maintains documents• Reviewed by team members as needed• Weekly meeting discussions• Face-to-face brainstorming sessions

– Formal• IIV&V performs verification and validation of products

• Bugzilla– Track identified issues– Use comments to discuss solutions

• WinBook– Track requirement defects/concerns


87

Quality Focal Point

Defect Injection and Removal

FEDLCP

OCDPRO

SIDSSAD

0

2

4

6

8

10

12

14

16

18

Exploration

Valuation

Bugs By Component

ExplorationValuation

Component

Bugs


88

Quality Focal Point


Exploration Valuation

FED 2 6

LCP 2 9

OCD 16 10

PRO 0 3

SID 0 3

SSAD 0 17

TOTAL 20 48

Bugs By Component


89

Quality Focal Point


blockermajor

normalminor

trivialenhancement

0

2

4

6

8

10

12

14

16

18

Exploration

Valuation

Bugs By Severity

ExplorationValuation

Severity

Bugs


90

Quality Focal Point

Defect Injection and RemovalBugs By Severity

Exploration Valuation

blocker 0 1

major 3 4

normal 7 17

minor 5 7

trivial 5 3

enhancement 0 16


91

Quality Focal Point


FED LCP OCD PRO SID SSAD0

2

4

6

8

10

12

14

16

18

Valuation Bugs by Component and Severity

enhancementtrivialminornormalmajorblocker


Thank You!

Questions?

architecture review boards foundation commitment review

Documents