domingo, 9 de septiembre de 2018

Ingenieria de Requisitos



Integrantes: Alexandra Villanueva Abanto

                    Marilin Pisco Coronel
                    Marisol Vilchez Balladares

                                                             Ingeniería de Requerimientos
I. Tema: Ingeniería de Requisitos
1. Contenido
 Definición:
Ingeniería de Requisitos: Es el proceso de desarrollar una especificación de Software. Las especificaciones pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. Trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible.
 Características
·       Permite gestionar las necesidades del proyecto en forma estructurada
·       Mejora la capacidad de predecir cronogramas de los proyectos, así como sus resultado
·        Disminuye los costos y retrasos del proyecto
·       Mejora la calidad del software
·        Mejora la comunicación entre equipos
·       Evita rechazos de los usuarios finales
 Fases
Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento preliminar de los requisitosde usuario. Aquí, los Analistas de Requerimientos deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc. Es importante,que la extracción sea efectiva, ya que la aceptación delsistema dependerá de cuan bien éste satisfaga las necesidades del cliente
B. Estudio de Viabilidad: En esta fase se estima si el problema del usuario se podrá resolver con la tecnología disponible y si el sistema será rentable según el presupuesto del que se dispone.
C. Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se interactúa con clientes o usuarios para determinar los requisitos funcionales y no funcionales del sistema, además del dominio de la aplicación. Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento. Estudiar sobre la base de extracción los requerimientos del cliente los problemas existentes, como solucionarlos, entre otrospuntos de interés.
Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa se leen los requerimientos, se conceptúan, se investigan, se intercambianideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos.
D. Especificación: En esta fase se documentan los requisitos con mayor detalle y precisión, de manera que sirva de base para un contrato entre el desarrollador y el cliente. En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado dedetalle. Aquí se definen con el cliente la documentación del requerimiento detallando muy bien cadaproceso, necesidad, mejora, en fin conocer en detalle el requerimiento.En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede decir que la especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML (Lenguaje de Modelado Unificado), que es un estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se utiliza cada vez más para la obtención de requerimientos.
E. Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los requisitos, es decir, verificar todos los requisitos que aparecen en el documento especificado para asegurarse de que son aceptados por el cliente. Esto implica verificar que los requisitos sean consistentes, que estén completos, que sean realistas y que puedan ser verificables. Se puede apreciar que el proceso de Ingeniería de Requerimientos es un conjunto estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar un mantenimiento adecuado al documento de especificación de requerimientos, que es el documento final, de carácter formal, que se obtiene de este proceso. Es necesario recalcar que no existe un proceso único que sea válido de aplicar en todas las organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personasinvolucradas en la ingeniería de requerimientos.
 Métodos
