FUNDAMENTOS DE INGENIERIA DE SOFTWARE

UNIDAD 1. FUNDAMENTOS DE INGENIERIA DE SOFTWARE

PROFESORA: ING.MARIA NANCY GARCIA CASTRO

INTEGRANTES DEL EQUIPO:

GERARDO ALEXIS ARCE NAVARRETE 10320987

JOSE LUIS TERAN MANZANAREZ 10320953

ISAAC NOE MENDOZA LUNA 10320930

SEMESTRE: 6° ENERO-JUNIO AULA: 709

1

INDICE

1.1 CONCEPTOS BASICOS………………………………………………...……...…4

1.2 EL PAPEL EVOLUTIVO DEL SOFTWARE…………………...........................8

1.3 ETAPAS DEL DESARROLLO SOFTWARE…………………...........................11

1.4 CLASIFICACION DE LA TECNOLOGIA EN EL DESARROLLO DEL SOFTWARE (TECNOLOGIA ESTRUCTURADA Y ORIENTADA A OBJETOS)……………………………………………………………………..….16

1.5 DEFINICION E HISTORIA DE LAS HERRAMIENTAS CASE………....…23

1.6 CLASIFICACION DE LAS HERRMIENTAS CASE…………………….….28

2

INTRODUCCION.

EN ESTA UNIDAD VEREMOS LOS FUNDAMENTOS DE LA INGENIERIA DE SOFTWARE, DESDE SUS PRIMEROS PASOS HASTA NUESTRA ACTUALIDAD.

ESTUDIAREMOS LAS CAUSAS POR LAS CUALES SURGIO LA NECESIDAD DE HACER DE LA INGENIERIA DE SOFTWARE UNA RAMA IMPORTANTE EN LA CREACION EN LA PRODUCCION DE SOFTWARE.

TOMANDO EN CUENTA VARIAS PRESPECTIVAS DE VARIOS AUTORES CON CLONCLUIMOS EN QUE LA INGENIERIA DE SOFTWARE ES UNA DISCIPLINA QUE SE ENCARGA DE LA PRODUCCION DE SOFTWARE Y QUE SE ADECUA A LO QUE EL CLIENTE NECESITA TOMANDO EN CUENTA LOS RECURSOS FINANCIEROS, EL TIEMPO CON EL CUAL CUENTA EL PROYECTO.

ANTES LOS PROYECTOS NO CONTABAN CON LA DOCUMENTACION QUE LO RESPALDARA, EN LA EPOCA CONTEMPORANEA TODO PROYECTO DE INGENIERIA DE SOFTWARE DEBE ESTAR RESPALDADO POR LA INFORMACION QUE PRECEDE SU FORMACION.

3

UNIDAD 1 FUNDAMENTOS DE INGENIERÍA DE SOFTWARE.

1. CONCEPTOS BASICOS

EL SOFTWARE DE COMPUTADORA ES EL PRODUCTO QUE DISEÑAN Y CONSTRUYEN LOS INGENIEROS DE SOFTWARE.

CARACTERÍSTICAS DEL SOFTWARE:

EL SOFTWARE SE DESARROLLA NO SE FABRICA EL SOFTWARE NO SE ESTROPEA, SE DETERIORA

LA INGENIERÍA DE SOFTWARE ES EL ESTABLECIMIENTO Y USO DE LOS PRINCIPIOS ROBUSTOS DE LA INGENIERÍA A FIN DE OBTENER ECONÓMICAMENTE SOFTWARE QUE SEA FIABLE Y QUE FUNCIONE EFICIENTEMENTE SOBRE LAS MAQUINAS REALES.LA INGENIERÍA DE SOFTWARE ES LA APLICACIÓN DE UN ENFOQUE SISTEMÁTICO, DISCIPLINADO Y CUANTIFICABLE HACIA EL DESARROLLO, OPERACIÓN Y MANTENIMIENTO DEL SOFTWARE; ES DECIR, LA APLICACIÓN DE LA INGENIERÍA AL SOFTWARE.LA INGENIERÍA DE SOFTWARE ES UNA DISCIPLINA QUE INTEGRA, MÉTODOS Y HERRAMIENTAS PARA EL DESARROLLO DEL SOFTWARE DE COMPUTADORA. SE HAN PROPUESTO VARIOS MODELOS DE PROCESOS PARA LA INGENIERÍA DE SOFTWARE DE DIFERENTES, CADA UNO EXHIBIENDO VENTAJAS E INCONVENIENTES, PERO TODOS TIENEN UNA SERIE DE FACES GENÉRICAS EN COMÚN.

APLICACIONES DEL SOFTWARE: SOFTWARE DE GESTIÓN SOFTWARE DE SISTEMAS SOFTWARE DE INGENIERÍA Y CIENTÍFICO SOFTWARE EMPOTRADO SOFTWARE DE TIEMPO REAL SOFTWARE DE COMPUTADORAS PERSONALES SOFTWARE BASADO EN WEB SOFTWARE DE INTELIGENCIA ARTIFICIAL

4

LA INGENIERÍA DEL SOFTWARE] ES EL ESTABLECIMIENTO Y USO DE PRINCIPIOS ROBUSTOS DE LA INGENIERÍA A FIN DE OBTENER ECONÓMICAMENTE SOFTWARE QUE SEA FIABLE Y QUE FUNCIONE EFICIENTEMENTE SOBRE MÁQUINAS REALES.

EL FUNDAMENTO DE LA INGENIERÍA DEL SOFTWARE ES LA CAPA DE PROCESO. EL PROCESO DE LA INGENIERÍA DEL SOFTWARE ES LA UNIÓN QUE MANTIENE JUNTAS LAS CAPAS DE TECNOLOGÍA Y QUE PERMITE UN DESARROLLO RACIONAL Y OPORTUNO DE LA INGENIERÍA DEL SOFTWARE. EL PROCESO DEFINE UN MARCO DE TRABAJO PARA UN CONJUNTO DE ÚREAS CLAVE DE PROCESO QUE SE DEBEN ESTABLECER PARA LA ENTREGA EFECTIVA DE LA TECNOLOGÍA DE LA INGENIERÍA DEL SOFTWARE. LAS ÁREAS CLAVES DEL PROCESO FORMAN LA BASE DEL CONTROL DE GESTIÓN DE PROYECTOS DEL SOFTWARE Y ESTABLECEN EL CONTEXTO EN EL QUE SE APLICAN LOS MÉTODOS TÉCNICOS, SE OBTIENEN PRODUCTOS DEL TRABAJO (MODELOS, DOCUMENTOS, DATOS, INFORMES, FORMULARIOS, ETC.), SE ESTABLECEN HITOS, SE ASEGURA LA CALIDAD Y EL CAMBIO SE GESTIONA ADECUADAMENTE.

LOS MÉTODOS DE LA INGENIERÍA DEL SOFTWARE INDICAN «CÓMO» CONSTRUIR TÉCNICAMENTE EL SOFTWARE. LOS MÉTODOS ABARCAN UNA GRAN GAMA DE TAREAS QUE INCLUYEN ANÁLISIS DE REQUISITOS, DISEÑO, CONSTRUCCIÓN DE PROGRAMAS, PRUEBAS Y MANTENIMIENTO. LOS MÉTODOS DE LA INGENIERÍA DEL SOFTWARE DEPENDEN DE UN CONJUNTO DE PRINCIPIOS BÁSICOS QUE GOBIERNAN CADA ÁREA DE LA TECNOLOGÍA E INCLUYEN ACTIVIDADES DE MODELADO Y OTRAS TÉCNICAS DESCRIPTIVAS.

BIBLIOGRAFÍALIBRO: FUNDAMENTOS DE INGENIERÍA DE SOFTWARE UN ENFOQUE PRACTICO AUTOR: ROGER S. PRESSMANEDITORIAL: MCGRAW-HILLQUINTA EDICIÓN

5

1.1 CONCEPTOS BÁSICOS

DEFINICIÓN DE INGENIERÍA DE SOFTWARE.ES UNA DISCIPLINA QUE COMPRENDE TODOS LOS ASPECTOS DE LA PRODUCCIÓN DEL SOFTWARE DESDE LAS ETAPAS INICIALES DE LA ESPECIFICACIÓN DEL SISTEMA, HASTA EL MANTENIMIENTO DE ESTE DESPUÉS DE QUE SE UTILIZA.EL SOFTWARE SE DESARROLLA, NO MANUFACTURA; NO SE DESGASTA PERO SE DETERIORA.LA INGENIERÍA DE SOFTWARE INCLUYE A LAS PERSONAS, PROCESOS, PROYECTOS Y PRODUCTOS.PERSONAS:ES LA GENTE QUE COLABORA EN LA ELABORACIÓN DE PROYECTOS EN LA ING. DE SOFTWARE, LOS EQUIPOS TRABAJAN MEJOR CUANDO TIENEN CONOCIMIENTO DE LO QUE SE SUPONE QUE DEBEN HACER, Y CUANDO LOS MIEMBROS TIENEN PAPELES ESPECÍFICOS.OTRO ELEMENTO DEL FACTOR "PERSONAS" SE REFIERE A LOS INTERESADOS EN EL PROYECTO: PERSONAS QUE GANAN O PIERDEN ALGO CON SU RESULTADO. ESTAS INCLUYEN EL CLIENTE, EL USUARIO FINAL Y LOS PATROCINADORES FINANCIEROS.ESTAS PERSONAS PUEDEN TENER UN PROFUNDO EFECTO EN EL PROYECTO.PROCESO:UN PROCESO DE SOFTWARE PROPORCIONA EL MARCO DE TRABAJO DESDE EL CUAL SE PUEDE ESTABLECER UN PLAN DETALLADO PARA EL DESARROLLO DEL SOFTWARE. UN PEQUEÑO NÚMERO DE ACTIVIDADES DEL MARCO DE TRABAJO ES APLICABLE A TODOS LOS PROYECTOS DE SOFTWARE, SIN IMPORTAR SU TAMAÑO Y COMPLEJIDAD.ALGUNOS CONJUNTOS DE TAREAS DIFERENTES PERMITEN QUE LAS ACTUALIZACIONES DEL MARCO DE TRABAJO SE ADAPTEN A LAS CARACTERÍSTICAS DEL PROYECTO DE SOFTWARE, ASÍ COMO LOS REQUISITOS DEL EQUIPO DEL PROYECTO. POR ÚLTIMO, LAS ACTIVIDADES PROTECTORAS, COMO EL CONTROL DE LA CALIDAD, GESTIÓN DE CONFIGURACIÓN Y MEDICIÓN, CUBREN EL MODELO DEL PROCESO.

6

