Tecn. de Analisis de Diseno. de Software PDF

INSTITUTO TECNOLÓGICO SUPERIOR
“DAVID AUSUBEL”
SEMIPRESENCIAL
VICERRECTORADO ACADÉMICO
GUÍA DE ESTUDIO MODULAR
TÉCNICA DE ANÁLISIS DE
DISEÑO DE SOFTWARE
CUARTO NIVEL
TECNOLOGÍA EN:
INFORMÁTICA MENCIÓN: ANÁLISIS DE

SISTEMAS
AUTOR: ING. MARCO MOLINA ÁLVAREZ
Corrección: Comisión de Redacción
Aprobado: Vicerrectorado Académico
Edición: Instituto Superior Tecnológico “David Ausubel”
PERÍODO: Octubre 2015 – abril 2016
QUITO - ECUADOR
“DAVID AUSUBEL”
SEMIPRESENCIAL
PARA USTED APRECIADO ESTUDIANTE
NO OLVIDE QUE EL ESFUERZO Y LA PERSEVERANCIA MÁS EL ESTUDIAR

Y TRABAJAR ENGRANDECE AL SER HUMANO. Y USTED DEPENDE EL
ENGRANDECERSE
El Instituto Tecnológico Superior “David Ausubel”, da la bienvenida a este

su módulo de Técnicas de Análisis de Diseño de Software y espera que el
desarrollo del mismo aporte para su vida profesional.
“DAVID AUSUBEL”
SEMIPRESENCIAL
NOTA:
EN ESTE TEXTO GUIA SE ENCUENTRAN DESARROLLADOS LOS TEMAS QUE

CORRESPONDEN A ESTE MÓDULO, Y LAS TAREAS QUE USTED DEBE DESARROLLAR; Y
CON LA AYUDA DEL TUTOR USTED LLEGARÁ A DOMINAR EL CONOCIMIENTO.
1. EL ESTUDIANTE TIENE LAS OPORTUNIDADES QUE SEAN NECESARIAS PARA

ACLARAR LOS TEMAS QUE NO COMPRENDA MEDIANTE LA EXPLICACIÓN DEL
TUTOR YA SEA DE MANERA PRESENCIAL O MEDIANTE EL CORREO ELECTRONICO.
2. LAS TAREAS SERAN ENVIADAS POR EL TUTOR, DE ACUERDO A LAS FECHAS DEL
CALENDARIO Y DE ACUERDO AL DESARROLLO DEL MÓDULO.
3. ES OBLIGACION DEL ESTUDIANTE ASISTIR A CADA UNA DE LAS TUTORÍAS

PRESENCIALES PROGRAMADAS EN EL CALENDARIO DE ACTIVIDADES.
4. TODO TRABAJO DEL ESTUDIANTE SERÁ EVALUADO CUANTITATIVAMENTE.
5. AL FINAL EL TUTOR EVALUARA EL MÓDULO EN SU TOTALIDAD.
6. DE REQUERIR CUALQUIER INFORMACION DIRIGIRSE AL CORREO DE LA

DIRECCION ACADEMICA Y SERA ATENDIDO INMEDIATAMENTE EN SU CONSULTA.
Docente: Geovanny Paucar gio_wpg@hotmail.com
Vicerrectoradoacademico@davidausubel.edu.ec
Gracias por su confianza.

“DAVID AUSUBEL”
SEMIPRESENCIAL
1. PERFIL DE INFORMÁTICA MENCIÓN ANÁLISIS DE SISTEMAS
a) OBJETIVO DE FORMACIÓN INTEGRAL DEL PROFESIONAL

Demostrar en el desempeño profesional de la informática un comportamiento ético que se
evidencie en el interés por la investigación e innovación tecnológica, con responsabilidad social,
espíritu empresarial y compromiso con el desarrollo sostenido y sustentable del país.
b) PERFIL DEL TECNÓLOGO EN INFORMÁTICA
Es un profesional capaz de usar herramientas y técnicas para recolectar datos, analizar,
diseñar, desarrollar e implementar nuevos sistemas que permitan automatizar los
procedimientos de las empresas con fundamentos científicos, tecnológicos, humanísticos
y de gestión, demostrando sólidos valores ético-morales.
c) COMPETENCIAS PRINCIPALES POR DESARROLLAR

 Conducir el ciclo de vida de un sistema de información que permita automatizar el
manejo de los datos mediante un sistema de computadora, utilizando para ello las
diferentes herramientas informáticas existentes en el medio actual.
 Fundamentar cambios en la estructura organizacional, procedimientos, políticas y
funciones de una entidad que permitan optimizar el flujo de datos e información,
aumentando con ello la productividad y competitividad y disminuyendo los costos
operativos.
 Administrar las acciones para realizar un correcto análisis, diseño, desarrollo y
documentación de los sistemas informáticos de un centro de cómputo, que cubran
las expectativas de la institución y del medio en que se desenvuelve.
 Evaluar y seleccionar hardware y software, fundamentado en cuadros
comparativos técnicos que permitan satisfacer los requerimientos de las empresas
y organizaciones en general.
 Analizar de manera independiente e imparcial las bondades o defectos de un
sistema de información, mediante la valoración de todos los procesos que
intervienen, tomando en cuenta las necesidades y el presupuesto económico.
 Apoyar la toma de decisiones de la gerencia utilizando métodos matemáticos,
estadísticos, modelos de transporte y de investigación de operaciones.
“DAVID AUSUBEL”
SEMIPRESENCIAL
SISTEMATIZACIÓN DE LAS COMPETENCIAS POR NIVELES
d) NIVEL COMPETENCIA PRINCIPAL

 Instalar, operar y administrar programas utilitarios conociendo todos los principios
de la informática.
 Programar en lenguajes de tercera generación aplicando técnicas especializadas y
con pleno conocimiento de sistemas matemáticos y contables
 Conocer las acciones requeridas hacia la automatización de las empresas
mediante el análisis, diseño, desarrollo, documentación e implementación de los
sistemas.
 Diseñar y administrar Bases de datos, dominando la programación en
herramientas de cuarta generación y la programación orientada a objetos.
 Participar en el diseño de sistemas informáticos interactuando con plataformas de
internet y con pleno conocimiento de la administración de las redes y sus sistemas
operativos.
 Administrar las actividades de un departamento de cómputo con la aplicación de
herramientas informáticas y gerenciales incluyendo la creación de su propia
microempresa.
e) ESCENARIOS DE ACTUACIÓN
El Tecnólogo en Informática podrá desempeñarse en todo tipo de empresa pública o
Privada donde se requiera tratar de una manera especial a los datos y la información que
Se generan dentro de la entidad, sea por procesos o por transacciones:
 ·Instituciones Bancarias
 Entidades Financieras
 Empresas Comerciales
 Empresas del estado
 Entes de servicio a la comunidad
 Instituciones de capacitación a nivel profesional, universitario o intermedio
“DAVID AUSUBEL”
SEMIPRESENCIAL
 Empresas de Asesoría Informática
f) OCUPACIONES PROFESIONALES
El Tecnólogo en Informática podrá desempeñarse como:
 Gerente de Sistemas
 Programador de computadoras
 Director de grupos de trabajo
 Administrador de Centros de Cómputo
 Asistente de gerencia
 Administrador de Bases de Datos
 Instructor de personal en el área informática
 Asesor organizacional de las empresas
 Asesor en el área informática
“DAVID AUSUBEL”
SEMIPRESENCIAL
DESCRIPCIÓN DE LA MATERIA
En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver

los problemas.
La Ingeniería de Software es un enfoque sistemático del desarrollo, operación,
mantenimiento y retiro del software. Se considera que la Ingeniería de software es la rama
de la Ingeniería que aplica os principios de la ciencia de la computación y la matemática
para lograr soluciones costo-efectivas a los problemas de desarrollo de software.
Un sistema debe estar basado en un ciclo de vida del software que comprende cuatro
grandes fases estudiadas en el contenido.
Se estudiará las fases del análisis con sus respectivas actividades poniendo énfasis en la
metodología orientada a objetos.
OBJETIVO GENERAL
Conocer las actividades a realizar dentro de las fases de análisis y conceptos básicos de
diseño en el desarrollo de software.
GENERALIDADES
CONCEPTOS
Metodología
Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a
los desarrolladores a realizar nuevo software.
Tarea
Actividades elementales en que se dividen los procesos.
Procedimiento
Definición de la forma de ejecutar la tarea.
Técnica
Herramienta utilizada para aplicar un procedimiento. Se pueden utilizar una o varias.
Herramienta
Para realizar una técnica, podemos apoyarnos en las herramientas software que
automatizan su aplicación.
Producto
Resultado de cada etapa
“DAVID AUSUBEL”
SEMIPRESENCIAL
CONTENIDO
CAPITULO I
1. HISTORIA DEL SOFTWARE

1.1 LA IMPORTANCIA DEL SOFTWARE
1.1.1 EL SOFTWARE
1.1.2 CARACTERISTICAS DEL SOFTWARE
1.1.3 COMPONENTES DEL S0FWARE
1.1.4 APLICACIONES DEL SOFTWARE
1.1.4.1 SOFTWARE DE SISTEMAS
1.1.4.2 SOFTWARE DE TIEMPO REAL
1.1.4.3 SOFTWARE DE GESTIÓN
1.1.4.4 SOFTWARE EMPOTRADO
1.1.4.5 SOFTWARE DE INTELIGENCIA ARTIFICIAL
1.2 MITOS
1.3 PARADIGMAS DE LA INGENIERIA DE SOFTWARE
1.4 INGENIERIA DE SOFTWARE
CAPITULO II
2. CICLOS DE VIDA
2.1 EL CICLO DE VIDA CLÁSICO SEGÚN PROGER
2.2 PLANIFICACIÓN DEL SISTEMA
2.3 MODELO DEL COSTO DE UN PROYECTO
2.3.1 MODELO DE PROTOTIPO PARA EL CICLO DE VIDA
2.4 FACTORES DE CALIDAD
2.5 MEDICIÓN DE SOFTWARE
2.6 INGENIERÍA DE SOFTWARE
CAPITULO III
3. INGENIERIA DE SOFTWARE
3.1 SISTEMAS BASADOS EN COMPUTADORAS
3.2 LA JERARQUUÍA DE LA INGENIERIA DE SISTEMAS DE COMPUTADORAS
3.3 MODELO DE SISTEMAS
3.4 INGENIERIA DE INFORMACIÓN
3.5 INGENIERIA DE PRODUCTOS
3.6 PLANIFICACIÓN DE LA ESTRATEGÍA DE LA INFORMACIÓN
3.6.1 MODELADO DE LA EMPRESA
3.6.2 MODELADO DE DATOS A NIVEL DE NEGOCIO
3.6.3 ANALISIS DEL AREA DE NEGOCIO
3.6.4 MODELADO DEL PROCESO
“DAVID AUSUBEL”
SEMIPRESENCIAL
3.6.5 MODELADO DE FLUJO DE INFORMACIÓN

3.6.6 INGENIERÍA DE PRODUCTOS
CAPITULO IV
4. IDENTIFICADORES DE NECESIDADES
4.1 ESTUDIO DE LA VARIABLE
4.1.1 ANÁLISIS ECONÓMICO
4.1.2 ANÁLISIS TECNICO
4.2 MODELADO DE LA ARQUITECTURA DEL SISTEMA
4.3 MODELADO Y SIMULACIÓN DEL SISTEMA
4.4 ESPECIFICACIÓN DEL SISTEMA
4.5 TECNICAS ORIENTADAS A OBJETOS
4.6 CARACTERÍSTICAS
CAPITULO V
5. METODOLOGÍAS DE DESARRROLLO DE SOFTWAR
5.1 METODOLOGÍA Vs CICLO DE VIDA
5.1.1 GENERACIÓN DE METODOLOGÍA
5.1.2 DESARROLLO CONVENCIONAL
5.1.3 DESARROLLO ESTRUCTURADO
5.1.4 DESARROLLO ORIENTADO A OBJETOS
5.2 METODOLOGÍAS ORIENTADAS A OBJETOS
5.2.1 CLASIFICACIÓN DE LAS METODOLOGÍAS
5.2.2 METODOLOGÍAS ESTRUCTURADAS
5.2.3 METODOLOGÍA YOURDON/CONSTANTE
5.2.4 METODOLOGÍA ORIENTADA A DATOS JERÁRQUICOS / NO JERÁRQUICOS
5.3 CICLO DE VIDA DEL SISTEMA ORIENTADO A OBJETOS
5.3.1 ESTUDIO PREMILINAR
5.3.2 ANÁLISIS ORIENTADOS A OBJETOS
5.3.3 DISEÑO ORIENTADOS A OBJETOS
5.3.4 CONTRUCCIÓN ORIENTADA A OBJETOS
5.3.5 IMPLEMENTACIÓN
5.4 OBJETO
5.4.1 CLASIFICACIÓN DEL OBJETO
5.4.2 ANÁLISIS ORIENTADO A OBJETOS
5.4.3 OBJETIVO DEL ANÁLISIS
5.4.4 ANÁLISIS DE OBJETOS
5.5 EJERCICIOS
“DAVID AUSUBEL”
SEMIPRESENCIAL
DESARROLLO DEL CONTENIDO
CAPITULO I
1. HISTORIA DEL SOFTWARE
Durante las tres primeras décadas de la Informática, el principal desafío era el desarrollo
del hardware de las computadoras, de forma que se redujera el costo de procesamiento y
almacenamiento de datos.
La necesidad de enfoques sistemáticos para el desarrollo y mantenimiento de productos

de software se patentizó en la década de 1960. En ésta década aparecieron las
computadoras de la tercera generación y se desarrollaron técnicas de programación como
la multiprogramación y el tiempo compartido. Y mientras las computadoras estaban
haciéndose más complejas, resultó obvio que la demanda por los productos de software
creció en mayor cantidad que la capacidad de producir y mantener dicho software. Estas
nuevas capacidades aportaron la tecnología necesaria para el establecimiento de
sistemas computacionales interactivos, de multiusuario, en línea y en tiempo real;
surgiendo nuevas aplicaciones para la computación, como las reservaciones aéreas,
bancos de información médica, etc.
Fue hasta el año 1968 que se convocó una reunión en Garmisch, Alemania Oriental
estimulándose el interés hacia los aspectos técnicos y administrativos utilizados en el
desarrollo y mantenimiento de software, y fue entonces donde se utilizó el término
"Ingeniería de Software".
A lo largo de la década de los ochenta, los avances en microelectrónica han dado como
resultado una mayor potencia de cálculo a la vez que una reducción de costo. Hoy el
problema es diferente. El principal desafío es mejorar la calidad y reducir el costo.
1.1 LA IMPORTANCIA DEL SOFTWARE
Durante las tres primeras décadas de la informática, el principal desafío era el desarrollo
del hardware de computadoras, de forma que se redujera el costo del procesamiento y
almacenamiento de datos. A lo largo de las décadas de los ochenta, los avances en
microelectrónica han dado como resultado una mayor potencia de cálculo a la vez que
una reducción del costo. Hoy, el problema es diferente. El principal desafío es mejorar la
calidad (y reducir el costo) de las soluciones basadas en computadoras – soluciones que
se implementan con el software.
La potencia de las grandes computadoras de la era de los ochenta esta hoy disponible en
una computadora personal. Las enormes capacidades de procesamiento y el
almacenamiento de hardware moderno representan una gran potencia de cálculo. El
software es el mecanismo que nos facilita utilizar y explotar este potencial.
1.1.1 EL SOFTWARE
“DAVID AUSUBEL”
SEMIPRESENCIAL
Hace veinte años menos del 1 por 100 de la gente podría describir de forma inteligente lo
que significaba el “software de computadora”. Hoy, la mayoría de los profesionales y
muchas personas en general creen que entienden el software. Una descripción del
software de un libro de texto puede tener la siguiente forma:
“Instrucciones (programas de computadora) que cuando se ejecutan proporcionan la

función y el comportamiento deseado”.
“Estructuras de datos que facilitan a los programas manipular los datos adecuadamente
la información”.
“Documentos que describen la operación y el uso de los programas”.
1.1.2 CARACTERÍSTICAS DEL SOFTWARE
Para poder comprender lo que el software (y consecuentemente la ingeniería del

software), es importante examinar las características del software que lo diferencian de
otras cosas que los hombres pueden construir. Cuando se construye hardware, el proceso
creativo humano (análisis, diseño, construcción y prueba) se traduce finalmente de una
forma física. Si construimos una nueva computadora, nuestro boceto inicial, diagramas
formales de diseño y prototipo de prueba, evolucionan hacia un producto físico (pastillas
de VLSI, tarjetas de circuitos impresos, fuentes de potencia, entre otros).
El software es un elemento del sistema que es lógico, en lugar de físico. Por tanto, el
software tiene unas características distintas a las del hardware:
El software se desarrolla, no se fabrica en un sentido clásico.

