Вы находитесь на странице: 1из 8

MODELO

CARACTERISTICAS
Anlisis: Necesidades del usuario especificaciones Diseo: Descomposici n en elemen!os "ue puedan desarrollarse por separado especificaciones de cada elemen!o Codificacin: Pro#ramaci n de cada elemen!o por separado $%prue&as aisladas' In!e#raci n( Se )un!an los elemen!os * se prue&a el sis!ema comple!o Mantenimiento: Cam&ios ocasionales $errores o me)oras'

FASES
Anlisis del Sistema: Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algn subconjunto de estos requisitos al software. Diseo: el diseo del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la interfaz. El proceso de diseo traduce los requisitos en una representacin del software con la calidad requerida antes de que comience la codificacin

TIEMPO DE ELABORACION

EJEMPL

PROCESO DE DESARROLLO DEL SOFTWARE MODELO EN CASCADA

EL MODELO DE DRA

Es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo D!" es una adaptacin a alta #elocidad del modelo de cascada en el que se logra el desarrollo r$pido mediante un enfoque de construccin basado en componentes. %etodolog&a basada en prueba y error. 'undamentada en #alores y pr$cticas. E(presada en forma de )* practicas.

Modelado de estin El flu)o de informaci n en!re las funciones de #es!i n se modela de forma "ue responda a las si#uien!es pre#un!as( +,u- informaci n conduce el proceso de #es!i n. +,u- informaci n se #enera. +,ui-n la #enera. +A d nde /a la informaci n. +,ui-n la proceso.0 ! Modelado de Datos El flu)o de informaci n definido como par!e de la fase de modelado de #es!i n se refina como un con)un!o de

DE +, " -, D."/.

0uando se 1ace de una nue#a tecnolog&a o cuando el software nue#o requiere de cierta interoperabilidad con otros programas y e(istentes. 2ersin beta que se saca a prueba para que otros usuarios lo utilicen y #ean que errores tiene para que al #ol#er a en#i$rselo al desarrollador para que

o&)e!os de da!os necesarios para apo*ar la empresa0 Se definen las carac!er1s!icas $llamadas a!ri&u!os' de cada uno de los o&)e!os * las relaciones en!re es!os o&)e!os0 ! Modelado de P"ocesos Los o&)e!os de da!os definidos en la fase de modelado de da!os "uedan !ransformados para lo#rar el flu)o de informaci n necesario para implemen!ar una funci n de #es!i n0 Las descripciones del proceso se crean para a2adir3 modificar3 suprimir3 o recuperar un o&)e!o de da!os0 Es la comunicaci n en!re los o&)e!os0 4 5eneraci n de Aplicaciones El DRA asume la u!ili6aci n de !-cnicas de cuar!a #eneraci n0 En lu#ar de crear sof!7are con len#ua)es de pro#ramaci n de !ercera #eneraci n3 el proceso DRA !ra&a)a para /ol/er a u!ili6ar componen!es de pro#ramas *a e8is!en!es $cuando es posi&le' o a crear componen!es reu!ili6a&les $cuando sea necesario'0 4 Prue&as de En!re#a Como el proceso DRA enfa!i6a la reu!ili6aci n3 *a se 9an compro&ado muc9os de los componen!es de los pro#ramas0 Es!o reduce !iempo de prue&as0 Sin em&ar#o3 se de&en pro&ar !odos los componen!es nue/os * se de&en e)erci!ar !odas las in!erfaces a fondo0

identifique lo errores y para que saque la #ersin completa y sin errores.

MODELO DE CASCADA

:El modelo reali6a una re/isi n al final de cada e!apa para de!erminar si es!; preparado para pasar a la si#uien!e e!apa0 < El modelo en cascada es!; diri#ido por documen!os0 < A*uda a locali6ar errores en las primeras e!apas del pro*ec!o a un &a)o cos!o0 < Funciona especialmen!e &ien si se dispone de personal poco calificado o ine8per!o3 por"ue presen!a el pro*ec!o con una es!ruc!ura "ue a*uda a minimi6ar el esfuer6o in=!il0

