Professional Documents
Culture Documents
DESARROLLO DE SOFTWARE
INTRODUCCIÓN AL ANÁLISIS DE SISTEMAS
ANÁLISIS DE SISTEMAS
2019
UNIVERSIDAD NACIONAL “PEDRO RUIZ GALLO”
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
ESCUELA PROFESIONAL DE ESTADÍSTICA
MATERIA
ANÁLISIS DE SISTEMAS
TEMA
INTRODUCCIÓN AL ANÁLISIS DE SISTEMAS
CONTENIDO
“CICLOS DE VIDA EN EL DESARROLLO DE SISTEMAS DE INFORMACIÓN”
DOCENTE
FUENTES ADRIANZÉN DENNY JOHN.
INTEGRANTES
APONTE SUYÓN LUCELY.
CALDERON HUAMÁN SANDRA.
RODAS AZALDE JHAN CARLOS.
SANTAMARÍA VÁSQUEZ CARLOS.
SILVA MONTAÑO KENIA.
FECHA
12/05/2015
MODELO SECUENCIAL LINEAL
Este es el más básico de todos los modelos, y sirve como bloque de construcción para los demás
modelos de ciclo de vida. La visión del modelo cascada del desarrollo de software es muy simple;
dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase
tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la
satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase. Las flechas
muestran el flujo de información entre las fases. La flecha de avance muestra el flujo normal. Las
flechas hacia atrás representan la retroalimentación.
Características:
Ventaja:
Una de las contribuciones más importantes del modelo cascada es para los
administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.
Desventajas:
Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en
las etapas tempranas del proyecto. Si los cambios se producen en etapa madura
(codificación o prueba) pueden ser catastróficos para un proyecto grande.
No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos
(etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos
es luego difícil de acomodar.
El cliente debe tener paciencia ya que el software no estará disponible hasta muy
avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser
desastroso, implicando reinicio del proyecto con altos costos.
MODELO CASCADA
DESCRIPCIÓN
Requiere que los requerimientos estén bien definidos y estables en forma razonable.
Ingeniería y Análisis del Sistema: Debido a que el software es siempre parte de un sistema
mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y
luego asignando algún subconjunto de estos requisitos al software.
Análisis de los requisitos del software: El proceso de recopilación de los requisitos se centra
e Intensifica especialmente en el software. El ingeniero de software debe comprender
el ámbito de la Información del software, así como la función, el rendimiento y las
interfaces requeridas.
Diseño: el diseño del software se enfoca en cuatro atributos distintos del programa: la
estructura de los datos, la arquitectura del software, el detalle procedimental y la
caracterización de la interfaz.
Codificación: el diseño debe traducirse en una forma legible para la máquina. El paso de
codificación realiza esta tarea.
Prueba: La prueba se centra en la lógica interna del software, y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados que
realmente se requieren.
Es el más utilizado.
Es una visión del proceso de desarrollo de software como una sucesión de etapas que
producen productos intermedios.
Para que el proyecto tenga éxito deben desarrollarse todas las fases.
VENTAJAS
La planificación es sencilla.
DESVENTAJAS
CONCLUSIONES
En conclusión a pesar de que es un modelo que es muy tardado ya que lleva una planeación que
debe cumplirse obligatoriamente para que los resultados sean satisfactorios.
MODELO INCREMENTAL
El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque
incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de
desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir
experiencia con el sistema. Este modelo se conoce también bajo las siguientes
denominaciones:
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía
interactiva de Construcción de Prototipos. Como se muestra en la Figura 1, el modelo
incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el
calendario. Cada secuencia lineal produce un incremento del software. El primer incremento
generalmente es un producto esencial denominado núcleo.
En una visión genérica, el proceso se divide en 4 partes:
Análisis
Diseño
Código
Prueba
Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o Pipeline.
Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada
incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a
fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se
elabora el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.
PIPELINE
CARACTERÍSTICAS
Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta
frecuencia.
Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como
un todo.
VENTAJAS:
DESVENTAJAS:
CONCLUSIÓN:
Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del
producto Software denominados "incrementos" del sistema, que son escogidos en base a
prioridades predefinidas de algún modo.
El modelo permite una implementación con refinamientos sucesivos (ampliación y/o mejoras).
Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora
la versión previamente implementada del producto software.
MODELO EVOLUTIVO
Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y
complejas, hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante la fase de
operación. Los modelos “Iterativo Incremental” y “Espiral” (entre otros) son dos de los más
conocidos y utilizados del tipo evolutivo.
La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial,
exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el
sistema adecuado. Una ventaja de este modelo es que se obtiene una rápida realimentación del
usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.
VENTAJAS
Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja
en una mejora de la calidad del software.
Es más efectivo que el modelo de cascada, ya que cumple con las necesidades
inmediatas del cliente.
DESVENTAJAS
Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el
sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen
cada versión del sistema.
Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para
la estructura del software haciendo costoso el mantenimiento.
El modelo de desarrollo en espiral es un generador de modelo de proceso guiado por el riesgo que
se emplea para conducir sistemas intensivos de ingeniería de software concurrente y a la vez con
muchos usuarios.
CICLOS O ITERACIONES
Las Alternativas: Los varios métodos de alcanzar los objetivos de manera exitosa, a través
de diferentes puntos como son:
Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la
creación de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos
fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y
habilidad para detectar y catalogar correctamente los riesgos.
TAREAS
Fijar también los productos definidos para obtener: requisitos, especificación, manual de
usuario.
Fijar las restricciones.
Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
Hay una cosa que solo se hace una vez: planificación inicial.
Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes
y planificamos la próxima actividad.
VENTAJAS
El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los
restantes modelos.
Reduce riesgos del proyecto.
Incorpora objetivos de calidad.
Integra el desarrollo con el mantenimiento, etc.
DESVENTAJAS
MODELO DE PROTOTIPOS
Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del
desarrollo del software puede no estar seguro de la eficiencia de un algoritmo, de la calidad de
adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombre-
máquina. En estas y en otras muchas situaciones, un paradigma de construcción de prototipos
puede ofrecer el mejor enfoque. El paradigma de construcción de prototipos comienza con la
recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales
para el software, identifican los requisitos conocidos y las áreas del esquema en donde es
obligatoria más definición. Entonces aparece un diseño rápido. El diseño rápido se centra en una
representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño
rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y se utiliza
para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se
pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el
desarrollador comprenda mejor lo que se necesita hacer.
PROGRAMACION EXTREMA XP
OBJETIVOS.
CONTEXTO XP
CARACTERÍSTICAS XP
1) Simplicidad XP: propone el principio de hacer la cosa más simple que pueda funcionar, en
relación al proceso y la codificación. Es mejor hacer hoy algo simple, que hacerlo complicado y
probablemente nunca usarlo mañana.
2) Comunicación: Algunos problemas en los proyectos tienen origen en que alguien no dijo algo
importante en algún momento. XP hace casi imposible la falta de comunicación.
3) Retroalimentación: Durante la vida de un proyecto son muy pocas las direcciones que
permanecen constantes, ya sean los detalles del desarrollo, los requerimientos del sistema, la
arquitectura y muchas otras pueden cambiar.
EL ESTILO XP
CONCLUSIONES
Apostolado de metodologías exitosas
Aporte de la experiencia práctica a los modelos teóricos
Enfoque de conjunto de prácticas como rompecabezas
Tecnología en expansión
Importancia de revisitar las metodologías desde la experiencia práctica
Metodología Scrum
Historia
Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y principios de los
estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a
mediados de los 80. Aunque surgió como modelo para el desarrollo de productos tecnológicos,
también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y
flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software.
Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation
(Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en
Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken
Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96.
Más tarde, en 2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de
software scrum está considerado como modelo ágil por la Agile Alliance.
Definición
Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo
principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en
construir primero la funcionalidad de mayor valor para el cliente y en los principios de
inspección continua, adaptación, auto-gestión e innovación.
Utilidad
Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve
crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el software
con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o
de prioridad en el inicio de cada nueva iteración sin ningún problema.
Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que forma
parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar
sus capacidades.
Beneficios
1) Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le
aporta cada requisito / historia del proyecto, el equipo los estima y con esta información el
Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product
Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al
equipo.
2) Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos
generados por necesidades del cliente o evoluciones del mercado. La metodología está diseñada
para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.
3) Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más
importantes del proyecto antes de que esté finalizado por completo.
4) Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión
funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.
5) Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la
burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos
para organizarse.
6) Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las
prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de inversión.
7) Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del equipo
por sprint (los llamados puntos historia), con lo que consecuentemente, es
posible estimar fácilmente para cuando se dispondrá de una determinada funcionalidad que
todavía está en el Backlog.
8) Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer lugar
y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos
eficazmente de manera anticipada.
VALORES DE SCRUM
Scrum es una “carrocería” para dar forma a los principios ágiles. Es una ayuda para organizar a
las personas y el flujo de trabajo; como lo pueden ser otras propuestas de formas de trabajo ágil:
Cristal, DSDM, etc.
La carrocería sin motor, sin los valores que dan sentido al desarrollo ágil, no funciona.
Delegación de atribuciones (empowerment) al equipo para que pueda auto- organizarse y
tomar las decisiones sobre el desarrollo.
Respeto entre las personas.
Los miembros del equipo deben confiar entre ellos y respetar sus conocimientos y capacidades.
Responsabilidad y auto-disciplina (no disciplina impuesta).
Trabajo centrado en el desarrollo de lo comprometido Información, transparencia y visibilidad
del desarrollo del proyecto.
¿Qué ganamos con la metodología Scrum?
Los beneficios son amplios y repercuten en el equipo, en los Stakeholders y en la organización en su
conjunto.
Se fomenta el trabajo en equipo, focalizando todos los esfuerzos en alcanzar un objetivo común.
Se trata de un modelo basado en la auto-disciplina y la auto-gestión, lo que repercute
positivamente en la responsabilidad. Respecto al aspecto comunicativo, esta metodología
fomenta la comunicación entre los distintos miembros del equipo.
Los Stakeholders tienen un mayor control y transparencia sobre el proyecto, permitiendo una
mejor organización. El cliente puede hacer seguimiento más cercano de lo que pasa, sin tener que
esperar a un resultado final que no le convenza. Con las metas intermedias se minimizan riesgos.
En definitiva, la adopción de estas buenas prácticas permite reducir el tiempo de desarrollo de
productos, más capacidad de adaptación y flexibilidad frente a un entorno y unos requisitos
cambiantes aumentando el valor que se aporta a los clientes.
Natural: los participantes pueden estimar el esfuerzo con la cifra exacta que crean más
adecuada.
Fibonacci: las estimaciones solo se pueden realizar empleando números de la sucesión de
Fibonacci. En cada caso, el juego de cartas empleado tiene la numeración apropiada.
VENTAJAS:
Programación organizada.
Menor taza de errores.
Satisfacción del programador.
DESVENTAJAS:
Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.
La estimación de póquer
SEMEJANZAS
Es un Agile Manifiesto.
Existen una Interacción de Usuario a Usuario.
Realizan los Proyectos en un Corto Periodo de Tiempo.
Trabajan en Equipo.
DIFERENCIAS( CUADRO DE COMPARACION)
SCRUM
Las iteraciones de entregas son de 2 a 4
semanas.
Lo que se termina, funciona y este bien, se
aparta y ya no se toca.
Cada miembro del Scrum Team trabaja de forma
individual.
El Scrum Team trata de seguir el orden de
prioridad q marca el Product Owner en el Sprint
Backlog pueden ser modificadas.
Está basada en la administración del proyecto.
XP (EXTREME PROGRAMMING)
Las iteraciones de entrega son a 1 a 3
semanas.
Las tareas q se van entregando a los
diferentes clientes son susceptibles a las
modificaciones.
Los miembros del programan en pareja en
un proyecto XP.
El equipo de desarrollo sigue estrictamente
el orden de prioridad de las tareas definidas
por el cliente.
Se centra más en la propia programación o
creación del producto.
LINKOGRAFIAS
http://procesosoftware.wikispaces.com/Modelo+Incremental
http://jorgetrejos.blogspot.com/2010/08/modelo-evolutivo.html
http://es.wikipedia.org/wiki/Desarrollo_en_espiral
http://jorgetrejos.blogspot.com/2010/08/modelo-en-espiral.html