Ingeniería de Software Educativo¿Para qué complicarnos si podemos hacerlo

fácil?

Escuela de Post-GradoDidácti ca y Tecnología de la Información

Mg. Juan Antonio CARBAJAL MAYHUA

SensibilizaciónJuan Antonio Carbajal Mayhua

El por qué de esta cátedra

La ingeniería de software y la calidad

nos resultan temas apasionantes…

Ser humanamente responsable

nos resulta un reto

Intentar hacer las dos primeras sin la última

es claramente un despropósito

Con esta cátedra no pretendemos enseñarle a ser “humanamente

responsable”

Lo único que queremos es darle algunas ideas de “por qué

debería serlo” si se dedica usted al tema de

“hacer software”

¿Qué es Ingeniería de Software?

Busquemos una definición

La Ingeniería de Software es la aplicación práctica del conocimiento científico en el diseño y construcción

de programas de computadora y la documentación asociada requerida

para construirlos, operarlos y mantenerlos.

Bohem - 1976.

Ingeniería del Software es el estudio de los principios y

metodologías para desarrollo y mantenimiento de sistemas de

software.

Zelkovitz - 1978

La Ingeniería de Software es la aplicación de un enfoque

sistemático, disciplinado, y cuantificable al desarrollo,

operación, y mantenimiento del software.

IEEE - 1993.

Ingeniería de software es la disciplina o área de la informática

que ofrece métodos y técnicas para desarrollar y mantener software de

calidad.

Wikipedia

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_del_software

Todo eso parece un concepto muy

elevado para algo que parece ser tan simple como

“hacer software”

Si, es cierto…

Es tan simple que puedes aprenderlo en internet, incluso trabajar en ello y ganar mucho más, que muchos de los que estudian física, matemáticas y ética…

¡Ups!...

Un momento, nadie dijo que lo hicieras bien, solo que también

podías hacerlo, hacer lo simple…

y… ¿Por qué conformarse con eso?

Quizá la Ingeniería de Software no tiene tantos años como la física, matemáticas o

arquitectura…

Pero créanos, tampoco se la inventaron ayer…

Se han preguntado alguna vez

¿Dónde hay software?

Para empezar a entender todo estohagamos una pequeña reflexión

¿Quién es un ingeniero de software?

En esta cátedra, cuando hablamos de un ingeniero de software no

hablamos de un ingeniero titulado, hablamos de una persona involucrada

en el proceso de construcción de cualquier

producto de software…

¡Hablamos de usted!

¿Lo duda?

Veamos que tanto lo involucra todo esto

Intente responder un par de preguntas típicas

¿Iría en un viaje alrededor de la tierra en globo,

sabiendo que este esta controlado

por una computadora?

¿Viajaría usted en un avión cuyo software ha sido construido por

usted?

Si estas preguntas le producen un tanto de

risa o duda, lo invitamos a

replantearse…

El tema de que nuestra profesión sea un chiste, ha sido comparado con

este video:

¿Qué pasaría si los programadores construyeran

aviones?http://www.youtube.com/watch?v=UZq4sZz56qM

Gracioso ¿No?

¡Pues NO!

No es gracioso que siendo un profesional tu trabajo sea tomado en broma…

El problema es

¿Qué pasa si nosotros mismos nos

tomamos nuestro trabajo en broma?

Comparemos…

¿Dudan los enfermos del

corazón de sus médicos

cirujanos?

¿Dudan los empresarios de los ingenieros civiles y

arquitectos que construyen sus

edificios?

¿Dudan los acusados del abogado que defenderá su inocencia?

¿Dudan las personas de los contadores que

les ayudan a llevar sus finanzas?

¿Dudas de ti? ¿Dudas de tu equipo de

trabajo?

Esto es una invitación a cuestionarse

La ingeniería de software es una idea casi ética (no solo ética) de como hacer el software de forma correcta (software de

calidad)