Aunque existen algunas similitudes entre le desarrollo del software y la construcción del
hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la
buena calidad se adquiere mediante un buen diseño, pero la fase de construcción del
hardware puede introducir problemas de calidad que no existen en el software. Ambas
actividades dependen de las personas, pero la relación entre la gente dedicada y el
trabajo realizado es completamente diferente para el software. Ambas actividades
requieren la construcción de un producto, pero los métodos son diferentes.
Los costos del software se encuentran en la ingeniería. Esto significa que los proyectos no
se pueden gestionar como si fueran proyectos de fabricación y esto es bien importante
para el manejo de los sistemas de información.
El software no se “estropea”.
El software no es susceptible a los males del entorno que hacen que el hardware se
estropee. Los defectos no detectados harán que falle el programa durante las primeras
etapas de su vida. Sin embargo, una vez que se corrigen, suponiendo que no introducen
nuevos errores, el software no se estropea !Pero se deteriora! Durante su vida, el software
“DAVID AUSUBEL”
SEMIPRESENCIAL
sufre cambios (mantenimiento). Conforme se hacen los cambios, es bastante probable

que se introduzcan nuevos defectos.
Lentamente, el nivel mínimo de fallos comienza a crecer; el software se va deteriorando
debido a los cambios. Este aspecto de mantenimiento del software, es de suma
importancia para el buen manejo de los sistemas de información que fluyen dentro de una
empresa.
La mayoría del software se construye a medida, en vez de ensamblar componentes

existentes.
Se puede comprar software ya desarrollado, pero solo con una unidad completa, no como
componentes que pueden reensamblarse en nuevos programas.
1.1.3 COMPONENTES DEL SOFTWARE
El software de computadora es información que existe en dos formas básicas:

componentes no ejecutables en la maquina y componentes ejecutable en las maquinas.
Los componentes de software se crean mediante una serie de traducciones que hacen
corresponder los requisitos del cliente con un código ejecutable en la maquina. Se traduce
un modelo (prototipo) de requisitos a un diseño. Se traduce el diseño del software a una
forma en un lenguaje que especifica las estructuras de datos, los atributos procedí
mentales y los requisitos que atañen al software. La forma en lenguaje es procesada por
un traductor que la convierte en instrucciones ejecutables a la maquina.
La habilidad de poder volver a usarse es una característica importante para un

componente de software de alta calidad. Es decir, el componente debe diseñarse e
implementarse para que pueda volver a usarse en muchos programas diferentes.
Los componentes de software se construyen mediante un lenguaje de programación que

tiene un vocabulario limitado, una gramática definida explícitamente y reglas bien
formadas de sintaxis y semántica. Estos atributos son esenciales para la traducción por la
maquina. Las clases de lenguaje que se utilizan actualmente son lenguajes de maquina,
los lenguajes de alto nivel y los lenguajes no procedí mentales.
Los lenguajes maquina son una representación sim del conjunto de instrucciones de la
CPU.
Los lenguajes de alto nivel permiten al programador y al programa independizarse de la

maquina. Cuando se utiliza un traductor sofisticado, el vocabulario, la gramática, la
sintaxis y la semántica de un lenguaje de alto nivel pueden ser mucho más sofisticados
que los lenguajes maquinan.
Los lenguajes de programación modernos (lenguajes que soportan directamente las

prácticas modernas para el diseño procide mental y datos) tales como Pascal, C y Ada se
utilizan ampliamente. Los lenguajes orientados a los objetos como c+++, Object Pascal,
Eiffel y otros, están ganando cada vez más seguidores entusiastas.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Los lenguajes especializados (diseñados para ámbitos de aplicación específicos), como

APL, LIPS, OPS5 y lenguajes descriptivos para redes neutrales artificiales, están teniendo
cada vez mayor aceptación conforme las nuevas aplicaciones pasan de los laboratorios a
la práctica.
1.1.4 APLICACIONES DEL SOFTWARE
El software puede aplicarse en cualquier situación en la que se haya definido previamente

un conjunto especifico de pasos procedí mentales(es decir un algoritmo). Para determinar
la naturaleza de una aplicación de software, hay dos factores importantes que se deben
considerar: El contenido y el determinismo de la información. El contenido se refiere al
significado y a la forma de la información de entrada y de salida. Por ejemplo, muchas
aplicaciones bancarias usan unos datos de entrada muy estructurados (una base de
datos) y producen informes con
Determinados formatos. El software que controla una maquina automática (por ejemplo,
un control numérico) actúa sobre elementos de datos discretos con una estructura
limitada y produce ordenes concretas para la maquina de rápida sucesión.
El determinismo de la información se refiere a la predecibilidad del orden y del tiempo de

llegada de los datos. Un programa de ingeniería acepta datos que están en un orden
predefinido, ejecuta el algoritmo sin interrupción y produce los datos resultantes en un
informe o formatos grafico.
Algunas veces es difícil establecer categorías genéricas para las aplicaciones del software
que sean significativas. Conforme aumenta la complejidad del software, es más difícil
establecer compartimientos nítidamente separados. Las siguientes áreas del software
indican la amplitud de las posibilidades de aplicación.
1.1.4.1 SOFTWARE DE SISTEMAS.
Es software de sistemas es un conjunto de programas que han sido escritos para servir a
otros programas. Algunos programas de sistemas (p. Ej.: compiladores, editores y
utilidades de gestión de archivos) procesan estructuras de información complejas pero
determinadas. En cualquier caso, el área del software de sistemas se caracteriza por una
fuerte interacción del hardware de la computadora; una gran utilización por múltiples
usuarios; una operación concurrente que requiere una planificación, una compartición de
recursos y una sofisticada gestión de procesos; unas estructuras de datos complejos y
múltiples interfaces externas.
1.1.4.2 SOFTWARE DE TIEMPO REAL.
El software que mide/analiza/controla sucesos del mundo real conforme ocurren, se

denominan de tiempo real. Entre los elementos del software de tiempo real se incluyen:
un componente de adquisición de datos que recolecta y da formato a ala información
“DAVID AUSUBEL”
SEMIPRESENCIAL
recibida del entorno externo, un componente de análisis que transforma la información

según lo requiera la aplicación, un componente de control / salida que responda al
entorno externo y un componente de monitorización que coordina todos los demás
componentes, de forma que puede mantenerse la respuesta en tiempo real.
1.1.4.3 SOFTWARE DE GESTIÓN.
El procesamiento de información comercial constituye la mayor delas áreas de aplicación

del software. Los “sistemas discretos” (por ejemplo: Nominas, cuentas de
haberes/debitos, inventarios etc. que proporcionan información básica a la organización)
han evolucionado hacia el software de sistemas de información de gestión (SIG), que
accede a una o más bases de datos grandes que contienen información comercial. Las
aplicaciones en esta área reestructuran los datos existentes en orden a facilitarlas
operaciones comerciales o gestionar las tomas de decisiones. Además de las tareas
convencionales de procesamientos de datos, las aplicaciones de software de gestión
también realizan cálculo interactivo (por ejemplo: el procesamiento de transacciones en
puntos de ventas).
1.1.4.4 SOFTWARE EMPOTRADO
El software empotrado reside en memoria de solo lectura y se utiliza para controlar

productos y sistemas de los mercados industriales y de consumo. El software empotrado
puede ejecutar funciones muy limitadas y curiosas (por ejemplo: el control de las teclas de
un horno de microonda) o suministrar una función significativa y con capacidad de control
(por ejemplo: Funciones digitales en un automóvil, tales como control de gasolina,
indicaciones en el salpicadero, sistemas de frenado, etc.).
1.1.4.5 SOFTWARE DE INTELIGENCIA ARTIFICIAL.
El software de inteligencia artificial hace uso de algoritmos no numéricos para resolver

problemas complejos para los que no es adecuado él cálculo o el análisis directo.
Actualmente, el área más activa de la IA es la de los sistemas experto, también llamados
sistemas basados en el conocimiento.
1.2 MITOS
Muchas de las causas de la crisis del software se pueden encontrar en una mitología que
surge durante los primeros años del desarrollo del software. Hoy la mayoría de los
profesionales competentes consideran a los mitos como actitudes erróneas que han
causado serios problemas, siendo éstos hábitos difíciles de modificar.
Examinemos algunos de ellos:
Mitos de Gestión
Mitos del Cliente
Mitos de los Desarrolladores
“DAVID AUSUBEL”
SEMIPRESENCIAL
Mitos de Gestión
Mito.
Tenemos ya un libro que está lleno de estándares y procedimientos para construir
software. ¿No le proporciona ya a mi gente todo lo que necesita saber?
Realidad.
Está muy bien que el libro exista, pero ¿Se usa? ¿Conocen los trabajadores su
existencia? ¿Refleja las prácticas modernas de desarrollo de software? ¿Es completo? En
muchos casos, la respuesta a todas estas preguntas es "no"?.
Mito.
Nuestra gente dispone de las herramientas de desarrollo de software más avanzadas;
después de todo, les compramos las computadoras más nuevas.
Realidad.
Se necesita mucho más que el último modelo de computadora grande (o de PC) para
hacer desarrollo de software de gran calidad. Las herramientas de ingeniería del software
asistida por computadora (CASE), aunque no se usen la mayoría, son más importantes
que el hardware para conseguir buena calidad y productividad.
Mito.
Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo
perdido.
Realidad.
El desarrollo de software no es un proceso mecánico como la fabricación. Brooks dice:
"Añadir gente a un proyecto de software retrasado lo retrasa aún más". Ya que cuando se
añaden nuevas personas, la necesidad de aprender y comunicarse con el equipo puede y
hace que se reduzca la cantidad de tiempo gastado en el desarrollo productivo. Puede
añadirse gente, pero de una manera planificada y bien coordinada.
Mitos del Cliente

Mito.
Una declaración general de los objetivos es suficiente para comenzar a escribir los
programas. (Podemos detallar más adelante).
Realidad.
Una mala definición inicial es la causa principal del trabajo baldío en software. Es esencial
una descripción formal y detallada del ámbito de la información, funciones, rendimiento,
etc. Y todas éstas características sólo se pueden determinar después de una exhaustiva
comunicación entre cliente y analista.
Mito.
Los requisitos del proyecto cambian continuamente, pero los cambios pueden
acomodarse fácilmente, ya que el software es flexible.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Realidad.
Es verdad que los requisitos del software cambian pero el impacto del cambio varía según
el momento en que se introduzca. Entre más temprano se realicen mejor.
Mitos de los Desarrolladores.

Mito.
Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha
terminado.
Realidad.
Alguien dijo una vez: "Cuando más pronto se comience a escribir código, más se tardará
en terminarlo". Datos industriales indican que entre el 50 y el 70 por ciento de todo el
esfuerzo dedicado a un programa se realizará después de que se le haya entregado al
cliente por primera vez.
Mito.
Hasta que no tengo el programa “ejecutándose” realmente no tengo forma de comprobar
su calidad.
Realidad.
Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos
para garantizar la calidad del software (Revisión de técnica formal). La revisión del
Software es un "filtro de calidad" que se ha comprobado que es más efectivo que la
prueba, para encontrar ciertas clases de defectos en el software.
Mito.
Lo único que se entrega al terminar el programa funcionando.
Realidad.
Un programa que funciona es sólo una parte de una configuración del software que
incluye todos los elementos tales como el Análisis, Diseño, Documentación del sistema,
etc.
1.3 PARADIGMAS DE LA INGENIERIA DE SOFTWARE
El mal que ha afectado el desarrollo del software no va a desaparecer de la noche a la

mañana. No existe un único enfoque mejor para solucionar el mal del software. Sin
embargo mediante la combinación de métodos completos para todas las fases del
desarrollo del software, mejores herramientas para automatizar estos métodos, bloques
de construcción más potentes para la implementación del software, mejores técnicas para
la garantía de calidad del software y una filosofía predominante para la coordinación,
control y gestión, podemos conseguir una disciplina para el desarrollo del software.
1.4 INGENIERIA DE SOFTWARE

“DAVID AUSUBEL”
SEMIPRESENCIAL
Una de las primeras definiciones de ingeniería del software fue la propuesta por Fritz
Bauer en la primera conferencia importante [NAU 69] dedicada al tema:
El establecimiento y uso de principios de ingeniería robustos, orientados a obtener

software económico que sea fiable y funcione de manera eficiente sobre máquinas reales.
Aunque se han propuesto muchas más definiciones generales, todas refuerzan la

importancia de una disciplina de ingeniería para el desarrollo del software.
La ingeniería del software surge de la ingeniería de sistemas y de hardware. Abarca un

conjunto de tres elementos clave – métodos, herramientas y procedimientos- que facilitan
a las personas a controlar el proceso del desarrollo del software.
Los métodos de la ingeniería del software indican cómo construir técnicamente el

software. Los métodos abarcan un amplio espectro de tareas que incluyen: planificación y
estimación de proyectos, análisis de los requisitos del sistema y del software, diseño de
estructuras de datos, arquitectura de programas y procedimientos algorítmicos,
codificación, prueba y mantenimiento. Los métodos de la ingeniería del software
introducen frecuentemente una notación especial orientada a un lenguaje o gráfica y un
conjunto de criterios para la calidad del software.
Las herramientas de la ingeniería del software suministran un soporte automático o

semiautomático para los métodos. Hoy existen herramientas para soportar cada uno de
los métodos mencionados anteriormente. Cuando se integran las herramientas de forma
que la información creada por una herramienta pueda ser usada por otra, se establece un
sistema para el soporte del desarrollo del software llamado Ingeniería de Software
asistido por una Computadora (CASE). CASE combina software, hardware y bases de
datos sobre ingeniería de software (una estructura de datos que contenga la información
relevante sobre el análisis, diseño, codificación y prueba) para crear un entorno de
ingeniería del software (por ejemplo [BRE88]) análogo al diseño/ingeniería asistido por
computadora, CAD/CAE (de las siglas en inglés) para el hardware.
Los procedimientos de la ingeniería del software son el pegamento que junta los métodos
y las herramientas y facilita un desarrollo racional y oportuno del software de la
computadora. Los procedimientos definen la secuencia en la que se aplican los métodos,
las entregas (documentos, informes, formas) que se requieren los controles que ayudan a
asegurar la calidad y coordinar los cambios y las directrices que ayudan a los gestores del
software a evaluar el progreso.
La ingeniería del software está compuesta por una serie de pasos que abarcan los
métodos, las herramientas y los procedimientos antes mencionados. Estos pasos se
denominan frecuentemente paradigmas de la ingeniería de software. La elección de un
paradigma para la ingeniería del software se lleva a cabo de acuerdo con la naturaleza del
proyecto y de la aplicación, los métodos y herramientas a usar y los controles y entregas
requeridos. Tres Son los diferentes tipos de paradigmas que se han tratado ampliamente.
“DAVID AUSUBEL”
SEMIPRESENCIAL
CAPITULO II
2. CICLOS DE VIDA
Es esencial definir previamente los requisitos de todos los elementos del sistema, así
como un modelo de vida para cada uno de los proyectos de programación, puesto que
permite clasificar y controlar las diferentes actividades necesarias para el desarrollo y
mantenimiento del producto.
 Modelo de Fases de Ciclo de Vida

 Modelo del Costo de un Proyecto
 Modelo de Prototipo para el Ciclo de Vida
 Modelo de fases del ciclo de vida (Cascada)
2.1 EL CICLO DE VIDA CLÁSICO SEGÚN ROGER S. PRESSMAN.
Este modelo divide el ciclo de vida del producto de programación en una serie de
actividades sucesivas; cada fase requiere información de entrada, procesos y resultados,
bien definidos.
 Planificación del Sistema

 Análisis
 Diseño
 Codificación
 Prueba
 Mantenimiento
En ocasiones se denomina de cascada porque los productos pasan de un nivel a otro con
suavidad.
Este es el ciclo de vida clásico y más antiguo, usado en el desarrollo de productos de

software. Sin embargo, con el paso de unos cuantos años, se han producido críticas,
incluso por seguidores activos, que cuestionan su aplicabilidad a todas las situaciones.
2.2 PLANIFICACIÓN DEL SISTEMA:
Es la etapa en la que se determina si el proyecto es o no factible de realizar y se

