Revisiones Estáticas - IEEE-1028: revisiones de software & Modelos de desarrollo

Revisiones Estáticas

Beneficios de las Revisiones

La razón para buscar defectos en productos tempranos es porque éstos se traducen en defectos en el producto final. Es decir, defectos en los requisitos se traducirán en defectos en el sistema final. Veamos una analogía con la arquitectura de edificios. Si en un plano el color de una línea indica su significado, una confusión en el color se traducirá en un error en el edificio. Por ejemplo, si el azul indica tuberías de agua y el amarillo cables eléctricos y el arquitecto comete un error usando el azul en una conducción eléctrica, los electricistas que usen el plano como guía para su trabajo no colocarán cables eléctricos mientras que los fontaneros colocarán tuberías de agua donde no debían ir. El plano de un edificio es el artefacto equivalente al diseño de un producto software. Si un diseño contiene defectos, seguramente estos defectos se trasmitirán al código cuando los programadores usen ese diseño como guía para su trabajo.

La detección temprana de errores acarrea grandes beneficios. Si las revisiones únicamente se aplican al código mejoran la calidad y producen ahorros en los costos del proyecto. Pero los ahorros son mayores si se inspeccionan artefactos tempranos del desarrollo. Estudiando los resultados publicados sobre ahorros con las revisiones, puede afirmarse que la utilización de inspecciones de código produce un ahorro del 39% sobre el coste de detectar y corregir defectos, frente a únicamente utilizar la evaluación dinámica. Sin embargo, el ahorro es del 44% si se inspecciona también el diseño. La experiencia demuestra que entre el 30% y el 70% de los defectos, de diseño y código son detectados por las técnicas estáticas. Esto supone un gran ahorro, pues la corrección es más fácil y menos costosa durante la evaluación estática que durante la dinámica. Nótese que cuando durante la evaluación dinámica del sistema se detecta un fallo en un programa, lo que se detecta es el fallo, no la falta que lo provoca. Es decir, tras la detección del fallo, se requiere una labor de localización en el programa de la falta que provocó el fallo. Sin embargo, con las técnicas estáticas, lo que se detecta son directamente faltas. Por tanto, una vez detectada, se puede pasar a la fase de corrección. Es decir, desaparece la tarea de localización de la falta.

Esto significa, que las técnicas estáticas son más baratas por falta que las dinámicas. Las revisiones también proporcionan beneficios más generales. Entre éstos se pueden citar están:

• Evaluación del progreso del proyecto.
• Potencia las capacidades de los participantes.
• Mejoran la comunicación entre el equipo de desarrollo, aumentando su motivación, pues los productos pasan a ser documentos públicos.
• Proporciona aprendizaje, retroalimentación y prevención.
• Forma y educa a los participantes

En el caso concreto de las revisiones de código, éstas, además, permiten localizar secciones críticas, lo que permitirá dedicar un mayor esfuerzo a ellas en la fase de pruebas.

Objetivos de la Evaluación Estática

La evaluación estática de los distintos artefactos o productos que se generan en el desarrollo de software (especificación de requisitos, modelos conceptuales, diseño, código, etc.) pretende comprobar su calidad. distintos. Del mismo modo que la calidad de un plano y la calidad de una casa significa cosas distintas. En un plano de un futuro edificio se desea que sea claro (se entienda suficientemente bien como para servir de guía a la construcción del edificio), que sea correcto (por ejemplo, que las líneas que identifican paredes indiquen, a escala, efectivamente el lugar donde se desea que vayan las paredes), que no tenga inconsistencias (por ejemplo, entre las distintas hojas que forman el plano; si una página se focaliza, digamos, en una habitación que en otra página aparecía sólo sus cuatro paredes, que las medidas de las líneas en ambas páginas se correspondan con la misma medida de la realidad), etc.. Sin embargo, de una casa se espera que sea robusta (por ejemplo, que no se caiga), usable (por ejemplo, que los peldaños de las escaleras no sean tan estrechos que provoquen caídas) etc. Por tanto, cuando se esté evaluando estáticamente un producto software, es importante que el evaluador tenga en mente qué tipo de defectos está buscando y cuál sería un producto de ese tipo de calidad adecuada. Digamos que si uno no sabe lo que busca (por ejemplo, inconsistencias al revisar la calidad de un plano) es difícil que lo encuentre, aunque lo tenga delante.

Los defectos que se buscan al evaluar estáticamente los productos software son:

