lunes, 29 de octubre de 2012

INGENIERÍA DE SOFTWARE: CASO DE USO


¿Caso de Uso?

Un caso de uso es un conjunto de escenarios que 
tienen una meta de usuario en común.
Además también suele ser una descripción de un proceso fina-fin, relativamente largo, que incluye varias etapas o transacciones.
siendo una manera específica de utilizar el sistema, es 
una historia que describe un uso particular del sistema.
Es la imagen de una funcionalidad del sistema, 
desencadenada en respuesta al estímulo de un 
actor o rol externo.

¿Escenario?

Es una secuencia de acciones e interacciones (pasos) entre los usuarios (actores) y el sistema... por ejemplo: 
“El usuario introduce su nombre de usuario y su contraseña. 
El sistema verifica la validez del nombre de usuario y de la contraseña y permite al usuario el acceso al sistema. El sistema muestra la pantalla principal del sistema. El usuario selecciona la opción de añadir nuevo empleado. El sistema muestra...”

¿Actor, Rol?
Un actor representa el rol jugado por una persona o cosa que actúa con el sistema.

“Cliente, Administrador, Usuario no Registrado (Autenticado), 
Usuario Registrado (Autenticado), Jefe de Compras, Jefe de 
Personal, Moderador, Jefe de Departamento, Obrero de 
Planta, Supervisor.

¿Actor o Rol?: Sería mejor usar la palabra rol, pero 
algunos piensan que “Actor” fue usado debido a una 
mala traducción del Sueco

NOTA: NO TODOS los 
interesados en el 
sistema (stakeholders) 
son actores, sólo son 
actores aquellos que  utilizarán el sistema como tal osea es toda entidad externa al sistema que guarda una relación con este y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluyen a todas los sistemas externos, además de entidades abstractas, como el tiempo.  t








lunes, 15 de octubre de 2012

QUE ES RUP Y SU CICLO DE VIDA


(( 11 POST ))

DEFINICIÓN


El Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, diseño, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
También se conoce por este nombre al software, también desarrollado por Rational, que incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, elRational Unified Process, que se vendiera como producto independiente...

 Archivo:Rup espanol.gif







CICLO DE VIDA DE RUP


El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea Base) de la arquitectura.
Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos.

lunes, 8 de octubre de 2012

INGENIERÍA DE SOFTWARE


               10 POST !!  CASOS DE REQUERIMIENTOS




Formas para resolver los 2 primeros  casos de  requerimientos, el objetivo primordial  es leer los casos, interpretarlos, luego interiorizarlos y crear un documento con nuestro propio comprender. A partir de allí mostrar sus requerimientos y luego sacar los requisitos… tanto funcionales como no funcionales.




Boletín Nº1: Ejercicios de Casos de Uso.
EJERCICIO 1.
UNA EMPRESA ENCARGADA DE VENDER PRODUCTOS, DESEA DE INFORMATIZARLA, Y PARA ELLO DESEA QUE EL SISTEMA REALICE LAS SIGUIENTES FUNCIONES:
EL SISTEMA HA DE PERMITIR QUE LOS VENDEDORES INTRODUZCAN LOS PRODUCTOS QUE VENDEN, JUNTO CON SUS PRECIOS EN EL SISTEMA. ESTA INFORMACIÓN SE EMPLEARÁ PARA CONSTRUIR LISTADOS ESTADÍSTICOS, PARA QUE EL DIRECTOR PUEDA CONSULTARLA. CADA MES, SE GENERARÁ UN LISTADO ESPECIAL CON AGRUPACIONES DE VENTAS POR MESES. EL SISTEMA, ADEMÁS, HA DE PERMITIR AL JEFE DE RECURSOS HUMANOS, DAR DE ALTA Y BORRAR A LOS DIFERENTES VENDEDORES QUE SE AÑADAN O DEJEN LA EMPRESA. EN CUALQUIER MOMENTO, TAMBIÉN TENDRÁ LA OPCIÓN DE CONSULTARLA. PARA LA REALIZACIÓN DE ESTAS TRES FUNCIONALIDADES, SE DISPONDRÁ DE UN SISTEMA GESTOR  DE BASE DE DATOS, ENCARGADO DE TRADUCIR LAS PETICIONES DEL JEFE DE RECURSOS HUMANOS.
EL DIRECTOR, TAMBIÉN PODRÁ CONSULTAR EN TODO MOMENTO  TODA LA INFORMACIÓN REFERENTE AL PERSONAL DE LA EMPRESA.

SOLUCIÓN

RESUMEN DE REQUISITOS

