Anuncio

¿Qué es la Ingeniería de Sistemas?

Es el conjunto de recursos humanos y materiales a través de los cuales se recolectan, almacenan, recuperan, procesan y comunican datos e información con el objetivo de lograr una gestión eficiente de las operaciones de una organización.








lunes, 26 de diciembre de 2011

Desarrollo y Gestión de Requerimientos Parte I

En el presente post explicarè el còmo elaborar los diferentes documentos del curso de Desarrollo y Gestiòn de Requerimientos de la Universidad Peruana de Ciencias Aplicadas referente al ciclo 2011-1.

En el mencionado curso, se elaboran una serie de documentos relacionados con la tecnologìa RUP. Para esto necesitaremos instalarnos el Rational Requisite Pro y el Rational Rose. Queda claro que no colocarè ningun link para descargar estos programas puesto infrigirìa las leyes de Blogger.

El primer paso serà evaluar el problema, unas preguntas simples pero muy utiles son:

¿Què necesita el cliente?

¿Què espera tener el cliente?

¿Cual es la extensiòn del proyecto?

La ùltima pregunta, la cual conlleva a la extensiòn del proyecto es tener en claro que le vamos a entregar al cliente y que espera èl del proyecto.

Ahora les voy como se hace cada rùbrica en el Rational Requisite Pro. Como es idòneo creamos un proyecto TOTALMENTE EN BLANCO esto nos sirve para poder crear nosotros mismos nuestros requerimientos y nuestros documentos, ya sea importando plantillas o eligiendo las que estàn por defecto en la tecnologìa RUP.

Luego procedemos a darle clic en Blank:

Ponemos el nombre del proyecto, elegimos el directorio donde se guardarà. Para este curso no tendremos que usar una base de datos especial por tanto dejamos la opciòn como MS Access y agregamos una pequeña descripción.

Curioseando poco a poco podràn darse cuenta que posee una interfaz no tan agradable a simple vista pero su uso es muy intuitivo y con un conocimiento bajo de inglès podràn elaborar cualquier proyecto con este programa. Ahora les explicarè tan solo unas cuantas opciones ùtiles para este curso ya sea crear: un package, un documento, una vista y sobre todo un requerimiento.

Creaciòn de un Package:

Le damos clic izquierdo al proyecto ene ste caso “Proyecto de prueba Blog INFOSISTEMASUPC”, luego clic en New y finalmente Package.

Luego llenamos los valores, con Nombre de la carpeta, la descripciòn y sobre todo el Parent Package, este parent package es la carpeta (o proyecto) que incluirà a la nueva carpeta. Por defecto aparece llenada con la carpeta a la cual le dimos clic izquierdo.

Finalmente, clic en aceptar y observaremos como està creada y con una lìnea punteada que refleja parentesco.


Creaciòn de un Requerimiento:

Para crear un nuevo requerimiento es necesario CREAR EL TIPO DE REQUERIMIENTO ANTES.

Clic izquierdo en el Proyecto, luego clic en Properties.

Luego clic en la pestaña de Requirement Types. Y clic en Add...

Luego llenamos los valores con el nombre de requerimiento, la drescripciòn dejamos en 1 el Initial Requirement #, El Tag Prefix tendremos en cuenta cual sea el tipo de requerimiento que se va a crear, puesto que para seguir los estàndares algunos ya tienen un prefijo establecido. El color del requerimiento es indispensable pero uds. podràn elegir cual a su gusto y el estilo del requerimiento tambièn (Les recomiendo el Double Underline).

Clic en Ok ye tendremos creado nuestro TIPO DE REQUERIMIENTO, nos sigue crear el requerimiento como tal.

Pare crear el Requerimiento como tal, clic izquierdo en el proyecto, luego New y luego Requirement.

Elegimos el tipo de requerimiento ya creado, llenamos los valores y luego le damos clic en OK.

Finalmente observaremos en la interfaz principal del proyecto como aparece, cabe resaltar que podremos crear una carpeta para colocar dentro los requerimientos de forma que se vea mas ordenado.


