Ingeniera 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

Ingeniera de Software

INTRODUCCION

Desarrollar un software significa construirlo simplemente mediante su descripcin. Est es una muy buena razn para considerar la actividad de desarrollo de software como una ingeniera. En un nivel ms general, la relacin 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 afectarn al software y que sern afectadas por l ser el Dominio de Aplicacin. Es all donde los usuarios o clientes observarn si el desarrollo del software ha cumplido su propsito. Una de las mayores deficiencias en la prctica de construccin de software es la poca atencin que se presta a la discusin del problema. En general los desarrolladores se centran en la solucin dejando el problema inexplorado. El problema a resolver debe ser deducido a partir de su solucin. Esta aproximacin orientada a la solucin puede funcionar en campos donde todos los problemas son bien conocidos, clasificados e investigados, donde la innovacin se ve en la deteccin de nuevas soluciones a viejos problemas.

Ingeniera de Software

OBJETIVOS

Objetivo general.

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

Objetivos especficos.

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 produccin y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado. Desarrollar competencias para la construccin de software de calidad.

Ingeniera 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 revisin, medicin, prueba y evaluacin 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 especificacin y validacin de requerimientos por parte del usuario se lleva a cabo en la etapa inmediatamente anterior que es la etapa de gestin en la cual se planifica, supervisa y controla la especificacin de los requisitos que se deben tener en cuenta para la construccin del proyecto de software, para que posteriormente se realice la evaluacin de calidad del proyecto de software con base en dichas especificaciones.

No porque la filosofa de la Calidad del software proporciona una concepcin global que fomenta la Mejora Continua en la organizacin involucrando a todos sus miembros, centrndose en la satisfaccin tanto del cliente interno como del externo.

Podemos definir esta filosofa del siguiente modo: Gestin (el cuerpo directivo est totalmente comprometido) de la Calidad (los requerimientos del cliente son comprendidos y asumidos exactamente) Total (todo miembro de la organizacin est involucrado, incluso el cliente y el proveedor, cuando esto sea posible); y en consecuencia de la plena satisfaccin de las necesidades y expectativas del cliente (interno y externo).

Ingeniera de Software

2. Si se le da la responsabilidad de mejorar la calidad del software en su organizacin. Qu es lo primero que hara? Qu sera 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 definicin 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 mtricas simples de calidad Impacto en la Calidad: Reduce los defectos. Beneficios: Las mtricas altamente visibles mantienen la calidad en la mente de todo el equipo y muestran cundo 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 desempean 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 reelaboracin significa menos repeticin de pruebas y menos ciclos, lo cual reduce enormemente el esfuerzo general.

Ingeniera de Software

Roles relevantes: Gerentes, analistas de negocio, diseadores de experiencia del usuario, arquitectos. Realizar pruebas ms inteligentes para efectuar menos pruebas Impacto en la Calidad: Reduce los defectos. Beneficio: Un enfoque en evaluaciones de las reas ms riesgosas y cruciales asegura que reciban la mayor parte de los recursos para evaluaciones y que cualquier bug que haya estar circunscrito a las caractersticas de menor importancia. Roles relevantes: Control de calidad, gerentes. Disear aplicaciones para disminuir el riesgo de errores Impacto en la Calidad: Reduce los defectos. Beneficio: Diseos ms simples y limpios producen cdigo que es ms simple, ms limpio y ms fcil de evaluar y volver a trabajar, lo cual significa que el cdigo tendr menos errores y que esos bugs sern ms fciles 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 automatizacin libera recursos de las pruebas comunes para enfocarse en las pruebas de alta prioridad e incrementa la posibilidad de repeticin de los ciclos de pruebas. Roles relevantes: Control de calidad, desarrolladores. "La calidad debe ir ms 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 satisfaccin 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".

Ingeniera de Software

3. Una reunin de revisin tcnica formal slo es efectiva si todo el mundo se prepara por adelantado. Cmo descubrira que uno de los participantes no se ha preparado? Qu hara si fuera el jefe de divisin? Los participantes de la revisin son: El jefe de revisin: Quien lidera la reunin. Los revisores: Uno de los cuales se encarga de registrar todos los sucesos de la reunin. El productor. Descubrira 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 temtica procedimental, adems cada participante debe estar capacitado en el proceso y psicologa humana. Por lo que en la reunin se evidenciar la debida preparacin de los participantes conforme las intervenciones sean apropiadas. Si yo fuera el jefe de divisin planeara la reunin mediante una agenda de trabajo. Y presidira la reunin bajo los siguientes parmetros:
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 nmero de participantes e insistir en la preparacin anticipada. Desarrollar una lista de comprobacin para cada producto que haya de ser revisado. Disponer recursos y una agenda para las Revisiones Tcnicas Formales. Capacitacin y entrenamiento de los revisores. Revisar las revisiones anteriores. Quienes no demuestren estar preparados para la Revisin Tcnica Formal debern ser removidos del proyecto, y si es necesario la reunin ser aplazada.

4. Quin debe llevar a cabo la prueba de validacin -el desarrollador del software o el usuario-? Justifique su respuesta

Ingeniera de Software

INTRODUCCIN

