CAPITULO I

PROCESO UNIFICADO DE DESARROLLO DE

SOFTWARE

17
1.1INTRODUCCIÓN

En el desarrollo de proyectos de software se han realizado de manera

paulatina cambios en los métodos de ingeniería, pero desafortunadamente, estos
cambios no se han realizado a la par en el área de su administración. En el transcurso
del documento se visualizará de manera general los cambios en los ciclos de vida de
un proyecto, indicando sus ventajas y el porqué dicha evolución.

Hoy en día existe un conjunto de modelos de ciclo de vida en la gerencia de

proyectos que han evolucionado desde el tradicional modelo en cascada, pasando por
algunas propuestas de mejoramiento como son el caso de cascadas con fases
solapadas o cascada con subproyectos.

Este modelo tiene como enfoque la entrega del desarrollo de software por
etapas como también el enfoque de entrega evolutiva.

Cabe recalcar que cada uno de estos enfoques contiene mayores niveles de
complejidad a la administración, pero aseveran poseer un marco de trabajo más
sólido y ajustado para el desarrollo de proyectos con niveles moderados de riesgo. Es
por esta razón que se desarrolló el modelo en espiral.

El modelo en espiral se centra en algunas prácticas fundamentales del

desarrollo de software, tales como la orientación al manejo de riesgos, la orientación
al cliente y el desarrollo iterativo. El modelo se organiza en un conjunto de
iteraciones que pueden considerarse a sí mismas como pequeños proyectos que
siguen el ciclo de vida completo.

Las primeras iteraciones tienen como objetivo identificar los riesgos del
proyecto para determinar su viabilidad, y en caso de seguir adelante, definir un plan
de manejo para mitigarlos o eliminarlos. Adicionalmente, el usuario participa
activamente en la priorización de los casos de uso a desarrollar y en el proceso de

18
pruebas, con lo cual se logra obtener una funcionalidad estable y operativa desde las
primeras iteraciones del proyecto.

Para alcanzar este modelo que permita una mejor administración de riesgos se
va a emplear una nueva metodología denominada RUP (Proceso Unificado de
desarrollo de software), que contiene pasos específicos para obtener el modelo en
espiral.

19
1.2 DEFINICIÓN

El Proceso Unificado de desarrollo de software se lo puede definir como:

“Conjunto de actividades necesarias para transformar los requisitos del usuario

en un sistema software”. (Gustavo Torossi)1

Este proceso de desarrollo de software está dirigido por casos de uso, se

encuentra centrado en la arquitectura de software del sistema; es iterativo e
incremental, con el objetivo de asegurar la mejor producción de software de calidad
en los plazos y presupuestos establecidos.

Es un marco genérico que tiene la capacidad de aplicarse en una variedad de

tipos de sistemas, en diferentes áreas de aplicación, diferentes tipos de
organizaciones, niveles de aptitud, como también en diferentes tamaños de
proyectos.

1.3 PRINCIPIOS PARA DESARROLLAR EL RUP

El RUP se encuentra enfocado en cinco principios claves que se describen a

continuación:

¾ Adaptar el proceso.- Todo proceso del sistema deberá adaptarse a las

características propias del proyecto u organización. Dependiendo del
tamaño del proyecto, como también las regulaciones que lo
condicionen deberán ser tomados en cuenta en el diseño del mismo.
Es importante tener claro el alcance del proyecto.

1
Gustavo Torossi El Proceso Unificado de Desarrollo de Software,
www.ecomchaco.com.ar/UTN/disenodesistemas/apuntes/oo/ApunteRUP.pdf

20
 ¾ Balancear prioridades.- Los requerimientos de los diversos usuarios
pueden ser diferentes o contradictorios como también puede disputar
recursos limitados. Se debe encontrar un balance que satisfaga las
necesidades de todos.

¾ Demostrar valor iterativamente.- El proyecto se debe entregar, ya

