UNIVERSIDAD DE SAN CARLOS CENTRO UNIVERSITARIO DE … · Existen varias versiones del ciclo de vida...

Ciclo de vida del software

0

UNIVERSIDAD DE SAN CARLOS

CENTRO UNIVERSITARIO DE IZABAL

Carrera: PEM. En Computación E Informática

Ing. Freddy Oswaldo Pérez Pérez

Curso: Programación

Nombre Del Trabajo.

INTEGRANTES: Carné

Angélica Del Carmen Rivas Romero 201542690

Heydi Elizabeth Bolaños Samayoa 201143497

Julio David Pineda López 201545242

Brenda Marleny Diaz Gutierrez 201542773

Keysi Stefany Guadalupe Flores Cordòn. 201545248

Maria Roxana Villeda Guerra 201543516

Puerto barrios, Izabal 01/Agosto/2015


I

Introducción……………………………………………………………………………………………III Ciclo de vida del software……………………………………………………………………………..1

Modelos de ciclo de vida ............................................................................................................... - 1 -

Modelo en cascada........................................................................................................................ - 2 -

Modelo V ........................................................................................................................................ - 2 -

Modelo De Desarrollo Incremental................................................................................................ - 2 -

Modelo De Desarrollo Evolutivo .................................................................................................... - 3 -

Modelo de Prototípico de Requerimientos. ................................................................................... - 4 -

Modelo Espiral ............................................................................................................................... - 4 -

Modelo Concurrente ...................................................................................................................... - 5 -

Definición De Ingeniería Del Software. ......................................................................................... - 6 -

Métodos rápidos ............................................................................................................................ - 7 -

RAD - Desarrollo rápido de aplicaciones ...................................................................................... - 7 -

DSDM............................................................................................................................................. - 7 -

UP - Proceso unificado .................................................................................................................. - 8 -

RUP - Proceso unificado racional ................................................................................................. - 8 -

XP - Programación extrema .......................................................................................................... - 8 -

Evolución de la industria del software. .......................................................................................... - 8 -

Características del software .......................................................................................................... - 9 -

El software se desarrolla, no se fabrica en sí. .......................................................................... - 9 -

El software no se estropea. ..................................................................................................... - 10 -

La mayoría del software se construye a medida..................................................................... - 11 -

Aplicaciones del software. ....................................................................................................... - 12 -

Software de sistemas............................................................................................................... - 12 -

Software de tiempo real ........................................................................................................... - 12 -

Software de gestión ................................................................................................................. - 12 -

Software científico y de ingeniería........................................................................................... - 13 -

Software de ordenadores personales. .................................................................................... - 13 -

Software empotrado................................................................................................................. - 13 -

Software de inteligencia artificial. ............................................................................................ - 13 -

Problemas del software. .......................................................................................................... - 13 -

La planificación y la estimación de costes son muy imprecisas................................................. - 14 -

La productividad es baja. ......................................................................................................... - 14 -

La calidad es mala. .................................................................................................................. - 15 -


II

El cliente queda insatisfecho. .................................................................................................. - 15 -

Conclusión………………………………………………………………………………………………….IV Egrafia ................................................................................................................................................ V


III

Es la forma mediante la cual se describen los diferentes pasos que se deben seguir para el

desarrollo de un software o ciclo del software, partiendo desde una necesidad hasta llegar a la puesta en marcha de una solución y su apropiado mantenimiento. El ciclo de vida para un software comienza cuando se tiene la necesidad de resolver un problema, y termina cuando

el programa que se desarrolló para cumplir con los requerimientos, deja de ser utilizado. Existen varias versiones del ciclo de vida del software entre las cuales se destacan: el ciclo

de vida clásico o en cascada, el modelo en espiral, el desarrollo de prototipos, el modelo por incrementos y el modelo extremo entre otros. De manera paralela, el tema de modelos para el mejoramiento de los procesos de desarrollo ocupa un lugar importante en la búsqueda de

la metodología adecuada para producir software de calidad en cualquier contexto de desarrollo. De una u otra forma, las características de los proyectos de software hacen necesario seguir prácticas específicas para optimizar los resultados de los desarrollos. Este

artículo presenta en contexto las generalidades del estado actual de evolución de los modelos de ciclo de vida de desarrollo de software. Un modelo es una estructura guía,

