Está en la página 1de 37

Metodología para el Desarrollo de Sistema de

Información
Enviado por thais Londoño

1. Introducción
2. Contenido
3. Requerimientos
4. Análisis / Diseño
5. Construcción
6. Pruebas
7. Producción y mantenimiento
8. Conclusión

Introducción
Diseñar un sistema de información no solo requiere de la experiencia sino también de
la metodología a seguir existen muchos autores que atreves de los años desarrollaron distintas
metodología para este fin, esto se debió a la falta del manejo de datos en las empresas para
mayor factibilidad y éxito de la misma, es por ello que hoy día existen Organizaciones exitosas y
con altos puestos a nivel económico en el mundo actual, cave destacar que sin estos autores que
a través del tiempo han aplicado su metodología y a sido demostrada que a través de
estos métodos el éxito de las organizaciones se ha visto por el levantamiento o despertar
económico de un país, de lo antes expuesto he leído la metodología de Llorens Fabregas, que
evalúa un S.I. en 5 fases sumamente importantes para el desarrollo de un SI, que satisface las
necesidades del individuo u organización a nivel mundial. El análisis de este autor es un
análisis estructurado ya que consta de partes en las que se desarrolla la metodología para
evaluar un SI.

Contenido
Fabregas se enfoca en la necesidad de la Organización para el cumplimiento cabal de sus
actividades y se basa en su metodología para establecer fases que determinan cada paso
del diseño o la implementación de un Sistema de Información, su técnica es utilizada para
desarrollar estrategias que mejoren el funcionamiento de los sistemas de información ya
existentes. El ciclo de desarrollo de sistemas de información propuesto por Llorens Fabregas
esta compuesto de 5 Fases, las cuales enfocan de una manera clara los métodos y pasos para la
implementación de un SI. La primera fase, los requerimientos, esta enfocado a la necesidad
de la organización, lo que significa, la planeación y las estrategias que se van a emplear para el
desarrollo del nuevo sistema, es decir los requerimientos del cliente. Este análisis de
información va desde los procesos que integran al departamento u Organización en donde se va
a desarrollar el sistema, hasta los bienes materiales y humanos que componen al mismo. La
segunda fase, el Análisis y Diseño, en este se requieren datos aportados por el solicitante del SI.
Estos datos son los recopilados por la primera fase, analizar, organiza y diseña los procesos, los
datos, los componentes físicos que el sistema necesita para poder funcionar de forma efectiva y
que cumpla con todos Los requerimientos del cliente. Al concluir estas dos fases, se procede a
la construcción del sistema, el cual esta divido en varias sub.-fases: El Desarrollo de
Infraestructura (Lo cual permite el cumplimiento de las tareas del sistema de forma mas
efectiva), Adaptación de Paquetes (Se revisa el funcionamiento del sistema por el equipo
Analista- Usuario para su mejor entendimiento), Desarrollo de unidades de diseño interactivas
(Los procedimiento visuales), Unidades de diseño batch (transacciones de datos) y el
Desarrollo de unidades de diseño Manuales. Luego, siguen la fase de las pruebas, en donde se
prueba por completo el sistema, midiendo su nivel de calidad, funcionalidad, integración y
aceptación técnica. Luego, se prueba el sistema completo en base a los niveles de prueba:
Funcional, De Sistema, De integración y De Aceptación Técnica. Al concluir con estas pruebas
de forma satisfactoria, se cargan los archivos, bases de datos y las tablas del nuevo sistema,
para de esta forma comenzar su uso, primero durante un Periodo de Aceptación, y finalizado
este como el sistema oficial. Por ultimo, una vez que un sistema pasa a formar parte de la vida
diaria de la empresa cada programa, procedimiento y cada estructura de datos se convierte en
una pieza del negocio, que como tal, deberá funcionar de forma constante exacta y confiable.
Una Metodología para el Desarrollo de Sistemas de Información es un conjunto de actividades
llevadas a cabo para desarrollar y poner en marcha un Sistema de Información.
Los Objetivos de las Metodologías de Desarrollo de Sistemas de Información son:
 Definir actividades a llevarse a cabo en un Proyecto de S.I.
 Unificar criterios en la organización para el desarrollo de S.I.
 Proporcionar puntos de control y revisión
Llorens Fabregas utiliza un análisis estructurado por que:
 Se maneja como proyecto
 Gran volumen de datos y transacciones
 Abarca varias áreas organizativas de la empresa
 Tiempo de desarrollo largo
 Requiere que se cumplan todas las etapas, para poder cumplir las siguientes (progresión
lineal y secuencial de una fase a la otra).
FASE I –

Requerimientos
Esta fase fundamental para que la estrategia informática encaje dentro de las metas de
la empresa, ya que en ella se cumplen las funciones del modelaje del negocio y planificación de
sistemas; esto con el fin de proyectar las estrategias del negocio y determinar de esta forma sus
requerimientos de información.
Aunque la fase de requerimientos puede aplicarse a todos los procesos de la empresa, o a un
área en específico, suele ser mas practico analizar área por área del negocio.
Durante esta fase se desarrolla un modelo del área estudiada, donde se representa: Los
procesos que se llevan a cabo, la información utilizada por ellos y las reglas políticas y prácticas
de la empresa relacionada con estos procesos.
Este modelo permite proyectar las estrategias, procesos y flujos de datos de la empresa al igual
que las interrelaciones entre procesos y datos, con el fin de desarrollar un plan de sistema de
información capaz de guiar el desarrollo de un sistema que permita dar soporte al área en
estudio en el cumplimiento de sus objetivos.
El Plan de Sistemas debe contener:
 Los sistemas que requiere el área del negocio, así como sus bases de datos y la información
que intercambiaran o compartieran.
 Descripción detallada de cada sistema y aplicación incluyendo sus objetivos funcionales y
sus bases de diseño.
 Todo hardware y software que serán utilizados para el funcionamiento requeridos por el
área de negocio (incluyendo las redes)
 Métodos de desarrollo para cada sistema como lo es adquisición de paquetes, nuevo
desarrollo o actualizaciones
 Esquema de los problemas actuales del área de negocio y de las posibles mejoras que se
puedan realizar en cada sistema
 Análisis de los beneficios que se espera derivar de los sistemas que conforman la
arquitectura
El plan de sistemas de información es uno de los factores más importantes para el
departamento de informática o sistemas ya que constituye la guía para emprender
los proyectos que requiera el cliente, reclutar y adiestrar al personal necesario y la adquisición e
instalación de hardware y software necesarios.
Además, el plan de sistemas es fundamental para la constr5uccion y desarrollo de
un ambiente de alta calidad y productividad ya que:
 La arquitectura de sistemas sobre la cual descansa el plan para una determinada área
de negocios define la forma de cómo cada aplicación desarrollada será destinada a dar
soporte a objetivos claves y estratégicos para esa especifica área del negocio y, por ende, a la
empresa,
 Se determinara una definición precisa de los beneficios, alcances y objetivos de cada
sistema, lo cual creara soluciones que el negocio realmente necesite. Estos sistemas se
ajustaran a las estrategias definidas por la gerencia.
 Cada proyecto tendrá una prioridad fijada por la gerencia, lo que determinara el orden de
ejecución.
 Cada aplicación desarrollada podrá ser interrelacionada con otros sistemas.
FASE II

Análisis / Diseño
El objetivo de esta fase es desarrollar el diseño arquitectónico de los sistemas, utilizando los
requerimientos obtenidos en la primera fase. En el diseño arquitectónico se engloban dos
componentes: los datos y los procesos, los cuales serán analizados y diseñados desde una
perspectiva conceptual a una física, dentro de las cuatros actividades que se encuentran en esta
fase.
Actividades dentro de la fase de Análisis/Diseño.
 Analizar y Diseñar Proceso: Las operaciones del negocio y los requerimientos de
