ALTERNATIVAS DE

SOLUCIÓN
INTRODUCCIÓN
PROBLEMAS: Síntomas y causas
• Estudio para el 2015 en la industria de desarrollo de software
• Factores que determinan el éxito de los proyectos de software
• Detección de errores y costo desde los requisitos del software

• Síntomas y causas de los problemas en los requisitos del software

Informe 2015 Estado de la industria en el desarrollo de
software
2011, 22%
2012, 17%
Fallidos 2013, 19%
2014, 17%
2015, 19%

2011, 49%
2012, 56%
Desafiantes 2013, 50%
2014, 55%
2015, 52%

2011, 29%
2012, 27%
Exitosos 2013, 31%
2014, 28%
2015, 29%

0% 10% 20% 30% 40% 50% 60%

2011 2012 2013 2014 2015

Estudio realizado para 50000 proyectos - http://www.infoq.com/articles/standish-chaos-2015

 FACTORES PUNTOS INVERSIÓN DESCRIPCIÓN
Apoyo ejecutivo Estado de los15proyectos
15% Compromiso a finalizar con éxito el proyecto.

Factores de Fracaso
Participación de los usuarios 15 15%
Los usuarios toman parte activa en el desarrollo del
proyecto

Recurso humano especializado 10 10% El personal entiende el negocio y la tecnología

Inicia con la gestión del alcance basada en el valor del
Optimización 15 15%
negocio

Arquitectura estándar 8 8% Prácticas integradas, servicios y productos para el desarrollo

Es la diferencia entre los buenos resultados y los malos

Aptitud ágil 7 7%
resultados ágiles
Ejecución modesta 6 6% Utilización moderada de las herramientas y los procesos

Experiencia en gestión de proyectos 5 5% Utiliza su experiencia para agregar valor a la organización

Objetivos de negocio claros 4 4% Todos los interesados tienen claros el negocio

Suma de habilidades y debilidades que determinan la
Nivel madurez emocional 15 15% madurez emocional del equipo de trabajo
 Detección y costo de errores de
requisitos
El 60% de los
Se descubren aquí
errores surgen aquí

Requisitos Diseño Codificación Pruebas Despliegue

20 veces 100 veces

más más costoso
costoso en pruebas
ACTIVIDAD 1 - FORO

Ingrese a la página -
http://www.infoq.com/articles/standish-chaos-2015
realicen un análisis de cada uno de los gráficos
encontrados allí e ingrese a la plataforma para responder
el foro.
Síntomas y causas de problemas en requisitos
Síntomas
◦Requisitos faltantes
◦Requisitos incorrectos
◦Requisitos mal interpretados
◦Requisitos asumidos
◦Requisitos conflictivos
Síntomas y causas de problemas en requisitos
Causas principales
◦Conocimiento tácito
◦Hacer suposiciones
◦Experiencias y culturas diferentes
◦Preocupaciones diferentes
◦Conflictos emergentes entre interesados
◦Temor al cambio
TEMOR AL CAMBIO
S hock
A nger
R esistance
A cceptance
H ealing/Hope
ALTERNATIVAS DE
SOLUCIÓN
CON CE PTOS CL AV ES
SOLUCIÓN
Conjunto de cambios al estado actual de una
organización que son realizados con la finalidad de
habilitar a la organización para responder a una
necesidad de negocio.

Resolver un problema o aprovechar una oportunidad

de negocio.
 REQUISITO Vs REQUERIMIENTO
Requirement = Requisito
Request = Requerimiento

Requerimiento: acto judicial por el que se

intima que se haga o se de deje de ejecutar
algo (petición)
Requisito: circunstancia o condición
necesaria para algo (condición)
 INTERESADO / STAKEHOLDER
Persona u organización que tiene influencia (directa
o indirecta) sobre los requisitos de un sistema.
Proveedores
EXTERNOS Sociedad
Gobierno
Acreedores
Clientes
INTERNOS
Empleados
Gerentes
Accionistas
CONTEXTO DEL NEGOCIO
CONTEXTO DE LA SOLUCIÓN / ASPECTOS

Contexto de la
solución
ERROR, DEFECTO Y FALLO
FALLO (failure)
Desviación del componente o del sistema
respecto de prestación, servicio o
FALLO resultado esperado

DEFECTO DEFECTO (defect)

Imperfección en un componente o
sistema que puede causar que el
componente o sistema falle en
desempeñar las funciones requeridas

ERROR ERROR (mistake)

Una acción del ser humano que
produce un resultado
incorrecto
ROL DEL ANALISTA DE NEGOCIO

NEGOCIO EQUIPO TECNOLÓGICO

Usuario Ing. Requisitos Desarrollador Probador

Producto
Software
 ROL DEL ANALISTA DE NEGOCIO

NEGOCIO EQUIPO TECNOLÓGICO

Usuario Arquitecto de Desarrollador

Analista de solución
negocio

Solución técnica
Solución de de
negocio Software
Diferenciar los roles es fundamental
Analista Funcional
• Posee conocimientos desde la
perspectiva funcional de un
sistema.
• Son expertos en las mejores
prácticas de una empresa.
• Se convierten en dueños de una
plataforma limitando su visión
holística.
Analista de
requisitos
Se encarga de identificar todos
los requisitos necesarios para el
desarrollo de un producto de
software
Obtiene una visión de los
requisitos del negocio limitada
Se centra en los deseos de los
interesados
Están altamente enfocados en el
producto
Analista del negocio
• Tiene conocimiento holístico de la
organización
• Conocer los objetivos, metas,
problemas, y por lo tanto propone
soluciones
• Sabe interpretar las necesidades
de los stakeholders frente a lo que
requiere el negocio
• Entiende como debe colaborar con
el equipo Tecnológico
 ACTIVIDAD 2 – CRUCIGRAMA Y TALLER
PROYECTO
1. Realice el taller de conceptos propuesto por el
instructor.
2. Realice los puntos 1 y 2 del taller de formulación de
proyectos.
ELICITACIÓN
PROCESO DE ELICITACIÓN
TÉCNICAS DE ELICITACIÓN
Modelo de ingeniería de requisitos (BA)
Proceso
PLANIFICACIÓN Y SEGUIMIENTO

Solución Gestión

Análisis de
Análisis
documentación de
empresarial Gestión de
Elicitación requisitos
requisitos
Validación y
verificación
Actividades de la elicitación
Antes Durante Después

Realizar las
Estudiar a Organizar y
Planear el Preparar actividades Clasificar la
los compartir
alcance y las recurso de información
interesados notas
sesiones elicitación
MODELO KANO
Insatisfacciones básicas
Propiedades evidentes del
sistema y se dan por sentadas
por los interesados
(conocimiento subconsciente)
Satisfactores (desempeño)
propiedades explícitas del
sistema exigidas por los
interesados
(conocimiento consciente)

Deleite (Entusiasmo)
Indiferente
Propiedades no conscientes o
esperadas y se descubren
mientras utilizan el sistema
(conocimiento inconsciente) Propiedades no necesarias del
sistema
EVALUACIÓN DEL MODELO KANO
Se formulan preguntas de dos modos
◦ ¿Cómo te sientes si el sistema incluye estas características? (modo funcional)
◦ ¿Cómo te sientes si el sistema no incluye esta característica? (modo
disfuncional)
DELEITE
Posibles respuestas
◦ Satisfecho INDIFERENTE
◦ Debe ser necesaria CUESTIONABLE
◦ Neutral (indiferente)
◦ No me importa BÁSICA
◦ Insatisfecho INVERSA
 EVALUACIÓN MODELO KANO
Si no incluye esto
Matricular curso online
Validar los prerrequisitos para matricular el

Prescindible

Insatisfecho
Indiferente
Satisfecho

Necesaria
curso
Ver el estado de matriculas en cada curso

Satisfecho R ! Obtener el listado de estudiantes del curso

? !
Si incluye esto

Necesaria R Asignar profesores al curso

Indiferente R R !
Ver información histórica de matriculas
Prescindible R R R !
Insatisfecho R R R R ? Asignación manual de estudiantes a un curso
Aspectos a considerar antes de la
elicitación
Planear alcance y agenda
Programar recursos
◦ Físicos
◦ Humanos
Estudiar a los interesados
◦ Conocer sus hábitos
◦ Proporcionar documentación de apoyo
Preparar cada sesión de elicitación
◦ Preguntas abiertas
◦ Preguntas cerradas
 Fuentes
