miércoles, 25 de julio de 2012


Fundamentos del Enfoque Orientado a Objetos
El enfoque orientado a objeto esta constituido por los siguientes fundamentos:

Abstracción
Es aquel fundamento que revela las características y comportamiento de un objeto.

Encapsulamiento
Permite el ocultamiento de una información , pero los datos de este no son conocidos fuera de el, es decir esconde los detalles y muestra lo relevante y define los atributos y métodos de cada clase o objeto a través del modo de acceso que son:publico , privado y protegido , el cual cumple un papel fundamental para el encapsula miento.

Modularidad
Es aquella que accede a dividir el programa en diversas parte , con el propósito que esa partes divididas sean independiente del programa.

Herencia
Consiste en que de una clase se obtiene atributos de otra clase.

Polimorfismo
Este trata sobre la asociación que existe entre objetos que tienen diferentes funciones.

Componente
Un componente es una unidad de composición de aplicaciones de software, que posee un conjunto de interfaces y un conjunto de requisitos, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio.

Características de un Componente

  • Identificable: Debe tener una identificación que permita acceder fácilmente a sus servicios.
  • Auto contenido: Un componente no debe requerir de la utilización de otros para finiquitar la función para la cual fue diseñado.
  • Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore.
  • Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a lo largo de su implementación.
  • Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementación sí.
  • Bien Documentado: Un componente debe estar correctamente documentado para facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
  • Es genérico: Sus servicios deben servir para varias aplicaciones.
  • Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación. Independiente de la plataforma: Hardware, Software,

En cuanto al desarrollo de componente este permite realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión, también proporciona el marco de trabajo técnico para un modelo de proceso e incorpora muchas de las características del modelo en espiral, sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software.
Entre los principales beneficios que este ofrece se encuentra la reutilización del software, la simplificación de las pruebas entre otros.

Estándares en el Proceso de Desarrollo de Software
Algunas de estas soluciones intentan sistematizar o formalizar la desorganizada tarea de desarrollar software. Otros aplican técnicas de gestión de proyectos para la creación del software. Si los proyectos de software corren el riesgo de demorarse o consumir un presupuesto mayor que el planeado. Dada la cantidad de proyectos de software que no cumplen sus metas en términos de funcionalidad, costes o tiempo de entrega.

Planificación
La importante tarea a la hora de crear un producto de software es obtener los requisitos o el análisis de estos requisitos. Los clientes suelen tener una idea más bien abstracta del resultado final, pero no sobre las funciones que debería cumplir el software. Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un análisis del ámbito del desarrollo.

Implementación, pruebas y documentación
La implementación es parte del proceso en el que los ingenieros de software programan el código para el proyecto, por otra parte están las pruebas del software la cual es el proceso de desarrollo del software. Esta parte del proceso tiene la función de detectar los errores que este tiene lo antes posible. La documentación del software cumple con el objetivo de facilitar su mejora.

Despliegue y mantenimiento
El despliegue comienza cuando el código ha sido suficientemente probado, para su liberación y ha sido distribuido en el entorno de producción, también esta el entrenamiento y soporte para el software ya que este es de suma importancia para muchos desarrolladores de software. Por otra parte esta el mantenimiento el cual mejora al software con problemas recientemente desplegado puede requerir más tiempo que el desarrollo inicial del software.

Codificar y corregir
Este modelo es utilizado en los inicios del desarrollo de software. Contiene dos pasos los cuales son:
  • Escribir código.
  • Corregir problemas en el código.
Estos dos pasos tratan de implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento.
Este tiene tres problemas principales:
  • Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos.
  • Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara.
  • El código es difícil de reparar por su pobre preparación para probar y modificar.
Modelo en cascada
Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso. El modelo en cascada consta de las siguientes fases:
1. Definición de los requisitos
2. Diseño de software
3.Implementación y pruebas unitarias
4. Integración y pruebas del sistema
5.Operación y mantenimiento

Cada una de estas fase tiene como resultado los documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas.

Desarrollo evolutivo
La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en varias versiones hasta que se desarrolle el sistema adecuado. Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

Este contiene dos tipos de desarrollo evolutivo que son:
  • Desarrollo Exploratorio:
  • Enfoque utilizando prototipos
