Cursos gratuitos de Ingeniería Informática

Googleando me encuentro con una web bastante interesante y que tiene muchos recursos gratuitos para educación que pertenecen a la Universidad Carlos III de Madrid.
Permite descargarte todo el curso entres presentaciones, pdf, exámenes y ejercicios muy bueno la página y muy útil por los recursos que aporta, lo recomiendo :) me baje unos unos cuantos y ya les estoy echando el ojo o.O :)

A continuación lo que podemos encontrar:

Accesibilidad Universal (2012)

Algorithms and Data Structures (2011)

Aprendizaje Automático (2009)

Aprendizaje Automático para el Análisis de Datos (2013)

Arquitectura de Computadores II (2012)

Automated Planning (2008)

Components Based Software Design (2010)

Computación Biológica (2010)

Computer Structure (2011)

Desarrollo de Aplicaciones Distribuidas (2012)

Desarrollo de Sistemas de Información Corporativos (2008)

Desarrollo de Sistemas de Información Corporativos (2012)

Diseño Basado en Componentes (2009)

Diseño de Bases de Datos (2008)

Diseño de Software Avanzado (2010)

Diseño y Administración de Bases de Datos (2008)

Estructura de Computadores (2010)

Evitando las Barreras de Accesibilidad en la Sociedad de la Información (2011)

Ficheros (2008)

Ficheros y Bases de Datos (2008)

Fundamentos de las Bases de Datos (2008)

Fundamentos de las Bases de Datos (2012)

Herramientas de la Inteligencia Artificial (2010)

Information Engineering (2010)

Informática (2011)

Informática de Gestión (2009)

Ingeniera del Software III (2008)

Ingeniería de la Información (2010)

Inteligencia Artificial (2) (2009)

Inteligencia Artificial (2008)

Interfaces de Usuario (2009)

Language Processors (2012)

Metodología de Desarrollo Visual (2012)

Métodos y Técnicas de Trabajo Corporativo (2008)

Planificación Automática (2008)

Principios de Ingeniería Informática (2012)

Programación Automática (2013)

Programación en Lenguaje C (2013)

Programación en Lenguaje Java (2008)

Programming in C Language (2013)

Programming in Java Language (2011)

Recuperación y Acceso a la Información (2010)

Redes de Neuronas Artificiales (2011)

Secure Electronic Commerce (2010)

Security Engineering (2012)

Seguridad en Sistemas Distribuidos (2009)

Sistemas Avanzados de Recuperación de Información (2009)

Sistemas Distribuidos (2013)

Teoría de Autómatas y Lenguajes Formales (2012)

Estos cursos se encuentran bajo Creative Commons License o.O
La web es http://ocw.uc3m.es/ingenieria-informatica

continue reading

Scrumy - Herramienta online para gestionar proyectos

Scrumy es una herramienta online con forma de pizarra bastante sencilla de usar y aprender, pero no por eso deja de ser una poderosa herramienta para gestionar nuestros proyectos.

Tienes la posibilidad de crear un proyecto de forma gratuita o si tienes la posibilidad de soltar unos dolares, también cuenta con un gestor profesional.

Scrumy se basa en parte en Scrum y en la tabla Kanban para organizar el espacio de trabajo, se pueden crear las Historias de Usuario que se deseen y estas a su vez se subdividen en "tareas" las cuales se asignan a una persona para su ejecución, a su vez cada columna de la tabla indica que progreso tiene una tarea, tenemos "to do" "POR HACER", "In Progress" "EN PROGRESO", "Verify" "VERIFICACIÓN" o testeo de la tarea concluida para encontrar errores y por ultimo la columna "done" o "TAREA CONCLUIDA"

Sitio Web: http://www.scrumy.com/

continue reading

Procesos del Software

¿Qué es un modelo de procesos del software?

 3094x2457

Clic para ampliar

Modelos del proceso del software

• El modelo en cascada
• Desarrollo evolutivo
• Ingeniería del software basada en componentes

Iteración de procesos

• Entrega incremental
• Desarrollo en espiral

El Proceso Unificado de Rational

continue reading

ROI: Retorno de la Inversión

¿Que es el ROI?

Es el beneficio que obtenemos por cada unidad monetaria invertida en tecnologías de información (TI) durante un periodo de tiempo.

Se utiliza para analizar la viabilidad de un proyecto y medir su éxito. En épocas de crisis, se convierte en una herramienta fundamental para que cada centavo invertido en tecnología regrese a ser posible acompañado de más.

