What they don’t tell you: Software Engineering lessons Sriram Srinivasan (“Ram”) [email protected]

What they don’t tell you:Software Engineering lessons

What they don’t tell you:Software Engineering lessons

Sriram Srinivasan (“Ram”)[email protected]

Sriram Srinivasan 2

Good design comes fromGood design comes from

comes from making bad mistakescomes from making bad mistakes

ExperienceExperienceExperienceExperience

Sriram Srinivasan 3

Today, you’ll learn ..Today, you’ll learn ..

To look at methodologies with a critical eye

What worked for me, and what didn’tQA practices adopted for a successful

commercial product WebLogic Application Server (www.bea.com)

Sriram Srinivasan 4

OO is wonderfulOO is wonderful

Application == system of interacting objects

Guides thinking, partitioning the problemRUP provides different views

Structural view of data, processesClass diagrams

Dynamic viewUse casesSequence diagrams, State charts

Focus on data and data flow

Sriram Srinivasan 5

Case Study #1: OO thinkingCase Study #1: OO thinking

One of the world’s largest courier companies

Project: To come up with a company-wide business object model Re-engineer all systems with this model Promote reusability across the enterprise

Sriram Srinivasan 6

Case Study #1 : Lessons learntCase Study #1 : Lessons learnt

“Business objects”: nebulous conceptReusability – dubious goalClear problem statement

“Replace a legacy system” is not a goal. Don’t think “object”, “web”, “computer” UML

when learning a domain

Systemic thinking – includes manual processes

Sriram Srinivasan 7

Case Study #2: ComponentsCase Study #2: Components

Objects vs componentsRemote objects, Remote components

CORBA, DCOM, Java RMI Enterprise JavaBeans, DCOM+MTS, .NET

My experience, from both sides: Used remote components for a large aircraft

scheduling application, network management systems

Wrote a CORBA server Wrote the world’s first EJB framework

Sriram Srinivasan 8

Case study #2: LessonsCase study #2: Lessons

Business Object Models do not translate well to code

Mismatch between RDBMS and objectsNetwork not transparentDuplication between object framework

and RDBMS: concurrency, transactions, security

Using objects to generate UI: bad ideaAll designers must be active programmers

Sriram Srinivasan 9

Other delivery issuesOther delivery issues

Customers want cheap, fast, goodConstant change

Requirements, technologies, business practices, programmers

Documents and Code mismatched soon

Proposed solution: eXtreme Programming (XP)

Sriram Srinivasan 10

Extreme ProgrammingExtreme Programming

Kent Beck, Ward CunninghamStresses customer satisfactionFocus on attitude

simplicity (in documentation, in coding) communication feedback courage: embracing change

RUP and XP coexist happily


XP PracticesXP Practices

Planning Writing User Stories (use cases)

Each story implementable in ~ 3 weeks

Release and Iteration planningSort stories by desirability

Designing Simple: Only accommodate what's needed now, not for the future

Design evolves as project evolves Customer available throughout the project


XP Practices (contd)XP Practices (contd)

Coding Implement and deliver a story at a time Write unit tests first

Don’t write more code before exisiting tests succeed

Pair Programming Continuous Refactoring, Integration Collective ownership

Testing All code must pass unit tests All bug fixes accompanied by more tests


XP pitfallsXP pitfalls

Types of software projects Shrinkwrap, embedded, games, throwaway,

internal IT projects

Most methodologies apply to internal IT projects Customer is not always available Not much chance of repeated versions in

embedded software and games


XP pitfallsXP pitfalls

Pair programming doesn’t work well Ego clashes, mismatched experience levels,

need for unstructured think time Pair desigining, debugging works well for me

Erring on the side of too less documentation, less design Problem with inexperienced XP’ers. Larger projects require more structure

Refactoring costs time


What works for meWhat works for me

General Meeting notes, emails, random ideas,

prototypes archived and indexed Every team project has a web-site PowerPoint instead of verbose documents Daily short meeting

Requirements phase Problem statement (not list of features)

Design User Interaction first: objects later


What works for me (contd)What works for me (contd)

Programming Write unit tests first Source code control, frequent integrations. Assertion checks throughout Peer code reviews Tools: Profiler, Coverage & Thread analyzer Design docs updated as design changes Test for performance

System Test Web test tools

Post-mortem


QA @ BEAQA @ BEA

www.bea.comWeblogic Server

Market leading Java application server for the last seven years

Testers and programmers in same roomSeveral tiers of testing


Tier 1: Build and Test “Monkey”Tier 1: Build and Test “Monkey”

Fast, basic sanity check of recent checkins Build and test in clean-room environment

Rule by shame Monkey spams engineering for build or test

breakage listing suspects

Performs broad-spectrum functional test (3000+ test cases) that should always pass

Status viewable through intranetTools: Inhouse testing framework, WebLogic

itself used as intranet webserver


Tier 2: NightlyTier 2: Nightly

Nightly functional testing (same tools as earlier) Quarter-million test cases in 12 hours across 5+

codeline branches Partial JDK, OS, RDBMS platform matrix

coverage Daily report to all WLS engineering via web page QA folks analyze and summarize report each AM

Longevity testing Web based test tools


Tier 3: WeeklyTier 3: Weekly

Full functional testing Full JDK and platform and protocol

coverage Full database coverage Full 3rd party integration coverage

Performance testing Loadrunner, mercury interactive, grinder

30,000 client loadrunner configuration on ES4500, E10000

Stress tests, applications like ecPerf, ePizza, PetStore

Sun J2EE CTS


Tier 4: MonthlyTier 4: Monthly

Manual GUI testingPackaging/download testing

Installation verification Examples testing

Complexity/coverage analysis McCabe software metrics

Usability testingEach bug tracked independently. Bug fix

requires test case nameRegression tests


ReferencesReferences

General The Mythical Man Month, Fred Brooks About-Face: Principles of User Interface design, Alan

Cooper The Inmates Are Running The Asylum, Alan Cooper Bringing Design to Software, Terry Winograd The Design of Everyday Things, Donald Norman

Software Engineering www.joelonsoftware.com, Joel Spolsky www.holub.com, Alan Holub www.ObjectMentor.com, Robert Martin www.nakedobjects.org



Extreme Programming eXtreme Programming Explained, Kent Beck www.extremeprogramming.org xprogramming.com Extreme Programming Installed

Ronald Jeffries, Ann Henderson, Chet Hendrickson

Extreme programming considered harmfulwww.avoca-vsm.com/downloads/downloads.html

UI www.useit.com, Jacob Nielsen www.uidesign.net www.cooper.com Alan Cooper



Distributed computing A Note on Distributed Computing, Jim Waldo et

alwww.sunlabs.com/techrep/1994/abstract-29.html

WebLogic Application Serverwww.bea.com