Metología P1

Fundamentos de
Ingeniería de
Software 6368
UNIDAD 2
2.1.1 Proceso de Desarrollo de SW
2.1.2 Ciclos de Vida
Ing. Jenny Ruiz R.

SANGOLQUI – ECUADOR Dir. Carr. Ingeniería de Software
2020 Universidad de las Fuerzas Armadas ESPE
Av. General Rumiñahui s/n. Sangolquí - Ecuador
Email: jaruiz@espe.edu.ec
Cel. 0985313365 Telf. 593 (02) 3989400 Ext
1913
Contenido
1. Actividades del proceso de

desarrollo de software
2. Cómo enfrentar el cambio
3. Ciclos de vida
1. Actividades del proceso
1.1 Especificación del software
1.2 Diseño e implementación del software
1.3 Validación de software
1.4 Evolución de software
1.5 Cómo enfrentar el cambio
1.6 Creación del prototipo
1.7 Proceso Unificado Racional RUP
1.1 Especificación del software: Consiste en el

procedimiento de comprender y definir qué
servicios se requieren del sistema, así como la
identificación de las restricciones sobre la
operación y el desarrollo del sistema
Proceso de Ing de
requerimientos
1.2 Diseño e implementación del software:
Corresponde al proceso de convertir una especificación
del sistema en un sistema ejecutable, se entiende
como una descripción de la estructura del software que
se va a implementar, los modelos y las estructuras de
datos utilizados por el sistema
Modelo general de proceso
de diseño
1.3 Validación de software
Pruebas de desarrollo: las personas que desarrollan el
sistema ponen a prueba los componentes que constituyen
el sistema.
Pruebas del sistema Los componentes del sistema se
integran para crear un sistema completo
Pruebas de aceptación Ésta es la etapa final en el proceso
de pruebas, antes de que el sistema se acepte para uso
operacional.
Fases en un proceso de
software para pruebas
Evolución del sistema
1.4 Evolución de software: pensar en lugar de dos
procesos separados, es realista pensar en la Ingeniería
de software como un proceso evolutivo donde el sw
cambia a lo largo de su vida, en función de los
requerimientos y las necesidades cambiantes del cliente.
Proceso desarrollo
prototipo
Creación del prototipo
1.5 Un prototipo es una versión inicial de un sistema de
software que se usa para demostrar conceptos, tratar
opciones de diseño y encontrar más sobre el problema y
sus posibles soluciones.
1. En el proceso de IR, un prototipo ayuda con la
selección y la validación de requerimientos del sistema
2. En el proceso de diseño de sistemas, un prototipo
sirve para buscar soluciones específicas de software y
apoyar el diseño de interfaces de usuario.
1. The waterfall model
2. Incremental development
3. The process of prototype
development
4. Boehm’s spiral model of the
software process
5. Phases in the Rational
Unified Process
Flujos de trabajo estáticos
de RUP
GRACIAS POR SU ATENCIÓN
PREGUNTAS
POR FAVOR REVISAR LA U2 GUIA TAREA 7

Fundamentos de
Ingeniería de
Software 6368
UNIDAD 2
2,2 Fundamentos de Ing. de requisitos IR
Ing. Jenny Ruiz R.

Cel. 0985313365 Telf. 593 (02) 3989400 Ext
1913
Contenido
1. ¿Qué es un requisito?
2. ¿Qué es Ingeniería de
requisitos?
3. Características de los Ing. en
requisitos.
Qué es un requisito
Según la Real Academia Española de la
Lengua requisito es “Circunstancia o
condición necesaria
para algo” (RAE, 2012).
Para (IEEE, 2002)
“(1) Una condición o capacidad que un usuario
necesita para resolver un problema o lograr un
objetivo. (2) Una condición o capacidad que debe
tener un sistema o un componente de un sistema
para satisfacer un contrato, una norma, una
especificación u otro documento formal. (3) Una
representación en forma de documento de una
condición o capacidad como las expresadas en
(1) o en (2).”
Para (IEEE, 1998),
“Una declaración que identifica las características

o restricciones operativas, funcionales, o de
diseño de un producto o proceso, las cuales
deben ser: no ambiguas, verificables o
cuantificables, y que son necesarias para que el
producto o proceso sea aceptado por los clientes
o que concuerde con las directrices internas de
garantía de calidad.”
User and system requirements
Qué es un stakeholder
• Son la principal fuente de información para la
educción, análisis de requisitos y
posteriormente son actores importantes para
la validación de los mismos.
• Son las personas que van a interactuar con el
sistema, ya sea como usuarios o
administradores; también pueden ser
profesionales especializados que deben
involucrarse, según de la naturaleza del
sistema (Young, 2004).
Qué es Ing. de requisitos
IR
Para (Hsia, Davis, & Kung, 1993)
Todas las actividades relacionadas con:

• Identificación y documentación de las necesidades de
clientes y usuarios.
• Creación de un documento que describe la conducta
externa y las restricciones asociadas que satisfará
dichas necesidades.
• Análisis y validación del documento de requisitos para
asegurar consistencia, compleción y viabilidad.
• Evolución de las necesidades.”
IR
Para (Pohl, 2010)
“…el proceso de la obtención de las necesidades

individuales y las necesidades de las partes interesadas,
creando una documentación detallada, de los requisitos
acordados y especificados, de tal manera que puedan
servir de base para todas las otras actividades de
desarrollo del sistema”.
IR.
La IR. es un proceso cooperativo, iterativo e incremental,
en el cual se descubren, analizan, documentan,
comunican, validan y gestionan las características o
restricciones operativas y funcionales que se esperan del
sistema, las cuales deben ser: documentadas, completas
y acordadas entre los involucrados (stakeholders); de tal
manera que sean la base para las posteriores fases del
desarrollo del sistema.
A spiral view of the requirements
engineering process
Proceso de IR.
“Software Engineering Body of Knowledge
– SWEBOK” (IEEE Computer Society, 2004)
1. Educción o elicitación de requisitos
También llamada como “captura de requisitos”,

“descubrimiento de requisitos” o “adquisición de
requisitos” En esta fase se cumplen las siguientes
actividades:
• Comprender el problema que resolverá el software

• Identificar a los involucrados(stakeholders).
2. Análisis y negociación de requisitos
Los objetivos que se persiguen en esta fase están:
• Determinar la información útil

• Gestionar el conocimiento del dominio del problema.
• Detectar conflictos en los requisitos
• Establecer las bases para el diseño
2. Análisis requisitos
3. Especificación de requisitos
En esta fase se documentan los requisitos resultantes

del análisis. El resultado es un documento llamado
especificación de requisitos del software, las buenas
prácticas recomiendan seguir una norma para el
desarrollo de este documento, por ejemplo la norma
IEEE 830, la cual indica las características que debe
cumplir cada requisito.
4. Tipos de Requisitos
4.1 Requisitos Funcionales
Son declaraciones de los servicios que debe

