ChrisGarrisonProjectThesis

1
Auburn University:
Master of Software
Engineering Design
Project
Featherweight:Achangemanagement application to helpteams
integrateagileprocessesinto theirorganizations.
ChrisGarrisonunderthe guidance of Dr. DavidUmphress
10/28/2009

2
Abstract
Too often, software developmentteamshave few ornodefinedsoftwareprocessesinplace.
Many teamscurrently“getby” withan ad hoc approach,but as the software industrymaturesitwill
become increasingmore difficultforthese teamstoremaincompetitive. Adoptingaprocessis
challengingforsome teams.The trainingandtoolsrequiredare sometimesprohibitivelyexpensive.
Often,teamsdissolve andprojectsare complete withinayear,soitis difficultformanagerstojustify
large expendituresontrainingandtools.More plandrivenprocessesare sometimesinfeasible for
smallerteamsbecause theyare frequently rolebased.Thesemethodologiessometimeshave more roles
than smallerteamshave members. Well establishedteamsmayresistthe change makingprocess
adoptionmore difficult.
Featherweightisaneasy-to-integrate change managementapplicationthathelpsteams
incorporate agile processesintotheirorganization.The applicationprovidesstrongsupportfor
fundamental componentsof agile software practice:Requirementsmanagement,communicationand
collaboration,responsibilityandprojectmanagement.Itservesasa processfoundationuponwhich
teamscan mature theirprocess as theyare able.
Featherweightisbasedonabug trackingsystemso teamscan dynamicallytrackrequirements
as theyprogressthroughthe team’sworkflow.The systemfunctionsasa centralizedrepositoryfor
developmentassetswhichprovidesdetailedformstocapture requirementsaswell astestcases,
designsandattachmentssuchas UML diagrams,screenmock-upsandstate charts. Thiscentralization
enhancesteamcommunicationandcollaboration.Responsibilityisakeyconceptinthe applicationto
guard againstblindspotsin the organization. Projectmanagerscansee metricsthatcompare user’s
effortestimatesversustheiractual effortexpended whichhelpsgenerate more reliableschedules.
Featherweightfunctionsasthe middle groundbetweenadhocand plandrivenmethodologies.
Teams(especiallysmallerteams)whoapproachdevelopmentinanad hocfashioncan benefitfromthis
applicationbecause itprovidessupportforfundamental conceptsof software process.More
experienced teamscanalsobenefitbythe application’sgeneral agilesupport.Regardlessof ateam’s
processmaturity,Featherweightcanhelpteams produce successfulsoftware products, whichis the key
to successinthe software industry.

3
Chapter 1
In order to consistently produce on-time, high quality software, development teams
must integrate and practice software engineering process principles. Evidence clearly indicates
that groups using formal processes outperform those who have no process engineering
methods.1,2 Even with this evidence, a large number of development teams still use ad hoc
approaches. For now, some teams may be able to survive without a defined process or
methodology, but as the software development industry matures, these teams will find it
increasingly more difficult to compete.
The Problem:
Unfortunately, adopting a process is not as simple as “deciding to be more efficient.”
There are several challenges to overcome in adopting a development methodology including
training, tool cost, and the need to hone the process to fit the organization. Overcoming these
challenges typically pays off in the long run, but they can pose significant problems for some
organizations. In today’s software environment, some teams don’t have adequate resources for
long term planning. Even teams within successful software companies have to contend with
budgets that may not support long term strategy or training needs.
Obviously, training is needed so teams can implement a process. Both managers and
team members must understand the process framework, the underlying process models,
evaluation algorithms, and tools provided.3 Integrating a process into an existing team can also
be difficult. Many organizations have a strongly embedded culture. Established teams may be
reluctant to change from the status quo.

4
Another challenge in integrating process is cost. Process tools can be prohibitively
expensive. One license for IBM’s Rational Software Analyzer Enterprise Editions costs $50,000
per year.4 Several other commercial offerings are available, but they typically cost over $1000
per license. There are some free, open-source process tools, but they require the same training
as their for-fee counterparts. Someone would likely need to be dedicated to learn and
implement the tool which could stress schedules and resources. Whether a team member
learns the product, and then trains the staff, or a consultant is brought in to train, these options
can be time consuming and expensive.
In 1992, a survey estimated that the five-year cost of computer- aided software
engineering (CASE) tool adoption to be $35,000 per user, with the majority of this cost
attributable to such learning-related activities as technology evaluation, consultants, installing a
methods support group, and training. And, these estimates do not include the potentially
substantial costs required to reach the point on the learning curve where performance is
comparable to preexisting technologies.5 Generally speaking, the more plan-driven the model
process, the more training required for its implementation. Smaller companies simply cannot
afford to stay in business with this type of expense.
Another problem in adopting a development process is that many case tools are role-
based. In small development shops, roles are often imprecisely defined and sometimes shared.
These developers typically wear many hats.6 IBM’s Rational Unified Process and their open
source product “Open Up” has 7 roles identified and used in its product.7 Extreme Programming
calls for pair programming. 8 These constraints make it difficult or infeasible for smaller teams
to integrate these practices. This can be another major barrier in adopting a model process.

5
Most commercial /start-up companies need to stay as lean as possible. It is difficult for
these teams to justify the investment in implementing a large process strategy. In all of these
cases, learning the process or tool would require the team to stop billable work. In a
commercial environment “stop billable work” is a phrase you seldom hear. Larger, contract
based firms can often absorb the cost, but not in leaner organizations. Plus, since projects
usually last from one to three years, it is sometimes difficult to justify implementing a larger
scale process for a team that will dissolve in a relatively short amount of time. Understandably,
smaller teams must question their return on investment.
Another contributor to the lack of process utilization is simply the relative immaturity of
the industry. Many practitioners are simply unaware of software process. They view software
development strictly as an implementation activity. The industry is just starting to see a
“process push” which is making it more and more difficult for ad hoc teams to stay competitive.
TheNeed:
There is a need for a flexible, low cost tool which can help teams implement software
process fundamentals. This tool could function as a “lightweight” process framework or serve
as a starting point to help an organization identify which process improvements to implement.
Perhaps it could help a team identify a plan driven process to fully integrate. The tool should
support fundamental engineering principles such as requirements management,
communication and collaboration, project estimation and management, and role
responsibilities among other key software engineering principles.

6
Since many of the problems in ad hoc development environments are related to team
size and price, a tool supporting agile methods would be most appropriate. Generally speaking,
agile (lightweight) processes are appropriate for smaller teams with a higher level of
experience, and products with lower risks but highly dynamic requirements. See figure 1.1.
Figure 1.1 Agile versus Plan Driven Processes
The tool should enable teams to start small and expand process controls to fit their
needs. See figure 1.2. For some teams this could be more effective than starting with a large
formal process and be forced to pare it down to fit the organizations current needs and abilities
(team size, roles, etc.). “If your organization does not have methods in place to measure its
improvement efforts, start small! All measurements and methodologies should be evaluated to

7
determine their appropriateness to your organization and its overall software process
improvement effort and tested prior to implementing them throughout your organization” 9
Figure 1.2 Process Improvements added over time
The tool would not need to provide some of the more detailed and complex
functionality included with much higher priced systems. However, it should focus on satisfying
common process elements by providing support for the technical, managerial and process
facets of software engineering. Ultimately, the tool should enable software teams with little or
no engineering discipline to begin the process of maturation by incorporating process
components as the teams is ready. As previously stated, many small but experienced teams
don’t necessarily need a plan driven process framework. A change management tool could
serve as a process foundation which would support and enable the incorporation of agile
processes.

8
Regardless of the tool or model process, the goal of all software teams is to have
successful projects. Whether that takes an “inch-pebble ironbound contractual approach” or an
ad hoc approach, the goal is still a successful project. The process a team uses is only a means
of accomplishing this goal. See table 1.2 for a list of key elements and perspectives to a
successful project.
Table 1.1 What makes a project successful? 10
Executive Perspective
 Not oversold or overcommitted
 Milestones achieved
 Costs controlled
 Customer enthusiastic
Project Leadership Perspective
 Determined user needs
 Resources available
 Schedules realistic
 Change controlled
 Progress tracked
 Management supportive
User Perspective
 Project team understood needs
 Vital changes accommodated
 Progress reported
 Product timely
 Product
Project Team Perspective
 Involved in planning and execution
 Policies well communicated
 Adequate tools provided
 Humane treatment by management
and user
Producing consistent, on-time, high quality software products is the only way for teams to
be competitive and succeed in industry. A flexible, low cost change management tool could
enable smaller teams to integrate software process principles into their organization without
the expenditures associated with more plan driven approaches.

9
Chapter 2: Previous Work/ Motivation
The genesis of this work comes from my experience in an environment with little or no
software development process. I worked for three years for a commercial division of a major
engineering and defense contractor. Even though our process began as ad-hoc, we went
through significant maturation as the project progressed. We developed our own hybrid
process.
Thestarting point:
At the beginning of the project, the President of the company would dictate which
features he wanted delivered in the next release and when he wanted it delivered. Neither the
president nor the development team had any idea how much effort was actually required to
implement the features. It was classic right-hand extraction (RHE). It was also problematic in
that the sales and marketing department was counting on the features to be complete on that
date set by the president. They had their own sales expectation to meet.
Needless to say, we weren’t very successful in meeting our deadlines. The only way our
goals were met was through heroic efforts. Meeting a deadline was unfortunately very
counterproductive, because it reinforced the president’s belief that his schedules were
reasonable, despite our objections.
One of the few tools we had was a change management/bug tracking system. Since we
were primarily focused on new development we initially didn’t use it. But in an effort to start

10
forming some processes (and to protect ourselves) we started entering our features into the
bug tracking systemand assigning estimates to them.
Maturingthoughgradual processimprovement
Over the next two years, our development process matured significantly. We tracked all
new features as well as bugs through the bug tracking system. We estimated how long each
feature would take; and we also used historic estimates as a sanity check on our newer
estimates. Our releases schedules (which were now much more accurate) were based on our
estimates and historic performance instead of RHE. The features included in each release were
selected by a team composed of members from management, marketing and development.
Each feature had a “priority” attribute to aid in evaluating the features. All groups met and
reviewed a report which listed all outstanding features with their estimates, and priorities. We
would generate a consensus on which features should be delivered in our monthly release.
Also, our defect rate went down and our morale went up because we had all but
eliminated the death march. Our software support team also reaped benefits from our process
growth. They were able to search the feature/bug database to see if customer calls were bugs
or upcoming features and if so/when they were scheduled to be fixed.
The president was able to understand our schedules. He also had a good view into our
division because he could logon to the systemand review tasks. The sales teamhad a much
more accurate view of project timelines. This was significant because marketing materials were
created based the contents of each release. Marketing materials were much more accurate and
up-to-date because of our process.

