Este documento describe las etapas del proceso de ingeniería de software para el desarrollo de un sistema telemático. Incluye las etapas de análisis de requerimientos, arquitectura, programación, prueba, documentación y mantenimiento. También describe modelos de bases de datos como el modelo jerárquico, en red y orientado a objetos, así como conceptos clave como entidades, atributos y relaciones en el modelo entidad-relación.

1. Sistemas Telemáticos
Desarrollo de un sistema telemático
1802
Prof. Jaime Humberto Pech Carmona
Tecnológico de Estudios Superiores de Ecatepec

2. Metodología genérica
Diseño de un S.T.
Ingeniería de
software
Creación eficiente
de aplicaciones
Resultados óptimos
Encontrar procesos
que sean:
Sistemáticos
Predecibles
Repetibles
Objetivo
Productividad en el
desarrollo
Calidad del producto

3. Etapas del proceso (Ingeniería de Software)
1
Análisis de
requerimientos
2
Arquitectura
3
Programación
4
Prueba
5
Documentación
6
Mantenimiento

4. 1. Análisis de requerimientos.
Extrae
• Requisitos y
requerimientos
Requiere
• Habilidad en I.S.
para:
• Reconocer
requerimientos
incompletos,
ambiguos o
contradictorios.
Resultados
• Se plasma en el
documento ERS
Especificación de
Requerimientos
del Sistema (SRS)
• Normalización:
• IEEE 830 1998
• Consideraciones
para un buen
SRS
• Las partes de un
SRS
Definición
• Diagrama Entidad
– Relación
• Registra las
entidades
participantes en
el desarrollo
Desarrollador
Cliente

5. 2. Arquitectura
 Actividad de planeación.
 A nivel de infraestructura de red y hardware, o de software.
 La arquitectura de software consiste en:
 Un diseño arquitectónico describe en general el cómo se
construirá una aplicación de software. Para ello se
documenta utilizando diagramas.
Entidades de
negocio
Diseño de
componentes
Visualiza la
interacción
ente las
entidades
Validación
por
diagramas de
secuencia

6. Una base de datos...

7. La atomicidad de una transacción
garantiza que todas sus acciones
sean realizadas o ninguna sea
ejecutada.
La consistencia garantiza que las
reglas que hayan sido declaradas para
una transacción sean cumplidas.
Garantiza que las transacciones que
se estén realizando en el sistema
sean invisibles a todos los usuarios
hasta que estas hayan sido
declaradas finales.
La durabilidad de una transacción
garantiza que al instante en el que
se finaliza la transacción esta
perdure a pesar de otras
consecuencias.

8. Modelo jerárquico
Los datos son organizados
en una estructura de árbol
La estructura de fichas
permite:
Repetir y usar relaciones
Padre/Hijo
Los atributos de un registro
son catalogados bajo un
tipo de entidad (tabla)
Registro  fila
Atributo  columna

9. Modelo en red
 El modelo de red es
un modelo de base de
datos concebido como un
modo flexible de representar:
 Objetos
 Su relación.

10. Modelo orientado a objetos
 Modelos de objetos
interrelacionados entre sí
para solucionar el
problema.
 Manejo de clases.
 Manejo de estados.
 Eventos que alteran el
estado de los objetos.
 Genera mensajes 
Acciones

11. Modelo E-R
 Modelo E-R (entidad relación), que describe los datos cono
entidades, vínculos (relaciones) y atributos.
Genera un
conjunto de
esquemas de
relaciones
Almacenando
información con
un mínimo de
redundancia
Facilitando la
recuperación de
la información.
Teniendo una
forma normal.
Modelo de datos
conceptual

12. Entidad
 Las entidades están compuestas de:
atributos que son los datos que definen el objeto (para la entidad persona serían NIP, nombre,
apellidos, dirección,...).
Una entidad concreta tendrá un valor para cada uno de sus atributos.
Tres reglas generales que debe cumplir cualquier entidad son (Tardieu):
1.Tiene que tener existencia propia.
2. Cada ocurrencia de un tipo debe poder distinguirse de las demás.
3.Todas las ocurrencias de un tipo de entidad deben tener los mismos tipos de características
(atributos).
Existen dos clases de entidades:
Regulares, que tienen existencia por ellas mismas.
ALUMNO LIBRO
Objeto Existe Distinguible
Podemos
almacenar
información
características especiales y únicas
que tiene un objeto o entidad

13. Débiles, cuya existencia depende de otro tipo de entidad.
Como ejemplo de entidad débil podríamos pensar en la entidad PAGO
como los distintos pagos de un préstamo (el primer pago, el
segundo,…) que dependerían de la entidad PRESTAMO, y la eliminación
de PRESTAMO en nuestra base de datos obligaría a eliminar PAGO.
La representación gráfica de un tipo de entidad es un rectángulo
etiquetado con el nombre del tipo de entidad:
 Atributos.- Característica interesante sobre ella es decir,
representa alguna propiedad que nos interesa almacenar.
 La identidad persona tiene un nombre, una fecha de nacimiento y un
número de seguro social; algunos de los valores de estos atributos
los comparte con otras personas, y otros son exclusivos de él.
PAGO

14.  La representación gráfica de un atributo consiste en una
elipse con el nombre del atributo en su interior.
Nombre Puesto

15.  De entre todos los atributos de un tipo de entidad debemos
elegir uno o varios de forma que me identifiquen
unívocamente a la entidad para que sean clave primaria.
 • Superclave: es el conjunto de uno o más atributos que
juntos permiten identificar de forma única una entidad.
 • Clave candidata: es una superclave para la cual no existe
ningún subconjunto suyo que sea a su vez superclave.
 • Clave primaria: es la clave candidata elegida por el
diseñador de la base de datos para identificar a la entidad.
 Los atributos que actúan como clave primaria se
representarán de la misma forma que el resto de atributos, es
decir mediante elipses, pero con el nombre del atributo
subrayado.

16. Relaciones
Una base de datos relacional permite la utilización simultánea de
datos procedentes de más de una tabla.
Al hacer uso de las relaciones, se evita la duplicidad de datos,
ahorrando memoria y espacio en el disco, aumentando la
velocidad de ejecución y facilitando al usuario el trabajo con
tablas.
 Por ejemplo, una relación entre una entidad "Empleado" y una
entidad "Departamento" podría ser "trabaja_en", porque el
empleado trabaja en un departamento determinado.
 El tipo de relación se representa mediante un rombo
etiquetado con el nombre de la relación, unido mediante líneas
a los tipos de entidad que asocia:

17.  Tipos de cardinalidad:
 Relación de uno a uno
 En este tipo de relaciones, cada instancia o elemento de la entidad A está asociado solamente a un
elemento de la entidad B. Se recomienda que cuando se identifique una relación de este tipo, se una ambas
entidades formando una sola, salvo casos especiales.
 Relación de uno a muchos
 En este tipo de relaciones, cada instancia o elemento de la entidad A está asociado a varios elementos de la
entidad B, entonces la clave que forma el vínculo entre ambas entidades, pasa hacia la entidad que tiene el
mayor grado de cardinalidad, es decir el que posee la denominación ‘muchos’.
 Relación de muchos a muchos
 En este tipo de relación, los elementos de la entidad A están asociados a varios elementos de la entidad B, y
los elementos de la entidad B están asociados a varios elementos de la entidad A, cuando sucede esto, se
genera una nueva entidad denominada ‘Entidad Asociada’, generalmente toma el nombre de ambas
entidades participantes o la denominación del verbo de la relación. La entidad asociada se grafica sólo en el
modelo físico de datos, en el nivel lógico se representa la relación muchos a muchos.

18. Diagrama Entidad- Relación
 Es la representación gráfica del Modelo Entidad-Relación y permite
ilustrar la estructura de la base de datos del negocio modelado.
Escribe Johnson "los diagramas ER constituyen una notación para
documentar un diseño tentativo de bases de datos. Los analistas los
utilizan para facilitar el proceso de diseño"
 Está compuesto por los siguientes elementos, como los
mencionamos anteriormente:

20. 3. Programación
 Reducir un diseño a código puede ser la parte más obvia
del trabajo de ingeniería de software, pero no
necesariamente es la que demanda mayor trabajo y ni la
más complicada. La complejidad y la duración de esta
etapa está íntimamente relacionada al o a los lenguajes de
programación utilizados, así como al diseño previamente
realizado.

21. 4.Prueba
 Consiste en comprobar que el software realice correctamente las tareas
indicadas en la especificación del problema.
 Una técnica de prueba es probar por separado cada módulo del software, y
luego probarlo de forma integral, para así llegar al objetivo.
 Se considera una buena práctica el que las pruebas sean efectuadas por
alguien distinto al desarrollador que la programó, idealmente un área de
pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias
pruebas.
 En general hay dos grandes formas de organizar un área de pruebas:
1. Está compuesta por personal inexperto y que desconozca el tema de pruebas, de
esta forma se evalúa que la documentación entregada sea de calidad, que los
procesos descritos son tan claros que cualquiera puede entenderlos y el
software hace las cosas tal y como están descritas.
2. Tener un área de pruebas conformada por programadores con experiencia,
personas que saben sin mayores indicaciones en qué condiciones puede fallar una
aplicación y que pueden poner atención en detalles que personal inexperto no
consideraría.

22. 5. Documentación
 Todo lo concerniente a la documentación del propio
desarrollo del software y de la gestión del proyecto,
pasando por modelaciones, diagramas de casos de uso,
pruebas, manuales de usuario, manuales técnicos, etc; todo
con el propósito de eventuales correcciones, usabilidad,
mantenimiento futuro y ampliaciones al sistema.

23. 6. Mantenimiento
 Fase dedicada a mantener y mejorar el software para
corregir errores descubiertos e incorporar nuevos
requisitos. Esto puede llevar más tiempo incluso que el
desarrollo del software inicial.Alrededor de 2/3 del
tiempo de ciclo de vida de un proyecto está dedicado a
su mantenimiento. Una pequeña parte de este trabajo
consiste eliminar errores (bugs); siendo que la mayor
parte reside en extender el sistema para incorporarle
nuevas funcionalidades y hacer frente a su evolución.

24. Modelos de desarrollo
 La ingeniería de software dispone de varios
modelos, paradigmas y filosofías de desarrollo, en los cuales se
apoya para la construcción del software, entre ellos se puede
citar:
 Modelo en cascada o Clásico (modelo tradicional)
 Modelo de prototipos
 Modelo en espiral
 Desarrollo por etapas
 Desarrollo iterativo y creciente o Iterativo e Incremental.
 RAD (Rapid Application Development)
 Desarrollo concurrente
 Proceso Unificado
 RUP (Proceso Unificado Racional)