sea de manera interna en etapas iteradas. En cada iteración se analiza
la opinión de los usuarios, la estabilidad y la calidad del producto, a la
par se refina los riesgos o la dirección del proyecto.

¾ Elevar el nivel de Abstracción.- Esto motiva el uso de conceptos

reutilizables como puede ser: Lenguajes de 4GL, patrón de software o
esquemas (frameworks). Esto permite definir los diversos niveles
arquitectónicos representados generalmente por los modelos UML.

¾ Enfocarse en la Calidad.- El control de calidad se debe controlar en

todos los aspectos de la producción, más no en cada iteración.

1.4 PRINCIPALES CARACTERÍSTICAS DEL RUP

La metodología RUP tiene varias características y las detallaremos de

acuerdo al grado de importancia.

¾ CENTRADO EN LA ARQUITECTURA

El Proceso Unificado asume que no existe un modelo único que cubra

todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas
que definen la arquitectura de software de un sistema. Mediante la arquitectura del
sistema se describen diferentes vistas del software en construcción, incluyendo los
aspectos estáticos y dinámicos más significativos del sistema.

21
 Arquitectura: Conjunto de decisiones significativas acerca de la
organización de un sistema software, la selección de los elementos estructurales a
partir de los cuales se compone el sistema, las interfaces entre ellos, su
comportamiento, sus colaboraciones, y su composición.2

La arquitectura deberá permitir el desarrollo de casos de uso requeridos para

la construcción del sistema.

Se desarrolla la arquitectura a partir de la comprensión de un conjunto

reducido de casos de uso fundamentales o críticos (usualmente no más del 10 % del
total). Los pasos a seguir para elaborar la arquitectura del proyecto son las
siguientes:
x Crea un esquema en borrador de la arquitectura comenzando por la
parte no específica de los casos de uso (por ejemplo la plataforma)
pero con una comprensión general de los casos de uso fundamentales.
x A continuación, trabaja con un conjunto de casos de uso clave o
fundamental. Cada caso de uso es especificado en detalle y realizado
en términos de subsistemas, clases, y componentes.
x A medida que los casos de uso se especifican y maduran, se descubre
más de la arquitectura, y esto a su vez lleva a la maduración de más
casos de uso.

Este proceso continúa hasta que se considere que la arquitectura es estable.

¾ DIRIGIDO POR CASOS DE USO

Un caso de uso es un fragmento de funcionalidad del sistema que proporciona

un resultado de valor a un usuario. Los casos de uso modelan los requerimientos
funcionales del sistema. Los casos de uso también guían el proceso de desarrollo
(diseño, implementación, y prueba).
2Gustavo Torossi El Proceso Unificado de Desarrollo de Software,
www.ecomchaco.com.ar/UTN/disenodesistemas/apuntes/oo/ApunteRUP.pdf

22
 Basándose en los casos de uso se crea una serie de modelos de diseño e
implementación que llevan a cabo los casos de uso. De este modo los casos de uso no
solo inician el proceso de desarrollo sino que le proporcionan un hilo conductor, que
avanza a través de una serie de flujos de trabajo. Todos los casos de uso juntos
constituyen el modelo de casos de uso.

Los casos de uso y la arquitectura están profundamente relacionados. Los casos de

uso deben encajar en la arquitectura, y a su vez la arquitectura debe permitir el
desarrollo de todos los casos de uso requeridos, actualmente y a futuro.

¾ ITERATIVO E INCREMENTAL

Es práctico dividir el esfuerzo de desarrollo de un proyecto de software en

partes más pequeñas o mini proyectos.

Cada mini proyecto es una iteración que resulta en un incremento. Las

iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos a
crecimientos en el producto.

Las iteraciones deben estar controladas. Esto significa que deben

seleccionarse ejecutarse de una forma planificada. Los desarrolladores basan la
selección de lo que implementarán en cada iteración en dos cosas: el conjunto de
casos de uso que amplían la funcionalidad, y en los riesgos más importantes que
deben mitigarse.

