Introducción a la Ingeniería de
Software
UNIDAD # 1
MSIG. KATTY LINO
Temas
• Introducción a la Ingeniería de Software
• Procesos del Software
• Desarrollo Metodologías Ágiles
• Requerimientos de Ingeniería de Software
Introducción
Objetivos de la Unidad
Entender los conflictos
Conocer que es la Comprender las distintas
éticos y profesionales que
Ingeniería de Software y técnicas de Ingeniería de
son importantes para los
por qué es importante Software
ingenieros de Software
Definiciones Básicas
¿Qué es la Ingeniería de Software?
Es el proceso de desarrollo que seguimos para construir
un sistema informático y posteriormente mantenerlo,
ajustándonos siempre a diferentes factores: recursos,
coste, duración, calidad, etc.
La ingeniería de software es importante por
dos razones:
Cada vez con mayor frecuencia, los individuos y la sociedad se apoyan en los
avanzados sistemas de software. Por ende, se requiere producir económica y
rápidamente sistemas confiables.
A menudo resulta más barato a largo plazo usar métodos y técnicas de
ingeniería de software para los sistemas de software, que sólo diseñar los
programas como si fuera un proyecto de programación personal. Para muchos
tipos de sistemas, la mayoría de los costos consisten en cambiar el software
después de ponerlo en operación
Actividades fundamentales de la Ingeniería de
Software
Especificación Desarrollo
Evolución del
Validación
software
¿Cuáles son los costos de la Ingeniería de
Software?
Desarrollo
60%
Producto
Final
Pruebas
40%
Ingeniería de Software
El software no es sólo
Los productos de
un programa o
software se desarrollan
programas, sino que
para el cliente o para
también incluye
un mercado en general
documentación.
Atributos esenciales del buen software
Estándares de comportamiento aceptable
para un Ingeniero de Software
1. Debe respetar la confidencialidad de
2. No hay que aceptar de manera
sus empleadores o clientes sin importar
intencional trabajo que esté fuera de su
si se firmó o no un acuerdo formal
competencia
sobre la misma
3. Tiene que conocer las leyes locales
que rigen el uso de la propiedad
4. No debe emplear sus habilidades
intelectual, como las patentes y el
técnicas para usar incorrectamente las
copyright. Debe ser cuidadoso para
computadoras de otros individuos
garantizar que se protege la propiedad
intelectual de empleadores y clientes
Ética en la Ingeniería de Software
Los ingenieros de software deben comprometerse a hacer del
análisis, la especificación, el diseño, el desarrollo, la prueba y el
mantenimiento del software, una profesión benéfica y respetada.
De acuerdo con su compromiso con la salud, la seguridad y el
bienestar del público, los ingenieros de software tienen que
adherirse a los ocho principios siguientes:
Principios del Código de Ética en la
Ingeniería de Software
Proceso de
Desarrollo de
Software
Proceso de Desarrollo de Software
Existen muchos procesos de
Es una serie de actividades
software pero todos deben
relacionadas que conduce a
incluir 4 actividades que
la elaboración de un
son fundamentales para la
producto de software
Ingeniería de Software
Proceso de Desarrollo de Software
Evolución del
Software
Validación del
Software
Diseño e
implementación
del Software
Especificación
del Software
Modelos de Proceso
Modelo en Cascada
Desarrollo incremental
Modelo en Cascada (Waterfall)
Toma las actividades fundamentales
del proceso de especificación,
desarrollo. validación y evolución y ,
luego, los representa como fases
separadas del proceso, tal como
especificación de requerimientos,
diseño de software, implementación,
pruebas
Modelo en Cascada - Características
Una fase no
comienza hasta que
la anterior ha
Consiste en la terminado.
ejecución secuencial
de una serie de fases
Primer modelo
empleado (Royce,
1970), también
denominado ciclo de
vida clásico y modelo
lineal secuencial.
Problemas que en ocasiones surgen al aplicar
el modelo de la cascada
1. Es raro que los proyectos reales sigan el flujo secuencial propuesto por el
modelo. Aunque el modelo lineal acepta repeticiones, lo hace en forma
indirecta. Como resultado, los cambios generan confusión conforme el
equipo del proyecto avanza.
2. A menudo, es difícil para el cliente enunciar en forma explícita todos
los requerimientos. El modelo de la cascada necesita que se haga y tiene
dificultades para aceptar la incertidumbre natural que existe al principio
de muchos proyectos.
3. El cliente debe tener paciencia. No se dispondrá de una versión
funcional del(de los) programa(s) hasta que el proyecto esté muy
avanzado. Un error grande sería desastroso si se detectara hasta revisar el
programa en funcionamiento.
Desarrollo Incremental
Este enfoque vincula las actividades de
especificación, desarrollo y validación. El sistema
se desarrolla como una serie de
versiones(incrementos) y cada versión añade
funcionalidad a la versión anterior
Se basa en la idea de diseñar una implementación
inicial, exponer ésta al comentario del usuario y
luego desarrollarla en diversas versiones hasta
producir un sistema adecuado. Las actividades de
especificación, desarrollo y validación están
entrelazadas en vez de separadas, con rápida
retroalimentación a través de las actividades.
Beneficios del Desarrollo incremental
Es más sencillo obtener retroalimentación
Es posible que sea más rápida la entrega e
del cliente sobre el trabajo de desarrollo
Se reduce el costo de adaptar los implementación de software útil al cliente,
que se realizó. Los clientes pueden
requerimientos cambiantes del cliente. La aun si no se ha incluido toda la
comentar las demostraciones del software y
cantidad de análisis y la documentación que funcionalidad. Los clientes tienen
darse cuenta de cuánto se ha
tiene que reelaborarse son mucho menores posibilidad de usar y ganar valor del
implementado. Los clientes encuentran
de lo requerido con el modelo en cascada. software más temprano de lo que sería
difícil juzgar el avance a partir de
posible con un proceso en cascada
documentos de diseño de software.
Problemas del enfoque incremental
La estructura del sistema tiende a degradarse
El proceso no es visible. Los administradores
conforme se tienen nuevos incrementos. A menos
necesitan entregas regulares para medir el
que se gaste tiempo y dinero en la refactorización
avance. Si los sistemas se desarrollan
para mejorar el software, el cambio regular tiende
rápidamente, resulta poco efectivo en términos
a corromper su estructura. La incorporación de
de costos producir documentos que reflejen cada
más cambios de software se vuelve cada vez más
versión del sistema.
difícil y costoso
Metodologías
de Desarrollo
Ágil
Las metodologías ágiles de desarrollo de
software
Nacieron como respuesta a
Proceso que permite al
la creciente necesidad de la
equipo dar respuestas
industria por entregar
rápidas e impredecibles a
productos de calidad en el
las valoraciones que reciben
menor tiempo y costo
sobre su proyecto.
posible.
Desarrollo de Metodologías Ágiles
La filosofía pone el énfasis
La ingeniería de software
en: la satisfacción del Los equipos pequeños y
ágil combina una filosofía
cliente y en la entrega muy motivados para
con un conjunto de
rápida de software efectuar el proyecto
lineamientos de desarrollo.
incremental
Los lineamientos de
Los métodos informales, los
desarrollo enfatizan la
productos del trabajo con
entrega sobre el análisis y el
mínima ingeniería de
diseño y la comunicación
software y la sencillez
activa y continua entre
general en el desarrollo.
desarrolladores y clientes
Principios de Agilidad
Son bienvenidos los
requerimientos cambiantes, aun
La prioridad más alta es Entregar con frecuencia software
en una etapa avanzada del
satisfacer al cliente a través de la que funcione, de dos semanas a
desarrollo. Los procesos ágiles
entrega pronta y continua de un par de meses, de preferencia
dominan el cambio para
software valioso. lo más pronto que se pueda.
provecho de la ventaja
competitiva del cliente.
Hay que desarrollar los
El método más eficiente y eficaz
Las personas de negocios y los proyectos con individuos
para transmitir información a los
desarrolladores deben trabajar motivados. Debe darse a éstos el
integrantes de un equipo de
juntos, a diario y durante todo el ambiente y el apoyo que
desarrollo, y entre éstos, es la
proyecto. necesiten, y confiar en que harán
conversación cara a cara
el trabajo.
Principios de Agilidad
Los procesos ágiles promueven
el desarrollo sostenible. Los
La atención continua a la
La medida principal de avance es patrocinadores, desarrolladores
excelencia técnica y el buen
el software que funciona. y usuarios deben poder
diseño mejora la agilidad.
mantener un ritmo constante en
forma indefinida.
El equipo reflexiona a intervalos
Las mejores arquitecturas,
regulares sobre cómo ser más
requerimientos y diseños surgen
eficaz, para después afinar y
de los equipos con organización
ajustar su comportamiento en
propia.
consecuencia
Ventajas de las metodologías ágiles
Mejora de la motivación e
Mejoran la satisfacción del Permite ahorrar tiempo y
implicación del equipo de
cliente costes.
desarrollo.
Eliminar cualquier
Se trabaja con mayor velocidad
característica innecesaria del
y eficiencia.
producto.
Principales metodologías agiles
Extreme
Programming
Programación
Usa un enfoque orientado a objetos como
Extrema paradigma preferido de desarrollo, y engloba un
conjunto de reglas y prácticas
FASES
XP
• Se adapta al desarrollo de sistemas pequeños y
mediano tamaño.
• Se optimiza, agiliza y complementa
conocimientos haciendo la programación en
Ventajas parejas
• La XP brinda no solo ventajas en cuanto a
rapidez, sino que promueve habilidades sociales
como la comunicación, el trabajo en equipo y
disciplina.
Marco de trabajo Ágil que permite atender y resolver
problemas complejos, proponiendo soluciones
SCRUM creativas para entregar productos con el mayor valor
posible al negocio en el menor tiempo.
SCRUM
Se realizan reuniones
periódicamente, con un máximo
Se trabaja en ciclos cortos de de 15 minutos, y en ellas el
trabajo (de dos a cuatro propio cliente se involucra para
semanas) ver el trabajo desarrollado, y
proponer cambios o
modificaciones.
Pilares de SCRUM
Transparencia Inspección Adaptación
• Todos los • Los miembros del • El equipo se ajusta
implicados tienen equipo Scrum para conseguir el
conocimiento de frecuentemente objetivo
qué ocurre en el inspeccionan el
proyecto y cómo progreso para
ocurre. detectar posibles
problemas.
ROLES DE SCRUM
HITOS DE LA METODOLOGÍA SCRUM
HITOS DE LA METODOLOGÍA SCRUM
• En esta reunión todo el equipo Scrum define qué tareas se van
Sprint Planning a abordar y cuál será el objetivo del sprint.
• Es una reunión diaria dentro del sprint que tiene como máximo
Daily meeting 15 minutos de duración.
• Su duración es de 4 horas para sprints de un mes, y es la única
Sprint review reunión de Scrum a la que puede asistir el cliente.
Sprint • Tiene una duración de 3 horas para Sprints de un mes, y es la
reunión del equipo en la que se hace una evaluación de cómo
retrospective se ha implementado la metodología Scrum en el último sprint.
Herramientas para la
metodología Scrum
Product Backlog
• Es el listado de tareas que engloba todo un
proyecto
• La responsabilidad exclusiva de ordenar el product
backlog es del Product Owner, que se encuentra en
constante comunicación con el cliente para
asegurarse de que las prioridades están bien
establecidas.
Sprint backlog
• Es el grupo de tareas del product backlog que el
equipo de desarrollo elige en el sprint planning
junto con el plan para poder desarrollarlas.
Conocida como ‘Tarjeta Visual» muy útil para los responsables de
proyectos.
Es un marco de trabajo que requiere una comunicación en tiempo
real sobre la capacidad del equipo, utilizado para controlar el avance
de trabajo en una línea de producción, en la cual se clasifican las
KANBAN tareas en sub estatus, esto con la intención de determinar los niveles
de productividad en cada fase del proyecto.
Consiste en la elaboración de un cuadro o diagrama en el que se
reflejan tres columnas de tareas; pendientes, en proceso o
terminadas.
KANBAN
Para el desarrollo de software, gracias a su sencillez KANBAN,
simplifica la planificación y la asignación de
responsabilidades, en un tablero se representan los procesos
del flujo de trabajo, cómo mínimo deben existir tres columnas
(Pendiente, En Progreso, Terminado), la cantidad de tarjetas
en estatus pendiente forma parte de lo solicitado por el
cliente, aquellas colocadas en progreso dependerán de la
capacidad del equipo de trabajo.
El cuadro debe estar al alcance de todos los miembros del
equipo, evitando así la repetición de tareas o la posibilidad de
que se olvide alguna de ellas.
Planificación de tareas
Ventajas de Mejora en el rendimiento de trabajo del equipo
Kanban Los plazos de entregas son continuos
Tiempos de ciclos reducidos.
Menos cuellos de botella.
Entrega continua.
Objetivos
• Entender los conceptos de requerimientos del usuario y del sistema, así
como por qué tales requerimientos se deben escribir en diferentes formas;
• Comprender las diferencias entre requerimientos de software funcionales y
no funcionales;
• Reconocer cómo se organizan los requerimientos dentro de un documento
de requerimientos de software;
• Conocer las principales actividades de la ingeniería de requerimientos:
adquisición, análisis y validación, así como las relaciones entre dichas
actividades;
• Analizar por qué es necesaria la administración de requerimientos y cómo
ésta apoya otras actividades de la ingeniería de requerimientos.
Requerimientos
Los requerimientos para un sistema son descripciones de lo que
el sistema debe hacer: el servicio que ofrece y las restricciones
en su operación.
Al proceso de descubrir,
analizar, documentar y
Tales requerimientos
verificar estos servicios y
reflejan las necesidades de
restricciones se le llama
los clientes
Ingeniería de
Requerimientos (IR).
Requerimientos del Usuario & Requerimientos del
Sistema
Son enunciados, en un lenguaje natural junto
con diagramas, acerca de qué servicios
Requerimientos de Usuario
esperan los usuarios del sistema, y de las
restricciones con las cuales éste debe operar.
Clasificación
Son descripciones más detalladas de las
funciones, los servicios y las restricciones
operacionales del sistema de software.
El documento de requerimientos del sistema
(llamado en ocasiones especificación
funcional) tiene que definir con exactitud lo
Requerimientos del Sistema que se implementará.
Puede formar parte del contrato entre el
comprador del sistema y los desarrolladores
del software.
Requerimientos del
Usuario &
Requerimientos del
Sistema
Requerimientos funcionales
Son enunciados acerca de
servicios que el sistema debe
En algunos casos, los
proveer, de cómo debería
requerimientos funcionales
reaccionar el sistema a entradas
también explican lo que no debe
particulares y de cómo debería
hacer el sistema.
comportarse el sistema en
situaciones específicas.
Requerimientos funcionales
La especificación de los requerimientos funcionales de un
sistema debe ser completa y consistente.
Totalidad significa que Consistencia quiere decir
deben definirse todos los que los requerimientos
servicios requeridos por tienen que evitar
el usuario. definiciones contradictorias.
Ejemplos de Requerimientos Funcionales
Requerimientos no funcionales
Son requerimientos que no se relacionan directamente con los servicios
específicos que el sistema entrega a sus usuarios.
Los requerimientos no funcionales,
Pueden relacionarse con propiedades
como el rendimiento, la seguridad o la
emergentes del sistema, como
disponibilidad, especifican o restringen
fiabilidad, tiempo de respuesta y uso
por lo general características del
de almacenamiento.
sistema como un todo.
Tipos de Requerimientos no funcionales
Tipos de Requerimientos no funcionales
Requerimientos del producto
Estos requerimientos especifican o restringen el
comportamiento del software.
Los ejemplos incluyen requerimientos de rendimiento
sobre qué tan rápido se debe ejecutar el sistema y
cuánta memoria requiere, requerimientos de fiabilidad
que establecen la tasa aceptable de fallas,
requerimientos de seguridad y requerimientos de
usabilidad
Tipos de Requerimientos no funcionales
Requerimientos de la
organización Son requerimientos de sistemas amplios, derivados de políticas y procedimientos
en la organización del cliente y del desarrollador.
Los ejemplos incluyen requerimientos del proceso operacional que definen cómo
se usará el sistema, requerimientos del proceso de desarrollo que especifican el
lenguaje de programación, estándares del entorno o el proceso de desarrollo a
utilizar, y requerimientos ambientales que definen el entorno de operación del
sistema.
Tipos de Requerimientos no funcionales
Requerimientos externos
Este término cubre todos los requerimientos derivados de factores externos al
sistema y su proceso de desarrollo.
En ellos se incluyen requerimientos regulatorios que establecen lo que debe
hacer el sistema para ser aprobado en su uso por un regulador, como sería un
banco central; requerimientos legislativos que tienen que seguirse para
garantizar que el sistema opere conforme a la ley, y requerimientos éticos que
garanticen que el sistema será aceptable para sus usuarios y el público en
general.
Ejemplos
Métricas para especificar requerimientos no
funcionales
Ejemplos de Requerimientos No Funcionales
Ejemplos de Requerimientos No Funcionales
