Unidad 2 ing de software

INSTITUTO TECNOLOGICO
SUPERIOR DE LA COSTA CHICA.
CARRERA:
ING. EN TECNOLOGIAS DE LA
INFORMACION Y COMUNICACIONES
UNIDAD 2:
Modelos de la ingeniería del software
DOCENTE:
LIC.DORA AGUIRRE MARTINEZ
EQUIPO:
INTREGRANTES:
BARRERA JAVIER ARMANDO
GOMEZ LAGUNAS RICARDO
HERNANDEZ LOPEZ ROBERTO
HERNANDEZ SANCHEZ DELFINO

2.1 MODELO DE
CAPACIDAD DE
MADUREZ
EL MODELO CMM DEFINE QUE DEBEN EXISTIR ALGUNAS ÁREAS O
PROCESOS CLAVE EN LA ORGANIZACIÓN QUE DEBERÁN REALIZAR
ALGUNA FUNCIÓN ESPECÍFICA. A ESTAS ÁREAS SE LES DENOMINA
COMO ÁREAS CLAVE DE PROCESO (KPA - KEY PROCESS AREA).
EL MODELO DEFINE PARA CADA UNA DE ESTAS ÁREAS UN CONJUNTO
DE BUENAS PRÁCTICAS, DEPENDIENDO DE QUE TANTO SE AJUSTEN
ESTAS ÁREAS CON EL MODELO CMM SE PUEDE CONOCER EL NIVEL DE
MADUREZ DE ESTA ORGANIZACIÓN.
EL MODELO CMM Y EL MODELO CMMI - CAPABILITY MATURITY MODEL
INTEGRATION SE DIFERENCIAN BÁSICAMENTE EN QUE EL PRIMERO SE
ENFOCA PRINCIPALMENTE A LAS ORGANIZACIONES O ÁREAS DE
TECNOLOGÍAS DE INFORMACIÓN EN CAMBIO EL MODELO CMMI COMO
SU NOMBRE LO INDICA ES UN MODELO INTEGRADO Y MEJORADO QUE
SE PUEDE APLICAR A UN NUMERO MAYOR DE ORGANIZACIONES DE
DIFERENTES SECTORES.
19/07/2014UNIDAD 2 Modelos de la ingeniería

EL MODELO CMM DEFINE 5
NIVELES DE MADUREZ:

INICIAL.
ES EL PRIMER NIVEL ES DECIR QUE NO ES NECESARIO HACER
NINGÚN ESFUERZO PARA LLEGAR AQUÍ, LAS ORGANIZACIONES EN
ESTE NIVEL NO DISPONEN DE UN AMBIENTE ADECUADO PARA EL
DESARROLLO DE SOFTWARE. AUNQUE SE UTILICEN TÉCNICAS
CORRECTAS DE INGENIERÍA, LOS ESFUERZOS SE VEN MINADOS POR
FALTA DE PLANIFICACIÓN. LOS PROCESOS VARÍAN SEGÚN LOS
INDIVIDUOS, EL ÉXITO DE LOS PROYECTOS SE BASA LA MAYORÍA DE
LAS VECES EN EL ESFUERZO PERSONAL, AUNQUE A MENUDO SE
PRODUCEN FRACASOS Y CASI SIEMPRE RETRASOS Y SOBRE COSTOS.
EL RESULTADO DE LOS PROYECTOS ES IMPREDECIBLE Y ESTA
POBREMENTE CONTROLADO