Documentación
La documentación es un aspecto importante y fundamental durante el desarrollo de un software, ya que permite plasmar cada una de las fases del ciclo de vida del mismo, generadas por cada uno de los actores que participan en la creación de un sistema y que desempeñan diversos roles, tales como los arquitectos, diseñadores, analistas, programadores, entre otros, los cuales son quienes especifican los distintos aspectos y el proceso del producto.
El código fuente del software, la estructura de datos y los enlaces de comunicaciones forma parte de la documentación presente en productos e instalaciones informáticos.

Artefactos
Se dice que un artefacto son los productos tangibles como el documento, modelo o parte de la información que resulta durante el proceso en la construcción de un software, algunos de estos artefactos son los elementos que componen los modelos y productos, como glosarios y diccionarios, diagramas de caso de uso , especificación de Requisitos, clases o subsistemas, estos permiten comprender mejor tanto el análisis como el diseño del sistema.
En ocasiones un artefacto puede referirse a un producto terminado, como el código fuente o el ejecutable, pero habitualmente se refiere a la documentación generada a lo largo del desarrollo del producto en lugar del producto en sí.
Metodología RUP
El Rational Unified Process o Proceso Unificado de Racional. Es un proceso de ingeniería de software que suministra un enfoque para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es asegurar la producción de software de alta calidad que satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto previsible. Es una metodología de desarrollo iterativo enfocada hacia “los casos de uso, manejo de riesgos y el manejo de la arquitectura”.

El RUP mejora la productividad del equipo ya que permite que cada miembro del grupo sin importar su responsabilidad específica acceda a la misma base de datos de conocimiento. Esto hace que todos compartan el mismo lenguaje, la misma visión y el mismo proceso acerca de cómo desarrollar software.
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.
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.
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.

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
Consiste en dominar diversos conceptos por parte del equipo con el fin de discutir las dimensiones de cada uno de los temas. 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.

Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada sistema sino en todos los aspectos de la producción. Para así medir la calidad del software y determinar si cumple con las funcionalidades especificadas por el programador y evaluar las cualidades.

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
Fases
  • Establece oportunidad y alcance
  • Identifica las entidades externas o actores con las que se trata
  • Identifica los casos de uso
La estructura dinámica de RUP es la que permite que éste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:

Fase de Inicio
Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.

Modelado del negocio
  • En esta fase el equipo se familiarizará más al funcionamiento de la empresa, sobre conocer sus procesos.
  • Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado.
  • Entender el problema actual en la organización objetivo e identificar potenciales mejoras.
  • Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización objetivo.

Requisitos
En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos.
  • Establecer y mantener un acuerdo entre clientes y otros sobre lo que el sistema podría hacer.
  • Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.
  • Definir el ámbito del sistema.
  • Proveer una base para estimar costos y tiempo de desarrollo del sistema.
  • Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.
Fase de elaboración
En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.

Análisis y Diseño
En esta actividad se especifican los requerimientos y se describen sobre como se van a implementar en el sistemas

  • Transformar los requisitos al diseño del sistema.
  • Desarrollar una arquitectura para el sistema.
  • Adaptar el diseño para que sea consistente con el entorno de implementación.
Fase de Desarrollo
El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.

Implementación
Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás. El resultado final es un sistema ejecutable.

  • Planificar qué subsistemas deben ser implementados y en qué orden deben ser integrados, formando el Plan de Integración.
  • Cada implementador decide en qué orden implementa los elementos del subsistema.
  • Si encuentra errores de diseño, los notifica.
  • Se integra el sistema siguiendo el plan.

Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino que debe ir integrado en todo el ciclo de vida.

  • Encontrar y documentar defectos en la calidad del software.
  • Generalmente asesora sobre la calidad del software percibida.
  • Provee la validación de los supuestos realizados en el diseño y especificación de requisitos por medio de demostraciones concretas.
  • Verificar las funciones del producto de software según lo diseñado.
  • Verificar que los requisitos tengan su apropiada implementación.
Fase de Cierre
El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con todas las especificaciones.

Despliegue
Esta actividad tiene como objetivo producir con éxito distribuciones del producto y distribuirlo a los usuarios. Las actividades implicadas incluyen:

  • Probar el producto en su entorno de ejecución final.
  • Empaquetar el software para su distribución.
  • Distribuir el software.
  • Instalar el software.
  • Proveer asistencia y ayuda a los usuarios.
  • Formar a los usuarios y al cuerpo de ventas.
  • Migrar el software existente o convertir bases de datos

Implementación del RUP para el proyecto
La metodología RUP es más apropiada para proyectos grandes (Aunque también pequeños), dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios.

No hay comentarios:

Publicar un comentario