Ingeniería de Software

Introducción
Sofía Isabel Fernández Gregorio
Maestra en Computación Aplicada

sfernandez@tecmartinez.edu.mx | INGENIERÍA EN SISTEMAS COMPUTACIONALES | ITSMT |04 de Febrero del 2017

 Introducción
Intención didáctica
La asignatura debe ser teórico – práctico, y capaz de
desarrollar en el estudiante la habilidad para la
aplicación de las diferentes técnicas en el desarrollo de
software, considerando siempre los principios de la
ingeniería de software, para lo cual se organiza el
temario en cuatro temas.

2
 Introducción
Competencias previas

Diseña y desarrolla programas para la solución de

problemas computacionales utilizando el paradigma
orientado a objetos.
Desarrolla soluciones de software para resolver problemas
en diversos contextos utilizando programación concurrente,
acceso a datos, que soporten interfaz gráfica de usuario y
consideren dispositivos móviles.
Crea y gestiona bases de datos para resolver problemas del
contexto considerando la concurrencia e interoperabilidad
de los datos.
Realiza el análisis de un proyecto de software, a partir de la
identificación del modelo de negocios de la organización que
permitan alcanzar estándares y métricas de calidad.
3
 Introducción

Competencias a desarrollar

Desarrolla soluciones de software, considerando la

metodología y herramientas para la elaboración de
un proyecto aplicativo en diferentes escenarios.

4
 Introducción

Tabla de contenido
1. Análisis
2. Diseño
3. Desarrollo
4. Pruebas e implementación

Evaluación de segunda oportunidad: 08 de Abril-17

Asesorías: Lunes de 14:00 a 15:00 h
5
 Introducción

Evaluación por unidad

Examen 40%
Actividades de aprendizaje 60%

6
 Introducción

Bibliografía:
Booch G. (2006). El lenguaje Unificado de Modelado,
UML 2.0, Guía de Usuario. 2ª. Edición. España: Pearson
ADDISON-WESLEY.
Braude, E. (2003). Ingeniería de Software una
perspectiva orientada a objetos. México: ALFAOMEGA.
Pressman, R.S. (2008). Ingeniería del Software un
enfoque práctico. 6ª. Edición México: MC GRAW HILL.
Senn J.A. (1996). Análisis y Diseño de Sistemas. 2ª
Edición. México: MC GRAW HILL.

7
 Introducción

Examen diagnostico

8
 Tema 1
Análisis

Objetivo:
Abstrae información del usuario final para elaborar el
análisis de requerimientos del software a desarrollar

9
 Análisis semántico

Tabla de contenido

1.1 Revisión de especificación de requisitos.

1.2 Descripción de procesos actuales
1.3 Diagramas UML
1.4 Estudio de Factibilidad
1.5 Análisis Costo-Beneficio

10
 Introducción a la teoría de lenguajes
formales
Evaluación de la unidad

Examen 40%.
Reporte 10%
Carta compromiso 10%
Diagrama UML 20%
Estudio de factibilidad 10%
Metodología 10%

11
 Análisis
Revisión de especificación de requisitos

Definición
La especificación de requisitos de software (ERS) es una
descripción completa del comportamiento del sistema que
se va a desarrollar. Incluye un conjunto de casos de uso que
describe todas las interacciones que tendrán los usuarios
con el software.

12
 Análisis
Revisión de especificación de requisitos

Definición
La especificación de requisitos de software (ERS) es una
descripción completa del comportamiento del sistema que
se va a desarrollar. Incluye un conjunto de casos de uso que
describe todas las interacciones que tendrán los usuarios
con el software.

13
 Análisis
Revisión de especificación de requisitos

Tipos de requisitos
Existen varios tipos de requisitos como lo son:
 Requisitos de Usuarios: Necesidades que los usuarios
expresan verbalmente
 Requisitos del Sistema: Son los componentes que el
sistema debe tener para realizar determinadas tareas
 Requisitos Funcionales: Servicios que el sistema debe
proporcionar
 Requisitos no funcionales: Restricciones que afectaran al
sistema

14
 Análisis
Revisión de especificación de requisitos

