1. CS 577b: Software Engineering II
CS 577b Software Engineering II -- Introduction
1 April 2017
CS 577b: Software Engineering II
Class Introduction
© USC Center for Software Engineering

2. Outline Schedule Marks Allocation Possible 577b risks
Guest Lecturers
TechTalk
Pair Research Presentation
Marks Allocation
Possible 577b risks
Team Re-Formation
(C)USC-CSSE

3. CS 577b Software Engineering II -- Introduction
1 April 2017
Course Schedule
See
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
© USC Center for Software Engineering

4. CS 577b Software Engineering II -- Introduction
1 April 2017
Milestone Reviews
Rebaselined Development Commitment Review
Design Code Review
Core Capability Drive thru
Transition Readiness Review
© USC Center for Software Engineering

5. Technology Interchange Meeting Retrospective meeting
Milestone review
Design Review
Code Review
Sprint Review
Technology Interchange Meeting
Retrospective meeting
©USC-CSSE

6. The Incremental Commitment Spiral Model
This slide shows the overall concept of the ICM
Commitment and accountability
Success-critical stakeholder satisficing,
Incremental growth of system definition and stakeholder commitment,
Concurrent engineering,
Iterative development cycles,
Risk-based activity levels and milestones
©USC-CSSE

7. ICSM –Class Milestones
2/12
3/26
4/16
4/30
3/5
Code Review
(C)USC-CSSE

8. (C)USC-CSSE

9. ARB Review Success Criteria
FCR
DCR
For 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:
All major risks resolved or covered by risk management plan
Key stakeholders committed to support full life cycle 4

10. Commitment Review Success Criteria
CCD
TRR / OCR
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?
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

11. ARB Session Outline RDCR similar format to DCR, different focus:
More time on changes and updates
More 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 11

12. 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

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 CTS
Team 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. 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 CTS
Team 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

15. Grading Guidelines Total = 50 points (20) Progress of your work
(10) Presentation
(5) Risk Management
(15) Quality
4/2/2012
(C) USC-CSSE

16. 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

17. CS 577b Software Engineering II -- Introduction
1 April 2017
Milestone Reviews
Rebaselined Development Commitment Review
Design Code Review
Core Capability Drive thru
Transition Readiness Review
© USC Center for Software Engineering

18. ©USC-CSSE

19. Internal Code Review
©USC-CSSE

20. Outline Problems & Motivation Faithful vs. Unfaithful
Preparation and Review Process
4/2/2012
(C) USC-CSSE

21. 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
(C) USC-CSSE

22. 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
(C) USC-CSSE

23. 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
(C) USC-CSSE

24. 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
x 2.46
Shall Statements
x 0.89
Use-Case
x 7.06
Use-Case Steps
x 66.91
SLOC
* Ali Afzal Malik, Supannika Koolmanojwong, Barry Boehm. “An Empirical Study of Requirements-to-Code Elaboration Factors
4/2/2012
(C) USC-CSSE

25. 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

26. 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

27. 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
(C) USC-CSSE

28. 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
(C) USC-CSSE

29. 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
(C) USC-CSSE

30. Preparation Source code files SSAD and UML models Personnel
As implemented
SSAD and UML models
Personnel
Must be present:
Developer (coder)
Architect(s)
Optional
Other team members
4/2/2012
(C) USC-CSSE

31. 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
(C) USC-CSSE

32. Grading Guidelines Total = 15 points
(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
(C) USC-CSSE

33. CS 577b Software Engineering II -- Introduction
1 April 2017
Milestone Reviews
Rebaselined Development Commitment Review
Design Code Review
Core Capability Drive thru
Transition Readiness Review
© USC Center for Software Engineering

34. Core Capabilities Drive-thru
©USC-CSSE

35. ©USC-CSSE

36. CCD vs Testing ©USC-CSSE

37. 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

38. 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

39. Collaboration Problem
Exploration & Valuation
Foundations
Development
Operations
Construction
Transition
©USC-CSSE

40. Exploration & Valuation
Solution: CCD
Exploration & Valuation
Foundations
Development
Operations
Construction
Transition
©USC-CSSE

41. Developer Preparation
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)
©USC-CSSE

42. Developer Preparation
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. Developer Preparation
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
©USC-CSSE

44. Client Preparation 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.
©USC-CSSE

45. CCD : Baseline Agenda 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
©USC-CSSE

46. Client’s “Hands-on” Usage
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.
©USC-CSSE

47. CCD Products 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
©USC-CSSE

48. CCD Report 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
©USC-CSSE

49. CCD Motivation Effort for remaining work More data for analysis
Past estimation
Overestimate?
Underestimate?
Analyze past estimations
©USC-CSSE

50. CCD Summary 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
©USC-CSSE

51. Grading Guidelines Total = 15 points (3) Preparation for the CCD
(5) Progress of your work
(7) Quality of the core capabilities
4/2/2012
(C) USC-CSSE

52. CS 577b Software Engineering II -- Introduction
1 April 2017
Milestone Reviews
Rebaselined Development Commitment Review
Design Code Review
Core Capability Drive thru
Transition Readiness Review
© USC Center for Software Engineering

53. CSCI 577b Software Engineering II, TRR Preparation
4/1/2017
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
© USC-CSE

54. CSCI 577b Software Engineering II, TRR Preparation
4/1/2017
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
© USC-CSE

55. CSCI 577b Software Engineering II, TRR Preparation
4/1/2017
User Manual
Teach & guide user on how to use product
i.e., describe
Steps
For running SW
Performing operations
Expected
Inputs
Output(s)
Measures to be taken if errors occur
©USC-CSSE
© USC-CSE

56. CSCI 577b Software Engineering II, TRR Preparation
4/1/2017
Support Plan
Guide system’s support stakeholders (administrators, operators, maintainers, …) on successful
Operation
Maintenance [and Enhancement?]
©USC-CSSE
© USC-CSE

57. CSCI 577b Software Engineering II, TRR Preparation
4/1/2017
Training Materials
Identify training
Objectives
Schedule
Participants
Prepare
Lectures
Examples
Exercises
Prepare any sample data need for training
©USC-CSSE
© USC-CSE

58. TRR Presentation Summary
CSCI 577b Software Engineering II, TRR Preparation
4/1/2017
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
© USC-CSE

59. CSCI 577b Software Engineering II, TRR Preparation
4/1/2017
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 Plan
10 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
© USC-CSE

60. Grading Guidelines Total = 50 points (20) Progress of your work
(10) Presentation
(5) Risk Management
(15) Quality
4/2/2012
(C) USC-CSSE

61. 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
Ref:
©USC-CSSE

62. Outline Schedule Marks Allocation Possible 577b risks
Guest Lecturers
TechTalk
Pair Research Presentation
Marks Allocation
Possible 577b risks
Team Re-Formation
(C)USC-CSSE

63. Potential Guest Lecturers
Boeing
Defense Acquisition University
WSR Consulting Group, LLC
JPL
Vresorts, Inc.
(C)USC-CSSE

64. 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

65. TechTalk Schedule Date Topics Activities 2/5/2014 System Acquisition
TechTalk I
2/12/2014
Rebaselined DCR ARB
2/19/2014
Requirements Volatility
TechTalk II
2/26/2014
Software Maintenance
TechTalk III
3/5/2014
Design-Code Review
3/12/2014
Software Engineering standards
TechTalk IV
3/19/2014
Spring Break
3/26/2014
Core Capability Drivethrough
4/2/2014
12 Knowledge Areas Every USC IT Engineering Student Should Know!
TechTalk V
(C)USC-CSSE

66. DEN/ Remote students Call in Presentation in person [optional]
Presentation through webex
Presentation in person [optional]

67. 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
Note: If you have an interesting tool / framework that is not in the list, please let me know before Jan 22.
Doodle link:
(C)USC-CSSE

68. TechTalk 45 points 10 points: Presentation preparation and delivery
30 points: Content
5 points: Time Management
(C)USC-CSSE

69. TechTalk Topics - I Presentation date: February 5, 2014 PM tools 1
TuLeap - Life Cycle Management Software - 2
Alfresco - open source content management platform - 3
SugarCRM - 4
Feng Office - Project Management tool - 5
Activiti - BPM Tool - 6
Bonita BPM 6 - BPM tool - 7
ProjectLibre - Project Management Tool - 8
LibrePlan - Project Management Tool - 9
OpenProject - Project Management Tool - 10
RedMine - Project Management Tool -
(C)USC-CSSE

70. TechTalk Topics - II Presentation date: February 19, 2014
QA &Testing tools 1
Badboy Software ( 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) - 5
Cucumber - BDD tool - 6
Lettuce - BDD tool - 7
Robot Framework - test automation framework - 8
Jmeter 9
Tsung - Load Testing Tool - 10
Load Impact - Performance Testing Service on the cloud -
(C)USC-CSSE

71. TechTalk Topics - III Presentation date: February 26, 2014
QA &Testing tools 11
Phabricator - Peer Code Review Tools - 12
Capybara - Web app testing tool - 13
Tarantula - Testing tool - 14
Smartbear - Testing tool - 15
Load Runner - performance testing tool - 16
QuickTest Professional HP - Functional Testing - 17
Crubible - Collaborative peer code review - 18
IBM AppScan - Security Testing Tool
Development framework
HTML 5
(C)USC-CSSE

72. TechTalk Topics - IV Presentation date: March 12, 2014
QA &Testing tools 19
AppPerfect Load Test - 20
AppPerfect Web Test - 21
AppPerfect App Test - 22
AppPerfect Java Code Test - 23
AppPerfect Java Unit Test -
Development tools and frameworks 1
Django - opensource web application framework 2
MongoDB - NoSQL DB 3
Couchbase Server - NoSQL DB - 4
Apache Hadoop - 5
Apache Sqoop -
(C)USC-CSSE

73. TechTalk Topics - V Presentation date: April 2, 2014
Development tools and frameworks 7
Bootstrap - 8
Less - 9
AngularJS - 10
Backbone.js - 11
D3 - Data Driven Documents - 12
Jenkins - 13
Rasberry Pi - 14
Apache Shiro - Java Security Framework - 15
Varnish - Web application accelerator - 16
Docker - Cloud application development tool -
(C)USC-CSSE

74. Outline Schedule Marks Allocation Possible 577b risks
Guest Lecturers
TechTalk
Pair Research Presentation
Marks Allocation
Possible 577b risks
Team Re-Formation
(C)USC-CSSE

75. Individual Research Presentation
Not report, not inform
Presentation
PPT, vdo, demo, prototype
10 minutes presentation
2 minutes Q & A
Peer review as in-class quizzes

76. 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

77. 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

78. 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

79. Not so good topics The Rational Unified Process
What is Cloud Computing?
Model-View-Controller Architecture

80. DEN/ Remote students Call in Presentation in person [optional]
Presentation through webex
Presentation in person [optional]

81. A guide to presenters 10 minutes presentation
[accepted]
HW-2 Submit Research Proposal
March 12
Acceptance Notification
April 2
Announce Presentation Date
April 9
Presentation
April 23, May 30
[not accepted]
10 minutes presentation
Submit your presentation 24 hours before your presentation schedule

82. Research proposal (HW2)
Due: March 12
15 points
Abstract
words
Keywords
References

83. 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

84. 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
(C)USC-CSSE

85. Outline Schedule Marks Allocation Possible 577b risks
Guest Lecturers
TechTalk
Pair Research Presentation
Marks Allocation
Possible 577b risks
Team Re-Formation
(C)USC-CSSE

86. Marks Allocation Category % Individual Score (HW/In-Class) 23%
Individual Critique
11%
Tech Talk & Pair Research Presentation
Individual Contribution 5%
Team Score
45%
Client Evaluation
100%
(C)USC-CSSE

87. CS 577b Software Engineering II -- Introduction
1 April 2017
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
© USC Center for Software Engineering

88. Primary CS577b Risk Items (cont.)
CS 577b Software Engineering II -- Introduction
1 April 2017
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
© USC Center for Software Engineering

89. COTS & External Component Risks
CS 577b Software Engineering II -- Introduction
1 April 2017
COTS & External Component Risks
COTS risks
Immaturity
Inexperience
Incompatibility with
Application
Platform
Other COTS
Controllability
(C)USC-CSSE
© USC Center for Software Engineering

90. COTS & External Component Risks (cont.)
CS 577b Software Engineering II -- Introduction
1 April 2017
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
(C)USC-CSSE
© USC Center for Software Engineering

91. Top 11 - Risk distribution in CSCI577
(C)USC-CSSE

92. Comparing between risks in Fall and Spring
(C)USC-CSSE

93. Heads-Up: CS 577b Planning Common LCP Problems @ RDCR
CS 577b Software Engineering II -- Introduction
1 April 2017
Heads-Up: CS 577b Planning Common LCP 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
© USC Center for Software Engineering

94. CS577 Academic Integrity Guidelines
CS 577b Software Engineering II -- Introduction
1 April 2017
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
(C)USC-CSSE
© USC Center for Software Engineering

95. Outline Overview Schedule Marks Allocation Possible 577b risks
In-Class Team Discussion
Guest Lecturers
Individual Research Presentation
Marks Allocation
Possible 577b risks
Team Re-Formation
(C)USC-CSSE

96. 577b project roles Project Manager Implementer Tester Trainer IIV&Ver
Quality Focal Point
(C)USC-CSSE

97. (C)USC-CSSE

98. 577b Project Activities Rebaselined Foundations Phase
(C)USC-CSSE

99. 577b Project Activities Development Phase – Construction Increment
(C)USC-CSSE

100. 577b Project Activities Development Phase – Transition Increment
(C)USC-CSSE

101. 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

102. Team Reformation Project On-Campus Off-campus Note 1
LA Commons Upgrade of Website ?? 2
City of Los Angeles Personnel Department 5 3
Mission Science
1-sem 4
LiveRiot – social networking enhancement
e-Lockbox 6
Yanomamo Interactive DVD/online 7
ThrdPlace Social Networking 8
LOSE4GOOD.org 9
City of Los Angeles Public Safety 10
Student Scheduling System Part II 11
Surgery Assist 12
Online wedding invitations 13
Spherical Modeling Tool 14
Healthy Kids Zone 15
JEP Online Platform 16
MedFRS
Available :
Hasan Ali H Al Yousuf
Abdulkareem
Vindhya Awari
Tu Duoung
Ari Summer
T01-Huaiqi Wang
T09-Shreyas Devaraj
(C)USC-CSSE