EL PROCESO DE "CASCADA COMIENZA CON LA ESPECIFICACIÓN DE LOS REQUERIMIENTOS PARA LA APLICACIÓN. DESPUÉS PROCEDE A LA ETAPA DE DISEÑO, IMPLEMENTACIÓN Y PRUEBA.PROYECTO:LOS PROYECTOS DE SOFTWARE SE REALIZAN DE MANERA PLANIFICADA Y CONTROLADA POR UNA RAZÓN PRINCIPAL: ES LA ÚNICA FORMA CONOCIDA DE GESTIONAR LA COMPLEJIDAD."UN PROYECTO ES COMO UN VIAJE POR CARRETERA. ALGUNOS PROYECTOS SON SIMPLES Y RUTINARIOS, COMO CONDUCIR HACIA LA TIENDA A PLENA LUZ DEL DÍA. PERO LA MAYORÍA DE LOS PROYECTOS QUE VALE LA PENA REALIZAR SON MÁS PARECIDOS A CONDUCIR UN CAMIÓN EN LA CARRETERA, EN LA MONTAÑA DE NOCHE".

PRODUCTO:ANTES DE PLANEAR UN PROYECTO SE DEBERÍAN ESTABLECER LOS OBJETIVOS Y EL ÁMBITO DEL PRODUCTO, CONSIDERAR SOLUCIONES ALTERNATIVAS E IDENTIFICAR LAS RESTRICCIONES TÉCNICAS Y DE GESTIÓN. SIN ESTA INFORMACIÓN ES IMPOSIBLE DEFINIR ESTIMACIONES RAZONABLES DEL COSTO CON UNA VALORACIÓN EFECTIVA DEL RIESGO, UNA DIVISIÓN REALISTA DE LAS TAREAS DEL PROYECTO O UN CALENDARIO DE PROYECTO MANEJABLE QUE OFREZCA UNA INDICACIÓN FIABLE DEL PROGRESO.EL DESARROLLADOR DEL SOFTWARE Y EL CLIENTE SE DEBEN REUNIR PARA DEFINIR LOS OBJETIVOS Y EL ÁMBITO DEL PRODUCTO, LOS OBJETIVOS IDENTIFICAN LAS METAS GLOBALES DEL PRODUCTO SIN CONSIDERAR COMO SE LOGRARAN. EL ÁMBITO IDENTIFICARAN LOS DATOS PRIMARIOS, LOS INTENTOS POR ENLAZAR TALES CARACTERÍSTICAS EN FORMA CUANTITATIVA. UNA VEZ ENTENDIDOS LOS OBJETIVOS Y EL ÁMBITO DEL PRODUCTO SE CONSIDERAN SOLUCIONES ALTERNATIVAS, LAS ALTERNATIVAS POSIBILITAN QUE LOS GESTORES Y PRACTICANTES SE RELACIONEN UN MEJOR ENFOQUE, CUMPLAN LAS RESTRICCIONES QUE IMPONEN LAS FECHAS LÍMITES DE ENTREGA, RESTRICCIONES PRESUPUESTARIAS, DISPONIBILIDAD DEL PERSONAL, INTERFACES TÉCNICAS, ETC.CALIDAD:

7

RESALTA TRES ACTIVIDADES PARA ASEGURAR LA CALIDAD: INSPECCIÓN, DEMOSTRACIÓN DE FUNCIONAMIENTO CORRECTO Y PRUEBAS.LA INSPECCIÓN ES UN PROCESO ORIENTADO AL TRABAJO EN EQUIPO PARA ASEGURAR LA CALIDAD Y SE APLICA EN TODAS LAS ETAPAS DEL PROCESO. UNA DEMOSTRACIÓN DE FUNCIONAMIENTO CORRECTO ES UNA TÉCNICA MATEMÁTICA O LÓGICA USADA PARA CONVENCERNOS DE QUE UN PROGRAMA HACE LO QUE DEBE.ESTAS DEMOSTRACIONES SON MÉTODOS FORMALES.LOS PROGRAMAS NO SE EJECUTAN DURANTE EL PROCESO DE DEMOSTRACIÓN SOLO SE INSPECCIONA SU CÓDIGO FUENTE, EN LAS PRUEBAS SE EJECUTAN LOS PROGRAMAS.

1.2 EL PAPEL EVOLUTIVO DEL SOFTWARE

HOY EN DÍA EL SOFTWARE TIENE UN DOBLE PAPEL. ES UN PRODUCTO Y, AL MISMO TIEMPO, EL VEHÍCULO PARA ENTREGARLO. COMO PRODUCTO, HACE ENTREGA DE LA POTENCIA INFORMÁTICA QUE INCORPORA EL HARDWARE INFORMÁTICO O, MÁS AMPLIAMENTE, UNA RED DE COMPUTADORAS QUE ES ACCESIBLE POR HARDWARE LOCAL. SI RESIDE DENTRO DE UN TELÉFONO CELULAR U OPERA DENTRO DE UNA COMPUTADORA CENTRAL, EL SOFTWARE ES UN TRANSFORMADOR DE INFORMACIÓN, PRODUCIENDO, GESTIONANDO, ADQUIRIENDO, MODIFICANDO, MOSTRANDO O TRANSMITIENDO INFORMACIÓN QUE PUEDE SER TAN SIMPLE COMO UN SOLO BIT, O TAN COMPLEJO COMO UNA PRESENTACIÓN EN MULTIMEDIA. COMO VEHÍCULO UTILIZADO PARA HACER ENTREGA DEL PRODUCTO, EL SOFTWARE ACTÚA COMO LA BASE DE CONTROL DE LA COMPUTADORA (SISTEMAS OPERATIVOS), LA COMUNICACIÓN DE INFORMACIÓN (REDES) Y LA CREACIÓN Y CONTROL DE OTROS PROGRAMAS (HERRAMIENTAS DE SOFTWARE Y ENTORNOS).

EL PAPEL DEL SOFTWARE INFORMÁTICO HA SUFRIDO UN CAMBIO SIGNIFICATIVO DURANTE UN PERIODO DE TIEMPO SUPERIOR A 50 AÑOS. ENORMES MEJORAS EN RENDIMIENTO DEL HARDWARE, PROFUNDOS CAMBIOS DE ARQUITECTURAS INFORMÁTICAS, GRANDES AUMENTOS DE MEMORIA Y

8

CAPACIDAD DE ALMACENAMIENTO Y UNA GRAN VARIEDAD DE OPCIONES DE ENTRADA Y SALIDA HAN CONDUCIDO A SISTEMAS MÁS SOFISTICADOS Y MÁS COMPLEJOS BASADOS EN COMPUTADORA. LA SOFISTICACIÓN Y LA COMPLEJIDAD PUEDEN PRODUCIR RESULTADOS DESLUMBRANTES CUANDO UN SISTEMA TIENE ÉXITO, PERO TAMBIÉN PUEDEN SUPONER GRANDES PROBLEMAS PARA AQUELLOS QUE DEBEN CONSTRUIR SISTEMAS COMPLEJOS.

LIBROS POPULARES PUBLICADOS DURANTE LOS AÑOS 70 Y 80 PROPORCIONAN UNA VISIÓN HISTÓRICA ÚTIL DENTRO DE LA PERCEPCIÓN CAMBIANTE DE LAS COMPUTADORAS Y DEL SOFTWARE, Y DE SU IMPACTO EN NUESTRA CULTURA. OSBORNE [OSB79] HABLABA DE UNA «NUEVA REVOLUCIÓN INDUSTRIAL. TOFFLER [TOF80] LLAMÓ A LA LLEGADA DE COMPONENTES MICRO ELECTRÓNICOS LA «TERCERA OLA DEL CAMBIO» EN LA HISTORIA DE LA HUMANIDAD, Y NAISBITT "A1821 PREDIJO LA TRANSFORMACIÓN DE LA SOCIEDAD INDUSTRIAL A UNA «SOCIEDAD DE INFORMACIÓN ». FEIGENBAUM Y MCCORDUCK [FE1831 SUGIRIERON QUE LA INFORMACIÓN Y EL CONOCIMIENTO (CONTROLADOS POR COMPUTADORA) SERÍAN EL FOCO DE PODER DEL SIGLO VEINTIUNO, Y STO11 [STO891 ARGUMENTÓ QUE LA «COMUNIDAD ELECTRÓNICA » CREADA MEDIANTE REDES Y SOFTWARE ES LA CLAVE PARA EL INTERCAMBIO DE CONOCIMIENTO ALREDEDOR DEL MUNDO.

AL COMIENZO DE LOS AÑOS 90, TOFFLER [TOF90] DESCRIBIÓ UN «CAMBIO DE PODER» EN EL QUE LAS VIEJAS ESTRUCTURAS DE PODER (GUBERNAMENTALES, EDUCATIVAS, INDUSTRIALES, ECONÓMICAS Y MILITARES) SE DESINTEGRARÍAN A MEDIDA QUE LAS COMPUTADORAS Y EL SOFTWARE NOS LLEVARAN LA DEMOCRATIZACIÓN DEL CONOCIMIENTO». A YOURDON [YOU92] LE PREOCUPABA QUE LAS COMPAÑÍAS EN ESTADOS UNIDOS PUDIERAN PERDER SU COMPETITIVIDAD EN EMPRESAS RELATIVAS AL SOFTWARE Y PREDIJO «EL DECLIVE Y LA CAÍDA DEL PROGRAMADOR AMERICANO». HAMMER Y CHAMPY [HAM93] ARGUMENTARON QUE LAS TECNOLOGÍAS DE INFORMACIÓN IBAN A DESEMPEÑAR EL PAPEL PRINCIPAL EN LA REINGENIERÍA DE LA COMPAÑÍA». A MEDIADOS DE LOS AÑOS 90, LA PERSISTENCIA DE LAS COMPUTADORAS Y DEL SOFTWARE

9

