6) PRESENT DIFFERENT SYSTEM DEVELOPMENT METHODOLOGY THAT CAN BE

APPLIED IDENTIFY THE ADVANTAGES AND DISADVANTAGES

Alexis, apparently, has made the best decision, wherein, the usage of combination of the system
development methodologies that she chose depending on the needs and the available resources and
skills faced by the CBA. (Waterfall, Spiral, Prototype, RAD, and so forth) These methodologies have
different targets in resolving the organization’s problem. All have its respective advantages and
disadvantages. To develop a system that will resolve the issues of the organizations, the best way is to
consider each of the factors that will give clue to eliminate the root of all these issues, and by which the
proposed system, when implemented, will achieve all the primary goals and objectives of the
organization.

The following are the different system development methodology that can be applied, with their
advantages and disadvantages:

1) WATERFALL METHODOLOGY

Framework: Linear

BASIC PRINCIPLES:

1) Project is divided into

sequential phases, with
some overlap and
splashback acceptable
between phases.

2) Emphasis is on
planning, time
schedules, target dates, budgets and implementation of an entire system at one time.

3) Tight control is maintained over the life of the project through the use of extensive written
documentation, as well as through formal reviews and approval/signoff by the user and information
technology management occurring at the end of most phases before beginning the next phase

This methodology is appropriate to cover only some of the possible waterloos and targets only few
needs of the organization. The following are the advantages of applying the waterfall methodology in
the developing a system.

 It is ideal for supporting less experienced project teams and project managers, or project
teams whose composition fluctuates. Since after Alexis evaluated the resources, she found out
that the staff that might help her were relatively small and the CBA staff were lacking
development expertise.
 It conserves resources. Aside from the lack of human resources, Alexis was also struggling about
budgets being cut to support the development process.
  Waterfall methodology is most appropriate when the project already established clear
objectives.

Although this methodology might be helpful to resolve some issues of the project, there are more
reasons why the solely usage of this methodology would not work really well:

 It was clearly stated that the continuance of the existing system shall be iterative and on-going
process. So there would be little room for use of iteration, which can reduce manageability if
used. Basically, when the project progressed forward, it would only have a slight movement
backward.
 Inflexible, slow, costly and cumbersome due to significant structure and tight controls.
 There are requirements inconsistencies, missing system components, and unexpected
development needs are often discovered during design and coding.
 Due to fluctuating standards, this methodology is least appropriate to large projects where the
requirements are not well understood or are changing for any reasons such as external
changes, changing expectations, budget changes or rapidly changing technology.
 This methodology cannot also work well into database with web-enabled user interface
primarily due to the pressure of implementing a WIS project quickly.

2) PROTOTYPE MODEL

Framework: Iterative

BASIC PRINCIPLES:

1) Not a standalone, complete

development methodology, but
rather an approach to handling
selected portions of a larger, more
traditional development
methodology.

2) Attempts to reduce inherent

project risks by breaking a project
into smaller segments and providing
more ease-of-change during development process.

3) User is involved throughout the process, which increases the likelihood of user acceptance of the
final implementation.

4) Small-scale mock-ups of the system are developed following an iterative modification process until
the prototype evolves to meet the users’ requirements.

5) While most prototypes are developed with the expectation that they will be discarded, it is possible in
some cases to evolve from prototype to working system.
6) A basic understanding of the fundamental business problem is necessary to avoid solving the wrong
problem.

Mike and Kevin already developed a prototype that utilized Microsoft Access, however, they believe
that new system should be designed using a client/server model for the database with a Web-enabled
user interface. The prototype model is likely to be the most appropriate and traditionalist model to be
used but Alexis believed, that to improve the system, there shall be combinations of the methodologies.
The following are the advantages of prototyping in the organization:

 Since there are minimal interaction between the staff, prototyping improves both user
participation in system development and communication among project stakeholders. Given
the fact that the organization has been lacking human resources, probably the best solution is
for them to build task and maintenance goals simultaneously.
 In discarded prototypes, instead of throwing them away, prototyping can transform them to
‘evolutionary’ one.
 As the organization has several problems and issues to be resolved one by one, and Alexis, on
the other hand has been worrying for her project not being completed at the AACSB review,
prototyping provides quick implementation of an incomplete, but functional applications since
pressure exist for immediate implementation of something.
 This method also encourages innovations and flexible designs, and by that way, developers
may think outside the box ideas, which can really be effective and valuable to the organization.

Despite of the huge help that prototyping can offer within the development, there are still some flaws
that this method is incapable of concealing:

 Similar to waterfall model, applying the prototyping model is least appropriate with
organizations that requires web-enabled systems.
 Designers may prototype too quickly, without sufficient up-front user needs analysis, resulting
in an inflexible design with narrow focus that limits future system potential.
 It can lead to false expectations, where the customer mistakenly believes that the system is
“finished” when in fact it is not; the system looks good but has adequate user interfaces; but is
not truly functional.
 Although the CBA is willing to incur high initial cost for the betterment, this would be very risky;
iterations add to project budgets and schedules, thus the added costs must be weighed against
the potential benefits. Very small projects may not be able to justify the added time and money,
while only the high-risk portions of very large, complex projects may gain benefit from
prototyping.
 3) RAPID APPLICATION DEVELOPMENT (RAD)

Framework: Iterative

BASIC PRINCIPLES:

1) Key objective is for fast

development and delivery of a
high quality system at a
relatively low investment cost.

2) Attempts to reduce inherent

project risk by breaking a
project into smaller segments
and providing more ease-of-
change during the
development process.