REPETIBLE.
EN ESTE SEGUNDO NIVEL SE ENCUENTRAN LAS EMPRESAS EN
LAS QUE EXISTE PLANIFICACIÓN Y SEGUIMIENTO DE PROYECTOS
Y ESTÁ IMPLEMENTADA LA GESTIÓN DE LOS MISMOS. NO
OBSTANTE, AÚN EXISTE UN RIESGO SIGNIFICATIVO DE NO
CUMPLIR LAS METAS.
DEFINIDO.
EXISTE UN CONJUNTO ESTABLECIDO DE PROCESOS ESTÁNDAR
GLOBALES BIEN DEFINIDOS (ESTABLECIENDO SUS OBJETIVOS)
DENTRO DE LA ORGANIZACIÓN. EXISTE UN SISTEMA DE GESTIÓN
DE LOS PROYECTOS. UNA DIFERENCIA CRÍTICA ENTRE LOS
NIVELES 2 Y 3 DE MADUREZ ES EL ALCANCE DE LOS
ESTÁNDARES, DESCRIPCIONES DE LOS PROCESOS Y
PROCEDIMIENTOS. EN EL NIVEL 2 PUEDEN VARIAR ENTRE LAS
DISTINTAS INSTANCIAS DE LOS PROCESOS (ENTRE DIFERENTES
PROYECTOS); A NIVEL 3 SON GLOBALES DENTRO DE
LA ORGANIZACIÓN E IGUAL EN TODAS LAS INSTANCIAS DE CADA
PROCESO.

GESTIONADO.
SE CARACTERIZA PORQUE LAS ORGANIZACIONES DISPONEN DE UN
CONJUNTO DE MÉTRICAS SIGNIFICATIVAS DE CALIDAD Y
PRODUCTIVIDAD, QUE SE USAN DE MODO SISTEMÁTICO PARA LA TOMA
DE DECISIONES Y LA GESTIÓN DE RIESGOS. EL SOFTWARE
RESULTANTE ES DE ALTA CALIDAD.
OPTIMIZADO.
LA ORGANIZACIÓN COMPLETA ESTÁ VOLCADA EN LA MEJORA
CONTINUA DE LOS PROCESOS. SE HACE USO INTENSIVO DE LAS
MÉTRICAS Y SE GESTIONA EL PROCESO DE INNOVACIÓN

MODELOS DE MADUREZ DEL CMM
ESTE GRAFICO ME PERMITIÓ ENTENDER MEJOR COMO EL MODELO
CMM DEFINE ESTOS 5 NIVELES Y CLASIFICA A LAS ORGANIZACIONES
EN ALGUNO DE ESTOS.

NIVEL 1
EN EL NIVEL INICIAL EL RESULTADO DE LOS PROCESOS SUELE SER
IMPREDECIBLE TAL COMO LO MUESTRA EL GRAFICO, NO EXISTEN
ÁREAS O FUNCIONES FORMALMENTE DEFINIDAS ASÍ COMO TAMPOCO
PUNTOS DE CONTROL EN EL PROCESO, SOLO SE PUEDE TENER UNA
VISIÓN CLARA DE LAS COSAS CUANDO SE EMPIEZA EL PROYECTO Y
CUANDO SE LOGRA ACABAR, PERO NO ES POSIBLE CONOCER DE
MANERA ADECUADA EL ESTADO DEL PROYECTO EN SUS PROCESOS
INTERMEDIOS. ES POR ESO QUE EN ESAS CIRCUNSTANCIAS SURGEN
PERSONAS QUE SE SUBEN AL HOMBRO EL PROYECTO Y LO LOGRAN
SACAR ADELANTE, AUNQUE GENERALMENTE ESTE TIPO DE
PROYECTOS SUFRIRÁ DEMORAS Y PROBABLEMENTE NO SE
CULMINARÁ.

NIVEL 2
SEGÚN NUESTRO GRAFICO YA ES POSIBLE VER UNA GRAN
DIFERENCIA ENTRE EL NIVEL INICIAL Y EL REPETIBLE, EN ESTE
SEGUNDO NIVEL SE PUEDE OBSERVAR QUE SE DEFINEN
CLARAMENTE PUNTOS DE CONTROL EN CADA ETAPA PRINCIPAL DEL
PROYECTO, ESTO OBVIAMENTE PERMITE TENER UN MAYOR CONTROL
DEL PROYECTO. LO IMPORTANTE A RESALTAR DEL GRAFICO ES QUE
CADA ETAPA ES AÚN UNA CAJA NEGRA ES DECIR NO PODEMOS
SABER CON PRECISIÓN COMO SE DESENVUELVE EL PROYECTO
DENTRO DE CADA ETAPA.
NIVEL 3
LOS PROCESOS COMUNES PARA DESARROLLO Y MANTENIMIENTO
DEL SOFTWARE ESTÁN DOCUMENTADOS DE MANERA SUFICIENTE EN
UNA BIBLIOTECA ACCESIBLE A LOS EQUIPOS DE DESARROLLO. LAS
PERSONAS HAN RECIBIDO LA FORMACIÓN NECESARIA PARA
COMPRENDER LOS PROCESOS. EN CONCLUSIÓN CADA PROCESO SE
HACE TRANSPARENTE PARA TODOS

