lunes, 31 de mayo de 2010
SCRUM
Leer de la pagina 57 hasta la 105.
Es imperativo que lean las paginas indicadas por lo menos dos veces.
lunes, 24 de mayo de 2010
viernes, 21 de mayo de 2010
miércoles, 5 de mayo de 2010
Modelo de Datos
Características
- Es el proceso de analizar los aspectos de interés para una organización y la relación que tienen unos con otros.
- Resulta en el descubrimiento y documentación de los recursos de datos del negocio.
- El modelado hace la pregunta " Qué ? " en lugar de " Cómo ? ", ésta última orientada al procesamiento de los datos.
- Es una tarea difícil, bastante difícil, pero es una actividad necesaria cuya habilidad solo se adquiere con la experiencia.
Metas y beneficios
- Registrar los requerimientos de datos de un proceso de negocio.
- Dicho proceso puede ser demasiado complejo y se tendrá que crear un "enterprise data model", el cual deberá estar constituído de líneas individuales.
- Permite observar:
- Patrones de datos
- Usos potenciales de los datos
Tipos de modelado de datos
Basicamente son 3:
- Conceptual: muy general y abstracto, visión general del negocio/institución.
- Lógico: versión completa que incluye todos los detalles acerca de los datos.
- Físico: esquema que se implementara en un manejador de bases de datos (DBMS).
lunes, 3 de mayo de 2010
Prototipado
Un usuario de sistema sólo interactúa con un software a través de la interfaz de usuario por lo que tiene lógica gastar una cantidad significativa de tiempo en los requisitos para garantizar que la interfaz de usuario tenga toda la funcionalidad deseada por el usuario este incluida, y que la funcionalidad más comúnmente utilizada sea de fácil acceso. La forma más sencilla de hacerlo es utilizando un prototipo de pantalla.
Entre estos dos extremos se encuentra aplicaciones de pantalla de diseño que le permiten dibujar las pantallas y las interacciones entre las pantallas de modelo. Herramientas de alta calidad de prototipos permiten introducir datos de ejemplo y permitir a los usuarios cambiar entre las pantallas pulsando los botones para que puedan easily comprender la interfaz y su funcionalidad. La mayoría de las herramientas de creación de prototipos producir la salida final en un formato HTML para que puedan ser fácilmente compartida, incluso si un cliente no está en la misma oficina donde los requisitos se están desarrollando.
En la búsqueda de una herramienta de creación de un prototipo, asegúrese de seleccionar una herramienta que es bastante fácil de utilizar que usted puede fácilmente pantallas prototipo, mientras que su cliente está en la habitación. Esto le permitirá a la lluvia de ideas y hacer cambios a las pantallas sin demoras. Una herramienta de creación de prototipos debe tener controles comunes ya definidos para mantener los estándares de diseño y mejorar el aspecto de las pantallas. Ser capaz de introducir los datos de muestra en cada pantalla ,puede permitir que el cliente identifique las áreas que pueden estar incorrectas.
jueves, 15 de abril de 2010
lunes, 12 de abril de 2010
miércoles, 7 de abril de 2010
FORMATO DE PROYECTO
FORMATO DE PROYECTO DE ANALISIS DE SISTEMAS
· Portada
· Introducción
· Índice
· Objetivos: General y Específicos
Situacion Problematica
-Planteamiento del Problema
· Capitulo I: Marco Teórico:
o Sistemas
o sistemas de información
§ clasificación de los SI
o Sistema XXXX
§ Definición
§ Componentes
§ Etc.
o Proceso Unificado de desarrollo de software
· Capitulo II: Marco Empírico
o Generalidades de la organización o área donde se realizara el análisis
o ERS
o Casos De uso
§ Actores
§ Diagramas de Casos de Uso
§ Especificación de Casos de Uso
o Clases de Dominio
§ Identificar clases de dominio o de contexto
§ Identificar atributos y comportamiento de las clases
§ Diagrama de Clases de dominio
martes, 6 de abril de 2010
ESPECIFICACION DE CASOS DE USO
ID | CU100 |
Nombre: | Registrar Empresas |
Descripción: | Permite dar de alta a una empresa en el sistema |
Autor: | Jonathan Rivas |
Fecha Creación: | 06-04-2010 |
Fecha Última Modif.: | 06-04-2010 |
Actores: | Contador |
Precondiciones: | El actor debe estar autenticado exitosamente en el sistema |
Flujo Normal de Eventos: | 1. Seleccionar la opción Registrar Empresa 2. Ingresar los datos solicitados de nombre, giro, representante legal, contador, etc. 3. El actor selecciona la opción de guardar 4. El sistema verifica los datos ingresados y que los campos obligatorios hayan sido completados. 5. El sistema guarda el registro de la empresa ingresada. |
Flujo Alterno: | Duplicidad de Registro. 4. El sistema envía un mensaje indicando que la empresa que intenta ingresar ya ha sido dada de alta, y le indica al usuario que modifique los datos o aborte la operación. (Regrese paso 2). Datos Faltantes o Incorrectos 4. El sistema detecta que un valor no ha sido ingresado o no se ha completado correctamente e indica la usuario sobre ello, dirigiéndolo hacia el campo donde se encuentra la incongruencia. (Regrese paso 2). |
Post Condiciones | La empresa ya esta registrada. |
ID | CU300 |
Nombre: | Gestionar Sistema Contable |
Descripción: | Realiza las operaciones básicas de mantenimiento del catalogo de cuentas. |
Autor: | Jonathan Rivas |
Fecha Creación: | 06-04-2010 |
Fecha Última Modif.: | 06-04-2010 |
Actores: | Contador, Auxiliar Contable |
Precondiciones: | El actor debe estar autenticado exitosamente en el sistema |
Flujo Normal de Eventos: | |
Flujo Alterno: | |
Post Condiciones | |
ID | CU320 |
Nombre: | Eliminar Cuenta |
Descripción: | Elimina cuenta contable del sistema para que no se puedan hacer movimientos con esta. |
Autor: | Jonathan Rivas |
Fecha Creación: | 06-04-2010 |
Fecha Última Modif.: | 06-04-2010 |
Actores: | Contador |
Precondiciones: | La cuenta a eliminar debe de existir |
Flujo Normal de Eventos: | 1. El usuario selecciona la opción de administración catalogo de cuentas. 2. Selecciona la cuenta contable que desea eliminar 3. El usuario selecciona la opción eliminar 4. El sistema verifica que la cuenta no tenga movimientos 5. El sistema solicita confirmación de operación 6. La cuenta se elimina del sistema y envía un mensaje al usuario. |
Flujo Alterno: | Cuenta con movimientos: 4. El sistema encuentra que la cuenta a eliminar posee movimientos. 4.1 El sistema muestra un mensaje al usuario 4.2 Aborta la operación Confirmación de Operación: 5. El usuario decide no eliminar la cuenta y selecciona la opción de cancelar. 5.1 Se aborta la operación. |
Post Condiciones | La cuenta esta eliminada. |
ID | CU310 |
Nombre: | Modificar Cuenta |
Descripción: | Realizar cambios en una cuenta existente. |
Autor: | Jonathan Rivas |
Fecha Creación: | 07-04-2010 |
Fecha Última Modif.: | 07-04-2010 |
Actores: | Contador |
Precondiciones: | La cuenta debe existir en el catálogo de cuentas. |
Flujo Normal de Eventos: | 1. El usuario selecciona la opción administración de catalogo de cuentas 2. El usuario selecciona la cuenta que desea modificar. 3. El usuario selecciona la opción modificar. 4. Se realizan los cambios en el nombre de la cuenta y/o el nivel. 5. El usuario selecciona la opción guardar. 6. El sistema verifica los valores ingresados y los campos obligatorios. 7. El sistema solicita confirmación de operación. 8. La cuenta se modifica en el sistema y se envía un mensaje al usuario. |
Flujo Alterno: | DUPLICIDAD DE NOMBRE CUENTA 6. El sistema encuentra que el nombre de la cuenta ya existe en ese mismo nivel dentro del catalogo de cuentas registrado 6.1 El sistema muestra un mensaje al usuario 6.2 Aborte la operación. DATOS FALTANTES 6. No se ha ingresado un nombre de cuenta 6.1 El sistema muestra un mensaje al usuario para indicarle que falta especificar un nombre de cuenta y lo direcciona hacia el campo correspondiente. (Regrese paso 4). |
Post Condiciones | La cuenta ha sido actualizada correctamente. |
lunes, 5 de abril de 2010
lunes, 29 de marzo de 2010
lunes, 22 de marzo de 2010
miércoles, 17 de marzo de 2010
CASOS DE USO
INTRODUCCION
Un caso de uso es una herramienta que sirve para representar la forma como un cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en la cual, los elementos interactuan, a estas acciones se les llama operaciones o Casos de uso.
Los casos de uso se utilizan básicamente en el proceso de modelado de sistemas, partiendo de una percepción o perspectiva que nos plantea el paradigma de la orientación a objetos, y en este caso el analisis y diseño orientados a objetos.
Los casos de uso forman parte del Lenguaje Unificado de Modelado UML por sus siglas en ingles (Unified Modeling Languaje) el cual a su vez se compone de muchas otras herramientas, básicamente diagramas como: Diagramas de Clase, Diagramas de Secuencia, Colaboracíón, Transición de Estados, Diagramas de Actividad, Componentes, Deployment, entre otros. Todas ellas usadas a lo largo de las etapas o ciclo de vida del proceso de desarrollo.
La aplicación principal de los casos de uso es en el proceso de análisis y diseño pero de manera particular en la definición de requerimientos del usuario. Es una excelente herramienta de comunicación debido a la sencillez de su elaboración asi como su comprensión. En teoría los usuarios deberían conocer como hacer sus propios casos de uso, pero eso solo es en "teoría".
Un diagrama de casos de uso consta de los siguientes elementos: Actor, Casos de Uso y Relaciones.
Elementos
l Actor:
Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.Como ejemplo para ilustrar la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.
l Caso de Uso:
Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.
l Relaciones:
¡ Asociación. Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.
¡ Dependencia o Instanciación. Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.
¡ Generalización. Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de:
Uso (<
extends. Se recomienda utilizar cuando un caso de uso es similar a otro (características).
uses. Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica. De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.
PASOS PARA MODELAR SISTEMAS A TRAVES DE LOS CASOS DE USO
Si quisieramos aprender a modelar sistemas orientados a objetos por medio de Casos de Uso, ¿cuales serían los pasos a seguir? es decir, ¿existe una forma generalmente aceptada que nos diga el 'como', para realizarlos?
Bien, efectivamente existe, pero tampoco no es un dogma, son solo guias generales. Dichos pasos son:
- Identificar actores. Los actores son mejor dicho, los roles que un usuario o usuarios del sistema llevan a cabo en algun momento del tiempo. Tambien pueden ser otros sistemas con los que el 'sistema' en proceso de modelado tiene interacción. Ejemplo: Para un sistema de ventas (directas y por catalogo), nuestros actores pueden ser: Vendedor, Cliente, Supervisor de Ventas.
- Identificar Metas (Metas, objetivos generales o responsabilidades). Todos los actores en el entorno a modelar tienen metas u objetivos, o en su defecto responsabilidades, o en su defecto, acciones que desean realizar u obtener del sistema. Por ejemplo: Para el sistema de Ventas, el Vendedor tiene como meta, objetivo o responsabilidad (Ofrecer productos, Cerrar Venta, Ganar mucho dinero via Cobrar comisiones).
- Obtener o identificar los Casos de Uso a partir de las Metas. Las metas son importantes porque a partir de su identificación pasamos a realizarlas y estas se convierten en los Casos de Uso, de esta forma tan sencilla obtenemos la información de funcionalidad que requiere nuestro sistema.
- Especificar cada Caso de Uso. Una vez identificados seguimos a especificarlos uno a uno, es probable que en el inter, de esos sencillos pasos algunos casos de uso desaparezcan o se fusionen con otros, por ambiguedades detectadas o por detalles que se hayan escapado durante el proceso. Es importante recordar que de eso se trata el modelado, no es indispensable que quede al cien por ciento el modelo desde la primera vez, por eso hay que hacerlo en iteraciones o ciclos. La especificación de los casos de uso contiene varias partes, las fundamentales son Nombre, Descripcion, Actores, Flujo Principal y Flujos Alternos. Este grupo de elementos constituyen lo que se conoce como plantilla (Template), y nos podemos encontrar un sinnumero de plantillas en la red. Por ejemplo ésta: