Applying XP and AMDD to Our Sample Application

Now that we have looked at some background on a generic software development process, let's apply parts of this to our sample application.

Domain Model

Let's start our domain model, which essentially has all the data entities and their relationships, but no attributes. This helps to define some initial domain concepts and their relationships to each other. The domain model is typically sketched while working with domain experts and people with business knowledge, such as business users and analysts.

Figure 2.2 shows the domain model for our application, Time Expression. As you can see, our domain model has a simple design because it contains the bare-minimum number of entities to get us going while following a clean design. Again, we just need a simple domain model to start with, something good enough for us to move forward with, which we have now.

Figure 2.2. Domain model for Time Expression.

User Interface (UI) Prototype

Now that we have a fairly good idea of the features our customer is looking for in Time Expression, we can rapidly mock up some prototype screens to allow the customer to test drive the mocked web application.

By developing prototype screens early on, you put a face to the application, which gets people excited and motivated to get the application built. This is also a good way to eliminate many of the cosmetic changes up front (such as fonts, colors) and come up with an agreed upon consistent look and feel that can be implemented using cascading style sheets (CSS). Furthermore, you can use prototypes to model the business process and subsequently use the same prototypes to define the users' stories (covered later in this chapter).

Figures 2.3 through 2.10 show what the various screens in the Time Expression application will look like. We will begin designing this application in the next chapter; then, in subsequent chapters, we will get our environment set up and begin developing some code!

Figure 2.3. Sign-In screen.

Figure 2.4. Timesheet List screen.

Figure 2.5. Enter Hours screen.

Figure 2.6. Print Hours screen.

Figure 2.7. Approve Timesheets screen.

Figure 2.8. Mark Paid screen.

Figure 2.9. Report: Staff Hours screen.

Figure 2.10. Report: Overall Summary screen.

At this point, let's keep these screens as simple HTML (versus JSP) files so that we can pull them up locally in a browser instead of having to run them in a Java web server or pull them up in a JSP/HTML editor each time. When working with a customer, it is a good idea to keep technology out of the picture, as much as possible, until you are ready for developmentthis keeps things simple, so you can avoid any "technical difficulties" and instead focus on the business requirements at hand.

Managing Customer Expectations During UI Prototyping

Although UI prototype provides significant benefits, it is important to manage the customer's expectations in this stage, as well. For example, I have run across two problems. First, when customers see prototype screens, they might believe the application is mostly developed and almost ready to be deployed. However, as developers, we know there is a lot more to application development than mocked up screens. Second, user prototyping can get out of hand if the customer is picky about fonts, button placements, and other UI aesthetics. Still, the customer should always come first because they are typically paying for the application, and so you should try to find the right balance when managing a customer's expectations. Of course, one effective way of getting around this management of expectations is to do hand-drawn UI sketches instead of prototyping. This keeps thing simple because these sketches can be drawn on paper or the whiteboard.

Storyboard

A storyboard, also called a UI flow diagram or website map, is essential to show a navigation map of the various screens. Figure 2.11 shows the storyboard for our sample application. As you can guess from our storyboard, after a user is signed in to the system, the user is directed to an initial screen designated for the user's role type. Users belonging to either the Employee and Manager role have additional functionality that can be accessed from the initial screens.

Figure 2.11. Storyboard (also known as a UI flow diagram).

User Stories

Given the business requirements and UI prototypes defined for Time Expression earlier in this chapter, we can now define a set of user stories for our application. As explained earlier in this book, I decided to use XP/AMDD; therefore, you see the use of the term user story versus use case. Although these serve similar purposes, user stories tend to be shorter than use casesfor example, one to three sentences each. The remaining details can be discussed between the developer and the customer when the developer begins working on a given user story in the planned iteration; hence, the term active stakeholder participation.

Use cases come in many formats themselves. The three I'm familiar with are formal, brief, and casual. The casual format is probably closest to a user story because it is short and informal. Formal use cases can entail a page or two of requirements with preconditions, postconditions, success/basic path, failure/alternative path, and other sections for each use case. The reason I have described use case and their formats here is because certain organizations define essential use cases (or even business requirements with "shall" statements) first, and then later break each use case down into one or more (maybe even several) user stories using our guideline of one- to three-day development per user story or development task.

