DIAGRAMA DE ESTADO

Una máquina de estados es todo lo que pueda tener diferentes estados. En muchos casos, cuando hablamos de estados, hablamos de los diferentes estados de un objeto. Los diagramas complejos pueden tener muchos estados diferentes. Para entender mejor objetos difíciles, en ocasiones tiene sentido entender todos los diferentes estados posibles de un objeto y cómo llega el objeto a ese estado. Los estados son las diferentes combinaciones de información que puede contener un objeto y no cómo se comportan.

Cada diagrama de estado generalmente empieza con un círculo oscuro que indica el estado inicial y termina con un círculo con un contorno blanco que denota el estado final. Sin embargo, a pesar de tener puntos de inicio y finalización definidos, se debe recordar que los diagramas de estado no necesariamente son la mejor herramienta para plasmar un desarrollo general de eventos. En lugar de ello, se especializan en ilustrar tipos específicos de comportamiento —en particular, cambios de un estado a otro.

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. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams".

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. A menudo es útil para complementar a un diagrama de clases, pues el diagrama de secuencia se podría describir de manera informal como "el diagrama de clases en movimiento", por lo que ambos deben estar relacionados entre sí (mismas clases, métodos, atributos...). Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

DIAGRAMA DE CLASES

En ingeniería de software, un diagrama de clases en Lenguaje Unificado de Modelado (UML) es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos.

DIAGRAMA DE CASO DE USO

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una forma de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado (UML), 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. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso. En los conceptos se debe detallar más de un caso de uso para poder identificar qué es lo que hace un caso de uso.

• La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.

• La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes y consistentes promueven una imagen fácil de comprender del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.

INTRODUCCIÓN AL UML 

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de modelado visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la implementación de sistemas de software complejos, tanto en estructura como en comportamiento. UML tiene aplicaciones más allá del desarrollo de software, p. ej., en el flujo de procesos en la fabricación.

Es comparable a los planos usados en otros campos y consiste en diferentes tipos de diagramas. En general, los diagramas UML describen los límites, la estructura y el comportamiento del sistema y los objetos que contiene.

UML no es un lenguaje de programación, pero existen herramientas que se pueden usar para generar código en diversos lenguajes usando los diagramas UML. UML guarda una relación directa con el análisis y el diseño orientados a objetos.

Los lenguajes orientados a objetos dominan el mundo de la programación porque modelan los objetos del mundo real. UML es una combinación de varias notaciones orientadas a objetos: diseño orientado a objetos, técnica de modelado de objetos e ingeniería de software orientada a objetos.

UML usa las fortalezas de estos tres enfoques para presentar una metodología más uniforme que sea más sencilla de usar. UML representa buenas prácticas para la construcción y documentación de diferentes aspectos del modelado de sistemas de software y de negocios.

TEMA 2.4 VALIDACIÓN DE REQUERIMIENTOS

Objetivos

Esta actividad tiene como objetivo realizar la validación de todos los requerimientos del sistema a construir. Estos requerimientos pueden ser tanto funcionales como no funcionales.

Descripción

Los analistas se reúnen con el cliente y/o usuario del sistema para validad los requerimientos que se revelaron y especificaron, es decir que estas especificaciones reflejan realmente lo que los usuarios necesitan.

Dela reunión de validación de requerimientos pueden surgir cambios en los requerimientos que impliquen que se realicen nuevamente las actividades de las especificaciones de requerimientos y priorizando los requerimientos necesarios.

TEMA 2.3 ESPECIFICACIÓN DE REQUERIMIENTOS

La especificación de los requerimientos de software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar.  Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como  requisitos funcionales.
Recomendaciones para hacer una buena especificación de requerimientos:
Completa: Todos los requerimientos deben estar reflejados en ellas.
Correcta: El software debe de cumplir con los requisitos de la especificación.
Modificable: Aunque todo requerimiento es modificable, se refiere a que se debe de ser facilmente modificable.

TEMA 2.2 OBSERVACION Y ANÁLISIS DE REQUERIMIENTOS

