Objetivos en el Desarrollo de Software

u Entender qué es el proceso de desarrollo de software

u Cuáles son los componentes que debe considerar un proceso de desarrollo de software

u Modelos de proceso de desarrollo de software

u Calidad del proceso de desarrollo de software

Conceptos Importantes

u Personas: los que trabajan

u Producto: lo que se obtiene

u Proyecto: la pauta a seguir para desarrollar un producto

u Proceso: la pauta a seguir para desarrollar un proyecto

Prototipos

En los modelos clásicos se insiste en las actividades de revisión de resultados al final de cada fase para evitar la vuelta atrás, que no se contempla de una forma organizada y resulta muy costosa. Están orientados a una forma de desarrollo lineal.

u Prototipo: es un sistema auxiliar que permite probar experimentalmente soluciones parciales a los requisitos del sistema

Para que el coste de desarrollo del prototipo sea bajo en relación al del sistema final podemos:

u Limitar las funciones

u Limitar su capacidad

u Limitar su eficiencia

u Evitar limitaciones de diseño, utilizando un hardware más potente que el que ejecutará el sistema final

u Reducir la parte a desarrollar

Ventajas

u Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.

u También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

Desventajas

u El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.

u En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final…

Prototipos Desechables

u Esta clase de prototipos se construyen lo más rápido posible, implementándose únicamente aquellos requerimientos que estén pobremente comprendidos. No tiene sentido considerar la implementación de los requerimientos totalmente entendidos, pues esto acarrea ningún tipo de conocimiento adicional y sí una pérdida de tiempo y recursos.

u Los prototipos desechables se usan experimentalmente, para estudiar cuáles requerimientos son reales y cuáles no, desechándose una vez que se ha obtenido la información deseada. Entonces, se escribe la especificación de requerimientos del software, incorporando lo que se aprendió, y se construye el sistema real basado en esa especificación.

u Funcionan muy bien en forma aislada, para verificar partes relativamente pequeñas de problemas complejos.

Prototipos Evolutivos

u Estos prototipos se construyen siguiendo un proceso de calidad, incluyendo especificación de requerimientos, documentación de diseño y prueba rigurosas, e implementan únicamente requerimientos confirmados; de esta forma se evita el implementar aquellos requerimientos débilmente entendidos, cuando se sabe que después del prototipo se van a conocer mejor.

u Los prototipos evolutivos también se usan experimentalmente, pero para determinar cuáles requerimientos existen y de los cuales no se había pensado en un comienzo. Entonces, este nuevo conocimiento debe ser usado para modificar la especificación de los requerimientos ya conocidos, y el sistema debe ser rediseñado, (probablemente) re-implementado en algunas partes y vuelto a probar. Bajo este enfoque, el proceso completo se puede repetir varias veces.

u Los prototipos evolutivos funcionan bien cuando la mayoría de las funciones críticas están bien entendidas.

Ventajas de la POO

Facilita la creación de software de calidad pues sus características potencian:

• La mantención
• La extensión
• La reutilización del software generado bajo este paradigma

La POO se basa en la

Metodología Abstracción

u El modelo define una perspectiva abstracta del problema

u Los datos que son afectados

u Las operaciones que se aplican sobre los datos

Conceptos de la POO

La POO trata de aproximarse al modo de actuar del hombre y no al de la máquina

Conceptos fundamentales que sustentan la POO:

• Clase, Objeto, Instancia, Atributos, Métodos.

Clase

Una clase es como un tipo de dato creado por el usuario, que posee dos categorías de miembros: Atributos (Datos) ⇒ Estado, Métodos (Algoritmos) ⇒ Comportamiento

Instancias-Objetos

Una Instancia es una ocurrencia de la clase, Al momento de crear un objeto se produce la instanciación, Un Objeto es una instancia de una Clase específica.

Atributos

Son los datos que caracterizan a los objetos de una clase y determinan el estado de un objeto: marca año color etc.

Métodos

Representan todas aquellas acciones que se pueden realizar sobre un objeto de cierta clase. En la implementación, estos métodos son segmentos de código en la forma de funciones. La clase Vehículo puede incluir los métodos: frenar, acelerar etc.

Principios de la POO

Ø Propiedades, que lo llevan a ser un estilo de desarrollo que permite crear código re-utilizable: Encapsulamiento Herencia Polimorfismo

Encapsulamiento: Proceso por el que se ocultan:

• Las estructuras de datos
• Los detalles de la implementación

Permite considerar a los objetos como «cajas negras», evitando que otros objetos accedan a detalles que NO LES INTERESA

Una vez creada la clase, las funciones usuarias no requieren conocer los detalles de su implementación

u Herencia: Permite reutilizar código creando nuevas clases a partir de las existentes (construidas y depuradas)

u Compromete una relación de jerarquía.

u Una nueva clase se generará agregando atributos y/o código a una clase existente

u Una clase (derivada) puede heredar de otra clase (base): atributos y métodos

Etiquetas: desarrollo de software, encapsulamiento, herencia, Polimorfismo, POO, Programación Orientada a Objetos, Prototipos