Norma EEE830
El estándar 830 fue generado por un equipo de trabajo del
IEEE, su finalidad es la integración de los requerimientos del
sistema desde la perspectiva del usuario, cliente y
desarrollador.

15
 Análisis
Revisión de especificación de requisitos

Norma EEE830
 La norma 830 se encarga de poner las pautas para
identificar y esquematizar los requerimientos de software
no solo como parte integral del desarrollo de software, sino
también como base fundamental de este. Todo esto con el
fin de no caer en cambios, errores o situaciones que pongan
en peligro la creación de una solución, producto o software;
incurriendo en gastos o cambios producto de una mal
análisis de requerimientos.

16
 Análisis
Revisión de especificación de requisitos

Trazabilidad de requisitos
 La trazabilidad en la Ingeniería de Software es una práctica
de control que ayuda a obtener el producto en el dominio
de la solución lo más exacto y fiable posible a las
necesidades expresadas por el cliente.
La trazabilidad en la Ingeniería de Software es una práctica
de control que ayuda a obtener el producto en el dominio
de la solución lo más exacto y fiable posible a las
necesidades expresadas por el cliente en el dominio del
problema.

17
 Análisis
Revisión de especificación de requisitos

Trazabilidad de requisitos
 Según el estándar IEEE 830-1998, la trazabilidad es la
habilidad para seguir la vida de un requerimiento en ambos
sentidos, hacia sus orígenes o hacia su implementación a
través de las especificaciones generadas durante el proceso
de desarrollo. Es un factor de calidad.

18
 Análisis
Revisión de especificación de requisitos

Trazabilidad de requisitos
Nos permite identificar el origen de cada requisito (ya sea
una fuente autorizada o un requisito de nivel superior) y
seguir cada cambio que se realice sobre el mismo. Pero no
sólo eso, al trazar los requisitos con otros artefactos
(pruebas, casos de uso, planes de proyecto, etc.) será
posible responder a los cambios en el proyecto de forma
más controlada y con más información. Podremos
anteponernos a lo que un cambio puede significar.

19
 Análisis
Revisión de especificación de requisitos

Trazabilidad de requisitos
Análisis de impacto de cambios
Por medio de las trazas, tanto los requisitos entre ellos,
como los requisitos con otros elementos del proyecto,
estarán relacionados y dichas trazas estarán documentadas.
Esto permite analizar de forma precisa que puede implicar
que una petición de cambio afecte a un requisito ¿Qué
otros requisitos se verán afectados? ¿Qué funcionalidades?
¿Qué pruebas habrá que volver a ejecutar o reescribir?
¿Qué usuarios o stakeholders deben ser notificados de este
cambio?.

20
 Análisis
Revisión de especificación de requisitos

Trazabilidad de requisitos
Matrices de trazabilidad
Una técnica comúnmente utilizada para recoger la
información bi-direccional de trazas, son las matrices de
trazabilidad. Éstas muestran diversos elementos en filas y
columnas (por ejemplo, requisitos y pruebas) indicando
después en cada celda de la matriz si los elementos están o
no trazados (y en qué dirección, en caso de ser relevante).
Permitiendo realizar el análisis de trazabilidad de forma
más gráfica.

21
 Análisis
Revisión de especificación de requisitos

Trazabilidad de requisitos
Matrices de trazabilidad
Una técnica comúnmente utilizada para recoger la
información bi-direccional de trazas, son las matrices de
trazabilidad. Éstas muestran diversos elementos en filas y
columnas (por ejemplo, requisitos y pruebas) indicando
después en cada celda de la matriz si los elementos están o
no trazados (y en qué dirección, en caso de ser relevante).
Permitiendo realizar el análisis de trazabilidad de forma
más gráfica.

22
 Análisis
Revisión de especificación de requisitos

Trazabilidad de requisitos
Matrices de trazabilidad
Ejemplo:

23
 Análisis
Revisión de especificación de requisitos

Trazabilidad de requisitos
Matrices de trazabilidad
Ejemplo:

24
 Análisis
Revisión de especificación de requisitos

Trazabilidad de requisitos
Matrices de trazabilidad
Ejemplo:

25
26
 Análisis
Descripción de procesos actuales

