TRAZABILIDAD Y

CONFIGURACION DE SOFTWARE
 Sara Sofia Santibañez Ortega
 Profesor David Rodríguez
CALENDARIO ACTIVIDADES
FEBRERO

FEBRERO tareas

1 2 3 4 5
Foro
1

6 7 8 9 10 11 12

13 14 15 16 17 18 19
TEST Foro
1 2

20 21 22 23 24 25 26

27 28
 REQUERIMIENTOS

 Descripciones de lo que el sistema debe hacer

 Necesidades de los clientes

REQUERIMIENTOS DEL USUARIO

Enunciados en lenguaje natural junto con diagramas acerca de que servicios esperan los
usuarios del sistemas y de las restricciones con las cuales este debe operar
REQUERIMIENTOS DEL SISTEMA
Descripciones más detalladas de las funciones, los servicios y las restricciones
operacionales del sistema de software
El documento de requerimientos del sistema (especificación funcional) tiene que
definir con exactitud lo que se implementará.

Requerimientos Funcionales
Son enunciados acerca de servicios que el sistema debe proveer de cómo debería
reaccionar el sistema de entradas particulares y de cómo debería comportarse el sistema
en situaciones especificas

Requerimientos NO Funcionales
Son limitaciones sobre servicios o funciones que ofrece el sistema, incluyen
restricciones tanto de temporización y del proceso de desarrollo
Se suelen aplicar al sistema como un todo, más que a características o a servicios
individuales del sistema
 REQUERIMIENTOS DEL PRODUCTO: Estos requerimientos especifican o
restringen el comportamiento del software. Los ejemplos incluyen
requerimientos de rendimiento sobre que tan rápido se debe ejecutar el sistema
 REQUERIMIENTOS DE LA ORGANIZACION: Son sistemas amplios,
derivados de políticas y procedimientos en la organización del cliente y del
desarrollador
 REQUERIMIENTOS EXTERNOS: Son todos los requerimientos derivados de
factores externos al sistema y su proceso de desarrollo. Se incluyen
 requerimientos regulatorios que establecen lo que debe hacer el sistema para ser
aprobado por un regulador

Requerimientos legislativos que tienen que seguirse para garantizar que el

sistema opere conforme a la ley

METRICAS Requerimientos no Funcionales:

CASOS DE USO
Permiten identificar visualmente a los actores implicados y como interactúan, lo anterior se
complementa con información adicional que describe la interacción con el sistema.
La información adicional puede ser una descripción textual o bien, uno o más modelos
gráficos como una secuencia UML o un gráfico de estado

EJEMPLOS:

ESCENARIOS DE APLICACIÓN:
 SISTEMAS NUEVOS
Con un buen levantamiento de RF se puede conocer las necesidades para crear un
sistema que automatice tareas que posiblemente se estén llevando a cabo a mano
SISTEMAS EXISTENTES
Al conocer los RF Se puede conocer cómo funciona un sistema existente y hacer
mejoras sobre el mismo o crear nuevos módulos para ampliar la funcionalidad.

GESTIÓN DE REQUERIMIENTOS

GESTION DE REQUERIMIENTOS: Es el proceso de gestionar adecuaciones de

peticiones nuevas que se han hecho sobre un sistema. Los requerimientos evolucionan por
los cambios qué hay en el entorno del sistema y porque los clientes adquieren un mejor
entendimiento de sus necesidades reales conforme el proyecto avanza.
Para reducir el impacto en el proyecto por los cambios que surjan es necesaria la gestión de
requerimientos, en la que los cambios sean documentados y controlados.

PRINCIPALES PREOCUPACIONES
 Gestionar los cambios a los requerimientos acordados
 Gestionar las relaciones entre requerimientos
 Gestionar las dependencias entre la documentación inicial y otros documentos
que se producen durante el proceso de ingeniería de software

GESTION DEL CAMBIO

Tiene que ver con los procedimientos, procesos y estándares que se usan para administrar el
cambio de los requerimientos del sistema. Se asegura que toda la información común se
recolecta para cada cambio y que todas las decisiones alrededor de aceptarlo de hacen con
un previo análisis del costo beneficio que traerá.

Para asegurar un enfoque consistente de gestión de cambios, las organizaciones deberán