proporcionar el sistema, la manera en que debe
reaccionar ante peticiones y entradas particulares.
Puede declarar explícitamente lo que el sistema no
debe hacer.
4.1 Requisitos Funcionales Ej.
Insulin Pump/Control Software/SRS/3.3.2
Function Compute insulin dose: safe sugar level.
Description
Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3
and 7 units.
Inputs Current sugar reading (r2); the previous two readings (r0 and r1).
Source Current sugar reading from sensor. Other readings from memory.
Outputs CompDose—the dose in insulin to be delivered.
Destination Main control loop.
Action
CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of increase is
decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing
the difference between the current sugar level and the previous level by 4 and rounding the result. If the result, is
rounded to zero then CompDose is set to the minimum dose that can be delivered.
Requirements
Two previous readings so that the rate of change of sugar level can be computed.
Pre-condition
The insulin reservoir contains at least the maximum allowed single dose of insulin.
Post-condition r0 is replaced by r1 then r1 is replaced by r2.
Side effects None.
4.2 Requisitos NO Funcionales
Los requisitos no funcionales se refieren a las

características de un sistema, las cuales no se pueden
expresar como funciones, se refieren a aspectos
relativos a los atributos de calidad del producto, como
por ejemplo: los requisitos de mantenibilidad,
portabilidad, facilidad de uso, el número máximo de
usuarios simultáneos, el tiempo y rendimiento Los
requisitos no funcionales también pueden incluir
problemas de fiabilidad, precisión de los resultados,
interfaz hombre-máquina temas y limitaciones en la
implementación del sistema.
Tipos de requisitos
Readers of different types of
requirements specification
Los requisitos no funcionales son obligaciones no

negociables que deben ser soportadas por el sistema.
La norma IEEE 830 detalla cuatro tipos de requisitos
no funcionales:
1. Requisitos de interfaz externa
2. Requisitos de desempeño
3. Restricciones
4. Atributos de software del sistema.
.
4.3 Requisitos de Clientes y Usuarios
Los requisitos de clientes y usuarios son los

proporcionados por el cliente al inicio de un sistema o
esfuerzo de desarrollo de software, por ejemplo, en
una solicitud de información, propuesta o cotización o
en una declaración de trabajo (SOW).
4.4 Requisitos de Requisitos de
Desarrolladores
Los requisitos reales deben ser establecidos por los

desarrolladores y deben garantizar que reflejan las
necesidades y expectativas comprobadas de los
usuarios para un determinado sistema.
Desarrolladores
Una estrategia sugerida:

1. Escribir un plan de requisitos.
2. Diseñar o adaptar un proceso de requisitos para su
proyecto.
3. La inversión en los requisitos relacionados con las
actividades del ciclo de vida del sistema.
4. La utilización de las prácticas eficaces requisitos,
mecanismos, métodos, técnicas, herramientas y
capacitación.
PREGUNTAS

Fundamentos de
Ingeniería de
Software 6368
UNIDAD 2
2.2.2 proceso de Ingeniería de requisitos
Ing. Jenny Ruiz R.

Cel. 0985313365 Telf. 593 (02) 3989400 Ext
1913
Contenido
1. ¿ Cómo se realiza la educción de
requisitos de SW ?
2. Tipos de requisitos
3. Forma de escribir requisitos
4. Evolución de requisitos
Tipos de requisitos
Readers of different types of
requirements specification
Los requisitos no funcionales son obligaciones no

negociables que deben ser soportadas por el sistema.
La norma IEEE 830 detalla cuatro tipos de requisitos
no funcionales:
1. Requisitos de interfaz externa
2. Requisitos de desempeño
3. Restricciones
4. Atributos de software del sistema.
.
4.3 Requisitos de Clientes y Usuarios
Los requisitos de clientes y usuarios son los

proporcionados por el cliente al inicio de un sistema o
esfuerzo de desarrollo de software, por ejemplo, en
una solicitud de información, propuesta o cotización o
en una declaración de trabajo (SOW).
Desarrolladores
Los requisitos reales deben ser establecidos por los

desarrolladores y deben garantizar que reflejan las
necesidades y expectativas comprobadas de los
usuarios para un determinado sistema.
4.5 Requisitos de Desarrolladores
Una estrategia sugerida:

1. Escribir un plan de requisitos.
2. Diseñar o adaptar un proceso de requisitos para su
proyecto.
3. La inversión en los requisitos relacionados con las
actividades del ciclo de vida del sistema.
4. La utilización de las prácticas eficaces requisitos,
mecanismos, métodos, técnicas, herramientas y
capacitación.
Usuarios de Doc_req
Users of a requirements
document
Chapter Description
Preface This should define the expected readership of the document and describe its
version history, including a rationale for the creation of a new version and a
summary of the changes made in each version.
Introduction This should describe the need for the system. It should briefly describe the
system’s functions and explain how it will work with other systems. It should also
describe how the system fits into the overall business or strategic objectives of
the organization commissioning the software.
Glossary This should define the technical terms used in the document. You should not
make assumptions about the experience or expertise of the reader.
User requirements definition Here, you describe the services provided for the user. The nonfunctional system
requirements should also be described in this section. This description may use
natural language, diagrams, or other notations that are understandable to
The
customers. Product and process standards that must be followed should be
specified.
System architecture This chapter should present a high-level overview of the anticipated system
structure
architecture, showing the distribution of functions across system modules.
Architectural components that are reused should be highlighted.
System requirements specification This should describe the functional and nonfunctional requirements in more
detail. If necessary, further detail may also be added to the nonfunctional
of a
requirements. Interfaces to other systems may be defined.
System models This might include graphical system models showing the relationships between
the system components and the system and its environment. Examples of
requireme
possible models are object models, data-flow models, or semantic data models.
System evolution This should describe the fundamental assumptions on which the system is
based, and any anticipated changes due to hardware evolution, changing user
nts
needs, and so on. This section is useful for system designers as it may help
them avoid design decisions that would constrain likely future changes to the
system.
Appendices These should provide detailed, specific information that is related to the
document
application being developed; for example, hardware and database descriptions.
Hardware requirements define the minimal and optimal configurations for the
system. Database requirements define the logical organization of the data used
by the system and the relationships between data.
Index Several indexes to the document may be included. As well as a normal

alphabetic index, there may be an index of diagrams, an index of functions, and
so on.
Ways of
writing a
system
requireme
nts
specificati
on
Example
requireme
nts for the
insulin
pump
software
system
Insulin Pump/Control Software/SRS/3.3.2
A Function
Description
Compute insulin dose: safe sugar level.
structured
Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3
and 7 units.
Inputs Current sugar reading (r2); the previous two readings (r0 and r1).
specificati Source
Outputs
Current sugar reading from sensor. Other readings from memory.
CompDose—the dose in insulin to be delivered.
on of a
Destination Main control loop.
Action
CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of increase is
requireme
decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing
the difference between the current sugar level and the previous level by 4 and rounding the result. If the result, is
rounded to zero then CompDose is set to the minimum dose that can be delivered.
nt for an
Requirements
Two previous readings so that the rate of change of sugar level can be computed.
insulin
Pre-condition
The insulin reservoir contains at least the maximum allowed single dose of insulin.
Post-condition r0 is replaced by r1 then r1 is replaced by r2.
pump Side effects None.

Use cases for the MHC-PMS
Requirements evolution
PREGUNTAS

Fundamentos de
Ingeniería de
Software 6368
UNIDAD 2
2.3 Fundamentos de Análisis y Diseño de
SW
Ing. Jenny Ruiz R.

