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 ISAAC NOE MENDOZA LUNA 10320953 10320930

SEMESTRE: 6 ENERO-JUNIO AULA: 709

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

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.

UNIDAD 1 FUNDAMENTOS DE INGENIERA DE SOFTWARE. 1. CONCEPTOS BASICOS EL SOFTWARE DE COMPUTADORA ES EL PRODUCTO QUE DISEAN Y CONSTRUYEN LOS INGENIEROS DE SOFTWARE. CARACTERSTICAS DEL SOFTWARE: EL SOFTWARE SE DESARROLLA NO SE FABRICA EL SOFTWARE NO SE ESTROPEA, SE DETERIORA LA INGENIERA DE SOFTWARE ES EL ESTABLECIMIENTO Y USO DE LOS PRINCIPIOS ROBUSTOS DE LA INGENIERA A FIN DE OBTENER ECONMICAMENTE SOFTWARE QUE SEA FIABLE Y QUE FUNCIONE EFICIENTEMENTE SOBRE LAS MAQUINAS REALES. LA INGENIERA DE SOFTWARE ES LA APLICACIN DE UN ENFOQUE SISTEMTICO, DISCIPLINADO Y CUANTIFICABLE HACIA EL DESARROLLO, OPERACIN Y MANTENIMIENTO DEL SOFTWARE; ES DECIR, LA APLICACIN DE LA INGENIERA AL SOFTWARE. LA INGENIERA DE SOFTWARE ES UNA DISCIPLINA QUE INTEGRA, MTODOS Y HERRAMIENTAS PARA EL DESARROLLO DEL SOFTWARE DE COMPUTADORA. SE HAN PROPUESTO VARIOS MODELOS DE PROCESOS PARA LA INGENIERA DE SOFTWARE DE DIFERENTES, CADA UNO EXHIBIENDO VENTAJAS E INCONVENIENTES, PERO TODOS TIENEN UNA SERIE DE FACES GENRICAS EN COMN. APLICACIONES DEL SOFTWARE: SOFTWARE DE GESTIN SOFTWARE DE SISTEMAS SOFTWARE DE INGENIERA Y CIENTFICO SOFTWARE EMPOTRADO SOFTWARE DE TIEMPO REAL SOFTWARE DE COMPUTADORAS PERSONALES SOFTWARE BASADO EN WEB SOFTWARE DE INTELIGENCIA ARTIFICIAL

LA INGENIERA DEL SOFTWARE] ES EL ESTABLECIMIENTO Y USO DE PRINCIPIOS ROBUSTOS DE LA INGENIERA A FIN DE OBTENER ECONMICAMENTE SOFTWARE QUE SEA FIABLE Y QUE FUNCIONE EFICIENTEMENTE SOBRE MQUINAS REALES. EL FUNDAMENTO DE LA INGENIERA DEL SOFTWARE ES LA CAPA DE PROCESO. EL PROCESO DE LA INGENIERA DEL SOFTWARE ES LA UNIN QUE MANTIENE JUNTAS LAS CAPAS DE TECNOLOGA Y QUE PERMITE UN DESARROLLO RACIONAL Y OPORTUNO DE LA INGENIERA 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 TECNOLOGA DE LA INGENIERA DEL SOFTWARE. LAS REAS CLAVES DEL PROCESO FORMAN LA BASE DEL CONTROL DE GESTIN DE PROYECTOS DEL SOFTWARE Y ESTABLECEN EL CONTEXTO EN EL QUE SE APLICAN LOS MTODOS TCNICOS, 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 MTODOS DE LA INGENIERA DEL SOFTWARE INDICAN CMO CONSTRUIR TCNICAMENTE EL SOFTWARE. LOS MTODOS ABARCAN UNA GRAN GAMA DE TAREAS QUE INCLUYEN ANLISIS DE REQUISITOS, DISEO, CONSTRUCCIN DE PROGRAMAS, PRUEBAS Y MANTENIMIENTO. LOS MTODOS DE LA INGENIERA DEL SOFTWARE DEPENDEN DE UN CONJUNTO DE PRINCIPIOS BSICOS QUE GOBIERNAN CADA REA DE LA TECNOLOGA E INCLUYEN ACTIVIDADES DE MODELADO Y OTRAS TCNICAS DESCRIPTIVAS. BIBLIOGRAFA LIBRO: FUNDAMENTOS DE INGENIERA DE SOFTWARE UN ENFOQUE PRACTICO AUTOR: ROGER S. PRESSMAN EDITORIAL: MCGRAW-HILL QUINTA EDICIN

1.1 CONCEPTOS BSICOS DEFINICIN DE INGENIERA DE SOFTWARE. ES UNA DISCIPLINA QUE COMPRENDE TODOS LOS ASPECTOS DE LA PRODUCCIN DEL SOFTWARE DESDE LAS ETAPAS INICIALES DE LA ESPECIFICACIN DEL SISTEMA, HASTA EL MANTENIMIENTO DE ESTE DESPUS DE QUE SE UTILIZA. EL SOFTWARE SE DESARROLLA, NO MANUFACTURA; NO SE DESGASTA PERO SE DETERIORA. LA INGENIERA DE SOFTWARE INCLUYE A LAS PERSONAS, PROCESOS, PROYECTOS Y PRODUCTOS. PERSONAS: ES LA GENTE QUE COLABORA EN LA ELABORACIN 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 ESPECFICOS. 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 PEQUEO NMERO DE ACTIVIDADES DEL MARCO DE TRABAJO ES APLICABLE A TODOS LOS PROYECTOS DE SOFTWARE, SIN IMPORTAR SU TAMAO Y COMPLEJIDAD. ALGUNOS CONJUNTOS DE TAREAS DIFERENTES PERMITEN QUE LAS ACTUALIZACIONES DEL MARCO DE TRABAJO SE ADAPTEN A LAS CARACTERSTICAS DEL PROYECTO DE SOFTWARE, AS COMO LOS REQUISITOS DEL EQUIPO DEL PROYECTO. POR LTIMO, LAS ACTIVIDADES PROTECTORAS, COMO EL CONTROL DE LA CALIDAD, GESTIN DE CONFIGURACIN Y MEDICIN, CUBREN EL MODELO DEL PROCESO.

EL PROCESO DE "CASCADA COMIENZA CON LA ESPECIFICACIN DE LOS REQUERIMIENTOS PARA LA APLICACIN. DESPUS PROCEDE A LA ETAPA DE DISEO, IMPLEMENTACIN Y PRUEBA. PROYECTO: LOS PROYECTOS DE SOFTWARE SE REALIZAN DE MANERA PLANIFICADA Y CONTROLADA POR UNA RAZN 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 DA. PERO LA MAYORA DE LOS PROYECTOS QUE VALE LA PENA REALIZAR SON MS PARECIDOS A CONDUCIR UN CAMIN EN LA CARRETERA, EN LA MONTAA DE NOCHE". PRODUCTO: ANTES DE PLANEAR UN PROYECTO SE DEBERAN ESTABLECER LOS OBJETIVOS Y EL MBITO DEL PRODUCTO, CONSIDERAR SOLUCIONES ALTERNATIVAS E IDENTIFICAR LAS RESTRICCIONES TCNICAS Y DE GESTIN. SIN ESTA INFORMACIN ES IMPOSIBLE DEFINIR ESTIMACIONES RAZONABLES DEL COSTO CON UNA VALORACIN EFECTIVA DEL RIESGO, UNA DIVISIN REALISTA DE LAS TAREAS DEL PROYECTO O UN CALENDARIO DE PROYECTO MANEJABLE QUE OFREZCA UNA INDICACIN 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 CARACTERSTICAS 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 LMITES DE ENTREGA, RESTRICCIONES PRESUPUESTARIAS, DISPONIBILIDAD DEL PERSONAL, INTERFACES TCNICAS, ETC. CALIDAD:
7

