• Author / Uploaded
• Charlixitho Polonio Ordoñes

Citation preview

¿Existe una guía sobre el cuerpo de conocimientos? Un cuerpo de conocimientos (BOK, del inglés Body of Knowledge), es un compendio de términos, usos y definiciones acerca de un tema, es creado por la asociación profesional que valida el tema del que se trata; muchos de estos cuerpos, se han llegado a convertir en estándares y normas de calidad, y de la misma manera, se han creado normas a partir de ellos.

Algunos de los cuerpos de conocimiento más famosos en las TI son:

 BABOK (Business Analysis Body of Knowledge).Guía sobre los fundamentos del conocimiento del análisis de negocio.  PSPBOK (Personal Software Process Body of Knowledge).Guía para la gestión de tiempo y productividad personal.  TSPBOK (Team Software Body of Knowledge).Guía de gestión de equipos para organizar y generar software de gran escala.  PMBOK (Project Management Body of Knowledge). Guía de dirección de proyectos. INGENIERÍA DEL SOFTWARE 6  SWEBOK (Software Engineering Body of Knowledge).Guía acerca del conocimiento necesario de un ingeniero de software

Áreas principales Para SWEBOK V3.0 el conocimiento se ha agrupado en áreas, que son:          

Requisitos Diseño Desarrollo Pruebas Mantenimiento Gestión de configuración Gestión de Software Proceso de ingeniería Herramientas y métodos de ingeniería Calidad de software

Requisitos: Interpreta las necesidades del cliente en una lista de objetivos a cumplir, cada uno se puede trasformar en un subsistema o sólo en una funcionalidad, si los requisitos no son interpretados correctamente, el sistema sufrirá consecuencias graves en el desarrollo y mantenimiento

Diseño: Define la arquitectura, interfaces, diagramas de flujo, entre otros del sistema; en esta etapa se analizan los requerimientos y se crean posibles soluciones gráficas a cada uno.

Desarrollo: Interpreta la arquitectura, esquemas y diagramas de flujo definidos en la etapa de diseño en codificación de un lenguaje de programación, interactuando también con el sistema operativo y algunas veces con los dispositivos de entrada y salida.

Pruebas: Evalúa la eficiencia y calidad del producto detectando las posibles mejoras o fallas.

Mantenimiento: Corrige las fallas y realiza las mejoras detectadas anteriormente.

Gestión de configuración: Identifica la configuración general del sistema para realizar posibles adaptaciones y configurar su ciclo de vida, detecta las características físicas y funcionales del sistema además del cumplimiento de sus objetivos.

Gestión de ingeniería: Verifica la infraestructura del proyecto, el control y la planeación del programa, asegura que el mantenimiento del producto sea adecuado.

Gestión del proceso: Valida todas las etapas del proceso, como las tareas que componen el proceso, funciones, mediciones, configuración, mantenimiento, entre otros.

Herramientas y proceso de ingeniería: son todos los recursos virtuales que nos ayudan a realizar tareas exhaustivas como, validar el producto, crear el diseño, realizar pruebas, detectar fallas, entre otros; pero es importante saber que estas herramientas sólo interpretan el resultado de la información que brindamos, si la información es errónea, el resultado puede llevarnos a una mala decisión.

Calidad de software: El conjunto de las actividades vistas anteriormente tiene como objetivo crear un producto de calidad, el cual pueda brindar al cliente la solución a los procesos que realiza o a la problemática que tiene, siendo eficaz, costeable, moldeable, y que pueda

tener futuras implementación, éstas son algunas características de software de calidad.

¿Qué necesitamos para poner un ejemplo de requisitos? Una necesidad /problema. Al igual que ponemos los caballos delante del carro, pongamos primero un problema y, después, una solución REQUISITOS FUNCIONALES Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La compleción significa que todos los servicios solicitados por el usuario están definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias. REQUISITOS NO FUNCIONALES Se trata de requisitos que no se refieren directamente a las funciones específicas suministradas por el sistema (características de usuario), sino a las propiedades del sistema: rendimiento, seguridad, disponibilidad. En palabras más sencillas, no hablan de “lo que” hace el sistema, sino de “cómo” lo hace. Establecen restricciones de cómo estos requisitos funcionales son implementados. Alternativamente, definen restricciones del sistema tales como la capacidad de los dispositivos de entrada/salida y la representación de los datos utilizados en la interfaz del sistema. Los requisitos no funcionales se originan en la necesidad del usuario, debido a restricciones presupuestarias, políticas organizacionales, la necesidad de interoperabilidad con otros sistemas de software o hardware, o factores externos tales como regulaciones de seguridad, políticas de privacidad, entre otros.