funcionamiento definidos en la primera fase, se toman en cuenta con el propósito de
determinar la forma en que debe funcionar el sistema.
 Analizar y Diseñar Los Datos: Con los requerimientos de información definidos en la fase I
se debe organizar los distintos modelos de datos que nos ayuden a diseñar la base de
datos que hagan falta para que el sistema funcione de acuerdo al modelo de
funcionamiento.
 Diseñar y Organizar Los Componentes Físicos: Todo componente físico como (pantallas,
base de datos) que hagan posible el funcionamiento del sistema de acuerdo al modelo de
funcionamiento.
 Planificar El Desarrollo De Los Componentes Físicos: actividad en la cual planificamos la
forma en que pueden ser construidos e implementados los componentes físicos de una
forma rápida y productiva.
En esta fase de análisis / diseño puede incluirse una sub.-fase de evaluación de paquetes. Esta
se pudiese realizar si en los requerimientos se estableció adquirir un paquete de aplicaciones en
lugar de completar un diseño arquitectónico.
FASE III

Construcción
Dentro de esta fase de construcción existen actividades separadas en cinco sub.-fases:
Desarrollo De Infraestructura
Durante esta fase se desarrollará y organizará la infraestructura que permita cumplir las tareas
de construcción en la forma más productiva posible.
Adaptación De Paquetes
Ofrece una desventaja fundamental: el personal de la instalación no conoce los componentes
del paquete con la misma profundidad con que conoce los componentes desarrollados por ellos
mismos. Uno de los objetivos centrales de esta sub.-fase es conocer al máximo detalle posible el
funcionamiento del paquete, este asegurará que el paquete será utilizado con el máximo
provecho, tanto desde el punto de vista del negocio, como de la utilización de recursos. Cada
componente del paquete será revisado en forma exhaustiva por el equipo Analista – Usuario,
con el fin de conocer y comprender todos los aspectos del paquete.
Desarrollo De Unidades De Diseño Interactivas
Las unidades de diseño interactivas, son procedimientos que se cumple o se ejecutan a través
de un dialogo usuario / sistema.
Las actividades de esta sub.-fase tienen como objetivo central:
 Especificar en detalle las tareas que debe cumplir la unidad de diseño
 Desarrollar componentes
 Realizar las pruebas unitarias y las pruebas de integración a nivel de la unidad de diseño.
Desarrollo De Unidades De Diseño Batch
Las unidades de diseño Batch, son aquellos procedimientos que se cumplen en forma
automatizada, pero en la que no se entabla un dialogo entre usuario y el analista, sino que
involucra grupos de transacciones que se alimentan al computador de una sola vez. Su objetivo
central es igual a la fase de desarrollo de unidades de diseño interactivas. En esta sub.-fase se
preparan especificaciones hechas utilizando una combinación de técnicas como flujo
gramas, diagramas de estructuras, tablas de decisiones etc. Cualquiera que se utilice será útil
para que la especificación sea clara y se logre el propósito de que el programador comprenda y
pueda programar y probar los programas correspondientes.
 Desarrollo De Unidades De Diseño Manuales
Esta sub.-fase incluyen las tareas que se ejecutan en forma manual que se incluyen dentro de lo
procedimientos administrativos. Las actividades de esta sub.-fase tienen como objetivo central
desarrollar todos los procedimientos administrativos que rodearán y gobernarán la utilización
de los componentes computarizados desarrollados en la fase de diseño detallado y
construcción.
FASE IV

Pruebas
Esta fase, da inicio luego de que las diferentes unidades de diseño han sido desarrolladas y
probadas por separado. Durante su desarrollo, el sistema se emplea de forma experimental
para asegurar que el software no falle, es decir que funcione de acuerdo a sus especificaciones y
a la manera que los usuarios esperan que lo haga, y de esta forma poder detectar cualquier
anomalía, antes de que el sistema sea puesto en marcha y se dependa de el. Para evaluar el
desenvolvimiento del sistema, en esta fase se llevan a cabo varios niveles de prueba:
 Funcional: Prueba desde el punto de vista de los requerimientos funcionales.
 De Sistema: Prueba desde el punto de vista de los niveles de calidad del sistema y
de desempeño.
 De Integración: Prueba de interfaces.
 De Aceptación Técnica: Prueba de manejo de condiciones extremas.
Si el Sistema cumple de forma satisfactoria con estos niveles mencionados anteriormente, se
procede a realizar la carga de los archivos, base de datos y tablas del nuevo sistema, para de
esta forma dar inicio al proceso de aceptación final, durante el cual, el sistema comenzará a
funcionar bajo la responsabilidad del departamento de operaciones y del usuario, por un lapso
determinado de tiempo llamado Periodo de Aceptación.
Finalizado el Periodo de Aceptación, se le dará al sistema la aprobación final, para que pase a
ser el sistema oficial.
FASE V

Producción y mantenimiento
Esta fase corresponde al Diseñar es la fase mas importante donde tosos los elementos del SI.
Están completos y se puede ejecutar el proyecto. Una vez que un sistema pasa a formar parte de
la vida diaria de la empresa, cada programa, cada procedimiento y cada estructura de datos se
convierte en una pieza del negocio que, como tal, deberá funcionar en forma constante, exacta y
confiable. L a operación del negocio ahora dependerá del funcionamiento del sistema, por lo
que las tareas de mantenimiento cobran vital importancia.
Durante la fase de mantenimiento, se ponen en práctica todas las políticas y los procedimientos
destinados a garantizar la operación continúa de los de los sistemas y a asegurar su uso
efectivo, con el fin, de que éstos se constituyan en una verdadera herramienta de apoyo al logro
de los objetivos estratégicos de la empresa (Llorens Fabregas)."

 Producción
Finalmente, en la etapa de producción se asegura que el sistema funcione correctamente en la
mayoría de los casos, y con intervención mínima de los administradores del sistema. Para esto
se realizan nuevas pruebas, se reevalúan los resultados y se hacen refinamientos del sistema,
los cambios necesarios deberán ser introducidos sin afectar a los usuarios, y deberá conseguirse
la máxima confianza de los usuarios. El resultado de esta etapa un sistema listo para su
operación.
 Mantenimiento
Luego que el nuevo sistema ha estado operando, el auditor de sistemas independiente de las
otras fases de la vida del sistema, revisará lo siguiente: Determinar si el programa ha logrado
los requerimientos de los objetivos, se debe prestar especial atención a la utilización y la
satisfacción de los usuarios finales, ellos constituirán un indicador excelente. Verificar que se
miden, analizan e informan adecuadamente a la gerencia los beneficios identificados con
el estudio de factibilidad. Revisar las solicitudes de cambios a los programas que se han
realizado, para evaluar el tipo de cambios que se exigen al sistema, el tipo de cambios puede
indicar problemas de diseño, programación o interpretación de los requerimientos de usuario.
Conclusiones Preliminares:
En la elaboración del desarrollo de esta unidad podemos evaluar la metodología utilizada por
Llorens Fabregas, una metodología estructurada basada en proyectos exitosos al igual que la
Laudon & Laudon, implementando valiosos métodos para el Diseño e implementación de un
SISTEMA DE INFORMACION, capaz de satisfacer las necesidades de las Organizaciones a
nivel Mundial.
Conclusión
El análisis de sistemas se realiza en una serie de pasos formales llamados Ciclo de Vida en el
Desarrollo de Sistemas, los cuales son utilizados típicamente para construir un sistema desde la
raíz o para hacer cambios notables en el mismo.
Existen diversas denominaciones para cada uno de estos pasos o fases del ciclo de vida de los
sistemas entre las cuales se encuentra la de Llorens Fabregas que nos permite desarrollar
sistemas de información en organizaciones de cualquier tipo a través de sus cinco fases
(requerimientos, análisis/diseño, construcción, pruebas, producción/mantenimiento). Esta
metodología ésta orientada a proyectos medianos y grandes.
Metodología
Llorens Fabregas

