INSTITUTOPOLITCNICONACIONAL

UNIDADPROFESIONALINTERDISCIPLINARIADEINGENIERAYCIENCIASSOCIALES
YADMINISTRATIVAS

Tema:MtodoIncremental.

EstradaMartnezAldoDavid

MaldonadoRodrguezPamelaMontserrat

NolascoOrtizEduardo

OrtzSnchezGabriela

ViteHernandezArletKenia

Coordinador:ViteHernandezArletKenia

Fecha:24/Febrero/2016

Introduccin

Existen modelos que facilitan la estructuracin, planificacin y control del proceso de

desarrollo de software, para esto se aplicanmetodologas, tcnicas y modelos quepermiten
resolver todo tipo de problemas. Desde 1985 hasta el presente, han ido apareciendo
herramientas, metodologas ytecnologasque se presentaban como lasolucindefinitivaal
problema de la planificacin, previsin de costos y aseguramiento de la calidad en el
desarrollo de software. La dificultad propia de los nuevos sistemas, y su impacto en las
organizaciones, ponen de manifiesto las ventajas, y en muchos casos la necesidad, de
aplicarunametodologaformalparallevaracabolosproyectosdeestetipo
.
(Valds,2014)

En ste documento se pretende dar a conocer un modelo valioso propuesto por el

Profesor de Ciencias de la Computacin del Instituto de Tecnologa de Florida, Dr. Harlan
Mills. Su modelo, conocido como
Mtodo de las comparaciones limitadas sucesivas
o
Modelo Incremental
el cual bsicamente combina diferentes elementos secuenciales con
una filosofa interactiva en la que se mantiene al usuario/cliente enconstante contactocon
los resultados obtenidosen cada
incremento obtenido. Unincrementoeselproductofinalde
la aplicacinde lasfases delModeloIncremental,enelqueelsistemageneralsedivideyse
obtienendelsubsistemasmsfcilesdemanipular,loscuales,alfinalizardeestructurarlos,
seasocianyenconjuntoproducenelsistemafinal.

ndice

Contenido.

Captulo1
.
Historia
4

Captulo2.Fases
.5

Captulo3.Caractersticasdelmodelo
7

Captulo4.Ventajas/Desventajas
.8

Captulo5.Casoprctico
9

Captulo6.
Frameworks10

Conclusiones...11

Bibliografas..11

Captulo1.Historia

Definamos la diferencia entre

modelo
y
metodologa.
Un modelo es un conjunto de
mtodos y agrupa lametodologa, es decirque para cumplir conelmodelosedebenseguir
pasos estrictos y bien definidos. A sta serie de pasos se le llama metodologa y al
concluirlos se est cumpliendo tambin el modelo. Entonces, el Modelo Incremental de
desarrollo de software contiene una metodologa sencilla de explicar, que se definir ms
adelante.

El M.I. (Modelo Incremental) fue propuesto por el Doctor Harlan Mills en el ao 1980,
quien
sugiriel enfoqueincrementaldedesarrollocomounamaneradereducirlarepeticin
deltrabajoenelprocesodedesarrollo y daroportunidadderetrasarla tomadedecisionesen
losrequisitoshastaadquirirexperienciaconel sistema.
(Pressman,2007)Suideaprincipales
la separacin del sistema general en subsistemas que puedan ser ms fcilmente
manipulados deforma que conla constanterevisinyaprobacin se llegueala unificacin
delsistemageneral.

Este modelo tambin es conocido como

Mtodo de las comparaciones limitadas
sucesivas
y
Mtodo de atacarel problemaporramasfusiona elementos del modelolineal
secuencial en elquese desarrollaporetapasyqueal trmino de cadaetapanoesposible
regresar, El modelolineal secuencialaplica cuatro fases o etapas (aplicadasrepetidamente)
que son: Planificacin, Anlisis de riesgos, Ingeniera y Evaluacin del cliente. stasfases
las toma el M.I. como parte de su construccin, aplicando las secuencias lineales pero de
manera escalonada. Cada secuencia lineal genera un incremento de software, y el primer
incremento denominado ncleo es el ms importante ya que contiene la idea principal e
incluyeeldesarrollodelosrequerimientosmsimportantesacordadosconelcliente.

Captulo2.Fases

Considerandoque lassecuenciaslinealesproducentanimportanteproducto,describimoslas
fasesdestasdetalladamente.

Imagen1.FasesdelModeloIncremental.

