jueves, 19 de abril de 2012

INTRODUCCION A LA INGENIERIA DE SOFTWARE


DEFINICIONES DE LA INGENIERIA DE SOFTWARE




Este término fue introducido a finales de los 60 a raíz de la crisis del software.

Esta crisis fue el resultado de la introducción de la tercera generación del hardware.

QUE ES LA INGENIERIA DE SOFTWARE?... MIRALO AQUI

El hardware dejo de ser un impedimento para el desarrollo de la informática; redujo los costos y mejoro la calidad y eficiencia en el software producido

La crisis se caracterizo por los siguientes problemas:

    Imprecisión en la planificación del proyecto y estimación de los costos.
    Baja calidad del software.
    Dificultad de mantenimiento de programas con un diseño poco estructurado, etc.

Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en la compra.

Tambien se requiere una serie de características como fiabilidad, facilidad de mantenimiento y de uso, eficiencia, etc.

PARA MAS INFORMACION

OBJETIVOS
2. Objetivos de la ingeniería de software

En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la ingeniería de software.

    mejorar la calidad de los productos de software
    aumentar la productividad y trabajo de los ingenieros del software.
    Facilitar el control del proceso de desarrollo de software.
    Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.
    Definir una disciplina que garantice la producción y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.

Objetivos de los proyectos de sistemas

Para que los objetivos se cumplan las empresas emprenden proyectos por las siguientes razones: "Las cinco C "

Capacidad

Las actividades de la organización están influenciadas por la capacidad de ésta para procesar transacciones con rapidez y eficiencia.

Los sistemas de información mejoran esta capacidad en tres formas.

* Aumentan la velocidad de procesamiento:

Los sistemas basados en computadora pueden ser de ayuda para eliminar la necesidad de cálculos tediosos y comparaciones repetitivas.

Un sistema automatizado puede ser de gran utilidad si lo que se necesita es un procesamiento acelerado.

*Aumento en el volumen:

La incapacidad para mantener el ritmo de procesamiento no significa el abandono de los procedimientos existentes. Quizá éstos resulten inadecuados para satisfacer las demandas actuales. En estas situaciones el analista de sistemas considera el impacto que tiene la introducción de procesamiento computarizado, si el sistema existente es manual. Es poco probable que únicamente el aumento de la velocidad sea la respuesta. El tiempo de procesamiento por transacción aumenta si se considera la cantidad de actividades comerciales de la empresa junto con su patrón de crecimiento.

* Recuperación más rápida de la información:

Las organizaciones almacenan grandes cantidades de datos, por eso, debe tenerse en cuenta donde almacenarlos y como recuperarlos cuando se los necesita.

Cuando un sistema se desarrolla en forma apropiada, se puede recuperar en forma rápida la información.

Costo

* Vigilancia de los costos:

Para determinar si la compañía evoluciona en la forma esperada, de acuerdo con lo presupuestado, se debe llevar a cabo el seguimiento de los costos de mano de obra, bienes y gastos generales.

La creciente competitividad del mercado crea la necesidad de mejores métodos para seguir los costos y relacionarlos con la productividad individual y organizacional.

* Reducción de costos:

Los diseños de sistemas ayudan a disminuir los costos, ya que toman ventaja de las capacidades de cálculo automático y de recuperación de datos que están incluidos en procedimientos de programas en computadora. Muchas tareas son realizadas por programas de cómputo, lo cual deja un número muy reducido de éstas para su ejecución manual, disminuyendo al personal.

Control

*Mayor seguridad de información:

Algunas veces el hecho de que los datos puedan ser guardados en una forma adecuada para su lectura por medio de una máquina, es una seguridad difícil de alcanzar en un medio ambiente donde no existen computadoras.

Para aumentar la seguridad, generalmente se desarrollan sistemas de información automatizados. El acceso a la información puede estar controlado por un complejo sistemas de contraseñas, limitado a ciertas áreas o personal, si está bien protegido, es difícil de acceder.

*Menor margen de error: (mejora de la exactitud y la consistencia)

Esto se puede lograr por medio del uso de procedimientos de control por lotes, tratando de que siempre se siga el mismo procedimiento. Cada paso se lleva a cabo de la misma manera, consistencia y con exactitud: por otra parte se efectúan todos los pasos para cada lote de transacciones. A diferencia del ser humano, el sistema no se distrae con llamadas telefónicas, ni olvidos e interrupciones que sufre el ser humano. Si no se omiten etapas, es probable que no se produzcan errores.

Comunicación

La falta de comunicación es una fuente común de dificultades que afectan tanto a cliente como a empleados. Sin embargo, los sistemas de información bien desarrollados amplían la comunicación y facilitan la integración de funciones individuales.

* Interconexión: ( aumento en la comunicación)

Muchas empresas aumentan sus vías de comunicación por medio del desarrollo de redes para este fin, dichas vías abarcan todo el país y les permiten acelerar el flujo de información dentro de sus oficinas y otras instalaciones que no se encuentran en la misma localidad.

Una de las características más importantes de los sistemas de información para oficinas es la transmisión electrónica de información, como por ejemplo, los mensajes y los documentos.

* Integración de áreas en las empresas:

Con frecuencia las actividades de las empresas abarcan varias áreas de la organización, la información que surge en un área se necesita en otra área, por ejemplo.

Los sistemas de información ayudan a comunicar los detalles del diseño a los diferentes grupos, mantienen las especificaciones esenciales en un sitio de fácil acceso y calculan factores tales como el estrés y el nivel de costos a partir de detalles proporcionados por otros grupos.

COMPETITIVIDAD

Los sistemas de información computacionales son un arma estratégica, capaz de cambiar la forma en que la compañía compite en el mercado, en consecuencia éstos sistemas mejoran la organización y la ayudan a ganar "ventaja competitiva", sin embargo, si los competidores de la compañía tienen capacidades mas avanzadas para el procesamiento de información, entonces los sistemas de información pueden convertirse en una "desventaja competitiva".

Una organización puede ganar ventaja competitiva a través de sus sistemas de información de diferentes formas.

* Asegurar clientes:

Como los clientes son los más importante para una organización, los directivos buscan diferentes formas para conseguir nuevos clientes y mantener los que tienen. Para eso las empresas proporcionan:

1- Mejores precios

2- Servicios exclusivos.

3- Productos diferentes.

La ventaja en precios se observa continuamente en la actividad comercial (sí el producto es exclusivo o distinto entonces tener el liderazgo en precios bajos quizás no sea el objetivo a alcanzar).

La estrategia eficaz de precios a menudo se alcanza al desarrollar sistemas de información por razones tales como reducción de costos y ganancia en la exactitud.

Generalmente cuando una compañía puede ofrecer servicios exclusivos y atraer clientes, es posible que los competidores no sean capaces de atraer a los clientes de la compañía.

* Dejar fuera a los competidores:

Pasar sobre los competidores puede ser un inconveniente si ellos se encuentran la forma para duplicar los logros de la compañía, los sistemas de información pueden ser la base para dejar fuera del mercado a la competencia ya sea el disuadir sus intentos por ingresar al mercado o creándoles obstáculo para su entrada.

*Mejores acuerdos con los proveedores:

En los negocios, los proveedores también tienen importancia estratégica. Una manera de utilizar los sistemas de información para favorecer arreglos con los proveedores es ofreciendo un mejor precio. Disminuyendo los costos.

*Formar bases para nuevos productos

Los sistemas de información también forman la base de muchos productos y servicios nuevos.

Los servicios de base de datos experimentan un crecimiento común en todas las industrias.

Productos que van desde programas personales hasta planes de construcción pueden hacerse a la medida del cliente gracias al procesamiento de información.

Una cosa es clara, es necesario que los sistemas entren en operación y que trabajen de manera confiable.

ESTRATEGIAS

Los sistemas de información basados en computadoras sirven para diversas finalidades que van desde el procesamiento de las transacciones de una empresa hasta proveer de la información necesaria para decidir sobre asuntos que se presentan con frecuencia.

En algunos casos los factores que deben considerarse en un proyecto de sistema de información, como el aspecto más apropiado de la computadora o la tecnología de comunicaciones que se va a utilizar, el impacto del nuevo sistema sobre los empleados de la empresa y las características específicas que el sistema debe tener se pueden determinar de manera secuencial. Todas estas situaciones están determinadas por tres métodos básicos:

miércoles, 18 de abril de 2012

UML: HISTORIA Y OBJETIVOS


