UNIVERSITY OF THE EAST

ACADEMIC VICE-RECTORATE

POSTGRADUATE STUDIES COUNCIL

POSTGRADUATE IN MANAGEMENT INFORMATICS

MONAGAS NUCLEUS

Methodologies for Software Development

Teacher: Masters:
Dr. Juan Oliveira Eng. Francisco Antequera
Eng. Jesus Mota
Eng. Jose Figueroa
Eng. Ruth Reyes
Eng. Yanired Urbina

Maturin, June 2018

INDEX
INDEX.........................................................................................................................................................1
INTRODUCTION........................................................................................................................................2
1. Definition of Software Development Methodology:................................................................................4
2. Classification of methodologies:..............................................................................................................6
2.1. Structured methodology:...................................................................................................................6
2.1.1. Process-oriented methodologies (Data flow):.............................................................................7
2.1.2. Methodologies oriented to Data Structures:................................................................................8
2.2. Object-oriented methodology:...........................................................................................................9
2.3 Methodologies for real-time systems................................................................................................14
2.4 Agile Methodologies........................................................................................................................15
2.4.1 SCRUM.....................................................................................................................................15
2.4.2. Extreme Programming (XP):....................................................................................................16
2.4.3. Crystal Clear:............................................................................................................................17
2.5. Methodology for web application development..............................................................................17
2.5.1 IWeb..........................................................................................................................................18
2.6 Methodologies for the construction of Multimedia Systems............................................................20
2.6.1 OOHDM....................................................................................................................................21
2.7. Methodologies by authors...............................................................................................................22
2.7.1. Kendall & Kendall....................................................................................................................23
2.7.2 Roger Pressman:........................................................................................................................26
2.7.3 James Senn................................................................................................................................29
2.7.4 Jonas Montilva..........................................................................................................................31
2.7.5 Llorens Fabregas.......................................................................................................................35
3. Models or approaches for software development...................................................................................38
3.1 Cascade............................................................................................................................................38
3.2 Evolutionary Development (Spiral)..................................................................................................40
3.3 Prototype Methodology....................................................................................................................42
CONCLUSIONS........................................................................................................................................43
WEB REFERENCES.................................................................................................................................44
BIBLIOGRAPHIC REFERENCES...........................................................................................................45

1
 INTRODUCTION

A methodology can be defined as the use of a set of procedures, techniques and tools in a
rational, orderly and organized manner in order to achieve a particular objective. In this sense, its
use contributes to researchers being able to achieve the goals that have been established, for
which they must follow a sequence of actions defined by the methodology they implement.

Software development does not escape the situation described above, that is, for the team
in charge of executing this activity it is important to determine the methodology that will be used
to successfully complete the development. From this point of view, the methodologies represent a
framework that allows structuring and controlling the entire system development process, from
planning to putting it into production.

It is important to highlight that software development methodologies are based on the life
cycle of information systems, which consists of several phases, depending on the author, but
which generally includes analysis, design, implementation and maintenance. From this point of
view, there are different methodologies proposed by authors such as James Senn, Roger
Preesman, Kendall & Kendall, Llorens Fabregas, Jonas Montilva, among others.

On the other hand, each methodology uses its own approach or model for software
development, which can be linear, iterative or mixed types. Within these models, the following
can be identified: waterfall, structured, spiral, prototype, Rapid Application Development (RAD)
and Extreme Programming (XP). Additionally, other approaches can be mentioned such as:
Object-Oriented Development and the Unified Development Process.

According to what was stated above, through this research work, the description of
different methodologies will be carried out, by authors, as well as approaches or models that can
be used to implement them within software development.

2
 1. Definition of Software Development Methodology:

The word Methodology refers to a set of logical procedures used to achieve one or more
objectives, or the study and choice of a pertinent and appropriately applicable method to achieve
a certain objective. These are based on a development model to define their entire structure, while
these become the control and administration element over a given process.

Therefore, it can be said that a Software Development Methodology consists mainly of

using various tools, techniques, methods and models for the development, implementation and
maintenance of a software product from the moment the need for the product arises until the
objective for which it was created is met. This type of methodology usually needs to be
documented so that the programmers involved in project planning fully understand the
methodology and, in some cases, the software life cycle that is intended to be followed.

What is sought when implementing a methodology is neatness, correctness and control at

each stage of the development of a program. Which will allow a systematic way of obtaining a
correct and error-free product.

This arises when the need to adapt computer systems to market demands arose, and it was
the programmer who, in response to these requirements, began the hard task of coding. This task
was not administered, supervised or managed in any way, so it was corrected as errors arose, both
logical errors arising from coding and those from Requirements requested by the client or end
user. In the 1970s, programs became increasingly complex, making the old technique of coding
and editing obsolete. This technique was based on ambiguous requirements and no specific
specifications. By not following project standards, the client or user only provided very general
specifications for the final product. It was scheduled, corrected, and rescheduled while the project
was in progress. The life cycle of this type of project ended when the specifications were met, not
only the initial ones that gave rise to the need for the program, but also all those that arose along
the way. Things like quality, satisfaction, competitiveness, benefits, etc. were not taken into
account. This is why it is so important, because if it is not developed based on a methodology, the
final result will be unpredictable and the progress of the project cannot be controlled.

3
 A software development methodology provides a framework for building applications
efficiently and rigorously, ensuring a product close to what is expected, also allowing us to divide
a large project into smaller modules called stages, and the actions that correspond to each of
them, it helps us define inputs and outputs for each of the stages and, above all, it standardizes the
way in which we will manage the project.

From a general point of view, the life cycle of a software can be considered to have five
stages, which are:

1. Start: The idea is born, the project objectives and the resources needed for its execution are
defined based on a preliminary study and the collection of current information. It involves
where you want to go, defining the problem.
2. Planning: A detailed plan is created to guide the management of the project, both in terms of
time and money; determination of requirements, development of a system prototype.
3. Implementation: Software development, system testing, the set of activities that make up the
realization of the product are agreed upon.
4. Put into production: Definition stage where it is presented to the client or end user, knowing
that it works correctly and responds to the requirements requested at the time.
5. Production control: control of the product, analyzing how the process differs or does not
differ from the original requirements and initiating corrective actions if necessary. When it is
decided that the product must be corrected, reference is made to small deviations from the
original requirements that may arise in the production environment.