Anlisis de "e#$isitos
En es!a fase se anali6an las necesidades de los usuarios finales del sof!7are para de!erminar "u- o&)e!i/os de&e cu&rir0 De es!a fase sur#e una memoria llamada SRD $documen!o de especificaci n de re"uisi!os'3 "ue con!iene la especificaci n comple!a de lo "ue de&e 9acer el sis!ema sin en!rar en de!alles in!ernos0 Es impor!an!e se2alar "ue en es!a e!apa se de&e consensuar !odo lo "ue se re"uiere del sis!ema * ser; a"uello lo "ue se#uir; en las si#uien!es e!apas3 no pudi-ndose re"uerir nue/os resul!ados a mi!ad del proceso de ela&oraci n del sof!7are0

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creacin de un /istema 3perati#o.

Diseo del Sistema


Descompone * or#ani6a el sis!ema en elemen!os "ue puedan ela&orarse por separado3 apro/ec9ando las /en!a)as del desarrollo en e"uipo0 Como resul!ado sur#e el SDD $Documen!o de

Dise2o del Sof!7are'3 "ue con!iene la descripci n de la es!ruc!ura relacional #lo&al del sis!ema * la especificaci n de lo "ue de&e 9acer cada una de sus par!es3 as1 como la manera en "ue se com&inan unas con o!ras0 Es con/enien!e dis!in#uir en!re dise2o de al!o ni/el o ar"ui!ec! nico * dise2o de!allado0 El primero de ellos !iene como o&)e!i/o definir la es!ruc!ura de la soluci n $una /e6 "ue la fase de an;lisis 9a descri!o el pro&lema' iden!ificando #randes m dulos $con)un!os de funciones "ue /an a es!ar asociadas' * sus relaciones0 Con ello se define la ar"ui!ec!ura de la soluci n ele#ida0 El se#undo define los al#ori!mos empleados * la or#ani6aci n del c di#o para comen6ar la implemen!aci n0

Diseo del P"o%"ama


Es la fase en donde se reali6an los al#ori!mos necesarios para el cumplimien!o de los re"uerimien!os del usuario as1 como !am&i-n los an;lisis necesarios para sa&er "ue 9erramien!as usar en la e!apa de Codificaci n0

Codificacin
Es la fase en donde se implemen!a el c di#o fuen!e3 9aciendo uso de pro!o!ipos as1 como de prue&as * ensa*os para corre#ir errores0 Dependiendo del len#ua)e de pro#ramaci n * su /ersi n se crean las &i&lio!ecas *

componen!es reu!ili6a&les den!ro del mismo pro*ec!o para 9acer "ue la pro#ramaci n sea un proceso muc9o m;s r;pido0

P"$e&as
Los elemen!os3 *a pro#ramados3 se ensam&lan para componer el sis!ema * se comprue&a "ue funciona correc!amen!e * "ue cumple con los re"uisi!os3 an!es de ser en!re#ado al usuario final0

'e"ificacin
Es la fase en donde el usuario final e)ecu!a el sis!ema3 para ello el o los pro#ramadores *a reali6aron e89aus!i/as prue&as para compro&ar "ue el sis!ema no falle0 En la creacion de desarrollo de cascada se implemen!a los codi#os de in/es!i#acion * pue&as del mismo

Mantenimiento
>na de las e!apas mas cri!icas3 *a "ue se des!ina un ?@A de los recursos3 es el man!enimien!o del Sof!7are *a "ue al u!ili6arlo como usuario final puede ser "ue no cumpla con !odas nues!ras e8pec!a!i/as0 El modelo en espiral puede adaptarse y aplicarse a lo largo de la #ida del software de computadora. 0omo el software e#oluciona a medida que progresa el proceso, el

/e planificaran los

siguientes pasos y se comienza un nue#o ciclo de la espiral. 4a espiral tiene una forma de caracola y se dice que mantiene dos

MODELO ESPIRAL

dimensiones, la radial y la angular:

).
desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los ni#ele e#oluti#os. El modelo en espiral permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de e#olucin del producto. El modelo en espiral demanda una consideracin directa de los riesgos t5cnicos en todas las etapas del proyecto y si se aplica adecuadamente debe reducir los riesgos antes de que se con#iertan en problemas.

Angular: .ndi

ca el a#ance del proyecto del software dentro de un ciclo.

*.

Radial: .ndic