Creaciòn de un documento:

Lo primero es crear el TIPO DE DOCUMENTO.

Luego le damos clic en la pestaña Document Types, y luego clic en Add...

Llenamos los valores con el nombre del documento, la descripcion, como ya mencione con anterioridad el File extension es importante al igual que en los requerimientos ya que debemos seguir los estàndares para que nuestro trabajo pueda ser entendido por cualquier profesional de la carrera. Los estàndares para los documentos estàn en google tan sòlo busquen: File extension RUP documents y los obtendràn.

Tambièn cabe resaltar que hay documentos que no estaràn disponibles y para eso tendràn que importar plantillas, cuyos pasos estaràn al final del presente documento.

Clic en Ok y tendremos nuestro tipo de Documento listo para ser CREADO.

Clic en el proyecto, clic en New, clic en document y nos aparecerà la siguiente interfaz:

Una vez que llenemos los valores elegimos el Document Type y estarà el que creamos pasos atràs, Clic en OK y se nos abrirà el documento en WORD.

Cerramos el documento, y lo veremos asì en nuestra interfaz principal del Rational Requisite Pro.

Creaciòn de una Vista:

Las vistas nos sirven mas que todo para realizar la Matriz de trazabilidad entre los requerimientos, tema que les serà explicado mas o menos a la mitad del curso. Les seràn de utilidad segùn estèn avanzando y les recomiendo que las vayan aprendiendo a usar puesto que al final necesitaran de ellas para realizar el documento especificaciòn de casos de uso.

Llenamos los valores de la vista, y lo mas relevante aquì es elegir el TIPO DE VISTA, pues elegimos Traceability Matrix y abajo como sòlo hemos creado un sòlo tipo de requerimientos el cruce serà entre este mismo, pero cabe resaltar que el cruce puede ser de tipos de requerimientos variados.

Clic en OK y observaremos en la interfaz principal:

Una vez llenemos de requerimientos y creemos los documentos esto nos quedarà genial.

Ahora lo prometido es deuda, les voy a enseñar como se importan plantillas de documentos, esto lo usaràn al final del curso, tendran que conseguirse la plantilla del documento Especificaciòn de casos de uso, puesto no està integrado en el RUP.

Clic en Properties, luego clic en la pestaña Document Types, clic en Add... Y aparecerà esta interfaz:

Cabe resaltar que en el OUTLINE no elegimos ningun documento como base, lo dejamos en none.

Una vez llenados los datos, clic en Ok y ya tendremos creado nuestro TIPO DE DOCUMENTO EN BLANCO.

Clic en el proyecto, clic en New, clic en Document, y elegimos el tipo Documento Importado 1 y clic en OK.

Finalmente, copiamos y pegamos la estructura del documento que deseemos dentro del WORD y comenzamos a trabajar.


Bueno, esto ha sido todo en este primer post sobre el grandioso curso de Desarrollo y Gestiòn de Requerimientos enseñado en la UPC, este modelo lo utilicè durante el ciclo 2011-1. Les doy las gracias a todos nuestros lectores y sobre todo a aquellos que ayudan a crecer a este blog. Conmigo serà hasta la pròxima oportunidad, sigan visitando y recomendando este blog pues se esperan nuevas mejoras.

miércoles, 31 de agosto de 2011

HEMOS VUELTO!

HOLA A TODOS

NO CONTÁBAMOS CON LA GRAN ACOGIDA QUE PODÍA LLEGAR A TENER ESTE INTERESANTE BLOG. EN VERDAD ESTO OCURRIÓ A RAZÓN DE UN TRABAJO QUE NOS ASIGNARON EN UN CURSO LLAMADO INTRODUCCIÓN A LA COMPUTACIÓN.

MAS BIEN NOS ALEGRA VER QUE LE HAYA SERVIDO A MUCHA GENTE Y POR ENDE VAMOS A SEGUIR PUBLICANDO COSAS DE SU INTERÉS DESDE LAS METODOLOGÍAS DE DISEÑO DE SOFTWARE HASTA ENSEÑANZA DE PROGRAMACIÓN.