• Usuarios del sistema Arquitectos
Interesados • Operadores del sistema Clientes
• Desarrolladores Probadores

• Estándares de industria
• Documentos universales Documentos legales
Documentos •
• Documentos específicos Documentos de requisitos
• Reportes de error

Sistemas • Sistemas heredados

en
operación • Sistemas de la competencia
Aspectos a considerar antes de la
elicitación
Educar e involucrar a los interesados
Tomar buenas notas
◦ Grabaciones
◦ Uso de tableros y post it
◦ Fotografías
Aprovechar el espacio físico
Sondear excepciones
◦ ¿Qué podría…?
◦ ¿Qué pasa cuando …?
◦ ¿Alguna vez necesitará …?
◦ ¿De dónde saca …?
Técnicas de obtención de requisitos
1 Técnicas de interrogatorio

2 Técnicas de creatividad

3 Técnicas centradas en documentación

4 Técnicas de observación

5 Técnicas de apoyo
Modelo de ingeniería de requisitos
(Business Analysis, BA)
Requisitos Reglas, políticas y
del negocio estándares

Cómo va a funcionar,
Requisitos de especificación de
usuario
los interesados

Requisitos de la Especificación de
requisitos
solución
Esquema de la clasificación de los requisitos

Requisitos de Reglas de
negocio negocio
Requisitos de negocio
Visión de alcance

Requisitos de
los
interesados
Requisitos de los interesados
Especificación de
usuarios Interfaces
Requisitos externas
Requisitos
no
funcionales
funcionales
Restricciones
Especificación de requisitos
de software Requisitos de la solución
Clasificación de la información obtenida
Interfaces Requisitos del proyecto
externas
Requisitos
no Restriccione
funcionale
s
s
Restricciones del proyecto

Requisitos
funcional
Requisitos Suposiciones
de datos
es

Dependencias
Reglas
Ideas de
de
negocio
solución Información adicional
Requisitos
interesado
s
Requisitos
de negocio Información que no agrega valor
Requisitos del negocio
Pueden ser los objetivos, metas, o necesidades de la organización
Definen las razones del por qué de un proyecto
Representa los beneficios para la organización como un todo
No necesariamente están asociados al software
Son desarrollados y definidos a través del Análisis empresarial (BA)
Ejemplos
Aumentar la cuota de mercado en la región X en Y porcentaje dentro de Z meses
Ahorrar X cantidad de dinero por año en electricidad desperdiciada por las
unidades ineficientes
Lograr X% de retorno sobre la inversión dentro de Y meses
Desarrollar ventajas competitivas en X producto/servicio
Reglas de negocio
Política corporativa, estándar de industria, normas, regulación gubernamental
que define o limita algún aspecto del negocio
No es un requisito del software en si mismo, pero es el origen de varios tipos
de requisitos.

Ejemplos:
Todas las quejas realizadas por los clientes deben responderse dentro de las
siguientes 24 horas después de radicada la queja.
En la historia clínica solo se debe permitir adicionar registros, pero nunca
modificar ni borrar atenciones previas. (Ley 100 1993)
El IMC se calcula de la siguiente forma peso/mas.
Requisitos de los interesados
Es una meta o una tarea que los tipos de interesados específicos deben ser
capaces de realizar con el sistema.

Incluye descripciones de los atributos o características del producto que son

importantes para la satisfacción del usuario.

Cuando un usuario dice “NECESITO” “QUIERO” “DESEO” probablemente esté

describiendo un requisito de interesado
Ejemplos
Quiero ingresar las evaluaciones de los estudiantes directamente en el sistema

Deseo obtener estadísticas de resultados por periodos y áreas

Necesito consultar el estado de las cuentas de mis clientes desde Internet

Como superior, necesito informar al encargado cuando se ha completado el

proceso de descargo de facturas.
Requisitos funcionales
Especifican el comportamiento observable que un sistema ofrece o exhibe bajo
ciertas condiciones.

