lunes, 23 de mayo de 2011
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.
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.
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.
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 clases, secuencia, 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.
- Objeto/Actor:
El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto. - Mensaje a Otro Objeto:
Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular. - Mensaje al Mismo Objeto:
No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio.
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 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.
1: actor
2: objeto
3: colaboracion
4: conector de flujo de informacion
5: conector
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.
1: componente
2: paquete
3: exponer la interfas
4: conector
5: interfasz
6: ensamble
1: componente
2: paquete
3: exponer la interfas
4: conector
5: interfasz
6: ensamble
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, 2 de mayo de 2011
martes, 26 de abril de 2011
martes, 12 de abril de 2011
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 esencial para la captura de requerimientos, la planificación,o el control de proyectos iterativos. La caphlra de los casos de uso es una de lastareas principales durante la fase de elaboración; de hecho, es lo primero que sedebe hacer.
¿Que es un caso de uso?
CASO DE USO: Los casos de uso son un fenómeno interesante. Durante muchotiempo, tanto en el desarrollo orientado a objetos como en el tradicional, laspersonas se auxiliaban de escenarios típicos que les ayudaban a comprender losrequerimientos. Estos escenarios, sin embargo, se trataban de modo muyinformal¡ siempre se construían, pero pocas veces se documentaban. IvarJacobson es ampliamente conocido por haber cambiado esto con su métodoObjectory y su primer libro sobre el tema.
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.
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.
Suscribirse a:
Entradas (Atom)
Archivo del blog
-
▼
2011
(76)
-
▼
mayo
(34)
- 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
- La Evaluación del Sistema:
- Capacitación de Usuarios del Sistema:
- IMPLANTACION Y ENFOQUES DE IMPLEMENTACION
- EVALUACION DEL DISEÑO "PASOS"
- ¿QUE DEBE REALIZAR UN ANALISTA PARA EL DISEÑO DE S...
- COHESION
- principales atributos de calidad a evaluar en un s...
- diseño clásico
- Diseño del software
- diagrama de comunicación
- diagrama global de las interacciones
- diagrama de secuencia
- diagrama de interacción
- diagrama de maquinas de estado
- diagrama de caso de uso
- Sin título
- Diagramas de comportamiento
- DIAGRAMA DE PAQUETES
- Diagrama de despliegue
- diagrama de estructura compuesta
- DIAGRAMA DE OBJETOS
- DIAGRAMA DE COMPONENTES
- Diagramas de Estructura
- DIAGRAMA
- FORMATO
-
►
abril
(12)
- PRACTICA DE CASO DE USO
- TEORÍA PRINCIPAL CASO DE USO
- UML
- ACTIVIDADES Y CASO DE USO
- EJEMPLOS DE CASO DE USO
- Cual es el propósito primario del modelo de caso d...
- Por que el caso de uso es una herramienta valiosa?
- ¿Que es un caso de uso?
- FORO DE CASO DE USO
- FORO DE UML
- tipos de vistas de UML?
- Que es una vista en UML?
-
▼
mayo
(34)