Anlisis

Enstaetapasedeterminanlos requerimientos delsistemaadesarrollar:Sieselprimer

incremento
se jerarquizan los requerimientos para comenzar a desempear los ms
importantes e
impostergables para el cliente. Se identificarn en los casos de uso las
operaciones ms importantes a realizar y los actores del sistema, sean primarios (quienes
interaccionan con el sistema para explotar su funcionalidad y trabajan directamente con el
software), secundarios (dansoportedel sistema para que losprimarios puedantrabajar).En
caso contrario, se evaluarn y detallarn los requerimientos siguientes en nuestra escalao
ensudefectolosnuevosrequerimientossillegaranasurgir.
Si es una iteracin se evaluarn las funciones correcciones y mejoras resultantes de las
pruebas.
5

Diseo

Esta seccin tiene como objetivo realizaruna implementacin eficiente quecumpla con
las funciones y los requerimientos que el cliente proporcion en la fase anterior. Aqu, se
determina laarquitectura lgicayfsica(componentes)delsistema,serealizaeldiseo lgico
funcional y tambin sediseanlas interfacesdeusuario parasuinteraccin.Juegaunpapel
importante ya que en ellaseestablece lacalidad delsoftware.Se producen variosmodelos
delsistemaoproductodelquesevaaconstruirelmismo,estosmodelospuedenevaluarsey
mejorarse antes de pasar a las siguientes fasesque son lageneracindecdigo, pruebas,
consultadeusuariosfinalesparaaprobardichoproyectoyfinalizarlo.

Cdigo

Enestaetapadel modelodeterminar el tipodelenguajedeprogramacinautilizarpara

realizar el software que se le entregar al cliente la cualatravs de su documentacinse
describe cada partedel cdigo realizado deacuerdoala ideaprincipalyaestablecidaen las
etapas anteriores y dando detalles del tiempo necesario que se invirti en los aplicativos
entregadosalclientehastallegaralaaplicacinfinalydefinitiva.

Prueba

Esta etapa consiste en

testear*
la aplicacin
para identificar los errores quellegarana
surgir, en determinado caso deque aparecieraalgunaanomalaseregresaalafaseanterior
y se corrige. Posteriormente, cuando el equipo de desarrollo se ha cerciorado de que el
aplicativoesaceptable, se muestra alclientequien finalmentedasu aprobacin.Hechosto
seentrega laaplicacinal usuarioysecierrael incrementodedichoproyectoparadarpaso
alsiguiente.

(*
Lapalabratestearnoexisteeneldiccionariodelarealacademiaespaola,provienedelapalabraeningls
testqusignificaprobar.)

Captulo3.Caractersticasdelmodelo

Caractersticasprincipales.

El sistema se entrega porpartes (incrementos)yconellosse entregalafuncionalidad

queserequiere.
Se entregan de manera sucesiva, cuando se termina uno, se vuelve la base del
comienzodelsiguiente.
Los requerimientos se priorizan y los ms relevantes son los primeros que se
consideran.
Elusuarioseinvolucraduranteeldesarrollodelproyecto.
Existemenosriesgodeinconformidadporpartedelusuario.
Durante el proyecto puede surgir la oportunidad de que se generen nuevos
requerimientos.
El usuariovaconociendo einteractuandoconelsistemadesdeantesquecomiencea
utilizarlo.

Beneficios

La construccin de un sistema de menor tamao siempre es ms til por su mejor

seguridadyaquenoesriesgoso.
El desarrollo de dichas partes funcionales nos ayudaran para determinar si los
requerimientossonaptosparalossubnivelesconsiguientes.
Siunerrorquetienesumaimportanciasellevaacabo,laltimaiteracinsernegada
Haciendo ms corto el tiempo de desarrollo delsistema, se hacems factiblepara
quelosdiferentesusuariosnopuedanhacermodificaciones.
Unincrementopreviopuedeserutilizadodadounerrorrealizado.
Elresultadoconsiguienteobtenidosermuypositivo

Captulo4.Ventajas/Desventajas

Ventajas

Unavezquesetienebienestablecidalaideaprincipalsereducetiempo.
El cliente puede hacer uso del programa o tener interacciones constantes, aunque
estesigaenconstruccin.
La correccin es bastante cmoda debido a que se realiza por subproyectos de
acuerdoalincrementoqueselleve.
Lascorreccionesserealizanenelmomentoqueestassondetectadas.
Estil cuandonosecuentaconelpersonalsuficienteparalacodificacincompletade
dichosistema.