We will use user stories in this book to not only define the requirements, but also to name our Java classes, using the story name/tag, and create acceptance tests. Table 2.2 shows the user stories with the priority and initial estimate to complete. Note that the user stories you might find in the real world might be a bit more detailed than what I have shown in Table 2.2; however, given the simplicity of Time Expression, these work fine for us.

Table 2.2. User Stories, Priorities, and Estimates for Our Sample Application

#	Story Name (Tag)	Story Description		Priority	Points (estimate)
1	Enter Hours	User can enter hours worked and save this data.		1	2
2	Timesheet	List Employee can see a list of timesheets previously entered and click the ones that can be modified.		1	1
3	Sign In	User can sign in to system using a valid employee id and password.		2	1
4	Sign Out	Users can sign out of system to end current session.		2	1
5	Reminder Email: Employee	A reminder email is sent every Friday at 2 p.m. to employees who have not submitted their timesheet yet.		2	1
6	Print Timesheet	Employee can print timesheet using best possible formatting in browser and automatic display of print dialog box.		3	1
7	Report: My Hours	Employee can run a report named "My Hours" to view/print summary of weekly hours.		3	1
8	Submit Timesheet	User can submit timesheet after hours have been entered; submittal email is sent to Manager.		3	1
9	Report: Staff Hours	Manager can run a report named Staff Report to view a summary of a given week's hours for all employees under Manager.		4	1
10	Report: Overall Summary	Executive can run a report named Overall Summary to view a summary of a given week's hours for all Managers in company.		4	2
11	Timesheet Approval	Manager can approve/disapprove timesheet;notification email sent to Employee and Accounting department.		5	1
12	Timesheet Payment	Accounting can indicate that Employee has been paid.		5	1
13	Reminder Email: Manager	A reminder email is sent every Friday at 4 p.m. to managers who have timesheets pending approval.		5	1
				Total Points:	15

Incidentally, a good book to check out on user stories is Mike Cohn's User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series, 2004).

The estimates shown in Table 2.2 are initial estimates, or sizing. The developer provides more accurate estimates at the beginning of the iteration when the user story will be developed, because the user story can be broken down into development tasks to better size the time required to complete the entire user story. Incidentally, I have come across real-world projects where they did not do the breaking down of user stories into tasks, nor did they size the user stories during iteration planning. The reason for this was because sometimes the user story priorities changed or the user story itself changed, so the upfront work was for nothing. Instead, they picked two to three stories on day one of a new iteration and only estimated those.

Points (last column of Table 2.2) are some unit of measure relative to the given project. For example, 1 point could equal 1 regular workday, 1 ideal workday, 1 week or another periodwhatever the customer and developers agree on. Whatever each point might measure is then used to provide estimates to the customer.

Ideal (development) days are a good way to estimate projects because it factors in planned and unplanned events (for example, meetings, computer problems, sick leave, and so on). The difference between a regular day and an ideal day is referred to as the load factor.

A load factor, typically between 2 and 4, is a number you multiply your initial estimate by to come up with an ideal day. For example, I like to use a load factor of 3 for projects where I have a good understanding of the business requirements and technologies. (Note: If you believe there are risks involved, such as a learning curve related to a new technology, you can use a higher number, such as 4 or even 5.) For example, if we know a development task will take me approximately 8 hours of uninterrupted, totally focused, heads-down time, we can multiply that by 3 (that is, 8 * 3) and come up with 24 ideal hours or 3 ideal days (assuming a 8-hour work day).

In this book, we will develop the Enter Hours and Timesheet List (items 1 and 2 in Table 2.2; both with priority 1). So, if we use these two screens as example, it would take 9 actual days to complete these screens (that is, 3 ideal days times the load factor of 3).

Release (and Iteration) Plan

After the customer (end user and/or business analyst) has defined the user stories, the customer and development project manager (and/or developer) can put together a release plan for the next release or version of the application.

A release plan is essentially a project plan listing various system releases and the dates for each release. In this book, we will assume that we have only one releasefor example, v1.0.

Releases are typically small, about 1 to 3 months in length. Each release consists of a set of user stories the customer wants implemented in that release. Each release is then further broken down into iterations.