11
The bug tracking systemserved as the center cog in our company’s operational wheel. It
became the primary source of information for the entire enterprise. Everyone in the company
had access to it. By starting with small process improvements and expanding our efforts as we
progressed, we developed a unique process that matched the company’s needs.
My motivation is to develop an application that can help companies (particularly small
companies) integrate process improvements into their organization at a pace and a price they
can afford. My goal is to extend and expand on the change management system model to
provide a broader palette of process enabling elements.

12
Chapter 3:
Featherweight is a change management system that supports the integration of software
engineering processes and principles into software organizations. Based on a bug tracking
system, the application supports dynamic requirements management, team communication
and collaboration, and project management while providing a solid foundation on which to
expand agile development practices.
Featherweight serves as a centralized information repository. Rather than having project
schedules, design artifacts, screen shots, test plans and requirements scattered throughout an
organization, the application provides one interface to store and view these development
assets. Teammembers responsible for resolving issues or implementing solutions have instant
access to all the information needed. Their actions within the system are stored for enhanced
traceability.
The application is also easy to learn and integrate into existing teams. It features
customizable workflows (representing the various phases within an iteration), so the virtual
system status of an issue mirrors the actual status. Teams can utilize a standard workflow or
create a custom flow that best serves their organization. The application also provides
comprehensive search tools enabling team members to focus on their highest priority tasks.
The user interface is “compressed” to resemble popular Integrated Development Environments
(IDEs) so the learning curve is minimal.

13
Providing on time software is a constant challenge for development teams particularly
those in dynamic environments where requirements can change frequently. Featherweight
provides a mechanism to calculate estimates and release dates. It also creates “adjusted”
values based on past estimates and historical performance data. This provides a good
perspective to team leaders and project managers planning and scheduling development
efforts.
Teams who have few or no established processes can begin building process maturity by
using Featherweight. It is also a good tool for smaller, more experienced teams who already
utilize agile methodology. Featherweight provides a sound framework on which to develop
process maturity and help ensure that teams create quality, on-time software products.
Functional Components:
RequirementsManagement
Featherweight provides a simple yet effective means of requirements management. The
“work item” is the principle object in the domain model. It represents a requirement, a bug, a
task to be completed, etc. Each work item has several modifying attributes that aid in general
requirements management. See table 3.1 for a list of work item attributes.
Table 3.1
Attribute Description Examples Required
Status Current status of work item.
Represents a point in team
workflow or iteration
Unassigned, In Progress,
Peer Review, Design,
Testing…
Yes
Version Created “current” version when found (if
bug)
V 1.1, 1.2, etc No

14
Version Target Version in which to be completed V 1.3, 1.4, TBD Yes
Client Client the work item is for U.S. Government, ABC Co. No
Priority Importance of work item Trivial, Low, Medium, High Yes
User Responsible User who is currently responsible
for the issue
Yes
Type The type or work item Bug, Requirement,
documentation, follow up
phone call, etc.
Yes
Parent / Child Work items are recursive. Work items can have super
and child work items
No
Short, Long
Description
Text fields enabling users to
elaborate on work item
Short =
Yes
Long =
No
How to Recreate Describe how to recreate (if bug
or recreate-able issue)
No
Estimate Fields for developer, team leader,
tester, etc. to provide estimates.
Float values acceptable No
Actual Actual unites required to
complete work item
Float values acceptable No
Completed Date Date the work item has
completed the custom work flow
mm/dd/yyyy format No
Attachments Users upload attachments
associated with the work item
Screen shots, mockups
UML Diagram, other design
artifacts
No
Design CRC Card based design form No
Test Cases Test cases for the work item No
Activities Log of all activity for the work
item
Create, updates, comments Yes/ No
Work items not yet assigned to a version sit in a pool with other unassigned items. Team
leaders or a committee can review all unassigned issues and associate a target version for the
highest priority work items. The others obviously remain in an unassigned status available for
selection for the next iteration.
Updates to a work item such as status changes, user responsible changes, adding a test case
or design are logged in an activity table. On these updates, the user is presented a box to insert

15
comments about the change being made. These actions are visible in a tree node (“Activity”)
associated with the work item so users can not only see the current state of the work item, but
also the change history. In future version, there will be greater control over the activity object.
Customizableworkflow/status
Most teams have a workflow that is defined or influenced by the team’s size, culture,
experience, etc. Rather than hard code a workflow for the organization as some other change
management systems do, Featherweight enables administrators to create an application
workflow that mirrors that of the team. This prevents work items from “falling through the
cracks” and it enables teams to modify their workflow as their team grows and matures.
There is also a “hidden” attribute so teams can eliminate a status from their current
workflow when necessary. Statuses for new work items are limited to those (not hidden), but
historical data with previously used statuses (hidden) would be viewable. Additional
functionality has been defined and designed but not fully implemented.
Responsibility
A work item must always have a user who is “currently responsible” for it. Even those in
the queue awaiting target version assignment have a user responsible. This feature coupled
with customizable workflow can provide valuable insight into an organization’s process. While
the system will always be black and white with regard to status and responsibility, real-world
situations are not always that distinct. There are many instances when miscommunications,
overlapping responsibilities, mentor/trainee relationships, etc., can cloud the picture. In other
words, the system does not always accurately mirror reality. These instances are opportunities
for teams to examine their processes. Is the mismatch reasonable and to be expected? Or is a

16
process analysis in order? Perhaps a new status could be added to the work flow or maybe one
could be taken away. Are developers accurately implementing designs and requirements, or are
team leaders not providing enough detail? Both the customizable workflow and user
responsible features are key components in integrating process elements into an organization.
Design
System architects and engineers need to be able to communicate designs to those
implementing projects. CRC cards are a typical means of creating designs in many model
processes including XP, Scrum, PSP among others. Featherweight provides a CRC form for
engineers to complete and convey designs to those responsible for implementing the solutions.
The Featherweight CRC design form includes:
 Class name
 Super class name
 Sub class name
 Interfaces implemented
 Methods
 Design notes
Class name is required.
And for greater detail, a user can upload UML class diagrams, sequence diagrams,
flowcharts, etc. to further define expectations. Most document types of reasonable size can be
uploaded into the system. Having all development artifacts housed in one systemgreatly
reduces errors of omission, miscommunications and ineffective collaboration.

17
TestDrivenDevelopment
Many agile development methodologies stress testing: Both unit and integration testing.
Test engineers can specify any number of tests to be performed by the developer or by the
testing team. The testing form includes the following fields:
 Test Case Description
 Test Execution Steps
 Expected Results
 Precondition
 Test Type
 Date Tested
 Pass/Fail
 Results/Remarks
 Postcondition
 Configuration
Search Features
Featherweight provides strong support for search queries. This benefits engineers and
developers in managing requirements, but it also provides a critical troubleshooting tool for
support staff. Teams that can quickly access solutions to problems have a significant
competitive advantage compared to those teams that don’t.
A set of filters can be applied to a search which gives teams comprehensive search
capabilities. Users can search for work items with a variety of attributes. The searchable
attributes and operators are listed below.
Attributes
 Work Item Id
 User created
 (Current) user responsible
 Short Description
 Long Description
 How To Recreate
 Estimate 1 and 2
 Actual 1 and 2
 Priority
 Date Created
 Type
 Target Version
 Version Created
 Custom Status

18
 Completed Date
Operators
 = (equality)
 != (not equal)
 <
 <=
 >
 >=
 LIKE (matches String pattern)
 ~ (starts with String pattern)
One important feature of the search function is dependent select boxes. When a user
selects an attribute, the operator and value fields automatically update to reflect valid
selections for that attribute. For example, if a user selected to search on “Date Created”, the
operators LIKE and ~ would be removed from the selection criteria for operators. These
operators aren’t valid for dates, so they are excluded. This would leave =, != , >, >=, <, and <=.
When the user clicks in the date value area, a calendar pops-up to help select the date. Figure
3.2 shows an example of selecting “Date Created” and figure 3.3 shows an example of selecting
the “User Created” attribute.
Figure 2.2

19
If the user selects “User Created” as an attribute, the only valid operators would be = and
!=. A dropdown selection listing all users would replace the existing value text box so it is
impossible to enter an invalid value. The user can create more complex queries by selecting
from two conjunctions “and” or “or”. This enables users to layer several filters into a search.
Figure 3.3
Users may also save their searches. When the user selects the saved query from a drop
down list, all attributes, operators, attribute values and conjunctions are updated to the values
in the saved query.
Figure 3.4

20
Query search results are displayed in a sort-able table. Work Item Id, Target Version,
Priority, User Responsible, Target Date and Short Description are the attributes displayed in the
table for sorting and review. Also, the user can view more information by simply hovering over
a result. When the user hovers over short description, the long description will be displayed in a
tool tip. See figure 6.5. When hovering over user responsible, the user created will be
displayed in a tooltip. Hovering over date created displays last activity date and when hovering
over target version, the date found will be displayed in a tool tip.
Figure 3.5
Attachments
As mentioned in the design section, attachments can be uploaded and stored with the other
work item information. Virtually any type of attachment may be uploaded. Teams can include
designs, screen shots, mockups, contracts, etc. Once again, having all development assets
stored in one central location is very important for team collaboration and cooperation.
Project Management
A critical aspect in software engineering is the ability to project software release dates
and deliver on-time software. Featherweight supports this in several ways. First, a system
administrator specifies the target delivery date for a version. This can be done by simply
selecting a date, or by entering the number hours of to include in a release. This is good

21
feature for helping control requirements creep and to enforce the agile principle of short and
frequent iterations.
Users who perform work on a work item simply provide an estimate for their efforts (in
hours) before beginning work. Once their task is complete, they enter the actual amount of
time taken. As the version is worked by the development team, project managers can see
graphs of a user’s (or team’s) progress by version.
Current Release – mapped against the Target Version release Date:
 Estimates of completed issues / Estimates of incomplete issues
 Actuals of completed issues / Estimates of incomplete issues
 Actuals of completed issues / Adjusted estimates of incomplete issues (based on actual)
