Ir al contenido principal

Entradas

Diagramas de Actividad

Los diagramas que definen el comportamiento de un sistema son muy utilizados, entre los cuales se encuentran los de componentes, de secuencia, flujo de datos, entre otros. Pero existe uno un poco más sencillo y particular como lo es el diagrama de actividad. Los diagramas de actividad definen básicamente las diferentes actividades que componen un caso de uso determinado, dentro del diagrama se muestra el recorrido que toman las actividades con un punto de inicio y final, también el cómo se modifica su recorrido al momento en que se debe tomar decisiones, este diagrama permite mostrar las actividades que se ejecuten paralelamente. Al ser un diagrama UML se forma a partir de diferentes elementos o figuras como las siguientes: Punto Inicial: Este punto se representa mediante un circulo relleno (Negro). Actividad o Acción: Este elemento se representa como un ovalo o rectángulo con esquinas redondeadas. Flujo de control o Transición: Se representan con una línea y una flecha
Entradas recientes

UML

Existen muchos diagramas que se utilizan para representar proyectos, sistemas o en este caso software, como los diagramas de clases, diagramas de componentes, diagramas de casos de uso, entre otros, pero estos diagramas a la hora de elaborarlos se deben realizar con una serie de estándares o reglas y para eso está UML. UML son las siglas de Unified Modeling Language o Lenguaje Unificado de Modelado creado para establecer reglas sintácticas y semánticas para crear distintos modelados de software, sistemas, comportamiento de sistemas o movimiento de la información en un sistema entre muchos otros. Este lenguaje permite un mayor entendimiento de los proyectos tanto de los que se quieran desarrollar como los ya terminados. Por lo que es muy utilizado para las reuniones entre los desarrolladores de software, en este caso, con los clientes, pero también es una buena manera de comunicación entre los distintos equipos de desarrolladores. El UML ha sido adoptado a nivel mundial por muc

Diagramas de Flujo de Datos (DFD)

Existen diversos diagramas para representar un programa, partes de un programa, sus funcionalidades, diagramas de clases, diagrama de casos de uso, entre muchos otros, pero esta vez se detallarán los diagramas de flujo de datos que se centran en cómo se mueven los datos de un sistema. Los diagramas de flujo de datos brindan una representación de cómo se conforma un flujo de datos de un sistema (No necesariamente software) o proceso, describen que información almacenan, que datos reciben o envían diferentes entidades que forman parte del flujo de los datos dentro del sistema o proceso. La estructura en sí de los diagramas la conforman los siguientes componentes: Entidad: Son sistemas externos, como un usuario, otro sistema, una empresa, se podrían considerar como los actores en un diagrama de casos de uso. Las entidades son las que reciben y alimentan de información del flujo de datos. La entidad generalmente es representada con un rectángulo con el nombre en su interior. Alm

Aseguramiento de la calidad – (QA)

Un QA (Quality Assurance), del inglés aseguramiento de la calidad, es el encargado de realizar los procesos que comprueben que un producto cumple con las especificaciones y la calidad esperada por el cliente. Fuente El ingeniero en QA participa en todas las etapas del desarrollo y puede hacer distintas actividades como: ·          Diseñar casos de pruebas. ·          Verificar y validar los requerimientos del proyecto. ·          Descubre errores. ·          Genera Métricas. Hay que señalar que un QA no es un simple tester (puede realizar funciones), el ingeniero ofrece más que eso. Los roles que un ingeniero en QA puede ocupar pueden ser de Tester, diseñador de prueba, ingeniero en automatización, consultor, arquitecto etc. La metodología básica que sigue un QA en los proyectos es un ciclo con lo siguiente: ·          Planificación de Test ·          Especificación de Test ·          Ejecución de Test ·          Resultados de Test ·          Evaluación

Requerimientos Volátiles y Estables

Los requerimientos de un proyecto de software se pueden clasificar de formas distintas por ejemplo cuando identificamos los requisitos funcionales, no funcionales y los de información, pero también es posible clasificarlos de una forma distinta, más específicamente en volátiles y estables. Requerimientos Volátiles: Estos requisitos volátiles (Cambiantes) tienen una alta probabilidad de sufrir cambios durante el proceso de desarrollo del software, pero también pueden cambiar fuera de dicho proceso cuando el software está terminado o incluso cuando ya está en uso por parte del usuario. Estos requisitos tienen subclasificaciones ya que son muy diversos, los cuales son los siguientes. ·          Mutables: Reciben este nombre los requisitos que se ven afectados por cambios que puedan presentarse en el ambiente con el que opera la organización. ·          Emergentes: Estos aparecen cuando el proceso de diseño de los requerimientos, facilitan el entendimiento del sistema y le perm

Técnicas Prototipos - StoryBoards

La utilización de los prototipos en el proceso de desarrollo de un producto son cada vez más frecuentes, esto también aplica al desarrollo de software. Pero cómo podemos crearlos o presentarlos, a continuación explicaremos en qué consiste la técnicas StoryBoards. Los StoryBoards son un tipo de prototipos muy utilizados, consiste básicamente en ir mostrando en una secuencia de imágenes un proceso, acción o ejercicio que se puede realizar en el sistema una vez terminado, las imágenes van mostrando la evolución que va teniendo el sistema conforme el usuario interactúa con el sistema. Un forma muy común de ejemplificar los StoryBoards son con las revistas de cómics, ya que van mostrando una secuencia de imágenes en cuadros con un orden establecido que permiten entender la línea de la historia contada. Fuente Esta técnica es muy flexible económicamente hablando, ya que se pueden crear StoryBoards muy sencillos y baratos o por el contrario desarrollarlos de forma más sof

StakeHolders

La palabra stakeholders se utiliza para definir a las personas, grupo de personas o empresas que están interesados en un proyecto especifico, en nuestro caso un proyecto de software. El termino stakeholders se puede traducir como “interesados”, estos interesados son empresas o personas que tienen relación de alguna forma con el proyecto y no necesariamente trabajan en el. Algunos ejemplos son los siguientes: Empresas y Organizaciones: En algunos casos los proyectos necesitan de la aprobación de otras empresas u organizaciones para poder desarrollarlo, como financiamientos, seguros, aprobación de licencias etc. Usuarios: Son las personas a las cual va dirigido el proyecto, son los usuarios del programa informático en un proyecto de software, estas personas pueden estar de acuerdo o en desacuerdo con el proyecto. Afectados: Son personas u organizaciones que están indirectamente involucrados en el proyecto, y tampoco son el objetivo de los resultados del proyecto, p