RESALTA TRES ACTIVIDADES PARA ASEGURAR LA CALIDAD: INSPECCIN, DEMOSTRACIN DE FUNCIONAMIENTO CORRECTO Y PRUEBAS. LA INSPECCIN ES UN PROCESO ORIENTADO AL TRABAJO EN EQUIPO PARA ASEGURAR LA CALIDAD Y SE APLICA EN TODAS LAS ETAPAS DEL PROCESO. UNA DEMOSTRACIN DE FUNCIONAMIENTO CORRECTO ES UNA TCNICA MATEMTICA O LGICA USADA PARA CONVENCERNOS DE QUE UN PROGRAMA HACE LO QUE DEBE. ESTAS DEMOSTRACIONES SON MTODOS FORMALES. LOS PROGRAMAS NO SE EJECUTAN DURANTE EL PROCESO DE DEMOSTRACIN SOLO SE INSPECCIONA SU CDIGO FUENTE, EN LAS PRUEBAS SE EJECUTAN LOS PROGRAMAS. 1.2 EL PAPEL EVOLUTIVO DEL SOFTWARE HOY EN DA EL SOFTWARE TIENE UN DOBLE PAPEL. ES UN PRODUCTO Y, AL MISMO TIEMPO, EL VEHCULO PARA ENTREGARLO. COMO PRODUCTO, HACE ENTREGA DE LA POTENCIA INFORMTICA QUE INCORPORA EL HARDWARE INFORMTICO O, MS AMPLIAMENTE, UNA RED DE COMPUTADORAS QUE ES ACCESIBLE POR HARDWARE LOCAL. SI RESIDE DENTRO DE UN TELFONO CELULAR U OPERA DENTRO DE UNA COMPUTADORA CENTRAL, EL SOFTWARE ES UN TRANSFORMADOR DE INFORMACIN, PRODUCIENDO, GESTIONANDO, ADQUIRIENDO, MODIFICANDO, MOSTRANDO O TRANSMITIENDO INFORMACIN QUE PUEDE SER TAN SIMPLE COMO UN SOLO BIT, O TAN COMPLEJO COMO UNA PRESENTACIN EN MULTIMEDIA. COMO VEHCULO UTILIZADO PARA HACER ENTREGA DEL PRODUCTO, EL SOFTWARE ACTA COMO LA BASE DE CONTROL DE LA COMPUTADORA (SISTEMAS OPERATIVOS), LA COMUNICACIN DE INFORMACIN (REDES) Y LA CREACIN Y CONTROL DE OTROS PROGRAMAS (HERRAMIENTAS DE SOFTWARE Y ENTORNOS). EL PAPEL DEL SOFTWARE INFORMTICO HA SUFRIDO UN CAMBIO SIGNIFICATIVO DURANTE UN PERIODO DE TIEMPO SUPERIOR A 50 AOS. ENORMES MEJORAS EN RENDIMIENTO DEL HARDWARE, PROFUNDOS CAMBIOS DE ARQUITECTURAS INFORMTICAS, GRANDES AUMENTOS DE MEMORIA Y
8

CAPACIDAD DE ALMACENAMIENTO Y UNA GRAN VARIEDAD DE OPCIONES DE ENTRADA Y SALIDA HAN CONDUCIDO A SISTEMAS MS SOFISTICADOS Y MS COMPLEJOS BASADOS EN COMPUTADORA. LA SOFISTICACIN Y LA COMPLEJIDAD PUEDEN PRODUCIR RESULTADOS DESLUMBRANTES CUANDO UN SISTEMA TIENE XITO, PERO TAMBIN PUEDEN SUPONER GRANDES PROBLEMAS PARA AQUELLOS QUE DEBEN CONSTRUIR SISTEMAS COMPLEJOS. LIBROS POPULARES PUBLICADOS DURANTE LOS AOS 70 Y 80 PROPORCIONAN UNA VISIN HISTRICA TIL DENTRO DE LA PERCEPCIN CAMBIANTE DE LAS COMPUTADORAS Y DEL SOFTWARE, Y DE SU IMPACTO EN NUESTRA CULTURA. OSBORNE [OSB79] HABLABA DE UNA NUEVA REVOLUCIN INDUSTRIAL. TOFFLER [TOF80] LLAM A LA LLEGADA DE COMPONENTES MICRO ELECTRNICOS LA TERCERA OLA DEL CAMBIO EN LA HISTORIA DE LA HUMANIDAD, Y NAISBITT "A1821 PREDIJO LA TRANSFORMACIN DE LA SOCIEDAD INDUSTRIAL A UNA SOCIEDAD DE INFORMACIN . FEIGENBAUM Y MCCORDUCK [FE1831 SUGIRIERON QUE LA INFORMACIN Y EL CONOCIMIENTO (CONTROLADOS POR COMPUTADORA) SERAN EL FOCO DE PODER DEL SIGLO VEINTIUNO, Y STO11 [STO891 ARGUMENT QUE LA COMUNIDAD ELECTRNICA CREADA MEDIANTE REDES Y SOFTWARE ES LA CLAVE PARA EL INTERCAMBIO DE CONOCIMIENTO ALREDEDOR DEL MUNDO. AL COMIENZO DE LOS AOS 90, TOFFLER [TOF90] DESCRIBI UN CAMBIO DE PODER EN EL QUE LAS VIEJAS ESTRUCTURAS DE PODER (GUBERNAMENTALES, EDUCATIVAS, INDUSTRIALES, ECONMICAS Y MILITARES) SE DESINTEGRARAN A MEDIDA QUE LAS COMPUTADORAS Y EL SOFTWARE NOS LLEVARAN LA DEMOCRATIZACIN DEL CONOCIMIENTO. A YOURDON [YOU92] LE PREOCUPABA QUE LAS COMPAAS EN ESTADOS UNIDOS PUDIERAN PERDER SU COMPETITIVIDAD EN EMPRESAS RELATIVAS AL SOFTWARE Y PREDIJO EL DECLIVE Y LA CADA DEL PROGRAMADOR AMERICANO. HAMMER Y CHAMPY [HAM93] ARGUMENTARON QUE LAS TECNOLOGAS DE INFORMACIN IBAN A DESEMPEAR EL PAPEL PRINCIPAL EN LA REINGENIERA DE LA COMPAA. A MEDIADOS DE LOS AOS 90, LA PERSISTENCIA DE LAS COMPUTADORAS Y DEL SOFTWARE
9

GENER UNA ERUPCIN 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 LEGTIMAS PERO IGNORANDO LOS PROFUNDOS BENEFICIOS QUE SE HAN LLEVADO A CABO [LEV95]. AL FINAL DE LOS AOS 90, YOURDON [YOU96] VOLVI A EVALUAR LAS PERSPECTIVAS DEL SOFTWARE PROFESIONAL Y SUGIRI LA RESURRECCIN Y ELEVACIN 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 MS. AQU TUVO LUGAR EL IMPACTO DE LA BOMBA DE RELOJERA Y2K (POR EJEMPLO: [YOU98B], [DEJ98], [KAR99]). AUNQUE MUCHOS VIERON LAS PREDICCIONES DE LOS CRTICOS DEL Y2K COMO REACCIONES, SUS POPULARES LECTURAS DEVOLVIERON LA DIFUSIN DEL SOFTWARE A SUS VIDAS. HOY EN DA, LA COMPUTACIN OMNIPRESENTE [NOR98] HA PRODUCIDO UNA GENERACIN DE APLICACIONES DE INFORMACIN QUE TIENEN CONEXIN EN BANDA ANCHA A LA WEB PARA PROPORCIONAR UNA CAPA DE CONEXIN SOBRE NUESTRAS CASAS, OFICINAS, Y AUTOPISTAS [LEV99]. EL PAPEL DEL SOFTWARE CONTINA SU EXPANSIN. EL PROGRAMADOR SOLITARIO DE ANTAO HA SIDO REEMPLAZADO POR UN EQUIPO DE ESPECIALISTAS DEL SOFTWARE, CADA UNO CENTRADO EN UNA PARTE DE LA TECNOLOGA REQUERIDA PARA ENTREGAR UNA APLICACIN 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: BIBLIOGRAFA LIBRO: FUNDAMENTOS DE INGENIERA DE SOFTWARE UN ENFOQUE PRACTICO AUTOR: ROGER S. PRESSMAN EDITORIAL: MCGRAW-HILL QUINTA EDICI
10