En cada iteración los desarrolladores identifican y especifican los casos de

uso relevantes, crean un diseño utilizando la arquitectura seleccionada como guía,
para implementar dichos casos de uso. Si la iteración cumple sus objetivos, se
continúa con la próxima. Caso contrario deben revisarse las decisiones previas y
probar un nuevo enfoque.

23
 ¾ BENEFICIOS DEL ENFOQUE ITERATIVO

x La iteración controlada reduce el riesgo a los costes de un solo

incremento.
x Ataca los riesgos más importantes reduciendo retrasos en el calendario
de actividades.
x Acelera el desarrollo. Los trabajadores trabajan de manera más
eficiente al obtener resultados a corto plazo.
x Tiene un enfoque más realista al reconocer que los requisitos no
pueden definirse completamente al principio.

1.5 CICLO DE VIDA DE RUP

Para una mejor organización el RUP se divide en etapas y fases que facilitan
la administración del proyecto.

1.5.1 FASES DEL CICLO DE VIDA

El proceso de RUP es una serie de ciclos que constituyen la vida de un
sistema; constituyendo cada ciclo una versión del sistema.

Hitos

Inicio Elaboración Construcción Transición

Tiempo

Figura 1.1 Fases E Hitos De Un Proyecto

Las fases que constituyen el ciclo de vida RUP son denominadas:

x Inicio: Definir el alcance del Proyecto

x Elaboración: Planificar el proyecto, elaborar una arquitectura base
x Construcción: Construir el Sistema
x Transición: Transición a los usuarios
24
1.5.2 ETAPAS DEL RUP

La metodología RUP cuenta con dos fases para su desarrollo las que se
describirán a continuación:

¾ ETAPA DE INGENIERÍA.

Agrupa las Fases de Inicio y Elaboración, esta etapa tiene como objetivo la
conceptualización del sistema y el diseño inicial de la solución del problema.

Se inicializa el proceso de administración de los requerimientos con la

identificación y especificación de los casos de uso, como también se asegura la
calidad del proyecto mediante los casos de prueba.

Se identifica los riesgos y se determina su plan de manejo mediante la tabla

de priorización de riesgos y los casos de uso Vs. Riesgos para determinar en qué
orden y en que iteraciones se desarrollarán los artefactos de software para
solucionar los casos de uso.

Se identifica los recursos necesarios tanto económicos y humanos acordes a

las necesidades del proyecto.

¾ ETAPA DE PRODUCCIÓN

En esta etapa se realiza un proceso de refinamiento en las estimaciones de

tiempo y recursos para las fases de construcción y transición, se determina un
plan de mantenimiento para los productos entregados en la etapa de Ingeniería,
en esta etapa se implementan los casos de uso que falta y se entrega el producto
al cliente garantizando la capacitación y el soporte a los usuarios.

25
1.5.3 ITERACIONES DE FASE
Cada una de estas
fases se encuentra
dividida en una
serie de iteraciones,
ofreciendo a su vez
como resultado un
incremento del
producto
desarrollado que
añade o mejora las
funcionalidades del
Figura 1.2 Diagrama de Disciplinas Básica sistema en desarrollo.
Las iteraciones establecidas a su vez se desarrollan un conjunto de disciplinas o
flujos de trabajo.

DISCIPLINAS

Figura 1.3 Diagrama de Fases, Iteraciones y Disciplina

26
 Las disciplinas son un conjunto de actividades relacionadas (flujo de trabajo);
que se encuentran vinculadas en un área específica dentro del proyecto que se
pretende desarrollar.

Las disciplinas más importantes son: Requerimientos, Análisis, Diseño,

Codificación y Prueba.

Este tipo de
organización
ayuda a
comprender
la Visión
tradicional
en espiral.

Figura 1.4 Diagrama de Modelo y Disciplinas de un Proyecto

Cada una de estas disciplinas se encuentran vinculadas a un conjunto de modelos que

se desarrollan; cada uno de ellos están compuestos por artefactos.