SALUDOS CORDIALES,

EL STAFF DE INGENIERÍA DE SISTEMAS.

domingo, 6 de junio de 2010

Trabajo Sobre Modelación de Procesos

1. Investigue que lenguajes o notaciones existen en el medio para graficar un proceso de Negocio. Haga un resumen de por lo menos 3 notaciones.



En la actualidad se han creado una gran cantidad de notaciones para graficar un proceso de Negocio. En este trabajo se explicará tres de ellas, de las cuales usaremos sólo una para explicarla detalladamente.


En primer lugar, el Lenguaje Unificado de Modelado UML, en ingles, es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Durante los ochenta y principios de los noventa Grady Booch, James Rumbaugh, e Ivar Jacobson trabajaban por separado en desarrollo de notaciones para el análisis y diseño de sistemas orientados a objetos. Los tres llegaron por separado a obtener bastante reconocimiento.


A mediados de los noventa empezaron a intercambiar documentos y trabajar en conjunto produciendo grandes avances en el modelado de sistemas orientados a objetos.En 1994 Rational contrató a Rumbaugh en donde ya trabajaba Booch, un año después Jacobson se unía a ellos en Rational. Finalmente, en 1997 salió a la luz la versión 1.0 de UML.

En segundo lugar, el Business Process Modeling Notation o BPMN es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo (workflow). BPMN fue inicialmente desarrollada por la organización Business Process Management Initiative (BPMI), y es actualmente mantenida por el OMG (Object Management Group), luego de la fusión de las dos organizaciones en el año 2005. Su versión actual es la 1.2 y hay una versión futura propuesta, la 2.0.


Su principal objetivo es proveer una notación estándar que sea fácilmente leíble y entendible por parte de todos los involucrados e interesados del negocio (stakeholders). Entre estos interesados están los analistas de negocio, los desarrolladores técnicos y los gerentes y administradores del negocio. En síntesis, BPMN tiene la finalidad de servir como lenguaje común para cerrar la brecha de comunicación que frecuentemente se presenta entre el diseño de los procesos de negocio y su implementación.


Finalmente, diagrama de flujo de datos o DFD es una representación gráfica del "flujo" de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos. Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas. Este contexto a nivel de DFD se "explotó" para mostrar más detalles del sistema que se está modelando.


Componentes de los DFD:


• PROCESOS (burbujas): representan la parte del sistema que transforma ciertas entradas en ciertas salidas.

• FLUJOS: representan los datos en movimiento. Pueden ser flujos de entrada o flujos de salida. Los flujos conectan procesos entre sí y también almacenes con procesos.

• ALMACENES: representan datos almacenados. Pueden ser una base de datos, un archivo físico, etc.

• TERMINADORES: representan entidades externas que se comunican con el sistema. Esas entidades pueden ser personas, organizaciones u otros sistemas, pero no pertenecen al sistema que se está modelando.


Existen procesos y flujos especiales llamados procesos de control y flujos de control. Se emplean para modelar sistemas en tiempo real.


Los flujos de control son señales o interrupciones, en tanto los procesos de control son burbujas que coordinan y sincronizan otros procesos. Los procesos de control sólo se conectan con flujos de control.


Los flujos de control de salida "despiertan" otras burbujas, en tanto los flujos de control de entrada, especifican que una tarea terminó o se presentó un evento extraordinario.

 
Informacion obtenida de:


http://es.wikipedia.org/wiki/UML

http://www.ingenierosoftware.com/analisisydiseno/uml.php

http://es.wikipedia.org/wiki/BPMN

http://www.alegsa.com.ar/Dic/diagrama%20de%20flujo%20de%20datos.php

http://es.wikipedia.org/wiki/Diagrama_de_Flujo_de_Datos




 2. De UNA de las notaciones o lenguajes escogidos, explique cómo funciona (por ejemplo la cantidad de niveles que tiene) y que elementos utiliza para graficar un proceso. Haga una breve descripción de los principales elementos.


A continuación, hablaremos del tipo de notación UML.


