Taller1 Analaisis de Sistemas y Metodologias

FICHA DE IDENTIFICACIÓN DE TRABAJO DE INVESTIGACIÓN
Título Análisis de Sistemas y Metodologías

Nombres y Apellidos Código de estudiantes
Ledezma Romero Arturo Fabián 201207708
Autor/es
Fecha 11/09/2018
Carrera Ingeniería de Sistemas

Asignatura Taller De Licenciatura I
Grupo A
Docente Ing. Roxana Ramos Larico
Periodo Académico II-2018
Subsede Cochabamba
Copyright © (2018) por (Arturo). Todos los derechos reservados.
.
RESUMEN:
Título: Análisis de Sistemas y Metodologías
Autor/es: Ledezma Romero Arturo Fabián
Palabras clave: CMMI, modelo, estándar, desarrollo, software.
ABSTRACT:
Key words: CMMI, model, standard, development, software.
Tabla De Contenidos
LISTA DE TABLAS................................................................................................................................................5
1. INTRODUCCIÓN..........................................................................................................................................6
2. MARCO TEÓRICO.......................................................................................................................................7
2.1 CMMI: ASPECTOS GENERALES...............................................................................................................7
2.1.1. ¿Qué es CMMI?............................................................................................................................7
2.1.2. Propósito del CMMI.....................................................................................................................8
2.1.3. Objetivos del CMMI......................................................................................................................9
2.1.4. Áreas de conocimiento de CMMI..................................................................................................9
2.2. EVOLUCIÓN DEL ESTÁNDAR CMMI......................................................................................................10
2.2.1. Historia de los modelos CMM....................................................................................................10
2.2.2. Integración de los modelos CMM...............................................................................................11
2.2.3. Variaciones..................................................................................................................................12
2.2.4. Modelos CMMI...........................................................................................................................12
2.3. ESTRUCTURA DE CMMI........................................................................................................................12
2.3.1. Componentes de CMMI..............................................................................................................12
2.3.2. Categorías y áreas de proceso....................................................................................................14
2.3.3. Tipos de representación de CMMI..............................................................................................15
2.3.3.1. CMMI: Representación por Etapas......................................................................................................16
2.3.3.1.1. Estructura de CMMI por etapas.......................................................................................................16
2.3.3.1.2. Niveles de madurez.........................................................................................................................17
2.3.3.2. CMMI: Representación Continua.........................................................................................................20
2.3.3.2.1. Estructura de CMMI continuo.........................................................................................................20
2.3.3.2.2. Niveles de Capacidad......................................................................................................................21
2.4. INTERPRETACIÓN DE CMMI..................................................................................................................23
2.5. USOS Y BENEFICIOS DEL ESTÁNDAR......................................................................................................24
2.5.1. Usos de CMMI............................................................................................................................24
Asignatura: Gestión de Calidad

Página 19 de 19
Carrera: Ingeniería de Sistemas
2.5.2. Beneficios de CMMI...................................................................................................................25

2.5.3. Herramientas de evaluación.......................................................................................................25
3. CONCLUSIONES.............................................................................................................................................27
Referencias..............................................................................................................................................................28

Página 19 de 19
Lista De Tablas
Tabla 1 Categorías de procesos de CMMI con sus respectivas áreas.......................................15
Lista De Figuras
Figura 1 Componentes de CMMI............................................................................................13

Figura 2 Estructura de CMMI por etapas.................................................................................16
Figura 3 Niveles de CMMI por etapas.....................................................................................17
Figura 4 Componentes esenciales del CMMI-Contínuo..........................................................21
Figura 5 Medida de la capacidad de áreas de procesos............................................................21
Figura 6 Niveles de capacidad de CMMI Contínuo................................................................22