Metodo de Pressman
Para Pressman, en el proceso de análisis de requerimientos del software se puede identificar cinco tareas o etapas fundamentales:
·        Reconocimiento del problema: Se basa en el estudio inicial de las especificaciones del sistema y el plan del proyecto del software. El analista debe establecer un canal adecuado de comunicación con el equipo de trabajo involucrado en el proyecto. En esta etapa la función primordial del analista en todo momento es reconocer los elementos del problema tal y como los percibe el usuario.
·        Evaluación y síntesis: Se centra en el flujo y estructura de la información, definir las funciones del software, determinar los factores que afectan el desarrollo de nuestro sistema, establecer las características de la interfaz del sistema y descubrir las restricciones del diseño. Todas las tareas anteriores conducen fácilmente a la determinación del problema de forma sintetizada.
·        Modelización: Se basa en la creación de modelos del sistema que servirán para comprender mejor el proceso funcional, operativo y de contenido de la información. El modelo servirá de pilar para el diseño del software y como base para la creación de una especificación del software.
·        Especificación: Las tareas asociadas con la especificación intenta proporcionar una representación del software. Esto más adelante permitirá llegar a determinar si se ha llegado a comprender el software, en los casos que se lleguen a modelar se pueden dejar plasmados manuales.
·        Revisión: Es la etapa final del levantamiento de requisitos y se enfoca en demostrar que se ha llegado a un buen entendimiento de la forma de implementar con éxito el software. La documentación del análisis de requerimientos y manuales, permitirán una revisión por parte del cliente, la cual posiblemente traerá consigo modificaciones en las funciones del sistema por lo que deberán revisarse el plan de desarrollo y las estimaciones previstas inicialmente.
Metodo de Core
Existen metodologías alternas como el Método CORE (Controlled Requirements Expression) que plantean un escenario más tecnico al realizar una ingeniería de requerimientos sobre un software. Este método es un conjunto de notaciones textuales y gráficas, con guías especificadas para la captura y validación de requerimientos del sistema, en las etapas iniciales del diseño del sistema.Es pensado como puramente una técnica de captura y análisis de requerimientos, aunque soporta algunos aspectos de diseño tales como estructuras de datos. CORE está basada en el principio de primero definir el problema a ser analizado y luego dividirlo en unidades o puntos de vista a considerar.
Esta metodología se basa en 7 aspectos:
·        Definición del problema: El propósito de la definición del problema es identificar los límites del mismo. Contiene detalles de los objetivos de la empresa de los usuarios del sistema, la base para la necesidad de un nuevo sistema, limitaciones de costo y tiempo, y quién va a ser el responsable de la revisión y aceptación de los resultados finales.
·        Estructuración del punto de vista: El propósito de esta etapa es descomponer el ambiente del sistema en los elementos para que el sistema propuesto pueda ser analizado desde los puntos de vista de todas las entidades que se comunican con él, la más importante de las cuales son los usuarios. Durante esta etapa, todas las entidades que son fuentes potenciales de información deben ser identificadas.
·        Colección tabular: Esta etapa es cuando la información sobre los flujos de datos entre los puntos de vista y el procesamiento de éstos son reunidos. Esto ayuda a establecer la totalidad y consistencia.
·        Estructuración de datos: En la etapa previa, los elementos de información que pasan entre los puntos de vista son referidos por sus nombres generales. En esta etapa, se da una vista más cercana al contenido, a la estructura y a la derivación de datos, al producir diagramas de estructura de datos.
·        Modelación individual de puntos de vista: Esta etapa puede dividirse en dos partes. Lo único concerniente a la primera es convertir las TCF'S en una notación diferente para producir los diagramas individuales del modelo de punto de vista. La segunda parte se refiere a agregar alguna información nueva perteneciente a flujos de datos internos, control de acciones y tiempo de acciones.
·        Modelación combinada de punto de vista: Esta etapa facilita el análisis de una secuencia de eventos de más de un punto de vista. Cada diagrama de modelo combinado de punto de vista producido durante esta etapa es una representación del procesamiento de información que ocurre entre puntos de vista.
·        Análisis de restricciones. : En esta etapa, se consideran restricciones adicionales tales como desempeño y seguridad. Éstas pueden afectar los diagramas de puntos de vista ya producidos. Las restricciones se documentan en una especificación de restricción del sistema

2. Resumen
Mejora la calidad del software • Mejora la comunicación entre equipos Fases Aquí, los Analistas de Requerimientos deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc. Es importante, que la extracción sea efectiva, ya que la aceptación delsistema dependerá de cuan bien éste satisfaga las necesidades del cliente Estudiar sobre la base de extracción los requerimientos del cliente los problemas existentes, como solucionarlos, entre otrospuntos de interés. Métodos Metodo de Pressman
3. Conclusiones
La Ingeniería de Requisitos es una compleja disciplina que trata de formalizar las actividades relacionadas con obtener la especificación de requisitos formales del sistema a desarrollar a base de interactuar y negociar con el cliente. Especialmente en las metodologías 'pesadas' o tradicionales del desarrollo de software es crucial contar con un conjunto de requisitos muy estables sobre los que construir el resto del proyecto.
4. Recomendaciones
 Es importante tomarse el tiempo necesario para conocer a nuestros clientes y usuarios, así como su ambiente de trabajo. Esto, también ayuda a establecer una buena relación de trabajo y comunicación entre el equipo de desarrollo y los clientes. Es realmente necesario que los clientes y usuarios participen en la definición de sus requerimientos, pues ellos son los que deciden nuestro destino en el proyecto, deciden si les gustamos o no y además financian el proyecto.