Cel. 0985313365 Telf. 593 (02) 3989400 Ext
1913
Contenido
1. Revisión Metodologías Agiles

2. Conceptos Agilidad/SCRUM
3. Contexto(HU)
4. Ejemplo
Figure 1 The principles of agile methods
Principle Description
Customer involvement Customers should be closely involved throughout the development

process. Their role is provide and prioritize new system
requirements and to evaluate the iterations of the system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own ways
of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and in
the development process. Wherever possible, actively work to
eliminate complexity from the system.
Figure 2 Plan-driven and agile specification
Figure 3 The extreme programming release cycle
Figure 4 Extreme programming practices (a)
Principle or practice Description
Incremental planning Requirements are recorded on story cards and the stories to be included in a release
are determined by the time available and their relative priority. The developers break
these stories into development ‘Tasks’. See Figures 3.5 and 3.6.
Small releases The minimal useful set of functionality that provides business value is developed first.
Releases of the system are frequent and incrementally add functionality to the first
release.
Simple design Enough design is carried out to meet the current requirements and no more.
Test-first development An automated unit test framework is used to write tests for a new piece of functionality
before that functionality itself is implemented.
Refactoring All developers are expected to refactor the code continuously as soon as possible
code improvements are found. This keeps the code simple and maintainable.
Figure 4 Extreme programming practices (b)
Principle or practice Description
Incremental planning Requirements are recorded on story cards and the stories to be included in a
release are determined by the time available and their relative priority. The
developers break these stories into development ‘Tasks’. See Figures 3.5 and
3.6.
Small releases The minimal useful set of functionality that provides business value is developed
first. Releases of the system are frequent and incrementally add functionality to
the first release.
Simple design Enough design is carried out to meet the current requirements and no more.
Test-first development An automated unit test framework is used to write tests for a new piece of
functionality before that functionality itself is implemented.
Refactoring All developers are expected to refactor the code continuously as soon as
possible code improvements are found. This keeps the code simple and
maintainable.
Figure 5 A ‘prescribing medication’ story
Figure 6 Examples of task cards for prescribing medication
Figure 7 Test case description for dose checking
Figure 8 The Scrum process
Figure 8 The Scrum process
PREGUNTAS
Fundamentos de
Ingeniería de
Software 6368
UNIDAD 2
2.5.3 Técnicas de pruebas
Ing. Jenny Ruiz R.

Cel. 0985313365 Telf. 593 (02) 3989400 Ext
1913
1.Técnica de Caja Blanca
2.Técnica de Caja Negra
Caja Blanca
La prueba de caja blanca, en ocasiones
llamada prueba de caja de vidrio, es una
filosofía de diseño de casos de prueba que usa
la estructura de control descrita como parte
del diseño a nivel de componentes para
derivar casos de prueba. (Pressman,2019)
Caja Blanca
PRUEBA DE RUTA BÁSICA.
La prueba de ruta o trayectoria básica es una
técnica de prueba de caja blanca propuesta
por primera vez por Tom McCabe [McC76]. El
método de ruta básica permite al diseñador de
casos de prueba derivar una medida de
complejidad lógica de un diseño de
procedimiento y usar esta medida como guía
para definir un conjunto básico de rutas de
ejecución.
PRUEBA DE RUTA BÁSICA. (1)
Notación de gráfico o grafo de
flujo
flujo
Rutas de programa
independientes Ej 2b
PRUEBA DE RUTA BÁSICA. (4) La
complejidad ciclomática
Ejemplo caja Blanca
Caja Negra
Las pruebas de caja negra, también llamadas

pruebas de comportamiento, se enfocan en los
requerimientos funcionales del software; es
decir, las técnicas de prueba de caja negra le
permiten derivar conjuntos de condiciones de
entrada que revisarán por completo todos los
requerimientos funcionales para un programa.
(Pressman,2019)
Caja Negra
Partición de equivalencia. Es un método de

prueba de caja negra que divide el dominio de
entrada de un programa en clases de datos de
los que pueden derivarse casos de prueba.
Partición de equivalencia. (1)
Las clases de equivalencia pueden definirse de

acuerdo con los siguientes lineamientos:
Ejemplo caja Negra
PREGUNTAS
Fundamentos de
Ingeniería de
Software 6368
UNIDAD 2
2.6 Fundamentos de Mantenimiento de SW
Ing. Jenny Ruiz R.

Cel. 0985313365 Telf. 593 (02) 3989400 Ext
1913
1.Qué es mantenimiento
2. ipos de mantenimiento
3. Procesos
Mantenimiento
Tipos de Mantenimiento
Esfuerzo en el mantenimiento
Predicción del mantenimiento
Proceso de reingeniería
Especificación de Administración
del Riesgo
Triángulo del Riesgo
Proceso formal
Resumen mantenimiento
PREGUNTAS
METODOLOGÍAS
DE INGENIERÍA
DE SOFTWARE
INGENIERÍA DE SOFTWARE I
2º DE GRADO EN INGENIERÍA INFORMÁTICA
CURSO 2017/2018
Francisco José García Peñalvo / fgarcia@usal.es

Alicia García Holgado / aliciagh@usal.es
Departamento de Informática y Automática

Universidad de Salamanca
INTRODUCCIÓN
Desde una perspectiva de Ingeniería de Software, una metodología
• Describe cómo se organiza un proyecto
• Establece el orden en el que la mayoría de las actividades tienen
que realizarse y los enlaces entre ellas
• Indica cómo tienen que realizarse algunas tareas proporcionando
las herramientas concretas e intelectuales
Con una metodología se intentan cubrir las siguientes necesidades

