1

Materia: Fundamentos de Ingeniería de Software

Quinto semestre
Docente: Ing. Fabiola Calderón Gómez
 1.1 Conceptos básicos
 ¿Qué es ingeniería?
 ¿Qué es software?
 ¿Qué es la Ingeniería de Software?
 ¿Qué es un proceso de software?
 ¿Qué es un modelo de proceso de software?
 ¿Cuáles son los costos de la ingeniería de software?
 ¿Qué son los métodos de la Ing. De software?
 ¿Qué son las herramientas CASE?
 ¿Cuáles son los atributos de software de calidad? 2
 1.1 Conceptos básicos
 Ingeniería
La ingeniería es el conjunto de conocimientos
científicos y tecnológicos para la innovación, invención,
desarrollo y mejora de técnicas y herramientas para
satisfacer las necesidades de las empresas y la sociedad.
La capacidad imaginativa y de creación del ser humano
sobresale para concebir cosas que aún no existen, y es
por medio de la aplicación de sus conocimientos
científicos que transforma esas ideas en acción o en
una realidad. 3
 1.1 Conceptos básicos
 ¿Qué es Software?
 El software nuevo puede ser creado desarrollando
nuevos programas, configurando sistemas de software
genérico o reutilizando software existente
 El software se desarrolla o modifica con intelecto; no se
manufactura.
 El software no se desgasta, pero sí se deteriora.

4
 Ingeniería de software

5
 Ingeniería de software

Según la definición del IEEE la ingeniería del software se

define como “La aplicación de un método sistemático,
disciplinado y cuantificable al desarrollo, operación y
mantenimiento de software, esto es, la aplicación de la
ingeniería al software”

6
 Proceso de software

7
 Modelo de Proceso de software

8
 Costos de la ingeniería de software

El desarrollo de software es una actividad muy compleja

obteniendo como resultado un producto intangible que
depende principalmente del esfuerzo intelectual y
creatividad de personas que lo realizan.

9
 Costos de la ingeniería de software

10
 Métodos de la ingeniería de software

11
 Herramientas CASE (Computer Aided Software
Engineering, Ingeniería de Software Asistida por
Computadora)
Se puede definir a las Herramientas CASE como un
conjunto de programas que dan asistencia a los
analistas, ingenieros de software y desarrolladores,
durante todos los pasos del Ciclo de Vida de desarrollo de
un Software.
Su finalidad es aumentar la productividad en el desarrollo
de software reduciendo el costo de las mismas en
términos de tiempo y de dinero.
12
 Las herramientas CASE, en función de las fases del ciclo de
vida del software, se pueden agrupar de la forma siguiente:

1. Herramientas integradas, I-CASE (Integrated CASE, CASE

integrado): Abarcan todas las fases del ciclo de vida del
desarrollo de sistemas.
2. Herramientas de alto nivel, U-CASE (Upper CASE - CASE
superior) o front-end, orientadas a la automatización y soporte
de las actividades desarrolladas durante las primeras fases del
desarrollo: análisis y diseño.
13
3. Herramientas de bajo nivel, L-CASE (Lower CASE - CASE
inferior) o back-end, dirigidas a las últimas fases del
desarrollo: construcción e implantación.
4. Juegos de herramientas o Tools-Case, son el tipo más
simple de herramientas CASE. Automatizan una fase dentro
del ciclo de vida. Dentro de este grupo se encontrarían las
herramientas de reingeniería, orientadas a la fase de
mantenimiento.

14
 Atributos del software de calidad

15
 1.2 Fases de la Ingeniería de software
 Fases Genéricas de la Ingeniería del Software
 Fase de Definición: se centra sobre el qué.
 qué información ha de ser procesada,
 qué función y rendimiento se desea,
 qué comportamiento del sistema,
 qué interfaces van a ser establecidas,
 qué restricciones de diseño existen,
 qué criterios de validación se necesitan para definir
