Documentaci n de Software

1. Documentación de Software …a esta altura..? …por el interés que parece haberles despertado el tema.. Si, a esta altura… ahora tratemos de explicarnos que hacemos aquí… tratemos que este tiempo que vamos a insumir… sea productivo. Comparemos la década del 50, computadoras gigantescas disponibles a científicos por periodos de tiempo acotado (1/2 hora semanal). Hoy, el guardia de seguridad toma la foto del ingresante al edificio y lo registra como tal.…por el interés que parece haberles despertado el tema.. Si, a esta altura… ahora tratemos de explicarnos que hacemos aquí… tratemos que este tiempo que vamos a insumir… sea productivo. Comparemos la década del 50, computadoras gigantescas disponibles a científicos por periodos de tiempo acotado (1/2 hora semanal). Hoy, el guardia de seguridad toma la foto del ingresante al edificio y lo registra como tal.

2. www.prosyde.com GENERALIDADES INTRODUCCION EL PROBLEMA OBJETIVOS Vamos a proponer el camino a recorrer en esta presentación… la propuesta es una breve introducción, una enunciación del problema… y cuales son los objetivos que se alcanzan con su solución…Vamos a proponer el camino a recorrer en esta presentación… la propuesta es una breve introducción, una enunciación del problema… y cuales son los objetivos que se alcanzan con su solución…

3. www.prosyde.com INTRODUCCION Contexto histórico El hardware es mucho más caro que el software. El desarrollo del hardware es más complejo que el del software. El hardware es poco fiable. Contexto actual Tecnología adecuada vs. Urgencia constante Vamos a pasar rápidamente por el Contexto histórico, porque como la presente convocatoria en sus letras pequeñas decía “ENTRADA RESTRINGIDA PARA MENORES DE 8 AÑOS”, todos los presentes somos del siglo pasado, así que algo de historia ya conocemos. Piensen por un momento que algunos fuimos testigos de la desaparición de algunas especies y de la aparición de otras… que todavía conviven con nosotros. Desaparecidas? Perfo-verificador, grabo-verificador, Jefe de Equipo… y si le dedicamos tiempo… seguro se nos ocurren más. Aparecidas? Metodólogos, Diseñadores, Coordinadores… y los más cercanos hoy… Auditores de Sistemas. Comparemos: Hardware costoso (millones para comprarlo y mantenerlo), el software (el sueldo del científico, en comparación, era insignificante), así que ¿por qué preocuparse por el coste del desarrollo de software? Además, no siempre los sistemas fallaban por problemas de software. Podemos hacer un ejercicio de análisis e identificar algunas de las características del desarrollo de software en los comienzos de la informática.Vamos a pasar rápidamente por el Contexto histórico, porque como la presente convocatoria en sus letras pequeñas decía “ENTRADA RESTRINGIDA PARA MENORES DE 8 AÑOS”, todos los presentes somos del siglo pasado, así que algo de historia ya conocemos. Piensen por un momento que algunos fuimos testigos de la desaparición de algunas especies y de la aparición de otras… que todavía conviven con nosotros. Desaparecidas? Perfo-verificador, grabo-verificador, Jefe de Equipo… y si le dedicamos tiempo… seguro se nos ocurren más. Aparecidas? Metodólogos, Diseñadores, Coordinadores… y los más cercanos hoy… Auditores de Sistemas. Comparemos: Hardware costoso (millones para comprarlo y mantenerlo), el software (el sueldo del científico, en comparación, era insignificante), así que ¿por qué preocuparse por el coste del desarrollo de software? Además, no siempre los sistemas fallaban por problemas de software. Podemos hacer un ejercicio de análisis e identificar algunas de las características del desarrollo de software en los comienzos de la informática.

4. www.prosyde.com EL PROBLEMA Crisis del software Ingeniería de Software Ingeniería de Requerimientos? CMM (gestión de requisitos – Nivel 2) IEEE (International Symposium on Requirements Engineering) (International Conference on Requirements Engineering) Proyectos europeos NATURE (Novel Approaches to Theories Underlying Requirements Engineering). CREWS (Cooperative Requirements Engineering With Scenarios) CICYT MENHIR (Metodologías, Entornos y Nuevas Herramientas para la Ingeniería de Requerimientos) Los avances tecnológicos hacen que se empiecen a comercializar los primeros equipos y esto requiere mayor complejidad en la construcción de software. Crisis del software: término utilizado por primera vez en la conferencia organizada por la Comisión de Ciencia de la OTAN en Garmisch, Alemania, en octubre de 1968, para designar la gran cantidad de problemas que presentaba (y aún presenta) el desarrollo de software y el alto índice de fracasos en los proyectos de desarrollo. ¿Qué podía hacerse ante una situación en la que los proyectos software tenían un alto riesgo de fracasar? La respuesta parecía obvia: construir software de forma similar a como se construye hardware, aviones, barcos, puentes o edificios, es decir, aplicar los métodos de la ingeniería a la construcción de software. Ingenieria de Software: …como la aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software. Otra definición dice: la aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios. Ingenieria de Requerimientos? La ingeniería del software comprende una serie de actividades lo suficientemente diversas como para poder considerar la necesidad de otras ingenierías dentro de la propia ingeniería del software. La ingeniería de requerimientos es todavía una disciplina joven en la que aún no se han definido claramente la terminología, los procesos ni los productos. En [IEEE, 1990] aparece la siguiente definición de análisis de requerimientos que, tal como se propone en [POH, 1997], puede interpretarse como otra definición de ingeniería de requerimientos: Ingeniería de requerimientos (4): (a) el proceso de estudiar las necesidades del usuario para llegar a una definición de requerimientos de sistema, hardware o software. (b) el proceso de estudiar y refinar los requerimientos de sistema, hardware o software. Por lo tanto, la Ingeniería de Requerimientos puede considerarse como un proceso de descubrimiento y comunicación de las necesidades de clientes y usuarios y la gestión de los cambios en dichas necesidades. En palabras de F. P. Brooks [Brooks 1995, pág. 199]: "La parte más difícil de construir de un sistema software es decidir qué construir. [...] Ninguna otra parte del trabajo afecta más negativamente al sistema final si se realiza de manera incorrecta. Ninguna otra parte es más difícil de rectificar después.Los avances tecnológicos hacen que se empiecen a comercializar los primeros equipos y esto requiere mayor complejidad en la construcción de software. Crisis del software: término utilizado por primera vez en la conferencia organizada por la Comisión de Ciencia de la OTAN en Garmisch, Alemania, en octubre de 1968, para designar la gran cantidad de problemas que presentaba (y aún presenta) el desarrollo de software y el alto índice de fracasos en los proyectos de desarrollo. ¿Qué podía hacerse ante una situación en la que los proyectos software tenían un alto riesgo de fracasar? La respuesta parecía obvia: construir software de forma similar a como se construye hardware, aviones, barcos, puentes o edificios, es decir, aplicar los métodos de la ingeniería a la construcción de software. Ingenieria de Software: …como la aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software. Otra definición dice: la aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios. Ingenieria de Requerimientos? La ingeniería del software comprende una serie de actividades lo suficientemente diversas como para poder considerar la necesidad de otras ingenierías dentro de la propia ingeniería del software. La ingeniería de requerimientos es todavía una disciplina joven en la que aún no se han definido claramente la terminología, los procesos ni los productos. En [IEEE, 1990] aparece la siguiente definición de análisis de requerimientos que, tal como se propone en [POH, 1997], puede interpretarse como otra definición de ingeniería de requerimientos: Ingeniería de requerimientos (4): (a) el proceso de estudiar las necesidades del usuario para llegar a una definición de requerimientos de sistema, hardware o software. (b) el proceso de estudiar y refinar los requerimientos de sistema, hardware o software. Por lo tanto, la Ingeniería de Requerimientos puede considerarse como un proceso de descubrimiento y comunicación de las necesidades de clientes y usuarios y la gestión de los cambios en dichas necesidades. En palabras de F. P. Brooks [Brooks 1995, pág. 199]: "La parte más difícil de construir de un sistema software es decidir qué construir. [...] Ninguna otra parte del trabajo afecta más negativamente al sistema final si se realiza de manera incorrecta. Ninguna otra parte es más difícil de rectificar después.

