Modelos de desarrollo de software separata

1,769 views

Published on

Modelos de desarrollo de software

Published in: Education, Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,769
On SlideShare
0
From Embeds
0
Number of Embeds
489
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Modelos de desarrollo de software separata

  1. 1. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero MODELOS DE PROCESOS DESARROLLO DE SOFTWARE EL MODELO EN CASCADA El modelo en cascada, algunas veces llamado el ciclo de vida clásico, sugiere el oun enfoque sistemático, secuencial hacia el desarrollo del software, que se igu erinicia con la especificación de requerimientos del cliente y que continúa con M omla planeación, el modelado, la construcción y el despliegue para culminar enel soporte del software terminado. El modelo en cascada es el paradigma más antiguo para la ingeniería del an Rsoftware. Sin embargo, en las décadas pasadas. , S rvin Problemas: GB a1. Es muy raro que los proyectos reales sigan el flujo secuencial que U c. M propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto actúa. Con frecuencia es difícil para el cliente establecer todos los requisitos de Li2. manera explícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos.3. El cliente debe tener paciencia. Una versión que funcione de los programas estará disponible cuando el proyecto esté muy avanzado. Un error grave será desastroso si no se detecta antes de la revisión del programa.En la actualidad, el trabajo del software está acelerado y sujeto a una cadenainfinita de cambios (de características, funciones y contenido de lainformación). Con frecuencia, el modelo en cascada no es apropiado paradicho trabajo. Sin embargo, puede servir como un modelo de proceso útil ensituaciones donde los requerimientos están fijos y donde el trabajo serealiza, hasta su conclusión, de una manera lineal.www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  2. 2. marfonline@gmail.com UGB San Miguel Lic. Marvin RomeroMODELO INCREMENTAL el o igu er M om an REl modelo incremental combina elementos del modelo en cascada aplicado enforma iterativa. El modelo incremental aplica secuencias lineales de manera , S rvinescalonada conforme avanza el tiempo en el calendario. Cada secuencialineal produce "incrementos" del software. Por ejemplo, el softwareprocesador de texto, desarrollado con el paradigma incremental en su GB aprimer incremento, podría realizar funciones básicas de administración de U c. Marchivos, edición y producción de documentos; en el segundo incremento,ediciones más sofisticadas, y tendría funciones más complejas deproducción de documentos; en el tercer incremento, funciones de corrección Liortográfica y gramatical; y en el cuarto, capacidades avanzadas deconfiguración de página.El modelo de proceso incremental, al igual que la construcción de prototiposy otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia dela construcción de prototipos, el modelo incremental se enfoca en la entregade un producto operacional con cada incremento. Los primeros incrementosson versiones "incompletas" del producto final, pero proporcionan al usuariola funcionalidad que necesita y una plataforma para evaluarlo.El desarrollo incremental es útil sobre todo cuando el personal necesariopara una implementación completa no está disponible. Los primerosincrementos se pueden implementar con menos gente. Si el productoesencial es bien recibido se agrega (si se requiere) más personal paraimplementar el incremento siguiente. Además, los incrementos se puedenplanear para manejar los riesgos técnicos. Por ejemplo, un sistema grandepodría requerir la disponibilidad de un hardware nuevo que está endesarrollo y cuya fecha de entrega es incierta. Sería posible planear losprimeros incrementos de forma que se evite el uso de este hardware, lo quewww.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  3. 3. marfonline@gmail.com UGB San Miguel Lic. Marvin Romeropermitiría la entrega de funcionalidad parcial a los usuarios finales sinretrasos desordenados.MODELO DRA el o igu er M om an R , S rvin GB a U c. M LiEl desarrollo rápido de aplicaciones (DRA) es un modelo de proceso desoftware incremental que resalta un ciclo de desarrollo corto. El modelo DRAes una adaptación a "alta velocidad" del modelo en cascada en el que se lograel desarrollo rápido mediante un enfoque de construcción basado encomponentes. Si se entienden bien los requisitos y se limita el ámbito delproyecto, el proceso DRA permite que un equipo de desarrollo cree un"sistema completamente funcional" dentro de un periodo muy corto (porejemplo, de 60 a 90 días).Como otros modelos de proceso, el enfoque DRA cumple con las actividadesgenéricas del marco de trabajo que ya se han presentado. La comunicacióntrabaja para entender el problema de negocios y las características deinformación que debe incluir el software. La planeación es esencial porquevarios equipos de software trabajan en paralelo sobre diferentes funcionesdel sistema. El modelado incluye tres grandes fases —modelado de negocios,www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  4. 4. marfonline@gmail.com UGB San Miguel Lic. Marvin Romeromodelado de datos y modelado del proceso— y establece representacionesdel diseño que sirven como base para la actividad de construcción delmodelo DRA. La construcción resalta el empleo de componentes de softwareexistente y la aplicación de la generación automática de código. Por último,el despliegue establece una base para las iteraciones subsecuentes, si éstasson necesarias.Si una aplicación de negocios se puede modular de forma que cada granfunción pueda completarse en menos de tres meses (mediante la aplicacióndel enfoque ya descrito), ésta es una candidata para el DRA. Cada granfunción se puede abordar mediante un equipo de DRA por separado, paradespués integrarlas y formar un todo.Como todos los modelos de proceso, el enfoque DRA tiene inconvenientes1) para proyectos grandes, pero escalables, el DRA necesita suficientesrecursos humanos para crear el número correcto de equipos DRA; el o2) si los desarrolladores y clientes no se comprometen con las actividades igu errápidas necesarias para completar el sistema en un marco de tiempo muybreve, los proyectos de DRA fallarán; M om3) si un sistema no se puede modular en forma apropiada, la construcción de an Rlos componentes necesarios para el DRA será problemática; , S rvin4) si el alto rendimiento es un aspecto importante, y se alcanzará al convertirinterfases en componentes del sistema, el enfoque DRA podría no funcionar;y GB a U c. M5) el DRA sería inapropiado cuando los riesgos técnicos son altos (porejemplo, cuando una aplicación nueva aplica muchas nuevas tecnologías). Liwww.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  5. 5. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero MODELOS EVOLUTIVOSLos modelos evolutivos son iterativos; los caracteriza la forma en quepermiten que los ingenieros de software desarrollen versiones cada vez máscompletas del software. • CONSTRUCCIÓN DE PROTOTIPOS • MODELO EN ESPIRAL • MODELO DE DESARROLLO CONCURRENTECONSTRUCCION DE PROTOTIPOS el o igu er M om an R , S rvin GB a U c. M LiA menudo un cliente define un conjunto de objetivos generales para elsoftware, pero no identifica los requisitos detallados de entrada,procesamiento o salida. En otros casos, el responsable del desarrollo delsoftware está inseguro de la eficacia de un algoritmo, de la adaptabilidad dewww.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  6. 6. marfonline@gmail.com UGB San Miguel Lic. Marvin Romeroun sistema operativo o de la forma que debería tomar la interacciónhumano-máquina. En éstas, y en muchas otras situaciones, un paradigma deconstrucción de prototipos puede ofrecer el mejor enfoque.A pesar de que la construcción de prototipos se puede utilizar como unmodelo de proceso independiente, se emplea más comúnmente como unatécnica susceptible de implementarse dentro del contexto de cualquiera delos modelos de proceso expuestos en este capítulo. Sin importar la forma enque éste se aplique, el paradigma de construcción de prototipos ayuda alingeniero de sistemas y al cliente a entender de mejor manera cuál será elresultado de la construcción cuando los requisitos estén satisfechos.El paradigma de construcción de prototipos se inicia con la comunicación. Elingeniero de software y el cliente encuentran y definen los objetivos globalespara el software, identifican los requisitos conocidos y las áreas del esquemaen donde es necesaria más definición. Entonces se plantea con rapidez unaiteración de construcción de prototipos y se presenta el modelado (en laforma de un diseño rápido). El diseño rápido se centra en una representación el ode aquellos aspectos del software que serán visibles para el cliente o el igu erusuario final (por ejemplo, la configuración de la interfaz con el usuario y el M omformato de los despliegues de salida). El diseño rápido conduce a laconstrucción de un prototipo. Después, el prototipo lo evalúa el an Rcliente/usuario y con la retroalimentación se refinan los requisitos del soft-ware que se desarrollará. La iteración ocurre cuando el prototipo se ajusta , S rvinpara satisfacer las necesidades del cliente. Esto permite que al mismo tiempoel desarrollador entienda mejor lo que se debe hacer. GB aDe manera ideal, el prototipo debería servir como un mecanismo para U c. Midentificar los requisitos del software. Si se construye un prototipo detrabajo, el desarrollador intenta emplear los fragmentos del programa yaexistentes o aplica herramientas (como generadores de informes,administradores de ventanas, etcétera) que permiten producir programas de Litrabajo con rapidez.Pero ¿qué debe hacerse con el prototipo una vez cumplido el propósitodescrito? Brooks ofrece una respuesta:En la mayoría de los proyectos, el primer sistema construido apenas seutiliza. Tal vez sea demasiado lento, muy grande o torpe en su uso, oreúna las tres características a la vez. No existe otra opción que comenzarde nuevo, aunque sea doloroso, es lo mejor, y construir una revisiónrediseñada en la que se resuelvan estos problemas... Cuando se aplica unconcepto nuevo de sistema o una tecnología nueva, se tiene que construirun sistema inservible y que sea necesario desechar, porque incluso lamejor planeación no es omnisciente como para que el sistema estéperfecto desde la primera vez. Por lo tanto, la pregunta de laadministración no es si debe construirse un sistema piloto y desecharlo.Esto tendrá que hacerse. La única pregunta es si se planea la construcciónde un desechable o se promete entregárselo a los clientes.www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  7. 7. marfonline@gmail.com UGB San Miguel Lic. Marvin RomeroEl prototipo puede servir como "primer sistema", el que Brooks recomiendadesechar. Pero ésta tal vez sea una visión idealizada. Es verdad que a losclientes y los desarrolladores les gusta el paradigma de construcción deprototipos. A los usuarios les gusta el sistema real y a los desarrolladores lesgusta construir algo de inmediato. Sin embargo, la construcción deprototipos también se torna problemática por las siguientes razones:1. El cliente ve lo que parece una versión en funcionamiento del software, sinsaber que el prototipo está unido "con chicle y cable para embalaje", que porla prisa de hacerlo funcionar no se ha considerado la calidad del softwareglobal o la facilidad de mantenimiento a largo plazo. Cuando se informa queel producto debe construirse otra vez para mantener los altos niveles de cali-dad, el cliente no lo entiende y pide la aplicación de "unos pequeños ajustes"para que se pueda elaborar un producto final a partir del prototipo. Es muyfrecuente que la gestión del desarrollo de software sea muy lenta.2. A menudo, el desarrollador establece compromisos de implementaciónpara lograr que el prototipo funcione con rapidez. Tal vez se utilice un el osistema operativo o lenguaje de programación inadecuado sólo porque está igu erdisponible y es conocido; se puede implementar un algoritmo ineficiente M omsólo para mostrar capacidad. Después de un tiempo, el desarrollador quizáse familiarice con estas selecciones y olvide las razones por las que son an Rinapropiadas. La selección menos ideal ahora se convierte en una parteintegral del sistema. , S rvinA pesar de que tal vez surjan problemas, la construcción de prototipospuede ser un paradigma efectivo para la ingeniería del software. La clave GB aes definir las reglas del juego desde el principio; es decir, el cliente y el U c. Mdesarrollador se deben poner de acuerdo en que el prototipo se construyay sirva como un mecanismo para la definición de requisitos, en que sedescarte, al menos en parte, y en que después se desarrolle el softwarereal con un enfoque hacia la calidad. Liwww.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  8. 8. marfonline@gmail.com UGB San Miguel Lic. Marvin RomeroMODELO EN ESPIRAL el o igu er M om an R , S rvinEl modelo en espiral, que Boehm propuso originalmente, es un modelo deproceso de software evolutivo que conjuga la naturaleza iterativa de laconstrucción de prototipos con los aspectos controlados y sistemáticos del GB amodelo en cascada. Proporciona el material para el desarrollo rápido de U c. Mversiones incrementales del software. Boehm describe este modelo de lasiguiente manera:El modelo de desarrollo en espiral es un generador del modelo de proceso Liguiado por el riesgo que se emplea para conducir sistemas intensivos deingeniería del software concurrente y con múltiples usuarios. Tiene doscaracterísticas distintivas principales. Una de ellas es un enfoque cíclicopara el crecimiento incremental del grado de definición e implementaciónde un sistema, mientras disminuye su grado de riesgo. La otra es un con-junto de puntos de fijación para asegurar el compromiso del usuario consoluciones de sistema que sean factibles y mutuamente satisfactorias.Cuando se aplica el modelo en espiral, el software se desarrolla en una seriede entregas evolutivas. Durante las primeras iteraciones, la entrega tal vezsea un documento del modelo o un prototipo. Durante las últimasiteraciones se producen versiones cada vez más completas del sistemadesarrollado.Un proceso en espiral se divide en un conjunto de actividades del marco detrabajo que define el equipo de ingeniería del software. Para propósitosilustrativos se aprovechan las actividades genéricas del marco de trabajoexpuestas páginas atrás. Cada una de las actividades del marco de trabajorepresenta un segmento de la ruta en espiral. Cuando comienza este procesowww.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  9. 9. marfonline@gmail.com UGB San Miguel Lic. Marvin Romeroevolutivo el equipo de software realiza actividades implicadas en un circuitoalrededor de la espiral que tiene una dirección en el sentido del movimientode las manecillas del reloj, y que se inicia desde el centro. El riesgo es unfactor considerado en cada revolución. Los puntos de fijación —unacombinación de productos de trabajo y condiciones incluidas a lo largo de laruta de la espiral— se consideran para cada paso evolutivo.El primer circuito alrededor de la espiral quizá genere el desarrollo de unaespecificación del producto; los pasos subsecuentes alrededor de la espiralse pueden aprovechar para desarrollar un prototipo y después, en formaprogresiva, versiones más elaboradas del software. Cada paso a través de laregión de planeación resulta en ajustes al plan del proyecto. Los costos y elitinerario se ajustan con base en la retroalimentación derivada de la relacióncon el cliente después de la entrega. Además, el administrador del proyectoajusta el número de iteraciones planeado que se requiere para completar elsoftware.A diferencia de otros modelos de proceso que terminan cuando se entrega el el osoftware, el modelo en espiral puede adaptarse y aplicarse a lo largo de la igu ervida del software de computadora. Por lo tanto, el primer circuito alrededor M omde la espiral podría representar un "proyecto de desarrollo del concepto", elcual se inicia en el centro de la espiral y continúa por múltiples iteraciones 6 an Rhasta que el desarrollo del concepto esté completo. Si el concepto sedesarrollará en un producto real, el proceso continúa en la siguiente fase de , S rvinla espiral y comienza un "proyecto de desarrollo de un producto nuevo". Elnuevo producto evolucionará a través de un número de iteraciones alrededorde la espiral. Después, un circuito alrededor de la espiral se podría emplear GB apara representar un "proyecto de mejoramiento del producto". En esencia, la U c. Mespiral, cuando se caracteriza de esta forma, permanece operativa hasta queel software se retira. En ocasiones el proceso está inactivo, pero siempre quese inicie un cambio el proceso comienza en el punto de entrada aprobado Li(por ejemplo, mejoramiento del producto).El modelo en espiral es un enfoque realista para el desarrollo de software yde sistemas a gran escala. Como el software evoluciona conforme avanza elproceso, el desarrollador y el cliente entienden y reaccionan de mejormanera ante los riesgos en cada etapa evolutiva. El modelo en espiral empleala construcción de prototipos como un mecanismo encaminado a reducirriesgos pero, en forma más importante, permite al desarrollador laaplicación del enfoque de la construcción de prototipos en cualquier etapaevolutiva del producto. Mantiene el enfoque sistemático de los pasos quesugiere el ciclo de vida clásico, pero lo incorpora al marco de trabajo ite-rativo que refleja de forma más verídica el mundo real. El modelo en espiralexige una consideración directa de los riesgos técnicos en todas las etapas delproyecto y, si se aplica en forma apropiada, debe reducir los riesgos antes deque se vuelvan problemáticos.Así como otros paradigmas, el modelo en espiral no es una panacea. Esdifícil convencer a los clientes (en particular en situaciones bajo contrato) deque el enfoque evolutivo es controlable, ya que se requiere una habilidadwww.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  10. 10. marfonline@gmail.com UGB San Miguel Lic. Marvin Romeroconsiderable para evaluar el riesgo y se confia en dicha habilidad paraobtener el éxito. Si un riesgo importante no se descubre y administra, sinduda surgirán problemas.MODELO DE DESARROLLO CONCURRENTE el o igu er M om an R , S rvin GB a U c. M LiEl modelo de desarrollo concurrente, llamado algunas veces ingenieríaconcurrente, se representa en forma esquemática como una serie deactividades del marco de trabajo, acciones y tareas de la ingeniería delsoftware y sus estados asociados. Por ejemplo, la actividad de modelado,definida para el modelo en espiral, se lleva a cabo al invocar las accionessiguientes: construcción de prototipos o modelado y especificación delanálisis y diseño.7www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  11. 11. marfonline@gmail.com UGB San Miguel Lic. Marvin RomeroSe proporciona un esquema de una tarea de ingeniería de softwarerelacionada con la actividad de modelado para el modelo de procesoconcurrente. La actividad —modelado— puede estar en alguno de losestados destacados mencionados antes en cualquier momento dado. Deforma similar, otras actividades o tareas (por ejemplo, la comunicación y laconstrucción) se representan de una manera análoga. Todas las actividadesexisten de forma concurrente, pero se encuentran en diferentes estados. Porejemplo, al principio del proyecto la actividad de comunicación (no semuestra en la figura) ha completado su primera iteración y existe en elestado de en espera de cambios. La actividad de modelado que existió en elestado ninguno mientras se realizaba la comunicación inicial, ahora realizauna transición al estado en desarrollo. Sin embargo, si el cliente indicacambios en los requisitos, la actividad de modelado se mueve del estado endesarrollo al estado de en espera de cambios.El modelo de proceso concurrente define una serie de eventos quedispararán transiciones de estado a estado para cada una de las actividades, el oacciones o tareas de la ingeniería del software. Por ejemplo, durante los igu erprimeros estados del diseño (una acción de la ingeniería del software queocurre en el curso de la actividad de modelación) no se detecta una M ominconsistencia en el modelo del análisis. Esto genera el evento corrección delanálisis del modelo, el cual disparará la creación del análisis desde el estado an Rrealizado hasta el estado de en espera de cambios. , S rvinEl modelo de proceso concurrente se aplica a todos los tipos de desarrollode software y proporciona una visión exacta del estado actual de unproyecto. En lugar de confinar las actividades, acciones y tareas de la GB aingeniería del software a una secuencia de eventos, define una red de U c. Mactividades. Cada actividad, acción o tarea en la red existe de manerasimultánea con otras actividades, acciones o tareas. Los eventos generadosentre los estados. Liwww.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...
  12. 12. marfonline@gmail.com UGB San Miguel Lic. Marvin Romero Actividad Nº 1 el o igu er M om Actividad Nº 2 an RInvestigue Y Explique: , S rvin • Cuáles son los Modelos Especializados de Proceso: – Desarrollo basado en C____________ GB a – Modelo de _____________ Formales U c. M – Desarrollo de Software Orientado a A_________ Liwww.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...

×