INGENIERIA DE SOFTWARE

EL PROCESO

1
 CONTENIDO
INTRODUCCIÓN
DEFINICIONES
TECNOLOGÍA ESTRATIFICADA
EL PROCESO DEL SOFTWARE
MODELOS DEL SOFTWARE
TECNOLOGÍA DE PROCESOS
PRODUCTO Y PROCESO
RESUMEN
2
 INTRODUCCION
EL SOFTWARE HOY EN DIA SE
CONSIDERA COMO UN PRODUCTO Y
PARA ELLO SE DEBE CONSTRUIR
DESDE UN ENFOQUE DISCIPLINARIO Y
ESTO CONDUCE A LA TERMINACIÓN
DE UN PRODUCTO CON CALIDAD.

3
 DEFINICIONES
“LA APLICACIÓN DE UN ENFOQUE SISTEMICO,
DISCIPLINADO Y CUANTIFICABLE HACIA EL
DESARROLLO, OPERACIÓN Y
MANTENIMIENTO DEL SOFTWARE”
“EL PROCESO DEL SOFTWARE DEFINE UN
MARCO DE TRABAJO DE LAS TAREAS QUE SE
REQUIEREN PARA CONSTRUIR SOFTWARE
DE ALTA CALIDAD”

4
TECNOLOGÍA ESTRATIFICADA

COMPRENDE DE CAPAS LAS MISMAS

QUE ESTAN SUPERPUESTAS E
INTERACTUAN ENTRE SI.

ENFOQUE DE CALIDAD
PROCESO
METODOS
HERRAMIENTAS
5
EL PROCESO DEL SOFTWARE

HERRAMIENTAS

METODOS

PROCESO

6
 CALIDAD
SON LOS CIMIENTOS DE LA
INGENIERIA DEL SOFTWARE QUE
COMPRENDE GESTIÓN TOTAL DE
CALIDAD
GARANTIA DE CALIDAD DEL
SOFTWARE

7
 PROCESO

ES UN DESARROLLO
RACIONAL DE LA
INGENERÍA DEL
SOFTWARE

8
 METODOS
COMO CONSTRUIR TECNICAMENTE EL
SOFTWARE:
ANÁLISIS DE REQUISITOS
DISEÑO
PROGRAMACIÓN
PRUEBAS Y
MANTENIMIENTO
9
 HERRAMIENTAS
LAS HERRAMIENTAS DAN UN
SOPORTE AUTOMÁTICO O SEMI
AUTOMÁTICO PARA EL PROCESO Y
METODOS
EJEMPLO LAS HERRAMIENTAS CASE

10
UNA VISIÓN GENERAL DE
LA INGENIERÍA DEL
SOFTWARE

11
 CARACTERISTICAS GENERICAS DEL
PROCESO DEL SOFTWARE

DEFINICION: INGENIERÍA DE SISTEMAS DE

INFORMACIÓN, PLANIFICACIÓN DEL
PROYECTO DEL SOFTWARE, ANALISIS DE
LOS REQUISITOS

DESARROLLO: DISEÑO DEL SOFTWARE,

GENERACIÓN DE CÓDIGO, PRUEBA DEL
SOFTWARE

12
MANTENIMIENTO: COMPRENDE
CORRECCIÓN DE ERRORES, ADAPATACIÓN A
LA EVOLUCIÓN DEL ENTORNO DEL
SOFTWARE, A LOS CAMBIOS POR LAS
MEJORAS DE LOS REQUISITOS DE LOS DE
LOS CLIENTES

A ESTAS TAREAS SE CONOCEN COMO FASES

GENÉRICAS DEL PROCESO DEL SOFTWARE

13
 TAREAS: EL QUE

 QUE INFORMACIÓN QUE HA DE SER

PROCESADA,
 QUE FUNCIONES Y RENDIMIENTOS SE
DESEA
 QUE COMPORTAMIENTO SE DESEA DEL
SISTEMA
 INTERFASES QUE VAN A SER ESTABLECIDAS
 RESTRICCIONES DE DISEÑO QUE EXISTEN

14
 TAREAS: EL COMO
 HA DE DISEÑARSE LA ESTRUCTURA DE DATOS
 HA DE IMPLEMENTARSE LA FUNCIÓN, COMO
