Software Engineering Wrap-up

1

5 Commandments onHow 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. 2

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/demos3

Administrivia: Team Peer Evaluations

• “Grade” your teammates: score + comments• 4 = above and beyond• 3 = solid team player & contributor• 2 = OK• 1 = kind of a slacker• 0 = NOP (absence of this person would not

have been noticed)• Will post form, each student emails to

me

Course Key Ideasand

Advice for Obamacare Website

5

If You Remember Nothing Else

Big Idea Topics in lectures/readingsDRY Design Design patterns & Refactoring

Aspects (validations, filters)Metaprogramming (attr_accessor)

Testability Test-first development“Surgical” stubbing and mockingSOFA & testing

Development as process

Embracing changeScenario/Iteration-based BDDAgile == always have working code

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

8

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!”

9

*Fox, A., & Patterson, D. “Is the New Software Engineering Curriculum Agile?” IEEE Software, 30:5, Sept/Oct 2013.

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***

10

*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-development-iterative.***http://www.pmi.org/en/Professional-Development/Career-Central/Must_Have_Skill_Agile.aspx.

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?

11

12

Agile vs. Plan-and-Document

76%

20%

4%

Small (Agile) Projects (<$1M)

on time, on budget

challenged (late, over budget, insuf-ficient functionality)

failed (cancelled prior to completion or delivered and never used)

10%

52%

38%

Large (Not Agile) Projects (>$10M)

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.

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

13

Bookstore: Silo

14

• Internal subsystems can share data directly– Review access user

profile

• All subsystems inside single API(“Bookstore”)

(Figure 1.2, Engineering SW as a Service by Armando Fox and David Patterson, 2nd Beta edition, 2013.)

15

Bookstore: SOA

• Subsystems independent, as if in separate datacenters– 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.)

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

16

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!”

17

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.

18

Achieving Effective Acquisition of Information Technology in the Department of Defense, National Research Council, 2010.