18GIIN Sesion 3 - Dudas - Tema 3 - Actividad 1

18GIIN Fundamentos de Ingeniería del
Software
Sesión 3
Dudas
Tema 3
Actividad 1
18GIIN Fundamentos de Ingeniería del Software
Agenda
 Dudas
 Tema 3: El proceso de desarrollo de software

 Requisitos
 Actividad 1
2
Agenda
 Dudas

 Requisitos
 Actividad 1
3
Dudas
4
Agenda
 Dudas

 Requisitos
 Actividad 1
5
Fundamentos de Ingeniería del Software
Tema 3: El proceso de desarrollo de software

 Conceptos y términos
 Fases del desarrollo de software
• Análisis
A áli i / R
Requisitos
i it
• Diseño
• Implementación
• Pruebas
 Metodologías de desarrollo del software
6
6 6
Desarrollo de Software: Conceptos, terminología
• Proceso
• Actividad
• Tarea
• (clásico) UML
• Artefacto
• Actor
• Implicado o Stakeholder
• Metodología de Desarrollo
7 7
7
Desarrollo de Software: Conceptos [estándares ISO/IEEE]
Proceso:
• “Conjunto de actividades interrelacionadas o interactivas que transforma las entradas en
salidas”.
• “Una serie sistemática de actividades dirigidas a causar un resultado final de manera que se
actúe sobre una o más entradas para crear una o más salidas”.
• “Conjunto
Conjunto de actividades interrelacionadas o interactivas que utilizan entradas para entregar
un resultado deseado”
Actividad:
• “Conjunto de tareas cohesionadas de un proceso”.
• “Una parte distinta y programada del trabajo realizado durante el curso de un proyecto”
Tarea:
• “Acción requerida, recomendada o permitida, destinada a contribuir al logro de uno o más
resultados de un proceso”
8 8
8
UML:
• El Lenguaje de Modelado Unificado (UML) es un lenguaje estándar de modelado de software
que está destinado a p
q proporcionar
p una forma de visualizar el diseño de un sistema.
Desarrollado a mediado de los años 1990.
• Sirve para especificar o para describir métodos o procesos, es decir modelar el software. Se
utiliza p
para definir un sistema,, p
para detallar los artefactos en el sistema y p
para documentar y
construir.
• Se puede aplicar en el desarrollo de software en gran variedad de formas para dar soporte a
una metodología de desarrollo de software (está muy asociado al Proceso Unificado (PU) o
Rational Unified Process, RUP), pero no especifica en sí mismo qué metodología o proceso
usar.
https://www.omg.org/spec/UML/
9 9
9
UML (actualmente estándar ISO/IEC 19505: 2012):
• UML no es programación, solo se diagrama la realidad de una utilización en un requerimiento.
En UML 2.5 Existen dos g
grupos
p de tipos
p de diagramas:
g diagramas
g estructurales y diagramas
g
de comportamiento.
1010
10
Artefacto:
• En el marco de Proceso Unificado (PU) de desarrollo de software un artefacto es el término
general usado p
g para cualquier
q producto del p
p proceso de desarrollo: código,
g g gráficos, Web,
esquema de base de datos, documentos de texto, diagramas, modelos, etc.
• Algunos artefactos como los casos de uso, diagrama de clases u otros modelos UML
ayudan
y a la descripción
p de la función,, la arquitectura
q o el diseño del software.
Actor:
• En los diagramas de casos de uso del UML, los actores son las distintas personas (o
dispositivos) que usan el sistema o producto en el contexto de la función que va a describirse.
describirse
• Los actores representan el papel que desempeñan las personas (o dispositivos) cuando
operan el sistema.
1111
11
Implicado o Stakeholder:
• Involucrados, parte interesada o interesados, hace referencia a una persona, organización
o empresa que tiene interés en una empresa u organización dada.
• S
Software
f P j
Project S k h ld
Stakeholder: S
Se
refiere a "una persona, grupo o
empresa que participa directa o
indirectamente en el proyecto y que
puede afectar o verse afectado por el
resultado del proyecto“.
1212
12
Metodología de Desarrollo
• Si un proceso software marca las actividades y tareas que deben realizarse en un

proyecto, los métodos indican cómo desarrollar dichas tareas.
• Una metodología es el conjunto de métodos que se siguen en una investigación científica o
en una exposición doctrinal [1].
[1]
• Metodología es un sistema de prácticas, técnicas, procedimientos y reglas utilizadas por
quienes trabajan en una disciplina [2].
• Metodología en Ingeniería del Software se entiende como “un proceso para producir
software de forma organizada, empleando una colección de técnicas y convenciones de
notación predefinidas”.
p
[1] https://dle.rae.es/metodolog%C3%ADa?m=form
[2] ISO (2017). IEC/IEEE 24765: 2017 systems and software engineering-vocabulary.
engineering vocabulary. Technical report,
Institute of Electrical and Electronics Engineers, Inc. Disponible en Aula 18GIIN, Materiales de apoyo
complementarios
1313
13
Fases del desarrollo de software
Las fases del desarrollo de software pueden definirse de diversas formas aunque, en general,
las distintas metodologías incluyen, las fases de:
• Análisis, requisitos (ingeniería de requisitos)

• Diseño
• Implementación
• Pruebas, verificación y validación
Indistintamente si el modelo de desarrollo de software o ciclo de vida sea en cascada, iterativo

o de metodologías ágiles. Al finalizar el desarrollo se entra en la fase de:
• Mantenimiento
1414
14
Una opción de estas fases del desarrollo de software puede ser:
15
15
A áli i requisitos
Análisis, i it
Objetivo: Comprensión precisa de los requisitos
• "Los requisitos expresan las necesidades y restricciones que debe satisfacer un producto software para
q p y q f p f p
contribuir a la solución de un problema real" [1].
• La ingeniería de requisitos es el proceso de establecer las necesidades de los implicados
(stakeholders) que deben ser resueltas por el software.
• Esta fase implica la comunicación y colaboración con los stakeholders, fundamentalmente
para encontrar cuáles son los requisitos del producto que se debe desarrollar.
• Los requisitos nos sirven para delimitar cuál de las posibles soluciones al problema son
adecuadas (las que cumplen los requisitos) y cuáles no.
• Las principales problemáticas que hay que vencer en esta tarea son las propias de cualquier
actividad de comunicación:
• Diferencias respecto a la información con la que trabajan las diferentes partes
• Limitaciones del canal de comunicación utilizado, etc.
[1] Bourque, P., & Fairley, R. E. (2014). Guide to the software engineering body of knowledge (SWEBOK (R)): Version 3.0. IEEE Computer Society Press. Guías
disponible en pdf en Materiales de apoyo complementarios
1616
16
Fases del desarrollo de software: Análisis, requisitos
Aunque en ell ttema 4 h
A haremos una iintroducción
t d ió a lla IIngeniería
i í d de requisitos,
i it algunas
l
características son:
• Importancia de los Requisitos. Comprensión entre los distintos stakeholders
1717
17
Tipos de
Ti d Requisitos
R i it
• Requisitos de usuario
Expresiones
p en lenguaje
g j natural q
que indican las funcionalidades q
que el usuario espera
p
del sistema. Por ejemplo:
 “El software debe proporcionar un medio para la representación y acceso a ficheros
externos creados ppor otras herramientas”
• Requisitos del sistema
Servicios y restricciones que se esperan del sistema. Ejemplos:
 “Cada tipo de fichero externo tendrá asociado una herramienta que podrá ser
aplicada al fichero”
 “Cada tipo de fichero externo podrá estar representado mediante un icono
específico
ífi en lal interfaz
i t f deld l usuario”
i ”
 “Se proporcionarán utilidades para que el usuario pueda definirse el tipo de icono
que asociará a cada tipo de fichero”
1818
18
Tipos de
Ti d Requisitos
R i it
Requisitos del sistema
• Requisitos Funcionales
Especificación de lo que hará el sistema. Ejemplo:
“La
La interfaz del usuario ha de implementarse mediante un navegador web”
web
• Requisitos No Funcionales
Restricciones sobre el conjunto posible de soluciones. Pueden especificar requisitos del
producto como tiempo de respuesta, memoria requerida, fiabilidad, portabilidad. Ejemplo:
“Producto desarrollado en Java”
“El máximo espacio
p de almacenamiento ocupado
p p
por el sistema debe ser de 8 GB”
1919
19
Especificación
E ifi ió de
d Requisitos
R i it
• La especificación de requisitos define el comportamiento y las características de un sistema
o componente de un sistema.
Características de una buena especificación de requisitos (IEEE):