En UML 2.0 existen 13 tipos de diagramas diferentes. Separados de la siguiente manera para una mayor compresión:


Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:


• Diagrama de clases

• Diagrama de componentes

• Diagrama de objetos

• Diagrama de estructura compuesta (UML 2.0)

• Diagrama de despliegue

• Diagrama de paquetes


Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:


• Diagrama de actividades

• Diagrama de casos de uso

• Diagrama de estados

• Diagrama de secuencia

 
Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:


• Diagrama de secuencia

• Diagrama de comunicación, que es una versión simplificada del Diagrama de colaboración (UML 1.x)

• Diagrama de tiempos (UML 2.0)

• Diagrama global de interacciones o Diagrama de vista de interacción
 Nosotros hemos empleado el diagrama de actividades conformado por algunos del siguiente elemento:


1- Nodo inicial: Es un punto negro que describe el inicio del proceso.

2- 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.

3- Actividad: Las acciones se denotan por rectángulos con las puntas redondeadas y representa un solo paso dentro de una actividad.

4- Decisión: Los flujos de control que provienen de un nodo de decisión. Su notación es un rombo.Tendrán condiciones de guarda que permitirán el control para fluir si la condición de guarda se realiza o no.

5- Nodo final: Marca el final de la actividad y se describe como un círculo con un punto dentro del mismo


Y otros elementos no visibles en la imagen como:


6- Bifurcación y unión: Indican el comienzo y final de hilos (acciones al mismo tiempo) actuales de control



Informacion obtenida de:
Imagen 1 tomada de:
http://es.wikipedia.org/wiki/Archivo:For-loop-diagram.png

Imagen 2 y 3 tomadas de:
http://www.scribd.com/doc/23197639/diagrama-de-actividades


3. Con el lenguaje o notación seleccionado grafique 3 procesos de una empresa a la cual pueda tener acceso.









PARA VER EL ARCHIVO: http://www.megaupload.com/?d=3IWPHMIV EN WORD 2003
                                             http://www.megaupload.com/?d=NJWLAFD2 EN WORD 2007

¿Qué es un UML?

El lenguaje Unificado de Modelado o UML, en inglés, es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrese un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Fuentes: http://es.wikipedia.org/wiki/UML (consulta: 6 de junio del 2010)

¿Qué es un BPMN?

Business Process Modeling Notation o BPMN (en español Notación para el Modelado de Procesos de Negocio) es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo (workflow).
El principal objetivo de BPMN es proveer una notación estándar que sea fácilmente legible y entendible por parte de todos los involucrados e interesados del negocio (stakeholders).
BPMN fue inicialmente desarrollada por la organización Business Process Management Initiate (BPMI), y es actualmente mantenida por el OMG (Object Management Group).
Fuentes: Wikipedia 2010. Sitio web con información histórica, educativa entre otras. (http://es.wikipedia.org/wiki/BPMN) (consulta: 6 de junio del 2010)

¿Qué es un diagrama de flujo de datos?

Un diagrama de flujo de datos (DFD por sus siglas en español e inglés) es una representación gráfica del "flujo" de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado).
Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas. Este contexto a nivel de DFD se "explotó" para mostrar más detalles del sistema que se está modelando.

Este posee 3 niveles:
NIVEL 0: Diagrama de contexto.
NIVEL 1: Diagrama de nivel superior.
NIVEL 2: Diagrama de detalle o expansión.

El inventor del diagrama de flujo de datos fue Larry Constantine, basándose en el modelo de computación de Martin y Estrin el cual era llamado "flujo gráfico de datos".

Fuentes: Wikipedia 2010. Sitio web con información histórica, educativa entre otras. (http://es.wikipedia.org/wiki/Diagrama_de_Flujo_de_Datos) (consulta: 6 de junio del 2010)

martes, 27 de abril de 2010

Video: Historia de la Informática


Fuente: http://www.youtube.com/watch?v=8AlRo8fKg5Q


En este video podremos observar la breve historia y cronología de la informática mediante imágenes, narradas con el programa de voz sintética loquendo.