NIVEL 4
TAL COMO LO MUESTRA EL GRAFICO, LA PRINCIPAL DIFERENCIA CON
EL NIVEL ANTERIOR ES LA MEDICIÓN Y CONTROL DE LOS PROCESOS
(MÉTRICAS). ESTAS MÉTRICAS NO SON SUBJETIVAS SI NO QUE SE
ESTABLECEN CON CRITERIOS CUANTITATIVOS FORMALMENTE
DEFINIDOS. CON EL TIEMPO ESTOS CONTROLES NOS BRINDARAN
MEJOR INFORMACIÓN SOBRE LA CALIDAD Y ESTADO DEL PROYECTO
PERMITIÉNDONOS COMPARARLO CON OTROS PROYECTOS SIMILARES
Y NOTAR CUALQUIER DESVIACIÓN TEMPRANAMENTE PARA PODER
CORREGIRLO.
NIVEL 5
EN ESTE NIVEL CADA PROCESO ES ANALIZADO Y CONTROLADO
PERMANENTEMENTE CON LA INTENCIÓN DE QUE SEA MEJORADO EN
TODO MOMENTO, LOS CONTROLES PERMITEN LA MEJORA CONTINUA
Y SE TIENEN IMPLEMENTADAS TODAS LAS ÁREAS CLAVE DE
PROCESO RECOMENDADAS POR EL MODELO.

A PARTIR DEL 2DO NIVEL DEL MODELO CMM SE DEBE CONTAR CON
ÁREAS ESPECÍFICAS QUE PERMITIRÁN TENER UN MAYOR CONTROL
DEL PROYECTO DE SOFTWARE:
PARA EL NIVEL 2 AL MENOS SE DEBERÁ CONTAR CON LAS
SIGUIENTES ÁREAS CLAVE DE PROCESO
GESTIÓN DE REQUISITOS PLANIFICACIÓN DEL
PROYECTO DE SOFTWARE
SEGUIMIENTOY
SUPERVISIÓN DEL
PROYECTO
GESTIÓN DE
SUBCONTRATOS DE
SOFTWARE
GARANTÍA DE CALIDAD DE
SOFTWARE
GESTIÓN DE LA
CONFIGURACIÓN DEL
SOFTWARE

Base para el proceso de software completo.
•Es como un libro de recetas de cocina.
•La adaptación es especial
•Aplicable a lo largo del proceso de software.
•Su objetivo la gestion,el rastreo y el control del proyecto,
•Garantiza la calidad del software.

Actividades del marco de
trabajo:
Aplicable a todos los proyectos

Conjunto de tareas:
Actividades que hacen que el marco de trabajo se adapte a las características
particulares de cada proyecto. Define el trabajo real a cumplirse:
Tareas
Hitos, entregas.
Puntos SQA

2.3. Modelos de la ingeniería del software:
modelo de cascada, modelo de prototipos,
modelo de espiral, modelo de Proceso
Unificado Racional (RUP).

Modelo de cascada:
•Es un modelo sencillo para explicar al cliente.
•También llamado ciclo de vida clásico sugiere un enfoque sistemático.
secuencial en el desarrollo del software.
•Requiere que los requerimientos estén bien definidos y estables en forma
razonable.
•Es el paradigma mas antiguo para la Ingeniería del Software.

Fases:
•Ingeniería y Análisis del Sistema: Debido a que el software siempre es parte
de un sistema mayor el trabajo comienza estableciendo los requerimientos de
todos los elementos del sistema y luego asignando algún subconjunto de estos
requisitos al software.
•Análisis de los requerimientos del software: El proceso de recopilación de los
requerimientos se centra e intensifica especialmente en el software. El
ingeniero del software debe comprender el ámbito de la información del
software así como la función del rendimiento y las interfaces requeridas.
.
•Diseño: 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 :Debe traducirse en una forma legible para la maquina.

