Fundamentos de la Ingeniería del Software

Software 

se refiere a las instrucciones que se incorporan a un sistema informático para que este lleve a cabo una determinada función. Partiendo de esta sencilla definición, el campo que se esconde detrás es inmenso, porque engloba desde pequeñas aplicaciones para llevar a cabo tareas muy específicas, a archi conocidos sistemas operativos con capacidad para realizar miles de funciones.

El software es imprescindible para cualquier sistema informático o basado en informática, puesto que sin él, este no funcionaría. Es el software quien dá las órdenes, quien indica que debe hacer cada máquina con sus elementos, cuando y como. Un ordenador sin software sería simplemente un conjunto de chips, cables, periféricos e interruptores totalmente inerte y sin función alguna. Es el software quien ordena todo ese material, lo reconoce, le asigna una función según sus características, y permite que funcione todo en su conjunto. Imaginaos una orquesta tocando una pieza: el director sería la parte central del ordenador, los músicos, el hardware periférico, y el software, la partitura de esa pieza. Está claro que sin partitura no habrá música, pero también que sin músicos tampoco. Continuando el símil, si en el caso de las partituras son los compositores quienes las crean, en el caso de la informática son los programadores, quienes diseñan el software para que cumpla con la función deseada. En grandes programas, como por ejemplo los sistemas operativos, existen equipos de cientos y miles de personas que trabajan en ellos durante largos periodos de tiempo, sobre todo debido a su complejidad. Y de hecho empresas como Apple, Microsoft, Google… son básicamente empresas dedicadas al software y su desarrollo, lo cual nos permite hacernos una pequeña idea del valor del software. Contra esta corriente de grandes empresas que obtienen beneficio económico del software, hay una corriente mundial que aboga por el software libre o gratuito, pero bueno, esa es otra historia.

Resumiendo y volviendo al hilo principal, el software controla al hardware, aunque evidentemente sin este último el software tampoco puede funcionar. De hecho cada software suele ser específico para determinados equipos o máquinas. Si intentas ejecutar un software para una centralita de coches en un ordenador, no encontrará ni los mandos de las puertas, ni los elevalunas, ni el climatizador, y por tanto te dará errores, si es que llega a ejecutarse. Un software adecuado es de vital importancia, pues, para llevar a cabo la tarea que se quiere hacer de modo correcto. Cuando un software no funciona bien en un determinado hardware, se habla de incompatibilidad entre ambos.

La importancia del software radica también en que permite una comunicación entre el usuario y la máquina, e incluso una interacción entre ambos. Pongamos otro ejemplo muy sencillo; ahora mismo, escribiendo esto, al pulsar un botón del teclado, se activa automáticamente una serie de órdenes, que permiten identificar que botón se ha pulsado, traducirlo a lenguaje de máquina, mostrarlo en pantalla para el usuario y almacenarlo. Así, el software que tengo instalado en mi ordenador se ha ocupado de todo eso ante un simple gesto mío. Y esa es precisamente otra de sus grandes funciones: facilitar las tareas a los usuarios. Gracias al software podemos ejecutar tareas que hace décadas hubiesen llevado años de trabajo, y ello ha supuesto sin lugar a dudas una revolución mundial en la sociedad moderna. Está tan presente en nuestra vida cotidiana, que muchas veces pasa desapercibido que no sólo tenemos programas y aplicaciones en los ordenadores, sino que la mayor parte de los electrodomésticos, coches, mandos… llevan su propio software (más o menos simple) incorporado.

Cualidades del Software

• Correctitud, Confiabilidad y Robustez

Todo proyecto de desarrollo de software debe ya en sus primeras etapas especificar el alcance y los requerimientos a cumplir en el producto terminado. En este sentido la más básica de las cualidades es la Correctitud, que simplemente significa que el programa cumple con los requerimientos especificados en el análisis.