5. www.prosyde.com EL PROBLEMA Es dar respuesta a… Usuarios, Auditorias, Certificaciones, Emergencias, Reingeniería, Cierre de proyecto, Cambio de plataforma…, etc. …como dar respuesta a un usuario, si no tenemos especificaciones aceptadas por él. Tenemos normalmente una idea y el tiene un “…yo asumí que vos..”. …como dar respuesta a la Auditoria que nos pide información que requería un mantenimiento… que por el día a día no pudimos realizar..? …como dar respuesa a los requerimientos necesarios para lograr una Certificación, si no tenemos organizado lo que día a día nos insume tiempo que acorta y acota el desarrollo…? …como dar respuesta a las guardias de desarrolladores que deben dar rápida respuesta pero que tienen a su vez, el ingreso más restringido por razones de seguridad…? …como dar respuesta a los proyectos de reingenieria, si tenemos que bucear en el código directamente para poder responder a preguntas básicas que nos exponen como improvisados… o por lo menos… con soporte inadecuado? …como justificar el cierre de un proyecto… si el alcance es subjetivo… esto implica muchas veces… ver alejarse el cobro de la última factura… …como realizar con seguridad un cambio de plataforma… aunque ese cambio sea asignado a un proveedor que por supuesto va a poner de manifiesto… todas nuestras debilidades en lo que hace a organización..? …como dar respuesta a un usuario, si no tenemos especificaciones aceptadas por él. Tenemos normalmente una idea y el tiene un “…yo asumí que vos..”. …como dar respuesta a la Auditoria que nos pide información que requería un mantenimiento… que por el día a día no pudimos realizar..? …como dar respuesa a los requerimientos necesarios para lograr una Certificación, si no tenemos organizado lo que día a día nos insume tiempo que acorta y acota el desarrollo…? …como dar respuesta a las guardias de desarrolladores que deben dar rápida respuesta pero que tienen a su vez, el ingreso más restringido por razones de seguridad…? …como dar respuesta a los proyectos de reingenieria, si tenemos que bucear en el código directamente para poder responder a preguntas básicas que nos exponen como improvisados… o por lo menos… con soporte inadecuado? …como justificar el cierre de un proyecto… si el alcance es subjetivo… esto implica muchas veces… ver alejarse el cobro de la última factura… …como realizar con seguridad un cambio de plataforma… aunque ese cambio sea asignado a un proveedor que por supuesto va a poner de manifiesto… todas nuestras debilidades en lo que hace a organización..?

6. www.prosyde.com OBJETIVO Minimizar efectos negativos Convencer en lugar de ordenar Adaptar el método a la necesidad Asociar en lugar de culpar Solucionar en lugar de dar excusas MEN: respecto a la certeza de los requerimientos, al costo del desarrollo, a la generación y ejecución de pruebas… individuales, de integración y de usuarios. CLO: el solo hecho de recibir una orden, predispone al primer estadío… puedo zafar? …el pedir por favor, minimiza el efecto negativo, pero lo que lo evita, es el convencimiento que me ahorra… al menos, esfuerzo de mi parte. AMN: los metodólogos (especie en franca expansión…), realizan sus propuestas basados en las mejores prácticas… hasta allí, excelente… pero las mejores prácticas de quien..? En que contexto…? Tengo la posibilidad de lograr con mis recursos lo que hacen en la casa matriz con todos los recursos que tienen…? ALC: convengamos que salvo en las familiares, rara vez hace falta llamar a los cuadros superiores para sacarse la foto… si hay un logro, pero si hay un problema… 4x4 con fondo blanco… para evitar eso, es necesario asociarse al usuario, integrar sus conceptos y sobretodo, permitirle que acceda a verlos especificados antes que se desarrollen… que se sienta parte… desde y hasta… no “porque”… algo no funcionó. SLDE: no importa la cantidad y calidad de documentación.. vinculante o probatoria, incriminatoria o no, lo real… es que ante una falla, los que se van a quedar sin dormir para solucionar el tema… son los integrantes del depto.de sistemas… así que es mejor revisar antes que acumular pruebas a favor.MEN: respecto a la certeza de los requerimientos, al costo del desarrollo, a la generación y ejecución de pruebas… individuales, de integración y de usuarios. CLO: el solo hecho de recibir una orden, predispone al primer estadío… puedo zafar? …el pedir por favor, minimiza el efecto negativo, pero lo que lo evita, es el convencimiento que me ahorra… al menos, esfuerzo de mi parte. AMN: los metodólogos (especie en franca expansión…), realizan sus propuestas basados en las mejores prácticas… hasta allí, excelente… pero las mejores prácticas de quien..? En que contexto…? Tengo la posibilidad de lograr con mis recursos lo que hacen en la casa matriz con todos los recursos que tienen…? ALC: convengamos que salvo en las familiares, rara vez hace falta llamar a los cuadros superiores para sacarse la foto… si hay un logro, pero si hay un problema… 4x4 con fondo blanco… para evitar eso, es necesario asociarse al usuario, integrar sus conceptos y sobretodo, permitirle que acceda a verlos especificados antes que se desarrollen… que se sienta parte… desde y hasta… no “porque”… algo no funcionó. SLDE: no importa la cantidad y calidad de documentación.. vinculante o probatoria, incriminatoria o no, lo real… es que ante una falla, los que se van a quedar sin dormir para solucionar el tema… son los integrantes del depto.de sistemas… así que es mejor revisar antes que acumular pruebas a favor.

7. www.prosyde.com MARCO TEÓRICO INGENIERÍA DE SOFTWARE SISTEMAS EXPERTOS