Like any discipline, software development matures and over time generates new
mechanisms for its own optimization. From these efforts emerge software development
methodologies: frameworks used to structure, plan and control the development process of an
information system.

Although there is currently a great variety in programming methodologies. The reality is

that they are all based on certain generalist approaches that were created many years ago.

4
 2. Classification of methodologies:

Taking into account the definition studied above, where methodologies are not paradigms
or programming models that indicate patterns of behavior or simple structural ideas in the
development process, but rather, they are the way in which each task of the cycle must be carried
out for a specific project; it can be seen that there are two General Methodologies that have an
analogy in practice with the programming paradigms:

2.1. Structured methodology:

It proposes the creation of system models that represent the processes, flows and data
structure in a top-down manner, both in the system functions, in the data structure or in both
aspects. Each function to be performed by the system is broken down into small individual
modules. It is easier to solve small problems, and then piece together each of the solutions, than
to tackle one big problem.

The structured methodology identifies the functions of the system during analysis, while
during design it identifies the data. It uses data flow and data structure as a mechanism for
analysis, from which trends arise: Process-oriented methodologies (Data Flow) and Data
Structure-oriented methodologies.

The tools associated with these methodologies during the requirements and analysis
phases to describe the logical system are:

 Data flow diagrams. (DFD).

 Entity-Relationship Diagrams. (Definition of data stores for the DFD).
 Data dictionary.
 Functional descriptions.
 Structured natural language.
 Decision tables.

Among the disadvantages of structured methodologies are:

 They do not provide easy answers to changes in the problem domain.

5
  They are unsuitable for problem domains of a concurrent and real-time nature.
 They do not offer measures to guarantee the principle of information concealment.

2.1.1. Process-oriented methodologies (Data flow):

They use a top-down decomposition approach to evaluate the problem processes and the
data flows to which they are connected. Software engineering is based on the basic
input/process/output model of a system, whereby data is entered into the system and the system
responds to it by transforming it to obtain the outputs. Examples of this group of methodologies
include:

 Merise
 YSM (Yourdon Systems Method)
 SSADM (Structured Systems Analysis and Design Method)
 METRIC v.2.1
 METRIC v3.0
 Yourdon / by Marco.
 Gane / Sarson.
 Yourdon / Myers /Constantine.
 Page / Jones.
 SADT (Structured Analysis and Design Technique)
 RDD (Requirement Driven Design)

2.1.2. Methodologies oriented to Data Structures:

Also called “data-driven” methodologies, they are based on the idea that data, in addition
to flowing and having content, has a structure. Thus, the decomposition criterion is the data
structure.

Analysis activities begin by first evaluating the data and their interrelationships to
determine the underlying data architecture. Process orientation provides a management system
with indicators and facilitates decision-making based on reliable data. It allows the balanced
allocation of resources to activities. Analysis activities begin by first evaluating the data and their
interrelationships to determine the underlying data architecture.

6
 When this architecture is defined, the outputs to be produced and the processes and inputs
necessary to obtain them are defined. Data is the heart of the information system and is more
stable than the processes that act on it. The study of processes is derived from an initial definition
of the data (data model) consisting of the set of basic data entities and the interrelations between
them.

These methodologies are further divided into Hierarchical and Non-Hierarchical Data
Oriented Methodologies.

2.1.2.1 Hierarchical Data Oriented Methodologies:

The program control structure should be hierarchical and should be derived from the data
structure. The design process consists of first defining the input and output structures, and then
combining them to obtain the program structure. Finally, the procedural logic is arranged to fit
this structure. Logical design must precede and be separate from physical design. Some of these
methods are:

 JSP (Jackson Structured Programming)

 JSD (Jackson Structured Design)
 LCP (Logical Construction Program)
 DESD (Development of Structured Data Systems), also known as Warnier-Orr
methodology
 LCS (Logical Construction Systems)

2.1.2.2 Non-Hierarchical Data Oriented Methodologies:

Data is the essential part of the system because it is more stable than the processes that act
on it. They are a representation of an organization's data model consisting of a set of basic data
entities and the relationships between them. Processes derive from an initial definition of the
data. Within this type, the Information Engineering (IE) methodology by J. Martin and C.

7
Finkelstein, for which entities and processes are identified; subsequently a hierarchical structure
in the data is assumed; to subsequently represent the structure of the data using sequence,
selection and repetition. Finally, methods are defined to transform a hierarchical data structure
into a program structure.

2.2. Object-oriented methodology:

It is based on the integration of the two aspects of information systems (data and
processes) and unlike the structured methodology, these do not understand the processes as
functions, but rather create modules based on components, that is, each component is
independent of the other. This allows the code to be reusable. It is easier to maintain because
changes are localized to each of these components.

Object-oriented methodology guides the software construction process by using the

Unified Process and also allows software development professionals to express their work in
terms of diagrams by using the UML. There are two approaches in object-oriented
methodologies:

 Revolutionaries or pure: those who understand object orientation as a profound change

that makes structured methodologies obsolete.
 Synthetists or evolutionists: who think that structured analysis and design constitute the
basis for object-oriented development, and that elements of structured analysis and design
can be combined with those of object orientation.

Characteristics of the object-oriented methodology:

 It encompasses an architectural planning activity, which groups layers of objects by level

of abstraction.
 Identify relevant situations.
 Create a design prototype and validate the prototype by applying it to use cases.

Advantages of object-oriented methodology:

8
 Reuse. Classes are designed to be reused across many systems. To maximize reuse,
classes are built so that they can be adapted to other systems. A fundamental goal of
object-oriented techniques is to achieve massive reuse when building software.

 Stability. Classes designed for repeated reuse become stable, in the same way that
microprocessors and other chips become stable.

 The designer thinks in terms of the behavior of objects and not in low-level details.
Encapsulation hides the details and makes complex classes easy to use.

 A faster design. Applications are built from existing components. Many of the
components are built so that they can be tailored to a particular design.

 Integrity. Data structures (objects) can only be used with specific methods. This is