[Piattini et al., 2004]
• Mejores aplicaciones
• Mejor proceso de desarrollo
• Establecer un proceso estándar en una organización
2
Ingeniería de Software I - Metodologías de Ingeniería de Software
DEFINICIÓN DE
METODOLOGÍA
Un proceso para producir software de forma
organizada, empleando una colección de
técnicas y convenciones de notación
predefinidas (Rumbaugh et al., 1991)
3
CONFUSIÓN ENTRE LOS TÉRMINOS
METODOLOGÍA, MÉTODO Y CICLO DE VIDA POR
ABUSO DEL LENGUAJE TÉCNICO
• Una metodología puede seguir uno o varios modelos de ciclo de
vida
• El ciclo de vida indica qué es lo que hay que obtener a lo largo
del desarrollo del proyecto, pero no cómo. Esto sí lo debe
indicar la metodología
• Una metodología es un concepto más amplio que el de método
• Se puede considerar a la metodología como un conjunto de
métodos
4
CARACTERÍSTICAS DESEABLES
EN UNA METODOLOGÍA
Una metodología debe cubrir (Henderson-Sellers y Firesmith, 1999)
• Un proceso de ciclo de vida completo, que comprenda aspectos tanto del
negocio como técnicos
• Un conjunto completo de conceptos y modelos que sean internamente
consistentes
• Una colección de reglas y guías
• Una descripción completa de artefactos a desarrollar
• Una notación con la que trabajar, idealmente soportada por diversas
herramientas CASE y diseñada para una usabilidad óptima
• Un conjunto de técnicas probadas
• Un conjunto de métricas, junto con asesoramiento sobre calidad,
estándares y estrategias de prueba
• Identificación de los roles organizacionales
• Guías para la gestión de proyectos y aseguramiento de la calidad
• Asesoramiento para la gestión de bibliotecas y reutilización
5
METODOLOGÍAS
ESTRUCTURADAS
• Proponen la creación de modelos del sistema que representan los
procesos, los flujos y la estructura de los datos de una manera
descendente
• Se pasa de una visión general del problema, nivel de abstracción
alto, a un nivel de abstracción sencillo
• Esta visión se puede enfocar
• Hacia un punto de vista funcional del sistema
• Metodologías orientadas a procesos
• Hacia la estructura de datos
• Metodologías orientadas a datos
6
METODOLOGÍAS ESTRUCTURADAS
ORIENTADAS A PROCESOS
• La Ingeniería del Software se fundamenta en el modelo básico
entrada/proceso/salida de un sistema
• Estas metodologías se enfocan fundamentalmente en la parte de proceso
• Utilizan un enfoque de descomposición descendente para evaluar los
procesos del espacio del problema y los flujos de datos con los que están
conectados
• Este tipo de metodologías se desarrolló a lo largo de los años 70
• Representantes de este grupo son las metodologías de análisis y diseño
estructurado como
• Merise (Tardieu et al., 1986)
• YSM (Yourdon Systems Method) (Yourdon Inc., 1993)
• SSADM (Structured Systems Analysis and Design Method) (Ashworth y Goodland,
1990)
• METRICA v.2.1 (MAP, 1995)
• METRICA v3.0 (Parcialmente) (MAP, 2001)
7
METODOLOGÍAS ORIENTADAS
A OBJETOS
• Se fundamentan en la integración de los dos aspectos de los
sistemas de información: datos y procesos
• En este paradigma un sistema se concibe como un conjunto de
objetos que se comunican entre sí mediante mensajes
• El objeto encapsula datos y operaciones
• Este enfoque permite un modelado más natural del mundo real y
facilita enormemente la reutilización del software
• Las metodologías orientadas a objetos acortan la distancia existente
entre el espacio de conceptos (lo que los expertos o usuarios
conocen) y el espacio de diseño e implementación
8
A OBJETOS
Gran cantidad de representantes
• Metodologías dirigidas por los datos
• OMT (Object Modeling Technique) (Rumbaugh et al., 1991)
• Fusion (Coleman et al., 1994)
• Metodologías dirigidas por las responsabilidades
• RDD (Responsibility Driven Design) (Wirfs-Brock et al., 1990)
• OBA (Object Behavior Analysis) (Rubin y Goldberg, 1992)
• Metodologías dirigidas por los casos de uso
• Objectory (Jacobson et al., 1992)
• Proceso Unificado (Jacobson et al., 1999)
• Metodologías dirigidas por estados
• Metodología de Shlaer y Mellor (Shlaer y Mellor, 1992)
9
A OBJETOS
Evolución de las metodologías OO
Metodologías de primera generación
RDD Objectory
OMT Booch (91) Unificación,
Estandarización
UML
Metodologías de
Métricas segunda generación
Metodologías de
tercera generación
OMT 2 Syntropy
Lenguajes OPEN
MEDEA UP
Formales Fusion Moses
Booch (94)
10
A OBJETOS
Metodologías estructuradas vs. Metodologías Orientadas a Objetos
Análisis Diseño Implementación

PROCESOS
Metodologías estructuradas
STD
DFD PROGRAMA
DATOS
RELACIONAL TABLAS
DER
11
A OBJETOS
Metodologías Orientadas a Objetos
Análisis Diseño Implementación

OBJETOS
12
A OBJETOS
Por Elaboración
O
O
ANÁLISIS DISEÑO
ado
r
ctu
rt u
Es
Por Transformación
13
METODOLOGÍAS ÁGILES
Las aproximaciones ágiles emplean procesos técnicos y de
gestión que continuamente se adaptan y se ajustan a (Turk et al.,
2002)
• Cambios derivados de las experiencias ganadas durante el
desarrollo
• Cambios en los requisitos
• Cambios en el entorno de desarrollo
La agilidad en el desarrollo del software no significa únicamente
poner en el mercado o en explotación los productos software más
rápidamente
• Esto choca frontalmente con los modelos de procesos tradicionales
que son monolíticos y lentos, centrados en una única iteración o
ciclo de larga duración
14
AGILE MANIFESTO
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to
value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
While there is value in the items on the right, we value the items
on the left more.
Agile Manifesto
15
METODOLOGÍAS ÁGILES
La agilidad significa respuesta efectiva al cambio
pero incluye
• Estructuras de equipo y actitudes para facilitar la comunicación entre los
miembros
• Énfasis en la entrega rápida de software funcional, para lo que resta importancia a
los productos intermedios (lo cual siempre no es bueno)
• Adopción del cliente como parte del equipo de desarrollo
• Planificación incierta y, por tanto, flexible
16
EXTREME PROGRAMMING
Controvertido enfoque de desarrollo de software basado en el modelo
incremental
Está indicado para
• Equipos de tamaño mediano o pequeño
• Requisitos imprecisos y cambiantes
Características (Beck, 2000)
• El juego de la planificación
• Versiones pequeñas
• Metáfora
• Diseño sencillo
• Hacer pruebas
• Refactorización
• Programación en parejas
• Propiedad colectiva
• Integración continua
• Cliente in-situ
• Estándares de codificación
17
SCRUM
• Propuesto por Jeff Sutherland y desarrollado por Shwaber y
Beedle (Schwaber, 1995)
• El conjunto de buenas prácticas de Scrum se aplica
esencialmente a la gestión de proyecto
• Es un framework, por lo que es necesaria su adaptación en
cada organización o incluso en cada equipo
• El objetivo es obtener resultados rápidos con adaptación a los
cambios de las necesidades de los clientes
• Las principales características de Scrum
• El desarrollo software mediante iteraciones incrementales
• Las reuniones a lo largo del proyecto
18
SCRUM
Scrum se basa en entregas
parciales priorizadas por el
beneficio que aporta al receptor
final del producto
19
SCRUM
• Actividades estructurales
• Requisitos
• Análisis
• Diseño
• Evolución
• Entrega
• Dentro de cada actividad las tareas se organizan con un
patrón de proceso denominado sprint
• El trabajo del sprint se adapta al problema y se define y
modifica en tiempo real por el equipo Scrum
• Uso de patrones de proceso de demostrada eficacia en
proyectos críticos, con plazos cortos y requisitos cambiantes
20
SCRUM
• Scrum define un ciclo de vida iterativo e incremental, que
mejora la gestión del riesgo y aumenta la comunicación
• Se basa en tres pilares
• Transparencia
• Todos los aspectos del proceso que afectan al resultado son visibles para todos
aquellos que administran dicho resultado
• Inspección
• Se debe controlar con la suficiente frecuencia los diversos aspectos del
proceso para que puedan detectarse variaciones inaceptables en el mismo
• Revisión
• El producto debe estar dentro de los límites aceptables
• En caso de desviación se procederá a una adaptación del proceso y del
material procesado
• Mecanismo de mejora continua, esto es, de control, para adaptarse y mejorar
21
SCRUM
Cada equipo Scrum tiene tres roles
• Scrum Master. Es el responsable de asegurar que el equipo Scrum siga las prácticas de
Scrum. Sus funciones
• Ayudar a que el equipo y la organización adopten Scrum
• Liderar el equipo Scrum para buscar la mejora en la productividad y la calidad de los
entregables
• Ayudar a la autogestión del equipo
• Gestionar e intentar resolver los impedimentos con los que el equipo se encuentra para cumplir
las tareas del proyecto
• Product owner. Es la persona responsable de gestionar las necesidades que se quieren
satisfacer mediante el desarrollo del proyecto. Sus funciones
• Recolectar las necesidades (historias de usuario)
• Gestionar y ordenar las necesidades
• Aceptar el producto software al finalizar cada iteración
• Maximizar el retorno de la inversión del proyecto
• Equipo de desarrollo. Tiene las siguientes características
• Autogestionado. El mismo equipo supervisa su trabajo (no existe el rol clásico de jefe de
proyecto)
• Multifuncional. Cada integrante del equipo debe ser capaz de realizar cualquier función
• No distribuidos. Es conveniente que el equipo se encuentre en el mismo lugar físico
• Tamaño óptimo. Al menos tres personas, máximo nueve, sin contar al scrum master ni al
product owner
22
SCRUM
Acciones de los patrones de proceso
• Retraso (pila de producto o product backlog): priorización de
requisitos. Debe estar detallado de manera adecuada, estimado,
emergente y priorizado
• Sprints: unidades de trabajo requeridas para alcanzar un requisito.
Es cada iteración. Se recomiendan iteraciones cortas (1-4 semanas)
y cuyo resultado será un producto software potencialmente
entregable. El equipo de desarrollo selecciona las historias de
usuario que se van a desarrollar en el sprint para conformar así la
pila de sprint (sprint Backlog). La definición de cómo descomponer,
analizar o desarrollar este sprint backlog queda a criterio del equipo
de desarrollo. Además, la lista de tareas se mantendrá inamovible
durante toda la iteración
• Reuniones Scrum: reuniones breves dirigidas por el maestro
Scrum
• Demostraciones preliminares: entrega de un incremento al cliente
23
SCRUM
Reunión 24 h.
diaria
Tareas backlog 1-4

