TRABAJO COLABORATIVO 3

Ingeniería de Software

TRABAJO COLABORATIVO 3 INGENIERIA DE SOFTWARE

ESTUDIANTES: EDWIN FABIAN ALONSO MARTINEZ 79.725.512 ALFONSO SANCHEZ DUSAN 301404 JUAN CARLOS RODRIGUEZ BAQUERO LUIS ANGEL GONZALEZ ESQUIVEL

TUTOR: JAIRO MARTINEZ BANDA

UNIVERSIDAD NACIONAL ABIERTA YA DISTANCIA “UNAD” JULIO 2011

Ingeniería de Software

INTRODUCCION

Desarrollar un software significa construirlo simplemente mediante su descripción. Está es una muy buena razón para considerar la actividad de desarrollo de software como una ingeniería. En un nivel más general, la relación existente entre un software y su entorno es clara ya que el software es introducido en el mundo de modo de provocar ciertos efectos en el mismo. Aquellas partes del mundo que afectarán al software y que serán afectadas por él será el Dominio de Aplicación. Es allí donde los usuarios o clientes observarán si el desarrollo del software ha cumplido su propósito. Una de las mayores deficiencias en la práctica de construcción de software es la poca atención que se presta a la discusión del problema. En general los desarrolladores se centran en la solución dejando el problema inexplorado. El problema a resolver debe ser deducido a partir de su solución. Esta aproximación orientada a la solución puede funcionar en campos donde todos los problemas son bien conocidos, clasificados e investigados, donde la innovación se ve en la detección de nuevas soluciones a viejos problemas.

Ingeniería de Software

OBJETIVOS

Objetivo general.

Evaluar la importancia de realizar software de calidad para las organizaciones y la importancia del control información en ellas.

Objetivos específicos.

-

Mejorar la calidad de los productos de software

-

Aumentar la productividad y trabajo de los ingenieros del software.

-

Facilitar el control del proceso de desarrollo de software.

-

Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.

-

Definir una disciplina que garantice la producción y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.

-

Desarrollar competencias para la construcción de software de calidad.

Ingeniería de Software

¿Es posible evaluar la calidad del software si el cliente no se pone de acuerdo sobre lo que se supone que ha de hacer? Justifique su respuesta y argumente.

No es posible evaluar la calidad del software si el cliente no se pone de acuerdo sobre lo que se supone que ha de hacer el prototipo ya que el principal objetivo de dicho proceso se fundamenta en la revisión, medición, prueba y evaluación de las condiciones de funcionamiento del prototipo creado para asegurar que cumple con los requisitos que han sido establecidos, lo cual no es posible si no tiene claro lo que desea el cliente. Adicionalmente, el proceso de especificación y validación de requerimientos por parte del usuario se lleva a cabo en la etapa inmediatamente anterior que es la etapa de gestión en la cual se planifica, supervisa y controla la especificación de los requisitos que se deben tener en cuenta para la construcción del proyecto de software, para que posteriormente se realice la evaluación de calidad del proyecto de software con base en dichas especificaciones.

No porque la filosofía de la Calidad del software proporciona una concepción global que fomenta la Mejora Continua en la organización involucrando a todos sus miembros, centrándose en la satisfacción tanto del cliente interno como del externo.

Podemos definir esta filosofía del siguiente modo: Gestión (el cuerpo directivo está totalmente comprometido) de la Calidad (los requerimientos del cliente son comprendidos y asumidos exactamente) Total (todo miembro de la organización está involucrado, incluso el cliente y el proveedor, cuando esto sea posible); y en consecuencia de la plena satisfacción de las necesidades y expectativas del cliente (interno y externo).

Ingeniería de Software

2. Si se le da la responsabilidad de mejorar la calidad del software en su organización. ¿Qué es lo primero que haría? ¿Qué sería lo siguiente? Definir la calidad

Impacto en la Calidad: Satisfacer los requerimientos del negocio; lograr una experiencia de usuario satisfactoria.

Beneficio: Su capacidad para lograr la calidad mejora, porque el equipo de desarrollo de aplicaciones no se llena de expectativas demasiado perfectas. Por el contrario, está alineado con una definición de la calidad que se ajusta a los tiempos establecidos, los recursos y las limitaciones presupuestarias. Roles relevantes: Clientes internos del negocio; todo el equipo de desarrollo de aplicaciones. Difundir métricas simples de calidad Impacto en la Calidad: Reduce los defectos. Beneficios: Las métricas altamente visibles mantienen la calidad en la mente de todo el equipo y muestran cuándo los esfuerzos se quedan cortos. Roles relevantes: Todo el equipo de desarrollo de aplicaciones. Afinar las metas individuales y del equipo para incluir la calidad Impacto en la Calidad: Se cumple con los requerimientos del negocios, se logra una experiencia de usuario satisfactoria; se reducen los defectos. Beneficio: Los miembros del equipo se desempeñan de acuerdo a sus incentivos, hacer de la mejora de la calidad parte de sus metas refuerza la conducta deseada. Roles relevantes: Gerencia. Obtener los requisitos adecuadamente Impacto en la Calidad: Cumple con los requerimientos del negocio, logra una experiencia de usuario satisfactoria. Beneficio: Menos reelaboración significa menos repetición de pruebas y menos ciclos, lo cual reduce enormemente el esfuerzo general.