particularly important in client-server systems and distributed systems, where unknown
users might attempt to gain access to the system.

 Easier maintenance. The maintainer changes one class method at a time. Each class
performs its functions independently of the others.

 A suggestive screen interface for the user. A graphical user interface should be used so
that the user points to icons or items in a drop-down menu related to the objects. On
certain occasions, the user may see an object on the screen. Seeing and writing down is
easier than remembering and writing down.

 Interaction. Software from multiple vendors can work together. A provider uses classes
from others. There is a standard way to locate and interact with classes. Software
developed independently in third-party locations must be able to work together and
appear as a single unit to the user.

 Massively distributed computing. Global networks will use software directories of

accessible objects. Object-oriented design is the key to massively distributed computing.
Classes on one machine interact with classes somewhere else without knowing where
those classes reside. They receive and send object-oriented messages in standard format.

9
  Higher level of database automation. Data structures (objects) in object-oriented databases
are tied to methods that perform automatic actions. An OO database has built-in
intelligence, in the form of methods, while a basic relational database lacks this.

 Migration. Existing applications, whether object-oriented or not, can be preserved if they

are wrapped in an object-oriented container so that communication with it is via standard
object-oriented messages.

 Best CASE tools. CASE (Computer Aided Software Engineering) tools will use graphical
techniques for the design of classes and the interaction between them, for the use of
existing objects adapted to new applications. Tools should facilitate modeling in terms of
events, trigger forms, object states, etc. CASE OO tools should generate code as soon as
classes are defined and allow the designer to use and test newly created methods. Tools
should be designed to support maximum creativity and continuous design refinement
during construction.

Some object-oriented methodologies are:

Data-driven methodologies:

 OMT (Object Modeling Technique)

 Fusion

Responsibility-driven methodologies:

 RDD (Responsibility Driven Design)

 OBA (Object Behavior Analysis)

Use case driven methodologies

 Objectory
 Unified Process

State-led methodologies:

10
  Shlaer and Mellor Methodology

Methodologies that use UML notation:

 OPEN
 METRIC (which also supports structured notation)

The UML (Unified Modeling Language) is a great engineering achievement. Even with
its shortcomings and points of criticism, it is a very significant advance, a common language for
all software development professionals, whether or not they are interested, to express their ideas.

Differences between Structured and Object Oriented methodologies:

Structured Object Oriented

To represent a model of the real world, a
Direct correspondence with real-world objects.
transformation of the problem space is required.
The Design is highly influenced by the Data and processes are treated at the same level
decomposition criterion. of abstraction.
Each module represents an object or class of
Each module models a function or a data packet
objects.
They are not useful in problems of a concurrent
They are applicable to all types of problems
or real-time nature.

2.3 Methodologies for real-time systems.

Methodology that takes elements from other existing ones and proposes its own
mechanisms to partially solve problems such as the transition from the object model to the
process model and the assignment of priorities. The methodology is divided into four phases

11
divided into two distinct areas, functional and non-functional aspects. Objective orientation and
UML are used throughout the methodology. To take advantage of the benefits of formal methods,
such as simulation, validation and code generation, a formal semantics is proposed for some of
the dynamic aspects of UML, specifically actions and state machines. The proposed semantics
are based on metamodeling and the MML language.

These methodologies are highly time-dependent systems that process control-oriented

information. They control and are controlled by external events. They are characterized by:

 The process of many activities is carried out simultaneously.

 Priorities are assigned to certain processes.
 A task is interrupted before it is completed, in order to begin another task with higher
priority.
 There is communication between tasks.
 There is simultaneous access to common data.

To specify the requirements of these systems, new concepts must be included for:

 Interrupt handling.
 Communication and synchronization between tasks.
 Manage concurrent processes.
 Provide a timely and timely response to external events.
 Continuous or discrete data.

2.4 Agile Methodologies

Agile methodologies are flexible and can be modified to fit the reality of each team and
project. Agile projects are subdivided into smaller projects using an ordered list of features. Each
project is treated independently and develops a subset of features over a short period of time,
between two and six weeks. Communication with the client is constant to the point of requiring a
representative from the client during development. Projects are highly collaborative and adapt
better to changes; in fact, changing requirements are an expected and desired feature, as is

12
constant delivery and feedback to the client. Both the product and the process are frequently
improved. Some of the most popular agile methodologies are:

2.4.1 SCRUM

It is based on the empirical process control theory or empiricism. Empiricism maintains

that knowledge comes from experience and making decisions based on what is known. This
methodology employs an iterative and incremental approach to optimize predictability and risk
control, and delivers the project itself.

There are three fundamental pillars that support the control of the empirical process,
which are:

 Transparency
 Inspection
 Adaptation

The Scrum methodology describes four major events that make up each release:

 Sprint Planning Meeting

 Daily Scrum
 Sprint Review
 Sprint Retrospective

Scrum focuses on dividing the entire work into different sections or blocks that can be
addressed in short periods of time (1-4 weeks), which are called Sprints.

2.4.2. Extreme Programming (XP):

Extreme programming is a methodology based on a series of rules and principles that

have been used throughout the history of software development, applying each of them together
to create an agile process, in which emphasis is given to tasks that add value and remove
procedures that generate bureaucracy.

13
 Extreme programming is divided into twelve basic principles, which are grouped into four
main categories, including:

 Fine-Scale Feedback: This phase involves a number of principles such as testing, planning
process, customer on site, and pair programming.
 Continuous Process: Instead of batch, it allows for continuous integration, refactoring
(Evaluate the system design throughout the project and recode if necessary) and small
deliveries.
 Shared Understanding: This category defines criteria such as creating an easy layout,
CRC (Class, Responsibility, and Collaboration) cards, and creating the system metaphor
or complete story.
 Programmer wellbeing: This is governed by the philosophy that a tired, exhausted
programmer creates poor quality code, which is why it is recommended that developers
work 40 hours a week and do very few overtime hours.

2.4.3. Crystal Clear:

Crystal is a methodology in which color codes are established as part of the definition of
the complexity of the methodology. If it is darker, then the method is more cumbersome; the
more critical the system, the more rigor is needed. Additionally, Crystal suggests defining a color
for each project based on its criticality and size. There is no crystal methodology in general, but
there is a crystal methodology for each type of project.

