Loading [MathJax]/jax/output/HTML-CSS/fonts/TeX/fontdata.js
null
US
Info
Ratings
Comments
Mind Map
by
ANDRES CAMILO YANEZ ESCOBAR
, created
more than 1 year ago
Mapa conceptual sobre la evolución e impacto de la Ingeniería de Software
Pinned to
114
0
0
No tags specified
ingeniería de software
evolución ingeniería de software
impacto ingeniería de software
Created by
ANDRES CAMILO YANEZ ESCOBAR
over 4 years ago
Rate this resource by clicking on the stars below:
(0)
Ratings (0)
0
0
0
0
0
0 comments
There are no comments, be the first and leave one below:
To join the discussion, please
sign up for a new account
or
log in with your existing account
.
Close
25501610
mind_map
2020-09-12T23:23:08Z
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.
1970 Surge la multi-programación y los
sistemas multi-usuario.
¡¡Prueba y Error!!
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.
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
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
Manifiesto ágil, como intento
de simplificar la complejidad
de las metodologías
existentes
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.
Solo el programador conocía
y entendía su código.
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.
Los mitos
Los requerimientos son claros
desde el principio.
Los diseños se pueden elaborar
de manera completa y validarse
antes de la construcción.
El proceso de construcción
es predecible
hay gente bien entrenada y
especializada para la realización de
las distintas labores.
“se deben tener todos los requerimientos del
sistema claramente definidos antes de empezar
el proyecto para que éste sea exitoso”.
“diseñar completamente antes de empezar a programar para que sea más
efectiva la labor de programa- ción y más independiente”.
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?
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?
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.
“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 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)
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.
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.
Double click this node
to edit the text
Click and drag this button
to create a new node
New
0
of
0
Go to link
Track All
Untrack All
25501610
mind_map
2020-09-12T23:23:08Z
You need to log in to complete this action!
Register for Free