1.2 EL PAPEL EVOLUTIVO DEL SOFTWARE EN LA ACTUALIDAD, EL SOFTWARE TIENE UN PAPEL DUAL. ES UN PRODUCTO Y UN VEHCULO MEDIANTE EL CUAL SE ENTREGA EL PRODUCTO. COMO PRODUCTO, OFRECE LA POTENCIA DE CMPUTO PRESENTADA COMO HARDWARE DE UNA COMPUTADORA, O DE MANERA MS AMPLIA, POR UNA RED DE COMPUTADORAS ACCESIBLE MEDIANTE HARDWARE LOCAL. NO IMPORTA DONDE RESIDA EL SOFTWARE, ESTE ES UN TRANSFORMADOR DE INFORMACIN; REALIZA LA PRODUCCIN, EL MANEJO, EL DESPLIEGUE O LA TRANSMISIN DE LA INFORMACIN QUE PUEDE SER TAN SIMPLE COMO UN SOLO BIT O TAN COMPLEJA COMO UNA PRESENTACIN MULTIMEDIA. EN SU PAPEL DE VEHCULO PARA LA ENTREGA DE UN PRODUCTO, EL SOFTWARE ACTA COMO LA BASE PARA EL CONTROL DE LA COMPUTADORA (SO), LA COMUNICACIN DE INFORMACIN (REDES), Y LA CREACIN Y EL CONTROL DE OTROS PROGRAMAS (UTILERAS DE SOFTWARE Y AMBIENTES). EL SOFTWARE DE COMPUTADORAS EVOLUCIONA A TRAVS DEL TIEMPO, SIN IMPORTAR SU DOMINIO DE APLICACIN, EL TAMAO 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 BSICA O MODELO EN CASCADA, EL MODELO LINEAL SECUENCIAL SUGIERE UN ENFOQUE5 SISTEMTICO, SECUENCIAL, PARA EL DESARROLLO DEL SOFTWARE QUE COMIENZA EN UN NIVEL DE SISTEMAS Y PROGRESA CON EL ANLISIS, DISEO, CODIFICACIN, PRUEBAS Y MANTENIMIENTO ANLISIS DE LOS REQUISITOS DEL SOFTWARE. EL PROCESO DE REUNIN 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 INFORMACIN DEL SOFTWARE (DESCRITO EN EL
11

CAPTULO 1 L), AS COMO LA FUNCIN REQUERIDA, COMPORTAMIENTO, RENDIMIENTO E INTERCONEXIN. DISEO. EL DISEO 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 DISEO TRADUCE REQUISITOS EN UNA REPRESENTACIN DEL SOFTWARE DONDE SE PUEDA EVALUAR SU CALIDAD ANTES DE QUE COMIENCE LA CODIFICACIN. GENERACIN DE CDIGO. EL DISEO SE DEBE TRADUCIR EN UNA FORMA LEGIBLE POR LA MQUINA. EL PASO DE GENERACIN DE CDIGO LLEVA A CABO ESTA TAREA. SI SE LLEVA A CABO EL DISEO DE UNA FORMA DETALLADA, LA GENERACIN DE CDIGO SE REALIZA MECNICAMENTE. PRUEBAS. UNA VEZ QUE SE HA GENERADO EL CDIGO, COMIENZAN LAS PRUEBAS DEL PROGRAMA. EL PROCESO DE PRUEBAS SE CENTRA EN LOS PROCESOS LGICOS INTERNOS DEL SOFTWARE, ASEGURANDO QUE TODAS LAS SENTENCIAS SE HAN COMPROBADO, Y EN LOS PROCESOS EXTERNOS FUNCIONALES; ES DECIR, REALIZAR LAS PRUEBAS PARA LA DETECCIN DE ERRORES Y ASEGURAR QUE LA ENTRADA DEFINIDA PRODUCE RESULTADOS REALES DE ACUERDO CON LOS RESULTADOS REQUERIDOS. MANTENIMIENTO. EL SOFTWARE INDUDABLEMENTE SUFRIR CAMBIOS DESPUS DE SER ENTREGADO AL CLIENTE (UNA EXCEPCIN POSIBLE ES EL SOFTWARE EMPOTRADO). SE PRODUCIRN 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 PERIFRICO 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 MS ANTIGUO Y MS EXTENSAMENTE UTILIZADO EN LA INGENIERA DEL SOFTWARE. SIN EMBARGO, LA CRTICA 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 INTERACCIN, LO HACE INDIRECTAMENTE. COMO RESULTADO, LOS CAMBIOS PUEDEN CAUSAR CONFUSIN CUANDO EL EQUIPO DEL PROYECTO COMIENZA. A MENUDO ES DIFCIL QUE EL CLIENTE EXPONGA EXPLCITAMENTE 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 VERSIN 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 CLSICO TIENE UN LUGAR DEFINIDO E IMPORTANTE EN EL TRABAJO DE LA INGENIERA DEL SOFTWARE. PROPORCIONA UNA PLANTILLA EN LA QUE SE ENCUENTRAN MTODOS PARA ANLISIS, DISEO, CODIFICACIN, PRUEBAS Y MANTENIMIENTO. EL CICLO DE VIDA CLSICO SIGUE SIENDO EL MODELO DE PROCESO MS EXTENSAMENTE UTILIZADO POR LA INGENIERA DEL SOFTWARE. PESE A TENER DEBILIDADES, ES SIGNIFICATIVAMENTE MEJOR QUE UN ENFOQUE HECHO AL AZAR PARA EL DESARROLLO DEL SOFTWARE. BIBLIOGRAFA
13

LIBRO: FUNDAMENTOS DE INGENIERA DE SOFTWARE UN ENFOQUE PRACTICO AUTOR: ROGER S. PRESSMAN EDITORIAL: MCGRAW-HILL QUINTA EDICIN 1.3 ETAPAS DEL DESARROLLO DEL SOFTWARE 1.-ANALISIS: CONSTRUYE UN MODELO DE LOS REQUISITOS. 2.- DISEO: 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.- CODIFICACIN: CONSTRUYE EL SISTEMA. LA SALIDA DE ESTA FASE ES CDIGO EJECUTABLE. 4.- PRUEBAS: SE COMPRUEBA QUE SE CUMPLEN CRITERIOS DE CORRECCIN Y CALIDAD. 5.- MANTENIMIENTO: EN ESTA FASE QUE TIENE LUGAR DESPUS DE LA ENTREGA SE ASEGURA QUE EL SISTEMA SIGA FUNCIONANDO Y ADAPTNDOSE A NUEVOS REQUISITOS. LAS ETAPAS CONSTAN DE TAREAS. LA DOCUMENTACIN 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 SEGN SE MUESTRA EN LA FIGURA. MODELOS DEL CICLO DE VIDA DEL SOFTWARE CASCADA: PROPUESTO POR ROCE EN 1970, FUE ADAPTADO PARA EL SOFTWARE PARTIR DE CICLOS DE VIDA DE OTRAS RAMAS DE INGENIERA. EL PRIMERO DE LOS PROPUESTOS Y EL MS AMPLIAMENTE SEGUIDO POR LAS ORGANIZACIONES. MODELOS DEL CICLO DE LA VIDA DEL SOFTWARE ESPIRAL: 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 DISEO, ERRORES EN LA IMPLEMENTACIN, ETC.
14