Los artefactos más importantes son los modelos que cada disciplina realiza:
modelo de casos de uso, modelo de diseño, modelo de implementación, y
modelo de prueba.

El RUP como se mencionó anteriormente es una serie de disciplinas o flujos

de trabajo que parten desde los requisitos hasta las pruebas.

Los flujos de trabajo desarrollan modelos desde el modelo de casos de uso

hasta el modelo de pruebas.

27
 La organización es la siguiente:

DISCIPLINA MODELOS
Requisitos Modelo de Casos de Uso
Análisis Modelo de Análisis
Diseño Modelo de Diseño-Modelo de Despliegue
Implementación Modelo de Implementación
Prueba Modelo de Prueba
Tabla 1.1 Modelos y Disciplinas para el desarrollo de software

1.5.5 HITOS

Cada fase se culmina con un hito que se determina por la disponibilidad de un

conjunto de modelos o documentos que se han desarrollado para alcanzar un estado
predefinido.

Los Hitos plantean muchos objetivos; lo más crítico de esto es que los
directores deben tomar decisiones antes de continuar con la siguiente fase; una
ventaja de trabajar con hitos es que permiten controlar la dirección y progreso del
trabajo.

R.U.P.

Basado en Dividido en

Modelo en
Etapas
Espiral

Figura 1.5 Diagrama de Modelo Conceptual RUP

28
 Figura 1.6 Diagrama de Modelo Conceptual RUP Espiral

Figura 1.7 Diagrama de Modelo Conceptual RUP dividido en Etapas

1.6DESARROLLO FASES DEL RUP

ETAPA DE INGENIERÍA

1.6.1. FASE DE INICIO

En esta fase se determina el alcance del proyecto, se identifica los riesgos

asociados al proyecto, se propone una visión muy general de la arquitectura del
software y producir el plan de las fases y el de iteraciones.

29
 1.6.1.1. ALCANCE DEL PROYECTO

Con el desarrollo de este proyecto se pretenden alcanzar diferentes puntos

para una excelente administración de la información que se maneja en el
departamento de subestaciones de la Empresa Eléctrica Regional CentroSur C.A.

1.6.1.2. DETERMINACIÓN DE ACTIVIDADES Y

ESTABLECIMIENTO DEL PERSONAL

ACTIVIDAD
Enumerar requisitos de usuarios
Comprender el contexto del sistema
Capturar Requisitos Funcionales
Capturar Requisitos No Funcionales
Capturar Requisitos de Software
Capturar Requisitos de Hardware
Determinación de Riesgos
Proyecto
Tabla 1.2 Tabla de Personal y Actividades en el desarrollo de Software fase de Inicio
PERSONAL
Andrés Calle, Maribel Duchi, Gladys Luna
Andrés Calle, Maribel Duchi, Gladys Luna
Maribel Duchi, Gladys Luna
Maribel Duchi, Gladys Luna
Andrés Calle
Andrés Calle
del Andrés Calle, Maribel Duchi, Gladys Luna

1.6.1.3. REQUERIMIENTOS

El propósito fundamental del flujo de trabajo de los requisitos es guiar el

desarrollo hacia el sistema correcto. Hay diferentes puntos de partida para la captura
de requisitos. En este caso es un sistema acotado que no da soporte al negocio por lo
tanto se puede organizar el proyecto a partir de un modelo de objetos sencillo como
un modelo del dominio.

En otros casos el cliente puede ya haber desarrollado una especificación

completa de requisitos no basada en objetos, de la cual podemos partir. En forma
típica, el flujo de trabajo de requisitos incluye los siguientes pasos:
30
 x Enumerar los requisitos de usuarios.
x Comprender el contexto del sistema.
x Capturar requisitos funcionales.
x Capturar requisitos no funcionales.
x Capturar requisitos de Hardware.
x Capturar requisitos de Software.

Se realizará un capítulo enfocado al el desarrollo de estos ítems se encuentra

