Introduction
The virtual surgery project is a code term for a multi-purpose surgery simulation software product that will assist surgeons in practicing basic mastoid surgery through a virtual environment. The product shall render skull CT scans enabling surgeons to study the virtual skull through the removal of bones via virtual burrs. A prototype-driven incremental software development lifecycle model has been adopted for this project. This model is suitable for handling regularly increasing project complexities as well as risks linked with the development of software products. The prototype-driven incremental model focuses on the development requirements of huge, distributed, and multi-supplier integrated real-time systems such as the virtual surgery project.
Most important risks in the project
I believe there are three major risks within this project mostly due to the software development chosen for the project. The first major risk is the delayed implementation of requirements, with the prototype-driven incremental software development lifecycle model is that the development team often seem to postpone project deliverables, hoping that they could be factored in on subsequent prototype increments. This project has several complex requirements which may require time as well as be tough to accomplish as such, the project team may be caught up with time or overwhelmed by activities hence tempted to postpone some unmet requirements to later increments. This is a huge risk as some delayed requirements may be the milestones with which the acceptance and functionality of the entire system depend on. Furthermore, some aspects of the project may require more research to satisfactorily implement them within the project, with a strict timeline, the temptation of postponing such requirements remains very much alive. This, however, should not be the case as it could have a dire effect on the schedule as well as the project budget.
Another major risk is bug propagation through increments where undiscovered increment bugs may be allowed to propagate to the increments that follow. This risk is a possibility as with the limited human resource, strict timeline and limited budget, the project team may not have adequate capacity to satisfactorily identify and fix bugs within each increment only to be identified within later increments when it may be too late. It is obviously logical to fix from bugs identified within each increment during the project lifecycle. This might be as a result of vague testing and process maintenance carried out at the end of every prototype increment. If a bug is not identified within a prototype increment, chances are quite high that the product may be deployed with the bug posing a huge danger to its functioning after deployment. This will require a significant amount of time delegated to bug testing as well as experienced and skilled persons to see the process successfully.
The last major risk is time and crucial required resources underestimation for every increment where a poor estimation of major resources within the budget and timeline for every increment shall possibly lead to underdevelopment in this project. Furthermore, the estimation of time need for every prototype increment delays subsequent increments implementation as more time will be needed to complete predecessor increments prior to moving to the next increments. These delays may certainly lead to unmet timelines within the project schedule. This shoddy time estimation may also lead to time contention in case some extra workload is placed on the developer’s shoulders, or in other cases, some requirements may be neglected.
Characteristics, features, and requirements of the project that will make it a difficult project.
Ideally this is a difficult project on the essence that it revolves around human life, hence errors in the simulation software may lead to errors later in human diagnosis. With requirements, being able to convert CT scans to 3D models is a very difficult concept requiring the integration of various technologies. This process would first require functionality to drill bones from the various images, then label the image before creating an algorithm to carry out the conversion of the images to surface models. This is not just a difficult requirement to implement but also critical to the product performance and may require extra skill to implement within budget and schedule.
Furthermore, since this is a virtual surgery simulation software product, the nature of user interactions that must be supported makes it difficult to develop. This includes features such as cutting of intricate structural components, it also requires accurate model structures and precise simulation in response to all user interactions which might necessitate several code segments to adequately work in unison. Despite the various available software libraries available to this project’s development team, getting real-time rendering and lighting systems as well as physical-based interactions would be quite difficult.
This is definitely a huge project making it quite difficult to select the necessary development tools, the mapping of the user interfaces to the product backend database as well as adding medical logic would require a great deal of developer expertise. Some requirements may also change during the software product lifecycle impacting on the budget as well as the timeline, with such huge products it is quite difficult to efficiently give a sufficient budget and a correct timeline.
In addition, the risks identified earlier also complicate the project in the sense that, handling all the project risks especially given the several increments makes it challenging. It is hard to be keen on every specific detail given that the project is developed by a team. Allocation of duties may also prove difficult as developers may shy off from being assigned to complex activities. Working with a team of developers is in some cases difficult especially if the team is brought together for the first time, the project may also require outside consultation which may take some time before the consultants respond affecting the project timeline. It is also hard to come up with specific requirements for this project as there may be a conflict between what the users want, what can be implemented, and what the project sponsors want.
Alternatives to the prototype-driven software development lifecycle.
There are several software development lifecycles that could still be used in this project though most of them are not as suitable as the one chosen by the development team. One of the substitutes would be the waterfall model where development is divided into phases and every phase completed before moving to the next. This model would majorly be better with regard to scheduling, budgeting as well as system implementation. It is also good at providing support for less experienced developers. It is also ideal for managing products that have already been developed. There is also a risk of bugs propagating to the next phases in this model just as in the case of prototyping-driven incremental model added to the very long model stages.
Comparing it to the prototyping-driven incremental model, it is much costly and only produces a working version of the software after the completion of all the project phases. The prototyping-driven model thus remains a better option with regard to the fact that within such a big project there is a need for flexibility to accommodate any changes during the project life without adversely affecting the project. It is also easy to determine project success by looking at the various prototypes rolled out in each increment. Furthermore, since in this project implementation of the identified requirements is not understood clearly, the waterfall becomes a challenge and not able to be applied effectively in this project.
The spiral software development lifecycle model would be another alternative given its suitability to big projects such as this one of developing a virtual surgery software. The model was first suggested by Boehm in 1988 founded on risks, in which the whole development process is based on foreseen and unforeseen risks.
Ideally, the spiral model has several iterations from which developers can fall back to the previous iteration even after proceeding to the next phase. This is ideal in the contexts of dealing with the earlier elucidated risks. This model is also highly optimized for hardware performance which may leave out major software product essentials. The explicit management of risks in this model distinguishes it from the prototype-driven incremental model, from the fact that this makes sure that project risks are identified early enough in the lifecycle. This is not also as ideal as a prototype-incremental model on the basis that it is hard to choose the development methodologies for every phase and the possibility of not meeting the budget and project schedule. Basing on the information elucidated above, I, therefore, agree with the proposition that the prototyping-driven incremental model was the only suitable process for this project.
Simulation software has been there for a few years that has allowed for development of a few crucial libraries in the medical field, however, the complexity of simulation projects still remains a challenge to most developers. This is definitely an ambitious project faced by some serious risks, but given the development model as well as an experienced team of developers, the project is much more likely to succeed. Measures should nevertheless be enforced to mitigate on the identified risk in order to increase the project success rate.