Autor:
Thais Londoño
Republica Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación Superior
Instituto Universitario Politécnico Santiago Mariño
Ciudad Ojeda Estado Zulia
Cátedra Análisis y Diseño de Sistemas

Comentarios
Para dejar un comentario, regístrese gratis o si ya está registrado, inicie sesión.

Trabajos relacionados
 Sobre la toma de decisiones de la Compañía de
Seguros Cigna
Descripción del proceso de toma de decisiones.
Análisis y evaluación de las decisiones. En este mundo
de hoy, en que la...
 Generalidades de un planeamiento estratégico
Sobre los objetivos estratégicos. Sobre La Misión.
Sobre La Visión. Sobre El Alcance. Gerentes. Calidad.
Organización...
 Henri Fayol
Nec y posibilidad de una enseñanza administrativa.
Importancia relativa de las diversas capacidades que
forman el valor...
Ver mas trabajos de Administracion y Finanzas

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas
formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede
descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com.
El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de
cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de
Monografias.com como fuentes de información.

Leer más: http://www.monografias.com/trabajos90/metodologia-desarrollo-sistema-informacion/metodologia-


desarrollo-sistema-informacion.shtml#ixzz4z8eg9YN4

1.3 Ciclo de desarrollo


El software es un elemento lógico, por lo que tiene unas
características muy diferentes a las del hardware:

El software se desarrolla, no se fabrica en el sentido


clásico de la palabra. Ambas actividades se dirigen a
la construcción de un "producto", pero los métodos
son diferentes. Los costes del software se encuentran
en la ingeniería, esto implica que los proyectos no se
pueden gestionar como si lo fueran de fabricación. A
mediados de la década de 1980, se introdujo el
concepto de "fábrica de software", que recomienda
el uso de herramientas para el desarrollo automático
del software.

Si se representa gráficamente la proporción de fallos


en función del tiempo, para el hardware se tiene la
figura conocida como "curva de bañera". Al principio
de su vida hay bastantes fallos (normalmente por
defectos de diseño y/o fabricación), una vez
corregidos se llega a un nivel estacionario (bastante
bajo). Sin embargo conforme pasa el tiempo,
aparecen de nuevo, por efecto de: mala calidad,
suciedad, malos tratos, temperaturas extremas y
otras causas. El hardware empieza a estropearse.

El software no se estropea. La gráfica de fallos en


función del tiempo, tendría forma de caída desde el
principio, hasta mantenerse estable por tiempo casi
indefinido. El software no es susceptible a los males
del entorno que provocan el deterioro del hardware.
Los efectos no detectados harán que falle el
programa durante las primeras etapas de su vida, sin
embargo una vez corregidas, no se producen nuevos
errores. Aunque no se estropea, si puede
deteriorarse. Esto sucede debido a los cambios que
se efectúan durante su vida.

Cuando un componente hardware se estropea, se


cambia por otro que actúa como una "pieza de
repuesto", mientras que para el software, no es
habitual este proceso, lo cual significa que el
mantenimiento de los programas es muy complejo.

La mayoría del software se construye a medida, en


vez de ensamblar componentes previamente
creados. Por contra en el hardware se dispone de
todo tipo de circuítos integrados, para fabricar de
manera rápida un equipo completo. Los ingenieros
de software no disponen de esta comodidad, aunque
ya se están dando los primeros pasos en esta
dirección, que facilitaria tanto el desarrollo de
aplicaciones informáticas.

La formalización del proceso de desarrollo se define como un


marco de referencia denominado ciclo de desarrollo del software
o ciclo de vida del desarrollo del software o ciclo de vida del
desarrollo. Se puede describir como, "el período de tiempo que
comienza con la decisión de desarrollar un producto software y
finaliza cuando se ha entregado éste". Este ciclo, por lo general
incluye las fases:
requisitos
diseño
implantación
prueba
instalación
aceptación

El ciclo de desarrollo software se utiliza para estructurar las


actividades que se llevan a cabo en el desarrollo de un producto
software. A pesar de que no hay acuerdo acerca del uso y la forma
del modelo, este sigue siendo útil para la comprensión y el control
del proceso.

Seguidamente se exponen las distintas aproximaciones de


desarrollo de software, en función del tipo de ciclo de vida:

A) Aproximación convencional

Se introdujo por Winston Royce en la década de 1970, como una


técnica rígida para mejorar la calidad y reducir los costos del
desarrollo de software. Tradicionalmente es conocido
como "modelo en cascada", porque su filosofía es completar cada
paso con un alto grado de exactitud, antes de iniciar el siguiente.

Esquemáticamente se puede representar de la siguiente forma:


donde:
FACTIBILIDAD: Definir un concepto preferente para el producto de
software y determinar su factibilidad de ciclo de vida y superioridad
frente a otros conceptos.

REQUERIMIENTOS: Elaborar una especificación completa y validada


de las funciones requeridas, sus interfaces y el rendimiento del
producto de software.

DISEÑO: Elaborar una especificación completa y validada de la


arquitectura global hardware-software, de la estructura de control y
de la estructura de datos del producto, así como un esquema de los
manuales de usuarios y planes de test.

DISEÑO DETALLADO: Elaborar una especificación completa y


verificada de la estructura de control, de la estructura de datos, de las
interfaces de relación, dimensionamiento y algoritmos claves de cada
componente de programa (rutina con un máximo de 100 instrucciones
fuentes).

CODIFICACION: Construir un conjunto completo y verificado de


componentes de programas.

INTEGRACION: Hacer funcionar el producto de software compuesto


de componentes de programa.

IMPLEMENTACION: Hacer funcionar el sistema global hardware-


software incluyendo conversión de programas y datos, instalación y
capacitación.

OPERACION Y MANTENCION: Hacer funcionar una nueva versión


del sistema global.

TRANSICION: Realizar una sucesión limpia de este a otros


eventuales productos.

En cada caso, "verificación" tienen la acepción: establecer la verdad


de la correspondencia entre un producto de software y su
especificación. Es decir: ¿ESTAMOS CONSTRUYENDO
CORRECTAMENTE EL PRODUCTO?

Los principales problemas que se han detectado en esta


aproximación son debidos a que se comienza estableciendo todos
los requisitos del sistema:
o En muchas ocasiones no es posible disponer de unas especificaciones
correctas desde el primer momento, porque puede ser difícil para el
usuario establecer al inicio todos los requisitos.

o En otras hay cambio de parecer de los usuarios sobre las necesidades


reales cuando ya se ha comenzado el proyecto, siendo probables los
verdaderos requisitos no se reflejen en el producto final
o Otro de los problemas de esta aproximación es que los resultados no se
ven hasta muy avanzado el proyecto, por lo tanto la realización de
modificaciones, si ha habido un error, es muy costosa.

Esta aproximación es la más empleada por los ingenieros


informáticos, aunque ha sido muy criticada, y de hecho se ha
puesto en duda su eficacia. Entre los problemas que se pueden
encontrar con este modelo, se tienen:
o Los proyectos raras veces siguen el modelo secuencial que se supone.
Los cambios pueden causar confusión.

