Information systems development methodologies (autosaved)

Ss. Kiril and Metodius – Faculty od Economics, Skopje
Vaska Chobanova index no: 4712

Homework 1: Information Systems Development Methodologies

This purpose of this paper is to give an understanding of the information systems development
methodologies available. A software development methodology or system development
methodology in software engineering is a framework that is used to structure, plan, and control
the process of developing an information system. Here are some iterative methodologies that can be
used especially for large projects and some of their characteristics.
Spiral Model
The idea is evolutionary development, using the waterfall model for each step; it's intended to help
manage risks. Don't define in detail the entire system at first. The developers should only define the
highest priority features. Define and implement those, then get feedback from users/customers (such
feedback distinguishes "evolutionary" from "incremental" development). With this knowledge, they
should then go back to define and implement more features in smaller chunks. Each iteration of the
prototype represented as a cycle in the spiral. The Spiral software development model is a risk-
oriented. Use the spiral model in projects where business goals are unstable but the architecture
must be realized well enough to provide high loading and stress ability.
Recognizing:
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 cycle involves a progression through the same sequence of steps, for each portion of the product
and for each of its levels of elaboration, from an overall concept-of- operation document down to the
coding of each individual program.
3. Each trip around the spiral traverses four basic quadrants: (1) determine objectives, alternatives, and
constraints of the iteration; (2) evaluate alternatives; identify and resolve risks; (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.
Phases:
1. Project Objectives. Similar to the system conception phase of the Waterfall Model. Objectives are
determined, possible obstacles are identified and alternative approaches are weighed.
2. 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.
3. Engineering & Production. Detailed requirements are determined and the software piece is developed.
4. 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.
Variations. Win-Win Spiral Process Model is a model of a process based on Theory W, which is a
management theory and approach "based on making winners of all of the system's key stakeholders
as a necessary and sufficient condition for project success."
Incremental Development
Here the project is divided into small parts. This allows the development team to demonstrate results
earlier on in the process and obtain valuable feedback from system users. Often, each iteration is
actually a mini-Waterfall process with the feedback from one phase providing vital information for
the design of the next phase.
Recognizing:
1. A series of mini-Waterfalls are performed, where all phases of the Waterfall development model are
completed for a small part of the system, before proceeding to the next increment; OR

Homework 1 ISDM Vaska Chobanova index no: 4712
2. Overall requirements are defined before proceeding to evolutionary, mini-Waterfall development of
individual increments of the system, OR
3. The initial software concept, requirements analysis, and design of architecture and system core are defined
using the Waterfall approach, followed by iterative Prototyping, which culminates in installation of the
final prototype (i.e., working system).
Phases:
1. Inception. Identifies project scope, risks, and requirements (functional and non-functional) at a high level
but in enough detail that work can be estimated.
2. Elaboration. Delivers a working architecture
3. Construction
4. Transition
Variations . A number of process models have evolved from the iterative approach. All of these
methods produce some demonstrable software product early on in the process in order to obtain
valuable feedback from system users or other members of the project team. In some, the software
products which are produced at the end of each step (or series of steps) can go into production
immediately as incremental releases.
Prototype Model
The prototype model is used to overcome the limitations of waterfall model. In this model, instead of
freezing the requirements before coding or design, a prototype is built to clearly understand the
requirements. This prototype is built based on the current requirements. Through examining this
prototype, the client gets a better understanding of the features of the final product. The processes
involved in the prototyping approach are shown in the figure below.
Recognizing:
1. Not a stand alone, complete development methodology, but rather an approach to handling selected
portions of a larger, more traditional development methodology (i.e., Incremental, Spiral, or Rapid
Application Development (RAD)).
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. 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 - necessary to avoid solving wrong problem.
Phases:
1. 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.
2. 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.
3. 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, modifications to existing coding.
4. Assessment. The prototype is presented to the customer for review. Comments and suggestions are
collected from the customer.
5. 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.
6. 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 cornerstone for
the fully functional system.
Variation. A popular variation is called Rapid Application Development (RAD). It introduces strict time
limits on each development phase and relies heavily on RA tools (allow quick development).
2


Comparison of models
Besides the characteristics described earlier in this document, here I make a contrast of the models
by listing the positive and negative sides of each.
ISDM Advantages Disadvantages
Spiral Allows development to begin even when all the Involves higher cost - needs to be
system requirements are not known or understood iterated more than once
by the development team Not suitable for smaller projects
Good for large and critical projects Project success depends on the risk
Working software is produced early in the analysis phase - hence, it requires highly
lifecycle specific expertise in risk analysis
Large amount of risk analysis and incorporates Limited reusability
prototyping as a risk reduction strategy No established controls for moving from
Can incorporate Waterfall, Prototyping, and one cycle to another cycle, no firm
Incremental methodologies as special cases in the deadlines, lack of milestones
framework Management is dubious
Focus on early error detection and design flaws
Identical approaches for development and
maintenance
Incremental Potential exists for exploiting knowledge gained Very rigid and do not overlap phases
in early increments. Not all the requirements are gathered
Moderate control over the life of the project before starting the development; this
through the use of written documentation and the could lead to problems related to system
formal review and approval/signoff by the user and architecture at later iterations.
information technology management at designated The user community needs to be
major milestones actively involved throughout the project -
Stakeholders can be given concrete evidence of time of the staff, project delay.
project status throughout the life cycle. Communication and coordination skills
Helps to mitigate integration/architectural risks. take central stage in the development.
Allows delivery of a series of implementations Informal requests for improvement
that are gradually more complete and can go into after each phase may lead to confusion -
production more quickly as incremental releases controlled mechanism for handling
Gradual implementation provides the ability to substantive requests needs to be
monitor the effect of incremental changes, isolate developed.
issues and make adjustments before the Possible “scope creep (user feedback on
organization is negatively impacted each phase increases customer demands.
Prototype Benefits from user input No “Current” Documents
As a working model of the system is provided, Increases complexity of the overall
users get a better understanding of the system that system
is being developed Involves exploratory methodology and
Errors and risks can be detected at a much therefore involves higher risk.
earlier stage, as the system is developed using Involves implementing and then
prototypes repairing the way a system is built, so
Addresses: inability of many users to specify errors are an inherent part of the
their information needs; difficulty of systems development process.
analysts to understand the user’s environment Can lead to false expectations and
Can be used to realistically model important poorly designed systems.
aspects of a system during each phase of the Approval process and control is not
traditional life cycle strict.
Improves user participation in system Requirements may frequently change
development and communication among project significantly.
stakeholders

3


Here is another table that consists of the situations where each model is the most appropriate for
applying. The data is based on my previous analysis and additional data collected from the internet.
Spiral Incremental Prototype
Systems Real-time or safety-critical Web Information Systems Online systems (with
systems. (WIS) and event-driven extensive user dialog), or less
systems and leading-edge well-defined expert and
applications decision support system
Project size Large, high-cost projects Large projects, long duration Large projects (many users,
interrelationships, functions)
Risk Risk avoidance - high priority Integration and architectural Project risk for requirements
risks exist definition is high and should
be reduced
Requirements Requirement exists for strong Requirements are not well Functional requirements may
approval and documentation understood or are changing, change frequently and
control. no or little data for the significantly.
project
Resource No need to absolutely No need to absolutely
consumption minimize resource minimize resource
consumption consumption
Project team Project manager: skilled and Project manager and team
experienced. members: experienced,
team composition: stable.
Other High degree of accuracy Unclear project objectives
Project might benefit from a Pressure for immediate
mix of other development implementation
methodologies. Not fully knowledgeable user
Implementation has priority Future scalability of design is
over functionality not critical

Conclusion
Why there are so many System Development Methodologies is because all projects and systems
require its own road to run. And not each method will be suitable for another one. Selecting the
correct software development methodology with a proper cost-benefit analysis for a project can help
projects to release successfully, on time, and within budget. Once an organization has determined
which methodologies will work best for its projects it can ensure that there is a repeatable process
established that will ensure successful projects. Tackling a project blindly with no process defined will
result in undesirable product. Errors in the products are common, yet if the process is utilized
properly, they can be eliminated quickly. Choosing the better approach or simply understanding the
methodologies is important to ensure the right project/product is a result from the hard work.

4

Information systems development methodologies (autosaved)

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Information systems development methodologies (autosaved) (20)

Recently uploaded (20)

Information systems development methodologies (autosaved)