un sistema correcto. 16
Fase de Desarrollo: se centra en el cómo.

 cómo han de diseñarse las estructuras de datos,

 cómo ha de implementarse la función dentro de una
arquitectura de software,
 cómo han de implementarse los detalles
procedimentales,
 cómo han de caracterizarse interfaces,
 cómo ha de traducirse el diseño en un lenguaje de
programación
 cómo ha de realizarse la prueba. 17
 Fase de Mantenimiento: se centra en el cambio que
va asociado a la corrección de errores, a las
adaptaciones requeridas a medida que evoluciona el
entorno del software y a cambios debidos a las mejoras
producidas por los requisitos cambiantes del cliente.

18
Durante la fase de mantenimiento se encuentran
cuatro tipos de cambios:
 Corrección. Incluso llevando a cabo las mejores
actividades de garantía de calidad, es muy probable
que el cliente descubra los defectos en el software. El
mantenimiento correctivo cambia el software para
corregir los defectos.
 Adaptación. Con el paso del tiempo, es probable que
cambie el entorno original para el que se desarrolló el
software. El mantenimiento adaptativo produce
modificación en el software para acomodarlo a los
cambios de su entorno externo. 19
 Mejora. Conforme se utilice el software, el
cliente/usuario puede descubrir funciones adicionales
que van a producir beneficios. El mantenimiento
perfectivo lleva al software más allá de sus
requisitos funcionales originales.
 Prevención. El software de computadora se deteriora
debido al cambio, y por esto el mantenimiento
preventivo también llamado reingeniería del
software, se debe conducir a permitir que el software
sirva para las necesidades de los usuarios finales.

20
21
Análisis de requisitos
Mientras que los clientes piensan que ellos saben lo que el
software tiene que hacer, se requiere de habilidad y experiencia
en la ingeniería de software para reconocer requisitos
incompletos, ambiguos o contradictorios. El resultado del
análisis de requisitos con el cliente se plasma en el documento
ERS, Especificación de Requerimientos del Sistema,
cuya estructura puede venir definida por varios estándares.

22
Diseño y arquitectura
Se refiere a determinar como funcionará de forma general
sin entrar en detalles. Consiste en incorporar
consideraciones de la implementación tecnológica, como
el hardware, la red, etc.
Se definen los Casos de Uso para cubrir las funciones
que realizará el sistema, y se transforman las entidades
definidas en el análisis de requisitos en clases de diseño,
obteniendo un modelo cercano a la programación
orientada a objetos.
23
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 es
necesariamente la porción más larga. La complejidad y la
duración de esta etapa está íntimamente ligada al o a los
lenguajes de programación utilizados.

24
Pruebas
Consiste en comprobar que el software realice
correctamente las tareas indicadas en la especificación.
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 practica 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. 25
Hay dos formas de organizar un área de pruebas:

• Que esté compuesta por personal inexperto y que

desconozca el tema de pruebas.

• Tener un área de pruebas conformada por

programadores con experiencia, personas que saben sin
mayores indicaciones en que condiciones puede fallar
una aplicación y que pueden poner atención en detalles
que personal inexperto no consideraría.
26
Documentación

Todo lo concerniente a la documentación del propio

desarrollo del software y de la gestión del proyecto, pasando
por modelaciones (UML), diagramas, pruebas, manuales de
usuario, manuales técnicos, etc.

Esto es con el propósito de eventuales correcciones,

usabilidad, mantenimiento futuro y ampliaciones al
sistema.
27
Mantenimiento
Mantener y mejorar el software para enfrentar errores
descubiertos y nuevos requisitos. Esto puede llevar más
tiempo incluso que el desarrollo inicial del software.

Una pequeña parte de este trabajo consiste en arreglar

errores, o bugs. La mayor parte consiste en extender el
sistema para hacer nuevas cosas.

Alrededor de 2/3 de toda la ingeniería de software tiene que