definir un grupo de políticas que cubran:
1. Un proceso para requerir el cambio y la información que se requiere para procesar
cada cambio de requerimiento.
2. Un proceso para analizar el impacto y el costo del cambio y la información de
trazabilidad asociada.
3. Un grupo evaluador el cual califique cual es la aportación global que este cambio
producirá al sistema
4. Un programa informático o un proceso electrónico para el proceso de control de
cambios (en caso de existir uno)

PROCESO:
Consiste en un grupo de actividades para documentar, reportar, analizar, presupuestar e
implementar cambios a un grupo de requerimientos. Puede ser pensado en 3 pasos:
1. Algunos problemas en los requerimientos son identificados: Los problemas se
pueden identificar de un análisis más profundo de los requerimientos, nuevas
necesidades del cliente, o problemas operacionales con el sistema.
2. Los cambios propuestos se analizan para ver cuántos requerimientos son
afectados En esta etapa se hace un primer análisis de cuanto costará en tiempo y
dinero hacer el cambio
3. Se implementa el cambio un grupo de adecuaciones al documento de
requerimientos o una nueva versión de este es creada.

ACTIVIDADES EN EL PROCESO DE GESTION DE CAMBIO

1) El requerimiento de cambios se revisa para ver si es válido. Algunas veces, los
clientes no entienden del todo los requerimientos y sugieren cambios innecesarios.
2) Los requerimientos que están directamente afectados por el cambio se descubren
3) La información de trazabilidad se usa para encontrar requerimientos dependientes
que podrían ser afectados por el cambio.
4) Se proponen los cambios que se deben de hacer a los requerimientos actuales. Se
debe volver con los clientes para asegurarse que estos cambios satisfacen sus
necesidades
 5) Se calculan los costos derivados de hacer los cambios. La estimulación debe incluir
tanto el esfuerzo requerido para hacer cambio y el impacto en el tiempo de entrega
del proyecto.
6) Se negocia con los clientes para ver si los costos implicados por el cambio son
aceptables para ellos. Si el cliente considera que el costo es muy alto, se debe volver
al paso 4 para proponer alternativas al cambio.

Etapas para rechazar requerimientos

1. Si el cambio al requerimiento es invalido. Esto normalmente pasa cuando el cliente
no entiende algo acerca del requerimiento y propone un cambio que no es
necesario.
2. Si el requerimiento de cambio no es aceptable por el usuario
3. Si el costo de implementar el cambio es muy alto (monetariamente) o toma mucho
tiempo.

CONCEPTOS
 La gestión de requerimientos es el proceso de gestionar adecuaciones de peticiones
nuevas que se han hecho sobre un sistema.
 Nuevos requerimientos surgen y los preexistentes cambian en todas las etapas en el
proceso de desarrollo de sistemas. Es común que más del 50% de los requerimientos del
sistema cambien antes de llevarlo a producción.
 Los cambios a los requerimientos del sistema pueden ser causados por una mala
interpretación en el proceso de ingeniería de requerimientos, en el diseño o por
problemas en la implementación. Nuevos requerimientos pueden surgir mientras los
involucrados desarrollan un mejor entendimiento del sistema. Sin embargo, la causa más
común del cambio en los requerimientos se debe a cambio en circunstancias externas.
 La gestión del cambio tiene que ver con los procedimientos, procesos y estándares que se
usan para administrar el cambio a los requerimientos del sistema.
 El requerimiento de cambio se revisa para ver si es válido. Algunas veces, los clientes no
entienden del todo los requerimientos y sugieren cambios innecesarios.
 Se calculan los costos derivados de hacer los cambios. La estimación debe incluir tanto el
esfuerzo requerido para hacer el cambio y el impacto en el tiempo de entrega del
proyecto.
 El cambio el requerimiento puede ser rechazado en tres (3) etapas en este proceso: [1] Si
el cambio al requerimiento es inválido. Esto normalmente pasa cuando el cliente no
entiende algo acerca del requerimiento y propone un cambio que no es necesario.
 Si el requerimiento de cambio no es aceptable por el usuario.

 Si el costo de implementar el cambio es muy alto (monetariamente) o toma mucho

tiempo.
 La gestión del cambio involucra manejar grandes cantidades de información y pasarla a
través de varias personas en la organización. Frecuentemente es necesario mantener
registro de la información sobre los cambios propuestos, cuáles fueron implementados,
cuáles están siendo considerados / evaluados etc. Todo el proceso descrito podría
beneficiarse de la ayuda de una herramienta automatizada. El problema con este tipo de
herramientas es que conllevan implícitamente su propio modelo de gestión de cambio.
 La gestión del cambio involucra manejar grandes cantidades de información y pasarla a