Like the methodologies described above, Crystal is governed by principles that make its
use efficient, among which we can mention:

 Each project requires a different degree of compensation (Trade Off).

 The smaller the project, the better the form of coordination.
 Each project requires different means of communication.
 There must be effective feedback and communication, thus reducing problems with failed
deliveries.
 Sweet spots accelerate development. You must have capable people dedicated to their
work, who care about making deliveries on time and according to what the client requests.

14
2.5. Methodology for web application development

Applications developed for the Web have special characteristics that make the engineering
mechanisms used different from those used to develop traditional information systems.

In 1998, Roger Pressman moderated a virtual roundtable with representatives from

traditional software engineering and exclusively Internet-based software development. The
general conclusion of that roundtable was that applying an engineering process is never a bad
idea, but that it should be adapted to the requirements of continuous change and speed that are
always present in the Web development process. From this initiative, a new discipline called Web
Engineering (IWeb) was born.

2.5.1 IWeb

The Phases that make up this methodology are:

PHASE 1: Formulation.

Within this phase, the company's requirements and goals for building the Web application
are identified, which is achieved by applying data collection tools such as interviews,
questionnaires and direct observations.

PHASE 2: Planning.

This phase includes activities associated with estimating the overall cost of the project and
evaluating the risks that may affect the development of the application. Effective planning
requires consideration of issues such as defining the scope and resources of Iweb managers,
technical staff, and client; defining costs and timelines for management review; providing an
overall approach to Iweb development for all project-related personnel; and describing how
application security will be ensured.

PHASE 3: Analysis.

To carry out the analysis phase, the technical requirements for the Web application must
be established, and the content elements and graphic design requirements to be incorporated must
be identified. During this stage, four (4) types of analysis must be carried out:

 Content Analysis: This involves researching the full spectrum of content to be delivered
such as: text data, graphics, images, video and sound.

15
  Interaction Analysis: Detailed description of user interaction with the Web application.
 Functional Analysis: Detailed description of all the functions and operations that the
system will carry out.
 Configuration Analysis: Description of the environment and infrastructure where the Web
application resides.

PHASE 4: Engineering.

During this phase, the designs necessary for the operation of the application are made,
these designs are:

 Architectural Design: Definition of the global hypermedia structure for the Web
application, and the application of design configurations and construction templates to
popularize the structure and achieve its reuse.
 Content design considers the detailed structure and format of the information content to
be presented.
 Navigation Design: Define the navigation routes that allow the user to access the content
and services of the application.
 User Interface Design: The design identifies the objects and actions of the interface and
then creates a screen layout that will form the basis of the user interface prototype.
 Data Structure Design: The structures that will allow the storage of data that will be
entered or stored within the application are designed.

PHASE 6: Page generation.

This is the phase that includes the construction of all the web pages where the application
will be presented. To this end, extensive use is made of automated tools that allow the creation of
these pages.

PHASE 7: Testing and Customer Evaluation.

Software must be tested to discover as many errors as possible before delivery to the
client. To this end, the internal logic of the Web components must be checked and the input and
output domains of the program must be verified to discover errors in its functionality, behavior
and performance.

Once its normal operation has been validated, it is made available to users.

16
2.6 Methodologies for the construction of Multimedia Systems

Building large hypermedia applications is extremely difficult, and there is no single

methodology that perfectly suits this type of software, tempting developers to skip the structural
design of the application. This situation results in the development of low-quality software that is
susceptible to subsequent corrections.

Typically, the development of Hypermedia Systems is usually done using tools directly at
the implementation level, neglecting the important prior process of analysis and design of the
structural aspects of navigation and interface. However, in recent years there has been a tendency
to consider hypermedia development with a software engineering process approach, so different
methodologies have already been proposed, such as:

 HDM (Hypertext Design Model)

 OOHDM (Object Oriented Hypermedia Design Method)

These methodologies consider a design prior to the construction of the system and offer a
series of techniques, more or less formal, to collect in different abstract models the specifications
of the hypermedia system to be developed. Of these, the most up-to-date is the OOHDM since it
takes many definitions of the HDM as a reference, in addition to being based on the object-
oriented paradigm.

2.6.1 OOHDM

This methodology proposes the design of an application of this type through five phases
that are developed in an iterative manner. These phases are:

Phase 1 - Requirements Determination

The tool on which this phase is based is the use case diagrams, which are designed by
scenarios with the purpose of clearly obtaining the requirements and actions of the system.

Phase 2- Conceptual Design

An object-oriented model is built that represents the application domain using object-
oriented techniques. The main goal during this phase is to capture the semantic domain of the

17
application to the extent possible, taking into account the role of the users and the tasks they
perform. The result of this phase is a model of related classes

Phase 3- Navigational Design

In OOHDM an application is viewed through a navigation system, for which the

application must be designed taking into account the tasks that the user is going to perform on the
system. To do this, we must start from the conceptual scheme developed in the previous phase.
Furthermore, it must be taken into account that different navigational models can be developed
on the same conceptual scheme (each of which will give rise to a different application). To define
this design the following navigational classes must be considered:

 Nodes: Nodes are basic information containers for hypermedia applications. These will
contain attributes of basic types (where types like images or sounds can be found) and
links.
 Links: Links reflect the navigation relationship that the user can explore.
 Access Structures: these act as indexes or dictionaries that allow the user to quickly and
efficiently find the desired information. Menus, indexes or route guides are examples of
these structures.
 Context Class: This is another special class that serves to complement the definition of a
navigation class. For example, it is used to indicate what information is accessible from a
link and where it can be reached.

Phase 4- Abstract Interface Design

Once the navigational structure has been defined, it must be prepared so that it is
perceptible to the user and this is what is attempted in this phase. This involves defining which
interface objects the user will perceive, and in particular the path in which the different
navigation objects will appear, as well as defining which interface objects will act in navigation,
the way multimedia objects will be synchronized and the transformation interface.

Phase 5 - Implementation

Once the conceptual model, the navigation model and the abstract interface model have
been obtained, all that remains is to transfer the objects to a specific programming language, in
order to obtain the executable implementation of the application.

18
2.7. Methodologies by authors

