6. Observaciones De La Ética Del Ingeniero De Software

Los ingenieros de software deberán comprometerse a convertir el análisis, especificación, diseño, implementación, pruebas y mantenimiento de software en una profesión respetada y benéfica. De acuerdo a su compromiso con la salud, seguridad y bienestar social, los ingenieros de software deberán sujetarse a los ocho principios siguientes:

1.    Publico. Los ingenieros de software actuarán en forma congruente con el interés social.

2.   Cliente. y empresario. Los ingenieros de software actuarán de manera que se concilien los mejores intereses de sus clientes y empresarios, congruentemente con el interés social.

3.   Producto. Los ingenieros de software asegurarán que sus productos y modificaciones correspondientes cumplen los estándares profesionales más altos posibles.

4.   Juicio. Los ingenieros de software mantendrán integridad e independencia en su juicio profesional.

5.   Gerencia. Los ingenieros de software gerentes y líderes promoverán y se suscribirán a un enfoque ético en la administración del desarrollo y mantenimiento de software.

6.   Profesión. Los ingenieros de software incrementarán la integridad y reputación de la profesión congruentemente con el interés social.

7.   Colegas. Los ingenieros de software apoyarán y serán justos con sus colegas.

    Los ingenieros de software participarán toda su vida en el aprendizaje relacionado con la práctica de su profesión y promoverán un enfoque ético en la práctica de la profesión.

5.Modelo v Gestión de desarrollo de software

4.Beneficio

Ventajas

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.

• Es un modelo sencillo y de fácil aprendizaje.

• Hace explícito parte de la iteración y trabajo que hay que revisar.

• Especifica bien los roles de los distintos tipos de pruebas a realizar.

• Involucra al usuario en las pruebas.

Desventajas

• Es difícil que el cliente exponga explícitamente todos los requisitos.

• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida.

• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas.

• El producto final obtenido puede que no refleje todos los requisitos del usuario.

3.Fases de Verificación

1.Análisis de Requisitos

En esta fase se colectan los requisitos del sistema y se analizan las necesidades del usuario. Esta fase determina que debe realizar el “sistema ideal”, pero no determina como será diseñado o construido.

1.1 Diseño del Sistema

Los técnicos analizan y entienden el funcionamiento o negocio del sistema propuesto, para ellos se basan en las exigencias del consumidor. Se calcula cada posibilidad y técnica que dichas exigencias pudieren ser ejecutadas.

1.2 Diseño del módulo

Codificar los fragmentos del sistema.

2. Prueba de Unidad

Mediante el análisis de código se descubren primeros fallos, corregirlos hace una reducción de costos al proyecto total.

2.1 Prueba de Integración

Probar los módulos separados (fragmentos del proyecto) en conjunto para detectar errores en interfaces y en la interacción de componentes integrados.

2.2 Prueba del Sistema

Se realiza una comparación del sistema producido hasta el momento contra el sistema real, utilizando los documentos de diseño.

2.3 Prueba de aceptación del Usuario

En caso de que no sea aceptado, se realizarán los cambios necesarios según las necesidades originales.

2.Objetivos

1. Minimización de los riesgos del proyecto

Mejora la transparencia del proyecto y control del proyecto, especificando los enfoques estandarizados, describe los resultados correspondientes y funciones de responsabilidad. Permite una detección temprana de las desviaciones y los riesgos y mejora la gestión de procesos, reduciendo así los riesgos del proyecto.

2.Mejora y Garantía de Calidad

Como un modelo de proceso estándar, asegura que los resultados que se proporcionan sean completos y contengan la calidad deseada. Los resultados provisionales definidos se puede comprobar en una fase temprana. La uniformidad en el contenido del producto mejora la legibilidad, comprensibilidad y verificabilidad.

3.Reducción de los gastos totales

El esfuerzo para el desarrollo, producción, operación y mantenimiento de un sistema puede ser calculado, estimado y control de manera transparente mediante la aplicación de un modelo de procesos estandarizados. Reduciendo la dependencia en los proveedores y el esfuerzo para las siguientes actividades y proyectos.

4.Mejora de la comunicación entre todos los inversionistas

La descripción estandarizada y uniforme de todos los elementos pertinentes y términos es la base para la comprensión mutua entre todos los inversionistas. De este modo, se reduce la pérdida por fricción entre el usuario, comprador, proveedor y desarrollador.

1.Modelo V

Introducción

Definición: En la construcción de un producto de software el orden en que se realicen las distintas etapas y actividades para su desarrollo, define el ciclo de vida; esto va desde la concepción de la idea hasta la concretización de la misma.

¿Qué es el Modelo en V?

*Es una representación gráfica del ciclo de vida del desarrollo de sistemas.

*El Modelo V tiende a ser muy relacionado con el Modelo de Cascada 

puesto que es una evolución de este.

*Se describen las actividades y resultados que deben producirse durante el desarrollo del producto.

*El lado izquierdo de la V representa la descomposición de las necesidades, y la creación de las especificaciones del sistema.

*El lado derecho de la V representa la integración de las piezas y su verificación.