abstracciones, marcos del proceso que pueden se extendidos y adaptadas para crear procesos más específicos. Los modelos no son excluyentes Las actividades fundamentales de un proceso de software son: ƒEspecificación del software, Diseño e implementación del

software, Validación del software, Evolución del software.

Para el caso del software existen 3 procesos comunes:

Modelo en cascada: presenta las actividades como fases separadas. Desarrollo evolutivo: entrelaza las actividades, se desarrolla en forma de espiral. Basado en componentes: componentes: se basa en la idea de la existencia de componentes reutilizables, los incorpora mas no los desarrolla. Es la primera actividad dentro de los procesos de software. Es el proceso de comprensión y definición de que servicios requiere el sistema. Identificación de restricciones de funcionamiento y desarrollo. Es la etapa más importante dentro del proceso de software pues se delimita el alcance del desarrollo. Un error en esta etapa representa inevitablemente problemas en el resto del desarrollo.


- 1 -

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

http://es.ccm.net/contents/qualite/qualite-introduction.php3


- 2 -

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.

Modelo De Desarrollo Incremental

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


- 3 -

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.

Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de

desarrollo, como se muestra en la figura. El modelo de desarrollo incremental provee algunos beneficios significativos para los

proyectos: Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.

Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.

Si un error importante es realizado, sólo la última iteración necesita ser descartada. Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el

desarrollo.

Si un error importante es realizado, el incremento previo puede ser usado. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

Modelo De Desarrollo Evolutivo

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipo evolutivo) construye una serie de grandes versiones sucesivas

de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.

En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que

son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos .

El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es

actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.

Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento.

Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.


- 4 -

Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.

El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación

de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.

Modelo de Prototípico de Requerimientos.

El prototipo de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es

construido de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos

individuos luego proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado, quienes capturan en la documentación actual de la especificación de requerimientos la información entregada por los usuarios para el desarrollo

del sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de

requerimientos). En otro caso, el prototipo puede servir su papel inmediatamente antes de algún o todo el desarrollo incremental en modelos incremental o evolutivo.

El Prototípico ha sido usado frecuentemente en los 90, porque la especificación de requerimientos para sistemas complejos tiende a ser relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que es mucho más fácil proveer retroalimentación

convenientemente basada en la manipulación, leer una especificación de requerimientos potencialmente ambigua y extensa.

Diferente del modelo evolutivo donde los requerimientos mejor entendidos están incorporados, un prototipo generalmente se construye con los requerimientos entendidos

más pobremente.

En caso que ustedes construyan requerimientos bien entendidos, el cliente podría responder con "sí, así es", y nada podría ser aprendido de la experiencia.

Modelo Espiral

El modelo espiral de los procesos software 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:

Determinar qué quieres lograr.

Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada

una, analizar los riesgos y resultados finales, y seleccionar la mejor.


- 5 -

Seguir la alternativa seleccionada en el paso 2.

Establecer qué tienes terminado.

La dimensión radial en la figura refleja costos acumulativos incurridos en el proyecto. Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a

resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situación y determinamos que los mayores riesgos son la interfaz del

usuario. Después de un cuidadoso análisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificación de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos

que el mejor curso de acción es construir un prototipo.

Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentación útil. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos

comiencen a aparecer sólo después de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximación es construir un incremento del sistema

que satisfaga sólo los requerimientos mejor entendidos. Hagámoslo ya. Después del despliegue, el cliente nos provee de retroalimentación que dirá si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarán en las cabezas de los

clientes. Y el tercer viaje alrededor de la espiral comienza.

El modelo espiral captura algunos principios básicos: Decidir qué problema se quiere resolver antes de viajar a resolverlo. Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.

Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo. No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema

que el cliente necesita conocer (comprender) los niveles de riesgo, que tendrás que tolerar. El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.

Modelo Concurrente

Como el modelo espiral, el modelo concurrente provee una meta-descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas

actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente. Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que

ocurren en algún tiempo del proceso de desarrollo de software. Discutamos un poco tales casos:

Los requerimientos son usualmente "líneas de base", cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo

considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian, y

nuestro entendimiento de los problemas desarrollados también). Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una


- 6 -

necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de

nuevo.

Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en esos componentes estables. Similarmente, durante

el diseño detallado, puede ser posible proceder con la codificación y quizás regular testeando en forma unitaria o realizando testeo de integración previo a llevar a cabo el diseño detallado