ver con dar mantenimiento 28
1.3 Metodologías del Desarrollo del Software

Una Metodología de desarrollo de software, consiste

principalmente en hacer uso de diversas herramientas,
técnicas, métodos y modelos para el desarrollo.

Existen principalmente dos tipos de metodologías para el

desarrollo de software:
• Clásicas
• Ágiles
29
1.3 Metodologías del Desarrollo
del Software
1.3.1 Clásicas

Metodología en cascada: el
estilo del modelo en cascada, es
que no podrás avanzar a la
siguiente fase, si la anterior no se
encuentra totalmente terminada,
pues no tiene porque haber
vuelta atrás. 30
Modelo de Prototipos: Consiste
básicamente en que en base a los
requerimientos y necesidades que
tiene el cliente, se realiza de forma
rápida un prototipo, este no vendrá
completo ni mucho menos
terminado, pero si permitirá contar
con las bases necesarias para que
cualquier programador pueda seguir
trabajando en él hasta llegar al
código final.
31
Modelo Incremental: Se trata de la combinación del modelo de
cascada y prototipos. Consiste en completar varias iteraciones de lo que
es el modelo de cascada, pero sin completar ninguna, haciendo
iteraciones lo que se hace es crear una evolución en el producto,
permitiendo que se agreguen nuevas especificaciones, opciones,
funciones y lo que el usuario requiera después de cada iteración.

32
Modelo en Espiral: consiste en ciertas fases que se van
realizando en modo de espiral, utilizando procesos de la misma
forma en que se utilizan en el modelo de cascada, sin embargo
aquí estos no son obligatorios y no llevan precisamente el orden
establecido.
El modelo en espiral es
principalmente utilizado
para el desarrollo de
grandes proyectos como
la creación de un sistema
operativo. 33
1.3 Metodologías del Desarrollo del Software
1.3.2 Ágiles

Las metodologías ágiles de desarrollo de software, a diferencia de

las metodologías tradicionales, funcionan mas como una
combinación de estas para lograr un objetivo.

Su finalidad siempre será el crear software de una forma más

rápida de lo que se venia logrando con las metodologías de
clásicas.
34
1.3 Metodologías del Desarrollo del Software
1.3.2 Ágiles

Una metodología ágil, consiste principalmente en trabajar con

menos documentación de la que, como vimos, las metodologías
tradicionales utilizan en todo momento.

Para comprender de que tratan las metodologías ágiles, existe un

documento llamado manifiesto ágil, en él se resume la filosofía de
este enfoque de desarrollo y se tiene una idea mas clara de hacia
donde se pretende llegar y principalmente Cómo se pretende
35
llegar a los objetivos.
Manifiesto Ágil
Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
36
Principios del Manifiesto Ágil
1. Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo. Los procesos Ágiles aprovechan
el cambio para proporcionar ventaja competitiva al
cliente.
3. Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de tiempo
más corto posible.
37
Principios del Manifiesto Ágil

4. Los responsables del negocio y los desarrolladores

trabajamos juntos de forma cotidiana durante todo
el proyecto.
5. Los proyectos se desarrollan en torno a individuos
motivados. Hay que darles el entorno y el apoyo que
necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.
38
Principios del Manifiesto Ágil

7. El software funcionando es la medida principal de

progreso.
8. Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante
de forma indefinida.
9. La atención continua a la excelencia técnica y al
buen diseño mejora la Agilidad.
39
Principios del Manifiesto Ágil

10. La simplicidad, o el arte de maximizar la cantidad de

trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños

emergen de equipos auto-organizados.

12. A intervalos regulares el equipo reflexiona sobre

cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia
40
Modelo Scrum

Para que un proyecto ingrese al marco de lo que es el modelo

