USE CASE DIAGRAM: USEP PRE-ENROLLMENT SYSTEM

There is always a procedure or process that is necessary to follow in an enrollment. As a student who envision himself/herself studying in one of the most prestigious university in the Philippines, the University of Southeastern Philippines, he/she must always be alert as well as always prepared in following the different procedures in USEP's enrollment. The use case diagram shown below describes the flow of the pre-enrollment process in USEP.

 

Brief Use Case Description

USE CASE: Requirements

 
Before getting the admission form, a student must first prepare the necessary requirements needed such as high school card (grades). He must submit it to the University Guidance and Testing Office or UGTO.

USE CASE: Admission

After checking the requirements and if there is no problem at all, the UGTO officer in charge will now give the admission form, to be fill up by the student.

USE CASE: Payment

Payment for examination is necessary in the pre-enrollment process. The student will pay the necessary amount in the cashier after filling up the admission form, to be able to take the entrance examination. 

USE CASE: Examination

After paying for examination, the student will now be ready for examination. Usually, a student will be scheduled on a certain date where he can take the examination. But sometimes, if there are a lot of students who want to take the test, a student will take the exam a few minutes or few hours after paying for the examination. The students who are ready to take the examination are divided into groups. For instance, in a room, there are 30 students who will take the exam together. Each room is assigned with one examiner who will facilitate the exam. 

USE CASE: English Bridge

English bridge examination is given by the UGTO to those students who will not be able to pass the passing grade or percentage in the English part of the examination. A student will need to have at least 75 percent in his English to prevent taking the English bridge exam. Nonetheless, a student will take the English bridge exam if he fails to pass the 75 ratings. The English Bridge has a 10-day class before conducting the exam. 

USE CASE: Interview

The students will go to their respective colleges. Each of them will be interviewed by the faculties of their colleges. One student will be asked by one faculty only. Different questions will be asked and the students' answers will be rated by the faculties. 

USE CASE: Medical Exam

A medical exam is very important in the pre-enrollment process since this process will test how healthy the students are and their capability to adjust and take the college life. The medical examination is conducted in USEP clinic. 

USE CASE: Payments

Students need to pay the fees in Obrero Campus Student Council (OCSC), Headlight (the official newspaper/publication of USEP), and in their respective Local Councils. Students must secure the receipts because these will be part of the requirements for the enrollment proper.

USE CASE: Advising

Each course and each level is assigned to different advisers. The assigned adviser will evaluate the students one by one and checked if the requirements for enrollment are complete. After that, if there is no problem, the students will be given Pre Registration Form (PRF), where they will jot down the subjects that they can take for the semester (including the subject code, subject description, scheduled time and room).

Systems Professional Versus Department Manager: Whose Approach Is Appropriate?

As our sixth assignment, we were a scenario about two experts on different fields but having the same goal, and that is to make an efficient and effective information system. These two people have different views and approach on how to generate a new information system that would work successfully. Before I go thoroughly on my discussion about their conversation, let me first define the individual expertise of John Juan, as a systems professional and Peter Pedro, as the department manager.

We are all aware that we are already living in what we call “Information Age.” Primarily, this means that most of our activities are being done with the use or help of computers or computer generated systems. In addition, in the fields of business (either it is a small one or big one), industry as well as in government, the role of technology in the Information Age has been renowned world wide, and their whole organizational structures as well as strategic planning procedures has been totally engage to this role of technology. According to R. H. Glover, the author of “Executive information systems: Current assessment & future agenda for Higher education,” as he gave emphasis on the function of technology, he believed that the caliber of information on hand to all decision makers is very significant. Basically, it is because the quality of strategic planning is dependent in the availability of quality information. This means that the people who make the decisions must be knowledgeable in strategic planning for him or her to make the planning efficiently. Glover also states that the administrative information systems were very serious in supplying the necessary data that produced the needed information. We are also aware that having a very good organizational structures as well as strategic plans, with the use of the technology, is very important in the success of every company and enterprise, for it is responsible in making the company competitive and prominent.

JOHN JUAN, THE SYSTEMS PROFESSIONAL

On our past assignments, we have been discussing about the systems analyst, what does the role of a systems analyst as well as how do the systems analyst works. Also, we discussed about the different phases of systems development life cycle which is necessary in making an efficient and effective system.

In the scenario given, John Juan is the systems professional or the one who do the systems analysis. As the systems analyst, John Juan is the one responsible in designing the new information system considering the information requirements of the company as well as of the end users.

Responsibility of John Juan as A Systems Professional

As a systems professional, John Juan has responsibilities that he must always bear in mind.

• To the Employers/Clients/System Users