de todos los componentes. En algunos proyectos, múltiples etapas de un producto se han desarrollado

concurrentemente. Por ejemplo, no es inusual estar haciendo mantención de la etapa 1 de un producto, y al mismo tiempo estar haciendo mantención sobre un componente 2, mientras

que se está haciendo codificación sobre un componente 3, mientras se realiza diseño sobre una etapa 4, y especificación de requisitos sobre un componente 5. En todos estos casos, diversas actividades están ocurriendo simultáneamente. Eligiendo

seguir un proyecto usando técnicas de modelación concurrente, se posibilita el conocimiento del estado verdadero en el que se encuentra el proyecto.

Definición De Ingeniería Del Software.

Desarrollar un sistema de software complejo no es algo que puede abordarse sin una

preparación previa. El hecho de abordar un proyecto de desarrollo de software como cualquier otro ha llevado a una serie de problemas que limitan nuestra capacidad de aprovechar los recursos que el hardware pone a nuestra disposición.

Los problemas que a lo largo de los años han ido apareciendo no es algo que se va a solucionar en un corto espacio de tiempo pero identificarlos y conocer sus causas es el único método que nos puede ayudar a solucionarlos. La combinación de métodos aplicables a

cada una de las fases del desarrollo del software, la construcción de herramientas para automatizar estos métodos, el uso de técnicas para garantizar la calidad de los productos

desarrollados y la coordinación de todas las personas que intervienen en el desarrollo de un proyecto, hará que se avance mucho en la solución de estos problemas. De todo esto se encarga la disciplina llamadaIngeniería del Software.

Una definición concreta puede ser: El establecimiento y uso de principios de ingeniería

robustos, orientados a obtener software económico, que sea fiable y funcione de manera eficiente sobre las máquinas. La ingeniería del software abarca un conjunto de tres

elementos clave: métodos, herramientas y procedimientos, que facilitan al gestor el control del proceso de desarrollo y suministran a los implementadores bases para construir de forma productiva software de alta calidad.

Los métodos indican cómo construir técnicamente el software, abarcando

amplias tareas de planificación y estimación de proyectos, análisis de requisitos, diseño de estructuras de datos, programas y procedimientos, la

codificación, las pruebas y el mantenimiento.


- 7 -

Las herramientas proporcionan un soporte automático o semiautomático

para usar los métodos. Existen herramientas para cada una de las fases anteriores y sistemas que integran las herramientas de cada fase de forma

que sirven para todo el proceso de desarrollo. Estas herramientas se denominan CASE (ComputerAssisted Software Engineering).

Los procedimientos definen la secuencia en que se aplican los métodos,

los documentos que requieren, los controles que aseguran la calidad y las directrices que permiten a los gestores evaluar los progresos.

Métodos rápidos

"El desarrollo de software de "métodos rápidos" (también denominado Modelo rápido o

abreviado AG) reduce el tiempo del ciclo de vida del software (por lo tanto, acelera el

desarrollo) al desarrollar, en primera instancia, una versión prototipo y después integrar la

funcionalidad de manera iterativa para satisfacer los requisitos del cliente y controlar todo el

ciclo de desarrollo.

Los métodos rápidos se originaron por la inestabilidad del entorno técnico y el hecho de que

el cliente a veces es incapaz de definir cada uno de los requisitos al inicio del proyecto. El

término "rápido" es una referencia a la capacidad de adaptarse a los cambios de contexto y a

los cambios de especificaciones que ocurren durante el proceso de desarrollo. Por lo tanto,

en el año 2001, 17 personas redactaron el manifiesto ágil, en el que expresaron los

siguientes puntos principales:

individuos e interacciones en lugar de procesos y herramientas

desarrollo de software en lugar de documentación exhaustiva

trabajo con el cliente en lugar de negociaciones contractuales

apertura para los cambios en lugar de cumplimiento de planes poco flexibles

Con la ayuda de los métodos rápidos, el cliente tiene control total de su proyecto y logra una

rápida implementación del software. De esta forma, se permite al usuario involucrarse desde

el inicio del proyecto.

RAD - Desarrollo rápido de aplicaciones

El Desarrollo rápido de aplicaciones (o RAD) definido por James Martin a principios de la

década de 1980, consiste en un ciclo de desarrollo corto basado en tres fases (Requisitos,

Diseño y Construcción) con un plazo de entrega ideal de 90 a 120 días como máximo.