UNA ARQUITECUTRA DEL SOFTWARE
 HAN DE SER LAS CARCATERISTICAS DE LAS
INTERFASES
 HA DE IMPLEMENTARSE LOS DETALLES
PROCEDIMENTALES
 HA DE TRADUCIRSE EL DISEÑO A UN
LENGUAJE DE PROGRAMACIÓN
 HA DE REALIZARSE LA PRUEBA
15
 TIPOS DE CAMBIOS
 CORRECCIÓN: DESCUBRIMIENTO DE
DEFECTOS EN EL SOFTWARE POR EL
CLIENTE, MANTENIMIENTO CORRECTIVO

 ADAPTACIÓN: CAMBIO DEL ENTORNO

ORIGINAL DEL SOFTWARE CON EL TIEMPO
POR Ejemplo, REGLAS DE LA EMPRESA, S.O.,
CPU, CARACTERISTICAS EXTERNAS PARA EL
QUE SE DESARROLLO EL SOFTWARE, SE
DENOMINA MANTENIMIENTO PERFECTIVO
16
 TIPOS DE CAMBIO
 MEJORA: DESCUBRIMIENTO DE FUNCIONES
ADICIONALES QUE VAN A PRODUCIR
BENEFICIOS, MANTENIMIENTO PERFECTIVO
 PREVENCIÓN: DETERIORO DEL SOFTWARE
POR EL CAMBIO, CAMBIOS EN PROGRAMAS
PARA CORREGIR, ADAPTAR Y MEJORAR MAS
EFICIENTEMENTE. MANTENIMIENTO
PREVENTIVO.

17
 RESUMEN
LOS PROBLEMAS REALES SE TRATAN POR UNA
ESTRATEGÍA DE DESARROLLO LA MISMA QUE
INVOLUCRA:
PROCESO
METODOS
HERRAMIENTAS Y
FASES GENERICAS DEL PROCESO
A TODO ESTO SE LLAMA MODELO DE PROCESO O
PARADIGMA DE LA INGENIERÍA DE SOFTWARE
18
 MODELOS DEL PROCESO DEL
SOFTWARE

BUCLE DE RESOLUCIÓN DE PROBLEMAS

TODO EL DESARROLLO DEL SOFTWARE
SE PUEDE CARACTERIZAR COMO UN
BUCLE DE RESOLUCIÓN DE
PROBLEMAS
CON CUATRO ETAPAS DISTINTAS

19
BUCLE DE RESOLUCIÓN DE PROBLEMAS

 STATUS QUO
 DEFINICIÓN DE PROBLEMAS
 DESARROLLO TÉCNICO
 INTEGRACIÓN DE SOLUCIONES

20
 STATUS QUO
REPRESENTA EL ESTADO ACTUAL DE
LOS SUCESOS

SE DEFINEN PROBLEMAS, IDENTIFICA

EL PROBLEMA ESPECIFICO A
RESOLVERSE

21
 DESARROLLO TÉCNICO

RESUELVE EL PROBLEMA A TRAVÉS DE

LA APLICACIÓN DE ALGUNA
TECNOLOGÍA.

22
 INTEGRACIÓN DE SOLUCIONES
OFRECE LOS RESULTADOS POR
EJEMPLO:
 DOCUMENTOS
 PROGRAMAS
 DATOS
 NUEVA FUNCIÓN COMERCIAL
A LOS QUE SOLICITEN LA
SOLUCIÓN EN PRIMER LUGAR
23
 EL BUCLE DE RESOLUCIÓN DE PROBLEMAS
SE APLICA AL TRABAJO DE INGENIERÍA DE
SOFTWARE, EN DIFERENTES NIVELES DE
RESOLUCIÓN

 A MACRO NIVEL: PARA LA APLICACIÓN

ENTERA
 A NIVEL MEDIO: CUANDO SE CONSIDERAN
COMPONENTES DEL PROGRAMA
E INCLUSO EN LA LÍNEA DELNIVEL CÓDIGO

24
POR CONSIGUIENTE SE PUEDE UTILIZAR
UNA REPRESENTACIÓN FRACTAL

PARA DAR UNA VISIÓN IDEALIZADA DEL

PROCESO

