Rational's suite of development tools support round-trip engineering (RTE), distributed and collaborative development, highly iterative development cycles, and much more. This is the first installment of a multiple-part article that will demonstrate Rational's tools in action and show how you can use them in a distributed, J2EE (Java 2 Platform, Enterprise Edition) project. We'll look at a simple fictional project, starting with high-level planning and requirements solicitation and moving through the phases of the Rational Unified Process (RUP). This article assumes you already have some familiarity with the RUP; if you don't, you might want to check out the resources listed later under Related Resources.
For the sake of simplicity, we won't go through all the necessary iterations of the RUP, but will show only the major features of the tools used at the various stages. We'll follow our small sample project through to its first major build, demonstrating:
- many of the RUP concepts and Rational tools in use, applied to meet the challenges of remote development, tight schedules, and a constrained budget
- end-to-end traceability and requirements management using Rational's technologies
- tool integration in a J2EE project, complete with automated testing, RTE, geographically distributed code reviews, and quality assurance (QA)
- integration of J2EE tools with Rational's technologies, in particular applying J2EE, a relational database like DB2 or Oracle, and a Java IDE to the final solution
The article parts will all have a similar organization. Each will begin with a roadmap through the article like the one below, with links to those parts that are currently available.
- 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
| Part 1 Snapshot |
Tools and technologies demonstrated in Part 1:
|
The fictional premise of this article is that we're a software company, named Lookoff Technologies Incorporated, that specializes in IT systems, including integration, support, and development from the ground up. We're based in Toronto and have a number of smaller offices distributed across Canada. This corporate structure allows us to centralize a good deal of our expertise (typically the back-end development and project management) while having analysis and development teams located close to a large number of customers across the country.
We were approached by another fictional company, Audiophile Speaker Design, Inc. (ASDI), located nearby in St. John, New Brunswick. ASDI started as a niche speaker construction and design company, developing custom speaker solutions for individuals. As their popularity grew, they developed a more mainstream speaker line, delivering products to franchised audio and electronics stores across Canada and the northeastern United States.
ASDI's technological infrastructure hadn't scaled up with their growth in size. They were having difficulty managing incoming orders, planning their backlogs, tracking part requirements, and managing shipping. Furthermore, ASDI's customers were complaining about their inability to view availability and delivery progress.
Realizing the risks associated with moving from paper and spreadsheets to a semi-automated asset management system, ASDI decided to sole-source their IT requirements to Lookoff. Their main reasons for choosing us were reputation and close proximity to their office (for ease of support).
Note that although the sample project is fictional, it's based on my personal experiences, observation of other projects, and knowledge I've acquired through excellent books such as those listed under Related Resources.
Soliciting High-Level Requirements
Like many small non-IT companies, ASDI recognized their problem but didn't have a clear statement of their requirements. Their original statement of work (SOW) was only two pages long and was a mix of contractual, functional, and programmatic requirements. We sat down with them to discuss the significance of each of their points; of greatest interest here are the contractual and programmatic issues, discussed below.
The customer (ASDI) wanted us to sign up for a firm fixed price (FFP) contract of 1.1 million dollars Canadian (CDN), with delivery of software within ten months of contract acceptance. Without a clear vision of the requirements, it was impossible for us to agree to this. It would have exposed us to excessive risk and would have been unfair to the customer, had we found out that their technical requirements could be satisfied for much less. We came to the first meeting intending to discuss the strengths of iterative and incremental software development over sequential ("waterfall") development.
The key features of the RUP that we emphasized to the customer included:
- iterative engineering, to reduce risk and converge on the right solution rather than get stuck in the direction outlined in an FFP SOW
- making the greatest possible use of existing tools, technologies, and off-the-shelf (OTS) products, to reduce cost and increase quality
- managing and controlling change
- giving the customer insight into the emerging product
- building a high-quality product
The customer still had concerns about the lack of a drop-dead date for delivery of the software. Through some discussions, we succeeded in showing that they would have significant insight into the progress of the project from start to finish. They also wanted the comfort of a ceiling for the project's budget, and some liability on our part for underperformance. Consequently, the project plan evolved into this two-phased structure:
- Phase 1 -- creation of a "proof of concept" version of the system. We'd be paid for this on a level-of-effort (LOE) basis, but with a ceiling.
- Phase 2 -- creation of a production version of the system. Payment for this would be FFP.
For Phase 1, the customer required a ceiling of 250K$CDN, which we felt was ample budget to achieve our goal of having a first-build demonstration of the prototyped system. We created the Gantt chart shown in Figure 1, placing the demo at the four-month mark, and reviewed it with the customer to ensure that we were at least roughly synchronized with respect to the Phase 1 schedule. (We'd later examine this schedule more closely with them.)
Figure 1: Phase 1 Gantt chart
The diagram in Figure 1 was created in Microsoft Visio, but you could just as easily use Microsoft Project or a similar software tool to plan your project. The main purpose of the chart was for us to agree on schedule and milestones and to set up a hierarchy of work breakdown structure (WBS) items that we could track, estimate, and execute against.
ASDI is an ISO shop and a strong believer in heavy documentation, sequential milestones, and extensive QA involvement. They aren't a terribly technical company, and they have their own ideas on process. One of our biggest challenges in working with them was to find a process and set of deliverables that would satisfy them yet not overly impede our team. They came into the meetings placing heavy emphasis on having a lot of thorough and detailed documents. Furthermore, their milestones were sequential, with the idea that each task must be fully completed before the next task could begin. These perceptions would make it more challenging for us to apply the RUP in the best possible way.
Although ASDI agreed we could use an iterative and incremental (RUP-based) approach, they had little interest in it. They wanted the following:
- Fixed milestones:
- a systems requirements review (SRR), preliminary design review (PDR), and critical design review (CDR)
- two demonstrations of the emerging software
- factory acceptance tests (FATs) and customer acceptance tests (CATs)
We easily fit these milestones into our process (as shown in the chart in Figure 1).
- A formal requirements document, a design specification, and acceptance test documentation. Being new to the object-oriented notations of the RUP-based approach, ASDI wasn't all that keen on working with them, but agreed to keep their deliverable descriptions high-level enough that we could satisfy them with RUP artifacts. We felt we could use Rational tools to generate any required documents without significantly impeding our process, and could successfully communicate the information to the customer. In particular, Rational SoDA would enable us to easily generate documentation from our model.
ASDI also planned to hire an IT manager to interface with our team and assume responsibility for maintenance and management of the finished project. We would need to involve this individual, who would serve as the technical authority for the project, in all technical progress. Unfortunately, the IT manager (being new to the company) would probably have as little knowledge of the customer's operations as our own team had.
Coming out of the first set of meetings with the customer, we'd made some excellent progress. Their expectations for both deliverables and schedule were somewhat flexible and allowed us to run with the RUP-based approach without too much impact. We managed to agree on a rough schedule structure for the project and to establish a good relationship with the customer. From our discussions with them, we were able to identify some risks that we later used to prioritize our tasks and management of the project.
One of our top priorities going forward would be to work with the customer to set the project vision, starting with the customer's SOW. We had obtained a brief understanding of their requirements, but we needed to scope out the specific work that would have to be done.
We also had to refine the schedule and get our exploratory phase underway as soon as possible. During Phase 1, we'd have to figure out how to satisfy requirements while ensuring a solution that was cost-effective and satisfactory to the customer. The customer had mentioned that maintenance of the final system and software/hardware costs of the system infrastructure would be major factors in their decision whether to move ahead with Phase 2.
To summarize, most of the work in the first few weeks would involve the following:
- expanding on the SOW for the project and entering the project requirements into Rational RequisitePro
- refining the schedule for Phase 1
- creating a project plan to show how we proposed making the transition to Phase 2 after a successful design review
- making specific execution plans for mitigating risks that were identified
The first few weeks of the project would be critical in establishing an effective relationship with the customer and taking the project in the proper technical direction. We wouldn't have much time to find the required technologies and integrate them into our team, since the customer was expecting very fast progress.
We felt we had to set up an issues database where we could raise action items, issues, and risks in a centrally located database. By placing this information on the Web, we would enable both the central office and the remote development team to monitor it. Even telecommuters would be able to track and update project risks as needed.
- The Rational Unified Process: An Introduction, Second Edition by Philippe Kruchten (Addison-Wesley, 2000) provides a good introduction to the RUP. Detailed information can be found in the RUP product itself.
- Rapid Development: Taming Wild Software Schedules by Steve McConnell (Microsoft Press, 1996).
- The Mythical Man-Month, Anniversary Edition: Essays on Software Engineering by Frederick P. Brooks, Jr. (Addison-Wesley, 1995).
- Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects by Edward Yourdon (Prentice Hall PTR, 1999).
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