Ingeniería de Software

Roles relevantes: Gerentes, analistas de negocio, diseñadores de experiencia del usuario, arquitectos. Realizar pruebas más inteligentes para efectuar menos pruebas Impacto en la Calidad: Reduce los defectos. Beneficio: Un enfoque en evaluaciones de las áreas más riesgosas y cruciales asegura que reciban la mayor parte de los recursos para evaluaciones y que cualquier bug que haya estará circunscrito a las características de menor importancia. Roles relevantes: Control de calidad, gerentes. Diseñar aplicaciones para disminuir el riesgo de errores Impacto en la Calidad: Reduce los defectos. Beneficio: Diseños más simples y limpios producen código que es más simple, más limpio y más fácil de evaluar y volver a trabajar, lo cual significa que el código tendrá menos errores y que esos bugs serán más fáciles de diagnosticar y reparar. Roles relevantes: Arquitectos, desarrolladores. Optimizar el uso de las herramientas de prueba Impacto en la Calidad: Reduce los defectos. Beneficio: La automatización libera recursos de las pruebas comunes para enfocarse en las pruebas de alta prioridad e incrementa la posibilidad de repetición de los ciclos de pruebas. Roles relevantes: Control de calidad, desarrolladores. "La calidad debe ir más allá del alcance de solo los profesionales de control de calidad para convertirse en una parte integrada del ciclo completo de vida del desarrollo de software, para reducir el trabajo redundante que mata cronogramas, mejora la satisfacción del usuario y reducir el riesgo de requerimientos no funcionales no probados tales como la seguridad y el rendimiento", afirman los analistas, agregando: "Los administradores deben hacer la calidad medible e incentivar a todos los puestos del equipo a mejorarla".

Ingeniería de Software

3. Una reunión de revisión técnica formal sólo es efectiva si todo el mundo se prepara por adelantado. ¿Cómo descubriría que uno de los participantes no se ha preparado? ¿Qué haría si fuera el jefe de división? Los participantes de la revisión son: · El jefe de revisión: Quien lidera la reunión. · Los revisores: Uno de los cuales se encarga de registrar todos los sucesos de la reunión. · El productor. Descubriría que uno de los participantes no se ha preparado si desconoce qué se va a revisar, quienes lo van a realizar y desconoce aspectos importantes de la agenda, como los objetivos y la temática procedimental, además cada participante debe estar capacitado en el proceso y psicología humana. Por lo que en la reunión se evidenciará la debida preparación de los participantes conforme las intervenciones sean apropiadas. Si yo fuera el jefe de división planearía la reunión mediante una agenda de trabajo. Y presidiría la reunión bajo los siguientes parámetros: · Revisar el producto, no al productor.

· Fijar una agenda y mantenerla. · Limitar el debate y las impugnaciones. · Enunciar áreas problemas pero no intentar resolver los problemas que se pongan de manifiesto. · Tomar notas escritas. · Limitar el número de participantes e insistir en la preparación anticipada. · Desarrollar una lista de comprobación para cada producto que haya de ser revisado. · Disponer recursos y una agenda para las Revisiones Técnicas Formales. · Capacitación y entrenamiento de los revisores. · Revisar las revisiones anteriores. Quienes no demuestren estar preparados para la Revisión Técnica Formal deberán ser removidos del proyecto, y si es necesario la reunión será aplazada.

4. ¿Quién debe llevar a cabo la prueba de validación -el desarrollador del software o el usuario-? Justifique su respuesta

Ingeniería de Software

INTRODUCCIÓN

La validación automática de sistemas es el proceso por el cual los requisitos de sistemas son corroborados con poca o nula participación por parte del equipo de proyecto, lo que permite mejorar el producto obtenido. En términos generales esto se logra relacionando cada requisito de sistema a un paquete de pruebas.

La validación automática de software es una práctica que en los últimos tiempos la comunidad de informática le a prestado atención debido a los costos cada vez más altos que tiene el proceso de complicación-depuración-integración-producción de los sistemas software.

Alguna de las razones por lo cual se hace menester hoy más que nunca intentar llegar a un proceso de validación automática de sistemas es:

- Requerimientos de usuarios cada vez más complejos. - Diversidad de lenguajes con los que se desarrolla un mismo sistema. - Diferentes plataformas donde se debe ejecutar un sistema. - Distintos entornos de programación. - Constante avance de las tecnologías y métodos de desarrollo. - Alta rotación de personal. La validación del software debe basarse en la prevención y detección temprana de los errores • Primer error: “Primero yo construyo y después tú válidas”.

Ingeniería de Software

• Segundo error: Asumir que el usuario, además de conocer su negocio, domina las técnicas de validación.

