QUE ES UN SOFTWARE???

Se conoce como software al equipamiento lógico o soporte lógico de un sistema informático, comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas, en contraposición a los componentes físicos, que son llamados hardware.

Los componentes lógicos incluyen, entre muchos otros, las aplicaciones informáticas; tales como el procesador de texto, que permite al usuario realizar todas las tareas concernientes a la edición de textos; el software de sistema, tal como el sistema operativo, que, básicamente, permite al resto de los programas funcionar adecuadamente, facilitando también la interacción entre los componentes físicos y el resto de las aplicaciones, y proporcionando una interfaz con el usuario

Proceso de desarrollo de software:

Un proceso para el desarrollo de software, es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe una enfoque diferente para diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un modelo de ciclo de vida un término más general que un determinado proceso para el desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software específicos que se ajustan a un modelo de ciclo de vida de espiral. 

Planificación

La importante tarea a la hora de crear un producto de software es obtener los requisitos o el análisis de los 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. Este documento se conoce como especificación funcional.

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. Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta parte del proceso tiene la función de detectar los errores de software lo antes posible. La documentación del diseño interno del software con el objetivo de facilitar su mejora y su mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentación de un API, tanto interior como exterior.

Despliegue y mantenimiento

El despliegue comienza cuando el código ha sido suficientemente probado, ha sido aprobado para su liberación y ha sido distribuido en el entorno de producción. Entrenamiento y soporte para el software es de suma importancia y algo que muchos desarrolladores de software descuidan. Los usuarios, por naturaleza, se oponen al cambio porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma adecuada a los futuros usuarios del software.

El mantenimiento y mejora del software de un software con problemas recientemente desplegado puede requerir más tiempo que el desarrollo inicial del software. Es posible que haya que incorporar código que no se ajusta al diseño original con el objetivo de solucionar un problema o ampliar la funcionalidad para un cliente. Si los costes de mantenimiento son muy elevados puede que sea oportuno rediseñar el sistema para poder contener los costes de mantenimiento.

Fundamentos del enfoque orientado a objetos:

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 estructura y comportamiento de objetos similares están definidos en su clase común; los términos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento común.

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 Objetos:

Los principios del modelo O.O (Orientado Objetos) 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 O.O (Orientado Objetos) no contiene alguno de los primeros cuatro elementos, entonces no es O.O (Orientado  Objetos).

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 objetoque 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

El Desarrollo de Software Basado en Componentes (DSBC) trata de apoyar las bases para el diseño y desarrollo de aplicaciones distribuidas basadas en componentes software reutilizables. Esta norma cuenta en la actualidad con una utilidad, tanto desde el panorama académico como desde el industrial, en donde su demanda de temas es cada día mayor.

La finalidad primordial de (DSBC) es entender los diferentes modelos de desarrollo de software y la importancia de sus componentes y servicios. También evaluar las diferencias entre este modelo y los estudiados anteriormente en el transcurso de desarrollar este tipo de software. Además deberíamos conocer los fundamentos sobre los que se sienta el modelo y todas las tendencias al momento de armar el software, es decir en su arquitectura.

¿Y por qué el empleo de este modelo de desarrollo en el mundo del software?

Se dice que la progresiva necesidad de efectuar sistemas complejos en poco de tiempo, y con menor esfuerzo tanto del desarrollador como de la parte económica, está beneficiando el avance de lo que se conoce como Desarrollo de Software Basado en Componentes (DSBC).

Este nuevo método se sustenta en componentes software ya desarrollado, que son combinados apropiadamente para satisfacer las exigencias del sistema. Los primordiales esfuerzos de la gente desarrolladora de software en estos temas se han basado hasta ahora en los aspectos prácticos de los componentes, es decir, en la funcionalidad que brindan. Sin embargo, por lo general se han venido previniendo muchos de los aspectos de calidad que intervienen a la hora de seleccionar componentes y ensamblarlos para construir aplicaciones que satisfagan los requisitos del cliente.

Estos aspectos “extra-funcionales”, cada vez absorbe la curiosidad de los arquitectos e ingenieros del software. Por un lado, los requisitos extra-funcionales pueden afectar a varias partes del sistema, y por ello tendrán prioridad si entran en conflicto con los requisitos funcionales. Asimismo, el cuidadoso análisis de las propiedades de calidad puede mejorar el proceso de diferencia de los componentes candidatos que cumplan el núcleo de requisitos funcionales. Por ejemplo, si dos componentes efectúan la misma funcionalidad, sus atributos extra-funcionales pueden ser el criterio definitivo en el proceso de selección.

COTS

La segunda tarea para este modelo de desarrollo se centraliza en los procesos y herramientas para la evaluación y selección de componentes COTS. Aparte de tener en cuenta las obligaciones funcionales de la aplicación, es necesario meditar otros factores que también se mezclan a la hora de seleccionar componentes. El problema es que este tipo de requisitos, denominados “extra-funcionales” son difíciles de apreciar, aunque todos somos conscientes de la importancia que representan.

Estos factores priman muchas veces incluso más que los funcionales, pues un diseñador hasta es capaz de adaptar la arquitectura de un sistema para poder incluir un componente que se desea que esté, o bien para evitar la presencia de un componente de un fabricante en el cual no se confía.

A pesar de estos problemas, los beneficios que proporciona el DSBC están ampliando su uso en ambientes industriales de desarrollo de software, sobre todo en cuanto a reducción de esfuerzos y costes de desarrollo y mantenimiento, y a la mejora de la calidad final de los productos y sistemas construidos. Esta extensión de su uso está favoreciendo la aparición de numerosas metodologías y herramientas de desarrollo para realizar un efectivo DSBC. Sin embargo, esta disciplina dista aún de ser una verdadera “ingeniería”, pues aún no se dispone ni de métricas adecuadas, ni de procesos precisos, ni de normativa internacional que la regule.

DOCUMENTACIÓN Y ARTEFACTOS:

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

Los artefactos: 
son métodos o procesos de un desarrollo especifico, un ejemplo de esto es el Proceso unificado. Por otra parte podemos decir que un artefacto es un producto tangible lo cual es el resultado de un proceso de desarrollo de software. Se utilizan para describir funciones, arquitectura o el diseño de un software los artefactos más comunes para realizar esta tarea es el de Caso de Uso, Diagrama de Clase y algunos modelos de UML. Otros modelos se enfocan en el proceso de desarrollo de sí mismo como un plan de proyecto, entre ellos tenemos Caso de Negocio o enfoque de riesgo. Existen ocasiones en el que los artefactos son productos terminados, como el código o el ejecutable.

Los artefactos pueden variar en su necesidad de mantenimiento y actualización. Los artefactos que detallan el diseño pretendido para el producto suelen realizarse al principio del proyecto y no necesitan mantenerse, mientras que otros se mantienen a lo largo del ciclo de vida con información que se actualiza durante el desarrollo.

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.