lunes, 23 de mayo de 2011

DIAGRAMA DE SECUENCIA

DIAGRAMA DE ACTIVIDADES

DIAGRAMA DE PAQUETES

DIAGRAMA DE ESTRUCTURA

DIAGRAMA DE COMPONENTES Y DESPLIEGUE

DIAGRAMA DE CLASES

VIDEO CASOS DE USO

Diagrama de componentes

GUÍA PARA EL USUARIO


martes, 10 de mayo de 2011

La Evaluación del Sistema:

Se lleva a cabo para identificar puntos débiles y fuertes del Sistema implantado. La evaluación ocurre a lo largo de cualquiera de las siguientes cuatro dimensiones:

 Evaluación operacional:

Es el Momento en que sé evalúa la manera en que funciona el Sistema, esto incluye su facilidad de uso, Tiempo de respuesta ante una necesidad o proceso, como se adecuan los formatos en que se presenta la Información, contabilidad global y su nivel de Utilidad.

 Impacto Organizacional:

Identifica y mide los beneficios operacionales para la Empresa en áreas tales como, Finanzas (Costos, Ingresos y Ganancias), eficiencia en el desempeño laboral e impacto competitivo, Impacto, rapidez y organización en el flujo de Información interna y externa.

Desempeño del Desarrollo.

Es la evaluación del Proceso de desarrollo adecuado tomando en cuentas ciertos criterios como, Tiempo y esfuerzo en el desarrollo concuerden con presupuesto y estándares y otros criterios de Administración de Proyectos. Además se incluyen la valoración de los métodos y herramientas utilizados durante el desarrollo del Sistema.

Capacitación de Usuarios del Sistema:

Es enseñar a los usuarios que se relacionan u operan en un proceso de implantación.La Responsabilidad de esta capacitación de los Usuarios primarios y secundarios es del Analista, desde el personal de captura de datos hasta aquellos que toman las decisiones sin usar una Computadora.

SERVICIOS DE CAPACITACION

Vendedores: Son aquellos que proporcionan capacitación gratuita fuera de la Empresa de uno o dos días.

Instructor pagado externamente: Son aquellos que pueden enseñar todo acerca de las computadoras pero para algunos usuarios esta no es una capacitación necesaria.

Instructores en casa: Están familiarizados con el personal y pueden adecuar los materiales a sus necesidades, pero le faltaría experiencia en Sistemas de Información que es realmente la necesidad del usuario.

OBJETIVOS

Es lograr que los usuarios tengan el Dominio necesario de las cosas básicas acerca de las maquinarias y procesos que se emplean para su operación de manera eficiente y segura.

IMPLANTACION Y ENFOQUES DE IMPLEMENTACION

Es la última fase del desarrollo de Sistemas. Es el proceso instalar equipos o Software nuevo, como resultado de un análisis y diseño previo como resultado de la sustitución o mejoramiento de la forma de llevar a cavo un proceso automatizado.


ENFOQUES DE IMPLEMENTACION

Es darle responsabilidad a los grupos.

Uso de diferentes estrategias para el entrenamiento de los usuarios.

El Analista de Sistemas necesita ponderar la situación y proponer un plan de conversión que sea adecuado para la organización.

El Analista necesita formular medidas de desempeño con las cuales evaluar a los Usuarios.

Debe Convertir físicamente el sistema de información antiguo, al nuevo modificado.

EVALUACION DEL DISEÑO "PASOS"

La evaluación de la interfaz del usuario es un ciclo iterativo que se resume en los siguientes pasos:
1.    Diseño preliminar

2.    Construcción del primer prototipo de la interfaz

3.    El usuario valida la interfaz

4.    El diseñador estudia la evaluación

5.    Se realizan cambios en el diseño

6.    Construcción del siguiente prototipo

7.    Si la interfaz no está completa se regresa al paso 3.

¿QUE DEBE REALIZAR UN ANALISTA PARA EL DISEÑO DE SALIDA?

Determine que información presentar. Decidir si la información será presentada en forma visual, verbal o impresora y seleccionar el medio de salida.

Disponga la presentación de la información en un formato aceptable.

Decida como distribuir la salida entre los posibles destinatarios.

COHESION

         La cohesión determina si los diferentes elementos de un módulo deben estar juntos.
         El objetivo es tener alta cohesión
         La cohesión y el acoplamiento están relacionados, a mayor cohesión en los módulos habrá menor acoplamiento entre módulos
         La correlación no es perfecta

principales atributos de calidad a evaluar en un sistema

Los principales atributos de calidad a evaluar en un sistema es que éste sea:
       Correcto
       Eficiente
       Mantenible
       Eficiente en costos

