codificar y corregir

El modelo codificar y corregir es el modelo utilizado cuando no nos paramos en buscar el modelo ms idneo para nuestro proyecto. Es decir en este modelo no se pierde el tiempo en la planificacin, en la calidad, en los documentos que hay que realizar cuando se terminan etapas o en cualquier otra actividad que no sea la codificacin. Por lo tanto este modelo no se necesita tener experiencia y una gran cantidad de conocimientos. Al no seguir un modelo no tenemos ningn medio de ver si se cumplen las expectativas creadas, lo cual es un problema si encontramos un error casi al finalizar el proyecto ya que hay que empezar de nuevo. Por consiguiente tardamos ms en ver los errores que en otro modelo que sigue un mnimo de planificacin.

es un modelo bsico utilizado en los inicios del desarrollo de software. Contiene dos pasos: Escribir cdigo. Corregir problemas en el cdigo. Se trata de primero implementar algo de cdigo y luego pensar acerca de requisitos, diseo, validacin, y mantenimiento.

surgi cuando la necesidad de adaptar los sistemas informticos a las exigencias del mercado, el programa realizaba un relevamiento de las solicitudes de quien necesitaba cierto programa o producto de software, y con aquellos requerimientos bajo el brazo comenzaba la dura tarea de codificar. Esta tarea no estaba administrada, supervisada o gestionada de ningn modo, por lo que se iba corrigiendo a medida que surgan los errores, tanto lgicos provenientes de la codificacin, como los de requerimientos solicitados por el cliente o usuario final.

No conlleva ninguna gestin; no se pierde tiempo en la planificacin, en la documentacin, en el control de calidad, en el cumplimiento de los estndares, o en cualquier otra actividad que no sea codificacin pura. Como se pasa directamente a codificar, se pueden mostrar inmediatamente indicios de progreso. Requiere poca experiencia: cualquier persona que haya escrito alguna vez un programa est familiarizada con ste modelo. Para proyectos pequeos que se intentan liquidar en un tiempo breve, o para modelos como programas de demostracin o prototipos desechables, el modelo codificar y corregir puede ser til.

 El

modelo resulta peligroso para otro tipo de proyectos que no sean pequeos. Puede que no suponga gestin alguna, pero tampoco ofrece medios de evaluacin del progreso. No proporciona medios de evaluacin de la calidad o de identificacin de riesgos. Si al llevar tres cuartas partes de la codificacin descubre que el diseo es incorrecto, no hay otra solucin que desechar el trabajo y comenzar de nuevo.

 Despus

de un nmero de correcciones, el cdigo puede tener una muy mala estructura, hace que los arreglos sean muy costosos. Frecuentemente, an el software bien diseado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstruccin es muy cara. El cdigo es difcil de reparar por su pobre preparacin para probar y modificar

 Integrantes: Jhovany Enrique

Gpe Flores de los Santos Pacheco Cruz

CICLOS DE VIDA EN ESPIRAL

ES UN MODELO DE CICLO DE VIDA DEL SOFTWARE DEFINIDO POR PRIMERA VEZ POR BARRY BOEHM EN 1988, UTILIZADO GENERALMENTE EN LA INGENIERA DEL SOFTWARE. LAS ACTIVIDADES DE ESTE MODELO SE CONFORMAN EN UNA ESPIRAL, EN LA QUE CADA BUCLE REPRESENTA UN CONJUNTO DE ACTIVIDADES.

EL CICLO DE VIDA EN ESPIRAL CONSISTE EN UNA SERIE DE CICLOS QUE SE REPITEN. CADA UNO TIENE LAS MISMAS FASES Y CUANDO TERMINA DA UN PRODUCTO AMPLIADO CON RESPECTO AL CICLO ANTERIOR. UN EJEMPLO DE ESTE, ES LA SIG. IMAGEN.

EN CADA VUELTA O ITERACION HAY QUE TENER EN CUENTA LO SIG.

LOS OBJETIVOS: QUE NECESIDAD DEBE EJEMPLO, SE HACEN ENTREVISTAS A CUESTIONARIOS, ETC. CUBRIR EL PRODUCTO, POR LOS CLIENTES, SE LLENAN

ALTERNATIVAS: SON LAS DIFERENTES FORMAS POSIBLES DE CONSEGUIR LOS OBJETIVOS.

