University of Southern California Center for Systems and Software Engineering CS 577b: Software Engineering II Class Introduction.

University of Southern California

Center for Systems and Software Engineering

CS 577b: Software Engineering II

Class Introduction



Outline

• Schedule– Guest Lecturers– TechTalk– Pair Research Presentation

• Marks Allocation• Possible 577b risks• Team Re-Formation

(C)USC-CSSE 2



Course Schedule

• See– http://greenbay.usc.edu/csci577/spring2014

• Class settings– 6:40pm – 8pm: Lecture– 8:15pm – 9:20pm: Class Activities

• No Class, but team presentations/reviews on– Rebaselined DC ARB – Week of 02/12– Design Code Review – Week of 03/05– Core Capability Drivethrough – Week of 03/26– Transition Readiness Review – Week of 04/16

(C)USC-CSSE 3

http://greenbay.usc.edu/csci577/spring2011/schedule.php

http://greenbay.usc.edu/csci577/spring2011/schedule.php



Milestone Reviews• Rebaselined Development Commitment

Review• Design Code Review• Core Capability Drive thru• Transition Readiness Review



Milestone review

©USC-CSSE 5

Design Review Code Review

Technology Interchange Meeting Retrospective

meeting

SPRINT REVIEW



The Incremental Commitment Spiral Model

6©USC-CSSE



(C)USC-CSSE 7

ICSM –Class Milestones

2/12 3/26 4/16 4/303/5

Code Review



(C)USC-CSSE 8


Center for Systems and Software EngineeringUniversity of Southern California


9 4

ARB Review Success Criteria

FCR DCRFor at least one architecture, a system built to arch. will:

• Support the Ops Concept• Satisfy the Requirements• Be faithful to the Prototype• Be buildable within the budgets and

schedules in the Plan• Show viable business case

Key stakeholders committed to support Foundations Phase (to DCR)

For the selected architecture, a system built to the arch. will:

• Support the Ops Concept• Satisfy the Requirements• Be faithful to the Prototype• Be buildable within the budgets and

schedules in the Plan

All major risks resolved or covered by risk management plan

Key stakeholders committed to support full life cycle



Commitment Review Success Criteria

10

TRR / OCR

• Show value• Product works as expected (or not

with noted exceptions)• Product will help users do job

• Show quality development• e.g. relevant parts of your

• IOC documentation• Process

• Show sustainability • e.g. support requirements/plans

• Transition plan & status• Show confidence that product is/will

be ready to be used• e.g. Transition plan & status

• See also value

• Determine whether client needs anything further to ensure successful Transition and Operation• Changes in priorities for

remaining features?• Changes being made to

operational procedures?• More materials needed for

training?• Changes in system data or

environment we should prepare for?

• Anyone else who should experience CCD?

CCD




11 11

ARB Session Outline• RDCR similar format to DCR, different focus:

More time on changes and updatesMore time for Architecture, Plans

• General rule on focus: emphasize your projects high risk areas– At FCR (in most cases) this will involve

establishing the operational concept (including system analysis)

– At DCR (in most cases) this will involve the system design and development plan (especially schedule)

– At RDCR this will involve the system design and development plan and test plan



RDCR ARB topics

• Topics to cover in your presentation & recommended time allocations– Summary of Change Sources & Resulting

Changes– Progress of Prototype– Construction Plans; Transition Plan Draft– General Discussions– Risk analysis to determine course of actions

12




13

RDCR ARB – Architected Agile Teams(x,y): (presentation time, total time)(8, 10) Acceptance Test Plan and Cases; Team's strong and weak points + Shaping

& Overall Project Evaluation; Full test plan and cases(2, 3) OCD. System purpose; changes in current system and deficiencies,

proposed new system, system boundary, and desired capabilities and goals; top-level scenarios

(10,15) Prototype Update. Changes in significant capabilities (especially those with high risk if gotten wrong)

(8, 10) Architecture. Overall and detailed architecture; design if critical; COTS/reuse selections (NOT JUST CHOICES)