ampliadas por el semanas
Sprint backlog equipo
Incremento del producto

Product backlog Demostración de su funcionalidad
(priorizado por el cliente)
24
BIBLIOGRAFÍA
• F. J. García-Peñalvo y A. García-Holgado, "Introducción a la
Ingeniería del Software," Recursos docentes de la asignatura
Ingeniería de Software I. Grado en Ingeniería Informática. Curso
2017-2018, F. J. García-Peñalvo y A. García-Holgado, Eds.,
Salamanca, España: Grupo GRIAL, Universidad de Salamanca,
2018. [Online]. Disponible en: https://goo.gl/9bVcWo. doi:
10.5281/zenodo.1182457. (pp. 65-90)
• F. J. García-Peñalvo y A. García-Holgado, "Modelos de proceso,"
Recursos docentes de la asignatura Ingeniería de Software I.
Grado en Ingeniería Informática. Curso 2017-2018, F. J. García-
Peñalvo y A. García-Holgado, Eds., Salamanca, España: Grupo
GRIAL, Universidad de Salamanca, 2018. [Online]. Disponible en:
https://goo.gl/xYYJGM. doi: 10.5281/zenodo.1179286. (pp. 63-71)
25
METODOLOGÍAS
DE INGENIERÍA
DE SOFTWARE
INGENIERÍA DE SOFTWARE I
2º DE GRADO EN INGENIERÍA INFORMÁTICA
CURSO 2017/2018
Francisco José García Peñalvo / fgarcia@usal.es

Alicia García Holgado / aliciagh@usal.es
Departamento de Informática y Automática

Universidad de Salamanca
Fundamentos de
Ingeniería de
Software 6368
UNIDAD 2
Lenguaje Natural
Ing. Jenny Ruiz R.

Cel. 0985313365 Telf. 593 (02) 3989400 Ext
1913
Contenido
1 Efectos relacionados con el

lenguaje
2 Construcción de requerimientos
utilizando plantillas de fases
3 Resumen
Retos en la modelación.
• Los lenguajes naturales parecen

ser apropiados para la definición
de requisitos.
• Pero los lectores interpretan los
lenguajes naturales de forma
diferente.
Los requerimientos son puestos de
manifiesto por distintas personas,
leídos por personas con distintas
características socio-culturales.
1. Conocimiento y experiencia
2. Capacidades sociales y de
comunicación
3. Antecedentes culturales
Transformación de la información
Transformación (de acuerdo PNL ,

programación neurolingüística).
1. Generalización
2. Selección
3. Distorsión
1. Generalización
Generalización de le experiencia
Ej en tren siempre llega tarde
Pregunta: ¿El tren llegará un 10%
más tarde?
Pregunta: ¿El tren llegó tarde
todos los días de la semana
pasada?.
2. Selección
El énfasis está dirigido solo a una parte

específica de nuestra experiencia. Otras
experiencias o características son ignoradas.
Ej: el sistema debe incluir autenticación de
usuario.
Preguntas: ¿Cómo tendrá lugar la
autenticación? ¿Quién crea los usuarios en el
sistema? ¿Qué medidas de seguridad serán
aplicadas?
3. Distorsión(1 de 2)
• Remodelado de la experiencia
• Todas las formas de trabajo creativo son
distorsiones.
• Todo aquello que no ha existido previamente
es el resultado de un trabajo creativo.
3. Distorsión (2 de 2)
Ej. el medio de transporte más económico para

ir desde aquí al centro de la ciudad es el
automóvil
Pregunta: ¿Qué datos conducen a esta
afirmación? Es decir que ir desde aquí hasta el
centro de la cuidad en automóvil es el medio
más económico. ¿Se tienen acceso a una
evaluación de los datos que apoyen esta
información?
Documentación en
lenguaje natural
1. Ejemplo 1: debe,
tiene
Documentación en
lenguaje natural
Utilizar solo verbos para describir una actividad

o un procedimiento.
Solo se permitirá el uso de verbos para describir
proceso.
Ej: imprimir, guardar, presentar.
Documentación en
lenguaje natural
Ej 2. “Deberá ser capaz de imprimir”
1. Evitar ambigüedad
2. Utilizar glosario
3. Utilizar distintos niveles de detalles
Caracterizar el comportamiento del
sistema
Debe << Proceso >>
Proporcionar <<>>, con la

El sistema Tiene que
capacidad de << proceso>>
Ser capaz de
Deberá
<< proceso >>
Ejemplo 3: el sistema deberá imprimir

Identificar los objetos involucrados
Debe <<Proceso>>
Proporcionar <<>>, con
El sistema Tiene que la capacidad de << <<Objeto>>

proceso>>
Ser capaz de
Deberá
<<proceso>>
Ejemplo 4: el sistema deberá ofrecer posibilidades de imprimir recibos

Reglas para la especificación de requerimientos:
1.Utilizar frases y párrafos cortos.