Aquí va una propuesta de una definición menos formal

Y hacer las cosas bien, siempre va a requerir un poco más de esfuerzo, que hacerlas de

cualquier otro modo

No hacerlo, siempre va a tener consecuencias…

¿Qué consecuencias?

¿Acaso en software no importa es básicamente que

funcione?

Veamos algunas respuestas a esa pregunta…

(Ojo, las siguientes imagenes son meramente ilustrativa, no todas pertenecen al hecho descrito)

Therac-25 (1985 – 1987)

Era una máquina empleada en terapia de radiación, producida por Atomic Energy of Canada Limited, notoria por haber sido objeto del error de software, causando al menos seis accidentes y que le costó la vida al menos a cinco personas

Mariner 1(28 de Julio de 1962)

Un guión en las instrucciones del programa de guiado del cohete provocó la desviación del Atlas y tuvo que enviarse un comando para su autodestrucción a los 4 minutos y 53 segundos de su lanzamiento

Vuelo 501 del ARIANE-5

(4 de Junio de 1996)

Otro ejemplo documentado sobre el daño ocasionado por software mal

diseñado es el de la explosión de la lanzadera Ariane-5, cuando a 40

segundos después de la iniciación de la secuencia de vuelo, la

lanzadera se desvió de su ruta, se partió y explotó. En el proyecto global se invirtieron 10 años de

construcción y 7 mil millones de euros, lo que supuso un duro golpe

para la Agencia Espacial Europea (ESA)

http://www.youtube.com/watch?v=IONcgYzVFlg

A-320 de Air France(26 de junio de 1988)

Durante una presentación en el meeting de Habsheim, cerca de

Mulhouse (Francia), un A-320 de Air France se estrella en el bosque, al

final de la pista. Habrá tres muertos y una centena de heridos.

Justo después, el mundo se pregunta las causas del accidente del avión anunciado como "el más

seguro del mundo".

Una de las causas se le atribuye a un error en el software de

navegación

http://www.youtube.com/watch?v=_EM0hDchVlY

¿Qué tal las

respuestas?

¡Nada agradables si me permiten

decirles!

Pues bien, aunque actualmente existen muchas personas que construyen

software con conocimiento empírico, tal como si fuera arte, lo que debe diferenciar un trabajo bien hecho

(profesional o empírico), es los métodos y la evidente forma de hacer el trabajo teniendo en mente la calidad de los

procesos ejecutados y de los productos desarrollados.

Usemos otra analogía para entenderde que estamos hablando…

Si una edificación fuera nuestro proyecto…

¿Qué necesitaríamos para construirlo?

Veamos…

HerramientasPersonasTiempoDinero

RecursosEstrategia

Parece intuitivo ¿No?

Sin embargo sabemos que en realidad, es un poco más difícil de

lo que imaginamos

Pues bien lo mismo sucede con la construcción de software…

Para desarrollar software existen una serie de roles asociados,

encargados de analizar, planificar y establecer, qué es lo que va a desarrollarse, cómo, con cuantos recursos, en cuanto tiempo e

incluso a que nivel de calidad, es lo que conocemos como el Proceso

Software

El Proceso de Software es el conjunto de actividades que se realizan para la construcción, liberación y evolución de un

producto de software, comenzando con el estudio de una idea y finalizando con el retiro final

del sistema.

Pressman

Actividades

PersonasHerramientas

Roles ArtefactosNotación

Practicas y Principios

Proceso de Software

Proceso de Softwarejuancarbajalm@undac.edu.pe

El ciclo de vida describe los estados por los que pasa un

producto de software, desde su concepción hasta su muerte.

Ciclo de Vida Clásico

Análisis

Diseño

Construcción

Pruebas

Operación y Mantenimie

nto

Ciclo de Vida Clásico

Existe una gran la variedad de propuestas de proceso de

software, sin embargo el conjunto de actividades fundamentales

