sintesis

¿Por qué?

Hardware

telar

  • La humanidad gracias a sus herramientas y, en particular, al conocimiento (ciencias, ingenierías, …​), ha construido grandes sistemas artificiales: acueductos, telares con tarjetas perforadas, red eléctrica, red telefónica, …​ para automatizar tareas, o sea, simplificar y reutilizar

    • 8000 aec., Los sumerios construyen telares para cubrirse

    • 1642 ec., Blaise Pascal construye la Pascalina, primera calculadora mecánica girando ruedas

    • 1801 ec., Jacquard construye el primer telar mecánico y automático con tarjetas perforadas para definir los dibujos

    • 1842 ec., Charles Babbage y Ada Lovalace trabajan sobre la Máquina Analítica, con las tarjetas perforadas de los telares …​ pero no llegó a funcionar aunque Ada ya escribió las primeras líneas de código de la historia.

    • 1884 ec., Hollerith desarrolló la Máquina Tabular de tarjetas perforadas para ordenar el registro de propiedad en la Conquista del Oeste

    • 1936 ec., Konrad Zuse, ingeniero alemán, diseñó y fabricó la Z1, la que para muchos es la primera computadora programable de la historia

telarMecanico

pascalina

tarjetaPerforada

maquinaTabular

primeraComputadora

¿Cuándo? ¿Dónde? ¿Quién?

  • 1812-13, 20’tipocos años tras la Revolución francesa!!!

  • Londres, Imperio Británico en guerra con los recientes Estados Unidos de América!!!

fecha

londres

  • Ada Lovalace,

    • Matemática y escritora

    • Considerada la primera programadora del mundo mundial, concepto del software

    • Condesa de Lovelace, hija del poeta Lord Byron y de la matemática y activista Lady Byron

charlesBabbage

adaLovalace

maquinaAnalitica

carta

¿Qué?

Software es la información que suministra el desarrollador a la computadora para que manipule de forma automática la información que suministrará el usuario
— Brad Cox
informacionRecursiva
Naturaleza de Lenguajes y Formatos

  • Programas en lenguajes de programación (Java, C/C++, …​),

  • Scripts para la creación de las tablas de las bases de datos y su población (SQL),

  • Scripts para la generación de páginas dinámicas en aplicaciones Web (JSP, PHP,…​),

  • Presentaciones en lenguajes de formato para aplicaciones Web (HTML, CSS, …​)

  • Datos de configuración en diversos formatos (texto libre, XML, JSON, …​)

  • Multimedia en formatos de imagen, sonido o video para elementos gráficos en la Interfaz de Usuario (*.png, *.waw, *.mpeg, …​)

  • …​

¿Para qué?

Objeto Capacidad cualitativa Capacidad cuantitativa

Ser humano

Muy buena: reconocimiento de patrones, asociaciones, recursividad, …​

Muy mala: pequeña, errores por cansancio, desmotivación, …​ y muy lentos

Hardware

Muy mala: ningún computador superó la prueba de Turing

Muy buena: sin errores y a toda velocidad

  • Efectividad en la gestión de sistemas de información, requeridos por clientes para diferentes usuarios, con

    • Eficacia, sin errores en cálculos, filtrados, secuencias de acciones, …​

    • Eficiencia, con escaso consumo de recuros:

      • hardware y energía eléctrica

      • tiempo de los usuarios para aprender y explotar el producto software
software

Sistema de Información

Un sistema de información es un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su uso posterior, generados para cubrir una necesidad o un objetivo
— Sistema Información
Wiki

  • Gestión (CRUD), es el tratamiento de la información, Informática!

    • altas (Create) de información en el sistema

    • bajas (Delete) de información en el sistema

    • modificaciones (Update) de información en el sistema

    • consultas (Read) de información en el sistema

crud

¿Cómo?

Complejidad del Software

El trabajo con software es el más complejo que jamás haya emprendido la humanidad
— F. Brooks

  • Proyecto software

    • Extensión: 100.000 lineas/proyecto mediano y ~3 palabras/línea

    • Entidades: identificadores …​ centenares

    • Autor: 6-8 personas

    • Duración: entre 6 meses y años

    • Coste: miles de €

    • Ámbito: otra persona cambiante

  • El quijote de la Mancha

    • Extensión: 300.000 palabras

    • Entidades: Dulcinea, Sancho Panza, …​ decenas

    • Autor: Miguel de Cervantes Saavedra

    • Duración: 18 años

    • Coste: gratis en la cárcel

    • Ámbito: suyo