Sería ingenuo pensar que el análisis de requerimientos hecho en primera instancia cubre todos las alternativas posibles. De hecho la realidad siempre supera nuestras previsiones por más cuidadosas que éstas sean y aunque claro está un análisis riguroso puede prevenirme de más problemas que uno exiguo, un buen diseño no puede acabar en él. Es precisamente aquí donde entran la segunda y tercera de las cualidades.
En un caso ideal diremos que un software es confiable si cumple con los requerimientos especificados y no ocasiona graves problemas frente a situaciones imprevistas. La idea detrás de la Confiabilidad es que quizás aunque en ciertas ocasiones el programa reaccione en forma inesperada, el usuario se encuentra cómodo usándolo ya que estos fallos no traen aparejados problemas graves. Todo el mundo es consciente de los bugs presentes en muchos programas populares como ms-word pero aún así la mayoría de la gente los usa entre otras cosas porque son confiables. Distinta sería la situación si una caída en el ms-word implicara la corrupción del file system por ejemplo; sin duda la popularidad del programa no sería la misma aún cuando los fallos se produjeran por las mismas causas. En un caso idílico podemos suponer que todo proyecto de software implica un cuidadoso análisis de requerimientos especificado entre usuarios y analistas; por lo tanto a nuestros efectos todo programa confiable es correcto.

La Confiabilidad implicaba un comportamiento aceptable frente a situaciones inesperadas; pensemos cuanto mejor sería si pudiéramos en la fase de desarrollo fijar comportamientos frente a situaciones no previstas en la fase de análisis, pero ya evidentes durante el desarrollo. Esto es precisamente lo que definiremos como Robustez. En otras palabras un programa es robusto si reacciona en forma adecuada frente a situaciones a priori imprevistas. Claramente un programa robusto es también confiable y por ende correcto.

En un proyecto de propósito muy general como el nuestro, es difícil garantir cualquiera de estas propiedades. Aún así hemos puesto mucho esmero en cumplirlas, apoyándonos en un desarrollo sumamente modular que ha sido exigentemente verificado, delegando una importante parte de los chequeos al compilador, realizando cada clase sus propios chequeos de consistencia, apoyándonos en componentes de alto nivel para la implementación de diversas estructuras y algoritmos (e.g. STL y Design Patterns) y complementado todo lo anterior con mecanismos de manejo de excepciones para los casos más patológicos.

• Legibilidad

Cuando hablamos de Legibilidad nos referimos a la facilidad para interpretar como funciona el programa. Podemos dividirlo en varias partes: el código, la arquitectura, etc. En general la Legibilidad concierne exclusivamente a los desarrolladores ya que al usuario final rara vez le interesa ver el código o estudiar la arquitectura del programa que usa. En nuestro caso la situación es radicalmente diferente a la expuesta; de hecho es poco probable que un usuario de Bicoti pueda explotar adecuadamente el potencial de la biblioteca sin tener un buen conocimiento de como está estructurada. Como veremos en el diseño, los requerimientos solo pueden cumplirse razonablemente usando el código fuente en todo momento para crear aplicaciones; e incluso agregando clases y módulos en ciertos casos. Por lo anterior es claro que la Legibilidad es una cualidad esencial a incluir si aspiramos a concluir el proyecto con éxito.

En Bicoti hemos incluido diversos elementos que mejoran la Legibilidad. 

En el código hemos hecho un importante esfuerzo de estandarización en nombres de variables, clases y funciones, estructura de módulos, comentarios varios y hemos delegado mucho del trabajo de bajo nivel a una biblioteca estándar del C++ como la STL. 

En la arquitectura hemos invertido mucho tiempo en diseñar la misma en forma clara y prolija dando en todos los casos posibles, soluciones estándar de alto nivel en la jerarquía de clases para los problemas, apostando a la abstracción como herramienta para mejorar la claridad.

Complementamos lo anterior con documentación detallada y precisa, tanto de alto como de bajo nivel, así como con diversos ejemplos que esperemos faciliten la lectura.

No terminaremos sin remarcar que los usuarios regulares de Bicoti deben hacer un esfuerzo de su parte por entender como y por que se han hecho las cosas de cada forma, en complemento al puesto de nuestra parte en clarificarlas.