8. www.prosyde.com INGENIERÍA DE SOFTWARE La Ingeniería de Software es la disciplina encargada del desarrollo de un producto de software a bajo costo y alto rendimiento. Es la aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios. Al estudiar sobre la materia de Ingeniería de Software se observó que en la actualidad, la documentación de software tiene insuficiente importancia, contando con pocas herramientas de soporte tecnológico, lo cual causa un efecto en la institución u organización provocando demora de tiempo y costos que podrían haberse evitado elaborando una correcta documentación del software, es de ahí que nace de la inquietud de poder ofrecer un sistema que estimule realizar una correcta documentación de software. Al estudiar sobre la materia de Ingeniería de Software se observó que en la actualidad, la documentación de software tiene insuficiente importancia, contando con pocas herramientas de soporte tecnológico, lo cual causa un efecto en la institución u organización provocando demora de tiempo y costos que podrían haberse evitado elaborando una correcta documentación del software, es de ahí que nace de la inquietud de poder ofrecer un sistema que estimule realizar una correcta documentación de software.

9. www.prosyde.com SISTEMAS EXPERTOS Están basados en probabilidades y en reglas. Todavía no abarcan toda la problemática de documentación Específicos que generan desde el código, las pruebas de comportamiento. Los sistemas expertos son llamados así porque emulan el comportamiento de un experto en un dominio concreto y en ocasiones son usados por ellos. Con los sistemas expertos se busca una mejor calidad y rapidez en las respuestas dando así lugar a una mejora de la productividad del experto.Los sistemas expertos son llamados así porque emulan el comportamiento de un experto en un dominio concreto y en ocasiones son usados por ellos. Con los sistemas expertos se busca una mejor calidad y rapidez en las respuestas dando así lugar a una mejora de la productividad del experto.

10. www.prosyde.com MARCO PRÁCTICO NECESIDAD vs. URGENCIA RECOLECCION DE DATOS (REQUERIMIENTO) DISEÑO DEL SISTEMA CONSTRUCCION VALIDACION Y PRUEBA

11. www.prosyde.com NECESIDAD vs. URGENCIA Mercado Fusiones Entidades regulatorias Decisiones incuestionables Mercado La competencia hace que las decisiones rara vez pasen por una consulta previa a Sistemas, lo normal es tomar el compromiso y después pedir el esfuerzo. Fusiones Implican el desafío de competir en eficiencia para poder seguir en la línea. Muchas veces la prolijidad demostrada inclina una balanza. Entidades regulatorias Generadoras de desarrollos urgentes con fechas límite a cumplir. Saber que tocar y cuando es invaluable cuando se debe lidiar con estas entidades, entiéndase Banco Central, SuperIntendencia de Seguros, SuperIntendencia de AFJP. Decisiones incuestionables Aquellas emanadas del dueño o directorio de la Empresa, por funestas que resulten, deben realizarse y hay que estar preparados para ellas.Mercado La competencia hace que las decisiones rara vez pasen por una consulta previa a Sistemas, lo normal es tomar el compromiso y después pedir el esfuerzo. Fusiones Implican el desafío de competir en eficiencia para poder seguir en la línea. Muchas veces la prolijidad demostrada inclina una balanza. Entidades regulatorias Generadoras de desarrollos urgentes con fechas límite a cumplir. Saber que tocar y cuando es invaluable cuando se debe lidiar con estas entidades, entiéndase Banco Central, SuperIntendencia de Seguros, SuperIntendencia de AFJP. Decisiones incuestionables Aquellas emanadas del dueño o directorio de la Empresa, por funestas que resulten, deben realizarse y hay que estar preparados para ellas.

12. www.prosyde.com RECOLECCION DE DATOS Requerimientos Relevamiento Análisis Validación Otros modelos de procesos Pohl Swebok (Software Engineering Body of Knowledge) REAIMS (Requirements Engineering adaptation and improvement for safety and dependability) La Ingeniería de Requerimientos se divide en tres etapas: relevamiento, análisis y validación de requerimientos. Relevamiento de requisitos interacción entre clientes y usuarios e ingenieros Objetivos Conocer el dominio del problema Descubrir las necesidades reales de clientes y usuarios: además de aquellas necesidades explícitamente manifestadas por los clientes y usuarios, es muy importante llegar a descubrir el conocimiento tácito, es decir, aquellas necesidades que la mayor parte de las veces se asumen y toman por implícitas. Consensuar los requisitos entre los propios clientes y usuarios: puede que distintos grupos de clientes y usuarios presenten distintas necesidades que sean contradictorias entre sí. Durante el relevamiento, normalmente después de la primera iteración, es necesario negociar entre los distintos participantes hasta obtener una visión común de los requisitos. Otros autores [Pohl 1997, Sawyer y Kontoya 1999] separan las actividades de negociación de las de elicitación. En nuestra opinión, preferimos un modelo de procesos más sencillo en el que la elicitación englobe también los aspectos de negociación, dado que la negociación puede entenderse como la elicitación de la información necesaria para llegar a un acuerdo y además suelen aparecer nuevos requisitos cuando es necesario negociar. En cualquier caso, ambas actividades requieren reuniones entre los participantes involucrados en las que predominan los aspectos sociales sobre los técnicos. Análisis de requisitos: Objetivos Detectar conflictos en los requisitos Profundizar en el conocimiento del dominio del problema Establecer las bases para el diseño Validación de Requisitos Asegurarse de que los requisitos describen el producto deseado, de forma que se evite la situación en la que el producto final, que puede ser técnicamente correcto, no es satisfactorio. La Ingeniería de Requerimientos se divide en tres etapas: relevamiento, análisis y validación de requerimientos. Relevamiento de requisitos interacción entre clientes y usuarios e ingenieros Objetivos Conocer el dominio del problema Descubrir las necesidades reales de clientes y usuarios: además de aquellas necesidades explícitamente manifestadas por los clientes y usuarios, es muy importante llegar a descubrir el conocimiento tácito, es decir, aquellas necesidades que la mayor parte de las veces se asumen y toman por implícitas. Consensuar los requisitos entre los propios clientes y usuarios: puede que distintos grupos de clientes y usuarios presenten distintas necesidades que sean contradictorias entre sí. Durante el relevamiento, normalmente después de la primera iteración, es necesario negociar entre los distintos participantes hasta obtener una visión común de los requisitos. Otros autores [Pohl 1997, Sawyer y Kontoya 1999] separan las actividades de negociación de las de elicitación. En nuestra opinión, preferimos un modelo de procesos más sencillo en el que la elicitación englobe también los aspectos de negociación, dado que la negociación puede entenderse como la elicitación de la información necesaria para llegar a un acuerdo y además suelen aparecer nuevos requisitos cuando es necesario negociar. En cualquier caso, ambas actividades requieren reuniones entre los participantes involucrados en las que predominan los aspectos sociales sobre los técnicos. Análisis de requisitos: Objetivos Detectar conflictos en los requisitos Profundizar en el conocimiento del dominio del problema Establecer las bases para el diseño Validación de Requisitos Asegurarse de que los requisitos describen el producto deseado, de forma que se evite la situación en la que el producto final, que puede ser técnicamente correcto, no es satisfactorio.