diseño clásico

 El diseño clásico consiste de tres actividades:



Diseño de la arquitectura del software

El resultado de diseñar los módulos de un sistema de software se le conoce como diseño de la arquitectura del sistema. El diseño de la arquitectura es el primer paso en el diseño, va seguido del diseño detallado y la fase de pruebas del diseño



Diseño detallado

Durante esta fase, cada uno de los módulos identificados durante el diseño de la arquitectura es especificado a detalle, incluyendo seudocódigo representando los algoritmos, las estructuras de datos y los datos miembros.



Pruebas del diseño

Sirve para verificar que los requerimientos se estén incluyendo conforme a las especificaciones. Las estructuras creadas durante el diseño de la arquitectura son un vehículo importante para las pruebas del diseño, en las que se siguen los escenarios de los casos de uso  en una simulación del uso del sistema. Dichas pruebas son imposibles sin la representación de los módulos y sus inter-relaciones (acoplamiento).

Diseño del software

El diseño es la fase del proceso de desarrollo de software “donde se crea Una representación o modelo del software. A diferencia del análisis donde se describen los datos y funciones requeridos, el modelo del diseño proporciona los detalles acerca de las estructuras de los datos, las arquitecturas, las interfaces y los componentes del software necesarios para implementar el sistema” [Pressman, 2005]

 

lunes, 9 de mayo de 2011

diagrama de comunicación

 Un diagrama de comunicación modela las interacciones entre objetos o partes en términos de mensajes en secuencia. Los diagramas de comunicación representan una combinación de información tomada desde el diagrama de clasessecuencia, y diagrama de casos de uso describiendo tanto la estructura estática como el comportamiento dinámico de un sistema.



diagrama global de las interacciones

El diagrama global de las interacciones es un diagrama de comportamiento, más precisamente, uno de los cuatro diagramas de interacción. Muestra una cierta vista sobre los aspectos dinámicos de los sistemas modelados. Aunque un diagrama global de las interacciones es una representación gráfica de una interacción, éste se distingue fuertemente de los diagramas de secuencia y de comunicación, dos de los otros diagramas de interacción. De hecho, algunos elementos gráficos del diagrama global de las interacciones están tomados del diagrama de actividades, otro diagrama de comportamiento para el modelado de actividades.



diagrama de secuencia

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML.

diagrama de interacción

El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente.
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de Casos de Uso (son diferentes).
Los componentes de un diágrama de interacción son:
  • Un Objeto o Actor.
  • Mensaje de un objeto a otro objeto.
  • Mensaje de un objeto a si mismo.
Elementos

diagrama de maquinas de estado

diagrama de caso de uso

 un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. 





Diagramas de comportamiento

los diagramas de comportamiento se emplean para visualizar, especificar, construir y documentar los aspectos dinámicos de un sistema.
Los aspectos dinámicos de un sistema de software involucran cosas tales como el flujo de mensajes a lo largo del tiempo y el movimiento físico de componentes en una red.

DIAGRAMA DE PAQUETES

Diagrama de despliegue

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.

diagrama de estructura compuesta

Un diagrama de estructura compuesta es un tipo de diagrama de estructura estática en el Lenguaje de Modelado Unificado (UML), que muestra la estructura interna de una clase y las colaboraciones que esta estructura hace posibles. Esto puede incluir partes internas,puertas mediante las cuales, las partes interactúan con cada una de las otras o mediante las cuales, instancias de la clase interactúan con las partes y con el mundo exterior, y conectores entre partes o puertas. Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de ejecución para lograr algún propósito.



martes, 3 de mayo de 2011

DIAGRAMA DE OBJETOS

Un diagrama de Objetos está relacionado de cerca con un diagrama de Clases, con la diferencia de que éste describe las instancias de los objetos de clases en un punto en el tiempo. Esto podría parecer similar al diagrama de Estructura Compuesta, que modela el comportamiento en tiempo de ejecución; la diferencia es que el diagrama de Objetos ejemplifica al diagrama de Clases estático, mientras que los diagramas de Estructura Compuesta refleja las arquitecturas diferentes de sus contrapartes estáticas. Los diagramas de Objetos no presentan arquitecturas que varíen de sus correspondientes diagramas de Clases, pero reflejan la multiplicidad y los roles a los que las clases instanciadas podrían servir. Ellos son muy útiles en la comprensión de diagramas de Clases complejos, al crear diferentes casos en los que se aplican las relaciones y las clases.


[Imagen5.png]


1: actor


2: objeto


3: colaboracion


4: conector de flujo de informacion


5: conector

DIAGRAMA DE COMPONENTES