• Evolutividad y Flexibilidad

Evolutividad y Flexibilidad son dos cualidades interdependientes. La primera se refiere a la posibilidad de extender el programa para adaptarse a requerimientos más amplios y la segunda para variarlos, dentro de lo que podríamos llamar un dominio de aplicaciones en ambos casos. Detrás de ambas cualidades está implícita la idea de diseño para el cambio, básica para cumplir las metas de re-uso de código y arquitectura.

Estas dos cualidades son imprescindibles en nuestro proyecto ya que forman parte de nuestros requerimientos más directos como veremos más adelante; posiblemente hayan sido además las que presentaron mas carencias en la biblioteca anterior trayendo como consecuencia inevitable, la independencia en los desarrollos y reduciendo los proyectos a esfuerzos individuales aislados que terminaban de hecho en la mayoría de los casos, en el momento que finalizaba el proyecto en cuestión.

• Reparabilidad y Mantenibilidad

Para presentar ambos conceptos nos apoyaremos en un ejemplo que se presentó durante la implementación. Durante el diseño habíamos adoptado la convención que las coordenadas de un pixel de la imagen, fueran de tipo entero sin signo; pero de todos modos hacíamos un chequeo de consistencia en las funciones de las clases que recibían este tipo de parámetros. Descubrimos chequeando éstas funciones que algunos compiladores no reaccionaban como habíamos esperado cuando recibían los parámetros fuera del tipo predefinido y de hecho hacían casting, cambiando completamente el efecto esperado como resultado de estas funciones. Al notar el problema, cambiamos la convención original y pasamos a aceptar tipos enteros como coordenadas en los cabezales de las funciones, dejando solo los chequeos internos. En los hechos cambiar el tipo de las variables en cuestión, se redujo a poco más que un find & replace en un puñado de clases.

En forma similar podríamos mencionar muchos ejemplos de las mismas características. La nueva cualidad que en cierta forma estábamos poniendo a prueba con la situación anterior es la que llamaremos Reparabilidad, que es la posibilidad de corregir los defectos del software con un limitado gasto de trabajo.

La Mantenibilidad es similar a la anterior, pero no está vinculado a la solución de bugs sino a cambios que no aparecían en la especificación original o que fueron establecidos en forma incorrecta.

En el ciclo de vida de todo producto de software, el tiempo de mantenimiento es un componente importante del tiempo total, por lo que ambas cualidades son vitales en cualquier programa y claro está Bicoti no es la excepción.

• Performance del Software y Eficiencia en el desarrollo

En esencia diremos que un programa tiene una mejor Performance que otro si realiza el mismo trabajo en menor tiempo. Esta cualidad que básicamente es de comparación, es sin duda la más objetiva de todas. En programas que por su naturaleza demandan pocos recursos, la Performance no es una cualidad vital. Muchas de las aplicaciones de imágenes implican un importantísimo costo de cálculo por lo que la Performance ha sido sumamente contemplada en Bicoti. Se han realizado varias pruebas de Performance contra otros softwares entre las que destacamos Blitz y la biblioteca vieja.

Con la biblioteca vieja, las pruebas de Performance fueron similares así que no nos extenderemos en comentarios a este respecto.