o Es difícil disponer en principio de todos los requisitos. Este modelo


presenta dificultades en el momento de acomodar estas incertidumbres.

o La versión operativa de los programas no está disponible hasta que el


proyecto está muy avanzado. Un error importante puede ser desastroso,
si se descubre al final del proceso.

o Los responsables del desarrollo siempre se retrasan innecesariamente.


Algunos integrantes del equipo de desarrollo han de esperar a otros para
completar tareas pendientes.

B) Aproximación prototipo

Es habitual que en un proyecto software no se identifiquen los


requisitos detallados de entrada, procesamiento o salida. En otros
casos no se está seguro de la eficiencia de un algoritmo, o de la
forma en que se ha de implantar la interface hombre-máquina.

En casos así, lo habitual es construir un prototipo, que idealmente


sirviera como mecanismo para identificar los requisitos del
software. Esta aproximación consiste en realizar la fase de
definición de requisitos del sistema en base a estos tres factores:

o Un alto grado de iteración

o Un muy alto grado de participación del usuario

o Un uso extensivo de prototipos

Las premisas clave de esta aproximación son:


o Que los prototipos constituyen un medio mejor de comunicación que los
modelos en papel
o Que la iteración es necesaria para canalizar, en la dirección correcta, el
proceso de aprendizaje. Esta aproximación se enfoca a mejorar la
efectividad del proceso de desarrollo y no a mejorar la eficacia de ese
proceso.

o El problema, es que los usuarios finales, ven lo que parece ser una
versión de trabajo del software, sin considerar que no es la versión
definitiva y por lo tanto no se han considerado aspectos de calidad o
facilidad de mantenimiento. Cuando se les dice, que el producto es a
partir de entonces cuando se debe de empezar a "fabricar", no lo
entiende y empieza de nuevo con ajustes, lo cual hace este proceso muy
lento.
C) Aproximación evolutiva

En esta aproximación el énfasis está en lograr un sistema flexible


y que se pueda expandir de forma que se pueda realizar muy
rápidamente una versión modificada del sistema cuando los
requisitos cambien.

Se diferencia de la aproximación anterior, en que en esta los


requisitos cambian continuamente, lo cual implicaría en el caso
previo que las iteraciones no tendrían fin.

D) Aproximación incremental

Es un concepto muy parecido al de desarrollo evolutivo, y


frecuentemente comprendido en la aproximación del desarrollo
evolutivo. Se comienza el desarrollo del sistema para satisfacer
un subconjunto de requisitos especificados. Las últimas versiones
prevén los requisitos que faltan. De esta forma se logra una
rápida disponibilidad del sistema, que aunque incompleto, es
utilizable y satisface algunas de las necesidades básicas de
información.

La diferencia con la aproximación anterior es que en este caso


cada versión parte de una previa sin cambios pero con nuevas
funciones, mientras que la aproximación evolutiva cada vez se
desarrolla una nueva versión de todo el sistema.

Un ejemplo de este paradigma se tiene en el desarrollo de una


aplicación sencilla, como es un editor de textos. En el primer
incremento se podría desarrollar con un reducido conjunto de
funciones, como las funciones básicas de gestión de archivos. En
un segundo incremento, se puede incluir la gestión avanzada de
textos. Y en un tercer incremento se pondría la corrección
ortográfica.

E) Aproximación espiral

Nace con el objetivo de captar lo mejor de la aproximación


convencional y de la de prototipo, añadiendo un nuevo
componente, el análisis de riesgos.Esquemáticamente se puede
ilustrar mediante una espiral, con cuatro cuadrantes que definen
actividades.

En la primera vuelta de la espiral se definen los objetivos, las


alternativas y las restricciones y se analizan y se identifican los
riesgos. Si como consecuencia del análisis de riesgo se observa
que hay incertidumbre sobre el problema entonces en la actividad
correspondiente a la ingeniería se aplicará la aproximación
prototipo cuyo beneficio principal es el de reducir la incertidumbre
de la naturaleza del problema de información y los requerimientos
que los usuarios establecen para la solución a ese problema.

Al final de esta primera vuelta alrededor de la espiral el usuario


evalúa los productos obtenidos y puede sugerir modificaciones.
Se comenzaría avanzando alrededor del camino de la espiral
realizando las cuatro actividades indicadas a continuación. En
cada vuelta de la espiral, la actividad de ingeniería se desarrolla
mediante la aproximación convencional o ciclo de desarrollo en
cascada o mediante la aproximación de prototipos.

o Actividades

o Acciones

o Planificación Determinación de alternativas, identificación y resolución de


riesgos

o Ingeniería

o Desarrollo y verificación del producto de siguiente nivel

o Evaluación del cliente

o Valoración de los resultados del proceso de desarrollo

F) Aproximación basada en transformaciones

Con la aparición de las herramientas CASE junto con los


generadores de código, el ciclo de desarrollo software en cascada
ha cambiado a un ciclo de vida basado en transformaciones.

CASE (Computer Aided Software Engineering), en castellano


"Ingeniería de software Asistida por Computadora", es un
conjunto de métodos, utilidades y técnicas que facilitan la
automatización del ciclo de vida del desarrollo de sistemas de
información.

La utilización de herramientas CASE afecta a todas las fases del


ciclo de vida del software. Este ciclo de vida se puede considerar
como una serie de transformaciones. Primero se definen los
requisitos del sistema, seguidamente existe un proceso de
transformación que hace que la especificación se convierta en un
diseño lógico del sistema. Posteriormente, este sufre otro proceso
de transformación para lograr un diseño físico, es decir que
responda a la tecnología destino.

La tecnología CASE propone que estos procesos de


transformación sean lo más automatizables posible. Sus ventajas
son:
o Posibilidad de comprobación de errores en etapas iniciales de desarrollo

o Posibilidad de realizar el mantenimiento en el ámbito de especificación

o Soporte de rastreabilidad de los requisitos

o Soporte de reusabilidad

o Potencia la especificación orientada al problema

G) Programación extrema

La Programación Extrema (PX), mejor conocida por su nombre en


inglés "Extreme Programming" (XP), es una de las llamadas
Metodologias Agiles de desarrollo de software más exitosas de los
tiempos recientes. Cada día se genera incontable información
sobre el tema, generalmente en inglés; fue formulada por Kent
Beck, autor del primer libro sobre la materia,"Extreme
Programming Explained: Embrace Chang".

Las fundamentales del método son:

 Desarrollo iterativo e incremental


 Pruebas unitarias continuas,
 Programación por parejas de personas
 Frecuente interacción del equipo de programación con el
cliente
 Corrección de todos los errores antes de añadir nueva
funcionalidad.
 Refactorización del código
 Propiedad del código compartida
 Simplicidad en el código

Un ejemplo de un caso en el que se aplicó esta metodología fue


en la identificación mediante el ADN de las víctimas del atentado del
11 de septiembre de 2001 en Nueva York (EE.UU.)
El siguiente enlace ofrece una relación de tipos de herramientas
CASE.

Bibliografía de ampliación:

 Alonso Amo, F y Segovia Pérez, F. "Entornos y


metodologías de programación". Paraninfo, Madrid 1995

 Amescua Seco, Antonio de y otros "Ingeniería del software


de gestión. Análisis y diseño de aplicaciones" Paraninfo,
Madrid 1995

 McClure, Carma "CASE, la automatización del software".


Ra-ma. Madrid 1992

 Piattini, M. y otros "Análisis y diseño de aplicaciones


