25501610
Description
Mind Map by ANDRES CAMILO YANEZ ESCOBAR, updated more than 1 year ago
|
Created by ANDRES CAMILO YANEZ ESCOBAR
over 3 years ago
|
|
Ingeniería de Software
- Evolución
- 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.
- ¡¡Prueba y Error!!
- 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
- Por esto, nace el término de
Ingeniería del Software, en una
conferencia financiada por la OTAN
- Los errores tenían que ser corregidos
apenas se detectaban fallas, y los
programas cambiaban al cambiar los
requisitos
- Aparece el concepto
Hombre-Máquina
- 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)
- La industria del software se
convierte en la cuna de la
economía mundial
- 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.
- Se implementa el
lenguaje de
modelado (UML)
- 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
- Dispositivos como celulares,
PDAs entre otros, se
involucran en el ciclo de vida.
- 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
- Ideas como "reutilización de
código" y "arquitectura de
software" se van planteando
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- “se deben tener todos los requerimientos del
sistema claramente definidos antes de empezar
el proyecto para que éste sea exitoso”.
- 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)
- Es imposible hacer un diseño completo y detallado para un
conjunto de requerimientos incompletos y ambiguos.
- “diseñar completamente antes de empezar a programar para que sea más
efectiva la labor de programa- ción y más independiente”.
- 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.
- 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.
- 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?
- 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 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.
- 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 deben tener todos los requerimientos del
sistema claramente definidos antes de empezar
el proyecto para que éste sea exitoso”.
- Los requerimientos son claros
desde el principio.
Want to create your own Mind Maps for free with GoConqr? Learn more.