Catálogo de publicaciones - libros

Professor Van Lickman desperately calculated his options, he contem-plated what could have gone wrong, how could he fix it and how long was it going to take? He knew that he didn’t have much time; the launch pack-age was about to cut away the helium balloon that was to carry it to an alti-tude of 100,000 feet. This was the triggering mechanism for igniting the engines of the model rocket on board the launch package. The rocket was the second stage for this mission that was to prove that off the shelf tech-nology could be used to achieve a low Earth orbit (LEO). Once in orbit, the rocket would autonomously assemble various pieces of hardware that were launched using the same approach. Final assembly would yield a fully assembled spacecraft in LEO that would conduct atmospheric studies of the Earth. The approach had never been tried; recent studies had re-vealed that fluctuations in Earth’s gravity could allow for common tech-nologies to escape the pull of the Earth. That was not on the professor’s mind right now, he needed to understand why the vehicle was about to prematurely cut away the helium balloon prior to achieving 100,000 feet. What could have gone wrong?

Even though this book is focused on conveying information to engineers and scientists, I have to include a chapter on management. I have learned from my experiences that the project can not experience success unless management and subject matter experts (SMEs) work together. Numerous times I have fielded questions from the engineers in the trenches like “Why in the world does management want to know that?” It would be much simpler if management only communicated better. It would be just as simple if the engineers in the field fully understood and appreciated ex-actly what it took to lead a project in its entirety. The data that manage-ment uses to develop plans and control the project comes from the SMEs, as such they should fully understand or at least have an idea as to how that data is going to be used. That is why I have included a chapter on man-agement.

The Verification and Validation (V&V) life-cycle is easily understood if you are familiar with a traditional software engineering life cycle. A ge-neric model of the V&V life-cycle is depicted in Figure 3.1. The intent of the figure is to put the V&V life-cycle in perspective with a traditional software engineering life-cycle.

Without a systems approach to performing verification and validation (V&V) all you can do is draw general conclusions about particular stages of a system’s life. Not only are you constrained to individual phases of the life-cycle you can only verify that the software is an adequate representa-tion of the documented behavior. There is another dimension that needs to be considered and that is validation. Is the right behavior evident in the system? This focal point looks beyond the software as well as the docu-mented behavior and is often absent during development. The source code may be built adequately but if it doesn’t operate as the user needs it to then what’s the point in building the system? I am suggesting two things. First I believe that there is a correlation between each set of results that V&V produces during the different phases of the life-cycle. Second, to deter-mine whether the software will meet the needs of the user and its intended application then V&V needs to take into consideration everything that can affect the software.