informáticas de gestión". RA-MA, Madrid 2004

 Pressman, Roge S. "Ingeniería del software. Un enfoque


práctico". 3ª ed. McGraw Hill, Madrid 1993

 Roda, José Luis y Brito, Julio. "Introducción a la ingeniería


del software". Gobierno de Canarias, 2001

 Somerville, Ian, "Ingeniería del software". Addison Wesley


Iberoamericana, Wilnington (EE.UU.) 1998

 Toval, Ambrosio y Nicolás, Joaquín. "Ingeniería del


software. Gestión de requisitos". DM-ICE, Murcia 1999

 Yourdon, E. "Análisis estructurado modeno". Prentice Hall,


EE.UU. 1995
Enlaces de interés:

- Cornegie Mellon University. Software Engineering Institute

- Guide to the Software Engineering Body of Knowledge

- ICTnet Comunidades. Ingeniería del software

- Rational software. IBM

- Secretaría del Consejo Superior de Informática y para el impulso de la


administración electrónica

Metodología RUP
La metodología RUP , abreviatura de Rational Unified Process (o Proceso Unificado
Racional), es un proceso propietario de la ingeniería de software creado por Rational
Software , adquirida por IBM , ganando un nuevo nombre Irup que ahora es una
abreviatura Rational Unified Process y lo que es una marca en el área de
software, proporcionando técnicas que deben seguir los miembros del equipo de
desarrollo de software con el fin de aumentar su productividad en el proceso
de desarrollo.
La metodología RUP utiliza el enfoque de la orientación a objetos en su diseño y está
diseñado y documentado el uso de la notación UML ( Unified Modeling Language ) para
ilustrar los procesos en acción. Utiliza técnicas y prácticas probadas comercialmente.
Es un proceso considerado pesado y preferentemente aplicable a grandes equipos de
desarrollo y grandes proyectos , pero el hecho de que es ampliamente personalizable que
permite adaptarse a proyectos de cualquier escala.

Para la gestión del proyecto , la metodología RUP proporciona una solución disciplinada
como las tareas y responsabilidades señaladas dentro de una organización de desarrollo de
software.
RUP es, en sí, un producto de software. Es modular y automatizado, y toda su metodología
se apoya en varias herramientas de desarrollo integradas y vendidos por IBM a través de
sus “Suites racional.”

Los métodos de la competencia en el campo de la ingeniería de software incluyen ” salas


blancas ” (considerado pesado) y ágil (luz) como Extreme Programming (Programación
XP-Extreme), Scrum , FDD y otros.

Contenido
 1 Directrices de la metodología RUP
o 1.1 Requisitos de gestión
o 1.2 El uso de una arquitectura basada en componentes
o 1.3 El uso de modelos visuales de software en la metodología RUP
o 1.4 Comprobar la calidad del software
o 1.5 Software de gestión y de cambio de control
 2 Fases de la metodología RUP
o 2.1 Fase de diseño
o 2.2 Fase de elaboración
o 2.3 Fase de construcción
o 2.4 Fase de transición
 3 Disciplinas de la metodología RUP
o 3.1 Seis Disciplinas de Ingeniería de Software
o 3.2 Tres Disciplinas Soporte / Servicio de la metodología RUP
 4 Principios y las mejores prácticas de la metodología RUP
o 4.1 Desarrollo iterativo
o 4.2 La gestión de requisitos
o 4.3 El uso de una arquitectura basada en componentes
o 4.4 Software de modelado visual
o 4.5 Software de control de calidad
o 4.6 Control de cambios en el software
DIRECTRICES DE LA METODOLOGÍA RUP
RUP define las siguientes líneas maestras y los esqueletos ( plantillas ) para los miembros
del personal de un ciclo de producción: parte del cliente, y una evaluación de los avances
del proyecto por su gestión. Ayuda a los desarrolladores para mantener la concentración en
el proyecto.

REQUISITOS DE GESTIÓN
La documentación apropiada es esencial para cualquier proyecto de gran envergadura; en
cuenta que RUP describe cómo documentar la funcionalidad, las limitaciones del sistema,
restricciones de diseño y requisitos de negocio.

Los casos de uso (en Inglés Casos de uso ) y los escenarios son ejemplos de artefactos de
proceso dependiente, que se han considerado mucho más eficaz en la captura de requisitos
funcionales.

EL USO DE UNA ARQUITECTURA BASADA EN COMPONENTES


La arquitectura basada en componentes crea un sistema que puede ser fácilmente
extensible, promoviendo la reutilización y el software una comprensión intuitiva. Un
componente se refiere normalmente a un objeto en la programación orientada a objetos.

RUP proporciona una manera sistemática para construir este tipo de sistema, centrándose
en la producción de una arquitectura ejecutable en las primeras etapas del proyecto, es
decir, antes de comprometer recursos a gran escala.

Estos componentes se incluyen normalmente en las infraestructuras existentes, tales como


CORBA y COM (Component Object Model).
EL USO DE MODELOS VISUALES DE SOFTWARE EN
LA METODOLOGÍA RUP
Al abstraer la programación de su código y representarla utilizando bloques de construcción
gráficas, RUP puede una manera eficaz de conseguir una visión general de una solución.

El uso de modelos visuales también puede permitir que los individuos menos perfil técnico
(como clientes) tienen una mejor comprensión de un problema dado, y así estar más
involucrados en el proyecto en su conjunto.

El lenguaje de modelado UML se ha convertido en un estándar de la industria para


representar los proyectos, y es ampliamente utilizado por RUP!

COMPROBAR LA CALIDAD DEL SOFTWARE


No asegura la calidad del software es el fallo más común en todos los proyectos de sistemas
informáticos. Por lo general, uno piensa en la calidad del software después de la
finalización de los proyectos, o la calidad es la responsabilidad de un equipo de desarrollo
de equipo diferente.

RUP tiene como objetivo ayudar en el control de la planificación de la calidad,


comprobando que en la construcción de todo el proceso y la participación de todos los
miembros del equipo de desarrollo.

SOFTWARE DE GESTIÓN Y DE CAMBIO DE CONTROL


En todos los proyectos de software de la existencia del cambio es inevitable. RUP define
métodos para controlar y vigilar los cambios. Como un pequeño cambio puede afectar a las
aplicaciones de maneras totalmente impredecibles, el control de cambio es esencial para el
éxito de un proyecto.

RUP también define las áreas de trabajo y seguridad , lo que garantiza un programador que
cambia en otro sistema no afectará a su sistema.

FASES DE LA METODOLOGÍA RUP


Hasta ahora estas líneas guía son generales, para ser adherido a pasar por la vida de un ciclo
de proyecto. Las fases (ver figura abajo) indican el énfasis se da en el proyecto en un
instante dado. Para capturar la dimensión temporal de un proyecto, RUP divide el proyecto
en cuatro fases diferentes:
 Iniciación o Diseño : énfasis en el alcance del sistema;
 Preparación : énfasis en la arquitectura;
 Construcción : énfasis en el desarrollo;
 Transición : énfasis en la aplicación.
 RUP se basa también en las 4 Ps:
 Personas
 Diseño
 Producto
 Proceso
Las capas se componen de iteraciones. Iteraciones son ventanas de tiempo; iteraciones han
definido término como las fases son objetivos.

Todas las fases generan artefactos. Estos serán utilizados en la siguiente fase y documentar
el proyecto y permite un mejor seguimiento.