GENERÓ UNA ERUPCIÓN DE LIBROS POR «NEO LUDDITES» (POR EJEMPLO: RESISTING TE VIRTUAL LIFE, EDITADO POR JAMES BROOK Y IAN BOAL, Y THE FUTURE DOES NOT COMPUTE DE STEPHEN TALBOT). ESTOS AUTORES CRITICAN ENORMEMENTE LA COMPUTADORA, HACIENDO ÉNFASIS EN PREOCUPACIONES LEGÍTIMAS PERO IGNORANDO LOS PROFUNDOS BENEFICIOS QUE SE HAN LLEVADO A CABO [LEV95].AL FINAL DE LOS AÑOS 90, YOURDON [YOU96] VOLVIÓ A EVALUAR LAS PERSPECTIVAS DEL SOFTWARE PROFESIONAL Y SUGIRIÓ LA «RESURRECCIÓN Y ELEVACIÓN» DEL PROGRAMADOR AMERICANO. A MEDIDA QUE INTERNET CRECIÓ EN IMPORTANCIA, SU CAMBIO DE PENSAMIENTO DEMOSTRÓ SER CORRECTO. AL FINAL DEL SIGLO VEINTE, EL ENFOQUE CAMBIÓ UNA VEZ MÁS. AQUÍ TUVO LUGAR EL IMPACTO DE LA «BOMBA DE RELOJERÍA» Y2K (POR EJEMPLO: [YOU98B], [DEJ98], [KAR99]). AUNQUE MUCHOS VIERON LAS PREDICCIONES DE LOS CRÍTICOS DEL Y2K COMO REACCIONES, SUS POPULARES LECTURAS DEVOLVIERON LA DIFUSIÓN DEL SOFTWARE A SUS VIDAS. HOY EN DÍA, «LA COMPUTACIÓN OMNIPRESENTE» [NOR98] HA PRODUCIDO UNA GENERACIÓN DE APLICACIONES DE INFORMACIÓN QUE TIENEN CONEXIÓN EN BANDA ANCHA A LA WEB PARA PROPORCIONAR «UNA CAPA DE CONEXIÓN SOBRE NUESTRAS CASAS, OFICINAS, Y AUTOPISTAS» [LEV99]. EL PAPEL DEL SOFTWARE CONTINÚA SU EXPANSIÓN.

EL PROGRAMADOR SOLITARIO DE ANTAÑO HA SIDO REEMPLAZADO POR UN EQUIPO DE ESPECIALISTAS DEL SOFTWARE, CADA UNO CENTRADO EN UNA PARTE DE LA TECNOLOGÍA REQUERIDA PARA ENTREGAR UNA APLICACIÓN CONCRETA. Y DE ESTE MODO, LAS CUESTIONES QUE SE PREGUNTABA EL PROGRAMADOR SOLITARIO SON LAS MISMAS CUESTIONES QUE NOS PREGUNTAMOS CUANDO CONSTRUIMOS SISTEMAS MODERNOS BASADOS EN COMPUTADORAS:

BIBLIOGRAFÍALIBRO: FUNDAMENTOS DE INGENIERÍA DE SOFTWARE UN ENFOQUE PRACTICO AUTOR: ROGER S. PRESSMANEDITORIAL: MCGRAW-HILLQUINTA EDICIÓ

10

1.2 EL PAPEL EVOLUTIVO DEL SOFTWARE

EN LA ACTUALIDAD, EL SOFTWARE TIENE UN PAPEL DUAL. ES UN PRODUCTO Y UN VEHÍCULO MEDIANTE EL CUAL SE ENTREGA EL PRODUCTO. COMO PRODUCTO, OFRECE LA POTENCIA DE CÓMPUTO PRESENTADA COMO HARDWARE DE UNA COMPUTADORA, O DE MANERA MÁS AMPLIA, POR UNA RED DE COMPUTADORAS ACCESIBLE MEDIANTE HARDWARE LOCAL.NO IMPORTA DONDE RESIDA EL SOFTWARE, ESTE ES UN TRANSFORMADOR DE INFORMACIÓN; REALIZA LA PRODUCCIÓN, EL MANEJO, EL DESPLIEGUE O LA TRANSMISIÓN DE LA INFORMACIÓN QUE PUEDE SER TAN SIMPLE COMO UN SOLO BIT O TAN COMPLEJA COMO UNA PRESENTACIÓN MULTIMEDIA.EN SU PAPEL DE VEHÍCULO PARA LA ENTREGA DE UN PRODUCTO, EL SOFTWARE ACTÚA COMO LA BASE PARA EL CONTROL DE LA COMPUTADORA (SO), LA COMUNICACIÓN DE INFORMACIÓN (REDES), Y LA CREACIÓN Y EL CONTROL DE OTROS PROGRAMAS (UTILERÍAS DE SOFTWARE Y AMBIENTES).EL SOFTWARE DE COMPUTADORAS EVOLUCIONA A TRAVÉS DEL TIEMPO, SIN IMPORTAR SU DOMINIO DE APLICACIÓN, EL TAMAÑO O COMPLEJIDAD.EL CAMBIO (MANTENIMIENTO DE SOFTWARE) CONDUCE ESTE PROCESO Y SE REPRESENTA CUANDO SE CORRIGEN ERRORES, CUANDO EL SOFTWARE SE ADOPTA A UN NUEVO AMBIENTE.

1.3 ETAPAS DEL DESARROLLO DEL SOFTWARE

EL MODELO LINEAL SECUENCIAL LLAMADO ALGUNAS VECES «CICLO DE VIDA BÁSICA» O MODELO EN CASCADA», EL MODELO LINEAL SECUENCIAL SUGIERE UN ENFOQUE5 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

ANÁLISIS DE LOS REQUISITOS DEL SOFTWARE. EL PROCESO DE REUNIÓN DE REQUISITOS SE INTENSIFICA Y SE CENTRA ESPECIALMENTE EN EL SOFTWARE. PARA COMPRENDER LA NATURALEZA DEL (LOS) PROGRAMA(S) A CONSTRUIRSE, EL INGENIERO («ARIALISTA ») DEL SOFTWARE DEBE COMPRENDER EL DOMINIO DE INFORMACIÓN DEL SOFTWARE (DESCRITO EN EL

11

CAPÍTULO 1 L), ASÍ COMO LA FUNCIÓN REQUERIDA, COMPORTAMIENTO, RENDIMIENTO E INTERCONEXIÓN.

DISEÑO. EL DISEÑO DEL SOFTWARE ES REALMENTE UN PROCESO DE MUCHOS PASOS QUE SE CENTRA EN CUATRO ATRIBUTOS DISTINTOS DE PROGRAMA: ESTRUCTURA DE DATOS, ARQUITECTURA DE SOFTWARE, REPRESENTACIONES DE INTERFAZ Y DETALLE PROCEDIMENTAL (ALGORITMO). EL PROCESO DEL DISEÑO TRADUCE REQUISITOS EN UNA REPRESENTACIÓN DEL SOFTWARE DONDE SE PUEDA EVALUAR SU CALIDAD ANTES DE QUE COMIENCE LA CODIFICACIÓN.

GENERACIÓN DE CÓDIGO. EL DISEÑO SE DEBE TRADUCIR EN UNA FORMA LEGIBLE POR LA MÁQUINA. EL PASO DE GENERACIÓN DE CÓDIGO LLEVA A CABO ESTA TAREA. SI SE LLEVA A CABO EL DISEÑO DE UNA FORMA DETALLADA, LA GENERACIÓN DE CÓDIGO SE REALIZA MECÁNICAMENTE.

PRUEBAS. UNA VEZ QUE SE HA GENERADO EL CÓDIGO, COMIENZAN LAS PRUEBAS DEL PROGRAMA. EL PROCESO DE PRUEBAS SE CENTRA EN LOS PROCESOS LÓGICOS INTERNOS DEL SOFTWARE, ASEGURANDO QUE TODAS LAS SENTENCIAS SE HAN COMPROBADO, Y EN LOS PROCESOS EXTERNOS FUNCIONALES; ES DECIR, REALIZAR LAS PRUEBAS PARA LA DETECCIÓN DE ERRORES Y ASEGURAR QUE LA ENTRADA DEFINIDA PRODUCE RESULTADOS REALES DE ACUERDO CON LOS RESULTADOS REQUERIDOS.MANTENIMIENTO. EL SOFTWARE INDUDABLEMENTE SUFRIRÁ CAMBIOS DESPUÉS DE SER ENTREGADO AL CLIENTE (UNA EXCEPCIÓN POSIBLE ES EL SOFTWARE EMPOTRADO). SE PRODUCIRÁN CAMBIOS PORQUE SE HAN ENCONTRADO ERRORES, PORQUE EL SOFTWARE DEBE ADAPTARSE PARA ACOPLARSE A LOS CAMBIOS DE SU ENTORNO EXTERNO (POR EJEMPLO: SE REQUIERE UN CAMBIO DEBIDO A UN SISTEMA OPERATIVO O DISPOSITIVO PERIFÉRICO NUEVO), O PORQUE EL CLIENTE REQUIERE MEJORAS FUNCIONALES O DE RENDIMIENTO. EL SOPORTE Y MANTENIMIENTO DEL SOFTWARE VUELVE A APLICAR CADA UNA DE LAS FASES PRECEDENTES A UN PROGRAMA YA EXISTENTE Y NO A UNO NUEVO.

12

EL MODELO LINEAL SECUENCIAL ES EL PARADIGMA MÁS ANTIGUO Y MÁS EXTENSAMENTE UTILIZADO EN LA INGENIERÍA DEL SOFTWARE. SIN EMBARGO, LA CRÍTICA DEL PARADIGMA HA PUESTO EN DUDA SU EFICACIA [HAN95]. ENTRE LOS PROBLEMAS QUE SE ENCUENTRAN ALGUNAS VECES EN EL MODELO LINEAL SECUENCIAL SE INCLUYEN:

LOS PROYECTOS REALES RARAS VECES SIGUEN EL MODELO SECUENCIAL QUE PROPONE EL MODELO. AUNQUE EL MODELO LINEAL PUEDE ACOPLAR INTERACCIÓN, LO HACE INDIRECTAMENTE. COMO RESULTADO, LOS CAMBIOS PUEDEN CAUSAR CONFUSIÓN CUANDO EL EQUIPO DEL PROYECTO COMIENZA.

A MENUDO ES DIFÍCIL QUE EL CLIENTE EXPONGA EXPLÍCITAMENTE TODOS LOS REQUISITOS. EL MODELO LINEAL SECUENCIAL LO REQUIERE Y TIENE DIFICULTADES A LA HORA DE ACOMODAR LA INCERTIDUMBRE NATURAL AL COMIENZO DE MUCHOS PROYECTOS.

EL CLIENTE DEBE TENER PACIENCIA. UNA VERSIÓN DE TRABAJO DEL (LOS) PROGRAMA(S) NO ESTARÁ DISPONIBLE HASTA QUE EL PROYECTO ESTÉ MUY AVANZADO. UN GRAVE ERROR PUEDE SER DESASTROSO SI NO SE DETECTA HASTA QUE SE REVISA EL PROGRAMA.

CADA UNO DE ESTOS ERRORES ES REAL. SIN EMBARGO, EL PARADIGMA DEL CICLO DE VIDA CLÁSICO TIENE UN LUGAR DEFINIDO E IMPORTANTE EN EL TRABAJO DE LA INGENIERÍA DEL SOFTWARE. PROPORCIONA UNA PLANTILLA EN LA QUE SE ENCUENTRAN MÉTODOS PARA ANÁLISIS, DISEÑO, CODIFICACIÓN, PRUEBAS Y MANTENIMIENTO. EL CICLO DE VIDA CLÁSICO SIGUE SIENDO EL MODELO DE PROCESO MÁS EXTENSAMENTE UTILIZADO POR LA INGENIERÍA DEL SOFTWARE. PESE A TENER DEBILIDADES, ES SIGNIFICATIVAMENTE MEJOR QUE UN ENFOQUE HECHO AL AZAR PARA EL DESARROLLO DEL SOFTWARE.