En cuanto a la investigación realizada de la técnica de Casos de Uso para la Ingeniería de Requerimientos, puede decirse que los casos de uso son independientes del método de diseño que se utilice, y por lo tanto, del método de programación. Luego de documentar los requerimientos de un sistema con casos de uso, se puede diseñar un sistema "estructurado" (manteniendo una separación entre datos y funciones), o un sistema Orientado a Objetos, sin que la técnica sea de mayor o menor utilidad en alguno de los dos casos. Esto da más flexibilidad al método, y probablemente contribuya a su éxito.
Otro punto a considerar, es la inclusión del término "Administración de Requerimientos" en la década de los 90. Con esta nueva visión, se busca encontrar una descripción más apropiada de las actividades involucradas, a la vez de enfatizar la importancia de mantener una buena relación entre los afectados y el equipo del proyecto.
Entregar software de calidad, a tiempo y dentro del presupuesto, hará que nuestros clientes confíen y asegurará el crecimiento y madurez de la relación de negocio

5. Apreciación del Equipo
v  Tomando en cuenta la magnitud de comunicación y el trabajo en equipo que debe existir en la IR, considero necesario enfatizar más en cerrar las brechas que todavía existen, incluyendo los siguientes elementos:
·       Factores sociales: involucrar al grupo para compartir sus experiencias.
·       Factores de problemas específicos: el dominio de la estructura y estándares disponibles.
·       Factores organizacionales: tiempo y costo presupuestados.
·       Factores de diseño: por ejemplo, interfases de usuario
v  Debemos recordar que la Ingeniería de Requerimientos es una actividad que involucra a clientes, usuarios, equipo de desarrollo, administradores de proyectos, etc.; por lo tanto, el proceso de IR no depende solamente de la forma en cómo se percibe el problema, sino también, del nivel de experiencia que tengan los involucrados.




6. Glosario de Términos
v  Bosquejo: Diseño o proyecto de una obra artística, hecho de manera provisoria, solamente con los elementos esenciales
v  UML: El lenguaje unificado de modelado es el lenguaje de modelado de sistemas de software más conocido
v  Estándar: Que es lo más habitual o corriente, o que reúne las características comunes a la mayoría
v  Ratificar: Confirmar la validez o la verdad de una cosa que se ha dicho o se ha hecho anteriormente
v  Interfaz: Dispositivo capaz de transformar las señales generadas por un aparato en señales comprensibles por otro
v  Pilar: Elemento arquitectónico de soporte, rígido, más alto que ancho y normalmente de sección cuadrada o poligonal, que sirve para soportar la estructura horizontal de un edificio, un arco u otra construcción.
v  CORE: Core es una palabra en inglés que significa núcleo o centro, se utiliza para nombrar toda la zona muscular que envuelve el centro de gravedad de nuestro cuerpo, que lo encontramos justo debajo del ombligo, aunque dependerá de varios factores como del movimiento del cuerpo
v  TCF’s: El Test de Connaissance du Français (TCF) es un examen de competencia de francés para hablantes no nativos del idioma. Es administrado por el Centre international d'études pédagogiques (CIEP) como intermediario del Ministerio de Educación Nacional de Francia
7. Bibliografía o Linkografía




domingo, 2 de septiembre de 2018

Metodología de Desarrollo de Software

                        Ingenieria de Requerimientos






Metodologia de Desarrollo de Software

Integrantes: Alexandra Villanueva Abanto
                    Marilin Pisco Coronel
                    Marisol Vilchez Balladares

1.-Contenido
¿Que es metodologia?

 Como metodología se denomina la serie de métodos y técnicas de rigor científico que se aplican sistemáticamente durante un proceso de investigación para alcanzar un resultado teóricamente válido. En este sentido, la metodología funciona como el soporte conceptual que rige la manera en que aplicamos los procedimientos en una investigación.
