Mood's In Control
The trends of increasing technical complexity of the systems, coupled with the need for repeatable and predictable process methodologies, have driven System Developers to establish system development models or software development life cycle models. As what I have learned about the system development models, it is an abstract representation of a process. Also, it presents a description of a process from some particular perspective. System development model specifies how activities of development process are organized in the total system development effort.
Now, let me discuss some of the system development models which are commonly used as to what I have researched, read, and learned.
THE WATERFALL MODEL
To start, Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases. This is the classic SDLC model, with a linear and sequential method that has goals for each development phase. The waterfall model simplifies task scheduling, because there are no iterative or overlapping steps. One drawback of the waterfall is that it does not allow for much revision. In waterfall model phases, one phase has to be complete before moving on to the next phase.
With the waterfall model, the activities performed in a software development project are requirements analysis, project planning, system design, detailed design, coding and unit testing, system integration and testing. Linear ordering of activities has some important consequences. First, to clearly identify the end of a phase and beginning of the others. Some certification mechanism has to be employed at the end of each phase. This is usually done by some verification and validation. Validation means confirming the output of a phase is consistent with its input (which is the output of the previous phase) and that the output of the phase is consistent with overall requirements of the system.
For a successful project resulting in a successful product, all phases listed in the waterfall model must be performed anyway. Any different ordering of the phases will result in a less successful software product.
During our Software Engineering I, system development models were also discussed such as this waterfall model. In that time, I have found out some problems regarding this kind of model. First, inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Second, few business systems have stable requirements. Third, it is appropriate only when the requirements are well understood and changes will be fairly limited during the design process.
The advantages of this model is that it is easy to understand and easy to use, it provides structures to inexperienced staff, sets requirements stability, and is good for management control such as plan, staff and track. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.
The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model. There are also limitations in using this model. All requirements must be known upfront, system can be frozen before the design begins, and little opportunity for customer to preview the system (until it may be too late).
This model best applies for large systems engineering projects where a system is developed at several sites.
THE PROTOTYPING MODEL
A prototype is a working model that is functionally equivalent to a component of the product.
In many instances the client only has a general view of what is expected from the software product. In such a scenario where there is an absence of detailed information regarding the input to the system, the processing needs and the output requirements, the prototyping model may be employed.
This model reflects an attempt to increase the flexibility of the development process by allowing the client to interact and experiment with a working representation of the product. The developmental process only continues once the client is satisfied with the functioning of the prototype. At that stage the developer determines the specifications of the client’s real needs.
In this model, a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed.
As for the advantages of his model, let me indicate some: Customers can “see” the system requirements as they are being gathered, More accurate end product, Unexpected requirements accommodated, Allows for flexible design and development, and Lower overall development costs when requirements change frequently.
Same with the waterfall model, prototyping has limitations too. Prototyping can lead to false expectations. Prototyping can lead to poorly designed systems.
For any company engaged in rapid prototyping and manufacturing or functional testing, prototype models are crucial for troubleshooting potential problems in the design process. Prototype models allow product designers and engineers to quickly test the parts of their designs that are most likely to have problems, solve those problems, and then build the complete design. While prototype models are by definition cheap to produce, it can be expensive to build multiple iterations during therapid prototype tooling process, and turnaround times can be too lengthy for today's tight deadlines.
With a knowledge of this kind of model, I couldn’t keep asking myself on to what are the best projects to use prototyping. It has been argued that prototyping, in some form or another, should be used all the time. However, prototyping is most beneficial in systems that will have many interactions with the users.
It has been found that prototyping is very effective in the analysis and design of on-line systems, especially for transaction processing, where the use of screen dialogs is much more in evidence. The greater the interaction between the computer and the user, the greater the benefit is that can be obtained from building a quick system and letting the user play with it.
Systems with little user interaction, such as batch processing or systems that mostly do calculations, benefit little from prototyping. Sometimes, the coding needed to perform the system functions may be too intensive and the potential gains that prototyping could provide are too small.
Prototyping is especially good for designing good human-computer interfaces. "One of the most productive uses of rapid prototyping to date has been as a tool for iterative user requirements engineering and human-computer interface design."
THE SPIRAL MODEL
The spiral model was defined by Barry Boehm in his 1988 article A Spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.
The spiral model, also known as the spiral lifecycle model, is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive, and complicated projects.
In Spiral development, process is represented as a spiral rather than as a sequence of activities with backtracking, each loop in the spiral represents a phase in the process, no fixed phases such as specification or design - loops in the spiral are chosen depending on what is required, and risks are explicitly assessed and resolved throughout the process.
About the model’s sectors, there are these, Objective setting in which specific objectives for the phase are identified, Risk assessment and reduction in which risks are assessed and activities put in place to reduce the key risks, Development and validation in which a development model for the system is chosen which can be any of the generic models, and Planning in which the project is reviewed and the next phase of the spiral is planned.
There are many advantages to using the spiral model in software development. Spiral model Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier. It is more able to cope with the (nearly inevitable) changes that software development generally entails. Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.
Using, or perhaps misusing, spiral modeling can also have disadvantages. Highly customized limiting re-usability, Applied differently for each application, Risk of not meeting budget or schedule, and Risk of not meeting budget or schedule.
With the support of my learnings in our Software Engineering I and with the aid of my references, I can now identify the different system development models. I learned that the systems development life cycle model was developed as a structured approach to information system development that guides all the processes involved from an initial feasibility study through to maintenance of the finished application. SDLC models take a variety of approaches to development and each process model follows a particular life cycle in order to ensure success in process of software development.
References:
http://onestoptesting.com
Now, let me discuss some of the system development models which are commonly used as to what I have researched, read, and learned.
THE WATERFALL MODELTo start, Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate process phases. This is the classic SDLC model, with a linear and sequential method that has goals for each development phase. The waterfall model simplifies task scheduling, because there are no iterative or overlapping steps. One drawback of the waterfall is that it does not allow for much revision. In waterfall model phases, one phase has to be complete before moving on to the next phase.
With the waterfall model, the activities performed in a software development project are requirements analysis, project planning, system design, detailed design, coding and unit testing, system integration and testing. Linear ordering of activities has some important consequences. First, to clearly identify the end of a phase and beginning of the others. Some certification mechanism has to be employed at the end of each phase. This is usually done by some verification and validation. Validation means confirming the output of a phase is consistent with its input (which is the output of the previous phase) and that the output of the phase is consistent with overall requirements of the system.
For a successful project resulting in a successful product, all phases listed in the waterfall model must be performed anyway. Any different ordering of the phases will result in a less successful software product.
During our Software Engineering I, system development models were also discussed such as this waterfall model. In that time, I have found out some problems regarding this kind of model. First, inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. Second, few business systems have stable requirements. Third, it is appropriate only when the requirements are well understood and changes will be fairly limited during the design process.
The advantages of this model is that it is easy to understand and easy to use, it provides structures to inexperienced staff, sets requirements stability, and is good for management control such as plan, staff and track. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.
The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model. There are also limitations in using this model. All requirements must be known upfront, system can be frozen before the design begins, and little opportunity for customer to preview the system (until it may be too late).
This model best applies for large systems engineering projects where a system is developed at several sites.
THE PROTOTYPING MODELA prototype is a working model that is functionally equivalent to a component of the product.
In many instances the client only has a general view of what is expected from the software product. In such a scenario where there is an absence of detailed information regarding the input to the system, the processing needs and the output requirements, the prototyping model may be employed.
This model reflects an attempt to increase the flexibility of the development process by allowing the client to interact and experiment with a working representation of the product. The developmental process only continues once the client is satisfied with the functioning of the prototype. At that stage the developer determines the specifications of the client’s real needs.
In this model, a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed.
As for the advantages of his model, let me indicate some: Customers can “see” the system requirements as they are being gathered, More accurate end product, Unexpected requirements accommodated, Allows for flexible design and development, and Lower overall development costs when requirements change frequently.
Same with the waterfall model, prototyping has limitations too. Prototyping can lead to false expectations. Prototyping can lead to poorly designed systems.
For any company engaged in rapid prototyping and manufacturing or functional testing, prototype models are crucial for troubleshooting potential problems in the design process. Prototype models allow product designers and engineers to quickly test the parts of their designs that are most likely to have problems, solve those problems, and then build the complete design. While prototype models are by definition cheap to produce, it can be expensive to build multiple iterations during therapid prototype tooling process, and turnaround times can be too lengthy for today's tight deadlines.
With a knowledge of this kind of model, I couldn’t keep asking myself on to what are the best projects to use prototyping. It has been argued that prototyping, in some form or another, should be used all the time. However, prototyping is most beneficial in systems that will have many interactions with the users.
It has been found that prototyping is very effective in the analysis and design of on-line systems, especially for transaction processing, where the use of screen dialogs is much more in evidence. The greater the interaction between the computer and the user, the greater the benefit is that can be obtained from building a quick system and letting the user play with it.
Systems with little user interaction, such as batch processing or systems that mostly do calculations, benefit little from prototyping. Sometimes, the coding needed to perform the system functions may be too intensive and the potential gains that prototyping could provide are too small.
Prototyping is especially good for designing good human-computer interfaces. "One of the most productive uses of rapid prototyping to date has been as a tool for iterative user requirements engineering and human-computer interface design."
THE SPIRAL MODELThe spiral model was defined by Barry Boehm in his 1988 article A Spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.
The spiral model, also known as the spiral lifecycle model, is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive, and complicated projects.
In Spiral development, process is represented as a spiral rather than as a sequence of activities with backtracking, each loop in the spiral represents a phase in the process, no fixed phases such as specification or design - loops in the spiral are chosen depending on what is required, and risks are explicitly assessed and resolved throughout the process.
About the model’s sectors, there are these, Objective setting in which specific objectives for the phase are identified, Risk assessment and reduction in which risks are assessed and activities put in place to reduce the key risks, Development and validation in which a development model for the system is chosen which can be any of the generic models, and Planning in which the project is reviewed and the next phase of the spiral is planned.
There are many advantages to using the spiral model in software development. Spiral model Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier. It is more able to cope with the (nearly inevitable) changes that software development generally entails. Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.
Using, or perhaps misusing, spiral modeling can also have disadvantages. Highly customized limiting re-usability, Applied differently for each application, Risk of not meeting budget or schedule, and Risk of not meeting budget or schedule.
With the support of my learnings in our Software Engineering I and with the aid of my references, I can now identify the different system development models. I learned that the systems development life cycle model was developed as a structured approach to information system development that guides all the processes involved from an initial feasibility study through to maintenance of the finished application. SDLC models take a variety of approaches to development and each process model follows a particular life cycle in order to ensure success in process of software development.
References:
http://onestoptesting.com