BIBLIOGRAFÍA

13

LIBRO: FUNDAMENTOS DE INGENIERÍA DE SOFTWARE UN ENFOQUE PRACTICO AUTOR: ROGER S. PRESSMANEDITORIAL: MCGRAW-HILLQUINTA EDICIÓN

1.3ETAPAS DEL DESARROLLO DEL SOFTWARE

1.-ANALISIS: CONSTRUYE UN MODELO DE LOS REQUISITOS.2.- DISEÑO: A PARTIR DEL MODELO DE ANALISIS SE DEDUCEN LAS ESTRUCTURAS DE DATOS, LA ESTRUCTURA EN LA QUE DESCOMPONE EL SISTEMA Y LA INTERFAZ DEL USUARIO.3.- CODIFICACIÓN: CONSTRUYE EL SISTEMA. LA SALIDA DE ESTA FASE ES CÓDIGO EJECUTABLE.4.- PRUEBAS: SE COMPRUEBA QUE SE CUMPLEN CRITERIOS DE CORRECCIÓN Y CALIDAD.5.- MANTENIMIENTO: EN ESTA FASE QUE TIENE LUGAR DESPUÉS DE LA ENTREGA SE ASEGURA QUE EL SISTEMA SIGA FUNCIONANDO Y ADAPTÁNDOSE A NUEVOS REQUISITOS.LAS ETAPAS CONSTAN DE TAREAS. LA DOCUMENTACIÓN ES UNA TAREA IMPORTANTE QUE SE REALIZA EN TODAS LAS ETAPAS, CADA ETAPA TIENE COMO ENTRADA UNO O VARIOS DOCUMENTOS PROCEDENTES DE LAS ETAPAS ANTERIORES Y PRODUCE OTROS DOCUMENTOS DE SALIDA SEGÚN SE MUESTRA EN LA FIGURA.MODELOS DEL CICLO DE VIDA DEL SOFTWARECASCADA: PROPUESTO POR ROCE EN 1970, FUE ADAPTADO PARA EL SOFTWARE PARTIR DE CICLOS DE VIDA DE OTRAS RAMAS DE INGENIERÍA. EL PRIMERO DE LOS PROPUESTOS Y EL MÁS AMPLIAMENTE SEGUIDO POR LAS ORGANIZACIONES.MODELOS DEL CICLO DE LA VIDA DEL SOFTWAREESPIRAL: PROPUESTO POR BOHEMA EN 1988. CONSISTE EN UNA SERIE DE CICLOS QUE SE REPITEN. CADA UNO TIENE LAS MISMAS FASES Y CUANDO TERMINA DA UN PRODUCTO AMPLIADO CON RESPECTO AL CICLO ANTERIOR. EN ESTE SENTIDO ES PARECIDO AL MODELO INCREMENTAL, LA DIFERENCIA IMPORTANTE ES QUE TIENE EN CUENTA EL CONCEPTO DE RIESGO.UN RIESGO PUEDE SER MUCHAS COSAS:REQUISITOS NO COMPRENDIDOS, MAL DISEÑO, ERRORES EN LA IMPLEMENTACIÓN, ETC.

14

UNA REPRESENTACIÓN TÍPICA DE ESTA ESTRUCTURA SE MUESTRA EN LA SIGUIENTE FIGURA:VENTAJAS:-NO NECESITA UNA DEFINICIÓN COMPLETA DE LOS REQUISITOS PARA EMPEZAR A FUNCIONAR.-AL ENTREGAR PRODUCTOS DESDE EL FINAL DE LA PRIMERA ITERACIÓN ES MÁS FÁCIL VALIDAR LOS REQUISITOS.-EL RIESGO EN GENERAL ES MENOR, PORQUE SI TODO SE HACE MAL, SOLO SE HA PERDIDO EL TIEMPO Y RECURSOS INVERTIDOS.-EL RIESGO DE SUFRIR RETRASOS ES MENOR, YA QUE AL IDENTIFICAR LOS PROBLEMAS EN ETAPAS TEMPRANAS HAY TIEMPO DE SOLUCIONARLAS.ES DIFÍCIL EVALUAR RIESGOS. NECESITA DE LA PARTICIPACIÓN CONTINUA POR PARTE DEL CLIENTE, CUANDO SE SUBCONTRATA HAY QUE PRODUCIR PREVIAMENTE UNA ESPECIFICACIÓN COMPLEJA DE LO QUE SE NECESITA, Y ESTO LLEVA TIEMPO.MODELO BASADO EN PROTOTIPOSNO POSEE LA FUNCIONALIDAD TOTAL DEL SISTEMA PERO SI CONDENSA LA IDEA PRINCIPAL DEL MISMO. PASO A PASO CRECE SU FUNCIONALIDAD, ALTO GRADO DE PARTICIPACIÓN DEL USUARIO.VENTAJAS & DESVENTAJAS-EL CLIENTE PUEDE PENSAR QUE EL PROTOTIPO ES UNA VERSIÓN ACABADA-PUEDEN LLEGAR A PASARSE POR ALTO LA CALIDAD DEL SOFTWARE GLOBAL O EL MANTENIMIENTO A LARGO PLAZO-LAS HERRAMIENTAS ELEGIDAS PUEDEN SER INADECUADAS-LA CLAVE DEL ÉXITO DE ESTE MODELO CONSISTE EN DEFINIR BIEN, DESDE EL PRINCIPIO, LAS REGLAS DEL JUEGO.-ALTO GRADO DE PARTICIPACIÓN DEL USUARIO.APLICACIONES-SU UTILIZACIÓN SI EL MERCADO NO SE ENCUENTRA EL PRODUCTO PERO EL CLIENTE DESEA RESULTADOS INMEDIATOS.-CONVENIENTE EN CASO DE SER NECESARIO DESARROLLAR MÓDULOS.-PARA SISTEMAS INTERACTIVOS PEQUEÑA O DE TAMAÑO PEQUEÑO.-PARA PARTES DE SISTEMAS GRANDES EN VIDA CORTA.

15

1.4 CLASIFICACIÓN DE LA TECNOLOGÍA EN EL DESARROLLO DE SOFTWARE (TECNOLOGÍA ESTRUCTURADA Y ORIENTADA A OBJETOS)

UN PROYECTO DE DESARROLLO DE UN SISTEMA INFORMÁTICO, COMO CUALQUIER PROYECTO DE INGENIERÍA, SE ESTRUCTURA EN UNA SERIE DE FASES PARA CONFIGURAR SU CICLO DE VIDA. EN EL CASO DE PROYECTO INFORMÁTICO, ESTAS FASES SE BASAN EN LAS ACTIVIDADES Y SEGÚN EL MODO EN EL QUE SE ORGANIZAN SE DEFINEN LOS PARADIGMAS ESTRUCTURADOS Y LOS PARADIGMAS ORIENTADOS A OBJETOS.ES IMPORTANTE DESTACAR QUE EL MODO EN QUE SE DESARROLLA EL SOFTWARE ES LO QUE REALMENTE DETERMINA CUAL ES EL PARADIGMA DE CICLO DE VIDA QUE SE SIGUE, CONDICIONANDO LA SECUENCIA Y LA FORMA EN QUE SE REALIZAN LAS ACTIVIDADES.

PARADIGMA ORIENTADO A OBJETOS

FRENTE A LOS MÉTODOS, QUE YA PUEDEN SER LLAMADOS RACIONALES, SURGE EL MODELADO ORIENTADO A OBJETOS, EN EL QUE EL ÉNFASIS DEL PROYECTO SE CENTRA EN LAS FASES DE ANÁLISIS Y DISEÑO. EL OBJETIVO ES PERMITIR Y FACILITAR LA REUSABILIDAD, EL REFINAMIENTO, LA VERIFICACIÓN, EL MANTENIMIENTO Y LA EXTENSIÓN DEL SOFTWARE. PARA ELLO ES NECESARIO UN DISEÑO BASADO EN LOS PRINCIPIOS DE OCULTACIÓN DE INFORMACIÓN, CLASIFICACIÓN, GENERALIZACIÓN, PASO DE MENSAJES Y POLIMORFISMO QUE RIGEN ESTE PARADIGMA.

SEGÚN EL OBJECT MALAJEMENTE GROUP, UN OBJETO ES UNA COSA. SE CREA LA INSTANCIA DE UN TIPO DE OBJETO. TAMBIÉN CADA OBJETO TIENE UNA IDENTIDAD ÚNICA QUE ES DESTINADA E INDEPENDIENTE DE CUALQUIERA DE SUS CARACTERÍSTICAS Y OFRECE UNA O MÁS OPERACIONES.PARA OBTENER LOS OBJETOS EN EL MODELADO DE UN SISTEMA SOFTWARE SE APLICA UN MECANISMO DE ABSTRACCIÓN A LAS ENTIDADES DEL MUNDO REAL. ESTE MECANISMO EXTRAE LAS CARACTERÍSTICAS MÁS SIGNIFICATIVAS DE UNA ENTIDAD, OBVIANDO LAS SUPLEMENTARIAS Y OBTENIENDO UN MODELO

16

QUE FACILITA EL MANEJO DEL MISMO EN UN SISTEMA SOFTWARE.

