domingo, 7 de abril de 2013

caso de uso

Casos de Uso (Use Case)


El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:

  • actor 
  • caso de uso
  • relaciones de uso, herencia y comunicación.


Elementos
  • 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 a 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.
  • 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.
  • 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 (<<uses>>) o deHerencia (<<extends>>).
      Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
      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.

NOTA: Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué). De forma que al ser parte del análisis nos ayudan a describir qué es lo que es sistema debe hacer. Los Casos de Uso son qué hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cómo este interactúa con el usuario.

domingo, 17 de marzo de 2013

CICLO DE VIDA DE UN SISTEMA DE INFORMACION


CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS

El ciclo de vida de un sistema de información está ligado al ciclo de vida del sistema de base de datos sobre el que se apoya. Al ciclo de vida de los sistemas de información también se le denomina ciclo de vida de desarrollo del software. 

Las etapas típicas del ciclo de vida de desarrollo del software son: planificación, recolección y análisis de los requisitos, diseño (incluyendo el diseño de la base de datos), creación de prototipos, implementación, prueba, conversión y mantenimiento. El método del ciclo de vida para el desarrollo de sistemas consta de 6 etapas:



1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.

2). Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. 

3). Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.

4). Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.

Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.

5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. 

Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.

6). Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.

Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

domingo, 10 de marzo de 2013

UML


  • quinto blog

¿QUE ES UML?
Es El Lenguaje Unificado de Modelad prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.


  • Mejores tiempos totales de desarrollo (de 50 % o más).
  • Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
  • Establecer conceptos y artefactos ejecutables.
  • Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
  • Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
  • Mejor soporte a la planeación y al control de proyectos.
  • Alta reutilización y minimización de costos.




UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.



  • Diagramas de Casos de Uso para modelar los procesos 'business'.
  • Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
  • Diagramas de Colaboración para modelar interacciones entre objetos.
  • Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
  • Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
  • Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
  • Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
  • Diagramas de Componentes para modelar componentes.
  • Diagramas de Implementación para modelar la distribución del sistema.



  • UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.



    En 1996, el Object Management Group (OMG), un pilar estándar para la comunidad del diseño orientado a objetos, publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares. UML, en su versión 1.0, fue propuesto como una respuesta a esta petición en enero de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG un documento revisado de UML, llamado UML versión 1.1. Este documento fue aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento OMG UML versión 1.1. El OMG está actualmente en proceso de mejorar una edición técnica de esta especificación, prevista su finalización para el 1 de abril de 1999.



    Los principales beneficios de UML son:
    • Mejores tiempos totales de desarrollo (de 50 % o más).
    • Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
    • Establecer conceptos y artefactos ejecutables.
    • Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
    • Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
    • Mejor soporte a la planeación y al control de proyectos.
    • Alta reutilización y minimización de costos.


    domingo, 3 de marzo de 2013

    TÉCNICAS PARA DEFINIR LOS REQUERIMIENTOS

    cuarto blog


    La importancia de aplicar correctamente la tecnicas de recoleccion de informacion es que son vitales y ademas de esto facilitan la busqueda y definicion de los requerimientos necesarios de un sistema de informacion .Aplicando estas tecnicas,podemos ir mas alla y asi detectar los requerimientos necesarios,las técnicas como el chequeo,la observación, el método delfil , la sesión de grupo entrevista,muestreo documental son técnicas que cada una de ellas aplican métodos diferentes para identificar requerimientos diferentes. Por esta razón es muy importante que estas técnicas de recolección de información  sean aplicadas de la manera mas correcta posible para así concluir con buenos requerimientos para la creación del software.

    Dentro de los objetivos de esta fase se encuentran el entender el dominio de la aplicación, las necesidades del negocio, las restricciones del sistema, a los participantes del sistema y al problema en si, para entender de manera inicial lo que se debe desarrollar.
    Algunas de las técnicas y herramientas más importantes para llevar a cabo la recolección de requerimientos son:

    Entrevistas: La entrevista es un método para descubrir hechos y opiniones que tienen los posibles usuarios y otros participantes dentro del sistema que se está desarrollando.

    Observación y análisis social: Este método es muy útil cuando se busca estudiar las actividades y procesos que se están llevando a cabo en una organización en el momento. La observación permite a los investigadores observar lo que los usuarios hacen actualmente en un determinado contexto.

    Lluvia de Ideas: Las lluvias de ideas son sesiones donde todos los participantes brindan sus ideas para obtener una solución a una problemática.
    entre otros.

    sábado, 23 de febrero de 2013

    SOFTWARE COMO PRODUCTO.

    • TERCER BLOG
    Para comenzar, según lo que e investigado a cerca del software con la recopilación  de mis conocimientos e logrado destacar que  el software como producto es la unión de componentes lógicos que permiten al usuario realizar tareas especificas, con la ayuda de componentes. físicos llamados hardware. Si reside dentro de un teléfono celular u opera dentro de una computadora central, el software es un transformador de información, produciendo, gestionando, adquiriendo, modificando, mostrando o transmitiendo información que puede ser tan simple como un solo bit, o tan complejo como una presentación en multimedia. Como vehículo utilizado para hacer entrega del producto, el software actúa como la base de control de la computadora (sistemas operativos), la comunicación de información (redes) y la creación y control de otros programas (herramientas de software y otros). 

    Considerando este punto de vista  de lo anterior, el software como producto  va más allá de los programas de computación en sus distintos estados: código fuentebinario o ejecutable; también su documentación, los datos a procesar e incluso la información de usuario forman parte del software: es decir, abarca todo lo intangible, todo lo 'no físico' relacionado.


    NOTA: gracias por su atención acepto criticas.


    viernes, 15 de febrero de 2013

    Roles del Analista de sistemas



    El analista de sistemas evalúa de manera sistemática el funcionamiento de un negocio mediante el examen de la entrada y el procesamiento de datos y su consiguiente producción de información, con el propósito de mejorar los procesos de una organización. Muchas mejoras incluyen un mayor apoyo a las funciones de negocios a través del uso de sistemas de información computarizados. Esta definición pone énfasis en un enfoque sistemático y metódico para analizar en consecuencia mejorar lo que sucede en el contexto específico creado por un negocio.

    Mi definición de analista de sistemas es amplia. El analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en computadoras. El analista desempeña diversos roles, en ocasiones varios de ellos al mismo tiempo. Los cuatro roles principales del analista de sistemas son el de consultor, especialista de apoyo, agente de cambio y lenguaje de programación.



    lunes, 11 de febrero de 2013

    AUDITORES DE SISTEMAS


    • NOTA:

    EN MI PUNTO DE VISTA PARA COMENZAR TENEMOS QUE PREGUNTARNOS ¿QUE ES AUDITORIA DE SISTEMAS? COMO BIEN SABEMOS LA AUDITORIA DE SISTEMAS DE INFORMACIÓN SE DEFINE COMO CUALQUIER AUDITORIA QUE ABARCA LA REVISIÓN Y EVALUACIÓN DE TODOS LOS ASPECTOS (O DE CUALQUIER PORCIÓN DE ELLOS) DE LOS SISTEMAS AUTOMÁTICOS DE PROCESAMIENTO DE LA INFORMACIÓN INCLUIDOS LOS PROCEDIMIENTOS NO AUTOMÁTICOS RELACIONADOS CON ELLOS Y LAS INTERFACES CORRESPONDIENTES. 


    ¿QUE ES AUDITORIA DE SISTEMAS?
    La auditoria en informática es la revisión y la evaluación de los controles, sistemas, procedimientos de informática; de los equipos de cómputo, su utilización, eficiencia y seguridad, de la organización que participan en el procesamiento de la información, a fin de que por medio del señalamiento de cursos alternativos se logre una utilización más eficiente y segura de la información que servirá para una adecuada toma de decisiones.
    La auditoria en informática deberá comprender no sólo la evaluación de los equipos de cómputo, de un sistema o procedimiento específico, sino que además habrá de evaluar los sistemas de información en general desde sus entradas, procedimientos, controles, archivos, seguridad y obtención de información.
    La auditoria en informática es de vital importancia para el buen desempeño de los sistemas de información, ya que proporciona los controles necesarios para que los sistemas sean confiables y con un buen nivel de seguridad. Además debe evaluar todo (informática, organización de centros de información, hardware y software).