FASE DE DISEÑO
La fase de diseño o de iniciación contiene los flujos de trabajo necesarios para el acuerdo
de las partes interesadas – interesados – con los objetivos, la arquitectura y la planificación
del proyecto. Si estos actores tienen un buen conocimiento, no será necesario analizar. De
lo contrario, se requiere un análisis más elaborado.

En esta etapa, los requisitos esenciales del sistema se transforman en los casos de uso . El
objetivo no es para cerrarlas en absoluto, sino sólo las que sean necesarias para dar forma a
la opinión.

El paso es generalmente corto y se utiliza para definir si es factible para continuar con el
proyecto y definir los riesgos y el coste de la última. Un prototipo se puede hacer para que
el cliente apruebe. Como cita el RUP, lo ideal es realizar iteraciones , las cuales deben estar
bien definida en cuanto a su importe y objetivos.

FASE DE ELABORACIÓN
La preparación será para el diseño del sistema, como complemento de la encuesta y / o
documentación de casos de uso, frente a la arquitectura del sistema, revisar el modelo de
negocio para el proyecto e iniciar la versión del manual del usuario. Uno debe aceptar:

Descripción del producto (aumento + integración) es estable;? El plan del proyecto es


fiable?; Los costos son elegibles?

FASE DE CONSTRUCCIÓN
En la fase de construcción, el desarrollo físico del software se inicia, códigos de
producción, pruebas alfa. pruebas beta se llevaron a cabo al inicio de la fase de transición.

Se debe aceptar las pruebas, procesos estables y de prueba, y el código del sistema son
“línea de base”.

FASE DE TRANSICIÓN
En esta fase es la entrega ( “despliegue”) de software, que se lleva a cabo el plan de
despliegue y entrega, el seguimiento y la calidad del software. Productos (lanzamientos, las
versiones) se van a entregar, y coloque la satisfacción del cliente. Esta etapa también se
lleva a cabo la formación de los usuarios.

DISCIPLINAS DE LA METODOLOGÍA RUP


SEIS DISCIPLINAS DE INGENIERÍA DE SOFTWARE
LA DISCIPLINA MODELADO DE NEGOCIO
Las organizaciones dependen cada vez más de los sistemas de TI , por lo que es imperativo
que los ingenieros de sistemas de información saben cómo se integran las aplicaciones en el
desarrollo de la organización. Las empresas invierten en TI, que entienden la ventaja
competitiva del valor añadido por la tecnología.

El objetivo de modelado de negocio es establecer primero una mejor comprensión y


comunicación entre ingeniería de negocios y la ingeniería de software.

Comprender el negocio significa que los ingenieros de software deben entender la


estructura y la dinámica de la empresa objetivo (el cliente), los problemas actuales de la
organización y las posibles mejoras. También deben asegurar una comprensión común de la
organización de destino entre los clientes, usuarios finales y desarrolladores.

El modelado de negocios explica cómo describir la visión de una organización en la que se


implementará el sistema y cómo utilizar esta visión como base para describir los procesos,
funciones y responsabilidades.

REQUISITOS DEL CURSO


Este curso explica cómo al llegar peticiones de las partes interesadas ( “partes interesadas”)
y los convierten en un conjunto de requisitos que los productos funcionan dentro del
sistema que se construirán y proporcionar los requisitos detallados para lo que es necesario
que el sistema.

ANÁLISIS Y DISEÑO DE LA DISCIPLINA ( “DISEÑO”)


El propósito del análisis y diseño es mostrar cómo se llevará a cabo el sistema. El objetivo
es construir un sistema que:

Ejecutar en un entorno de ejecución específica, las tareas y las funciones especificadas en


las descripciones de casos de uso

Satisfacer todas sus necesidades

Es fácil de mantener cuando no son cambios en los requisitos funcionales, los resultados
del proyecto en un modelo de análisis y diseño tiene opcionalmente un modelo de análisis.
El modelo de diseño sirve como una abstracción del código fuente, es decir, el proyecto
sirve como modelo de “retroalimentación” de la forma en que el código fuente está
estructurado y escrito.

El modelo de diseño consta de clases de diseño estructurados en paquetes y subsistemas


con interfaces bien definidas, en representación de lo que se convertirá componentes de la
aplicación. También contiene descripciones de cómo los objetos de estas clases colaboran
para llevar a cabo el diseño de casos de uso.

LA DISCIPLINA IMPLEMENTACIÓN
Los efectos de la aplicación son:

 Para configurar el código de la organización en términos de subsistemas de aplicación


organizados en capas
 Para llevar a cabo las clases y objetos en términos de componentes (archivos de código fuente,
binarios, ejecutables, etc.)
 Para probar los componentes desarrollados como unidades
 Incorporar los resultados producidos por los ejecutores individuales (o equipos), en un sistema
ejecutable
Los sistemas se logran a través de los componentes de la aplicación. El proceso describe
cómo reutilizar componentes existentes o implementar nuevos componentes con
responsabilidades bien definidas, haciendo que el sistema sea más fácil de mantener y
aumentar las posibilidades de reutilización.

PRUEBA DE DISCIPLINA
Los fines de disciplina prueba son:

Comprobar la interacción entre los objetos


Comprobar la correcta integración de todos los componentes de software
Compruebe que todos los requisitos han sido ejecutadas correctamente
Identificar y asegurar que los defectos se tratan antes de la implementación de software
Asegúrese de que todos los defectos son corregidos, revisados y cerrados

El Rational Unified Process propone un enfoque iterativo, lo que significa que debería estar
probando el proyecto en su totalidad. Esto le permite encontrar defectos tan pronto como
sea posible, lo que reduce drásticamente el costo de reparar el defecto.

Las pruebas se realizan a lo largo de cuatro dimensiones de la calidad: fiabilidad,


funcionalidad, rendimiento de las aplicaciones y el rendimiento del sistema . Para cada una
de estas dimensiones de la calidad, el proceso se describe cómo a pasar la prueba de la
planificación, diseño, implementación, ejecución y evaluación.

LA DISCIPLINA IMPLEMENTACIÓN
El propósito del despliegue es producir lanzamientos de productos exitosos y entregar el
software a los usuarios finales. Abarca una amplia gama de actividades, incluyendo la
producción de versiones de software externos, el envase de aplicaciones de software y de
negocios, distribución de software, instalación de software y proporcionar ayuda y
asistencia a los usuarios.

Aunque las actividades de despliegue se centran principalmente en torno a la transición,


muchas de las actividades se deben incluir en las etapas anteriores para preparar la
aplicación, al final de la fase de construcción. Los procesos ( “flujos de trabajo”) de
“Implementación y Medio Ambiente” RUP contienen menos detalles que otros flujos de
trabajo.

TRES DISCIPLINAS SOPORTE / SERVICIO DE


LA METODOLOGÍA RUP
DISCIPLINA PARA EL MEDIO AMBIENTE
El medio ambiente se centra en las actividades necesarias para configurar el proceso para
un proyecto. En él se describen las actividades necesarias para desarrollar directrices para
apoyar un proyecto.

La propuesta de las actividades ambientales es proporcionar a los procesos de organización


de desarrollo de software y herramientas que apoyarán al equipo de desarrollo. Si los
usuarios no entienden que RUP RUP es un marco de proceso, pueden percibirlo como un
proceso engorroso y costoso. Sin embargo, un concepto clave en las RUP era la lata RUP y,
a menudo debe ser refinado.

