Clase 25 Marzo 2021 Diagrama de actividades

 Diagrama de actividades 


En UML un diagrama de actividades se usa para mostrar la secuencia de actividades. Los diagramas de actividades muestran el flujo de trabajo desde el punto de inicio hasta el punto final detallando muchas de las rutas de decisiones que existen en el progreso de eventos contenidos en la actividad. Estos también pueden usarse para detallar situaciones donde el proceso paralelo puede ocurrir en la ejecución de algunas actividades. Los Diagramas de Actividades son útiles para el Modelado de Negocios donde se usan para detallar el proceso involucrado en las actividades de negocio.


Cuando usar un diagrama de actividad 

Estos diagramas son utilizados para describir cualquier tipo de procesos. Es especialmente común para modelar gráficamente los diferentes casos de uso, transacciones o procedimientos que haya en un sistema de información. En resumen, son utilizados para representar la forma en la que un sistema hace una implementación. La finalidad de este diagrama es modelar el workflow de una actividad a otra, pero sin tener en cuenta el paso de mensajes entre ellas. Para ello, estas actividades pueden dividirse en sistemas por lo que una finalidad (la más común) de este diagrama puede ser capturar estos sistemas y describir como se relacionan entre sí.

Las siguientes secciones describen los elementos que constituyen un diagrama de actividades.

Actividades

Una actividad es la especificación de una secuencia parametrizada de comportamiento. Una actividad muestra un rectángulo con las puntas redondeadas adjuntando todas las acciones, flujos de control y otros elementos que constituyen la actividad.



Acciones

Una acción representa un solo paso dentro de una actividad. Las acciones se 
denotan por rectángulos con las puntas redondeadas.



Restricciones de Acción

Las restricciones se pueden adjuntar a una acción. El siguiente diagrama muestra una acción con pre y post condiciones locales.


Flujo de Control

Un flujo de control muestra el flujo de control de una acción a otra. Su notación es una línea con una punta de flecha.



Nodo Inicial

Un nodo inicial o de comienzo se describe por un gran punto negro, como se muestra a continuación.



Nodo Final

Hay dos tipos de nodos finales: nodos finales de actividad y de flujo. El nodo final de actividad se describe como un círculo con un punto dentro del mismo

El nodo final de flujo se describe como un círculo con una cruz dentro del mismo.

La diferencia entre los dos tipos de nodos es que el nodo final del flujo denota el final de un solo flujo de control, y el nodo final de actividad denota el final de todos los flujos finales dentro de la actividad.

Nodos de Decisión y Combinación

Los nodos de decisión y combinación tienen la misma notación: una forma de diamante. Los dos se pueden nombrar. Los flujos de control que provienen de un nodo de decisión tendrán condiciones de guarda que permitirán el control para fluir si la condición de guarda se realiza. El siguiente diagrama muestra el uso de un nodo de decisión y un nodo de combinación.

Nodos de Bifurcación y Unión