Página 19 de 19
Introducción
A medida de que van creciendo los proyectos informáticos se presentan problemas para
analizar estos, los requerimientos del producto van surgiendo a medida que el cliente se da
cuenta de que necesita algo nuevo y por ende el diseño se ve afectado, esto hace que se vayan
aplicando metodologías que permitan realizar un trabajo adecuado, dado las situaciones que
puedan presentarse y ofrecer buenos resultados en la gestión de proyectos.
Las metodologías tradicionales y las agiles tiene características comunes. Las mismas,
comparten tres conceptos, los objetivos del proyecto, el tiempo y los costes; estos términos
forman el triángulo de hierro ya que van relacionados entre sí, de modo que si uno de ellos
cambia los demás se ven afectados. Es decir si tenemos menos tiempo es necesario delimitar el
proyecto, con la finalidad de reducir el coste y mejorar los objetivos. Si esto no sucede, se
compromete la calidad del proyecto.
Es por eso que, debe realizarse un control permanente analizando que falta por hacer; Por lo
tanto, la metodología SCRUM que es una metodología ágil, se vuelve una gran opción a la hora
de planificar o realizar un análisis de sistemas.

Página 19 de 19
1. Capitulo l: Planteamiento del problema

2. Objetivos
1.1.1. Objetivo general

 Describir el análisis de sistemas y aplicar la metodología SCRUM en el desarrollo de
un sistema X…
1.1.2. Objetivos específicos
 Recolectar información sobre el análisis de sistemas
 Examinar las metodologías de desarrollo de software
 Analizar las ventajas y desventajas de las metodologías agiles.
 Analizar el desarrollo de un sistema X… basado en la metodología SCRUM
3. Alcance
4. Justificación
Durante los últimos años se ha demostrado el uso de metodologías como un entorno de

trabajo para el desarrollo de software. Lo que indica que el conocimiento de estos, para el
análisis de un sistema, se ha vuelto una necesidad. Debido a que cada día se vuelve más
complejo realizar el desarrollo de un proyecto, a causa del cambio de requerimientos, las
exigencias de los clientes, la aparición de nuevas tecnologías y la adaptación a estas.
Al contar con la información a presentarse, ofrecerá información acerca las metodologías de

desarrollo de software como los diferentes tipos dentro de esta.
También profundizando lo que es la metodología SCRUM, se podrá indicar y analizar el
método de trabajo de desarrollo de software que comprende dicha metodología.

Página 19 de 19
2. Capitulo II: Marco Teórico

5. Análisis de Sistemas
En una definición puede presentarse como un conjunto o disposición de procedimientos o

programas relacionados de manera que juntos forman una sola unidad. Un conjunto de hechos,
principios y reglas clasificadas y dispuestas de manera ordenada mostrando un plan lógico en la
unión de las partes. Un método, plan o procedimiento de clasificación para hacer algo. También
es un conjunto o arreglo de elementos para realizar un objetivo predefinido en el procesamiento
de la Información. (Gane, 1988)
El Análisis de Sistemas trata básicamente de determinar los objetivos y límites del sistema
objeto de análisis, caracterizar su estructura y funcionamiento, marcar las directrices que
permitan alcanzar los objetivos propuestos y evaluar sus consecuencias. Dependiendo de los
objetivos del análisis, podemos encontrarnos ante dos problemáticas distintas:
 Análisis de un sistema ya existente para comprender, mejorar, ajustar y/o predecir su

comportamiento.
 Análisis como paso previo al diseño de un nuevo sistema-producto.
Los sistemas en relación con el análisis de sistemas están relacionados con cualquier campo
tales como: procesos industriales, administración, toma de decisiones, procesos, protección al
medio ambiente, etc. (Kendall, 1991)
En sistemas informáticos se deben observar ciertos principios:
 Debe presentarse y entenderse el dominio de la información de un problema.

 Defina las funciones que debe realizar el Software.
 Represente el comportamiento del software a consecuencias de acontecimientos externos.
 Divida en forma jerárquica los modelos que representan la información, funciones y
comportamiento.
6. Ciclo de vida de un software
El proceso debe partir desde la información esencial hasta el detalle de la Implementación.

Página 19 de 19
Figura 1: Ciclo de vida de un software
Fuente: (Ledezma, 2018)
a) Planificación. El primer punto importante en el ciclo de vida de software, es analizar