(6, 8) Life Cycle Plan. At lease until CCD or as appropriate; Include plans for CTSTeam members’ roles & responsibilities in 577b, Full Iteration Plan

(5, 10) Feasibility Evidence. Focus on Risk Analysis. Traceability Matrix. Definition of Done, Metrics

• Plan on 2 minutes per briefing chart, except title• Focus on changes (particularly new things) since DCR• You may vary from the above: please notify ARB board members IN ADVANCE• QFP & QMP not presented/discussed due to time constraints.




14 14

RDCR ARB – NDI-intensive Teams(x,y): (presentation time, total time)(8, 10) Acceptance Test Plan and Cases; Team's strong and weak points + Shaping

& Overall Project Evaluation; Full test plan and cases(2, 3) OCD. System purpose; changes in current system and deficiencies,

proposed new system, system boundary, and desired capabilities and goals; top-level scenarios

(10,15) Prototype Update. Changes in significant capabilities (especially those with high risk if gotten wrong)

(5,7) Architecture. Overall and detailed architecture; design if critical; COTS/reuse selections (NOT JUST CHOICES)

(6, 8) Life Cycle Plan. At lease until CCD or as appropriate; Include plans for CTSTeam members’ roles & responsibilities in 577b, Full Iteration Plan

(5, 10) Feasibility Evidence. Focus on Risk Analysis, Traceability Matrix. Definition of Done, Metrics

• Plan on 2 minutes per briefing chart, except title• Focus on changes (particularly new things) since DCR• You may vary from the above: please notify ARB board members IN ADVANCE• QFP & QMP not presented/discussed due to time constraints.



Grading GuidelinesTotal = 50 points

(20) Progress of your work

(10) Presentation

(5) Risk Management

(15) Quality

4/2/2012 15(C) USC-CSSE



Milestone review tasks

• Prepare for milestone review– Set scope

• Schedule review meeting• Distribute meeting materials• Conduct review meeting

– Progress, Quality, risk profile, feasibility

• Record decision

©USC-CSSE 16







©USC-CSSE 18



Internal Code Review

19©USC-CSSE



Outline• Problems & Motivation• Faithful vs. Unfaithful• Preparation and Review Process

4/2/2012 20(C) USC-CSSE



Motivation• To aid with successful transition• Ensure that implementation is faithful to the

design– Or at least consistent

• Sufficient documentation for maintenance period– Ease software understanding– Enable evolutionary development

4/2/2012 21(C) USC-CSSE



Problems• When implementation and design are

different– The only way to understand implementation is

to read through code– Documented artifacts appear useless – Wasted efforts and time

• Ultimately, Lose-Lose situation– Unhappy clients– Unhappy developers bugged by clients– Unhappy maintainers

4/2/2012 22(C) USC-CSSE



Architectural Drift• Classic problem in software engineering

and software maintenance• Often happen slowly during implementation

– Developers feel changes are minor– Effects of changes multiply

4/2/2012 23(C) USC-CSSE



Requirements-to-Code Elaboration

• Impact factor from one step to the next

• Increase in number of “statements”

• Clearly, significant impact when changes made to early stages

Objective

Shall Statements

Use-Case

Use-Case Steps

SLOC

x 2.46

x 0.89

x 7.06

x 66.91

* Ali Afzal Malik, Supannika Koolmanojwong, Barry Boehm. “An Empirical Study of Requirements-to-Code Elaboration Factors

4/2/2012 24(C) USC-CSSE



Faithful Implementation• The definition• Structural elements Source code

– All should be there

• Source code must not utilize new major computational elements not specified in architecture

• Source code must not contain new connections not found in architecture

• Can we deviate from this?

4/2/2012 (C) USC-CSSE 25



Unfaithful Implementation• The implementation has its own

architecture– Implementation is the architecture

• Impacts of failure to recognize distinction between designed and implemented architecture – Ability to reason about application’s

architecture in future– Misleading (what they think vs. what they have)– Evolution strategies based on documented