¿Qué son Stakeholders? Stakeholder es una palabra del inglés que, en el ámbito empresarial, significa 'interesado' o 'parte interesada', y que se refiere a todas aquellas personas u organizaciones afectadas por las actividades y las decisiones de una empresa.

OTROS TIPOS DE REQUISITOS 1. Requisitos inversos Lo que la aplicación no debe hacer (son infinitos...)  

Pueden aclarar posibles malentendidos, el alcance del sistema. Seleccionar aquellos que sirven para aclarar los verdaderos requisitos.

2. Rendimiento  

Especifican restricciones temporales que la aplicación debe cumplir. Son críticas en los sistemas de tiempo real.

3. Fiabilidad y disponibilidad En estos dos factores se reconoce que las aplicaciones difícilmente son perfectas, pero sí se exige un nivel de calidad mínimo.



Fiabilidad: Cuantifica los errores permisibles y su gravedad



Disponibilidad: Cuantifica el grado de disponibilidad de la aplicación para los usuarios.

4. Manejo de errores Cómo debe responder la aplicación a errores de su entorno o errores internos. No se debe abusar del manejo de errores internos, que no deben existir (no debemos cubrir nuestros errores con un código interminable de manejo de errores)

5. Requisitos de Interfaz Describen el formato con el que la aplicación se comunica con su entorno. Ejemplo:

Hardware: El coste del envío se mostrará en la esquina inferior derecha.

Software: No existe posibilidad de adquirir licencias de software. La aplicación deberá funcionar sobre Oracle.

6. Seguridad Security: seguridad del sistema frente a amenazas externas (confidencialidad, integridad, disponibilidad, etc.) Safety: seguridad de las personas frente a fallos del sistema

PROBLEMAS HABITUALES 

La existencia de un requerimiento ha de estar debidamente justificada (debemos saber por qué es un requisito del sistema).



Un requerimiento es, a veces, difícil de verificar (especialmente, si es un requisito no funcional). Además, si somos incapaces de especificarlo, ¿cómo sabemos que realmente es un requisito?

REQUERIMIENTOS O REQUISITOS? Requirements Engineering = Ingeniería de Requisito Request Engineering = Ingeniería de Requerimiento

¿Qué es un Requerimiento? Es una definición abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste Son objetivos que se buscan para el software tenga la funcionalidad que necesita el cliente/ usuario y mostrarle lo que puede y no puede hacer.

¿Qué es un Requisito? Son declaraciones que identifican atributos, capacidades, características y/o cualidades que necesita cumplir un sistema para que tenga valor y utilidad para el usuario.

LA EXPERIENCIA EMPIRICA DEMUESTRA… •

Los requisitos contienen demasiados errores.

•

Muchos de estos errores no se detectan al principio.

•

Muchos de estos errores podrían ser detectados al principio.

•

No detectar estos errores incrementará los costes (tiempo, dinero) de forma exponencial.

•

Además, los programadores obedecen los requisitos (cuando existen).

¿QUE ES INGENIERÍA DE REQUISITOS? Los requisitos expresan lo que el sistema debe hacer para satisfacer las necesidades de sus clientes o usuarios. IMPORTANCIA DE LOS REQUISITOS •

Identificación de requisitos

etapa clave

•

Problemas: Inconsistencia, ambigüedad, cliente no sabe de lo que quiere, etc.

Requisitos de Usuario / de Sistema Requisitos de Usuario: Son aquellos que están dirigidos a los usuarios y clientes del sistema (interesados en general). Se redactan usando lenguaje natural (generalmente) de forma “no técnica” con el objetivo de que el personal no técnico los pueda entender

Requisitos de Sistema: Son aquellos dirigidos a personal técnico: analistas, programadores, arquitectos, ingenieros, etcétera. Generalmente están escritos en un lenguaje mucho más técnico pero mucho más preciso que los requerimientos de usuario

1. Características  

Los requisitos deben ser lo más claros y no ambiguos que se pueda, y cuantificables (si es posible). Los requisitos son una etapa clave en el ciclo de vida

2. Dificultades  Posibles Problemas con los Requisitos: o

No reflejan las necesidades reales del cliente

o

Son inconsistentes y/o incompletos

o

Es costoso realizar cambios sobre los requisitos una vez que han sido acordados

o

Puede haber malentendidos entre clientes, analistas, ingenieros software.