1. CARACTERSTICAS: EXPERIENCIA DEL PERSONAL, REQUISITOS A CUMPLIR, ETC. 2. FORMAS DE GESTIN DEL SISTEMA. 3. RIESGO ASUMIDO CON CADA ALTERNATIVA.
RESTRICCIONES: 1. DESDE EL PUNTO DE VISTA DEL PRODUCTO: INTERFACES DE TAL O CUAL MANERA, RENDIMIENTO, ETC. 2. DESDE EL PUNTO DE VISTA ORGANIZATIVO: COSTE, TIEMPO, PERSONAL, ETC. GESTIN: ES LA DISCIPLINA DE ORGANIZAR Y ADMINISTRAR RECURSOS DE MANERA TAL QUE SE PUEDA CULMINAR TODO EL TRABAJO REQUERIDO EN EL PROYECTO DENTRO DEL ALCANCE, EL TIEMPO, Y COSTE DEFINIDOS.

RIESGOS: LISTA DE RIESGOS IDENTIFICADOS. RESOLUCIN DE RIESGOS: LA TCNICA MS USADA ES LA CONSTRUCCIN DE PROTOTIPOS. RESULTADOS: SON LO QUE REALMENTE DESPUS DE LA RESOLUCIN DE RIESGOS. COMPROMISO: CONTINUAR. DECISIONES DE GESTIN HA OCURRIDO

PLANES: LO QUE SE VA A HACER EN LA SIGUIENTE FASE. SOBRE COMO

AL TERMINAR UNA ITERACIN SE COMPRUEBA QUE LO QUE SE HA HECHO EFECTIVAMENTE CUMPLE CON LOS REQUISITOS ESTABLECIDOS, TAMBIN SE VERIFICA QUE FUNCIONA CORRECTAMENTE. EL PROPIO CLIENTE EVALA EL PRODUCTO.

LAS VENTAJAS DE ESTE CICLO DE VIDA SON: NO NECESITA UNA DEFINICIN COMPLETA DE LOS REQUISITOS PARA EMPEZAR A FUNCIONAR. AL ENTREGAR PRODUCTOS DESDE EL FINAL DE LA PRIMERA ITERACIN ES MS FCIL VALIDAR LOS REQUISITOS. EL RIESGO EN GENERAL ES MENOR, PORQUE SI TODO SE HACE MAL, SOLO SE HA PERDIDO EL TIEMPO Y RECURSOS INVERTIDOS EN UNA ITERACIN (LAS ANTERIORES ITERACIONES ESTN BIEN). EL RIESGO DE SUFRIR RETRASOS ES MENOR, YA QUE AL IDENTIFICAR LOS PROBLEMAS EN ETAPAS TEMPRANAS HAY TIEMPO DE SUBSANARLOS.

LAS DESVENTAJAS: GENERA MUCHO TIEMPO EN EL DESARROLLO DEL SISTEMA MODELO COSTOSO REQUIERE EXPERIENCIA EN LA IDENTIFICACIN DE RIESGOS LOS INCONVENIENTES: ES DIFCIL EVALUAR LOS RIESGOS. NECESITA DE LA PARTICIPACIN CONTINUA POR PARTE DEL CLIENTE. CUANDO SE SUBCONTRATA HAY QUE PRODUCIR PREVIAMENTE UNA ESPECIFICACIN COMPLETA DE LO QUE SE NECESITA, Y ESTO LLEVA TIEMPO.

ESTE SISTEMA ES MUY UTILIZADO Y ADECUADO EN PROYECTOS GRANDES Y COMPLEJOS COMO PUEDE SER, LA CREACIN DE UN SISTEMA OPERATIVO, PROYECTOS DONDE SEA IMPORTANTE EL FACTOR RIESGO, CUANDO NO SEA POSIBLE DEFINIR AL PRINCIPIO TODOS LOS REQUISITOS. AL SER UN MODELO DE CICLO DE VIDA ORIENTADO A LA GESTIN DE RIESGO SE DICE QUE UNO DE LOS ASPECTOS FUNDAMENTALES DE SU XITO RADICA EN QUE EL EQUIPO QUE LO APLIQUE TENGA LA NECESARIA EXPERIENCIA Y HABILIDAD PARA DETECTAR Y CATALOGAR CORRECTAMENTE LOS RIESGOS.

CICLOS DE VIDA DEL SOFTWARE EVOLUTIVO

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximacin 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 slo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementacin parcial del sistema que recibe slo estos requerimientos. El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a los desarrolladores. Basada en esta retroalimentacin, la especificacin de requerimientos es actualizada, y una segunda versin del producto es desarrollada y desplegada. El proceso se repite indefinidamente.

VENTAJAS Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma especfica de observar el desarrollo de algn incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado tambin. 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.

DESVENTAJAS El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulacin de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentacin debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.

MODELO EVOLUTIVO

REQUERIMIENTOS

REQUERIMIENTOS