Blitz es una biblioteca básicamente diseñada para álgebra de matrices; sus desarrolladores prometen una Performance similar a la de Fortran en este tipo de operaciones, con las ventajas de programación de C++. A modo de adelanto de diseño, podemos pensar que Bicoti implementa todos sus algoritmos sobre una capa estándar, que me independiza entre otras cosas de la dimensión de la imagen en que trabajo y del tipo de implementación que se ha elegido para esta. Las comparaciones de Performance arrojaron resultados dispares dependiendo del tipo de operaciones realizadas. Cuando las pruebas se hicieron sobre operaciones algebraicas en las imágenes, Bicoti perdió claramente frente a Blitz por un factor de 2 o 3 veces; sin embargo las pruebas sobre otros tipos de operaciones propias de las imágenes como los filtros lineales, dejaron a Bicoti mejor parado en una relación similar. Estos resultados pueden parecer desconcertantes a primera vista, pero en realidad son bastante naturales si pensamos en los objetivos de cada una. Blitz está diseñada exclusivamente para operaciones algebraicas y las implementaciones de estas están íntimamente ligadas a las estructuras de datos usadas. En Bicoti por el contrario las operaciones algebraicas integran una de varias familias de algoritmos, así que si quisiéramos comparar en un caso general, sería más justo usar otro tipo de operaciones como los filtros lineales por ejemplo. Esta interpretación muestra que en realidad la Performance media en Bicoti es buena y si bien es cierto que sería aún mejor, si los algoritmos estuvieran implementados específicamente en cada dimensión y tipo de implementación, esto iría en desmedro de otras cualidades a pesar a la hora del diseño.

Creemos que la discusión anterior es muy útil para presentar otra cualidad no menos importante, la Eficiencia en el desarrollo o Productividad. La Eficiencia también refleja comparaciones de tiempo, pero en este caso los tiempos tenidos en cuenta son ya no los de ejecución del programa una vez compilado, sino los de desarrollo del mismo. Si la obsesión de un programador fuera la Performance, quizás debería optar por usar Fortran (o si queremos ser más dramáticos aún, Assembler) para desarrollar sus aplicaciones de imágenes. Seguramente nadie preferiría esta última alternativa aún cuando la misma implique una mejora de Performance de un factor de 2 o 3, a costa entre muchas razones de demorar semanas en escribir un programa, que probablemente no pueda re-usarse en el futuro ni aún por el mismo programador y que con certeza no podrá ser portado a otra arquitectura. Es en esta cualidad donde esperamos que Bicoti supere ampliamente a las experiencias anteriores, no tanto quizás en aplicaciones concretas sino mas bien en el desarrollo a largo plazo, por el re-uso de algoritmos. Es también para velar por esta cualidad que en genral hemos decido no incluir algoritmos de ningún tipo en las estructuras que almacenan datos.

• Amigabilidad

Un sistema es Amigable, si los usuarios humanos lo encuentran fácil de usar. Comúnmente se asocia la Amigabilidad a la interfase gráfica, aunque el concepto es más general. En Bicoti-I no existe interfase gráfica alguna así que nos limitaremos a la Amigabilidad en el uso de la biblioteca. Esta cualidad en contraste con las anteriores es sumamente subjetiva y varía en su evaluación no solo de un usuario a otro, sino también para un mismo usuario en distintos instantes de tiempo. Existen dos formas de usar Bicoti-I; una primera que podríamos llamar de Prototipación y la de Desarrollo.

Comentaremos ambas formas comenzando por la segunda. El Desarrollo es la forma cruda de usar la biblioteca. El usuario a este nivel no puede evitar enfrentarse a la compleja arquitectura del Framework. Debe crear explícitamente varios objetos para realizar operaciones que en principio parecieren sencillas. Puede agregar clases nuevas al Framework pero debe hacerlo en forma consistente con el resto, así que en general podemos pensar que este uso se hará fundamentalmente en los casos que se intenta incorporar componentes nuevos, una vez probados los algoritmos y siendo conscientes que estos funcionan correctamente. Los programadores de Desarrollo deben tener un buen conocimiento de la arquitectura y el por que de la misma, pero también deben ser programadores experimentados en C++ y manejar ideas básicas de Ingeniería de Software.