Procesos de la Ingeniería de Requisitos 

Captura: Es la actividad por medio de la cual se obtienen (capturan) los requerimientos Entrevistas, modelo de negocios, prototipos, Observación directa, etc.



Análisis: Es la actividad por medio de la cual se extiende el modelo de requisitos, se buscan y localizan errores, inconsistencias, limitaciones, carencias, etcétera. Inspecciones de entrevistas, etc.



documentos,

desarrollo

de

prototipos,

discusiones,

Especificación: Es la actividad por medio de la cual se documentan (escriben / se ponen en “blanco y negro”) los requerimientos. Documento de Especificación de Requerimientos Documento de Definición de Requisitos requerimientos



Validación:

Criterios para establecer una Requisito        

Necesario: Si el sistema puede satisfacer las necesidades reales priorizadas sin el requisito, no es necesario. Viable: El requisito es factible y puede llevarse a cabo dentro del presupuesto y el calendario. Correcto: Los hechos relacionados con el requisito son exactos, y es técnica y legalmente posible. Concisa: El requisito está previsto simplemente. Inequívoca: El requisito se puede interpretar de una sola manera. Completa: Todas las condiciones en las que se aplica el requisito se expresan, y que expresa una idea completa o declaración. Consistente: No está en conflicto con otros requisitos. Verificable: Aplicación del requisito en el sistema puede ser probado

La regla en la industria es que “el consultor debe ser lo suficientemente hábil como para detectar la problemática organizacional con la profundidad requerida con una simple ojeada”.

CALIDAD Alcance, Tiempo, Costos.

El Project Charter Es un Documento de alto nivel que autoriza formalmente el inicio o fase de un proyecto, documenta los Requisitos iniciales que satisface a los deseos, necesidades y expectativas de los interesados.

Ciclo de vida del desarrollo Software Es una secuencia estructurada y bien definida de las etapas en Ingeniería de software para desarrollar el producto sofware deseado. 1. Comunicación 2. Requisitos del sistema 3. Estudio de Factibilidad 4. Análisis del sistema 5. Diseño de software 6. Códigos 7. Pruebas 8. Integración 9. Implementación 10. Operaciones y mantenimiento 11. Disposición

Inicio --- planificación ----- ejecución/ control ----- cierre Paradigma de desarrollo de Software El Paradigma de desarrollo de Software ayuda al desarrollador a escoger una estrategia para desarrollar el software. El paradigma de desarrollo software tiene su propio set de herramientas, métodos y procedimientos, los cuales son expresados de forma clara, y define el ciclo de vida del desarrollo del software



Modelo Cascada: Es el modelo de paradigma más simple en desarrollo de software. Sigue un modelo en que las fases del SDLC funcionarán una detrás de la otra de forma lineal. Lo que significa que solamente cuando la primera fase se termina se puede empezar con la segunda, y así progresivamente.



Modelo Repetitivo: Este modelo guía el proceso de desarrollo de software en repeticiones. Proyecta el proceso de desarrollo de forma cíclica repitiendo cada paso después de cada ciclo en el proceso de SDLC. Es más fácil gestionar el proceso de desarrollo, pero a la vez se consumen más recursos.



Modelo en espiral: El modelo en espiral es una combinación de ambos modelos, el repetitivo y uno del modelo SDLC. El modelo empieza determinando los objetivos y las limitaciones del software al inicio de cada repetición. En la siguiente etapa se crean los modelos de prototipo del software. Esto incluye el análisis de riesgos.



Modelo V: El mayor inconveniente del modelo de cascada es que solo se pasa a la siguiente fase cuando se completa la anterior, por tanto, no es posible volver atrás si se encuentra algún error en las etapas posteriores. El Modelo V aporta opciones de evaluación del software en cada etapa de manera inversa. Esto hace que tanto la verificación como la validación vayan en paralelo. Este modelo también se conoce como modelo de validación y verificación.



Modelo big bang: Requiere poca planificación, mucha programación y también muchos fondos. Este modelo se conceptualiza alrededor de la teoría de creación del universo 'Big Bang'. Requiere poca planificación. No sigue ningún proceso concreto, y a veces el cliente no está seguro de las futuras necesidades y requisitos. Este modelo no es recomendable para grandes proyectos de software, pero es bueno para aprender y experimentar.



Modelo de ensamblaje: Es evolutivo y exige un enfoque interactivo para la creación del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software (clases).



Modelo de prototipos: permite que todo el sistema, o algunas de sus partes, se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos.