UNA REPRESENTACIN TPICA DE ESTA ESTRUCTURA SE MUESTRA EN LA SIGUIENTE FIGURA: VENTAJAS: -NO NECESITA UNA DEFINICIN COMPLETA DE LOS REQUISITOS PARA EMPEZAR A FUNCIONAR. -AL ENTREGAR PRODUCTOS DESDE EL FINAL DE LA PRIMERA ITERACIN ES MS FCIL 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 DIFCIL EVALUAR RIESGOS. NECESITA DE LA PARTICIPACIN CONTINUA POR PARTE DEL CLIENTE, CUANDO SE SUBCONTRATA HAY QUE PRODUCIR PREVIAMENTE UNA ESPECIFICACIN COMPLEJA DE LO QUE SE NECESITA, Y ESTO LLEVA TIEMPO. MODELO BASADO EN PROTOTIPOS NO POSEE LA FUNCIONALIDAD TOTAL DEL SISTEMA PERO SI CONDENSA LA IDEA PRINCIPAL DEL MISMO. PASO A PASO CRECE SU FUNCIONALIDAD, ALTO GRADO DE PARTICIPACIN DEL USUARIO. VENTAJAS & DESVENTAJAS -EL CLIENTE PUEDE PENSAR QUE EL PROTOTIPO ES UNA VERSIN 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 PARTICIPACIN DEL USUARIO. APLICACIONES -SU UTILIZACIN SI EL MERCADO NO SE ENCUENTRA EL PRODUCTO PERO EL CLIENTE DESEA RESULTADOS INMEDIATOS. -CONVENIENTE EN CASO DE SER NECESARIO DESARROLLAR MDULOS. -PARA SISTEMAS INTERACTIVOS PEQUEA O DE TAMAO PEQUEO. -PARA PARTES DE SISTEMAS GRANDES EN VIDA CORTA.

15

1.4 CLASIFICACIN DE LA TECNOLOGA EN EL DESARROLLO DE SOFTWARE (TECNOLOGA ESTRUCTURADA Y ORIENTADA A OBJETOS) UN PROYECTO DE DESARROLLO DE UN SISTEMA INFORMTICO, COMO CUALQUIER PROYECTO DE INGENIERA, SE ESTRUCTURA EN UNA SERIE DE FASES PARA CONFIGURAR SU CICLO DE VIDA. EN EL CASO DE PROYECTO INFORMTICO, ESTAS FASES SE BASAN EN LAS ACTIVIDADES Y SEGN 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 MTODOS, 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 ANLISIS Y DISEO. EL OBJETIVO ES PERMITIR Y FACILITAR LA REUSABILIDAD, EL REFINAMIENTO, LA VERIFICACIN, EL MANTENIMIENTO Y LA EXTENSIN DEL SOFTWARE. PARA ELLO ES NECESARIO UN DISEO BASADO EN LOS PRINCIPIOS DE OCULTACIN DE INFORMACIN, CLASIFICACIN, GENERALIZACIN, PASO DE MENSAJES Y POLIMORFISMO QUE RIGEN ESTE PARADIGMA. SEGN EL OBJECT MALAJEMENTE GROUP, UN OBJETO ES UNA COSA. SE CREA LA INSTANCIA DE UN TIPO DE OBJETO. TAMBIN CADA OBJETO TIENE UNA IDENTIDAD NICA QUE ES DESTINADA E INDEPENDIENTE DE CUALQUIERA DE SUS CARACTERSTICAS Y OFRECE UNA O MS OPERACIONES. PARA OBTENER LOS OBJETOS EN EL MODELADO DE UN SISTEMA SOFTWARE SE APLICA UN MECANISMO DE ABSTRACCIN A LAS ENTIDADES DEL MUNDO REAL. ESTE MECANISMO EXTRAE LAS CARACTERSTICAS MS 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 ABSTRACCIN OBTIENE UN OBJETO EN EL MODELADO. EN CAMBIO, SI EL MECANISMO SE APLICA A UN CONJUNTO DE ENTIDADES AGRUPADAS POR DETERMINADAS CARACTERSTICAS COMUNES ENTONCES LA ABSTRACCIN OBTIENEN UNA CLASE DE OBJETOS EN EL MODELADO. ESTA CLASE DE OBJETOS JUSTAMENTE CONTIENE LOS ASPECTOS MS SIGNIFICATIVOS DE TODO EL CONJUNTO DE ENTIDADES Y ES UNO DE LOS RESULTADOS DEL ANLISIS DEL SISTEMA. POR LO CONTRARIO, CUANDO EXISTE UNA CLASE DE OBJETOS Y SE QUIERE PARTICULARIZAR ESTA CLASE MEDIANTE LA OBTENCIN DE UN EJEMPLAR DE LA MISMA, QUE REPRESENTA UNA DE LAS ENTIDADES DEL MUNDO REAL, SE EST APLICANDO EL MECANISMO DE INSTANCIACIN U OBTENCIN DE UN ESPCIMEN DE UNA CLASE DE OBJETOS, QUE ES PROPIAMENTE EL OBJETO DE DICHA CLASE. LAS PRIMERAS METODOLOGAS ORIENTADAS A OBJETOS QUE SURGIERON A PARTIR DE LAS METODOLOGAS ESTRUCTURADAS, CON LAS QUE HAN CONVIVIDO HASTA NO HACE MUCHO, PROPUGNABAN CICLOS DE VIDA CON ESTRUCTURA CLSICA PERO CON TCNICAS Y HERRAMIENTAS ORIENTADAS A OBJETOS. AS SURGIERON OS CONCEPTOS DE ANLISIS ORIENTADO A OBJETOS, DISEO ORIENTADO A OBJETOS, PROGRAMACIN ORIENTADA A OBJETOS, PRUEBAS ORIENTADAS A OBJETOS, ETC. SIN EMBARGO, ESTOS ENFOQUES NO DIERON RESULTADO PUESTO QUE LA METODOLOGA ORIENTADA A OBJETOS SUPONE UN CAMBIO DE ENFOQUE SUSTANCIAL RESPECTO A LAS TCNICAS TRADICIONALES. PRINCIPALMENTE REQUIERE UNA FORMA DIFERENTE DE PENSAR, DE DESARROLLAR Y DE COMUNICARSE ENTRE LAS DIVERSAS FASES DEL PROYECTO. TAMBIN EXIGAN LA APARICIN DE NUEVAS TCNICAS Y LENGUAJES DE MODELADO Y REPRESENTACIN DE LOS CONCEPTOS ASOCIADOS A LOS OBJETOS.

SEGN LOS NUEVOS ENFOQUES DE METODOLOGAS ORIENTADAS A OBJETOS, EL PROCESO DE DESARROLLO DE

17