25
MODELOS DEL PROCESO DEL SOFTWARE

PARA RESOLVER PROBLEMAS UN INGENIERO

DE SOFTWARE INCORPORA UNA ESTRATEGÍA
DE DESARROLLO QUE ACOMPAÑE AL
PROCESO, MÉTODOS, A LA CAPA DE
HERRAMIENTAS, Y A LAS FACES GENERÍCAS

ESTA ESTRATEGÍA SE DENÓMINA PARADIGMA

DE LA INGENIERÍA DEL SOFTWARE

26
 MODELO LINEAL SECUENCIAL

LLAMADO TAMBIÉN CICLO DE VIDA CLASICO

O MODELO EN CASCADA, FUE PROPUESTO
POR ROYCE EN EL 1972 ESTE PREVEÍA
BUCLES DE REALIMENTACIÓN, PERO FUE
APLICADO COMO SI FUERA ESTRICTAMENTE
LINEAL.
ESTE MODELO ACOMPAÑA A LAS
SIGUIENTES ACTIVIDADES:

27
 MODELO LINEAL SECUENCIAL

ANÁLISIS

DISEÑO

CÓDIGO

PRUEBA

28
ANÁLISIS DE LOS REQUISITOS DEL SOFTWARE

ES EL PROCESO DE REUNIÓN DE REQUISITOS DEL

SISTEMA
PARA COMPRENDER LA NATURALEZA DE LOS
PROGRAMAS A CONSTRUIRSE EL INGENIERO DE
SOFTWARE DEBE COMPRENDER:

 EL DOMINIO DEL PROBLEMA

 EL DOMINIO DE LA INFORMACIÓN
 LA FUNCIÓN REQUERIDA
 COMPORTAMIENTO, RENDIMIENTO E
INTERCONEXIÓN
29
 DISEÑO
PROCESO DE MUCHOS PASOS, SE CENTRA
EN 4 ATRIBUTOS:

 ESTRUCTURA DE DATOS
 ARQUITECTURA DEL SOFTWARE
 REPRESENTACIÓN DE INTERFAZ
 DETALLE PROCEDIMENTAL (ALGORITMO)

30
EL PROCESO DE DISEÑO TRADUCE LOS
REQUISITOS EN UNA REPRESENTACIÓN DEL
SOFTWARE, QUE SE PUEDE EVALUAR POR
CALIDAD ANTES DE LA GENERACIÓN DE
CÓDIGO

EL DISEÑO SE DOCUMENTA Y SE HACE

PARTE DE LA CONFIGURACIÓN DEL
SOFTWARE

31
 GENERACIÓN DE CÓDIGO

EL DISEÑO SE DEBE TRADUCIR EN UNA

REPRESENTACIÓN LEGIBLE POR LA
MÁQUINA

ESTA TAREA LA LLEVA EL PASO DE

GERACIÓN DE CÓDIGO

32
 PRUEBAS

SON LAS PRUEBAS DEL PROGRAMA

 EN LOS PROCESOS LÓGICOS INTERNOS DEL

SOFTWARE DE TODAS LAS SENTENCIAS
 EN LOS PROCESOS EXTERNOS FUNCIONALES
ASEGURA QUE LA ENTRADA DEFINIDA
PRODUZCA RESULTADOS REALES ACORDE
CON LOS REQUISITOS

33
 MANTENIMIENTO

CAMBIOS DE ERROR POR ADAPTACIÓN DE

CAMBIOS DEL ENTORNO DEL SOFTWARE:
SISTEMAS OPERATIVOS, DISPOSITIVOS,
PERIFERICOS NUEVOS
O EL CLIENTE REQUIERE MEJORAS
FUNCIONALES O DE RENDIMIENTO
CAMBIOS EN LAS REGLAS DE LA CIA. O DEL
GOBIERNO
EL MANTENIMIENTO VUELVE A APLICAR CADA
UNA DE LAS FASES PRECEDENTES A UN
PROGRAMA EXISTENTE
34
 CONSTRUCCIÓN DE PROTOTIPO
ES UN PROCESO QUE FACILITA AL DESARROLLADOR
LA CREACIÓN DE UN MODELO DE SOFTWARE A
CONSTRUIR
ESTE MODELO ES LA MEJOR OPCIÓN CUANDO:

 EL CLIENTE NO IDENTIFICA LOS REQUISITOS