determinan tiempos y costos aproximados, estableciendo así la ruta crítica de cada
actividad. Esto es porque la falta de planeación de un sistema es la causa principal de
retrasos en programación, incremento de costos, poca calidad, y altos costos de
mantenimiento en los desarrollos de productos de software.
Con frecuencia se dice que es imposible realizar una planeación inicial, porque la
información precisa sobre las metas del proyecto, necesidades del cliente y restricciones
del producto no se conocen al comenzar el proyecto de desarrollo, sin embargo, uno de
los principales propósitos de esta fase es aclarar los objetivos, problemas o necesidades y
restricciones. La dificultad de la planeación no debe desalentar tan importante actividad.
“DAVID AUSUBEL”
SEMIPRESENCIAL
ANÁLISIS
Es indispensable comprender perfectamente los requisitos del software, para que éste no
fracase. Esta etapa puede parecer una tarea relativamente sencilla, pero las apariencias
engañan. Abundan los casos en que se puede llegar a malas interpretaciones o falta de
información.
Existe una frase que se utiliza al momento de hacer el análisis, y es la siguiente:

"Sé que crees que comprendes lo que piensas que he dicho, pero no estoy seguro de que
lo que creíste oír sea lo que yo quise decir..."
DISEÑO
El diseño del software es realmente un proceso multipaso que se enfoca sobre cuatro
atributos distintos del programa: la estructura de los datos, la arquitectura del software, el
detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los
requisitos en una representación del software que pueda ser establecida de forma que
obtenga la calidad requerida antes de que comience la codificación. Al igual que los
requisitos, el diseño se documenta y forma parte de la configuración del software.
CODIFICACIÓN
El diseño debe traducirse en una forma legible para la máquina. Si el diseño se realiza de
una manera detallada, la codificación puede realizarse mecánicamente.
PRUEBA
Una vez que se ha generado el código, comienza la prueba del programa. La prueba se
centra en la lógica interna del software, asegurando que todas las sentencias se han
probado, y en las funciones externas, realizando pruebas que aseguren que la entrada
definida produce los resultados que realmente se requieren.
MANTENIMIENTO
Es indudable que el software una vez entregado al cliente sufrirá cambios (posible
excepción es el software empotrado). Los cambios ocurrirán debido a que se hayan
encontrado errores, a que el software deba adaptarse a posibles cambios. El desarrollo de
productos de software bajo éste ciclo de vida tiene los siguientes problemas:
1.- Los proyectos reales raramente siguen el flujo secuencial que propone el modelo.
2.- Normalmente, es difícil para el cliente establecer explícitamente al principio todos los
requisitos. Este ciclo lo requiere y tiene dificultades en entender posibles problemas que
pudieran existir.
“DAVID AUSUBEL”
SEMIPRESENCIAL
3.- El cliente debe tener paciencia. Hasta llegar a las etapas finales del desarrollo del
proyecto.
A pesar de sus inconvenientes, este ciclo de vida sigue siendo el modelo clásico más
ampliamente usado por los ingenieros del software.
2.3 MODELO DEL COSTO DE UN PROYECTO
Otro punto de vista para el ciclo de vida de desarrollo de un producto de programación es

la consideración del costo de la realización de las distintas actividades del proyecto. El
costo de un proyecto es la suma de los costos incurridos en cada fase, y éstos, a su vez,
incluyen los costos de la realización de los procesos y preparación de los documentos de
esa fase, más los costos de verificación de la consistencia de estos productos con los de
las fases previas. Es sumamente importante hacer hincapié en que es prácticamente 100
veces más costoso hacer un cambio a los requisitos durante la prueba del sistema, que
hacerlo durante su definición.
2.3.1 MODELO DE PROTOTIPO PARA EL CICLO DE VIDA
Un prototipo es una representación o modelo del producto de programación que, a

diferencia de un modelo de simulación, incorpora componentes del producto real. Por lo
regular, un prototipo tiene un funcionamiento limitado en cuanto a capacidades,
confiabilidad o eficiencia.
Hay varias razones para desarrollar un prototipo; una de ellas es ilustrar los formatos de
datos de entrada, mensajes, informes y diálogos al cliente, este es un mecanismo
adecuado para explicar opciones de procesamiento y tener un mejor entendimiento de las
necesidades de él.
Una vez realizado el sistema prototipo, la pregunta que surgiría sería la siguiente: ¿Qué
debemos hacer con el prototipo cuando ya ha servido para el propósito establecido?
Brooks nos da una respuesta:
"En la mayoría de los proyectos, el primer sistema construido apenas es utilizable". Puede
ser demasiado lento, demasiado grande, difícil de usar o las tres cosas. No hay más
alternativa que comenzar de nuevo y construir una versión rediseñada que resuelva los
problemas que se presenten... Cuando se utiliza un nuevo concepto de sistema o de
tecnología, hay que construir un sistema para desecharlo, porque incluso la mejor
planificación no puede asegurar que vaya a ser bueno la primera vez. Por tanto, la
cuestión no es si hay que construir un sistema piloto y tirarlo. Se tirará. La única cuestión
es si planificar de antemano la construcción de algo que se va a desechar, o prometer
entregar el desecho a los clientes.
Al igual que el ciclo de vida clásico, la construcción de prototipos puede ser problemática
por las siguientes razones:
“DAVID AUSUBEL”
SEMIPRESENCIAL
1.- El cliente ve funcionando lo que parece ser una primera versión del software,
ignorando que, por las prisas en hacer que funcione, no hemos considerado los aspectos
de calidad o de mantenimiento del software a largo plazo. Cuando se le informa de que el
producto debe ser reconstruido, el cliente se vuelve loco y solicita que se apliquen
“cuantas mejoras” sean necesarias para hacer del prototipo un producto final que
funcione. Y el desarrollador del producto cede demasiado a menudo.
2.- El técnico de desarrollo, frecuentemente, impone ciertos compromisos de
implementación con el fin de obtener un prototipo que funciones rápidamente. Puede que
utilice un sistema operativo inapropiado, o un lenguaje de programación equívoco o
simplemente porque ya está disponible y es conocido, puede que implemente
ineficientemente un algoritmo, sencillamente para demostrar su capacidad.
La clave está en definir al comienzo las reglas del juego; esto, es, el cliente y el técnico
deben estar de acuerdo en que el prototipo se construya para servir sólo como un
mecanismo de definición de los requisitos.
2.4 FACTORES DE CALIDAD
El grado de formalidad y la cantidad de tiempo asignada varía de acuerdo con el tamaño y

complejidad del producto que se desarrollará. Existe una gran diferencia entre escribir un
programa pequeño de uso personal y el desarrollar para una empresa, ya que esto
requiere el desarrollo y mantenimiento de productos de alta calidad y habilidades técnicas
y gerenciales comparables con otras ramas de la ingeniería.
Capacidad Individual
El desarrollo de productos de software es laborioso por lo que la capacidad de cada
individuo influye mucho en la calidad de desarrollo. Existen dos aspectos en la capacidad:
la competencia global del individuo y su familiaridad con el área particular de aplicación
Por mencionar algunos ejemplos: programadores que se muestran competentes en el
procesamiento de datos, suelen no serlo en áreas científicas, y de igual forma, un buen
programador científico no es, forzosamente, un buen programador de sistemas.
Comunicación en grupo
Aunque la programación se considera una actividad individual y privada de modo que
muchos programadores tienen poco contacto social y prefieren trabajar en forma aislada.
Con el incremento del tamaño de un producto, disminuye la productividad debido al
aumento en complejidad de las interacciones entre los diversos componentes del sistema,
y a causa del incremento de comunicación necesario entre programadores, gerentes y
clientes.
Complejidad del Producto

Existen tres tipos de complejidad en un producto generalmente aceptados: programas de
aplicación, programas de apoyo y programas de sistema operativo. Los programas de
aplicación tienen el más alto nivel de productividad mientras que los programas de
sistemas operativos tienen el menor, medido en términos de líneas de código por día de
programador. El esfuerzo requerido para desarrollar y mantener un producto de
programación es una función no lineal del tamaño del producto y su complejidad. Un
producto del doble de tamaño o doblemente difícil que otro producto, usando cualquier
“DAVID AUSUBEL”
SEMIPRESENCIAL
métrica diferente del esfuerzo, puede requerir diez o tal vez 100 veces más esfuerzo para
obtener el producto.
Notaciones apropiadas
Las notaciones apropiadas son vehículos de comunicación entre el personal asignado al
proyecto y planean la posibilidad de usar una herramienta automatizada de programación
para manejar las notaciones verificando su uso correcto. Esto puede beneficiar un
proyecto en particular, pero se obtendrán más beneficios cuando se adopte, en todas las
organizaciones e industrias, un conjunto pequeño de notaciones bien definidas para los
proyectos de programación.
Enfoques Sistemáticos
Es indispensable al momento de desarrollar software, el utilizar herramientas de diseño
tales como modelos de desarrollo. Pudiéndose utilizar de cascada, costo,
Versiones sucesivas, y más. Dependiendo del sistema. En este documento se describen
varios enfoques sistemáticos de desarrollo y mantenimiento pero, como la ingeniería del
software se encuentra en su infancia, muchos de los procedimientos propuestos tendrán
todavía que madurar.
Control de Cambios
La flexibilidad de un programa es un gran beneficio y a su vez una gran fuente de
dificultad en la ingeniería de software. Las notaciones y procedimientos que permitan
seguir la secuencia y determinar el impacto de un posible cambio son necesarios para
hacer visible el costo verdadero de una modificación aparentemente pequeña al código
fuente; estos cambios de manuales, requisitos y planes de prueba. Por otro lado, el uso
de notaciones y técnicas apropiadas hace que se puedan realizar cambios controlados,
sin menoscabo de la calidad del producto.
Nivel Tecnológico
Incluye aspectos como selección del lenguaje, ambiente computacional, prácticas de
programación y herramientas de programación disponibles. Entre más tecnología de
hardware y software se tenga mejor será la calidad y productividad.
Nivel de Confiabilidad
Todo producto de programación debe poseer un nivel elemental de confiabilidad; sin
embargo, la alta confiabilidad sólo se consigue con gran cuidado en el análisis, diseño,
instrumentación, pruebas y mantenimiento del software.
Captación del problema

Muchas veces, es el cliente quien no entiende realmente la naturaleza del problema,
además de no entender las capacidades y limitaciones de la computación. Para poder
resolver esta situación, se necesita realizar entrevistas con el cliente, la observación de la
tarea manual, el desarrollo de prototipos, una versión preliminar del manual del usuario,
entre otros.
Tiempo Disponible
“DAVID AUSUBEL”
SEMIPRESENCIAL
La mayoría de las veces las empresas desean tener los sistemas para ayer.
Aunque pareciera que un proyecto de programación que requiere de un esfuerzo de seis
meses-programador pueda ser completado por un programador en seis meses o seis
programadores en un mes, los proyectos de programación son sensibles no sólo al total
de esfuerzo requerido, sino también al número de personas comprendidas. El uso de seis
programadores durante un mes probablemente sea menos eficiente que usar sólo uno
durante seis meses, y esto se debe a que la curva de aprendizaje para el grupo de seis
programadores afectará notablemente al proyecto.
Especialización requerida.
No es necesario que todos los ingenieros poseen todas las habilidades necesarias, pero
los miembros del equipo de programación sí deberán poseerlas, ya que se requiere de
una gama de habilidades y especialidades; por ejemplo: la obtención de la información de
los clientes con el fin de determinar sus necesidades requiere de la habilidad de
comunicarse, de tener tacto y diplomacia, así como de un buen conocimiento del área de
aplicación.
Facilidades y recursos.
Es muy motivante para un programador contar con un buen ambiente de trabajo, así
como un buen acceso a una buena máquina y un lugar silencioso donde laborar. Casi
todos los programadores se motivan con los recursos con que cuentan, por lo tanto son
muy sensibles y están sujetos a frustración si cuentan con recursos pobres o
inadecuados. Los gerentes de un proyecto de programación deben de ser eficaces en el
manejo de los factores de motivación y frustración, si desean mantener la calidad de sus
productos, la productividad de sus programadores y la satisfacción del trabajo.
Entrenamiento adecuado
La programación de un producto es sólo un aspecto de la ingeniería de programación sin
embargo, ésta es la única fase del desarrollo y mantenimiento de un producto que se
enseña en muchas escuelas. Hasta el momento, la mayoría de los programadores se han
educado como ingenieros en computación, ingenieros electrónicos, contadores,
matemáticos, más no como ingenieros en productos de programación. Las universidades
han formado tradicionalmente licenciado en computación y las industrias buscan, también
por tradición, ingenieros de programación.
Habilidades gerenciales
Los proyectos de programación son, por lo común, supervisados por gerentes que tienen
poco conocimiento, si acaso lo tienen, acerca de la ingeniería de programación Por otro
lado, la costumbre de promover a puestos administrativos de un proyecto de
programación a individuos técnicamente competentes, con poca inclinación gerencial y sin
entrenamiento administrativo, también suele producir resultado negativos.
Metas apropiadas
La meta principal de la ingeniería de software es el desarrollo de productos de
programación que cumplan con los requisitos del uso deseado; idealmente, todo producto
“DAVID AUSUBEL”
SEMIPRESENCIAL
de programación debe proporcionar niveles óptimos de generalidad, eficiencia y

confiabilidad
2.5 MEDICION DEL SOFTWARE

Hay varias razones por las que hay que medir el software:
 .Para indicar la calidad del Producto

 Para evaluar la productividad de la gente que desarrolla el producto
 .Para evaluar los beneficios
 Para establecer una línea de base para la estimación
 Para ayudar a justificar el uso de nuevas herramientas o de formación adicional
2.6 INGENIERÍA DE SOFTWARE
No es una ciencia sino un conjunto de técnicas.

Una de las primeras definiciones de ingeniería del software fue la propuesta por Fritz
Bauer en la primera conferencia importante [NAU 69] dedicada al tema:
“El establecimiento y uso de principios de ingeniería robustos, orientados a obtener

software económico que sea fiable y funcione de manera eficiente sobre máquinas
reales”.
Aunque se han propuesto muchas más definiciones generales, todas refuerzan la

importancia de una disciplina de ingeniería para el desarrollo del software.
La ingeniería del software surge de la ingeniería de sistemas y de hardware.

Abarca un conjunto de tres elementos clave – métodos, herramientas y procedimientos-
que facilitan a las personas a controlar el proceso del desarrollo del software.
Los métodos de la ingeniería del software indican cómo construir técnicamente el

software. Los métodos abarcan un amplio espectro de tareas que incluyen: planificación y
estimación de proyectos, análisis de los requisitos del sistema y del software, diseño de
estructuras de datos, arquitectura de programas y procedimientos algorítmicos,
codificación, prueba y mantenimiento.
Las herramientas de la ingeniería del software suministran un soporte automático o

semiautomático para los métodos. Hoy existen herramientas para soportar cada uno de
los métodos mencionados anteriormente. Cuando se integran las herramientas de forma
que la información creada por una herramienta pueda ser usada por otra, se establece un
sistema para el soporte del desarrollo del software, llamado Ingeniería de Software
asistido por una Computadora (CASE).
Los procedimientos de la ingeniería del software son el pegamento que junta los métodos
y las herramientas y facilita un desarrollo racional y oportuno del software de la
computadora. Los procedimientos definen la secuencia en la que se aplican los métodos,
las entregas (documentos, informes, formas, etc.) que se requieren, los controles que
“DAVID AUSUBEL”
SEMIPRESENCIAL
ayudan a asegurar la calidad y coordinar los cambios y las directrices que ayudan a los
gestores del software a evaluar el progreso.
En este caso nos enfocaremos a la Ingeniería de Sistemas que es lo que más se apega a
lo del curso de Análisis de Sistemas.
CAPITULO III
3. INGENIERIA DE SISTEMAS
La Ingeniería de Software ocurre como consecuencia de un proceso denominado

Ingeniería de Sistemas de Computadora. En lugar de concentrarse únicamente en el
software, la Ingeniería de Sistemas de Computadora se concentra en una variedad de
elementos, analizando, diseñando y organizando esos elementos en un sistema que
puede ser un producto, un servicio o una tecnología para la transformación de información
o control de información.
El proceso de Ingeniería de Software es denominado Ingeniería de Información cuando el

contexto del trabajo de Ingeniería se enfoca en una empresa. Cuando hay que construir
un producto el proceso se denomina Ingeniería de Producto. Aunque cada una se aplica
en un dominio de aplicaciones diferentes, ambas trabajan para asignar un papel al
software de la computadora y establecer los enlaces que unen al software con otros
elementos de un sistema basado en computadoras.
3.1 SISTEMAS BASADOS EN COMPUTADORAS
Un Sistema basado en computadora se define como un conjunto o arreglo de elementos