Describe lo que los desarrolladores deben implementar para que los usuarios
puedan realizar sus tareas.

Especifican el qué debe hacer el sistema.

Ejemplo
Si el perfil de un pasajero no indica una preferencia de asientos, el sistema de
reserva deberá asignar un asiento que no esté en estado ocupado, al pasajero.

El sistema deberá permitir consultar a un profesor una evaluación de un curso

específico al cuál pertenece

El sistema deberá permitir imprimir al pasajero una tarjeta de embarque para
el segmento de vuelo al que se haya presentado.
Requisitos NO funcionales
Describe un servicio o capacidad del sistema que involucra atributos de calidad ISO 9126 -
FURPS+

Influye la arquitectura más que los requisitos funcionales

Describen que tan bien el sistema hace algo.

Deben ser precisos, medibles y finitos.

Ejemplos
El sistema tendrá una disponibilidad el 97,7% considerando solo un día al año
para mantenimiento y reparación.

Si un cliente realiza una consulta en un momento pico de operación, la

respuesta a la consulta es dada en un tiempo no mayor a 4 segundos.

Un cliente debe poder realizar el proceso de cheking en un tiempo no superior

a 1 minuto sin que el sistema presente más de 4 ventanas distintas.
Restricciones
Son limitaciones impuestas a las opciones disponibles para el desarrollador , ya
sea para el diseño o para la construcción del producto.

Son de obligatorio cumplimiento.

Tipos: Técnicas y del proyecto.

Ejemplo
Técnicas:

Los archivos enviados electrónicamente no pueden superar los 10mb de

tamaño

Las contraseñas deben ser encriptadas por medio del algoritmo hash MDS.

Deben ser programados en PHP conectado a una base de datos MySQL.

Ejemplos
Del proyecto:

El presupuesto del proyecto no puede exceder $150000000.

El proyecto debe finalizar antes del 31 de diciembre.

Una vez implantado y finalizado el proyecto se debe capacitar a los usuarios

de acuerdo con su rol.
Interfaces Externas
Conexiones entre el sistema y un usuario a otro sistema o dispositivo de
hardware.

Ejemplo:
El sistema debe consultar en el CRM de la organización la información de los
clientes

El sistema debe informar al ERP cuando se ha realizado un nuevo pago.

Requisitos de datos
Es cuando se describe el formato, tipo de datos, los valores permitidos o el
valor por defecto para un elemento de datos.

La composición de una escritura compleja de datos de negocio, o un reporte

que se genere.

El id de un cliente que va desde 0 hasta 19,999,999 es para identificar el sexo

femenino, para masculino va desde 20,000,000 hasta 79,999,999.
Requisitos de datos

Una orden esta compuesta por la identidad del cliente, la información de envío,
uno o más productos, cada uno de los cuales incluye el id del producto, número
de unidad , precio unitario y total … incluye y descrina el IVA de acuerdo con el
tipo de IVA
Ideas de solución
Ideas preconcebidas de cómo implementar o solucionar el problema.
Se debe sondear para llegar a los verdaderos requisitos.
Poner la cédula en un campo de texto que no se pueda modificar.
El sistema debe registrar en un archivo cada una de las transacciones que
realiza el cliente.
Los clientes deben ingresar al sistema por medio de un usuario y una
contraseña.
Identificar la razones legítimas de una idea de solución ya que no son
necesariamente malas o incorrectas.
¿Cuándo se ha terminado la elicitación?
Los interesados no pueden pensar más casos de uso o historias de usuario.
Los interesados proponen nuevos escenario pero no conducen a nuevos
requisitos.
Los interesados repiten problemas ya tratados.
Las sugerencias son consideradas fuera de alcance.
Los requisitos propuestos son cosméticos o de baja prioridad.
Los requisitos propuestos son futuros.
ACTIVIDAD 3 - Proyecto

1. Realice los puntos 3 y 4 del taller de formulación de

proyectos.
CARACTERÍSTICAS DE
LOS REQUISITOS
ESTÁNDAR ISO 9126 EVOLUCIÓN A ISO 25010
CARACTERÍSTICAS REQUISITOS FUNCIONALES Y NO FUNCIONALES
Estándar ISO 9126 evolución a ISO 25010
CALIDAD DE SOFTWARE