Ecuación estándar del ROI

Ventajas:

• Simplicidad de su cálculo.
• Mayormente aplicable por organizaciones funcionales e industriales.
• Es un primer paso para estimar la recuperación de la inversión en un proyecto sin usar recursos considerables.
• Permite que los encargados identifiquen y que entiendan mejor las funciones del proyecto, las dependencias y su impacto total en el ROI.

Desventajas:

• El cálculo del ROI no considera el valor del dinero en el tiempo. (1 $ hoy, no es igual a 1 $ mañana).
• No considera el riesgo asociado a un proyecto o a una inversión.
• La ecuación favorece ahorros a corto plazo y pasa por alto costes a largo plazo tales como mantenimiento, ayuda y mejoras. 

Ejemplo:

Calcular el ROI a un año para un proyecto de software que tiene las siguientes caracteristicas

a- Costos de desarrollo ...............................1500 bs.
b- Costo de instalacion ................................200 bs.
c- Costo de capacitacion .............................250 bs.
d- Costo de migracion de datos ...................150 bs.
e- Gastos evitados (1er periodo) .................800 bs.
f- Ingresos mejorados (1er periodo) ..........1500 bs.
g- Reduccion de gastos ...............................400 bs.
h- Costos de operaciones ...........................500 bs.

Solución:

Separando entre los ingresos del primer año y los costos de la inversion, tenemos

Inversión incisos a,b,c,d tenemos:

1500 + 200 + 250 + 150 = 2100

Ingresos incisos e,f,g,h tenemos:

800+1500+400+(-500) = 2200

Aplicando la formula ROI:

ROI = ((2200-2100)/2100)*100% = 4,76%

¿Que quiere decir este 4,76%?

Si el ROI es menor o igual a cero, significa que el proyecto NO ES RENTABLE, mientras mayor sea el ROI que se obtiene, MAYOR ES LA RENTABILIDAD DEL PROYECTO, por tanto en nuestro ejemplo no ingresamos en perdida ya que obtuvimos ganancias y recuperamos nuestra inversión, pero nuestra rentabilidad es demasiado baja, esto es normal en el primer periodo, pero si se continua con esa tendencia en los siguientes periodos, el proyecto no sera rentable.

continue reading

Ingenieria del Software, Ian Sommerville 7 Edición en Español [NO ESCANEADO]

Buscando por muchos lugares al fin encontre el libro de Ian Somerville "Ingenieria del Software" 7 edición en Español, pero lo bueno es que este libro, NO ESTA ESCANEADO, asi que aparte de que el libro puede leerse mucho mas facilmente, porque no es pesado, se pueden realizar busquedas de texto cosa que no se puede con las otras versiones escaneadas del libro que circulan por la red

 Prueba para que se vea que se puede seleccionar texto XD

INDICE

Parte I. VISIÓN GENERAL 1
1. Introducción
2. Sistemas socio-técnicos
3. Sistemas críticos
4. Procesos del software
5. Gestión de proyectos

Parte II. REQUERIMIENTOS
6. Requerimientos del software
7. Procesos de la ingeniería de requerimientos
8. Modelos del sistema
9. Especificación de sistemas críticos
10. Especificación formal

Parte III. DISEÑO
11. Diseño arquitectónico
12. Arquitecturas de sistemas distribuidos
13. Arquitecturas de aplicaciones
14. Diseño orientado a objetos
15. Diseño de software de tiempo real
16. Diseño de interfaces de usuario

Parte IV. DESARROLLO
17. Desarrollo
18. Reutilización del software
19. Ingeniería del software basada en componentes
20. Desarrollo de sistemas críticos
21. Evolución del software

Parte V. VERIFICACIÓN Y VALIDACIÓN
22. Verificación y validación
23. Pruebas del software
24. Validación de sistemas críticos

Parte V I . GESTIÓN DE PERSONAL
25. Gestión de personal
26. Estimación de costes del software
27. Gestión de calidad
28. Mejora de procesos
29. Gestión de configuraciones

Sin más aqui el enlace de descarga, no pesa nada

continue reading

Ingenieria de Software (Proceso Básico)

Ingeniería de software es la disciplina o área de la informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad.

Productos de CALIDAD a un MONTO ECONOMICO en el TIEMPO OPORTUNO

Ingenieria de Software (Proceso Básico)

Se debe tomar en cuenta:

Disciplina: Se refiere a respetar "normas de desarrollo" (Métodos), esto nos permite que el proyecto sea "entendible" por cualquier otra persona (ingeniero de software) que necesite darle "mantenimiento" en cualquier momento

Sistemático: Dividir el proyecto en partes mas pequeñas de manejar de acuerdo a un metodo de desarrollo (Ciclo de Vida)

Medición: Quiere decir, tomarse el trabajo para realizar un control sobre el "tiempo de desarrollo", "calidad del software", etc.

Variables a Considerar:

Costo: Tratar de no sobrepasar el dinero que se tenga presupuestado, si es un proyecto independiente, conseguir nuevos auspiciadores retarda el proceso de desarrollo y si es un proyecto a pedido, gastar más dinero del asignado por el cliente, causa molestias en estos y aleja a nuevos clientes.

Tiempo: Controlar el tiempo desarrollo, la mayoria de los clientes quiere resultados inmediatos, pero esto no debe poner en riesgo la calidad del software
Capacidad: Se refiere a las exigencias impuestas por el cliente (Un procesador de texto, una Web Comercial, Gestion de Base de Datos, etc), se debe tratar de cumplir con todos estas exigencias con la menor cantidad de errores en el menor tiempo posible.
Calidad: La calidad de un sofware, se mide primeramente de acuerdo a "su desarrollo" y luego en su "uso" por parte del cliente final.

continue reading

Mapeamiento de clases

En el ejemplo se tiene un "modelo de clases" de un colegio "XYZ" esta simplificado ya que de lo que trata este tutorial es de explicar con un ejemplo el mapeamiento de clases persistentes a un modelo relacional.

Cuando diseñamos nuestro modelo de clases  y llega el momento de pasar las clases persistentes a un modelo de base de datos relacional, tenemos que seguir unas cuantas reglas:

• Cada clase corresponde a una tabla, una clases = una tabla.
• Un atributo primitivo (nombre, edad, etc) con una columna.
• Un atributo clase con una columna clave foranea (IDCategoria)
• Una relacion uno a muchos se mapea con una tabla adicional.
• Un atributo no primitivo con uno o varios archivos (fotografia)

continue reading

UML (Unified Modeling Language)

En un principio el hombre dormia a la interperie pero se dio cuenta que era peligroso estar a la merced de los elementos asi que empezo a construir rusticas cabañas, primero de paja luego de barro hasta llegar a los inmensos edificios de hoy en dia, pues lo mismo paso con el "software" mas conocido como "programa", los primeros programas aunque contaban con cientos de lineas de codigo, eran sencillos y de facil mantenimientos por parte de sus programadores, pero la ciencia evoluciona aun mas rapido que el hombre asi que se hizo necesario de una metodologia que permitiera visualizar, especificar, construir y documentar un sistema.

Primer editor de windows junto a Microsoft Word, ambos editores de texto

La UML es la creacion de Grady Booch, James Rumbaugh e Ivar Jacobson, trabajaron en distintas empresas en la decada de los 80 y cada uno de ellos creo su propia metodologia, luego empezaron a trabajar juntos y nacio UML.

continue reading

Modelo de requerimientos - Casos de Uso (parte 2)

Una ves que tenemos identificado el problema y sus alcances, trataremos de encontrar los actores y casos de uso para nuestro sistema.

Dado la magnitud del proyecto, solo se necesita de un actor al cual llamaremos "usuario", nos toca tambien detectar los "casos de uso" necesarios para el sistema.

Se detectaron nueve casos de uso tratando de cumplir con los requerimientos basicos que el sistema debe cumplir. Ahora para continuar con el "modelo de requerimientos", agruparemos estos casos de uso en un diagrama de paquetes.

continue reading

Modelo de requerimientos - Ejemplo (parte 1)

¿Por qué importan los requerimientos?

En uno de los párrafos más citados en la bibliografía de la Ingeniería del Software, Frederick P. Brooks [Brooks, 1987], dice "La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna es tan difícil de corregir más adelante... Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto."

Por lo tanto antes de ponerse a programar, al menos proyectos enormes, se debe tener bien claro que es lo que se quiere tener como producto final y para ello necesitamos requerimientos ya sea por parte del cliente que requiere esa necesidad en el sistema o bien porque el sistema necesita de ese requerimiento para funcionar por lo tanto si no se consiguen los requerimientos correctos el prducto resultante no permitira a los usuarios finales llevar a cabo su trabajo.

