CUADRO COMPARATIVO

MODELOS PRESCRIPTIVOS DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN
INGENIERÍA INFORMÁTICA
Fundamentos de sistemas de información
Unidad 3
Equipo #2
Integrantes:
José Luis Baltazar Anaya
Crhistian Iván Madrueño Aguilar
Profesor: Jorge Aragón Hope
Trabajo: Cuadro comparativo
20 de octubre de 2020
OBJETIVO
En términos generales el objetivo de este trabajo es comparar los diferentes modelos y metodologías prescriptivas del
desarrollo de sistemas de información, se tratará de resaltar la definición, características, etapas, ventajas y desventajas
de cada uno de los modelos que se vieron en la unidad 3, con el fin de notar las diferencias entre estas metodologías y
comprender que para cada tipo de proyecto se puede buscar y aplicar el modelo que más le convenga y no solamente
escoger uno al azar, ya que para eso fueron desarrollados, para agilizar, mejorar, reducir riegos, reducir costos, reducir
tiempos, analizar riesgos, mejorar calidad, etc. Todo ello aplicado al desarrollo de software.
El ingeniero de software debe conocer y comprender de que va cada uno de estos modelos y metodologías para poder
aplicarlos en proyectos que se le presenten, ya que es indispensable para desarrollar sistemas de información de cualquier
tipo.
MODELO
CASCADA
DEFINICIÓN
¿Qué es?
También conocido
como
modelo
clásico,
modelo
tradicional
o
modelo lineal sec
uencial. Él método
de la cascada es
considerado como
el enfoque clásico
para el ciclo de
vida del desarrollo
de sistemas.
CARACTERÍSTICAS / RIESGOS
•
•
El modelo en
cascada es un
proceso
de
desarrollo
secuencial, en el
que el desarrollo
de software se
concibe como un
conjunto
de
etapas que se
ejecutan una tras
otra.
Se
le
denomina así por
las posiciones que
ocupan
las
diferentes fases
que componen el
proyecto,
colocadas
una
encima de otra, y
siguiendo un flujo
de ejecución de
arriba hacia abajo,
como
una
cascada.
•
•
Es adecuada para los
proyectos
donde
se
desarrollan
componentes
software paralelamente y los
miembros del equipo trabajan
en varios trabajos. Es vital
para los proyectos en los
cuales
se
tienen
bien
definidos cuales son los
objetivos y requisitos e ir paso
a paso siguiendo cada una de
las etapas del proyecto.
El modelo Cascada posee un
alto riesgo en sistemas
nuevos debido a problemas
en las especificaciones y en el
diseño.
La aplicación del modelo en
cascada se orienta mejor al
desarrollo de proyectos de
corto
plazo,
de
poca
innovación, como proyectos
definitivos bien detallados
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,
donde no se puede avanzar a
la siguiente si la anterior no se
encuentra
totalmente
terminada
ETAPAS / grafico
VENTAJAS
●
●
●
●
Requisitos: En esta fase se hace un análisis
(que incluye un estudio de viabilidad) de las
necesidades del cliente para determinar las
características del software a desarrollar, y se
especifica todo lo que debe hacer el sistema sin
entrar en detalles técnicos.
Diseño: En esta etapa se describe la estructura
interna del software, y las relaciones entre las
entidades que lo componen.
Implementación: En esta fase se programan
los requisitos especificados haciendo uso de las
estructuras de datos diseñadas en la fase
anterior.
Verificación: Una vez se termina la fase de
implementación se verifica que todos los
componentes
del
sistema
funcionen
correctamente y cumplen con los requisitos.
Mantenimiento: A partir de ahora hay que
asegurarse de que el software funcione y hay que
destinar recursos a mantenerlo.
Después de cada etapa
importante las pruebas se
realizan para comprobar el
correcto funcionamiento
del código.
La documentación se
produce en cada etapa del
desarrollo del modelo de
cascada.
La cantidad de recursos
necesarios
para
implementar este modelo
es mínima.
Es un modelo lineal
(más simples a ser
implementadas).
DESVENTAJAS
•
•
•
•
No se puede volver
atrás.
Poco
margen
para
realizar ajustes a lo largo
del proyecto debido a un
cambio
en
las
exigencias.
En ocasiones, los fallos
solo se detectan una vez
finalizado el proceso de
desarrollo.
El usuario final no se
integra en el proceso de
producción hasta que no
termina la programación.
INCREME
NTAL
En este modelo se
desarrolla
el
sistema
para
satisfacer
un
subconjunto de los
requisitos
especificados y en
posteriores
versiones
se
incrementa
el
programa
con
nuevas
funcionalidades
que
satisfagan
más requisitos.
•
•
•
•
•
•
•
•
El
modelo
incremental
entrega
el
software en partes
pequeñas,
pero
utilizables,
llamadas
incrementos. En
general
cada
incremento
se
construye sobre
aquel que ya ha
sido
entregado.
Cada secuencia
lineal produce un
incremento
del
software. El primer
incremento
generalmente es
un
producto
esencial
denominado
núcleo.
•
•
Se evitan proyectos largos y
se entrega “algo de valor” a
los usuarios con cierta
frecuencia.
El usuario se involucre más.
Difícil de evaluar el costo total.
Difícil de aplicar a los sistemas
transaccionales que tienden a
ser integrados y a operar
como un todo.
Requiere
gestores
experimentados.
Los errores en los requisitos
se detectan tarde.
El resultado puede ser muy
positivo.
se mantiene al cliente en
constante contacto con los
resultados obtenidos en cada
incremento.
Al igual que los otros métodos
de modelado, el Modelo
Incremental es de naturaleza
interactiva pero se diferencia
de aquellos en que al final de
cada incremento se entrega
un producto completamente
operacional.
Por otro lado los incrementos
se pueden planear para
gestionar
riesgos
más
fácilmente.
•
•
•
•
•
Las etapas de ingeniería de software que cubre
el modelo incremental son Definición y
Desarrollo.
•
•
Definición:
Análisis
Desarrollo:
Diseño
Código
Pruebas
•
•
•
Mediante este modelo se
genera software operativo
de forma rápida y en
etapas tempranas del ciclo
de vida del software.
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.
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.
Es un modelo más flexible,
por lo que se reduce el
coste en el cambio de
alcance y requisitos.
Es más fácil gestionar
riesgos.
•
•
•
•
•
Para el uso de este
modelo se requiere una
experiencia
importante
para
definir
los
incrementos y distribuir en
ellos las tareas de forma
proporcionada.
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.
Cada fase de una iteración
es rígida y no se
superponen con otras.
EVOLUTIV
O
consta
del
desarrollo de una
versión inicial que
luego
de
exponerse se va
refinando
de
acuerdo de los
comentarios
o
nuevas
necesidades por
parte del cliente o
del usuario final.
•
existen dos tipos de desarrollo
evolutivo:
•
•
Desarrollo Exploratorio:
El objetivo de este
enfoque es explorar con
el usuario los requisitos
hasta llegar a un sistema
final
Enfoque
utilizando
prototipos: El objetivo es
entender los requisitos
del usuario y trabajar
para mejorar la calidad de
los requisitos
•
•
•
•
Otras características:
•
•
•
•
•
•
•
Gestionan
bien
la
naturaleza evolutiva del
software.
Son
iterativos:
construyen versiones de
software cada vez más
completas.
Se adaptan bien
Los
cambios
de
requisitos del producto
Especificaciones
parciales del producto
Se puede aplicar en
todos los sistemas, pero
es más recomendado
para sistemas pequeños
y medianos
Estos modelos se aplican
cuando se reconoce la
naturaleza evolutiva del
proyecto de ingeniería de
software.
el desarrollo evolutivo consta del desarrollo de
una versión inicial que luego de exponerse se va
refinando de acuerdo de los comentarios o
nuevos requerimientos por parte del cliente o del
usuario final. las fases de especificación,
desarrollo y validación se entrelazan en vez de
separarse.
•
•
•
•
•
Especificación inicial
Desarrollo del producto
Implementación y evaluación
Versiones del software
Re-especificacion
Reduce el riesgo de
construir productos que no
satisfagan
las
necesidades
de
los
usuarios.
Reduce costo y aumenta
la probabilidad de éxito.
Exige disponer de las
herramientas adecuadas.
Este modelo es útil cuando
el cliente conoce los
objetivos generales para el
software, pero no identifica
los requisitos detallados
de entrada, procesamiento
o salida.
También ofrece un mejor
enfoque
cuando
el
responsable del desarrollo
del 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 humanomáquina.
•
•
El cliente considera la
mayoría de veces al
prototipo como el producto
final.
La calidad del software o
la
factibilidad
de
mantenimiento puede que
no se tome en cuenta.
ESPIRAL
es un modelo de
proceso
de
software evolutivo
que conjuga la
naturaleza
iterativa
de
construcción de
prototipos con los
aspectos
controlados
y
sistemáticos del
modelo
lineal
secuencial.
Proporciona
el
potencial para el
desarrollo rápido
de
versiones
incrementales del
software.
•
•
•
•
•
El modelo de desarrollo en
espiral se utiliza a menudo
para proyectos más grandes
que están sujetos a riesgos
Es un modelo que puede
combinarse
con
otros
modelos de procesos de
desarrollo
(cascada
y
evolutivo).
Es el mejor modelo que se
utiliza
para
desarrollar
grandes sistemas.
El análisis de riesgo requiere
la participación de personal
con experiencia.
Toma de Riesgos:
•
El Espiral utiliza el MCP
para reducir riesgos y
permite
aplicarlo
en
cualquier etapa de la
evolución. Mantiene el
enfoque
clásico
(cascada) pero incorpora
un marco de trabajo
iterativo que refleja mejor
la realidad.
•
Este modelo requiere
considerar
riesgos
técnicos en todas las
etapas del proyecto;
aplicado adecuadamente
debe reducirlos antes de
que sean un verdadero
problema.
•
•
•
Objetivo y determinación alternativa: Los
objetivos se determinan conjuntamente con el
cliente. Al mismo tiempo, se discuten posibles
alternativas y se especifican las condiciones
marco (por ejemplo, sistemas operativos,
entornos y lenguajes de programación).
Análisis y evaluación de riesgos: Se identifican
y evalúan los riesgos potenciales. También se
evalúan las alternativas existentes. Los riesgos
son registrados, evaluados y luego reducidos
utilizando prototipos, simulaciones y softwares de
análisis. En este ciclo, existen varios prototipos
como plantillas de diseño o componentes
funcionales
Desarrollo y prueba: Los prototipos se amplían
y se añaden funcionalidades. El código real es
escrito, probado y migrado a un entorno de
prueba varias veces hasta que el software pueda
ser implementado en un entorno productivo.
Planificación del siguiente ciclo: El siguiente
ciclo se planifica al final de cada etapa. Si se
producen errores, se buscan soluciones, y si una
alternativa es una mejor solución, se prefiere en
el siguiente ciclo.
•
•
Puede
adaptarse
y
aplicarse a lo largo de la
vida del software de
computadora.
Es un enfoque realista del
desarrollo de sistemas y
de software a gran escala.
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 niveles
evolutivos.
Utiliza la construcción de
prototipos
como
mecanismo de reducción
de riesgos.
Permite a quien lo
desarrolla
aplicar
el
enfoque de construcción
de prototipos en cualquier
etapa de evolución del
producto.
Mantiene
el
enfoque
sistemático de los pasos
sugeridos por el ciclo de
vida clásico, pero lo
incorpora al marco de
trabajo iterativo que refleja
de forma más realista el
mundo real.
•
•
•
•
•
•
•
Puede
resultar
difícil
convencer a grandes
clientes (particularmente
en
situaciones
bajo
contrato) de que el
enfoque
evolutivo
es
controlable.
Requiere
una
considerable
habilidad
para la evaluación del
riesgo.
No se ha utilizado tanto
como los paradigmas
lineales secuenciales o de
construcción
de
prototipos.
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 mucho tiempo en
el desarrollo del sistema.
Modelo costoso.
RAD
El
método
comprende
el
desarrollo
interactivo,
la
construcción de
prototipos y el uso
de
utilidades
CASE (Computer
Aided
Software
Engineering).
Tradicionalmente,
el
desarrollo
rápido
de
aplicaciones
tiende a englobar
también
la
usabilidad, utilidad
y la rapidez de
ejecución.
se
suele utilizar para
referirnos
al
desarrollo rápido
de interfaces
gráficas
de
usuario tales
como Glade,
o entornos
de
desarrollo
integrado complet
os. Algunas de las
plataformas más
conocidas
son Visual
Studio, Lazarus,
Gambas.
•
•
•
•
•
•
•
•
•
El software no se
desarrolla y utiliza en su
totalidad, sino en una
serie de incrementos,
donde
en
cada
incremento se incluyen
nuevas
funcionalidades
al
sistema.
A menudo se desarrollan
las interfaces de
usuario
del
sistema
utilizando un sistema de
desarrollo interactivo que
permite que
el diseño de la interfaz se
cree rápidamente
dibujando y colando
iconos en la interfaz.
Para su desarrollo se
utilizan herramientas de
desarrollo visual para
agilizar el proceso.
La aplicación funcionará
de
manera
independiente.
Se
pueden
usar
mayormente bibliotecas
existentes.
Desempeño no crítico.
Distribución
limitada,
interna o vertical.
Alcance del proyecto
limitado.
Confiabilidad no crítica.
Es adecuada para los
proyectos
de
bajo
presupuesto o con un
desarrollo rápido y con un
desempeño no tan crítico.
•
•
•
•
•
•
•
Modelado de gestión: Este modelo se basa en
dar respuesta a las siguientes preguntas: – ¿Qué
información conduce el proceso de gestión? –
¿Qué información genera?
Modelado de datos: En este modelo se definen
los almacenes de datos y cómo se relacionan los
almacenes entre si.
Modelado del proceso: Se utiliza para añadir,
modificar, suprimir o recuperar un objeto de
datos.
Generación de aplicaciones: Para esto se
utiliza una herramienta de cuarta(o quinta)
generación que permite crear el software y
facilitar la construcción del programa.
Pruebas y entrega: El proceso de desarrollo
finaliza realizando pruebas de calidad del
software diseñado con la herramienta RAD.
•
•
•
•
Comprar
puede
ahorrar dinero en
comparación
con
construir.
Los
entregables
pueden ser fácilmente
trasladados a otra
plataforma.
El
desarrollo
se
realiza a un nivel de
abstracción mayor.
Visibilidad temprana.
Mayor flexibilidad.
Menor
codificación
manual.
Mayor
involucramiento
de
los usuarios.
Posiblemente menos
fallas.
Posiblemente menor
costo.
Ciclos de desarrollo
más pequeños.
Interfaz
gráfica
estándar.
•
•
•
•
•
•
•
•
•
•
Comprar puede ser
más
caro
que
construir.
Costo
de
herramientas
integradas y equipo
necesario.
Progreso más difícil
de medir.
Menos eficiente.
Menor
precisión
científica.
Riesgo de revertirse a
las
prácticas
sin
control de antaño.
Más
fallas
(por
síndrome de “codificar
a lo bestia”).
Prototipos pueden no
escalar, un problema
mayúsculo.
Funciones reducidas
(por “timeboxing”).
Dependencia
en
componentes
de
terceros:
funcionalidad de más
o
de
menos,
problemas legales.
WIN-WIN
El modelo win-win
es una variante del
modelo en espiral.
En el modelo
espiral el software
se construye en
una
serie
de
versiones
incrementales
•
Se define como
aquellas tácticas
negociadoras
cuya
finalidad
reside en el hecho
en que las
dos
partes,
compradorproveedor, salgan
ganando con unas
condiciones muy
favorables
para
ambos.
•
•
•
•
•
•
•
•
Trata de mejorar los ciclos de
vida clásicos y prototipos.
Puede combinarse con otros
modelos de proceso de
desarrollo
En cada giro se construye un
nuevo modelo del sistema
completo.
Incorpora objetivos de calidad
y gestión de riesgos
Elimina errores y alternativas
no atractivas al comienzo
Permite iteraciones, vuelta
atrás y finalizaciones rápidas
Cada ciclo se completa con
una revisión que incluye todo
el ciclo anterior y el plan para
el siguiente
Análisis del riesgo: Se lleva a
cabo el estudio de las causas
de las posibles amenazas y
probables
eventos
no
deseados y los daños y
consecuencias que éstas
puedan producir.
Habitualmente tiene sentido
aplicar este método en
proyectos grandes, largos,
caros y complejos
1.- Identificación del sistema o subsistemas clave
de los directivos.
2. Determinación de las «condiciones de victoria
de ambas partes.
3. Negociación de las condiciones de victoria.
4.- Evaluar las alternativas del producto y del
proceso y resolución de riesgos.
5.- Definir el siguiente nivel del producto y del
proceso, incluyendo particiones.
6.- Validar las definiciones del producto y del
proceso.
7.- Revisión y comentarios.
•
El análisis del riesgo se
hace de forma explícita y
clara.
•
Une
los
mejores
elementos de los modelos
restantes.
•
No es recomendable
para
sistemas
pequeños, debido a su
complejidad
•
Resulta difícil convencer
a grandes clientes.
•
Reduce
proyecto.
del
•
Resulta como un modelo
muy costoso.
•
4.- Incorpora objetivos de
calidad.
•
Genera mucho tiempo
en el desarrollo del
sistema.
•
Integra el desarrollo con el
mantenimiento.
•
•
Añade la posibilidad de
tener en cuenta mejoras y
nuevos requerimientos sin
romper
con
la
metodología, ya que este
ciclo de vida no es rígido ni
estático.
Requiere experiencia en
la
identificación
de
riesgos.
•
Fallos en el análisis de
riesgos podría influir
negativamente a todo el
proyecto.
riesgos
PROGRA
MACIÓN
EXTREMA
La programación
extrema es una
metodología
de
desarrollo ágil que
tiene
como
principal objetivo
aumentar
la
productividad a la
hora
de
desarrollar
un
proyecto software.
Da prioridad a los
trabajos que dan
un
resultado
directo y en los
cuales se reduce
la burocracia que
pueda existir en el
entorno
de
trabajo.
•
•
•
•
•
•
•
•
La programación extrema
(XP), cuenta con los valores
de la comunicación, la
retroalimentación, el coraje y
el
respeto,
entre
los
elementos que conforman a
todo este proceso.
•
Un desarrollo iterativo e
incremental:
pequeñas
mejoras, unas tras otras.
Programación
en
parejas: Tareas de desarrollo
que se lleven a cabo por dos
personas en un mismo
puesto.
Frecuente integración
del
equipo de programación con
el cliente o usuario.
Refactorización del
código,
rescribir ciertas partes del
código para aumentar su
legibilidad y mantenibilidad,
sin
modificar
su
comportamiento.
Simplicidad, la programación
extrema apuesta que es más
sencillo hacer algo simple y
tener un poco de trabajo extra
para cambiarlo si se requiere,
que realizar algo complicado y
quizás nunca utilizarlo.
Es recomendable emplearlo
solo en proyectos a corto
plazo.
se
realizan
pequeños
programas
de
prueba
(“spikes”),
para
reducir
riesgos.
•
•
•
•
•
Este tipo de metodología tiene un proceso
continuo, es decir, que tendremos que repetir
continuamente todos los pasos para obtener un
resultado complaciente para el desarrollador y el
cliente.
Cada uno de los pasos llevaran a un
pequeño producto, sin embargo, se tienen
previstos que los errores en ellos sean naturales.
Las entregas de cada producto suelen ser
rápidas, teniendo como tiempo estimado de 2-3
semanas.
•
•
•
•
Planificación
Diseño
Codificación
pruebas
•
•
•
•
Relación estrecha con
el cliente
Facilita los cambios.
Ausencia de trabajos
de
programación
innecesarios.
Permite
ahorrar
mucho tiempo.
Menos
errores
gracias
a
la
programación
en
pareja.
Cuenta con una tasa
de
errores
muy
pequeña.
Puede ser aplicada a
cualquier lenguaje de
programación.
Da lugar a una
programación
sumamente
organizada.
El cliente tiene el
control sobre las
prioridades.
Se hacen pruebas
continuas durante el
proyecto.
•
•
•
•
•
•
Es
recomendable
emplearla solo en
proyectos a corto
plazo.
Fuerte dependencia
de las personas.
Dificultad
para
documentar.
Puede no siempre ser
más fácil que el
desarrollo tradicional.
Requiere control de
versiones.
Posibles “roces” con
el cliente.
MADUREZ
DE
CAPACID
ADES
El Modelo de
Madurez
de
Capacidades es
un modelo para
determinar
la
madurez de los
procesos
de
software y de la
organización, y la
identificación de
las
practicas
claves requeridas
para
el
mejoramiento
e
incremento de la
madurez de los
procesos y de
mejora de calidad
en el desarrollo y
mantenimiento de
software.
Características comunes:
•
Compromiso
de
la
realización: Describe las
acciones
que
la
organización debe realizar
para asegurar que el
proceso sea establecido y
pueda perdurar.
•
La capacidad de realización:
Describe las precondiciones
que deben existir en el
proyecto u organización
para implementar el proceso
de software en forma
competente.
➢ Recursos
y
financiamiento.
➢ Capacitación.
➢ Orientación.
•
•
•
•
•
•
•
•
•
Otras características:
•
•
•
Aplica
estudio
y
capacitación
para
la
realización de este proceso
específico.
Tiene un plan sistemático
secuencial, con un orden
determinado y único para el
desarrollo del proceso.
Define
procesos,
documentados y definidos,
integrando
disciplinas,
sistemas, software bajo la
premisa de mejorar el
proceso en su conjunto.
Nivel 1. Inicial: Se definen cuáles son los
lineamientos generales del proyecto y cuáles son
los posibles recursos disponibles para
concretarlo.
Nivel 2. Repetible: Se describen las actividades
y prácticas usadas por el equipo de desarrollo.
Nivel 3. Definido: Se definen los procesos según
las actividades requeridas, la disponibilidad de
recursos, se establecen los puntos de control, los
instrumentos de control que se utilizaran para
llevarlos a cabo, las herramientas y los métodos
requeridos.
Nivel 4. Administrado: En esta etapa la
organización del proyecto ya cuenta con la
estabilidad necesaria para poder incorporar
Mejora la visibilidad
sobre proyectos.
Mejora
la
comunicación.
Mejora
la
planificación.
Mejora la calidad del
producto.
Conocimiento de la
organización.
Mejor ambiente de
trabajo.
Se genera una base
de conocimiento.
Un
cliente
más
informado.
Reducción
del
número de defectos.
•
•
•
El
proceso
de
evaluación es muy
costoso en cuestión
de tiempo y esfuerzo.
Puede
ser
excesivamente
detallado
para
algunas
organizaciones.
Puede ser difícil de
entender.
herramientas de control
productividad más precisas.
de
calidad
y
Nivel 5. Optimizado: La evaluación emanada de
las etapas anteriores permite seleccionar
aquellos procesos exitosos para poder
replicarlos, y también identificar las brechas en
aquellos que necesitan mejoras.
PSP
Es un conjunto de
prácticas
disciplinadas, para
la gestión del
tiempo y mejora
de
la
productividad
personal de los
programadores o
ingenieros
de
software,
en
tareas
de
desarrollo
y
mantenimiento de
sistemas.
Está alineado y
diseñado
para
emplearse
en
organizaciones
con modelos de
procesos CMMI o
ISO 15504.
•
•
•
•
•
•
•
•
•
Con PSP los ingenieros
de
software
pueden
adquirir las habilidades
necesarias para trabajar
en un proceso de
software en equipo TSP.
Se puede considerar
como la guía de trabajo
personal para ingenieros
de
software
en
organizaciones
que
emplean
un modelo
CMMI con nivel de
madurez o de capacidad
de procesos que implica
la medición cualitativa y
mejora de procesos.
Mejora
del
funcionamiento.
Establecer
metas
personales.
identificar métodos a
utilizar.
Medir el trabajo.
Analizar resultados.
Toma en cuenta riesgos.
PSP pretende formar
ingenieros de software
con
métodos
disciplinados
para
mejorar su desarrollo
personal de software.
•
•
•
•
Disciplina de procesos y mediciones: (psp0,
psp0.1).
Estimación y planeación: (psp1, psp1.1).
Administración de la calidad y diseño: (psp2,
psp2.1).
TSP (desarrollo cíclico, administración de
riesgos, equipo de construcción).
•
Entre las ventajas a
destacar de este
modelo
podemos
mencionar la mejora
la productividad de las
personas.
mejora en los hábitos
de programación.
se puede lograr una
detección temprana
de defectos y riesgos
lo que deriva en una
disminución de los
defectos.
una mejora en la
calidad, y por lo tanto,
una reducción en el
ciclo de vida.
Se trabaja con un plan
con una base de
estimación
más
certera
al
ser
realizada
por
el
equipo; se logra una
buena comunicación
entre los integrantes.
•
•
•
•
Las desventajas de
este modelo es que
es necesario que
cada uno de los
miembros tiene que
tener el compromiso y
la disciplina de seguir
el plan.
Debe de llenar toda
la
documentación
requerida que incluye
sus
registros,
planificación,
las
plantillas
o
formularios.
Se debe de contar
con un buen conjunto
de
métricas
y
parámetros
de
calidad, lo cual, para
algunas
organizaciones,
puede ser difícil de
definir.
Cada miembro debe
de estar entrenado en
el PSP, si algún
miembro se va, es
necesario entrenar a
los nuevos miembros.
RUP
Es
una
metodología
de
desarrollo
de
software que está
basado
en
componentes
e
interfaces
bien
definidas, y junto
con el Lenguaje
Unificado
de
Modelado (UML),
constituye
la
metodología
estándar
más
utilizada para el
análisis,
implementación y
documentación de
sistemas
orientados
a
objetos.
•
•
•
•
•
•
•
•
•
•
Su función es hacer una
propuesta
orientada
por
disciplinas que deben seguir
los miembros del equipo de
desarrollo de software con el
fin
de
aumentar
su
productividad en el proceso
de desarrollo.
Su meta principal es asegurar
la producción de software de
alta calidad que cumpla con
las necesidades de los
usuarios, con una planeación
y presupuesto predecible.
desarrollo iterativo.
Administración de requisitos.
Uso de arquitectura basada
en componentes.
Control de cambios.
Modelado visual del software.
Verificación de la calidad del
software.
Pretende implementar las
mejores
prácticas
en
Ingeniería de Software, de
forma que se adapte a
cualquier proyecto.
Toma en cuenta riesgos.
•
•
Fase de inicio: Consiste en especificar y
delimitar los objetivos del proyecto y su alcance
con las partes interesadas.
fase de elaboración: Se establece la
arquitectura base del sistema para brindar una
plataforma segura, se definen los casos de uso
escogidos para ello.
fase construcción: El producto se desarrolla a
través de iteraciones donde cada iteración
involucra tareas de análisis, diseño e
implementación.
fase transición: Se libera el producto y se
entrega al usuario para un uso real.
Se incluyen tareas de marketing, empaquetado
atractivo,
instalación,
configuración,
entrenamiento, soporte, mantenimiento. Etc.
Los manuales de usuario se completan y refinan
con la información anterior.
Estas tareas se realizan también en iteraciones.
•
Es
el
proceso
de
desarrollo más general de
los
existentes
actualmente. Es decir,
este proceso es de los
más utilizados para el
desarrollo del software por
la
mayoría
de
las
empresas,
pues
su
enfoque
es
bastante
optimo y tiende a ser una
metodología viable para la
mayoría de estas.
Es una forma disciplinada
de asignar tareas y
responsabilidades en una
empresa de desarrollo,
pues lo roles están muy
bien definidos, y dictan
quien
realiza
cada
actividad, dependiendo del
área en el que se
desarrollara,
de
esta
manera es bastante útil
para definir roles en los
proyectos.
Los roles pueden ser
reutilizados en proyectos
futuros,
dando
como
resultado
una
mejor
organización al proyecto y
menos
utilización
de
recursos
o
tiempo,
aspectos que se pueden
emplear directamente en
el
proyecto.
•
•
•
Por
el
grado
de
complejidad puede ser no
muy adecuado. Debido a
que es un proceso
bastante
grande
y
complejo es muy común
que no sea el adecuado
para cualquier proyecto
pequeño (cosa que se
explicara en la siguiente
desventaja), es por eso
que a veces no puede ser
el adecuado.
En proyectos pequeños,
es posible que no se
puedan cubrir los costos
de dedicación del equipo
de
profesionales
necesarios. Al ser una
metodología bastante cara
y
con
bastantes
requerimientos en cuanto
a roles (personales), a
veces los costos son muy
elevados, dando como
resultado
una
imposibilidad por costear
el proyecto.
Método
pesado.
En
muchos aspectos tiende a
ser muy pesado, pues
como se explicaba en los
puntos
anteriores,
la
complejidad es alta.
KANBAN
Este método se
basa
en
el
desarrollo
incremental,
es
decir,
en
la
división del trabajo
en
diferentes
partes. Por lo
tanto, no se habla
de una tarea en sí,
sino que se agiliza
el proceso de
producción
al
dividir el trabajo en
distintos pasos.
•
•
•
•
•
•
Mover tarjetas dentro de una
lista o trasladar de una lista a
otra.
En cada tarjeta viene definida
una tarea.
Asignar personas a tarjetas.
Las aplicaciones de Kanban
son
herramientas
colaborativas en las que se
invita a distintos miembros e,
incluso, a clientes.
Añadir notas y comentarios en
las
tarjetas.
Las aplicaciones de Kanban
para la gestión de proyectos
cuentan con espacio ilimitado
para añadir notas en cada
tarjeta.
Incluir listas de control.
Cada tarjeta puede tener una
o más listas de verificación.
Establecer límites para el
avance
del
proyecto.
Algunas
aplicaciones
de
Kanban permiten restringir la
cantidad de tareas que se
pueden incluir en una lista.
Ver las tarjetas como un
calendario.
Muchas
aplicaciones
de
Kanban ofrecen la posibilidad
de activar una vista de
calendario.
•
•
Fases:
Informar al personal: formar a todo el personal
en los principios de Kanban y sus beneficios.
•
Identificación e implementación en las zonas
con problemas: implementar Kanban en
aquellos componentes con más problemas para
facilitar su proceso.
Implementar en el resto de zonas.
Revisión del sistema: esta fase consiste en la
revisión del sistema, teniendo en cuenta las
siguientes
recomendaciones
para
el
funcionamiento: ningún trabajo debe ser hecho
fuera de secuencia y si se encuentra algún
problema notificarlo al supervisor de manera
inmediata.
•
Transparencia: Los
tiempos de entrega
son más cortos y hay
una mayor fiabilidad
en los mismos. Todo
el mundo sabe cuál es
su tarea y en qué
momento está de su
ciclo.
Evita
tareas
ineficientes: Se evita
la sobreproducción y
la limitación de los
recursos,
lo
que
supone una mayor
disponibilidad
de
materiales.
Control de las tareas:
El
tiempo
de
producción es más
rápido, por tanto, se
reduce el control del
esfuerzo y se mejora
la planificación.
Flexibilidad:
Como
todo el equipo sabe
perfectamente cuál es
su tarea y la realiza
con eficacia, si surge
alguna
imprevista
existe una capacidad
de respuesta que
permite atenderla.
•
•
•
•
•
no
es
posible
implantar el método
Kanban cuando el
proveedor
tarda
mucho en suministrar
el producto.
Se trata de un sistema
que
no
permite
anticiparse a grandes
aumentos
de
la
demanda. En el caso
de recibir muchos
pedidos de golpe la
empresa
podría
encontrarse
desbordada.
En grandes proyectos
es posible que no se
cumplan los plazos de
entrega
Muchos proveedores
no aceptan trabajar
bajo
estas
condiciones.
Prefieren suministrar
los productos bajo el
método convencional.
Cuando se trabaja
con
muchas
referencias
puede
resultar un sistema
poco eficiente.
UML
UML es un popular
lenguaje
de
modelado
de
sistemas
de
software. Se trata
de un lenguaje
gráfico
para
construir,
documentar,
visualizar
y
especificar
un
sistema
de
software.
Entre
otras
palabras,
UML se utiliza
para definir un
sistema
de
software.
•
Características de un UML :
•
•
•
•
visualizar.
Especificar.
Construir.
documentar y/o ser base
de documentación.
Lo
fundamental
herramienta UML:
•
•
•
•
•
de
•
una
La
capacidad
de
diagramación,
y
los
diferentes
tipos
de
diagramas que soporta la
herramienta
Documentación
Construcción
Implantación de sistema
Flexibilidad para admitir
cambios no previstos
durante el diseño o el
rediseño.
•
•
•
•
•
•
•
•
•
•
Diagramas de clases
Diagramas de objetos
Diagramas de casos de uso
Diagramas de componentes
Diagramas de distribucion
Diagramas de actividad
Diagramas de estados
Diagramas de colaboracion
Diagramas de secuencia
•
•
El objetivo de la
realización
del
proyecto podría a ser
más alcanzable ya
que ayuda a analistas
a simplificar el diseño
del software.
Al utilizar UML será
más
intuitivo
y
ayudará
a
crear
sentido sobre los
requerimientos
y/o
procesos
del
software.
Con
respecto
al
diagrama de Clases
UML dará una mayor
ilustración y visión
general del sistema
porque se podrán
representar
los
atributos del objeto,
tipos de datos, los
comportamiento
y
tipos de retorno
UML
ayudará
a
pensar con mayor
claridad la fase de
codificación.
UML colaborará a
optimizar el uso del
tiempo.
•
•
•
•
UML
solo
está
orientado a objetos
Al parecer no se
pueden resolver todos
los
problemas
surgidos con
los
diagramas UML
UML tiene énfasis en
el diseño lo que
puede
ser
problemático
para
algunos
desarrolladores.
Los diagramas UML
pueden
ser
abrumadores
visualmente. Si se
intenta ubicar en
estos diagramas y
trazar
todos
los
escenarios para el
sistema
de
información
puede
volverse
desordenado.
De
acuerdo a Borini, S.
(Desarrollador UML)
recomienda
incluir
hechos
básicos,
puntuales,
e
información de alto
nivel en los diagramas
UML.
CONCLUSIONES
José Luis Baltazar Anaya
Hoy en día el desarrollo de software es un proceso muy complejo, es por eso que se crearon los modelos y metodologías
para el desarrollo de sistemas de información, las metodologías de ingeniera de software consisten en el uso de métodos,
técnicas, herramientas y modelos para el desarrollo. Actualmente existen muchas metodologías y la selección de cada una
de ellas dependerá del tipo de proyecto que se quiera realizar, existen metodologías antiguas y modernas como en todo,
ya que, con el paso del tiempo el proceso de desarrollo de software ha ido evolucionando y con ello su nivel de complejidad
aumentando, es así que las metodologías modernas contemplan características como el desarrollo de software de manera
iterativa, manejo de requerimientos, modelado de software visual, control de cambios, control de riesgos, estos se centran
en ser flexibles y adaptables de acuerdo al tipo de proyecto. Existen metodologías que no solo se centran en el software si
no que hay algunas que se caracterizan por ayudar al desarrollador a mejorar su nivel de productividad, su nivel de
organización, a superar sus propias metas y ser mejor programador, para que, el proyecto se desarrolle de mejor manera
y tenga calidad, que es lo que siempre se busca con la ingeniera de software. Es por eso que un ingeniero de software
debe conocer, estudiar e identificar cada tipo de modelo y metodología, para siempre estar preparado.
Crhistian Ivan Madrueño Aguilar
En la actualidad la rapidez y el dinamismo en la industria del software han hecho replantear los cimientos sobre los que se
sustenta el desarrollo de software tradicional. Estudios recientes y el mismo mercado actual está marcando la tendencia en
la ingeniería del software teniendo como características principales atender a las necesidades de rapidez, flexibilidad y
variantes externas que hacen de nuestro entorno una ventaja más competitiva al aumentar la productividad y satisfacer las
necesidades del cliente en el menor tiempo posible para proporcionar mayor valor al negocio. Ante esta situación, el grado
de adaptación de las metodologías tradicionales a estos entornos de trabajo no eran del todo eficientes y no cubrían las
necesidades del mercado actual. En la actualidad existen una gran cantidad de metodologías para el desarrollo de software,
separadas en dos grandes grupos; las metodologías tradicionales o pesadas y las metodologías agiles. Las metodologías
tradicionales se basan en las buenas prácticas dentro de la ingeniería del software, siguiendo un marco de disciplina estricto
y un riguroso proceso de aplicación. Las metodologías agiles, en cambio, representan una solución a los problemas que
requieren una respuesta rápida en un ambiente flexible y con cambios constantes, haciendo caso omiso de la
documentación rigurosa y los métodos formales.
BIBLIOGRAFÍA
Hope, J. A. (s.f.). UNIDAD 3- presentacion power point.
http://avellano.usal.es. (s.f.). Obtenido de http://avellano.usal.es/~mmoreno/ASTema2.pdf
https://moodle2.unid.edu.mx. (s.f.). Obtenido de https://moodle2.unid.edu.mx/dts_cursos_mdl/lic/IEL/SI/AM/06/Modelos.pdf
https://repositorio.uca.edu.ar. (s.f.). Obtenido de https://repositorio.uca.edu.ar/bitstream/123456789/522/1/metodologias-desarrollosoftware.pdf
https://www.ecured.cu. (s.f.). Obtenido de https://www.ecured.cu/Desarrollo_de_software
https://www.elconspirador.com. (s.f.). Obtenido de https://www.elconspirador.com/2013/08/19/modelos-de-desarrollo-de-software/
informatica, g. 3. (s.f.). presentaciones power point unidad 3.