definidas en el Ciclo de Vida Clásico se encuentran presentes

en todos ellos.

Conozcamos algunas…

Métodologías Estructuradas

RUP

Microsoft

SolutionsFramework

MSF

Métodologías Ágiles

AUPSCRUMXP

Individuos e Interacciones

Software que funciona

Colaboración con el cliente

Responder ante el cambio

Procesos y herramientas

Documentación exhaustiva

Negociación de contratos

Seguimiento de un plan

sobre

sobre

sobre

sobre

Manifiesto Ágil

No existe un proceso de desarrollo de software universal que sea

efectivo para todos los contextos de proyectos de desarrollo, de allí que sea necesario elegir cual de

ellos es más conveniente, teniendo en cuenta algunos criterios…

Criterios de selección

Complejidad

Costo/Beneficio Económico

Robustez del software

Conocimiento disponible

Roles del Procesojuancarbajalm@undac.edu.pe

El desarrollo de software es una actividad que, dada su complejidad, debe desarrollarse en grupo.

Además, esta actividad requiere de distintas capacidades, las que no se encuentran todas en

una sola persona. Por ello, se hace necesario formar el grupo de desarrollo con las personas que cubran todas las capacidades requeridas.

Cada una de esas personas aportará al grupo parte del total de las capacidades necesarias para llevar a

cabo con éxito el desarrollo.

Con el tema de los

roles tampoco debemos permitir que nos suceda esto…

Gerente de Proyectos

Analista Funcional

Arquitecto de Software

Analista Diseñador

Analista Programador

Analista de Pruebas

Revisor

parUsuari

o

Líder técnico

Otros Roles

Dinámica Vivencial (Procesos y Roles)www.juancarbajalm.net

Dinámica de Grupos

• Se requieren 3 grupos de 4 personas cada uno

• Cada grupo recibirá unos materiales (hoja de números, resaltador, marcador y unas tijeras) y un conjunto de

instrucciones a seguir

• Cada grupo debe leer sus instrucciones en silencio y sin conversar entre los integrantes a menos que así lo indique la

hoja de instrucciones.

• Los equipos deben seguir la estrategia definida en la hoja de instrucciones sin modificarla, no debe copiarse la

estrategia de otro grupo.

• A la señal los equipos deben iniciar con las tareas que se estarán proyectando. La proyección no se devolverá.

Idea original de la dinámica: Luis Fernando Londoño

El tema que tiene que ver con procesos es como el habito de comer, uno puede comer de dos maneras, bien o mal en ultima instancia el fin

"para muchas personas" es llenarse…

Uno puede comer comida sana o comida chatarra y vive, puede vivir con mas dificultades pero vive,

…

Sin embargo "el que se alimenta bien tiene más posibilidades de sobrevivir“

Calidad de SoftwareUNDAC

¿Qué es calidad?

“Quality is Value to some person”

Gerald Weinberg

¿Les ha ocurrido esto?

Lo sentimos por un error en el sistema, no podemos

darle la información que necesita. Por favor regrese

otro día…

¿Nos tenemos que acostumbrar?

¿Qué están haciendo para

corregirlo?

¿Siempre vamos a vivir con estos

errores?

“Cambiar la primera impresión es muy difícil”

“Perder la confianza es fácil, volverla a recuperar cuesta”

Dichos populares

Portabilidad

Mantenibilidad

Eficiencia

Usabilidad

Confiabilidad

Funcionalidad

}ISO / IEC 9126

¿Cuáles son las características de calidad para productos de software?

Funcionalidad

¿Las funciones y propiedades satisfacen las necesidades

explícitas e implícitas?

Funcionalidad{Adecuación

Exactitud

Interoperabilidad

Conformidad

Seguridad

Confiabilidad

¿Puede mantener el nivel de rendimiento, bajo

ciertas condiciones y por cierto tiempo?

Confiabilidad{Nivel de Madurez

Tolerancia a Fallas

Recuperación

Usabilidad¿El software es fácil de

usar y aprender?

Usabilidad{Comprensibilidad

Facilidad para Aprender

Operabilidad

Eficiencia¿Es rápido y minimalista en cuanto al uso de recursos?

¿Cuáles son las características de calidad para productos de software?

Eficiencia{ Comportamiento con respecto al tiempo

Comportamiento con respecto a recursos

Mantenibilidad

¿Es fácil de modificar y verificar?

Mantenibilidad{Capacidad de Análisis

Capacidad de Modificación

Estabilidad

Facilidad de Pruebas

Portabilidad

¿Es fácil de transferir de un sistema a otro?

Portabilidad{Adaptabilidad

Facilidad de Instalación

Conformidad

Capacidad de Reemplazo

Requirement Analysis Acceptance Testing

Coding Unit Testing

Module Design

Integration Testing

Architecture Design

System Design System Testing

¿Cómo mejoramos la calidad?

ProcesoPr

oduc

to

ConclusionesLa calidad no se debe dejar para el final,

es una actividad transversal a todo el proceso

Es muy valiosa la percepción del usuario, pues es quien trabaja y recibe nuestro producto.

Es común ver software hechos para quienes lo desarrollaron y no para quienes lo van a usar

Conclusiones

El ser humano cuenta con una gran capacidad para crear hábitos.

Creemos hábitos para construir software con calidad

Conclusiones

¿La ingeniería de software está en pañales?No tanto, ya existen muchos trabajos y

estudios en torno a ella, de nosotros depende su adopción, para que esta

disciplina siga madurando.

Conclusiones

La calidad es exigida por

todas las partes.

Si la exigimos

debemos colaborar

con ella.

Dinámica Vivencial (Calidad de Software)

¿Qué atributos de calidad tendrían los siguientes elementos?

Idea original de la dinámica: @betancurEstas imágenes son usadas con propósitos exclusivamente educativos

Errores TípicosUNDAC

Los principios y practicas que pueden seguirse en la Ingeniería de

Software, buscan garantizar un mejor resultado y uso de los

recursos

Pero, por alguna razón el comportamiento de los

proyectos no es “aún” el esperado…

¿Quién dice que siempre sale

mal?

A pues no, no siempre sale

mal…

Solo algunas veces

Fuente: http://vidanp.wordpress.com/2010/02/01/estandares-de-medida/

CHAOS Report (Estudio de Resultado de Ejecución de los Proyectos de

Software)

Seguimos cayendo en

los mismos errores

una y otra vez…

Pues bien, muchos de estos errores son aducidos

principalmente a falta de planeación y buen análisis, cosa que tiene mucho sentido pero que sin embargo, no es la

única razón…

Como seres humanos involucrados en el Proceso de Software, cometemos

errores que de no ser corregidos a tiempo, van aumentando su costo y

consecuencias

¿Qué errores se comenten?

Falta de comunicación

Ausencia de objetivos y metas claras durante la ejecución del proyecto

Falta de planificación

Falta de análisis y entendimiento de las necesidades del cliente

Requisitos poco claros y falta de acceso a la información

Mala estimaciónde tiempos

Indefinición del alcance y las responsabilidades de las

partes

Falta de identificación y gestión de los

riesgos

Carencia de habilidades en la ejecución de un rol

Falta de seguimiento al avance del proyecto

Falta de control del presupuesto

Recursos Insuficientes

Tratar de construir sin tener una arquitectura definida

Falta de conocimiento e interés en la aplicación de mejores

prácticas

Hasta ahora hemos hablando de conceptos generales, en la primera

etapa, la etapa de análisis, hay muchas tareas por hacer…

Para poner manos a la obra empezaremos por una tarea muy importante, la identificación de

las necesidades del cliente

Ingeniería de Requisitos

La ingeniería de 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 de software, la

Ingeniería de Requisitos es una de ellas.

Si, Ingeniería de Requisitos y NO

de

Requerimientos

Un requisito por definición es: una condición necesaria para algo.

Podemos entenderlo en nuestro caso como un enunciado que identifica una capacidad,

característica o factor de calidad de un sistema con el fin de que tenga utilidad para un cliente o

usuario.

¿Les ha ocurrido?¿De quien es el error?

#OffTopic

¡Aquí otro ejemplo de problemas

en la definición

de requisitos!

“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”

Roger S. Pressman

“No se puede conocer la solución de un problema si

antes no se conoce el problema.”

Mirador - Monterrey, México 1994

Importancia de los Requisitos

• Mostrar que resultados quieren los participantes

• Dar a los participantes oportunidad de decir que quieren

• Representar diferentes puntos de vista• Probar el diseño• Medir el progreso• Aceptar productos contra criterios precisos

Elicitación de Requisitos

Especificación de todos los requisitos de un sistema, restricciones y condiciones definidas por los usuarios para el

correcto, eficiente, y eficaz funcionamiento del sistema a construir.

Técnicas de Elicitación de Requisitos

Lectura de informaciónCuestionarios y encuestasObservaciónEntrevistasLluvia de Ideas JAD (Joint Application Design - Desarrollo

Conjunto de Aplicaciones) Modelos y/o prototipado Ingeniería reversa

¿Quiénes debería estar involucrados?Clientes

Usuarios

AnalistasDirectoresde Proyecto

Desarrolladores Arquitectos

Reguladores Expertos

Hay una serie de condiciones que debe cumplir un requisito, para

ser considerado un buen requisito

Características de los Requisitos

Comprensible por Clientes y UsuariosCorrectoNo AmbiguoCompletoConsistenteVerificableRastreableAnotado con Importancia y Estabilidad Independiente del Diseño e

Implementación

Hagamos un ejercicio, para empezar a practicar… ¡Juguemos!

¿Conocen el juego?

Si lo conocen, vamos a recordar, si no, vamos a aprender, ¡Como niños!

Escaleras y Serpientes

• Esta es la “Especificación” que se da a un niño de 5 años para que participe en el juego.

– Los jugadores se sitúan en la casilla de salida. – Empieza a jugar quien mayor puntuación obtenga.– El turno avanza de derecha a izquierda.– Cada jugador lanza por turnos y avanza con su ficha

tantas casillas como puntos saque.– Si cae en una casilla situada al pie de las escaleras,

avanza hasta el final de la misma.– Si cae en la casilla ocupada por la cabeza de la

serpiente, retrocede hasta la cola.

¿Todo está claro?

De acuerdo a la “Especificación”

• ¿Cual es el objetivo del juego?• ¿Cual es la casilla de salida?• ¿Cual es la ultima casilla?• ¿Con cuantos dados se juega?• Y es que, ¿Quién dijo que eran dados?• ¿Hacia que dirección se avanza?• ¿Cuantos jugadores pueden participar?• Si se para en la cabeza ¿Retrocede hasta la cola?

¡Ouch!Lo mismo sucede con las especificaciones de

requisitos cuando son entregadas a los desarrolladores para que estos construyan los

sistemas.

Los desarrolladores no tienen la información suficiente para poder llevar a cabo bien su tarea, y si para colmo, cometen el error de suponer aquello

que no saben, tenemos un problema mayor.“El sentido común, el es menos común de los

sentidos”, y tiene una alta probabilidad de no coincidir con las necesidades de los usuarios.

¿Lo intentamos?

Workshop de Requisitos

Quedan muchos temas por aprender…

Análisis, Modelamiento, Diseño y Arquitectura, Mejores Practicas de Codificación, Integración Continua,

Pruebas de Software y más.

Esperamos haber sembrado en ustedes la inquietud de aprender mucho más sobre

Ingeniería de Software

¡Gracias!