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.
El
RUP está basado en 6 principios clave que son los siguientes:
El
proceso deberá adaptarse a las necesidades del cliente ya que es muy
importante interactuar con él.
Los
requisitos de los diversos participantes pueden ser diferentes,
contradictorios o disputarse recursos limitados. Debe
encontrarse un equilibrio que satisfaga los deseos de todos.
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.
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.
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
- 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
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