Systems-Development Life Cycle

This methodology was first developed in the 1960s to manage the large software projects associated with corporate
systems running on mainframes. It is a very structured and risk-averse methodology designed to manage large
projects that included multiple programmers and systems that would have a large impact on the organization.

Various definitions of the SDLC methodology exist, but most contain the following phases.

1. Preliminary Analysis. In this phase, a review is done of the request. Is creating a solution possible? What alternatives exist?
What is currently being done about it? Is this project a good fit for our organization? A key part of this step is a feasibility
analysis, which includes an analysis of the technical feasibility (is it possible to create this?), the economic feasibility (can we
afford to do this?), and the legal feasibility (are we allowed to do this?). This step is important in determining if the project
should even get started.
2. System Analysis. In this phase, one or more system analysts work with different stakeholder groups to determine the specific
requirements for the new system. No programming is done in this step. Instead, procedures are documented, key players are
interviewed, and data requirements are developed in order to get an overall picture of exactly what the system is supposed to
do. The result of this phase is a system-requirements document.
3. System Design. In this phase, a designer takes the system-requirements document created in the previous phase and develops
the specific technical details required for the system. It is in this phase that the business requirements are translated into specific
technical requirements. The design for the user interface, database, data inputs and outputs, and reporting are developed here.
The result of this phase is a system-design document. This document will have everything a programmer will need to actually
create the system.
4. Programming. The code finally gets written in the programming phase. Using the system-design document as a guide, a
programmer (or team of programmers) develop the program. The result of this phase is an initial working program that meets
the requirements laid out in the system-analysis phase and the design developed in the system-design phase.
5. Testing. In the testing phase, the software program developed in the previous phase is put through a series of structured tests.
The first is a unit test, which tests individual parts of the code for errors or bugs. Next is a system test, where the different
components of the system are tested to ensure that they work together properly. Finally, the user-acceptance test allows those
that will be using the software to test the system to ensure that it meets their standards. Any bugs, errors, or problems found
during testing are addressed and then tested again.
 6. Implementation. Once the new system is developed and tested, it has to be implemented in the organization. This phase
includes training the users, providing documentation, and conversion from any previous system to the new system.
Implementation can take many forms, depending on the type of system, the number and type of users, and how urgent it is that
the system become operational. These different forms of implementation are covered later in the chapter.
7. Maintenance. This final phase takes place once the implementation phase is complete. In this phase, the system has a structured
support process in place: reported bugs are fixed and requests for new features are evaluated and implemented; system updates
and backups are performed on a regular basis.

https://www.viewnext.com/el-ciclo-sdlc-en-7-fases/

https://ungoti.com/es/servicios/desarrollo-de-software/sdlc/

Ventajas y desventajas:

https://www.intellectsoft.net/blog/what-is-system-development-life-cycle/#:~:text=Advantages%20of%20Structured%20SDLC%3A,Involves
%20comprehensive%20and%20explicit%20steps

https://existek.com/blog/sdlc-models/

https://eternalsunshineoftheismind.wordpress.com/2013/03/03/advantages-and-disadvantages-of-sdlc/

RAD:

https://blog.capterra.com/what-is-rapid-application-development/#:~:text=Rapid%20Application%20Development%20(RAD)%20is,strict
%20planning%20and%20requirements%20recording.

https://www.guru99.com/what-is-rad-rapid-software-development-model-advantages-disadvantages.html
Watefall method:
El desarrollo en cascada es un procedimiento lineal que se caracteriza por dividir los procesos de desarrollo en sucesivas fases de
proyecto. Al contrario que en los modelos iterativos, cada una de estas fases se ejecuta tan solo una vez. Los resultados de cada una de
las fases sirven como hipótesis de partida para la siguiente. El modelo de cascada se utiliza, especialmente, en el desarrollo de software.

La versión original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en
1985.

La presente metodología está compuesta por las siguientes fases:

1. Análisis: planificación, análisis y especificación de los requisitos.

2. Diseño: diseño y especificación del sistema.
3. Implementación: programación y pruebas unitarias.
4. Verificación: integración de sistemas, pruebas de sistema y de integración.
5. Mantenimiento: entrega, mantenimiento y mejora.

Ventajas

Una estructura sencilla gracias a unas fases de proyecto claramente diferenciadas.

 Buena documentación del proceso de desarrollo a través de unos hitos bien definidos.

Los costes y la carga de trabajo se pueden estimar al comenzar el proyecto.

 Aquellos proyectos que se estructuran en base al modelo en cascada se pueden representar cronológicamente de forma sencilla.

Incovenientes:

Por norma general, los proyectos más complejos o de varios niveles no permiten su división en fases de proyecto claramente
diferenciadas.

Poco margen para realizar ajustes a lo largo del proyecto debido a un cambio en las exigencias.

El usuario final no se integra en el proceso de producción hasta que no termina la programación.

En ocasiones, los fallos solo se detectan una vez finalizado el proceso de desarrollo.
Desarrollo Rápido de Aplicaciones (RAD)
El desarrollo rápido de aplicaciones es una metodología de desarrollo de sistema que da prioridad a las entregas e iteraciones rápidas
de prototipos. En la presente metodología, se tiene más en cuenta el uso del software y la retroalimentación del usuario que la
planificación y el registro de los requisitos.