architecture doomed to failure

4/2/2012 (C) USC-CSSE 26



Two-Way Mapping• This is what should have been done• Changes can be discovered during design

or implementation phases– What to do?– How to effectively handle?

4/2/2012 27(C) USC-CSSE



Design to Implementation• Decide to first visit the design

– Update the design– Review the changes– Implement according to the new design

• Always have a “blue print” to refer to• Architects may have more understanding

on impact of design changes– Easier to foresee future impacts

4/2/2012 28(C) USC-CSSE



Implementation to Design• Changes made to the implementation

immediately– Then trace back to design– Update design to reflect new implementation

• Easier from developers perspective• Many changes may have been missed in

design update• Difficult to foresee future effects

– Unless highly experienced

4/2/2012 29(C) USC-CSSE



Preparation• Source code files

– As implemented

• SSAD and UML models• Personnel

– Must be present:• Developer (coder)• Architect(s)

– Optional• Other team members

4/2/2012 30(C) USC-CSSE



Review Process• Mainly done with code tracing and walkthrough• Design patterns / Architecture frameworks

– Which is specified in SSAD?– Meet the standards?

• Design classes vs. Implemented classes– Consistent attributes– Consistent operations

• Use-case tracing– Consistency between use-case behavior and

implementation

4/2/2012 31(C) USC-CSSE




(3) Faithfulness to design patterns / architecture frameworks

(5) Faithfulness in design classes to implemented classes mapping

(5) Accuracy of implemented Use-Case behaviors

(2) Overall

4/2/2012 32(C) USC-CSSE







Core Capabilities Drive-thru

©USC-CSSE 34



©USC-CSSE 35http://justincaseyouwerewondering.com/wp-content/uploads/2012/01/UsabilityTest.png



CCD vs Testing

©USC-CSSE 36http://www.digitalcunzai.com/usability_testing.php



CCD Purpose• Improve likelihood of successful transition• Improve operational stakeholder

communication & motivation– Sense of what they’ll be getting

• Hands-on usage opportunity• Product will soon be theirs to manage

– Determine whether developers are on right track• Use real operational scenarios (preferred)

©USC-CSSE 37



CCD Purpose• Determine whether client needs anything

further to ensure successful Transition and Operation– Changes in priorities for remaining features?– Changes being made to operational procedures?– More materials needed for training?– Changes in system data or environment?– Anyone else who should experience CCD?

©USC-CSSE 38



Collaboration Problem

©USC-CSSE 39

Exploration & Valuation Foundations

Development

OperationsConstruction Transition



Solution: CCD

©USC-CSSE 40

Exploration & Valuation Foundations

Development

OperationsConstruction Transition



Developer Preparation

©USC-CSSE 41

• Schedule drive–through time with client– 40-60 minutes generally OK– Place: SAL 322, SAL 329– Discuss with client

• Agenda• Core Capabilities• Scenarios (acceptance test sub-set)• Drive–through users

– Coordinate with 577b staff• schedule prior to CCD• Specify hardware/software required (if needed)

http://blog.zilicus.com/enhancing-user-experience-of-zilicuspm/




©USC-CSSE 42

• Acceptance Test Subsets• Prepare draft User’s Manual

– Bring hard copies for clients & others– Minimally: describe how to use core capabilities

• Outline form– 1 high-level per capability– Sublevels describe steps to perform capability

• Index cards– 1-2 cards per capability– Steps to perform capability on cards




©USC-CSSE 43

• Prepare & dry run context presentation– Bring hard copies for clients & others

• Concern Logs– Can be in any form

• 577 template

OR• Your own

– Included in the report



Client Preparation

©USC-CSSE 44

• Communicate with client• Not just limited to client(s), but user(s) as well• Plan “user” test scenario(s) of core capabilities

– High-level description of typical usage– Should exercise capabilities in way user would

• May want to discuss with– Intended users– Acceptance Test developers

• Data, usage scenarios, users, etc.



CCD : Baseline Agenda

©USC-CSSE 45