Definición
El levantamiento y descripción de los procesos es una forma
de representar la realidad de la manera más exacta posible,
a partir de la identificación de las diferentes actividades y
tareas que se realizan en un proceso para lograr un
determinado resultado o producto.

27
 Análisis
Descripción de procesos actuales

Elementos:
Al efectuar el levantamiento del proceso y describirlo, hay
ciertos elementos que deberán ser tomados en
consideración para incluirlos en el trabajo que se realiza:
1. La clara identificación del proceso, al cual deberá
asignársele un nombre o denominación que permita
identificarlo (alfanumérica por ejemplo “P-3”).
2. La definición funcional: expresar en forma simple qué
función central realiza o qué objetivo tiene el proceso que
se está describiendo.

28
 Análisis
Descripción de procesos actuales

Elementos:
3. Cuáles son sus límites, en el sentido de delimitarlo y poder
diferenciarlo de otros procesos cercanos o relacionados;
para esto ayuda mucho el mapa de procesos.
4. Destinatarios del proceso: a quiénes está dirigido el
proceso, quiénes son los que valoran los resultados del
proceso.
5. Cuáles son las expectativas, tanto de los destinatarios
como de los gestores o responsables de dicho proceso.
Esto es definir las condiciones óptimas para este proceso,
desde ambas perspectivas.

29
 Análisis
Descripción de procesos actuales

Información:
Después de una descripción general viene el elemento
central de la gestión de los procesos que es su descripción,
la cual consta de un área descriptiva y de un área gráfica,
que son complementarias y que deberán contener al menos
la siguiente información:

30
 Análisis
Descripción de procesos actuales

Información:
Recursos o input: son los elementos materiales, de
información u otros que pueden incluso ser intangibles
(como el conocimiento empírico de los profesionales) que
el proceso consume o necesita para poder generar la salida
u output.
Actividades: es la descripción secuencial, en orden
cronológico, de las actividades y sus respectivas tareas, que
tienen que realizar los participantes (protagonistas).
Protagonistas o actores: personas o grupos de personas
que desarrollan las actividades y tareas del proceso.

31
 Análisis
Descripción de procesos actuales

Información:
Salida: resultado del proceso, el output, aquello para lo cual
ha sido diseñado el proceso.
Destinatario: persona o conjunto de personas que reciben y
valoran la salida del proceso.
Indicadores: estas mediciones permiten hacer un
seguimiento y valoración del cumplimiento de los objetivos
del proceso. En estricto rigor no son parte de la descripción
del proceso, pero al momento de hacer este trabajo es
adecuado incluir este aspecto por la estrecha relación que
tiene con el trabajo de levantamiento.

32
 Análisis
Descripción de procesos actuales

Información:
Diagrama de flujo del proceso (flujograma): es la expresión
gráfica del proceso, que resulta de mucha utilidad porque
facilita su análisis y rediseño.

Existen otras formas de graficar los procesos, en los cuales

queda mejor identificado cuáles son los diferentes actores
que en él participan, y desde el punto de vista de su
elaboración podría resultar más simple.

33
 Análisis
Descripción de procesos actuales

Información:
Ejemplo:

34
 Análisis
Descripción de procesos actuales

Carta compromiso:
Una carta compromiso Cliente-Desarrollador permite
delimitar los alcances del sistema y evitar problemas
futuros.

Ejemplo:

35
36
 Análisis
Descripción de procesos actuales

Actividad:
Crear una carta compromiso de acuerdo a los acuerdos
establecidos con su cliente.

37
 Análisis
Diagramas UML

Definición:
El lenguaje unificado de modelado (UML, por sus siglas en
inglés, Unified Modeling Language) es el lenguaje de
modelado de sistemas de software más conocido y utilizado
en la actualidad.

38
 Análisis
Diagramas UML

Diagramas:
Tipos de diagramas en UML
 Diagrama de clases  Diagrama de casos de uso
 Diagrama de componentes  Diagrama de máquina de
 Diagrama de despliegue estados
 Diagrama de objetos  Diagrama global de
 Diagrama de paquetes interacciones
 Diagrama de perfiles  Diagramas de comunicación
 Diagrama de estructuras  Diagrama de secuencia