La palabra, como tal, proviene del griego μέθοδος (méthodos), que significa ‘método’, y el sufijo -logía, que deriva de λóγος (lógos) y traduce ‘ciencia, estudio, tratado’. De allí que también sea definida como la ciencia del método.
Podemos encontrar metodología en distintas áreas de estudio, como la metodología didáctica en Educación, o la jurídica en Derecho, del mismo modo como para la solución de problemas determinados podemos aplicar una serie de pasos específicos que, en suma, funcionan como una metodología.
Metodologias de  Desarrollo de Software
Una metodología de software es un enfoque, una manera de interpretar la realidad o la disciplina en cuestión, que en este caso particular correspondería a la Ingeniería de Software. De hecho, la metodología destinada al desarrollo de software se considera como una estructura utilizada para planificar y controlar el procedimiento de creación de un sistema de información especializada.
Dicho esto, mostramos a continuación cuáles son algunas de las metodologías de desarrollo que te permitirán saber cuál sería la más adecuada para tu negocio.

1. Modelo de Cascada

Si alguna vez has incursionado en el mundo del Desarrollo de Software, de seguro te has topado en algún momento con el modelo de cascada. De no ser así, cabe destacar que en este modelo cada etapa representa una unidad de desarrollo con un pequeño descanso en el medio. Por lo tanto, cada siguiente etapa inicia tan pronto como la anterior haya culminado, y esos descansos son usados para confirmaciones del lado del cliente.
Adicionalmente, este es considerado como el método tradicional de explicar el proceso de desarrollo de software en ingeniería de software, por lo que actualmente es visto como anticuado. Sin embargo, aún sigue siendo aplicado a proyectos con metas claras y requisitos que demandan hasta 100 horas de desarrollo, sobre todo considerando que este enfoque permite a los negocios deshacerse del papeleo innecesario, reuniones regulares que consumen mucho tiempo y retrasos en sus procesos de negocio.
Es por esto que esta es una gran opción para pequeños proyectos donde todos los aspectos del proceso de desarrollo de software se conocen de antemano, pero una mala solución para proyectos complicados, ya que se trata de un modelo bastante inflexible. 

2. Modelo de Espiral

Mientras que la metodología de la cascada ofrece una estructura ordenada para el desarrollo de software, las demandas de tiempo reducido al mercado hacen que sus pasos en serie sean inapropiados.
El siguiente paso evolutivo desde la cascada es donde se realizan los diversos pasos para múltiples entregas o traspasos. La última evolución de la caída del agua es la espiral, aprovechando el hecho de que los proyectos de desarrollo funcionan mejor cuando son incrementales e iterativos.
La metodología espiral refleja la relación de tareas con prototipos rápidos, mayor paralelismo y concurrencia en las actividades de diseño y construcción. El método en espiral debe todavía ser planificado metódicamente, con las tareas y entregables identificados para cada paso en la espiral.

3. Metodología de Prototipo

Es un procedimiento de desarrollo especializado que permite a los desarrolladores la posibilidad de poder solo hacer la muestra de la resolución para poder  validar su esencia funcional ante los clientes, y hacer los cambios que sean fundamentales antes de crear la solución final auténtica. De hecho, la mejor parte de esta metodología es que tiende a resolver un conjunto de problemas de diversificación que ocurren con el método de la cascada.
Además de esto, la gran ventaja de optar por este enfoque es que da una idea clara sobre el proceso funcional del software, reduce el riesgo de falla en una funcionalidad de software y asiste bien en la recolección de requisitos y en el análisis general.

4. Desarrollo Rápido de Aplicaciones (RAD)

Con el objetivo de otorgar resultados rápidos, se trata de un enfoque que está destinado a proporcionar un excelente procesos de desarrollo con la ayuda de otros enfoques, pero además, está diseñado para aumentar la viabilidad de todo el procedimiento de desarrollo de software para resaltar la participación de un usuario activo.
Dicho esto, algunas de las ventajas a destacar de este tipo de desarrollo son las siguientes:
  • Hace todo el proceso de desarrollo sin esfuerzo.
  • Asiste al cliente en la realización de revisiones rápidas.
  • Alienta la retroalimentación de los clientes para su mejora.

5. Metodología de Programación Extrema (XP)