Many authors, based on the systems development life cycle (SDLC), have structured a
series of phases, which applied sequentially, contribute to software development. Below are some
of them:

2.7.1. Kendall & Kendall

Within his work “Systems Analysis and Design” he maintains that the SDLC “is a phased
approach to analysis and design whose main premise is that systems are best developed using a
specific cycle of analyst and user activities.”, for which they define a total of 8 phases, which are
briefly explained below.

PHASE I: Identification of problems, opportunities and objectives

As indicated by the statement of this phase, the fundamental purpose of developing it is to

identify the problems, which can be discovered by the systems analyst or, in some cases, by other
actors in the organization, this problematic situation must be examined and detailed as precisely
as possible, in order to evaluate the opportunities or situations that can be improved through the
use of information systems, which point towards effective control within the organization, to
finally describe the objectives that the company intends to achieve to solve the problem and
which of course contribute to the achievement of the goals and objectives of the company.

The staff actively involved in the development of this phase is represented by users,
analysts and system administrators. The activities that should be developed during this phase,
according to its authors, are the following:

 Direct observation of the environment

 Interview application to collect information.
 Synthesize the information collected to build objectives
 Estimate the scope of the project
 Identify whether there is a need, problem or argued opportunity
 Documenting results
 Study the project risks
 Submit a road report

19
 Once the team presents the feasibility report, it is up to the organization's administration
or management to decide whether to proceed or cancel the project.

PHASE II: Determining information requirements

During this phase of systems development, the systems analyst must collect all the
information associated with the data that users require to carry out their activities. By
implementing tools such as interviews, questionnaires, direct observation, evaluation of existing
data, among others, the team involved in software development must provide answers to the
following key questions to understand in detail the system being studied:

 Who? Determine personnel involved

 That? What is the activity of the organization?
 Where? Consider the environment within which the activities are carried out
 When? Analyze the opportune moment for the execution of the activities
 As? Know how current work procedures are carried out.

PHASE III: Analysis of system needs

During the development of this phase, all the products obtained during the previous
phases must be evaluated to define the inputs, processes and outputs of the system functions.
Using tools such as Data Flow Diagrams (DFD), the defined functions can be obtained in a
graphical and structured manner. Additionally, based on the DFDs, a data dictionary is created
where all the data used in the system is described. To complete the development of this phase, a
proposal for the system must be prepared, as well as a cost/benefit analysis of the possible
alternatives and recommendations offered in this regard.

PHASE IV: Recommended system design

For this phase, the development team must define the entire system through a logical
design, which includes:

 User data entry interfaces, for which procedures must be defined to ensure correct data
entry into the system, i.e. avoid duplications, erroneous data, etc.; as well as design
efficient input forms or screens.
 Design of files and databases, within which valuable information for the organization will
be stored.

20
  Design of system outputs (screens, reports, graphs, etc.)
 Design of procedures that allow backups to be made to protect the system and the
information associated with it.
 Program specification packages, which include general schemes for data input and
information output as well as processing details.

PHASE V: Software development and documentation

This is the phase that directly involves developers or systems programmers, since it is
during this phase that the procedures to be developed are evaluated and their corresponding
coding is carried out (in the selected programming language) as well as the elimination of
syntactical errors that could be generated; additionally, as indicated by Kendall & Kendall, the
necessary documentation must be prepared: "Among the structured techniques to design and
document software are structural diagrams, Nassi-Shneiderman diagrams and pseudocode.
During this phase, the analyst works with users to develop effective documentation for the
software, such as procedure manuals, online help, and websites that include answers to frequently
asked questions in “readme” files that will be integrated into the new software.”

PHASE VI: Testing and maintenance of the system

Although as the lines that make up the system are coded, tests are carried out regarding its
operation, the authors (Kendall & Kendall) define this phase as a way of subjecting the system to
tests, before it is delivered to the users, these tests are initially carried out with fictitious data and
then with real data to determine any problems or deficiencies that the system presents.

Additionally, during this phase, system maintenance begins and will continue for as long
as the system is active within the organization. Some of the activities that should be developed in
this phase are:

 Define a schedule for performing system testing.

 Develop an instrument that allows the information system to be evaluated.
 Prepare a summary of the system test results.
 Develop a maintenance plan, defining the frequency and duration of the activities that
must be carried out on the system to ensure its operation.
 Prepare a list of operations that could undergo code modifications.

21
PHASE VII: Implementation and evaluation

This phase completes the system development cycle proposed by Kendall & Kendall. The
implementation of the system includes the installation of all the necessary equipment to ensure
the operation of the software, as well as training users to manipulate the system.

Although evaluation is mentioned as part of this phase, it is necessary to highlight that

during the execution of all phases of the methodology, the system is subject to constant
evaluation of its requirements, needs, designs, developments and tests; however, during this stage
the adaptability of users to the new system must be evaluated.

2.7.2 Roger Pressman:

This author establishes the following methodological stages to develop information

systems:

Stage I: Analysis

Pressman establishes that the task of requirements analysis is a process in which the scope
of the software must be defined in detail, as well as creating models of the data requirements,
information flow and control, and the operational behavior of the system. Through the
development of this stage, the developer or developers will be able to specify the function and
performance of the software, as well as determine the interface of the software with other
elements of the system and establish the restrictions that it must meet. This stage is subdivided
into five (5) areas:

 Problem recognition: Identify and acknowledge the basic elements of the problem as seen
by users.
 Evaluation and synthesis: Define all externally observable data objects, evaluate the flow
and content of information, define and elaborate all software functions, understand the
behavior of the software in the context of events that affect the system.
 Modeling: Generating models of the system such that the flow and control of data, as well
as the operational behavior of the system and the content of the information, can be
understood more accurately.
 Specification: make a formal statement and/or description of the software.
 Review: consists of carrying out a general check on the entire process.

22
Stage II: Design

The design phase, as presented by Pressman, is concerned with “establishing data

structures, general software architecture, interface representations, and algorithms. The design
process translates requirements into a software representation”

In general, this phase represents the first of the technical activities that must be carried out
during the software engineering process (the other two are coding and testing). At the end of this
stage, there must be a data design, which consists of transforming the information domain model
developed during the analysis phase; an architectural design, through which the relationships
between the different elements that make up the program must be defined; and an interface
design that must describe how the system communicates with itself, with other systems and with
its users and operators.

