On our fourth assignment, we were told to identify and discussed three different types of systems development models. But before anything else, I would like to discuss first what is Systems Development Life Cycle (SLDC) and how it is related with System Development Models.
On the whole, Systems Development Life Cycle, or SDLC is very important in project management. It is a conceptual model which is used as a guide for preparing to planning until maintaining a project. The Systems Development Life Cycle (SDLC) illustrates the different stages that are involved to make an effective information system development project, starting from the preliminary feasibility through the safeguarding of the completed project.
Usually, an SDLC methodology goes after the following steps:
1. Evaluating the existing or accessible system. Flaws and imperfections are identified. All of these are done by interrogating the users of the system as well as seeking advice from the support personnel.
2. Defining the new and latest system requirements. Particularly, the insufficiency in the existing system should be dealt with precise proposals for progress and enhancement.
3. Designing what the newly proposed system. The different plans are put down with reference to the physical construction, hardware, operating systems, programming, communications, and security issues.
4. Developing the new system. Since it is said to be “new system”, the new components and programs must be attained and installed, or if some components and programs from the previous system can still be used, enhancing is very appropriate in order to make the new system function well. Users of the system must undergo trainings in its use, and all phase of routine must be tested to avoid unnecessary delays of work and malfunctioning of the system. If it is essential, at this stage, modification and correction must be made.
5. The system is put into use. There are many different ways to put the system into use. One of those is phasing in the new system, considering the application or location until the old system is slowly but surely interchanged. But to be more practical and maybe cost effective, in some cases, shutting down the old system and executing the new system at the same time is necessary.
6. Comprehensively evaluation should be done by the time the new system is up and operating for a moment. In order to avoid unnecessary malfunctioning or break down of the system, maintenance must be kept up thoroughly all the time. Furthermore, users of the system should be kept up-to-date pertaining to the most recent adjustments and processes.
What were discussed above are the phases or stages of the Systems Development Life Cycle. Basically, different authors have different approach in identifying the SDLC methodology. But bottom line is, they still have the same perceptions on how the SDLC methodology works.
The next thing I will discuss is about the System Development Models and how these models are related in Systems Development Life Cycle.
The Purpose of Systems Development Models
Primarily, Systems development models are used to illustrate the different phases in Systems Development Life Cycle (SDLC) such as planning, analysis, design, development, implementation and maintenance of information systems. Every phase is intended for a detailed function and motivation. Some have the same aims and allocate various common responsibilities. Essentially, developers make use of some kind of system development model to direct the project’s life cycle to be able to guarantee excellent and quality systems are build up concerning to the needs and wants of the business organization.
Different Types of System Development Models
• SYNCHRONIZE-AND-STABILIZE (SYNC-AND-STABILIZE)
One of the models in the Systems Development Life Cycle is the Synchronize-and-stabilize (sometimes just called sync-and-stabilize). It is an SDLC model in which teams work in parallel on individual application modules, repeatedly coordinating their code with that of other teams, and debugging (stabilizing) code on a regular basis all the way through the development procedure. It is said that the sync-and-stabilize model is more advantageous over the older waterfall, which is rigorously chronological in nature. Because sync-and-stabilize development allows parallelism, changes can be done at any point in the process and for that, it can be flexible, and responding to the market requirement changes is easier.
HISTORY
David Yoffie of Harvard University and Michael Cusumano of MIT were the people who created the Synchronize and Stabilize, also known as sync-and-stabilize approach. Cusumano and Yoffie both studied commonalities between processes Microsoft used in developing Internet Explorer and those Netscape Communications Corp. used in developing Netscape Communicator. As the researchers continue their study, among other similarities, they found out both corporation put together all the project code nightly. They both also brought together all the components and tried to stabilize code before it was released. Their findings gave Cusumano and Yoffie the idea to incorporate the successful common strategies of the two projects into the sync-and-stabilize model.
According to Michael Cusumano and Richard Selby, Microsoft Corporation is using the sync-and-stabilize approach in their project development. It is also said that without Synchronize and Stabilize structured approach in Microsoft’s system development, Microsoft would almost certainly never been able to propose, design, construct, produce and ship the products it offers now and plans to offer in the future.
Synchronize and Stabilize Model versus Sequential Model (Waterfall Model)
In Synchronize and Stabilize Model:
On the whole, Systems Development Life Cycle, or SDLC is very important in project management. It is a conceptual model which is used as a guide for preparing to planning until maintaining a project. The Systems Development Life Cycle (SDLC) illustrates the different stages that are involved to make an effective information system development project, starting from the preliminary feasibility through the safeguarding of the completed project.
Usually, an SDLC methodology goes after the following steps:
1. Evaluating the existing or accessible system. Flaws and imperfections are identified. All of these are done by interrogating the users of the system as well as seeking advice from the support personnel.
2. Defining the new and latest system requirements. Particularly, the insufficiency in the existing system should be dealt with precise proposals for progress and enhancement.
3. Designing what the newly proposed system. The different plans are put down with reference to the physical construction, hardware, operating systems, programming, communications, and security issues.
4. Developing the new system. Since it is said to be “new system”, the new components and programs must be attained and installed, or if some components and programs from the previous system can still be used, enhancing is very appropriate in order to make the new system function well. Users of the system must undergo trainings in its use, and all phase of routine must be tested to avoid unnecessary delays of work and malfunctioning of the system. If it is essential, at this stage, modification and correction must be made.
5. The system is put into use. There are many different ways to put the system into use. One of those is phasing in the new system, considering the application or location until the old system is slowly but surely interchanged. But to be more practical and maybe cost effective, in some cases, shutting down the old system and executing the new system at the same time is necessary.
6. Comprehensively evaluation should be done by the time the new system is up and operating for a moment. In order to avoid unnecessary malfunctioning or break down of the system, maintenance must be kept up thoroughly all the time. Furthermore, users of the system should be kept up-to-date pertaining to the most recent adjustments and processes.
What were discussed above are the phases or stages of the Systems Development Life Cycle. Basically, different authors have different approach in identifying the SDLC methodology. But bottom line is, they still have the same perceptions on how the SDLC methodology works.
The next thing I will discuss is about the System Development Models and how these models are related in Systems Development Life Cycle.
The Purpose of Systems Development Models
Primarily, Systems development models are used to illustrate the different phases in Systems Development Life Cycle (SDLC) such as planning, analysis, design, development, implementation and maintenance of information systems. Every phase is intended for a detailed function and motivation. Some have the same aims and allocate various common responsibilities. Essentially, developers make use of some kind of system development model to direct the project’s life cycle to be able to guarantee excellent and quality systems are build up concerning to the needs and wants of the business organization.
Different Types of System Development Models
• SYNCHRONIZE-AND-STABILIZE (SYNC-AND-STABILIZE)
One of the models in the Systems Development Life Cycle is the Synchronize-and-stabilize (sometimes just called sync-and-stabilize). It is an SDLC model in which teams work in parallel on individual application modules, repeatedly coordinating their code with that of other teams, and debugging (stabilizing) code on a regular basis all the way through the development procedure. It is said that the sync-and-stabilize model is more advantageous over the older waterfall, which is rigorously chronological in nature. Because sync-and-stabilize development allows parallelism, changes can be done at any point in the process and for that, it can be flexible, and responding to the market requirement changes is easier.
HISTORY
David Yoffie of Harvard University and Michael Cusumano of MIT were the people who created the Synchronize and Stabilize, also known as sync-and-stabilize approach. Cusumano and Yoffie both studied commonalities between processes Microsoft used in developing Internet Explorer and those Netscape Communications Corp. used in developing Netscape Communicator. As the researchers continue their study, among other similarities, they found out both corporation put together all the project code nightly. They both also brought together all the components and tried to stabilize code before it was released. Their findings gave Cusumano and Yoffie the idea to incorporate the successful common strategies of the two projects into the sync-and-stabilize model.
According to Michael Cusumano and Richard Selby, Microsoft Corporation is using the sync-and-stabilize approach in their project development. It is also said that without Synchronize and Stabilize structured approach in Microsoft’s system development, Microsoft would almost certainly never been able to propose, design, construct, produce and ship the products it offers now and plans to offer in the future.
Synchronize and Stabilize Model versus Sequential Model (Waterfall Model)
In Synchronize and Stabilize Model:
- Product development and testing is done in parallel
- Vision statement and evolving specification
- Features prioritized and built in 3 or 4 milestone sub projects
- Frequent synchronization (daily builds) and intermediate stabilization (milestone)
- “Fixed” release and ship dates and multiple release cycles
- Customer feedback continuous in the development process
- Product and process design so large teams work like small teams
In Sequential Model:
- Separate done in sequence
- Complete “frozen” specification and detailed design before building the product
- Trying to build all pieces of a product simultaneously
- One late and large integration and system test phase at the projects end
- Aiming for feature and product “perfection” in each project cycle
- Feedback primarily after development as inputs for future projects
- Working primarily as a large group of individuals in a separate functional department
Base on the things mentioned above about the synch-and-stabilize model and sequential model, it is somehow clear that the Synchronize and Stabilize Model is more flexible compared to Sequential Model in System Development Life Cycle. Since synch-and-stabilize approach uses parallelism, more works can be done and it is also a cost-effective scheme compared to sequential approach which uses a chronological method.
The Synchronize and Stabilize team process can be summarized as follows:
- Feature Oriented
- Synchronize (daily build) and Stabilize (fix errors at end of each milestone, such that the required set of features is completely functional)
- Product Managers develop a vision statement and feature list based on customer input
- Program Managers develop an initial functional specification based on the vision statement
- Program Managers create schedules and parallel feature teams of 3-8 developers and testers based on the functional specification
- Team members can work autonomously, thus maintaining some creative freedom on the project, provided their work can be combined successfully into the daily builds
- Teams develop their own playful penalties for breaking the daily build, which forces a certain amount of discipline amongst a team, while at the same time remaining democratic
According to the book “How Microsoft Builds” by Cusumano and Selby, there are phases which is need to under go in synch-and-stabilize approach.
PLANNING PHASE (3-12 months, depending on size of project)
Vision Statement – Product and program management use extensive customer input to identify and priority-order product features.
Specification - Based on vision statement, program management and development group defines feature functionality, architectural issues and components interdependencies.
Schedule And Feature Team Formation - Based on specification document, program management coordinates schedule and arranges feature teams that each contain approximately 1 program manager, 3 to 8 developers, and 3 to 8 testers(who work in parallel 1:1 with developers.)
DEVELOPMENT PHASE (6-12 months)
Project managers coordinate evolution of specification. Developers design, code, and debug. Testers pair with developers for continuous testing.
Subproject I: most crucial 1/3 features, milestone release I
Subproject II: second 1/3 features, milestone release II
Subproject III: final (least critical) 1/3 features, milestone release III --- code complete
STABILIZATION PHASE (3-8 MONTHS)
Program managers coordinate OEMs and ISVs and monitor customer feedback. Developers perform final debugging and code stabilization.
Internal Testing - Testers recreate and isolate errors.
External Testing - Thorough testing of complete product within the company.
Release Preparation - Thorough testing of complete product outside the company by “beta” sites such as OEMs, ISVs, and end users. Prepare final release of “golden master” disk and documentation for manufacturing.
THE SPIRAL LIFE CYCLE MODEL
Another Systems Development Life Cycle Model is the Spiral Life Cycle Mode. The spiral model, also known as the spiral lifecycle model, is one the systems development lifecycle (SDLC) model used in the field information technology (IT). It is that the spiral model is a combination of prototyping model and waterfall model. In making of a large, expensive and complicated project, spiral model is usually used.
Generally, the process in the spiral life cycle model can be illustrated as follows:
1. The new system requirements are defined in as much detail as possible. Primarily, this phase requires interrogating a number of users in behalf of all the internal and external users as well as the other features of the existing system.
2. Creating an initial drawing or design for the newly proposed system.
3. A first example of the newly proposed system is built from the initial design. This is generally a scaled-down system, and symbolizes an estimation of the distinctiveness and characteristics of the final product.
4. A second sample is developed by a fourfold procedure:
(1) Evaluate - assessing the first example in terms of its potencies, drawbacks, and threats;
(2) Define - classifying the constraints of the second sample;
(3) Plan and Design - setting up and designing the second sample;
(4) Construct and Test - creating and examining the second example.
5. Fundamentally, the customer has the choice or the option to abort the whole project if it will cause an immense risk. For instance, the development cost is beyond the budget of the customer, miscalculation of the operating cost, or any other factor that could result into dissatisfaction in the final product or output, considering the customer’s judgment. For that, it will lead to some bad and negative feedbacks against the company if it happens that the developers did not meet the customer’s wants and needs that force them to back out.
6. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
7. Since it is called as the spiral model, the procedures are iterated, from the beginning through the end, until the customer will get satisfied, that the developed sample illustrated the final product desired by the customer.
8. After the processes that the prototype undergone, the final system can now be assembled
9. Thorough evaluation and examination is necessary to the final system. Primarily, regular maintenance should be carried out to prevent comprehensive fiasco as well as to minimize delays and downtime.
• Objectives: functionality, performance, hardware/software interface, serious achievement issue, etc.
• Alternatives: construct, recycle, acquire, delegate, etc.
• Constraints: expenditure, timetable, interface, etc.
• Study alternatives which is relative to objectives and constraints
• Identify risks – it defines the lack of experience, new technology, tight schedules, poor process, etc.
• Resolve risks – it describes the evaluation if money could be lost by continuing system development
The following strengths and weaknesses as well as when do we use spiral model is according to Yogi Berra.
Spiral Model Strengths
• Provides early indication of undefeatable risks, without much cost
• Users see the system early because of rapid prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently
Spiral Model Weaknesses
• Time spent for evaluating risks too large for small or low-risk projects. This means that spiral model is very time consuming. For that, delays could probably occur.
• Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive. This may lead to downtime risk. Also, it will cause to outbound the budget and time given.
• The model is complex. Spiral model is complicated because you cannot go into the next phase unless you perfectly done the previous stage.
• Risk assessment expertise is required. Every now and then, it is very important that the process underlying the Spiral model must always be evaluated in order to avoid malfunctioning of the system.
• Spiral may continue for an indefinite period
• Developers must be reassigned during non-development phase activities
• May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration. Basically, the iteration process of the spiral model may lead to some risks that could cause difficulty in doing the system as required in the objective.
When to use Spiral Model
• When creation of a prototype is appropriate
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of potential changes to economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and exploration)
The following strengths and weaknesses as well as when do we use Rapid Application Development Model is according to Yogi Berra.
RAPID APPLICATION DEVELOPMENT MODEL (RAD)
Some of us are familiar with the RAD or the Rapid Application Development, which is an idea that the product can be developed and produced more rapidly and of great and higher quality through
• Gathering requirements using workshops or focus groups. It means that method of gathering information is via joining workshops or any scheme where there is so-called “groups” of people.
• Prototyping and early, reiterative user testing of designs
• The re-use of software components. Recycling or reusing the old components of the previous software or system is part of the RAD model activity.
• A rigidly paced schedule that defers design improvements to the next product version
• Less formality in reviews and other team communication
Further Discussion on Rapid Application Development
• Requirements planning phase (a workshop utilizing structured discussion of business problems)
• User description phase – automated tools capture information from users
• Construction phase – productivity tools, such as code generators, screen generators, etc. inside a time-box. (“Do until done”)
• Cutover phase -- installation of the system, user acceptance testing and user training
Rapid Application Development Model Strengths
• Reduced cycle time and improved productivity with fewer people means lower costs
• Time-box approach mitigates cost and schedule risk
• Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs
• Focus moves from documentation to code (WYSIWYG).
• Uses modeling concepts to capture information about business, data, and processes.
Rapid Application Development Model Weaknesses
• Accelerated development process must give quick responses to the user
• Risk of never achieving closure
• Hard to use with legacy systems
• Requires a system that can be modularized
• Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.
When to use Rapid Application Development Model
Experienced programmers are members of the team
RAD is a fast paced SDLC. Developers will be using different tools in order to achieve the goal of building software fast. Although it does not need much coding because of the given set of tools, only experienced programmers could work on these tools. If anything happens to the software, only experienced developers could dig deep into the problem even though they did not encode the program.
Expediting application development
For whatever reasons, developers are hard pressed to build applications fast. Using sets of tools, different software could be created in no time. The participation of the users will be greater since they will work in double time to check if the software is up with the standards.
Quick solution for a business problem
The tools used in developing software have steps or processes that could cater to any business need. If a business needs an answer to their nagging question of productivity and better reporting, RAD could create the software based on the business need. There are lots of software which already have the functions needed by any businesses.
Objective Oriented and Highly Critical Users
Everything starts and ends with the objective. Users have to use the software to achieve the intended goal faster or easier. Different user interface and workflows are based on the realization of the objective. RAD makes the developers focus more on answering the need before creating something on their own. The set of tools could be used to answer the problem. Even the design of the user interface could be influenced by users.
Rapid Application Development Model Phases
Like most SDLCs, RAD also has a step by step process. But unlike other SDLCs, the process of developing a program under RAD is faster. Relying on sets of tools for software development, RAD will no longer have to force us to dig deeper in our coding techniques where we burn an hour or two just to complete a single command.
There are only three phases in Rapid Application Development:
• Planning of Requirements
• Design Workshop
• Implementation.
1. Planning of Requirements
In this stage, developers meet with the project director or manager to generate definite objectives from the preferred program. Primarily, different strategies for development as well as the tools that will be used for development are also put up in a specific project. For business organizations, this stage is very necessary since the projected answer to business concerns will be laid out for the first time. Everything in this stage is hypothetical but it will be working together with the clients or businesses that need a software to answer their business need.
2. Design Workshop
When the plans have been laid out; it is time to start building on the plans. Using the agreed tools and interfaces, developers will start to create different programs based on the business need wants. RAD needs a lot of reaction as it also requires a lot of software iteration. Since RAD already has the set of tools to produce the program, developers will only need to refine the user interface. As tools make it easier to create the real prototypes, users will be able to work on a sample. Comment and implications are appreciated as this will be the bases on of the supplementary software procedures and instructions. Slowly developers and users can come up with one prototype that is almost ready for public use.
3. Implementation Phase
After further refinement, the software will finally be introduced to the business or to their intended users. Even though it has gone through hundreds or even thousands of testing and critique, the stage wherein the software is implemented in a larger scale is different hence new suggestions and bugs should be expected from different users. Developers have to remember these inputs and use it for the next software update. Developers have to be sure that the software update will be correct so that users will abandon the older version. This will prevent the system from malfunctioning since only one version is used.
The difference of Design Workshop to the Implementation Phase is not only in bugs but in software implementation. In Design Workshop, developers have to start from the bottom to impress the users. In the latter phase, developers will only have to work in software updates to ensure wider user acceptance.
Rapid Application Development or RAD takes the Prototype Model of SDLC further. Instead of using codes, developers use different tools and software development kits and bring them all together to create a software. Developers who are time challenged could use this application development. Businesses will also appreciate this software as it’s aimed to answer specific problems. Users’ feedbacks are important in this development cycle since they will suggest whether the program will fit to their specifications and needs.
References:
http://searchsoftwarequality.techtarget.com/definition/systems-development-life-cycle
http://searchsoa.techtarget.com/definition/synchronize-and-stabilize
https://docs.google.com/viewer?a=v&q=cache:_lGbnm2X9QIJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.92.1577%26rep%3Drep1%26type%3Dpdf+synchronize-and-stabilize+%28sync-and-stabilize%29+model+phase&hl=en&gl=ph&pid=bl&srcid=ADGEESh6i-Vo0G04PnDvWEQ_sUOjv4VrcbUV3-EBfKB66HuNWJmeL0YLIIRA8OHv--fhjlaOvVtE-ZqDxgrAGfxSEmXReQWYwH_B-jhH_IAjVlo_SV1macB9kWLmya3QFALg2abHgXjT&sig=AHIEtbSUqX4s3QLilblAlp1E50s9sDShhg
https://docs.google.com/viewer?a=v&q=cache:siLjXXYW-5gJ:condor.depaul.edu/jpetlick/extra/394/Session2.ppt+the+fountain+model+of+SDLC&hl=en&gl=ph&pid=bl&srcid=ADGEEShCfW0_MLC4wRbczfUxrndHTkbwguF9fZuaUCe0RDyOCWyO2PTmaPhHnZ4jRhZZ75maVO_7gVAD2ex5-QIhrj1683hMefBNkak7FkQJCAwd-i0-_aQfEVEEKP177h4mmkvMMWJ7&sig=AHIEtbR77wACNjJYd3McDO_KsR7LIELc9w
http://www.learn.geekinterview.com/it/sdlc/rapid-application-development.html
No comments:
Post a Comment