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
– Individual 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/spring2015
• 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/11
Design Code Review – Week of 03/04
Core Capability Drivethrough – Week of 03/25
Transition Readiness Review – Week of 04/08
(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/11
3/4
3/25
4/08
4/29
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 If there is no change, just present system
boundary diagram
(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. Project plan- at lease until CCD or as appropriate;
Team members’ roles & responsibilities in 577b, Full Iteration Plan
(5, 10)
Feasibility Evidence. Focus on Risk Analysis. Traceability Matrix. Definition
of Done, 2 Metrics results, Technical Debt
• 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
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 If there is no change, just present system
boundary diagram
(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. Project plan - at lease until CCD or as appropriate; Team
members’ roles & responsibilities in 577b, Full Iteration Plan
(5, 10)
Feasibility Evidence. Focus on Risk Analysis, Traceability Matrix. Definition
of Done, 2 Metrics results, Technical Debt
• 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
14
14
University of Southern California
Center for Systems and Software Engineering
Grading Guidelines
Total = 65 points
(30)
(10)
(5)
(20)
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
–
–
–
–
Week of 03/25, 30 minutes
Location: SAL 322 or 329
Schedule with TA
Marks allocation - Total = 25 points
(5) Faithfulness to design patterns / architecture frameworks
(8) Faithfulness in design classes to implemented classes
mapping
(7) Accuracy of implemented Use-Case behaviors
(5) Overall
4/2/2012
(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
FCR
Exploration &
Valuation
DCR
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
Week of 03/25
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 = 25 points
(3)
(15)
(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)
5 min.
Introduction
– Operational concept overview
30 min.
15 min.
10 min.
Demo of IOC (Product status demonstration)
Quality assurance
- Test results
- Traceability Matrix.
- show that you comply with the Definition of Done that you
presented during RDCR ARB
- 2 Metrics results
- Technical Debt
Summary of Transition Plan and transition plan (as appropriate)
–
–
–
–
–
–
15 min.
HW, SW, site, staff preparation
Operational testing, training, & evaluation
Stakeholder roles & responsibilities
Milestone plan
Required resources
Software product elements (code, documentation, etc.)
Feedback
*** Times are approximate ***
©USC-CSSE
59
University of Southern California
Center for Systems and Software Engineering
Grading Guidelines
Total = 65 points
(30)
(10)
(5)
(20)
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
– Individual 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
Aerospace Corporation
Cornerstone
Kyocera
Share the training
Los Angeles Department of Water and Power
(C)USC-CSSE
63
University of Southern California
Center for Systems and Software Engineering
Outline
• Schedule
– Guest Lecturers
– Individual Presentation
• Marks Allocation
• Possible 577b risks
• Team Re-Formation
(C)USC-CSSE
64
University of Southern California
Center for Systems and Software Engineering
Individual Presentation
• 80 points
• 2 kinds – Pick one
– TechTalk
• Product evaluation
– Individual Research Presentation
• New trends in software engineering
• 8 minutes presentation
(C)USC-CSSE
65
University of Southern California
Center for Systems and Software Engineering
Individual Presentation Schedule
8 presenters per day
Date
Activity
02 / 25
Tech Talk I
03 / 11
Tech Talk II
04 / 01
Tech Talk III
04 / 15
Research Presentation
04 / 22
Research Presentation
04 / 29
Research Presentation
(C)USC-CSSE
66
University of Southern California
Center for Systems and Software Engineering
TechTalk
• Don’t pick a tool 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
– Show case / demo it to the class
– good points, bad points, when to use it, should we use it
(C)USC-CSSE
67
University of Southern California
Center for Systems and Software Engineering
DEN/ Remote students
• Call in
– Presentation through webex
• Presentation in person [optional]
68
University of Southern California
Center for Systems and Software Engineering
TechTalk Process
M Feb 2
M Feb 16
• Submit HW
2 TechTalk
or Individual
research
topic
• Will provide
feedback
• Last day of
selecting
and
scheduling
Individual
Presentation
W Feb 25
• First
Individual
Presentation
Note:
- For TechTalk, you will select from to-be-posted link (first come first serve – 8 people per
day
- For individual research presentation, you will submit a topic with abstract on February 2
- If you have an interesting tool / framework that is not in the list, please let me know
before January 21.
(C)USC-CSSE
69
University of Southern California
Center for Systems and Software Engineering
TechTalk Topics – PM & Prototype
Presentation date: February 25, 2015
PM & Prototyping 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 LibrePlan - Project Management Tool - http://www.libreplan.com/
8 OpenProject - Project Management Tool - https://www.openproject.org/
9 RedMine - Project Management Tool - http://www.redmine.org/projects/redmine
10 FluidUI https://www.fluidui.com
11 Proto.io http://proto.io
12 UXPin
http://uxpin.com
13 Justinmind http://www.justinmind.com
14 Notism https://www.notism.io/home
(C)USC-CSSE
70
University of Southern California
Center for Systems and Software Engineering
TechTalk Topics - II
Presentation date: March 11, 2015
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
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/
Load Runner - performance testing tool - http://www8.hp.com/us/en/software(C)USC-CSSE
15 solutions/software.html?compURI=1175451
71
University of Southern California
Center for Systems and Software Engineering
TechTalk Topics - III
Presentation date: April 01, 2015
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/
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
72
University of Southern California
Center for Systems and Software Engineering
Individual Research Presentation
• Research
– Not report, not inform
• Presentation
– PPT, vdo, demo, prototype
73
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
74
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
75
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
76
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
What’s new in HTML5
77
University of Southern California
Center for Systems and Software Engineering
DEN/ Remote students
• Call in
– Presentation through webex
• Presentation in person [optional]
78
University of Southern California
Center for Systems and Software Engineering
HW2
• Due: Monday February 2
• 10 points
• TechTalk
– Select the topic & date on to-be-posted doodle
– First come first serve (8 people per day)
– Brief report (100-300 words) on
• Quicklook evaluation
• Individual Research Presentation
– Abstract
• 100-300 words
– Keywords
– References
79
University of Southern California
Center for Systems and Software Engineering
Marks allocation
TechTalk
• 80 points
– 10 points : Time management
– 30 points : Quality of Demo
Scenario
– 20 points : Quality of Product
evaluation
– 20 points : Quality of
Presentation
Research presentation
• 80 points
–
–
–
–
–
5 points : Interesting
5 points : Soundness
10 points : Time management
10 points : Contribution to 577
10 points : Benefit to SE
students
– 20 points : Quality of Work
– 20 points : Quality of
Presentation
80
University of Southern California
Center for Systems and Software Engineering
Outline
• Schedule
– Guest Lecturers
– Individual Presentation
• Marks Allocation
• Possible 577b risks
• Team Re-Formation
(C)USC-CSSE
81
University of Southern California
Center for Systems and Software Engineering
Marks Allocation
Category
%
Individual Score (HW/In-Class)
24%
Individual Critique
11%
Tech Talk & Pair Research Presentation
10%
Individual Contribution
Team Score
5%
45%
Client Evaluation
5%
100%
(C)USC-CSSE
82
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
83
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
84
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
85
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
86
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
87
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
88
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
89
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
90
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
91
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
92
University of Southern California
Center for Systems and Software Engineering
(C)USC-CSSE
93
University of Southern California
Center for Systems and Software Engineering
577b Project Activities
Rebaselined Foundations Phase
(C)USC-CSSE
94
University of Southern California
Center for Systems and Software Engineering
577b Project Activities
Development Phase – Construction Increment
(C)USC-CSSE
95
University of Southern California
Center for Systems and Software Engineering
577b Project Activities
Development Phase – Transition Increment
(C)USC-CSSE
96
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
97
Team Reformation
University of Southern California
Center for Systems and Software Engineering
Project
On-Campus
Off-campus
Suggestions
8
1 We Are Trojans (WAT network)
2 Soccer Data Webcrawler
3 SnapValet
3
1
4 FlowerSeeker
6
1
5 SnApp - Voice Communication System (VCS)
6 BlackProfessionals.net
1
7 Mission Science iRobots
3
1
5
1
6
1
8 e-LockBox
9 TipSure.com
10 REFERsy
11 ShareTheTraining.com
12 Cash Doctor 3.0 Mobile APP
13 Mobile Application for Mobile-Controlled Lighting
14 Women At Work Website Redesign
15 GOTRLA Smartphone App Development
3
7
7
7
10
10
Alaskari, Abdullah Mansour, A.
Hu, Yu-Hsiang
Lee, Danny, W.
Mardah, Hanadi, Omar
Mukhin, Sergey
Al Sudais, Sadeem, Saleh A
3 Horng, Patrick
3 Bousman, Brian, Gordon
(C)USC-CSSE
off-campus
off-campus
98