Como metodología ágil de ingeniería de software, la metodología de programación extrema se conoce actualmente como metodología de XP (eXtreme Programming). Esta metodología, se utiliza principalmente para evitar el desarrollo de funciones que actualmente no se necesitan, pero sobre todo para  para atender proyectos complicados. Sin embargo, sus métodos peculiares pueden tomar más tiempo, así como recursos humanos en comparación con otros enfoques

Ciclo de Vida del Desarrollo de Software

El ciclo de vida del desarrollo Software (SDLC en sus siglas inglesas), es una secuencia estructurada y bien definida de las etapas en Ingeniería de software para desarrollar el producto sofware deseado.

Actividades del SDLC

El SDLC aporta una serie de pasos a seguir con la finalidad de diseñar y desarrollar un producto software de manera eficiente. El borrador del SDLC incluye los pasos que veremos a continuación:
SDLC

Comunicación

Este es el primer paso donde l usuario inicia la petición de un producto software determinado. Contacta al proveedor de servicios e intenta negociar las condiciones. Presenta su solicitud al proveedor de servicios aportando la organización por escrito.

Recolección de solicitudes

A partir de este paso y en adelante el equipo de desarrollo software trabaja para tirar adelante el proyecto. El equipo se reúne con varios depositarios de dominio del problema, e intentan conseguir la máxima cantidad de información possible sobre lo que requieren. Los requisitos se contemplan y agrupan en requisitos del usuario, requisitos funcionales y requisitos del sistema. La recolección de todos los requisitos se lleva a cabo como se especifica a continación -
  • Estudiando el software y el sistema actual o obsoleto,
  • Entrevistando a usuarios y a desarrolladores de Software,
  • Consultando la base de datos o
  • Recogiendo respuestas a través de cuestionarios.

Estudio de viabilidad

Después de la recolección de requisitos, el equipo idea un plan para procesar el software. En esta fase, el equipo analiza si el software puede hacerse para cubrir todos los requisitos del usuario y si hay alguna posibilidad de que el software ya no sea necesario. Se investiga si el proyecto es viable a nivel financiero, práctico, y a nivel tecnológico para que la organización acepte la oferta. Hay varios algoritmos disponibles, los cuales ayudan a los desarrolladores a concluir si el proyecto software es factible o no.

Análisis del sistema

En este pas los desarrolladores trazan su plan e intentan crear el mejor y más conveniente modelo de software para el proyecto. El análisis del sistema inclye el entendimiento de las limitaciones del producto Software; el aprendizaje de los problemas relacionados con el sistema; los cambios que se requieren en sistemas ya existentes con antelación, identificando y dirigiendo el impacto del proyecto a la organización y al personal, etc. El equipo del proyecto analiza las posibilidades del proyecto y planifica la temporalización y los recursos correspondientes.

Diseño de Software

El siguiente paso es diseñar el producto software con la ayuda de toda la información recogida sobre requisitos y análisis. Los inputs (aportacines) de los usuarios y los resultados de la recogida de información hecha en la fase anterior seran las aportaciones base de la fase actual. El output (o resultado) de esta etapa toma la forma de 2 diseños; El diseño lógico y el diseño físico. Los ingenieros crean meta-data (Metadatos), Diagramas dilógicos, diagramas de flujo de datos, y en algunos casos pseudocódigos.

Codificación

Esta fase también se puede denominar 'fase de programación'. La implementación del diseño de software empieza con el lenguaje de programación más conveniente, y desarrollando programas ejecutables y sin errores de manera eficiente.

Pruebas

Se estima que el 50% de todos los procesos de desarrollo de software deberían ser evaluados. Los errores pueden arruinar el software tanto a nivel crítico y hasta el punto de ser eliminado. Las pruebas de Software se hacen mientras se codifica y suelen hacerlo los desarrolladores y otros expertos evaluadores a varios niveles. Esto incluye evaluación de módulos, evaluación del programa, evaluación del producto, evaluación interna y finalmente evaluación con el consumidor final. Encontrar errores y su remedio a tiempo es la llave para conseguir un software fiable.

Integración

El Software puede necesitar estar integrado con las bibliotecas, Bases de datos o con otro u otros programas. Esta fase del SDLC se focaliza en la integración del software con las entidades del mundo exterior.