brevemente los requerimientos que el cliente pide para la elaboración del sistema que
necesita. Esta etapa requiere se cierto conocimiento para poder entender la idea que el
cliente propone, además de que regularmente debes tomar nota con cada uno de los
puntos importantes que se te solicitan, de este modo puedes hacer una planificación al
momento y llegar incluso a determinar los tiempos de desarrollo que te llevará, antes de
proceder a entregar el producto final. (Kendall, 1991)
b) Implementación. Una vez que hemos platicado con el cliente y tenemos lo que es un
análisis de requerimientos, necesidades y funcionalidades por parte de una aceptación en
ambas partes, entonces procedemos con lo que es el ciclo de vida de desarrollo de
software. Para este punto, existen una infinidad de metodologías de desarrollo de
software, que nos ofrecen la posibilidad de trabajar de distintas formas. (Kendall, 1991)
c) Pruebas. Una vez que el sistema se va desarrollando, es importante para el ciclo de vida
del desarrollo del software, que se realicen ciertas pruebas conforme se vaya avanzando.
La idea es que no se termine el desarrollo para poder hacer pruebas, si no que mucho
antes, durante el proceso de creación, estas ya se puedan ir ejecutando. Las pruebas nos
van a permitir ver si el sistema que se está desarrollando es funcional, si tiene algunos
errores, si le faltan ciertas cosas para funcionar correctamente, pues básicamente para
avanzar al siguiente punto del ciclo de desarrollo de software, será necesario haber
pasado las pruebas correctamente. (Kendall, 1991)

Página 19 de 19
d) Documentación. Muchas metodologías de lo que es el ciclo de vida software, van

creando documentación, conforme se va avanzando en el desarrollo del sistema. Sin
embargo algunas otras prefieren no hacer la documentación hasta el final. Ahora sí que
sea cual sea la metodología que elijas, la documentación siempre será importante, pues
considera que no siempre vas a estar tú y tu equipo disponibles y cuando otro equipo
llegue a programar lo que ustedes hicieron, será indispensable que haya una
documentación de la cual se puedan basar, para poder empezar a desarrollar nuevamente
el sistema incompleto. (Kendall, 1991)
e) Despliegue. Ya casi llegando a lo que son las últimas etapas del desarrollo de software,
nos encontramos con el Despliegue. Este no es otra cosa, más que el momento en que el
sistema ya está terminado y ha sido aprobado para que se elabore el producto final.
(Kendall, 1991)
f) Mantenimiento. La última de las fases del desarrollo de software, es el mantenimiento.
Que creías, que nunca más verías al software que hicieron, terminaron y distribuyeron.
Pues claro que si lo volverías a ver, pues es momento de darle mantenimiento. Acá
además se pueden agregar lo que son las actualizaciones, dependiendo del tipo de
desarrollo. (Kendall, 1991)
7. Metodologías de desarrollo de software
Las Metodologías de Desarrollo de Software surgen ante la necesidad de utilizar una serie de
procedimientos, técnicas, herramientas y soporte documental a la hora de desarrollar un producto
software. Las metodologías pretenden guiar a los desarrolladores a crear un nuevo software, pero
los requisitos de un software a otro son tan variado y cambiante, que ha dado lugar a una gran
variedad de metodologías para la creación del software. (Canos Jose, 2000)
Actualmente una metodología es un conjunto integrado de técnicas y métodos que permite
abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un
proyecto de desarrollo. Las metodologías se basan en una combinación de los modelos de
proceso genéricos (cascada, incremental, etc.). Definen artefactos, roles y actividades, junto con
prácticas y técnicas recomendadas. (Canos Jose, 2000)

Página 19 de 19
Cada una de las metodologías disponibles es más adecuada para tipos específicos de
proyectos, basados en consideraciones técnicas, organizacionales, de proyecto y de equipo. Una
metodología de desarrollo de software o metodología de desarrollo de sistemas en ingeniería de
software es un marco de trabajo que se usa para estructurar, planificar y controlar el proceso de
desarrollo de un sistema de información. Se podrían clasificar en dos grandes grupos:
 Las metodologías tradicionales
 Las metodologías agiles
2.2.1. Las metodologías tradicionales
Estableciendo rigurosamente las actividades a desarrollar, herramientas a utilizar y

notaciones utilizadas. Estas metodologías son también llamadas Metodologías pesadas.
2.2.1.1. Modelo secuencial

Las principales etapas de este modelo se transforman en actividades fundamentales de
desarrollo:
Figura 2: Modelo secuencial

Es llamado algunas veces ciclo de vida básico o modelo en cascada, el modelo lineal
secuencial sugiere un enfoque sistemático, secuencial, para el desarrollo del software que
comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y
mantenimiento. (Sommerville, 2005)