que están organizados para alcanzar un objetivo predefinido procesando información.
Para conseguir este objetivo el sistema hace uso de varios elementos:
Software: Se refiere a programas de computadora, estructuras de datos y su

documentación.
Hardware: Son dispositivos electrónicos que proporcionan capacidad de calculo y

dispositivos electromecánicos que proporcionan una función externa.
Personas: Se refiere al usuario o operador del hardware y software.
Bases de Datos: Una gran colección de información.

“DAVID AUSUBEL”
SEMIPRESENCIAL
Documentación: Manuales, formularios y otra información descriptiva que retrata el

empleo y operación del sistema.
Procedimientos: Pasos que definen el empleo especifico de cada elemento del sistema.
Los elementos se combinan de varias maneras para transformar la información.
3.2 LA JERARQUIA DE LA INGENIERÍA DE SISTEMAS DE COMPUTADORAS
La Ingeniería de Sistemas de Computadora comprende una colección de métodos para

navegar de arriba abajo y de abajo a arriba dentro de su jerarquía. El proceso empieza
con lo que se conoce normalmente como Vista Global, esto se refiere a examinar el
dominio entero del negocio o producto para asegurarse de que se puede establecer el
contexto de negocio o tecnológico apropiado.
La visión global se refina para enfocarse totalmente en un dominio de interés específico

para analizar la necesidad de elementos del sistema. Finalmente se inicia el análisis,
diseño y construcción del elemento deseado.
En la parte alta de la jerarquía se establece un contexto muy amplio y en la parte baja se

llevan a cabo actividades técnicas mas detalladas, realizadas por la disciplina de
ingeniería correspondiente.
La visión global retrata una clara definición de la funcionalidad general que permitirá al
ingeniero entender el dominio y finalmente el sistema o producto del contexto apropiado.
3.3 MODELADO DEL SISTEMA
La ingeniería de Sistemas de Computadora es un proceso de modelado por lo que es

necesario crear modelos que definan los procesos que satisfagan las necesidades de la
visión bajo consideración, representa en el comportamiento de los procesos y los
supuestos en que se basa el comportamiento, definen explícitamente las entradas de
información y representa en todas las uniones que permitan entender mejor la visión.
Para construir el modelo hay que tener ciertas restricciones:

 Supuestos que reducen el número de permutaciones y variaciones posibles.
 Simplificaciones que permitan crear el modelo a tiempo
 Limitaciones que ayuden a delimitar el sistema
 Restricciones que guían la manera de crear el modelo y el enfoque que se toma al
implementar el modelo.
 Preferencia que indican la arquitectura preferida para toda la información,
funciones y tecnología.
El modelo de sistema resultante puede reclamar una exclusión completamente

automática, semiautomática o un enfoque manual. Es posible caracterizar modelos de
“DAVID AUSUBEL”
SEMIPRESENCIAL
cada tipo que sirven como soluciones alternativas para el problema que tenemos entre
manos. En esencia el trabajo se limita a modificar simplemente la influencia relativa de los
diferentes elementos del sistema para crear modelos de cada tipo.
3.5 INGENIERÍA DE INFORMACIÓN
La meta de la Ingeniería de Información es definir arquitecturas que permitan a las

empresas emplear la información eficazmente y crear un plan global para ampliar dichas
arquitecturas.
Se deben analizar y diseñar 3 arquitecturas diferentes dentro del contexto de objetivos y

metas del negocio:
 Arquitectura de Datos: Proporciona una estructura para las necesidades de
información de un negocio o una función de negocio. Los componentes de la
arquitectura son los objetos de datos que emplea la empresa. Estos fluyen entre
las funciones de negocio
 Arquitectura de Aplicación: Comprende aquellos elementos de un sistema que
transforman objetos dentro de la arquitectura de datos por algún propósito del
negocio.
 Infraestructura de Tecnología: Proporciona el fundamento de las arquitecturas de
datos y de aplicaciones. La infraestructura comprende del hardware y software
empleados para dar soporte a las aplicaciones y datos. Esto incluye computadoras
y redes de computadoras, enlaces de telecomunicaciones, tecnologías de
almacenamiento y la arquitectura diseñada para implementar estas tecnologías.
Para modelar las arquitecturas de sistema definidas anteriormente, se define una

jerarquía de actividades de ingeniería de la información.
La visión global se consigue a través del Planificación de la Estrategia Información (PEI).

PEI ve al negocio como una entidad y aísla los dominios del negocio importantes para la
totalidad de la empresa. Además define los objetos de datos visibles a nivel de empresa,
sus relaciones y como fluyen entre los dominios del negocio.
La vista de dominio del negocio se trata con una actividad II denominada Análisis del Área
de Negocio (AAN). El AAN se ocupa de identificar en detalle la información y los requisitos
de la funciones de áreas de negocio seleccionadas identificadas durante el PEI. Se ocupa
solo de especificar que se requiere en un área de negocio.
Una vez que se ha aislado un sistema de información para un desarrollo posterior, la II

hace una transición a la ingeniería del software. Invocando un paso del Diseño de
Sistema de Negocio (DSN), se modelan los requisitos básicos de un sistema de
información específico y estos requisitos se traducen en arquitectura de datos,
arquitectura de aplicación, e infraestructura tecnológica. El paso final de la II(Construcción
e Integración) se concentra en los detalles de implementación. La arquitectura e
infraestructura se implementan construyendo una base de datos apropiada y estructuras
“DAVID AUSUBEL”
SEMIPRESENCIAL
internas de datos, mediante la construcción de aplicaciones que están constituidas por

programas.
Cada uno de estos componentes del sistema debe integrarse para formar una aplicación
o sistema de infamación completo.
INGENIERÍA DE PRODUCTOS
La meta de la Ingeniería de Productos es traducir el deseo de un cliente, de un conjunto

de capacidades definidas, en un producto operativo. Para conseguir esta meta, la
ingeniería de producto debe crear una arquitectura y una infraestructura.
La arquitectura comprende 4 tipos de componentes de sistema distintos: software,

hardware, datos y personas. Se establece una infraestructura de soporte e incluye
tecnología requerida para unir componentes y la información que se emplea para dar
soporte a los componentes.
Los requisitos generales del producto se obtienen del cliente. Estos requisitos
comprenden necesidades de información y control, funcionalidad del producto y
comportamiento, rendimiento general del producto, diseño, restricciones de la interfaz y
otras necesidades especiales. Luego de determinar los requisitos es necesario asignar
funcionalidad y comportamiento a cada uno de los 4 componentes mencionados
anteriormente.
Una vez realizada la asignación comienza la Ingeniería de Componentes. La Ingeniería de

componentes es un conjunto de actividades concurrentes que se dirigen separadamente a
cada uno de los componentes de sistema.
La visión de elemento para la ingeniería de productos es la disciplina de ingeniería

aplicada a la asignación de componentes. Para la ingeniería de Software, esto significa
actividades de modelado del análisis y diseño y actividades de construcción e integración
que comprenden generación de código, pruebas y actividades de soporte.
3.6 PLANIFICACIÓN DE LA ESTRATEGIA DE LA INFORMACIÓN
El primer paso de la ingeniería de información es la Planificación de la Estrategia de

Información (PEI). Los objetivos generales del PEI son:
 Definir los objetivos y metas estratégicos del negocio

 Aislar los factores de éxito críticos
 Analizar el impacto de la tecnología y automatización en las metas y objetivos
 Analizar la información existente para determinar su papel en la consecución de
las metas y objetivos. Con esto se pretende evaluar el desempeño del sistema
actual.
3.6.1 MODELADO DE LA EMPRESA
“DAVID AUSUBEL”
SEMIPRESENCIAL
El modelado de la empresa crea una visión a tres dimensiones de un negocio. La primera

dimensión se ocupa de la estructura de la organización y de las funciones que se realizan
dentro de las áreas de negocio definidas en el organigrama. La segunda dimensión
descompone la función de negocio para aislar los procesos que hacen que ocurra dicha
función. Finalmente, la tercera dimensión relaciona los objetivos, metas y FCE con la
organización y sus funciones. Además el modelado de la empresa crea un modelo de
datos a nivel de negocio que define objetos de datos y sus relaciones con otros elementos
del modelo de empresa.
3.6.2 MODELADO DE DATOS A NIVEL DE NEGOCIO
El modelado de datos a nivel de negocio es una actividad de modelado de empresa que

se concentra en objetos de datos o entidades necesarias para alcanzar las funciones de
negocios como soporte corporativo, ventas y marketting, Ingeniería y fabricación.. Un
objeto de información contiene un conjunto de atributos que define algún aspecto,
cualidad, característica o descriptor de la información que describe. Una vez que se
definen las entidades se determina las relaciones entre ellas.
3.6.3 ANALISIS DEL AREA DE NEGOCIO
Para modelar las complicadas y sutiles maneras en que se relacionan los diferentes
aspectos de la información de la empresa, el ingeniero de la información debe describir
cómo se usan y transforman los objetos de datos dentro de cada área de negocios.
Para esto se emplean varios modelos diferentes:

Modelos de datos
Modelos de flujos de proceso
Diagramas de descomposición de procesos
Una variedad de matrices de referencias cruzadas
3.6.4 MODELADO DEL PROCESO
El trabajo realizado dentro de un área de negocio comprende un conjunto de funciones de

negocio que se refinan más en los procesos de negocio. Por ejemplo el proceso de
ventas:
Función de Ventas:
 n el cliente

 Considerar cuestiones y detalles

 Aceptar la orden de ventas
 Comprobar la disponibilidad del pedido
 Preparar la orden de envío
 Confirmar con el cliente el pedido , los precios y la fecha de envío
 Transmitir la orden de envío al depto. de distribución
 Hacer un seguimiento al cliente
“DAVID AUSUBEL”
SEMIPRESENCIAL
Con esta información se puede perfectamente desarrollar un diagrama de flujo de

proceso.
3.6.5 MODELADO DEL FLUJO DE INFORMACIÓN
El modelo de flujo de proceso está integrado con el modelo de datos para proporcionar
una indicación de cómo fluye la información a través del área de negocio. Se muestran los
objetos de datos de entrada y salida para cada proceso, proporcionando una indicación
de cómo el proceso transforma la información.
Una vez que se ha creado un conjunto de modelos de flujo de proceso, el ingeniero de

información examina cómo se puede rediseñar el proceso existente y donde se podrían
modificar o sustituir los sistemas o aplicaciones de información actuales por otras
tecnologías de la información eficaces.
EL modelo de proceso revisado se emplea como base para la especificación de software

nuevo o revisado para dar soporte a la función de negocio.
3.6.6 INGENIERIA DE PRODUCTOS
La ingeniería de productos (o Ingeniería de sistemas de computadora) es una actividad de

resolución de problemas. Se localiza, analiza y asigna la información, función y
comportamiento del producto deseado a componentes individuales de ingeniería.
Análisis de Sistema
El análisis del sistema se lleva a cabo con los siguientes objetivos en mente:
 Identificar la necesidad del cliente;
 Evaluar el concepto del sistema para establecer la viabilidad
 Realizar un análisis técnico y económico
 Asignar funciones al hardware, software, personal, bases de datos y otros
elementos del sistema
 Establecer las restricciones de presupuesto y planificación temporal
 Crear una definición de sistema que forme el fundamento de todo el trabajo de
ingeniería .Se requiere un gran dominio del hardware y software para conseguir
con éxito los objetivos mencionados anteriormente.
“DAVID AUSUBEL”
SEMIPRESENCIAL
CAPITULO IV
4. IDENTIFICACION DE NECESIDADES
El primer paso del proceso de análisis del sistema afecta a la identificación de la

necesidad. El analista se reúne con el cliente y el usuario final. La intención es entender
los objetivos del producto y definir las metas necesarias para alcanzar esos objetivos.
Una vez que se han identificado las metas globales, el analista pasa a la evaluación de la
información suplementaria: ¿Existe la tecnología para construir el sistema ?¿Qué
recursos especiales de desarrollo y fabricación serán necesarios ?¿Qué límites se han
puesto al presupuesto y a la planificación temporal? Si el nuevo es un producto a
desarrollar para venderlo a muchos clientes, se plantean además las siguientes
cuestiones: ¿Cuál es el mercado potencial del producto ?¿Cómo es comparativamente
este producto con los de la competencia ?¿Qué posición ocupa este producto en la línea
general de producción de la compañía?
Esta información es reunida por el analista en base a las reuniones y entrevistas con el
cliente, la comunicación cliente – analista originará modificaciones a esta información.
4.1 ESTUDIO DE VIABILIDAD
Todos los proyectos son posibles si se tiene finitos recursos y tiempo. Desgraciadamente,
el desarrollo de un sistema o producto basado en computadora es muy probable que esté
plagado de escasees de recursos y de fechas de entrega difíciles (no realistas). Es
necesario y prudente evaluar la viabilidad de un proyecto cuanto antes. Se pueden evitar
meses o años de esfuerzo, miles o millones y un bochorno profesional si se reconoce un
sistema mal concebido en la pronta fase de definición.
La viabilidad y el análisis de riesgo están relacionados de muchas maneras. Si el riesgo

del proyecto es alto, la viabilidad de producir software de calidad se reduce. Durante la
ingeniería de producto, sin embargo, concentramos nuestra atención en cuatro áreas
principales de interés:
Viabilidad económica, Una evaluación del costo de desarrollo sopesado con los ingresos
netos o beneficios obtenidos del sistema o producto desarrollado
Viabilidad técnica, un estudio de función, rendimiento y restricciones que pueden afectar a

la consecución de un sistema aceptable.
Viabilidad legal, Determinar infracción, violación o responsabilidad legal que se podría

incurrir durante el desarrollo del sistema.
Alternativas, Una evaluación de los enfoques alternativos al desarrollo del sistema o

producto.
“DAVID AUSUBEL”
SEMIPRESENCIAL
No es necesario un estudio de viabilidad para sistemas en que la justificación económica

es obvia, el riesgo técnico es bajo, se esperan pocos problemas legales y no existe
ninguna alternativa razonable.
4.1.1 ANÁLISIS ECONÓMICO
Entre la información más importante contenida en un estudio de viabilidad está el análisis

costo/ beneficio: una valoración de la justificación económica para un proyecto de sistema
basado en computadora. El análisis costo/beneficio determina los costos para el
desarrollo del proyecto y los relaciona contra los beneficios tangibles.
El análisis costo/beneficio es complicado por criterios que varían con las características
del sistema a desarrollar, el tamaño relativo del proyecto y los beneficios esperados de la
inversión como parte del plan estratégico de la compañía.
El analista puede estimar cada costo y usar después el desarrollo y los costos sucesivos
para determinar la recuperación de lo invertido, un punto de beneficio cero y un período
de rentabilidad.
Solo invirtiendo tiempo para evaluar la viabilidad reducimos las posibilidades de una grave
situación embarazosa en etapas posteriores del proyecto de un sistema.
4.1.2 ANÁLISIS TÉCNICO
Durante el análisis técnico, el analista evalúa los principios técnicos del sistema al mismo
tiempo que se recoge información adicional sobre el rendimiento, fiabilidad, características
de mantenimiento y productividad. En algunos casos, esta frase del análisis del sistema
también incluye una cierta cantidad de investigación y diseño.
El análisis técnico empieza con una valoración de la viabilidad técnica del sistema
propuesto. ¿Qué tecnologías se requieren para lograr el funcionamiento y rendimiento del
sistema ?¿Qué nuevos materiales, métodos o procesos se necesitan y cuál es su riesgo
de desarrollo ?¿Cómo afectarán estos aspectos tecnológicos a los costos?
Las herramientas disponibles para un análisis técnico se obtienen de técnicas de

optimización y modelos matemáticos, probabilidades y estadísticas, teoría de colas y de
control, por nombrar unas pocas. Es importante resaltar, sin embargo, que no siempre es
posible una evaluación analítica. El modelado es un mecanismo eficaz para el análisis
técnico de sistemas basados en computadora.
Los resultados obtenidos del análisis técnico forman la base para otra decisión de
continuar/abandonar sobre el sistema. Si el riesgo es grave , si los modelos indican que
no se puede conseguir la función o rendimiento deseados , si las piezas no encajan
perfectamente unas con otras , Hay que buscar un nuevo planteamiento....
4.2 MODELADO DE LA ARQUITECTURA DEL SISTEMA

“DAVID AUSUBEL”
SEMIPRESENCIAL
Todos los sistemas basados en computadora pueden modelarse como la transformación

empleando una arquitectura del tipo entrada-proceso-salida.
Últimamente se han incluido dos características adicionales del sistema: proceso de