Previous three releases - mapped against the Target Version release Date:
 Estimates of all completed issues / Estimates of current incomplete issues
 Actuals of all completed issues / Estimates of current incomplete issues
 Actuals of completed issues / Adjusted estimates of current incomplete issues
Previous 6 releases - mapped against the Target Version release Date:
 Estimates of completed issues / Estimates of incomplete issues
 Actuals of completed issues / Estimates of incomplete issues
 Actuals of completed issues / Adjusted estimates of incomplete issues
Teams utilizing this feature will need to provide estimates before the iteration begins. Even
if a tech lead provides all estimates before assigning the work items to individual developers,
the calculations would still be valid. The important point is to establish a ratio that project
managers can rely on for delivery dates.

22
User Interface
The user interface in Featherweight is very compressed. That is, there is a lot of
information on the few screens it has. This is by design. Much like an airplane cockpit provides
a lot of information to the pilot at a glance; Featherweight provides a lot of information to
developers without a lot of navigation control or clicks. A pilot references the instruments in
his/her plane for data but the true task is flying the plane. Similarly developers, engineers,
testers, support personnel have specific tasks they need to perform. They need easy-to-find,
supporting information from the change management system with minimal interaction.
The layout of the interface is intended to mirror the layout of popular Integrated
Development Environments like Eclipse and Sun’s Net Beans. The upper left contains a tree
view while the upper right panel contains the main content. This is the same as many popular
IDE as well as Microsoft’s Windows OS. The lower left contains search criteria and the lower
right has the search results.
The goal is to make the application easy to learn and integrate into a development
team. A user can save a custom query and only have to enter a couple of clicks to get all the
information needed for an entire day of work. There really isn’t much to learn in the way of site
navigation. Regardless of the perspective, all searches are performed in the same panel (lower
left). The same is true for entering and review form data (upper right) as well as tree
navigation(upper left). By designing the interface in this manner, teams can easily integrate
Featherweight.

23
SystemArchitecture:
Featherweight is a web application based on the client-server model. Requests from the
client or clients are submitted to a server which processes the client’s request. The request
typically requires a database action to be performed by the server (or perhaps another
dedicated database server). Once this action is complete, the server sends its response back to
the client where the results may be displayed. This response may be a collection of data or a
message indicating a database transaction was successful. The benefit of the client-model is
that it utilizes networks to enable resource sharing which is a critical requirement for this type
of application. 11
Featherweight is a three-tiered application. It implements the Model-View-Control
(MVC) pattern which separates the presentation layer (view) from the data layer (domain). This
pattern promotes low-coupling and high-cohesion which enable the two layers (model and
view) to be independent of one another. Changes in the User Interface have no effect on the
domain model and vice-versa. MVC is important because it enables the division of labor so
specialized skill sets can be applied to the appropriate tasks. It also makes code changes easier
because problems associated with refactoring don’t typically ripple through the entire
application.
Model Layer
The Model layer contains the domain model and the persistence layer for the
application. The domain model is the object oriented conceptual model of the various system

24
entities and their relationships. See Appendix B. It represents real-world objects that are of
importance to the system.
The persistence layer is collection of interfaces and classes that enable object
persistence and retrieval. A creational design pattern (Factory pattern) is used so the exact class
of the object to be saved, updated or loaded can be handled by subclasses and/or classes
implementing data access interfaces at runtime. The primary interface in the application is the
DAOInterface which defines all data access functions. Implementations of these methods are
provided by various classes implementing this interface.
Featherweight utilizes an object/relational mapping tool which provides a linkage
between the domain objects and database tables. The application uses Hibernate, an open
source object/relational persistence and query service implementing this object/relational
model.12 Domain object members are mapped to tables in the database by annotations entered
in the source code of java classes. Column name, data type, join columns, among others are
specified on “getter methods” to create a mapping of domain objects to database entities.
Tables are mapped to classes as well. See figure 3.6.

25
Figure 3.6
These annotations provide the mapping tool with all information necessary to generate
database tables enabling data persistence and retrieval. An object/relational mapping tool is
especially convenient when refactoring the domain model. It is also particularly useful during
early project phases when the domain model is initially being developed and changes are
frequent.
Hibernate also provides a suitable API that make CRUD (create, update, delete) work
easy. In fact, Featherweight has five persistence methods which serve approximately 80% of
data access needs. See figure 3.7.

26
Figure 3.7
When classes implementing the DAOInterface are instantiated, they require a class
name in the constructor. This class name is passed as an argument along with the load/store
parameters to the data access methods provided by hibernate. Hibernate automatically
generates the necessary sql to retrieve or store data for the class name passed in the method
argument.
Obviously, more complex queries require additional code, but a great deal of time is
saved by simply calling these methods for typical data needs. Coding sql methods is not only
tedious, but also where many errors are injected because IDEs don’t compile String literals
containing sql. Also, when refactoring without an object/relational tool, problems can “ripple”
through the application. These ripples are often difficult to anticipate. Object/relational
mapping tools can prevent many of these problems.
While there are several advantages with this tool, there are also significant
disadvantages in this mapping approach. Abstracting away some of the tedious details of sql
coding is convenient, but it also presents potential risk. Troubleshooting lower level details is
difficult with these tools. The learning curve can be fairly steep. Also, there is a performance
penalty when using this additional layer. As the domain model becomes more stable, it would
be wise to use prepared sql statements for CRUDs in order to maximize performance.

27
Featherweight uses a PostgreSQL (Postgres) Database Management System (DBMS).
Postgres is a popular open source database supporting standard relational database
constructs.13 It was chosen because it has a good track record, it is popular within the industry
and it is free (for both development and distribution). A different database could be used with
minimal configuration changes.
View (User Interface)
Featherweight is a web application so its user interface is delivered by a web browser.
Java server pages (jsp) are used to create the web pages with dynamic content. Independent
tag libraries are used in the jsp’s for simplified coding. There are html tags, logic tags as well as
template tags. These all make the user interface a much cleaner coding environment and they
hide some coding details developers may not want to share. See figure 3.8
Figure 3.8
The user interface is divided into panels or “tiles” which enables the developer to group
like user interface code into components. This encapsulation allows the interface developer to

28
focus only on 1 panel at a time, rather than having to manage all details at once in one source
code file.
Figure 3.9
If a result is displayed on panel 2, for example, while all other panels remain static, the
developer can simply work on the .jsp that will be presented in panel 2. Variables, imports,
javascript libraries, layouts, etc. area all managed on the parent/layout tile.
The application uses standard cascading style sheets to format and style the interface.
This further decouples the data with the presentation. Major and minor changes can be
implemented with relative ease. It is also improves page rendering (speed) because browsers
typically cache stylesheets. Once the initial page is loaded, subsequent page loads referencing
the same stylesheet don’t have to repeatedly read style data which means less html to parse
and thus faster page loads.

29
There are several javascript libraries in Featherweight including code to sort query
results as well as a calendar function which helps users pick dates. These are both open source
libraries available for free download.14,15 There are also tooltips as well as various submit
functions which affect the flow of the application.
One of the more important components in the user interface is the use of asynchronous
javascript (AJAX). When users select an attribute to search on, the application dynamically
retrieves a.) valid search operators and b.) valid attribute values. If a user wants to see all work
items that have an estimate < 10, the user would first select the estimate attribute. Then the
system would find the valid operators for estimate. Since the estimate is a numerical value, the
system would present the valid operators ( = , != <, <=, >, >=). The attribute value would be
blank allowing the user to enter 10. If a user wanted to see all work items “Joe” was
responsible for, he/she would first select the attribute “User Responsible.” The system would
retrieve the valid search operators, (= and !=) then it would populate a drop-down list of user
names in the attribute value column. Only the two fields (operator and attribute value) change
when this occurs. The rest of the user interface is static. Ease of integration is a key point of
Featherweight so usability is important.
Loading saved queries also utilizes AJAX. When a user selects a saved query, the system
retrieves the search parameters previously saved and populates the attribute, operator and
attribute value fields. Again, only the affected fields are refreshed. The rest of the user interface
(search results, tree view and main content area) remains as-is.

30
Control Layer
The control layer functions as the “traffic cop” of the system. Incoming requests from
the view are parsed and analyzed by a controller servlet then expedited to the appropriate
action. Actions are typically responsible for making calls to the domain or business logic and
preparing the results to be displayed by the user interface. Based on the results (a successful
transaction, error, invalid data, etc.) the control decides which view is appropriate to display.
See figure 3.10.
All requests to the application must go through the controller servlet to be routed to the
appropriate action. Likewise, all responses go through the control to identify the appropriate
view based on the outcome of the response. This secures the application from inappropriate
access and it decouples the view from the model. The view doesn’t even know which action
class will be invoked once the Controller Servlet is invoke. It only knows the action alias, so if a
different action is needed, a simple change to a configuration file is the only change required.
Neither the user interface not the domain model is aware of the change.

31
Figure 3.10
The control layer also supports internationalization of the application. A configuration
file stores text and labels used in the user interface. Rather than hard coding labels in the UI,
labels “point to” files which contain the appropriate display text for the selected language.
English is the only language currently supported.
Interceptors are classes created for data validation, preventing double submits, data
conversion etc.16 These classes are called before the controller servlet forwards to the
appropriate action. If a required field is missing, or invalid data was entered in a field, the
interceptor will catch this error and forward to the appropriate view with an error message or
prompt. This approach simply saves the application from wasting memory and processor
resources on database connections, etc. Featherweight utilizes interceptors when there is a
potential to head-off errors before delegating to the various deeper levels of the application.

32
ApplicationDependencies:
The Table below lists specific technical details about the application and the various
software packages and libraries it utilizes.
Table 3.2
Package/Library Name Comments
Web Application Server Apache Tomcat 5.5.27
Database PostgreSQL 8.3
Object/Relational Mapping
Tool
Hibernate 3.2
Model View Control
Framework
Apache Struts 2.1
Primary programming
language
Java JDK 1.6
User Interface tag libraries Jakarta Struts Tags, Apache
Tiles 2.0
Logging package Log4j v1.2.15
Testing framework JUnit 4.4 Automated repeatable testing
DOM Formatting exchange JSON Data interchange for format
used with AJAX. Used to
manipulate the DOM.

