resumen85 sobre codificacion de datos | Apuntes de Minería de Datos

Un#modelo#de#ciclo#de#vida#

(MCV)#

de#un#SI#es#el#conjunto#de#fases#(o#etapas)#por#las#que#pasa#el#sistema#desde#que#se#concibe#

hasta#que#se#retira#del#servicio.#

Clasificación#de#los#modelos#de#ciclo#de#vida#

Modelos#tradicionales:#Son#los#de#más#amplia#utilización.##

-Modelo#en#cascada.#

-#Modelos#basados#en#prototipos#

Modelos#alternativos#

Modelo#en#espiral#

-#Modelos#basados#en#transformaciones

Evolución#de#los#modelos#de#ciclo#de#vida#

La#secuencia#histórica#que#marca#la#evolución#de#los#distintos#modelos#de#ciclo#de#vida#sería#la#siguiente:##

-#Modelo#Code-and-Fix#

-#Modelo#por#etapas.#

-#Modelo#en#cascada.#Evolución#del#anterior#que#permite#la#realimentación#entre#etapas.#

-#Modelos#de#prototipado.#

-#Modelos#de#transformación.##

CODE-AND-FIX#

1.#Escribiralgúncódigooprograma(CODE).##

2.#Resolverlosproblemasenelcódigo(FIX).#

Caro#y#costoso#

MODELO#EN#CASCADA#(WATERFALL)#

1. Considera#la#realización#de#bucles#de#realimentación#entre#etapas,#permitiendo#la#resolución#de#problemas#

detec-#tados#en#una#etapa,#en#la#etapa#anterior.#Solo#admite#vueltas#a#la#etapa#anterior#

2. Una#incorporación#inicial#del#prototipado#en#el#ciclo#de#vida#del#software.#

Una#dificultad#principal#del#modelo#en#cascada#es#su#énfasis#en#documentos#totalmente#elaborados#como#criterio#de#ter-#

minación#de#las#distintas#fases#de#análisis#de#requerimientos#y#diseño.#

Fases#del#modelo:#

1ª#Fase#Análisis:

#En#esta#fase#se#desarrollará#el#documento#de#requisitos#del#software#que#consistirá#en#una#especificación#

precisa#y#completa#de#lo#que#debe#hacer#el#sistema.#

2ª#Fase#Diseño:

#Consiste#en#descomponer#y#organizar#el#sistema#en#elementos#En#esta#fase#se#desarrollará#el#Documento#

del#diseño#del#Software#que#será#una#descripción#de#la#estructura#global#del#sistema.#

3ª#Fase#Codificación:

#En#esta#fase#se#traduce#el#diseño#a#un#lenguaje#legible#para#el#computador.#La#documentación#de#esta#fase#

será#el#Código#fuente.#

4ª#Fase#Integración:

#Consiste#en#probar#el#sistema#completo#para#garantizar#el#funcionamiento#correcto#del#conjunto#antes#de#

ser#puesto#en#explotación.#Aquí#tendremos#el#Sistema#Software#ejecutable#

5ª#Fase#Mantenimiento:

#Puede#ocurrir#que#durante#la#explotación#del#sistema#sea#necesario#realizar#cambios#para#corregir#

errores#que#no#han#sido#detectados#en#las#fases#anteriores#o#bien#para#introducir#mejoras.#Tendremos#que#hacer#un#

Documento#de#cambios#ante#cualquier#modificación.##

El#número#de#fases#es#irrelevante,#lo#que#caracteriza#verdaderamente#a#este#modelo#es#la#secuencialidad#entre#las#fases#y#la#

necesidad#de#completar#cada#una#de#ellas#para#pasar#a#la#siguiente.##

Críticas#al#modelo#en#cascada#

Las#principales#críticas#al#modelo#se#centran#en#sus#características#básicas,#es#decir#secuencialidad#y#utilización#de#los#

resultados#de#una#fase#para#acometer#la#siguiente#de#manera#que#el#sistema#sólo#se#puede#validar#cuando#está#terminado.#

No#prevé#revisiones#o#validaciones#intermedias#por#parte#del#usuario,#así#los#resultados#de#los#trabajos#sólo#se#ven#al#final#

de#una#serie#de#tareas#y#fases#de#tal#forma#que#si#se#ha#producido#un#error#en#las#pri-#meras#fases#este#sólo#se#detectará#al#

final#y#su#corrección#tendrá#un#costo#muy#elevado.#

Vista previa parcial del texto

¡Descarga resumen85 sobre codificacion de datos y más Apuntes en PDF de Minería de Datos solo en Docsity!

Un modelo de ciclo de vida (MCV) de un SI es el conjunto de fases (o etapas) por las que pasa el sistema desde que se concibe hasta que se retira del servicio.

Clasificación de los modelos de ciclo de vida

Modelos tradicionales: Son los de más amplia utilización.

Modelo en cascada.
Modelos basados en prototipos Modelos alternativos
Modelo en espiral
Modelos basados en transformaciones Evolución de los modelos de ciclo de vida La secuencia histórica que marca la evolución de los distintos modelos de ciclo de vida sería la siguiente:
Modelo Code-and-Fix
Modelo por etapas.
Modelo en cascada. Evolución del anterior que permite la realimentación entre etapas.
Modelos de prototipado.
Modelos de transformación.

CODE-AND-FIX

Escribiralgúncódigooprograma(CODE).
Resolverlosproblemasenelcódigo(FIX). Caro y costoso

MODELO EN CASCADA (WATERFALL)