Las bifurcaciones y uniones tienen la misma notación: tanto una barra horizontal como vertical (la orientación depende de si el flujo de control va de derecha a izquierda o hacia abajo y arriba. Estos indican el comienzo y final de hilos actuales de control. El siguiente diagrama muestra un ejemplo de su uso.

Una unión es diferente de una combinación ya que la unión sincroniza dos flujos de entrada y produce un solo flujo de salida. El flujo de salida desde una unión no se puede ejecutar hasta que todos los flujos se hayan recibido. Una combinación pasa cualquier flujo de control directamente a través de esta. Si dos o más flujos de entrada se reciben por un símbolo de combinación, la acción a la que el flujo de salida apunta se ejecuta dos o más veces.




Informacion tomada de : http://www.sparxsystems.com.ar/resources/tutorial/uml2_activitydiagram.php

Clase 23 Marzo 2021 Ingeniería de requerimientos y casos de uso

 Ingeniería de requerimientos


El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema de software es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos es entregar una especificación de requerimientos de software correcta y completa. La ingeniería de requerimientos apunta a mejorar la forma en que comprendemos y definimos sistemas de software complejos. 






El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones



CLASIFICACIÓN DE LOS REQUERIMIENTOS 



    CASOS DE USO 


El diagrama de casos de uso es una forma de diagrama de comportamiento en lenguaje de modelado unificado (UML, del inglés Unified Modelling Language), con la que se representan procesos empresariales, así como sistemas y procesos de programación orientada a objetos. Por lo tanto, UML no es un lenguaje de programación, sino un lenguaje de modelado, es decir, un método estandarizado para representar sistemas planificados o ya existentes. En este diagrama, todos los objetos involucrados se estructuran y se relacionan entre sí.

Elementos y estructura del diagrama de casos de uso 


Para garantizar que el diagrama de casos de uso sea comprensible para todo el mundo de un vistazo, se utilizan elementos estandarizados para elaborarlo. En primer lugar, hay tres elementos principales: 

Actor: tanto si es una persona, como un sistema, se representa con el dibujo de una figura humana esquemática. 

Sistema: el sistema al que se refiere el caso de uso tiene forma de rectángulo. 

Caso de uso: se muestra como una elipse que suele incluir un texto describiendo brevemente el proceso.


ASOCIACION

La relación entre estos elementos se representa con unas líneas de conexión llamadas asociaciones. Una línea recta entre el actor y el caso de uso evidencia que el actor y el caso de uso descrito en la elipse están relacionados. Una línea discontinua establece una relación entre diferentes casos de uso









Clase 18 Marzo 2021 Requerimientos

 REQUERIMIENTOS


La primera tarea de la etapa de análisis de requisitos es identificar y expresar los requisitos. Aunque esto pueda parecer una tarea fácil o trivial, por lo general es fuente de muchos errores, omisiones y conflictos. En forma mínima, esta tarea traduce estos objetivos en un esquema de requerimientos funcionales y no funcionales que se necesitarán para cumplir con los objetivos. 

Requerimientos Funcionales 

Los requisitos funcionales son declaraciones de los servicios que prestará el sistema, en la forma en que reaccionará a determinados insumos. Cuando hablamos de las entradas, no necesariamente hablamos sólo de las entradas de los usuarios. Pueden ser interacciones con otros sistemas, respuestas automáticas, procesos predefinidos. En algunos casos, los requisitos funcionales de los sistemas también establecen explícitamente lo que el sistema no debe hacer. Es importante recordar esto: un RF puede ser también una declaración negativa. Siempre y cuando el resultado de su comportamiento sea una respuesta funcional al usuario o a otro sistema, es correcto. Y más aún, no sólo es correcto, sino que es necesario definirlo. Y eso nos lleva al siguiente punto.

Los requerimientos funcionales son frecuentemente identificados en términos de entradas, salidas, procesos y datos almacenados que son necesarios para satisfacer los objetivos de mejora del sistema.

Requerimientos No Funcionales 

Se trata de requisitos que no se refieren directamente a las funciones específicas suministradas por el sistema (características de usuario), sino a las propiedades del sistema: rendimiento, seguridad, disponibilidad. En palabras más sencillas, no hablan de “lo que” hace el sistema, sino de “cómo” lo hace. Alternativamente, definen restricciones del sistema tales como la capacidad de los dispositivos de entrada/salida y la representación de los datos utilizados en la interfaz del sistema.

Ejemplos de requerimientos no funcionales incluyen desempeño (tiempo de desempeño y de respuesta); facilidad de aprendizaje y uso; presupuestos, costos y ahorros de costos; cronogramas y vencimientos; documentación y necesidades de capacitación; administración de la calidad y controles de auditoria interna y seguridad.

Rara vez esta tarea de definición identifica todos los requerimientos de negocios funcionales y no funcionales. Pero este esquema enmarcará su pensamiento mientras procede con tareas posteriores que agregarán nuevos requerimientos y detalles al mismo. Por tanto, ni la totalidad ni la perfección son una meta en esta tarea.

Bibliografia

Libro Análisis de sistemas: Diseño y métodos, 7ma Edición Mc Graw Hill


Clase 11 Marzo 2021 Roles en el desarrollo de un proyecto de software

 Roles en el desarrollo de un proyecto de software


Un equipo de desarrollo de software consta de muchas personas con diferentes roles y, por lo tanto, diferentes habilidades. Es la contribución de estas capacidades lo que condujo a la realización del objetivo.

Gerente de proyecto 

Es el responsable de definir el proyecto y asignarle recursos. Apoya las tareas de estimación y definición de las actividades contenidas en el plan, y las revisa y aprueba.

Cliente

Puede pensar que es extraño pensar en el cliente como parte del equipo de desarrollo, pero en realidad no es el caso: como cualquier otro miembro del equipo, el cliente es un factor importante en el éxito del proyecto. Es importante conseguir que los clientes participen activamente en el proyecto.

Analista 

El analista es la persona responsable de comprender las necesidades del cliente y garantizar que la solución desarrollada satisfaga estas necesidades.
 
Diseñador 

Es el responsable de crear un concepto de sistema que ayude a cumplir con los objetivos comerciales marcados por las partes relevantes y asegurar que el sitio cumpla con las características de accesibilidad, navegabilidad, interactividad y usabilidad, brindando así una grata experiencia a los usuarios.

Arquitecto de software 

Es una persona que tiene suficiente conocimiento técnico de productos o servicios y puede buscar su aplicación técnica de acuerdo a las necesidades de los clientes. Su tarea es la de crear un documento (junto con el analista de software) que recopile los requisitos durante todo el proceso de desarrollo, y le corresponde a él enfocar las decisiones técnicas en los problemas que van a surgir. 

Desarrollador de software 

El desarrollador de software será la persona que reciba los documentos creados por los arquitectos y analistas e implemente el producto en base a ellos.


Programador 

Es responsable de convertir las especificaciones del sistema en código. Aunque los desarrolladores también pueden "escribir código", los programadores se dedican a esto. Esta persona debe conocer diferentes lenguajes de programación. Además, es responsable de depurar errores, implementar nuevas funciones o mantener la aplicación cuando sea necesario.

Responsable de las pruebas  (tester)

Esta persona es responsable de asegurar que los requisitos funcionales establecidos por el producto se cumplan mediante la planificación y ejecución de pruebas de todo el software construido, y que el producto esté libre de averías. Es el responsable de aprobar productos o aplicaciones que se pueden pasar al entorno de producción, y su responsabilidad es tan grande que el éxito del proyecto juega un papel en ello.


Bibliografia

Grupo, I. S. S. I. (2003). Metodologías ágiles en el desarrollo de software. VIII Jornadas de Ingeniería del Software y Bases de Datos.

Clase 09 Marzo 2021 Fases de un proyecto.

 FASES DE UN PROYECTO



1. Identificación del proyecto.

La identificación es la primera fase del ciclo de vida del proyecto. Aquí es donde se mide el valor y la viabilidad del proyecto. Los gerentes suelen utilizar dos herramientas de evaluación para decidir si quieren o no llevar a cabo un proyecto.El plan de negocio y el estudio de factibilidad.

2. Planificación del proyecto.

El plan del proyecto proporciona al equipo dirección para producir productos de calidad, manejar el riesgo, crear aceptación, comunicar los beneficios a las partes interesadas y administrar los proveedores.

3. Ejecución del proyecto.

Esta es la fase más comúnmente asociada con la gestión de proyectos. La ejecución se basa en la construcción de entregables que satisfacen al cliente. La ejecución depende en gran medida de la fase de planificación. El trabajo y los esfuerzos del equipo durante la fase de ejecución se derivan del plan del proyecto.

4. Seguimiento del Proyecto.

La supervisión y el control a veces se combinan con la ejecución porque a menudo ocurren al mismo tiempo. A medida que los equipos ejecutan su plan de proyecto, deben monitorizar constantemente su propio progreso, con el fin de garantizar las fechas de entrega de lo que se prometió.

5. Cierre del proyecto.

Los equipos cierran un proyecto cuando entregan el proyecto terminado al cliente. Hay que comunicar la finalización a los interesados y liberar recursos para otros proyectos. Este paso vital en el ciclo de vida del proyecto permite al equipo evaluar y documentar el proyecto y avanzar en el siguiente, utilizando los errores y éxitos del proyecto anterior para construir procesos más fuertes y equipos más exitosos.

ALCANCE DE UN PROYECTO

El alcance de un proyecto incluye todo el trabajo necesario para realizar el proyecto y todo lo que se requiere para que ese trabajo se completado satisfactoriamente. En definitiva, el alcance define qué se incluye y qué no se incluye en el proyecto. Por lo tanto, la correcta gestión del alcance del proyecto conduce al cumplimiento de las expectativas y al éxito del mismo.






Clase 04 Marzo 2021 Ciclo de vida de un proyecto de software y tipos de sistemas

 CICLO DE VIDA DE UN PROYECTO DE SOFTWARE


El ciclo de vida del desarrollo de software (también conocido como SDLC o systems Development Life Cycle) incluye las fases necesarias para verificar el desarrollo del software, a fin de garantizar que cumpla con los requisitos de verificación del programa de desarrollo y aplicación, asegurando así que el método que se utilice, sea implementado de manera adecuada.


En el ciclo de vida de una aplicación, el orden y la existencia de cada proceso depende del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrollo.



CLASIFICACIÓN DE LOS SISTEMAS DE INFORMACIÓN





NIVELES DE UNA ORGANIZACIÓN




CUADRO COMPARATIVO


COMPARACIÓN ENTRE SAP, ERP Y CRM 



















Clase 02 Marzo 2021 Introduccion

 INTRODUCCIÓN AL CURSO 

Los sistemas de información (SI) en la organización capturan y gestionan datos para generar información útil que apoye a la organización, los empleados, clientes, proveedores y socios. Muchas organizaciones piensan que los sistemas de información son esenciales para su capacidad para competir o adquirir alguna ventaja competitiva. La mayoría de las organizaciones se han dado cuenta que los trabajadores deben participar en el desarrollo de sistemas de información con el fin de lograr hacerlo los mas optimo posible. El desarrollo de sistemas de información es un tema relevante , ya sea que desee o no convertirse en un profesional en el desarrollo de sistemas de información.


'Imagen tomada del libro Análisis de sistemas, 7ma Edición '