en el Capítulo 3 de este documento.

1.6.1.4. IDENTIFICACIÓN DE RIESGOS DEL PROYECTO

INTRODUCCIÓN

En el desarrollo de software el riesgo se considera como uno de los tres

pilares fundamentales en el enfoque conceptual, por lo tanto el futuro es lo que nos
preocupa por ejemplo: ¿Qué riesgos podrían hacer que nuestro proyecto fracasara?,
¿Cómo afectarán los cambios en los requisitos de nuestros clientes; en las
tecnologías de desarrollo, en los ordenadores a las que van dirigidas?, Para terminar,
nos enfrentamos con elecciones ¿qué métodos y herramientas deberíamos emplear,
cuánta gente debería estar implicada, qué importancia hay que darle a la calidad de
software?.

Antes de identificar los "riesgos adecuados" que se pueden presentar en el

desarrollo de un proyecto de software, es importante darse cuenta de todos los
riesgos que sean obvios para los jefes de proyectos y profesionales del software;
existen dos tipos de estrategias para identificar riesgos:

¾ Estrategia Proactiva.- Esta estrategia empieza mucho antes de que

comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se
valoran su probabilidad y su impacto y se establece una prioridad según su

31
 importancia. Después el equipo de software establece un plan para controlar
el riesgo. Siendo el principal objetivo de este plan evitar el riesgo, pero por lo
general no se pueden evitar todos los riesgos. Por esta razón el equipo trabaja
en el desarrollo de un plan de contingencia que permita responder de manera
eficaz los posibles riesgos que se presenten en el proyecto.

¾ Estrategia Reactiva.- Esta estrategia únicamente supervisa el proyecto en

previsión de posibles riesgos. Los recursos se ponen aparte, en caso de que
pudieran convertirse en problemas reales. Pero lo más frecuente es que el
equipo de software no haga nada respecto a los riesgos hasta que se presente
algún problema. Generalmente este tipo de método se denomina "de
bomberos". Cuando falla, "la gestión de crisis" entra en acción y el proyecto
se encuentra en peligro real.

En cuanto a los riegos del software se han identificado dos características:

x Incertidumbre.-Se define por la probabilidad en que el riego puede o no
ocurrir. Es decir no existen riesgos con una probabilidad de ocurrencia de un
100%.

x Pérdida.- Si llegara a ocurrir el riesgo, esto provocaría pérdidas o

consecuencias no deseadas.

Los riesgos se encuentran clasificados por categorías los cuales detallamos a

continuación:
¾ Riesgos del proyecto.-Este tipo de riesgo amenaza al plan del proyecto; es
decir que existe la probabilidad de que se presente un retraso en la
planificación temporal del proyecto, ocasionando que los costos aumenten.
Los riesgos del proyecto como se mencionó anteriormente identifican los
problemas potenciales de presupuesto, planificación temporal, personal
(asignación y organización), recursos, clientes, requerimientos.

32
 ¾ Riesgos Técnicos.- Amenazan la calidad y la planificación temporal del
software. Si llegara a ocurrir este riesgo la implementación del software
puede llegar a ser difícil o imposible. Los riesgos técnicos identifican
problemas potenciales de diseño, implementación, de interfaz. verificación y
de mantenimiento. Considerando también las ambigüedades de
especificaciones, incertidumbre técnica, técnicas anticuadas y las "tecnologías
punta" que son también factores de riesgo.

¾ Riesgos del Negocio.- Este tipo de riesgo amenaza la posibilidad de la

construcción del software.

¾ Riesgos Predecibles: Como su nombre lo indica son los que se pueden

identificar con la experiencia de proyectos anteriores.

¾ Riesgos Impredecibles: Son aquellos que pueden y de hecho ocurren en un

proyecto, y por lo general son difíciles de identificar.

1.6.1.5. IDENTIFICACIÓN DEL RIESGO

Es un intento sistemático para especificar las amenazas al plan del proyecto