Modelo de desarrollo rápido de aplicaciones: Es un modelo del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto.



Modelo de métodos formales: Es una especificación expresada en un vocabulario, sintaxis y semántica están formalmente definidos.



Modelo de desarrollo concurrente: Se utiliza a menudo paradigma de desarrollo de aplicaciones cliente/ servidor.

como el

HISTORIA DE USUARIOS “COMO, QUIERO, PARA” Es una descripción rápida y sencilla de una forma en la que un usuario utilizará el software. La mayoría de historias de usuario se deben escribir entre una y cuatro frases. Deben caber en una tarjeta de 3x5 pulgadas Es importante conocer qué condiciones se deben cumplir para considerar una historia terminada. Es lo que se denominan condiciones de satisfacción, también denominadas criterios de aceptación o definición de Hecho 

INVEST El método sirve para comprobar la calidad de una historia de usuario revisando que cumpla una serie de características:



I - Independent (independiente) Es ventajoso que cada historia de usuario pueda ser planificada e implementada en cualquier orden. Para ello las historias deberían de ser totalmente independientes (lo cual facilita el trabajo posterior del equipo).



N - Negotiable (negociable) Una historia de usuario es una descripción corta de una necesidad que no incluye detalles. Las historias deben ser negociables ya que sus detalles serán acordados con el cliente o el usuario durante la fase de conversación.



V Valuable (valiosa) Una historia de usuario tiene que ser valiosa para el cliente o el usuario. Una manera de hacer una historia valiosa es que la escriba el mismo.



E - Estimable (estimable) Una buena historia de usuario debe de poder ser estimada con la precisión suficiente para ayudar al cliente, usuario o propietario del producto a priorizar y planificar su implementación.



S - Small (pequeña)

Las historias de usuario deberían englobar como mucho unas pocas semanas/persona de trabajo. Incluso hay equipos que las restringen a días/persona. Una descripción corta ayuda a disminuir el tamaño de una historia de usuario facilitando así su estimación.



T - Testable (comprobable) La historia de usuario debería ser capaz de ser probada (fase confirmación de la historia de usuario). Si el cliente o usuario no sabe cómo probar la historia de usuario significa que no es del todo clara o que no es valiosa. Si el equipo no puede probar una historia de usuario nunca sabrá si la ha terminado o no.

Los 3 C’s de las Historias de Usuario CARACTERÍSTICAS DE LAS HISTORIAS DE USUARIO:



Tarjeta

Card

También conocidos como ficha o en inglés Index Cards (como en la imagen arriba). El propósito de la tarjeta es limitar el espacio para la información que describe un requisito particular. ¿POR QUÉ LIMITAR EL ESPACIO? Atiende al propósito de recordar a los miembros del equipo del que se trata el requisito y algún medio de identificar la misma. Normalmente, la historia tiene un título de fácil asociación y un identificador único que sirve de fácil indexación para búsquedas y agrupación de historias de usuario a través de temas, épicos, sprints, trimestres y etc ¿QUÉ INFORMACIÓN DE LA TARJETA DEBE CONTENER? Inicialmente, este requisito debe dejar claro su objetivo de negocio que abastece a un determinado agente / cliente / usuario para lograr un cierto beneficio 



Conversación

Conversation

¿QUIÉN HABLA? El requisito idealmente debería ser comunicado de un cliente o usuario para el equipo o para las personas que van a desarrollar la misma. Esta conversación debería expresar los pensamientos, opiniones y sentimientos



Confirmación

Confirmation

Independiente de la cantidad de tiempo que el equipo invierta en madurar y clarificar un requisito o funcionalidad de un sistema, lo que se ha observado es que no sabemos cómo funcionará la funcionalidad cuando esté lista.

En el Paso Confirmación, pueden producirse varias actividades. Al desarrollador lee un determinado requisito y evaluando el sistema, pueden surgir dudas que deben ser dirigidas por alguien especialista en negocios (en inglés SME - Subject Matter Expert) o por un Product Owner / Product Manager, dependiendo del ambiente y de las metodologías utilizadas para desarrollar el software.

Nombre de la historia de usuario Como un  Quiero  Tal que  [Cada historia de usuario tiene una razón de ser, un valor que justifica su existencia y, si bien eso puede deducirse de la parte "Tal que", muchas veces se requiere contexto extra y eso debe agregarse aquí.]

Criterio de aceptación    