compuestas  Diagrama de tiempos
 Diagrama de actividades

39
 Análisis
Diagramas UML

Diagrama de casos de uso:

Los diagramas de casos de uso ofrecen una visión general
de los actores involucrados en un sistema, las diferentes
funciones que necesitan esos actores y cómo interactúan
estas diferentes funciones.

40
 Análisis
Diagramas UML

Diagrama de casos de uso:

Actores:

Se le llama actor a toda entidad externa al sistema que guarda

una relación con éste y que le demanda una funcionalidad.
Esto incluye a los operadores humanos pero también incluye a
todos los sistemas externos, además de entidades abstractas,
como el tiempo.

41
 Análisis
Diagramas UML

Diagrama de casos de uso:

Relaciones:
 Inclusión (include): Es una forma de interacción o creación,
un caso de uso dado puede "incluir" otro caso de uso. El
primer caso de uso a menudo depende del resultado del
caso de uso incluido. La notación es de una flecha de punta
abierta con línea discontinua desde el caso de uso que lo
incluye hasta el caso de uso incluido, con la etiqueta
"«include»".

42
 Análisis
Diagramas UML

Diagrama de casos de uso:

Relaciones:
 Extensión (extend): Es otra forma de interacción, un caso
de uso dado (la extensión) puede extender a otro. El caso
de uso extensión puede ser insertado en el caso de uso
extendido bajo ciertas condiciones. La notación, es una
flecha de punta abierta con línea discontinua, desde el
caso de uso extensión al caso de uso extendido, con la
etiqueta «extend».

43
 Análisis
Diagramas UML

Diagrama de casos de uso:

Relaciones:
 Generalización: "Entonces la Generalización es la actividad
de identificar elementos en común entre conceptos y
definir las relaciones de una superclase (concepto general)
y subclase (concepto especializado). Es una manera de
construir clasificaciones taxonómicas entre conceptos que
entonces se representan en jerarquías de clases. Las
subclases conceptuales son conformes con las superclases
conceptuales en cuanto a la intención y extensión."

44
 Análisis
Diagramas UML

Diagrama de casos de uso:

Notaciones:

45
 Análisis
Diagramas UML

Diagrama de casos de uso:

Ejemplo:

46
 Análisis
Diagramas UML

Diagrama de casos de uso:

Ejemplo:

47
 Análisis
Diagramas UML

Actividad:
Crear el Diagrama de casos de uso de su sistema.

48
 Análisis
Diagramas UML

Descripción de casos de uso:

Una especificación de caso de uso proporciona detalles
textuales de un caso de uso. Este tema ofrece una ejemplo
de descripción de una especificación de caso de uso.
Reutilice y modifique esta descripción según convenga en
un documento de especificaciones de caso de uso.

49
 Análisis
Diagramas UML

Descripción de casos de uso:

CU-01 Capturar registros
Descripción: Se realiza la captura de los síntomas diarios que el paciente ha tenido durante el día, el flujo máximo
espiratorio y si ha consumido la dosis adecuada del día. Y se envía la información registrada al médico.
Precondiciones:Configuración de datos personales.
Postcondiciones: Envío de datos al médico.
Flujo básico
Paso Acción
1. El paciente accede a la opción registro diario.
2. Se muestran la primera pantalla “Síntomas” con disnea, tos, sibilancias, opresión de pecho.
Flujo alterno
Paso Acción
1. El paciente se encuentra en “Síntomas” del registro diario.
2. Muestra la pantalla con una caja de texto para introducir comentarios.
Flujo de excepción
Excep Paso Acción
.
2. 1 El dispositivo móvil no tiene disponible en ese momento una salida de datos.
2 Guarda la información y la envía hasta que tenga una conexión disponible WI-FI o de red celular.
Comentarios Sin requerimientos no funcionales , los comentarios del sistema son opcionales.

50
 Análisis
Diagramas UML

Actividad:
Realizar la descripción de los casos de uso del sistema que
le corresponde.

51
 Análisis
Estudio de factibilidad