33
Chapter 4:
There is a need for a flexible and easily integrated tool which can help teams implement
elements of software process. To facilitate process integration, the tool should support a.)
requirements management, b.) communication and collaboration, c.) establishing roles and
responsibilities, and d.) project estimation and management. Featherweight is a candidate to
meet this need in that it is a flexible change management system that supports software
organizations incorporating agile processes. The following section describes how
Featherweight meets these needs.
Featherweight provides support for requirements management. In fact, it is based in
part on popular bug tracking applications designed to track software development issues.
Featherweight enables teams to capture, prioritize and modify requirements in many ways. The
application has many text fields in which users provide descriptions and explanations for work
items. There are several attributes such as type, status, estimates, priority, target version
among others that further define and classify the requirement. It also provides the means to
include designs, test cases and attachments which enable engineers to better define team
expectations and to more comprehensively control the development process.
Featherweight also tracks changes in individual requirements. Each change or addition
to a requirement (or work item) is logged in an “activity” sub-systemwhich can be used to
review requirement history, note team interactions, and provide textual comments and
updates on the status of the requirement as it progresses through the team’s workflow.

34
Featherweight supports managing requirements. Users can quickly search for and
review a list of requirements targeted for a particular software release or a list of unassigned
issues “in the queue.” Assigning a requirement to be implemented with a particular version is
as simple as changing the target release value and assigning responsibility to a team member.
All the information necessary to implement the requirement (designs, test cases, problem
descriptions, etc.) are readily available in the system.
The application also supports communication and collaboration. Featherweight is a web
application so system access can be granted to team members as well as to outside consultants,
clients and other stakeholders. By providing secure open access all interested parties can be a
part of the process. For most agile methodologies, stakeholder input is critical throughout the
life of the project.
Team collaboration is supported because Featherweight provides the means to store all
requirement related material in one location. Test cases, CRC cards and various other resources
can be added to a requirement which means team members have a single access point for
development assets. Featherweight acts as a centralized information kiosk where process
artifacts are stored and all communication takes place. This eliminates the problem of losing or
misinterpreting requirements. If the work item is entered into Featherweight, it will be
accounted for. It may need modification or clarification, but it will be tracked. Requirements
mentioned in emails, hallway conversations, meetings etc. are not (and should not be)
honored.

35
Responsibility is supported because a team member is always responsible for an active
work item. The current “user responsible” is a required field in the application, so even if a
work item is a trivial, low priority bug that is likely to never be implemented, someone is
responsible for it. The bug can be closed or fixed, but until then someone on the team is
responsible for it. This is simple concept but one that is difficult to practice without a dynamic
change management system.
Once a work item is in progress, it will advance through various stages or statuses in the
team’s work flow. Different team members assume responsibility for the work item while it’s
being resolved. One user may be responsible for developing test cases, another for creating the
design, while yet another is responsible for implementation. Or perhaps one individual is
responsible for all of these activities. The work flow in the systemcan be matched to the team’s
actual work flow and it can be adjusted when necessary.
Users can search the system on virtually any attribute, but one of the most useful query
filters is “current user responsible.” Regardless of the task, priority or status, this provides a
strong sense of responsibility throughout the system. Responsibility and the work item’s status
provide engineers a good perspective on their process. If there are quality issues with the
product, this is a signal for team leaders to review the data captured in the work items to
identify the issue. The problem may be simple to correct. However, there may be no evidence
of a problem in the system which means there is opportunity for improvement in the team’s
process. If team members are using the tool as they are supposed to, but the process is not
leading to quality product the process likely needs to change.

36
Maybe work item descriptions are being entered, but they are not detailed enough for
the designers and developers. Perhaps completed code is not adequately satisfying the
requirement. Is this a training issue, or should another status (like “Requirement Review”) be
added to the work flow to ensure quality and completeness of requirements? This might ensure
the work item descriptions are detailed enough to provide accurate designs and complete and
correct implementations. Perhaps too many bugs are occurring in production code. Is a peer
review appropriate? Are the test cases being accurately defined and performed? By providing
strong support for responsibility, Featherweight not only enforces this principle, but it also
helps identify where teams can improve their processes.
Finally, project estimation and management is supported by Featherweight. Project
managers can view statistics on user’s effort estimates versus their actual effort. The system
will calculate the ratio between the estimates and actual over the current release, the last three
releases, and last six releases by individual users as well as the entire team. This will give
project managers more accurate estimates which mean delivery dates for clients are more
accurate.
The ratio between estimates and actual also give the developers a good view of their
work activities. The intent of the ratio is not for developers to strive for a 1/1 relationship, but
to simply establish a more accurate estimate. Teams should be wary of any type of
measurement or incentive based on this ratio. By providing views of progress against deadlines,
the team is in better position to shift responsibilities or seek help when necessary to meet a
milestone.

37
Ultimately, the true measure of a software organization is producing successful
products. Regardless of the model process, tools, standards and methodologies used, the team
must produce on time, high quality software. Without the end result being a success, the rest
simply doesn’t matter. See Table 1.1 for the factors that make a project successful?
Featherweight provides some degree of support for virtually all success factors defined
above. Obviously a tool cannot function as a true process, but it can help facilitate that process.
From the Executive Perspective, Featherweight’s project management capabilities support not
overselling and achieving milestones because they help keep the project on track and on time
by proving more accurate estimates. They also can help project the amount of effort available
for future needs based on estimates and adjusted estimates. Customer enthusiasm is
supported by all factors of the application. The project management features in the application
can also play a role in controlling costs.
From the User Perspective, the requirements management capabilities support the majority
of success factors. Understanding needs and accommodating changes are directly supported by
the change management and communication aspects of the application. Timely product is
supported by project management capabilities. A combination of the other factors also
indirectly supports this perspective.
Virtually all of the Management’s Perspective is supported to some degree by the project
management components of the system. Available resources, reasonable schedules and
management support are fully supported by the project management aspects. Determining

38
user needs, tracking progress and controlling change utilize the requirements management
characteristics of Featherweight.
The Team’s Perspective is supported by the requirements management, responsibility and
communication and collaboration aspects of the application. Engineers can associate designs,
and test cases with work items, which better define expectations and effectively communicate
the development policies of the team. Users participate in both planning and execution.
Project managers have the means to get an accurate status on the progress of a version or work
item which translates to more humane treatment due to better overall team visibility. Graphic
4.3 shows a matrix mapping success factors against the major features of Featherweight.

40
Chapter 5
Summary:
Featherweight is a flexible and easy-to-integrate change management tool that supports
software teams integrating agile processes into their organization. Teams with little or no
engineering discipline can quickly begin integrating process principles. More experienced
teams already practicing agile development can also benefit from many of the application’s
features. It provides support for requirements management, communication and collaboration,
roles and responsibilities and project management.
Observations:
Tools
There is a dizzying array of software development tools, and many of them are available
for free download. Tools essentially abstract away detail to enable programmers to focus more
on implementing designs and less time dealing with configuration, boilerplate code and other
mundane tasks. Tools are an indispensible part of software development however; tools can
sometimes require more effort than they save.
In approaching this project, I decided to use some of the more popular cutting edge
tools. I used Hibernate which is a persistence framework. It enables programmers to map Java
classes directly to database tables. This allows programmers to code in a more object oriented

41
idiom maintaining consistency through inheritance, polymorphism, collections, etc. The object
oriented paradigm can theoretically be preserved in the persistence code. This tool proved very
helpful when designing the model layer, but I ran into significant problems during
implementation.
Complex associations are not well supported in Hibernate. I had several problems on
data reads and writes when complex objects were involved. In searching for solutions, I often
found suggestions that were “workarounds.” I also found that there were bugs in the tool
which prevented me from doing what I needed to do following the relational mapping
paradigm. The learning curve was also steep. In abstracting away detail, Hibernate made
coding the persistence layer even more difficult than it should have been. I spent more time
and effort on learning and researching the tool than I would have by simply using SQL code.
Had I been a Hibernate “guru” I may not have run into these problems. However this
begs the question: Should programmers expend their effort learning specific tools? Or should
they focus on core governing principles and standards? Technology evolves so quickly it is hard
to justify spending a lot of time becoming an expert on a tool that may not even be supported
in two or three years. What happens when the next cutting edge relational mapping tool is
released?
There were significant consequences in using this tool. My estimates for tasks involving
Hibernate were grossly underestimated. In implementing some of the workarounds I had to use
a non-Hibernate methods. My persistence layer has both Hibernate and standard SQL/JDBC
code. This is inconsistent and would be difficult for a team to maintain. I faced difficult

42
questions several times during the implementation. Should I continue with one more work-
around? Or should I abandon this approach and re-implement the entire persistence layer.
Schedules must be considered in these decisions so the answer is not always black and white.
I ran into similar (almost identical) issues using dojo, a toolkit advertised to make
implementing AJAX technology easier. There were bugs and workarounds. The code was not
always backwards compatible between versions. In the end, I abandoned dojo.
When evaluating software development tools, teams should give careful consideration.
When a tool is adopted, the team creates a dependency on that tool. These are black box
components; the internal details are beyond the developer’s control. Since tools are essentially
abstractions, teams need to be prepared to become experts in the tools they use. This expertise
must serve as a substitute for the ability to analyze and troubleshoot at a less abstract/more
detailed level.
The importance of communication in agile process
In researching agile model processes, I realized that many of the fundamental principles are
based on communication. The ability to communicate and collaborate with stakeholders is the
foundation for agile methodology. The following is a list of five of the twelve principles in the
Agile Manifesto focusing on communication.17
 Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage. (communication)

43
 Business people and developers must work together daily throughout the project.
(communication/collaboration)
 The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.(communication)
 The best architectures, requirements, and designs emerge from self-organizing teams.
(communication/collaboration)
 At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly. (communication)
Two of the four core principles in XP are based on collaboration: feedback and
communication.18 Primary XP practices also include communication and collaboration driven
objectives: Pair programming, collective code ownership and working with customers during
the project.19 SCRUM practitioners begin each day with a fifteen minute standup meeting to
discuss the previous days achievements and the coming day’s tasks.20 They also perform group
post mortem analyses for continuous process improvement.
It is surprising that so much emphasis is placed on communication in model processes, yet
training programs and university curricula focus primarily on technical facets of software
engineering. A greater emphasis on communication and collaboration is needed to match the
objectives found in agile model processes.
Lean Development
Lean Development is an agile process methodology that focuses primarily on eliminating
waste. Its origins can be traced to the Toyota Motor Company and its startup efforts following
World War II. Toyota did not have the resources the American manufacturers in Detroit had, so