CONSTRUIR INCREMENTO #1

CONSTRUIR INCREMENTO #2

GRACIAS POR SU ATENCION

UNIVERSIDAD AUTONOMA DE BAJA CALIFORNIA SUR AREA DE CIENCIAS DEL MAR LIC. EN COMPUTACIN INGENIERA DEL SOFTWARE FLAVIO IGNACIO NAVA RUIZ PEDRO ENRIQUE ALBA OSUNA

Es un modelo de desarrollo de software iterativo en el cual el desarrollo es visto como un fluir constante para frente (como una cascada) a travs de las fases de anlisis de requisitos, proyecto, implementacin, pruebas, integracin, y mantenimiento de software.

En 1970 Royce propuso lo que es ahora popularmente designado en el modelo en cascada como un concepto inicial, un modelo en el cual l argumentaba ser defectuoso. Su trabajo entonces explor como el modelo inicial podra ser desarrollado en un modelo iterativo, con feedback de cada fase influenciando las prjimas, de modo similar a muchos mtodos ampliamente utilizados hoy

Se invent para permitir retroalimentacin y ensimamiento entre fases. Es un modelo iterativo y no lineal.

Debido al solapamiento los hitos son ms ambiguos. Problemas al tener tareas en paralelo, mala comunicacin, suposiciones incorrectas e ineficacia Se puede tener problemas cuando existen interdependencias Imprevistas entre los subsistemas

El modelo cascadas modificadas es aplicable a sistemas pequeos y bien definidos

El modelo cascada tambin es conocido como "modelo clsico", "modelo tradicional" o "modelo lineal secuencial.

es el paradigma ms antiguo y extensamente utilizado, sin embargo las crticas a l (ver desventajas) han puesto en duda su eficacia. Pese a todo tiene un lugar muy importante en la Ingeniera de software y contina siendo el ms utilizado; y siempre es mejor que un enfoque al azar

 fue

propuesto por W. Royce a principio de los aos 70. Bsicamente distingue una serie de pasos que se pueden resumir en:

A) Especificacin de requerimientos: el proceso de recopilacin de requerimientos se centra e intensifica especialmente para el software. Se debe a captar y comprender el mbito de la informacin del software as como la funcin, el rendimiento y los interfaces requeridos. Los requisitos se documentan y revisan con el cliente de la aplicacin. B) Diseo : es un proceso que se centra sobre cuatro atributos distintos del programa: 1.- estructura de datos. 2.- arquitectura del software. 3.- detalle procedural. 4.- caractersticas del interface. Se traducen los requisitos software en una presentacin del software establecida de forma que se obtenga la calidad requerida antes de empezar la codificacin. Al igual que los requerimientos, el diseo se documenta y forma parte de la configuracin del software.

C) Codificacin: es la traduccin de las especificaciones de diseo a un lenguaje de programacin determinado. Si el diseo se hizo detalladamente, la codificacin puede realizarse casi mecnicamente. D) Prueba: consiste en verificar el funcionamiento requerido del software. E) Integracin: de los distintos componentes software producidos. La integracin tambin comporta la realizacin de las pruebas pertinentes.

F) Mantenimiento: el software no est libre de modificaciones, bien por peticin del usuario del mismo, bien por detectarse anomalas en su funcionamiento. Este paradigma clsico posee muchas crticas fruto de la experiencia: 1.- suelen aparecer iteraciones en el flujo. 2.-normalmente es difcil para el cliente especificar desde el principio todos los requisitos. Al comienzo suele existir incertidumbre. 3.-el cliente debe tener paciencia pues hasta las etapas finales no existe una versin operativa del programa. Un error detectado al final del ciclo puede ser un desastre.

Aqu se muestra una representacin del ciclo de vida clsico, a la izquierda el que conceptualmente se desea y a la derecha el real, fruto de la experiencia

El modelo Cascada Realimentado resulta muy atractivo, hasta ideal, si el proyecto presenta alta rigidez (pocos o ningn cambio, no evolutivo), los requisitos son muy claros y estn correctamente especificados. Modelo y planificacin fcil y sencillos. Sus fases son conocidas por los desarrolladores Los usuarios lo pueden comprender fcilmente

Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificacin o prueba) pueden ser catastrficos para un proyecto grande. No es frecuente que el cliente o usuario final explique clara y completamente los requisitos (etapa de inicio); y el modelo lineal lo requiere. La incertidumbre natural en los comienzos es luego difcil de acomodar.

El cliente debe tener paciencia ya que el software no estar disponible hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase de operacin) puede ser desastroso, implicando reinicio del proyecto, con altos costos.