Stage III: Coding

This phase is also known as the code generation phase, which consists of translating all
the designs defined during the previous phase in such a way that they can be understood and
executed by the computers where they will be implemented. To do this, the programming
language that the development team deems most appropriate will be used, or in the event that the
organization has some standardization, it must be adapted to the organizational conditions.

Stage IV: Test

Although, during the coding phase, developers perform functional tests on the generated
processes, the testing phase should formally begin as soon as the code has finished being
generated. According to Pressman, “The testing process focuses on the internal logical processes
of the software, ensuring that all statements have been tested, and on the external functional
processes, that is, performing tests to detect errors.” During this phase, the system must be tested
with real data as well as with interaction with other systems in order to obtain as much feedback
as possible to discover any abnormality in its operation in order to correct the deviation.

Stage V: Maintenance

This stage is of vital importance since the implemented software must have the necessary
modularity so that adaptations can be made to it, allowing new modules to be incorporated
without affecting its operation.

23
2.7.3 James Senn

This author focuses his attention on the Life Cycle and Development of the System, for
which reason he proposes the execution of the following stages:

Stage 1. Preliminary Investigation

The development of this stage includes the following activities:

 Clarification of the request: in this particular case, it must be determined as clearly and
precisely as possible what the request is from the users or organization that requires the
development of an Information System.
 Feasibility Study: Once the request has been clarified, the author proceeds to determine