SOFTWARE DEBE SER DE TIPO ITERATIVO. ESTE PROPONE UNA COMPRENSIN INCREMENTAL DEL PROBLEMA A TRAVS DE REFINAMIENTOS SUCESIVOS Y UN CRECIMIENTO INCREMENTAL DE UNA SOLUCIN EFECTIVA A TRAVS DE VARIOS CICLOS. COMO PARTE DEL ENFOQUE ITERATIVO, SE ENCUENTRA LA FLEXIBILIDAD PARA ACOMODARSE A NUEVOS REQUISITOS O A CAMBIOS TCTICOS EN LOS OBJETIVOS DEL NEGOCIO. TAMBIN PERMITE QUE EL PROYECTO IDENTIFIQUE Y RESUELVA LOS RIESGOS MS BIEN PRONTO QUE TARDE. BIBLIOGRAFA: INGENIERA DE PROYECTOS INFORMTICOS: ACTIVIDADES Y PROCEDIMIENTOS, ESCRITO POR JOS SALVADOR SNCHEZ GARRETA, PAGINAS 61-65. PARADIGMA ESTRUCTURADO ESTE MTODO ES UNA COLECCIN DE IDEAS SOBRE INGENIERA DEL SOFTWARE, DESARROLLADO DURANTE LOS LTIMOS VEINTE AOS POR AUTORES COMO E. YOURDON, T. DE MARCO, CONSTANTINE, J.D, WARNIER, Y OTROS. ESTAS IDEAS HAN SIDO RECOGIDAS BAJO EL NOMBRE DE TCNICAS ESTRUCTURADAS: PROGRAMACIN ESTRUCTURADA, DISEO ESTRUCTURADO Y ANLISIS ESTRUCTURADO. EL MTODO ESTRUCTURADO CONCIBE EL ANLISIS Y DISEO DEL SISTEMA EN BASE A LA CONSTRUCCIN DE MODELOS, CON EL FIN DE REPRESENTAR LAS FUNCIONES QUE REALIZA EL SISTEMA, DESDE SU CONCEPCIN FSICA HASTA LA DEDUCCIN LGICA DE SU INFORMACIN Y PROCESOS. TODO MODELO EST DETERMINADO POR TRES PARTES BIEN DIFERENCIADAS. LA REPRESENTACIN GRFICA LA CONSTITUYEN UN CONJUNTO DE DIAGRAMAS QUE PRESENTAN ESQUEMTICAMENTE LAS FUNCIONES Y FLUJOS DE INFORMACIN. LA DEFINICIN O DICCIONARIO DE DATOS RECOGE LA DESCRIPCIN DE CADA OBJETO REPRESENTADO EN LOS DIAGRAMAS, SU DEFINICIN Y COMPOSICIN. LA ESPECIFICACIN ES UNA DESCRIPCIN DETALLADA DE LAS FUNCIONES O PROCESOS MS PRXIMOS AL PROGRAMA O MODULO A CODIFICAR.
18

LA TCNICA ESTRUCTURADA SE BASA EN EL CONCEPTO TOPDOWN 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 DCADA DEL 70 LA PROGRAMACIN ESTRUCTURADA FUE CONSIDERADA COMO UN NUEVO PARADIGMA QUE CONTRIBUYO A MEJORAR LA CONSTRUCCIN, EL MANTENIMIENTO Y USO DE LAS HERRAMIENTAS DE SOFTWARE. PERO, A DIFERENCIA DE LAS TCNICAS Y MTODOS DE PROGRAMACIN 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 PROGRAMACIN ORIENTADA U OBJETOS EL TRATAMIENTO ES DIFERENTE, PUES EN CADA APLICACIN 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, SEGN LOS PROCEDIMIENTOS ASOCIADOS A CADA OBJETO. ESTE PARADIGMA DE LA PROGRAMACIN ORIENTADA A OBJETOS BUSCA DISMINUIR LA BRECHA ENTRE EL LENGUAJE DE LAS SOLUCIONES DE LA COMPUTACIN CON EL DEL PLANTEAMIENTO DE LOS PROBLEMAS. ELLO CON EL INTERS DE GENERAR ELEMENTOS DE SOFTWARE CON LAS CARACTERSTICAS DE REUTILIZACIN, CONSISTENCIA Y ROBUSTEZ, CUYA CONSTRUCCIN, MANTENIMIENTO Y REFINACIN SEAN MS FCILES, PARA AFRONTAR ADECUADAMENTE LOS PROBLEMAS EXISTENTES DESDE EL INICIO DEL DESARROLLO DEL SOFTWARE, LA FALTA DE PORTABILIDAD DEL CDIGO Y REUSABILIDAD, CDIGO DIFCIL DE MODIFICAR, CICLOS DE DESARROLLO LARGOS Y TCNICAS DE CODIFICACIN NO INTUITIVAS.

19