Implementación

Aquí se instala el software en máquinas de clientes. A veces, el software necesita instalar configuraciones para el consumidor final con posterioridad. El Software se evalúa por su adaptabilidad y su portabilidad, en cuanto a las cuestiones relacionadas con la integración y conceptos asociados, se resuelven durante la implementación.

Mantenimiento y Funcionamiento

Esta fase confirma el funcionamiento del software en términos de más eficiencia y menos errores. Si se requiere, los usuarios se forman, o se les presta documentación sobre como operar y como mantenerlo en funcionamiento. El software se mantiene de forma temprana actualizando el código en acorde a los cambios que tienen lugar en entornos del usuario o tecnológicos. Esta fase puede que tenga que encarar retos originados por virus ocultos o problemas no identificados del mundo real.

Disposición

Con el paso del tiempo, puede que el software falle en su ejecución. Puede que se vuelva totalmente obsoleto o que necesite actualizaciones. De ahí surge una necesidad urgente de eliminar una parte importante del sistema. Esta fase incluye archivar datos y componentes software requeridos, cierre del sistema, planificación de la actividad de disposición y terminación de sistema en el momento final del sistema.

Paradigma de desarrollo de Software

El Paradigma de desarrollo de Software ayuda al desarrollador a escoger una estrategia para desarrollar el software. El paradigma de desarrollo software tiene su propio set de herramientas, métodos y procedimientos, los cuales son expresados de forma clara, y define el ciclo de vida del desarrollo del software. Algunos paradigmas de desarrollo de software o modelos de proceso se definen a continuación:

Modelo de cascada

El modelo de cascada es el modelo de paradigma más simple en desarrollo de software. Sigue un modelo en que las fases del SDLC funcionarán una detrás de la otra de forma lineal. Lo que significa que solamente cuando la primera fase se termina se puede empezar con la segunda, y así progresivamente.
Este modelo asume que todo se lleva a cabo y tiene lugar tal y como se había planeado en la fase anterior, y no es necesario pensar en asuntos pasados que podrían surgir en la siguiente fase. Este modelo no funcionará correctamente si se dejan asuntos de lado en la fase previa. La naturaleza secuencial del modelo no permite volver atrás y deshacer o volver a hacer acciones.
Este modelo es recomendable cuando el desarrollador ya ha diseñado y desarrollado softwares similares con anterioridad, y por eso está al tanto de todos sus dominios.

Modelo repetitivo

Este modelo guía el proceso de desarrollo de software en repeticiones. Proyecta el proceso de desarrollo de forma cíclica repitiendo cada paso después de cada ciclo en el proceso de SDLC.
Modelo iterativo
El software primero se desarrolla en menor escala y se siguen y tienen en consideración todos los pasos. Entonces, por cada repetición, más módulos y características son diseñados, codificados, evaluados y añadidos al software. Cada ciclo produce un sotware completo, con más características y capacidad que los previos.
Después de cada repetición, el equipo directivo puede concentrarse en la gestión de riesgos y prepararse para la siguiente repetición. Como el ciclo incluye pequeñas porciones de la totalidad del proceso software, es más fácil gestionar el proceso de desarrollo, pero a la vez se consumen más recursos.

Modelo en espiral

El modelo en espiral es una combinación de ambos modelos, el repetitivo y uno del modelo SDLC. Se puede ver como si se combina un modelo de SDLC combinado con un proceso cíclico (modelo repetitivo).
Modelo espiral
Este modelo considera el riesgo, factor que otros modelos olvidan o no prestan atención en el proceso. El modelo empieza determinando los objetivos y las limitaciones del software al inicio de cada repetición. En la siguiente etapa se crean los modelos de prototipo del software. Esto incluye el análisis de riesgos. Luego un modelo estándar de SDLC se usa para construir el software. En la cuarta etapa es donde se prepara el plan de la siguiente repetición.

Modelo V