DETALLADOS DE ENTRADA Y SALIDA
 EL DESARROLLADOR NO ESTA SEGURO DE LA
EFICIENCIA DEL ALGORITMO, DE LA CAPACIDAD DE
ADAPTACIÓN DE UN S. O. o DE LA INTERACCIÓN
HOMBRE/MÁQUINA

35
 SECUENCIA DE SUCESOS DE
CONSTRUCCIÓN DE PROTOTIPOS

RECOLECCIÓN Y REFINAMIENTO DE
REQUISITOS
DISEÑO RAPIDO
CONSTRUCCIÓN DE PROTOTIPO
EVALAUCIÓN DEL PROTOTIPO POR EL
CLIENTE
REFINAMIENTO DEL PROTOTIPO
PRODUCTO DE INGENIERÍA
36
 INICIO

RECOLECCIÓN DISEÑO
DE REQUISITOS RÁPIDO
FIN

CONSTRUCCIÓN
INGENIERÍA

PROTOTIPO
PRODUCTO

REFINAMIENTO EVALUACIÓN
PROTOTIPO CLIENTE

37
 MODELO DE DESARROLLO RAPIDO

 ES UN MODELO DE PROCESO DEL

DESARROLLO RAPIDO DEL SOFTWARE
LINEAL SECUENCIAL, Que. PONE
ENFASIS EN EL CICLO DE DESARROLLO
EXTREMADAMENTE CORTO
 ES UNA ADAPTACIÓN A ALTA
VELOCIDAD DEL MODELO LINEAL
SECUENCIAL

38
SI SE COMPRENDE BIEN LOS
REQUISITOS Y SE LIMITA EL
AMBITO
DEL PROYECTO EL DRA CREA UN
“SISTEMA COMPLETAMENTE
FUNCIONAL” EN PERIODOS
CORTOS

39
 FASES DEL MODELO DRA

MODELADO DE GESTION
MODELADO DE DATOS
MODELADO DEL PROCESO
GENERACIÓN DE APLICACIONES
PRUEBAS Y ENTREGA

40
 EQUIPO Nº 2

MODELADO
DE GESTIÓN

EQUIPO Nº 1

MODELADO
DE DATOS
MODELADO
DE GESTIÓN

MODELADO
DE PROCESOS
MODELADO
DE DATOS

GENERACIÓN DE
APLICACIONES
MODELADO
DE PROCESOS

PRUEBAS
Y VOLUMEN
GENERACIÓN DE
APLICACIONES

PRUEBAS
Y VOLUMEN

DE 60 A 90 DÍAS

41
 MODELADO DE GESTION
MODELA EL FLUJO DE INFORMACIÓN QUE
SE GESTIONA ENTRE LAS FUNCIONES Y
RESPONDE A LAS SIGUIENTES PREGUNTAS
¿Qué información conduce el proceso de
gestión?
¿ Qué información se genera?
¿Quién genera?
¿A dónde va la información?
¿Quién la procesa?

42
 MODELADO DE DATOS

EL FLUJO DE INFORMACIÓN DEFINIDO EN

LA FASE DE GESTIÓN, SE REFINA COMO UN
CONJUNTO DE OBJETOS DE DATOS PARA
APOYAR A LA EMPRESA
SE DEFINEN LAS CARACTERISITCAS
(ATRIBUTOS) DE CADA UNO DE LOS
OBJETOS Y SUS RELACIONES

43
 MODELADO DEL PROCESO

LOS OBJETOS DE DATOS DEFINIDOS EN LA

ANTERIOR FASE, SE TRANSFORMAN PARA
LOGRAR EL FLUJO DE INFORMACIÓN
NECESARIO PARA IMPLEMETAR UNA
FUNCIÓN DE GESTIÓN
LAS DESCRIPCIONES DEL PROCESO SE
CREAN PARA: AÑADIR, MODIFICAR,
SUPRIMIR, O RECUPERAR UN OBJETO DE
DATO.

44
GENERACIÓN DE APLICACIONES

EL DRA ASUME LA UTILIZACIÓN DE T4G Y