2.Solo un requisito por frase.
3.Terminología consistente sustentada por un
glosario.
4.Evitar generalizaciones, utilizar referencias
claras.
Resumen
En lenguaje natural es un medio útil para
especificar requisitos, pero puede conducir a la
ambigüedad.
Los requisitos pueden ser interpretados de
diferentes forma, debido a los diferentes niveles
del conocimiento sobre el dominio del problema,
que tienen los interesados.
PREGUNTAS
POR FAVOR REVISAR LA U2 GUIA TAREA 9,10

Metodologías
Desarrollo SW
UNIDAD 1
1.1 Metodologías de desarrollo de SW
Ing. Jenny Ruiz R.

SANGOLQUI – ECUADOR Docente TC DCCO
Cel. 0985313365 Telf. 593 (02) 3989400 Ext
1913
Metodología de desarrollo
de software
Definición
Conjunto de técnicas y procedimientos

organizados en fases para el desarrollo de
productos software, de manera eficaz, y
abarca el ciclo de vida del mismo
Objetivos:
• Apoyar a la comprensión del sistema (el
todo y las partes).
• Guiar el desarrollo de todas las fases del
ciclo de vida del software: análisis,
diseño, construcción, pruebas e
implantación
• Ayudar en el desarrollo de documentación
de alta calidad que permita un fácil
mantenimiento
• Trazar el camino para realizar un trabajo
de manera eficiente y eficaz.
Metodología(I)
Metodología (II)
Metodologías
estructuradas
• Se basan en la descomposición funcional
de problemas en unidades más
pequeñas interrelacionadas entre sí
• Representan los procesos, flujos y
estructuras de datos, de una manera
jerárquica y ven el sistema como
entradas-proceso-salidas
• Tienen un enfoque top-down
Breve historia(I)
1968 Conceptos sobre la programación

estructurada de DIJKSTRA
1974 Técnicas de programación
estructurada de WARNIER y JACKSON
1975 Primeros conceptos sobre diseño
estructurado de MYERS y YOURDON
1977 Primeros conceptos sobre análisis
estructurado GANE y SARSON
Breve historia(II)
1978 Análisis estructurado: DEMARCO y

WEINBERG
1981 SSADM (versión inicial)
1985 Análisis y Diseño estructurado para
sistemas de tiempo real de WARD y
MELLOR
1986 SSADM Versión 3
1987 Análisis y Diseño estructurado para
sistemas de tiempo real de HATLEY y
PIRHBAY
Breve historia(III)
1989 METRICA (versión inicial)

1990 SSADM Versión 4
1993 METRICA Versión 2
1995 METRICA Versión 2.1
Metodologías
estructuradas (I)
Ejemplo
– Edward Yourdon
• Construir un modelo ambiental
– DFD de contexto
– Lista de acontecimientos
– DFD preliminares
Metodologías
estructuradas (II)
• Construir un modelo de
comportamiento
– DFD de diferentes niveles
– Especificación de procesos
– DER
– Diccionario de datos
– DTE
• Balancear modelos
Metodologías
estructuradas (III)
• Ejemplos
– Gane y Sarson
• Construir el modelo lógico actual (DFD
lógico actual)
• Construir el modelo del nuevo sistema:
elaborar una especificación estructurada y
construir un modelo lógico de datos.
Metodologías
estructuradas (IV)
• Seleccionar un modelo lógico
• Crear el nuevo modelo físico del
sistema
• Empaquetar la especificación
Metodologías Orientadas
a Objetos (I)
• Son interactivas e incrementales.
• Se fomenta la reutilización de
componentes.
Metodologías Orientadas
a Objetos (II)
Proceso Unificado de Desarrollo (PUD/RUP)
Es un proceso de ingeniería del software
que provee una disciplina para la
asignación de tareas y responsabilidades
dentro de una empresa de desarrollo. Su
meta es la de asegurar la producción de
software de alta calidad que satisfaga las
necesidades de los usuarios finales dentro
de un plan de trabajo y presupuesto
predecibles.
6 Mejores Prácticas
según RUP
• Desarrollo iterativo de software.
• Gestión de requerimientos.
• Uso de arquitectura basada en
componentes.
• Modelamiento visual del software.
• Verificación de la calidad del
software.
• Control de cambios en el software.
Estructura para la
Planificación
Disciplinas y Modelo
Fases del Ciclo de Vida
Metodologías Ágiles(I)
2001 “The Agile Alliance”
Manifiesto Ágil.
• Los individuos y las interacciones entre
ellos son más importantes que las
herramientas y los procesos empleados
• Es más importante crear un
producto software que funcione que
escribir documentación exhaustiva
Metodologías Ágiles(II)
• La colaboración con el cliente debe

prevalecer sobre la negociación de
contratos
• La capacidad de respuesta ante un
cambio es más importante que el
seguimiento estricto de un plan.
Metodologías Ágiles(III)
• Actualmente existen más de 20

metodologías ágiles, sin contar los
métodos híbridos de desarrollo que
integran en sus prácticas, por ejemplo a
XP con Scrum.
• Existe una metodología ágil más
elaborada o estructurada que las demás,
llamada Agile Unified Process (AUP),
inspirada en el Rational Unified Process
(RUP).
Programación Extrema –
XP (I)
Programación extrema es una
metodología ágil que ha gozado de un
alto nivel de difusión, la cual se
fundamenta en los siguientes puntos:
Se orienta a cumplir con los

requerimientos del cliente,
involucrándolo en el equipo de
desarrollo.
Programación Extrema –
XP (II)
• Procura detectar los errores en las
etapas iniciales del proceso, mediante el
uso de pruebas unitarias.
• Apoya al desarrollo de las personas
que integran el equipo de trabajo,
creando ambientes de inter-
aprendizajes.
XP (III)
Fases de XP
Criterios XP - Scrum
Methods and Practices (I)
Methods and Practices
(II)
(III)
(III)
Link material de Somerville 9:
SE9 web index (st-andrews.ac.uk)
PREGUNTAS
3594 Metodologías
de Desarrollo de
SW
Proceso de desarrollo de software
Ing. Jenny Ruiz R.

SANGOLQUI – ECUADOR Docente TC DCCO
Cel. 0985313365 Telf. 593 (02) 3989400 Ext
1913
Contenido U1(1,2)
1.2.1 Especificación del software.

1.2.2 Diseño e implementación del
software
1.2.3 Validación de Software.
Contenido
1. ¿Qué es un requisito?
2. ¿Qué es Ingeniería de
requisitos?
3. Características de los Ing. en
requisitos.
Según la Real Academia Española de la
Lengua requisito es “Circunstancia o
condición necesaria
para algo” (RAE, 2012).
Para (IEEE, 2002)
“(1) Una condición o capacidad que un usuario
necesita para resolver un problema o lograr un
objetivo. (2) Una condición o capacidad que debe
tener un sistema o un componente de un sistema
para satisfacer un contrato, una norma, una
especificación u otro documento formal. (3) Una
representación en forma de documento de una
condición o capacidad como las expresadas en
(1) o en (2).”
Para (IEEE, 1998),
“Una declaración que identifica las características