Scrum, debe contar con las siguientes características:
• Desarrollo Incremental. Una metodología ágil sin desarrollo
incremental, no puede ser considerada Scrum.
• Calidad de las personas. Básicamente la calidad de un
producto, no será analizada en base a la calidad de cada uno
de los procesos llevados a cabo. Al contrario, la calidad
dependerá de las personas, la auto organización y el
conocimiento de los equipos de trabajo.
41
Modelo Scrum

• Adiós al Secuencial y Cascada. En el modelo Scrum, hay algo

a lo que se le denomina solapamiento. Esto consiste en que no
importa en que proceso se encuentre, si un proceso necesita ser
trabajado, vuelve a él para realizar lo que se tiene que hacer.
• La comunicación es Fundamental. La ventaja que es que
podrá estar en constante comunicación con los otros equipos
de trabajo, nadie está envuelto en su propia burbuja y toda la
información que se maneje o lleve a cabo, será comunicada sin
problema.
42
43
Product Backlog. El Product Backlog es una lista
de las funcionalidades del producto a desarrollar.
Sin embargo, no se trata de una lista cualquiera
hecha con escritos y nada más.
El Product Backlog debe estar ordenado de acuerdo
a las prioridades del sistema de mas a menos, con
la idea de que las cosas con mayor prioridad sean
las que se realicen primero.
Es elaborado por el Product Owner y el objetivo
base es responder a la pregunta “¿Qué hay que
hacer?”. 44
45
Sprint Backlog. Una vez que se tiene el
Product Backlog terminado, aparecerá el
primer Sprint Backlog.

Pero ¿Qué es el Sprint Backlog? Consiste básicamente en

seleccionar algunos de los puntos escritos en el Product
Backlog, los cuales procederán a ser realizados.

Sin embargo en este punto el Sprint Backlog tiene como

requisito marcar el tiempo en que se llevará a cabo el Sprint.
46
Sprint Planning Meeting. Antes de iniciar
un Sprint, el cual es la fase de desarrollo,
se realiza lo que es un Sprint Planning
Meeting.
Es una reunión que se realiza para definir plazos y procesos a
efectuarse para el proyecto establecido en el Product Backlog.
Cada Sprint, se compone de diversos features, que no son otra
cosa mas que procesos o subprocesos que se deben realizar,
puede ser la creación de un logo, la gestión de contenido, el
diseño visual, etc. Todo dependerá del proceso que se desee
llevar a cabo.
47
Daily Scrum o Stand-up Meeting. Cuando un
Sprint está en proceso, entonces entramos a lo
que son los Daily Scrum o Stand-up Meeting.

Esto consiste en hacer reuniones diarias mientras se está

llevando a cabo un Sprint, para responder las siguientes
preguntas: ¿Que hice ayer?, ¿Qué voy a hacer hoy, ¿Qué
ayuda necesito?.
Aquí entra en función el Scrum Master, quien será el
encargado de determinar la solución de los problemas y cada
complicación que suceda.
48
Sprint Review. El Sprint Review, es básicamente una reseña
de lo que fue el Sprint.

Consiste específicamente en la revisión del Sprint terminado

y para este punto ya tendría que haber algo que mostrarle al
cliente, algo realmente visual o tangible para que se pueda
analizar un cierto avance.

49
Sprint Retrospective. Para concluir, el Sprint Retrospective,
permite al equipo analizar los objetivos cumplidos, si se
cometieron errores, visualizarlos y tratar de no cometerlos
nuevamente mas adelante.

Este proceso también sirve para

lo que son la implementación de
mejoras.

50
Equipos que componen un proceso Scrum

Product Owner. (Propietario del producto) Si se trata de tener un

líder de proyecto, entonces el Product Owner lo será. Se podría
decir que son los ojos del cliente, será la persona encargada del
proyecto y de supervisar que se lleve a cabo de tal forma que
cumpla las expectativas de lo que se espera.

51
52
Equipos que componen un proceso Scrum

Scrum Master. Para cada reunión realizada, siempre debe