La validacin automtica de sistemas es el proceso por el cual los requisitos de sistemas son corroborados con poca o nula participacin por parte del equipo de proyecto, lo que permite mejorar el producto obtenido. En trminos generales esto se logra relacionando cada requisito de sistema a un paquete de pruebas.

La validacin automtica de software es una prctica que en los ltimos tiempos la comunidad de informtica le a prestado atencin debido a los costos cada vez ms altos que tiene el proceso de complicacin-depuracin-integracin-produccin de los sistemas software.

Alguna de las razones por lo cual se hace menester hoy ms que nunca intentar llegar a un proceso de validacin automtica de sistemas es:

- Requerimientos de usuarios cada vez ms complejos. - Diversidad de lenguajes con los que se desarrolla un mismo sistema. - Diferentes plataformas donde se debe ejecutar un sistema. - Distintos entornos de programacin. - Constante avance de las tecnologas y mtodos de desarrollo. - Alta rotacin de personal. La validacin del software debe basarse en la prevencin y deteccin temprana de los errores Primer error: Primero yo construyo y despus t vlidas.

Ingeniera de Software

Segundo error: Asumir que el usuario, adems de conocer su negocio, domina las tcnicas de validacin.

El xito de la validacin 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, integrndose en el desarrollo de la aplicacin. Ambos procesos, desarrollo y pruebas, se realizan en paralelo, manteniendo un compromiso y una comunicacin fluida entre los equipos de desarrollo y de pruebas. Las principales caractersticas que contribuyen a asegurar una validacin 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 ejecucin de las pruebas, se lleva a cabo todo un proceso metodolgico que facilita y asegura el xito de las mismas. En el momento de la ejecucin, est todo previsto, tanto los aspectos funcionales como tcnicos, evitndose la improvisacin. La figura del usuario (equipo) participa en el inicio y fin del ciclo. La clave est en determinar los roles que participan: negocio, reas tcnicas (informtica y organizacin), sistemas y produccin. Se prueban todos los tipos de requerimientos del proyecto: funcionales, tcnicos, de interfaz de usuario, de rendimiento, etc.

Equipo de pruebas

Las pruebas deben realizarse por un equipo independiente y multidisciplinar, con la siguiente composicin:

Un coordinador de pruebas para interactuar con los diferentes equipos involucrados: desarrollo, pruebas y usuarios funcionales y tcnicos.

Ingeniera de Software

Equipo de pruebas para realizar todas las actividades relacionadas con las pruebas de aceptacin. Usuarios funcionales, responsables de cada parte funcional de las aplicaciones, y usuarios tcnicos, responsables de los aspectos tcnicos de las aplicaciones y la instalacin, con las siguientes funciones: a) Participacin en la definicin del Plan de pruebas. b) Participacin en la definicin del Modelo de pruebas. c) Participacin en la ejecucin de las pruebas. d) Colaboracin en el anlisis de las incidencias. e) Aceptacin del producto final. Un responsable de entornos de la instalacin, con las siguientes funciones: a) Participacin en la planificacin del entorno de pruebas. b) Preparacin del entorno de pruebas. c) Soporte al entorno. d) Limpieza del entorno de pruebas. Participacin de los equipos de desarrollo objeto de las pruebas de aceptacin. Las pruebas de aceptacin contribuyen de forma decisiva a la consecucin de los objetivos de calidad de los proyectos Como consecuencia de la adecuada validacin de los requerimientos, los proyectos cumplen con su compromiso de calidad. Los beneficios que se consiguen no slo 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: Informtica cumple sus compromisos de plazo, coste y calidad. Los proyectos pasan al entorno de produccin con estabilidad, se minimiza el mantenimiento correctivo despus de la implantacin de los sistemas.

Se ha dado respuesta a los aspectos tcnicos relevantes del ciclo de vida en produccin: crecimiento esperado de BBDD, puntos de backup y recovery, tiempos de respuesta, ventana batch...

Ingeniera de Software

En definitiva, se facilita la transicin de desarrollo a produccin y se incrementa la confianza y el nivel de satisfaccin de los usuarios finales de la explotacin del nuevo sistema. Se incrementa la confianza y el nivel de satisfaccin de los usuarios y se facilita el proceso de aceptacin, ya que se proporciona una evidencia objetiva de la satisfaccin de los requisitos del sistema.

CONCLUSIONES

Ingeniera de Software

Cada vez es ms necesario que los ingenieros de software desarrollen y le entreguen al cliente productos de la ms alta calidad. Asimismo no deben de descuidar el compromiso que el ingeniero tiene con el cliente de entregar el producto puntualmente. Adems 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 modificacin alguna.

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

BIBLIOGRAFIA

Ingeniera de Software

Modulo Ingeniera del software UNAD FACULTAD DE CIENCIAS BASICAS E INGENIERIA PROGRAMA INGENIERIA DE SISTEMAS Pressman R., "Ingeniera del Software, un Enfoque Prctico" - Tercera Edicin Editorial Mc Graw-Hill - 1993. Bernd Bruegge, Allen h. Dutoit. Ingeniera de Software Orientado a Objetos. Prentice Hall. 2002. Sommerville. "Ingeniera de Software 6 Edicin". Addison Wesley. apartados 4.1 4.3 Sahri Lawrence Pfleeger. 2002. Ingeniera de Software. Teora y Prctica. Prentice Hall. Captulo 7.