DSDM

El DSDM (Método de Desarrollo de Sistema Dinámico) se desarrolló para completar lo que le

faltaba al método RAD al proporcionar una estructura que tome en cuenta el ciclo de

desarrollo completo.

Las características principales del método DSDM son las siguientes:

Participación del usuario

http://www.agilemanifesto.org/


- 8 -

Desarrollo iterativo y creciente

Frecuencia de entrega mejorada

Pruebas integradas en cada fase

La aceptación de los productos entregados depende directamente del cumplimiento de los

requisitos.

UP - Proceso unificado

El método proceso unificado (UP) es un proceso de desarrollo iterativo y creciente. Esto

significa que el proyecto se divide en fases más cortas y que se envía una nueva versión

gradual al final de cada fase.

Este enfoque está basado en el modelo UML para la descripción de la arquitectura del

software (funcional, de aplicación y física) y para el desarrollo del caso del usuario. Dicho

modelo describe los requisitos y las demandas del usuario.

RUP - Proceso unificado racional

RUP (Proceso unificado racional) es un método de desarrollo iterativo promovido por la

compañía Rational Software, que fue comprada por IBM. El método RUP especifica,

principalmente, la constitución del equipo y las escalas de tiempo, así como un número de

modelos de documento.

XP - Programación extrema

El método XP (Programación extrema) define un conjunto de prácticas óptimas para el

desarrollo de aplicaciones en excelentes condiciones al colocar al cliente en el centro del

proceso de desarrollo, manteniendo una cercana relación con dicho cliente.

La Programación extrema se basa en los siguientes conceptos:

Los equipos de desarrollo trabajan directamente con el cliente durante ciclos cortos de

una o dos semanas como máximo.

La entrega de las versiones del software ocurre muy temprano y en intervalos muy cortos

para maximizar la interacción con el usuario.

Existe una fuerte colaboración entre el equipo de desarrollo mientras trabaja en el código.

El código se prueba y depura a lo largo del proceso de desarrollo.

Existen indicadores que miden el progreso del proyecto para poder actualizar el plan de

desarrollo.

Evolución de la industria del software.

En el comienzo de la informática, el hardware tenía mucha mayor importancia que en la actualidad, su coste era mucho mayor, y su fiabilidad, capacidad de almacenamiento y procesamiento era lo que determinaba las prestaciones de un determinado producto. El


- 9 -

software pasaba a un segundo plano, no se le daba mucha importancia, la mayoría se desarrollaba y era usado por la misma persona, siendo ella misma quien lo escribía, ejecutaba y si fallaba, lo depuraba. El diseño estaba en la mente de alguien y la

documentación no existía, si algo fallaba siempre estaría esa persona para subsanar el error.

Dada esta situación, las empresas se dedicaron a la mejora de las prestaciones de los equipos en lo que se refiere al hardware, reduciendo los costes y aumentando la velocidad

de cálculo y capacidad de almacenamiento. Debido a esto el hardware se desarrolló rápidamente y los sistemas informáticos cada vez eran más complejos necesitando un software, a su vez, más complejo para su funcionamiento. Es entonces cuando surgen las

primeras casas dedicadas al software y comienza la movilidad laboral, por lo que con la marcha de un trabajador era poco probable el mantenimiento o modificación de los

programas desarrollados por éste.

Al no existir una metodología y una documentación consistente, los programas presentaban, en muchas ocasiones errores e inconsistencias, por lo que estaban en una

continua depuración elevando así los costes de los mismos. Era más rápido en muchas ocasiones, comenzar de cero que modificar lo que ya estaba hecho, pero no por ello estaban exentos de errores y futuras modificaciones, por lo que la situación volvía a ser la misma.

Hoy en día, todo ha cambiado y el software pasa a ser el elemento principal del coste frente

al hardware, lo cual a llevado a la aparición y desarrollo de nuevas tecnologías que enfocan integralmente el problema abarcando todas sus fases, que en su mayoría no se

consideraban en los desarrollos tradicionales, y que son fundamentales en la reducción de costes y plazos, así como la calidad del producto final. Es lo que llamamos la ingeniería del software, definiéndose como “el tratamiento sistemático de todas las fases del ciclo de vida

del software”.

Características del software.

Una definición de software podría ser la siguiente:

Software: instrucciones de ordenador que cuando se ejecutan proporcionan la función y el comportamiento deseado, estructuras de datos que facilitan a los programas manipular

adecuadamente la información, y documentos que describen la operación y el uso de los programas. Por ello, decir tiene que el software incluye no sólo los programas de ordenador,

sino también las estructuras de datos que manejan esos programas y la documentación que se adjunta del proceso de desarrollo, mantenimiento y uso de dichos programas.

Según esto, mientras el hardware es algo físico, material, el software es inmaterial y por ello tiene unas características completamente distintas. Algunas de ellas pueden ser:

El software se desarrolla, no se fabrica en sí.

Tanto en el proceso de desarrollo del software como del hardware se siguen unas fases de análisis, diseño y desarrollo o construcción, obteniendo un buen producto final dependiendo de la calidad del diseño.


- 10 -

En el caso de producción de hardware a gran escala, el coste del producto depende del coste de los materiales empleados y del propio proceso de producción, no influyendo tanto en el coste las fases previas de ingeniería. En cambio en el caso del software, el desarrollo

es una más de las labores de ingeniería, y la producción a gran o pequeña escala no influye en el impacto que tiene la ingeniería en el coste, al ser un producto inmaterial. Por otro lado,

el software no presenta problemas técnicos y no requiere un control de calidad individualizado, cosa que si que ocurre en el hardware.

Los costes del software radican en el desarrollo de la ingeniería y no en la producción, y es ahí donde hay que incidir para reducir el coste final del producto.

El software no se estropea.

Partiendo tanto de la figura 1.1, como de la figura 1.2, podemos observar como por un lado el hardware (figura 1.1.), tiene la llamada curva de bañera, que indica que tiene muchos fallos al principio de su vida, debidos en gran parte a los defectos de diseño o a la baja calidad

inicial de la fase de producción. Dichos defectos se van subsanando hasta llegar a un nivel estacionario, pero los fallos vuelven a incrementarse debido al deterioro de los componentes (suciedad, vibraciones u otros factores externos) por lo que hay que sustituir los

componentes defectuosos por otros nuevos para que la tasa de fallos vuelva a estar a un nivel estacionario.

Por otro lado observamos que en el caso del software (figura 1.2.), inicialmente la tasa de fallos es alta, por errores no detectados durante su desarrollo, pero que una vez corregidos y

dado que no está expuesto a factores de deterioro externos, la tasa de fallos debería alcanzar un nivel estacionario y mantenerse definitivamente.

Todo esto no es más que una simplificación del modelo real de fallos de un producto

software. Durante su vida, el software va sufriendo cambios debido a su mantenimiento, el cual puede orientarse tanto a la corrección de errores como a cambios en los requisitos iniciales del producto. Al realizar los cambios es posible que se produzcan nuevos errores

con lo cual se manifiestan picos en la curva de fallos.

Estos errores pueden corregirse, pero los sucesivos cambios, hacen que el producto se aleje cada vez más de las especificaciones iniciales de acuerdo a las cuales fue desarrollado,

conteniendo cada vez más errores. Además, a veces, se solicita un nuevo cambio antes de haber corregido todos los errores producidos por el cambio anterior.


- 11 -

Por todo ello, como vemos en la figura 1.3, el nivel estacionario que se consigue después de un cambio es algo superior al que había antes de efectuarlo, degradándose poco a poco el funcionamiento del sistema. De esta manera, podemos decir que el software no se estropea,

pero se deteriora.

Además, hay que decir, que cuando un componente software se deteriora, al contrario que ocurre en el hardware, no podemos sustituirlo por otro porque no existen “piezas de repuesto”. Cada fallo indica un fallo en el diseño o en el proceso por el que se transformó el

diseño en código máquina ejecutable. La solución está en sustituir el diseño por otro así como el desarrollo del producto.

La mayoría del software se construye a medida.

En el caso del hardware el diseño se realiza con componentes digitales existentes en catálogo que han sido probados por el fabricante y usuarios anteriores, teniendo unas

especificaciones claras y estando bien definidos. Con el software no ocurre así. No existen catálogos de componentes, y aunque productos como sistemas operativos, editores, entornos de ventanas y bases de datos se venden en grandes ediciones, la gran mayoría del

software se fabrica a medida, siendo su reutilización muy baja.