Essentially, John Juan has the responsibility to be loyal and faithful to his employer in professional matters. He must also preserve every user’s, company’s and supplier’s privilege to secrecy and confidentiality as well as to be in awe of any ownership rights that belongs to them. He can do that that by giving appropriate security to the information, limiting the capability to access and ensure the accurate disclosure of any data and information about the clients as well as the users. In addition, John Juan must always treat all persons fairly, especially, when in his colleagues (if he is part of a team).
.
• To the Profession

As a professional, John should not just depend on the blunt truth, but basically on the mere facts basis. As a systems professional, he must not jump into conclusion unless he has evidences and make some experiments and surveys to prove it for his own. He must not make any unsupported statements or false statements or present any ambiguous information. He must always make a connection to his client, providing that he must inform them about the progress or conflict on the system he makes. He should take or make his research cautiously and meticulously. He must gather, tabulate, and interpret the data and information with complete awareness. He must consult his client first before taking any action, for approval purposes. Also, he must be vigilant in making or disclosing any information as a result of his research. He should always uplift his colleagues to do their very best to make a good outcome.

• To the Society

As part of his responsibility to the society, John Juan must be able to make the system he working at to be beneficial to most number of user as well as it will make the company more profitable. Also, he must generate instructions and proper training to those people who will use the system in order to avoid unnecessary damage to the system and negative feedbacks from the client and users. He must also acknowledge those people who helped (or will help him) and take part on the making of the system.

Skills (In Summary)

Basically, the most important skill John Juan must have, are the following:
• Interpersonal skills: this skill is pertaining to the ability of the systems professional to deal with people in an educated manner. This means that he is capable to appropriately interact with others. This skill includes everything that is necessary in interacting with other people; from communicating skills to listening skills to attitude and manner.

• Business skills: this skill defines the capability of the system professional to deal with the business logic of the client or company he worked in. Essentially, for John Juan, he must be aware on the business process of the company before he could propose a necessary system which fits to the company’s need.

• Analysis and design skills: systems professionals are known to be knowledgeable in terms of analyzing and interpreting problems as well as analyzing and interpreting the gathered data and information related to the problem after he could propose and deign a new system.

• Programming skills: this is a very important skill of a system analyst and John Juan must have a broad background on programming to be able to do the required by the company. Without knowledge on program, it is impossible for a systems analyst or a system professional to generate and deploy an information system.

His Approach on Generating a New Information System

As I have read and understood, based on the given scenario and on the conversion took place between him and Peter Pedro, John Juan wants to be knowledgeable on how the existing information system works; to be able to know the reason why it is necessary for the company to make a new one and to know if it just needs to be improve by doing some modifications and adjustments. This view could be practical in terms of cost to buy new parts and components for the new information system.

PETER PEDRO, THE DEPARTMENT MANAGER

As the department manager, Peter Pedro must be capable to manage many functional areas. He must have the ability to lead; he must acquire good leadership skills in order to handle all the people under his supervision efficiently. Peter Pedro must have a very tough administrative and managerial skill, as well as organizational and analytical skills. Also, as a department manager, Peter Pedro must be very proficient and excellent in making decision as well as he must acquire a good problem solving skills. Since he also manage a team who are assigned for making the system of the company; which means that John Juan is under his supervision, Peter Pedro must have a good background about information technology and facilities management. On the other hand, Peter Pedro is also called as the generalist. He is anticipated to have the ability to manage, at the same time, in several vicinity, proceedings and cut-off date. Peter Pedro must also comprise intense interpersonal and communication skills. This means that he must the “power of the tongue”; the ability to encourage the teams under him to work hard, the ability to persuade clients and the ability to handle fiery situation in a calm state. Also, he must be able to nurture and uphold a mutual and compassionate workplace. Peter Pedro must be able to do his responsibilities with minimal supervision.

Skills (In Summary)

• The capacity to lead and encourage a team
• Outstanding communication and people skills
• A great dedication to customer service
• The aptitude to perform under stress and nervous tension and can take care of demanding state of affairs
• Self-confidence, determination and eagerness
• Decision-making competence and a sense of accountability
• The ability to scrutinize and be familiar with sales figure

His Approach on Generating a New Information System

As I have read and understood, based on the given scenario and on the conversion took place between him and John Juan, Peter Pedro does not want John Juan to go over to the old system again. For his point of view, he wanted to go directly to the list of requirements for the system he wants to develop by John Juan’s team. As far as I am concern, Peter Pedro would like to totally break down the old system and develop and deploy a new one. This approach could lead to time effectiveness; the point here is, if the systems professional will go on finding what was wrong and still can be use in the old system, they would spend a lot of time and the deadline for the expected output would be extended and the deployment of the new system will be delayed.

Comparison of Their Approach