través de varias personas en la organización. Frecuentemente es necesario mantener
registro de la información sobre los cambios propuestos, cuáles fueron implementados,
cuáles están siendo considerados / evaluados etc. Todo el proceso descrito podría
beneficiarse de la ayuda de una herramienta automatizada. El problema con este tipo de
herramientas es que conllevan implícitamente su propio modelo de gestión de cambio.
 Herramientas de propósito específico como procesadores de texto, hojas de cálculo y
sistemas de correo electrónico pueden ser usadas para implementar un sistema de gestión
de cambios más limitado.
 Los requerimientos son descripciones de lo que el sistema debe hacer: el servicio que
ofrece y las restricciones en su operación.
 Los requerimientos pueden ser tan sencillos como un enunciado abstracto de alto nivel en
un servicio que debe proporcionar un sistema, o bien, una restricción sobre un sistema o
tan complejo como una definición detallada y formal de una función del sistema.
 Los requerimientos del usuario son enunciados en lenguaje natural junto con diagramas,
acerca de qué servicios esperan los usuarios del sistema, y de las restricciones con las
cuales éste debe operar.
 Los requerimientos del sistema 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 que se implementará.
 Los requerimientos funcionales son enunciados acerca de servicios que el sistema debe
proveer, de cómo debería reaccionar el sistema a entradas particulares y de cómo debería
comportarse el sistema en situaciones específicas. En algunos casos, los requerimientos
funcionales también explican lo que no debe hacer el sistema.
 Los requerimientos no funcionales son limitaciones sobre servicios o funciones que ofrece
el sistema. Incluyen restricciones tanto de temporización y del proceso de desarrollo,
como impuestas por los estándares. Los requerimientos no funcionales se suelen aplicar al
sistema como un todo, más que a características o a servicios individuales del sistema.
 Los requerimientos del producto

 especifican o restringen el comportamiento del software.

 Los ejemplos incluyen requerimientos de rendimiento sobre qué tan rápido se debe
ejecutar el sistema.
 Los requerimientos de la organización son de sistemas amplios, derivados de políticas y
procedimientos en la organización del cliente y del desarrollador
 Los requerimientos externos incluyen los regulatorios que establecen lo que debe hacer el
sistema para ser aprobado en su uso por un regulador, como sería un banco central.
 Los diagramas de casos de uso permiten identificar visualmente a los actores implicados y
como interactúan, lo anterior se complementa con información adicional que describe la
interacción con el sistema.
 Los requerimientos funcionales son enunciados acerca de servicios que el sistema debe
proveer, de cómo debería reaccionar el sistema a entradas particulares y de cómo debería
comportarse el sistema en situaciones específicas. Las definiciones del ejemplo caen en
esa categoría.
 Los requerimientos del producto especifican o restringen el comportamiento del software.
Los ejemplos incluyen requerimientos de rendimiento sobre qué tan rápido se debe
ejecutar el sistema [“Una consulta de saldo del cajero automático no debe exceder 5.5
segundos”].
 Los requerimientos del producto especifican o restringen el comportamiento del software.
Los ejemplos incluyen requerimientos de cuánta memoria requiere el sistema [“Se deben
poder registrar al menos 20,000 usuarios concurrentes en el sistema de venta de boletos
en línea”].
 Los requerimientos del producto incluyen requerimientos de [39] fiabilidad que
establecen la tasa aceptable de fallas [“El servicio de impresión debe estar disponible al
menos el 98% del tiempo”].
 Los requerimientos del producto incluyen requerimientos de seguridad [-”se debe requerir
user y password de directorio activo para poder acceder a la red WiFi del campus”] y
requerimientos de usabilidad [“El icono de cesta de compra debe ser de color naranja y
ser visible en todo momento en la esquina superior derecha de la página web”]
 Los ejemplos de requerimientos de la organización incluyen el proceso operacional que
definen cómo se usará el sistema [“Todos los usuarios se autenticarán por medio de
tarjetas NFC o móviles que cuenten con esta tecnología”].
 Los requerimientos de la organización especifican el lenguaje de programación,
estándares del entorno [“El desarrollo debe llevarse a cabo en lenguaje C++”] o el proceso
de desarrollo a utilizar, y requerimientos ambientales [“Ningún usuario podrá imprimir
más de 20 páginas al mes”] que definen el entorno de operación del sistema.
 Requerimientos de externos incluyen, 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.
 Para construir diagramas de casos de uso cada caso de uso debe documentarse con una