estar un líder, en este caso el Scrum Master será el líder de
cada una de las reuniones y ayudará en los problemas que
hayan surgido. Será como un “facilitador” el cual
minimizará obstáculos, sin embargo no los omitirá. En
realidad el Scrum Master debe ser una persona empapada
de conocimientos sobre el lenguaje o lenguajes bajo los
cuales se llevará a cabo el proyecto, de lo contrario no
tendría como ayudar a solucionar problemas.
53
54
Equipos que componen un proceso Scrum

Scrum Team. Es el núcleo de la metodología Scrum, pues

es el equipo de desarrollo, encargado de lo que es la
codificación del software y de cumplir los objetivos o metas
propuestas por el Product Owner.

55
Cliente. El cliente también
forma parte del equipo. En
la metodología Scrum, el
cliente tiene la capacidad
para influir en el proceso,
debido a que siempre estará
empapado de él, ya sea que
proponga nuevas ideas o
bien haciendo algún tipo de
comentario.
56
57
Metodología Kanban

Es una metodología Japonesa, la cual consiste en ir etiquetando

con tarjetas cada uno de los procesos que se deben llevar a cabo,
también se le ha denominado como “Un sistema de producción
de alta efectividad y productividad”.

Empresas como la marca de autos Toyota, fueron una de las

primeras en implementarla para acelerar los procesos de
producción.
58
Metodología Kanban

Una de las principales ventajas de Kanban, es que además de

ser una metodología Ágil, también es muy fácil de usar e
implementar, sobre todo porque el equipo de trabajo se unirá y
empezarán a trabajar a la par en diferentes aspectos del
desarrollo.

59
Principios Básicos de Kanban

1. Garantía de Calidad. El ser una metodología ágil, no es

sinónimo de trabajar a las carreras o de hacer todo de golpe.

Kanban promueve la calidad antes que la velocidad, es decir,

un producto bien hecho desde la primera vez que se elaboro es
más rápido, que un producto mal hecho al cual se le tienen que
volver a meter las manos para arreglarlo.

Todo debe salir bien desde el inicio y no debe haber margen de

60
error.
Principios Básicos de Kanban

2. Desperdicios. La metodología Kanban trabaja de una forma

en la cual, solamente se debe hacer lo necesario y requerido para
que el sistema o el desarrollo quede bien.

Evitando todo aquello que es considerado como extra, superficial

o innecesario. De este modo no solamente se ofrece una mayor
calidad en el producto, si no que además se optimizan tiempos y
costos.
61
Principios Básicos de Kanban

3. Mejora Continua. Algo interesante de esta metodología, es

que no solamente de trata de un sistema diseñado para
el proceso de desarrollo de Software, se puede implementar en
el desarrollo de cualquier tipo de producto.

Además es un sistema que nos da la oportunidad de ir

mejorando constantemente en los procesos, dependiendo claro de
cual sea el objetivo o la meta final.
62
Principios Básicos de Kanban

4. Es Flexible. La flexibilidad es uno de los principios de Kanban

¿Qué obtenemos con ello?. Gracias a que es flexible, podemos

adelantarnos a un proceso que queramos hacer o que tenga
cierto nivel de prioridad, no necesitamos seguir una línea de
trabajo, lo cual hace de Kanban una metodología más dinámica y
además permite resolver problemas que surjan de imprevisto,
algo que con otras metodologías simplemente ni se considera.
63
¿Cómo configurar una estrategia Kanban?

1.Definir el Flujo de Trabajo. Un tablero es requisito para esta

metodología, es entonces cuando podrás empezar a seccionarlo
dependiendo del número de tareas, fases o proyectos que
tengas en puerta.

El tablero debe estar a la vista de todo el equipo de trabajo, pues

será necesario estar al pendiente de los procesos y de ir
actualizándolos conforme se vaya avanzando en el.
64
¿Cómo configurar una estrategia Kanban?