o restricciones operativas, funcionales, o de
diseño de un producto o proceso, las cuales
deben ser: no ambiguas, verificables o
cuantificables, y que son necesarias para que el
producto o proceso sea aceptado por los clientes
o que concuerde con las directrices internas de
garantía de calidad.”
Ejemplo Requisitos
Qué es un stakeholder
• Son la principal fuente de información para la
educción, análisis de requisitos y
posteriormente son actores importantes para
la validación de los mismos.
• Son las personas que van a interactuar con el
sistema, ya sea como usuarios o
administradores; también pueden ser
profesionales especializados que deben
involucrarse, según de la naturaleza del
sistema (Young, 2004).
IR
Para (Hsia, Davis, & Kung, 1993)
Todas las actividades relacionadas con:

• Identificación y documentación de las necesidades de
clientes y usuarios.
• Creación de un documento que describe la conducta
externa y las restricciones asociadas que satisfará
dichas necesidades.
• Análisis y validación del documento de requisitos para
asegurar consistencia, compleción y viabilidad.
• Evolución de las necesidades.”
IR
Para (Pohl, 2010)
“…el proceso de la obtención de las necesidades

individuales y las necesidades de las partes interesadas,
creando una documentación detallada, de los requisitos
acordados y especificados, de tal manera que puedan
servir de base para todas las otras actividades de
desarrollo del sistema”.
IR.
La IR. es un proceso cooperativo, iterativo e incremental,
en el cual se descubren, analizan, documentan,
comunican, validan y gestionan las características o
restricciones operativas y funcionales que se esperan del
sistema, las cuales deben ser: documentadas, completas
y acordadas entre los involucrados (stakeholders); de tal
manera que sean la base para las posteriores fases del
desarrollo del sistema.
A spiral view of the requirements
engineering process
“Software Engineering Body of Knowledge
– SWEBOK” (IEEE Computer Society, 2004)
1. Educción o elicitación de requisitos
También llamada como “captura de requisitos”,

“descubrimiento de requisitos” o “adquisición de
requisitos” En esta fase se cumplen las siguientes
actividades:
• Comprender el problema que resolverá el software

• Identificar a los involucrados(stakeholders).
2. Análisis y negociación de requisitos
Los objetivos que se persiguen en esta fase están:
• Determinar la información útil

• Gestionar el conocimiento del dominio del problema.
• Detectar conflictos en los requisitos
• Establecer las bases para el diseño
Proceso de adquisición y aAnálisis
requisitos
Proceso Análisis requisitos EJ
CU requisitos EJ
Creación de prototipos EJ
Evolución de requisitos
Administración del cambio de requisitos
3. Especificación de requisitos
En esta fase se documentan los requisitos resultantes

del análisis. El resultado es un documento llamado
especificación de requisitos del software, las buenas
prácticas recomiendan seguir una norma para el
desarrollo de este documento, por ejemplo la norma
IEEE 830, la cual indica las características que debe
cumplir cada requisito.
Contenido
1. ¿Qué es un modelo?
2. ¿Por qué modelamos?
3. Clasificación de los modelos
Qué es un modelo
1. Es una simplificación de la realidad
2. Un modelo proporciona los planos de un sistema, los
planos pueden ser detallados o generales
3. Un buen modelo incluye aquellos elementos que son
relevantes para el nivel dado de abstracción.
4. Cada modelo es, por tanto, una abstracción
semánticamente cerrada del sistema.
5. Un modelo puede ser estructural, haciendo hincapié en
la organización del sistema, o puede ser de
comportamiento, haciendo hincapié en la dinámica del
sistema
Grady Booch
Cuándo hacer modelos
Dependiendo de la complejidad del problema se
generarán los modelos necesarios, se seleccionarán las
herramientas y equipos de trabajo
Por qué modelar
• Visualiza de manera global
• Aumenta gradualmente el conocimiento
• Proyecta o anticipa la estructura o funcionamiento de
algo
• Simula la manipulación de algo y observar los
resultados.
• Toma decisiones.
• Documenta para revisiones futuras
Los modelos en la
Ingeniería de
Software
Modelos:
1. Conceptuales
2. Orientados a procesos
3. Orientados a datos/objetos
4. Orientados a estados
Modelos Conceptuales
Favorecen la comprensión de los requisitos del
usuario, describen el dominio del discurso
The context of the MHC-PMS
Tomado de Figures – Chapter 5

Somerville 9 Edic.
Modelos Sistema
Permiten anticipar el funcionamiento del futuro sistema
software
Microwave oven operation

Somerville 9 Edic.
Ontología subyacente
Los modelos conceptuales tienen un propósito
específico y describen el dominio del discurso
con:
• léxico = símbolos o constructores
• sintaxis, la cual gobierna la combinación de
los símbolos constructores = reglas
Ej Modelos conceptuales 1
Transfer-data use case

Somerville 9 Edic.
Ej Modelos conceptuales 2
MHC-PMS: Transfer data
Actors Medical receptionist, patient records system (PRS)
Description A receptionist may transfer data from the MHC-PMS to a general

patient record database that is maintained by a health authority. The
information transferred may either be updated personal information
(address, phone number, etc.) or a summary of the patient’s diagnosis
and treatment.
Data Patient’s personal information, treatment summary
Stimulus User command issued by medical receptionist
Response Confirmation that PRS has been updated
Comments The receptionist must have appropriate security permissions to access

the patient information and the PRS.
Tabular description of the ‘Transfer data’ use-case

Somerville 9 Edic.
Ej. UML 1
Use cases involving the role

‘Medical Receptionist

Somerville 9 Edic.
Ej. UML 2
Sequence diagram for View patient information

Somerville 9 Edic.
Ej. Modelo conceptual 3
Tomado de “Modelos conceptuales”

Diestes O.
Unified Modeling Language
1. Según la OMG, “UML es una especificación
que define un lenguaje gráfico para:
visualizar, especificar, construir y
documentar los artefactos de sistemas”
2. UML es el resultado de la unificación de
varias técnicas de modelado orientadas a
objetos.
3. UML es un lenguaje que cuenta con una
sintáxis y una semántica propia que ha
atravesado por varias revisiones y
refinamientos desde su creación
“El 80 por ciento de la mayoría de los
problemas pueden modelarse usando
alrededor del 20 por ciento de UML” - Grady
Booch
Historia
2.3
2.2 (May 2010)
2.0 (Feb 2009)
1.5 (Jul 2005)
(Mar 2003)
1.0
(Ene 1997)
Otros métodos
OOSE
Elementos de UML
• Vistas: Conjunto de diagramas
• Diagramas: 13 tipos de grafos
• Elementos del modelo: Clases, objetos,
mensajes, relaciones…
• Mecanismos generales: Comentarios,
información, semántica, extensiones y
adaptaciones
Diagramas
Diagramas de
comportamiento
Diagramas
estructurales
Diagramas de clases Ej. 1
Diagrama de clases
Representa una colección de
elementos del modelo
estático, tales como clases y
tipos, sus contenidos y sus
relaciones
Classes and associations in the MHC-PMS

Diagramas de secuencia
Ej. 2
Diagrama de secuencias
Modela la secuencia lógica, a
través del tiempo, de la
interacción entre los objetos,
a través de mensajes. Order processing
Diagramas de máquina de
estados Ej. 3
Diagrama de máquinas de estados
Describe los estados que pueden tener un objeto o

interacción, así como las transiciones entre dichos
estados. Se lo denomina también diagrama de
estado, diagrama de estados y transiciones o
diagrama de cambio de estados.
Diagramas de máquina de
estados Ej. 3
State diagram of a microwave oven