44
they had to find a way to produce cars without massive assembly lines utilizing specialized,
single-use automation machinery. Their solution was to “empower their employees.”21
Today, employee empowerment is an overused slogan, but Toyota originated this
concept and put it into practice. Instead of relying exclusively on engineers to design every
facet of the production line, they relied in part on the workers who were actually building the
cars. Workers were encouraged to provide feedback regarding the cars design and production.
They were empowered. This resulted in much greater efficiencies. Many industries have
successfully copied Toyota’s approach.
There are interesting parallels between Detroit’s original assembly line and some plan-
driven processes compared to Toyota’s manufacturing approach and Lean Development. The
American assembly line relied on “all powerful” engineers who controlled virtually every aspect
of car production. The workers on the assembly line were unskilled. Engineers designed their
tasks, and then timed them with a stopwatch for productivity measurements. Responsibilities
on the worker were minimized. Lean practitioners would argue that some plan driven
processes use a similar approach with software designs so specific and exact that the code “falls
out.” They would suggest that in this scenario, programmers are utilized as unskilled labor.
They would suggest that this is waste.
Lean development on the other hand attempts to take advantage of programmer’s skills
and knowledge. Instead of centralizing control with the “all powerful” engineer, lean
practitioners empower their developers to participate in design efforts and make suggestions
on potential improvements. Lean organizations are flatter as opposed to the more hierarchical

45
structure. Lean software development teams eliminate waste by capitalizing on the highly
skilled aspect of their workers.
There is no “The Process.” The domain is a driving factor in the model process used by
an organization. Clearly Lean Development would probably not be appropriate for large scale,
high risk projects, but many commercial applications could greatly benefit from this approach.
Software development requires highly skilled workers. It makes sense in certain situations to
“push down” responsibility to these programmers to become a more efficient team.
Featherweight
Change management systems provide a starting point for teams to integrate agile
processes into their organizations. Teams that utilize change management systems such as
Featherweight can incorporate agile principles without the expense, training and time often
required to implement a model process. Requirements management, communication and
collaboration, roles and responsibilities and project management are all important process
principles that are at least partially supported by these systems.
Certainly, a software application cannot serve as an actual process. However, it can
facilitate process adoption by enabling managers and engineers to define expectations for
development procedures, work flows and routines. It can also provide some means of
measuring how those expectations are being met. These measurements are typically not as
robust as more plan driven processes, but they are appropriate in situations where an agile
development process is suitable. These aspects of change management software enable teams

46
with little or no process discipline to adopt lightweight processes and in turn, increase their
ability to produce high quality, on time software.
Future Directions:
Featherweight could be expanded in many directions to improve support for process
integration. This application and a version control system could be integrated to provide even
greater requirements management capability. By incorporating features from a version control
system, users could gain even more insight and more convenience in seeing the progression of
code changes. Instead of just seeing the change in requirements, design and testing, users
could also see changes in the implementation. Porting Featherweight into an IDE such as Eclipse
or Net Beans would facilitate this as well as being a nice enhancement in and of itself.
Another area for extension is in project management and estimations. Currently the
adjusted estimates are based on simple calculations (basically the ratio of estimated/actual).
More complex algorithms could be added to provide more accurate estimations such as those
provided in PSP and other model processes. This would provide managers a much better
perspective of project estimations, etc. Also additional perspectives would help project
management efforts. Enabling custom grouping of work items would be beneficial.
There are several enhancements and features that were either identified during the
creation of this project or before implementation began. Some were excluded for this iteration
of development due to time constraints. Others were simply discovered as the design and

47
implementation unfolded. Please see Appendix D for a detailed list of planned features for
upcoming versions of Featherweight.

48
Bibliography
[1] JohnD. Vu.“Software ProcessImprovement Journey:FromLevel 1to Level 5.” 7th
SEPG Conference,
San Jose,March 1997.
[2] Wang and King.2000. Software EngineeringProcess.CRCPress.P.562.
[3] Paul Grunbacher,A Software AssessmentProcessforSmall SoftwareEnterprises, EUROMICRO97.
'NewFrontiersof InformationTechnology'.,Proceedingsofthe 23rd EUROMICRO Conference,
September1– 4, 1997, 123
[4] Huff,C.C., "Elementsof aRealisticCASETool AdoptionBudget,"Comm.ACM,35, 4 (1992), 45-54.
[5] Huff p. 54
[6] IBM, Rational Software AnalyzerEnterpriseEdition.Price quote fromGabriel Wong,Business
DevelopmentRepresentative|Software Response Leadmanagement.06/30/2008
[6] Grunbacher,123
[7] RicardoBalduino,IntroductiontoOpenUP(OpenUnifiedProcess),www.eclipse.org
http://www.eclipse.org/epf/general/OpenUP.pdf ,August2007
[8] Extreme ProgrammingPocketGuide,Copyright ©2003,O’ReillyMedia,Inc.ISBN-10;0-596-00485-0,
pg. 29-32, 1005 GravensteinHighwayNorth,Sebastopol,CA 95472
[9]JamesA Rozum,ComceptsonMeasuringthe Benefitsof Software ProcessImprovements,Software
EngineeringInstitute,June 1993
[10] Dr. DavidUmphress,Software ProcessIntroduction.SoftwareProcess.AuburnUniversity, August
16, 2008
[11] Gersting,JudithL.,Schneider,Michael,G. InvitationtoComputerScience:3rd
edition. Boston,MA:
ThompsonCourse Technology,2004.pg.321
[12] https://www.hibernate.org/.RedHatMiddleware,LLC.Last accessed07/15/2009
[13] http://www.postgresql.org/.PostgreSQLGlobal DevelopmentGroup.Lastaccessed07/15/2009
[14] http://yoast.com/articles/sortable-table/ .Joostde Valk.Lastaccessed07/15/2009

49
[15] https://engineering.purdue.edu/ECN/Support/KB/Docs/JavascriptCalendar.Lastupdated
2007/10/31. Last accessed07/15/2009
[16] http://struts.apache.org/2.x/docs/interceptors.html.Apache SoftwareFoundation.Lastaccessed
07/15/2009
[17] http://agilemanifesto.org Agile Manifesto.Lastaccessed10/04/2009
[18] Extreme ProgrammingPocketGuide,7-9
[19] Extreme ProgrammingPocketGuide,21-34,36
[20] http://scrummethodology.com ScrumMethodology.Lastaccessed10/04/2009
[21] Poppendeick,Mary,Poppendeick,Tom.LeanSoftware Development:A ToolkitCopyright©2003,
Addison-Wesly.ISBN-0-321-15078-3, Upper Saddle River,NJ07458

50
Appendix A: Use Cases & Glossary
Note: Not all use cases are fully implemented in Version 0.2 (see version row for each use case
for details on when implemented). Most objects cited in the use cases exist in the domain model,
but there may not be user interface support. For example, Use Case #1 User Login: There are
user and role objects and tables in the database, but currently there is no UI or business logic to
actually log in to the system. The unimplemented use cases are shown here to provide
additional information on the direction and the future efforts on the project.
Also, see the glossary following the use cases for definitions, explanations and screen shots, etc.
1. UserLogin
Goal User logsinto the system
Summary The systemvalidatesthe user’susername andpassword
Actors All users
Preconditions
Basic Course of Events 1. User selectsoption/linktologintosystem
2. Systempresentsloginform
3. User entersusername andpasswordtothe loginform andsubmits
4. Systemvalidatessecuritycredentialsandforwardsusertohis home
page
Alternative Paths 3a. User entersinvalidsecuritycredentials.
3a.1 Systemre-displaysloginpage anddisplayserrormessage indicating
the username andpasswordcombinationare invalid.
Post Condition The user isloggedinthe system
Version Will implement in futureiterations

51
2 UserEnters Work Item
Goal User entersa workitemintothe system
Summary User entersa work itemandits detailsintothe system
Actors User withauthoritytoentera workitem
Preconditions
Basic Course of Events 1. User selectsthe option/linktoenterawork itemintothe system.
2. Systempresents workitemform
3. User completesandsubmitsthe form alongwithcommentsaboutthe
activity.
4. The systemvalidatesthe form, savesthe dataanddisplaysthe form
withthe workitemdata.
Alternative Paths 3a. Requiredfieldsnotcomplete.
3a.1 The system re-displaysthe form(withpreviouslyenteredcorrect
data) and displaysanerror indicatingwhichfield(s) is/are invalid.
3b. Invaliddataentered(date format,stringinplace if int,etc)
3b.1 The systemre-displaysthe form(withpreviouslyenteredcorrect
data) and displaysanerror indicatingwhichfield(s) containinvaliddata
values.
Post Condition The user hasenteredthe workitemintothe system.
Version 0.2
3 UserWork Item Search
Goal User retrievesalistof workitems
Summary The systemdisplayalistof work itemsmatchingthe user’ssearchcriteria
Actors Users withSearchauthority
Preconditions
Basic Course of Events 1. User selectsthe option/linktosearch
2. The systemdisplaysthe searchform
3. The user enterssearchcriteria andsubmitssearch
4. The systemqueriesthe database basedonenteredcriteriaand
displaysthe listof workitemsonthe searchresultscreen.
Alternative Paths
Post Condition The systemdisplaysthe searchresults
Version 0.2
Notes
4 UserAdvanced Issue Search OBE
Goal User performsadvancedsearch
Summary User queriesthe database withadvancedsearchfunctions
Actors User withadvancedsearchauthority
Preconditions

52
Basic Course of Events 1. User selects advancedsearchoption
2. Systemdisplays advancedsearchoptionform
3. The user entersthe advancedsearchcriteriaandsubmits
4. The systemqueriesthe database basedonthe user’scriteriaand
displaysthe listof issuesonthe searchresultscreen.
Alternative Paths
Post Condition The systemdisplaysthe advancedsearchresults
Notes OBE – the regularquerytool satisfies thisrequirement
5 UserSaves Search
Goal User savesa search
Summary The users savessearch criteriaforquicksearches
Actors Users withsearchauthority
Preconditions User has performedasearchand the resultsare displayed
Basic Course of Events 1. User entersa name forthe savedsearchand submits.
2. The systemsavesthe searchand displaysthe searchresults.
Alternative Paths 1a. The userentersa non-uniquename.
1a.1 The systemredisplaysthe searchresultsscreenanddisplaysanerror
message indicatingthatthe searchname is notunique.
Post Condition User has savedthe search
Version 0.2
6 UserRuns SavedSearch
Goal User performsasavedsearch
Summary The usersselectsa savedsearchto run andruns it
Preconditions User has saveda search
Basic Course of Events 1. User selectsthe savedsearchtorun and submitsrequest.
2. The systemretrievesqueryparametersandpopulatestext
boxes/dropdownboxes
3. User selects“run”
4. Systemrunsqueryand retrieves results
Alternative Paths
Post Condition User has performedthe savedsearch
Version 0.2
Notes