a el aumento del coste del proyecto, ya que con cada nue#a iteracin se pasa m$s tiempo desarrollando. Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creacin de un /istema 3perati#o. "l ser un modelo de 0iclo de 2ida orientado a la gestin de riesgo se dice que uno

En la utilizacin de de los aspectos grandes sistemas a fundamentales de su 5(ito doblado la producti#idad.

radica en que el equipo que lo aplique tenga la necesaria e(periencia y 1abilidad para detectar y catalogar correctamente los riesgos.

%3DE43 67
En 67 se trabaja estrec1amente con el cliente, se 1ace pequeas iteraciones cada dos semanas, donde no e(iste mas documentacin que el cdigo en si8 cada #ersin contiene las modificaciones necesarias segn como el cliente #aya retroalimentando al sistema, por eso es necesaria la disponibilidad del cliente durante el desarrollo. 67 utiliza 9istorias de :suarios, es una frase que representa a una funcin que realizar$ el sistema. 0ada 9istoria de :suario no puede demorar en desarrollarse m$s de una semana, si as& lo requiere, debe de segmentarse. ;ambi5n es un requisito en 67 definir un Est$ndar en el ;ipo de 0odificacin, lo cual le permite a los programadores tener definido un slo estilo al momento de programar. 4os programadores trabajan en parejas intercambi$ndose en el tipeo, esta forma de trabajo tiene #entajas como: Detecta f$cilmente los errores de programacin, uno de los programador que est$ #isualizando controla al que tipea El programador poco e(perimentado aprende del que m$s lo est$. Fase de Explora i!n"#en esta fase la 9istoria de :suarios es de gran inter5s para la primera entrega del producto, lo que permite al equipo de desarrollo familiarizarse con las 1erramientas, tecnolog&as y pr$cticas que se utilizara en el proyecto. /e construye un prototipo que pruebe las tecnolog&as y e(plore las posibilidades de la arquitectura del sistema. 4a fase de e(ploracin se toma semanas o meses dependiendo del tamao y familiaridad que tengan los programadores con la tecnolog&a. Fase de Planeamiento"#los programadores consideran el esfuerzo que requiere cada 1istoria y a partir de all& se define el cronograma. 7ara el primer release <liberacin=, la duracin del cronograma no e(cede m$s de dos meses, se toma en cuenta #arias iteraciones para lograr un release. 4a primera iteracin crea un sistema con la arquitectura del sistema completo, esto se 1ar$ seleccionando las 1istorias que 1ar$n cumplir la construccin de la estructura para el sistema completo. 4as 1istorias ser$n seleccionadas por el cliente para cada iteracin, al final de la ltima iteracin el sistema estar$ listo para la produccin. Fase de Produ i!n"#requiere prueba y comprobacin e(tra del funcionamiento del sistema antes de que esta pueda liberar al cliente. Durante esta fase, las iteraciones pueden ser aceleradas de una a tres semanas, las ideas y las sugerencias que se pospongan se documentan para una puesta en pr$ctica posterior, por ejemplo en la fase de mantenimiento. Fase de Mantenimiento"#requiere de un mayor esfuerzo para satisfacer las tareas del cliente. "s& la #elocidad del desarrollo puede desacelerar despu5s CICLO DE $IDA El ciclo de #ida de 67 segn una iteracin de desarrollo es el tiempo en el que se realiza un conjunto de funciones determinadas que en 67 corresponden a un conjunto de 9istorias de :suarios. 4as iteraciones son cortas ya que entre mas r$pido se le entreguen los desarrollos al cliente muc1a mas retroalimentacin se #a a obtener, lo cual significa una mejor calidad del producto a largo plazo. E(iste un ni#el de an$lisis inicial orientado a programar las iteraciones de desarrollo y cada iteracin incluye, diseo, codificacin y pruebas.

de que el sistema est5 en la produccin. 4a fase de mantenimiento puede requerir la incorporacin de nue#a gente y cambiar la estructura del equipo. Fase de Muerte"#es cuando el cliente no tiene m$s 1istorias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema, se genera la documentacin final del sistema y no se realizan m$s cambios en la arquitectura. 4a muerte del proyecto tambi5n puede ocurrir cuando el sistema no genere los beneficios esperados por el cliente o cuando no 1ay presupuesto par mantenerlo.

Вам также может понравиться