Considera la realización de bucles de realimentación entre etapas, permitiendo la resolución de problemas detec- tados en una etapa, en la etapa anterior. Solo admite vueltas a la etapa anterior
Una incorporación inicial del prototipado en el ciclo de vida del software. Una dificultad principal del modelo en cascada es su énfasis en documentos totalmente elaborados como criterio de ter- minación de las distintas fases de análisis de requerimientos y diseño. Fases del modelo: 1ª Fase Análisis: En esta fase se desarrollará el documento de requisitos del software que consistirá en una especificación precisa y completa de lo que debe hacer el sistema. 2ª Fase Diseño: Consiste en descomponer y organizar el sistema en elementos En esta fase se desarrollará el Documento del diseño del Software que será una descripción de la estructura global del sistema. 3ª Fase Codificación: En esta fase se traduce el diseño a un lenguaje legible para el computador. La documentación de esta fase será el Código fuente. 4ª Fase Integración: Consiste en probar el sistema completo para garantizar el funcionamiento correcto del conjunto antes de ser puesto en explotación. Aquí tendremos el Sistema Software ejecutable 5ª Fase Mantenimiento: Puede ocurrir que durante la explotación del sistema sea necesario realizar cambios para corregir errores que no han sido detectados en las fases anteriores o bien para introducir mejoras. Tendremos que hacer un Documento de cambios ante cualquier modificación. El número de fases es irrelevante, lo que caracteriza verdaderamente a este modelo es la secuencialidad entre las fases y la necesidad de completar cada una de ellas para pasar a la siguiente.

Críticas al modelo en cascada

Las principales críticas al modelo se centran en sus características básicas, es decir secuencialidad y utilización de los resultados de una fase para acometer la siguiente de manera que el sistema sólo se puede validar cuando está terminado. No prevé revisiones o validaciones intermedias por parte del usuario, así los resultados de los trabajos sólo se ven al final de una serie de tareas y fases de tal forma que si se ha producido un error en las pri- meras fases este sólo se detectará al final y su corrección tendrá un costo muy elevado.

Modelos basados en prototipos

Estos modelos fueron creados para solventar las diferencias percibidas en los modelos clásicos. Permiten a los desarrolla- dores construir rápidamente versiones tempranas de los sistemas software que pueden evaluar los usuarios. No resulta económico generar documentación durante las fases iterativas de la construcción del prototipo. Existen varios modelos derivados del uso de prototipos:

Prototipos rápidos, también llamados maquetas
Prototipos evolutivos
Prototipado incremental Prototipado Rápido Los prototipos deben poder construirse con facilidad para evaluarlos en una temprana fase del desarrollo, han de ser baratos y deben desarrollados en poco tiempo. Tienen como finalidad la de adquirir experiencia sin pretender emplearlos como productos. Una vez aceptado, el prototipo se desecha y se comienza el desarrollo desde cero. Prototipado Evolutivo construye una implementación parcial del sistema que satisface los requisitos conocidos, la cual es empleada por el usuario para comprender mejor la totalidad de requisitos que desea. Responde al enunciado “no sé qué quiero, pero cuando vea algo te lo digo”. Estos modelos se encaminan a conseguir un sistema flexible que se pueda expandir de forma que sea posible realizar rápidamente un nuevo sistema cuando los requisitos cambian. En este modelo se asume que los requisitos van a cambiar continuamente desde el principio. Prototipado Incremental Incorpora conceptos del modelo en Cascada y del de Prototipos. El proyecto se desarrolla en capas. Partiendo de un mo- delo en cascada se crea una primera versión, cuya funcionalidad se va ampliando a medida la especificación crece. La gran diferencia respecto al modelo evolutivo es que los requisitos sí se conocen en su totalidad, pero su implementación se va dosificando deliberadamente. Modelo en Espiral Creado por Böehm. Este modelo se caracteriza principalmente porque incorpora un nuevo elemento: el análisis de riesgos. En cada giro (vuelta a la espiral) se construye un nuevo modelo del sistema completo. Recomendado para grandes sistemas. Las principales diferencias entre este modelo y los anteriores son:
En este modelo hay un reconocimiento explícito de las diferentes alternativas para alcanzar los objetivos del proyecto.
Se centra en la identificación de los riesgos asociados a cada alternativa y en la manera de resolver dichos riesgos.
Los proyectos se dividen en ciclos (ciclos de la espiral) avanzándose en el desarrollo mediante consensos al final de cada ciclo.
Se adapta a cualquier tipo de actividad. Fases de un ciclo: planificación, análisis de riesgos, ingeniería y evaluación. Ventajas modelo en espiral:
Concentra su atención en opciones que consideran la reutilización de software existente
Permite preparar la evolución del ciclo de vida, crecimiento y cambios del producto software.
Es especialmente adecuado para la temprana eliminación de errores. El Plan de Gestión del Riesgo. Plan de Gestión del Riesgo asegura que en cada proyecto se haga una identificación temprana de sus items de riesgo más altos; desarrolla una estrategia para resolver los items de riesgo; identifica y establece una agenda para resolver nuevos items de riesgo a medida que afloran y, por último, muestra los progresos respecto al plan en revisiones mensuales.

Modelos basados en la transformación

El modelo de transformación asume la existencia de la posibilidad de convertir, automáticamente, una especificación formal de un producto software en un programa que satisface las especificaciones. Los pasos seguidos por el modelo de transformación son:

Especificaciónformaldelproductotalcomopermitelacomprensióninicialdelproblema.
Transformaciónautomáticadelaespecificaciónencódigo.
Unbucleiterativo,sifueranecesario,paramejorarelrendimientodelcódigoresultante.
Probarconelproductoresultante.

resumen85 sobre codificacion de datos, Apuntes de Minería de Datos

Documentos relacionados