Los requerimientos se pueden dividir en requerimientos funcionales y no funcionales.

Los funcionales definen qué hace el sistema (describen todas las entradas y salidas), es decir, las funciones del sistema. Por su parte, los no funcionales definen los atributos que le indican al sistema cómo realizar su trabajo (eficiencia, hardware, software, interfase, usabilidad, etc.); es el cómo, cuándo y cuánto del qué.

Para entender mejor cual es la funcion y que es lo que debe tener el modelo de requerimientos se llevara a cabo un pequeño ejemplo de un programa simple.




Identificación del Problema.

Desarrollar una aplicación denominada “Administrador de Gastos”, que permitirá al usuario llevar las cuentas de sus gastos con un presupuesto mensual. 

La funcionalidad mínima que debe tener el software es:

• La aplicación debe permitir autentificarse con una contraseña propia. Como medida de seguridad debe limitar el número de intentos a 3.
• Debe permitir el registro de gastos, ingresos y presupuesto,
• Debe permitir la gestión de las diferentes categorías que puedan existir
• Debe tener la capacidad de mostrar en pantalla un informe de ingresos y gastos.

Alcance. Con este sistema se pretende  cubrir las necesidades básicas  del usuario que haga uso del sistema para el control de sus gastos mensual de acuerdo a un presupuesto establecido por la misma persona.

Objetivos del sistema. En este apartado vamos a definir una lista con los diferentes objetivos que se esperan alcanzar cuando el sistema software a desarrollar esté en explotación.

OBJ–01          Gestión
Descripción    El sistema deberá gestionar ingresos, gastos y presupuesto, mostrar informes y gestionar categorías.
Estabilidad       Alta
Comentarios    Ninguno

OBJ–02           Seguridad
Descripción    El sistema deberá gestionar ingresos, gastos y presupuesto, mostrar informes y gestionar categorías.
Estabilidad      Alta
Comentarios    Ninguno

continue reading

Diagrama de Casos de Uso

• Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista del usuario.
• Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno
• Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación
• Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado.
• Los Casos de Uso cubren la carencia existente en métodos previos (OMT, Booch) en cuanto a la determinación de requisitos.
• Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo
• Están basado en el lenguaje natural, es decir, es accesible por los usuarios

Actores:

• Principales: personas que usan el sistema
• Secundarios: personas que mantienen o administran el sistema
• Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados
• Otros sistemas: sistemas con los que el sistema interactúa

La misma persona física puede interpretar varios papeles como actores distintos

El nombre del actor describe el papel desempeñado

Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interacción, los escenarios, desde el punto de vista del usuario

Un escenario es una instancia de un caso de uso.

Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso.

Una característica resaltada respecto de un proceso de desarrollo de software asociado a UML es su naturaleza “use case driven”, es decir, el proceso es dirigido por los casos de uso. Esto significa que en puntos determinado del desarrollo se valida y verifica el correspondiente modelo respecto del modelo de casos de uso. En sí la especificaciones de casos de uso (con los respectivos diagramas de interacción) constituyen una especificación de casos de prueba para el sistema (pruebas funcionales).

Casos de Uso: Relaciones

UML define cuatro tipos de relación en los Diagramas de Casos de Uso:

Comunicacion

Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino

Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino

Herencia : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía

ejemplo

Casos de Uso: Construcción

Un caso de uso debe ser simple, inteligible, claro y conciso
Generalmente hay pocos actores asociados a cada Caso de Uso

Preguntas clave:

• ¿cuáles son las tareas del actor?
• ¿qué información crea, guarda, modifica, destruye o lee el actor?
• ¿debe el actor notificar al sistema los cambios externos?
• ¿debe el sistema informar al actor de los cambios internos?

La descripción del Caso de Uso comprende:

• el inicio: cuándo y qué actor lo produce?
• el fin: cuándo se produce y qué valor devuelve?

la interacción actor-caso de uso: qué mensajes intercambian ambos?

objetivo del caso de uso: ¿qué lleva a cabo o intenta?

cronología y origen de las interacciones

repeticiones de comportamiento: ¿qué operaciones son iteradas?
situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el caso de uso?

continue reading

Diagrama de Casos de Uso - Ejemplos

 RELACIONES

- Inclusion

- Extension

Ejemplo cajero automático

Casos de Uso “Acceder Sistema”

continue reading

Proceso de Requerimientos - Trabajadores