Both John Juan and Peter Pedro have points in their different approach and both approaches are for the benefit of making a new system. Primarily, although John Juan and Peter Pedro have different approach on how to make the system analysis, they still have one goal and that is to make a functional information system. As an educated system professional, John Juan’s actions and approach is based on what he knows is right and because it is part of what he has learned. I believe he just want to have a better and thorough review and research on the old system to generate a great idea in order to produce an effective and efficient new system. On the other hand, Peter Pedro would go directly on making the new system since, based on what he has said in the conversation between him and John Juan, they always get the customized and modified edition of the old system which is not fit to the new system they require and want to have. Obviously, Peter Pedro really wants to have and deploy new information system. He does not care if the old system only needs some adjustments and modification and can still be use. All he wants is only to have a new information system that possibly will be utilized for his department. (Well, it is only based on how I understand the things that Peter Pedro told John Juan in their conversation.)

Which Approach I Am In Favor With?

Well, based on the scenario with their conversation, my sympathy will be with John Juan. Primarily because he is more knowledgeable in making efficient information system compared to Peter Pedro, who only do managing and supervising although he has, somehow, knowledge about information system procedures, but not that much knowledge as of John Juan.

As a good and effective systems analyst or a systems professional, it is necessary that you always go into detail, no matter how big or small it is, as long as it is related to the system you are working at. In the case of John Juan, he only wants to go over to the old system to be able to know if there could be something on it that can still be use. Also, by making that step, he could bring about new and better ideas that will be very helpful for his client as will as for the users. John Juan is only applying the step by step procedure of System Development Life Cycle (SDLC) which is essential in building an operative and competent information system.
It seems that the information systems develop is essential for the part of Peter Pedro but it will be inappropriate for the case of the system analyst (systems professional, John Juan), the one who will make the system, to directly jump and do what Peter Pedro wants. It must be “doing what you need for the benefit of many than doing what you want for your own benefit.”

As A System Analyst…Method I Will Propose..

As a systems analyst, I want to consider the time I will spend in making the system as well as the cost and the availability of the resources. First and foremost, it is important for a systems analyst to know the needs of the client. Although, sometimes, there is a point that the systems analyst has a different views compared to the client that would bring up an unnecessary misunderstanding. But basically, to be able to produce a good information system, the client and the systems analyst must agreed on the same idea, and they must always consult each other as the process takes place. Since in our previous assignment, we were tasked to discuss different systems development models that are appropriate in making a good and functional information system. If I were John Juan, I will use the Synchronize-and-stabilize (sometimes just called sync-and-stabilize). For me, Synchronize-and-stabilize method is appropriate in making a good and effective information system since the works can be done in parallel. Also, in parallelism method, works can be done on a less allotted time. The only thing is, in the progress of the process of making the system, people who work in parallel must interact to one another to ensure that their works are correct, and to avoid iterated works.

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.

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

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 inter dependencies.

 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.


Conclusion:

As a systems analyst, one must always capable of knowing how the old system works before proposing a new system. Primarily, there must be something wrong with the old system that is why the company wants to have a new system. As a good and effective systems analyst, he or she must be able to apply, if necessary, the 3Rs: Reduce, Reuse, and Recycle.

REDUCE: It could be apply in reducing the cost as well as the time that could be allotted. Basically, if the systems analyst proposes to use some parts of the existing system in making a new one,, there will be able saved in terms of cost as well as time. For instance, a specific component is not available in a near location, which means there is a need to go to other location to find or buy that component. That will cost time and money. If that happens, there will be cots ineffectiveness as well as delay of scheduled time the systems must do.

REUSE: Instead of just throwing things away, try to find ways to use them again. Fundamentally, reusing the materials that can still be even avail will lessen the budget allotted to buy new parts and components for making the new system.

RECYCLE: Nowadays, numerous numbers of materials we use can be recycled. We are all aware that recycled materials undergo procedures that make it possible to generate or produce new products and materials from the old ones.


My main point here is, if there is just a need of improvement on the existing system, there is no need to junk or break the whole system. Making some adjustments on current system will do as long as the new system that the company needs and want is fit to the capability of the improved system. Nonetheless, if the company really needs to have a new system with new parts and components, here comes the time that the systems analyst would do the feasibility analyzing and propose a new system considering the business logic of the company he works in. Also, the systems analyst and the client must agree on the same idea to avoid misunderstandings. To be able to make a good system, both must helping each other and supporting each other as well encouraging their colleagues to work hard and enjoy what they are doing. Lastly, acknowledging ones help and work is necessary to build a good relationship between the people who worked hard in producing an information system.





Sources:
http://net.educause.edu/ir/library/html/cnc9764/cnc9764.html
http://www.asis.org/AboutASIS/professional-guidelines.html
http://www.arts.cornell.edu/romance/staff/TFIRM/roleofmanager.pdf
http://searchsoa.techtarget.com/definition/synchronize-and-stabilize

Different System Development Life Cycle Models

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:

•  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