• Summary of Core Capability content– Prioritized capabilities

• Review example Core Capability usage scenario

• Hands-on client usage– Most of time should be spent here

• Discussion of IOC priorities• Tailor agenda to your project



Client’s “Hands-on” Usage

©USC-CSSE 46

• Imagine the reality once software is delivered

• Let the clients play with the system• Use of user’s guide/manual

– DO NOT tell the clients what to do

• Observe and listen– Usability – Reactions– Etc.



CCD Products

©USC-CSSE 47

• Concern logs (include things customer liked)– Core capabilities– User’s Manual– Tutorial– Test Cases

• As appropriate– Re–prioritized list of remaining features– List of changes

• Operational procedures• System data or environment developers



CCD Report

©USC-CSSE 48

• Gather and submit– As-Is user’s manual– Concern Logs– Record of demonstration as performed

• Summarize Core Capabilities driven–through• Include suggestions and positive feedbacks

– Be specific – Break down by capability

– New risks, if any, and mitigation plans• Things that are Core Capabilities, but were NOT exercised:

Mitigation = repeat CCD?• Core capabilities not ready: Mitigation = do afterwards, coordinated

with Client• Changes in understanding

– Reprioritized capabilities, if any– COCOMO Estimation + Code Count reports



CCD Motivation• Effort for remaining work• More data for analysis• Past estimation

– Overestimate?– Underestimate?

• Analyze past estimations

49©USC-CSSE



CCD Summary

©USC-CSSE 50

• CCD is an opportunity to– Set customer expectations– Get positive feedbacks and suggestions– Validate core capabilities– Validate development directions and

understandings– Ease transition– Identify new risks and mitigations




(3) Preparation for the CCD


(7) Quality of the core capabilities

4/2/2012 51(C) USC-CSSE







53

TRR Package Overview

• Transition Set– Transition plan– User manual

• Support Set– Support plan – Training materials

• inc. Tutorials & sample data

– Test plan, cases, and results

©USC-CSSE



54

Transition Plan• “Ensure that system’s operational stakeholders

are able to successfully operate & maintain system”

• Plans for change from development mode to operational mode– Site installation & test– Load data– Pilot Operations– Preparations for roll-out

©USC-CSSE



55

User Manual

• Teach & guide user on how to use producti.e., describe

• Steps – For running SW– Performing operations

• Expected – Inputs– Output(s)

• Measures to be taken if errors occur

©USC-CSSE



56

Support Plan

• Guide system’s support stakeholders (administrators, operators, maintainers, …) on successful

– Operation

– Maintenance [and Enhancement?]

©USC-CSSE



57

Training Materials

• Identify training – Objectives– Schedule – Participants

• Prepare– Lectures– Examples– Exercises

• Prepare any sample data need for training

©USC-CSSE



58

TRR Presentation Summary

• Specific requirements for your presentation:– Your product!

• i.e., fully working IOC version– Salesman-like discussion of your project’s usefulness

• Base on your business case, etc• Why is system going to be really great for customer

– Transition issues & transition plan• if you delivered your product how did it go?

– (you should have by presentation)• If not, when?

– Support issues• How will you support product, once deployed?

– E.g. next term, for instance– OK to say that

» You will never touch it ever again» Everything’s up to customer

©USC-CSSE



59

TRR Agenda (80 Minutes)10 min. Introduction

– Operational concept overview, TRR specific outline, transition objective & strategy

25 min. Demo of IOC (Product status demonstration) 5 min. Support Plan10 min. Data Reporting & Archiving (if any)15 min. Summary of Transition Plan (as appropriate)

– HW, SW, site, staff preparation– Operational testing, training, & evaluation– Stakeholder roles & responsibilities– Milestone plan– Required resources– Software product elements (code, documentation, etc.)

15 min. Feedback*** Times are approximate ***

©USC-CSSE





(10) Presentation

(5) Risk Management

(15) Quality

4/2/2012 60(C) USC-CSSE



Other things about milestone reviews

• Phase shifting– The milestones are being made, but the work hasn’t actually been

completed, hence shifting it to subsequent phase• Project signoff / Project close-out

– Signifies completeness or business acceptance of the deliverable– Prepare list of deliverables in advance– Phase signoff – check point

• Conditional signoff – specific conditions that will need to be met in the succeeding phases; spike in Scrum; need more feasibility evidence

• Acceptable variance signoff – not completely satisfy, but deliver with acceptable variance

• Postponed signoffs – move to next checkpoint, should not happen– Closeout – sometimes include lesson learned , post-implementation

report, recognize outstanding work, archive project records

©USC-CSSE 61Ref: www.pmhut.com



Outline



(C)USC-CSSE 62



Potential Guest Lecturers

• Boeing• Defense Acquisition University• WSR Consulting Group, LLC• JPL• Vresorts, Inc.

(C)USC-CSSE 63



TechTalk• 7 minutes in-class presentation

– predefined topics– PM tools, QA & Testing tools, Dev tools & frameworks

• Don’t pick a topic that you already know– pick a new one, challenging one

• Mainly open source tools– some commercial for free 10days/30days

• Imagine your manager ask you to review the tool/technology– Use the tool, try the technology– Report it to the class – good points, bad points, when to use it, should we use it

(C)USC-CSSE 64



TechTalk Schedule

DateTopics Activities

2/5/2014System Acquisition TechTalk I

2/12/2014Rebaselined DCR ARB

2/19/2014Requirements Volatility TechTalk II

2/26/2014Software Maintenance TechTalk III

3/5/2014Design-Code Review

3/12/2014Software Engineering standards TechTalk IV

3/19/2014Spring Break

3/26/2014Core Capability Drivethrough

4/2/201412 Knowledge Areas Every USC IT Engineering Student Should Know! TechTalk V

(C)USC-CSSE 65



DEN/ Remote students

• Call in– Presentation through webex

• Presentation in person [optional]

66



TechTalk Process

W Jan 15

• Topics and schedule posted on doodle

• Pick the topic and schedule that you are interested in

• Prepare your presentation

T Jan 28

• Last day of selecting and scheduling TechTalk

W Feb 5

• First TechTalk

(C)USC-CSSE 67

Note: If you have an interesting tool / framework that is not in the list, please let me know before Jan 22. Doodle link: http://doodle.com/eh5swgyvthmdy7bd

http://doodle.com/eh5swgyvthmdy7bd



TechTalk

• 45 points– 10 points: Presentation preparation and delivery– 30 points: Content– 5 points: Time Management

(C)USC-CSSE 68



TechTalk Topics - I

(C)USC-CSSE 69

PM tools

1 TuLeap - Life Cycle Management Software - http://www.enalean.com/

2 Alfresco - open source content management platform - http://www.alfresco.com/

3 SugarCRM - http://www.sugarcrm.com/

4 Feng Office - Project Management tool - http://www.fengoffice.com/web/

5 Activiti - BPM Tool - http://www.activiti.org/

6 Bonita BPM 6 - BPM tool - http://www.bonitasoft.com/

7 ProjectLibre - Project Management Tool - http://www.projectlibre.org/

8 LibrePlan - Project Management Tool - http://www.libreplan.com/

9 OpenProject - Project Management Tool - https://www.openproject.org/

10 RedMine - Project Management Tool - http://www.redmine.org/projects/redmine

Presentation date: February 5, 2014



TechTalk Topics - II

(C)USC-CSSE 70

QA &Testing tools

1 Badboy Software (www.badboy.com.au), web automated testing tool

2 Selenium (automated testing tool) - SElinium IDE (Beginner)

3 Selenium (automated testing tool) - SElinium WebDriver (Advanced)

4 Geb (browser automation solution) - http://www.gebish.org/

5 Cucumber - BDD tool - http://cukes.info/

6 Lettuce - BDD tool - http://lettuce.it/tutorial/simple.html

7 Robot Framework - test automation framework - http://robotframework.org/

8 Jmeter