HISTORIA DE UML
El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología del software).
El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML.
Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir.
UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. Un sistema se modela como una colección de objetos discretos que interactúan para realizar un trabajo que finalmente beneficia a un usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas de modelado e incorporar las mejores prácticas actuales en un acercamiento estándar.
UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores de código de UML para una gran variedad de lenguaje de programación, así como construir modelos por ingeniería inversa a partir de programas existentes.
La notación UML se deriva y unifica las tres metodologías de análisis y diseños más extendidas.
Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.
Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object - Modelling Technique).
Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos de uso (use case).
El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacob son y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE.
De las tres metodologías de partida, las de Bco. y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y colaboración.
Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG, que es también el origen de CORBA, el estándar líder en la industria para la programación de objetos distribuidos.
En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el diseño orientado a objetos.
UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño. Se trata pues de un meta-modelo auto-referencial (cualquier lenguaje de modelado de propósito general debería ser capaz de modelarse a sí mismo).
OBJETIVOS DE UML
Durante el desarrollo del UML sus autores tuvieron en cuenta:
Proporcionar una notación y semánticas suficientes para poder alcanzar una gran cantidad de aspectos del modelado contemporáneo de una forma directa y económica.
Proporcionar las semánticas suficientes para alcanzar aspectos del modelado que son de esperar en un futuro, como por ejemplo aspectos relacionados con la tecnología de componentes, el cómputo distribuido, etc.
Proporcionar mecanismos de extensión de forma que proyectos concretos puedan extender el meta-modelo a un coste bajo.
Proporcionar mecanismos de extensión de forma que aproximaciones de modelado futuras podrían desarrollarse encima del UML.
Permitir el intercambio del modelos entre una gran variedad de herramientas.
Proporcionar semánticas suficientes para especificar las interfaces a bibliotecas para la comparición y el almacenamiento de componentes del modelo.
Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir.
UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.
UML no pretende ser un método de desarrollo completo.
Debe ser un lenguaje universal, como cualquier lenguaje de propósito general.
Imponer un estándar mundial.
Proporcionar a los usuarios un lenguaje de modelado visual expresivo y utilizable para el desarrollo e intercambio de modelos significativos.
Proporcionar mecanismos de extensión y especialización.
Ser independiente del proceso de desarrollo y de los lenguajes de programación.
Proporcionar una base formal para entender el lenguaje de modelado.
Fomentar el crecimiento del mercado de las herramientas OO.
Soportar conceptos de desarrollo de alto nivel como pueden ser colaboraciones, frameworks, patterns, y componentes.
El UML debe entenderse como un estándar para modelado y no como un estándar de proceso software. Aunque UML debe ser aplicado en el contexto de un proceso, la experiencia ha mostrado que organizaciones diferentes y dominios del problema diferentes requieren diferentes procesos. Por ello se han centrado los esfuerzos en un meta-modelo común (que unifica las semánticas) y una notación común que proporcione una representación de esas semánticas. De todas formas, los autores de UML fomentan un proceso guiado por casos de uso, centrado en la arquitectura, iterativo e incremental. Bajo estas líneas genéricas proponen el proceso software definido en una de las extensiones del UML (Objectory Extension for Software Enginnering) , pero en general el proceso software es fuertemente dependiente de la organización y del dominio de aplicación



ELEMENTOS DE ANOTACIÓN UML


ELEMENTOS DE ANOTACION
 Los elementos de anotación son las partes explicativas de los modelos UML. Son comentarios que se pueden aplicar para describir, clasificar y hacer observaciones sobre cualquier elemento de un modelo.
 El tipo principal de anotación es la nota que simplemente es un símbolo para mostrar restricciones y comentarios junto a un elemento o un conjunto de elementos
 Relaciones
 Existen cuatro tipos de relaciones entre los elementos de un modelo UML. Dependencia, asociación, generalización y realización, estas se describen a continuación
  
     Dependencia
 Es una relación semántica entre dos elementos en la cual un cambio a un elemento  (el elemento independiente) puede afectar a la semántica del otro elemento (elemento dependiente). Se representa como una línea discontinua, posiblemente dirigida, que a veces incluye una etiqueta.
 Asociación
 Es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregación es un tipo especial de asociación y representa una relación estructural entre un todo y sus partes. La asociación se representa con una línea continua, posiblemente dirigida, que a veces incluye una etiqueta. A menudo se incluyen otros adornos para indicar la multiplicidad y roles de los objetos involucrados
 Generalización
 Es una relación de especialización / generalización en la cual los objetos del elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta forma, el hijo comparte la estructura y el comportamiento del padre. Gráficamente, la generalización se representa con una línea con punta de flecha vacía.
 Realización
 Es una relación semántica entre clasificadores, donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de realización en dos sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan. La realización se representa como una mezcla entre la generalización y la dependencia, esto es, una línea discontinua con una punta de flecha vacía.

CONCEPTOS Y MODELOS DE UML


HISTORIA DE UML
El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología del software).
El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML.
Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir.
UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. Un sistema se modela como una colección de objetos discretos que interactúan para realizar un trabajo que finalmente beneficia a un usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas de modelado e incorporar las mejores prácticas actuales en un acercamiento estándar.
UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores de código de UML para una gran variedad de lenguaje de programación, así como construir modelos por ingeniería inversa a partir de programas existentes.
La notación UML se deriva y unifica las tres metodologías de análisis y diseños más extendidas.
Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.
Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object - Modelling Technique).
Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos de uso (use case).
El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacob son y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE.
De las tres metodologías de partida, las de Bco. y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y colaboración.
Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG, que es también el origen de CORBA, el estándar líder en la industria para la programación de objetos distribuidos.
En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el diseño orientado a objetos.
UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño. Se trata pues de un meta-modelo auto-referencial (cualquier lenguaje de modelado de propósito general debería ser capaz de modelarse a sí mismo).
OBJETIVOS DE UML
Durante el desarrollo del UML sus autores tuvieron en cuenta:
Proporcionar una notación y semánticas suficientes para poder alcanzar una gran cantidad de aspectos del modelado contemporáneo de una forma directa y económica.
Proporcionar las semánticas suficientes para alcanzar aspectos del modelado que son de esperar en un futuro, como por ejemplo aspectos relacionados con la tecnología de componentes, el cómputo distribuido, etc.
Proporcionar mecanismos de extensión de forma que proyectos concretos puedan extender el meta-modelo a un coste bajo.
Proporcionar mecanismos de extensión de forma que aproximaciones de modelado futuras podrían desarrollarse encima del UML.
Permitir el intercambio del modelos entre una gran variedad de herramientas.
Proporcionar semánticas suficientes para especificar las interfaces a bibliotecas para la comparición y el almacenamiento de componentes del modelo.
Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir.
UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.
UML no pretende ser un método de desarrollo completo.
Debe ser un lenguaje universal, como cualquier lenguaje de propósito general.
Imponer un estándar mundial.
Proporcionar a los usuarios un lenguaje de modelado visual expresivo y utilizable para el desarrollo e intercambio de modelos significativos.
Proporcionar mecanismos de extensión y especialización.
Ser independiente del proceso de desarrollo y de los lenguajes de programación.
Proporcionar una base formal para entender el lenguaje de modelado.
Fomentar el crecimiento del mercado de las herramientas OO.
Soportar conceptos de desarrollo de alto nivel como pueden ser colaboraciones, frameworks, patterns, y componentes.
El UML debe entenderse como un estándar para modelado y no como un estándar de proceso software. Aunque UML debe ser aplicado en el contexto de un proceso, la experiencia ha mostrado que organizaciones diferentes y dominios del problema diferentes requieren diferentes procesos. Por ello se han centrado los esfuerzos en un meta-modelo común (que unifica las semánticas) y una notación común que proporcione una representación de esas semánticas. De todas formas, los autores de UML fomentan un proceso guiado por casos de uso, centrado en la arquitectura, iterativo e incremental. Bajo estas líneas genéricas proponen el proceso software definido en una de las extensiones del UML (Objectory Extension for Software Enginnering) , pero en general el proceso software es fuertemente dependiente de la organización y del dominio de aplicación



CICLO DE VIDA RUP


Ciclo de vida

Esfuerzo en actividades según fase del proyecto.
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea Base) de la arquitectura.
Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.
Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementación de la nueva versión del producto.
En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina varía.
Principales características

Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
Pretende implementar las mejores prácticas en Ingeniería de Software
Desarrollo iterativo
Administración de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificación de la calidad del software
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

METODOLOGÍA RUP: INTRODUCCION Y PRINCIPIOS DE DESARROLLO


Introducción
El Proceso Unificado de Rational (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 con las 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...

Principios de desarrollo
El RUP está basado en 6 principios clave que son los siguientes:
Adaptar el proceso
El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subformal.
Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados
Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.
Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

METODO DEL CICLO DE VIDA


MÉTODO DEL CICLO DE VIDA CLÁSICO

El método del ciclo de vida para desarrollo de sistemas es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información.

El método del ciclo de vida para el desarrollo de sistemas consta de las siguientes actividades:

1) Investigación preliminar

La solicitud para recibir ayuda de un sistema de información pueden originarse por una persona, cuando se formula la solicitud comienza la primera actividad del sistema. Esta actividad tiene tres partes:

*Aclaración de la solicitud

Antes de considerar cualquier investigación de sistemas, la solicitud de proyecto debe examinarse para determinar con precisión lo que el solicitante desea; ya que muchas solicitudes que provienen de empleados y usuarios no están formuladas de manera clara.

*Estudio de factibilidad

En la investigación preliminar un punto importante es determinar que el sistema solicitado sea factible. Existen tres aspectos relacionados con el estudio de factibilidad, que son realizados por los general por analistas capacitados o directivos:

-Factibilidad técnica.

Estudia si el trabajo para el proyecto, puede desarrollarse con el software y el personal existente, y si en caso de necesitar nueva tecnología, cuales son las posibilidades de desarrollarla (no solo el hardware).

-Factibilidad económica.

Investiga si los costos se justifican con los beneficios que se obtienen, y si se ha invertido demasiado, como para no crear el sistema si se cree necesario.

-Factibilidad operacional:

Investiga si será utilizado el sistema, si los usuarios usaran el sistema, como para obtener beneficios.

* Aprobación de la solicitud

Algunas organizaciones reciben tantas solicitudes de sus empleados que sólo es posible atender unas cuantas. Sin embargo, aquellos proyectos que son deseables y factibles deben incorporarse en los planes. En algunos casos el desarrollo puede comenzar inmediatamente, aunque lo común es que los miembros del equipo de sistemas estén ocupados en otros proyectos. Cuando esto ocurre, la administración decide que proyectos son los más importantes y el orden en que se llevarán acabo.

Después de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades de personal

2) Determinación de los requisitos del sistema.

Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a ciertas preguntas claves.

Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los procesos de la empresa. Cuando no es posible entrevistar, en forma personal a los miembros de grupos grandes dentro de la organización, se emplean cuestionarios para obtener esta información.

Las investigaciones detalladas requieren el estudio de manuales y reportes, la observación en condiciones reales de las actividades del trabajo y, en algunas ocasiones, muestras de formas y documentos con el fin de comprender el proceso en su totalidad.

Reunidos los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las características que debe tener el nuevo sistema.

3) Diseño del sistema.(diseño lógico)

El diseño de un sistema de información responde a la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis.

Es común que los diseñadores hagan un esquema del formato o pantalla que esperan que aparezca cuando el sistema esta terminado, se realiza en papel o en la pantalla de una terminal utilizando algunas de las herramientas automatizadas disponibles para el desarrollo de sistemas.

También se indican los datos de entrada, los que serán calculados y los que deben ser almacenados. Los diseñadores seleccionan las estructuras de archivo y los dispositivos de almacenamiento. Los procedimientos que se escriben indican cómo procesar los datos y producir salidas.

Los documentos que contienen las especificaciones de diseño representan a éste mediante diagramas, tablas y símbolos especiales.

La información detallada del diseño se proporciona al equipo de programación para comenzar la fase de desarrollo de software.

Los diseñadores son responsables de dar a los programadores las especificaciones de software completas y claramente delineadas.

4) Desarrollo de software (diseño físico).

Los encargados de desarrollar software pueden instalar software comprado a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.

Los programadores son responsables de la documentación de los programas y de explicar su codificación, esta documentación es esencial para probar el programa y hacer el mantenimiento.

5) Prueba de sistemas.

Durante esta fase, el sistema se emplea de manera experimental para asegurarse que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjuntos de datos de prueba para su procesamiento y después se examinan los resultados. En ocasiones se permite que varios usuarios utilicen el sistema, para que los analistas observen si tratan de emplearlo en formas no previstas, antes de que la organización implante el sistema y dependa de él.

En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribió los programas originales; para asegurarse de que las pruebas sean completas e imparciales y, por otra, que el software sea más confiable.

6) Implantación y evaluación.

La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla.

Cada estrategia de implantación tiene sus méritos de acuerdo con la situación que se considere dentro de la empresa. Sin importar cuál sea la estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas.

Los sistemas de información deben mantenerse siempre al día, la implantación es un proceso de constante evolución.

La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

    Evaluación operacional

Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.

    Impacto organizacional

Identificación y medición de los beneficios para la organización en áreas como finanzas (costos, ingresos y ganancias), eficiencia operacional e impacto competitivo.

- Opinión de los administradores

Evaluación de las actitudes de directivos y administradores dentro de la organización así como de los usuarios finales.

  

DESEMPEÑO DEL DESARROLLO EN EL CICLO DE VIDA


  DESEMPEÑO DEL DESARROLLO

La evaluación del proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos.

Cuando la evaluación de sistema se conduce en forma adecuada proporciona mucha información que puede ayudar a mejorar la efectividad de los esfuerzos cuando la evaluación de sistemas se conduce en forma adecuada proporciona mucha información que puede ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes.

MÉTODO DE DESARROLLO POR ANÁLISIS ESTRUCTURADO

Muchos especialistas en sistemas de información reconocen la dificultad de comprender de manera completa sistemas grandes y complejos. El método de desarrollo del análisis estructurado tiene como finalidad superar esta dificultad por medio de:

    la división del sistema en componentes y
    la construcción de un modelo del sistema.

El método incorpora elementos tanto de análisis como de diseño

El análisis estructurado se concentra en especificar lo que se requiere que haga el sistema o la aplicación. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento, etc.). Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.

El análisis estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Éste análisis permite al analista conocer un sistema o proceso en una forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente.

Componentes

Símbolos gráficos: Iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes.

Diccionario de datos: descripción de todos los datos usados en el sistema. Puede ser manual o automatizado.

Descripciones de procesos y procedimientos: declaraciones formales que usan técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.

Reglas: estándares para describir y documentar el sistema en forma correcta y completa.

Diseño Estructurado.

El diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software.

El objetivo del Diseño Estructurado es programas formados por módulos independientes unos de otros desde el punto de vista funcional.

El Diseño Estructurado es una técnica específica para el diseño de programas.

La herramienta fundamental del Diseño Estructurado es el diagrama estructurado que es de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo). Los Diagramas Estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.

Análisis de flujo de datos.

Estudia el empleo de los datos para llevar a cabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas usa los diagrama de flujos de datos y los diccionarios de datos.

Herramientas

Las herramientas muestran todas las características esenciales del sistema y la forma en que se ajustan entre si, como es muy difícil entender todo un proceso de la empresa en forma verbal, las herramientas ayudan a ilustrar los componentes esenciales de un sistema, junto con sus acciones.

Diagrama de flujo de datos

Es el modelo del sistema. Es la herramienta mas importante y la base sobre la cual se desarrollan otros componentes.

El modelo original se detalla en diagramas de bajo nivel que muestran características adicionales del sistema. Cada proceso puede desglosarse en diagramas de flujos de datos cada vez más detallados. Repitiéndose esta secuencia hasta que se obtienen suficientes detalles para que el analista comprenda la parte del sistema que se encuentra bajo investigación.

El diagrama físico de datos da un panorama del sistema en uso, dependiente de la implantación, mostrando cuales tareas se hacen y como son hechas. Incluyen nombres de personas, nombres o números de formato y documento, nombres de departamentos, archivos maestro y de transacciones, equipo y dispositivos utilizados, ubicaciones, nombres de procedimientos.

El diagrama lógico de datos da un panorama del sistema, pero a diferencia del físico es independiente de la implantación, que se centra en el flujo de datos entre los procesos, sin considerar los dispositivos específicos y la localización de los almacenes de datos o personas en el sistema. Sin indicarse las características físicas.

Notaciones: son cuatro símbolos, que fueron desarrollados y promovidos la mismo tiempo por dos organizaciones: Yourdon y Gane y Sarson.

Flujo de datos: son movimientos de datos en una determinada dirección, desde un origen hasta un destino. Es un paquete de datos.

Yourdon Gane y Sarson

Proceso: son personas, procedimientos o dispositivos que utilizan o producen datos. No identifica el componente físico

Fuente o destino de los datos: pueden ser personas, programas, organizaciones u otras entidades que interactúan con el sistema pero que se encuentre fuera.

Almacenamiento de datos: es un lugar donde se guardan los datos. El almacenamiento de datos puede representar dispositivos tanto computarizados como no computarizados.

Cada componente en un diagrama de flujo de datos tiene una etiqueta con un nombre descriptivo. Los nombres de los procesos reciben un numero para poder identificarlos, este numero tiene un valor adicional cuando se estudian los componentes que integran un proceso especifico