BIBLIOGRAFA: MTODO PARA LA SOLUCIN DE PROBLEMAS UTILIZANDO LA PROGRAMACIN ORIENTADA A OBJETOS, ESCRITO POR JUAN JOS FLORES CUETO, PAGINA 13. METODOLOGA DEL ANLISIS ESTRUCTURADO DE SISTEMAS, ESCRITO POR JESS BARRANCO DE AREBA, PAGINAS 59-60. 1.4 CLASIFICACIN DE LA TECNOLOGA EN EL DESARROLLO DEL SOFTWARE (TECNOLOGA ESTRUCTURADA Y ORIENTADA A OBJETOS. TECNOLOGA ESTRUCTURADA -ORIENTADA A PROCESOS ORIENTADA A DATOS- MIXTAS *JERRQUICOS * NO JERRQUICOS ANALISIS REQUISITOS: ESPECIFICACIONES, MODIFICACIONES, REDUNDANTES, AMBIGUAS, IMPOSIBLES DE MANTENER. ESPECIFICACIONES FUNCIONALES: GRAFICAS, PARTICIONADAS, MNIMAMENTE REDUNDANTES ORIENTADA A PROCESOS -DIAGRAMAS DE FLUJO DE DATOS -DICCIONARIO DE DATOS -ESPECIFICACIN DE PROCESOS FASES DEL ANALISIS ESTRUCTURADO MTODO DEL MARCO CONSTRUIR EL MODELO FSICO ACTUAL (DAD FSICO ACTUAL) CONSTRUIR EL MODELO LGICO ACTUAL (DAD LGICA ACTUAL) CREAR UN CONJUNTO DE MODELOS FSICOS ALTERNATIVOS ESTIMAR LOS COSTOS Y TIEMPOS DE CADA OPCIN SELECCIONAR UN MODELO EMPAQUETAR LA ESPECIFICACIN MTODO DE GANE & SARDN CONSTRUIR EL MODELO LGICO ACTUAL (DAD LGICO ACTUAL) CONSTRUIR EL MODELO DEL NUEVO SISTEMA: ELABORAR UNA ESPECIFICACIN ESTRUCTURADA Y CONSTRUIR UN MODELO LGICO DE DATOS EN TERCERA FORMAN NORMAL QUE EXPRESE EL CONTENIDO DE LOS ALMACENES DE DATOS. SELECCIONAR UN MODELO LGICO CREAR EL NUEVO MODELO FSICO DEL SISTEMA
20

EMPAQUETAR LA ESPECIFICACIN METODOLOGA DE YOURDON/CONSTANTINE -REALIZAR LOS DAD DEL SISTEMA -REALIZAR EL DIAGRAMA DE ESTRUCTURAS -EVALUAR EL DISEO -PREPARAR EL DISEO PARA LA IMPLEMENTACIN METODOLOGAS ORIENTADAS A DATOS JERRQUICOS -LA ESTRUCTURA DE CONTROL DEL PROGRAMA DEBE SER JERRQUICA Y SE DEBE DERIVAR DE LA ESTRUCTURA DE DATOS DEL PROGRAMA -EL PROCESO DE DISEO 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 DISEO LGICO DEBE PROCEDER Y ESTAR SEPARADO DEL DISEO FSICO METODOLOGAS ORIENTADAS A DATOS NO JERRQUICOS METODOLOGA INGENIERA DE LA INFORMACIN: PLANIFICACIN: CONSTRUIR UNA ARQUITECTURA DE LA INFORMACIN Y UNA ESTRATEGIA QUE SOPORTE LOS OBJETIVOS DE LA ORGANIZACIN. ANALISIS: COMPRENDER LAS REAS DEL NEGOCIO Y DETERMINAR LOS REQUISITOS DEL SISTEMA DISEO: ESTABLECER EL COMPORTAMIENTO DEL SISTEMA DESEADO POR EL USUARIO Y QUE SEA ALCANZABLE POR LA TECNOLOGA CONSTRUCCIN: CONSTRUIR SISTEMAS QUE CUMPLAN LOS TRES NIVELES ANTERIORES. DISEO ESTRUCTURADO: (FINALES DE AOS 70) -MAYOR NIVEL DE ABSTRACCIN (INDEPENDENCIA LENGUAJE DE PROGRAMA) -ELEMENTO BSICO DEL DISEO -MODULARIDAD. MEDIDAS DE CALIDAD DEL PROGRAMA METODOLOGAS ORIENTAS A OBJETOS -REVOLUCIONARIOS O PUROS -SINTETIZAS O EVOLUTIVOS
21

DEL

DESARROLLO ORIENTADO A OBJETOS -ESENCIA: IDENTIFICACIN Y ORGANIZACIN DE CONCEPTOS DEL DOMINIO DE LA APLICACIN Y NO TANTO DE SU REPRESENTACIN FINAL EN UN LENGUAJE DE PROGRAMACIN -AOS 80 -TRATA FUNCIONALIDAD Y DATOS DE FORMA CONJUNTA -PRINCIPIOS: -ABSTRACCIN -OCULTACIN DE INFORMACIN (ENCAPSULAMIENTO) -MODULARIDAD -LAS TCNICAS ESTRUCTURADAS HAN INFLUIDO EN ESTAS METODOLOGAS CAMBIAN LOS PRINCIPIOS DE LAS METODOLOGAS ESTRUCTURADAS ESTRUCTURADO: EXAMINAR EL SISTEMA EXAMINANDO EL DOMINIO DEL PROBLEMA COMO UN CONJUNTO DE OBJETOS QUE INTERACTAN ENTRE S. OBJETOS: ENCAPSULAN FUNCIONES + DATOS ENFOQUES: REVOLUCIONARIOS O PUROS: -LA DE SE ENTIENDE COMO UN CAMBIO PROFUNDO DE LAS METODOLOGAS ESTRUCTURADAS QUE SE VEN COMO OBSOLETAS. -ODD (BROOCH), CROC/RED (WIRES-BROCK) SINTETIZAS O EVOLUTIVOS: -ANALISIS Y DISEO ESTRUCTURADO SE CONSIDERA COMO LA BASE PARA DESARROLLO DE -INT, RAP CICLOS DE VIDA PARA OO. AGRUPAMIENTO: ADAPTA FILOSOFA DE PRODUCTO VS PROYECTO, CONJUNTO DE CLASES RELACIONADAS CON UN OBJETIVO COMN. CARACTERSTICAS: SUBIRLOS DE VIDA CON ESPECIFICACIN, DISEO, REALIZACIN, VALIDACIN, GENERALIZACIN. METER 1990 FUENTE:

22

REPRESENTA GRFICAMENTE. EL ALTO GRADO DE ITERACIN Y SOLAPAMIENTO DE LA ORO, APLICABLE A NIVEL DE CLASE INDIVIDUAL O AGRUPAMIENTOS HENDERSON SELLAR 1990. PINAL: REFLEJA EL PROCESO DEL DESARROLLO DE OO. DOS ESTILOS: SEGURO, TECNOLOGAS Y MTODOS PROBADOS; AL LIMITE: MAYOR RIESGO, MS VENTAJAS. AMBLAR 1994 REMOLINO: EN LA PRCTICA, EL DESARROLLO ES DESORDENADO E IMPLICA MLTIPLES ITERACIONES RELACIONADAS. DIMENSIONES DE ITERACIN: AMPLITUD-TAMAO DEL DESARROLLO, PROFUNDIDAD-NIVEL DE ABSTRACCIN A DETALLE. MADUREZ:- GRADO DE COMPLECIN, CORRECCIN Y ELEGANCIA. ALTERNATIVAS- DIFERENTES SOLUCIONES A UN PROBLEMA. ALCANCE- OBJETIVOS DEL SISTEMA (REQUISITOS) PROCESO, MULTICICLICO NO LINEAL CON FORMA DE REMOLINO. 1.5 DEFINICIN E HISTORIA DE LAS HERRAMIENTAS CASE CASE SIGNIFICA COMPUTER-AIDED SOFTWARE ENGINEERING. LAS HERRAMIENTAS CASE, APLICADAS AL DESARROLLO DE PROYECTOS INFORMTICOS, SON SISTEMAS INFORMTICOS DE AYUDA QUE POTENCIAN LA AUTOMATIZACIN DE LA PLANIFICACIN, ANLISIS Y DISEO Y GENERACIN DE SOFTWARE. SUS PRINCIPALES CARACTERSTICAS SON UTILIZAR EDICIONES Y REPRESENTACIONES GRFICAS, COMPROBAR LA CONSISTENCIA DEL TRABAJO (VER SI LAS ESTRUCTURAS DE DATOS ESTN COMPLETAMENTE ESPECIFICADAS, SI LOS INTERFACES DE MDULOS SON CORRECTOS, ETC.) Y GENERAR INTERFACES DE USUARIO. LAS HERRAMIENTAS CASE SON SOFTWARE DE APOYO AL DESARROLLO, MANTENIMIENTO Y DOCUMENTACIN INFORMATIZADOS DE SOFTWARE.

23

DE ESTA DEFINICIN 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 CLCULO, DE DIBUJO EN GENERAL, DE PLANIFICACIN DE PROYECTOS DE CUALQUIER INGENIERA), YA QUE PROPIAMENTE PERTENECEN A OTROS MBITOS; O BIEN SE UTILIZAN PARA CODIFICAR EL SOFTWARE (COMPILADORES, ENTORNOS DE CUARTA GENERACIN, EDITORES ORDINARIOS DE PROGRAMAS, ETC.), YA QUE SIEMPRE ESTN PRESENTES, INCLUSO EL DESARROLLO DE SOFTWARE SE HACE DE LA MANERA MS MANUAL POSIBLE. QUEDAN, PUES, PRINCIPALMENTE LAS HERRAMIENTAS QUE AYUDAN A APLICAR TCNICAS CONCRETAS DE DESARROLLO Y MANTENIMIENTO DE SOFTWARE Y POR ESO GESTIONAN INFORMACIN SOBRE LOS ELEMENTOS Y CONCEPTOS QUE SE UTILIZAN EN EL MTODO DE DESARROLLO, COMO LAS SIGUIENTES: LAS HERRAMIENTAS DIAGRAMTICAS, LAS CUALES, A DIFERENCIA DE LAS DE DIBUJO, RECONOCEN QUE UN DETERMINADO SMBOLO ES UNA CLASE Y NO SIMPLEMENTE UN RECTNGULO. ESTAS HERRAMIENTAS TAMBIN ACOSTUMBRAN A ACEPTAR DOCUMENTACIN TEXTUAL SOBRE AQUELLOS ELEMENTOS. LAS HERRAMIENTAS DE GESTIN DE LA PRUEBA Y DE GESTIN DE LA CALIDAD EN GENERAL. LAS HERRAMIENTAS DE GESTIN DE CAMBIOS, ETC. LA EXPANSIN DEL USO DE HERRAMIENTAS CASE EN EL MTODO ESTRUCTURADO SE FREN A CAUSA DE LA DIVERSIDAD Y DE LA FALTA DE ESTANDARIZACIN DE LAS TCNICAS QUE SE UTILIZAN; EN LOS MTODOS ORIENTADOS A OBJETOS, EN CAMBIO, ACTUALMENTE LA SITUACIN ES LA CONTRARIA: POR UN LADO, ALGUNOS DIAGRAMAS SIRVEN TANTO PARA EL ANLISIS COMO PARA EL DISEO, Y POR EL OTRO, SE HA PRODUCIDO UNA ESTANDARIZACIN DE LAS TCNICAS Y NOTACIONES EN EL MODELO CONOCIDO COMO UML QUE HA HECHO QUE EN EL POCO TIEMPO TRANSCURRIDO DESDE SU PUBLICACIN HAYA APARECIDO UN NMERO IMPORTANTE
24

DE CONJUNTOS INTEGRADOS DE HERRAMIENTAS CASE BASADAS EN L. DESDE PRINCIPIOS DE LA DCADA 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 MS EFICIENTE CON LOS USUARIOS E INTEGRAR EL TRABAJO QUE DESEMPEAN EN EL SISTEMA. RAZONES PARA EL USO DE LAS HERRAMIENTAS CASE AUMENTO EN LA PRODUCTIVIDAD DEL ANALISTA. MEJORA DE LA COMUNICACIN ANALISTA-USUARIO. INTEGRACIN 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 DOCUMENTACIN. LOS SETENTAS VIERON LA INTRODUCCIN DE TCNICAS GRFICAS Y DIAGRAMAS DE FLUJO DE ESTRUCTURAS DE DATOS. SOBRE ESTE PUNTO, EL DISEO Y ESPECIFICACIONES EN FORMA PICTRICA HAN SIDO EXTREMADAMENTE COMPLEJOS Y CONSUMAN MUCHO TIEMPO PARA REALIZAR CAMBIOS. LA INTRODUCCIN DE LAS HERRAMIENTAS CASE PARA AYUDAR EN ESTE PROCESO HA PERMITIDO QUE LOS DIAGRAMAS PUEDAN SER FCILMENTE CREADOR Y MODIFICADOS, MEJORANDO LA CALIDAD DE LOS DISEOS 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 DISEO DE FLUJO DE DATOS Y ANLISIS ESTRUCTURAL, HECHO POSIBLE A TRAVS 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 DIAGRAMACIN YA EXISTAN. 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 MTODOS FAVORABLEMENTE ESTRUCTURADOS PARA PLANEAMIENTO, ANLISIS Y DISEO. ESTO LLEVARA A LA GENERACIN AUTOMTICA DE CDIGO PARA DESARROLLO DE SOFTWARE VA UNA ESPECIFICACIN FORMALMENTE DISEADA. BIBLIOGRAFA: INSTITUTO NACIONAL DE ESTADSTICAS E INFORMTICA, PAGINAS 13-15. INFORMACIN TECNOLGICA, VOL. 8 N 6, 1997, PGINA 159. ANLISIS Y DISEO DE SISTEMAS, SEXTA EDICIN, KENNETH E. KENDALL, JULIE E. KENDALL, PAGINAS 14-16. 1.5 DEFINICIN E HISTORIA DE LAS HERRAMIENTAS CASE DEFINICIN: DE ACUERDO CON KENDALL EL DESARROLLO DE SISTEMA ES ASISTIDA POR ORDENADORES EN LA APLICACIN INFORMTICA, 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, TAMBIN SUELEN INCLUIR: -UN DIRECCIONADO PARA LOS DATOS DE LA APLICACIN DE BASE DE DATOS. -HERRAMIENTAS DE DISEO 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 LGICO.
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 PLANIFICACIN, ANALISIS Y DISEO DE SISTEMA. BAJO NIVEL: APOYA A LAS FASES INFERIORES DEL CICLO DE VIDA COMO EL DISEO DETALLADO, LA IMPLANTACIN, Y EL SOPORTE DE SISTEMAS. CRUZADO: HERRAMIENTAS QUE APOYAN ACTIVIDADES A LO LARGO DE TODO EL CICLO DE VIDA, INCLUYE ACTIVIDADES COMO LA GESTIN DE PROYECTOS Y LA ESTIMACIN. HISTORIA EN LA DCADA DE LOS 70 EL PROYECTO IDOS DESARROLLO UN LENGUAJE LLAMADO PROBLEMA STATEMENT LENGUAJE (PSL) PARA LA SOLUCIN DE UN PROBLEMA INFORMTICO 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 ACTUAL EN LAS LTIMAS DCADAS SE HA TRABAJADO EN EL DESARROLLO DE SISTEMAS PARA ENCONTRAR TCNICAS PARA INCREMENTAR LA PRODUCTIVIDAD Y CALIDAD EN EL PROCESO DE ELABORACIN DEL SOFTWARE, HOY LA HERRAMIENTA CASE HA REEMPLAZADO EL PAPEL Y LPIZ POR EL ORDENADOR PARA LA TRANSFORMACIN DEL DESARROLLO DE SOFTWARE EN UN PROCESO AUTOMATIZADO. LA TECNOLOGA CASE SUPONE LA AUTOMATIZACIN DEL DESARROLLO DE SOFTWARE PARA ELEVAR LA PRODUCTIVIDAD Y LA CALIDAD EN EL DESARROLLO DE SISTEMAS ANLOGAS A LO QUE SUPONEN LAS TCNICAS CADA/CAM EN ESTE ENFOQUE PERMITE MEJORAR LA CALIDAD DEL SOFTWARE. -LA MEJORA Y LA ESTANDARIZACIN DE LA DOCUMENTACIN - AUMENTAR LA PORTABILIDAD DE LAS APLICACIONES -FACILITAR LA REUTILIZACIN DE COMPONENTES DE SOFTWARE -PERMITIR UN DESARROLLO Y UN REFINAMIENTO DE LAS APLICACIONES, MEDIANTE LA UTILIZACIN DE CONTROLES GRFICOS.
27

1.6 CLASIFICACIN 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 PRECISIN CUALES SON LAS HERRAMIENTAS CASE DE ALTO NIVEL Y CUALES LAS DE BAJO NIVEL, PODRA 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 DISEADORES, EN TANTO QUE LAS DE BAJO NIVEL SON UTILIZADAS CON MS FRECUENCIA POR PROGRAMADORES Y TRABAJADORES QUE DEBEN IMPLEMENTAR LOS SISTEMAS DISEADOS CON HERRAMIENTAS CASE DE ALTO NIVEL. HERRAMIENTAS CASE DE ALTO NIVEL UNA HERRAMIENTA CASE DE ALTO NIVEL DA AL ANALISTA LA POSIBILIDAD DE CREAR Y MODIFICAR EL DISEO DEL SISTEMA. TODA LA INFORMACIN RELACIONAD CON EL PROYECTO SE ALMACENA EN UNA ENCICLOPEDIA DENOMINADA DEPOSITO CASE, UNA ENORME COLECCIN DE REGISTROS, ELEMENTOS, DIAGRAMAS, PANTALLAS, INFORMES E INFORMACIN DIVERSA. CON LA INFORMACIN DEL DEPSITO SE PODRAN GENERAR INFORMES QUE MUESTREN DONDE EST INCOMPLETO EL DISEO O DONDE CONTIENE ERRORES. LAS HERRAMIENTAS CASE DE ALTO NIVEL TAMBIN PUEDEN APOYAR LA MODELACIN DE LOS REQUERIMIENTOS FUNCIONALES DE UNA ORGANIZACIN, 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 ORGANIZACIN. ADEMS, ALGUNAS HERRAMIENTAS CASE DE ALTO NIVEL PUEDEN AYUDAR EN LA CREACIN DE PROTOTIPOS DE DISEOS DE PANTALLAS E INFORMES. HERRAMIENTAS CASE DE BAJO NIVEL LAS HERRAMIENTAS CASE DE BAJO NIVEL SE UTILIZAN PARA GENERAR CDIGO FUENTE DE COMPUTADORA, ELIMINADO AS LA NECESIDAD DE PROGRAMAR EL SISTEMA. LA GENERACIN DE CDIGO TIENE VARIAS VENTAJAS:
28

