ETICA PROFESIONAL EN LOS INGENIEROS DE SOFTWARE

OBSERVACIONES DE LA ÉTICA DE INGENIERÍA 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. PERSONAS. 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, congruente-mente
 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 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.

modelo v Gestión de desarrollo de software

BENEFICIOS

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 interacció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 implí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.

FASE 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 Unidades: 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.

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.

MODELO EN V

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.

define un procedimiento uniforme para el desarrollo de productos para las TIC. Es el estándar utilizado para los proyectos de la administración federal alemana y de defensa. Como está disponible públicamente muchas compañías lo usan. Es un método de gestión de proyectos comparable a prince2 y describe tanto métodos para la gestión como para el desarrollo de sistemas.

¿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.