cuadranteProyectos

  • No estamos hablando de Análisis de Algoritmos, O(n), ni de Teoría de la Computabilidad, ni de la Teoría de la Complejidad Computacional …​ sobre la cantidad de tiempo/espacio/recursos/…​ requeridos en tiempo de ejecución de un programa en explotación

ordenes

Sistema

  • Software es un conjunto de clases/módulos relacionándose por herencia, composición, … o interdependientes formando una aplicación. Cada aplicación está delimitada por su entorno tecnologíco-comercial, descrito por su arquitectura del software y requisitos y expresado en su ejecución

Sistema complejo

  • Software de una aplicación media (~100.000 líneas de código) tiene una complejidad que excede con creces la capacidad intelectual humana

Características de Sistemas complejos

  • Estructura jerárquica gracias a sus jerarquías de herencia, composición, paquetes con clases con atributos y métodos, métodos con sentencias, sentencias con expresiones, …​

  • Elementos primitivos relativos gracias a sus tipos primitivos dependiendo del lenguaje (enteros, cadena de caracteres?, fechas?, …) y los definidos por el usuario

  • Separación de asuntos gracias a la encapsulación y modularidad

  • Patrones comunes gracias a algunos métodos de clases que corresponden al paso de mensajes a objetos

  • Formas intermedias estables gracias a las metodologías iterativas o por culpa de nuevas tecnologías o nuevas necesidades
jerarquiasParadigma

Proyecto Software

MetodogiasAgiles
variablesProyectoSoftware

davidProyecto

Interrelación

  • No hay una relación sencilla entre las cuatro variables.

    • Por ejemplo, no puedes reducir el tiempo a la mitad, gastando el doble
Nueve mujeres no pueden tener un bebé en un mes […​ (y por si no lo entiende un directivo)], dieciocho mujeres aún no pueden tener un bebé en un mes
— Brooks
La forma de hacer en este modelo del juego del desarrollo del software es que las fuerzas externas (clientes, directores de proyecto) eligen los valores de tres variables cualquiera. El equipo de desarrollo determina el valor resultante de la cuarta variable
— Beck
1999
Algunos directores de proyecto y clientes creen que pueden escoger el valor de las cuatro variables. Cuando esto suceda, la calidad siempre desaparecerá, ya que nadie hace bien el trabajo cuando está sujeto a una fuerte presión. También, probablemente, el tiempo estará fuera de control
— Beck
1999

Ámbito

  • Es la más importante a tener en cuenta

  • Naturaleza del Ámbito

    • Poco ámbito permite entregar más rápido, mas calidad (mientras el problema del cliente esté resuelto) y más barato

    • Ámbito muy variable:

      • Porque los programadores y el personal del negocio no tienen más que una idea vaga sobre lo que tiene valor en el software que se está desarrollando.

      • Porque los requisitos nunca están claros al principio y los clientes no pueden decirnos exactamente lo que quieren.

        • El desarrollo de una pieza de software cambia sus propios requisitos ya que tan pronto como el cliente ve la primera versión, aprenden lo que quieren para la segunda versión …​ o lo que realmente querían en la primera.

        • Y esto es un aprendizaje valioso, porque no hay posibilidades de especulación. Este aprendizaje solamente puede venir de la experiencia. Pero los clientes no pueden estar solos, necesitan gente que pueda programar, no como guías, sino como compañeros.

  • Gestión del Ámbito

    • Intentando no hacer demasiado, mantenemos nuestra capacidad de producir la calidad requerida en un tiempo determinado.

    • Si se gestiona activamente el ámbito, se puede proporcionar a los directores de proyecto y clientes control sobre el coste, calidad y tiempo.

    • Eliminación del ámbito es una de las decisiones más importantes en la gestión del proyecto

      • Si el tiempo está limitado por la fecha de lanzamiento de una versión, hay siempre algo que podemos diferir a la siguiente versión.

      • Si dejas fuera importante funcionalidad al final de cada ciclo de versión, el cliente quedará disgustado. Para evitar esto, se utilizan dos estrategias:

        • Implementa en primer lugar los requisitos más importantes del cliente, de tal manera que si se deja después alguna funcionalidad, es menos importante que la funcionalidad que ya está incorporada al sistema

        • Consigue mucha práctica haciendo estimaciones y realimentando los resultados reales. Mejores estimaciones reducen la probabilidad de que tengas que dejar fuera funcionalidad