13. www.prosyde.com …para considerar…

14. www.prosyde.com DISEÑO DEL SISTEMA Metodologías Ninguna Académicas Antiguas Modernas Agiles XP Scrum TDD Ninguna: es la más conocida y utilizada, requiere urgencia y complicidad. Antiguas: relevamiento, especificación, construcción, prueba, instalaciòn y mucho… mantenimiento. En base a procesos y comprobantes existentes DFD, etc. Estructuradas (Modelizaciòn) Modernas: Orientadas a objetos (comprenden nuevas tecnologias, lenguaje universal de modelado, requieren capacitación y compromiso). Agiles: XP (Extreme Programming) un teclado, un mouse, dos desarrolladores, su base, la comunicación, rotación y participación, la vuelta al equipo. Scrum igual que XP pero acelera tiempos, menos rotación con inicio de jornada en tertulia (de pie), para comunicar lo hecho y por hacer. TDD (Test Driven Development, (desarrollo dirigido por pruebas), el cambio no solo es posible, sino deseable), gira alrrededor de tres actividades: escribir casos de prueba, escribir código que pase las pruebas y una vez pasadas, reescribirlo para optimizarlo. Porque se llega esta Metodología? Porque las formales, igualmente dejan resultados negativos quienes las practican… o son gurues informáticos o son jóvenes con sobrante de adrenalina. No es muy posible que un responsable pago, se arriesgue.Ninguna: es la más conocida y utilizada, requiere urgencia y complicidad. Antiguas: relevamiento, especificación, construcción, prueba, instalaciòn y mucho… mantenimiento. En base a procesos y comprobantes existentes DFD, etc. Estructuradas (Modelizaciòn) Modernas: Orientadas a objetos (comprenden nuevas tecnologias, lenguaje universal de modelado, requieren capacitación y compromiso). Agiles: XP (Extreme Programming) un teclado, un mouse, dos desarrolladores, su base, la comunicación, rotación y participación, la vuelta al equipo. Scrum igual que XP pero acelera tiempos, menos rotación con inicio de jornada en tertulia (de pie), para comunicar lo hecho y por hacer. TDD (Test Driven Development, (desarrollo dirigido por pruebas), el cambio no solo es posible, sino deseable), gira alrrededor de tres actividades: escribir casos de prueba, escribir código que pase las pruebas y una vez pasadas, reescribirlo para optimizarlo. Porque se llega esta Metodología? Porque las formales, igualmente dejan resultados negativos quienes las practican… o son gurues informáticos o son jóvenes con sobrante de adrenalina. No es muy posible que un responsable pago, se arriesgue.

15. www.prosyde.com CONSTRUCCION Artesanal Paso a paso, on site. Software factory Organización para resultados Teletrabajo Globalización Economía

16. www.prosyde.com VALIDACION Y PRUEBA Importancia Dedicación Participación

17. www.prosyde.com COSTO - BENEFICIO DETERMINACIÓN DE COSTOS ESTIMACIÓN DE BENEFICIOS ANÁLISIS COSTO BENEFICIO

18. www.prosyde.com DETERMINACIÓN DE COSTOS Evidentes Económicos Políticos Ocultos Velocidad de reacción Disponibilidad de recursos Actualización …nos referimos a costos de documentación… Evidentes Económicos… si no documento, puedo invertir en otra cosa la partida asignada, eso si tuviera una partida asignada a documentación. Lo normal es que no exista. La documentación se infiere como parte del desarrollo y se tapa con el diseño (desactualizado en el mejor de los casos), el agujero documental. Políticos… son mis pares y superiores quienes van a sufrir antes… que sus clientes internos ó externos, quien seguro va a sufrir el costo final es Sistemas. Ocultos Cancelaciones y eventualidades disparan la cubrir la necesidad. Quintas con propietarios de los que se depende casi totalmente. Genera normalmente compromisos de difícil cumplimiento por desconocimiento. Actualización de plataformas… (Ej. S/36 en entorno AS/400)…nos referimos a costos de documentación… Evidentes Económicos… si no documento, puedo invertir en otra cosa la partida asignada, eso si tuviera una partida asignada a documentación. Lo normal es que no exista. La documentación se infiere como parte del desarrollo y se tapa con el diseño (desactualizado en el mejor de los casos), el agujero documental. Políticos… son mis pares y superiores quienes van a sufrir antes… que sus clientes internos ó externos, quien seguro va a sufrir el costo final es Sistemas. Ocultos Cancelaciones y eventualidades disparan la cubrir la necesidad. Quintas con propietarios de los que se depende casi totalmente. Genera normalmente compromisos de difícil cumplimiento por desconocimiento. Actualización de plataformas… (Ej. S/36 en entorno AS/400)

19. www.prosyde.com ESTIMACIÓN DE BENEFICIOS Optimizable Auditable Certificable Dinámico …del software documentado, frente a uno no documentado… Optimizable Quien en su sano juicio, se embarcaría en optimizar algo que funciona (razonablemente), para transformarlo en algo que fuincione mejor… sin respaldo de documentación adecuada? Auditable Implica mínima erogación de tiempo de recursos ante una Auditoria, consideremos la aparición de SOX, la globalización… todo eso hace que el sillón donde me podía abulonar… se transforme en “virtual” por una decisión tomada a miles de quilómetros o a metros si me faltan argumentos. Certificable No depende de nosotros decidir certificar o no. Si depende de nuestro esfuerzo que lo podamos lograr. Una instalación documentada adecuadamente, tiene un costo menos que considerar. Dinámico Cambios o eventos no planificados, no obligan a reagrupar esfuerzos de investigación en código. La lectura para la generación de diagnósticos es posible.…del software documentado, frente a uno no documentado… Optimizable Quien en su sano juicio, se embarcaría en optimizar algo que funciona (razonablemente), para transformarlo en algo que fuincione mejor… sin respaldo de documentación adecuada? Auditable Implica mínima erogación de tiempo de recursos ante una Auditoria, consideremos la aparición de SOX, la globalización… todo eso hace que el sillón donde me podía abulonar… se transforme en “virtual” por una decisión tomada a miles de quilómetros o a metros si me faltan argumentos. Certificable No depende de nosotros decidir certificar o no. Si depende de nuestro esfuerzo que lo podamos lograr. Una instalación documentada adecuadamente, tiene un costo menos que considerar. Dinámico Cambios o eventos no planificados, no obligan a reagrupar esfuerzos de investigación en código. La lectura para la generación de diagnósticos es posible.