9 Tsung - Load Testing Tool - http://tsung.erlang-projects.org/10 Load Impact - Performance Testing Service on the cloud - http://loadimpact.com


http://lettuce.it/tutorial/simple.html

http://loadimpact.com/



TechTalk Topics - III

(C)USC-CSSE 71

QA &Testing tools11 Phabricator - Peer Code Review Tools - http://phabricator.org/

12 Capybara - Web app testing tool - http://jnicklas.github.io/capybara/

13 Tarantula - Testing tool - http://www.testiatarantula.com/

14 Smartbear - Testing tool - http://smartbear.com/products/free/

15 Load Runner - performance testing tool - http://www8.hp.com/us/en/software-solutions/software.html?compURI=1175451

16 QuickTest Professional HP - Functional Testing - http://en.wikipedia.org/wiki/HP_QuickTest_Professional

17 Crubible - Collaborative peer code review - https://www.atlassian.com/software/crucible/overview

18 IBM AppScan - Security Testing Tool http://www-03.ibm.com/software/products/en/appscanDevelopment framework

HTML 5


https://www.atlassian.com/software/crucible/overview



TechTalk Topics - IV

(C)USC-CSSE 72

QA &Testing tools

19 AppPerfect Load Test - http://www.appperfect.com/products/load-test.html

20 AppPerfect Web Test - http://www.appperfect.com/products/web-test.html

21 AppPerfect App Test - http://www.appperfect.com/products/app-test.html

22 AppPerfect Java Code Test - http://www.appperfect.com/products/java-code-test.html

23 AppPerfect Java Unit Test - http://www.appperfect.com/products/java-unit-test.html

Presentation date: March 12, 2014

Development tools and frameworks

1 Django - opensource web application framework

2 MongoDB - NoSQL DB

3 Couchbase Server - NoSQL DB - http://www.couchbase.com/

4 Apache Hadoop - http://hadoop.apache.org/

5 Apache Sqoop - http://sqoop.apache.org/



TechTalk Topics - V

(C)USC-CSSE 73

Development tools and frameworks

7 Bootstrap - http://getbootstrap.com/

8 Less - http://lesscss.org/

9 AngularJS - http://angularjs.org/

10 Backbone.js - http://backbonejs.org/

11 D3 - Data Driven Documents - http://d3js.org/

12 Jenkins - http://jenkins-ci.org/

13 Rasberry Pi - http://www.raspberrypi.org/

14 Apache Shiro - Java Security Framework - http://shiro.apache.org/

15 Varnish - Web application accelerator - https://www.varnish-cache.org/

16 Docker - Cloud application development tool - http://www.docker.io/

Presentation date: April 2, 2014



Outline



(C)USC-CSSE 74



Individual Research Presentation

• Research– Not report, not inform

• Presentation– PPT, vdo, demo, prototype

• 10 minutes presentation • 2 minutes Q & A• Peer review as in-class quizzes

75



Possible topics

• Any software/ systems engineering topics– Not limited to process improvement

• BUT needs to relate to CSCI577ab– Or at least provide benefits to the class– Or use CSCI577ab knowledge to apply to your

topic

76



Possible Topics

• Green and sustainable software• Cooperative and Human Aspects of Software Engineering• Games and Software Engineering• Software Engineering for Secure Systems• Software Engineering for Cloud Computing• Product Line Approaches in Software Engineering• Managing Technical Debt• Software Clones• Automation of Software Test• Software Measurements• Developing Tools as Plug-ins• Software Processes

77



Possible Topics - Software processes• Agile/Lean processes in software and systems development• Assessment and improvement of software and systems processes• Cost estimation and project planning• Global software and systems development• Software and systems supply chain• Life cycle development methods including product-line engineering and all

others• Modeling and simulation of software and systems processes• Novel techniques for process representation and analysis of software and

systems processes• Process improvement• Process tools and metrics for software and systems engineering• Studies focused on specific portions of the development lifecycle including

requirements engineering, design, testing, independent verification and validation and others