Se puede comprar software ya desarrollado, pero como unidades completas, no como componentes que pueden ser re ensamblados para construir nuevos programas. Esto hace

que el coste de ingeniería sobre el producto final sea muy elevado.

A lo largo de los años se ha intentado la reutilización del software pero tras muchos intentos ha habido poco éxito. Un ejemplo claro de reutilización son las bibliotecas que se empezaron

a desarrollar en los años sesenta como subrutinas científicas, reutilizables en muchas aplicaciones científicas y de ingeniería, así como hoy en día la mayor parte de los lenguajes modernos incluyen bibliotecas de este tipo. Sin embargo, existen otros problemas como la

búsqueda de un elemento en una estructura de datos, debido a la gran variación que existe en cuanto a la organización interna de estas estructuras y en la composición de los datos que

la contienen, por lo que, aunque existen algoritmos para resolver estos problemas, no queda más remedio que programarlos una y otra vez, adaptándolos a cada situación particular.

Un nuevo intento de conseguir la reutilización se produjo con el uso de técnicas de programación estructurada y modular. Sin embargo, se dedica por lo general poco esfuerzo

al diseño de módulos lo suficientemente generales para ser reutilizables, y en todo caso, no se documentan ni se difunden lo suficiente para extender su uso, con lo cual se tiende a


- 12 -

diseñar y programar módulos muy semejantes una y otra vez. La programación estructurada permite diseñar programas con una estructura más clara y más fácil de entender, lo cual permite la reutilización de módulos dentro de los programas o incluso dentro del proyecto que

se está desarrollando, pero la reutilización de código en proyectos es muy baja.

La última tendencia es el uso de técnicas orientadas a objetos, que permiten la programación por especialización. Los objetos disponen de interfaces claras y los errores

cometidos en su desarrollo pueden ser depurados sin que esto afecte a la corrección de otras partes del código y pueden ser heredados y reescritos parcialmente, haciendo posible su reutilización aún en situaciones no contempladas en el diseño inicial.

Aplicaciones del software.

El software puede aplicarse a numerosas situaciones del mundo real. En primer lugar, diremos que puede aplicarse a todos aquellos problemas para los que se ha establecido un conjunto de acciones que lleven a su resolución (algoritmo). En estos casos, usamos

lenguajes para implementar estos algoritmos.

Es difícil establecer categorías genéricas para las aplicaciones del software. Cuanto más complejo es el mismo más complicado se hace establecer compartimentos claramente

separados. No obstante, se suele aceptar esta clasificación:

Software de sistemas.

Formado por aquellos programas cuyo fin es servir al desarrollo o al funcionamiento de otros programas. Este tipo de programas son muy variados: editores, compiladores, sistemas operativos, entornos gráficos, programas de telecomunicaciones, etc., pero todos ellos tienen

unos puntos en común y como estar muy próximos al hardware, ser utilizados por numerosos usuarios y por ser programas de difusión, no están diseñados normalmente a medida. Esto permite un mayor diseño y optimización, pero también les obliga a ser muy fiables,

cumpliendo estrictamente las especificaciones para las que fueron creados.

Software de tiempo real

Formado por aquellos programas que miden, analizan y controlan los sucesos del mundo real a medida que ocurren, debiendo reaccionar de forma correcta a los estímulos de entrada

en un tiempo máximo prefijado. Deben, por tanto, cumplir unos requisitos temporales muy estrictos, además de ser fiables y tolerantes a fallos. Por otro lado, no suelen ser muy complejos y precisan de poca interacción con el usuario.

Software de gestión

Este tipo de programas utiliza grandes cantidades de información almacenadas en bases de datos para poder facilitar las transacciones comerciales o la toma de decisiones. Además de las tareas convencionales de procesamiento de datos, en las que el tiempo de procesamiento no es crítico y los errores pueden ser corregidos a posteriori, incluyen

programas interactivos que sirven de soporte a las transacciones comerciales.


- 13 -

Software científico y de ingeniería.

Es otro de los campos clásicos de aplicación de la informática. Se encarga de realizar complejos cálculos sobre datos numéricos de todo tipo. En este caso un requisito básico que deben cumplir es la corrección y exactitud de las operaciones que realizan.

Este campo se ha ampliado últimamente con el desarrollo de los sistemas de diseño,