(estimaciones, planificación temporal, carga de recursos, etc).

Existen dos tipos de riesgo:

x Los riesgos genéricos.- Son una amenaza potencial para todos los proyectos
de software.

x Los específicos de producto.- Sólo los pueden identificar los que tienen una
clara visión de la tecnología, personal y el entorno específico del proyecto en
cuestión. La lista de comprobación se puede utilizar para identificar riesgos y
se enfoca en un subconjunto de riesgos conocidos y predecibles en las
siguientes subcategorías genéricas:

33
 1. Tamaño del producto: riesgos asociados con el tamaño general del software
a construir o a modificar.

2. Impacto en el negocio: riesgos asociados con las limitaciones impuestas por

la gestión o por el mercado.

3. Características del cliente: riesgos asociados con la sofisticación del cliente

y la habilidad del desarrollador para comunicarse con el cliente en los
momentos oportunos.

4. Definición del proceso: riesgos asociados con el grado de definición del

proceso del software y su seguimiento por la organización de desarrollo.

5. Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de

las herramientas que se van a emplear en la construcción del producto.

6. Tecnología a construir: riesgos asociados con la complejidad del sistema a

construir y la tecnología punta que contiene el sistema.

7. Tamaño y experiencia de la plantilla: riesgos asociados con la experiencia

técnica y de proyectos de los ingenieros del software que van a realizar el
trabajo.

El detalle de cada uno de los riesgos será descrito en el capítulo 3.8

1.6.2. FASE DE ELABORACIÓN

Durante la fase de elaboración se especifican en detalle la mayoría de los

casos de uso del producto y se diseña la arquitectura.

34
 ACTIVIDAD PERSONAL
Diseño de la Arquitectura del Andrés Calle, Maribel Duchi, Gladys Luna
Software
Determinación y Diseño de Casos de Andrés Calle, Maribel Duchi, Gladys Luna
Uso
Diseño del Modelo de Diagrama de Maribel Duchi, Gladys Luna
Secuencias
Diseño del Modelo de Procesos Maribel Duchi, Gladys Luna
Diseño del Modelo Conceptual Andrés Calle
Diseño del Modelo de Componentes Andrés Calle
Diseño del Modelo de Diagrama de Andrés Calle, Maribel Duchi, Gladys Luna
Clases
Diseño de Prototipos de Software Andrés Calle, Maribel Duchi, Gladys Luna
Tabla 1.3 Tabla de Personal y Actividades para desarrollo de Software Fase de Elaboración

ETAPA DE PRODUCCIÓN

1.6.3. FASE DE CONSTRUCCIÓN

Durante la fase de construcción se crea el producto. La línea base de la

arquitectura crece hasta convertirse en el sistema completo. Al final de esta fase, el
producto contiene todos los casos de uso implementados, sin embargo puede que no
esté libre de defectos.

ACTIVIDAD PERSONAL
Elaboración de Prototipos Andrés Calle, Maribel Duchi, Gladys Luna
Elaboración de Manual de Andrés Calle, Maribel Duchi, Gladys Luna
Usuario
Tabla 1.4 Tabla de Personal y Actividades en desarrollo de software Fase de Construcción

35
 1.6.4. FASE DE TRANSICIÓN

La fase de transición cubre el período durante el cual el producto se

convierte en la versión beta. A esta fase no se llegará a cumplir porque no se cuenta
con el tiempo necesario.

1.7GLOSARIO DE TÉRMINOS

Actividad.- Los trabajadores realizan actividades. Una actividad es algo que realiza
un trabajador para proveer un resultado de valor en el contexto de un proyecto.

Artefactos.- Las actividades tienen artefactos de entrada y de salida. Un artefacto

es un producto de trabajo en un proceso: los trabajadores utilizan artefactos para
realizar actividades y producen artefactos como resultado de sus actividades. Los
artefactos son responsabilidad de un único trabajador y promueven la idea de que
toda pieza de información en el proceso debe ser responsabilidad de un rol
específico. Un trabajador es el “propietario” de un artefacto, pero otros trabajadores
pueden usarlo y tal vez modificarlo si tienen permiso para ello.

Base de Datos.- Información almacenada sistemáticamente, para que resulte sencillo

recuperar o actualizar uno o varios ítems.

Diagrama Arquitectónico.- Este diagrama muestra los principales subsistemas que

componen un sistema.

Diagramas de Caso de Uso.- Este tipo de diagrama describe lo que hace un sistema
desde el punto de vista de un observador externo.

Disciplina.- Una disciplina es una colección de actividades relacionadas vinculadas

con un área específica del proyecto. Este agrupamiento de actividades en disciplinas

36
es principalmente para facilitar la comprensión del proyecto desde la perspectiva
tradicional del modelo en cascada.

Flujo de trabajo.- Un flujo de trabajo describe la secuencia en que se realizan las

actividades en una disciplina, quienes la realizan (trabajadores) y que artefactos
producen.

Hardware.- Partes tangibles de una computadora. Conjunto de elementos

mecánicos, eléctricos o magnéticos para el procesamiento de la información.

Interfaz.- Una interfaz es la parte de un programa informático que permite a éste

comunicarse con el usuario o con otras aplicaciones permitiendo el flujo de
información.

Lenguaje estructurado.- Es una forma restringida del lenguaje natural. Mantiene

mucha expresividad y asegura que cierto grado de uniformidad se imponga a la
especificación.

Lenguaje Natural.- Es un lenguaje utilizado para redactar las especificaciones de

requerimientos del sistema.

Multiplataforma.- Un sistema puede trabajar sobre cualquier Sistema Operativo.

Pasos (steps).-Las actividades son descompuestas en pasos. Podemos distinguir tres

categorías de pasos:

x Pasos de acción: donde los trabajadores crean o actualizan algunos

artefactos.
x Pasos de análisis: donde el trabajador comprende la naturaleza de la tarea,
examina los artefactos de entrada, y formula las salidas.

37
 x Pasos de revisión: donde los trabajadores inspeccionan los resultados según
determinados criterios.

Procesador.- Es el motor de la unidad central de proceso que se encarga de manejar

memoria, control de flujo de información y realizar operaciones básicas sobre los
datos.

Proceso de Ingeniería de Software.- Un proceso es un conjunto de pasos ordenados

para alcanzar un objetivo. En ingeniería de software, el objetivo es construir un
producto de software nuevo o extender uno existente. En RUP esto se organiza en un
conjunto de Disciplinas que define un flujo de trabajo.

Requerimiento del sistema.- Establecen con detalle los servicios y restricciones del
sistema. Se orientan al personal técnico y a los administradores del proyecto.

Requerimiento del usuario.- Son declaraciones en lenguaje natural y diagramas de

los servicios que se espera que el sistema provea y de las restricciones bajo las cuales
debe operar.

Requerimiento.- Declaración abstracto de alto nivel de un servicio que debe proveer

el sistema.

Requerimientos funcionales.- Son declaraciones de los servicios que proveerá el

sistema, de la manera en que éste reaccionará a entradas particulares y de cómo se
comportará en situaciones particulares.

Requerimientos no funcionales.- Son restricciones de los servicios o funciones

ofrecidos por el sistema.

Sistema Operativo.- Conjunto de programas para la administración de los recursos

del equipo que permiten la interrelación de la computadora con usuario.
38
Sistema.- Combinación de procedimientos destinados a producir ciertos resultados.

Software.- Conjunto de rutinas, programas, procedimientos y normas para que

funcione un sistema.

Trabajador (Rol).- Un trabajador o rol, define un comportamiento o

responsabilidades de un individuo o grupo de individuos trabajando en equipo, en el
contexto de una organización de ingeniería de software.

Usuario.- Persona o grupo de personas que utilizarán el software para actualizarlo

y/o consultarlo.

4GL.- Lenguaje de Cuarta Generación.

39