• Process issues in health care, transportation, and automation systems

78



Not so good topics

• The Rational Unified Process• What is Cloud Computing?• Model-View-Controller Architecture

79



DEN/ Remote students

• Call in– Presentation through webex

• Presentation in person [optional]

80



A guide to presenters

• 10 minutes presentation• Submit your presentation 24 hours before

your presentation schedule

81

[not accepted][accepted]

• HW-2 Submit Research Proposal

March 12

• Acceptance Notification

April 2

• Announce Presentation Date

April 9

• Presentation

April 23, May 30



Research proposal (HW2)

• Due: March 12• 15 points• Abstract

– 100-300 words

• Keywords• References

82



Marks allocation

• Research Proposal – 15 points• Presentation – 45 points

– 5 points : Interesting – 5 points : Soundness – 5 points : Contribution to 577 – 5 points : Benefit to SE students – 5 points : Collaboration– 10 points : Quality of Work – 10 points : Quality of Presentation

83



Examples of research presentation from previous years

• Business Case Analysis and Tool for Software Engineering Course – Kantipa Lumyai (xls)

• A Case Study of Web Interface Design Patterns - Mark Villanueva

• Video Game Development and Incremental Commitment - Stephen Rice

• Green Software Engineering – Sheryl John

84(C)USC-CSSE

http://greenbay.usc.edu/csci577/spring2009/site/reservations/presentation.htm

http://sunset.usc.edu/classes/cs510_2012/EPs_2012/BusinessCaseAnalysisTool.xls

http://greenbay.usc.edu/csci577/spring2012/uploads/presentations/Mark_Villanueva_Presentation.pptx

http://greenbay.usc.edu/csci577/spring2012/uploads/presentations/Stephen_Rice_Presentation.pptx

http://greenbay.usc.edu/csci577/spring2011/uploads/presentations/Green_Software_Engineering.pptx



Outline



(C)USC-CSSE 85



Marks Allocation

(C)USC-CSSE 86

Category %

Individual Score (HW/In-Class) 23%

Individual Critique 11%

Tech Talk & Pair Research Presentation 11%

Individual Contribution 5%

Team Score 45%

Client Evaluation 5%

100%



(C)USC-CSSE 87

Primary CS577b Risk Items

• Personnel– Commitment – Compatibility– Ease of communication– Skills (management, web/java, Perl, CGI, data

compression, …)• Schedule

– Project scope– IOC content– Critical-path items (COTS, platforms, reviews, …)

• COTS– See next chart– Multiple COTS



(C)USC-CSSE 88

Primary CS577b Risk Items (cont.)

• Requirements & UI– Not matching client user needs