Página 19 de 19
En principio, el resultado de cada fase es uno o más documentos aprobados (firmados). La

siguiente fase no debe empezar hasta que la fase previa haya finalizado. En la práctica, estas
etapas se superponen y proporcionan información a las otras. Durante el diseño se identifican los
problemas con los requerimientos; durante el diseño del código se encuentran problemas, y así
sucesivamente. El proceso del software no es un modelo lineal simple, sino que implica una serie
de iteraciones de las actividades de desarrollo. (Pressman, 2005)
Dicha metodología cuenta con las siguientes ventajas:
 Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es mejor que
ninguno.
 Facilita la gestión del desarrollo.
 La calidad del producto resultante es alta.
 Sus fases son conocidas por los desarrolladores.
 Se tiene todo muy bien organizado y no se mezclan las fases.
 La planificación es sencilla.
 Los usuarios lo pueden comprender fácilmente.
Como también tiene desventajas:
 En general, establecer todos los requisitos al principio del proceso de desarrollo es un
mito inalcanzable: Los usuarios no pueden imaginárselo que quieren hasta que no ven un
sistema funcionando.
 Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado cambia,
todo cambia.
 El usuario debe esperar mucho tiempo hasta ver los resultados.
 Los errores de análisis y diseño son costosos de eliminar, y se propagan a las fases
siguientes con un efecto conocido como bola de nieve.
 Se genera mucho mantenimiento inicial debido al período de congelación de requisitos y
éste recae, en su mayor parte.

Página 19 de 19
2.2.1.2. Modelo de desarrollo incremental

El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa.
Éste aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el
calendario. Cada secuencia lineal produce incrementos del software. (Sommerville, 2005)
Figura 3: Modelo incremental

Se identificó las siguientes de ventajas:
 Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se
implementa la funcionalidad parcial.
 También provee un impacto ventajoso frente al cliente, que es la entrega temprana de
partes operativas del Software.
 El modelo proporciona todas las ventajas del modelo en cascada realimentado,
reduciendo sus desventajas sólo al ámbito de cada incremento.
 Permite entregar al cliente un producto más rápido en comparación del modelo de
cascada.
 Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
 Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo
como técnico.

Página 19 de 19
Como también desventajas:

 El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto
nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.
 Requiere de mucha planeación, tanto administrativa como técnica.
 Requiere de metas claras para conocer el estado del proyecto.
 Se necesitan pruebas de regresión y su coste puede aumentar.
2.2.1.3. Modelo por prototipos

A menudo un cliente define un conjunto de objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, procesamiento o salida. En otros casos, el
responsable del desarrollo de software está inseguro de la eficacia de un algoritmo, de la
adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-
máquina. En éstas, y en muchas otras situaciones, un paradigma de construcción por prototipos
puede ofrecer el mejor enfoque.
Figura 4: Modelo de desarrollo por Prototipos

Se identificó las siguientes ventajas:
 Permite al desarrollador darse en cuenta de lo que quiere el cliente
 Se crea con rapidez
 Son Fácilmente modificables
 Reduce costo.
 Aumenta la probabilidad de Éxito

Página 19 de 19
Como también desventajas:

 Administración difícil.
 Adaptarlo como el sistema final.
 El Desarrollador y el Cliente tienen poca comunicación.
 Surge Cambios imprevistos que retrasan el progreso de prototipo.
2.2.1.4. Modelo en Espiral

El modelo de desarrollo en espiral es un generador del modelo de proceso guiado por el riesgo
que se emplea para conducir sistemas intensivos de ingeniería del software concurrente y con
múltiples usuarios. Tiene dos características distintivas principales. Una de ellas es un enfoque
cíclico para el crecimiento incremental del grado de definición e implementación de un sistema,
mientras disminuye su grado de riesgo. (Pressman, 2005)
La otra es un conjunto de puntos de fijación para asegurar el compromiso del usuario con
soluciones de sistemas que sean factibles y mutuamente satisfactorias. (Pressman, 2005)
Cuando se aplica el modelo en espiral, el software se desarrolla en una serie de entregas
evolutivas. Durante las primeras iteraciones, la entrega tal vez sea un documento del modelo o
un prototipo. Durante las últimas iteraciones se producen versiones cada vez más completas del
sistema desarrollado. (Pressman, 2005)

