This is the second installment of a multiple-part article (as outlined below) that demonstrates using Rational's tools in a distributed, J2EE-based project.
- Part 1: project introduction; high-level planning
- Part 2: detailed planning; risk management; requirements management
- Part 3: Rational Rose model creation and access control; requirements analysis
- Part 4: use-case refinement; report generation; tool and technology selection
- Part 5: architecture and design
- Part 6: detailed design; early development; round-trip engineering; early unit tests
- Part 7: continued development; early builds; demonstrations
- Part 8: strategies for unit testing; function tests; GUI test scripts
- Part 9: system builds and testing; defect tracking; product acceptance
- Part 10: project results; conclusions; future work
The fictional premise of the article is that we're a software company, Lookoff Technologies Incorporated, and our customer, Audiophile Speaker Design, Inc. (ASDI), has hired us to meet their burgeoning IT requirements. For a more detailed introduction to the project, see Part 1.
| Part 2 Snapshot |
| Tools and technologies demonstrated in Part 2:
Artifacts created or updated:
|
Plan from the Start or Plan to Fail
In any software project, getting off to a good start is critical. Not only do you want your early efforts to set the tone for the entire project, but you also want to quickly identify the high-risk and challenging areas of the system. Probably more than half of all projects are doomed within their first month, due to factors that include:
- poor customer relations
- inadequate budget
- poor management (including inability to manage and prioritize risks, and poor scope management)
- reliance on a silver bullet
- inadequate engineering skills or experience
- unrealistic schedule
The Rational Unified Process (RUP) tries to reduce the number of factors that contribute to project failure, by improving the efficiency of a team and guiding the team as it matures. Better data reaches the project manager, better tools support the engineering team, and better processes help the software product evolve in a predictable fashion. This Part 2 installment will address some of the early strategies we employed to get things rolling in our sample project.
Note that project management involves some activities that aren't currently addressed in the RUP. I highly recommend the book Rapid Development: Taming Wild Software Schedules as a further reference for information on reducing risk factors in programming projects.
We wanted to start the software engineering as quickly as possible, but first we had to get buy-in from the customer on a number of programmatic issues. We took the Phase 1 schedule we'd created (culminating in a demo at the four-month point) and reviewed it more closely with the customer. They raised the following questions, all of which were valid and required some discussion:
- "With iterative development, how will the engineering team know how many iterations are required to give us what we want?"
- "We're not comfortable with starting architecture and design before the prerequisite phases of analysis and architecture are complete."
- "What functionality will be demonstrated in the four-month demo?"
- "What tools will you use to build the system? We'd like to start the procurement and training process."
This is what we saw as their primary concerns, and how we responded to each of them:
- Concern that the project would spiral endlessly with no clear deliverables. Because they're a very sequential ISO shop, ASDI is used to having early concrete deadlines that lead from one to another in sequence. We pointed out that iterations reduce risk and avoid the problems inherent in an all-at-once delivery. Although the number of iterations would fluctuate during the course of the project, the customer would be able to observe the progress of the project much better than with only a single iteration. While having a single iteration might seem simpler, we needed multiple iterations in order to build the system cost-effectively. ASDI's involvement during early iterations would work to their benefit, giving them insight and the opportunity for input into the developing system.
- Concern about missed requirements and insufficient analysis. Again, ASDI's ISO background led them to believe analysis should be performed and documented before any design is begun. We emphasized that the RUP has the advantage of allowing task overlaps; that is, different phases can have tasks taking place in parallel. For example, detailed design can involve the creation of prototypes and other code development in order to verify design assumptions, mitigate performance risks, and so on. Waterfall development processes are much less flexible and don't provide as many early warnings of high risk.
- Concern about being able to track progress. ASDI had already voiced concern about using an iterative approach, and they needed to see some guarantee of concrete progress in a mid-project demo. At this point we couldn't tell them what the demo would entail; it would crystallize over the next month or two as we'd come to understand more about the critical and high-risk areas of the system. We explained that at the very least the demo would exhibit some deep slices of the architecture that mitigated major risks we identified. We also anticipated that it would show a shallow slice through the whole system to demonstrate workflow, usability issues, and interoperability between over-the-shelf (OTS) components.
- Concern that we'd pick tools they wouldn't be able to afford or support in the future. This was important to ASDI because they planned to assume maintenance responsibilities after the project was completed. They didn't want to see early adoption of exciting but risky technologies. Tool selection would require us to do some early exploration into the customer's technical requirements, maintenance plan, and other needs. The OTS evaluation (including our recommendations) would give ASDI an opportunity to review our selection criteria and rationale. At this point, they were still unsure of their performance requirements and had very little existing IT infrastructure to push us to a quick decision.
Overall, we didn't feel that the schedule was too ambitious, and we were confident it would stay within the customer's cost expectations. Also relevant to our ability to meet schedule was our team structure, which we reviewed with ASDI at this time. As shown in Table 1, we planned to involve some individuals in part-time roles. For instance, we have a single QA person in our shop who works across a number of projects; where her time is shown as a 20% role, it means she was to work on the project one day a week:
Table 1: Team structure
| Role | Time commitment | |
| Project management | Project manager | 50% |
| Accounting support | 15% | |
| QA | 10% | |
| Project engineering | Project engineer | 50% |
| Engineering support (involving configuration management, system administration, and so on) | Part-time | |
| Support and review team (for periodic reviews and consultation) | Part-time (employing staff from inside and outside the project) | |
| Team lead/senior analyst | Full-time | |
| Senior developer | Full-time | |
| Junior developer | Full-time | |
| Database architect | 25% |
In total, we projected that we'd require 450 person-days of effort to get to the four-month demo. As we progressed, we'd know if we were going to require more or less time than this, and we'd give ASDI significant notice if so. At the time of the demo, we'd also be fully prepared for an in-depth design review and would be able to present estimates for Phase 2 of the project. If ASDI was happy with our proof of concept (POC) work in Phase 1, they'd start a new contract for Phase 2 work to develop the production system.
ASDI was pleased to see they'd have significant input into the evolving product, even though we were only shooting for a Phase 1 demo. At the very least, they'd have access to a requirements review, screen mockups, an OTS evaluation, an architecture review, two practice builds, and a demo.
It's important to track risks from the start. On previous projects, we'd managed risks in Microsoft Excel, but this time we decided to use Rational ClearQuest to simplify risk entry, management, and reporting. ClearQuest isn't a cheap tool, and it wouldn't be cost-effective for risk management alone; however, it would also be central to managing our integration and test issues. In addition, we planned to amortize its cost across a number of Lookoff projects.
It was very convenient to design new data structures and forms with ClearQuest Designer. For example, to create a risk entry form similar to the Defect form already present in ClearQuest Designer, we simply created a new schema based on the DefectTracking schema, removing some of the unnecessary elements and renaming others, and similarly updated the corresponding form, removing or renaming prompts and fields as required.
Here's how you can try this out yourself: Assuming you installed ClearQuest with administrative privileges, you should have no trouble finding the ClearQuest Designer application. From the File menu, choose New Schema, and select an existing schema that you'd like to modify. We chose to modify the DefectTracking schema. Once you've given your new schema a name, you'll be prompted to create a database to associate with that schema. Unless you've taken special measures, you'll want to create this as a Microsoft Access database. When asked to associate a schema with this new database, select the schema you just named and created. You can then check this database out for editing, and modify the forms and data types as you see fit. For instance, you can expand the Record Types and Forms nodes of the tree to inspect the existing Defect_Base_Submit form. These forms can be renamed and fields can be deleted, added, and so on. Refer to the ClearQuest documentation for more information on creating and modifying ClearQuest forms.
I was able to quickly enter the risks for our project into ClearQuest by running it from the desktop. The whole team would have access to the risk repository and would be able to enter risks as they observe them. Although only the project manager (PM) and project engineer (PE) should have privileges to close risks, there's nothing wrong with giving all team members privileges to raise risks. Project managers may want to review the entered risks for customer visibility first, since some of them may not be relevant or may be able to be solved quickly. As an example, Figure 1 shows a form being used to enter a project risk encountered early in our discussions.
Figure 1: ClearQuest risk entry form
(
click here to enlarge)
We identified and entered a total of 17 risks for the start of the project. This wasn't a particularly large number, and some of them (such as the challenging schedule) would last until the final leg of the project.
Figure 2 shows the ClearQuest interface with one of our queries for pulling up a partial list of project risks. The risks are listed at the top, ordered by severity. Further detail on individual risks are obtained by clicking on a risk, which populates the fields below this list.
Figure 2: ClearQuest risk report
(
click here to enlarge)
Management needed tools to track progress. In the early stages of the project, we couldn't rely on things like defects, change requests, and test results to measure project success. Instead, we'd have to base our progress tracking on work breakdown structure (WBS) items and on estimates to complete (ETCs) versus actuals.
A good WBS is important in tracking progress. The Gantt chart in Part 1 outlined our Phase 1 work packages. To enable us to extract useful metrics, these packages had to be clearly defined and appropriately sized. We typically budgeted them to take between 10 and 40 days of effort.
In addition, ClearQuest helped us track volatile parts of the system -- those parts in which change requests were disproportionately high. In previous projects, we'd found that having excessive change requests during the elaboration phase was often a sign of one or more of the following: insufficient analysis, a difficult customer, a weak engineering team, poor execution of process, or complex re-engineering. At the very least, areas of the system exhibiting these symptoms needed extra attention from management and the team lead.
Managing Customer Expectations
At times it may seem easier to reduce the number of meetings and encounters with the customer ("out of sight, out of mind"); however, in reality, the customer is one of the most important members of your team and should be involved throughout the project. Not only will this yield better analysis and improve the results achieved within each iteration, but it will manage the customer's expectations by enabling them to see the evolving product and understand the challenges. Especially when the customer isn't very technical, their vision of the final system could be vastly out of touch with the realities of cost, schedule, and feasibility.
We suspected that the true priorities and motives for the project weren't reflected in the customer's SOW, yet we needed to understand the customer's major priorities and expectations. To address this, we drafted a brief vision document to help us learn more about customer expectations. (Because of time constraints, we merged the business vision and the project vision into a single document.) Both the SOW and the vision document underwent multiple revisions, with the customer's involvement.
The vision document was based on one of several Microsoft Word templates supplied with the RUP package. We installed these templates in an area pointed to by Word for user or workgroup templates (via Tools > Options > File Locations). As shown in Figure 3, we generated previews for each template (by opening each .dot template file, selecting File > Properties > Summary, checking "Save preview picture," and saving the file) and renamed the *.dot files to the template titles to make them easier to scan.
Figure 3: Scanning RUP Microsoft Word templates
(
click here to enlarge)
The requirements for this system weren't trivial. Also, because ASDI had very little IT infrastructure in place, translation of system requirements into specific software requirements required substantial time and effort. Rational RequisitePro helped us tremendously in this task, allowing us to manage our requirements and track changes in scope throughout the project.
The customer had already started an SOW that would serve as our baseline for the system's requirements. In most cases, we would have started with business modeling and requirements analysis, as outlined in the RUP. This would have included a set of business use cases, supplementary system specifications, and a business object model. Instead, it was important for us to start with the customer's SOW to satisfy their expectations and build on their work. We'd massage their SOW into a RUP artifact called the software requirements specification (SRS) and use it as the base set of requirements against which we could trace our subsequent analysis and modeling artifacts.
RequisitePro's Block Create capabilities made it very easy for us to import the requirements from the customer's SOW. Our creation rules matched on the Bullet style, or on sentences with any or all of the keywords "must", "will", and "should". Another trick that helped us set up the requirements hierarchy involved grabbing blocks of requirements at the same level, setting the defaults under the Block Create tab to point to the proper parent requirement, and then letting the creation tool do the work. (At first we used Block Create without setting the parent requirement, and we had to go back to each requirement and assign the parent to each requirement -- a tedious chore for hundreds of requirements.)
Figure 4 shows one page (out of approximately 40 pages) of requirements from the Customer Services subsystem. As you can see, the RequisitePro interface is tightly integrated into the Word application, so you have full access to the features of Microsoft Word and RequisitePro at the same time.
Figure 4: Rational RequisitePro interface
(
click here to enlarge)
We worked closely with the customer to communicate what information was required, but let them do the bulk of the work on the requirements document. This proved to be a very efficient way to proceed; we were able to transfer process skills to their team, while they brought their subject expertise to our team. They tended to dive into some areas with tremendous detail but left others at a very high level. In some cases this was appropriate, but in other cases it reflected their degree of enthusiasm for a particular area of the system. Through iterative reviews of the document, we were able to coach ASDI toward writing an even and adequately detailed set of requirements. Because we were dealing with a Word document, it was easy to interoperate on the spec, and then run RequisitePro on it once we were satisfied with it.
Also at this time we addressed the system's nonfunctional requirements, meaning those not described by the system's functional specifications. These include usability requirements that address human factors (such as ease of learning and use) and reliability requirements, among others.
At this point in the project, we were running with a fairly small team. Getting the plan and resources in place was our top priority. There was no sense in increasing the burn rate of the team until we knew where we were headed and had some idea of how we were going to get there. An important first step we'd accomplished was that we now had an SOW (the SRS) that set the base system and software requirements for the project.
We wanted to get the engineering team involved as soon as possible, but our next set of tasks required a senior analyst to make more progress in the RUP inception phase, getting it well underway. For one thing, the requirements as stated in our SOW were essentially a set of decomposed specifications that didn't lead to a clear breakdown of the work or even yield many architectural clues. We've consistently found that requirements expressed in plain text don't bring the same advantages as their Unified Modeling Language (UML) equivalents, so we planned to translate our requirements into use cases (in Rational Rose using UML).
Also, we needed a formal means of managing customer change requests, concerns, and feedback. Although we hadn't used ClearQuest's Web interface before, it seemed like the perfect tool to keep the development team and the customer synchronized. Setting up ClearQuest Web would be a high priority for us over the next week or two.
Our risks hadn't changed significantly: We had to continue to focus on establishing an effective relationship with the customer and on quickly taking the project in the proper technical direction. We now had an issues database, so we were able to close that risk; however, until we set up ClearQuest's Web interface, the customer wouldn't have much visibility into the project risks and the areas where they could support us. (As it later turned out, we couldn't afford the time or infrastructure to set this up, but a larger project would definitely have benefited from it.)
The customer was happy with our progress to date, partly because the artifacts didn't feel foreign to them. As we proceeded with moving over to RUP artifacts, however, we'd have to maintain this comfort level with plenty of guidance and gentle introduction to the new concepts: uses cases, business objects, and so on.
We felt that our schedule was feasible and well designed but that there was very little contingency. This meant that resources had to be put in place quickly, and review feedback would have to be timely. We also had to focus on high-priority risks right from the start, since we couldn't afford to let them slip far into Phase 1.
- Rapid Development: Taming Wild Software Schedules by Steve McConnell (Microsoft Press, 1996)
Steven Franklin has an extensive background in software design, architecture, and engineering process, which he usually applies to large, distributed information management and command and control systems. He's been using Rational tools since 1997, and his primary areas of interest include XML, J2EE, wireless, and software engineering methodologies. Steven can be reached via e-mail.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