1. Para los requisitos: 

• Corrección: Los requisitos especifican correctamente lo que el sistema debe hacer. Es decir, un requisito incorrecto es un requisito que no cumple bien su función. Puesto que la función de un requisito es indicar qué debe hacer el sistema, un requisito incorrecto será aquel que, o bien pide que el sistema haga algo que no es lo que debe hacer, o pide que haga algo que no deba hacer.
• Compleción: Especificación completamente el problema. Está especificado todo lo que tiene que hacer el sistema y no incluye nada que el sistema no deba hacer. En dos palabras: no falta nada; no sobra nada Consistencia. No hay requisitos contradictorios.
• Ambigüedad: Los requisitos no pueden estar sujetos a interpretación. Si fuese así, un mismo requisito puede ser interpretado de modo distinto por dos personas diferentes y, por tanto, crear dos sistemas distintos. Si esto es así, los requisitos pierden su valor pues dejan de cumplir su función (indicar qué debe hacer el sistema). Las ambigüedades provocan interpretación por parte de la persona que use o lea los requisitos. Por tanto, una especificación debe carecer de ambigüedades.
• Claridad: Se entiende claramente lo que está especificado.

2. Para el diseño:

• Corrección: El diseño no debe contener errores. Los errores de corrección se pueden referir a dos aspectos. Defectos de “escritura”, es decir, defectos en el uso de la notación de diseño empleada (el diseño contiene detalles prohibidos por la notación). Defectos con respecto a los requisitos: el diseño no realiza lo que el requisito establece. Hablando apropiadamente, los primeros son los puros defectos de corrección, mientras que los segundos son defectos de validez.
• Compleción: El diseño debe estar completo. Ya sea que diseña todo el sistema marcado por los requisitos; ya sea no diseñando ninguna parte no indicada en los requisitos. De nuevo, nada falta, nada sobra.
• Consistencia: Al igual que en los requisitos, el diseño debe ser consistente entre todas sus partes. No puede indicarse algo en una parte del diseño, y lo contrario en otra.
• Factibilidad: El diseño debe ser realizable. Debe poderse implementar.
• Trazabilidad: Se debe poder navegar desde un requisito hasta el fragmento de diseño donde éste se encuentra representado.

3. Para el Código Fuente:

• Corrección: El código no debe contener errores. Los errores de corrección se pueden referir a dos aspectos. Defectos de “escritura”, es decir, lo que habitualmente se conoce por “programa que no funciona”. Por ejemplo, bucles infinitos, variable definida de un tipo, pero utilizada de otro, contador que se sale de las dimensiones de un array, etc. Defectos con respecto al diseño: el diseño no realiza lo que el diseño establece. 

IEEE-1028: revisiones de software

El propósito de esta norma es definir revisiones sistemáticas y auditorías aplicables a la adquisición, suministro, desarrollo, operación y mantenimiento de software. Esta norma describe cómo realizar una revisión. Otras normas o la administración local definen el contexto dentro del cual se realiza una revisión y el uso que se hace de los resultados de la revisión. Las revisiones de software se pueden utilizar en apoyo de los objetivos de gestión de proyectos, ingeniería de sistemas (por ejemplo, asignación funcional entre hardware y software), verificación y validación, gestión de configuración, garantía de calidad y auditoría. Los diferentes tipos de revisiones reflejan diferencias en las metas de cada tipo de revisión. Las revisiones sistemáticas se describen por sus procedimientos definidos, alcance y objetivos.

Términos y definiciones

1. Revisión de la gestión: Una evaluación sistemática de un producto o proceso de software realizado por o en nombre de la administración que monitorea el progreso, determina el estado de los planes y horarios, confirma los requisitos y su sistema de asignación o evalúa la efectividad de los enfoques de manejo utilizados para alcanzar la aptitud para su respectivo propósito, el cual es; una revisión de una gestión es monitorear el progreso, determinar el estado de los planes y los horarios, o evaluar la efectividad de los enfoques de manejo usados para lograr la adecuación al propósito. Las revisiones de la gerencia apoyan decisiones sobre acciones correctivas, cambios en la asignación de recursos, o cambios en el alcance del proyecto. Las revisiones de gestión identifican la coherencia y las desviaciones de los planes, o las adecuaciones e insuficiencias de los procedimientos de gestión. El conocimiento técnico puede ser necesario para llevar a cabo un exitoso examen de la gestión. El examen puede requerir más de una reunión. El examen no necesita abordar todos los aspectos del producto o proceso de software.

