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
Outline
• Schedule
– Guest Lecturers
– TechTalk
– Pair Research Presentation
• Marks Allocation
• Possible 577b risks
• Team Re-Formation
(C)USC-CSSE
2
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
Milestone Reviews
• Rebaselined Development Commitment
Review
• Design Code Review
• Core Capability Drive thru
• Transition Readiness Review
University of Southern California
Center for Systems and Software Engineering
Milestone review
©USC-CSSE
5
University of Southern California
Center for Systems and Software Engineering
The Incremental Commitment Spiral Model
©USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
ICSM –Class Milestones
2/12
3/5
3/26
4/16
4/30
Code Review
(C)USC-CSSE
7
University of Southern California
Center for Systems and Software Engineering
(C)USC-CSSE
8
University
University of
of Southern
SouthernCalifornia
California
Centerfor
Center
forSystems
Systems
and
and
Software
Software
Engineering
Engineering
ARB Review Success Criteria
FCR
DCR
For at least one architecture, a
system built to arch. will:
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
• Show viable business case
• 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
Key stakeholders committed to
covered by risk management
support Foundations Phase
plan
(to DCR)
Key stakeholders committed to
support full life cycle
9
4
University of Southern California
Center for Systems and Software Engineering
Commitment Review Success Criteria
CCD
•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?
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
10
University
University of
of Southern
SouthernCalifornia
California
Centerfor
Center
forSystems
Systems
and
and
Software
Software
Engineering
Engineering
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
11
University of Southern California
Center for Systems and Software Engineering
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
University
University of
of Southern
SouthernCalifornia
California
Centerfor
Center
forSystems
Systems
and
and
Software
Software
Engineering
Engineering
RDCR ARB – Architected Agile Teams
(x,y):
(8, 10)
(presentation time, total time)
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.
13
University
University of
of Southern
SouthernCalifornia
California
Centerfor
Center
forSystems
Systems
and
and
Software
Software
Engineering
Engineering
RDCR ARB – NDI-intensive Teams
(x,y):
(8, 10)
(presentation time, total time)
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
14
University of Southern California
Center for Systems and Software Engineering
Grading Guidelines
Total = 50 points
(20)
(10)
(5)
(15)
4/2/2012
Progress of your work
Presentation
Risk Management
Quality
(C) USC-CSSE
15
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
Milestone Reviews
• Rebaselined Development Commitment
Review
• Design Code Review
• Core Capability Drive thru
• Transition Readiness Review
University of Southern California
Center for Systems and Software Engineering
©USC-CSSE
18
University of Southern California
Center for Systems and Software Engineering
Internal Code Review
©USC-CSSE
19
University of Southern California
Center for Systems and Software Engineering
Outline
• Problems & Motivation
• Faithful vs. Unfaithful
• Preparation and Review Process
4/2/2012
(C) USC-CSSE
20
University of Southern California
Center for Systems and Software Engineering
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
21
University of Southern California
Center for Systems and Software Engineering
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
22
University of Southern California
Center for Systems and Software Engineering
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
23
University of Southern California
Center for Systems and Software Engineering
Requirements-to-Code Elaboration
Objective
x 2.46
Shall
Statements
x 0.89
Use-Case
x 7.06
• Impact factor from one step to
the next
• Increase in number of
“statements”
• Clearly, significant impact when
changes made to early stages
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
24
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
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
27
University of Southern California
Center for Systems and Software Engineering
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
28
University of Southern California
Center for Systems and Software Engineering
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
29
University of Southern California
Center for Systems and Software Engineering
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
(C) USC-CSSE
30
University of Southern California
Center for Systems and Software Engineering
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
31
University of Southern California
Center for Systems and Software Engineering
Grading Guidelines
Total = 15 points
(3)
(5)
(5)
(2)
4/2/2012
Faithfulness to design patterns / architecture
frameworks
Faithfulness in design classes to implemented
classes mapping
Accuracy of implemented Use-Case behaviors
Overall
(C) USC-CSSE
32
University of Southern California
Center for Systems and Software Engineering
Milestone Reviews
• Rebaselined Development Commitment
Review
• Design Code Review
• Core Capability Drive thru
• Transition Readiness Review
University of Southern California
Center for Systems and Software Engineering
Core Capabilities Drive-thru
©USC-CSSE
34
University of Southern California
Center for Systems and Software Engineering
©USC-CSSE
http://justincaseyouwerewondering.com/wp-content/uploads/2012/01/UsabilityTest.png
35
University of Southern California
Center for Systems and Software Engineering
CCD vs Testing
©USC-CSSE
http://www.digitalcunzai.com/usability_testing.php
36
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
Collaboration Problem
Exploration &
Valuation
Development
Foundations
Operations
Construction
©USC-CSSE
Transition
39
University of Southern California
Center for Systems and Software Engineering
Solution: CCD
Exploration &
Valuation
Development
Foundations
Operations
Construction
©USC-CSSE
Transition
40
University of Southern California
Center for Systems and Software Engineering
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)
http://blog.zilicus.com/enhancing-user-experience-of-zilicuspm/
©USC-CSSE
41
University of Southern California
Center for Systems and Software Engineering
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
42
University of Southern California
Center for Systems and Software Engineering
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
43
University of Southern California
Center for Systems and Software Engineering
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
44
University of Southern California
Center for Systems and Software Engineering
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
45
University of Southern California
Center for Systems and Software Engineering
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
46
University of Southern California
Center for Systems and Software Engineering
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
47
University of Southern California
Center for Systems and Software Engineering
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
48
University of Southern California
Center for Systems and Software Engineering
CCD Motivation
• Effort for remaining work
• More data for analysis
• Past estimation
– Overestimate?
– Underestimate?
• Analyze past estimations
©USC-CSSE
49
University of Southern California
Center for Systems and Software Engineering
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
50
University of Southern California
Center for Systems and Software Engineering
Grading Guidelines
Total = 15 points
(3)
(5)
(7)
4/2/2012
Preparation for the CCD
Progress of your work
Quality of the core capabilities
(C) USC-CSSE
51
University of Southern California
Center for Systems and Software Engineering
Milestone Reviews
• Rebaselined Development Commitment
Review
• Design Code Review
• Core Capability Drive thru
• Transition Readiness Review
University of Southern California
Center for Systems and Software Engineering
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
53
University of Southern California
Center for Systems and Software Engineering
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
54
University of Southern California
Center for Systems and Software Engineering
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
55
University of Southern California
Center for Systems and Software Engineering
Support Plan
• Guide system’s support stakeholders
(administrators, operators, maintainers, …)
on successful
– Operation
– Maintenance [and Enhancement?]
©USC-CSSE
56
University of Southern California
Center for Systems and Software Engineering
Training Materials
• Identify training
– Objectives
– Schedule
– Participants
• Prepare
– Lectures
– Examples
– Exercises
• Prepare any sample data need for training
©USC-CSSE
57
University of Southern California
Center for Systems and Software Engineering
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
58
University of Southern California
Center for Systems and Software Engineering
TRR Agenda (80 Minutes)
10 min. Introduction
– Operational concept overview, TRR specific outline, transition
objective & strategy
25 min.
5 min.
10 min.
15 min.
Demo of IOC (Product status demonstration)
Support Plan
Data Reporting & Archiving (if any)
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
59
University of Southern California
Center for Systems and Software Engineering
Grading Guidelines
Total = 50 points
(20)
(10)
(5)
(15)
4/2/2012
Progress of your work
Presentation
Risk Management
Quality
(C) USC-CSSE
60
University of Southern California
Center for Systems and Software Engineering
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: www.pmhut.com
©USC-CSSE
61
University of Southern California
Center for Systems and Software Engineering
Outline
• Schedule
– Guest Lecturers
– TechTalk
– Pair Research Presentation
• Marks Allocation
• Possible 577b risks
• Team Re-Formation
(C)USC-CSSE
62
University of Southern California
Center for Systems and Software Engineering
Potential Guest Lecturers
•
•
•
•
•
Boeing
Defense Acquisition University
WSR Consulting Group, LLC
JPL
Vresorts, Inc.
(C)USC-CSSE
63
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
TechTalk Schedule
Date Topics
2/5/2014 System Acquisition
2/12/2014 Rebaselined DCR ARB
2/19/2014 Requirements Volatility
2/26/2014 Software Maintenance
3/5/2014 Design-Code Review
3/12/2014 Software Engineering standards
3/19/2014 Spring Break
3/26/2014 Core Capability Drivethrough
12 Knowledge Areas Every USC IT
4/2/2014 Engineering Student Should Know!
(C)USC-CSSE
Activities
TechTalk I
TechTalk II
TechTalk III
TechTalk IV
TechTalk V
65
University of Southern California
Center for Systems and Software Engineering
DEN/ Remote students
• Call in
– Presentation through webex
• Presentation in person [optional]
66
University of Southern California
Center for Systems and Software Engineering
TechTalk Process
W Jan 15
T Jan 28
• Topics and
schedule
posted on
doodle
• Pick the topic
and schedule
that you are
interested in
• Prepare your
presentation
• 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: http://doodle.com/eh5swgyvthmdy7bd
(C)USC-CSSE
67
University of Southern California
Center for Systems and Software Engineering
TechTalk
• 45 points
– 10 points: Presentation preparation and delivery
– 30 points: Content
– 5 points: Time Management
(C)USC-CSSE
68
University of Southern California
Center for Systems and Software Engineering
TechTalk Topics - I
Presentation date: February 5, 2014
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
(C)USC-CSSE
69
University of Southern California
Center for Systems and Software Engineering
TechTalk Topics - II
Presentation date: February 19, 2014
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
(C)USC-CSSE
70
University of Southern California
Center for Systems and Software Engineering
TechTalk Topics - III
Presentation date: February 26, 2014
QA &Testing tools
11 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/softwaresolutions/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://www03.ibm.com/software/products/en/appscan
Development framework
HTML 5
(C)USC-CSSE
71
University of Southern California
Center for Systems and Software Engineering
TechTalk Topics - IV
Presentation date: March 12, 2014
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-codetest.html
23 AppPerfect Java Unit Test - http://www.appperfect.com/products/java-unittest.html
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/
(C)USC-CSSE
5 Apache Sqoop - http://sqoop.apache.org/
72
University of Southern California
Center for Systems and Software Engineering
TechTalk Topics - V
Presentation date: April 2, 2014
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/
(C)USC-CSSE
73
University of Southern California
Center for Systems and Software Engineering
Outline
• Schedule
– Guest Lecturers
– TechTalk
– Pair Research Presentation
• Marks Allocation
• Possible 577b risks
• Team Re-Formation
(C)USC-CSSE
74
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
Not so good topics
• The Rational Unified Process
• What is Cloud Computing?
• Model-View-Controller Architecture
79
University of Southern California
Center for Systems and Software Engineering
DEN/ Remote students
• Call in
– Presentation through webex
• Presentation in person [optional]
80
University of Southern California
Center for Systems and Software Engineering
A guide to presenters
[accepted]
[not accepted]
April 23,
May 30
April 2
• HW-2 Submit
Research Proposal
March 12
• Acceptance
Notification
• Announce
Presentation
Date
• Presentation
April 9
• 10 minutes presentation
• Submit your presentation 24 hours before
your presentation schedule
81
University of Southern California
Center for Systems and Software Engineering
Research proposal (HW2)
• Due: March 12
• 15 points
• Abstract
– 100-300 words
• Keywords
• References
82
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
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
84
University of Southern California
Center for Systems and Software Engineering
Outline
• Schedule
– Guest Lecturers
– TechTalk
– Pair Research Presentation
• Marks Allocation
• Possible 577b risks
• Team Re-Formation
(C)USC-CSSE
85
University of Southern California
Center for Systems and Software Engineering
Marks Allocation
Category
%
Individual Score (HW/In-Class)
23%
Individual Critique
11%
Tech Talk & Pair Research Presentation
11%
Individual Contribution
Team Score
5%
45%
Client Evaluation
5%
100%
(C)USC-CSSE
86
University of Southern California
Center for Systems and Software Engineering
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
87
University of Southern California
Center for Systems and Software Engineering
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
88
University of Southern California
Center for Systems and Software Engineering
COTS & External Component
Risks
• COTS risks
– Immaturity
– Inexperience
– Incompatibility with
• Application
• Platform
• Other COTS
– Controllability
(C)USC-CSSE
89
University of Southern California
Center for Systems and Software Engineering
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
90
University of Southern California
Center for Systems and Software Engineering
Top 11 - Risk distribution in CSCI577
12
10
8
6
4
2
0
(C)USC-CSSE
91
University of Southern California
Center for Systems and Software Engineering
Comparing between risks in Fall and Spring
6
5
4
3
2
Fall
1
Spring
0
(C)USC-CSSE
92
University of Southern California
Center for Systems and Software Engineering
Heads-Up: CS 577b Planning
Common 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
93
University of Southern California
Center for Systems and Software Engineering
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
94
University of Southern California
Center for Systems and Software Engineering
Outline
• Overview
• Schedule
– In-Class Team Discussion
– Guest Lecturers
– Individual Research Presentation
• Marks Allocation
• Possible 577b risks
• Team Re-Formation
(C)USC-CSSE
95
University of Southern California
Center for Systems and Software Engineering
577b project roles
•
•
•
•
•
•
Project Manager
Implementer
Tester
Trainer
IIV&Ver
Quality Focal Point
(C)USC-CSSE
96
University of Southern California
Center for Systems and Software Engineering
(C)USC-CSSE
97
University of Southern California
Center for Systems and Software Engineering
577b Project Activities
Rebaselined Foundations Phase
(C)USC-CSSE
98
University of Southern California
Center for Systems and Software Engineering
577b Project Activities
Development Phase – Construction Increment
(C)USC-CSSE
99
University of Southern California
Center for Systems and Software Engineering
577b Project Activities
Development Phase – Transition Increment
(C)USC-CSSE
100
University of Southern California
Center for Systems and Software Engineering
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
University of Southern California
Center for Systems and Software Engineering
Team Reformation
Project
On-Campus
1
LA Commons Upgrade of Website
1
2
City of Los Angeles Personnel Department
5
3
Mission Science
1-sem
4
LiveRiot – social networking enhancement
1-sem
5
e-Lockbox
6
Yanomamo Interactive DVD/online
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
13
Spherical Modeling Tool
2
2
14
Healthy Kids Zone
6
1
15
JEP Online Platform
5
1
16
MedFRS
Available :
-Hasan Ali H Al Yousuf
-Abdulkareem
-Vindhya Awari
- Tu Duoung
-Ari Summer
4
Off-campus
Note
??
1
1
1-sem
??
1-sem
1-sem
-T01-Huaiqi Wang
-T09-Shreyas Devaraj
(C)USC-CSSE
102