20. www.prosyde.com ANÁLISIS COSTO BENEFICIO Requerimientos Diseño Construcción Prueba Instalación Mantenimiento Migración Requerimientos: 1 dólar en etapa de generación del requerimiento, significa entre 65 y 100, en etapa de Mantenimiento. Diseño: Mejora en tiempo de generación y comprobación Construcción: Permite alternativas para evaluación, puede variar entre Interna, Externa, Fábrica de Software, llave en mano. Prueba: Verificación y validación, integridad. Instalación: Minimizar la aparición de defectos, capacitación adecuada y efectiva. Mantenimiento: Desarrollo de políticas, organización, medición de stress del software, etc. Migración: Plantea base cierta para la toma de decisiones y produce ahorro en los tiempos de relevamiento. Requerimientos: 1 dólar en etapa de generación del requerimiento, significa entre 65 y 100, en etapa de Mantenimiento. Diseño: Mejora en tiempo de generación y comprobación Construcción: Permite alternativas para evaluación, puede variar entre Interna, Externa, Fábrica de Software, llave en mano. Prueba: Verificación y validación, integridad. Instalación: Minimizar la aparición de defectos, capacitación adecuada y efectiva. Mantenimiento: Desarrollo de políticas, organización, medición de stress del software, etc. Migración: Plantea base cierta para la toma de decisiones y produce ahorro en los tiempos de relevamiento.

21. www.prosyde.com CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES RECOMENDACIONES No por obvias… dejan de ser necesarias… Sin embargo, permitanme tener una posición fatalista sobre este tema… es un poco como el cigarrillo, el HIV, el matrimonio… muchos son los que advierten… los advertidos asienten… “puede pasar”, pero igualmente… “corren el riesgo…” La pregunta es… sirve para algo el riesgo..? me genera algo trascendente que lo va a justificar si se materializa? …seamos justos, en el matrimonio si, más allá de la decisión que no es casualidad… los hijos que llegan valen el riesgo… pero en el cigarrillo, el HIV y la documentación… ? En los dos primeros nos va la vida… en el tercero… nos puede ir el puesto… y nuestra tranquilidad familiar a partir de ese infortunio, si se diera la situación… yo preguntaria porque? Yo no tenia la plata para hacerlo..? …no, no es “mi” plata… no tenia recursos para asignar a un proyecto de este tipo… pero cuando aprietan de arriba… pido esfuerzo y tengo recursos… estirados los actuales o nuevos… depende …pero vamos a las conclusiones…No por obvias… dejan de ser necesarias… Sin embargo, permitanme tener una posición fatalista sobre este tema… es un poco como el cigarrillo, el HIV, el matrimonio… muchos son los que advierten… los advertidos asienten… “puede pasar”, pero igualmente… “corren el riesgo…” La pregunta es… sirve para algo el riesgo..? me genera algo trascendente que lo va a justificar si se materializa? …seamos justos, en el matrimonio si, más allá de la decisión que no es casualidad… los hijos que llegan valen el riesgo… pero en el cigarrillo, el HIV y la documentación… ? En los dos primeros nos va la vida… en el tercero… nos puede ir el puesto… y nuestra tranquilidad familiar a partir de ese infortunio, si se diera la situación… yo preguntaria porque? Yo no tenia la plata para hacerlo..? …no, no es “mi” plata… no tenia recursos para asignar a un proyecto de este tipo… pero cuando aprietan de arriba… pido esfuerzo y tengo recursos… estirados los actuales o nuevos… depende …pero vamos a las conclusiones…

22. www.prosyde.com CONCLUSIONES Aquí, el tamaño no es significativo… Diseñar… no es documentar Documentar… no sirve… Ser oveja no solo es tener lana… EL TAMAÑO… porque sin importar la dimensión de la Empresa, el problema de la documentación esta presente en casi todas. DISEÑAR… el diseño es interpretado por los especialistas… no se actualiza, no se compromete con las pruebas, no nos permite evaluar el stress del software. DOCUMENTAR …si se hace para cumplir… en lugar de hacerse para que se utilice. Todo esfuerzo destinado a disfrazar una realidad, solo sirve a quien lo hace, porque para el resto, la realidad es el disfraz. Esforzarse para uno mismo es válido en lo personal y espiritual, dibujar para el ambiente laboral es perder tiempo y esfuerzo. SER OVEJA…también es aceptar lo que nos mandan desde el norte… invertir esfuerzo en utilizarlo y saber al hacerlo que no nos aporta absolutamente nada más que un esfuerzo que después nos va a generar mayor esfuerzo aún. Pensemos también que no podemos decir NO, si podemos tener alternativas, válidas.EL TAMAÑO… porque sin importar la dimensión de la Empresa, el problema de la documentación esta presente en casi todas. DISEÑAR… el diseño es interpretado por los especialistas… no se actualiza, no se compromete con las pruebas, no nos permite evaluar el stress del software. DOCUMENTAR …si se hace para cumplir… en lugar de hacerse para que se utilice. Todo esfuerzo destinado a disfrazar una realidad, solo sirve a quien lo hace, porque para el resto, la realidad es el disfraz. Esforzarse para uno mismo es válido en lo personal y espiritual, dibujar para el ambiente laboral es perder tiempo y esfuerzo. SER OVEJA…también es aceptar lo que nos mandan desde el norte… invertir esfuerzo en utilizarlo y saber al hacerlo que no nos aporta absolutamente nada más que un esfuerzo que después nos va a generar mayor esfuerzo aún. Pensemos también que no podemos decir NO, si podemos tener alternativas, válidas.

23. www.prosyde.com RECOMENDACIONES Considere la documentación del software como parte de sus objetivos. Si no tiene recursos, contrátelos. Si no tiene arquitectura formal, obténgala. Evalúe alternativas, hay varias y todas posibles.

24. www.prosyde.com Bibliografia… [Booch et al. 1999] G. Booch, J. Rumbaugh, y I. Jacobson. The Unified Modeling Language User Guide. Addison–Wesley, 1999. [Pohl 1997] K. Pohl. Requirements Engineering: An Overview. Encyclopedia of Computer Science and Technology, 36, 1997. Disponible en http://sunsite.informatik.rwth-aachen.de/CREWS/reports96.htm. [Potts et al. 1994a] C. Potts, K. Takahashi, y A. Anton. Inquiry–Based Requirements Analysis. IEEE Software, 11(2), 1994. [Thayer y Dorfman 1997] R. H. Thayer y M. Dorfman, editores. Software Requirements Engineering. IEEE Computer Society Press, 2a edición, 1997. Es la 2a edición de [Thayer y Dorfman 1990]. [Yourdon Inc. 1993] Yourdon Inc. Yourdon Systems Method: Model–Driven Systems Development. Prentice–Hall, 1993. Amador Durán Toro “Un Entorno Metodológico de Ingeniería de Requerimientos para Sistemas de Software”. [Prentice Hall. 2002] Shari Lawrence Pfleeger. Ingenieria de software - Teoría y practica. [Users.Code. 03/2006] Prueba de software, Metodologias Agiles

25. www.prosyde.com …gracias por su tiempo…

26. ANEXO