ingeniería y fabricación asistida por ordenador (CAD, CAE y CAM), lo simuladores gráficos y otras aplicaciones interactivas que lo acercan al software de tiempo real e incluso al de sistemas.

Software de ordenadores personales.

El uso de ordenadores personales y de uso doméstico se ha extendido a lo largo de la última década. Aplicaciones típicas son los procesadores de texto, las hojas de cálculo, bases de datos, aplicaciones gráficas, juegos, etcétera. Son productos de amplia difusión orientados a

usuarios no profesionales, por lo que sus principales requisitos son la facilidad en el uso y el bajo coste.

Software empotrado.

Es aquél que va instalado en otros productos industriales, como por ejemplo la electrónica de consumo, dotando a estos productos de un grado de inteligencia cada vez mayor. Se aplica a

todo tipo de productos, desde un vídeo doméstico hasta un misil con cabeza nuclear, pasando por sistemas de control de los automóviles, y realiza funciones muy diversas, desde complicados cálculos en tiempo real a sencillas interacciones con el usuario facilitando el

manejo del aparato que los incorpora. Comparten características con el software de sistemas, el de tiempo real, el de ingeniería y científico y el de ordenadores personales.

Software de inteligencia artificial.

El software basado en lenguajes procedimentales es útil para realizar de forma rápida y fiable

operaciones que para el ser humano son tediosas e incluso inabordables. Sin embargo, es difícil su aplicación a problemas que requieran funciones intelectuales más elevadas. Esta deficiencia trata de subsanarla el software de inteligencia artificial, basándose en el uso de

lenguajes declarativos, sistemas expertos y redes neuronales.

Como hemos visto, el software permite aplicaciones muy diversas, pero en todas ellas encontramos algo en común: el objetivo es que el software determine una determinada

función cumpliendo, a su vez, una serie de requisitos (fiabilidad, corrección, respuesta en un tiempo determinado, facilidad de uso, bajo coste, etcétera) a la hora de desarrollar el software.

Problemas del software.

A lo largo del tiempo, ya hemos visto que el software ha sufrido lo que se llama “crisis del software”. Dicha crisis vino como consecuencia de los problemas surgidos al desarrollar un


- 14 -

software de cierta complejidad y que hoy en día también existen sin que se haya avanzado mucho en los intentos por darle una solución.

Estos problemas son causados por las propias características del software y por los errores cometidos por quienes intervienen en su producción. Entre ellos podemos citar:

La planificación y la estimación de costes son muy imprecisas.

Al comenzar un proyecto de cierta complejidad es frecuente que surjan imprevistos que no estaban recogidos en la planificación inicial, y como consecuencia se producirá un cambio en los costes del proyecto. Sin embargo, en el desarrollo del software lo más frecuente es que la

planificación sea prácticamente inexistente, y que nunca se revise en el desarrollo del proyecto. Sin una planificación detallada es imposible hacer una estimación de costes que

tenga alguna posibilidad de cumplirse, y tampoco pueden localizarse las tareas conflictivas que pueden desviar los costes previstos.

Entre las causas de este problema podemos citar:

No se recogen datos sobre el desarrollo de proyectos anteriores, con lo que no

se adquiere la experiencia que pueda ser utilizada en nuevos proyectos. Los gestores de los proyectos no están especializados en la producción de software. Es decir, de siempre los responsables del desarrollo del software han sido

ejecutivos de medio y alto nivel sin conocimientos de informática, por lo que, si bien es cierto que siempre se ha dicho que un buen gestor puede gestionar cualquier

proyecto, no cabe duda que también es necesario conocer las características específicas del software, aprender las técnicas que se aplican en su desarrollo y conocer una tecnología que está en continua evolución.

La productividad es baja.

Los proyectos software tienen, en general, mayor duración de lo que en un principio se esperaba. Como consecuencia de ello los costes se disparan y la productividad y beneficios disminuyen. Un punto importante que influye es la falta de propósitos claros a la hora de comenzar el proyecto. La mayoría del software se desarrolla a partir de unas

especificaciones ambiguas e incorrectas sin existir una comunicación con el cliente hasta la entrega del producto. Todo esto no lleva a frecuentes modificaciones de las especificaciones

o los cambios de última hora, después de la entrega al cliente. No se realiza un estudio detallado de estos cambios y la complejidad interna de las aplicaciones va creciendo hasta hacerse imposible de mantener y cada modificación, por pequeña que sea, es más costosa y