interfaz de usuario y proceso del mantenimiento y autocomprobación. Mediante la
representación de entrada-proceso-salida, proceso de la interfaz de usuario y de
autocomprobación un ingeniero de sistemas puede crear un modelo de componentes de
sistema que establezca el fundamento para análisis de requisitos posteriores y etapas de
diseño en cada una de las disciplinas de ingeniería.
Las dos herramientas que se usan en este proceso son: el diagrama de contexto de la
arquitectura y el diagrama de flujo de arquitectura. El diagrama de contexto establece el
límite de información entre el sistema que se esta implementando y el entorno en que va a
operar. Y por otro lado esta el de flujo que es el flujo de información a través de las
regiones y se usa para guiar al ingeniero de sistemas.
4.3 MODELADO Y SIMULACION DEL SISTEMA
Muchos sistemas basados en computadora interaccionan con el mundo real de forma

reactiva. Es decir, los acontecimientos del mundo real son vigilados por el hardware y el
software que componen el sistema y basándose en esos eventos, el sistema aplica su
control sobre las máquinas, procesos e incluso las personas que motivan los
acontecimientos.
Hoy en día se utilizan herramientas CASE en el modelado y simulación de sistemas para

ayudar a eliminar sorpresas cuando se construyen sistemas reactivos basados en
computadora. Estas herramientas se aplican durante el proceso de ingeniería del sistema,
mientras se están especificando las necesidades del hardware, software, bases de datos
y de personas.
4.4 ESPECIFICACION DEL SISTEMA
La especificación del sistema es un documento que sirve como fundamento para la

ingeniería hardware, software, bases de datos y humana. Describe la función y el
rendimiento de un sistema basado en computadora y las restricciones que gobernarán su
desarrollo. La especificación delimita cada elemento del sistema asignado. Por ejemplo:
proporciona al ingeniero del software una indicación del papel del software dentro del
contexto del sistema en su totalidad y los distintos subsistemas. Especificando además lo
que se introduce y se saca del sistema.
4.5 TÉCNICAS ORIENTADAS A OBJETOS
 Principio de la Ingeniería de Software

“DAVID AUSUBEL”
SEMIPRESENCIAL
 “la gran ingeniería es una ingeniería SENCILLA”

 Actualidad y tendencia del desarrollo de software
 Toda metodología debe realizar una representación más natural y real.
METODOLOGÍA
ESTRUCTURAL ORIENTADA A OBJETOS
ANÁLISIS Y DISEÑO
OMT UML
ORIENTADO A OBJETOS
DIAGRAMA DE COMPONENTES Y DE
DISTRIBUCIÓN
OBJETO
PROGRAMACIÓN
REDES Y
POR COMPONENTES
COMUNICACIONES
Y POR OBJETOS
DISTRIBUIDAS
EVOLUCIÓN (Generaciones)
“DAVID AUSUBEL”
SEMIPRESENCIAL
Primera Generación
 Data de los 50’

 Primera generación de Hardware (Tubos al vacío)
 Programación por cable
Segunda Generación
 Data de los 60’

 Transistores
 Aparecen los lenguajes de programación (FORTRAN - BASIC)
 Inicia el desarrollo de software
 Surge la crisis del software
 Se define el Ciclo de Vida del Software
CASCADA
PROTOTIPO
ESPIRAL
CLÁSICO
Tercera Generación
 Data de los 70’ y 80’

 Tercera y Cuarta Generación del Hardware (Circuitos Integrados y
Microprocesador)
 Apogeo de los lenguajes de programación
 Alto desarrollo del software comercial y genérico
 Se profundiza la crisis del software
 Aparece la técnica estructurada moderna de YOURDON
 Se incorporan técnicas de administración para:
 El control de proyectos de planificación
 Manejo de grupos de trabajo
Cuarta Generación
 Data de los finales de los 80’ y desde los 90’ en adelante

 Quinta Generación del Hardware (Computadoras Inteligentes)
 Desarrollo de la técnicas orientadas a objetos
o OMT
“DAVID AUSUBEL”
SEMIPRESENCIAL
o UML
o Desarrollo de áreas específicas como:
 Visual
 Electrónica
 Inteligencia artificial
 Simulación
ALCANCE
Todo se representa como un objeto.
INGENIERIA DE SISTEMAS
INGENIERIA DE REDES
INGENIERIA MANUFACTURA Y
PRODUCCIÓN
OBJETO INGENIERIA DE
CONOCIMIENTO
Metodologías
 Análisis Orientado a Objetos

o Análisis de objetos
 Diagramas orientados a objetos
 De casos de uso
 De clases
 De secuencia
 Diseño Orientado a Objetos
 Diagramas orientados a objetos
 De actividades
“DAVID AUSUBEL”
SEMIPRESENCIAL
 De componentes
 De distribución
 Herramientas CASE
o Racional Rose
o Power Designer
4.6 CARACTERÍSTICAS
Tiene una representación natural y real porque un objeto se le considera natural y real.
OBJETO
FÍSICO LÓGICO
Posee mayor complejidad.

Posee mayor reusabilidad.
Aplicación total de la GUI
EVENTO CLIC
Define estructuras más estables para la reutilización.

“DAVID AUSUBEL”
SEMIPRESENCIAL
CAPITULO V
5. METODOLOGÍAS DE DESARROLLO DE SOFTWARE
5.1 METODOLOGÍA vs. CICLO DE VIDA
Una metodología puede seguir uno o varios modelos de ciclo de vida, es decir, el ciclo de
vida indica qué es lo que hay que obtener a lo largo del desarrollo del proyecto pero no
cómo hacerlo.
La metodología indica cómo hay que obtener los distintos productos parciales y finales
5.1.1 GENERACIONES DE METODOLOGÍA
 Desarrollo Convencional (Sin Metodología).

 Desarrollo Estructurado.
 Desarrollo Orientado a Objetos.
5.1.2 DESARROLLO CONVENCIONAL
 Los resultados finales son impredecibles

 No hay forma de controlar lo que está sucediendo
 Los cambios organizativos afectan negativamente al proceso de desarrollo
EJEMPLO DE PROGRAMACIÓN CONVENCIONAL

10 CLS
20 A=10
30 INPUT B
40 IF B=A THEN GOTO 50 ELSE GOTO 70
50 PRINT “A Y B SON IGUALES”
60 GOTO 100
70 IF A>B THEN GOTO 80 ELSE GOTO 90
80 B= B + 1; GOTO 40
90 B= B - 1; GOTO 40
100 END
5.1.3 DESARROLLO ESTRUCTURADO
 Programación estructurada
 Diseño estructurado
 Análisis estructurado
Especificaciones funcionales:
 Gráficas
 Particionadas
 Mínimamente redundantes
“DAVID AUSUBEL”
SEMIPRESENCIAL
EJEMPLO DE PROGRAMACIÓN ESTRUCTURADA

PROGRAMA NUMEROS IGUALES
BEGIN
CLEARSCREEN;
A :=10 ;
INPUT B;
REPEAT
IF B=A THEN PRINT “A Y B SON IGUALES”
ELSE REDUCEDIFERENCIA(A, B);
UNTIL B=A;
END;
PROCEDURE REDUCEDIFENCIA(A, B);
BEGIN
IF A>B THEN B:= B+1
ELSE B:= B - 1
END
RELACION HISTORICA DE LAS PRINCIPALES METODOLOGIAS
5.1.4 DESARROLLO ORIENTADO A OBJETOS
La esencia del desarrollo orientado a objetos es la 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.
“DAVID AUSUBEL”
SEMIPRESENCIAL
5.2 METODOLOGÍAS ORIENTADAS A OBJETOS
 Se eliminan fronteras entre fases debido a la naturaleza iterativa del desarrollo

orientado al objeto.
 Aparece una nueva forma de concebir los lenguajes de programación y su uso al
incorporarse bibliotecas de clases y otros componentes reutilizables.
 Hay un alto grado de iteración y solapamiento, lo que lleva a una forma de trabajo
muy dinámica.
 Son interactivas e incrementales.
 Fácil de dividir el sistema en varios subsistemas independientes.

 Existencia de reglas predefinidas
 Cobertura total del ciclo de desarrollo
 Verificaciones intermedias
 Planificación y control
 Comunicación efectiva
 Utilización sobre un abanico amplio de proyectos
 Fácil formación
 Herramientas CASE
 Actividades que mejoren el proceso de desarrollo
 Soporte al mantenimiento
 Soporte de la reutilización de software
5.2.1 CLASIFICACIÓN DE LAS METODOLOGÍAS
 Estructuradas
o Orientadas a Procesos
o Orientadas a datos
 Jerárquicas
 No Jerárquicas
 Mixtas
 Orientadas a Objetos
 Para Sistemas de Tiempo Real
5.2.2 METODOLOGÍAS ESTRUCTURADAS
 Orientada a Procesos
o Diagramas de Flujo de Datos
o Diccionario de Datos
o Especificaciones de procesos
“DAVID AUSUBEL”
SEMIPRESENCIAL
5.2.3 METODOLOGÍA DE YOURDON/CONSTANTINE
 Realizar los DFD del sistema

 Realizar el diagrama de estructuras
 Evaluar el diseño
 Preparar el diseño para la implantación
METODOLOGIAS ORIENTADAS A DATOS JERARQUICOS
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 jerárquica de programa y después ordenar
detalladamente la lógica procedimental para que se ajuste a esta estructura.
El diseño lógico debe preceder y estar separado del diseño físico.
5.2.4 METODOLOGIAS ORIENTADAS A DATOS NO JERARQUICOS
METODOLOGÍA INGENIERÍA DE LA INFORMACIÓN
Planificación: construir una arquitectura de la Información y una estrategia que soporte los
objetivos de la organización
Análisis: comprender las áreas del negocio y determinar los requisitos del sistema
“DAVID AUSUBEL”
SEMIPRESENCIAL
Diseño: establecer el comportamiento del sistema deseado por el usuario y que sea
alcanzable por la tecnología
Construcción: construir sistemas que cumplan los tres niveles anteriores
METODOLOGIAS PARA SISTEMAS DE TIEMPO REAL
 Manejo de interrupciones
 Comunicación y sincronización entre tareas
 Gestión de procesos concurrentes
 Respuesta oportuna ante eventos externos
 Datos continuos o discretos
 Se está produciendo una evolución de las metodologías orientadas a objetos para
desarrollos de sistemas de tiempo real
PRINCIPALES METODOLOGIAS DE DESARROLLO
METODOLOGIA MERISE
Fases de la Metodología:
 Estudio Preliminar
 Estudio Detallado
 Implementación
 Realización y puesta en marcha
METODOLOGIA METRICA
FASE 0: Plan de Sistemas de Información

FASE 1: Análisis de Sistemas
FASE 2: Diseño de Sistemas
“DAVID AUSUBEL”
SEMIPRESENCIAL
FASE 3: Construcción de Sistemas

FASE 4: Implantación de Sistemas
5.3 CICLO DE VIDA DEL SISTEMA ORIENTADO A OBJETOS
Es el contenido de actividades secuenciales y organizadas para garantizar el éxito del

proceso.
Tipos:
 Clásico
 Cascada
 Prototipo
 Espiral
 Cuarta Generación
 Desarrollo rápido de aplicaciones
 Combinado
Fases:
ESTUDIO ANÁLISIS DISEÑO CONSTRUCCIÓN

IMPLEMENTACIÓN
PRELIMINAR ORIENTADO ORIENTADO ORIENTADO
A OBJETOS A OBJETOS A OBJETOS
Actividades
5.3.1 ESTUDIO PELIMINAR
Conocimiento general de la empresa y del proyecto o sistema.
Actividades:
 Recolección de información
“DAVID AUSUBEL”
SEMIPRESENCIAL
 Determinar la información empresarial

 Identificación y definición del proyecto (módulos)
 Fijación de objetivos
 Verificar la viabilidad
Conocimiento detallado del sistema.
¿Qué hace el sistema?
Actividades:
 Investigación detallada
 Descripción detallada del sistema (sistema actual SA)
 Estudio de requerimientos
 Definición del sistema propuesto (SP)
 Identificación y definición de objetos
 Diagramas del análisis orientado a objetos
 Modularidad (diagrama de paquetes DP)
 Funcionalidad de objetos (diagrama de casos de uso DCU, diagrama de clases
DC)
 Análisis de datos orientado a objetos (MOR)
 Comportamiento de objetos (diagrama de secuencias DS, diagrama de
colaboración DCol)
EVALUACIÓN ECONÓMICA (DE TODO EL PROYECTO)
 Documentación
 Planificación
5.3.3 DISEÑO ORIENTADO A OBJETOS
Proceso para generar las especificaciones técnicas del diseño para la construcción.
¿Cómo automatizar el sistema?
Actividades:
 Definir el ámbito del software

 Selección de plataforma
 Sistema operativo
 Administrador de base de datos
 Lenguaje de programación
 CASE orientado a objetos
 Especificar modularidad y abstracción del software
“DAVID AUSUBEL”
SEMIPRESENCIAL
 Generación de diagramas técnicos:

 Diseño de servicios (diagrama de estados DE, diagrama de actividades DA)
 Diseño de datos orientados a objetos (Modelo físico de datos MFD)
 Diseño de implementación e interfaz (diagrama de componentes DCom, diagrama
de distribución DD)
 Diseñar la administración del software
 Documentación
 Planificación
5.3.44CONSTRUCCION ORIENTADA A OBJETOS
Generar el software.
Actividades:
 Generación y pruebas a la base de datos

 Verificación y consistencia de interfaz
 Estandarización
 Consistencia
 Con los programas
 Con los datos especiales
 Codificación de módulos primarios
 Realizar pruebas
 Programar módulos transaccionales
 Realizar pruebas
 Generar módulos complementarios
o Usuarios
o Ayuda
o Ejecutables
 Integración del software
 Pruebas
 Generar el manual de usuario
 Documentación
 Planificación
5.3.5 IMPLEMENTACIÓN
Pasar a productividad el software con garantía de rendimiento.
Actividades:
 Verificar el rendimiento óptimo del centro de cómputo

 Instalación y configuración
 Capacitación de usuarios
 Pruebas reales con usuarios
“DAVID AUSUBEL”
SEMIPRESENCIAL
 Verificación de rendimiento con técnicos

 Garantizar el software
 Obtener la aprobación
“DAVID AUSUBEL”
SEMIPRESENCIAL
Secuencia de los Diagramas

“DAVID AUSUBEL”
SEMIPRESENCIAL
1.3.4 Estimación del esfuerzo
Desarrollo ANÁLISIS 40%

10-40% DISEÑO 20%
CONSTRUCCIÓN 40%
Mantenimiento
90-60%
Características:
Se asume un dominio metodológico

Desconocimiento del sistema, por lo que se da mayor tiempo al análisis.
5.4 OBJETO
Entidad real y abstracta con una estructura propia que le diferencia de otros.
Representación
Clase:
 Categoría
 Generación
 Pocas propiedades
 Pocos atributos
 Pocos servicios
 Baja aplicación
Objeto:
“DAVID AUSUBEL”
SEMIPRESENCIAL
 Instancia
 Especificación
 Varias propiedades
 Varios atributos
 Varios servicios
 Constante aplicación
5.4.1 CLASIFICACIÓN DE LOS OBJETOS:
Físicos
Ocupa un lugar en el espacio
Lógico
Hace referencia a ideas o definiciones
Evento
Transacción
Documento
Papeles normalizados
Estructura
De compras o lugar de trabajo
Estructura de un objeto
Atributos
Son los datos. Definen estructuras de datos para los modelos de datos.
Servicios
Son las actividades que modifican al objeto.
Características de los objetos
Encapsulamiento
Ocultamiento de información
Integra:
Atributos
Servicios
Herencia
Mecanismo para definir las propiedades de un objeto en base a existentes mediante
estructura jerárquica de nivel superior a descendientes.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Tipos:
 Simple
 Compuesta
 Polimorfismo
Es un conjunto o disposición de procedimientos o programas relacionados de manera que

juntos forman una sola unidad. Un conjunto de hechos, principios y reglas clasificadas y
dispuestas de manera ordenada mostrando un plan lógico en la unión de las partes. Un
método, plan o procedimiento de clasificación para hacer algo. También es un conjunto o
arreglo de elementos para realizar un objetivo predefinido en el procesamiento de la
Información. Esto se lleva a cabo teniendo en cuenta ciertos principios:
Debe presentarse y entenderse el dominio de la información de un problema.
Defina las funciones que debe realizar el Software.
Represente el comportamiento del software a consecuencias de acontecimientos

externos.
Divida en forma jerárquica los modelos que representan la información, funciones y

comportamiento.
El proceso debe partir desde la información esencial hasta el detalle de la