2. Fases del Ciclo de Producción. Es importante seccionar el

tablero para ir marcando el flujo de producción.
Es necesario que los procesos sean divididos en pequeños
segmentos, para que se pueda agilizar y no se quede estancado
en uno con demasiada duración.
Es por eso que en los post-it que se van colocando con cada
proceso, deberá ser colocado el número de horas requeridas
para completarlo, al finalizar las horas se determinará el porque
no se ha terminado o bien ya se habrá avanzado a otra fase.
65
¿Cómo configurar una estrategia Kanban?

3. Stop Starting, start finishing. La filosofía de Kanban, trabaja

de esta forma, esto se debe a que la idea es tener un alto
porcentaje de tareas completadas y no como ciertos equipos de
desarrollo que tienen una gran cantidad de proyectos en puerta y
muchas tareas por hacer, la mayoría empezadas, pero ninguna
terminada.
Esta es la situación principal que se trata de evitar con Kanban y
es que aunque parezca muy obvia, la realidad es que muchos la
pasan de largo, aún cuando es fundamental.
66
¿Cómo configurar una estrategia Kanban?
4. Tener un Control. Kanban, trabaja con el control del flujo de
trabajo.
Si bien la idea es que los trabajadores tengan actividad realmente
constante y no se detengan aún cuando terminen sus tareas.
Kanban permite llevar un control de todo gracias a las notas que
se van colocando. Esto permite que se ejecuten varios proyectos
se forma simultanea, una parte del equipo pudo haber terminado
sus tareas del proyecto y avanzar al siguiente, mientras los
demás siguen todavía trabajando en ello. La idea es no provocar
interrupciones a cada momento, además de que si necesitas un
67
control, puedes ir almacenando las tarjetas y listo.
Metodología XP (Programación eXtrema)

Es la combinación de las demás metodologías, solamente que se

van utilizando de acuerdo a como sea necesario, por eso es
considerada como la más destacada de las metodologías ágiles.

68
Metodología XP (Programación eXtrema)

Valores
• Comunicación.

• Simplicidad.

• Retroalimentación.

• Respeto.
69
Características que componen la metodología XP

• Tipo de Desarrollo Iterativo e incremental.

• Pruebas Unitarias.
• Trabajo en Equipo.
• Alguien del equipo trabaja con el cliente.
• Reestructuración del Código.
• El Código es de todos.
• Código simple es la clave.

70
Equipo de Trabajo dentro de una Metodología XP
• Programador. Es el encargado del código del sistema y
además de hacer las pruebas unitarias que se solicitan.

• Tester. Es el encargado de las pruebas del desarrollo. Lo que

se vaya implementando, el teste lo prueba y le dice al cliente o
mejor dicho, le comunica al cliente las pruebas funcionales,
para posteriormente comunicarle al equipo los resultados.

71
Equipo de Trabajo dentro de una Metodología XP

• Tracker. El seguimiento será lo suyo. Será el encargado de

realizar las comparaciones entre los tiempos estimados antes
de empezar un desarrollo y los tiempos reales que se
obtuvieron. Tratando siempre de mantener al tanto al equipo
para que traten de mejorar los tiempos.
• Entrenador. Este elemento es realmente importante, puesto
que es el responsable del proyecto básicamente y precisamente
hace las funciones de un entrenador. Se encarga de guiar al
equipo por el camino que deben seguir.
72
Equipo de Trabajo dentro de una Metodología XP

• Consultor. Regularmente el consultor no formaba parte del

equipo, bueno de hecho no lo integra. El consultor sigue
siendo un externo, pero que cuenta con conocimientos
específicos y que será capaz de ayudar en la solución de
problemas.
• Gestor. Posiblemente el líder más alto. Si se trata de unir a los
clientes con los programadores, el gestor es el intermedio, es
decir. Es el encargado de vincular e interrelacionar al cliente
con los programadores.
73