El sistema debe validar que los rangos de fechas sean válidos. El sistema no muestra en ningún caso registros de tipo X. El sistema muestra la pantalla en menos de 10 segundos. El sistema registra log de reportes con datos: fecha (localtime, usuario_id, ..)

[El criterio de aceptación es una herramienta de entendimiento, negociación y testing por lo que es importante no dejar criterios importantes fuera. Los requerimientos no funcionales tales como performance, seguridad, manejo de errores van aquí.]

Criterio de finalización [Checklist que indica los quality gates por los que debe pasar la feature]



El cliente ha revisado y aprobado la historia de usuario luego de la etapa de entendimiento.

   

El cliente ha visto y aceptado los mocks de las pantallas. El código se ha revisado en su totalidad durante los sucesivos commits. El análisis estático de código no encuentra errores de criticidad grave (definir). Los unit test pasan todos en verde.



El analista funcional (internal product owner, TL o focal point) ha aprobado la funcionalidad.



Se ha creado al menos un test automático para esta funcionalidad y el mismo pasa verde (cuando aplique).



El servidor de integración continua no reporta error alguno.

Referencia   

Mockups Documentación Referencias cruzadas.

Técnicas de educción de requisitos 



Es un proceso para encontrar los requisitos para un sistema de software que se intenta desarrollar, usando la comunicación con el cliente, los consumidores finales, usuarios del sistema y otros que tienen algún papel en el desarrollo del sistema de software. Es el ejercicio de deducir, inferir y extraer información sobre las necesidades y de SEOs que los usuarios esperan suplir con el producto de software esperado.

Entrevistas Las entrevistas son medios de recogida de requisitos medianamente fuertes. La organización puede conducir muchos tipos de entrevistas, tales como: Entrevistas estructuradas (cerradas), donde cada información que se recoge es decidida con antelación, siguen patrones y temas de debate de forma firme. Las entrevistas no estructuradas (abiertas), donde la información que se busca no se decide con antelación, es más flexible y menos tendenciosa.   

Entrevistas orales Entrevistas por escrito Entrevistas cara a cara entre 2 personas

Encuestas La organización puede conducir encuestas o sondeos entre varios accionistas pidiendo sus expectativas y requisitos para el sistema que se va a desarrollar.

Cuestionarios

Un documento con preguntas objetivas definidas previamente con sus opciones respectivas. Se entrega a todos los accionistas para que las respondan, se recogen y se recopilan. Una limitación de esta técnica es que, si una opción por algún asunto no se menciona en el cuestionario, el asunto puede quedar desatendido.

Tabla de evaluación Método para puntuar nuestras observaciones basado en ciertos criterios que permiten recolectar información y poder entender escenario del sistema a desarrollar.   

Buenas practicas Problemas Soluciones.

Análisis de tareas El equipo de ingenieros y de desarrolladores puede analizar la operación por la cual se requiere el nuevo sistema.

Análisis de dominio Cada software pertenece a una categorización del dominio. Los expertos en dominio pueden ser de gran ayuda para analizar requisitos generales y específicos.

Lluvia de ideas – brainstorming Un debate informal se lleva a cabo entre varios accionistas y todos los inputs o entradas se graban para el análisis de requisitos posterior. Algunas de las ventajas que ofrece la aplicación de esta herramienta son:    

La obtención de una amplia gama de ideas en un menor tiempo. El estímulo de la creatividad de los miembros del equipo de trabajo. La eliminación de bloqueos por parte del equipo frente a un contenido determinado. La obtención de diversas soluciones posibles sobre un mismo problema.

Modelo de prototipos Se basa en construir interfaces de usuario sin añadir detalles de las funcionalidades para que el usuario interprete las características del producto software que se quiere desarrollar. Ayuda aportando una mejor idea de los requisitos. Si el consumidor final no tiene el software instalado para que el desarrollador lo tome como referencia y el cliente no sabe cuáles son sus propios requisitos, el desarrollador crea un prototipo basado en los requisitos mencionados al inicio.

Observación El equipo de expertos visita la organización o el lugar de trabajo de los clientes. Observan el funcionamiento de los sistemas instalados ya existentes. También observan el flujo de trabajo y cómo se tratan los problemas de ejecución.

Benchmarking

Características de los requisitos del Software La recogida de requisitos de software es la fundación de la totalidad del proyecto de desarrollo software. Por ello, debe de ser clara, correcta y bien definida.            

Una completa especificación de requisitos Software debe ser: Clara Correcta Consistente Coherente Comprensible Modificable Verificable Priorizada sin ambigüedades Trazable Origen creíble