Implementación.
La función del Análisis puede ser dar soporte a las actividades de un negocio, o
desarrollar un producto que pueda venderse para generar beneficios. Para conseguir
este objetivo, un Sistema basado en computadoras hace uso de seis (6) elementos
fundamentales:
Software, que son Programas de computadora, con estructuras de datos y su

documentación que hacen efectiva la logística metodología o controles de requerimientos
del Programa.
Hardware, dispositivos electrónicos y electromecánicos, que proporcionan capacidad de

cálculos y funciones rápidas, exactas y efectivas (Computadoras, Censores, maquinarias,
bombas, lectores, etc.), que proporcionan una función externa dentro de los Sistemas.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Personal, son los operadores o usuarios directos de las herramientas del Sistema.
Base de Datos, una gran colección de informaciones organizadas y enlazadas al Sistema

a las que se accede por medio del Software.
Documentación, Manuales, formularios, y otra información descriptiva que detalla o da

instrucciones sobre el empleo y operación del Programa.
Procedimientos, o pasos que definen el uso específico de cada uno de los elementos o
componentes del Sistema y las reglas de su manejo y mantenimiento.
Un Análisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en

mente:
IDENTIFIQUE LAS NECESIDADES DEL CLIENTE.
Evalúe que conceptos tiene el cliente del sistema para establecer su viabilidad.
Realice un Análisis Técnico y económico.
Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos del
Sistema.
Establezca las restricciones de presupuestos y planificación temporal.
Cree una definición del sistema que forme el fundamento de todo el trabajo de Ingeniería.
Para lograr estos objetivos se requiere tener un gran conocimiento y dominio del
Hardware y el Software, así como de la Ingeniería humana (Manejo y Administración de
personal), y administración de base de datos.
5.4.3 OBJETIVOS DEL ANÁLISIS.
Identificación de Necesidades.
Es el primer paso del análisis del sistema, en este proceso en Analista se reúne con el
cliente y/o usuario (un representante institucional, departamental o cliente particular), e
identifican las metas globales, se analizan las perspectivas del cliente, sus necesidades y
requerimientos, sobre la planificación temporal y presupuestal, líneas de mercadeo y otros
puntos que puedan ayudar a la identificación y desarrollo del proyecto.
Algunos autores suelen llamar a esta parte ¨ Análisis de Requisitos ¨ y lo dividen en cinco
partes:
“DAVID AUSUBEL”
SEMIPRESENCIAL
 Reconocimiento del problema.

 Evaluación y Síntesis.
 Modelado.
 Especificación.
 Revisión.
Antes de su reunión con el analista, el cliente prepara un documento conceptual del

proyecto, aunque es recomendable que este se elabore durante la comunicación Cliente –
analista, ya que de hacerlo el cliente solo de todas maneras tendría que ser modificado,
durante la identificación de las necesidades.
MODELADO DE LA ARQUITECTURA DEL SISTEMA.
Cuando queremos dar a entender mejor lo que vamos a construir en el caso de edificios,
Herramientas, Aviones, Maquinas, se crea un modelo idéntico, pero en menor escala
(mas pequeño).
Sin embargo cuando aquello que construiremos es un Software, nuestro modelo debe
tomar una forma diferente, deben representar todas las funciones y subfunciones de un
Sistema. Los modelos se concentran en lo que debe hacer el sistema no en como lo hace,
estos modelos pueden incluir notación gráfica, información y comportamiento del Sistema.
Todos los Sistemas basados en computadoras pueden modelarse como transformación

de la información empleando una arquitectura del tipo entrada y salida.
ESPECIFICACIONES DEL SISTEMA.
Es un Documento que sirve como fundamento para la Ingeniería Hardware, software,

Base de datos, e ingeniería Humana. Describe la función y rendimiento de un Sistema
basado en computadoras y las dificultades que estarán presente durante su desarrollo.
Las Especificaciones de los requisitos del software se producen en la terminación de la
tarea del análisis.
5.4.4 ANÁLISIS DE OBJETOS
La abstracción es el nivel de detalle.

Desde el punto de vista del objeto:
Se le conoce como FACTORIZACION, que consiste en eliminar las diferencias entre
objetos, identificando las propiedades comunes para formar una jerarquia de datos.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Ejemplo:
PERSONA
CLIENTE común PROVEEDOR

Dirección
Nombre
Código Teléfono RUC

Fecha ingreso e-mail
Fecha nacimiento fax
. .
. .
Servicios:
Nivel de abstracción:
Servicios
Actividades
tareas MAYOR DETALLE
EJERC
ESTRUCTURA ENTRE OBJETOS
Es la generalización o parte de…

Define una estructura jerárquica de clasificación de lo general a lo específico. Se identifica
la herencia que existe.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Representación con UML:
TRANSPORTE
H
E
MARÍTIMO TERRESTRE AÉREO
R
E
URBANO INTERPROVINCIAL N
C
SELECTIVO POPULAR I
A
AGREGACIÓN O PARTE DE…
Define una estructura jerárquica de formación o composición de las partes al todo.

Identifica CARDINALIDAD.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Representación UML:
PC
DISPOSITIVOS CPU
ENTRADA SALIDA CASE MAINBOARD
ALMACENAMIENTO AT ATX
TIPOS DE AGRAGACIÓN:
Por referencia
Por valor
COMUNICACIÓN ENTRE DATOS
Consiste en ejecutar un servicio del objeto receptor mediante el mensaje del objeto
emisor.
Ejemplo.:
CATEGORÍA PRODUCTO
IngresarNuevaCategoria ingresarNuevoProducto
INSTITUTOREPRESENTACIÓN
ELEMENTO
TECNOLÓGICO SUPERIOR
DESCRIPCIÓN
“DAVID AUSUBEL”
SEMIPRESENCIAL
Objeto emisor objeto receptor
IngresarNuevoProducto
Relaciones:
 Estructura entre datos

 Generalización
 Agrupación
 Estructura de almacenamiento
o 1-1
o 1-n
o N-n
 Mensaje
DIAGRAMAS TÉCNICOS ORIENTADOS A OBJETOS
MOLULARIDAD
DIAGRAMA DE PAQUETES (DP)

Representa la modularidad del proyecto o del sistema.
ELEMENTO REPRESENTACIÓN DESCRIPCIÓN

Sistema
Subsistema
Módulos
Puede ser un área
PAQUETE organizacional
Sistemas externos que se
tienen comunicación
Contenido de detalle
técnico
RELACIÓN ENTRE
COMUNICACIÓN ----------------- PAQUETES
FUNCIONALIDAD
DIAGRAMA DE CASOS DE USO (DCU)

Representa los casos de uso o ACTIVIDADES O FUNCIONALIDAD del sistema.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Agente
Referencia a una
persona o grupo de
ACTOR personas
Área organizacional o
punto de trabajo
CASO DE USO
Es una actividad
Es una comunicación
y la ejecución del caso
RELACIÓN
de uso.
Identifica secuencia
de casos de uso
Representa el entorno que influye y ejecuta la funcionalidad del sistema o módulo.
5.5 EJERCICIO PROPUESTO:
El departamento de obras públicas de una gran ciudad ha decidido realizar un sistema

basado en computadora de seguimiento y reparación de baches (SSRB). A medida que
se informa sobre cada bache, se le asigna un número de identificación y se guarda con la
calle en la que se encuentra, su tamaño (en escala de 1 a 10), su posición (en el medio, o
a un lado, entre otros), su distrito (determinado a partir de la calle) y una prioridad de
reparación.(Determinada a partir de su tamaño). A cada bache se asocian datos de
petición de obra, incluyendo la ubicación y el tamaño, la brigada de reparación identificada
por un número, la cantidad de trabajadores de la brigada, el equipamiento asignado, las
horas de reparación, el estado del bache (obra en curso, reparado, reparación temporal,
no reparado), la cantidad de material de relleno usado y el coste de la reparación
(calculado con las horas dedicadas, el número de trabajadores, el material y el
equipamiento utilizado). Finalmente, se crea un archivo de daños para mantener la
información sobre los daños reportados debidos a la existencia del bache, incluyendo el
nombre del ciudadano, su dilección, su teléfono, el tipo daño y el coste del subsanamiento
del daño. El sistema SSRB es un sistema interactivo. Utilice el análisis estructurado para
modelizar el SSRB.
“DAVID AUSUBEL”
SEMIPRESENCIAL
DIAGRAMA DE CLASES (DC)

Primer diagrama sin módulos.
DIAGRAMA DE INTERFAZ
EJERCICIO PROPUETO:
El súper-comisariato está ampliando su sistema y desea también integrarlo al sistema

actual que controla el inventario de bodega.
Se requiere que el sistema controle todo el mundo transaccional como fecha, origen o
destino y las diferentes valoraciones, aquí se realizan compras, ventas, consumos,
transferencias y devoluciones, las devoluciones únicamente en compras y ventas,
además, se requiere controlar los parámetros de funcionalidad del sistema como el IVA y
los porcentajes para realizar las diferentes cotizaciones de acuerdo a la ocasión y al
destino. El destino principalmente es nuestro cliente, el cual puede ser un empleado,
administrador e incluso el mismo usuario del sistema. El usuario del sistema se configura
por globalidad que es un administrador y por especialidad que manejará módulos
específicos del sistema.
Como requerimientos de amigabilidad del software se requiere que la interfaz sea para
acceso, configuración o manipulación, cada una de ellas compuesta por ventanas, menús
y controles, cabe indicar que existen varios tipos de controles.
ANÁLISIS DE DATOS ORIENTADO A OBJETOS
MODELOS DE DATOS
Un modelo de datos es una serie de conceptos que puede utilizarse para describir un
conjunto de datos y las operaciones para manipularlos. Hay dos tipos de modelos de
datos: los modelos conceptuales y los modelos lógicos. Los modelos conceptuales se
utilizan para representar la realidad a un alto nivel de abstracción. Mediante los modelos
conceptuales se puede construir una descripción de la realidad fácil de entender. En los
modelos lógicos, las descripciones de los datos tienen una correspondencia sencilla con
la estructura física de la base de datos.
En el diseño de bases de datos se usan primero los modelos conceptuales para lograr
una descripción de alto nivel de la realidad, y luego se transforma el esquema conceptual
en un esquema lógico. El motivo de realizar estas dos etapas es la dificultad de abstraer
la estructura de una base de datos que presente cierta complejidad. Un esquema es un
conjunto de representaciones lingüísticas o gráficas que describen la estructura de los
datos de interés.
Los modelos conceptuales deben ser buenas herramientas para representar la realidad,
por lo que deben poseer las siguientes cualidades:
Expresividad: deben tener suficientes conceptos para expresar perfectamente la realidad.
Simplicidad: deben ser simples para que los esquemas sean fáciles de entender.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Minimalidad: cada concepto debe tener un significado distinto.

Formalidad: todos los conceptos deben tener una interpretación única, precisa y bien
definida.
En general, un modelo no es capaz de expresar todas las propiedades de una realidad
determinada, por lo que hay que añadir aserciones que complementen el esquema.
EL MODELO E-R
El modelo E-R es el modelo conceptual más utilizado para el diseño conceptual de bases
de datos. Fue introducido por Peter Chen en 1976. El modelo E-R está formado por un
conjunto de conceptos que permiten describir la realidad mediante un conjunto de
representaciones gráficas y lingüísticas.
Originalmente, el modelo E-R sólo incluía los conceptos de entidad, relación y atributo.
Más tarde, se añadieron otros conceptos, como los atributos compuestos y las jerarquías
de generalización, en lo que se ha denominado modelo entidad-relación extendido.
ENTIDAD
Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona,
concepto abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes, empresas,
oficios, diseños de productos, conciertos, excursiones, etc. Las entidades se representan
gráficamente mediante rectángulos y su nombre aparece en la parte superior. Un nombre
de entidad sólo puede aparecer una vez en el esquema conceptual.
EMPLEADOS
# CI
* Nombre
* Apellido
* Dirección
º Teléfono
* Cargo
º Jefe
Hay dos tipos de entidades: fuertes y débiles. Una entidad débil es una entidad cuya
existencia depende de la existencia de otra entidad. Una entidad fuerte es una entidad
que existe pos sí sola y no depende de la existencia de otras.
RELACIÓN (INTERRELACIÓN)
“DAVID AUSUBEL”
SEMIPRESENCIAL
Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene dos
extremos, cada uno de ellos con un nombre que describe su función. Las relaciones se
representan gráficamente mediante líneas continuas o entrecortadas, dependiendo de la
opcionalidad de las mismas.
R1 R2
Dueño de
Perteneciente a
Relación 1:N
Obligatorio - Opcional
Las entidades que están involucradas en una determinada relación se denominan

entidades participantes. El número de participantes en una relación es lo que se
denomina grado de la relación. Por lo tanto, una relación en la que participan dos
entidades es una relación binaria; si son tres las entidades participantes, la relación es
ternaria; entre otros.
Una relación recursiva es una relación donde la misma entidad participa más de una vez
en la relación con distintos papeles. El nombre de estos papeles es importante para
determinar la función de cada participación.
La cardinalidad con la que una entidad participa en una relación especifica el número
mínimo y el número máximo de correspondencias en las que puede tomar parte cada
ocurrencia de dicha entidad. La participación de una entidad en una relación es obligatoria
(total) si la existencia de cada una de sus ocurrencias requiere la existencia de, al menos,
una ocurrencia de la otra entidad participante. Si no, la participación es opcional (parcial).
Las reglas que definen la cardinalidad de las relaciones son las reglas de negocio.
A veces, surgen problemas cuando se está diseñado un esquema conceptual. Estos

problemas, denominados trampas, suelen producirse a causa de una mala interpretación
en el significado de alguna relación, por lo que es importante comprobar que el esquema
conceptual carece de dichas trampas. En general, para encontrar las trampas, hay que
asegurarse de que se entiende completamente el significado de cada relación. Si no se
entienden las relaciones, se puede crear un esquema que no represente fielmente la
realidad.
Una de las trampas que pueden encontrarse ocurre cuando el esquema representa una
relación entre entidades, pero el camino entre algunas de sus ocurrencias es ambiguo. El
“DAVID AUSUBEL”
SEMIPRESENCIAL
modo de resolverla es reestructurando el esquema para representar la asociación entre

las entidades correctamente.
Otra de las trampas sucede cuando un esquema sugiere la existencia de una relación
entre entidades, pero el camino entre una y otra no existe para algunas de sus instancias.
En este caso, se produce una pérdida de información que se puede subsanar
introduciendo la relación que sugería el esquema y que no estaba representada.
ATRIBUTO
Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los
atributos representan las propiedades básicas de las entidades y de las relaciones. Toda
la información extensiva es portada por los atributos. Gráficamente, se representan
mediante nombres escritos al interior de los rectángulos que representan a las entidades.
Cada atributo tiene un conjunto de valores asociados denominado dominio. El dominio

define todos los valores posibles que puede tomar un atributo. Puede haber varios
atributos definidos sobre un mismo dominio.
Por su opcionalidad, los atributos se dividen en obligatorios y opcionales. Los obligatorios

son aquellos que deben tener un valor válido en cada instancia de la entidad y de ninguna
manera puede ser nulo. Por otro lado, los atributos opcionales pueden como no pueden
tener un valor válido en cada instancia de una entidad.
Los atributos también pueden clasificarse en monovalentes o polivalentes. Un atributo

monovalente es aquel que tiene un solo valor para cada ocurrencia de la entidad o
relación a la que pertenece. Un atributo polivalente es aquel que tiene varios valores para
cada ocurrencia de la entidad o relación a la que pertenece. A estos atributos también se
les denomina multivaluados, y pueden tener un número máximo y un número mínimo de
valores. La cardinalidad de un atributo indica el número mínimo y el número máximo de
valores que puede tomar para cada ocurrencia de la entidad o relación a la que
pertenece. El valor por omisión es 1. .
CLAVES
Una clave de una entidad es un atributo o conjunto de atributos que , de alguna manera,
identifica cada ocurrencia de esa entidad. Las claves, dentro del modelo Entidad –
Relación, se clasifican en los siguientes tipos:
 Superclaves
 Claves Candidatas
 Clave Primaria
 Claves Alternas
“DAVID AUSUBEL”
SEMIPRESENCIAL
Toda entidad tiene al menos una clave primaria y puede tener varias claves alternas. Las
claves primarias se representan gráficamente con un signo de numeral junto al nombre
del mismo.
JERARQUÍA DE GENERALIZACIÓN
Una entidad E es una generalización de un grupo de entidades E1, E2,…., En. Si cada
ocurrencia de cada una de esas entidades es también una ocurrencia de E.
Cada jerarquía es total o parcial, y exclusiva o superpuesta:
Es total si cada instancia de la entidad genérica corresponde al menos a una instancia de