Un diagrama de Componentes ilustra los fragmentos de software, controladores embebidos, etc. que conformarán un sistema. Un diagrama de componentes tiene un nivel de abstracción más elevado que un diagrama de clase - usualmente un componente se implementa por una o más clases (u objetos) en tiempo de ejecución. Estos son bloques de construcción, como así eventualmente un componente puede comprender una gran porción de un sistema.




[Imagen3.png]


1: componente

2: paquete

3: exponer la interfas

4: conector

5: interfasz

6: ensamble

Diagramas de Estructura



DIAGRAMA

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, a veces es útil categorizarlos jerárquicamente, como se muestra en la figura de la derecha.

lunes, 11 de abril de 2011

Cual es el propósito primario del modelo de caso de uso?

El proposito primario del modelo caso de uso es comunicar las funciones y el comportamiento del sistema al cliente o la usuario final.

Por que el caso de uso es una herramienta valiosa?

Es una herramienta valiosa ya que es una técnica de aciertos y errores para obtener los requerimientos del sistema desde el punto de vista del usuario. Esto es importante si la finalidad es crear un sistema que puede ser utilizado por la gente en general.
Son una herramienta esenciapara lcaptura de requerimientos, lplanificación,el control dproyectoiterativos. La caphlrde los casos duso es una de lastareas principaledurantlfase de elaboración; dhecho, es lo primero que sedebe hacer.

¿Que es un caso de uso?

CASO DE USO: Locasoduso soun fenómeno interesante. Durantmuchotiempo, tanto eel desarrollorientado a objetos como eel tradicionallaspersonas se auxiliaban de escenarios típicos que les ayudaban a comprendelosrequerimientos. Estos escenarios, sin embargo, se trataban dmodmuyinformal¡ siempre se construíanpero pocas veces se documentaban. IvarJacobson es ampliamente conocido pohabecambiado esto con smétodoObjectory y sprimer libro sobre etema.

martes, 5 de abril de 2011

FORO DE CASO DE USO

casos de uso son una técnica para especificar el comportamiento de un sistema:
“Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus
servicios.”
Todo sistema de software ofrece a su entorno –aquellos que lo usan– una serie de servicios. Un caso de uso es
una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos “alguien o algo”
hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de
hardware y software.
Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo
pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está “ejecutando” el caso
de uso ingresando pedido.

FORO DE UML

UML es una especificación de notación orientada a objetos. Se basa en las anteriores especificaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto.
Con UML nos debemos olvidar del protagonismo excesivo que se le da al diagrama de clases, este representa una parte importante del sistema, pero solo representa una vista estática, es decir muestra al sistema parado. Sabemos su estructura pero no sabemos que le sucede a sus diferentes partes cuando el sistema empieza a funcionar. UML introduce nuevos diagramas que representa una visión dinámica del sistema. Es decir, gracias al diseño de la parte dinámica del sistema podemos darnos cuenta en la fase de diseño de problemas de la estructura al propagar errores o de las partes que necesitan ser sincronizadas, así como del estado de cada una de las instancias en cada momento. El diagrama de clases continua siendo muy importante, pero se debe tener en cuenta que su representación es limitada, y que ayuda a diseñar un sistema robusto con partes reutilizables, pero no a solucionar problemas de propagación de mensajes ni de sincronización o recuperación ante estados de error. En resumen, un sistema debe estar bien diseñado, pero también debe funcionar bien.
UML también intenta solucionar el problema de propiedad de código que se da con los desarrolladores, al implementar un lenguaje de modelado común para todos los desarrollos se crea una documentación también común, que cualquier desarrollador con conocimientos de UML será capaz de entender, independientemente del lenguaje utilizado para el desarrollo.

lunes, 4 de abril de 2011

tipos de vistas de UML?

LOS TIPOS DE VISTA SOLO SON 5 :


1) VISTA DE CASO DE USO

2)VISTA DE DISEÑO

3)VISTA DE PROCESOS 

4) VISTA DE IMPLEMENTACION 

5)VISTA DE IMPLANTACIÓN 

Que es una vista en UML?

Una vista en un UML es un subconjunto de construcciones de modelado que se enfoca en un aspecto particular del sistema.

martes, 29 de marzo de 2011

Significado de un modelo?

Un modelo es un generador de potenciales configuraciones de sistemas; los posibles sistemas son sus extenciones, o valores. idealmente, todas la configuraciones copnsistentes con el modelo deberian ser posibles. a veces, sin embargo, no no es posible presentar todas las restricciones dentro de un modelo. un modelo es tambien una descripcion de una estructura generica y del significado del sistema. las descripciones son su objetivo o significado. un modelo es siempre una abt5raccion a un cierti nivel. captua los aspectos ecenciales de un sistema y omite algunos de los detalles.

Para que sirven los modelos