Definición
El estudio de factibilidad es un instrumento que sirve para
orientar la toma de decisiones en la evaluación de un
proyecto y corresponde a la última fase de la etapa pre-
operativa o de formulación dentro del ciclo del proyecto.
Se formula con base en información que tiene la menor
incertidumbre posible para medir las posibilidades de éxito
o fracaso de un proyecto de inversión, apoyándose en él se
tomará la decisión de proceder o no con su
implementación.

52
 Análisis
Estudio de factibilidad

El estudio debe ayudar a:

Determinación plena e inequívoca del proyecto a través del
estudio de mercado, la definición del tamaño, la ubicación
de las instalaciones y la selección de tecnología.
Diseño del modelo administrativo adecuado para cada
etapa del proyecto.
Estimación del nivel de las inversiones necesarias y su
cronología/lo mismo que los costos de operación y el
cálculo de los ingresos.
Identificación plena de fuentes de financiación y la
regulación de compromisos de participación en el proyecto.

53
 Análisis
Estudio de factibilidad

El estudio debe ayudar a:

Definición de términos de contratación y pliegos de
licitación de obras para adquisición de equipos y
construcciones civiles principales y complementarias.
Sometimiento del proyecto si es necesario a las respectivas
autoridades de planeación y ambientales.
Aplicación de criterios de evaluación tanto financiera como
económica, social y ambiental, que permita allegar
argumentos para la decisión de realización del proyecto.

54
 Análisis
Estudio de factibilidad

Del estudio se puede esperar:

Abandonar el proyecto por no encontrarlo suficientemente
viable, conveniente u oportuno;
O mejorarlo, elaborando un diseño definitivo, teniendo en
cuenta las sugerencias y modificaciones que surgirán de los
analistas.

55
 Análisis
Estudio de factibilidad

Términos:
En consecuencia, los objetivos de cualquier estudio de
factibilidad se pueden resumir en los siguientes términos:
 Demostración de la viabilidad técnica y la disponibilidad
de los recursos humanos, materiales, administrativos y
financieros.
 Verificación de la existencia de un mercado potencial o de
una necesidad no satisfecha.
 Corroboración de las ventajas desde el punto de vista
financiero, económico, social o ambiental de asignar
recursos hacia la producción de un bien o la prestación de
un servicio.
56
 Análisis
Estudio de factibilidad

Tipos:
Se pueden realizar varios estudios dependiendo del tipo de
factibilidad:

 Factibilidad operativa
 Factibilidad técnica
 Factibilidad económica

57
 Análisis
Estudio de factibilidad

Factibilidad operativa:
Dentro de esta se mide la urgencia del problema o la
aceptabilidad de la solución.
Preguntas:
 ¿Vale la pena resolver el problema o funcionará la
solución pensada para el problema?
 ¿Qué opinan los usuarios finales y los directivos sobre el
problema (solución)?
 ¿Es posible superar éste problema? ¿Cómo?

58
 Análisis
Estudio de factibilidad

Factibilidad técnica:
La Factibilidad Técnica indica, sobre el desarrollo del
proyecto y funcionamiento del sistema.
Preguntas:
 ¿Es práctica la tecnología o solución propuesta?. Si la
tecnología es práctica y fácil de usar.
 ¿Disponemos de la tecnología necesaria? Contamos con
la tecnología necesaria, contamos con lo necesario
(analistas, diseñadores, programadores, económico, etc.)
para poder desarrollar nuestro sistema informático.

59
 Análisis
Estudio de factibilidad

Factibilidad económica:
Establecer los diferentes costos que se tendrán para y
durante el desarrollo del proyecto.

60
 Análisis
Análisis costo-beneficio

Objetivo:
Medir el costo que tendrá el proyecto y los beneficios que
dará.

61
 Análisis
Análisis costo-beneficio

Ejemplo:

62
 Análisis
Análisis costo-beneficio

Ejemplo:

63
 Análisis
Análisis costo-beneficio

Ejemplo:

64
 Análisis
Análisis costo-beneficio

Ejemplo:

65
 Análisis
Análisis costo-beneficio

Ejemplo:

66
 Análisis
Análisis costo-beneficio

Actividad:
Realizar el estudio de factibilidad correspondiente a su
proyecto.

Definir la metodología del desarrollo de software.

67