Iterations range between 1 to 3 weeks in length. Each iteration contains a list of user stories chosen from the set of user stories for the given release that the customer wants implemented in that iteration (along with defect fixes from previously failed acceptance tests).

Based on the user stories we defined earlier in this chapter, we can come up with an initial release plan, shown in Table 2.3, to incrementally build release v1.0 of our application.

Table 2.3. Release Plan

Iteration	Features		Release Date
0	Environment setup (JDK, Ant, JUnit) and database connectivity demo using Hibernate.		23-Dec-06
1	Small releaseAll priority 1 user stories.		12-Jan-07
2	Small releaseAll priority 2 user stories.		26-Jan-07
3	Small releaseAll priority 3 user stories.		09-Feb-07
4	Small releaseAll priority 4 user stories.		23-Feb-07

Our release plan does not use priority 5 user stories because these will be pushed off to release 2 of our application. Of course, this is all fictional and many of the examples we have looked at so far, such as the iteration and release plans, are for demonstration purposes only. In the real world, you are bound to see more detailed plans.

After the release plan containing the various iterations is defined for the next release of the software, the developer can begin working on the first iteration.

Prior to each iteration, the customer and development staff get together for an iteration-planning meeting, the outcome of which is an iteration plan for the next iteration. The customer picks the user stories that will be developed in the next iteration. The developers break down each user story into individual development tasks required to implement the user story. This is done so that each development task can be assigned to a developer, but more importantly, the tasks can be used to more accurately estimate the total development effort for the given user story and, in turn, the next iteration.

If the total estimate or points (to implement all chosen user stories for the next iteration) exceeds the total points implemented in the previous iteration (known as the Project Velocity in Extreme Programming), the customer must choose which user stories (or defect fixes) to defer to a future iteration or release. If the opposite is truethat is, there is room to get more done in the next iteration, the customer may add additional user stories, defect fixes, or enhancements, if needed.

For our purposes in this book, I have skipped including a sample iteration plan because this book is more about development than process. Also, formats of an iteration (and release) plan can vary, so instead I chose to leverage the release plan (see Table 2.3) and group our user stories by priority in it instead of breaking them down individually in each iteration plan.

Glossary

This is probably a good time for us to define a glossary for Time Expression.

A glossary is essentially a set of common terms, or project vocabulary, that everyone agrees on for the project. This list can include business terms (for example, Timesheet and Approved) or technical terms (for example, Entity, used while discussing the logical data model). The obvious benefit of a glossary is that it gets everyone in agreement with the terminology and definitions of each term to avoid any confusion. (We have enough of that already given the terminology/acronym madness that exists in our industry.)

• Accounting The accounting department/staff.

• Approved Status of a timesheet when a Manager approves a previously submitted timesheet.

• Employee A person who works on an hourly basis and reports to a manager.

• Executive An officer of the company, such as CEO, CFO, or COO.

• Hour A full hour of billable work that can be entered into a timesheet and the employee can get paid for.

• Manager Direct supervisor of an employee.

• Paid Status of a timesheet when the accounting department has issued a check.

• Period Ending Date This is the last day of each week (Sunday, in our case).

• Pending Status of a timesheet until the user submits it.

• Submitted Status of a timesheet when an employee has submitted a timesheet. Timesheet is "locked" from further changes by employee.

• Week A 40-hour workweek from Monday through Friday.

Whiteboard Architecture

By now, we have enough information to put together an informal architecture diagram. Figure 2.12 shows a high-level architecture diagram for Time Expression (on an indispensable tool of the trade, the whiteboard). By establishing this diagram, the developers and customer can agree on major technologies (for example, Java, database, web/app server) that will be used to build Time Expression.

Figure 2.12. An informal, high-level architecture on a whiteboard.

We will use an electronic and more detailed version of this architecture diagram in the next chapter to help us go one level deeper into the design of the applications. Converting whiteboard diagrams or CRC cards to electronic formats are my personal preference because legibility isn't a real concern with electronic artifacts. However, you could simply digitize artifacts such as whiteboard drawings and CRC cards via tools such as a digital camera and scanner, respectively.