enfoque sistemtico o ms bien secuencial del desarrollo de software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas y mantenimiento.

Libro: Metodologa y tecnologa de la programacin

Escrito por autor: JUAN SANCHEZ DIAZ

GRACIAS POR SU ATENCION

Equipo:

Martha Alicia Gaxiola

Gabriel Heras Moldrano

Los productos de las diferentes etapas se van refinando y mejorando.

DESARROLLO POR FASES

El Desarrollo por fases surgi con el objetivo de reducir el tiempo del ciclo. El sistema se disea de modo que puede ser entregado en piezas, lo que permite que los usuarios dispongan de cierta funcionalidad mientras el resto del sistema est siendo desarrollado. Existen dos enfoques que utilizan los desarrolladores para organizar el desarrollo del software por versiones.

El sistema, es particionado en subsistemas de acuerdo a su funcionalidad. Las versiones se definen comenzando con un subsistema funcional pequeo y agregando funcionalidad con cada nueva versin.

Este enfoque entrega un sistema completo desde el principio, y luego cambia la funcionalidad de cada subsistema con cada nueva versin. Al final de cada ciclo se entrega una versin completa del software mejorada respecto a la anterior.

Ventajas Provee soporte para determinar la efectividad de los procesos y de la calidad del producto. Permite estudiar y despus mejorar y ajustar el proceso para el ambiente en particular. Se puede ir corrigiendo errores con el modelo iterativo Se puede agregar ms funcionalidades con el modelo incremental Desventajas El desarrollo con este modelo requiere ms tiempo para entregar un producto final. El modelo no es tan sencillo como el de cascada debido a su complejidad en la planificacin.

Modelo en V

El modelo de ciclo de vida V es una variacin del modelo en cascada que demuestra como se realiza las actividades de prueba con las de anlisis y diseo. El Mtodo-V es una representacin grfica del ciclo de vida del desarrollo del sistema. Resume los pasos principales que hay que tomar en conjuncin con las correspondientes entregas de los sistemas de validacin.

Ministerio de Defensa Alemn 1992 Propuesto por Alan Davis

Las ventajas y desventajas de este modelo son las mismas del modelo de cascada pura. Pero con el agregado de las los controles cruzados entre etapas para lograr una mayor correccin. Ventajas.-que si se encuentra problemas con durante la verificacin y la validacin , entonces el lado izquierdo del modelo V puede ser ejecutado nuevamente, para solucionar el problema y mejorar los requerimientos el diseo y el cdigo antes de retomar los pasos de prueba sobre el lado derecho.

Desventajas.- Si sean cometido errores y no se detectado en la etapa, es costoso y difcil volver atrs para realizar la correccin posterior.

Podemos utilizar este modelo de ciclo de vida en aplicaciones, que si bien son simples (por ejemplo pequeas transacciones sobre bases de datos), necesitan una confiabilidad muy alta.

Qu es?
Consiste en un procedimiento que permite al equipo de desarrollo

disear y analizar una aplicacin que representa el sistema que sera implementado (McCracken y Jackson, 1982). Dicha aplicacin, llamada prototipo, est compuesta por los componentes que se desean evaluar ( las funciones principales). Las etapas del modelo son: Investigacin preliminar. Colecta y refinamiento de los requerimientos y proyecto rpido. Anlisis y especificacin del prototipo. Diseo y construccin del prototipo. Evaluacin del prototipo por el cliente. Renacimiento del prototipo. Diseo tcnico. Programacin y test. Operacin y mantenimiento.

El paradigma de construccin de prototipos tiene los siguientes pasos:

PASO 1. Evaluar la peticin del software y determinar si el

programa a desarrollar es un buen candidato para construir un prototipo. Debido a que el cliente debe interaccionar con el prototipo en los ltimos pasos, es esencial que: 1) el cliente participe en la evaluacin y refinamiento del prototipo, y 2) el cliente sea capaz de tomar decisiones de requerimientos de una forma oportuna. Finalmente, la naturaleza del proyecto de desarrollo tendr una fuerte influencia en la eficacia del prototipo.

 PASO 2. Dado un proyecto candidato aceptable, el analista

desarrolla una representacin abreviada de los requerimientos. Antes de que pueda comenzar la construccin de un prototipo, el analista debe representar los dominios funcionales y de informacin del programa y desarrollar un mtodo razonable de particin. La aplicacin de estos principios de anlisis fundamentales, pueden realizarse mediante los mtodos de anlisis de requerimientos. PASO 3. Despus de que se haya revisado la representacin de los requerimientos, se crea un conjunto de especificaciones de diseo abreviadas para el prototipo. El diseo debe ocurrir antes de que comience la construccin del prototipo. Sin embargo, el diseo de un prototipo se enfoca normalmente hacia la arquitectura a nivel superior y a los aspectos de diseo de datos, en vez de hacia el diseo procedimental detallado.

 PASO 4. El software del prototipo se crea, prueba y refina

