Abstract

In the given article, the writes, a number of vendors and government offices were assigned by the US Government to develop a system for the Computer-Based Patient Record using Object-Oriented (OO) technology.

It was first thought that bringing order to many diverse and conflicting views represented on the team would be impossible. However, the team decided to develop a process definition technique based on the metaphors of OO technology and this brought about common understanding and a clear project plan, which in the end saw through the satisfying outcome and ability to meet up with the deadline and provided rather accurate cost estimation.

The project was seen as a challenge as beside the magnitude, at the time of the project development-1996-the literature on OO technology was much less robust and there were no cookbooks or many guides.

Due to the magnitude, complexity, and funding of the project, in implementing the project, besides using the OO approach, the team embraced the Incremental Model as the Software Process Model and accepted the assertion of the Software Engineering Institute’s Capability Maturity Model (SEI-CMM). They also decided to make use and extend concept of Convergence Engineering and class-based reengineering and also Class/Responsibility/Collaboration (CRC) concepts. Also used is Unified Modeling Language notation and Computer-Aided Software Engineering (CASE) tools.

During the implementation, the team considered the theoretical logical work units as classes, defined class responsibilities as tasks with level-of-effort parameters and articulated collaborations as explicit interface definitions expressed in terms of dependencies and products with definitions articulated as acceptance criteria.

In the initial phase, the team management began by asking the members of each anticipated logical work unit to write down their own responsibilities and collaborations in general CRC card form. These would to include estimates of person-effort and the specific input required and output produced by each process. Each team was also to develop CRC cards for each of its “process neighbors”.

These processes are then followed by planning sessions in which different teams meet up together to hammer out details of collaboration with its process neighbors. All the previous processes proved to be valuable, as in these sessions considerable amount of dialogue are stimulated and redundancies, gaps, and faulty assumptions are quickly exposed. Finally, a face-to-face validation conference was held, attended by the entire team to refine all tasks, dependencies, sequences and product interfaces.

It was found that using the OO techniques, misconceptions, faulty assumptions, inexperience and biases are easily exposed. It has also simplified the project’s complexity, and the detailed, common understanding of responsibilities and collaborations substantially mitigate risk and save time and effort for the next increment process. The technique also made responsibilities, assumptions, and interdependent collaborations explicit.

The result of the first increment yielded a successful proof of concept, showing that interoperability among heterogeneous systems was feasible using open, distributed-object computing. For the second increment, it was found that the detailed process definition from the first increment had substantial reuse value, allowing rapid development of level-of-effort and schedule estimates for later increments. The first increment was successful and fell within the cost and schedule tolerances. The subsequent increment was also easily estimated in term of time and cost needed.

Furthermore, the clearly defined process as the results of the works in the initial phase save the teams substantial time in executing the tasks. Generating contact task statements for the subsequent increments took a fraction of the normal time because a large portion of the process definition can be reused.

Team status meetings also let managers detect departures from the defined process easily and early and thus wasteful misunderstandings between teams, tangential and dead end activities can be avoided.

The main limitation of the OO approach in defining team process is that the initial level of effort to develop the process reference model is high. It would be a contentious process and can easily harm team relationship early in the process. Also, all the member of the teams have to commit themselves to attending meetings in its entirety.

Keyword: OO, Incremental Approach, Software Engineering Institute’s Capability Maturity Model (SEI-CMM), Gantt chart, Class/Responsibility/Collaboration (CRC) cards, Unified Modeling Language, CASE (Computer-Aided Software Engineering) tools.