SI LA ENTIDAD EXISTE REALMENTE EN EL MUNDO REAL, LA ABSTRACCIÓN OBTIENE UN OBJETO EN EL MODELADO. EN CAMBIO, SI EL MECANISMO SE APLICA A UN CONJUNTO DE ENTIDADES AGRUPADAS POR DETERMINADAS CARACTERÍSTICAS COMUNES ENTONCES LA ABSTRACCIÓN OBTIENEN UNA CLASE DE OBJETOS EN EL MODELADO. ESTA CLASE DE OBJETOS JUSTAMENTE CONTIENE LOS ASPECTOS MÁS SIGNIFICATIVOS DE TODO EL CONJUNTO DE ENTIDADES Y ES UNO DE LOS RESULTADOS DEL ANÁLISIS DEL SISTEMA.POR LO CONTRARIO, CUANDO EXISTE UNA CLASE DE OBJETOS Y SE QUIERE PARTICULARIZAR ESTA CLASE MEDIANTE LA OBTENCIÓN DE UN EJEMPLAR DE LA MISMA, QUE REPRESENTA UNA DE LAS ENTIDADES DEL MUNDO REAL, SE ESTÁ APLICANDO EL MECANISMO DE INSTANCIACIÓN U OBTENCIÓN DE UN ESPÉCIMEN DE UNA CLASE DE OBJETOS, QUE ES PROPIAMENTE EL OBJETO DE DICHA CLASE.LAS PRIMERAS METODOLOGÍAS ORIENTADAS A OBJETOS QUE SURGIERON A PARTIR DE LAS METODOLOGÍAS ESTRUCTURADAS, CON LAS QUE HAN CONVIVIDO HASTA NO HACE MUCHO, PROPUGNABAN CICLOS DE VIDA CON ESTRUCTURA CLÁSICA PERO CON TÉCNICAS Y HERRAMIENTAS ORIENTADAS A OBJETOS. ASÍ SURGIERON OS CONCEPTOS DE ANÁLISIS ORIENTADO A OBJETOS, DISEÑO ORIENTADO A OBJETOS, PROGRAMACIÓN ORIENTADA A OBJETOS, PRUEBAS ORIENTADAS A OBJETOS, ETC. SIN EMBARGO, ESTOS ENFOQUES NO DIERON RESULTADO PUESTO QUE LA METODOLOGÍA ORIENTADA A OBJETOS SUPONE UN CAMBIO DE ENFOQUE SUSTANCIAL RESPECTO A LAS TÉCNICAS TRADICIONALES. PRINCIPALMENTE REQUIERE UNA FORMA DIFERENTE DE PENSAR, DE DESARROLLAR Y DE COMUNICARSE ENTRE LAS DIVERSAS FASES DEL PROYECTO. TAMBIÉN EXIGÍAN LA APARICIÓN DE NUEVAS TÉCNICAS Y LENGUAJES DE MODELADO Y REPRESENTACIÓN DE LOS CONCEPTOS ASOCIADOS A LOS OBJETOS.

SEGÚN LOS NUEVOS ENFOQUES DE METODOLOGÍAS ORIENTADAS A OBJETOS, EL PROCESO DE DESARROLLO DE

17

SOFTWARE DEBE SER DE TIPO ITERATIVO. ESTE PROPONE UNA COMPRENSIÓN INCREMENTAL DEL PROBLEMA A TRAVÉS DE REFINAMIENTOS SUCESIVOS Y UN CRECIMIENTO INCREMENTAL DE UNA SOLUCIÓN EFECTIVA A TRAVÉS DE VARIOS CICLOS. COMO PARTE DEL ENFOQUE ITERATIVO, SE ENCUENTRA LA FLEXIBILIDAD PARA ACOMODARSE A NUEVOS REQUISITOS O A CAMBIOS TÁCTICOS EN LOS OBJETIVOS DEL NEGOCIO. TAMBIÉN PERMITE QUE EL PROYECTO IDENTIFIQUE Y RESUELVA LOS RIESGOS MÁS BIEN PRONTO QUE TARDE.

BIBLIOGRAFÍA: INGENIERÍA DE PROYECTOS INFORMÁTICOS: ACTIVIDADES Y PROCEDIMIENTOS, ESCRITO POR JOSÉ SALVADOR SÁNCHEZ GARRETA, PAGINAS 61-65.

PARADIGMA ESTRUCTURADO

ESTE MÉTODO ES UNA COLECCIÓN DE IDEAS SOBRE INGENIERÍA DEL SOFTWARE, DESARROLLADO DURANTE LOS ÚLTIMOS VEINTE AÑOS POR AUTORES COMO E. YOURDON, T. DE MARCO, CONSTANTINE, J.D, WARNIER, Y OTROS. ESTAS IDEAS HAN SIDO RECOGIDAS BAJO EL NOMBRE DE TÉCNICAS ESTRUCTURADAS: PROGRAMACIÓN ESTRUCTURADA, DISEÑO ESTRUCTURADO Y ANÁLISIS ESTRUCTURADO.EL MÉTODO ESTRUCTURADO CONCIBE EL ANÁLISIS Y DISEÑO DEL SISTEMA EN BASE A LA CONSTRUCCIÓN DE MODELOS, CON EL FIN DE REPRESENTAR LAS FUNCIONES QUE REALIZA EL SISTEMA, DESDE SU CONCEPCIÓN FÍSICA HASTA LA DEDUCCIÓN LÓGICA DE SU INFORMACIÓN Y PROCESOS.TODO MODELO ESTÁ DETERMINADO POR TRES PARTES BIEN DIFERENCIADAS. LA REPRESENTACIÓN GRÁFICA LA CONSTITUYEN UN CONJUNTO DE DIAGRAMAS QUE PRESENTAN ESQUEMÁTICAMENTE LAS FUNCIONES Y FLUJOS DE INFORMACIÓN.LA DEFINICIÓN O DICCIONARIO DE DATOS RECOGE LA DESCRIPCIÓN DE CADA OBJETO REPRESENTADO EN LOS DIAGRAMAS, SU DEFINICIÓN Y COMPOSICIÓN.LA ESPECIFICACIÓN ES UNA DESCRIPCIÓN DETALLADA DE LAS FUNCIONES O PROCESOS MÁS PRÓXIMOS AL PROGRAMA O MODULO A CODIFICAR.

18

LA TÉCNICA ESTRUCTURADA SE BASA EN EL CONCEPTO TOP-DOWN DE PARTICIONAL EL SISTEMA EN FUNCIONES. EN UN PRIMER NIVEL SE REPRESENTAN LAS ENTRADAS Y SALIDAS DEL SISTEMA, PARA BAJAR A NIVELES INFERIORES, DONDE SE DESCRIBE EN QUE CONSISTE CADA PROCESO.

EN LA DÉCADA DEL 70 LA PROGRAMACIÓN ESTRUCTURADA FUE CONSIDERADA COMO UN NUEVO PARADIGMA QUE CONTRIBUYO A MEJORAR LA CONSTRUCCIÓN, EL MANTENIMIENTO Y USO DE LAS HERRAMIENTAS DE SOFTWARE. PERO, A DIFERENCIA DE LAS TÉCNICAS Y MÉTODOS DE PROGRAMACIÓN DEL SIGLO ANTERIOR, QUE CONSIDERABAN A LOS PROGRAMAS COMO AGRUPACIONES DE PROCEDIMIENTOS QUE SE LLAMABAN ENTRE SÍ, PROCEDIMIENTOS CUYOS DATOS ESTABAN ASOCIADOS PASIVAMENTE PARA OPERAR SOBRE ELLOS; EN LA PROGRAMACIÓN ORIENTADA U OBJETOS EL TRATAMIENTO ES DIFERENTE, PUES EN CADA APLICACIÓN LOS OBJETOS POSEEN SUS PARTICULARIDADES Y SUS PROPIOS ESTADOS, MANTENIENDO CIERTA FUNCIONALIDAD, ES DECIR, CADA OBJETO POSEE UN ESTADO Y COMPORTAMIENTO. ESTOS OBJETOS PUEDEN INTERCOMUNICARSE Y RELACIONARSE, GENERANDO CADA UNO SUS PROPIAS MANERAS DE RESPONDER, SEGÚN LOS PROCEDIMIENTOS ASOCIADOS A CADA OBJETO.

ESTE PARADIGMA DE LA PROGRAMACIÓN ORIENTADA A OBJETOS BUSCA DISMINUIR LA BRECHA ENTRE EL LENGUAJE DE LAS SOLUCIONES DE LA COMPUTACIÓN CON EL DEL PLANTEAMIENTO DE LOS PROBLEMAS. ELLO CON EL INTERÉS DE GENERAR ELEMENTOS DE SOFTWARE CON LAS CARACTERÍSTICAS DE REUTILIZACIÓN, CONSISTENCIA Y ROBUSTEZ, CUYA CONSTRUCCIÓN, MANTENIMIENTO Y REFINACIÓN SEAN MÁS FÁCILES, PARA AFRONTAR ADECUADAMENTE LOS PROBLEMAS EXISTENTES DESDE EL INICIO DEL DESARROLLO DEL SOFTWARE, LA FALTA DE PORTABILIDAD DEL CÓDIGO Y REUSABILIDAD, CÓDIGO DIFÍCIL DE MODIFICAR, CICLOS DE DESARROLLO LARGOS Y TÉCNICAS DE CODIFICACIÓN NO INTUITIVAS.

19

BIBLIOGRAFÍA:MÉTODO PARA LA SOLUCIÓN DE PROBLEMAS UTILIZANDO LA PROGRAMACIÓN ORIENTADA A OBJETOS, ESCRITO POR JUAN JOSÉ FLORES CUETO, PAGINA 13.METODOLOGÍA DEL ANÁLISIS ESTRUCTURADO DE SISTEMAS, ESCRITO POR JESÚS BARRANCO DE AREBA, PAGINAS 59-60.