Página 19 de 19
Figura 5: Modelo en espiral

Se identificó las siguientes ventajas:
 El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de
computadora.
 Como el software evoluciona a medida que progresa el proceso, el desarrollador y el
cliente comprenden y reaccionan mejor ante riesgos en cada uno de los nivele
evolutivos.
 El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construcción
de prototipos en cualquier etapa de evolución del producto.
 El modelo en espiral demanda una consideración directa de los riesgos técnicos en
todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos
antes de que se conviertan en problemas.
 En la utilización de grandes sistemas ha doblado la productividad.
Como también las desventajas:
 Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es
controlable.
 Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.
 Genera demasiado tiempo en el desarrollo de sistemas.

Página 19 de 19
 Si no existen grupos de trabajo no se puede trabajar en éste método.

Existen más modelos que pertenecen a la gama de los modelos procedurales también
conocidas como metodologías tradicionales de desarrollo. En los párrafos anteriores solo se
mencionaron algunos de ellos.
2.2.2. Metodologías de desarrollo ágiles
Las metodologías agiles nacen como una reacción contra los métodos tradicionales, muy
estructurados y estrictos, extraídos del modelo de desarrollo en cascada. El proceso originado de
uso del modelo en cascada era visto como burocrático, lento degradante e inconsistente con las
formas de desarrollo que realmente realizaban un trabajo eficiente. (Canos Jose, 2000)
Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos
desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del
proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en
cada una de las actividades desarrolladas. Además son un marco conceptual de la ingeniería de
software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del
proyecto, donde cada iteración del ciclo de vida incluye planificación, análisis, diseño,
codificación, revisión y documentación. Una iteración no debe agregar demasiada funcionalidad
para justificar el lanzamiento del producto al mercado, pero la meta es tener un producto parcial
o una parte del todo al final de cada iteración. (Canos Jose, 2000)
A todo esto se puede añadir un cambio bastante importante, en cuanto a la demanda del
mercado del software, cada vez más orientada a la Web, con requisitos muy volátiles y en
constante cambio, que requieren tiempos de desarrollo cada vez más cortos, lo que provocó que
las empresas se fijaran más en nuevos desarrolladores, con nuevos métodos que se combinan con
técnicas de las metodologías formales. Los modelos de desarrollo de las comunidades pudieron
ciertamente determinar la aparición de las metodologías ágiles, pero cada autor determina el
surgimiento de las metodologías ágiles de diferentes maneras. (Cockburn, 2000)
De las metodologías ágiles las más representativas corresponden a:
 SCRUM
 Programación Extrema XP (Extreme Programming)

Página 19 de 19
 Kanban
8. Metodología SCRUM
Figura 6: Metodologia SCRUM

Página 19 de 19

Scrum Un marco de trabajo por el cual las personas pueden acometer problemas complejos
adaptativos, a la vez que entregar productos máximo valor posible productivo y creativamente
Scrum es:
 Ligero
 Fácil de entender.
 Extremadamente difícil de llegar a dominar.
Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo de
productos complejos desde principios de los años 90. Scrum no es un proceso o una técnica para
construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear
varias técnicas y procesos. (Cockburn, 2000)

Página 19 de 19
Scrum muestra la eficacia relativa de las prácticas de gestión de producto y las prácticas de
desarrollo, de modo que podamos mejorar. (Cockburn, 2000)
El marco de trabajo Scrum consiste en los Equipos Scrum, roles, eventos, artefactos y reglas
asociadas. Cada componente dentro del marco de trabajo sirve a un propósito específico y es
esencial para el éxito de Scrum y para su uso. (Cockburn, 2000)
Las reglas de Scrum relacionan los eventos, roles y artefactos, gobernando las relaciones e
interacciones entre ellos.
2.2.3. Equipo SCRUM (SCRUM Team)
Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las
oportunidades de obtener retroalimentación. Las entregas incrementales de producto Terminado
aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto.
(Scrum.org., 2013)
Los equipos auto-organizados eligen la mejor forma de llevar a cabo su trabajo y no son
dirigidos por personas externas al equipo. Los equipos multifuncionales tienen todas las
competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no son
parte del equipo. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la
creatividad y la productividad.
El Equipo Scrum consiste:
 Product Owner (dueño del producto): Su trabajo va desde expresar claramente los
