Corrections such as these can be most easily and effectively performed by software, and should be planned for this stage. Although this role may solicit occasional grumbles from programmers, software's ethereal construction lends itself to being thought of in this fashion. It is often less expensive to "fix it in the software" than to correct the underlying problem—particularly when time is short.

Living with the Monster

Looking ahead into the next decade, diagnostic instruments will almost certainly become more, not less, complex. To maximize the chances of hitting the intended market window and to remove a considerable portion of the risk, certain key steps are indicated.

Carefully Plan Early Integration of Software into the System Architecture. All stakeholders must be on the same wavelength from the outset. If differing design viewpoints cannot be reconciled at an early stage, the instrument is certain to have a long development process and may go through unforeseen iterations.

This happened at one Midwest company. During its development, a poorly conceived IVD device with more than 100,000 lines of code encountered major problems that cost two years, led to the redesign of significant sections of software, and required the electromechanical components to be completely reworked. On paper, sufficient coordination appeared to be in place. The company formed an electromechanical group, a test group, a software group, an integration group, a user group, and several other teams to assist cross-disciplinary integration.

Unfortunately, the user group was located in a different building and came too late in the coordination chain. As a result, users didn't get what they'd asked for. To make matters worse, both the software and hardware groups made costly errors and didn't consult enough with others. Why? Some groups attended one meeting, and some went to another. Had these groups coordinated better with one another, the delays associated with this project could have been reduced significantly.

Perhaps the most important reason for the extensive delay of this project, however, was a difference in opinion over a precise definition for the instrument. Representatives from the different disciplines must be in agreement about the product's concept if they are to ensure that a safe, effective product is created.

Properly Document All Planning and Project Requirements. Doing the paperwork correctly provides a solid foundation for product development. Subsequent phases of the development can proceed more efficiently. This "up-front" documentation, which serves as a road map, consists of three key elements:

Essentially, the PRD states exactly what the instrument is to accomplish. A top-level design and architecture plan may then be constructed which describes how the system is to be partitioned, how each subsystem contributes, and how each subsystem interacts with the others.

There is a delicate line between specification (what the UI does) and design (how it does it). The UI document often has more "design" in it than is appropriate for the PRD because the look and feel of the entire instrument are true requirements of the UI. On the other hand, how the instrument delivers fluid or heats a sample is usually not integral to what the instrument does.

Risk analysis is crucial. For example, a major IVD system manufacturer didn't pay enough attention to hazard mitigation in the relationship between software and electromechanical components in a blood testing instrument. When it became evident that some samples could be confused with others while inside the device, significant software and some of the electromechanics had to be redone, costing several years of delay. The company eventually realized that critical system issues could have been resolved with teamwork. Safety concerns must be planned for early in the product development process.

Figure 1. Product development documentation consists of three equally important sets of requirements. They must always be in alignment.

These three documents (PRD, UI requirements, and safety requirements) do not exist in isolation. Even after the PRD has been written, safety requirements may cause functional requirements to be altered. These changes, in turn, can impact UI requirements. Further user feedback can result in another revision of the PRD.

Consider the user interaction method. The UI requirements may state that the sample identification is to be typed into the computer, while hazard mitigation requirements recommend that an automated entry, such as bar codes, be used. This change could add significant redesign costs to the instrument. If it is a high-end device, bar code cost is probably not a major concern, but does have electromechanical and software repercussions. If the product is a low-cost device, having the user type sample identification numbers twice could satisfy safety requirements. Thus the PRD, UI requirements, and safety requirements documents should not only be considered individually, but also in terms of how each will affect the others (see Figure 1).

Get a Commitment from Management to Allocate Resources. Management must use resource and staffing profiles to accurately set deadlines. This allows all variables to be taken into account, thereby ensuring that the right number of testing instruments are ordered, adequate staffing is organized, and the project has the resources it needs to be done on schedule.

Qualified professionals are the single most critical resource for any project. The best software engineers can be several times as productive as average software engineers. Finding, motivating, and nurturing them is the single best way to guarantee success on a software project.

Manufacturers must apportion time to develop necessary equipment for the project. For example, custom support software—such as a simulator to test how embedded instrument systems will integrate with UNIX or NT platforms in related hardware—is a very valuable tool. Because the instrument itself doesn't yet exist, a simulator must be developed to speed the software development process. By using a simulator early in the process, bugs can be detected sooner, which can take months off the project's time to market.

Conclusion

The desire to get a product to market during a specific period can affect its development time frame. However, deadlines must be set with an understanding by all involved of what the developmental process entails and the consequences of lengthening it.

To achieve timely project success, all parties must be brought together early in the development process to align each facet of instrument design. By wisely investing weeks at the beginning of project planning, years can be saved in bringing complex instruments to market.

References

1. Barry W Boehm, Software Engineering Economics (Englewood Cliffs, NJ: Prentice Hall, 1981).

2. Code of Federal Regulations, 21 CFR 820.

Nelson Holton is software systems director at RELA Inc. (Boulder, CO).

Images Copyright 1999 Photodisc Inc.