REQUERIMIENTOS  FUNCIONALES
·         PERMITIR QUE LOS VENDEDORES PUEDAN INTRODUCIR PRODUCTOS  QUE SE VENDEN JUNTO A LOS PRECIOS.
·         CONSTRUIR LISTADOS ESTADÍSTICOS
·         PERMITIR QUE EL DIRECTOR PUEDA CONSULTAR LA INFORMACIÓN  INFORMACIÓN REQUERIDA.
·         PERMITIR AL JEFE DE RECURSOS HUMANOS DAR DE ALTA Y/Ó BORRAR VENDEDORES
       
      REQUERIMIENTOS NO FUNCIONALES
·         PERMITIR  UN SISTEMA GESTOR  DE BASE DE DATOS, ENCARGADO DE TRADUCIR LAS PETICIONES DEL JEFE DE RECURSOS HUMANOS.
·         PERMITIR CONSULTAR EN TODO MOMENTO  TODA LA INFORMACIÓN REFERENTE AL PERSONAL DE LA EMPRESA.


TODO ESTOS REQUERIMIENTOS  PODRÍA CAMBIAR DEPENDIENDO DE LAS ESPECIFICACIONES DE TU SISTEMA.



 EJERCICIO 2.
Una empresa encargada del desarrollo de software “a medida”, tiene la necesidad de disponer de la siguiente aplicación CASE:
Los diferentes Clientes a los que se dará servicio, hablarán con los Analistas de Información para establecer los requisitos. El sistema ha de permitir a estos Analistas dar de alta un análisis de requisitos en los que queden establecidos la funcionalidad que el Cliente desea que tenga su programa. Para esto último, en el proceso de alta, se ha de tener la posibilidad de poder realizar una edición para introducir en el sistema el documento con los requisitos. Los Analistas de Sistemas de la empresa, podrán realizar consulta a estos últimos documentos, para lo cual tendrán que editarlo. Una vez estudiados, procederán a dar de alta a los diagramas y documentos de análisis. Para realizar los diagramas se utilizará la herramienta “Rational Rose”. Estos mismos agentes, también realizaran el diseño funcional del sistema, utilizando la funcionalidad de edición que ofrece el sistema.
Los Programadores, son los encargados de consultar el diseño, accediendo a la herramienta de edición, lo traducirán al lenguaje de programación JAVA, y lo compilarán. Por último, existe en la empresa el personal de Calidad encargada de revisar tanto la documentación generada por los Analistas como los programas tecleados por los Programadores. Para esto, podrán realizar consultas generales, pudiendo hacer uso tanto del módulo de edición como del compilador.

Representar mediante la técnica de “Casos de Uso”, las diferentes funcionalidades que ofrecerá el sistema, junto con los actores que la utilizan.

SOLUCIÓN
RESUMEN DE REQUISITOS—

REQUERIMIENTOS  FUNCIONALES
·         PERMITIR  QUE LOS DIFERENTES CLIENTES A LOS QUE SE DARÁ SERVICIO, HABLARÁN CON LOS ANALISTAS DE INFORMACIÓN PARA ESTABLECER LOS REQUISITOS.

·         PERMITIR AL ANALISTA LA POSIBILIDAD DE PODER REALIZAR LA EDICIÓN PARA INTRODUCIR EN EL SISTEMA EL DOCUMENTO DE LOS REQUISITOS ESTABLECIDOS PARA LA FUNCIONALIDAD QUE EL CLIENTE TENGA DESEA QUE TENGA SU PROGRAMA.

·         CONSULTAR  A ESTOS ÚLTIMOS DOCUMENTOS, PARA QUE LOS ANALISTAS DE SISTEMAS DE LA EMPRESA PUEDAN EDITARLO.

·         REALIZAR DIAGRAMAS QUE PROCEDERÁN A DAR DE ALTA A LOS DIAGRAMAS Y DOCUMENTOS DE ANÁLISIS.



REQUERIMIENTOS NO FUNCIONALES.

·         PERMITIR QUE LOS PROGRAMADORES, SON LOS ENCARGADOS DE CONSULTAR EL DISEÑO, ACCEDIENDO A LA HERRAMIENTA DE EDICIÓN, LO TRADUCIRÁN AL LENGUAJE DE PROGRAMACIÓN JAVA.

·         PERMITIR QUE EL PERSONAL DE CALIDAD  SE ENCARGUE DE REVISAR TANTO LA DOCUMENTACIÓN GENERADA POR LOS ANALISTAS COMO LOS PROGRAMAS TECLEADOS POR LOS PROGRAMADORES.