Ingeniería del Software de Gestión...un rendimiento esperados Conjunto de estructuras de datos que...

Tema 1

Introducción a la Ingeniería del Software

Ingeniería del Software de Gestión www.kybele.es

Marcos López SanzIngeniería del Software de Gestión

Índice

� Introducción

� ¿Qué es Software?

� ¿Qué es Ingeniería del Software?

� ¿Por qué surge la Ing. del SW?� Crisis del Software

� Mitos del Software


� Mitos del Software

� Malas prácticas de desarrollo y mantenimiento

� Lo que propone la Ing. del SW

� La complejidad inherente del software

� Algunos principios de la ingeniería del software

� Sistemas de Información

Introducción

¿Qué es Software?


Introducción

¿Qué es Software?

� Conjunto de programas que proporcionan una función y un rendimiento esperados

� Conjunto de estructuras de datos que permiten a los programas manipular adecuadamente la información


� Conjunto de documentos que describen el funcionamiento del SI (Sistema de Información).

� Tipos:

� Genéricos: Productos de uso genérico (procesadores, bases de datos, etc.)

� A medida: Productos específicos para un cliente particular

Introducción

¿Qué es Software?

� Características:

�No tiene forma física

� Se desarrolla, no se fabrica

� Los costes del SW son de ingeniería. No de fabricación

� El SW no se rompe, se deteriora


� El SW no se rompe, se deteriora

� La complejidad del mantenimiento del SW es mucho más grande que la del HW

� Si el HW se rompe se cambia por otro y listo

� Hay piezas de recambio

� Si el SW se deteriora, con cada cambio que se realiza se deteriore aún más

� No hay piezas de recambio

Introducción

¿Qué es Ingeniería del Software?

� Definición:

“La Ingeniería del Software es la disciplina de

ingeniería encargada de todos los aspectos

relacionados con la producción de software desde sus

etapas más tempranas de la especificación del


etapas más tempranas de la especificación del

sistema hasta el mantenimiento del sistema tras su

puesta en marcha”

Ingeniería del Software – Ian Sommerville

Introducción

¿Qué es Ingeniería del Software?

� Disciplina de ingeniería� Los ingenieros de software usan las herramientas,

métodos y teorías para solucionar los problemas que aparecen

� Incluso teniendo en cuenta restricciones económicas y de organización


de organización

� Producción de software� Planificación de proyectos

�Administración de proyectos software

� Procesos técnicos de desarrollo de software

�Dirección de proyectos

Introducción

¿Por qué surge la Ing. del Software?

� Para superar la crisis del software y terminar

con los mitos del software hasta ahora

existentes


� Para acabar con las malas prácticas de desarrollo y mantenimiento de software

llevadas a cabo por las empresas

� Crear software de calidad

Introducción

Crisis del Software

� Dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables(Dijkstra – 1968)

� Causas:

� Los proyectos no terminaban en plazo

� Los proyectos no se ajustaban al presupuesto inicial


� Los proyectos no se ajustaban al presupuesto inicial

� Software que no cumplía las especificaciones

� Código inmantenible que dificultaba la gestión y evolución del proyecto

� Consecuencias:

� Baja calidad del Software

� Tiempo y presupuesto excedido

� Confiabilidad cuestionable

� Altos requerimientos del personal para el desarrollo y el mantenimiento

“La empresa ya dispone de unos estándares de trabajo y unos procedimientos de desarrollo establecidos y son

conocidos por todos nuestros empleados”

MitoMito

Introducción

Mitos del SW – Sobre la gestión


En realidad muchas empresas no disponen de estándares ni procedimientos de trabajo y si los disponen, éstos son incompletos, no utilizan prácticas modernas de desarrollo, no todo el personal los conoce y nadie controla que éstos se apliquen.

RealidadRealidad

“El equipo de trabajo dispone de las más modernas herramientas de desarrollo y trabaja con las

máquinas más potentes”

MitoMito

Introducción



No sirve de nada trabajar con las mejores máquinas o utilizar las herramientas más modernas si el equipo no tiene los conocimientos necesarios para utilizarlas eficazmente (cursos de formación, soporte profesional externo…)

RealidadRealidad

“Por qué hacer una planificación exhaustiva, si cometemos algún error, siempre podemos añadir

gente”

MitoMito

Introducción



Añadir gente nueva en un proyecto que está atrasado, lo hace atrasar aún más. Los nuevos integrantes deben integrarse, recibir formación y aprender la manera de comunicarse en el grupo.

RealidadRealidad

“Una declaración general de los objetivos es suficiente “Una declaración general de los objetivos es suficiente para comenzar a escribir los programas, podemos dar para comenzar a escribir los programas, podemos dar

los detalles más adelante”los detalles más adelante”

MitoMito

Introducción

Mitos del SW – Sobre el cliente


Una mala definición inicial es la principal causa del trabajo inútil en software. Es esencial una descripción formal y detallada del ámbito de la información. Es necesaria una exhaustiva comunicación entre el cliente y el analista.

RealidadRealidad

“Los requisitos del proyecto cambian continuamente, “Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente ya pero los cambios pueden acomodarse fácilmente ya

que el software es flexible”que el software es flexible”

MitoMito

Introducción

Mitos del SW – Sobre el cliente


Es verdad que los requisitos del software cambian, pero el impacto del cambio varia según en el momento que se presenten (Definición: Bajo Impacto / Desarrollo: Alto Impacto / Después de la entrega: Crítico Impacto)

RealidadRealidad

““No es necesaria ninguna metodología, cuanto antes No es necesaria ninguna metodología, cuanto antes empecemos a programar, antes acabaremos”empecemos a programar, antes acabaremos”

MitoMito

Introducción

Mitos del SW – Sobre desarrolladores


Cuando más pronto se comience a escribir código, más se tardará

en terminarlo. Entre el 50% y el 70% de todo el esfuerzo dedicado

a un programa se realizará después de que se la haya entregado al

cliente por primera vez.

RealidadRealidad

““Lo único que realmente importa, cuando se termina un Lo único que realmente importa, cuando se termina un proyecto, es que la aplicación funcione. La proyecto, es que la aplicación funcione. La

documentación nadie la utiliza”documentación nadie la utiliza”

MitoMito

Introducción

Mitos del SW – Sobre desarrolladores


La documentación es la base de un desarrollo y, lo que es más

importante, proporciona guías para la tarea de mantenimiento del

software.

RealidadRealidad

Introducción

Malas prácticas de desarrollo y mantenimiento

� Planificación y estimaciones imprecisas:

�No se recopilan datos de proyectos pasados.

�Se invierte más dinero en mantenimiento que en

formación de los ingenieros en las nuevas

tecnologías de desarrollo.


tecnologías de desarrollo.

�No se documenta lo suficiente.

�Se pasa directamente a la codificación.

Introducción


� Procesos software improvisados

� No se siguen rigurosamente las especificaciones

� No se hace planificación de riesgos

� Se resuelven crisis inmediatas � Se apagan fuegos


� Se sacrifica funcionalidad y calidad del producto para cumplir plazos

� No se planifica debidamente

� No se realizan pruebas, verificaciones o revisiones del SW

Introducción


� Síntomas:

�Baja calidad del software desarrollado

�Alto grado de desconfianza e insatisfacción en el cliente


�Empresas inmaduras � En fase artesanal

� Se exceden en los plazos y presupuestos previstos

� 90% de los proyectos no consiguen los objetivos propuestos

� 40% fracasan completamente

� 29% nunca se entregan

Introducción¿Qué propone la IS? �� ¡ser Ingenieros!

� Artesano � Ingeniero

� Para ello se debe:

�Aplicar métodos, técnicas y herramientas de


�Aplicar métodos, técnicas y herramientas de

desarrollo

�Adoptar estándares de desarrollo

�Utilizar la experiencia acumulada

�Documentación

� ¿Qué conseguimos adoptando estándares de

desarrollo?

�Mejorar el proceso:

� Reducción de costes

Introducción

¿Qué propone la IS? �� ¡usar Estándares!


� Reducción del tiempo de desarrollo

� Reducción de riesgos

�Mejora de la calidad del producto

�Protección del cliente

�Protección de la organización

� Aumenta su competitividad

Índice

� Introducción


�Complejidad del dominio del problema


�Complejidad del dominio del problema

�Controlar el proceso de desarrollo

�Caracterizar problemas discretos



Complejidad del SW

� ¿Por qué es complejo el Software?

�Brooks (1987): “La complejidad del Software es una propiedad esencial y no accidental”

� Complejidad accidental: se debe a la manera en que intentamos solucionar el problema

� Complejidad esencial: es inherente al problema en sí mismo


� Complejidad esencial: es inherente al problema en sí mismo

� Tres motivos:

� La complejidad del dominio del problema

� La dificultad de controlar el proceso de desarrollo

� Los problemas para caracterizar sistemas discretos

Complejidad del SW

Complejidad del dominio del problema

� Los problemas del mundo real son complejos (miles de requisitos compitiendo y quizás contradictorios)

� Se añaden requerimientos no funcionales: eficiencia, coste, fiabilidad, robustez...


Se añaden requerimientos no funcionales: eficiencia, coste, fiabilidad, robustez...

� Diferente perspectiva del mismo problema entre los usuarios y los desarrolladores

� ¡Los requisitos cambian durante el desarrollo!

Complejidad del SW

Controlar el proceso de desarrollo

� Surgen incidencias

�Algunas previstas y otras no

� Miles de líneas de código

� Intentar la reutilización

Surgen diferentes versiones del producto


� Surgen diferentes versiones del producto

� Disminuir la complejidad mediante el “divide y vencerás”

�División en módulos

�Aún así, la creación de muchos módulos puede ser inmanejable

� El software trabaja con sistemas de estados discretos.

�Variables

�Flujos de control estado del sistema

�Eventos externos

Complejidad del SW

Caracterizar sistemas discretos


�Eventos externos

� Cada evento externo puede cambiar el estado del sistema, pero ¿se trata de un estado válido?

�Necesidad de pruebas � Complejo, costoso y en ocasiones imposible que sean exhaustivas.

Índice

� Introducción





Algunos principios de IS

1. Entregar el producto al cliente cuanto antes

�Se debe dedicar esfuerzo en la captura de las

necesidades del cliente

� Captura de Requisitos


� Involucrar al cliente en el proceso de desarrollo

� Uso de Prototipos

�Respetar los plazos acordados con el cliente.

Quedará satisfecho ☺


2. Determinar el problema antes de escribir

especificaciones

�Elegir la solución que mejor se adapte a las

necesidades del cliente


�Analizar todas las posibles soluciones. Costes,

esfuerzo, etc.

�No dar soluciones precipitadas. Explorar todas las

alternativas


3. Minimizar la distancia intelectual

�Distancia intelectual: “distancia entre el problema

del mundo real y la solución computerizada del

problema” (Dijkstra)


�Cuanto menor sea la distancia intelectual, más

mantenible será el software.

�La estructura del SW debería ser cercana a la

estructura del mundo real


4. Evaluar las alternativas de diseño

�Una vez establecidos los requisitos, ¿qué

arquitecturas o algoritmos elegir?


�Según por el diseño que optemos tendremos:

� Unos tiempos de respuesta u otros

� Más portabilidad

� Mayor seguridad


5. La técnica es más importante que las

herramientas

�Un ingeniero software indisciplinado con una

potente herramienta se puede convertir en un

ingeniero peligroso


ingeniero peligroso

�Antes de seguir una herramienta, se debe

comprender y seguir una técnica apropiada

= PELIGRO+


6. Hazlo bien antes de hacerlo rápido

�Es más fácil hacer que un programa que funciona

bien sea más rápido, que hacer que un programa

rápido que funciona mal funcione bien.


�No preocuparse en optimizar en la fase inicial.


7. La inspección de código es mejor que la

ejecución

�La inspección de código:

� Permite descubrir el 82% de los errores


� Consume cerca del 15% de los recursos disponibles para

el desarrollo

� Reduce los costes de desarrollo entre un 25% y un 30%

� Reduce el tiempo de pruebas entre un 50% y un 90%


8. El personal es la clave del éxito

� Personal cualificado con herramientas insuficientes se puede llegar al éxito

� Personal NO cualificado con las más potentes herramientas, NO llegamos al éxito


� Importante trabajar en equipo

� Todo el personal debe conocer los estándares de trabajo

� Alguien debe controlar la aplicación de estos estándares

� Deberá haber una persona encargada de mantenerlos, adaptarlos y ampliarlos

� El equipo debe recibir cursos de formación


9. Un diseño sin documentación, NO es un diseño

� Los ingenieros de SW no competentes suelen decir: “Ya

he terminado el diseño, sólo falta la documentación”.

� ¿Os imagináis a un arquitecto que diga: “ el diseño del


� ¿Os imagináis a un arquitecto que diga: “ el diseño del

nuevo edificio ya está listo, sólo faltan los planos”?

� Se debe ir documentando durante todo el proceso de

desarrollo


10. El código difícil de leer es difícil de mantener.

11. La encapsulación crea SW fácil de probar y mantener � “Divide y vencerás”


12. No probar tu propio SW. Los desarrolladores no deben probar el SW que han generado

13. La entropía de los sistemas aumenta. Cuanto más se modifica y crece un sistema SW, más complejo y desorganizado se vuelve

Índice

� Introducción


Algunos principios de la ingeniería del software




� ¿Qué es un sistema? Tipos y ejemplos

�Datos e información: ¿qué es un sistema de información?

¿Qué es un Sistema?

� Es un conjunto de dos o más elementos interrelacionados que satisfacen las 3 propiedades siguientes:�Cada elemento tiene influencia sobre el conjunto. No

podemos quitar ninguno

� El comportamiento de cada elemento depende de los


� El comportamiento de cada elemento depende de los otros elementos del conjunto

�No hay un elemento aislable dentro del sistema

� La complejidad es una función que depende de:�Nº elementos

�Nº de relaciones entre elementos

Ejemplos de Sistemas

Sistema operativo



Sistema de transporte



Sistema planetario


¿Qué es un Sistema?

Tipos

� Naturales

� Físicos:� Estelares: sistema solar

� Geológicos: sistema ibérico.

� Biológicos: sistema nervioso.

� Vivientes:� Animales: manadas.


� Animales: manadas.

� Creados por el hombre:

� Sociales: leyes, costumbres.

� De transporte: redes viales, líneas aéreas.

� De comunicación: Internet, teléfono, lengua.

� Financieros: Contabilidades, personal.

¿Qué son los Datos?

� Son los registros de los hechos, los

acontecimientos o las transacciones

� Son la materia prima para obtener la


� Son la materia prima para obtener la

información

� Son series de números, de caracteres que por si

solos no quieren decir nada

¿Qué es Información?

� Son los datos procesados de tal forma que

resultan útiles o significativos en un cierto

contexto.


� Según el proceso y según el contexto, la

información puede resultar diferente

¿Qué es un Sistema de Información?

� “Es un conjunto formal de procesos que operando sobre una

colección de datos estructurados, según las necesidades de la

empresa, recopilan, elaboran y distribuyen la información

necesaria para las operaciones de esta empresa, y para las

actividades de dirección y control correspondientes. De esta

manera, la empresa puede llevar a cabo su actividad según su


manera, la empresa puede llevar a cabo su actividad según su

estrategia de negocio”

(Andreu et al., 1991)

Elementos a tener en cuenta en un Sistema de Información

� Procedimientos de trabajo

� La información: es la parte principal del sistema.

� Las personas o usuarios: son los que tratan la


� Las personas o usuarios: son los que tratan la información.

� El equipo de soporte, para la comunicación, el procesamiento y el almacenaje de la información � La parte física y tangible (HW, papel, servidores, soportes digitales…)

Ingeniería del Software de Gestión...un rendimiento esperados Conjunto de estructuras de datos que...

Documents

Transcript of Ingeniería del Software de Gestión...un rendimiento esperados Conjunto de estructuras de datos que...