3) Aims to produce high quality systems quickly, primarily through prototyping (at any stage of
development), active user involvement, and computerized development tools.

4) Key emphasis is on fulfilling the business need, while technological or engineering excellence is of
lesser importance.

5) Project control involves prioritizing development and defining delivery deadlines or

“timeboxes”. If the project starts to slip, emphasis is on reducing requirements to fit timebox, not in
increasing the deadline

6) Includes Joint Application Development (JAD), where users are intensely involved in system
design, either through consensus building in structured workshops, or through electronically
facilitated interaction

7) Active user involvement is imperative.

8) Iteratively produces production software, as opposed to a throwaway prototype

9) Produces documentation necessary to facilitate future development and maintenance

10) Standard systems analysis and design techniques can be fitted to this framework.

RAD produces systems more quickly and to a business focus, this approach is applicable especially the
organization is in need to finish or complete the system before the accreditation and it tends to
complete a project at lower costs. Aside from this, there are more advantages that RAD possessed:

 RAD engage a better commitment with the stakeholders, users are seen as gaining more of a
sense of ownership of a system, while developers are seen as gaining more satisfaction from
producing successful system quickly. This can resolve the drawback between the faculty and
administration about who should own and benefit from the process
  Since there are many significant reporting changes due to fluctuating standards, RAD provides
the ability to rapidly change system design as demanded by users. It is flexible enough to cope
up with the demands
 Application of RAD is most appropriate also when data for the project are already existing
(completely or in part), and the project largely comprises analysis or reporting data.
 This methodology is most appropriate when project is of small-to-medium scale of short
duration (no more than six years), where the reviewing and revising the system is at least once
every five years.

Although this model satisfied most of the needs and resolves most of the conundrums, there are still
several factors to be considered why RAD is inappropriate to be applied in the entire project:

 It has the potential in creating inconsistent designs within and across the system and violation
of programming standards related to inconsistent naming convention and documentation. If
RAD has been used carelessly, this interruption may result for the project being unable to finish
in the target time.
 Using RAD may incur high cost of commitment on the part of the key user personnel.
 Since RAD produce faster system than the other models, some modules will be completed much
earlier than others and there are tendencies for difficult problems to be pushed to the future to
demonstrate early success to management.

4) SPIRAL MODEL

Framework: Combination of Linear and Iterative

BASIC PRINCIPLES:

1) Focus is on risk assessment and

on minimizing project risk by
breaking a project into smaller
segments and providing more ease-
of-change during the development
process, as well as providing the
opportunity to evaluate risks and
weigh consideration of project
continuation throughout the life
cycle.

2) Each trip around the spiral

traverses four basic quadrants: (1)
determine objectives, alternatives, and constraints of the iteration; (2) evaluate alternatives; identify
and resolve risk; (3) develop and verify deliverables from the iteration; and (4) plan the next iteration
4) Begin each cycle with an identification of stakeholders and their win conditions, and end each cycle
with review and commitment.

Various methods are acceptable for combining linear and iterative system development methodologies,
with the primary objective of reducing inherent risks by breaking a project into smaller segments and
providing more ease-of-change during development process. However, as Alexis thought of, perhaps,
this combination will be the most efficient and effective way of developing as system when applied.
Here are some pros of implementing spiral method:

 Aside of enhancing the project risk avoidance, it is useful in helping to select the best
methodology to follow for development of a given software iteration, based on these risks.
 It can incorporate waterfall, prototyping, and other methodologies as special cases in the
framework, and provide guidance as to which combination of these models best fits a given
software iteration.
 It is most appropriate when the implementation has priority over functionality, which can be
added in later version. One of the goals set by Alexis and her colleagues is to finish the system in
the earliest possible time since they have been after the accreditation and review by AACSB.

Given all the facts, in the organization’s situation, spiral model, despite all its pros, there are still some
several cons where too much reliability on this will possible make the organization less efficient:

 The project manager should be really skilled and experienced to determine how to apply it to
any given project. Since Alexis is just new and assigned as the project manager, she may have
some difficulties on setting the right strategy and approach in the system development.
 There is a challenge in determining the exact composition of development methodologies to
use for each iteration around the spiral.
 The system to be developed under Spiral approach is highly customized, and quite complex. If
an inexperienced manager ran this, it will also cause operations interruption.

5) DESIGN TO TOOLS MODEL

BASIC PRINCIPLES:

1) A radical approach that historically has been

used only within exceptionally time-sensitive
environments.

2) It is putting a capability into your product only if

it's directly supported by existing software tools.

3) If it isn't supported, it gets left out. Besides

architectural and functional packages, these tools
can be code and class libraries, code generators,
rapid-development languages and any other software tools that dramatically reduce implementation
time.

The primary advantage of this methodology is when time is a constraint, may be able to implement
more total functionality than possible when building everything "from scratch".

On the other hand, design to tools methodologies possessed these weaknesses:

 Losing a lot of control over the product.

 Becoming "locked in" to a vendor. If it is for long-term functionality, vendor lock-in can become
a weak link.
 May not be able to implement all features desired or in the manner desired.

Consider the tradeoffs of time-to-market versus lock-in and functionality compromises. This may be an
appropriate approach for a high-risk element of the overall project or architecture.

The above methods, when applied in their respective target problems will be more efficient and
effective than settling in one model. Alexis and the rest of her colleagues should be careful, keen
observers and think critically on which model is for which. By the combination that they will come up,
the system may be in success, or if the developing process is not properly iterated, of course, the system
will come to its downfall.