El presente enfoque fue inventado por James Martin en 1991.

Se compone a través de los siguientes pasos:

1. Definir y concretar los requisitos del proyecto

Durante esta fase, las partes implicadas deben trabajar juntas para definir y concretar los requisitos del
proyecto, como los objetivos, las expectativas, los plazos y el presupuesto. Una vez que se hayan establecido
y definido claramente todos los aspectos de los requisitos del proyecto, es el momento de pasarlos a la
dirección para que los aprueben.

Paso 2: Comenzar a diseñar los prototipos

En cuanto se haya terminado de definir el alcance del proyecto se puede comenzar la fase de desarrollo. Los
diseñadores y desarrolladores trabajarán estrechamente con los clientes con el objetivo de crear y mejorar
los prototipos que ya están en marcha hasta que el producto final esté preparado.

Paso 3: Recopilación de las opiniones del usuario

En esta fase, los prototipos y los sistemas beta se convierten en modelos de trabajo. Entonces, los
desarrolladores recogen la información que proporcionan los usuarios para corregir y mejorar los prototipos
y crear un producto con la mayor calidad posible.

Paso 4: Probar sucesivamente el modelo implementado

En esta fase en necesario poner a prueba el producto de software y asegurarse de que todos los engranajes
funcionan juntos sin problemas para satisfacer las expectativas del cliente. Se sigue incorporando la opinión
del cliente a medida que el código se pone a prueba una y otra vez hasta que su funcionamiento sea
impecable.
Paso 5: Presentación del sistema
Esta es la fase anterior al lanzamiento del producto terminado. En ella se integran la conversión de datos y la
formación del usuario.

Rapid Application Development Advantages and Disadvantages

Advantages of RAD Model Disadvantages of RAD Model

 Flexible and adaptable to changes  It can't be used for smaller projects

 It is useful when you have to reduce the overall project risk  Not all application is compatible with RAD

 It is adaptable and flexible to changes  When technical risk is high, it is not suitable

 It is easier to transfer deliverables as scripts, high-level  If developers are not committed to delivering software on
abstractions and intermediate codes are used time, RAD projects can fail

 Due to code generators and code reuse, there is a reduction  Reduced features due to time boxing, where features are
of manual coding pushed to a later version to finish a release in short period

 Due to prototyping in nature, there is a possibility of lesser  Reduced scalability occurs because a RAD developed
defects application begins as a prototype and evolves into a finished
application

 Each phase in RAD delivers highest priority functionality to  Progress and problems accustomed are hard to track as such
 client there is no documentation to demonstrate what has been
done

 With less people, productivity can be increased in short time

Agile Methodologies

Son un grupo de metodologías que utilizan cambios incrementales con un enfoque en la calidad y la atención al detalle.
Cada incremento se realiza en un período de tiempo específico creando un cronograma para la realización de las
múltiples tareas con objetivos muy específicos. Los principios de la presente metodología es el desarrollo iterativo,
interacción del usuario y capacidad de cambio.

Las metodologías ágiles se basan en el documento "Agile Manifesto", publicado por primera vez en 2001.
En la metodología agil no existe un orden predefinido de las etapas, sino que cada equipo va trabajando de forma
interconectada
 Xtreme programming

La metodología XP o Programación Extrema es una metodología ágil y flexible utilizada para la gestión de proyectos.
Extreme Programming se centra en potenciar las relaciones interpersonales del equipo de desarrollo como clave del éxito
mediante el trabajo en equipo, el aprendizaje continuo y el buen clima de trabajo.
Esta metodología pone el énfasis en la retroalimentación continua entre cliente y el equipo de desarrollo y es idónea para
proyectos con requisitos imprecisos y muy cambiantes.

La programación extrema o EXtreme Programming (PX) es un enfoque de la Ingeniería de Software formulado por Kent Beck,

autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change 1999. Es el más destacado de
los procesos ágiles de desarrollo de software.

VENTAJAS Y DESVENTAJAS DE EXTREME PROGRAMMING.

Ventajas:
 Da lugar a una programación sumamente organizada.
 Ocasiona eficiencias en el proceso de planificación y pruebas.
 Cuenta con una tasa de errores muy pequeña.
 Propicia la satisfacción del programador.
 Fomenta la comunicación entre los clientes y los desarrolladores.
 Facilita los cambios.
 Permite ahorar mucho tiempo y dinero.
 Puede ser aplicada a cualquier lenguaje de programación.
 El cliente tiene el control sobre las prioridades.
 Se hacen pruebas continuas durante el proyecto.
 La XP es mejor utilizada en la implementación de nuevas tecnologías.

Desventajas:
 Es recomendable emplearla solo en proyectos a corto plazo.
 En caso de fallar, las comisiones son muy altas.
 Requiere de un rígido ajuste a los principios de XP.
 Puede no siempre ser más fácil que el desarrollo tradicional.
Las fases son las siguientes:

  Planificación del proyecto con el cliente

  Diseño del proyecto
 Codificación, donde los programadores trabajan en pareja para obtener resultados más eficientes y de
calidad
  Pruebas para comprobar que funcionan los códigos que se van implementando