Tiempo

  • Si damos a un proyecto poco tiempo, la calidad sufre, con el ámbito. Las restricciones de controlar proyectos controlando el tiempo, generalmente vienen de fuera, de las manos del cliente.

  • Disponer de más tiempo para la entrega puede mejorar la calidad e incrementar el ámbito.

  • Ya que la realimentación desde los sistema en producción es de mayor calidad que cualquier otra clase de realimentación, dar a un proyecto demasiado tiempo será perjudicial.
Si la mayoría de los proyectos de tu organización son obsesivamente cortos, proyectos conducidos por el calendario, hay algo muy, muy malo. Cambios radicales en la organización del proceso de desarrollo software son necesarios, antes de que la compañía o su gente se arruine.
— Booch
Object Solutions

Coste

  • Al comienzo de un proyecto no puedes gastar mucho, la inversión tiene que comenzar siendo pequeña y crecer con el tiempo. Después, se puede de forma productiva gastar más y más dinero.

  • Mucho dinero puede engrasar la maquinaria un poco, pero demasiado dinero pronto crea más problemas que resuelve.

    • Mayores costes a menudo alimentan objetivos tangenciales, como estatus o prestigio (- "Tengo un proyecto de 150 personas!"" - y respira profundamente”)

  • Dentro del rango de inversión que pueda sensatamente hacerse, gastando más dinero puedes aumentar el ámbito, o puedes intentar de forma más deliberada aumentar la calidad, o puedes (hasta cierto punto) reducir el tiempo de salida al mercado.

    • También puede reducir las desavenencias: máquinas más rápidas, más especialistas técnicos, mejores oficinas.

  • Muy poco dinero, no permite resolver el problema del negocio del cliente. Todas las restricciones sobre el coste pueden volver locos a los directores de proyecto.

    • Especialmente si están sujetos a un proceso de presupuesto anual, están tan acostumbrados a considerarlo todo desde la perspectiva del coste y cometerán grandes errores al ignorar las restricciones sobre cuánto control te proporciona el coste.

Calidad

  • Hay una extraña relación entre la calidad interna (que miden los programadores) y externa (que mide el cliente).

calidadInternaExterna

  • Sacrificar temporalmente la calidad interna para reducir el tiempo de salida al mercado del producto, con la esperanza que la calidad externa no se vea muy dañada es tentador a corto plazo. Y puedes con frecuencia hacerlo impunemente generando una confusión en cuestión de semanas o meses. Al fin y al cabo, los problemas de calidad interna te alcanzan a ti y hacen que tu software sea prohibitivamente caro de mantener.

  • A menudo, al insistir en la mejora de la calidad puedes hacer que el proyecto esté listo en menos tiempo, o puedes conseguir hacer más en un una cantidad de tiempo dada. Se trabaja mejor si no se desmoraliza al producir software basura.

Te puedes echar colonia pero si no te duchas no disfrutarás de relaciones personales plenas porque tu peste provocará rechazo por muy interesante que seas

Es como pasear por la orilla del mar frente a "pasear" metido en el mar con el agua alcanzando el pecho
La observación general es que el principal enemigo de la fiabilidad, y tal vez de la calidad del software en general, es la complejidad
— Meyer
Cuanto más complejo sea un sistema, más abierto está al colapso total. Gran parte de la complejidad que se tiene que dominar es la complejidad arbitraria
— Booch

  • Características del software

    • Fiabilidad, cumpla una determinada función bajo ciertas condiciones durante un tiempo determinado

    • Extensibilidad, habilidad de tener la posibilidad de se extendido con nuevas funcionalidades

    • Usabilidad, sencillo de usar porque facilita la lectura de los textos, descarga rápidamente la información y presenta funciones y menús sencillos, por lo que el usuario encuentra satisfechas sus consultas y cómodo su uso

      • Accesibilidad, pueda ser accedido y usado por el mayor número posible de personas, indiferentemente de las limitaciones propias del individuo o de las derivadas del contexto de uso

    • Seguridad, proteger los datos que tiene, maneja y dispone para preservar la confidencialidad, la integridad y la disponibilidad

      • Confidencialidad, acceso a la información mediante autorización y control para prevenir la divulgación no autorizada de la información

      • Integridad, para modificar la información mediante autorización

      • Disponibilidad, degradación en cuanto a accesos para prevenir interrupciones no autorizadas

    • Interoperabilidad, habilidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada

    • Portabilidad, habilidad de reutilizar en vez de crear un nuevo software cuando se pasa de una plataforma a otra

    • Escalabilidad, habilidad para reaccionar y adaptarse sin perder calidad cuando aumentan el tamaña del sistema de información

    • …​ todas dependen en última instancia de:

Mantenibilidad

  • Mantenibilidad, habilidad de conservar su funcionamiento normal o para restituirlo una vez se ha presentado un evento de falla o un nuevo requisito

    • Mantenibilidad Correctiva, para la eliminación de errores de cualquier otra cualidad

    • Mantenibilidad Perfectiva, para la modificación de su funcionalidad con cualquier otra cualidad

    • Mantenibilidad Adaptativa, para la modificación de su infraestructura para cualquier otra cualidad
mantenibilidad
Mantenible No mantenible

  • Fluido

  • Flexible

  • Fuerte

  • Reusable

arbolMantenible

arbolNoMantenible

  • Viscoso

  • Rígido

  • Frágil

  • Inmóvil
Viscosidad vs Fluidez
Viscosidad del diseño Viscosidad del entorno

  • Se produce cuando nos enfrentamos a un cambio, los ingenieros suelen encontrar más de una manera de hacer el cambio. Algunas de las formas conservan el diseño, otros no lo hacen, es decir, son atajos.

    • Cuando preservar el diseño es más difícil que emplear los atajos, a continuación, la viscosidad del diseño es alta.

    • Es fácil de hacer las cosas mal, pero difícil de hacer lo correcto.

  • Se produce cuando el entorno de desarrollo es lento e ineficiente. Por ejemplo, si los tiempos de compilación son muy largos, los ingenieros tendrán la tentación de hacer cambios que no obligan a grandes re-compilaciones, a pesar de que esos cambios no son óptimos desde el punto de vista del diseño.

    • Si el sistema de control de código fuente requiere horas para comprobar tan sólo unos pocos archivos, consecuentemente, los ingenieros tendrán la tentación de hacer cambios que requieren el menor número de subidas (commits) como sea posible, independientemente de si el diseño se conserva.
Rigidez vs Flexibilidad

  • Rigidez es la tendencia del software que es difícil de cambiar, incluso en formas simples.

  • Cada cambio provoca una cascada de cambios posteriores en los módulos dependientes. Lo que comienza como un simple cambio de dos días a un módulo se convierte en un maratón de varias semanas de cambios en el módulo después de otros módulos según los ingenieros persiguen el hilo del cambio a través de la aplicación.

  • Cuando el software se comporta de esta manera, los gerentes temen que no permitirá a los ingenieros solucionar problemas críticos. Esta resistencia se deriva del hecho de que ellos no saben, con confiabilidad, cuando terminarán. Si los gerentes insisten, los ingenieros se perderán en este tipo de problemas, que pueden desaparecer durante largos periodos de tiempo.

  • Cuando los miedos del gerente son tan agudos que se niegan a permitir cambios en el software, la rigidez oficial se instala. Por lo tanto, lo que comienza como una deficiencia de diseño, termina siendo una política de gestión adversa.
Inmovilidad vs Reusabilidad

  • La inmovilidad es la imposibilidad de volver a utilizar el software de otros proyectos o de partes del mismo proyecto.

  • A menudo sucede que un ingeniero descubrirá que necesita un módulo que es similar a uno que escribió otro ingeniero. Sin embargo, también sucede a menudo que el módulo en cuestión tiene demasiado equipaje del que depende.

  • Después de mucho trabajo, los ingenieros descubren que el trabajo y el riesgo requerido para separar las partes deseables del software de las partes no deseadas son demasiado grandes como para tolerarlo. Y así, el software es simplemente reescrito en lugar de reutilizado.
Fragilidad vs Fortaleza

  • Fragilidad es la tendencia del software para estropearse en muchos lugares cada vez que se cambia. A menudo, el error se produce en las zonas que no tienen ninguna relación conceptual con el área que se ha cambiado..

  • Según empeora la fragilidad, la probabilidad de error aumenta con el tiempo, asintóticamente acercándose al 100%. Este tipo de software es imposible de mantener. Cada solución hace que sea peor, la introducción de más problemas que soluciones.

  • Tales errores llenan las sensaciones de los gerentes de malos presagios. Cada vez que autorizan una solución, temen que el software va a estropearse de alguna manera inesperada. Este tipo de software hace que los gerentes y los clientes sospechen que los desarrolladores han perdido el control de su software. La desconfianza reina, y la credibilidad se pierde.

Crisis del Software

  • La Crisis del Sotfware es la incapacidad para dominar la complejidad de los proyectos software incluyendo defunciones, accidentes, desastres, ruinas, …​

  • Estadísticas de Standish Group sobre 50.000 proyectos

    • se entregan tarde, con deficiencias funcionales y por encima del presupuesto, conocidos como proyectos fracasados o problemáticos.

standishGroup
Motivos de Proyectos Fracasados/Problemáticos Incidencia

  • Gestión

    • Falta del involucración del usuario

    • Poco apoyo de las gerencias involucradas

    • Falta de recursos

    • Tiempos poco realistas

  • Requisitos

    • Requerimientos y especificaciones poco claras

    • Cambio de requerimientos y especificaciones

    • Expectativas poco realistas

    • Objetivos poco claros

  • Tecnologías

    • Tecnología deficiente

    • Nuevas tecnologías

  • Otros

  • 31.0%

    • 12.8%

    • 7.5%

    • 6.4%

    • 4.3%

  • 35.3%

    • 12.3%

    • 11.8%

    • 5.9%

    • 5.3%

  • 10.7%

    • 7.0%

    • 3.7%

  • 23.0%

Síntesis

sintesis

sintesis

Bibliografía

Obra, Autor y Edición Portada Obra, Autor y Edición Portada

  • Object Solutions. Managing the Object Oriented Project

    • Grady Booch

    • Addison-Wesley Professional (1789)

height32

  • Object Oriented Analysis and Design with Applications

    • Grady Booch

    • Imprint Addison-Wesley Educational s Inc (3 de junio de 2011)

height32

  • The Unified Modeling Language User Guide

    • Grady Booch

    • Pearson Education (US); Edición: 2 ed (28 de junio de 2005)

height32

  • The Mythical Man Month. Essays on Software Engineering

    • Frederick P. Brooks

    • Prentice Hall; Edición: Nachdr. 20th Anniversary (1 de enero de 1995)

height32

  • Extreme Programming Explained. Embrace Change. Embracing Change

    • Kent Beck,Cynthia Andres

    • Addison-Wesley Educational Publishers Inc; Edición: 2nd edition (16 de noviembre de 2004)

height32

  • Refactoring. Improving the Design of Existing Code

    • Martin Fowler,Kent Beck,John Brant,William Opdyke,Don Roberts

    • Addison Wesley; Edición: 01 (1 de octubre de 1999)

height32

  • UML Distilled. A Brief Guide to the Standard Object Modeling Language

    • Martin Fowler,Kendall Scott

    • Addison-Wesley Educational Publishers Inc; Edición: 3 ed (15 de septiembre de 2003)

height32

  • Patrones de diseño

    • Erich Gamma et al

    • Grupo Anaya Publicaciones Generales; Edición: 1 (1 de noviembre de 2002)

height32

  • Clean Code. A Handbook of Agile Software Craftsmanship

    • Robert C. Martin

    • Prentice Hall; Edición: 01 (1 de agosto de 2008)

height32

  • Object-Oriented Software Construction

    • Bertrand Meyer

    • Prentice Hall; Edición: 2 ed (3 de abril de 1997)

height32

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM