Proceso de desarrollo de software:

Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Aunque un proyecto de desarrollo  de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido.

A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción.

Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea.

Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del  sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.).

Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares.

Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo.

Fundamentos del enfoque orientado  a objeto:

    

  El paradigma orientado a objetos se basa en el concepto de objeto.

Un objeto es aquello que tiene estado (propiedades más valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los demás objetos. La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstracción, la "esencia" de un objeto, tal como son. De aquí que un objeto no es una clase, sin embargo, una clase puede ser un objeto.

En el enfoque orientado a objeto las propiedades del objeto son claves. Los principios del modelo OO son: abstracción, encapsulación, modularidad y jerarquía, fundamentalmente, y en menor grado tipificación (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.

·Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros.

·Encapsulación. En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus características esenciales.

·Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.

·Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles.

·Tipificación. Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida.

· Concurrencia. Es la propiedad que distingue un objeto que está activo de uno que no lo está.

·Persistencia. Es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado).   

 Desarrollo de componentes software:

Este proceso implica la adaptación o desarrollo de componentes con el propósito expreso de ser reutilizados en futuras aplicaciones. Su objetivo es producir repositorios de activos que puedan ser reutilizados en el desarrollo de software.

Tipos de componentes:

Frameworks :

Los frameworks de componentes proporcionan servicios que soportan un modelo de componentes. Estos modelos de componentes son patrones que permiten interactuar entres si de acuerdo al problema que resuelven y permiten la extensibilidad del framework y su funcionalidad, estos son aplicados a dominios específicos, lo cual hace que el framework también lo sea,

Bussines Component:

Los componentes de negocio, son aquellos componentes especializados en prestar alguna clase de servicio, enfocado a un dominio en particular. Los componentes de negocio son aquellos componentes que generan el valor agregado y se enfocan a las necesidades de los clientes.

Característica de los componentes:

Los componente debe tener las siguientes características:

●Un componente puede ser implementado mediante cualquier lenguaje de  programación, aunque los lenguajes orientados a objetos son especialmente adecuados para este fín.

●Se distribuye en un único paquete instalable que contiene en sí todo lo necesario para su funcionamiento, con ninguna o  muy pocas dependencias con otros componentes o librerías

●Puede estar implementado en cualquier lenguaje de  programación y ser utilizado también para el desarrollo en cualquier lenguaje de  programación

●Normalmente es un producto comercial de calidad, realizado por un fabricante especializado. Por supuesto pueden existir  componentes gratuitos.

    Estándares en el proceso de desarrollo de software:

      La gran cantidad de organizaciones de desarrollo de software implementan metodologías para el proceso de desarrollo. Muchas de estas organizaciones pertenecen a la industria armamentística, que en los Estados Unidos necesita un certificado basado en su modelo de procesos para poder obtener un contrato.

El estándar internacional que regula el método de selección, implementación y monitoreo del ciclo de vida del software es ISO 12207.

Durante décadas se ha perseguido la meta de encontrar procesos reproducibles y predecibles que mejoren la productividad y la calidad. Algunas de estas soluciones intentan sistematizar o formalizar la aparentemente desorganizada tarea de desarrollar software.

Otros aplican técnicas de gestión de proyectos para la creación del software. Sin una gestión del proyecto, 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, una gestión de proyectos efectiva es algo que a menudo falta.

Artefactos y Documentación

La documentación es la debilidad más frecuente en productos e instalaciones informáticos. Los actores que intervienen en el ciclo de vida del software desempeñan diversos roles. Arquitectos, diseñadores, analistas, programadores, implementadores, administradores o auditores son quienes explicitan distintos aspectos de los productos y procesos.

  

El código fuente del software, la estructura de datos y los enlaces de comunicaciones constituyen en conjunto el paradigma de la documentación informática. Sin embargo, cuando los modelos de arquitectura, estructuras y especificaciones de diseño no los vinculan, sólo pueden acceder a éstos dificultosamente los iniciados. Hay buenas prácticas para escribir código fuente pero, las condiciones y circunstancias de cada programa y sistema son tan diversas que, las exigencias habituales se reducen a que funcione razonablemente.

Artefactos

Artefactos, de acuerdo con RUP, es una pieza de información producida, modificada o utilizada por un proceso. Artefacto son los productos tangibles del proyecto, las cosas que los proyectos producen o utilizan mientras se trabaja hacia el producto final. Los artefactos son insumos utilizados para realizar actividades y, son los resultados de estas actividades.

Son artefactos entregables como ejecutables, el código fuente, manuales, planes y proyectos. Productos intermedios, como documentos de arquitectura y diseño, especificaciones de requerimientos, modelos de negocios y casos de uso. De igual forma, son artefactos los elementos que componen los modelos y productos, como glosarios y diccionarios, gráficos, clases o subsistemas. También, en negocios regulados, son artefactos los instrumentos y evidencias de la gestión informática.