NO
FUNCIONAL
FUNCIONAL

Tomado de http://iso25000.com/index.php/normas-iso-25000/iso-25010
Funcionalidad
Características que describen las capacidades
requeridas de un sistema (debe/puede hacer)

Capacidad del software de

proporcional el resultado o efecto
correcto acordado con el grado de
exactitud Exactitud Capacidad del software de
(precisión) prevenir accesos no autorizados
o debilidades al programa o a los
• Compatibilidad datos. Confiabilidad, integridad,
• Coexistencia autenticidad y responsabilidad
Interoperabilidad Seguridad

• Completitud funcional Capacidad del software de

• Corrección funcional cumplir con normas, estándares
• Pertinencia funcional FUNCIONAL y normatividad legal
Adecuación Cumplimiento
(idoneidad)
 • Rendimiento
• Uso de recursos
Eficiencia
• Estabilidad
• Compresibilidad (entendido) • Pruebas
• Atractivo • Anabilizabilidad
• Facilidad de aprendizaje • Modificabilidad
• Operabilidad Usabilidad Mantenibilidad

• Madurez NO
• Adaptabilidad
• Tolerancia a fallas FUNCIONAL • Coexistencia
• Recuperabilidad • Instalabilidad
Fiabilidad • Reemplazabilidad
Portabilidad
FIABILIDAD
Habilidad de un producto software para llevar a cabo aquellas funciones
requeridas en condiciones establecidas para un periodo de tiempo, o número
de operaciones.

Madurez Tolerancia a fallos Recuperabilidad

Capacidad de restablecer un
Capacidad para mantener un
Capacidad de evitar fallos nivel específico de
nivel específico de
como resultado de defectos rendimiento y recuperar la
rendimiento en caso de
en el software información directamente
producirse fallas
afectada en caso de fallo
 USABILIDAD
Capacidad del software para ser comprendido, aprendido, utilizado y atractivo
al usuario cuando es utilizado bajo condiciones específicas

Compresibilidad Atractivo Facilidad de aprendizaje Operabilidad

Capacidad para facilitar al

Capacidad del producto Capacidad del producto
usuario apreciar si el Capacidad del producto
software de permitir al software para permitir al
software es adecuado y cómo software de ser atractivo al
usuario aprender su forma de usuario manejarlo y
puede ser utilizado para usuario
uso controlarlo
tareas específicas
EFICIENCIA
Capacidad del producto software para proporcionar un rendimiento apropiado
relativo a la cantidad de recursos usados bajo condiciones establecidas

Rendimiento Uso de los recursos

Grado en el cual un sistema o
componente logra la función
Capacidad de un producto
señalados dentro de las
software para hacer uso de
restricciones dadas con
cantidades y tipos de
respecto al tiempo de
recursos apropiados
proceso y tasa de
transferencia
 MANTENIBILIDAD
Facilidad con la que un producto software puede ser modificado para corregir
defectos, cumplir con nuevos requisitos, hacer más sencillo el mantenimiento
futuro o ser adaptado a un entorno modificado

Estabilidad Testability Anabilizabilidad Modificabilidad

Capacidad de un producto
Capacidad del producto Capacidad del producto Capacidad del producto
software de ser
software de permitir al software que hace posible software de hacer posible la
diagnosticado por
usuario aprender su forma de que el software modificado implementación de
deficiencias o causas de
uso sea probado modificaciones especificadas
fallos en el software
 PORTABILIDAD
Facilidad de un producto software para ser transferido de un entorno hardware
o software a otro.
Adaptabilidad
Capacidad de un producto
software para se adaptado a
diferentes entornos sin la
aplicación de acciones
distintas a las adaptadas para
este propósito
Coexistencia Instabilidad Reemplazabilidad
Capacidad del producto
Capacidad de coexistir con software para sr usado en
Capacidad del producto
otro software en un entorno lugar de otro software
software para ser instalado
común compartiendo especificado, con el mismo
en un entorno específico
recursos comunes propósito en el mismo
entorno
ACTIVIDAD 4

1. Ingrese a la plataforma Bb y realice la actividad de

correspondencia que se encuentra activa.