CARRERA DE INFORMATICA EDUCATIVA                                    Módulo IV    EJECUCIÓN Y EVALUACIÓN DE LOS PROCESOS DE...
En Ingeniería de software el desarrollo en cascada que no tieneprototipo que no era en cascada , también llamado modelo en...
especificación de lo que debe hacer cada una de sus partes, así como lamanera en que se combinan unas con otras.Es conveni...
Los elementos, ya programados, se ensamblan para componer el sistema yse comprueba que funciona correctamente y que cumple...
  Alternativas: las diferentes formas de conseguir los objetivos de formaexitosa, desde diferentes puntos de vista como p...
DETERMINAR O FIJAR OBJETIVOS  Fijar también los productos definidos a obtener: requerimientos,especificación, manual de u...
DESVENTAJAS     Genera mucho tiempo en el desarrollo del sistema     Modelo costoso     Requiere experiencia en la iden...
modelado de construcción de prototipos y/o análisis, especificación derequisitos y diseño.                  MODELO DE PROT...
será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en partic...
Upcoming SlideShare
Loading in …5
×

Carrera de informatica_educativa

384 views
325 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
384
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Carrera de informatica_educativa

  1. 1. CARRERA DE INFORMATICA EDUCATIVA Módulo IV EJECUCIÓN Y EVALUACIÓN DE LOS PROCESOS DE ENSEÑANZA APRENDIZAJE EN INFORMÁTICA EDUCATIVATarea Buscar ejemplos de modelos de la ingeniería del software Docente: Mg. Sc. Lena Ruiz R. Integrante del Grupo: Juan Diego Sinche Marzo– Julio Loja-Ecuador 2011-2012 DESARROLLO DE CASADA
  2. 2. En Ingeniería de software el desarrollo en cascada que no tieneprototipo que no era en cascada , también llamado modelo en cascada,es el enfoque metodológico que ordena rigurosamente las etapasdel proceso para el desarrollo de software, de tal forma que el inicio decada etapa debe esperar a la finalización de la etapa anterior.1Un ejemplo de una metodología de desarrollo en cascada es:1. Análisis de requisitos.2. Diseño del Sistema.3. Diseño del Programa.4. Codificación.5. Pruebas.6. Implantación.7. Mantenimiento.De esta forma, cualquier error de diseño detectado en la etapa de pruebaconduce necesariamente al rediseño y nueva programación del códigoafectado, aumentando los costes del desarrollo. Lapalabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad,el esfuerzo necesario para introducir un cambio en las fases másavanzadas de un proyecto.Si bien ha sido ampliamente criticado desde el ámbito académico y laindustria[cita requerida], sigue siendo el paradigma más seguido al día de hoy. FASES DEL MODELO ANÁLISIS DE REQUISITOSEn esta fase se analizan las necesidades de los usuarios finales delsoftware para determinar qué objetivos debe cubrir. De esta fase surge unamemoria llamada SRD (documento de especificación de requisitos), quecontiene la especificación completa de lo que debe hacer el sistema sinentrar en detalles internos.Es importante señalar que en esta etapa se debe consensuar todo lo quese requiere del sistema y será aquello lo que seguirá en las siguientesetapas, no pudiéndose requerir nuevos resultados a mitad del proceso deelaboración del software. DISEÑO DEL SISTEMADescompone y organiza el sistema en elementos que puedan elaborarsepor separado, aprovechando las ventajas del desarrollo en equipo. Comoresultado surge el SDD (Documento de Diseño del Software), que contienela descripción de la estructura relacional global del sistema y la
  3. 3. especificación de lo que debe hacer cada una de sus partes, así como lamanera en que se combinan unas con otras.Es conveniente distinguir entre diseño de alto nivel o arquitectónico ydiseño detallado. El primero de ellos tiene como objetivo definir laestructura de la solución (una vez que la fase de análisis ha descrito elproblema) identificando grandes módulos (conjuntos de funciones que vana estar asociadas) y sus relaciones. Con ello se define la arquitectura de lasolución elegida. El segundo define los algoritmos empleados y laorganización del código para comenzar la implementación. DISEÑO DEL PROGRAMAEs la fase en donde se realizan los algoritmos necesarios para elcumplimiento de los requerimientos del usuario así como también losanálisis necesarios para saber que herramientas usar en la etapa deCodificación. CODIFICACIÓNEs la fase en donde se implementa el código fuente, haciendo uso deprototipos así como de pruebas y ensayos para corregir errores.Dependiendo del lenguaje de programación y su versión se crean lasbibliotecas y componentes reutilizables dentro del mismo proyecto parahacer que la programación sea un proceso mucho más rápido. PRUEBAS
  4. 4. Los elementos, ya programados, se ensamblan para componer el sistema yse comprueba que funciona correctamente y que cumple con los requisitos,antes de ser entregado al usuario final. VERIFICACIÓNEs la fase en donde el usuario final ejecuta el sistema, para ello el o losprogramadores ya realizaron exhaustivas pruebas para comprobar que elsistema no falle. MANTENIMIENTOUna de las etapas mas criticas, ya que se destina un 75% de los recursos,es el mantenimiento del Software ya que al utilizarlo como usuario finalpuede ser que no cumpla con todas nuestras expectativas. VARIANTESExisten variantes de este modelo; especialmente destacamos la que haceuso de prototipos y en la que se establece un ciclo antes de llegar a la fasede mantenimiento, verificando que el sistema final este libre de fallos. DESVENTAJASEn la vida real, un proyecto rara vez sigue una secuencia lineal, esto creauna mala implementación del modelo, lo cual hace que lo lleve al fracaso.El proceso de creación del software tarda mucho tiempo ya que debe pasarpor el proceso de prueba y hasta que el software no esté completo no seopera. Esto es la base para que funcione bien.Cualquier error de diseño detectado en la etapa de prueba conducenecesariamente al rediseño y nueva programación del código afectado,aumentando los costos del desarrollo. DESARROLLO EN ESPIRALEl desarrollo en espiral es un modelo de ciclo de vida del 1software definido por primera vez por Barry Boehm en 1986, utilizadogeneralmente en la Ingeniería de software. Las actividades de este modelose conforman en una espiral, en la que cada bucle o iteración representaun conjunto de actividades. Las actividades no están fijadas a ningunaprioridad, sino que las siguientes se eligen en función del análisis de riesgo,comenzando por el bucle interior. CICLOS O ITERACIONESEn cada vuelta o iteración hay que tener en cuenta: Los Objetivos: qué necesidad debe cubrir el producto.
  5. 5.  Alternativas: las diferentes formas de conseguir los objetivos de formaexitosa, desde diferentes puntos de vista como pueden ser:1. Características: experiencia del personal, requisitos a cumplir, etc.2. Formas de gestión del sistema.3. Riesgo asumido con cada alternativa. Desarrollar y Verificar: Programar y probar el software.Si el resultado no es el adecuado o se necesita implementar mejoras ofuncionalidades: Se planificaran los siguientes pasos y se comienza un nuevo ciclo de laespiral. La espiral tiene una forma de caracola y se dice que mantiene dosdimensiones, la radial y la angular:1. Angular: Indica el avance del proyecto del software dentro de un ciclo.2. Radial: Indica el aumento del coste del proyecto, ya que con cada nuevaiteración se pasa más tiempo desarrollando.Este sistema es muy utilizado en proyectos grandes y complejos comopuede ser, por ejemplo, la creación de un Sistema Operativo.Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se diceque uno de los aspectos fundamentales de su éxito radica en que el equipoque lo aplique tenga la necesaria experiencia y habilidad para detectar ycatalogar correctamente los riesgos.TareasPara cada ciclo habrá cuatro actividades:1. Determinar Objetivos.2. Análisis del riesgo.3. Planificación.4. Desarrollar y probar.
  6. 6. DETERMINAR O FIJAR OBJETIVOS Fijar también los productos definidos a obtener: requerimientos,especificación, manual de usuario. Fijar las restricciones. Identificación de riesgos del proyecto y estrategias alternativas paraevitarlos. Hay una cosa que solo se hace una vez: planificación inicial o previa. ANÁLISIS DEL RIESGO Se lleva a cabo el estudio de las causas de las posibles amenazas yprobables eventos no deseados y los daños y consecuencias que éstaspuedan producir.Planificar Revisamos todo lo hecho, evaluándolo, y con ello decidimos sicontinuamos con las fases siguientes y planificamos la próxima actividad. DESARROLLAR, VERIFICAR Y VALIDAR(PROBAR) Tareas de la actividad propia y de prueba. Análisis de alternativas e identificación resolución de riesgos. Dependiendo del resultado de la evaluación de los riesgos, se elige unmodelo para el desarrollo, el que puede ser cualquiera de los otrosexistentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si losriesgos en la interfaz de usuario son dominantes, un modelo de desarrolloapropiado podría ser la construcción de prototipos evolutivos. Si lo riesgosde protección son la principal consideración, un desarrollo basado entransformaciones formales podría ser el más apropiado. Mecanismos de control La dimensión radial mide el coste. La dimensión angular mide el grado de avance del proyecto. Variaciones del Modelo En Espiral Modelo en Espiral Típico de seis regiones. Modelo en espiral WIN WIN.  VENTAJASEl análisis del riesgo se hace de forma explícita y clara. Une los mejoreselementos de los restantes modelos. Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento, etc.Además es posible tener en cuenta mejoras y nuevos requerimientos sinromper con la metodología, ya que este ciclo de vida no es rígido niestático.
  7. 7. DESVENTAJAS  Genera mucho tiempo en el desarrollo del sistema  Modelo costoso  Requiere experiencia en la identificación de riesgos. EL MODELO DESARROLLO CONCURRENTE. Davis y Sitaranm han descrito el modelo de desarrollo concurrente, llamado algunas veces ingeniería concurrente. Los gestores de proyectos que siguen los pasos del estado del proyecto en lo que se refiere a las fases importantes [del ciclo de vida clásico]no tiene idea del estado de sus proyectos. Estos son ejemplos de un intento por seguir los pasos extremadamente complejos de actividades mediante modelos demasiado simples. Tenga en cuenta que aunque un proyecto [grande] esté en la fase de codificación, hay personal de ese proyecto implicado en actividades asociadas generalmente a muchas fases de desarrollo simultáneamente. El modelo de proceso concurrente se puede sentar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas. Por ejemplo, la actividad de ingeniería definida para el modelo en espiral, se lleva acabo invocando las tareas siguientes:
  8. 8. modelado de construcción de prototipos y/o análisis, especificación derequisitos y diseño. MODELO DE PROTOTIPOSEl Modelo de prototipos, en Ingeniería de software, pertenece a losmodelos de desarrollo evolutivo. El prototipo debe ser construido en pocotiempo, usando los programas adecuados y no se debe utilizar muchodinero pues a partir de que éste sea aprobado nosotros podemos iniciar elverdadero desarrollo del software.El diseño rápido se centra en una representación de aquellos aspectos delsoftware que serán visibles para el cliente o el usuario final. Este diseñoconduce a la construcción de un prototipo, el cual es evaluado por el clientepara una retroalimentación; gracias a ésta se refinan los requisitos delsoftware que se desarrollará. La interacción ocurre cuando el prototipo seajusta para satisfacer las necesidades del cliente. Esto permite que almismo tiempo el desarrollador entienda mejor lo que se debe hacer y elcliente vea resultados a corto plazo. ETAPAS  Plan rápido  Modelado, diseño rápido  Construcción del Prototipo  Desarrollo, entrega y retroalimentación  Comunicación VENTAJAS  Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.  También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina. Las maquinas simples pueden ser palanca, plano inclinado entre otros La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál
  9. 9. será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto. Inconvenientes  El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.  En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.Bibliografíahttp://es.wikipedia.org/wiki/Desarrollo_en_cascadahttp://es.wikipedia.org/wiki/Desarrollo_en_espiral http://www.itpuebla.edu.mx/Alumnos/Cursos_Tutoriales/Ana_Sosa_Pintle/SISTEM AS/ARCHIVOS_FUNDAMENTOS/ARCHIVOS/U5_5.htm http://es.wikipedia.org/wiki/Modelo_de_prototipos

×