Desventajas

Noserecomiendaensistemasdetiemporeal.
Serequieredeunprototipoprincipal,parapodercomenzarconelproyecto.
El costo delproyecto puedeaumentar por lascorreccionesqueserealicen osienun
determinadomomentosellegaamodificarlaideaprincipal.
Se requiere de mucha planeacin de manera administrativa y tcnica, para obtener
mejoresresultados.

Captulo5.CasoPrctico

Ejemplo

Imaginemos que un cliente desea una aplicacin que trabaje como

Calculadora.
Identificamos mediante lajerarquizacin de los requerimientos queel msimportante es
la resolucin de funciones matemticas de grado
n y la obtencin de los puntos en el
plano. Entonces en nuestro primerincremento seincluirel desarrollo de la
Calculadora
laresolucindeoperacionesbsicasydefuncionesdegrado
n.

Conforme terminemos las cuatrofases del primerincremento, se leharentregadel

aplicativoal cliente,demaneraquestepueda comenzara utilizarelsistemaapesarde
quenosehaconcluido.

Para la entrega del segundo incremento, se agrega a la

Calculadora
la funcin de
graficar lospuntosobtenidosdelaresolucindefuncionesquecubrimosenelincremento
anterior.

Terminando stose le entrega nuevamente elaplicativo alclientequeledarusoala

nuevafuncin.

Supongamos que slo faltaagregaruna ltima funcinala

Calculadora
:laresolucin
de problemas fsicos. Entonces en el tercer incremento que realizaremos,
desarrollaremos la tercera y ltima funcionalidad que el cliente especific dentrodesus
requerimientos. Al concluir las cuatro fases del ltimo incremento seentregar elltimo
aplicativoalclienteyconellolasolucincompleta.

Captulo6.Frameworks

Enestemodelocomosepuedeapreciarse usaunamaneradetrabajodenominadacomo
Pipeline Para la creacin de este modelo existen frameworks considerando 2 de los ms
utilizados los cuales son Rational Unified Process y el Dynamic Systems Development
Method as como tambin se hace referencia a l en unmodelo de programacinllamado
Extreme Programming, los cuales se consideran como mtodos de desarrollo rpido del
software.

RationalUnifiedProcess:

Este sistema es actualmente propiedad de IBM y se conceptualiza como un modelo

estndar utilizado para el anlisis, diseo, implementacin y documentacin este tipo de
enfoque es uno de los ms requeridos en sistemas que estn orientados a objetos por su
semejanzaencuantoprogramacinpormediodemdulos.
cuyaestructuraeslasiguiente:

Adaptarelprocesoparaunamayorexactitud
Teneruncontrolsobrelosmdulosrelevantes
Demostrarvaloriterativamente
Colaboracinentreequipos
Contieneungranenfoquehacialacalidad

DynamicSystemsDevelopmentMethod:
Este tipodeframework fuedesarrolladoporlos aos90en elReinoUnido quepropusoque
la estructura para la resolucin de los problemas cuyas caractersticas fueran no tan
demandantesyprecisasporelloesconceptualizadocomounsoftwarededesarrollogil.
cuyaestructuraeslasiguiente:
Primerpasosecontemplaelestudiodeviabilidad,
Despus la informacin que el cliente proporcione y la que no por medio de un
estudio
Pormedioderepeticionessiendounmodelofuncional,
diseoeiteracindelaestructura

10

implementacinconlascorreccionesestablecidasyelsistemaperfeccionado.

Conclusiones

El objetivo del desarrollo incrementalesel desarrollarun softwaresacando provecho

deloquesehaaprendidoduranteeldesarrolloanterior,mejorandolasversionesentregables
del sistema considerando que en cada iteracin se realiza la mejora del sistema y se le
agregannuevascaractersticas.

Elmodelotieneplanteadosdosproblemas

1. Realmente no se sabe con exactitud qu es lo que sequiere delsistemaosi es

posibleabordarlodeestamaneraparalograrsatisfacerloquenecesitan.
2.Duranteel desarrollo se encuentran nuevasproblemticasporlotantopuedellegar
acambiar.

Bibliografa
Valds,J.L.(2014).
ModelodeDesarrollodeSoftwareIntegralColaborativo.
Cieco.
Pressman,Roger(2007).
IngenieradelSoftware.
MacGrawHill5taEdicin.

11