las subentidades.
Es parcial si existe alguna instancia de la entidad genérica que no corresponde con

ninguna ocurrencia de ninguna subentidad.
Una jerarquía es exclusiva si cada instancia de la entidad genérica corresponde, como

mucho, con una instancia de una sola de las subentidades.
Es superpuesta si existe alguna instancia de la entidad genérica que corresponda a

instancias de dos o más subentidades diferentes.
DISEÑO LÓGICO DE BASES DE DATOS
El objetivo del diseño lógico es convertir los esquemas conceptuales locales en un

esquema lógico global que se ajuste al modelo de DBMS sobre el que se vaya a
implementar el sistema. Mientras que el objetivo fundamental del diseño conceptual es la
compleción y expresividad de los esquemas conceptuales locales, el objetivo del diseño
lógico es obtener una representación que use, del modo más eficiente posible, los
recursos que el modelo de DBMS posee para estructurar los datos y para modelar las
restricciones
Los modelos de bases de datos más extendidos son el modelo relacional, el modelo de
red y el modelo jerárquico. El modelo orientado a objetos es también muy popular, pero
no existe un modelo estándar orientado a objetos.
El modelo relacional (y los modelos previos) carecen de ciertos rasgos de abstracción que
se usan en los modelos conceptuales. Por lo tanto, un primer paso en la fase del diseño
lógico consistirá en la conversión de esos mecanismos de representación de alto nivel en
términos de las estructuras de bajo nivel disponibles en el modelo relacional.
METODOLOGÍA DE DISEÑO LÓGICO EN EL MODELO RELACIONAL

“DAVID AUSUBEL”
SEMIPRESENCIAL
La metodología que se va a seguir para el diseño lógico en el modelo relacional consta de

dos fases, cada una de ellas compuesta por varios pasos que se detallan a continuación.
 Construir y validar los esquemas lógicos locales para cada vista de usuario.
 Convertir los esquemas conceptuales locales en esquemas lógicos locales.
 Derivar un conjunto de relaciones (tablas) para cada esquema lógico local.
 Validar cada esquema mediante la normalización.
 Validar cada esquema frente a las transacciones del usuario.
 Dibujar el diagrama entidad-relación.
 Definir las restricciones de integridad.
 Revisar cada esquema lógico local con el usuario correspondiente.
 Construir y validar el esquema lógico global.
 Mezclar los esquemas lógicos locales en un esquema lógico global.
 Validar el esquema lógico global.
 Estudiar el crecimiento futuro.
 Dibujar el diagrama entidad-relación final.
 Revisar el esquema lógico global con los usuarios.
En la primera fase, se construyen los esquemas lógicos locales para cada vista de usuario
y se validan. En esta fase se refinan los esquemas conceptuales creados durante el
diseño conceptual, eliminando las estructuras de datos que no se pueden implementar de
manera directa sobre el modelo que soporta el DBMS, en el caso que nos ocupa, el
modelo relacional. Una vez hecho esto, se obtiene un primer esquema lógico que se
valida mediante la normalización y frente a las transacciones que el sistema debe llevar a
cabo, tal y como se refleja en las especificaciones de requisitos de usuario. El esquema
lógico ya validado se puede utilizar como base para el desarrollo de prototipos. Una vez
finalizada esta fase, se dispone de un esquema lógico para cada vista de usuario que es
correcto, comprensible y sin ambigüedad.
Convertir los esquemas conceptuales locales en esquemas lógicos locales

En este paso, se eliminan de cada esquema conceptual las estructuras de datos que los
sistemas relacionales no modelan directamente:
Eliminar las relaciones de muchos a muchos, sustituyendo cada una de ellas por una
nueva entidad intermedia y dos relaciones de uno a muchos de esta nueva entidad con
las entidades originales. La nueva entidad será débil, ya que sus ocurrencias dependen
de la existencia de ocurrencias en las entidades originales.
Eliminar las relaciones entre tres o más entidades, sustituyendo cada una de ellas por una
nueva entidad (débil) intermedia que se relaciona con cada una de las entidades
originales. La cardinalidad de estas nuevas relaciones binarias dependerá de su
significado.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Eliminar las relaciones recursivas, sustituyendo cada una de ellas por una nueva entidad
(débil) y dos relaciones binarias de esta nueva entidad con la entidad original. La
cardinalidad de estas relaciones dependerá de su significado.
Eliminar las relaciones con atributos, sustituyendo cada una de ellas por una nueva
entidad (débil) y las relaciones binarias correspondientes de esta nueva entidad con las
entidades originales. La cardinalidad de estas relaciones dependerá del tipo de la relación
original y de su significado.
Eliminar los atributos multivaluados, sustituyendo cada uno de ellos por una nueva
entidad (débil) y una relación binaria de uno a muchos con la entidad original.
Revisar las relaciones de uno a uno, ya que es posible que se hayan identificado dos
entidades que representen el mismo objeto (sinónimos). Si así fuera, ambas entidades
deben integrarse en una sola.
Eliminar las relaciones redundantes. Una relación es redundante cuando se puede

obtener la misma información que ella aporta mediante otras relaciones. El hecho de que
haya dos caminos diferentes entre dos entidades no implica que uno de los caminos
corresponda a una relación redundante, eso dependerá del significado de cada relación.
Una vez finalizado este paso es más correcto referirse a los esquemas conceptuales
locales refinados como esquemas lógicos locales, ya que se adaptan al modelo de base
de datos que soporta el DBMS escogido.
DERIVAR UN CONJUNTO DE RELACIONES (TABLAS) PARA CADA ESQUEMA

LÓGICO LOCAL
En este paso, se obtiene un conjunto de relaciones (tablas) para cada uno de los
esquemas lógicos locales en donde se representen las entidades y relaciones entre
entidades, que se describen en cada una de las vistas que los usuarios tienen de la
empresa. Cada relación de la base de datos tendrá un nombre, y el nombre de sus
atributos aparecerá, a continuación, entre paréntesis. El atributo o atributos que forman la
clave primaria se subrayan. Las claves ajenas, mecanismo que se utiliza para representar
las relaciones entre entidades en el modelo relacional, se especifican aparte indicando la
relación (tabla) a la que hacen referencia.
A continuación, se describe cómo las relaciones (tablas) del modelo relacional

representan las entidades y relaciones que pueden aparecer en los esquemas lógicos.
Entidades fuertes. Crear una relación para cada entidad fuerte que incluya todos sus
atributos simples. De los atributos compuestos incluir sólo sus componentes.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Cada uno de los identificadores de la entidad será una clave candidata. De entre las
claves candidatas hay que escoger la clave primaria; el resto serán claves alternativas.
Para escoger la clave primaria entre las claves candidatas se pueden seguir estas
indicaciones:
 Escoger la clave candidata que tenga menos atributos.

 Escoger la clave candidata cuyos valores no tengan probabilidad de cambiar en el
futuro.
 Escoger la clave candidata cuyos valores no tengan probabilidad de perder la
unicidad en el futuro.
 Escoger la clave candidata con el mínimo número de caracteres (si es de tipo
texto).
 Escoger la clave candidata más fácil de utilizar desde el punto de vista de los
usuarios.
ENTIDADES DÉBILES
Crear una relación para cada entidad débil incluyendo todos sus atributos simples. Añadir
una clave ajena a la entidad de la que depende. Para ello, se incluye la clave primaria de
la relación que representa a la entidad padre en la nueva relación creada para la entidad
débil. A continuación, determinar la clave primaria de la nueva relación.
Relaciones binarias de uno a uno. Para cada relación binaria se incluyen los atributos de
la clave primaria de la entidad padre en la relación (tabla) que representa a la entidad hijo,
para actuar como una clave ajena. La entidad hijo es la que participa de forma total
(obligatoria) en la relación, mientras que la entidad padre es la que participa de forma
parcial (opcional). Si las dos entidades participan de forma total o parcial en la relación, la
elección de padre e hijo es arbitraria. Además, en caso de que ambas entidades
participen de forma total en la relación, se tiene la opción de integrar las dos entidades en
una sola relación (tabla). Esto se suele hacer si una de las entidades no participa en
ninguna otra relación.
Relaciones binarias de uno a muchos. Como en las relaciones de uno a uno, se incluyen
los atributos de la clave primaria de la entidad padre en la relación (tabla) que representa
a la entidad hijo, para actuar como una clave ajena. Pero ahora, la entidad padre es la de
``la parte del muchos'' (cada padre tiene muchos hijos), mientras que la entidad hijo es la
de ``la parte del uno'' (cada hijo tiene un solo padre).
Jerarquías de generalización. En las jerarquías, se denomina entidad padre a la entidad

genérica y entidades hijo a las subentidades. Hay tres opciones distintas para representar
las jerarquías. La elección de la más adecuada se hará en función de su tipo (total/parcial,
exclusiva/superpuesta).
“DAVID AUSUBEL”
SEMIPRESENCIAL
Crear una relación por cada entidad. Las relaciones de las entidades hijo heredan como
clave primaria la de la entidad padre. Por lo tanto, la clave primaria de las entidades hijo
es también una clave ajena al padre. Esta opción sirve para cualquier tipo de jerarquía,
total o parcial y exclusiva o superpuesta.
Crear una relación por cada entidad hijo, heredando los atributos de la entidad padre.
Esta opción sólo sirve para jerarquías totales y exclusivas.
Integrar todas las entidades en una relación, incluyendo en ella los atributos de la entidad
padre, los atributos de todos los hijos y un atributo discriminativo para indicar el caso al
cual pertenece la entidad en consideración. Esta opción sirve para cualquier tipo de
jerarquía. Si la jerarquía es superpuesta, el atributo discriminativo será multievaluado.
Una vez obtenidas las relaciones con sus atributos, claves primarias y claves ajenas, sólo
queda actualizar el diccionario de datos con los nuevos atributos que se hayan
identificado en este paso.
VALIDAR CADA ESQUEMA MEDIANTE LA NORMALIZACIÓN
La normalización se utiliza para mejorar el esquema lógico, de modo que satisfaga ciertas
restricciones que eviten la duplicidad de datos. La normalización garantiza que el
esquema resultante se encuentra más próximo al modelo de la empresa, que es
consistente y que tiene la mínima redundancia y la máxima estabilidad.
La normalización es un proceso que permite decidir a qué entidad pertenece cada

atributo. Uno de los conceptos básicos del modelo relacional es que los atributos se
agrupan en relaciones (tablas) porque están relacionados a nivel lógico. En la mayoría de
las ocasiones, una base de datos normalizada no proporciona la máxima eficiencia, sin
embargo, el objetivo ahora es conseguir una base de datos normalizada por las siguientes
razones:
Un esquema normalizado organiza los datos de acuerdo a sus dependencias funcionales,

es decir, de acuerdo a sus relaciones lógicas.
El esquema lógico no tiene porqué ser el esquema final. Debe representar lo que el
diseñador entiende sobre la naturaleza y el significado de los datos de la empresa. Si se
establecen unos objetivos en cuanto a prestaciones, el diseño físico cambiará el esquema
lógico de modo adecuado. Una posibilidad es que algunas relaciones normalizadas se
desnormalicen. Pero la desnormalización no implica que se haya malgastado tiempo
normalizando, ya que mediante este proceso el diseñador aprende más sobre el
significado de los datos. De hecho, la normalización obliga a entender completamente
cada uno de los atributos que se han de representar en la base de datos.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Un esquema normalizado es robusto y carece de redundancias, por lo que está libre de

ciertas anomalías que éstas pueden provocar cuando se actualiza la base de datos.
Los equipos informáticos de hoy en día son mucho más potentes, por lo que en ocasiones
es más razonable implementar bases de datos fáciles de manejar (las normalizadas), a
costa de un tiempo adicional de proceso.
La normalización produce bases de datos con esquemas flexibles que pueden extenderse
con facilidad.
El objetivo de este paso es obtener un conjunto de relaciones que se encuentren en la

forma normal de Boyce-Codd. Para ello, hay que pasar por la primera, segunda y tercera
formas normales. El proceso de normalización se describe más adelante en este texto.
DIBUJAR EL DIAGRAMA ENTIDAD-RELACIÓN
En este momento, se puede dibujar el diagrama entidad-relación final para cada vista de
usuario que recoja la representación lógica de los datos desde su punto de vista. Este
diagrama habrá sido validado mediante la normalización y frente a las transacciones de
los usuarios.
DEFINIR LAS RESTRICCIONES DE INTEGRIDAD
Las restricciones de integridad son reglas que se quieren imponer para proteger la base
de datos, de modo que no pueda llegar a un estado inconsistente. Hay cinco tipos de
restricciones de integridad.
Datos requeridos. Algunos atributos deben contener valores en todo momento, es decir,
no admiten nulos.
Restricciones de dominios. Todos los atributos tienen un dominio asociado, que es el

conjunto los valores que cada atributo puede tomar.
Integridad de entidad. La clave primaria de una entidad no puede ser nula, por lo tanto, las
claves primarias de las relaciones no admiten nulos.
Integridad referencial. Una clave extranjera enlaza cada tupla de la relación hijo con la
tupla de la relación padre que tiene el mismo valor en su clave primaria. La integridad
referencial dice que si una clave ajena tiene un valor (si es no nula), ese valor debe ser
uno de los valores de la clave primaria a la que referencia. Hay varios aspectos a tener en
cuenta sobre las claves ajenas para lograr que se cumpla la integridad referencial.
“DAVID AUSUBEL”
SEMIPRESENCIAL
¿Admite nulos la clave ajena? Cada clave ajena expresa una relación. Si la participación
de la entidad hijo en la relación es total, entonces la clave ajena no admite nulos; si es
parcial, la clave ajena debe aceptar nulos.
¿Qué hacer cuando se quiere borrar una ocurrencia de la entidad padre que tiene algún
hijo? O lo que es lo mismo, ¿qué hacer cuando se quiere borrar una tupla que está siendo
referenciada por otra tupla a través de una clave ajena? Hay varias respuestas posibles:
Restringir: no se pueden borrar tuplas que están siendo referenciadas por otras tuplas.
Propagar: se borra la tupla deseada y se propaga el borrado a todas las tuplas que le
hacen referencia.
Anular: se borra la tupla deseada y todas las referencias que tenía se ponen,
automáticamente, a nulo (esta respuesta sólo es válida si la clave ajena acepta nulos).
Valor por defecto: se borra la tupla deseada y todas las referencias toman,
automáticamente, el valor por defecto (esta respuesta sólo es válida si se ha especificado
un valor por defecto para la clave ajena).
No comprobar: se borra la tupla deseada y no se hace nada para garantizar que se sigue
cumpliendo la integridad referencial.
¿Qué hacer cuando se quiere modificar la clave primaria de una tupla que está siendo
referenciada por otra tupla a través de una clave ajena? Las respuestas posibles son las
mismas que en el caso anterior. Cuando se escoge propagar, se actualiza la clave
primaria en la tupla deseada y se propaga el cambio a los valores de clave ajena que le
hacían referencia.
Reglas de negocio. Cualquier operación que se realice sobre los datos debe cumplir las
restricciones que impone el funcionamiento de la empresa.
Todas las restricciones de integridad establecidas en este paso se deben reflejar en el
diccionario de datos para que puedan ser tenidas en cuenta durante la fase del diseño
físico.
Revisar cada esquema lógico local con el usuario correspondiente

Para garantizar que cada esquema lógico local es una fiel representación de la vista del
usuario lo que se debe hacer es comprobar con él que lo reflejado en el esquema y en la
documentación es correcto y está completo.
Relación entre el esquema lógico y los diagramas de flujo de datos
El esquema lógico refleja la estructura de los datos a almacenar que maneja la empresa.
Un diagrama de flujo de datos muestra cómo se mueven los datos en la empresa y los
almacenes en donde se guardan. Si se han utilizado diagramas de flujo de datos para
“DAVID AUSUBEL”
SEMIPRESENCIAL
modelar las especificaciones de requisitos de usuario, se pueden utilizar para comprobar

la consistencia y completitud del esquema lógico desarrollado. Para ello:
Cada almacén de datos debe corresponder con una o varias entidades completas.
Los atributos en los flujos de datos deben corresponder a alguna entidad.
Los esquemas lógicos locales obtenidos hasta este momento se integrarán en un solo
esquema lógico global en la siguiente fase para modelar los datos de toda la empresa.
NORMALIZACIÓN
La normalización es una técnica para diseñar la estructura lógica de los datos de un