1.4 CLASIFICACIÓN DE LA TECNOLOGÍA EN EL DESARROLLO DEL SOFTWARE (TECNOLOGÍA ESTRUCTURADA Y ORIENTADA A OBJETOS.

TECNOLOGÍA ESTRUCTURADA-ORIENTADA A PROCESOS –ORIENTADA A DATOS- MIXTAS*JERÁRQUICOS * NO JERÁRQUICOSANALISISREQUISITOS: ESPECIFICACIONES, MODIFICACIONES, REDUNDANTES, AMBIGUAS, IMPOSIBLES DE MANTENER.ESPECIFICACIONES FUNCIONALES: GRAFICAS, PARTICIONADAS, MÍNIMAMENTE REDUNDANTESORIENTADA A PROCESOS-DIAGRAMAS DE FLUJO DE DATOS-DICCIONARIO DE DATOS-ESPECIFICACIÓN DE PROCESOS

FASES DEL ANALISIS ESTRUCTURADOMÉTODO DEL MARCOCONSTRUIR EL MODELO FÍSICO ACTUAL (DAD FÍSICO ACTUAL)CONSTRUIR EL MODELO LÓGICO ACTUAL (DAD LÓGICA ACTUAL)CREAR UN CONJUNTO DE MODELOS FÍSICOS ALTERNATIVOSESTIMAR LOS COSTOS Y TIEMPOS DE CADA OPCIÓNSELECCIONAR UN MODELOEMPAQUETAR LA ESPECIFICACIÓNMÉTODO DE GANE & SARDÓNCONSTRUIR EL MODELO LÓGICO ACTUAL (DAD LÓGICO ACTUAL)CONSTRUIR EL MODELO DEL NUEVO SISTEMA: ELABORAR UNA ESPECIFICACIÓN ESTRUCTURADA Y CONSTRUIR UN MODELO LÓGICO DE DATOS EN TERCERA FORMAN NORMAL QUE EXPRESE EL CONTENIDO DE LOS ALMACENES DE DATOS.SELECCIONAR UN MODELO LÓGICOCREAR EL NUEVO MODELO FÍSICO DEL SISTEMA

20

EMPAQUETAR LA ESPECIFICACIÓN

METODOLOGÍA DE YOURDON/CONSTANTINE-REALIZAR LOS DAD DEL SISTEMA-REALIZAR EL DIAGRAMA DE ESTRUCTURAS-EVALUAR EL DISEÑO-PREPARAR EL DISEÑO PARA LA IMPLEMENTACIÓN

METODOLOGÍAS ORIENTADAS A DATOS JERÁRQUICOS-LA ESTRUCTURA DE CONTROL DEL PROGRAMA DEBE SER JERÁRQUICA Y SE DEBE DERIVAR DE LA ESTRUCTURA DE DATOS DEL PROGRAMA-EL PROCESO DE DISEÑO CONSISTE EN DEFINIR PRIMERO LAS ESTRUCTURAS DE LOS DATOS DE ENTRADA Y SALIDA, MEZCLARLAS TODAS EN UNA ESTRUCTURA PROCEDIMENTAL PARA QUE SE AJUSTE A ESTA ESTRUCTURA-EL DISEÑO LÓGICO DEBE PROCEDER Y ESTAR SEPARADO DEL DISEÑO FÍSICOMETODOLOGÍAS ORIENTADAS A DATOS NO JERÁRQUICOSMETODOLOGÍA INGENIERA DE LA INFORMACIÓN:PLANIFICACIÓN: CONSTRUIR UNA ARQUITECTURA DE LA INFORMACIÓN Y UNA ESTRATEGIA QUE SOPORTE LOS OBJETIVOS DE LA ORGANIZACIÓN.ANALISIS: COMPRENDER LAS ÁREAS DEL NEGOCIO Y DETERMINAR LOS REQUISITOS DEL SISTEMADISEÑO: ESTABLECER EL COMPORTAMIENTO DEL SISTEMA DESEADO POR EL USUARIO Y QUE SEA ALCANZABLE POR LA TECNOLOGÍACONSTRUCCIÓN: CONSTRUIR SISTEMAS QUE CUMPLAN LOS TRES NIVELES ANTERIORES.

DISEÑO ESTRUCTURADO: (FINALES DE AÑOS 70)-MAYOR NIVEL DE ABSTRACCIÓN (INDEPENDENCIA DEL LENGUAJE DE PROGRAMA)-ELEMENTO BÁSICO DEL DISEÑO-MODULARIDAD. MEDIDAS DE CALIDAD DEL PROGRAMA

METODOLOGÍAS ORIENTAS A OBJETOS-REVOLUCIONARIOS O PUROS-SINTETIZAS O EVOLUTIVOS

21

DESARROLLO ORIENTADO A OBJETOS-ESENCIA: IDENTIFICACIÓN Y ORGANIZACIÓN DE CONCEPTOS DEL DOMINIO DE LA APLICACIÓN Y NO TANTO DE SU REPRESENTACIÓN FINAL EN UN LENGUAJE DE PROGRAMACIÓN-AÑOS 80-TRATA FUNCIONALIDAD Y DATOS DE FORMA CONJUNTA-PRINCIPIOS:-ABSTRACCIÓN-OCULTACIÓN DE INFORMACIÓN (ENCAPSULAMIENTO)-MODULARIDAD-LAS TÉCNICAS ESTRUCTURADAS HAN INFLUIDO EN ESTAS METODOLOGÍASCAMBIAN LOS PRINCIPIOS DE LAS METODOLOGÍAS ESTRUCTURADASESTRUCTURADO: EXAMINAR EL SISTEMA EXAMINANDO EL DOMINIO DEL PROBLEMA COMO UN CONJUNTO DE OBJETOS QUE INTERACTÚAN ENTRE SÍ.OBJETOS: ENCAPSULAN FUNCIONES + DATOS

ENFOQUES:REVOLUCIONARIOS O PUROS:-LA DE SE ENTIENDE COMO UN CAMBIO PROFUNDO DE LAS METODOLOGÍAS ESTRUCTURADAS QUE SE VEN COMO OBSOLETAS.-ODD (BROOCH), CROC/RED (WIRES-BROCK)SINTETIZAS O EVOLUTIVOS:-ANALISIS Y DISEÑO ESTRUCTURADO SE CONSIDERA COMO LA BASE PARA DESARROLLO DE-INT, RAPCICLOS DE VIDA PARA OO.AGRUPAMIENTO:ADAPTA FILOSOFÍA DE PRODUCTO VS PROYECTO, CONJUNTO DE CLASES RELACIONADAS CON UN OBJETIVO COMÚN.CARACTERÍSTICAS: SUBIRLOS DE VIDA CON ESPECIFICACIÓN, DISEÑO, REALIZACIÓN, VALIDACIÓN, GENERALIZACIÓN.METER 1990FUENTE:

22

REPRESENTA GRÁFICAMENTE. EL ALTO GRADO DE ITERACIÓN Y SOLAPAMIENTO DE LA ORO, APLICABLE A NIVEL DE CLASE INDIVIDUAL O AGRUPAMIENTOSHENDERSON SELLAR 1990.PINAL:REFLEJA EL PROCESO DEL DESARROLLO DE OO.DOS ESTILOS: SEGURO, TECNOLOGÍAS Y MÉTODOS PROBADOS; AL LIMITE: MAYOR RIESGO, MÁS VENTAJAS.AMBLAR 1994REMOLINO:EN LA PRÁCTICA, EL DESARROLLO ES DESORDENADO E IMPLICA MÚLTIPLES ITERACIONES RELACIONADAS.DIMENSIONES DE ITERACIÓN: AMPLITUD-TAMAÑO DEL DESARROLLO, PROFUNDIDAD-NIVEL DE ABSTRACCIÓN A DETALLE.MADUREZ:- GRADO DE COMPLECIÓN, CORRECCIÓN Y ELEGANCIA.ALTERNATIVAS- DIFERENTES SOLUCIONES A UN PROBLEMA.ALCANCE- OBJETIVOS DEL SISTEMA (REQUISITOS)PROCESO, MULTICICLICO NO LINEAL CON FORMA DE REMOLINO.

1.5 DEFINICIÓN E HISTORIA DE LAS HERRAMIENTAS CASE

CASE SIGNIFICA COMPUTER-AIDED SOFTWARE ENGINEERING. LAS HERRAMIENTAS CASE, APLICADAS AL DESARROLLO DE PROYECTOS INFORMÁTICOS, SON SISTEMAS INFORMÁTICOS DE AYUDA QUE POTENCIAN LA AUTOMATIZACIÓN DE LA PLANIFICACIÓN, ANÁLISIS Y DISEÑO Y GENERACIÓN DE SOFTWARE.SUS PRINCIPALES CARACTERÍSTICAS SON UTILIZAR EDICIONES Y REPRESENTACIONES GRÁFICAS, COMPROBAR LA CONSISTENCIA DEL TRABAJO (VER SI LAS ESTRUCTURAS DE DATOS ESTÁN COMPLETAMENTE ESPECIFICADAS, SI LOS INTERFACES DE MÓDULOS SON CORRECTOS, ETC.) Y GENERAR INTERFACES DE USUARIO.LAS HERRAMIENTAS CASE SON SOFTWARE DE APOYO AL DESARROLLO, MANTENIMIENTO Y DOCUMENTACIÓN INFORMATIZADOS DE SOFTWARE.

23

DE ESTA DEFINICIÓN GENERALMENTE SE EXCLUYEN LAS HERRAMIENTAS QUE TIENEN UNA DE LAS FUNCIONES SIGUIENTES:O BIEN NO TIENEN SOLO ESTA FINALIDAD (HERRAMIENTAS DE TRATAMIENTO DE TEXTO, DE HOJA DE CÁLCULO, DE DIBUJO EN GENERAL, DE PLANIFICACIÓN DE PROYECTOS DE CUALQUIER INGENIERÍA), YA QUE PROPIAMENTE PERTENECEN A OTROS ÁMBITOS;O BIEN SE UTILIZAN PARA CODIFICAR EL SOFTWARE (COMPILADORES, ENTORNOS DE CUARTA GENERACIÓN, EDITORES ORDINARIOS DE PROGRAMAS, ETC.), YA QUE SIEMPRE ESTÁN PRESENTES, INCLUSO EL DESARROLLO DE SOFTWARE SE HACE DE LA MANERA MÁS MANUAL POSIBLE.QUEDAN, PUES, PRINCIPALMENTE LAS HERRAMIENTAS QUE AYUDAN A APLICAR TÉCNICAS CONCRETAS DE DESARROLLO Y MANTENIMIENTO DE SOFTWARE Y POR ESO GESTIONAN INFORMACIÓN SOBRE LOS ELEMENTOS Y CONCEPTOS QUE SE UTILIZAN EN EL MÉTODO DE DESARROLLO, COMO LAS SIGUIENTES:LAS HERRAMIENTAS DIAGRAMÁTICAS, LAS CUALES, A DIFERENCIA DE LAS DE DIBUJO, RECONOCEN QUE UN DETERMINADO SÍMBOLO ES UNA CLASE Y NO SIMPLEMENTE UN RECTÁNGULO. ESTAS HERRAMIENTAS TAMBIÉN ACOSTUMBRAN A ACEPTAR DOCUMENTACIÓN TEXTUAL SOBRE AQUELLOS ELEMENTOS.LAS HERRAMIENTAS DE GESTIÓN DE LA PRUEBA Y DE GESTIÓN DE LA CALIDAD EN GENERAL.LAS HERRAMIENTAS DE GESTIÓN DE CAMBIOS, ETC.LA EXPANSIÓN DEL USO DE HERRAMIENTAS CASE EN EL MÉTODO ESTRUCTURADO SE FRENÓ A CAUSA DE LA DIVERSIDAD Y DE LA FALTA DE ESTANDARIZACIÓN DE LAS TÉCNICAS QUE SE UTILIZAN; EN LOS MÉTODOS ORIENTADOS A OBJETOS, EN CAMBIO, ACTUALMENTE LA SITUACIÓN ES LA CONTRARIA: POR UN LADO, ALGUNOS DIAGRAMAS SIRVEN TANTO PARA EL ANÁLISIS COMO PARA EL DISEÑO, Y POR EL OTRO, SE HA PRODUCIDO UNA ESTANDARIZACIÓN DE LAS TÉCNICAS Y NOTACIONES EN EL MODELO CONOCIDO COMO UML QUE HA HECHO QUE EN EL POCO TIEMPO TRANSCURRIDO DESDE SU PUBLICACIÓN HAYA APARECIDO UN NÚMERO IMPORTANTE

24

DE CONJUNTOS INTEGRADOS DE HERRAMIENTAS CASE BASADAS EN ÉL.

DESDE PRINCIPIOS DE LA DÉCADA DE 1990, LOS ANALISTAS EMPEZARON A BENEFICIARSE DE LAS HERRAMIENTAS CASE. LOS ANALISTAS DE SISTEMAS SE APOYAN EN ESTAS HERRAMIENTAS, DESDE EL PRINCIPIO HASTA EL FIN DEL CICLO DE VIDA, PARA INCREMENTAR LA PRODUCTIVIDAD, COMUNICARSE DE MANERA MÁS EFICIENTE CON LOS USUARIOS E INTEGRAR EL TRABAJO QUE DESEMPEÑAN EN EL SISTEMA.

RAZONES PARA EL USO DE LAS HERRAMIENTAS CASE

AUMENTO EN LA PRODUCTIVIDAD DEL ANALISTA.MEJORA DE LA COMUNICACIÓN ANALISTA-USUARIO.INTEGRACIÓN DE LAS ACTIVIDADES DEL CICLO DE VIDA.EVALUAR DE MANERA PRECISA LOS CAMBIOS EN EL MANTENIMIENTO.LAS HERRAMIENTAS CASE TIENEN SU INICIO CON EL SIMPLE PROCESADOR DE PALABRAS QUE FUE USADO PARA CREAR Y MANIPULAR DOCUMENTACIÓN. LOS SETENTAS VIERON LA INTRODUCCIÓN DE TÉCNICAS GRÁFICAS Y DIAGRAMAS DE FLUJO DE ESTRUCTURAS DE DATOS. SOBRE ESTE PUNTO, EL DISEÑO Y ESPECIFICACIONES EN FORMA PICTÓRICA HAN SIDO EXTREMADAMENTE COMPLEJOS Y CONSUMÍAN MUCHO TIEMPO PARA REALIZAR CAMBIOS.LA INTRODUCCIÓN DE LAS HERRAMIENTAS CASE PARA AYUDAR EN ESTE PROCESO HA PERMITIDO QUE LOS DIAGRAMAS PUEDAN SER FÁCILMENTE CREADOR Y MODIFICADOS, MEJORANDO LA CALIDAD DE LOS DISEÑOS DE SOFTWARE. LOS DICCIONARIOS DE DATOS, UN DOCUMENTO MUY USADO QUE MANTIENE LOS DETALLES DE CADA TIPO DE DATO Y EL PROCESO DENTRO DE UN SISTEMA SON EL RESULTADO DIRECTO DE LA LLEGADA DEL DISEÑO DE FLUJO DE DATOS Y ANÁLISIS ESTRUCTURAL, HECHO POSIBLE A TRAVÉS DE LAS MEJORAS EN LAS HERRAMIENTAS CASE.

LA PRIMERA HERRAMIENTA COMERCIAL SE REMONTA A 1982, AUNQUE ALGUNOS ESPECIALISTAS INDICAN QUE ALGUNOS

25

EJEMPLOS DE HERRAMIENTAS PARA DIAGRAMACIÓN YA EXISTÍAN.NO FUE SINO HASTA 1985 EN QUE LAS HERRAMIENTAS CASE SE VOLVIERON REALMENTE IMPORTANTES EN EL PROCESO DE DESARROLLO DE SOFTWARE.LAS HERRAMIENTAS DEL CASE SERIAN UNA FAMILIA DE MÉTODOS FAVORABLEMENTE ESTRUCTURADOS PARA PLANEAMIENTO, ANÁLISIS Y DISEÑO. ESTO LLEVARÍA A LA GENERACIÓN AUTOMÁTICA DE CÓDIGO PARA DESARROLLO DE SOFTWARE VÍA UNA ESPECIFICACIÓN FORMALMENTE DISEÑADA.BIBLIOGRAFÍA:INSTITUTO NACIONAL DE ESTADÍSTICAS E INFORMÁTICA, PAGINAS 13-15.INFORMACIÓN TECNOLÓGICA, VOL. 8 N° 6, 1997, PÁGINA 159.ANÁLISIS Y DISEÑO DE SISTEMAS, SEXTA EDICIÓN, KENNETH E. KENDALL, JULIE E. KENDALL, PAGINAS 14-16.

1.5 DEFINICIÓN E HISTORIA DE LAS HERRAMIENTAS CASE

DEFINICIÓN:DE ACUERDO CON KENDALL EL DESARROLLO DE SISTEMA ES ASISTIDA POR ORDENADORES EN LA APLICACIÓN INFORMÁTICA, ES ACELERAR EL PROCESO PARA EL QUE HAN SIDO DESARROLLADAS.EN CAMBIO LAS HERRAMIENTAS CASE (COMPUTER-AIDED SOFTWARE ENGINEERING) SIRVE PARA APOYAR UNA FASE DEL CICLO DE VIDA DEL SISTEMA.CUANDO SE PLANIFICA LA BASE DE DATOS PERMITE ESCOGER UNA HERRAMIENTA CASE PARA LLEVAR DE FORMA EFICAZ Y POSIBLE LAS TAREAS, TAMBIÉN SUELEN INCLUIR:-UN DIRECCIONADO PARA LOS DATOS DE LA APLICACIÓN DE BASE DE DATOS.-HERRAMIENTAS DE DISEÑO PARA DAR APOYO AL ANALISIS DE DATOS.-HERRAMIENTAS PARA DESARROLLAR LOS PROTOTIPOS DE LAS APLICACIONES.-HERRAMIENTAS PARA DESARROLLAR EL MODELO DE DATOS CORPORATIVOS, LOS ESQUEMAS CONCEPTUAL Y LÓGICO.

26

-CON EL USO DE LAS HERRAMIENTAS CASE PUEDE MEJORAR LA PRODUCTIVIDAD DE APLICACIONES DE BASE DE DATOS.ESTRUCTURA:ALTO NIVEL: AUTOMATIZA O APOYA LAS FASES SUPERIORES DEL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS COMO PLANIFICACIÓN, ANALISIS Y DISEÑO DE SISTEMA.BAJO NIVEL: APOYA A LAS FASES INFERIORES DEL CICLO DE VIDA COMO EL DISEÑO DETALLADO, LA IMPLANTACIÓN, Y EL SOPORTE DE SISTEMAS.CRUZADO: HERRAMIENTAS QUE APOYAN ACTIVIDADES A LO LARGO DE TODO EL CICLO DE VIDA, INCLUYE ACTIVIDADES COMO LA GESTIÓN DE PROYECTOS Y LA ESTIMACIÓN.HISTORIAEN LA DÉCADA DE LOS 70 EL PROYECTO IDOS DESARROLLO UN LENGUAJE LLAMADO “PROBLEMA STATEMENT LENGUAJE (PSL)” PARA LA SOLUCIÓN DE UN PROBLEMA INFORMÁTICO DE UN DICCIONARIO AUTOMATIZADO. ERA UN PRODUCTO QUE ANALIZABA LOS PROBLEMAS Y NECESIDADES.LA PRIMER HERRAMIENTA ERA PARA PC LLAMADA “EXCELERATOR” EN 1984, LA OFERTA DE HERRAMIENTAS ES MUY AMPLIA COMO ES EL EASY CASE O WINPROJECT.ESTADO ACTUALEN LAS ÚLTIMAS DÉCADAS SE HA TRABAJADO EN EL DESARROLLO DE SISTEMAS PARA ENCONTRAR TÉCNICAS PARA INCREMENTAR LA PRODUCTIVIDAD Y CALIDAD EN EL PROCESO DE ELABORACIÓN DEL SOFTWARE, HOY LA HERRAMIENTA CASE HA REEMPLAZADO EL PAPEL Y LÁPIZ POR EL ORDENADOR PARA LA TRANSFORMACIÓN DEL DESARROLLO DE SOFTWARE EN UN PROCESO AUTOMATIZADO.LA TECNOLOGÍA CASE SUPONE LA AUTOMATIZACIÓN DEL DESARROLLO DE SOFTWARE PARA ELEVAR LA PRODUCTIVIDAD Y LA CALIDAD EN EL DESARROLLO DE SISTEMAS ANÁLOGAS A LO QUE SUPONEN LAS TÉCNICAS CADA/CAM EN ESTE ENFOQUE PERMITE MEJORAR LA CALIDAD DEL SOFTWARE.-LA MEJORA Y LA ESTANDARIZACIÓN DE LA DOCUMENTACIÓN- AUMENTAR LA PORTABILIDAD DE LAS APLICACIONES-FACILITAR LA REUTILIZACIÓN DE COMPONENTES DE SOFTWARE-PERMITIR UN DESARROLLO Y UN REFINAMIENTO DE LAS APLICACIONES, MEDIANTE LA UTILIZACIÓN DE CONTROLES GRÁFICOS.

27

1.6 CLASIFICACIÓN DE LAS HERRAMIENTAS CASE

LAS HERRAMIENTAS CASE SE CLASIFICAN COMO DE BAJO NIVEL, DE ALTO NIVEL E INTEGRADAS, ESTAS ÚLTIMAS COMBINANDO LAS DE ALTO NIVEL Y BAJO NIVEL EN UN SOLO CONJUNTO. A PESAR DE QUE LOS EXPERTOS DIFIEREN EN LOS CRITERIOS QUE DEFINEN CON PRECISIÓN CUALES SON LAS HERRAMIENTAS CASE DE ALTO NIVEL Y CUALES LAS DE BAJO NIVEL, PODRÍA SER ÚTIL CLASIFICARLAS CON BASE EN LOS USUARIOS A LOS QUE DAN APOYO. LAS HERRAMIENTAS CASE DE ALTO NIVEL AYUDAN PRINCIPALMENTE A LOS ANALISTAS Y DISEÑADORES, EN TANTO QUE LAS DE BAJO NIVEL SON UTILIZADAS CON MÁS FRECUENCIA POR PROGRAMADORES Y TRABAJADORES QUE DEBEN IMPLEMENTAR LOS SISTEMAS DISEÑADOS CON HERRAMIENTAS CASE DE ALTO NIVEL.

HERRAMIENTAS CASE DE ALTO NIVELUNA HERRAMIENTA CASE DE ALTO NIVEL DA AL ANALISTA LA POSIBILIDAD DE CREAR Y MODIFICAR EL DISEÑO DEL SISTEMA. TODA LA INFORMACIÓN RELACIONAD CON EL PROYECTO SE ALMACENA EN UNA ENCICLOPEDIA DENOMINADA DEPOSITO CASE, UNA ENORME COLECCIÓN DE REGISTROS, ELEMENTOS, DIAGRAMAS, PANTALLAS, INFORMES E INFORMACIÓN DIVERSA. CON LA INFORMACIÓN DEL DEPÓSITO SE PODRÍAN GENERAR INFORMES QUE MUESTREN DONDE ESTÁ INCOMPLETO EL DISEÑO O DONDE CONTIENE ERRORES.LAS HERRAMIENTAS CASE DE ALTO NIVEL TAMBIÉN PUEDEN APOYAR LA MODELACIÓN DE LOS REQUERIMIENTOS FUNCIONALES DE UNA ORGANIZACIÓN, AYUDAR A LOS ANALISTAS Y USUARIOS A DEFINIR EL ALCANCE DE UN PROYECTO DETERMINADO Y A VISUALIZAR LA FORMA EN QUE EL PROYECTO SE COMBINA CON OTRAS PARTES DE LA ORGANIZACIÓN. ADEMÁS, ALGUNAS HERRAMIENTAS CASE DE ALTO NIVEL PUEDEN AYUDAR EN LA CREACIÓN DE PROTOTIPOS DE DISEÑOS DE PANTALLAS E INFORMES.HERRAMIENTAS CASE DE BAJO NIVELLAS HERRAMIENTAS CASE DE BAJO NIVEL SE UTILIZAN PARA GENERAR CÓDIGO FUENTE DE COMPUTADORA, ELIMINADO ASÍ LA NECESIDAD DE PROGRAMAR EL SISTEMA. LA GENERACIÓN DE CÓDIGO TIENE VARIAS VENTAJAS:

28

EL SISTEMA SE PUEDE GENERAR MÁS RÁPIDO QUE SI SE ESTUVIERA QUE ESCRIBIR TODOS LOS PROGRAMAS. NO OBSTANTE, CON FRECUENCIA EL PERIODO PARA FAMILIARIZARSE CON LA METODOLOGÍA UTILIZADA POR EL GENERADOR DE CÓDIGO ES MUY LARGO, POR LO QUE LA GENERACIÓN DEL PROGRAMA PODRÍA SER MÁS LENTA AL PRINCIPIO.LA GENERACIÓN DE CÓDIGO REDUCE EL TIEMPO INVERTIDO EN EL MANTENIMIENTO. NO HAY NECESIDAD DE MODIFICAR, PROBAR Y DEPURAR LOS PROGRAMAS DE COMPUTADORA. EN LUGAR DE ESO EL DISEÑO CASE SE VUELVE A GENERAR EL CÓDIGO.HERRAMIENTAS UPPERCASE Y LOWERCASEA VECES SE DISTINGUE ENTRE HERRAMIENTAS UPPERCASE, QUE SON LAS DE ANALISIS Y DISEÑO, Y LOWERCASE, QUE SE USAN DURANTE LA PROGRAMACIÓN Y LA PRUEBA.LA IMPORTANCIA DE LA INTEGRACIÓN DE LAS HERRAMIENTASES CONVENIENTE QUE LAS HERRAMIENTAS QUE DAN APOYO A DIFERENTES TÉCNICAS UTILIZADAS DENTRO DEL MISMO MÉTODO ESTÉN INTEGRADAS, EN EL SENTIDO DE QUE SI HAY UN TIPO DE ELEMENTO QUE ES COMÚN A DOS TÉCNICAS, SEA COMPARTIDO UNA VEZ Y QUE TODOS LOS CAMBIOS QUE SE REALICEN DESPUÉS EN ESTA DESCRIPCIÓN LLEGUEN A LAS DOS.LAS HERRAMIENTAS CASE PUEDEN CLASIFICARSE TAMBIÉN DE ACUERDO A:FUNCIONALIDAD: QUE FUNCIÓN PROPORCIONAN.PROCESO SOPORTADO: QUE ACTIVIDADES DEL PROCESO DE SOFTWARE SOPORTAN.LA EXTENSIÓN DEL SOPORTE QUE PROPORCIONAN.

TODAS LAS CLASIFICACIONES PERMITEN QUE LAS HERRAMIENTAS SEAN EVALUADAS Y COMPARADAS.

CASE INTEGRADOMIENTRAS LAS HERRAMIENTAS CASE SON USADAS, MÁS PODER SE OBTIENE, SI LAS HERRAMIENTAS TRABAJAN CONJUNTAMENTE.

29

HERRAMIENTAS ESPECIALIZADAS PUEDEN COMBINARSE PARA PROPORCIONAR AMPLIO SOPORTE PARA LAS ACTIVIDADES DEL PROCESO.INTEGRACIÓN DEL DISEÑO Y DOCUMENTACIÓN DE LAS MESAS DE TRABAJO.INTEGRACIÓN DE ESPECIFICACIONES, DISEÑO Y PROGRAMACIÓN DE HERRAMIENTAS CON UNA CONFIGURACIÓN Y ADMINISTRACIÓN DE LAS MESAS DE TRABAJO.

BIBLIOGRAFÍA:INGENIERÍA DE SOFTWARE, BENET CAMPDERRICH, PAGINA 31.ANÁLISIS Y DISEÑO DE SISTEMAS, SEXTA EDICIÓN, KENNETH E. KENDALL, JULIE E. KENDALL, PAGINAS 16-17.

1.6 CLASIFICACIÓN DE LAS HERRAMIENTAS CASE.

LAS HERRAMIENTAS NO TIENEN UNA ÚNICA CLASIFICACIÓN Y ES DIFÍCIL DETERMINAR UNA CLASE Y PUEDEN SER CLASIFICADAS DE ACUERDO A:-LAS PLATAFORMAS QUE SOPORTAN-LAS FASES DEL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS QUE CUBREN-LA ARQUITECTURA DE APLICACIONES QUE PRODUCEN-SU FUNCIONABILIDADLAS HERRAMIENTAS CASE EN FUNCIÓN DE LAS FASES DEL CICLO DE VIDA QUE ABARCAN, SE PUEDEN AGRUPAR DE LA FORMA SIGUIENTE:HERRAMIENTAS INTEGRADAS:I-CASE (INTÉGRATE CASE, CASO INTEGRADO) ABARCAN TODAS LAS FASES DEL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS, LLAMADAS CASE WORKBENCH.HERRAMIENTAS DE ALTO NIVEL:U-CASE (CASE SUPERIOR O FRONT END) ORIENTADAS A LA AUTOMATIZACIÓN Y SOPORTE DE LAS ACTIVIDADES DESARROLLADAS DURANTE LAS PRIMERAS FASES DEL DESARROLLO: ANALISIS Y DISEÑO.HERRAMIENTAS DE BAJO NIVEL:L CASE (CASE INFERIOR O BACK END) DIRIGIDAS A LAS ÚLTIMAS FASES DEL DESARROLLO: DESARROLLO E IMPLANTACIÓN.JUEGOS DE HERRAMIENTA+ O TOOLKITS

30

SON EL TIPO MÁS SIMPLE DE LAS HERRAMIENTAS CASE, AUTOMATIZAN UNA FASE DENTRO DEL CICLO DE VIDA, DENTRO DE ESTE GRUPO SE ENCONTRARAN LAS HERRAMIENTAS DE REINGENIERÍA, ORIENTADAS A LAS FASES DE MANTENIMIENTO.

CONCLUSIÓNCOMO SE PUDO OBSERVAR EL DESARROLLO DEL SOFTWARE ES ALTAMENTE COMPLICADO, YA QUE ES MUY DIFÍCIL DE LOGRAR OBTENER UN SOFTWARE CONFIABLE, ES DECIR, QUE CUMPLA CON TODAS LAS EXPECTATIVAS QUE EL USUARIO REQUIERE, PARA ELLO EL DISEÑO, ANÁLISIS Y OTRAS ETAPAS SON SUMAMENTE IMPORTANTES, YA QUE NOS PERMITE EL MENOR MARGEN DE ERROR PARA LA SOLUCIÓN DEL PROBLEMA.COMO SE HA VISTO LAS HERRAMIENTAS CASE SON EL MEJOR MÉTODO PARA EL ANÁLISIS Y SOLUCIONES DE SOFTWARE, YA QUE HAN VENIDO A MEJORAR LOS ASPECTOS CLAVES EN EL DESARROLLO DE LOS SISTEMAS DE INFORMACIÓN, LAS CASE HAN SIDO CREADAS PARA LA AUTOMATIZACIÓN DE PROCESOS DE ANÁLISIS, DISEÑO E IMPLEMENTACIÓN, BRINDÁNDONOS UN SIN NÚMERO DE COMPONENTES QUE HACEN QUE LOS PROYECTOS SEAN CADA DÍA MÁS EFICIENTES PARA LOS USUARIOS. DESDE QUE SE CREARON ESTAS HERRAMIENTAS EN 1984 HASTA LA ACTUALIDAD, LAS HERRAMIENTA CASE CUENTAN CON UNA CREDIBILIDAD Y EXACTITUD QUE TIENE UN RECONOCIMIENTO UNIVERSAL, SIENDO USADAS POR CUALQUIER ANALISTA Y/O PROGRAMADOR QUE BUSCA UN RESULTADO ÓPTIMO T EFICAZ, PARA CADA UNO DE SUS PROCESOS. ADEMÁS LAS HERRAMIENTAS CASE DEBEN BRINDAR LO SIGUIENTE PARA SER CONSIDERADAS BUENAS:

TOPOLOGÍAS DE APLICACIÓN FLEXIBLES APLICACIONES PORTÁTILES CONTROL DE VERSIÓN CREAR CÓDIGO COMPILADO EN EL SERVIDOR DAR UN SOPORTE MULTIUSUARIO OFRECER SEGURIDAD

31

BIBLIOGRAFÍA GENERAL

FUNDAMENTOS DE INGENIERÍA DE SOFTWARE UN ENFOQUE PRACTICO, ROGER S. PRESSMAN, MCGRAW-HILL, QUINTA EDICIÓN

INGENIERÍA DE PROYECTOS INFORMÁTICOS: ACTIVIDADES Y PROCEDIMIENTOS, ESCRITO POR JOSÉ SALVADOR SÁNCHEZ GARRETA, PAGINAS 61-65.

MÉTODO PARA LA SOLUCIÓN DE PROBLEMAS UTILIZANDO LA PROGRAMACIÓN ORIENTADA A OBJETOS, ESCRITO POR JUAN JOSÉ FLORES CUETO, PAGINA 13.

METODOLOGÍA DEL ANÁLISIS ESTRUCTURADO DE SISTEMAS, ESCRITO POR JESÚS BARRANCO DE AREBA, PAGINAS 59-60.

INSTITUTO NACIONAL DE ESTADÍSTICAS E INFORMÁTICA, PAGINAS 13-15.

INFORMACIÓN TECNOLÓGICA, VOL. 8 N° 6, 1997, PÁGINA 159.ANÁLISIS Y DISEÑO DE SISTEMAS, SEXTA EDICIÓN, KENNETH E. KENDALL, JULIE E. KENDALL, PAGINAS 14-16.

INGENIERÍA DE SOFTWARE, BENET CAMPDERRICH, PAGINA 31.ANÁLISIS Y DISEÑO DE SISTEMAS, SEXTA EDICIÓN, KENNETH E. KENDALL, JULIE E. KENDALL, PAGINAS 16-17.

32