C&C Project Consulting University of Washington Dude, what’s this supposed to do anyway? Copyright University of Washington, Joe Frost, Marcia Tufarolo

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 non-commercial, 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.

May 2005 Cumrec 2005



Joe Frost, System Engineer

Scott Stephenson, System Engineer

Marcy Tufarolo, Technology Manager

Computing & CommunicationsAdministrative Information Systems




• State Research University

• 3 Major Campuses

• 40,000 Students

• 24,000 Faculty & Staff



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



Where We Started

• Stabilized the hardware

• Categorized and handled customer problems

• Documented the applications

• Recommended backups and version control



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



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”



Doing It Right

• Project Initiation

• Design Process

• Development

• Testing

• Support



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



Doing It Right


• Design Process

• Development

• Testing

• Support



Design Process

Client/UserInterviews

FunctionalSpecification

ApplicationPrototype

UsabilityTesting

Client/UserDesign

Sessions

DevelopmentTeam Design

Sessions



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?



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



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



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



Functional Specifications cont’d

• UML use cases for each functional element

– Prototype screen shots– Detailed documentation of integration points– Document any issues



Example UML Use CaseActor

WorldSummary

UW NetID and password are entered in order to authenticate as a valid UW NetID holder.

PreconditionsActor must already have a UW NetID in order to log in.

PostconditionsNone.

TriggerActor requests a page in the application that requires UW Authentication.

Normal FlowThe 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.



Example UML Use Case cont’dAlternate 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.



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.



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.



Doing It Right


• Design Process

• Development

• Testing

• Support



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



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



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



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



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



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



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



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



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



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)



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

}



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);}

}}



NUnit GUI



Doing It Right


• Design Process

• Development

• Testing

• Support



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



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)



Bug Tracking



“Monkey” Test Plans



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



Doing It Right


• Design Process

• Development

• Testing

• Support



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



Vacation Documents



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



The Testers

[email protected]