SophiaPretty
$14/per page/Negotiable
For the SunPass project, what baselines would you define and how would you control them? In other words, we know from our reading that a baseline is, effectively, a snapshot of the project in time. At which point(s) in time would you create a baseline of all of the SunPass project deliverables?
For your project, what baselines would you define and how would you control them?
               In general, baselines seem to be mechanisms forcontrolling, supporting, and documenting changes to software system. They provide a point of reference from which formal changes can occur and also provide a point of reference that can be returned to if the need should arise. Beyond this, I think baselines are useful for tracking the overall progress of a project. That is, project milestones are often marked by the acceptance of a baseline for key work products.
               When considering what baselines should be defined, a good starting pointwould be to look at the major deliverables that are typically associated with the various phases of a software project. For instance, before design can take place, I would think establishing a baseline requirements model would a good idea. Such a baseline would provide a relatively stable foundation on which design efforts could be based. This isn’t to imply that this baseline would be completely static with no further modifications, only that changes would be take place in a controlled manner and approached within the context of the project as a whole.A requirements model as a whole is a somewhat broad deliverable that’s typically composed of a variety of models. I guess whether or not to require individual models, such as data, process, or control, to be defined as separate baselines would be something that would have to be decided.
As the project progresses into the design phase, it would be important to establish baselines for various design elements. Specifically, this could include baselines for specification of system architecture, components, and interfaces. Even though there is almost always room for further refinement, there comes a point when designs must be translated into realized system. Before this translation begins, baseline design specifications should be approved. Coding a component based on preliminary specifications that have yet to be accepted as a baseline would likely prove counterproductive. Changes could still occur frequently and abruptly.  Again, even once baselines are approved, changes could still occur, but they should only occur in a more organized, controlled manner. Beyond design specifications, as code is generated, baseline versions of both individual components and system builds could be required.
Beyond the software itself, there are other aspects of the project that would require baselines. One such would be the testing plan. Baseline test cases along with the specific data to be used during testing could also be established. Requiring such baselines would help to ensure tests were adequately designed and reviewed before testing, or even coding, commenced. Further, they would provide documentation and a point of reference for future testing efforts that might result from changes in the software itself.
Simply defining which baselines are required is somewhat pointless without defining how they will be used. I would think it would be necessary to determine the minimal standards that must be met for each submitted SCI before it could be approved as a baseline. Accepted baselines would need to be stored. Being as the various work products that can be defined as baselines is quite diverse, the first thing to consider would be how they would be stored. These days, there exist specialized databases for storing such project related information. Once baselines have been accept and stored in the project database, they should only be modifiable using defined procedures. According to our text, the timing of a requested change may factor into the level of oversight necessary for implementing change. For instance, project level changes that are requested while the development project is still in progress may still be handled with various degrees of formality. The specific nature of the requested change or the baseline in question may factor into how the change should be addressed. Regardless, there should be procedures in place that govern these various degrees of control. Regardless, it’s important that any changes that do occur at this point are, at the very least, reviewed and documented. Once software has been released and put into operation, all changes must take place via formal change control. Change requests would require a thorough assessment by a change control board. This assessment would include reviewing motivating factors driving the request, determining how related system components would be affected, determining how the change would impact the system as a whole, determining feasibility in term of schedule and cost, and identifying potential risks and benefits associated with the change. Changes would only be implemented if and when the CCB approved the request. Baselines provide a point of reference when changes are to be made. They provide a static jumping off point that can be revisited whenever necessary. As new baselines are accepted, there is still the need to retain earlier versions.  At no point should previous versions be discarded. As new versions are generated, it’s important to maintain detailed documentation of changes that have occurred. This would include what specific changes were made, who made them, when they made them, and how the change affected other system elements. Beyond this, as changes are accepted and implemented, they should be communicated to all relevant parties.  Â
Attachments: