ASDI

ASDI is an ISO shop and a strong believer in heavy documentation, sequential milestones, and extensive QA involvement.

Although there was no formal warranty stage, ASDI would be raising issues that would be entered into the ClearQuest database.

As demonstrations increased in frequency and maturity, ASDI continued to be satisfied with the work we were doing.

Through iterative reviews of the document, we were able to coach ASDI toward writing an even and adequately detailed set of requirements.

ASDI had been involved in a number of our demonstrations and was feeling quite comfortable and satisfied with the product.

On the ASDI project, it would be easy to provide independent development environments, even for our remote offices.

When ASDI's technical lead started pushing for an OODB solution, we were concerned by this introduction of a new technology.

As ASDI started using the Phase 1 version of the software on their site, they continued to be satisfied with the product.

The real challenge was to convince ASDI of the need for activities to occur in parallel rather than to have all milestones be sequential.

They decided to defer action on Phase 2 until a later date, after they had more data and a clearer picture of their own financial situation.

Having passed the acceptance tests, the system was now ready for transition to ASDI (delivery and maintenance).

Looking at the schedule, ASDI was very concerned that we were almost halfway through the project yet still performing detailed design.

By the time we ran the customer acceptance tests, there was very little question that ASDI would be happy with the product.

To make life a little more difficult, ASDI was expecting us to wrap up the use-case documentation before we proceeded with follow-on tasks.

We were pleased that ASDI agreed to mockups and prototypes as useful parts of the analysis stage.

We were already leaning toward J2EE, and ASDI's recently hired IT manager strongly preferred it as well.

ASDI's original expectations were that the SOW would grow into a large textual document.

ASDI started as a niche speaker construction and design company, developing custom speaker solutions for individuals.

As the prototypes and detailed analysis sessions progressed, ASDI become much more comfortable with our progress.

The architecture and design activities were among the most enjoyable and creative tasks on the ASDI project.

We wanted to be sure the system would scale beyond ASDI's expectations.

Before launching into the details of the architecture and design efforts, let's review the overall progress of the ASDI project.

Demonstrations took place at several points in the ASDI project, but especially during the RUP elaboration and construction phases.

These scripts had been created using Rational Robot and had been thoroughly reviewed by ASDI.

Since this project was our first exposure to SoDA, we were glad ASDI was pleased with the standard SoDA templates.

You may wonder why we bothered to review the TOC with ASDI before writing any of the actual content.

The OTS evaluation (including our recommendations) would give ASDI an opportunity to review our selection criteria and rationale.

Both we and ASDI were aware that document review cycles frequently become endless and circular rather than focused and convergent.

Furthermore, ASDI's customers were complaining about their inability to view availability and delivery progress.

Once the detailed system requirements were completed, we'd pass them by ASDI as a formal deliverable.

We'd sorted out most of the technologies that would be involved in Phase 1 of the ASDI project.

Many of the iterative and incremental approaches encouraged by the RUP had good justification, and ASDI was seeing the benefits.

Again, ASDI's ISO background led them to believe analysis should be performed and documented before any design is begun.

This final installment describes what little was left to do to close out the ASDI project.

Since ASDI had agreed that an OODB wouldn't be prudent for this project, we no longer had that technical risk to manage.

For instance, there were places in the user interface where terms specific to ASDI's business domain were incorrect or misspelled.

You may be wondering what happened to the OODB option that ASDI had preferred.

Cross-platform technology was important, because ASDI expected to stick with this system for many years.

Finding the right balance between too many and too few builds was important on the ASDI project.

Further prototypes helped us convince ASDI and ourselves that a relational database was probably the safest route.

Figure 1 shows the evolution of use cases during Phase 1 (the RUP inception and elaboration phases) of the ASDI project.

In this way, we quickly honed in on the tasks (use cases) and things (business objects) relevant to ASDI's business.

Confidence was reasonably high; ASDI awarded us the contract based on our reputation and proposal.

We ran through checklists with ASDI to show that everything was complete, and we ended with the demonstration.

ASDI couldn't distribute these libraries and APIs to their customers in their current state.

Like many small non-IT companies, ASDI recognized their problem but didn't have a clear statement of their requirements.

During this project we had a very good relationship with ASDI, which was generally the case for us with our customers.

This was important to ASDI because they planned to assume maintenance responsibilities after the project was completed.

ASDI presented us with these criteria that they felt should influence our tool selections