2. Revisión técnica: Una evaluación sistemática de un producto de software por un equipo de personal calificado que examina la idoneidad del producto de software para su uso previsto e identifica discrepancias de especificaciones y estándares. El propósito de una revisión técnica es evaluar un producto de software por un equipo de personal calificado para determinar su idoneidad para el uso previsto e identificar discrepancias con las especificaciones y estándares. Proporciona a la dirección pruebas para confirmar el estado técnico del proyecto. Las revisiones técnicas también pueden proporcionar la recomendación y el examen de varias alternativas, que pueden requerir más de una reunión. El examen no necesita abordar todos los aspectos del producto.

3. Inspección: Un examen visual de un producto de software para detectar e identificar anomalías de software, incluidos errores y desviaciones de las normas y especificaciones. El propósito de una inspección es detectar e identificar anomalías de productos de software. Una inspección es un examen sistemático de pares que realiza uno o más de los siguientes:

• Verifica que el producto de software cumple con sus especificaciones.
• Verifica que el producto de software presenta atributos de calidad especificados.
• Verifica que el producto de software cumple con las regulaciones, normas, directrices, planes, especificaciones y procedimientos aplicables.
• Identifica las desviaciones de las disposiciones del punto 1, 2, y 3.
• Recopila datos de ingeniería de software (por ejemplo, datos de anomalías y esfuerzo).
• Proporciona los datos de ingeniería de software recopilados que se pueden utilizar para mejorar el propio proceso de inspección y su documentación de soporte (por ejemplo, listas de verificación).
• Solicita u otorga exenciones por violación de estándares donde la adjudicación del tipo y el alcance de las violaciones se asignan a la jurisdicción de inspección.
• Utiliza los datos como entrada para las decisiones de gestión de proyectos según sea apropiado (por ejemplo, para hacer concesiones entre inspecciones adicionales versus pruebas adicionales).

Las inspecciones constan de dos a seis participantes (incluido el autor). Una inspección es dirigida por un facilitador imparcial capacitado y capacitado en técnicas de inspección. La determinación de la acción correctiva o de investigación para una anomalía es un elemento obligatorio de una inspección de software, aunque la resolución no debe ocurrir en la reunión de inspección. La recopilación de datos con el fin de analizar y mejorar los procedimientos de ingeniería de software es un elemento obligatorio de las inspecciones de software.

4. Paso a paso: una técnica de análisis estático en la que un diseñador o programador dirige a los miembros del equipo de desarrollo y otras partes interesadas a través de un producto de software y los participantes hacen preguntas y hacen comentarios sobre posibles anomalías. Con el propósito de educar a una audiencia con respecto a un producto de software. Los principales objetivos son los siguientes:

• Encontrar anomalías.
• Mejorar el producto de software.
• Considerar implementaciones alternativas.
• Evaluar la conformidad con las normas y especificaciones.
• Evaluar la usabilidad y accesibilidad del producto de software.

Otros objetivos importantes del walk-through incluyen intercambio de técnicas, variaciones de estilo y entrenamiento de los participantes. Un walk-through puede señalar deficiencias (por ejemplo, problemas de eficiencia y legibilidad en el producto de software, problemas de modularidad en diseño o código o especificaciones no comprobables).

5. Auditoría: Un examen independiente de un producto de software, un proceso de software o un conjunto de procesos de software realizados por un tercero para evaluar el cumplimiento de especificaciones, estándares, acuerdos contractuales u otros criterios. El propósito de una auditoría de software es proporcionar una evaluación independiente de la conformidad de los productos y procesos de software con las regulaciones, normas, directrices, planes, especificaciones y procedimientos aplicables. Ejemplos de productos de software sujetos a auditoría incluyen, pero no se limitan a, lo siguiente:

• Planes de copia de seguridad y recuperación,
• Planes de Contingencia.
• Contratos.
• Quejas de clientes o usuarios.
• Planes de desastre.
• Planes de rendimiento del hardware.
• Planes de instalación.
• Procedimientos de instalación.
• Etc.

Modelos en los procesos de software

Modelo cascada

Primer Modelo en el Proceso de Desarrollo de Software. Debido a la cascada de una fase a otra, se conoce como: “modelo en cascada” o “ciclo de vida del software”. En ingeniería de software el desarrollo en cascada es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software. Se popularizó en la década de los 70 y guía la mayor parte de la práctica actual. El proceso es una “cascada” de fases, donde el producto de una fase es la entrada de la siguiente.