• No ambigua
• Completa
• Fácil de verificar
• Consistente
• Fácil de modificar
• Fácil p
para identificar el origen
g de cada requisito
q
• Fácil de utilizar durante las fases
2020
20
Tipos de
Ti d especificación
ifi ió de
d Requisitos
R i it
Historias de Usuario
• Uso muyy extendido en desarrollos ágiles.
g
Casos de Uso
• Funciones que da un sistema para añadir valor a sus
usuarios.
Escenarios de Uso
• Analiza la interacción del usuario con el sistema.
2121
21
Ti
Tipos de
d especificación
ifi ió de
d Requisitos
R i it
• Uso muy extendido en desarrollos ágiles.
Casos de Uso
• Funciones que da un sistema para añadir
valor a sus usuarios.
Escenarios de Uso
• Analiza la interacción del usuario con el
sistema.
22
22
Ti
Tipos de
d especificación
ifi ió de
d Requisitos
R i it
• Uso muy extendido en desarrollos ágiles.
Casos de Uso
• Funciones que da un sistema para añadir valor a sus
usuarios.
Escenarios de Uso
• Analiza la interacción del usuario con el sistema.
“El tiempo máximo de pérdida de servicios de la pasarela de pagos no puede ser superior a
1 minutos para clientes de Francia y Países Bajos empleado MasterCard, Visa, Carte-Blue,
iDEAL o PayPal”
2323
23
Agenda
 Dudas

 Requisitos
 Actividad 1
24
Actividad 1
DevOps
Buscar iinformación
B f ió sobre
b DevOps,
D O podéis
déi empezar por Wikipedia
Wiki di (https://es.wikipedia.org/wiki/DevOps)
(h // iki di / iki/D O ) y
en la Biblioteca de la VIU (https://universidadviu.summon.serialssolutions.com/#!/search?ho=t&l=es-
ES&q=devops).
Resumir en 2 o 3 páginas máximo:

- Descripción
- Origen
- Tabla
T bl resumen dde V
Ventajas
t j e IInconvenientes
i t
- Cómo funciona
25
Actividad 1
Proyecto (Fase 1)
Elija un proyecto d
Elij de d
desarrollo
ll dde una aplicación
li ió iinformática
f á i para solucionar
l i un problema
bl reall d
de su elección.
l ió
En las siguientes actividades de la asignatura trabajaremos sobre este mismo desarrollo.
Para el proyecto en esta primera fase necesitamos:
 Definir el proyecto (Explicación breve de un párrafo).

 Motivación (problema detectado y que aporta la aplicación propuesta a su solución).
 Funcionalidades
F i lid d (en
( estat primera
i f
fase puede
d ser textual,
t t l sin
i entrar
t en formalismos.
f li E importante
Es i t t ser lol
más preciso posibles de lo que deberá hacer y también se puede indicar lo que no hará [alcance del
proyecto]).
 Diseñar un ciclo de vida adecuado a la aplicación
p propuesta
p p (puede ser basado en alguno
(p g de los vistos
en clase o totalmente a medida combinando diferentes). Explicarlo y justificar de forma detallada el
porqué.
26
Dudas
27
Gracias

18GIIN Sesion 3 - Dudas - Tema 3 - Actividad 1

Cargado por

Información del documento

Descripción original:

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

18GIIN Sesion 3 - Dudas - Tema 3 - Actividad 1

Cargado por

Copyright:

Formatos disponibles

18GIIN Fundamentos de Ingeniería del

 Tema 3: El proceso de desarrollo de software

 Tema 3: El proceso de desarrollo de software

 Tema 3: El proceso de desarrollo de software

Tema 3: El proceso de desarrollo de software

• Si un proceso software marca las actividades y tareas que deben realizarse en un

• Análisis, requisitos (ingeniería de requisitos)

Indistintamente si el modelo de desarrollo de software o ciclo de vida sea en cascada, iterativo

Características de una buena especificación de requisitos (IEEE):

 Tema 3: El proceso de desarrollo de software

Resumir en 2 o 3 páginas máximo:

Para el proyecto en esta primera fase necesitamos:

 Definir el proyecto (Explicación breve de un párrafo).

También podría gustarte