VENTAJAS Y DESVENTAJAS

Ventajas:

Desventajas:

Modelo de prototipos:

VENTAJAS
La posibilidad de
cambiar el modelo.
La oportunidad para
suspender el modelo
del desarrollo del
modelo sino es
funcional.
La oportunidad de
crear un nuevo
modelo que se ajuste
a mejor a las
necesidades y
expectativas de los
usuarios.

Relaciones de usuario:
Las sugerencias obtenidas de los usuarios lleven al analista hacia
adecuaciones o cambios que se ajustan mejor a las necesidades de los
usuarios y que no habían sido pensadas antes de la interacción del usuario con
el prototipo. Debe ser construido en poco tiempo ,no debe de utilizarse mucho
dinero, cuando este sea aprobado podemos iniciar el verdadero desarrollo del
software.Prodra ser construido si con el software es posible experimentar.

Desventajas:
Debido a que el usuario ve que funciona piensa que este es el producto
terminado y no entienden que recién se va a desarrollar el software .
Debe ir acompañado de otro modelo para su desarrollo.

Tipo de modelo de prototipo:
Desechable.: Nos sirve para eliminar dudas sobre las que realmente quiere al
cliente además para desarrollar la interfaz que mas le convenga al cliente.
•Evolucionario.: Es parcialmente construido que puede pasar de ser prototipo a
ser software pero no tiene una buena documentación y calidad.
A favor:
Útiles cuando los requerimientos son cambiantes.
Cuando nose conoce bien la aplicación.
Cuando el usuario no se quiere comprometer con los requerimientos.
Cuando se quiere probar una arquitectura o tecnología. Cuando se requiere
rapidez en el desarrollo.

En contra:
No se conoce cuando se tendrá un producto aceptable.
No se sabe cuantas interacciones serán necesarias.
Da una falsa ilusión al usuario sobre la velocidad del desarrollo.
Se puede volver al producto aun y cuando no este en los estándares.

Modelo en espiral:
Las actividades se conforman en un espiral en la que cada bucle o interacción
representa un conjunto de actividades, no están fijadas a prioridad sino que las
siguientes se eligen en función de análisis de riesgo comenzando por el bucle
interior.

Características:
•Encada giro se construye un nuevo modelo del sistema
completo.
•Este modelo puede combinarse con otros modelos de
proceso de desarrollo .
•Mejo ir modelo para desarrollo de grandes sistemas.
El análisis de riesgo requiere la participación del personal
con alta calificación.
No hay numero definido de interacciones ,deben de
decidirlas el equipo de gestión de proyecto.

Ventajas:
Modelo espiral de cuatro regiones o modelo original de Boehm.
Modelo espiral de seis regiones.
Modelo espiral WINWIN.
Modelo espiral de cuatro regiones o modelo original de Boehm

Modelo espiral WINWIN:
WINWIN(Victoria) sugiere una actividad del marco de trabajo que aborda la
comunicación con el cliente. El objetivo de esta actividad es mostrar los
requisitos del cliente. En un contexto ideal del desarrollador simplemente
pregunta al cliente lo que se necesita y proporciona detalles suficientes para
continuar.
Ventajas:
•El modelo en espiral es un enfoque realista del desarrollo de sistemas.
•Modelo de proceso adaptable.
•El modelo en espiral puede s aplicarse a lo largo de la vida del software.
•El desarrollador y el cliente comprenden y reaccionan mejor ante riegos en
cada uno de los niveles evolutivos.
•Permite a quien lo desarrolla aplicar el enfoque de construccion de prototipos
en cualquier etapa de evolución del producto.

Demanda una consideración directa de los riesgos técnicos en todas las
etapas del proyecto y si se aplicada adecuadamente debe reducir los
riesgos antes de que se conviertan en problemas.
•Modelos evolutivos como el espiral son apropiados particularmente para el
desarrollo de Sistemas OO.
•Trata de mejorar los ciclos de vida de clásicos y prototipos.
•Permite acomodar otros modelos.
•Incorpora objetivos de calidad y gestión de riesgos.
•Elimina errores y alternativas no atractivas al comienzo.