27. www.prosyde.com Resultados del Informe de GAO. Fuente: Government Account Office, [GAO, 1979]. Desde 1968 se ha invertido un gran esfuerzo en determinar las causas y proponer soluciones para la crisis del software. En 1979, la Oficina de Cuentas del Gobierno Norteamericano (Government Account Office, GAO) realizó un estudio [GAO, 1979] seleccionando nueve proyectos de desarrollo de software para el gobierno norteamericano cuyos contratos sumaban una cantidad total de 6.800.000 dólares. De esta cantidad, sólo 119.000 dólares correspondían a un proyecto que se había utilizado tal como se había entregado. Dicho proyecto se trataba de un pre-procesador de COBOL, por lo que era un problema relativamente simple cuyos requerimientos eran comprendidos por clientes y desarrolladores y que además no cambiaron durante el desarrollo. El resto de los 6.8 millones de dólares se distribuyeron como puede verse en esta figura, en la que puede destacarse el enorme porcentaje de dinero invertido en proyectos cancelados o no satisfactorios.Desde 1968 se ha invertido un gran esfuerzo en determinar las causas y proponer soluciones para la crisis del software. En 1979, la Oficina de Cuentas del Gobierno Norteamericano (Government Account Office, GAO) realizó un estudio [GAO, 1979] seleccionando nueve proyectos de desarrollo de software para el gobierno norteamericano cuyos contratos sumaban una cantidad total de 6.800.000 dólares. De esta cantidad, sólo 119.000 dólares correspondían a un proyecto que se había utilizado tal como se había entregado. Dicho proyecto se trataba de un pre-procesador de COBOL, por lo que era un problema relativamente simple cuyos requerimientos eran comprendidos por clientes y desarrolladores y que además no cambiaron durante el desarrollo. El resto de los 6.8 millones de dólares se distribuyeron como puede verse en esta figura, en la que puede destacarse el enorme porcentaje de dinero invertido en proyectos cancelados o no satisfactorios.

28. www.prosyde.com Resultados del informe CHAOS Fuente: Grupo Standish [TSG 1995] En 1995, el Grupo Standish realizó un estudio, el informe CHAOS, mucho más amplio y significativo que el del GAO cuyos resultados, a pesar de haber pasado más de 25 años, no reflejaban una mejoría sustancial [TSG, 1995]. Los resultados generales, que pueden verse en la figura 2, si se compara con los de [GAO, 1979] presentan una mejora en los proyectos que se entregan cumpliendo todos sus requerimientos, 2% frente al 16.2%, sólo el 9% en grandes compañías, pero empeoran ligeramente respecto a los que se abandonan durante el desarrollo, 28.7% frente a 31.1%. Sin incluir al 16.2% de los proyectos terminados correctamente, la media del gasto final fue del 189% del presupuesto original, el tiempo necesario para su realización del 222% del plazo original y se cumplieron una media del 61% de los requerimientos iniciales, cifras que también empeoraban en el caso de grandes compañías.En 1995, el Grupo Standish realizó un estudio, el informe CHAOS, mucho más amplio y significativo que el del GAO cuyos resultados, a pesar de haber pasado más de 25 años, no reflejaban una mejoría sustancial [TSG, 1995]. Los resultados generales, que pueden verse en la figura 2, si se compara con los de [GAO, 1979] presentan una mejora en los proyectos que se entregan cumpliendo todos sus requerimientos, 2% frente al 16.2%, sólo el 9% en grandes compañías, pero empeoran ligeramente respecto a los que se abandonan durante el desarrollo, 28.7% frente a 31.1%. Sin incluir al 16.2% de los proyectos terminados correctamente, la media del gasto final fue del 189% del presupuesto original, el tiempo necesario para su realización del 222% del plazo original y se cumplieron una media del 61% de los requerimientos iniciales, cifras que también empeoraban en el caso de grandes compañías.

29. www.prosyde.com Resultados del informe CHAOS(encuesta a los participantes) Éxito por… Usuarios involucrados Apoyo de los directivos Enunciado claro de los requerimientos Fracaso por… Falta de información por parte de los usuarios Especificaciones y requerimientos incompletos Especificaciones y requerimientos cambiantes Las encuestas realizadas a los directores de los proyectos que participaron en el estudio indicaron que, en su opinión, los tres principales factores de éxito eran: Involucración de los usuarios Apoyo de los directivos Enunciado claro de los requerimientos Mientras que los tres principales factores de fracaso eran: Falta de información por parte de los usuarios Especificaciones y requerimientos incompletos Especificaciones y requerimientos cambiantes Las encuestas realizadas a los directores de los proyectos que participaron en el estudio indicaron que, en su opinión, los tres principales factores de éxito eran: Involucración de los usuarios Apoyo de los directivos Enunciado claro de los requerimientos Mientras que los tres principales factores de fracaso eran: Falta de información por parte de los usuarios Especificaciones y requerimientos incompletos Especificaciones y requerimientos cambiantes

30. www.prosyde.com Ingenieria de Software Informal principios probados Copy/Paste técnicas …quien fue el que hizo esto..? lenguajes …#@*€&$*@#…. herramientas para la creación y mantenimiento …fijate si hay algo en internet.. Dentro de un costo razonable …ponele “tanto” y después vemos….

31. www.prosyde.com Ingenieria de Software Informal software que satisfaga las necesidades de los usuarios. Software correcto: es aquel que hace lo que se supone que debe hacer. Software robusto: es aquel que responde aceptablemente en condiciones en las que no puede hacer lo previsto.Software correcto: es aquel que hace lo que se supone que debe hacer. Software robusto: es aquel que responde aceptablemente en condiciones en las que no puede hacer lo previsto.

32. Hace solo un momento… en algún lugar…comenzó una historia, …un ansioso oficial de marketing… tuvo una idea… que como toda idea desde marketing esta orientada a generar pingües ganancias… pero va necesitar todo el apoyo posible……un ansioso oficial de marketing… tuvo una idea… que como toda idea desde marketing esta orientada a generar pingües ganancias… pero va necesitar todo el apoyo posible…

33. www.prosyde.com como todas las historias… …pero no se queda en idea ni en èl… se eleva… se comparte con quienes deben presentar resultados para en definitiva… seguir manteniendo el lugar que ocupan…no?…pero no se queda en idea ni en èl… se eleva… se comparte con quienes deben presentar resultados para en definitiva… seguir manteniendo el lugar que ocupan…no?

34. www.prosyde.com que alguien entenderá… …puestos al tanto… arman un plan… definen todo lo que necesitan… y si tenemos suerte… antes de publicar la fecha de lanzamiento de lo que sea… SE LO VAN A COMUNICAR A SISTEMAS….!!!!…puestos al tanto… arman un plan… definen todo lo que necesitan… y si tenemos suerte… antes de publicar la fecha de lanzamiento de lo que sea… SE LO VAN A COMUNICAR A SISTEMAS….!!!!

35. www.prosyde.com bajarán lineas… que deberán… …aquí ya estamos en nuestro terreno… y en este terreno más que en ninguno… vamos a necesitar… DOCUMENTACION….!!!…aquí ya estamos en nuestro terreno… y en este terreno más que en ninguno… vamos a necesitar… DOCUMENTACION….!!!

36. www.prosyde.com Proceso propuesto…