El éxito de la validación de los requerimientos reside en unas pruebas de aceptaciones Completas e independientes El proceso de pruebas debe iniciarse en una fase temprana del ciclo de vida, integrándose en el desarrollo de la aplicación. Ambos procesos, desarrollo y pruebas, se realizan en paralelo, manteniendo un compromiso y una comunicación fluida entre los equipos de desarrollo y de pruebas. Las principales características que contribuyen a asegurar una validación exitosa de los requerimientos son: • Las pruebas no son una fase aislada del proyecto, sino que constituyen en sí un proyecto con su propio ciclo de vida integrado en el del propio proyecto. • Los equipos de desarrollo y pruebas son independientes, con funciones y perfiles diferenciados. • Antes de la ejecución de las pruebas, se lleva a cabo todo un proceso metodológico que facilita y asegura el éxito de las mismas. En el momento de la ejecución, está todo previsto, tanto los aspectos funcionales como técnicos, evitándose la improvisación. • La figura del usuario (equipo) participa en el inicio y fin del ciclo. La clave está en determinar los roles que participan: negocio, áreas técnicas (informática y organización), sistemas y producción. • Se prueban todos los tipos de requerimientos del proyecto: funcionales, técnicos, de interfaz de usuario, de rendimiento, etc.

Equipo de pruebas

Las pruebas deben realizarse por un equipo independiente y multidisciplinar, con la siguiente composición:

• Un coordinador de pruebas para interactuar con los diferentes equipos involucrados: desarrollo, pruebas y usuarios funcionales y técnicos.

Ingeniería de Software

• Equipo de pruebas para realizar todas las actividades relacionadas con las pruebas de aceptación. • Usuarios funcionales, responsables de cada parte funcional de las aplicaciones, y usuarios técnicos, responsables de los aspectos técnicos de las aplicaciones y la instalación, con las siguientes funciones: a) Participación en la definición del Plan de pruebas. b) Participación en la definición del Modelo de pruebas. c) Participación en la ejecución de las pruebas. d) Colaboración en el análisis de las incidencias. e) Aceptación del producto final. • Un responsable de entornos de la instalación, con las siguientes funciones: a) Participación en la planificación del entorno de pruebas. b) Preparación del entorno de pruebas. c) Soporte al entorno. d) Limpieza del entorno de pruebas. • Participación de los equipos de desarrollo objeto de las pruebas de aceptación. Las pruebas de aceptación contribuyen de forma decisiva a la consecución de los objetivos de calidad de los proyectos Como consecuencia de la adecuada validación de los requerimientos, los proyectos cumplen con su compromiso de calidad. Los beneficios que se consiguen no sólo repercuten en el área inmediata de desarrollo de los proyectos, sino que se extienden al resto de la empresa, áreas de negocio y cliente final: • “Informática” cumple sus compromisos de plazo, coste y calidad. • Los proyectos pasan al entorno de producción con estabilidad, se minimiza el mantenimiento correctivo después de la implantación de los sistemas.

• Se ha dado respuesta a los aspectos técnicos relevantes del ciclo de vida en producción: crecimiento esperado de BBDD, puntos de backup y recovery, tiempos de respuesta, ventana batch...

Ingeniería de Software

• En definitiva, se facilita la transición de desarrollo a producción y se incrementa la confianza y el nivel de satisfacción de los usuarios finales de la explotación del nuevo sistema. • Se incrementa la confianza y el nivel de satisfacción de los usuarios y se facilita el proceso de aceptación, ya que se proporciona una evidencia objetiva de la satisfacción de los requisitos del sistema.

CONCLUSIONES

Ingeniería de Software

Cada vez es más necesario que los ingenieros de software desarrollen y le entreguen al cliente productos de la más alta calidad. Asimismo no deben de descuidar el compromiso que el ingeniero tiene con el cliente de entregar el producto puntualmente. Además de que debe de estar consiente que el producto que va a desarrollar para el cliente, cuente con un presupuesto al alcance del cliente y que éste no sufra de modificación alguna.

Los ingenieros que no cumplan con estos compromisos, se arriesgan a que existan penalidades en los contratos y hasta la pérdida misma del cliente. Por lo tanto, este tipo de ingenieros no tiene un buen futuro y tiende a desaparecer.

BIBLIOGRAFIA

Ingeniería de Software

Modulo Ingeniería del software UNAD FACULTAD DE CIENCIAS BASICAS E INGENIERIA PROGRAMA INGENIERIA DE SISTEMAS Pressman R., "Ingeniería del Software, un Enfoque Práctico" - Tercera Edición Editorial Mc Graw-Hill - 1993. Bernd Bruegge, Allen h. Dutoit. “Ingeniería de Software Orientado a Objetos”. Prentice Hall. 2002. Sommerville. "Ingeniería de Software 6ª Edición". Addison Wesley. apartados 4.1 4.3 Sahri Lawrence Pfleeger. 2002. “Ingeniería de Software. Teoría y Práctica”. Prentice Hall. Capítulo 7.