Existe un gran número de técnicas para obtener requerimientos. A continuación describo las más utilizadas. Hay que aclarar que ninguna de estas técnicas es suficiente por sí sola y que es recomendable combinarlas para obtener requerimientos completos.

Entrevistas

La entrevista es de gran utilidad para obtener información cualitativa como opiniones, o descripciones subjetivas de actividades. Es una técnica muy utilizada, y requiere una mayor preparación y experiencia por parte del analista. La entrevista se puede definir como un “intento sistemático de recoger información de otra persona” a través de una comunicación interpersonal que se lleva a cabo por medio de una conversación estructurada. Debe quedar claro que no basta con hacer preguntas para obtener toda la información necesaria. Es muy importante la forma en que se plantea la conversación y la relación que se establece en la entrevista.

Estos son algunos de los aspectos más importantes a tener en cuenta al realizar entrevistas:

• Preparación. Es necesario documentarse e investigar la situación de la organización analizando los documentos disponibles, de tal forma que la entrevista se enfoque en aquellos aspectos que están solamente en la mente del entrevistado y que no son accesibles por otros medios como la observación o el análisis de documentos.
• Entrevistar al personal adecuado. La mayoría de los analistas adoptan un enfoque top-down, comenzando a entrevistar a directivos para que brinden un panorama general de hacia donde deberían ir las cosas, y terminando por hablar con los empleados que aportan detalles importantes de la operación.
• Duración. Una entrevista debería durar a lo sumo un par de horas.
• Formato. Se recomienda utilizar preguntas abiertas, donde los entrevistados puedan elaborar y dar detalles, más allá de simplemente responder “si” o “no”.

TEMA 2.1 ESTUDIO DE FACTIBILIDAD

El estudio de factibilidad es un instrumento que sirve para orientar la toma de decisiones en la evaluación de un proyecto y corresponde a la última fase de la etapa pre-operativa o de formulación dentro del ciclo del proyecto. Se formula con base en información que tiene la menor incertidumbre posible para medir las posibilidades de éxito o fracaso de un proyecto de inversión, apoyándose en él se tomará la decisión de proceder o no con su implementación.

VENTAJAS Y DESVENTAJAS DE LAS METODOLOGÍAS TRADICIONALES 

Estas metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada [42]. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.

Entre las metodologías tradicionales o pesadas podemos citar:

• RUP (Rational Unified Procces)

• MSF (Microsoft Solution Framework)

• Win-Win Spiral Model

• Iconix

VENTAJAS Y DESVENTAJAS DE METODOLOGÍAS ÁGILES

• La primera y la que, a mi parecer es la más importante, es que estas metodologías ofrecen una rápida respuesta a cambios de requisitos a lo largo del desarrollo del proyecto gracias a su proceso iterativo, es tan importante realizar una buena recolecta de requisitos, como después poder modificarlos evitando grandes pérdidas en cuanto a costes, motivación, tiempo…
• El cliente, si quiere colaborar, puede observar como va avanzando el proyecto, y por supuesto, opinar sobre su evolución gracias a las numerosas reuniones que realiza el equipo con el cliente. Esto le da tranquilidad.
• Uniendo las dos anteriores, se puede deducir que al utilizar estas metodologías, los cambios que quiera realizar el cliente van a tener un menor impacto, ya que se va a entregar en un pequeño intervalo de tiempo un pequeño “trozo” del proyecto al cliente, y si éste quiere cambiarlo, solo se habrá perdido unas semanas de trabajo. Con las metodologías tradicionales las entregas al cliente se realizaban tras la realización de una gran parte del proyecto, eso quiere decir que el equipo ha estado trabajando meses para que luego un mínimo cambio que quiera realizar el cliente, conlleve la pérdida de todo ese trabajo.
• Importancia de la simplicidad al eliminar trabajo innecesario

Pero claro, aunque las ventajas sean muy apetecibles, estas metodologías también presentan inconvenientes que hay que asumir cuando se decide trabajar con ellas. Estos son:

• Falta de documentación del diseño. Al no haber documentación es el código (junto con sus comentarios) lo que se toma como documentación.
• Problemas derivados de la comunicación oral. No hace falta decir que algo que está escrito “no se puede borrar”, en cambio, algo dicho es muy fácil crear ambigüedad.
• Fuerte dependencia de las personas.
• Falta de reusabilidad derivada de la falta de documentación
• Restricciones en cuanto a tamaño de los proyectos
• Problemas derivados del fracaso de los proyectos ágiles. Si un proyecto ágil fracasa no hay documentación o hay muy poca; lo mismo ocurre con el diseño. La comprensión del sistema se queda en las mentes de los desarrolladores.

   

CONFERENCIA CIBETIC

En la primera conferencia que tuvimos la verdad fue bastante mala ya que fue una vídeo conferencia y tuvieron bastantes errores técnicos y lamentablemente no se entendió nada de lo que nos estaba comentando aunque creo que era una de las mas importantes de esa conferencia y por desgracia no entendí nada.

La segunda conferencia nos hablo de las redes que en la vida cotidiana son muy importantes en la actualidad . 

AUDITORIAS

PERFIL DE UN AUDITOR

Las características de un auditor constituyen uno de los temas de importancia en el proceso de realizar una auditoria dentro de una empresa, ya que en el recae la responsabilidad de practicarla y lograr los resultados necesarios para proponer las medidas necesarias para elevar el desempeño.

PROCESOS DE AUDITORIA

Documentos de solicitud

Después de notificar a la organización de la próxima auditoria, el auditor normalmente solicita los documentos que figuran en una lista de comprobación preliminar. Éstos pueden incluir una copia del informe de alguna auditoria anterior, las declaraciones bancarias originales, los recibos y libros de contabilidad. Además, el auditor puede solicitar cartas de la organización, junto con copias de las actas de la junta y del comité, así como copias de los estatutos y reglas permanentes.

Preparación de un plan de auditoría

El auditor consultará la información contenida en los documentos y planes para especificar la forma en que la auditoría se llevará a cabo. Un taller de riesgo puede llevarse a cabo para identificar posibles problemas. Un plan de auditoría se redactará en este momento.

Programar una reunión abierta

La alta gerencia y el personal administrativo clave serán invitados a una reunión abierta en la que se presentará el alcance de la auditoría por parte del auditor. Debe determinarse un marco de tiempo, así como cualquier otra cuestión que tenga que ver con este rubro, como el tema de las vacaciones programadas. Los jefes de departamento pueden informar al personal sobre las entrevistas con el auditor.

La realización de trabajo de campo

El auditor tomará la información que ha obtenido de la sesión pública y puede usarla para finalizar el plan de auditoría. El trabajo de campo se llevará a cabo con los miembros del personal, quienes deben revisar los procedimientos y procesos. El auditor verificará el cumplimiento de las políticas y procedimientos. Los controles internos deben ser evaluados para asegurarte de que sean adecuados. El auditor puede discutir los problemas que puedan surgir para dar a la organización una oportunidad de respuesta.

Redacción de un informe

El auditor debe preparar un informe que detalle los hallazgos de la auditoría. En el informe se incluyen los errores matemáticos, problemas contables y pagos autorizados, pero no así las deudas y otras discrepancias; deben enumerarse otras preocupaciones de la auditoría. El auditor entonces debe escribir un comentario que describa los hallazgos de la auditoría y las soluciones recomendadas para los problemas.

Configuración de una reunión de cierre

El auditor solicita una respuesta de la dirección que indique si está de acuerdo o en desacuerdo con los problemas descritos en el informe, una descripción del plan de acción de la administración para hacer frente al problema y una fecha de finalización prevista. En la sesión de clausura, todas las partes involucradas deben discutir el informe y las respuestas de la administración. Si hay algunos asuntos pendientes, deben resolverse en este punto.

                   

UTSJR Modelo DRA