Difference between revisions of "VCM Boston 2005 Session - VistA Software Life Cycle"
From VistApedia
(initial) |
|||
| Line 8: | Line 8: | ||
One fundamental issue taught to computer science and other programmers is to avoid change. The [[Waterfall Software Life Cycle]] model is built upon a system of creating Requirements Documents. | One fundamental issue taught to computer science and other programmers is to avoid change. The [[Waterfall Software Life Cycle]] model is built upon a system of creating Requirements Documents. | ||
| − | The | + | The VistA Software Life Cycle, in contrast does not avoid change, but is designed to manage change. The VA's history of dealing with an integrated system means that the process anage complexity |
=== Lessons of History === | === Lessons of History === | ||
* Don't do big projects. Only small projects are known to succeed. | * Don't do big projects. Only small projects are known to succeed. | ||
* Do specific changes for specific people | * Do specific changes for specific people | ||
Latest revision as of 16:16, 7 March 2007
Overview
VistA is not setup on a "Best of Breed" model. Rather than being built as a patchwork "Frankenstein" model. VistA started using a different paradigm is an integrated model.
The Impact of Change
One fundamental issue taught to computer science and other programmers is to avoid change. The Waterfall Software Life Cycle model is built upon a system of creating Requirements Documents.
The VistA Software Life Cycle, in contrast does not avoid change, but is designed to manage change. The VA's history of dealing with an integrated system means that the process anage complexity
Lessons of History
- Don't do big projects. Only small projects are known to succeed.
- Do specific changes for specific people