Trabajador Analista de Sistemas

• Responsable del conjunto de requisitos que están modelados en los casos de uso.
• Responsable de delimitar el sistema.

 
Flujos de Trabajo
Una lista de actividades, trabajadores y artefactos constituye un proceso.
Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso.
No siempre es posible representar flujos de trabajo.
 Existen habitualmente problemas de comunicación entre ingenieros de software e ingenieros de negocios.
 RUP proporciona un lenguaje y proceso común para estos dos ámbitos.
 Para el modelamiento del negocio se usan “business use cases” (casos de uso del negocio):

Actividades y Trabajadores

Actividad Encontrar Casos de Uso
Identificar Actores y Casos de Uso
Para:
       Delimitar el sistema
       Actores y funcionalidad
       Glosario
Pasos:
     Descubrir los actores
     Descubrir los casos de uso
     Describir brevemente cada caso de uso
     Describir el modelo de casos de uso

Actividad Priorizar Casos de Uso

El propósito es proporcionar entradas a la priorizacion de los casos de uso para determinar cuáles son necesarios para el desarrollo (análisis, diseño, implementación).

Los resultados se recogen en la vista de la arquitectura del modelo de casos de uso.

• Visión de la arquitectura.
• Casos de uso a desarrollar en las primeras iteraciones.
• Casos de uso significativos.

Actividad Detallar Casos de Uso

Objetivo: flujo de sucesos (o eventos):

• Cómo comienza y termina el caso de uso
•  Cómo interactúa con los actores
•  Objetos que se intercambian

Veremos:

•  Cómo estructurar la descripción de un CU
•  Qué incluir en una descripción de un CU
•  Cómo formalizar la descripción del CU

Estructura de un Caso de Uso

Detallar casos de uso

• Cómo estructurar un CU
• Camino básico: “normal”

Alternativas:

• El actor puede elegir diferentes caminos
• Si está implicado más de un actor, las acciones de uno pueden influir el camino de otro
• El sistema detecta entradas erróneas
• Algunos recursos funcionan mal

Diagrama de Estados

Actividad Interfaz de Usuario

Objetivo: Construir un prototipo de interfaz de usuario.
 

Actividad Estructurar Casos de Uso
Se estructura para:

1. Extraer descripciones (de casos de uso) generales y compartidas que pueden ser utilizadas por descripciones (de casos de uso) mas especificas.

1. Extraer descripciones de funcionalidad (de casos de uso) adicionales u opcionales pueden extender descripciones (casos de uso) mas especificas.

Flujo de Eventos

continue reading

Proceso de Requerimientos

Artefactos

• Elementos de información producidos, modificados o usados por el proceso.
• Son los productos tangibles del proyecto.
• Son usados por los trabajadores para realizar nuevas actividades y son el resultado de esas actividades.

Artefacto Modelo de Casos de Uso
El modelo de casos de uso permite que los desarrolladores de software y los clientes lleguen a un acuerdo sobre los requisitos.

 Un modelo de casos de uso es un modelo del sistema que contiene actores, casos de uso, y sus relaciones

Artefacto Actor

Un actor juega un papel por cada caso de uso con el que colabora.
Varias personas juegan un rol, una persona puede jugar varios roles.

Artefacto Arquitectura
Contiene una vista del modelo de CU que describe los aspectos más importantes de la arquitectura.
Esta vista de la arquitectura se utiliza  como entrada cuando se priorizan los casos de uso para su desarrollo (análisis, diseño, implementación)

Artefacto Interfaz de Usuario
Nos ayudan a comprender y especificar las iteraciones entre actores humanos y el sistema durante la captura de requisitos.
Comprender de una forma detallada los casos de uso.
 
Artefacto Glosario

Para definir términos comunes importantes que los analistas (y otros  desarrolladores) utilizan al describir el sistema.

Es muy útil para alcanzar un consenso entre los desarrolladores para reducir el riesgo de confusiones.

Trabajadores

Representa los comportamientos, descripciones y responsabilidades del mismo. No es lo mismo que un individuo ya que éste puede representar a varios trabajadores si es que realiza distintas actividades.

ANALISTA DE SISTEMAS. Hace la captura de requisitos funcionales y no funcionales  para moldearlos a los CU.  Hay 1 por cada sistema.
ESPECIFICADOR DE CU. Asiste al analista de sistema.
DISEÑADOR DE INTERFAZ . Es responsable del prototipo de interfaz de usuario.
ARQUITECTO. Trabaja con la captura de requisitos para diseñar las vistas de la arquitectura del modelo de CU.