Desventajas:
•Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es
controlable.
•Es nuevo y no se a utilizado tanto como otros modelo de ciclo de vida.
•Requiere una considerable habilidad para la evaluación del riesgo y cuenta
con esta habilidad para el éxito.
•Si un riesgo es importante no es detectado y gestionado a tiempo
indudablemente surgirán problemas.
Hitos del modelo WIN-WIN:
Introduce tres hitos son los procesos llamados puntos de fijación que ayudan a
establecer la completitud de un ciclo alrededor de la espiral y proporcionan
hitos de decisión antes de continuar el proyecto de software.
Los puntos de fijación representan tres visiones diferentes del progreso
mientras que el proyecto recorre la espiral.

2.4. Tendencias modernas de modelos de la
ingeniería del software.

XP:Programacion extrema:
De todas las metodologías hábiles esta recibe mas atencion.Valores
:Retroalimentación.
Comunicación.
Simplicidad .
Coraje.
Construye un proceso de diseño evolutivo refractora un sistema simple en cada
iteración que se centra en la iteraccion actual no se hace nada
anticipadamente. Combina la disciplina con la adaptabilidad.Kent Beck escribió
Extreme Programming Explained que es clave de la XP.
La familia de cristal de Cockburn:
Tipos diferentes de proyectos requieren tipos diferentes de metodología.
Costituye:el numero de personas de un proyecto y las consecuencias de los
errores. Alistar requiere que las personas sigan un proceso diciplinado,explora
a metodología menos disciplinada que aun pueda tener éxito intercambiando
productividad. El cristal es menos productivo que la XP más personas serán

Código abierto: Es un estilo de software, en particular su proceso se engrana a
equipos físicamente distribuidos, la mayoría de los procesos adaptables exigen
procesos locales. La mayoría tiene uno mas mantenedores. Un mantenedor es
la única persona a la que se permite hacer cambio en el almacén de código
fuente, otras personas también pueden hacer cambios pero necesitan
madarlas a mantenedor para que las revise aplique.
El desarrollo de software adaptable de Highsmith:
Trabajando con metodologías predictivas. él las desarrolló, instaló, enseñó, y
concluyó que son defectuosas: particularmente para los negocios modernos.
En ASD hay tres fases, no lineales: especulación, colaboración, y aprendizaje.
En un ambiente adaptable, aprender desafía a todos - desarrolladores y sus
clientes - a examinar sus asunciones y usar los resultados de cada ciclo de
desarrollo para adaptar el siguiente.

Scrum:
Scrum divide un proyecto en iteraciones (que ellos llaman carreras cortas) de
30 días. Antes de que comience una carrera se define la funcionalidad
requerida para esa carrera y entonces se deja al equipo para que la entregue.
el punto es estabilizar los requisitos durante la carrera.
Todos los días el equipo sostiene una junta corta (quince minutos), llamada
Scrum, dónde el equipo discurre lo que hará al día siguiente. la literatura de
Scrum se enfoca principalmente en la planeación iterativa y el seguimiento del
proceso.
Desarrollo manejado por rasgo:
Fue desarrollado por Jeff de Luca y Peter Coad. Las iteraciones duran dos
semanas. Tiene cinco procesos. los primeros tres se hacen al principio del
proyecto.

•desarrollar un modelo global
•construir una lista de los rasgos
•planear por rasgo
•diseñar por rasgo
•construir por rasgo
Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas
y se da un criterio de comprobación.
Los desarrolladores entran en dos tipos: dueños de clases y programadores
jefe.
DSDM (MÉTODO DE DESARROLLO DE SISTEMA DINÁMICO)
Empieza con un estudio de viabilidad y negocio. Viabilidad considera si
DSDM es apropiado para el proyecto. Negocio es una serie corta de talleres
para entender el área de negocio dónde tiene lugar el desarrollo. También
propone arquitecturas de esbozos del sistema y un plan del proyecto.

El resto del proceso forma tres ciclos entretejidos: el ciclo del modelo
funcional produce documentación de análisis y prototipos, el ciclo de diseño
del modelo diseña el sistema para uso operacional, y el ciclo de
implantación se ocupa del despliegue al uso operacional.

Unidad 2 ing de software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Unidad 2 ing de software

Similar a Unidad 2 ing de software (20)

Unidad 2 ing de software