Contexto de la prueba de software (IEEE
Computer Society, 2014)
(International Software Testing Qualifications
Board, 2018
Las pruebas del software se encuentran relacionadas con

diversas áreas:
1. Mantenimiento del software.
2. Calidad del software.
3. Construcción del software.
4. Pruebas de unidad y de integración están
íntimamente relacionadas con la construcción de
software.
Fundamentos de Pruebas de SW
Según el International Software Testing Qualifications

Board, define las pruebas del software como: “El proceso
que consiste en todas las actividades de ciclo de vida,
tanto estáticas como dinámicas relacionadas con la
planificación, preparación y evaluación de productos de
software y productos relacionados con el trabajo para
determinar que cumplen los requisitos especificados,
para demostrar que son aptos para el propósito y para
detectar defectos” .
Objetivos típicos de las pruebas
• Evaluar productos de trabajo como requisitos, historias
de usuario, diseño y código.
• Para verificar si se han cumplido todos los requisitos
especificados.
• Para validar si el objeto de prueba está completo y
funciona como los usuarios y otras partes interesadas
esperar.
• Crear confianza en el nivel de calidad del objeto de
prueba.
• Para prevenir defectos .
• Para encontrar fallas y defectos.
Figura 1. Modelo en V
Pruebas de requisitos / pruebas de aceptación
Determinan si un sistema satisface sus criterios de

aceptación, generalmente al verificar los
comportamientos deseados del sistema con los
requisitos del cliente
Pruebas del diseño / pruebas de integración y de
sistema
La fase de diseño tiene como objetivo generar un

conjunto de especificaciones completas del sistema
que se va a implementar, transformando los
requisitos en un Plan de implementación.
Prueba de integración
Es el proceso de verificar las interacciones entre los

componentes del software. Las estrategias de
prueba de integración clásicas, como de arriba
hacia abajo y de abajo hacia arriba, a menudo se
usan con software estructurado jerárquicamente.
Prueba de sistema
Se refiere a probar el comportamiento de un

sistema completo. Las pruebas efectivas de unidad
e integración habrán identificado muchos de los
defectos del software.
Revisiones e inspecciones del código fuente /
pruebas unitarias
Las revisiones e inspecciones de código fuente son

una técnica para la detección manual de errores en
el código (Bashir and Goel 2000).
Figura 2 An input-output model of program testing
Figura 3 Inspections and testing
Figura 4 A model of the software testing process
Figura 5 Partición equivalente (CB 1)
Figura 6 Partición equivalente (CB 2)
Figura 7 Interface testing
Caja Blanca
Enfoque a las pruebas de programa, donde las

pruebas se basan en el conocimiento de la
estructura del programa y sus componentes. El
acceso al código fuente es esencial para
las pruebas de caja blanca.
Caja Negra
Un enfoque a las pruebas donde los examinadores

no tienen acceso al código fuente de
un sistema o sus componentes. Las pruebas se
derivan de la especificación del sistema.
1.Técnica de Caja Blanca
2.Técnica de Caja Negra
Caja Blanca
La prueba de caja blanca, en ocasiones
llamada prueba de caja de vidrio, es una
filosofía de diseño de casos de prueba que usa
la estructura de control descrita como parte
del diseño a nivel de componentes para
derivar casos de prueba. (Pressman,2019)
Caja Blanca
PRUEBA DE RUTA BÁSICA.
La prueba de ruta o trayectoria básica es una
técnica de prueba de caja blanca propuesta
por primera vez por Tom McCabe [McC76]. El
método de ruta básica permite al diseñador de
casos de prueba derivar una medida de
complejidad lógica de un diseño de
procedimiento y usar esta medida como guía
para definir un conjunto básico de rutas de
ejecución.
flujo
flujo
Rutas de programa
independientes Ej 2b
PRUEBA DE RUTA BÁSICA. (4) La
complejidad ciclomática
Ejemplo caja Blanca
Caja Negra
Las pruebas de caja negra, también llamadas

pruebas de comportamiento, se enfocan en los
requerimientos funcionales del software; es
decir, las técnicas de prueba de caja negra le
permiten derivar conjuntos de condiciones de
entrada que revisarán por completo todos los
requerimientos funcionales para un programa.
(Pressman,2019)
Caja Negra
Partición de equivalencia. Es un método de

prueba de caja negra que divide el dominio de
entrada de un programa en clases de datos de
los que pueden derivarse casos de prueba.


Ejemplo caja Negra
PREGUNTAS

Metología P1

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

Metología P1

Cargado por

Copyright:

Formatos disponibles

Fundamentos de

Ing. Jenny Ruiz R.

1. Actividades del proceso de

1.1 Especificación del software: Consiste en el

POR FAVOR REVISAR LA U2 GUIA TAREA 7

Ing. Jenny Ruiz R.

“Una declaración que identifica las características

Todas las actividades relacionadas con:

“…el proceso de la obtención de las necesidades

También llamada como “captura de requisitos”,

• Comprender el problema que resolverá el software

Los objetivos que se persiguen en esta fase están:

• Determinar la información útil

En esta fase se documentan los requisitos resultantes

Son declaraciones de los servicios que debe

Los requisitos no funcionales se refieren a las

Los requisitos no funcionales son obligaciones no

Los requisitos de clientes y usuarios son los

Los requisitos reales deben ser establecidos por los

Una estrategia sugerida:

POR FAVOR REVISAR LA U2 GUIA TAREA 9

Ing. Jenny Ruiz R.

Los requisitos no funcionales son obligaciones no

Los requisitos de clientes y usuarios son los

Los requisitos reales deben ser establecidos por los

Una estrategia sugerida:

Index Several indexes to the document may be included. As well as a normal

pump Side effects None.

POR FAVOR REVISAR LA U2 GUIA TAREA 10

Ing. Jenny Ruiz R.

1. Revisión Metodologías Agiles

Customer involvement Customers should be closely involved throughout the development

Principle or practice Description

Principle or practice Description

Ing. Jenny Ruiz R.

Las pruebas de caja negra, también llamadas

Partición de equivalencia. Es un método de

Las clases de equivalencia pueden definirse de

Ing. Jenny Ruiz R.

Francisco José García Peñalvo / fgarcia@usal.es

Departamento de Informática y Automática

Con una metodología se intentan cubrir las siguientes necesidades

Análisis Diseño Implementación

Análisis Diseño Implementación

Tareas backlog 1-4

Incremento del producto

Francisco José García Peñalvo / fgarcia@usal.es

Departamento de Informática y Automática

Ing. Jenny Ruiz R.

1 Efectos relacionados con el

• Los lenguajes naturales parecen

Transformación (de acuerdo PNL ,

El énfasis está dirigido solo a una parte

Ej. el medio de transporte más económico para

Utilizar solo verbos para describir una actividad

Debe << Proceso >>

Proporcionar <<>>, con la

Ejemplo 3: el sistema deberá imprimir

Proporcionar <<>>, con

El sistema Tiene que la capacidad de << <<Objeto>>

Ejemplo 4: el sistema deberá ofrecer posibilidades de imprimir recibos

1.Utilizar frases y párrafos cortos.