La Prototipación sin duda no es tan exigente hacia los usuarios como el Desarrollo. Aquí es mucho más importante tener un buen conocimiento de Tratamiento de Imágenes, ya que los detalles de arquitectura se han escondido en lo posible detrás de un conjunto de funciones de alto nivel que resuelven internamente muchas de las dificultades. Estos usuarios no ven a Bicoti como un complejo Framework, sino como una biblioteca con un conjunto bien definido de datos y algoritmos. El usuario simplemente desarrolla sus aplicaciones finales si estas solo implican usar la algorítmica existente; o bien diseña alguna funcionalidad nueva, o quizás especifica alguna nueva propiedad de interés. En el segundo caso es necesario una vez seguros del correcto funcionamiento, integrar a Bicoti los elementos nuevos para lo que no cabrá otra posibilidad que hacerlo en modo de Desarrollo. No hay que subestimar la utilidad de este último paso; la experiencia recogida en la biblioteca vieja permite afirmar, que aquellos componentes que no se integren realmente a la arquitectura, no serán usados en el futuro por otros grupos de trabajo. La integración, de hacerse en forma correcta, obligará al implementador a generalizar sus algoritmos para cubrir aspectos que quizás fueron pasados por alto, debido a las circunstancias particulares a las que este debió enfrentarse.

No queremos que quede la idea que el modo de prototipación es la cara amigable de Bicoti, en contraste con el de Desarrollo. En ambos casos se ha puesto esfuerzo por hacer amigable el uso; la diferencia principal radica en el hecho que el modo de desarrollo implica en general la resolución de problemas mucho más generales y complejos.

• Portabilidad

La Portabilidad es la capacidad de llevar exitosamente el sistema a otro entorno. Este fue desde el principio uno de nuestros principales objetivos, que hemos alcanzado adaptándonos estrictamente a los estándares de C++ en lo que a sintaxis se refiere, así como al uso de bibliotecas como la Standard Template Library. Durante todo el proyecto hemos probado todo el software simultáneamente sobre Unix y Windows hasta lograr soluciones compatibles y por lo tanto tenemos la convicción que este objetivo a sido alcanzado con éxito.

VISIÓN GENERAL DEL PROCESO DE DESARROLLO DE SOFTWARE

El proceso es afectado por la creatividad y juicio de las personas involucradas. En el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. 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.

Es actividades requeridas para desarrollar un sistema de software de alta calidad y proporciona el marco de trabajo desde el cual se puede establecer un plan detallado para el desarrollo del software. Actividades: Diseño, validación, evolución, especificación.

Todos sabemos que cuanto mayor sea la ayuda de los usuarios en un proyecto de desarrollo de software, mayores serán las probabilidades de éxito que tenga el mismo.

no obstante es importante hacer algunas matizaciones:

1) el proyecto no se hace sólo, porque incluso existiendo una gran ayuda por parte de los usuarios, si no se consigue interpretar con precisión lo que quieren y no se dinamiza un feedback continuo de los mismos durante todo el proceso de desarrollo, se incrementarán las posibilidades de que algún requisito funcional no se haya recogido adecuadamente o de que se haya realizado un software con una usabilidad incómoda para los usuarios.

Estas circunstancias son fuente de innumerables problemas en las fases finales del proyecto y provocan retrasos, sobrecostes y grandes dificultades para cerrar el proyecto, además de crear conflictos con el cliente que pueden perjudicar las relaciones futuras con el mismo. Esto hace que sea fundamental el papel que desempeñan tanto el jefe de proyectos, como el equipo de analistas funcionales y analistas programadores.

2) Es importante que entre el grupo usuarios asignados al proyecto haya usuarios que vayan a estar implicados en el futuro uso del sistema de información, es decir, no es suficiente que el equipo de usuarios esté formado por “ideólogos” o “teóricos” que se nutrirán del resultado del trabajo de la herramienta, sino que es fundamental que participen usuarios que después se tengan que poner el mono de trabajo y vayan a trabajar con el software. Es importante conseguir la combinación de ambos tipos de usuarios (tampoco es positivo que en el grupo de usuarios no participen usuarios directores, ya que pueden existir conflictos entre usuarios que éstos deben solucionar y también es recomendable que el software no sólo se diseñe para el corto plazo, sino que sirva para tareas de gestión, planificación, etc… y esta visión la proporcionan principalmente los usuarios directores), por lo que el jefe de proyectos debe poner en conocimiento del cliente esta necesidad, como es lógico explicando los riesgos de que no se aplique esta estrategia.