descripción textual, cada clase de interacción se constituye como una elipse con etiqueta,
las líneas vinculan a los actores con la interacción (opcionalmente, se agregan puntas de
flecha a las líneas para mostrar cómo se inicia la interacción) y se Identifican las
interacciones individuales entre el sistema y sus usuarios u otros sistemas.
 Los requerimientos del usuario son enunciados en lenguaje natural junto con diagramas,
acerca de qué servicios esperan los usuarios del sistema, y de las restricciones con las
cuales éste debe operar
 Los requerimientos del sistema 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 que se implementará..
 Los requerimientos funcionales son enunciados acerca de servicios que el sistema debe
proveer, de cómo debería reaccionar el sistema a entradas particulares y de cómo debería
comportarse el sistema en situaciones específicas. En algunos casos, los requerimientos
funcionales también explican lo que no debe hacer el sistema.
 Los requerimientos no funcionales son limitaciones sobre servicios o funciones que ofrece
el sistema.
 Los requerimientos del producto
• Especifican o restringen el comportamiento del software.
• Especifican o restringen el comportamiento del software. Los ejemplos incluyen
• Requerimientos de rendimiento sobre qué tan rápido se debe ejecutar el sistema.
• Requerimientos de cuánta memoria requiere el sistema.
• Requerimientos de fiabilidad que establecen la tasa aceptable de fallas.
• Requerimientos de seguridad
 Ejemplos de enunciados de requerimientos funcionales [41]"El sistema elaborará
diariamente, para cada clínica, una lista de pacientes que se espera que asistan a cita ese
día“ [42] "Cada miembro del personal que usa el sistema debe identificarse de manera
individual con su número de ocho dígitos “
 Los requerimientos pueden ser tan sencillos como un enunciado abstracto de alto nivel en
un servicio que debe proporcionar un sistema, o bien, una restricción sobre un sistema o
tan complejo como una definición detallada y formal de una función del sistema.
 Los requerimientos pueden ser tan sencillos como un enunciado abstracto de alto nivel en
un servicio que debe proporcionar un sistema, o bien, una restricción sobre un sistema o
tan complejo como una definición detallada y formal de una función del sistema.
 . Los requerimientos del usuario son enunciados en lenguaje natural junto con diagramas,
acerca de qué servicios esperan los usuarios del sistema, y de las restricciones con las
cuales éste debe operar.
 Los requerimientos del sistema 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 que se implementará.
 Requerimientos de externos incluyen, 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.
 Para construir diagramas de casos de uso cada caso de uso debe documentarse con una
descripción textual, cada clase de interacción se constituye como una elipse con etiqueta,
las líneas vinculan a los actores con la interacción (opcionalmente, se agregan puntas de
flecha a las líneas para mostrar cómo se inicia la interacción) y se Identifican las
interacciones individuales entre el sistema y sus usuarios u otros sistemas.
 Los requerimientos del usuario son enunciados en lenguaje natural junto con diagramas,
acerca de qué servicios esperan los usuarios del sistema, y de las restricciones con las
cuales éste debe operar
 . Los requerimientos del sistema 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 que se implementará..
 Los requerimientos funcionales son enunciados acerca de servicios que el sistema debe
proveer, de cómo debería reaccionar el sistema a entradas particulares y de cómo debería
comportarse el sistema en situaciones específicas. En algunos casos, los requerimientos
funcionales también explican lo que no debe hacer el sistema.

SQL
Structured Query Language
INSTRUCCIONES:
 SELECT es una instrucción sql que permite hacer consultas, es la instrucción inicial para
recuperar o hacer querys.
 ORDER BY es una instrucción sql que permite ordenar los resultados de una consulta
 WHERE permite filtrar los resultados de una consulta, es decir, permite poner condiciones.
 DISTINCT es una instrucción sql que permite que los resultados de una consulta sean
únicos, es decir, no se repitan.
 INSERT: es una instrucción sql que permite dar de alta un nuevo registro la instrucción que
sigue es INTO.
 UPDATE es una instrucción sql que permite editar ciertos campos de un registro dada una
condición
 DELETE es una instrucción sql que permite borrar un registro dada una condición.
 AND es una instrucción sql que obliga a que dos condiciones se cumplan.