Este sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado. Este modelo es aplicable en donde existen ocasiones en que los requisitos de un problema se entienden de una manera razonable y deben estar bien definidos, también cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal, esta situación se encuentra a veces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente. El modelo en cascada es el paradigma más antiguo para la ingeniería del software. Sin embargo, en las décadas pasadas, las críticas a este modelo de proceso han ocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia.       

Aplicación del modelo cascada:

• Se sigue una secuencia lineal de etapas.
• Las empresas establecen los productos y documentos que deben producirse en cada etapa.
• Estos productos y/o documentos permiten seguir el avance del proyecto.
• También se establece qué métodos aplicar en cada etapa.

Estos métodos se organizan en forma coherente en lo que es la “metodología de desarrollo de la empresa

Variaciones del modelo cascada:

• Sistemas de áreas conocidas pueden omitir el análisis de factibilidad.
• Sistemas complejos y/o grandes requieren dividir su desarrollo en porciones más pequeñas que puedan desarrollarse en forma más controlada y rigurosa.
• Un sistema con usuarios no especialistas puede requerir una etapa de entrenamiento y preparación de material de apoyo.

Desarrollo en cascada

Esta metodología elegida, de modelo en cascada, facilita una planificación sencilla. Podemos pasar por alto detalles concretos y después, en una nueva planificación, llevarlos a cabo. La calidad de este tipo de proyectos es muy alta dado que una vez terminada una versión puede mejorarse e incluso rediseñarse para que su funcionamiento sea más eficiente, fundamentalmente en las fases de interacción con el usuario del sistema y en la estructura del árbol de decisión. Además, esta metodología estuvo bastante acertada, pues los requisitos no los tuvimos completados hasta casi la fase final. También, dado el carácter del proyecto, principalmente descriptivo, no nos resultó muy traumático en el momento de hacer los cambios en la implementación.

1. Ingeniería y Análisis del Sistema: 

Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.

2. Análisis de Requisitos:

El proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar. El ingeniero de software (Analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas.

En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos. Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del software.

3. Diseño del Sistema:

Se descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras. Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. El primero de ellos tiene como objetivo definir la estructura de la solución (una vez que la fase de análisis ha descrito el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la organización del código para comenzar la implementación.

4. Diseño del Programa:

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario, así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.

5. Codificación:

Es la fase de programación o implementación propiamente dicha. Aquí se implementa el código fuente, haciendo uso de prototipos, así como pruebas y ensayos para corregir errores.

El diseño debe traducirse en una forma legible para la máquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente. Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucho más rápido.

6. Pruebas: 

Una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.  Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser puesto en funcionamiento. Las empresas pueden establecer estándares de pruebas:

• definición de un plan de pruebas.
• criterios de pruebas (caja negra, caja blanca).
• criterios de fin de las pruebas.
• administración de los casos de prueba.
• La depuración (“debugging”) es parte de esta etapa.
• Es el control de calidad llevado a cabo en esta etapa.
• Inspecciones para comprobar adhesión a los estándares.

 Existen varios tipos de Pruebas:

• Pruebas de unidad: ver que cada componente del programa cumpla con las especificaciones.
• Pruebas de integración: se integra los componentes y se prueba el funcionamiento del sw.
• Pruebas de sistema: Se prueban rendimiento y seguridades.
• Pruebas de aceptación: los hace el cliente y el usuario para estar seguros de que el sw cumple con las necesidades.

7. Mantenimiento:

•  El software necesitará cambios después de la entrega.
• El análisis de requisitos es una fuente de problemas, especialmente para los usuarios finales:
• los requisitos son difíciles de especificar,
• los requisitos cambian con el tiempo.
• Muchos errores no son resueltos hasta después de instalar el software en el cliente:
• es más caro corregir errores cuanto más tarde se detectan.
• Los cambios son (casi) siempre posibles, pero también (casi) siempre muy difíciles.
• El mantenimiento son todas las actividades que ocurren después que el software está instalado:
• corregir errores,
• agregar nueva funcionalidad

 Los tipos de mantenimiento son:

• Mantenimiento Preventivo y Perfectivo.
•  Mantenimiento Correctivo.
•  Mantenimiento Evolutivo.

Modelo espiral

El modelo en espiral del proceso del software que originalmente fue propuesto por Boehm (1988). El modelo en espiral es una de las más recomendables para el desarrollo y creación de un programa, ya que consta de pocas etapas o fases, las cuales se van realizando en manera continua y cíclica. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo.

Este es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.

EL modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas REGIONES DE TAREAS, Cada una de las regiones están compuestas por un conjunto de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las características del proyecto que va a emprenderse en todos los casos se aplican actividades de protección.

Cada ciclo espiral se divide en 4 etapas:

1. Definición de objetivos: Para esta fase del proyecto se definen los objetivos específicos. Se identifican las restricciones del proceso y el producto, y es estipula un plan detallado de administración. Se identifican los riesgos, se planean estrategias alternativas.

2. Evaluación y reducción de riesgos: Se lleva a cabo un análisis detallado para cada uno de los riesgos del proyecto. Se definen los pasos para reducir dichos riesgos, Por ejemplo, si existe el riesgo de tener requerimientos inapropiados, se desarrolla un prototipo del sistema.

3. Desarrollo y validación: Después de la evaluación de riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si los riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado, y así sucesivamente. El modelo de cascada es el más apropiado para el desarrollo si el mayor riesgo identificado es la integración de los subsistemas.

4. Planeación: El proyecto se revisa y se toma la decisión si se debe continuar con un ciclo posterior de la espiral. Si se decide continuar, se desarrollan los planes para la siguiente fase del proyecto. Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez más completa y, al final, el propio sistema software totalmente funcional.

El modelo en espiral WINWIN de Boehm, define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral. Más que una simple actividad de comunicación con el cliente se definen las siguientes actividades:

• Identificación del sistema o subsistemas clave de los directivos.
•  Determinación de las condiciones de victoria de los directivos.
•  Negociación de las condiciones de victoria de los directivos para reunirlas en un conjunto de condiciones para todos los afectados (incluyendo el equipo del proyecto de software).

El modelo en espiral WINWIN introduce tres hitos en el proceso, llamados puntos de fijación que ayudan a establecer la completitud de un ciclo alrededor de la espiral y proporcionan hitos de decisión.

Un ciclo de espiral comienza con la elaboración de los objetivos tanto funcionales como de rendimiento. Después se enumeran algunas formas posibles de alcanzar estos objetivos identificando las fuentes de riesgos posibles. El siguiente paso es resolver estos riesgos y llevar a cabo las actividades de desarrollo. Finalmente se planifica el siguiente ciclo de la espiral.

• Trata de mejorar los ciclos de vida clásicos y prototipos.
• Este modelo puede combinarse con otros modelos de proceso de desarrollo (cascada, evolutivo).
• En cada giro se construye un nuevo modelo del sistema completo.
• El análisis de riesgo requiere la participación de personal con alta cualificación.
• Incorpora objetivos de calidad y gestión de riesgos.
• Elimina errores y alternativas no atractivas al comienzo.
• Permite iteraciones, vuelta atrás y finalizaciones rápidas.
• Cada ciclo empieza identificando:
•  Los objetivos de la porción correspondiente.
•  Las alternativas.
• Restricciones.

Modelo V

El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo dela aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.

Este modelo tiene como objetivos:

• Regular el proceso de desarrollo del software.
• Minimización de los riesgos del proyecto.
• Mejorar y Garantizar la Calidad del proyecto.
• Reducción de los gastos totales durante todo el proyecto.
• Mejorar la comunicación entre todos los inversionistas.

Descripción del modelo V:

Representación gráfica del ciclo de vida del desarrollo de un sistema. En él se resumen las principales medidas que deben adoptarse en relación con las prestaciones correspondientes en el marco del sistema informático de validación. Aquí se describen las actividades y resultados que deben producirse durante el desarrollo del proyecto. Es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño.

La letra “V” significa «Verificación y validación».

• El lado izquierdo de la V: representa la descomposición de las necesidades, yla creación de las especificaciones del sistema.
• El lado derecho de la V: representa la integración de las piezas y su verificación.

V Es muy similar al modelo de la cascada clásico ya que es muy rígido y contiene una gran cantidad de iteraciones.

Partes del método:

La corriente de especificación consiste en:

• Conceptos de operaciones: qué debe hacer el sistema a grandes rasgos.
• Requisitos del sistema y arquitectura del mismo. Diseño detallado.

La corriente de pruebas consiste en:

• Integración de las distintas partes, test y verificación de las mismas.
• Verificación y validación del sistema en conjunto.
• Mantenimiento del sistema.

Fases del diagrama

• Fase #1: está orientado al “cliente”. El inicio del proyecto y el fin del proyecto constituyen los dos extremos del ciclo. Se componen del análisis de requisitos y especificaciones, se traduce en un documento de requisitos y especificaciones.

• Fase #2: se dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o indirectamente visibles por el usuario final, se traduce en un documento de análisis funcional.

• Fase #3: define los componentes es la fase de hardware y software del sistema final, a cuyo conjunto se denomina arquitectura del sistema.

• Fase #4: es la fase de implementación en la que se desarrollan los elementos unitarios o módulos del programa.

Conclusión

Una vez vistos los temas tales como la revisión estática, los términos del IEEE y algunos de los modelos de desarrollo, primero que todo las revisiones estéticas son importantísimas ya que nos ayudan a detectar defectos u errores la en un tiempo prematura, respecto al proyecto en el que se esté trabajando. Ciertamente si logramos detectar a temprana “edad” lo errores, es probable que este nos lleve a obtener grandes beneficios ya sea en costos y tiempo, incluso en lo que respecta al desarrollo del código. Así que en mi opinión este tipo de revisiones son muy útiles si se desarrollan y aplican correctamente. Lo cual nos genera un desarrollo de software de alta calidad y con respaldo. Por otro lado, tenemos lo que es el IEEE 1028-2008, el cual nos comenta como su propósito la cual es definir revisiones sistemáticas y auditorías aplicables a la adquisición, suministro, desarrollo, operación y mantenimiento de software. Es decir, aquí nos damos cuenta sobre lo que son lo importante de las diferentes revisiones y sobre como esta norma describe cómo realizar una revisión. Posteriormente tenemos lo que son las revisiones de software en las cuales se pueden utilizar en apoyo de los objetivos de gestión de proyectos, ingeniería de sistemas de configuración, garantía de calidad y auditoría. Donde es de importante tener en cuenta como todas estas acciones que se pueden realizar van de la mano con una estandarización de procesos como lo establece esta norma, la cual es una de las más importantes en el mundo, una que refleja la altísima calidad que se puede obtener, de cumplir al pie de la letra con lo que nos solicitan.

 Por último, pero no más importante tenemos los modelos de desarrollo los cuales ciertamente son una de las secciones más habituales, aun así son de muy utilidad a la hora de desarrollar proyectos, el mismo tipo de modelo que se desea trabajar conjuntamente dependerá de las necesidades del proyecto.

Conjuntamente estos tres temas son muy interesantes y dichosamente existe más información para informarse a futuro, lo cual nos ayudara como estudiantes en computación, ya que estos son unas de las tantas bases que nos ayudaran a realizar nuestra trabajo de la mejor manera, dando un respaldo de confianza y calidad en los trabajos futuros.

Referencias Bibliográficas

Cano, J. E. (13 de octubre de 2013). Slideshare. Obtenido de Técnicas Estáticas: https://es.slideshare.net/juanestebanpuertacano/tcnicas-estticas

Diez, E. (s.f.). Obtenido de Pruebas Estáticas: http://sistemas.unla.edu.ar/sistemas/sls/ls-4-optativa-algoritmos-y-lenguajes-prueba-del-software/pdf/Pruebas-de-Software-C03-Pruebas-estaticas.pdf

López, J. M. (2009). Obtenido de Verificación y Validación: https://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_VerificacionValidacion-2011.pdf

mendez45. (19 de mayo de 2010). slideshare. Obtenido de Modelo de cascada: https://es.slideshare.net/mendez45/modelo-de-cascadaa

NA. (s.f.). Obtenido de TÉCNICAS DE EVALUACIÓN ESTÁTICA: http://www.lsi.us.es/docencia/get.php?id=360

Ortega, M. (16 de abril de 2012). Slideshare. Obtenido de Modelo V: https://es.slideshare.net/MelissaOrtega5/modelo-v

Posligua, S. (14 de noviembre de 2013). Slideshare. Obtenido de Modelo en espiral: https://es.slideshare.net/soniaposligua/modelo-enespiral

Romero, M. (28 de julio de 2010). Slideshare. Obtenido de Modelo V: https://es.slideshare.net/grupo04/mtodo-v?next_slideshow=1

Committee, S. &. (2008). IEEE Standard for Software Reviews. New York, NY: IEEE-SA Standards Board.