37. www.prosyde.com Requerimientos (diez guías básicas) 1 Definir una estructura normalizada del documento de requerimientos. 2 Hacer el documento fácil de cambiar. 3 Identificar de manera única cada requerimiento. 4 Definir políticas para la gestión de requerimientos. 5 Definir plantillas normalizadas para la descripción de requerimientos. Para organizaciones sin ningún tipo de proceso de ingeniería de requisitos se proponen las siguientes diez guías básicas: 1 Definir una estructura normalizada del documento de requisitos. 2 Hacer el documento fácil de cambiar. 3 Identificar de manera única cada requisito. 4 Definir políticas para la gestión de requisitos. 5 Definir plantillas normalizadas para la descripción de requisitos. 6 Usar el lenguaje de forma simple, consistente y concisa. 7 Organizar revisiones formales de los requisitos. 8 Definir listas de comprobación para la validación. 9 Usar listas de comprobación para el análisis de los requisitos. 10 Planificar los conflictos y su resolución. Para organizaciones sin ningún tipo de proceso de ingeniería de requisitos se proponen las siguientes diez guías básicas: 1 Definir una estructura normalizada del documento de requisitos. 2 Hacer el documento fácil de cambiar. 3 Identificar de manera única cada requisito. 4 Definir políticas para la gestión de requisitos. 5 Definir plantillas normalizadas para la descripción de requisitos. 6 Usar el lenguaje de forma simple, consistente y concisa. 7 Organizar revisiones formales de los requisitos. 8 Definir listas de comprobación para la validación. 9 Usar listas de comprobación para el análisis de los requisitos. 10 Planificar los conflictos y su resolución.

38. www.prosyde.com Requerimientos (diez guías básicas) 6 Usar el lenguaje de forma simple, consistente y concisa. 7 Organizar revisiones formales de los requerimientos. 8 Definir listas de comprobación para la validación. 9 Usar listas de comprobación para el análisis de los requerimientos. 10 Planificar los conflictos y su resolución.

39. www.prosyde.com Prueba de software Objetivo Evitar que el error se convierta en defecto Descubrir en que etapas se producen mayor cantidad de errores El costo de no probar Ser improductivo Desperdiciar dinero Desconocer donde fallan nuestros métodos Objetivo Error es una falla en el proceso de desarrollo, defecto es el error detectado con posterioridad a la entrega. Consideremos que el requerimiento, también es una etapa. Un error de requerimiento se propaga en todo el desarrollo. El costo de no probar Corregir es no producir o por lo menos atrasar la producción. Es muy raro que en una etapa de desarrollo alguien produzca y otro corrija, lo habitual es que sea la misma persona en el mismo segmento de tiempo final que tiene asignado. De donde sale ese tiempo?, de sus horas de descanso o del presupuesto del equipo de desarrollo. Muchas veces se considera que hacer software es una actividad de costos reducidos, error, tiene los suficientes riesgos como para ser muy costoso. Ejemplo de manufactura de una pieza… el costo lo asociamos a la materia prima, al tiempo de mecanizado de la pieza y la mano de obra. Si hay un error en el diseño de la pieza, se pierde tiempo y mano de obra… se recupera la materia prima… pero en el desarrollo de software… que se recupera..? Consideremos que la actividad es intelectual, requiere tiempo… y ese componente… es irrecuperable. El tiempo transcurrido tiene valor… y ese valor es el principal costo de nuestra producción. Conocer donde nos equivocamos, nos permite saber donde se generan los costos indeseados. Probar estrategicamente un software, nos permite evitar la propagación del error a las etapas posteriores, nos permite ahorrar.Objetivo Error es una falla en el proceso de desarrollo, defecto es el error detectado con posterioridad a la entrega. Consideremos que el requerimiento, también es una etapa. Un error de requerimiento se propaga en todo el desarrollo. El costo de no probar Corregir es no producir o por lo menos atrasar la producción. Es muy raro que en una etapa de desarrollo alguien produzca y otro corrija, lo habitual es que sea la misma persona en el mismo segmento de tiempo final que tiene asignado. De donde sale ese tiempo?, de sus horas de descanso o del presupuesto del equipo de desarrollo. Muchas veces se considera que hacer software es una actividad de costos reducidos, error, tiene los suficientes riesgos como para ser muy costoso. Ejemplo de manufactura de una pieza… el costo lo asociamos a la materia prima, al tiempo de mecanizado de la pieza y la mano de obra. Si hay un error en el diseño de la pieza, se pierde tiempo y mano de obra… se recupera la materia prima… pero en el desarrollo de software… que se recupera..? Consideremos que la actividad es intelectual, requiere tiempo… y ese componente… es irrecuperable. El tiempo transcurrido tiene valor… y ese valor es el principal costo de nuestra producción. Conocer donde nos equivocamos, nos permite saber donde se generan los costos indeseados. Probar estrategicamente un software, nos permite evitar la propagación del error a las etapas posteriores, nos permite ahorrar.

