1940 y 1950 el desarrollo de software se realizaba sin
planificación. El software se creaba, se ejecutaba y ante los
fallos se depuraba. La estructura del diseño era implícita, y no
existía la documentación.
¡¡Prueba y Error!!
Para esta época el coste del
hardware era extremadamente
superior al software
Se consideraba que el ingeniero de
software solía ser el mismo que el de
hardware
Solo el programador conocía y
entendía su código.
1970 Surge la multi-programación y los
sistemas multi-usuario.
Aparece el concepto
Hombre-Máquina
Nace la primera generación de
gestión de bases de datos
Codifica y
corrige
Los errores tenían que ser corregidos
apenas se detectaban fallas, y los
programas cambiaban al cambiar los
requisitos
Dado que existían muchas fallas, los desarrollos
sobrepasaban el tiempo y los costos, haciendo
que el software fuera poco flexible, y esto
ocasiona el fenómeno de la CRISIS DEL
SOFTWARE
Por esto, nace el término de
Ingeniería del Software, en una
conferencia financiada por la OTAN
1980, es caracterizada por su
productividad y escabilidad de
sistemas de desarrollo.
La industria del software se
convierte en la cuna de la
economía mundial
Las técnicas de desarrollo del software
(4Gls) incrementan la productividad a través
de la programación por el usuario.
Se introduce la tecnología de la
programación orientada a objetos
(POO) a través de multiples lenguajes de programación.
Se crea el primer módulo
de madurez de capacidad
de procesos (SW-CMM)
1990, la orientación a objetos se
extiende a las fases de análisis y
diseño.
Se implementa el
lenguaje de
modelado (UML)
Se genera el 1er proceso
comercial de desarrollo
orientado a objetos (RUP)
Se define el modelo en espiral
para el desarrollo basado en
análisis de riesgos
Se define el desarrollo de
software iterativo e
incremental.
El software era privado, por lo tanto surge la
necesidad de crear proyectos que impulsen la
creación de software libre y código abierto.
La usabilidad de sistemas se
convierte en el foco de atención
e investigación.
En la actualidad los temas atañen a la
agilidad en el desarrollo y el valor para el
cliente.
Dispositivos como celulares,
PDAs entre otros, se
involucran en el ciclo de vida.
Se incrementa la programación
de software empaquetado.
Se incrementa el
desarrollo dirigido por
modelos y se integra el
desarrollo de software con
el de sistemas.
La conectividad global por parte del
internet evoluciona la economía.
La tecnología digital está transformando a las organizaciones
de negocio. Afectan directamente la decisión de los
administrativos, la planificación, y a la producción.
Actualmente se dispone de lenguajes de
programación más sofisticados, procesos
de desarrollo más maduros, y las
aplicaciones que actualmente se
desarrollan son mucho más complejas.
Manifiesto ágil, como intento
de simplificar la complejidad
de las metodologías
existentes
1960, la época de los
famosos códigos
espaguetti"
Ideas como "reutilización de
código" y "arquitectura de
software" se van planteando
Se impulsa la programación
estructurada
Se cita por primera vez el
término fábrica de software
Crisis del Software
A medida que crecen las técnicas de
desarrollo de software, la exigencia de la
calidad del mismo también aumenta.
Ocasionando así una espiral de costos del
software.
Ocasionando así una escasez de ingenieros de software. En 1991 se estimó
que hubo un déficit de un millón de profesionales de software que no
cumplían con las exigencias.
Si la especificación de requisitos es
incorrecta, incompleta o es ambigua, por
muy bien que se desarrolle el software
posteriormente, resultado final será
pobre.
La mala especificación de los requerimientos de
software es de las principales causas de los problemas
de los sistemas basados en software.
En
Colombia
Debido al incremento de facultades, programas
y denominaciones, es fácil no comprender el
verdadero campo de ingeniero. Esto causó que
se requira formar un nuevo tipo de ingeniero.
Existía una ausencia casi total de investigación
y de estimulo a la creatividad y la innovación.
El individualismo y la falta de solidaridad no facilitan el
trabajo en grupo ni las construcciones colectivas.
Uno de los principales problemas que
ocasionaron esta crisis, es la utilización de la
metodología derivada de programar-corregir
Con la aparición de internet, se implementaron los requerimientos no
funcionales. Tales como la escabilidad, la seguridad, tolerancia a fallas, el
manejo transaccional entre otros. Todos estos hacen de la construcción de
software un reto.
Esto ocasiona que haya una gran cantidad de proyectos que fallen,
sobrepasando los costos y los tiempos. Y así, clientes insatisfechos.
Ante esto, gracias al proceso unificado (UP) y en particular
(RUP) el desarrollo por ciclos es una buena estrategia de
construcción de software.
El proceso de software por equipos (TSP)
también basa su estrategia en ciclos
incrementales.
Los mitos
Los requerimientos son claros
desde el principio.
“se deben tener todos los requerimientos del
sistema claramente definidos antes de empezar
el proyecto para que éste sea exitoso”.
Es normal que el cliente y los usuarios no sepan los detalles de lo que quieren. También es
normal que una vez la aplicación esté en uso, aparezcan nuevas posibilidades o se
cuestionen los requerimientos
Lo correcto es manejar pocos requerimientos a la vez para
lograr una mayor focalización. Comenzar centrándose en lo que
le da valor al cliente.
Los diseños se pueden elaborar
de manera completa y validarse
antes de la construcción.
“diseñar completamente antes de empezar a programar para que sea más
efectiva la labor de programa- ción y más independiente”.
Es imposible hacer un diseño completo y detallado para un
conjunto de requerimientos incompletos y ambiguos.
Diseñar es todo un proceso de tomar decisiones sobre cómo
romper en partes (componentes, módulos, objetos, aspectos y
servicios)
El proceso de construcción
es predecible
No puede de ser predecible. ¿Cómo preveer cuántas veces el cliente va a
cambiar de opinión? ¿Cómo prever en qué momento nos vamos a dar
cuenta que al diseño le faltaba considerar la escabilidad?
cuando no hay claridad en los requerimientos y no se puede tener completos los
diseños, es una falacia pretender planificar en detalle el proyecto.
El plan inicial debe contener la estrategia, pero por cada ciclo es necesario disponer de un plan con más detalle y luego por cada semana, el detalle necesario
como para que se pueda hacer seguimiento, ver avance. Sobre los planes cortos no debería haber re-planeación. Se realiza en forma permanente, conduce a
que se pierda la oportunidad de analizar el estimado contra lo real y, lo más importante, la oportunidad de aprender.
hay gente bien entrenada y
especializada para la realización de
las distintas labores.
Es difícil conseguir personas bien entrenadas y especializadas en las distintas tecnologías, metodologías y procesos.
Tampoco están claro los roles, ¿Quién analiza es capaz de programar? ¿Quién dirige el proyecto sabe de dirección de
proyectos o de las tecnologías que se usan? ¿Quién diseña prueba? ¿El que programa habla con el cliente?
Se ha vuelto muy complicado encontrar gente calificada que pueda construir aplicaciones
utilizando las últimas tecnologías. Y por otro, los desarrolladores que manejan las últimas
tecnologías típicamente son los recién egresados que no tienen aún experiencia para
enfrentar problemas.
“se deben tener todos los requerimientos del
sistema claramente definidos antes de empezar
el proyecto para que éste sea exitoso”.