EL SISTEMA SE PUEDE GENERAR MS RPIDO QUE SI SE ESTUVIERA QUE ESCRIBIR TODOS LOS PROGRAMAS. NO OBSTANTE, CON FRECUENCIA EL PERIODO PARA FAMILIARIZARSE CON LA METODOLOGA UTILIZADA POR EL GENERADOR DE CDIGO ES MUY LARGO, POR LO QUE LA GENERACIN DEL PROGRAMA PODRA SER MS LENTA AL PRINCIPIO. LA GENERACIN DE CDIGO REDUCE EL TIEMPO INVERTIDO EN EL MANTENIMIENTO. NO HAY NECESIDAD DE MODIFICAR, PROBAR Y DEPURAR LOS PROGRAMAS DE COMPUTADORA. EN LUGAR DE ESO EL DISEO CASE SE VUELVE A GENERAR EL CDIGO. HERRAMIENTAS UPPERCASE Y LOWERCASE A VECES SE DISTINGUE ENTRE HERRAMIENTAS UPPERCASE, QUE SON LAS DE ANALISIS Y DISEO, Y LOWERCASE, QUE SE USAN DURANTE LA PROGRAMACIN Y LA PRUEBA. LA IMPORTANCIA DE LA INTEGRACIN DE LAS HERRAMIENTAS ES CONVENIENTE QUE LAS HERRAMIENTAS QUE DAN APOYO A DIFERENTES TCNICAS UTILIZADAS DENTRO DEL MISMO MTODO ESTN INTEGRADAS, EN EL SENTIDO DE QUE SI HAY UN TIPO DE ELEMENTO QUE ES COMN A DOS TCNICAS, SEA COMPARTIDO UNA VEZ Y QUE TODOS LOS CAMBIOS QUE SE REALICEN DESPUS EN ESTA DESCRIPCIN LLEGUEN A LAS DOS. LAS HERRAMIENTAS CASE PUEDEN CLASIFICARSE TAMBIN DE ACUERDO A: FUNCIONALIDAD: QUE FUNCIN PROPORCIONAN. PROCESO SOPORTADO: QUE ACTIVIDADES DEL PROCESO DE SOFTWARE SOPORTAN. LA EXTENSIN DEL SOPORTE QUE PROPORCIONAN. TODAS LAS CLASIFICACIONES PERMITEN QUE HERRAMIENTAS SEAN EVALUADAS Y COMPARADAS. LAS

CASE INTEGRADO MIENTRAS LAS HERRAMIENTAS CASE SON USADAS, MS PODER SE OBTIENE, SI LAS HERRAMIENTAS TRABAJAN CONJUNTAMENTE.
29

HERRAMIENTAS ESPECIALIZADAS PUEDEN COMBINARSE PARA PROPORCIONAR AMPLIO SOPORTE PARA LAS ACTIVIDADES DEL PROCESO. INTEGRACIN DEL DISEO Y DOCUMENTACIN DE LAS MESAS DE TRABAJO. INTEGRACIN DE ESPECIFICACIONES, DISEO Y PROGRAMACIN DE HERRAMIENTAS CON UNA CONFIGURACIN Y ADMINISTRACIN DE LAS MESAS DE TRABAJO. BIBLIOGRAFA: INGENIERA DE SOFTWARE, BENET CAMPDERRICH, PAGINA 31. ANLISIS Y DISEO DE SISTEMAS, SEXTA EDICIN, KENNETH E. KENDALL, JULIE E. KENDALL, PAGINAS 16-17. 1.6 CLASIFICACIN DE LAS HERRAMIENTAS CASE. LAS HERRAMIENTAS NO TIENEN UNA NICA CLASIFICACIN Y ES DIFCIL 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 FUNCIONABILIDAD LAS HERRAMIENTAS CASE EN FUNCIN DE LAS FASES DEL CICLO DE VIDA QUE ABARCAN, SE PUEDEN AGRUPAR DE LA FORMA SIGUIENTE: HERRAMIENTAS INTEGRADAS: I-CASE (INTGRATE 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 AUTOMATIZACIN Y SOPORTE DE LAS ACTIVIDADES DESARROLLADAS DURANTE LAS PRIMERAS FASES DEL DESARROLLO: ANALISIS Y DISEO. HERRAMIENTAS DE BAJO NIVEL: L CASE (CASE INFERIOR O BACK END) DIRIGIDAS A LAS LTIMAS FASES DEL DESARROLLO: DESARROLLO E IMPLANTACIN. JUEGOS DE HERRAMIENTA+ O TOOLKITS
30

SON EL TIPO MS SIMPLE DE LAS HERRAMIENTAS CASE, AUTOMATIZAN UNA FASE DENTRO DEL CICLO DE VIDA, DENTRO DE ESTE GRUPO SE ENCONTRARAN LAS HERRAMIENTAS DE REINGENIERA, ORIENTADAS A LAS FASES DE MANTENIMIENTO. CONCLUSIN COMO SE PUDO OBSERVAR EL DESARROLLO DEL SOFTWARE ES ALTAMENTE COMPLICADO, YA QUE ES MUY DIFCIL DE LOGRAR OBTENER UN SOFTWARE CONFIABLE, ES DECIR, QUE CUMPLA CON TODAS LAS EXPECTATIVAS QUE EL USUARIO REQUIERE, PARA ELLO EL DISEO, ANLISIS Y OTRAS ETAPAS SON SUMAMENTE IMPORTANTES, YA QUE NOS PERMITE EL MENOR MARGEN DE ERROR PARA LA SOLUCIN DEL PROBLEMA. COMO SE HA VISTO LAS HERRAMIENTAS CASE SON EL MEJOR MTODO PARA EL ANLISIS Y SOLUCIONES DE SOFTWARE, YA QUE HAN VENIDO A MEJORAR LOS ASPECTOS CLAVES EN EL DESARROLLO DE LOS SISTEMAS DE INFORMACIN, LAS CASE HAN SIDO CREADAS PARA LA AUTOMATIZACIN DE PROCESOS DE ANLISIS, DISEO E IMPLEMENTACIN, BRINDNDONOS UN SIN NMERO DE COMPONENTES QUE HACEN QUE LOS PROYECTOS SEAN CADA DA MS 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. ADEMS LAS HERRAMIENTAS CASE DEBEN BRINDAR LO SIGUIENTE PARA SER CONSIDERADAS BUENAS: TOPOLOGAS DE APLICACIN FLEXIBLES APLICACIONES PORTTILES CONTROL DE VERSIN CREAR CDIGO COMPILADO EN EL SERVIDOR DAR UN SOPORTE MULTIUSUARIO OFRECER SEGURIDAD

31

BIBLIOGRAFA GENERAL FUNDAMENTOS DE INGENIERA DE SOFTWARE UN ENFOQUE PRACTICO, ROGER S. PRESSMAN, MCGRAW-HILL, QUINTA EDICIN INGENIERA DE PROYECTOS INFORMTICOS: ACTIVIDADES Y PROCEDIMIENTOS, ESCRITO POR JOS SALVADOR SNCHEZ GARRETA, PAGINAS 61-65. MTODO PARA LA SOLUCIN DE PROBLEMAS UTILIZANDO LA PROGRAMACIN ORIENTADA A OBJETOS, ESCRITO POR JUAN JOS FLORES CUETO, PAGINA 13. METODOLOGA DEL ANLISIS ESTRUCTURADO DE SISTEMAS, ESCRITO POR JESS BARRANCO DE AREBA, PAGINAS 59-60. INSTITUTO NACIONAL DE ESTADSTICAS E INFORMTICA, PAGINAS 13-15. INFORMACIN TECNOLGICA, VOL. 8 N 6, 1997, PGINA 159. ANLISIS Y DISEO DE SISTEMAS, SEXTA EDICIN, KENNETH E. KENDALL, JULIE E. KENDALL, PAGINAS 14-16. INGENIERA DE SOFTWARE, BENET CAMPDERRICH, PAGINA 31. ANLISIS Y DISEO DE SISTEMAS, SEXTA EDICIN, KENNETH E. KENDALL, JULIE E. KENDALL, PAGINAS 16-17.

32