Identify and discuss at least 3 systems development models .. discuss each phases ... (at least 3000 words)
One thing that never changes in the information systems field is that things are always changing. New tools and techniques are continually emerging and system developers are always looking for new and better ways to work. There are numerous system development methodologies that the system developers might adapt from each techniques and life cycles when appropriate. There are various methods and techniques exercised to direct the life cycle of a software development project and most real world models are customized adaption of the basic and standard models. Building an information system for an organization would be very effective in supporting business process objectives. System development process models are employed by the developers to direct the project’s life cycle and would ensure that they would be able to develop a cost-effective and quality systems. System Development life cycle is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.
Whenever I search about system development models, I always encounter software life cycle models. As what I have read, software life cycle models describe phases of the software cycle and the order in which those phase are executed. There are different models and the company chose and adopts their own model. But in general, usually, the basic of every model is that it requires some important phases. It includes the requirements, design, implementation and testing. Each phase produces deliverables required by the next phase in the life cycle. As what I have understood, all the requirements gathered are then translated into design. On the other hand, the coding part is already produced during the implementation phase that was actually obsessed by the design. Testing verifies the deliverable of the implementation phase against requirements.
There are also some activities that were performed in system development. Typically, include are the following: System conceptualization, Systems requirements and benefits analysis, Project adoption and project scoping, System design, Specification of software requirements, Architectural design, Detailed design, Unit development, Software integration and testing, System integration and testing, Installation at site, Site testing and acceptance, Training and documentation, Implementation, and Maintenance.
As what I have read in one of my resources which is an article entitled, A Survey of System Development Process Models (CTG.MFA - 003) and this paper was based upon the work supported in part by the National Historical Publications and Records Commission under Grant No. 96023. It was mentioned there that most system development Process models in use in the present have evolved from three primary approaches. These are Ad-hoc Development, Waterfall Model, and the Iterative Process.
Ad-hoc Development
The Software Engineering Institute at Carnegie Mellon University states that with the use of Ad-hoc Process Model all the process capability is unpredictable because the software process is constantly changed or modified as the work progresses. As of the present time, there are still organizations that are practicing Ad-hoc Development Process Model either for the whole development or just a part of it. With Ad-hoc Development, it focuses on the performance which depends on the capabilities of the person and differs with their individual skills, knowledge, and motivations. In Ad-hoc Development, the performance of the software processes can be predicted only by an individual rather than the capability of an organization. The success of the projects is through the stout effort of a dedicated team. Some individual software projects produce excellent results.
Waterfall Model
The Waterfall Model is the earliest method of structured system development. This is the most common and classic of life cycle models. In recent years, it has been under criticize because it is too rigid and unrealistic when it comes to instantly meeting customer’s needs but still the Waterfall Model has been widely used. It is very simple to understand and use.
The Waterfall Model consists of the following steps:
•System Conceptualization.
System Conceptualization refers to the consideration of all aspects of the targeted business function or process, with the goals of determining how each of those aspects relates with one another, and which aspects will be incorporated into the system.
•Systems Analysis.
This step refers to the gathering of system requirements, with the goal of determining how these requirements will be accommodated in the system. Extensive communication between the customer and the developer is essential.
•System Design.
Once the requirements have been collected and analyzed, it is necessary to identify in detail how the system will be constructed to perform necessary tasks. More specifically, the System Design phase is focused on the data requirements (what information will be processed in the system?), the software construction (how will the application be constructed?), and the interface construction (what will the system look like? What standards will be followed?).
•Coding.
Also known as programming, this step involves the creation of the system software. Requirements and systems specifications from the System Design step are translated into machine readable computer code.
•Testing.
As the software is created and added to the developing system, testing is performed to ensure that it is working correctly and efficiently. Testing is generally focused on two areas: internal efficiency and external effectiveness. The goal of external effectiveness testing is to verify that the software is functioning according to system design, and that it is performing all necessary functions or sub-functions. The goal of internal testing is to make sure that the computer code is efficient, standardized, and well documented. Testing can be a labor-intensive process, due to its iterative nature.
Here is an Illustration of a waterfall model:
In a waterfall model, each phase must be completed in its whole before it can proceed and begin with the next phase. And every end of each phase, a recap must be done to identify if a certain project is on the right path and to analyze whether to continue or discard the project. Each phase are processed and completed one at a time. This type of model works well for smaller projects wherein all the requirements are very well understood.
There are also disadvantages in using a waterfall model: Adjusting scope during the life cycle can kill a project, No working software is produced until late during the life cycle, High amounts of risk and uncertainty, Poor model for complex and object-oriented projects, Poor model for long and ongoing projects, and Poor model where requirements are at a moderate to high risk of changing.
Iterative Development
Because of the seen problems with the Waterfall Model, system developers are looking for a new method of developing systems in which it could produce a quick output, requires lesser up-front information, and could give a greater flexibility. In Iterative Development, the project is divided into small parts. With this model, the developers are allowed to establish and demonstrate the results ahead of time while the process is ongoing and they obtain comments from its end-users. Often times, iteration is actually similar with a mini-waterfall process wherein the comments and feedbacks from the end-users from each phase will provide vital information for the accomplishment of the next phase.
Here is an illustration of an Iterative Development:
There are actually various system development models. Some are variations and evolved from the iterative and incremental approach or even in the waterfall model. I’ll be discussing some that are also used by the organizations.
Prototyping Model
Sometimes, in developing a system, it is difficult to know all the requirements needed at the beginning of a project that is why prototyping model was developed. There are some customers knows all the objectives that they want their system to be but they do not know what are detailed features and capabilities needed for their system. When the developer used a prototyping model, they build a simplified version of their proposed system and present it unto their clients as part of the development process. The clients will give then their comments and reaction which will be additional information for the system requirements.
There are a few different approaches that may be followed when using the Prototyping Model: Creation of the major user interfaces without any substantive coding in the background in order to give the users a “feel” for what the system will look like,Development of an abbreviated version of the system that performs a limited subset of functions; development of a paper system (depicting proposed screens, reports, relationships etc.), or Use of an existing system or system components to demonstrate some functions that will be included in the developed system.
On my source of information, it elaborate some steps that comprises prototyping. They are:
•Requirements Definition/Collection.
Similar to the Conceptualization phase of the Waterfall Model, but not as comprehensive. The information collected is usually limited to a subset of the complete system requirements.
•Design.
Once the initial layer of requirements information is collected, or new information is gathered, it is rapidly integrated into a new or existing design so that it may be folded into the prototype.
•Prototype Creation/Modification.
The information from the design is rapidly rolled into a prototype. This may mean the creation/modification of paper information, new coding, or modifications to existing coding.
•Assessment.
The prototype is presented to the customer for review. Comments and suggestions are collected from the customer.
•Prototype Refinement.
Information collected from the customer is digested and the prototype is refined. The developer revises the prototype to make it more effective and efficient.
•System Implementation.
In most cases, the system is rewritten once requirements are understood. Sometimes, the Iterative process eventually produces a working system that can be the cornserstone for the fully functional system.
Every model has its criticism. For prototyping model, there are two possible advantages when using it. First, Prototyping can lead to false expectations. And the other one is that Prototyping can lead to poorly designed systems.
Spiral Model
The Spiral Model was designed to include the best features from the Waterfall and Prototyping Models, and also to introduce a new module which is the risk assessment. The Spiral Model is similar to the incremental model, with more emphasis on the risk analysis. The word “spiral” is used to describe the process that is pursued as the development of the system takes place. Now, how does the best features of Waterfall and Prototyping models include in the Spiral model? In Spiral Model, similar with the Prototyping, they also develop an initial version of the system, and afterwards it was modified repetitively based on the suggestions, comments and criticism given by the costumer as they evaluate the system. However, progress of each version of the proposed system is carefully designed through the use of the steps that were involved in Waterfall Model.
Here is an illustration of a Spiral Life Cycle Model for System Development Process Models:
The Spiral Model has four phases: Planning, Risk Analysis, Engineering and Evaluation. In a software project, it passes repeatedly through the different phases in iterations. The iteration starts in the center. From the baseline spiral, which is part of the planning phase, the requirements needed for the development of the system are gathered and also the possible risks are assessed. The requirements are always gathered during the planning phase. Another phase is the risk analysis. In this phase a process is assumed to identify all the risk and the alternate solutions. And in every end of the risk analysis phase, a prototype is then produced. In the engineering phase software is then produced. At every end of the engineering phase there is always a testing that should be implemented. The evaluation phase focuses on the costumer. On the last phase, it allows the costumers to evaluate the output of the project and give there feedback on it before the developer will continue the next spiral.
I have found another figure of a spiral model. This is partly different from the other illustration that I gave earlier.
If we would try to observe well the Spiral Model is made to follow some steps:
•Project Objectives.
It is similar to the system conception phase of the Waterfall Model. Objectives are determined, possible obstacles are identified and alternative approaches are weighed.
•Risk Assessment.
Possible alternatives are examined by the developer, and associated risks/problems are identified. Resolutions of the risks are evaluated and weighed in the consideration of project continuation. Sometimes prototyping is used to clarify needs.
•Engineering & Production.
Detailed requirements are determined and the software piece is developed.
•Planning and Management.
The customer is given an opportunity to analyze the results of the version created in the Engineering step and to offer feedback to the developer.
Risk assessment is always included as a step in the development process as a means of evaluating each type of the system to determine whether development should continue or discard. The decisions will be on the costumer’s hand. If ever the client decides that there are great risk that would be identified, there is a possibility that the project would be stopped.
The advantages of using spiral model are: High amount of risk analysis, Good for large and mission-critical projects, and Software is produced early in the software life cycle. But on the other hand, there are also drawbacks that we should consider in using this type of model. Include on its shortcomings are: Can be a costly model to use, Risk analysis requires highly specific expertise, Project’s success is highly dependent on the risk analysis phase, and it does not work well for smaller projects.
V-Shaped Model
The V-Shaped model is just like the waterfall model. It is a sequential path of execution of processes. The same with the waterfall model, each phase of the V-Shaped model must be done and completed before the next phase could begin. In this model, testing is more emphasized and implemented always in this type of model.
Here is an illustration of a V-Shaped Life cycle model.
If we would be very observant, the testing procedures are developed earlier in the life cycle before the coding or programming is done. And during each phases there is a preceding implementation. The requirements are gathered similar with the Waterfall Model. A system test plan is created before the development started. The test plan focuses on meeting the functionality specified in the requirements gathering. The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together. The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well. The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.
There are also countable advantages in using V-Shaped Life Cycle Model. It is simple and easy to use similar with the waterfall model. Each phase has specific deliverables. There is a higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. And another advantage of using this model is that it works well for small projects where requirements are easily understood. There are also shortcomings that you could encounter in using this model. One disadvantage is the same with the disadvantage of the Waterfall; V-shaped is very rigid. It has little flexibility and adjusting scope is difficult and expensive. Software is developed during the implementation phase, therefore there are no early prototypes of the software are produced. Model doesn’t provide a clear path for problems found during testing phases.
Reuse Model
The basic principle in using the reuse model is that systems should be built using existing components. The reuse model is definitely suited and appropriate to object-oriented computing environments. As of today’s system development industry, Object-oriented environments have become one of the premier technologies.
Within the Reuse Model, libraries of software modules are maintained that can be copied for use
in any system. These components are of two types: procedural modules and database modules.
When building a new system, the developer will “borrow” a copy of a module from the system
library and then plug it into a function or procedure. If the needed module is not available, the
developer will build it, and store a copy in the system library for future usage. If the modules are
well engineered, the developer with minimal changes can implement them. A general criticism of the Reuse Model is that it is limited for use in object-oriented development environments. Although this environment is rapidly growing in popularity, it is currently used in only a minority of system development applications.
The Reuse Model consists of the following steps:
• Definition of Requirements.
Initial system requirements are collected. These requirements are usually a subset of complete system requirements.
• Definition of Objects.
The objects, which can support the necessary system components, are identified.
• Collection of Objects.
The system libraries are scanned to determine whether or not the needed objects are available. Copies of the needed objects are downloaded from the system.
• Creation of Customized Objects.
Objects that have been identified as needed, but that are not available in the library are created.
• Prototype Assembly.
A prototype version of the system is created and/or modified using the necessary objects.
• Prototype Evaluation.
The prototype is evaluated to determine if it adequately addresses customer needs and requirements.
• Requirements Refinement.
Requirements are further refined as a more detailed version of the prototype is created.
• Objects Refinement.
Objects are refined to reflect the changes in the requirements.
There may be various models and as our fast changing environment grows, more and more models and techniques would be developed and implemented and even used by the developers to make their work well. It’s really on the developer and the organizations hand on what model would they use. The capability and assurance of success in every model depend on how big or how small the project is. Every model has its criteria on what type of project it is much useful. Mostly, developers would take parts and procedures from those various process models and then integrate it to support system development. The evolution of the system development process models has replicated the changing needs of the costumers.
References:
http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx
Posted 07-13-2005 8:13 AM by Raymond Lewallen
http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf
One thing that never changes in the information systems field is that things are always changing. New tools and techniques are continually emerging and system developers are always looking for new and better ways to work. There are numerous system development methodologies that the system developers might adapt from each techniques and life cycles when appropriate. There are various methods and techniques exercised to direct the life cycle of a software development project and most real world models are customized adaption of the basic and standard models. Building an information system for an organization would be very effective in supporting business process objectives. System development process models are employed by the developers to direct the project’s life cycle and would ensure that they would be able to develop a cost-effective and quality systems. System Development life cycle is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.
Whenever I search about system development models, I always encounter software life cycle models. As what I have read, software life cycle models describe phases of the software cycle and the order in which those phase are executed. There are different models and the company chose and adopts their own model. But in general, usually, the basic of every model is that it requires some important phases. It includes the requirements, design, implementation and testing. Each phase produces deliverables required by the next phase in the life cycle. As what I have understood, all the requirements gathered are then translated into design. On the other hand, the coding part is already produced during the implementation phase that was actually obsessed by the design. Testing verifies the deliverable of the implementation phase against requirements.
There are also some activities that were performed in system development. Typically, include are the following: System conceptualization, Systems requirements and benefits analysis, Project adoption and project scoping, System design, Specification of software requirements, Architectural design, Detailed design, Unit development, Software integration and testing, System integration and testing, Installation at site, Site testing and acceptance, Training and documentation, Implementation, and Maintenance.
As what I have read in one of my resources which is an article entitled, A Survey of System Development Process Models (CTG.MFA - 003) and this paper was based upon the work supported in part by the National Historical Publications and Records Commission under Grant No. 96023. It was mentioned there that most system development Process models in use in the present have evolved from three primary approaches. These are Ad-hoc Development, Waterfall Model, and the Iterative Process.
Ad-hoc Development
The Software Engineering Institute at Carnegie Mellon University states that with the use of Ad-hoc Process Model all the process capability is unpredictable because the software process is constantly changed or modified as the work progresses. As of the present time, there are still organizations that are practicing Ad-hoc Development Process Model either for the whole development or just a part of it. With Ad-hoc Development, it focuses on the performance which depends on the capabilities of the person and differs with their individual skills, knowledge, and motivations. In Ad-hoc Development, the performance of the software processes can be predicted only by an individual rather than the capability of an organization. The success of the projects is through the stout effort of a dedicated team. Some individual software projects produce excellent results.
Waterfall Model
The Waterfall Model is the earliest method of structured system development. This is the most common and classic of life cycle models. In recent years, it has been under criticize because it is too rigid and unrealistic when it comes to instantly meeting customer’s needs but still the Waterfall Model has been widely used. It is very simple to understand and use.
The Waterfall Model consists of the following steps:
•System Conceptualization.
System Conceptualization refers to the consideration of all aspects of the targeted business function or process, with the goals of determining how each of those aspects relates with one another, and which aspects will be incorporated into the system.
•Systems Analysis.
This step refers to the gathering of system requirements, with the goal of determining how these requirements will be accommodated in the system. Extensive communication between the customer and the developer is essential.
•System Design.
Once the requirements have been collected and analyzed, it is necessary to identify in detail how the system will be constructed to perform necessary tasks. More specifically, the System Design phase is focused on the data requirements (what information will be processed in the system?), the software construction (how will the application be constructed?), and the interface construction (what will the system look like? What standards will be followed?).
•Coding.
Also known as programming, this step involves the creation of the system software. Requirements and systems specifications from the System Design step are translated into machine readable computer code.
•Testing.
As the software is created and added to the developing system, testing is performed to ensure that it is working correctly and efficiently. Testing is generally focused on two areas: internal efficiency and external effectiveness. The goal of external effectiveness testing is to verify that the software is functioning according to system design, and that it is performing all necessary functions or sub-functions. The goal of internal testing is to make sure that the computer code is efficient, standardized, and well documented. Testing can be a labor-intensive process, due to its iterative nature.
Here is an Illustration of a waterfall model:
In a waterfall model, each phase must be completed in its whole before it can proceed and begin with the next phase. And every end of each phase, a recap must be done to identify if a certain project is on the right path and to analyze whether to continue or discard the project. Each phase are processed and completed one at a time. This type of model works well for smaller projects wherein all the requirements are very well understood.
There are also disadvantages in using a waterfall model: Adjusting scope during the life cycle can kill a project, No working software is produced until late during the life cycle, High amounts of risk and uncertainty, Poor model for complex and object-oriented projects, Poor model for long and ongoing projects, and Poor model where requirements are at a moderate to high risk of changing.
Iterative Development
Because of the seen problems with the Waterfall Model, system developers are looking for a new method of developing systems in which it could produce a quick output, requires lesser up-front information, and could give a greater flexibility. In Iterative Development, the project is divided into small parts. With this model, the developers are allowed to establish and demonstrate the results ahead of time while the process is ongoing and they obtain comments from its end-users. Often times, iteration is actually similar with a mini-waterfall process wherein the comments and feedbacks from the end-users from each phase will provide vital information for the accomplishment of the next phase.
Here is an illustration of an Iterative Development:
There are actually various system development models. Some are variations and evolved from the iterative and incremental approach or even in the waterfall model. I’ll be discussing some that are also used by the organizations.
Prototyping Model
Sometimes, in developing a system, it is difficult to know all the requirements needed at the beginning of a project that is why prototyping model was developed. There are some customers knows all the objectives that they want their system to be but they do not know what are detailed features and capabilities needed for their system. When the developer used a prototyping model, they build a simplified version of their proposed system and present it unto their clients as part of the development process. The clients will give then their comments and reaction which will be additional information for the system requirements.
There are a few different approaches that may be followed when using the Prototyping Model: Creation of the major user interfaces without any substantive coding in the background in order to give the users a “feel” for what the system will look like,Development of an abbreviated version of the system that performs a limited subset of functions; development of a paper system (depicting proposed screens, reports, relationships etc.), or Use of an existing system or system components to demonstrate some functions that will be included in the developed system.
On my source of information, it elaborate some steps that comprises prototyping. They are:
•Requirements Definition/Collection.
Similar to the Conceptualization phase of the Waterfall Model, but not as comprehensive. The information collected is usually limited to a subset of the complete system requirements.
•Design.
Once the initial layer of requirements information is collected, or new information is gathered, it is rapidly integrated into a new or existing design so that it may be folded into the prototype.
•Prototype Creation/Modification.
The information from the design is rapidly rolled into a prototype. This may mean the creation/modification of paper information, new coding, or modifications to existing coding.
•Assessment.
The prototype is presented to the customer for review. Comments and suggestions are collected from the customer.
•Prototype Refinement.
Information collected from the customer is digested and the prototype is refined. The developer revises the prototype to make it more effective and efficient.
•System Implementation.
In most cases, the system is rewritten once requirements are understood. Sometimes, the Iterative process eventually produces a working system that can be the cornserstone for the fully functional system.
Every model has its criticism. For prototyping model, there are two possible advantages when using it. First, Prototyping can lead to false expectations. And the other one is that Prototyping can lead to poorly designed systems.
Spiral Model
The Spiral Model was designed to include the best features from the Waterfall and Prototyping Models, and also to introduce a new module which is the risk assessment. The Spiral Model is similar to the incremental model, with more emphasis on the risk analysis. The word “spiral” is used to describe the process that is pursued as the development of the system takes place. Now, how does the best features of Waterfall and Prototyping models include in the Spiral model? In Spiral Model, similar with the Prototyping, they also develop an initial version of the system, and afterwards it was modified repetitively based on the suggestions, comments and criticism given by the costumer as they evaluate the system. However, progress of each version of the proposed system is carefully designed through the use of the steps that were involved in Waterfall Model.
Here is an illustration of a Spiral Life Cycle Model for System Development Process Models:
The Spiral Model has four phases: Planning, Risk Analysis, Engineering and Evaluation. In a software project, it passes repeatedly through the different phases in iterations. The iteration starts in the center. From the baseline spiral, which is part of the planning phase, the requirements needed for the development of the system are gathered and also the possible risks are assessed. The requirements are always gathered during the planning phase. Another phase is the risk analysis. In this phase a process is assumed to identify all the risk and the alternate solutions. And in every end of the risk analysis phase, a prototype is then produced. In the engineering phase software is then produced. At every end of the engineering phase there is always a testing that should be implemented. The evaluation phase focuses on the costumer. On the last phase, it allows the costumers to evaluate the output of the project and give there feedback on it before the developer will continue the next spiral.
I have found another figure of a spiral model. This is partly different from the other illustration that I gave earlier.
If we would try to observe well the Spiral Model is made to follow some steps:
•Project Objectives.
It is similar to the system conception phase of the Waterfall Model. Objectives are determined, possible obstacles are identified and alternative approaches are weighed.
•Risk Assessment.
Possible alternatives are examined by the developer, and associated risks/problems are identified. Resolutions of the risks are evaluated and weighed in the consideration of project continuation. Sometimes prototyping is used to clarify needs.
•Engineering & Production.
Detailed requirements are determined and the software piece is developed.
•Planning and Management.
The customer is given an opportunity to analyze the results of the version created in the Engineering step and to offer feedback to the developer.
Risk assessment is always included as a step in the development process as a means of evaluating each type of the system to determine whether development should continue or discard. The decisions will be on the costumer’s hand. If ever the client decides that there are great risk that would be identified, there is a possibility that the project would be stopped.
The advantages of using spiral model are: High amount of risk analysis, Good for large and mission-critical projects, and Software is produced early in the software life cycle. But on the other hand, there are also drawbacks that we should consider in using this type of model. Include on its shortcomings are: Can be a costly model to use, Risk analysis requires highly specific expertise, Project’s success is highly dependent on the risk analysis phase, and it does not work well for smaller projects.
V-Shaped Model
The V-Shaped model is just like the waterfall model. It is a sequential path of execution of processes. The same with the waterfall model, each phase of the V-Shaped model must be done and completed before the next phase could begin. In this model, testing is more emphasized and implemented always in this type of model.
Here is an illustration of a V-Shaped Life cycle model.
If we would be very observant, the testing procedures are developed earlier in the life cycle before the coding or programming is done. And during each phases there is a preceding implementation. The requirements are gathered similar with the Waterfall Model. A system test plan is created before the development started. The test plan focuses on meeting the functionality specified in the requirements gathering. The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together. The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well. The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.
There are also countable advantages in using V-Shaped Life Cycle Model. It is simple and easy to use similar with the waterfall model. Each phase has specific deliverables. There is a higher chance of success over the waterfall model due to the development of test plans early on during the life cycle. And another advantage of using this model is that it works well for small projects where requirements are easily understood. There are also shortcomings that you could encounter in using this model. One disadvantage is the same with the disadvantage of the Waterfall; V-shaped is very rigid. It has little flexibility and adjusting scope is difficult and expensive. Software is developed during the implementation phase, therefore there are no early prototypes of the software are produced. Model doesn’t provide a clear path for problems found during testing phases.
Reuse Model
The basic principle in using the reuse model is that systems should be built using existing components. The reuse model is definitely suited and appropriate to object-oriented computing environments. As of today’s system development industry, Object-oriented environments have become one of the premier technologies.
Within the Reuse Model, libraries of software modules are maintained that can be copied for use
in any system. These components are of two types: procedural modules and database modules.
When building a new system, the developer will “borrow” a copy of a module from the system
library and then plug it into a function or procedure. If the needed module is not available, the
developer will build it, and store a copy in the system library for future usage. If the modules are
well engineered, the developer with minimal changes can implement them. A general criticism of the Reuse Model is that it is limited for use in object-oriented development environments. Although this environment is rapidly growing in popularity, it is currently used in only a minority of system development applications.
The Reuse Model consists of the following steps:
• Definition of Requirements.
Initial system requirements are collected. These requirements are usually a subset of complete system requirements.
• Definition of Objects.
The objects, which can support the necessary system components, are identified.
• Collection of Objects.
The system libraries are scanned to determine whether or not the needed objects are available. Copies of the needed objects are downloaded from the system.
• Creation of Customized Objects.
Objects that have been identified as needed, but that are not available in the library are created.
• Prototype Assembly.
A prototype version of the system is created and/or modified using the necessary objects.
• Prototype Evaluation.
The prototype is evaluated to determine if it adequately addresses customer needs and requirements.
• Requirements Refinement.
Requirements are further refined as a more detailed version of the prototype is created.
• Objects Refinement.
Objects are refined to reflect the changes in the requirements.
There may be various models and as our fast changing environment grows, more and more models and techniques would be developed and implemented and even used by the developers to make their work well. It’s really on the developer and the organizations hand on what model would they use. The capability and assurance of success in every model depend on how big or how small the project is. Every model has its criteria on what type of project it is much useful. Mostly, developers would take parts and procedures from those various process models and then integrate it to support system development. The evolution of the system development process models has replicated the changing needs of the costumers.
References:
http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx
Posted 07-13-2005 8:13 AM by Raymond Lewallen
http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf
Posted by
0 comments:
Post a Comment