elementos de la Lista del Producto, establecer las prioridades adecuadas que permitan
alcanzar los objetivos, asegurar que los elementos de la Lista del Producto sean claros,
transparentes y se entiendan completamente por parte del Equipo de Desarrollo.
 Development Team (Equipo de desarrollo): Consiste en un grupo de personas que
desempeñan funciones para conseguir los objetivos establecidas por el Dueño del
Producto, este trabajo se ve reflejado en la entrega de un nuevo incremento del producto
que ser puesto en producción una vez finalizado cada sprint.
 Scrum Master: Entre las tareas que debe cumplir un Scrum Master podemos encontrar:
debe ayudar al Dueño del Producto a entender la necesidad de contar con elementos de la

Página 19 de 19
Lista del Producto claros y concisos, así como priorizarlos; ayuda al Equipo de Desarrollo
a ser auto organizado y multifuncional, crear productos de alto valor y solventar
impedimentos para el progreso del equipo.

Página 19 de 19

Taller1 Analaisis de Sistemas y Metodologias

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Taller1 Analaisis de Sistemas y Metodologias

Uploaded by

Copyright:

Available Formats

FICHA DE IDENTIFICACIÓN DE TRABAJO DE INVESTIGACIÓN

Título Análisis de Sistemas y Metodologías

Carrera Ingeniería de Sistemas

Palabras clave: CMMI, modelo, estándar, desarrollo, software.

Key words: CMMI, model, standard, development, software.

Asignatura: Gestión de Calidad

2.5.2. Beneficios de CMMI...................................................................................................................25

Asignatura: Gestión de Calidad

Tabla 1 Categorías de procesos de CMMI con sus respectivas áreas.......................................15

Figura 1 Componentes de CMMI............................................................................................13

Asignatura: Gestión de Calidad

Asignatura: Gestión de Calidad

1. Capitulo l: Planteamiento del problema

1.1.1. Objetivo general

Durante los últimos años se ha demostrado el uso de metodologías como un entorno de

Al contar con la información a presentarse, ofrecerá información acerca las metodologías de

Asignatura: Gestión de Calidad

2. Capitulo II: Marco Teórico

En una definición puede presentarse como un conjunto o disposición de procedimientos o

 Análisis de un sistema ya existente para comprender, mejorar, ajustar y/o predecir su

En sistemas informáticos se deben observar ciertos principios:

 Debe presentarse y entenderse el dominio de la información de un problema.

6. Ciclo de vida de un software

El proceso debe partir desde la información esencial hasta el detalle de la Implementación.

Asignatura: Gestión de Calidad

Figura 1: Ciclo de vida de un software

Fuente: (Ledezma, 2018)

a) Planificación. El primer punto importante en el ciclo de vida de software, es analizar

Asignatura: Gestión de Calidad

d) Documentación. Muchas metodologías de lo que es el ciclo de vida software, van

7. Metodologías de desarrollo de software

Asignatura: Gestión de Calidad

Estableciendo rigurosamente las actividades a desarrollar, herramientas a utilizar y

2.2.1.1. Modelo secuencial

Fuente: (Ledezma, 2018)

Asignatura: Gestión de Calidad

En principio, el resultado de cada fase es uno o más documentos aprobados (firmados). La

Asignatura: Gestión de Calidad

2.2.1.2. Modelo de desarrollo incremental

Fuente: (Ledezma, 2018)

Asignatura: Gestión de Calidad

Como también desventajas:

2.2.1.3. Modelo por prototipos

Fuente: (Ledezma, 2018)

Asignatura: Gestión de Calidad

Como también desventajas:

2.2.1.4. Modelo en Espiral

Asignatura: Gestión de Calidad

Figura 5: Modelo en espiral

Fuente: (Ledezma, 2018)

Asignatura: Gestión de Calidad

 Si no existen grupos de trabajo no se puede trabajar en éste método.

Asignatura: Gestión de Calidad

Figura 6: Metodologia SCRUM

Asignatura: Gestión de Calidad

Fuente: (Ledezma, 2018)

Asignatura: Gestión de Calidad

2.2.3. Equipo SCRUM (SCRUM Team)

Asignatura: Gestión de Calidad

Asignatura: Gestión de Calidad

You might also like