continue reading

Desarrollo de Software Orientado a Objeto usando UML

¿Qué es un Proceso de Desarrollo de SW?

Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo

No existe un proceso de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable

Rational Unified Process (RUP) 

El Proceso Unificado Racional (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo a necesidades.

Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente.

Dos dimensiones

Fases e Hitos (Milestones)

Elementos en RUP 

• Workflows (Disciplinas)

    Workflows Primarios

1. Business Modeling (Modado del Negocio)
2. Requirements (Requisitos)
3. Analysis & Design (Análisis y Diseño)
4. Implementation (Implementación)
5. Test (Pruebas)
6. Deployment (Despliegue)

    Workflows de Apoyo

1. Environment (Entorno)
2. Project Management (Gestión del Proyecto)
3. Configuration & Change Management (Gestión de Configuración y Cambios)

Workers

    Analyst workers

• Business-Process Analyst
• Business Designer
• Business-Model Reviewer
• Requirements Reviewer
• System Analyst
• Use-Case Specifier
• User-Interface Designer

    Developer workers

• Architect
• Architecture Reviewer
• Capsule Designer
• Code Reviewer
• Database Designer
• Design Reviewer
• Designer
• Implementer
• Integrator

Testing professional workers

• Test Designer
• Tester

Manager workers

• Change Control Manager
• Configuration Manager
• Deployment Manager
• Process Engineer
• Project Manager
• Project Reviewer

Other workers

• Any Worker
• Course Developer
• Graphic Artist
• Stakeholder
• System Administrator
• Technical Writer
• Tool Specialist

Artefactos

Resultado parcial o final que es producido y usado durante el proyecto. Son las entradas y salidas de las actividades

• Un artefacto puede ser un documento, un modelo o un elemento de modelo

Conjuntos de Artefactos

• Business Modeling Set
• Requirements Set
• Analysis & Design Set
• Implementation Set
• Test Set
• Deployment Set
• Project Management Set
• Configuration & Change Management Set
• Environment Set

 Características Esenciales de RUP 

• Proceso Dirigido por los Casos de Uso
• Proceso Iterativo e Incremental
• Proceso Centrado en la Arquitectura

Proceso dirigido por los Casos de Uso

Proceso Iterativo e Incremental

• El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes
• En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a menor escala.
• Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes.
• Las actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteración

Cada iteración comprende:

• Planificar la iteración (estudio de riesgos)
• Análisis de los Casos de Uso y escenarios
• Diseño de opciones arquitectónicas
• Codificación y pruebas. La integración del nuevo código con el existente de iteraciones anteriores se hace gradualmente durante la construcción
• Evaluación de la entrega ejecutable (evaluación del prototipo en función de las pruebas y de los criterios definidos)
• Preparación de la entrega (documentación e instalación del prototipo)

Proceso Centrado en la Arquitectura 

Arquitectura de un sistema es la organización o estructura de sus partes más relevantes

Un arquitectura ejecutable es una implementación parcial del sistema, construida para demostrar algunas funciones y propiedades

RUP establece refinamientos sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo

Fases del Ciclo de Vida

El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versión del producto

Cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un número de iteraciones

Las fases son:

• Inicio o Estudio de oportunidad
• Elaboración
• Construcción
• Transición

Inicio o Estudio de oportunidad (inception)

• Define el ámbito y objetivos del proyecto
• Se define la funcionalidad y capacidades del producto

Elaboración

• Tanto la funcionalidad como el dominio del problema se estudian en profundidad
• Se define una arquitectura básica
• Se planifica el proyecto considerando recursos disponibles

Construcción

• El producto se desarrolla a través de iteraciones donde cada iteración involucra tareas de análisis, diseño e implementación
• Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí refinada de manera incremental conforme se construye (se permiten cambios en la estructura)
• Gran parte del trabajo es programación y pruebas
• Se documenta tanto el sistema construido como el manejo del mismo
• Esta fase proporciona un producto construido junto con la documentación

Transición

• Se libera el producto y se entrega al usuario para un uso real
• Se incluyen tareas de marketing, empaquetado atractivo, instalación, configuración, entrenamiento, soporte, mantenimiento, etc.
• Los manuales de usuario se completan y refinan con la información anterior
• Estas tareas se realizan también en iteraciones

continue reading