Software Engineering
Wrap-up
1
Course Key Ideas
and
Advice for Obamacare Website
2
If You Remember Nothing Else
Big Idea
Topics in lectures/readings
DRY Design
Design patterns & Refactoring
Aspects (validations, filters)
Metaprogramming (attr_accessor)
Test-first development
“Surgical” stubbing and mocking
SOFA & testing
Embracing change
Scenario/Iteration-based BDD
Agile == always have working code
Testability
Development as
process
SW Engineering Inequalities
• Hacking != developing
– little “greenfield” development except early startups
– Lone hacker != SW hero
• Working code != finished code
– refactoring, polishing more important than first draft
– unless maintainable & extensible, little reuse/short lifetime
• Language competence, grades != hireability
– Your code is your resume
– Learn a new language every 1-2 years
– Peter Norvig: “learn to program in 10,000 hours”
Why These Course Topics?
• ½ dozen companies for what want in SWE
– Amazon Web Services, eBay, Facebook,
GitHub, Google, Heroku, Microsoft, Pivotal Labs
1. Enhance sparsely-documented legacy code
2. Make testing a first-class citizen
3. Working with non-technical customers
4. Performing design reviews
5. Working in teams
5
Why These Topics?
• ACM/IEEE SW Eng Curriculum Committee
Plan-and-Document process familiarity*:
– SW processes, SW project management, Tools and
environments, Requirements engineering, SW design,
SW construction, SW verification validation, SW evolution,
Formal Methods, SW reliability
• 1/3 former students use P&D on job
– Toth: “You interview them while they interview you”
• Survey: “Often don’t use Agile in real world!”
*Fox, A., & Patterson, D. “Is the New Software Engineering Curriculum
Agile?” IEEE Software, 30:5, Sept/Oct 2013.
6
How Popular is Agile?
• IT SW companies using Agile: Amazon, eBay,
Facebook, Microsoft, Salesforce, …
• 2012 survey of 66 distributed projects*
– 55% Agile vs. 45% Plan-and-Document
• Forrester: 60% teams use Agile as primary
SW development in 2012 vs. 45% in 2009**
• Gartner: 80% teams primarily Agile by end of
2012***
*H.-C. Estler, M. Nordio, C. A. Furia, B. Meyer, and J. Schneider. Agile vs. structured distributed software development: A
case study. Proc. 7th Int’l Conf. on Global Software Engineering (ICGSE’12), pp 11–20, 2012.
**http://articles.economictimes.indiatimes.com/2012-08-06/news/33065621_1_thoughtworks-software-developmentiterative.
***http://www.pmi.org/en/Professional-Development/Career-Central/Must_Have_Skill_Agile.aspx.
7
Affordable Care Act
• Suppose you met President Obama, and
since he learned you were a CSE major, he
asked you what should I have done about
ACA?
• What would you say?
8
Agile vs. Plan-and-Document
Small (Agile) Projects (<$1M)
Large (Not Agile) Projects (>$10M)
on time, on budget
4%
10%
20%
challenged (late,
over budget,
insufficient
functionality)
76%
failed (cancelled
prior to completion or
delivered and never
used)
38%
52%
CHAOS MANIFESTO 2013 Think Big, Act Small, www.standishgroup.com.
Based on the collection of project case information on 50,000 real-life IT
environments and SW projects. Surveying since 1985.
9
Service Oriented Architecture
• SOA: SW architecture where all
components are designed to be services
• Apps composed of interoperable services
– Easy to tailor new version for subset of users
– Also easier to recover from mistake in design
• Contrast to “SW silo” without internal APIs
10
Bookstore: Silo
• Internal subsystems
can share data
directly
– Review access user
profile
• All subsystems
inside single API
(“Bookstore”)
reviews
users
orders
Review
Subsystem
User Profile
Service
Buying
Subsystem
Bookstore Service
(Figure 1.2, Engineering SW as a
Service by Armando Fox and David
Patterson, 2nd Beta edition, 2013.)
11
credit card
processing
Bookstore: SOA
• Subsystems
independent,
as if in separate
datacenters
user
reviews
editor
reviews
User Profile
Service
Review
Service
– Review Service
access User
Service API
• Can recombine
to make new
service (“Favorite
Books”)
(Figure 1.3, Engineering SW as a
Service by Armando Fox and David
Patterson, 2nd Beta edition, 2013.)
users
orders
Buying
Service
Bookstore Service
Favorite Books
Service
users
Social
Network
Service
12
CEO: Amazon Shall Use SOA!
1. “All teams will henceforth expose their data and
functionality through service interfaces.”
2. “Teams must communicate with each other
through these interfaces.”
3. “There will be no other form of interprocess
communication allowed: no direct linking, no
direct reads of another team's data store, no
shared-memory model, no back-doors
whatsoever. The only communication allowed is
via service interface calls over the network.”
13
CEO: Amazon shall use SOA!
4. “It doesn’t matter what [API protocol] technology
you use.”
5. “Service interfaces, without exception, must be
designed from the ground up to be
externalizable. That is to say, the team must plan
and design to be able to expose the interface to
developers in the outside world. No exceptions.”
6. “Anyone who doesn’t do this will be fired.”
7. “Thank you; have a nice day!”
14
Federal Procurement Obstacle
• 2010 National Academies study (Defense):
The DOD is hampered by a culture and acquisition-related
practices that favor large programs, high-level oversight,
and a very deliberate, serial approach to development and
testing (the waterfall model). Programs that are expected
to deliver complete, nearly perfect solutions and that take
years to develop are the norm in the DOD. In contrast,
leading-edge commercial firms have adopted agile
approaches that focus on delivering smaller increments
rapidly and aggregating them over time to meet capability
objectives. … As a result, the DOD … is unable to deliver
IT-based capabilities rapidly to meet urgent requirements.
Achieving Effective Acquisition of Information Technology in the
Department of Defense, National Research Council, 2010.
15
5 Commandments on
How to Give a Bad Demo
I. Thou shalt favor whizzy graphics and
‘safe’ features.
II. Thou shalt not distinguish how thine
own contribution improved on the
previous process.
III. Thou shalt appoint a lone demo czar.
IV. Thou shalt improvise rather than
rehearse.
V. Thou shalt not identify stakeholders.
16
Poster/Demo Session Logistics
• Would be great if your customer can make it
• Each team member present one story
– (or part of a story if complicated)
– Reflect: Which ideas & processes taught in the
class worked best/worst in your project?
– What if anything would you do differently?
• Then we will ask a few questions
• 15 minutes total per team – poster+demo
• If no one at your poster, look at other
posters/demos
17
Administrivia: Team Peer
Evaluations
• “Grade” your teammates: score + comments
• Assign positive integer to each team
member (incl. you) according to work
amount/quality on entire project (incl. docs,
leadership, code, test, customer interaction)
• Sum of scores = 10 * team size
– E.g. 60 pts for 6-person team
• Justify the scores