TRABAJA PARA VOLVER A UTILIZAR
COMPONENTES DE PROGRAMAS YA
EXISTENTES O CREAR LOS QUE NO EXISTEN
UTILIZA HERRAMIENTAS AUTOMATICAS
PARA FACILITAR LA CONSTRUCCIÓN DEL
SOFTWARE.

45
 PRUEBAS Y ENTREGA

SE DEBEN PROBAR LOS COMPONENTES

NUEVOS ESTO REDUCE EL TIEMPO DE
PRUEBA Y LAS INTERFACES.
LAS LIMITACIONES DE TIEMPO HACE QUE
SE “UTILICE ESCALAS” DONDE CADA UNA
DE LAS FUNCIONES PUEDEN SER
AFRONTADAS POR UN EQUIPO DIFERENTE
PARA LUEGO SER INTEGRADAS.

46
 MODELOS EVOLUTIVOS

LOS MODELOS EVOLUTIVOS SON

ITERATIVOS, SE CARACTERIZAN POR
LA FORMA EN Que. PERMITEN A LOS
INGENIEROS DE SOFTWARE TENER
VERSIONES CADA VEZ MAS
COMPLETAS DEL SOFTWARE
47
 RAZONES PARA IMPLEMETAR

 EVOLUCION DEL SOFTWARE CON EL

TIEMPO
 FECHAS TOPES DE ENTREGA DEL
PRODUCTO
 LOS REQUERIMIENTOS DE GESTIÓN Y DE
PRODUCTOS A MENUDO CAMBIAN
 PRODUCTO ADAPTABLE CON LOS
CAMBIOS

48
 MODELO INCREMENTAL

COMBINA LOS ELEMENTOS DEL MODELO

LINEAL SECUENCIAL APLICADOS
REPETITIVAMENTE CON EL ENFOQUE
INTERACTIVO DE CONSTRUCCIÓN DE
PROTOTIPOS

49
INCREMENTO 1 ANALISIS DISEÑO CÓDIGO PRUEBA

INCREMENTO 2 ANALISIS DIDEÑO CÓDIGO PRUEBA

INCREMENTO 3 ANALISIS DISEÑO CÓDIGO PRUEBA

INCREMENTO 4
ANALISIS DISEÑO CÓDIGO PRUEBA

50
 MODELO EN ESPITAL

ES UN MODELO DE PROCESO DE SOFTWARE

EVOLUTIVO CON EL ENFOQUE
“INTERACTIVO” DE CONSTRUCCIÓN DE
PROTOTIPOS, CON ASPECTOS
CONTROLADOS Y SISTEMÁTICOS DEL
MODELO LÍNEAL SECUENCIAL.

51
 PLANIFICACIÓN ANÁLISIS DE RIESGOS

COMUNICACIÓN
CON EL CLIENTE INGENIERÍA

EVALUACIÓN CONSTRUCCIÓN Y ADAPTACIÓN

DEL CLIENTE

52
 TAREAS POR REGIONES O ÁREAS

COMUNICACIÓN CON EL CLIENTE :

ESTABLECER COMUNICACIÓN ENTRE EL
DESARROLLADOR Y EL CLIENTE
PLANIFICACIÓN : TAREAS REQUERIDAS
PARA DEFINIR RECURSOS, TIEMPO Y
ASPECTOS RELACIONADOS CON EL
PROYECTO

53
ANALISIS DE RIESGOS: EVALUACIÓN DE
RIESGOS TÉCNICOS Y DE GESTIÓN
INGENIERIA: CONSTRUCCIÓN DE UNA MÁS
REPRESENTACIONES DE LA APLICACIÓN
CONSTRUCCIÓN Y ADAPTACIÓN: TAREAS
PARA CONSTRUIR, PROBAR, INSTALAR Y
PROPORCIONAR SOPORTE AL USUARIO
(DOCUMENTACIÓN Y PRACTICA).
EVALUACIÓN DEL CLIENTE: VALORACIÓN DE
LOS RESULTADOS DE LA INGENÍERIA

54
EL MODELO EN ESPIRAL ES UN ENFOQUE
REALISTA DEL DESARROLLO DE SISTEMAS Y
DE PROCESO.
EL DESARROLLADOR Y EL CLIENTE
COMPRENDEN Y REACCIONAN MEJOR ANTE
RIESGOS EN CADA UNO DE LOS NIVELES
EVOLUTIVOS