• Performance– Memory, Disk Space usage (#Bits)– Bus, Network, CPU utilization & bandwidth (#Bits/sec)– Overhead sources– Reliability of deliver– Safe– Secure

• External tasks– Client/operator preparation– Commitment for transition



(C)USC-CSSE 89

COTS & External Component Risks

• COTS risks– Immaturity– Inexperience– Incompatibility with

• Application• Platform• Other COTS

– Controllability



(C)USC-CSSE 90

COTS & External Component Risks (cont.)

• Non-commercial off-the shelf components– Sources

• Reuse libraries• Government (GOTS)• Universities (ROTS)

– Issues• Qualification testing• Benchmarking• Inspections• Reference checking• Compatibility analysis

• Both– Safety– Dependability– Security



Top 11 - Risk distribution in CSCI577

(C)USC-CSSE 91

Custo

mer

-dev

elope

r-use

r tea

m c

ohes

ion

Perso

nnel

shor

tfalls

Archit

ectu

re c

omple

xity;

qua

lity tr

adeo

ffs

Budge

t and

sch

edule

con

stra

ints

COTS and

oth

er in

depe

nden

tly e

volvi

ng s

yste

ms

Lack

of d

omain

kno

wledge

Proce

ss Q

uality

Ass

uran

ce

Requir

emen

ts v

olatili

ty; r

apid

chan

ge

User i

nter

face

mism

atch

Requir

emen

ts m

ismat

ch

Acquis

ition

and

cont

ract

ing p

roce

ss m

ismat

ches

0

2

4

6

8

10

12



Comparing between risks in Fall and Spring

(C)USC-CSSE 92

Customer-

develo

per-user

team

cohesi

on

Personnel

shortf

alls

Archite

cture

complex

ity; q

uality

tradeo

ffs

Budget a

nd sched

ule co

nstrain

ts

COTS an

d other indep

enden

tly ev

olving s

ystem

s

Lack o

f domain

knowled

ge

Proces

s Quali

ty Assu

rance

Require

ments

volati

lity; ra

pid chan

ge

User in

terfac

e mism

atch

Require

ments

mismatc

h

Acquisiti

on and co

ntracti

ng pro

cess m

ismatc

hes0

1

2

3

4

5

6

FallSpring



(C)USC-CSSE 93

Heads-Up: CS 577b PlanningCommon LCP Problems @ RDCR

• RDCR operational prototype, business-case iterations: What have you done since last semester?

• Too many internal-increment deliverables• Lack of core-capability specifics

– End-to-end demonstrable capability• Lack of specific team member responsibilities

– By artifact & increment; but flexible• Transition preparation

– Transition-leader’s success plan (teammates, clients)



(C)USC-CSSE 94

CS577 Academic Integrity Guidelines

• Individual Assignments– OK to discuss– Not OK to copy each others’ solution elements– Not OK to copy external sources without attribution

• Within “Fair Use Guidelines”

• Team Assignments– OK to use other teams’ patterns

• e.g. MS Project tasks• Must give credit!!!

– Not OK to copy other teams’ complete/partial solutions• e.g. MS course & project schedules



Outline

• Overview• Schedule

– In-Class Team Discussion – Guest Lecturers– Individual Research Presentation


(C)USC-CSSE 95



577b project roles

• Project Manager• Implementer• Tester• Trainer• IIV&Ver• Quality Focal Point

(C)USC-CSSE 96



97(C)USC-CSSE



577b Project ActivitiesRebaselined Foundations Phase

(C)USC-CSSE 98



577b Project ActivitiesDevelopment Phase – Construction Increment

(C)USC-CSSE 99



577b Project ActivitiesDevelopment Phase – Transition Increment

(C)USC-CSSE 100



577b Project Artifacts

• Exploration, Valuation, and Foundations set– OCD, SSAD, LCP, FED

• Initial Operational Capability set– Test Plan & Cases, Test Procedures & Results– Iteration Plan & Iteration Assessment Report (part of LCP)– CCD Report

• Transition and Support set– Transition Plan, Training Materials– Regression Test Package– User Manual

(C)USC-CSSE 101


Center for Systems and Software Engineering Team Reformation

(C)USC-CSSE 102

Project On-Campus Off-campus Note

1 LA Commons Upgrade of Website 1 ??

2 City of Los Angeles Personnel Department 5 1

3 Mission Science 1-sem

4 LiveRiot – social networking enhancement 1-sem

5 e-Lockbox 4 1

6 Yanomamo Interactive DVD/online 1-sem

7 ThrdPlace Social Networking 4

8 LOSE4GOOD.org 3

9 City of Los Angeles Public Safety 1 ??

10 Student Scheduling System Part II 6

11 Surgery Assist 0

12 Online wedding invitations 1-sem

13 Spherical Modeling Tool 2 2

14 Healthy Kids Zone 6 1

15 JEP Online Platform 5 1

16 MedFRS 1-sem

Available : - Hasan Ali H Al Yousuf- Abdulkareem- Vindhya Awari- Tu Duoung- Ari Summer

- T01-Huaiqi Wang- T09-Shreyas Devaraj

University of Southern California Center for Systems and Software Engineering CS 577b: Software Engineering II Class Introduction.

Documents

software engineering

test plan slide

development plan

code review slide

ccd slide

iteration plan

metrics plan

system design