Es el conjunto ordenado de pasos a seguir para llegar a la solución de un problema u obtención de un producto, en este caso particular, para lograr un producto software que resuelva un problema específico.
El proceso de creación de software puede llegar a ser muy complejo, dependiendo de su porte, características y criticidad del mismo. Por ejemplo la creación de un sistema operativo es una tarea que requiere proyecto, gestión, numerosos recursos y todo un equipo disciplinado de trabajo. En el otro extremo, si se trata de un sencillo programa (por ejemplo, la resolución de una ecuación de segundo orden), éste puede ser realizado por un solo programador (incluso aficionado) fácilmente. Es así que normalmente se dividen en tres categorías según su tamaño (líneas de código) o costo: de «pequeño»,«mediano» y «gran porte». Existen varias metodologías para estimarlo, una de las más populares es el sistema COCOMO que provee métodos y un software (programa) que calcula y provee una aproximación de todos los costos de producción en un «proyecto software» (relación horas/hombre, costo monetario, cantidad de líneas fuente de acuerdo a lenguaje usado, etc.). Cuando se va desarrollar un software intervienen muchas personas como lo es el cliente quien es el que tiene el problema en su empresa y desea que sea solucionado, para esto existe el analista de sistema quien es el encargado de hacerle llegar todos los requerimientos y necesidades que tiene el cliente a los programadores quienes son las personas encargadas de realizar lo que es la codificación y diseño del sistema para después probarlo y lo instalan al cliente. Es así como intervienen varias personas ya que una sola persona no podría determinar todo lo necesario lo mas seguro que le haga falta algún requerimiento o alguna parte del nuevo sistema y entre mas estén involucradas mejor para cubrir con todos los requerimientos del sistema.
Proceso:
El primer paso del proceso es el análisis, es aquí donde el analista se pone en contacto con la empresa para ver cómo está conformada, a que se dedica, saber todas las actividades que realiza en sí, conocer la empresa de manera general para posteriormente ver cuáles son sus necesidades o requerimientos que la empresa tiene en ese momento para poder realizar un análisis de la misma.
El primer paso del proceso es el análisis, es aquí donde el analista se pone en contacto con la empresa para ver cómo está conformada, a que se dedica, saber todas las actividades que realiza en sí, conocer la empresa de manera general para posteriormente ver cuáles son sus necesidades o requerimientos que la empresa tiene en ese momento para poder realizar un análisis de la misma.
Es importante saber cuáles son los requerimientos que la empresa tiene por que muchas veces los sistemas se desarrollan pero no pensando en el cliente y es ahí donde el sistema no cumple o no satisface las necesidades que existen con la empresa.
El segundo paso es el de diseño aquí entran todo el diseño del sistema es decir las pantallas, base de datos, todo esto debe de cumplir con ciertos estándares los cuales se toman en cuenta para poder desarrollar el diseño con calidad y así poder ofrecer un diseño amigable en cuestión de colores, tamaños de botones, cajas de texto, etc.
El tercer paso es la codificación es aquí donde se desarrolla todo el código del sistema por parte del programador esto se hace ya dependiendo de cada programador ya que cada programador tiene sus bases o formas para realizarlo pero en si deben todos llegar al mismo objetivo de ofrecerle funcionalidad al sistema siempre y cuando apegando se a las especificaciones del cliente.
El cuarto paso son las pruebas, es donde al sistema se pone a prueba como su palabra lo dice para así poder saber cuales son los posibles errores que se están generando del sistema y con ello mejorarlo para eliminar todos los errores que se puedan presentar por que un programa con menor errores mayor calidad puede llegar a tener.
El quinto y último paso es la instalación una vez realizado las pruebas correspondientes al sistema y haberlo corregido totalmente se procede a la instalación del mismo ya en la empresa para su uso correspondiente, todo con la finalidad de que los procesos se realicen de una manera más eficiente eliminando costos, tiempo y esfuerzo dentro de la organización.
El Modelo Constructivo de Costes o COCOMO; es un modelo matemático de base empírica utilizado para la estimación de costes de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.
Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80). Barry W. Boehm es un ingeniero informático estadounidense y también es profesor emérito de esta materia en el departamento de ciencias tecnológicas en la Universidad del Sur de California.
Describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo.
El ciclo de vida básico de un software consta de los siguientes procedimientos:
*Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global.
*Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.
*Diseño general: requisitos generales de la arquitectura de la aplicación.
*Diseño en detalle: definición precisa de cada subconjunto de la aplicación.
*Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.
*Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.
*Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.
*Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales.
*Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros.
*Implementación
*Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).
El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.
Modelos de ciclo de vida del software
Desventajas del modelo cascada:
- Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificación o prueba) pueden ser catastróficos para un proyecto grande.
- No es frecuente que el cliente o usuario final explicite clara y completamente los requisitos (etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos es luego difícil de acomodar
- El cliente debe tener paciencia ya que el software no estará disponible hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase de operación) puede ser desastroso, implicando reinicio del proyecto, con altos costos.
La forma y utilización de este modelo es uno de los más usados y populares. El modelo Cascada Realimentado resulta muy atractivo, hasta ideal para el mayor número de proyectos a realizar. El modelo lineal o en Cascada es el paradigma más antiguo y extensamente utilizado, sin embargo las críticas a él han puesto en duda su eficacia. Pese a todo tiene un lugar muy importante en la Ingeniería de software y continúa siendo el más utilizado; y siempre es mejor que un enfoque al azar.
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.
El modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:
1. Determinar qué quieres lograr.
2. Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.
3. Seguir la alternativa seleccionada en el paso 2.
Desventajas importantes:
- Requiere mucha experiencia y habilidad para la evaluación de los riesgos, lo cual es requisito para el éxito del proyecto.
- Es difícil convencer a los grandes clientes que se podrá controlar este enfoque evolutivo.
- Identificación del sistema o subsistemas clave de los directivos(*) (saber qué quieren).
- Determinación de «condiciones de victoria» de los directivos (saber qué necesitan y los satisface)
- Negociación de las condiciones «victoria» de los directivos para obtener condiciones «Victoria & Victoria» (negociar para que ambos ganen).