55
 MODELO DE DESARROLLO DE
COMPONENTES

LAS TECNOLOGÍAS ORIENTADA A OBJETOS

PROPORCIONANA EL MARCO DE TRABAJO
TÉCNICO PARA UN MODELO DE PROCESO
BASADO EN COMPONENTES PARA LA
INGENIERÍA DE SOFTWARE

EL PARADIGMA O.O. ENFATIZA LA

CREACIÓN DE CLASES QUE ENCAPSULAN:
DATOS Y ALGORITMOS

56
LAS CLASES DISEÑADAS E IMPLEMENTADAS,
ADECUADAMENTE SON REUTILIZABLES POR
LAS DIFERENTES APLICACIONES Y
ARQUITECTURAS DE SISTEMAS.
ESTE MODELO INCORPORA MUCHAS DE LAS
CARACTERÍSTICAS DEL MODELO EN ESPIRAL
ES EVOLUTIVO POR NATURALEZA Y TIENE
UN ENFOQUE INTERACTIVO PARA LA
CREACIÓN DE SOFTWARE.

57
TECNICAS DE LA 4ta. GENERACIÓN
EL TERMINO T4G ABARCA UN AMPLIO
ESPECTRO DE HERRAMIENTAS DE
SOFTWARE QUE TIENEN ALGO EN COMUN
TODAS FACILITAN AL DESARROLLADOR LA
ESPECIFICACIÓN DE ALGUNAS
CARACTERÍSTICAS DEL SOFTWARE DE ALTO
NIVEL
LA HERRAMIENTA GENERA
AUTOMÁTICAMENTE EL CÓDIGO FUENTE

58
RECOLECCIÓN DE
REQUISITOS

ESTRATEGIA
DE DISEÑO

IMPLEMENTACIÓN
EN L4G

PRUEBA

59
 DESVENTAJA

LAS HERRAMIENTAS DE LA T4G NO SON

MÁS FÁCILES DE UTILIZAR QUE LOS
LENGUAJES DE PROGRAMACIÓN.
EL CÓDIGO PRODUCTO ES “INEFICIENTE”

LOS L4G NO PROCEDIMENTALES SE

EMPLEAN PARA PEQUEÑAS APLICACIONES

60
EN ESTE MODELO EL DESARROLLADOR SE
CENTRA EN LA REPRESENTACIÓN DE
RESULTADOS

LAS T4G SE HAN CONVERTIDO EN PARTE

IMPORTANTE DEL DESARROLLO DEL SOFTWARE
CUANDO SE COMBINAN CON ENFOQUES DE
ENSAMBLAJE DE COMPONENTES.

61
 TÉCNOLOGÍA DE PROCESOS
LOS MODELOS TRATADOS SE DEBEN
ADAPTAR PARA UTILIZARSE POR EL EQUIPO
DEL PROYECTO, PARA ESTO EXISTEN
HERRAMIENTAS DE TECNOLOGÍA DE
PROCESOS QUE AYUDAN A LAS
ORGANIZACIONES DE SOFTWARE A
ANALIZAR LOS PROCESOS ACTUALES,
ORGANIZAR TAREAS DE TRABAJO.
CONTROLAR Y SUPERVISAR EL PROGRESO
62
 RESUMEN
PRODUCTO Y PROCESO NO SON UNA
DICOTOMÍA MÁS BIEN SON UNA DUALIDAD
LA INGENIERÍA DE SOFTWARE ES UNA
DISCIPLINA QUE INTEGRA: PROCESO,
MÉTODOS Y HERRAMIENTAS PARA EL
DESARROLLO DEL SOFTWARE
SE HAN PROPUESTO VARIAS PARADIGMAS
DIFERENTES CADA UNO EXIBIENDO
VENTAJAS E INCOVENIENTES,
63
PERO TODOS TIENEN UNA SERIE DE FASES
GENERICAS EN COMÚN

SE CONSIDERAN LOS PRINCIPIOS,

CONCEPTOS Y MÉTODOS QUE PERMITEN
LLEVAR A CABO EL PROCESO QUE SE LLAMA
INGENIERÍA DE SOFTEWARE.

64