40. www.prosyde.com Prueba de software La prueba Esencia de la prueba Fracaso de la prueba Éxito de la prueba Quien prueba? El autor Otro actor Intereses Cuando decimos… “estoy probando para ver si el software funciona bien”… estamos equivocando el concepto eso es antagónico al objetivo de la prueba. La esencia de la prueba es demostrar exactamente lo contrario. Cuando no encontramos errores, podemos decir que las etapas de desarrollo, fueron exitosas (diseño, construcción), pero la prueba fracasó.., no detecto errores… Una prueba es exitosa, cuando demuestra que el software funciona mal… El autor, normalmente esta muy emparentado con su creación y psicologicamente va a recorrer el camino correcto para evaluar su obra, por eso se constituyen “equipos” de prueba… lo malo es que son costosos… pero casi siempre mucho más efectivos… (ejemplo… no puso el Nro.de Cliente y pulso Enter, claro, canceló..!!! Los tiempos transcurridos, los compromisos, la factura pendiente… todo eso genera intereses que pueden afectar la prueba… seguramente.Cuando decimos… “estoy probando para ver si el software funciona bien”… estamos equivocando el concepto eso es antagónico al objetivo de la prueba. La esencia de la prueba es demostrar exactamente lo contrario. Cuando no encontramos errores, podemos decir que las etapas de desarrollo, fueron exitosas (diseño, construcción), pero la prueba fracasó.., no detecto errores… Una prueba es exitosa, cuando demuestra que el software funciona mal… El autor, normalmente esta muy emparentado con su creación y psicologicamente va a recorrer el camino correcto para evaluar su obra, por eso se constituyen “equipos” de prueba… lo malo es que son costosos… pero casi siempre mucho más efectivos… (ejemplo… no puso el Nro.de Cliente y pulso Enter, claro, canceló..!!! Los tiempos transcurridos, los compromisos, la factura pendiente… todo eso genera intereses que pueden afectar la prueba… seguramente.

41. www.prosyde.com Prueba de software Verificación vs. Validación Verificación Validación Equilibrio Tipos de prueba Caja blanca Caja negra Caja gris Las pruebas que verifican, intentan revisar si los resultados obtenidos se corresponden con los de la especificación técnica del sistema pero eso no garantiza que se ajuste a los requerimientos del solicitante. Las prueba que validan, intentan revisar los requerimientos estipulados tratando de garantizar que el software sea el correcto. En un buen esquema de prueba, debe existir un óptimo equilibrio entre verficaciones y validaciones para asegurar la rigurosidad técnica del producto y la satisfacción del solicitante. Tipos de prueba Caja blanca: es aquella donde participan entradas de diseño lógico y puede seguirse su transformación durante su procesamiento llegando a la observación de las salidas y permitiendo la comparación con la lógica esperada. Caja negra: participan también las entradas y se llega a la observación de las salidas, permitiendo la comparación con la lógica esperada pero no hay posibilidad de evaluar la transformación durante el procesamiento. Caja gris: un mix entre ambas. Solo se pueden evaluar algunos procesos de transformación, no todos. Las pruebas que verifican, intentan revisar si los resultados obtenidos se corresponden con los de la especificación técnica del sistema pero eso no garantiza que se ajuste a los requerimientos del solicitante. Las prueba que validan, intentan revisar los requerimientos estipulados tratando de garantizar que el software sea el correcto. En un buen esquema de prueba, debe existir un óptimo equilibrio entre verficaciones y validaciones para asegurar la rigurosidad técnica del producto y la satisfacción del solicitante. Tipos de prueba Caja blanca: es aquella donde participan entradas de diseño lógico y puede seguirse su transformación durante su procesamiento llegando a la observación de las salidas y permitiendo la comparación con la lógica esperada. Caja negra: participan también las entradas y se llega a la observación de las salidas, permitiendo la comparación con la lógica esperada pero no hay posibilidad de evaluar la transformación durante el procesamiento. Caja gris: un mix entre ambas. Solo se pueden evaluar algunos procesos de transformación, no todos.

42. www.prosyde.com Prueba de software Estrategias (niveles) Unidad Integración Validación Sistema Hasta cuando probar? Costo Conveniencia Probabilidades Estrategias Es la prueba de las unidades que componen un módulo ó sistema, sin la conexión de dicha unidad con las restantes. Integración, implica que el resultado de una Unidad, sea correcto para la siguiente, permite ver el acoplamiento entre los distintos módulos. Validación es confrontar los requerimientos del solicitante con lo que hace el software. Sistema apunta a los aspectos globales del desarrollo. Se verifican aspectos relacionados con a recuperación del sistema, la seguridad, la resistencia a la escalabilidad y el rendimiento. Hasta cuando probar? Aquí se presenta un problema… dijimos previamente que la prueba baja costos en función de evitar errores… bien, pero tambien dijimos que los equipos de prueba son costosos… asi que el hasta cuando… depende de cuanto cuesta… y nuestro presupuesto. Obviamente depende, en tanto y en cuanto tengamos claro que no probar no es sinónimo de instalar en situación crítica… La curva que se obtiene entre los fallos por hora de prueba y el tiempo de ejecución… es descendente… eso marca que después de un número aceptable de pruebas, las probabilidades de estar expuestos a errores… disminuyen. Estrategias Es la prueba de las unidades que componen un módulo ó sistema, sin la conexión de dicha unidad con las restantes. Integración, implica que el resultado de una Unidad, sea correcto para la siguiente, permite ver el acoplamiento entre los distintos módulos. Validación es confrontar los requerimientos del solicitante con lo que hace el software. Sistema apunta a los aspectos globales del desarrollo. Se verifican aspectos relacionados con a recuperación del sistema, la seguridad, la resistencia a la escalabilidad y el rendimiento. Hasta cuando probar? Aquí se presenta un problema… dijimos previamente que la prueba baja costos en función de evitar errores… bien, pero tambien dijimos que los equipos de prueba son costosos… asi que el hasta cuando… depende de cuanto cuesta… y nuestro presupuesto. Obviamente depende, en tanto y en cuanto tengamos claro que no probar no es sinónimo de instalar en situación crítica… La curva que se obtiene entre los fallos por hora de prueba y el tiempo de ejecución… es descendente… eso marca que después de un número aceptable de pruebas, las probabilidades de estar expuestos a errores… disminuyen.

43. www.prosyde.com Prueba de software Medir la calidad Siembra Formula Efectividad en la Detección de Errores (EDE) EDE= Para medir la calidad de la prueba, se utiliza un método que es la Siembra de Errores… …basicamente se plantan errores en las condiciones de prueba, para verificar si son detectados por los equipos de prueba. En base a ese método, se puede medir la EDE mediante una formula más que sencilla.Para medir la calidad de la prueba, se utiliza un método que es la Siembra de Errores… …basicamente se plantan errores en las condiciones de prueba, para verificar si son detectados por los equipos de prueba. En base a ese método, se puede medir la EDE mediante una formula más que sencilla.

44. www.prosyde.com Prueba de software Requisitos Trazabilidad Planificación Eficacia Realista Principio de Pareto Simplicidad Trazabilidad, porque una prueba debe permitir el seguimiento. Planificación, porque las pruebas no deben improvisarse. Eficacia, porque deben ser realizadas por un equipo capacitado para hacerlas. Realista, porque se debe evaluar qué se va a probar y determinar su posibilidad. Principio de Pareto, porque en el 20% de los componentes más suceptibles a poseer errores está el 80% de los errores. Ante un presupuesto limitado, se debe elegir muy bien que elementos someter a prueba profunda. Simplicidad, comenzar por lo pequeño y escalar hacia lo grande. Acotar los ambientes a revisables.Trazabilidad, porque una prueba debe permitir el seguimiento. Planificación, porque las pruebas no deben improvisarse. Eficacia, porque deben ser realizadas por un equipo capacitado para hacerlas. Realista, porque se debe evaluar qué se va a probar y determinar su posibilidad. Principio de Pareto, porque en el 20% de los componentes más suceptibles a poseer errores está el 80% de los errores. Ante un presupuesto limitado, se debe elegir muy bien que elementos someter a prueba profunda. Simplicidad, comenzar por lo pequeño y escalar hacia lo grande. Acotar los ambientes a revisables.

45. www.prosyde.com Prueba de software Es importante tener en cuenta que la prueba ayuda a mejorar la productividad y la calidad del producto, y pone en evidencia nuestras propias limitaciones en las actividades de desarrollo de sistemas. Bien entendidas, nos permiten perfeccionar nuestras técnicas y metodologías de producción de software. …bueno, nos despedimos de las pruebas con una reflexión… prestada… users.code …bueno, nos despedimos de las pruebas con una reflexión… prestada… users.code

46. www.prosyde.com DAS_Net(Documentación Activa del Software) Mail das.net@prosyde.com Web www.prosyde.com/dasnet (usuario: demo password: demo) Capacitación www.prosyde.com/campus (ingeniería de software) Idiomas disponibles al 01/09/2005 Castellano / Inglés / Portugués / Italiano Prosyde S.A. Argentina 54 11 4661 3162 54 (9) 4440 2800 Móvil Uruguay 598 2 309 1762 598 (94) 416 147 Móvil