El mayor inconveniente del modelo de cascada es que solo se pasa a la siguiente fase cuando se completa la anterior, por tanto no es posible volver atrás si se encuentra algún error en las etapas posteriores. El Modelo V aporta opciones de evaluación del software en cada etapa de manera inversa.
V-Modelo
En cada etapa, se crea la planificaión de las pruebas y los casos de pruebas para verificar y validar el producto según los requisitos de la etapa. Por ejemplo, en la etapa de recogida de requisitos, el equipo de evaluadores prepara las pruebas de caso correspondientes a los requisitos. Más tarde, cuando el producto se desarrolla y está preparado para ser evaluado, las pruebas de caso en esta etapa verifican el software y su validez sugún sus requisitos.
Esto hace que tanto la verificación como la validación vayan en paralelo. Este modelo también se conoce como modelo de validación y verificación.

Modelo Big Bang

Este modelo es el modelo con la forma más simple. Requiere poca planificación, mucha programación y también muchos fondos. Este modelo se conceptualiza alrededor de la teoría de creación del universo 'Big Bang'. Tal como cuentan los científicos, después del big bang muchas galaxias, planetas y estrellas evolucionaron. De la misma manera, si reunimos muchos fondos y programación, quizá podemos conseguir el mejor producto de software.
Big Bang Modelo
Para este modelo, se requiere poca planificación. No sigue ningún proceso concreto, y a veces el cliente no está seguro de las futuras necesidades y requisitos. Por tanto la entrada o input respecto a los requisitos es arbitraria.
Este modelo no es recomendable para grandes proyectos de software, pero es bueno para aprender y experimentar.

2.-Resumen
¿ Que es metodologia ? La palabra, como tal, proviene del griego μέθοδος ( méthodos ), que significa ‘método’, y el sufijo - logía, que deriva de λóγος ( lógos ) y traduce ‘ciencia, estudio, tratado’. Metodologias de Desarrollo de Software De hecho, la metodología destinada al desarrollo de software se considera como una estructura utilizada para planificar y controlar el procedimiento de creación de un sistema de información especializada. Adicionalmente, este es considerado como el método tradicional de explicar el proceso de desarrollo de software en ingeniería de software, por lo que actualmente es visto como anticuado. Desarrollo Rápido de Aplicaciones ( RAD ) Metodología de Programación Extrema ( XP ) Como metodología ágil de ingeniería de software
3- Conclusiones 
Utilización de la ingeniería de software como mecanismo de aplicación y evaluación de la eficiencia y calidad operacional de un sistema de función crítica, visto como la definición de criterios de operación bajo condiciones y límites establecidos por el sistema y por las características externas del medio externo. En el desarrollo de productos de software las etapas de análisis de requerimientos y diseño toma gran parte del tiempo del proyecto. El modelo planteado en este proyecto pretende establecer unos parámetros de diseño generales que permitan agilizar la implementación de proyectos tipo sistemas de control por software, cuya base común es el procesamiento de señales digitales en busca de comportamientos de interés (caracterización de señales).
4. Recomendaciones

  1. Uso de protocolos y estándares abiertos para comunicaciones y programación, facilitando el paso de mensajes y datos entre módulos y métodos internos y externos. 
  2. Diversos lenguajes de programación, realizando implementación de algunos módulos en lenguajes que ofrezcan mejores condiciones que otros en ambientes particulares de uso.


5. Apreciación del Equipo
Segun la apreciacion de nuestro grupo es que nos da la factibilidad de aplicación del modelo y desarrollo técnico a otras tipos de problema que requieran procesamiento de señales, específicamente detección de cambios o eventualidades sobre señales digitales
6. Glosario de Términos
*inputs:Todo lo que el mundo exteriorproporciona a un sistema, en particular a un ordenador, que puede consistir en señales,datos o programas
*output: Salida, resultados de un proceso y el periférico por donde aparecen. Salida.
*SDLC: Software development life cycle, the software development process Systems development life cycle or system design life cycleSynchronous Data Link Control, an IBM communications protocol
*conceptualiza:Organizar de modo sistemático un conjunto de elementos, poniendo de manifiestosus características y relaciones esenciales. sistematizar
*eventualidades:Hecho cuya realización no es segura reserva algo de dinero por si surge cualquiereventualidad. contingencia
7. Bibliografía o Linkografía