450 likes | 644 Views
www.prosyde.com. GENERALIDADES. INTRODUCCIONEL PROBLEMAOBJETIVOS. www.prosyde.com. INTRODUCCION. Contexto histricoEl hardware es mucho ms caro que el software.El desarrollo del hardware es ms complejo que el del software.El hardware es poco fiable. Contexto actualTecnologa adecuada vs. U
E N D
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