C&C Project Consulting
University of Washington
Dude, what’s this supposed to do
anyway?
Copyright University of Washington , Joe Frost, Marcia Tufarolo and Scott Stephenson 2005. This work is
the intellectual property of the Authors. Permission is granted for this material to be shared for noncommercial, educational purposes, provided that this copyright statement appears on the reproduced
materials and notice is given that the copying is by permission of the author. To disseminate otherwise or
to republish requires written permission from the authors.
C&C Project Consulting
University of Washington
Joe Frost, System Engineer
Scott Stephenson, System Engineer
Marcy Tufarolo, Technology Manager
Computing & Communications
Administrative Information Systems
May 2005
Cumrec 2005
C&C Project Consulting
University of Washington
• State Research University
• 3 Major Campuses
• 40,000 Students
• 24,000 Faculty & Staff
May 2005
Cumrec 2005
C&C Project Consulting
The Project Nightmare
• Emergency call
• Major usage peak was about to start
• Major hardware failure occurred
• Sole developer with many hats left in a huff
• No documentation, no specifications, no expert,
no time, no backups
May 2005
Cumrec 2005
C&C Project Consulting
Where We Started
• Stabilized the hardware
• Categorized and handled customer problems
• Documented the applications
• Recommended backups and version control
May 2005
Cumrec 2005
C&C Project Consulting
Long Term Fix
• Group hired system administrators and
developer
• Stabilized application with version control, test
plans and monitoring
• Trained/cross-trained new staff
• Transitioned support to new staff
May 2005
Cumrec 2005
C&C Project Consulting
Lessons Learned
• Lots of extra time to work with unfamiliar and
undocumented applications
• Six months to get area self-sufficient again
• Nobody is irreplaceable
• Do it right from the “get-go”
May 2005
Cumrec 2005
C&C Project Consulting
Doing It Right
• Project Initiation
• Design Process
• Development
• Testing
• Support
May 2005
Cumrec 2005
C&C Project Consulting
Project Initiation
• Contacted by UW department with a need
• Meet with the users and sponsors
• Prepare proposal with time and cost
estimates
• Reach agreement to proceed with project
May 2005
Cumrec 2005
C&C Project Consulting
Doing It Right
• Project Initiation
• Design Process
• Development
• Testing
• Support
May 2005
Cumrec 2005
C&C Project Consulting
Design Process
Client/User
Design
Sessions
Client/User
Interviews
Development
Team Design
Sessions
Application
Prototype
Functional
Specification
Usability
Testing
May 2005
Cumrec 2005
C&C Project Consulting
Design Process cont’d
• Client and user interviews
– Involve them early and often
– Discover key business processes to be
included in the application
– Discover “hidden” requirements early
• Development Team design sessions
– What are the functional elements of the
system?
– How do these elements work together?
May 2005
Cumrec 2005
C&C Project Consulting
Design Process cont’d
• Client/user design sessions
– Discuss outstanding issues/questions
– Create/review application prototype
– Refine prototype after each session
• Usability testing
– Scope of application and user base
determines if it’s needed
• Write functional specification and get sign-off
from project sponsor
May 2005
Cumrec 2005
C&C Project Consulting
Functional Specifications
• Miscellaneous processes
– e.g., batch processes and external system
dependencies
• Database schema discussion
– Schema diagram
– Purpose statement for each table
– Detailed description of all table columns
May 2005
Cumrec 2005
C&C Project Consulting
Functional Specifications cont’d
• List of all assumptions
– What is and what is not in the application
• List of outstanding issues
– Discussion points for client meetings
– May result in additional assumptions
• List of future enhancements
– Desired functionality not in the first version
May 2005
Cumrec 2005
C&C Project Consulting
Functional Specifications cont’d
• UML use cases for each functional element
– Prototype screen shots
– Detailed documentation of integration points
– Document any issues
May 2005
Cumrec 2005
C&C Project Consulting
Example UML Use Case
Actor
World
Summary
UW NetID and password are entered in order to authenticate as a valid UW
NetID holder.
Preconditions
Actor must already have a UW NetID in order to log in.
Postconditions
None.
Trigger
Actor requests a page in the application that requires UW Authentication.
Normal Flow
The System presents the UW NetID login page.
Actor enters UW NetID and password.
The System authenticates the Actor as a UW Affiliate and continues on to
Authorization.
May 2005
Cumrec 2005
C&C Project Consulting
Example UML Use Case cont’d
Alternate Flow
None.
Exception Flow 1
Actor does not have a UW NetID. A link is already provided on the UW
Authentication Page which presents information on how to obtain a UW
NetID.
Exception Flow 2
Actor has a UW NetID but has forgotten the password. A link is already
provided on the UW Authentication Page which explains how to get a new
password assigned.
Issues
On the C&C IIS servers, this page is displayed automatically if the
destination URL is beneath a secured directory and the Actor has not
already authenticated. Secured directories are named ‘uwnetid’.
Authentication functionality is already in place using central resources.
May 2005
Cumrec 2005
C&C Project Consulting
UML Use Case Definitions
• Actor is an entity (people or systems) that interacts with
the system to achieve a desired goal.
• Summary describes the interaction between the actor
and the system and the value that the use case adds to
the system.
• Preconditions are external conditions outside the scope
of the use case that must be satisfied before the use
case can occur.
• Postconditions are actions that must be satisfied after
the use case has completed successfully.
• Trigger describes conditions that are expected to be true
when an actor enters a use case. The trigger may
describe a business need or be time-related, or could be
the completion of another use case.
May 2005
Cumrec 2005
C&C Project Consulting
UML Use Case Definitions cont’d
• Normal Flow describes the steps that the actor and the
system go through to satisfy the goal of the use case.
Normal flow describes the most common scenario for the
use case.
• Alternate Flow describes the less common or unusual
events of the use case, although it does not include
errors or exceptions.
• Exception Flow shows the interactions that occur when
an error or exception is encountered.
• Issues document assumptions, external conditions,
unresolved issues, or possible future enhancements
related to the use case.
May 2005
Cumrec 2005
C&C Project Consulting
Doing It Right
• Project Initiation
• Design Process
• Development
• Testing
• Support
May 2005
Cumrec 2005
C&C Project Consulting
Development Process
• Regular client meetings (as before)
• Code to the functional specification!
• Do peer code/design reviews
– Does my coding approach/design make
sense?
– What did I miss?
• Employ paired/collaborative coding where useful
May 2005
Cumrec 2005
C&C Project Consulting
Development Process cont’d
• Write in-code documentation
– Modification notes (in version control too)
– NDoc, JavaDoc or similar for auto-generated
HTML documentation
• Use a common application architecture /
framework
• Employ test-driven development (TDD)
• Keep the functional specification up to date
May 2005
Cumrec 2005
C&C Project Consulting
Common Application Architecture
• A structured, common set of development “best
practices” and reusable classes with a
“standard” API.
– Make 2+/3-tier Web development realizable
despite tight schedules
– Minimize dependencies on platform
dependent code
– Provide uniform tools for common functions
May 2005
Cumrec 2005
C&C Project Consulting
Common Application Architecture cont’d
– Eases application cross-training
– Provides design and coding efficiencies
– Helps provide better application support
– Helps manage change
– Handles multiple computing environments
May 2005
Cumrec 2005
C&C Project Consulting
Test-Driven Development (TDD)
“ The point of TDD is to drive out the functionality
the software actually needs, rather than what the
programmer thinks it probably ought to have.
The way it does this seems at first
counterintuitive, if not downright silly. But it not
only makes sense, it also quickly becomes a
natural and elegant way to develop software.”
Dan North, November 3, 2003
May 2005
Cumrec 2005
C&C Project Consulting
TDD cont’d
• Came out of the Agile software movement and
Extreme Programming (XP)
• Not about testing! Rather, it’s an integral part of
development
– Simplest coding to satisfy functional
specification
– Cleanest code that satisfies the requirements
• Tests are code-level documentation of functional
specification
May 2005
Cumrec 2005
C&C Project Consulting
TDD cont’d
• Development rhythm: write a test, write some
code, refactor (simplify) the code
• Run the unit tests often and regularly
• Keep the tests synchronized with the functional
specification
May 2005
Cumrec 2005
C&C Project Consulting
TDD Process
1. Start by writing testing code (“unit tests”) as
though the application code we want to
develop already exists
2. Write the minimum amount of application code
to get the tests to compile (use stubs)
3. Run the unit tests and verify they fail
4. Write the application code to satisfy the tests
5. Refactor the application code to be as simple
as it can be and still satisfy the tests
May 2005
Cumrec 2005
C&C Project Consulting
TDD Tools
• Unit-testing frameworks
– NUnit: www.nunit.org
– JUnit: www.junit.org
• IDEs
– Microsoft Visual Studio .NET NUnit add-in:
www.testdriven.net
– IntelliJ IDEA: www.intellij.com/idea
– Open source Eclipse: www.eclipse.org
May 2005
Cumrec 2005
C&C Project Consulting
What is NUnit?
• Unit testing framework for all .NET languages
(not just C#)
• Initially ported from JUnit, but recently
redesigned and rewritten from scratch
• Written entirely in C#
• Takes advantage of many .NET language
features (e.g., custom attributes and other
reflection related capabilities)
May 2005
Cumrec 2005
C&C Project Consulting
NUnit Instrumentation
[TestFixture (Description = "Test Money class")]
public class TestMoney
{
[TestFixtureSetUp]
public void FixtureSetup()
{
// Run once at test startup
}
[TestFixtureTearDown]
public void FixtureTeardown()
{
// Run once at test completion
}
May 2005
Cumrec 2005
C&C Project Consulting
NUnit Instrumentation cont’d
[Test (Description = "Test parsing of string representation")]
public void TestParse()
{
try
{
Money m = new Money("123.45");
Assert.AreEqual(123, m.Dollars, “Incorrect Dollars value");
Assert.AreEqual(45, m.Cents, “Incorrect Cents value");
}
catch (FormatException e)
{
Assert.Fail("Failed: " + e.Message);
}
}
}
May 2005
Cumrec 2005
C&C Project Consulting
NUnit GUI
May 2005
Cumrec 2005
C&C Project Consulting
Doing It Right
• Project Initiation
• Design Process
• Development
• Testing
• Support
May 2005
Cumrec 2005
C&C Project Consulting
Testing Process
• Unit testing
– Test-driven design: write the tests before the
code
• Manual “monkey” test plans
– Exercise the application through the UI
• Regression testing
– Run unit test suite
– Run monkey test plans
May 2005
Cumrec 2005
C&C Project Consulting
Testing Process cont’d
• Evaluation release for testing
• Track bugs in a database and prioritize
• Iterative beta testing with client
• Write and execute detailed functional test plans
(integration testing)
May 2005
Cumrec 2005
C&C Project Consulting
Bug Tracking
May 2005
Cumrec 2005
C&C Project Consulting
“Monkey” Test Plans
May 2005
Cumrec 2005
C&C Project Consulting
Regression Testing
• Always use unit test suite as first element of
regression testing
• Rerun the “monkey” test plans, if required
• Future: investigate Microsoft Application Center
Test
– Application to execute tests in a replacement
for the browser
– Runs scripts for regression and load testing
May 2005
Cumrec 2005
C&C Project Consulting
Doing It Right
• Project Initiation
• Design Process
• Development
• Testing
• Support
May 2005
Cumrec 2005
C&C Project Consulting
Support Process
• Additional client/user training sessions, as
required (train the trainers)
• Train a support backup
• Vacation Document
• Application health monitoring
• Bug tracking and resolution
• General computing infrastructure support
May 2005
Cumrec 2005
C&C Project Consulting
Vacation Documents
May 2005
Cumrec 2005
C&C Project Consulting
Lessons Learned
• Use a proven, agreed upon process
• Employ test-driven development from the
“get-go”
• Use a common application architecture
• Don’t be afraid to “over communicate”
• Train your support backup
May 2005
Cumrec 2005
C&C Project Consulting
The Testers
[email protected]
May 2005
Cumrec 2005