3) Los analistas están para ayudar y para colaborar con los usuarios en la especificación y diseño de la solución, pero no están para “dar lecciones” a los usuarios y enseñarle cómo deben hacer su trabajo. Si los usuarios hacen su trabajo de una determinada manera, aunque no sea la más ortodoxa, siempre tendrá una justificación que sólo se entendería si realmente estuviéramos haciendo su trabajo durante un tiempo y viéramos los problemas con los que se enfrentan cotidianamente. La clave por tanto está en la colaboración y en el diálogo, es decir, se pueden proponer cosas al usuario, se le pueden dar ideas, pero no se le puede dar una vuelta al calcetín de cómo hacen sus tareas, salvo que ellos mismos lo soliciten y procurando en estos casos y en consenso con los usuarios que los cambios sean tranquilos.

4) Es fundamental documentar el proyecto, en primer lugar con la documentación que se especifique en las normativas de desarrollo de la organización para la que se realiza el servicio, con las matizaciones que indique el Director del Proyecto, en segundo lugar con la documentación que establezcan las normativas internas de calidad de tu organización (no requerirá un sobreesfuerzo, ya que en la mayor parte de los casos coincidirá) y a todo lo anterior sumarle toda la documentación de trabajo que sea necesaria para trabajar con los usuarios, que no tienen por qué entender de modelos de datos, de diagramas de casos de uso, etc…, es más, es un error trabajar con los usuarios utilizando dichas herramientas, ya que estas son de utilidad técnica y no hablan el mismo lenguaje de los usuarios. Este tipo documentación, por tanto, no tiene por qué tener los formalismos de la técnica y tiene como objetivo que el usuario capte lo que el analista está interpretando y se pueda ir perfilando a partir de esto, tanto requisitos, como casos de uso, interfaces, etc… Es muy importante trabajar todo esto, ya que comenzar demasiado pronto con la construcción, es algo muy arriesgado, ya que los costes de modificar algo en las distintas fases de la construcción pueden ser muy importantes y provocar que se tengan que reconstruir varias veces distintas funcionalidades de la aplicación.

INGENIERÍA DEL SOFTWARE

Es una disciplina formada por un conjunto de métodos, herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos (software).

Esta disciplina trasciende la actividad de programación, que es el pilar fundamental a la hora de crear una aplicación. El ingeniero de software se encarga de toda la gestión del proyecto para que éste se pueda desarrollar en un plazo determinado y con el presupuesto previsto.

La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el diseño del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto funcionamiento y la implementación del sistema.

Cabe destacar que el proceso de desarrollo de software implica lo que se conoce como ciclo de vida del software, que está formado por cuatro etapas: concepción, elaboración, construcción y transición.

La concepción fija el alcance del proyecto y desarrolla el modelo de negocio; la elaboración define el plan del proyecto, detalla las características y fundamenta la arquitectura; la construcción es el desarrollo del producto; y la transición es la transferencia del producto terminado a los usuarios.

Una vez que se completa este ciclo, entra en juego el mantenimiento del software. Se trata de una fase de esta ingeniería donde se solucionan los errores descubiertos (muchas veces advertidos por los propios usuarios) y se incorporan actualizaciones para hacer frente a los nuevos requisitos. El proceso de mantenimiento incorpora además nuevos desarrollos, para permitir que el software pueda cumplir con una mayor cantidad de tareas.

CICLO DE VIDA DEL SOFTWARE

El término ciclo de vida del software 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: se asegura de que los métodos utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementación y en los costos asociados.

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

Para facilitar una metodología común entre el cliente y la compañía de software, los modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo involucradas y la documentación requerida, de manera que cada etapa se valide antes de continuar con la siguiente etapa. Al final de cada etapa se arreglan las revisiones de manera que (texto faltante).

• Modelo en cascada

El modelo de ciclo de vida en cascada comenzó a diseñarse en 1966 y se terminó alrededor de 1970. Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente:

• Modelo V

El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño.