intruducción de la ingeniería de software
Post on 29-Jun-2015
389 Views
Preview:
TRANSCRIPT
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!
top related