what they don’t tell you: software engineering lessons
DESCRIPTION
What they don’t tell you: Software Engineering lessons. Sriram Srinivasan (“Ram”) [email protected]. Good design comes from. Experience. Experience. comes from making bad mistakes. Today, you’ll learn. To look at methodologies with a critical eye What worked for me, and what didn’t - PowerPoint PPT PresentationTRANSCRIPT
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
Sriram Srinivasan 11
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
Sriram Srinivasan 12
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
Sriram Srinivasan 13
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
Sriram Srinivasan 14
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
Sriram Srinivasan 15
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
Sriram Srinivasan 16
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
Sriram Srinivasan 17
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
Sriram Srinivasan 18
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
Sriram Srinivasan 19
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
Sriram Srinivasan 20
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
Sriram Srinivasan 21
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
Sriram Srinivasan 22
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
Sriram Srinivasan 23
ReferencesReferences
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
Sriram Srinivasan 24
ReferencesReferences
Distributed computing A Note on Distributed Computing, Jim Waldo et
alwww.sunlabs.com/techrep/1994/abstract-29.html
WebLogic Application Serverwww.bea.com