whether it is feasible to develop the system. To do this, the author suggests carrying out a
study that covers technical feasibility (determining whether the system can be developed
with the existing personnel, hardware and software capabilities within the organization or,
in the case of requiring technical resources, what are the possibilities of acquiring them);
economic feasibility (investigating whether the costs that will be incurred are justified
with respect to the benefits that will be obtained by implementing the system); and
operational feasibility (investigating the use that will be given to the system to obtain
benefits.

Stage 2. Determining System Requirements

During this stage of obtaining all the necessary information regarding the processes that
are executed within the organization and that relate to the system that is intended to be developed,
to collect the information you can do interviews, surveys, direct observations, questionnaires,
study of manuals and reports; the purpose of this collection of information is to know and
understand the process in its entirety, in order to establish the characteristics that the new system
should have, that is, to identify input data, processes that should be executed and output
information that the system should emit.

Stage 3. System Design (Logical Design)

When designing the system, the aim is to respond to how the system will meet all the
requirements identified during the previous phase. To this end, it is necessary to indicate which
data are input, calculated and which must be stored, therefore the data structures as well as the

24
devices where they will be stored must be defined; in the same way, it is necessary to design how
the data is processed and how the information will be output, for this purpose the necessary
diagrams must be prepared (DFD, Table Designs, Input Screens, Output Screens, Reports, etc.)
All the information defined within this phase is of vital importance for the execution of the
following stage.

Stage 4. System Development (Physical Design)

During this phase, all the programs necessary for the software to execute the functions
that were previously defined are coded. Additionally, the necessary documentation for the
programs must be prepared, that is, their coding must be explained, emphasizing the function that
each of the developed modules fulfills in order to facilitate the tasks when testing and
maintaining the system.

Stage 5. System Testing (Physical Design)

Once the previous stage is completed, the entire system is tested, that is, the system is
used experimentally to ensure that it works according to the required specifications and that it
also fully executes the functions requested by users. The data used for testing may be fictitious
and/or real. During the execution of this phase, users are invited to use the system in order to
observe that they use it in the necessary way before proceeding to implement it within the
organization.

Stage 6. Implementation and Evaluation

Once the system tests are completed, the implementation process begins, which consists
of installing the application within the organization so that it can be used by all users who require
it.

Additionally, an evaluation of the system must be carried out in order to identify its
strengths and weaknesses. When evaluating software, the following should be considered:

 Operational evaluation: Assess how the system works (ease of use, response time,
formats, reliability, and level of utilization).
 Organizational impact, measuring organizational benefits (revenue, profit, efficiency,
competitive impact)

25
  Development Performance: Evaluate the development process (time, effort, costs, and any
other project development criteria)

2.7.4 Jonas Montilva

This author designed the MEDSI methodology (Structured Methodology for the
Development of Information Systems), which is structured in 8 phases:

Phase 1. Project Definition

When needs are identified within an organization that are considered to be able to be
covered through the implementation of an information system, then the initial phase of this
methodology is executed, which consists of defining the project, for which the development of
the system must be justified as well as carrying out the necessary feasibility study, so that if it is
feasible, proceed with the planning of the project.

Within this phase, activities such as:

 Preliminary Study of the project: consists of recognizing and formulating the problem,
that is, generally diagnosing the current situation to which the use of an information
system is intended to be applied.
 Feasibility Study: for this purpose, the current system or situation must be evaluated to
establish, in general terms, what the requirements of the new system are; additionally, a
technical, economic and psychosocial feasibility study must be carried out.
 Project planning: With regard to project planning, it is important to develop the general
plan taking into account each of the phases that must be executed. Additionally, at this
time the system development group must be selected.

Phase 2. Context Analysis

After defining the project and evaluating the feasibility report, it is decided whether the
project is feasible. In this case, the context analysis must be initiated, that is, an evaluation of the
environment within which the system will operate. To do this, a documentary analysis of the
current system is carried out, compiling all the documents that exist in this regard, in order to
subsequently proceed to organize and study them in order to become familiar with the system
before carrying out a formal analysis of the current system.

26
 Additionally, when carrying out the context analysis, a model of the current system must
be constructed, if it does not exist, as well as identifying any problematic situation that influences
its operation.

Phase 3. Definition of Requirements

During this phase, all the requirements that the new system must satisfy must be
determined together with the system users, and the functions, restrictions and quality attributes of
the system must also be established.

The requirements that the new system must satisfy must be focused on information
requirements, functional requirements, development and operation restrictions, as well as system
attributes.

Phase 4. Preliminary Design

The purpose of developing this phase as indicated by Montilva is "To develop a

preliminary design of the information system that satisfies the requirements, restrictions and
attributes established in phase 3. The preliminary design consists of a prototype or general
physical model that outlines the human-machine interaction of the information system and
describes, in general terms, its automated processes.”

To this end, it is necessary to define prototypes that can satisfy the functional
specifications of the new system, and then carry out the prototype section based on a cost-benefit
analysis.

Phase 5. Detailed Design

Starting from the prototype selected during the previous phase, a detailed design of the
new system is carried out, for which it is necessary to design the Man-Machine interfaces, that is,
the interactions that users will have with the system through input/output screens, as well as
reports and reports. Additionally, the data design must be carried out, which includes both the
logical and physical design of the database.

On the other hand, all the programs and procedures that must be executed by the new
system must also be designed, for which the structure that it will have must be defined, in order
to design each of the modules of the structure. In addition, system documentation as well as any
manual procedures that need to be executed must be designed.

27
 Within this phase, the development of a test plan is proposed, which must establish the
different tests that must be carried out; those responsible for designing, building and executing
them; identification of times, costs and resources necessary to carry them out; the tools, methods,
techniques and procedures that must be used; and the criteria for declaring each test as successful.

Phase 6. System construction

During this phase, the system is built based on all the specifications declared during the
design phase. To do this, all the programs that make up the modules structured during the
previous phase must be coded. In addition, the entire database is built and the necessary
validations and tests are carried out for each of the modules or subsystems that make up the new
system.

Phase 7. System Testing

This phase is performed immediately after subsystem testing. During this, the group tests
the entire information system in order to determine discrepancies or anomalies between the newly
constructed information system and the objectives and requirements initially established with the
system users.

Additionally, during this phase, preparation for implementation is carried out, for which a
plan is drawn up with all the activities and tasks that the development group must carry out
during the implementation of the system within the organization.

Phase 8. Implementation of the system

The last phase of the MEDSI methodology consists of the implementation of the system,
for which the conversion of the current system to the newly developed system must be carried
out, that is, its implementation. In addition, the necessary training must be provided to users so
that they can interact with the system in the most efficient way possible. Finally, the system is
delivered to the users and the group that will be in charge of its maintenance, along with the Final
Report of the project.

2.7.5 Llorens Fabregas

28
 Fabregas, is based on the Information Systems Development Cycle to define the stages
that make up this methodology, which consists of 5 phases.

Phase I. Requirements

During this phase, a model of the area studied is developed, within which each of the
processes carried out must be represented, as well as the information used by them and the
political rules of the organization related to these processes. This model will allow the
interrelations between processes and data within the organization to be visualized, with the aim of
developing a plan for the information system capable of guiding the development of the system
itself and allowing support to the area under study to meet its objectives. This system plan must
contain:

 The systems required by the business area, as well as its databases and the information
that they will exchange or share.
 Detailed description of each system and application including its functional objectives and
design bases.
 All hardware and software that will be used for the operation required by the business
area (including networks)
 Development methods for each system such as package acquisition, new development or
updates
 Outline of current business area problems and possible improvements that can be made to
each system
 Analysis of the benefits expected to be derived from the systems that make up the
architecture

Phase II. Analysis / Design

Once all the requirements have been identified during the previous phase, the architectural
design of the system is carried out. This architectural design includes two elements: the data and
the processes, which must be analyzed from a conceptual vision to a physical vision of the same.
The activities contemplated in this phase are:

29
  Analyze and Design Process: The business operations and operating requirements defined
in the first phase are taken into account in order to determine how the system should
function.
 Analyze and Design Data: With the information requirements defined in phase I, the
different data models must be organized to help design the databases needed for the
system to operate according to the operating model.
 Design and Organize the Physical Components: All physical components such as
(screens, database) that make the system function according to the operating model.
 Planning Physical Component Development: Activity of planning how physical
components can be built and implemented quickly and productively.

Phase III. Construction

To build the system, the following activities must be carried out:

 Infrastructure Development: Develop and organize the infrastructure that allows software
construction tasks to be completed in the most productive way possible.
 Development of Interactive Design Units: Interactive design units are procedures that are
carried out or executed through a dialogue between the user and the system. Therefore,
the tasks that the design unit must carry out must be specified in detail, as well as
developing its components and performing unit tests and integration tests at the design
unit level.
 Development of Batch Design Units: Batch design units are those procedures that are
carried out in an automated manner, but in which a dialogue is not established between
the user and the analyst, but rather it involves groups of transactions that are fed to the
computer at one time. In this sense, specifications must be prepared using techniques such
as flowcharts, structure diagrams, decision tables, etc., with the intention of making the
specification as clear as possible so that the programmer can understand it and therefore
be able to program it.
 Development of Manual Design Units: This activity includes tasks that are executed
manually, with the purpose of developing all the administrative procedures that will
surround and govern the use of the computerized components developed in the design and
construction phase.

30
Phase IV. Evidence

Once all the design units have been developed and tested independently, the overall
system testing is carried out to ensure that the software does not fail and that it fulfills all the
specified functions. In this sense, several levels of proof are established:

 Functional: Testing from the functional requirements point of view.

 System: Testing from the point of view of system quality and performance levels.
 Integration: Interface testing.
 Technical Acceptance: Extreme conditions driving test.

If all the tests carried out at the levels established in the previous phase are satisfactory,
then the files, database and tables of the new system are loaded, in order to begin the acceptance
process, which will remain in operation for a period called "Acceptance Period". Once this period
has ended, the system becomes official within the organization.

Phase V. Production and Maintenance.

The production stage ensures that the system works correctly. To do this, new tests are
carried out, the results are re-evaluated and refinements are made to the system. The necessary
changes must be introduced without affecting the users, and maximum user confidence must be
achieved.

On the other hand, according to Fabregas, “During the maintenance phase, all policies and
procedures are put into practice to guarantee the continuous operation of the systems and to
ensure their effective use, so that they become a true support tool for achieving the company's
strategic objectives.”

3. Models or approaches for software development

3.1 Cascade.

In this model each stage represents a unit of development, therefore, the next stage starts
as soon as the previous one has finished. This is considered the most traditional method of
explaining the software development process within software engineering. It is applied to projects
with clear goals and requirements that demand up to a maximum of 100 hours of development. It
is therefore a great option for small projects where all aspects of the software development

31
process are known in advance, but it is a poor solution for complicated projects, as it is a rather
inflexible model. The stages that comprise it can be seen in figure 1. Where it can be seen that at
the end of the process (Software operation and maintenance) depending on its results, it is
possible to return to the execution of one of its phases to resolve any irregularities detected
during the operation of the system.

Figure 1. The cascade model

Source: Ian Sommerville (Software Engineering. 2005)

Requirements analysis and definition: All services, restrictions, objectives and goals associated
with the system are defined based on interactions with users. Then, all the needs of the software
to be developed are defined in detail.

System and software design: During the process, two types of designs are carried out: a high-
level design, which describes the solution, identifying the major modules that make up the system
and the relationships between them; and a detailed design, in which the algorithms and the
organization of the code are defined for later implementation.

Implementation and unit testing: During this stage, the software design is carried out, that is, the
source code is implemented, making use of prototypes as well as tests and trials to correct errors.
Reusable libraries and components are created within the same project to make programming a
much faster process.

32
System integration and testing: Once all the units or modules of the system have been developed
and tested, then all these subsystems are integrated into one to perform the tests as a complete
system to ensure that the software requirements are met, and then delivery to the client.

Operation and maintenance: In this phase the system is installed and put into practical operation.
Maintenance involves correcting errors not discovered in previous stages, as well as improving
the implementation of system modules.

3.2 Evolutionary Development (Spiral).

This model is an adaptation of the waterfall model for when the requirements are not
completely clear. The strategy to follow with the incremental model is to establish several
deliveries of the product, each one with greater functionality than the previous one. Therefore,
when the first increment is finished, the next one begins to be developed, and so on until the
product is finished. This allows the result to be divided into different packages and to see the
result evolve with each delivery.

This model is based on the idea of developing an initial implementation, exposing it to

user feedback and refining it through the different versions that are generated until a suitable
system is developed, as shown in Figure 2.

33
 Figure 2. Spiral Model

Source: Roger Pressman (Software Engineering. A practical approach, 2005)

The development begins a Communication stage, through which contact is established

with the users in order to determine the system requirements. Next, Planning is carried out, for
which the programming of activities to be executed is carried out taking into consideration a risk
analysis in this regard. Subsequently, a Modeling phase is carried out, during which an analysis
and design of the components that will make up the system is performed. The Construction
stage involves the activities of generating the software source code, as well as carrying out the
relevant tests. Finally, during the Deployment phase, the product is delivered to the user, to
receive the associated feedback. According to Pressman, “The first circuit around the spiral
results in the development of a product specification; successive turns are used to develop a
prototype and then increasingly sophisticated versions of the software. Each pass through the
planning region results in adjustments to the project plan. Cost and schedule of activities are
adjusted based on feedback obtained from the client after delivery. In addition, the project
manager adjusts the planned number of iterations required to complete the software.”

3.3 Prototype Methodology

It is a specialized development procedure that allows developers the possibility of being

able to only make a sample of the solution in order to validate its functional essence for clients,
and to make any fundamental changes before creating the authentic final solution.

Apart from this, the major advantage of opting for this approach is that it gives a clear
idea about the functional process of the software, reduces the risk of failure in a software
functionality and assists well in requirements gathering and overall analysis.

34
 CONCLUSIONS

 A software development methodology consists of using various tools,

techniques, methods and models for the development, implementation
and maintenance of a product from the moment the need arises until the
objective for which it was created is met.

 Software development methodologies can be approached from two main

points of view: structured and object-oriented. The latter can be applied to
any type of problem, as they establish a direct correspondence with real-
world objects. Data and processes are treated at the same level of
abstraction, and each module is represented and treated as an object or
class of object.

 There is a wide variety of methodologies for software development, some can be applied to
the development of systems in general, however, there are others that emerged as alternatives
to be applied to particular systems, such as the IWEB methodology (Web Engineering), for
the development of web-based systems; the OOHDM (Object Oriented Hypermedia Design
Method), which focuses on the development of multimedia systems. In this sense, in order to
use a methodology, the nature of the system to be developed must be previously evaluated, in
order to subsequently select the one that best suits it.

 Although there is a wide variety of general and specific methodologies, all of them, in the
description of their phases, cover the four main stages that make up the Systems Development
Life Cycle, which are none other than Analysis, Design, Development and Implementation of
the system.

35
 WEB REFERENCES

https://sisteminformacii.wikispaces.com/METODOLOG%C3%8DA+DE+KENDALL+
%26+KENDALL

https://sistemasdeinformacion2.wikispaces.com/Metodologia%20de%20Roger%20Pressman

https://sistemasdeinformacion2.wikispaces.com/METODOLOG%C3%8CA%20DE%20JAMES
%20A.SENN

http://www.monografias.com/trabajos14/medsi/medsi.shtml

https://vdocuments.site/documents/fases-de-medsi.html

https://www.freelancer.es/community/articles/process-del-desarrollo-software

https://sites.google.com/site/adai6jfm/home/clasificacin-de-las-metodologas

https://analistadesistema5.blogspot.com/2013/12/metodologias-para-desarrollo-de-software.html

https://prezi.com/wnm5gshccab9/clasificacion-de-las-metodologias-de-desarrollo/

https://hablemosdesoftware.wordpress.com/2014/10/03/metodologias-de-desarrollo-de-software/

https://okhosting.com/blog/metodologias-del-desarrollo-de-software/

https://sites.google.com/site/adai6jfm/home/clasificacin-de-las-metodologas

https://ingenieriadesoftware1elvisacuna.blogspot.com/2015/12/clasificacion-de-las-
metodologias-de.html

http://www.eumed.net/libros-gratis/2009c/587/Metodologias%20y%20Tecnologias%20Actuales
%20para%20la%20construccion%20de%20Sistemas%20Multimedia.htm

https://metodologiaiweb.blogspot.com/

36
 BIBLIOGRAPHIC REFERENCES

Kendall & Kendall: Systems Analysis and Design. Third Edition

Someerville, Ian. Software engineering. Seventh Edition.

Pressman, Roger. Software engineering. A practical approach. Seventh Edition

Seen, James. Analysis and Design of Information Systems. Second Edition.

37