Esto se hizo inicialmente de forma manual, es decir, un documento “caso del complejo”
escrito que especifica el proceso de refinado para ser utilizado. Más tarde, IBM producto
Compositor Método Racional fue creado para ayudar a hacer este paso simple, ingenieros
de proceso y los directores de proyectos podría más fácilmente personalizar el RUP para
sus necesidades del proyecto.
Muchas de las variaciones posteriores de las regiones ultraperiféricas, incluidas OpenUP /
Basic, el código abierto, versión ligera de RUP, se presentan ahora como procesos
separados en su propio derecho, y atender a los diferentes tipos y tamaños de proyectos,
tendencias y tecnologías de desarrollo de software.

Históricamente, como el RUP es a menudo la medida para cada proyecto por un experto en
procesos RUP, el éxito global del proyecto puede ser algo dependiente de la capacidad de
esta persona.

CONFIGURACIÓN DE LA DISCIPLINA Y DE LA GESTIÓN


La disciplina de la gestión del cambio en el negocio con RUP abarca tres tratamientos
específicos: configuración, solicitudes de cambio, y el estado y de medida.
La gestión de configuración: gestión de la configuración es responsable de la
estructuración sistemática de productos. Los artefactos tales como documentos y modelos
necesitan estar bajo el control de versiones y estos cambios deben ser visibles. También
realiza un seguimiento de las dependencias entre los artefactos de manera que todos los
artículos relacionados se actualizan cuando se realizan cambios
La gestión del cambio de solicitud: Durante el proceso de desarrollo del sistema con
muchos artefactos que existen varias versiones. El CRM realiza un seguimiento de los
cambios propuestos
El estado y la medición de la gestión: las solicitudes de cambio tienen los estados: nuevo ,
conectado , aprobado , asignado y completa . La solicitud de cambio también tiene atributos
como la causa raíz, o la naturaleza (como el incumplimiento y recuperación), prioridad, etc.
Estos estados y atributos se almacenan en la base de datos para producir informes útiles
sobre el progreso del proyecto. Racional también tiene un producto para mantener las
solicitudes de cambio llamados ClearQuest . Esta actividad tiene procedimientos a seguir
PROYECTO DE GESTIÓN DE LA DISCIPLINA
La planificación del proyecto en el RUP se produce en dos niveles. Hay un grano fino o
planes de fase que describe el proyecto en su totalidad, y un número de alta granularidad o
planes de iteración que describe los pasos iterativos.

Este curso se centra principalmente en los aspectos importantes de un proceso de desarrollo


iterativo: La gestión de riesgos; La planificación de un proyecto iterativo a través del ciclo
de vida y para una iteración en particular; Y el proceso de seguimiento de un proyecto
iterativo, la métrica. Sin embargo, esta disciplina de RUP no pretende cubrir todos los
aspectos de la gestión de proyectos.

Por ejemplo, no cubre cuestiones tales como:

 Gestión de personas: contratación, formación, etc.


 Presupuesto general: definición, asignación, etc.
 Gestión de contratos: con los proveedores, clientes, etc.
PRINCIPIOS Y LAS MEJORES PRÁCTICAS DE
LA METODOLOGÍA RUP
La metodología RUP se basa en un conjunto de principios de desarrollo de software y las
mejores prácticas, por ejemplo:
1. Desarrollo de software iterativo
2. La gestión de requisitos
3. El uso de una arquitectura basada en componentes
4. Software de modelado visual
5. La verificación de la calidad del software
6. Control de cambios en el software
DESARROLLO ITERATIVO
Teniendo en cuenta el tiempo necesario para desarrollar un software grande y sofisticada,
no se puede definir el problema y construir software en un solo paso. Los requisitos
cambiarán a menudo en el curso del desarrollo del proyecto , debido a las restricciones de
la arquitectura , las necesidades del usuario o para una mayor comprensión del problema
original.

Los cambios permiten que el proyecto para estar constantemente refinada, y la señal a los
elementos del proyecto de alto riesgo como las tareas de mayor prioridad. Idealmente, al
final de cada iteración habrá una versión ejecutable , lo que ayuda a reducir el riesgo de
configuración de diseño, que permite una mayor respuesta de los usuarios y ayudar al
desarrollador a permanecer centrado.

RUP utiliza el desarrollo iterativo e incremental por las siguientes razones:


 La integración se hace paso a paso durante el proceso de desarrollo, cada paso se limita a unos
pocos elementos
 La integración es menos complejo, reduciendo el coste y aumentar la eficiencia
diseño de las piezas por separado y / o implementación pueden ser fácilmente identificados
para su posterior reutilización
 Requisitos cambios son registrados y pueden ser acomodados
 Los riesgos se abordan en el comienzo del desarrollo y cada iteración permite la verificación
de riesgos ya percibidas y la identificación de nuevos
 Para la arquitectura de software se mejora a través de un repetidor scrutinize
El uso de iteraciones, un proyecto tendrá un plan general, así como varios planes de
iteración. La participación de las partes interesadas a menudo se alienta a cada entrega. En
esta forma, las entregas sirven como una manera de conseguir el compromiso de los
involucrados, mientras que también promueve una comparación constante entre las
necesidades y el desarrollo de la organización a los conflictos que surjan.

LA GESTIÓN DE REQUISITOS
La gestión de requisitos en RUP se centra en encontrar el final – el usuario necesita para la
identificación y especificación de lo que necesita y la identificación de lo que debe ser
cambiado. Esto trae los siguientes beneficios:

La corrección de los requisitos genera la corrección del producto, por lo que se satisfacen
las necesidades de los usuarios.
se incluirán las características requeridas, lo que reduce el costo de los acontecimientos
posteriores.
RUP sugiere que la administración de requerimientos tiene que seguir las actividades:

 Análisis de los problemas es que de acuerdo con el problema y crear medidas que probarán
su valor para la organización
 La comprensión de las necesidades de sus grupos de interés es para compartir el problema
y los valores con los principales interesados y elevar lo que las necesidades están involucrados
en el desarrollo de la idea
 La definición del problema es la definición de las características de las necesidades y el
diseño de los casos de uso , actividades que mostrarán fácilmente los requisitos de alto nivel y
el esquema modelo de uso del sistema
 Administrar el alcance del sistema es el alcance de los cambios que se comunica con base en
el progreso y los resultados seleccionados en el orden en que los diagramas de flujo de los
casos de uso son atacados
 Refinar los ajustes del sistema de ofertas con los detalles de los diagramas de flujo de casos
de uso con las partes interesadas con el fin de crear una especificación de las aplicaciones de
software que puede servir como un contrato entre su grupo y el cliente y puede guiar las
actividades de ensayo y proyecto
 Los requisitos de gestión del cambio es la forma de identificar las llegadas de los cambios en
las aplicaciones en un proyecto que ya ha comenzado
EL USO DE UNA ARQUITECTURA BASADA EN COMPONENTES
La arquitectura basada en componentes crea un sistema que es fácilmente extensible,
intuitiva y fácil de entender y promueve la reutilización de software.

Un componente de frecuencia asociado con un conjunto de objetos en objetos –


programación orientada .
Arquitectura de software aumenta en importancia cuando un sistema se hace más grande y
más compleja. RUP se centra en la producción de arquitectura básica en los primeros
pocos iteraciones. Esta arquitectura se convierte en un prototipo en los ciclos iniciales de
desarrollo.
La arquitectura desarrollada en cada iteración para convertirse en la arquitectura final del
sistema. RUP también propuso reglas de diseño y limitaciones para capturar normas de
arquitectura. Para el desarrollo iterativo es posible para identificar gradualmente
componentes que a continuación se pueden desarrollar o comprado reutilizada. Estos
componentes se construyen a menudo en las infraestructuras existentes, tales como
CORBA y COM o Java EE , o PHP
SOFTWARE DE MODELADO VISUAL
Haciendo abstracción de su programación de su código y representarla por medio de
bloques de construcción gráficas constituye una forma eficaz de obtener una visión general
de una solución. El uso de esta representación, los recursos técnicos pueden determinar la
mejor manera de poner en práctica un conjunto dado de interdependencias lógicas .