sistema de información en el modelo relacional, desarrollada por E. F. Codd en 1972. Es
una estrategia de diseño de abajo a arriba: se parte de los atributos y éstos se van
agrupando en relaciones (tablas) según su afinidad. Aquí no se utilizará la normalización
como una técnica de diseño de bases de datos, sino como una etapa posterior a la
correspondencia entre el esquema conceptual y el esquema lógico, que elimine las
dependencias entre atributos no deseadas. Las ventajas de la normalización son las
siguientes:
 Evita anomalías en inserciones, modificaciones y borrados.

 Mejora la independencia de datos.
 No establece restricciones artificiales en la estructura de los datos.
Uno de los conceptos fundamentales en la normalización es el de dependencia funcional.

Una dependencia funcional es una relación entre atributos de una misma relación (tabla).
Si x e y son atributos de la relación R, se dice que x es funcionalmente dependiente de y
(se denota por x → y) si cada valor de x tiene asociado un solo valor de y (x e y pueden
constar de uno o varios atributos). A x se le denomina determinante, ya que x determina el
valor de y. Se dice que el atributo y es completamente dependiente de x si depende
funcionalmente de x y no depende de ningún subconjunto de x.
La dependencia funcional es una noción semántica. Si hay o no dependencias funcionales

entre atributos no lo determina una serie abstracta de reglas, sino, más bien, los modelos
mentales del usuario y las reglas de negocio de la organización o empresa para la que se
desarrolla el sistema de información. Cada dependencia funcional es una clase especial
de regla de integridad y representa una relación de uno a muchos.
En el proceso de normalización se debe ir comprobando que cada relación (tabla) cumple

una serie de reglas que se basan en la clave primaria y las dependencias funcionales.
Cada regla que se cumple aumenta el grado de normalización. Si una regla no se cumple,
la relación se debe descomponer en varias relaciones que sí la cumplan.
“DAVID AUSUBEL”
SEMIPRESENCIAL
La normalización se lleva a cabo en una serie pasos. Cada paso corresponde a una forma
normal que tiene unas propiedades. Conforme se va avanzando en la normalización, las
relaciones tienen un formato más estricto (más fuerte) y, por lo tanto, son menos
vulnerables a las anomalías de actualización. El modelo relacional sólo requiere un
conjunto de relaciones en primera forma normal. Las restantes formas normales son
opcionales. Sin embargo, para evitar las anomalías de actualización, es recomendable
llegar al menos a la tercera forma normal.
PRIMERA FORMA NORMAL (1FN)
Una relación está en primera forma normal si, y sólo si, todos los dominios de la misma
contienen valores atómicos, es decir, no hay grupos repetitivos. Si se ve la relación
gráficamente como una tabla, estará en 1FN si tiene un solo valor en la intersección de
cada fila con cada columna.
Si una relación no está en 1FN, hay que eliminar de ella los grupos repetitivos. Un grupo
repetitivo será el atributo o grupo de atributos que tiene múltiples valores para cada tupla
de la relación. Hay dos formas de eliminar los grupos repetitivos. En la primera, se repiten
los atributos con un solo valor para cada valor del grupo repetitivo. De este modo, se
introducen redundancias ya que se duplican valores, pero estas redundancias se
eliminarán después mediante las restantes formas normales. La segunda forma de
eliminar los grupos repetitivos consiste en poner cada uno de ellos en una relación aparte,
heredando la clave primaria de la relación en la que se encontraban.
Un conjunto de relaciones se encuentra en 1FN si ninguna de ellas tiene grupos

repetitivos.
SEGUNDA FORMA NORMAL (2FN)
Una relación está en segunda forma normal si, y sólo si, está en 1FN y, además, cada
atributo que no está en la clave primaria es completamente dependiente de la clave
primaria.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más
atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo
atributo), entonces también está en 2FN. Las relaciones que no están en 2FN pueden
sufrir anomalías cuando se realizan actualizaciones.
Para pasar una relación en 1FN a 2FN hay que eliminar las dependencias parciales de la
clave primaria. Para ello, se eliminan los atributos que son funcionalmente dependientes y
se ponen en una nueva relación con una copia de su determinante (los atributos de la
clave primaria de los que dependen).
“DAVID AUSUBEL”
SEMIPRESENCIAL
TERCERA FORMA NORMAL (3FN)
Una relación está en tercera forma normal si, y sólo si, está en 2FN y, además, cada
atributo que no está en la clave primaria no depende transitivamente de la clave primaria.
La dependencia x →y es transitiva si existen las dependencias, x →z ; z →y siendo x, y, z
atributos o conjuntos de atributos de una misma relación.
Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en 1FN,
todavía pueden sufrir anomalías frente a las actualizaciones. Para pasar una relación de
2FN a 3FN hay que eliminar las dependencias transitivas. Para ello, se eliminan los
atributos que dependen transitivamente y se ponen en una nueva relación con una copia
de su determinante (el atributo o atributos no clave de los que dependen).
FORMA NORMAL DE BOYCE-CODD (BCNF)
Una relación está en la forma normal de Boyce-Codd si, y sólo si, todo determinante es
una clave candidata.
La 2FN y la 3FN eliminan las dependencias parciales y las dependencias transitivas de la
clave primaria. Pero este tipo de dependencias todavía pueden existir sobre otras claves
candidatas, si éstas existen. La BCNF es más fuerte que la 3FN, por lo tanto, toda
relación en BCNF está en 3FN.
La violación de la BCNF es poco frecuente ya que se da bajo ciertas condiciones que
raramente se presentan. Se debe comprobar si una relación viola la BCNF si tiene dos o
más claves candidatas compuestas que tienen al menos un atributo en común.
COMPORTAMIENTO DE OBJETOS
DIAGRAMA SECUENCIAL (DS)

En éste diagrama se identifican los escenarios. El escenario representa el conjunto
secuencial de servicios, definiendo la interacción entre objetos.
INTERACCIÓN:
Acción
Reacción
Elementos:
“DAVID AUSUBEL”
SEMIPRESENCIAL
DISEÑO ORIENTADO A OBJETOS
INTRODUCCIÓN
Conceptos y principios:
El Diseño de Sistemas se define el proceso de aplicar ciertas técnicas y principios con el

propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como
para permitir su interpretación y realización física.
La etapa del Diseño del Sistema encierra cuatro etapas:
El diseño de los datos.
Trasforma el modelo de dominio de la información, creado durante el análisis, en las

estructuras de datos necesarios para implementar el Software.
DISEÑO ARQUITECTÓNICO.
Define la relación entre cada uno de los elementos estructurales del programa.
El Diseño de la Interfaz.
Describe como se comunica el Software consigo mismo, con los sistemas que operan
junto con el y con los operadores y usuarios que lo emplean.
EL DISEÑO DE PROCEDIMIENTOS.
Transforma elementos estructurales de la arquitectura del programa. La importancia del

Diseño del Software se puede definir en una sola palabra Calidad, dentro del diseño es
“DAVID AUSUBEL”
SEMIPRESENCIAL
donde se fomenta la calidad del Proyecto. El Diseño es la única manera de materializar

con precisión los requerimientos del cliente.
El Diseño del Software es un proceso y un modelado a la vez. El proceso de Diseño es un

conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del
Sistema a construir. A lo largo del diseño se evalúa la calidad del desarrollo del proyecto
con un conjunto de revisiones técnicas:
El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de

análisis y debe acumular todos los requisitos implícitos que desea el cliente.
Debe ser una guía que puedan leer y entender los que construyan el código y los que
prueban y mantienen el Software.
El Diseño debe proporcionar una completa idea de lo que es el Software, enfocando los
dominios de datos, funcional y comportamiento desde el punto de vista de la
Implementación.
Para evaluar la calidad de una presentación del diseño, se deben establecer criterios
técnicos para un buen diseño como son:
Un diseño debe presentar una organización jerárquica que haga un uso inteligente del
control entre los componentes del software.
El diseño debe ser modular, es decir, se debe hacer una partición lógica del Software en
elementos que realicen funciones y subfunciones especificas.
 Un diseño debe contener abstracciones de datos y procedimientos.
 Debe producir módulos que presenten características de funcionamiento

independiente.
 Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre

los módulos y el entorno exterior.
 Debe producir un diseño usando un método que pudiera repetirse según la

información obtenida durante el análisis de requisitos de Software.
Estos criterios no se consiguen por casualidad. El proceso de Diseño del Software exige
buena calidad a través de la aplicación de principios fundamentales de Diseño,
Metodología sistemática y una revisión exhaustiva.
“DAVID AUSUBEL”
SEMIPRESENCIAL
Cuando se va a diseñar un Sistema de Computadoras se debe tener presente que el

proceso de un diseño incluye, concebir y planear algo en la mente, así como hacer un
dibujo o modelo o croquis.
DISEÑO DE LA SALIDA
En este caso salida se refiere a los resultados e informaciones generadas por el Sistema,
Para la mayoría de los usuarios la salida es la única razón para el desarrollo de un
Sistema y la base de evaluación de su utilidad. Sin embargo cuando se realiza un
sistema, como analistas deben realizar lo siguiente:
Determine que información presentar. Decidir si la información será presentada en forma

visual, verbal o impresora y seleccionar el medio de salida.
Disponga la presentación de la información en un formato aceptable.
Decida como distribuir la salida entre los posibles destinatarios.
DISEÑO DE ARCHIVOS
Incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se
fuera a emplear para guardar detalles de las transacciones, datos históricos, o
información de referencia. Entre las decisiones que se toman durante el diseño de
archivos, se encuentran las siguientes:
Los datos que deben incluirse en el formato de registros contenidos en el archivo.
La longitud de cada registro, con base en las características de los datos que contenga.
La secuencia a disposición de los registros dentro del archivo (La estructura de

almacenamiento que puede ser secuencial, indexada o relativa).
No todos los sistemas requieren del diseño de todos los archivos, ya que la mayoría de
ellos pueden utilizar los del viejo Sistema y solo tenga que enlazarse el nuevo Sistema al
Archivo maestro donde se encuentran los registros.
DISEÑO DE INTERACCIONES CON LA BASE DE DATOS.
La mayoría de los sistemas de información ya sean implantado en sistemas de cómputos

grandes o pequeños, utilizan una base de datos que pueden abarcar varias aplicaciones,
por esta razón estos sistemas utilizan u administrador de base de datos, en este caso el
diseñador no construye la base de datos sino que consulta a su administrador para
ponerse de acuerdo en el uso de esta en el sistema.
“DAVID AUSUBEL”
SEMIPRESENCIAL
HERRAMIENTAS PARA EL DISEÑO DE SISTEMAS.
Apoyan el proceso de formular las características que el sistema debe tener para
satisfacer los requerimientos detectados durante las actividades del análisis:
Herramientas de especificación.
Apoyan el proceso de formular las características que debe tener una aplicación, tales
como entradas, Salidas, procesamiento y especificaciones de control. Muchas incluyen
herramientas para crear especificaciones de datos.
Herramientas para presentación.
Se utilizan para describir la posición de datos, mensajes y encabezados sobre las

pantallas de las terminales, reportes y otros medios de entrada y salida.
Herramientas para el desarrollo de Sistemas.
Estas herramientas nos ayudan como analistas a trasladar diseños en aplicaciones

funcionales.
Herramientas para Ingeniería de Software.
Apoyan el Proceso de formular diseños de Software, incluyendo procedimientos y

controles, así como la documentación correspondiente.
GENERADORES DE CÓDIGOS.
Producen el código fuente y las aplicaciones a partir de especificaciones funcionales bien

articuladas.
Herramientas para pruebas.
Apoyan la fase de la evaluación de un Sistema o de partes del mismo contra las

especificaciones. Incluyen facilidades para examinar la correcta operación del Sistema así
como el grado de perfección alcanzado en comparación con las expectativas.
La revolución del procesamiento de datos de manera computarizada, junto con las

practicas de Diseño sofisticadas están cambiando de forma dramática la manera en que
se trasladan las especificaciones de Diseño d Sistemas de Información funcionales.
MODELOS DE DISEÑO ORIENTADO A OBJETOS

“DAVID AUSUBEL”
SEMIPRESENCIAL
DISEÑO DE SERVICIOS
DIAGRAMA DE LOS ESTADOS (DE)
DIAGRAMA DE ACTIVIDADES O PROCESOS (DA)

Tecn. de Analisis de Diseno. de Software PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tecn. de Analisis de Diseno. de Software PDF

Cargado por

Copyright:

Formatos disponibles

INSTITUTO TECNOLÓGICO SUPERIOR

GUÍA DE ESTUDIO MODULAR

INFORMÁTICA MENCIÓN: ANÁLISIS DE

AUTOR: ING. MARCO MOLINA ÁLVAREZ

Corrección: Comisión de Redacción

Aprobado: Vicerrectorado Académico

Edición: Instituto Superior Tecnológico “David Ausubel”

PERÍODO: Octubre 2015 – abril 2016

PARA USTED APRECIADO ESTUDIANTE

NO OLVIDE QUE EL ESFUERZO Y LA PERSEVERANCIA MÁS EL ESTUDIAR

El Instituto Tecnológico Superior “David Ausubel”, da la bienvenida a este

EN ESTE TEXTO GUIA SE ENCUENTRAN DESARROLLADOS LOS TEMAS QUE

1. EL ESTUDIANTE TIENE LAS OPORTUNIDADES QUE SEAN NECESARIAS PARA

3. ES OBLIGACION DEL ESTUDIANTE ASISTIR A CADA UNA DE LAS TUTORÍAS

4. TODO TRABAJO DEL ESTUDIANTE SERÁ EVALUADO CUANTITATIVAMENTE.

5. AL FINAL EL TUTOR EVALUARA EL MÓDULO EN SU TOTALIDAD.

6. DE REQUERIR CUALQUIER INFORMACION DIRIGIRSE AL CORREO DE LA

Docente: Geovanny Paucar gio_wpg@hotmail.com

Gracias por su confianza.

1. PERFIL DE INFORMÁTICA MENCIÓN ANÁLISIS DE SISTEMAS

a) OBJETIVO DE FORMACIÓN INTEGRAL DEL PROFESIONAL

c) COMPETENCIAS PRINCIPALES POR DESARROLLAR

SISTEMATIZACIÓN DE LAS COMPETENCIAS POR NIVELES

d) NIVEL COMPETENCIA PRINCIPAL

Se generan dentro de la entidad, sea por procesos o por transacciones:

 Empresas de Asesoría Informática

En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver

1. HISTORIA DEL SOFTWARE

3.6.5 MODELADO DE FLUJO DE INFORMACIÓN

DESARROLLO DEL CONTENIDO

La necesidad de enfoques sistemáticos para el desarrollo y mantenimiento de productos

1.1 LA IMPORTANCIA DEL SOFTWARE

“Instrucciones (programas de computadora) que cuando se ejecutan proporcionan la

“Documentos que describen la operación y el uso de los programas”.

1.1.2 CARACTERÍSTICAS DEL SOFTWARE

Para poder comprender lo que el software (y consecuentemente la ingeniería del

El software se desarrolla, no se fabrica en un sentido clásico.

sufre cambios (mantenimiento). Conforme se hacen los cambios, es bastante probable

La mayoría del software se construye a medida, en vez de ensamblar componentes

1.1.3 COMPONENTES DEL SOFTWARE

El software de computadora es información que existe en dos formas básicas:

La habilidad de poder volver a usarse es una característica importante para un

Los componentes de software se construyen mediante un lenguaje de programación que

Los lenguajes de alto nivel permiten al programador y al programa independizarse de la

Los lenguajes de programación modernos (lenguajes que soportan directamente las

Los lenguajes especializados (diseñados para ámbitos de aplicación específicos), como

1.1.4 APLICACIONES DEL SOFTWARE

El software puede aplicarse en cualquier situación en la que se haya definido previamente

El determinismo de la información se refiere a la predecibilidad del orden y del tiempo de

1.1.4.1 SOFTWARE DE SISTEMAS.

1.1.4.2 SOFTWARE DE TIEMPO REAL.

El software que mide/analiza/controla sucesos del mundo real conforme ocurren, se

recibida del entorno externo, un componente de análisis que transforma la información

1.1.4.3 SOFTWARE DE GESTIÓN.

El procesamiento de información comercial constituye la mayor delas áreas de aplicación

1.1.4.4 SOFTWARE EMPOTRADO

El software empotrado reside en memoria de solo lectura y se utiliza para controlar

1.1.4.5 SOFTWARE DE INTELIGENCIA ARTIFICIAL.

El software de inteligencia artificial hace uso de algoritmos no numéricos para resolver

Examinemos algunos de ellos:

Mitos del Cliente

Mitos de los Desarrolladores.

1.3 PARADIGMAS DE LA INGENIERIA DE SOFTWARE