Idealmente, los bloques de construccin de software preexisten se utilizan para crear el prototipo de una forma rpida. Desafortunadamente, tales bloques construidos raramente existen. Incluso si la implementacin de un prototipo que funcione es impracticable, es escenario de construccin de prototipos puede aun aplicarse. Para las aplicaciones interactivas con el hombre, es posible frecuentemente crear un prototipo en papel que describa la interaccin hombre-maquina usando una serie de hojas de historia.

PASO 5. Una vez que el prototipo ha sido probado, se presenta al

cliente, el cual "conduce la prueba" de la aplicacin y sugiere modificaciones. Este paso es el ncleo del mtodo de construccin de prototipo. Es aqu donde el cliente puede examinar una representacin implementada de los requerimientos del programa, sugerir modificaciones que harn al programa cumplir mejor las necesidades reales.

 PASO 6. Los pasos 4 y 5 se repiten iterativamente hasta que

todos los requerimientos estn formalizados o hasta que el prototipo haya evolucionado hacia un sistema de produccin. El paradigma de construccin del prototipo puede ser conducido con uno o dos objetivos en mente: 1) el propsito del prototipado es establecer un conjunto de requerimientos formales que pueden luego ser traducidos en la produccin de programas mediante el uso de mtodos y tcnicas de ingeniera de programacin, o 2) el propsito de la construccin del prototipo es suministrar un continuo que pueda conducir al desarrollo evolutivo de la produccin del software. Ambos mtodos tienen sus meritos y ambos crean problema.

Ventajas til cuando: El cliente no identifica los Este modelo es

requisitos detallados. El responsable del desarrollo no est seguro de la eficiencia de un algoritmo, sistema operativo o de la interface hombre-mquina. No modifica el flujo del ciclo de vida. Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. Reduce costos y aumenta la probabilidad de xito. Exige disponer de las herramientas adecuadas. No presenta calidad ni robustez. Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniera.

Desventajas
Su principal desventaja es que una vez que el cliente ha

dado su aprobacin final al prototipo y cree que est a punto de recibir el proyecto final, se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional, porque lo ms seguro es que el desarrollador haya hecho compromisos de implementacin para hacer que el prototipo funcione rpidamente. Es posible que el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, que est escrito en un lenguaje de programacin inadecuado.

INTEGRANTES:
*BERNARDO CHAPARRO
GARCIA

*JESUS ANIBAL MEZA GERALDO

GRACIAS!!!!

Es aquel por el que se debe pagar para utilizarlo; ms que el software, se est comprando la licencia para poder emplearlo y se deben comprar tantas licencias como equipos a utilizar dicho software.

son los productos de Microsoft, como el sistema operativo Windows y familia (9x, Me, XP), Sistema Manejador de Bases de Datos, programas para servicios de Internet y sus productos para el manejo de oficina (Suite Ofimtica), para el caso Office.

Comprar un software comercial de algn proveedor representa un conjunto de detalles, en la teora esta alternativa debera eliminar los riesgos de un software hecho en casa, en el sentido de que cuenta con lo ltimo en tecnologa y adems de estndares industriales a la hora de la elaboracin del producto. No se tienen los costos del mantenimiento del producto a largo plazo y los proveedores son los responsables de esta tarea.

Aunque en algunos casos el software es caro y difcil de personalizar, en otros casos son soluciones cerradas que no pueden ser modificadas, representan alternativas de muy rpida implementacin. El software comercial requiere licenciamiento y generalmente esta basado en procesos que representan la visin o estndares que se manejan en la industria, que no necesariamente reflejan la realidad del usuario final. Esta puede considerarse como una limitacin a la hora de la implementacin final.

Finalmente si el proveedor deja el negocio, descontina el producto o es comprado por otra compaa, es posible que no se cuente con algn tipo de soporte para el producto adquirido. En este caso tambin es necesario analizar y plantearse estas situacin a la hora de tomar una decisin.

No se puede modificar el programa (el cdigo fuente no est disponible) . Slo el fabricante puede realizar modificaciones; los clientes dan sugerencias de nuevas caractersticas que desean agregar a los programas y ellos (los fabricantes) deciden si las hacen (en caso de considerarlas convenientes) o no. Cuando salen nuevas versiones se debe pagar ms dinero si se desea actualizar la versin del programa adquirido.