Consider the following dialogue between a systems professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:
Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved.
Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.
Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.
Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.
Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved.
Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.
Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.
Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.
Required:
a.Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.
In this scenario both side had their own views about the systems analysis phase, in Juan, he wanted to examine first the old system, analyze the system and reviewing the documents, observing the workers performances, so that they can determine what aspects they should be preserved. In this situation, Juan wanted again to apply the previous method that he generated, but suddenly, Pedro differ the process because they have already tried that method but they didn’t succeed because they observed that after the process they cannot provide the system they promise to the client. There’s a problem they encountered and they cannot offered a perfect system that will apply to the client. In other side, Pedro tried a new method to generate a new system that has a perfect quality, he stated that they first started with a list of their requirements determined what were the system should be needed and required to their department, spending a long time to studies the process and give a method that will create a good system.
For me, I sympathized with Juan, although they have been through those types of projects before and at the end they didn’t generated the system required that they promises. But for me, Juan was right as a system analyst they should considered first what are the negative sides they made and after determining the problem, give best solutions and accurate the right, in that way you could be determined the lessons you did and resolve it and generate best solutions that could be created a perfect system. Though they were failed but still there’s chance to exact the bad side and decide a better solution to the system.
For me, I sympathized with Juan, although they have been through those types of projects before and at the end they didn’t generated the system required that they promises. But for me, Juan was right as a system analyst they should considered first what are the negative sides they made and after determining the problem, give best solutions and accurate the right, in that way you could be determined the lessons you did and resolve it and generate best solutions that could be created a perfect system. Though they were failed but still there’s chance to exact the bad side and decide a better solution to the system.
b.What method would you propose they take? Why?
For me, I would propose a Waterfall Life Cycle Model because this is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.
According to my research, the Waterfall Life Cycle Model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and Maintenance. The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.
The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce,[1] although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.
According to my research, the Waterfall Life Cycle Model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and Maintenance. The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.
The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce,[1] although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.
Advantages
• Simple and easy to use.
• Each phase has specific deliverables.
• Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.
• Works well for small projects where requirements are easily understood.
• Testing is inherent to every phase of the waterfall model
• It is an enforced disciplined approach
• It is documentation driven, that is, documentation is produced at every stage
Disadvantages
• Very rigid, like the waterfall model.
• Little flexibility and adjusting scope is difficult and expensive.
• Software is developed during the implementation phase, so no early prototypes of the software are produced.
• Model doesn’t provide a clear path for problems found during testing phases.
• Testing is inherent to every phase of the waterfall model
• It is an enforced disciplined approach
• It is documentation driven, that is, documentation is produced at every stage
Sources:http://en.wikipedia.org/wiki/Waterfall_model
http://toostep.com/trends/types-of-sdlc-models
0 comments:
Post a Comment