Esto también crea una capa intermedia entre el proceso de negocio y el código necesario a
través de tecnología de la información. Un modelo en este contexto es una pantalla y al
mismo tiempo una simplificación de un diseño complejo. RUP especifica qué modelos son
necesarios y por qué.
El Lenguaje de Modelado Unificado (UML) se puede utilizar para el modelado de casos
de uso , diagramas de clases y otros objetos. RUP también analiza otras formas de construir
estos modelos.
SOFTWARE DE CONTROL DE CALIDAD
Aseguramiento de la calidad del software es el punto de fallo más común en los proyectos
de software , ya que esto es a menudo algo que no se había pensado anteriormente y, a
veces es tratado por diferentes equipos. RUP ayuda en la planificación del control de
calidad y se encarga de su construcción en todos los procesos de participación de todos los
miembros del equipo.
No es una tarea está dirigida específicamente a la calidad ; RUP supone que cada miembro
del equipo es responsable de la calidad durante todo el proceso. El proceso se centra en el
descubrimiento de el nivel esperado de la calidad y proporciona pruebas en los procesos
para medir este nivel.
CONTROL DE CAMBIOS EN EL SOFTWARE
En todos los proyectos de software, los cambios son inevitables. RUP define métodos para
controlar, seguir y supervisar estos cambios. RUP define también el trabajo seguro de
espacios (espacios de trabajo seguros en inglés), lo que garantiza que un sistema de
ingeniería de software no se ve afectada por los cambios en otros sistemas. Este concepto es
pegar bien con arquitecturas de software basados en componentización.

tiempo hemos hablado acerca de las distintas metodologías del desarrollo de software, sin
embargo la cantidad de información que les hemos presentado puede resultar un poco
bochornosa, no por el hecho de que no sea de calidad, si no porque en ocasiones podemos
estar buscando algo más sintetizado, algo más resumido, lo más objetivo es por eso que a
continuación hablaremos de las principales metodologías del desarrollo de software pero sin
entrar en profundidad en cada una de ellas solamente las explicaremos con brevedad.

Contenido
 1 Metodologías del desarrollo de software
 2 Que es una metodología
o 2.1 Metodología en cascada
o 2.2 Método de prototipo
o 2.3 El modelo incremental
o 2.4 Modelo en espiral

Metodologías del desarrollo de software


Que es una metodología
Bueno, una metodología es como su nombre indica la forma o, la forma en que se realiza
algo o el método con el cual se llevará a cabo el proceso de desarrollo de software, en este
caso.
Aunque no lo creas existen una gran cantidad de metodologías y desde hace una gran cantidad
de tiempo ha existido diversas opiniones que habla acerca de qué metodología es mejor, cual
es recomendable de usar y qué metodología ofrece mejores resultados, etcétera.

Y es que básicamente una metodología consiste en seguir al pie de la letra los pasos que está
tiene asignados para llevar a cabo el proceso, mediante el cual se creará un programa o
sistema o cualquier tipo de software

Ahora mismo o saber cuáles son las principales metodologías para que tengas más o menos
una idea veremos esas metodologías de antaño las cuales fueron creadas desde un principio
y qué han ido evolucionando de forma realmente impresionante creando metodologías
nuevas Pero va a estar siempre en las principales que son las quedamos a ver a continuación.
Metodología en cascada
El método de cascada es una de las metodologías más antiguas que podemos encontrar Y
aunque su desarrollador nunca me mencionó como tal el nombre de supuesto debido a que el
proceso en el cual se desarrollan software es lineal

Para que tengas una idea más clara te lo mostraré a continuación sus fases de desarrollo son
las siguientes

 Análisis de requisitos
 Diseño de sistema
 Diseño de programa
 Modificación
 Ejecución de pruebas
 Codificación
 Mantenimiento
Sin embargo, el problema no es que tenga muchas fases nada Eso el verdadero inconveniente
con la metodología lineal es que una vez que pasas un proceso no puedes volver a la fase
anterior.

Método de prototipo
El método de prototipos posiblemente uno de los métodos más interesantes que podemos
encontrar resumiendo los de una mejor manera debe saber qué consiste básicamente en la
elaboración de un prototipo antes de pasar a lo que se desarrolló es decir creamos una interfaz
de desarrollo un sistema en modo prueba y se le permite al cliente que vea la versión Así si
al cliente le gusta entonces continuamos con el procedimiento o bien que vayamos tras tras
y se realice un prototipo nuevo

Las fases del desarrollo en el método productivo son las siguientes

 Planeación
 Modelado
 Elaboración del prototipo
 Desarrollo entrega
 Retroalimentación
 Comunicación con el cliente
 Entrega del producto final

Con esto estaríamos completando lo que es el método de prototipos ahora pasamos a ver lo
que es el modelo incremental

El modelo incremental
Sin Duda uno de los métodos que se han utilizado aún en nuestros tiempos es el método
incremental Pero en qué consiste

El modelo incremental es básicamente una combinación de los dos primeras metodologías


de acabamos de ver especificamente, los encontramos frente a una serie de fases lineales pero
con la diferencia de que una vez completas 1 fase el ciclo puede volver a empezar y realizar
una iteración. Más sin embargo ahora tú y tu equipo de desarrolladores ya contaran con una
base que fue creada en la primera iteración, por eso el método se le denomina incremental,
porque conforme avanza de iteración tendrás una serie de código fuente listo para ser
utilizado y al mismo tiempo lo puedes utilizar como un prototipo por eso mencionaba que
utilizan ambas metodologías

Las fases del modelo incremental son las siguientes

 Inicializacion
 Periodos de iteración
 Lista de control
y listo así como te darás cuenta a diferencia de la lineal y de prototipos esta metodología
combina ambas creando prototipos en cada fase para que estos puedan ser utilizados.

Modelo en espiral
El modelo de espiral hace uso de los procesos de la misma forma en que los utiliza el modelo
de cascada es decir utiliza las mismas fases sin embargo modelo a diferencia de ese modelo
antiguo el modelo en cascada se revoluciona

Pero porque digo que se revoluciona es que básicamente el modelo en espiral o tienes a las
mismas fases pero le da igual el orden incluso utilizamos lo que son los prototipos para ir
avanzando en espiral de esta forma nuestro ciclo de vida del Software ir avanzando y
avanzando cada vez más como si fuera un espiral estás solución las fases del modelo en
espiral

 Determinar objetivo
 Análisis de riesgo
 Desarrollar validar
 Probar
 Planificación

Y como te mencionaba con el modelo espiral, Una vez que se cumple un ciclo puedes volver
a empezar utilizando el prototipo que acabas de crear y se vuelve un círculo vicioso que
posiblemente no tenga final. Esa puede ser una de sus desventajas sin embargo si lo ves por
el lado positivo el Software que realice siempre podrá tener avances actualizaciones
modificaciones y todo lo que se requiere de hacer más adelante. Obviamente con tu cliente
eso deberá tener un costo extra pero eso ya es una pendiente de cada programador.

Por el momento ha sido todo, pero qué te parece si nos compartes en redes sociales, nos dejas
un like, nos Sigues en Facebook o en Twitter y de esta forma nos estarás ayudando de una
gran manera, ahora que si deseas leer un artículo mucho más profundo acerca de
las metodologías del desarrollo de software te dejo en enlace aquí en final del artículo