puede ocasionar el fallo de todo el sistema.

Debido a la falta de documentación sobre cómo se ha desarrollado el producto a que las continuas modificaciones han distorsionado el diseño actual, el mantenimiento del software

puede llegar a ser una tarea imposible de realizar, pudiendo llevar más tiempo realizar una modificación sobre el programa ya escrito que analizarlo y desarrollarlo entero de nuevo.


- 15 -

La calidad es mala.

Dado que las especificaciones son ambiguas o incluso incorrectas, y que no se realizan pruebas exhaustivas, el software contiene numerosos errores cuando se entrega al cliente. Dichos errores ocasionan un fuerte incremento de costes durante el mantenimiento del

proyecto cuando, en realidad, ya se esperaba que estuviese acabado. Recientemente se ha empezado a dar importancia a la prueba sistemática y completa, surgiendo así nuevos conceptos como fiabilidad y garantía de calidad.

El cliente queda insatisfecho.

Debido al poco interés mostrado al análisis de los requisitos del proyecto, la falta de comunicación con el cliente durante el desarrollo y la existencia de numerosos errores en el producto que se entrega, los clientes quedan muy poco satisfechos con los resultados

obtenidos. Esto da lugar a que las aplicaciones tengan que ser diseñadas y desarrolladas de nuevo, que no lleguen nunca a utilizarse o que se produzca un cambio de proveedor a la

hora de comenzar un nuevo proyecto.


IV

La base de datos es un componente fundamental de un sistema de información. El ciclo de vida de un sistema de información está ligado al ciclo de vida del sistema de base de datos

sobre el que se apoya. Al ciclo de vida de los sistemas de información también se le denomina ciclo de vida de desarrollo del software. Las etapas típicas del ciclo de vida de desarrollo del software son: planificación, recolección y análisis de los requisitos, diseño

(incluyendo el diseño de la base de datos), creación de prototipos, implementación, prueba, conversión y mantenimiento. Este ciclo de vida hace énfasis en la identificación de las

funciones que realiza la empresa y en el desarrollo de las aplicaciones que lleven a cabo estas funciones. Se dice que el ciclo de vida de desarrollo del software sigue un enfoque orientado a funciones, ya que los sistemas se ven desde el punto de vista de las funciones que llevan a cabo. Por esta razón, el análisis estructurado hace énfasis en los diagramas de flujo de

datos, siguiendo el movimiento de los datos a través de una secuencia de transformaciones, y refinando éstas a través de una serie de niveles. Lo mismo ocurre en el diseño

estructurado, que ve a un sistema como una función que se descompone sucesivamente en niveles o subsunciones. Concentrándose en las funciones se infravaloran los datos y, en especial, la estructura de los datos que son manipulados por las funciones. El resultado es que estos sistemas tienen valor durante poco tiempo en relación con las necesidades de los usuarios a largo plazo. Esto

sucede debido a que al poco tiempo de haber instalado un sistema, las funciones implementadas son en realidad un subconjunto de las funciones que los usuarios realmente

desean. Casi inmediatamente, los usuarios descubren una gran variedad de servicios adicionales que quisieran incorporar al sistema. Estas necesidades causan problemas a los sistemas obtenidos con un diseño orientado a funciones, puesto que este diseño puede

requerir una revisión importante para acomodar las funciones adicionales. En contraste, el enfoque orientado a datos centra el foco de atención en el análisis de los

datos utilizados por las funciones. Esto tiene dos ventajas. La primera es que los datos son una parte considerablemente más estable que las funciones. La segunda ventaja es que la

propia estructura de un esquema de base de datos requiere de un análisis sofisticado de los datos y de sus relaciones.


V

Aposto, S. W. (s.f.). Aposto. Recuperado el 19 de Julio de 2015, de

http://aposta.uv.es/givaro/modulo/Ciclo.htm

CCM, C. D. (20). CICLO DE VIDA DE SOFTWARE. Recuperado el 19 de Julio de 2015, de

http://es.ccm.net/contents/223-ciclo-de-vida-del-software

UNIVERSIDAD DE SAN CARLOS CENTRO UNIVERSITARIO DE … · Existen varias versiones del ciclo de vida...

Documents

Transcript of UNIVERSIDAD DE SAN CARLOS CENTRO UNIVERSITARIO DE … · Existen varias versiones del ciclo de vida...