53
7 Useroutputs search resultsto delimited file
Goal Outputsearchresultsindelimited(.csv,etc) format.
Summary User selectstooutput resultsindelimitedformat
Preconditions User has performedasearchand the resultsare displayed
Basic Course of Events 1. User selectstooutputresultsof searchina delimitedformatand
selectsthe delimiter
2. The systemoutputsthe searchresultsinthe delimitedformat,opening
on the usersscreen
Alternative Paths 2a The clientmachine maynotbe able to displaydelimited file
2a.1 TBD
Post Condition The search resultsare produced indelimitedformat.
Notes SystemPreferences determine the delimiter:The defaultdelimiterdisplays
inthe box,butthe usercan change it.
Version Will not be implemented forthis iteration
8 UserViewsWork Item
Goal User viewsaworkitemand itsdetails
Summary User viewsaworkitemand itsdetails
Actors User withauthoritytoview a workitem
Preconditions The work itemhasbeencreatedinthe system, a search has been
performed andsearchresultsare displayed.
Basic Course of Events 1. The user selectstoview aworkitemfromthe searchresults.
2. The systemretrievesthe detailsof the workitemalongwithanypast
history (otherupdates) anddisplaysit.
3. The user viewsthe workitemanddetails
Alternative Paths
Post Condition The work itemhasbeenviewed.
Version 0.2

54
9 UserUpdates WorkItem
Goal User updatesa workitem
Summary User updates/adds historytoaworkitem
Actors User withauthoritytoupdate a workitem
Preconditions The work itemhasbeencreatedinthe system;a searchhas been
performed todisplaythe workitem.
Basic Course of Events 1. The user selectstoupdate a workitemfromthe search resultsscreen.
2. The systemretrievesthe workitemanditsdetailsalongwithall past
history(otherupdates) anddisplaysonthe screen.
3. The user makeschanges(status,responsible party,etc) andcan add
commentsaboutthe update (onprogress,actions,etc).The user
submitsthe update
4. The systemsavesthe changesinthe work itemandrecordsthe history
of the change.The systemsendsanemail aboutthe update to those
whoare configuredtoreceive emailson updates. The systemdisplays
the editedworkitem.
Alternative Paths 3a. Changesonthe form are invalid.
3a.1 The systemre-displaysthe formanddisplaysanerrorindicating
whichfield(s) isinvalid.
3b. Requiredfieldsnotcomplete
3b.1 The systemre-displaysthe formanddisplaysanerrorindicating
requiredfieldsare notcomplete.
Post Condition The work itemhasbeenupdated.
Version 0.2 Partial – Email optionandgranular persistenceof actual fieldchanges
will be implementedin laterversions.
10 UserDesignsSolution
Goal User designssolutiontoissue
Summary User completesaCRCcards(s) for the designtothe solutionof the issue
Actors User withdesignauthority
Preconditions Issue hasbeencreated,Issue isbeing viewed
Basic Course of Events 1. User selectstocreate a designforan workitem
2. The systemdisplaysadesignform(CRCCard)
3. The user completesthe formandsubmits.
4. The systemsavesthe informationandentersthe designcreation
historyintoissue details.The systemredisplaysthe Issue
Alternative Paths 3a. Requiredfieldsnotcomplete
3a.1 Systempromptsformissingfields
Post Condition The designforthe issue hasbeencreated
Version 0.2

55
Notes For future iterations:
whenthe systemdisplays the form, itreadsthe classes,methods,etcfrom
the actual code and pre-populatesthe form. Youmaybe addinga method
to an existingclass.
Whenyoucreate new designs,the methodsare actuallystubbedoutinthe
actual code alongwiththe issue#, issue description,etcinthe comments.
Also– there can be 0 ..* designs(CRCcards) foran issue.
For this,the systemwouldneedtobe integratedwitha versioncontrol
system.Alsoitshouldbe developedasaplug-infor Eclipse,NetBeans,etc.
11 UserViewsDesign
Goal User viewsthe design
Summary User viewsthe designsolutionforanissue
Actors User withdesignview authority
Preconditions Issue hasbeencreated,Issue isbeingviewed,Designhasbeencreated
Basic Course of Events 1. User selectstoview the design
2. The systemretrievesthe designsolutionsforthe issue anddisplaysfor
the userto view.
Alternative Paths
Post Condition User has viewedthe design
Version 0.2
12 UserEdits Design
Goal User changesthe design
Summary User changesthe design
Actors User withdesigneditauthority
Preconditions Issue hasbeencreated,Issue detail isbeingviewed.
BasicCourseofEvents 1. User selectstoeditthe design
2. The systemretrievesthe designsolutionsforthe issue anddisplaysthe
valuesinthe designform(CRCcard).
3. The user editsthe designandsubmits
4. The systemsavesthe designchanges,recordsthe change and
redisplaysthe Issue
AlternativePaths 3a. Requiredfieldsnotcomplete
Post Condition User has viewedthe design
Version 0.2
13 UserCreatesa Test Casefora WorkItem
Goal User createsa Test Case foran work item

56
Summary User createsa Test Case foran work item
Actors User withCreate TestCase authority
Preconditions Issue hasbeencreated,Issue isbeingviewed
BasicCourseofEvents 1. User selectstocreate a Test Case for the issue.
2. The systemdisplaysaTestCase form. The usercompletesthe Form
and submits.
3. The systemsavesthe Testcase, updates issue detailswiththe Test
Case creationand displaysthe Issue
Post Condition TestCase hasbeencreated
Version 0.2
14 UserCompletesa TestCasefora WorkItem
Goal User testsa workitem
Summary User testsa workitem
Actors User withupdate Testauthority
Preconditions Issue isinCode/TaskComplete systemstatus,Userisviewingthe work
item
BasicCourseofEvents 1. User selectstoopenthe TestCase for the work item
2. The systemdisplaysthe TestCase formforthe workitem.
3. The user performsthe testandentersthe actual result,the time
testedandthe resultof the test as well ascomments.
4. The test resultsare savedandthe work itemstatusisupdated.
Post Condition The test case has beenperformed
Version 0.2
15 UserViewsTeamStats/Progressby Status
Goal User viewsthe issuesthe teamisresponsible forbystatus
Summary User viewsthe issuesthe teamisresponsible forbystatus
Actors User withRelease ProgressbyStatus authorities
Preconditions
BasicCourseofEvents 1. User selectstoview ReleaseProgressbyCustomStatus
2. The systemdisplaysthe team’scurrentreleaseprogressalongwithan
optiontoselecta differentrelease.The viewshowsthe numberof
issuesgroupedbycustomstatus.
3. The user selects/clicksacustomstatusfromresultsdisplayed.
4. The systemretrievesthe issuesassociatedwiththatcustomstatusand
release anddisplaysthe issuesummaries.
AlternativePaths 1a. User selectstoview Release ProgressbyStaticSystemStatus
1a.1 The systemdisplaysthe team’scurrentreleaseprogressalongwithan
optiontoselecta differentrelease.The viewshowsthe numberof issues

57
groupedbystatic status.
1a.2 The user selects/clicksastaticstatusfromresultsdisplayed.
1a.3 The systemretrievesthe issuesassociatedwiththatstaticstatusand
release anddisplaysthe issuesummaries.
Post Condition User ViewsRelease Progressbycustomstatus
Version Not includedinthis iteration
16 UserviewsTeam Stats/ProgressbyVersion
Goal User viewsthe estimates,progressandcalculationsforateamby version
Summary User viewsthe estimates,progressandcalculationsforateamby version
Actors Users withauthoritytosee TeamVersionProgress.
Preconditions
BasicCourseofEvents 1. User selectsaVersionandselectsto view TeamVersionProgress
2. The systemmakesthe appropriate calculationsfortargetdate or
target hours and itmakesstats/progress(see notesand diagrams)
calculations.Itdisplaysthe results
3. The user view the TeamProgress
AlternativePaths
Post Condition User viewsstats/progress
Version 0.2
Notes Calculations:
 Estimatedcompletedhours/estimatedincomplete
 Actual complete hours/estimatedcomplete
 Actual compete /estimatedcomplete* (actual
complete/incomplete estimated)
 Will displaycalculationsforcurrentrelease,last3releasesandlast
6 releases.
 See Stats/Progressdiagrams

58
17 UserviewsIndividual Stats/Progress by Version
Goal User seesthe estimates,progressandcalculationsforauserby version
Summary User seesthe estimates, progressandcalculationsforauserby version
Actors Users withauthoritytosee Individual VersionProgress.
Preconditions Users withauthoritytosee Individual VersionProgress.
Basic Course of Events 1. User selectsaVersionthe Userand he selectsto view Individual
VersionProgress
2. The systemmakesthe appropriate calculationsfortargetdate or
target hours and itmakesversionprogress(see notesand diagrams)
calculations.Itdisplaysthe results
3. The user view the Individual’sProgress
Post Condition User viewsissues
Version Will be implementedinfuture versions.
Notes Calculations:
Estimatedcompletedhours/estimatedincomplete
Actual complete hours/ estimatedcomplete
Actual compete /estimatedcomplete* (actual complete/incomplete
estimated)
Will displaycalculationsforcurrentrelease,last3releasesandlast6
releases.
See Stats/Progressdiagrams
18 UserPreferences:Userchangespassword
Goal User changespassword
Summary User changespassword
Actors User
Preconditions
BasicCourseofEvents 1. User selectsoption/linktoresetpassword.
2. Systemdisplaysthe formtochange passwordincluding3 fields;1for
existingpasswordand2 for the new password(bothmustmatch)
3. User entersexistingpasswordand 2 identical new passwords
4. The systemvalidatesthe oldandnew passwordsandsaves.The useris
directedtothe preferences.
AlternativePaths 3a. The oldpasswordisincorrect.
3a.1 The systemreturnsto the change passwordscreenanddisplaysan
error indicatingthatthe oldpasswordisinvalid.
3b. The new passwordsdonot match.
3b.1 The systemreturnstothe change passwordscreenand displaysan
error indicatingthatthe passwordsdonotmatch.
Post Condition
Version Will notbe implementedfor thisiteration

59
19 UserPreferences:Usersets ‘home search’
Goal Seta user’sdefaultsearch
Summary The user selectsasavedsearchto be hishome search
Actors User withpreferencesauthorities
BasicCourseofEvents 1. User selectsoption/linktosethome search
2. The systemdisplays the listof savedsearchesforthe user.
3. The user selectshishome searchandsubmits
4. The systemsavesthe home searchand displayspreferencesscreen
AlternativePaths 2a. No savedsearch
2a.1 Systemdisplaysamessage indicatingthatthere are nosaved
searches. Usermustsave a searchbefore settinghome search.
Post Condition User has sethissavedsearch
Version Will notbe implementedinthis iteration
Notes Searcheswill have a‘sortorder’
20 UserPreferences:Userdeletesasavedsearch
Goal Delete asavedsearch
Summary User deletesasearchpreviouslysaved
Basic Course of Events 1. User selectstodelete asavedsearch
2. The systemdisplaysalistof the user’ssavedsearches
3. The user selectsthe searchtodelete andsubmits
4. The systemdeletesthe savedsearchanddisplaysthe listof user’s
savedsearchesalongwithamessage confirmingthe searchwas
deleted.
Alternative Paths
Post Condition Searchhas beendeleted
Version Will notbe implementedinthis version
Notes

60
21 UserPreferences:Issue formpreferences
Goal Make enteringanissue fasterbydefaultingseldom-changingfieldstoa
preferred/predetermined(yet still editable) value.
Summary User setsthe initial state of a fieldwhenenteringanissue be pre-
determiningitsvalue inpreferences
Preconditions
Basic Course of Events 1. User selectstodetermine issue enteringpreferences
2. The systemdisplaysthe issue preferencesform
3. The user selectswhichvaluestopre-selectwhenenteringanissue.
The user submits.
4. The systemsavesthe preferencesandreturnsthe userto the
preferencesscreen.
Alternative Paths
Post Condition User has selectedissue formpreferences
Version Will notbe implementedfor project
Notes The administratorcontrolswhichfieldscanbe viewedbyauser.Usersmay
not be able to view oroverride the preferencessetbythe administrator.
22 UserPreferences:Enterunavailable hours
Goal User entersvacation/timeoff intosystemtoaidinschedulingof releases,
etc.
Summary The user schedulestimeoff inthe system
Actors Users with preferencesauthorities
Preconditions
Basic Course of Events 1. User selectstoentertime off
2. Systemdisplaysunavailable hoursformwhichincludesadate and a
numberof hoursunavailable field
3. The user entersthe dayand hoursunavailable andsubmits.
4. Theysystemsavesthe unavailable hoursandforwardsthe usertothe
unavailable hoursform.
Alternative Paths 3a. The userentersmore hoursoff thanadministerallowsavailable.
3a.1 The systemdisplaysthe unavailablehoursformanda message
indicatingthattoomany hourshave beenentered.
3b. The userenterstime off fora day that has alreadybeenenteredby
administratorinthe Administratorschedule off day.
3b.1 The systemdisplaysanerrormessage indicatingthattime off forthe
teamhas alreadybeenscheduled.
Post Condition The user hasenteredunavailable hoursintothe system.

61
23 UserPreferences:Delete unavailable hours
Goal User deletesvacation/time off previouslyentered
Summary The deletespreviouslyscheduledtime off
Actors Users withpreferencesauthorities
Preconditions User has scheduledtimeoff forthe day
Basic Course of Events 1. User selectstodelete previouslyscheduledtimeoff.
2. Systemdisplaysalistof requestsoccurringinthe future.
3. The user deletesthe instance.
4. The systemdeletesthe instanceanddisplayslistof requestsoccurring
inthe future.
Alternative Paths
Post Condition The user deletedunavailablehours
Version Will notbe implementedfor project
24 UserPreferences:UserConfiguresemail preferences
Goal User configuresemail preferences
Summary User determinesbycustomstatuswhentoreceive emails.Whenactivity
occurs on a workiteminthat particularstatus an email will be sent.
Actors Users withpreferencesauthorities
Preconditions
Basic Course of Events 1. User selectsoptiontoconfigure emailpreferences
2. The systemdisplaysalistof customsystemstatusesthe userhas
access to.
3. The user selectswhichstatuseshe wouldliketoreceive emailsfor.
Andif he wantsto receive themforall issuesthatare inthat statusor
justthose that he has beeninvolvedwith.
4. The systemsavesthe requestanddisplaysthe list of statuses.
Alternative Paths
Post Condition The user sethisemail preferences.
Notes Will notbe implementedfor thisiteration

62
25 TL/PM assignswork items
Goal The team leaderorProjectManager assigns workitems tousers
(responsible for) andupdatestheirstatus
Summary The TL/PM managerassigns workitems tousersbasedon information
presentedaboutthe users/developers.
Actors TL/PM
Preconditions There are userswithauthoritytobe assigned workitems;
Basic Course of Events 1. TL/PMselectsa workitems toview
2. The systemdisplaysthe workitems anditshistory.
3. TL/PMchangesthe status.If there ismore than 1 available usertobe
‘responsible for’,the systemwilldisplayanoptionandthe userwill
selectthe userwhowill now be responsible.
4. The systemsavesthe change and updatesthe statusto ‘assigned’(the
firstcustomstatus byorder).Inthe future,thisissue will show upon
the user’s(assignee) searchesinthe assignedstate.
Alternative Paths
Post Condition The work items hasbeenassigned/reassigned
Version 0.2
Notes All userswill be able toassignbasedontheirrole accessand assignment.
Rolesnotimplementedinthisiteration.
26 TL/PM setstarget for a Version
Goal TL/PMsetsa target( by date/byhour /none) fora version
Summary TL/PMsetsa completiontargetof eitherdate,numberof hours(orno
target/openended)
Actors TL/PMor UserwithVersionauthorities
Preconditions
Basic Course of Events 1. TL/PMselectstoset a target(by date,hoursor none) fora version
2. The systemdisplaysthe Versionform.
3. The TL/PM enters(if notalreadyentered/created)aversionnumber,a
target date (completiongoal) andastart date forthe release.The
TL/PMmay alsoindicate thatthis versionisthe “current”versionin
the worksfor the Team.See VersionTargetdiagrams inglossary.
4. The systemsavesthe information.
Alternative Paths 3a. The TL/PMentersa target numberof hoursand a start date forthe
release.The TL/PMmay alsoindicate thatthisversionisthe “current”
versioninthe worksforthe team.
3a.1 The systemsavesthe information
3b. The TL/PMenters“none”forthe target and a start date for the
release.The TL/PMmay alsoindicate thatthisversionisthe “current”
versioninthe worksforthe team.
3b.1 The systemsavesthe information
3c. The TL/PM doesnotentera start date.

63
3c.1 The systempromptsthe TL/PMwithanerror message indicatingthat
the start date isrequired once atarget has beenselected.
3c.2 The TL/PMselectsastart date andsubmits.
3c.3 The systemsavesthe Versioninformation.
Post Condition Versiontargethasbeenselected
Notes Algorithmforcalculatingavailable hourswhenselectingtargetby date:
hours = 0;
date = start date
While (date <end date){
hours= hours+ date.getAvailableHours();
date = date + 1;
}
Ex. A team leadersetsthe release periodfrom08/01/08 – 08/31/08. His
teamhas 5 workerswhoworkMonday – Fridaywitha “productive”6
hrs/day (setby admininsystem preferences) inthe monthof August(21
daysX 6 hours X 5 workers= 630 hours). The teamhas 1 day off (setin
admininschedule unavailablehours),Memorial Day(8hours X 5 workers
X 1 day= 40 hours). 2 of the workershave scheduled4hoursoff each for
doctorsappointments(userssetunavailable hours) ( 4 hours X2 workers
= 8 hours).
630 – 40 – 8 = 582 estimatedhoursavailable.
Thisnumberisusedto helpthe TL/PMplanand schedule hisreleases.
---
Algorithmforcalculatingtargetdate whenselectingtargetbyhours:
target date = start date - 1;
hours= 0;
while ( hours< numberof estimatedhoursforversion){
target date = start date + 1 day;
hours= hours+ targetdate.getHoursAvailable();
}
---
If none selected,notargetdate or hoursare created.
Will not be implemented forthis iteration.The projection calculationswill
be displayed in a search view,butsetting targetdates,etc. will not.
27 TeamLeader/ProjectManager(TL/PM)views“teamoverview”
screenOBE
Goal TL/PMreviewsan overview of the projectsandteam

64
Summary TL/PMreviewsanoverview of the projectsandteam
Actors TL/PM
Preconditions
BasicCourseofEvents 1. TL/PMselectsthe option/linktoview “teamoverview”.
2. The systemdisplays the teamoverview screen.
3. TL/PMview the screen
AlternativePaths
Post Condition TL/PMhas reviewedproject/developerstatus
Version
Notes OBE – the regularquerytool and otherviewssubsume thisrequirement.

65
28 TeamLeader/ProjectManager (TL/PM)views“developer
overview”screenOBE
Goal TL/PMreviewsanoverview of adeveloper’sprogress
Summary TL/PMreviewsanoverview of developer’sprogress
Actors TL/PM
Preconditions
BasicCourseofEvents 1. TL/PMselectsthe option/linktoview “developeroverview”.
2. The systemdisplaysthe developeroverview screen.
3. TL/PMselectsa specificdevelopertoreview.
4. The systemdisplaysthe developeroverview screen.
AlternativePaths
Post Condition TL/PMhas reviewedproject/developerstatus
Version OBE - thisissubsumedbyUse Case 17
Notes
29 AdminCreatesCustomStatus
Goal Create admindefinedcustomstatuses.The abilityforadministratorsto
create custom issue statuseshelpsthe systemmore closelymatchthe
organizationsworkflow.
Summary Administratorcreatesacustomstatus
Actors User withAdministratorauthorities
Preconditions
BasicCourseofEvents 1. User selectsoption/linktocreate a customstatus
2. The systemdisplaysthe custom issue statusform.
3. The user completesthe formbyenteringthe statusname,the orderin
whichitoccurs in the workflow,auserresponsible ( if there isjust1
userinitiallyresponsible forthisstate) andthe correspondingstatic
systemstatus.
4. The systemsavesthe new statusand displaysafreshcustomissue
statusform.The systemrenumbersthe orderby10s. (%10)
AlternativePaths 3a. User failsto enterrequiredfield
3a.1 Systemdisplaysthe issue statusformwiththe completedvalues
alongwithan error message indicatingthatthere are requiredfields
incomplete.
Post Condition The administratorhasaddeda new customstatus.
Version Thiswill notbe implementedinthisiterationalthoughcustomstatusesare
currentlyinthe application.Administratorsjustdon’thave the UIto be
able to enterthem.
Notes

66
30 AdmindeletesCustomStatus
Goal Customstatusis removedasan optioninthe system
Summary AdmindeletesaCustomIssue Status
Actors User withAdministratorauthorities
Preconditions User has createdcustomstatus
BasicCourseofEvents 1. User selectsoption/linktodeletecustomstatus
2. The systemdisplaysalistof customstatusesfordeletion
3. The user selecttodelete astatus
4. Systemresponds “Are yousure”
5. User responds“yes”
6. The systemdeletes(hides) the customstatusandredisplaysthe
updatedlistof customissue statuses
AlternativePaths 3a. The userselectsaundeletable status(unassignedorclosed)
3a1. The systemdisplaysan errormessage indicatingthe statuscannotbe
deleted.
3b. The selectedtodelete astatusthat hasissuescurrentlyinthatstatus.
3b.1 The systemdisplaysanerrormessage indicatingthatthere are
issuescurrentlyinthe statusthatthe user istryingto delete.
5a. User responds“no”
5a.1 Systemdoesnotdelete the customstatusanditredisplayslistof
issuestodeleted.
Post Condition The custom statushas beendeleted
Version Thiswill notbe implementedinthisiterationalthough customstatuses
are.Administratorswon’thave the UIto be able to delete them.
31 Admincreatesuser
Goal Create a useraccount
Summary Administratorcreatesauseraccount
Actors User withAdministrativeauthorities
Preconditions
BasicCourse ofEvents 1. User selectstocreate a user
2. Systemrespondswiththe create userform
3. The user completesthe formandsubmits
4. The systemcreatesthe useraccount, sendsanemail tothe userwitha
randomgeneratedpassword. Thentheysystemdisplaysafreshcreate
userform.
AlternativePaths 3a. User suppliesanon-uniqueusername
3a.1 The systemdisplaysthe create userformwithvalidentryvaluesand
an error message indicatingthatthe username innotunique.
3b. User doesnot complete arequiredfield(allfieldsare required)
3b.1 The systemdisplaysthe create userformwithvalidenteredvalues
and an error message indicatingthatrequiredfieldsare missing.
Post Condition The user iscreatedand the passwordisemailedtoheraccount.
Version Will not be implemented forthis iteration.Usersexist in the systemforV

67
0.2, butthere is no meansto any CRUDor login/logout.
32 Adminedits a user
Goal Edita useraccount
Summary Administratoredits auseraccount
Preconditions User account iscreated
Basic Course of Events 1. User selectsthe optiontoeditauser
2. Systemdisplaysalistof userstoedit.
3. User selectsthe specificusertoedit.
4. Systemrespondswiththe userformwiththe usersattributes
populated.
5. The user updatesthe editablefields( role,email address,firstname,
lastname,small andlarge icons) and submits
6. The systemupdatesthe useraccount anddisplaysthe listof usersto
editalongwitha message indicatingthatthe useraccount wasedited.
Alternative Paths 5a. User doesnotcomplete arequiredfield(all fieldsare required)
5a.1 The systemdisplaysthe create userformwithvalidenteredvalues
and an error message indicatingthatrequiredfieldsare missing.
Post Condition The user isedited.
Version Will not be implemented forthis iteration.Usersexist in the systemfor V
0.2, butthere is no meansto any CRUDor login/logout.
33 Admincreates unavailable hours
Goal Admincreatesvacation/timeoff soschedulesandcalculationsdon’t
include thistime forthe team
Summary Admincreatesvacation/timeoff forteamsoschedulesandcalculations
don’tinclude thistime
Preconditions
Basic Course of Events 1. Adminselectstocreate anunavailable hours/holidayentry
2. The systemdisplaysthe formwhichincludesadate and a fieldfor
hoursunavailable forthatdayfor the team.
3. The admincompletesentersthe dayandnumberof hoursthe team
will be unavailable forthatdayand submits
4. The systemsavesthe informationanddisplaysafreshformand a
message indicatingthatthe unavailablehourshave beenscheduled.
Alternative Paths
Post Condition The user deletedunavailablehours

68
34 Adminresetspassword
Goal Administratorresetsauser’spassword
Summary Administratorresetsauser’spassword
Actors User withadministrative authorities
Preconditions
BasicCourseofEvents 1. User selectstoreseta userspassword
2. The systemdisplaysthe listof users
3. The user selectstoresetthe user’spassword
4. The systemresponds“Are yousure”
5. The user responds“yes”
6. The systemgeneratesanew passwordandemailsittothe user.The
listof usersis redisplayedalongwithamessage indicatingthatthe
user’spasswordhasbeenresetandemailed.
AlternativePaths 5a. User responds“no”
5a.1 Systemredisplaysthe list of users
Post Condition The passwordhas beenresetandemail tothe user
Notes Will notbe implementedfor thisiteration
35 AdminCreate a Role
Goal Administratorcreatesarole towhichhe assignsusers.Thisrole controls
systemaccess
Summary Administratorcreatesarole
Preconditions
Basic Course of Events 1. User selectsoption/linktocreate a role
2. Systemdisplaysthe role form
3. User completesthe role formandsubmits
4. Systemsavesthe role dataand displaysafreshrole formalongwitha
message indicatingthatthe role hasbeencreated.
Alternative Paths 3a. User doesnot complete all requiredfields
3a.1 Systemre-displaysthe create role formwithvalidentriesdisplayed
alongwithan error message indicatingthatnotall requiredfieldshave
beencompleted
Post Condition The role has beencreated
Notes Questionstobe answeredongranularityof permissions/authorities.
SystemRoleswill be defaultedinV.02.

69
36 AdminEdit a Role
Goal Administratorchangesarole’spermissions.
Summary Administratorchangesarole’s permissions
Preconditions Role hasbeencreated
Basic Course of Events 1. User selectsoption/linktoeditarole
2. Systemdisplaysalistof roles.
3. User selectsthe specificrole toedit
4. The systemdisplaysthe role formwithvaluesof the selectedrole.
5. The user adds/removespermissionsandsubmitschanges.
6. The systemsaveschangesanddisplaysthe listof rolesforediting
alongwitha message indicatingthatthe role hasbeeneditedandthat
all userswill have the new permissionsonce theylogoff andlogin.
Alternative Paths
Post Condition Role hasbeenedited
37 AdminAssign Usersto Role
Goal Adminassignmultiple usersatonce toa role
Summary The adminselectsmultiple userstoassigntoa role
Preconditions Users have beencreated,Rolesare created.
Basic Course of Events 1. User selectsthe option/linktoassignuserstoroles
2. The systemdisplaysalistof all usersand an optiontoselect1 role
3. The user selectsthe desiredrole,andthenchecksall usershe wantsto
assignto the role.
4. The systemupdatesthe usersrole attributesanddisplaysamessage
indicatingthatthe usershave beenassigned toanew role
Alternative Paths
Post Condition Users have beenassignedtoanew role

70
38 Administrator UpdatesSystemValues
Goal Administratorupdatessystemvalues
Summary Administratorupdates systemvalues
Preconditions
Basic Course of Events 1. Administratorselectsthe option/linktoupdate systemvalues
2. The systemdisplaysthe systemvaluesform forupdate
3. The administratormakesthe necessarychangesinthe systemvalues
formand submitsthe changes
4. The systemsavesthe changes,displaythe new systemvaluesand
displaysamessage indicatingthatthe systemvalueshave beenedited
Alternative Paths
Post Condition Systemvalueshave beenchanged
39 Create Activity
Goal Create activityfora work item
Summary User createsan activity(throughActivityNode)
Actors Users withcreate activity authority
Preconditions Work itemselected
Basic Course of Events 1. User selectsthe new activitynode
2. The systemdisplaysnew activityform
3. User completesandsubmits
4. The activityispersisted
Alternative Paths 1a.1 User createsor updatesworkitem, design,testcase,orattachment
1a.2 User ispromptedtoentercommentsaboutthe workitem.Enter
commentsandsubmit.
1a.3 Activityiscreatedwiththe commentsenteredascommentsfield.
Post Condition Activityhasbeencreated
Version 0.2
Notes
40 ViewActivity
Goal View activityforawork item
Summary User viewsanactivity(throughActivityNode)
Actors Users with view activityauthority
Basic Course of Events 1. User selectsthe activitytoview
2. They systemdisplaysthe activityonthe maincontentarea(no
updates)
Alternative Paths
Post Condition Activityhasbeen viewed

71
Version 0.2
Notes
41 Create Attachment
Goal Create attachmentfora workitem
Summary User createsan attachment
Actors Users withcreate attachmentauthority
Basic Course of Events 1. User selectsthe new attachmentnode
2. The systemdisplaysnew activityform
3. User completesandsubmits
4. The attachment ispersisted.The linkisstoredinthe database,while
the actual uploadeddocumentisstoredonaserveras definedin
SystemPreferences.
Alternative Paths
Post Condition Attachmenthasbeencreated
Version 0.2 – butlocation of uploadsis currently hard coded.
Notes
42 ViewAttachment
Goal View attachmentfora workitem
Summary User viewsan attachment
Actors Users withview activityauthority
Basic Course of Events 1. User selectsthe activity toview
2. Theysystemdisplaysthe activity
Alternative Paths
Post Condition Activity hasbeenviewed
Version 0.2
Notes
43 Dependentdropdown search selection
Goal Whenan attribute isselectedforsearchcriteria, onlyvalidoperatorsand
attribute valuesappearasselections
Summary User selectsanattribute,andthe appropriate operatorsandvaluesare
displayedasoptions
Preconditions
Basic Course of Events 1. User selectsan attribute fromone of the dropdownselectionsinthe
searchbox
2. The systemretrievesthe selection,thenbasedonattribute type,

ChrisGarrisonProjectThesis

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (18)

Similar to ChrisGarrisonProjectThesis

Similar to ChrisGarrisonProjectThesis (20)

ChrisGarrisonProjectThesis