F A C U L T A D D E C I E N C I A S F Í S I C A S Y

M A T E M Á T I C A S

ESCUELA PROFESIONAL

ING. EN COMPUTACIÓN E INFORMÁTICA

TRABAJO:

Evolución de la Ingeniería De Software

DOCENTE:

Ing. Denny Fuentes Adrianzen.

INTEGRANTES:

Álvarez Vásquez, Hugo Custodio Garnique, Roberto Delgado Tello, Roberto Odar Millones, Kevin Velásquez Ñiquen, Pedro

PRESENTACIÓN:

Enero del 2015

LAMBAYEQUE – PERÚ

2

ÍNDICE

I. Introducción _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

03

II. Título del Tema _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

03

III. Objetivos _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

03

IV. Contenido del Tema _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

04

a. Retos de la Ingeniería del Software _ _ _ _ _ _ _ _

04

b. Evolución del Software: Crisis y Mitos _ _ _ _ _ _ _

04

c. Crisis del Software _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

07

d. Mitos del Software _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

10

3

e. Sistemas Heredados _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

13

f. Principios de la ingeniería de Software _ _ _ _ _ _

15

V. Conclusiones _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

19

VI. Bibliografía _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

19

VII. Linkografia _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

20

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

_ _ _

I. INTRODUCCIÓN:

El Software representa la vida interna de un computador, el manejo y aprovechamiento del mismo y todas las ventajas que se brindan el mundo de las computadoras, depende del software, facilitando a los usuarios el desarrollo de programas que contribuyen con tareas diarias tanto personales como generales, empresariales y organizacionales el software en sus diferentes tipos es el elemento esencial como interfaz entre usuario - computador, su historia desde un principio se muestra con poca atención pero con el paso del tiempo se ha tornado importante para los programadores y creadores de sistemas tanto de aplicación como operativos, todo lo que se ve digitalizado en un computador representa el software clasificado de alguna forma, las herramientas del menú inicio y todas aquellas que se despliegan al encendido del CPU, el desarrollo de esta herramienta ha permitido innovar en cuanto a la robótica he inteligencia

4

artificial facilitando el trabajo en determinadas áreas laborales y agilizando las mismas por ejemplo en la fabricación de vehículos mediante software de programación se diseñan estructuras robóticas inmensas y fuertes que realizan tareas que al brazo humano le tomarían más tiempo.

II. TITULO:

“EVOLUCIÓN DE LA INGENIERÍA DE SOFTWARE”

III. OBJETIVOS:

El uso eficiente del hardware. Facilidad para usar los recursos. Mejorar la calidad de los productos de software. Facilitar el control del proceso de desarrollo de software. Brindar mayor exactitud en los costos de proyectos y tiempo de desarrollo de los

mismos.

IV. CONTENIDO DEL TEMA:

RETOS DE LA INGENIERIA DEL SOFTWARE

En el siglo XXI, la ingeniería del software afronta tres retos fundamentales:

1.-El reto de la heterogeneidad: cada vez más, se requiere que los sistemas operen como sistemas distribuidos en redes que incluyen diferentes tipos de computadoras y con diferentes clases de sistemas de soporte. A menudo es necesario integrar software nuevo con sistemas heredados más viejos escritos en diferentes lenguajes de programación. El reto de la heterogeneidad es desarrollar técnicas para construir software confiable que sea lo suficientemente flexible para adecuarse a esta heterogeneidad.

5

2.-El reto de la entrega: muchas técnicas tradicionales de ingeniería del software consumen tiempo. El tiempo que éstas consumen es para producir un software de calidad. Sin embargo, los negocios de hoy en día deben tener una gran capacidad de respuesta y cambiar con mucha rapidez. Su software de soporte también debe cambiar con la misma rapidez. El reto de la entrega es reducir los tiempos de entrega para sistemas grandes y complejos sin comprometer la calidad del sistema.

3.-El reto de la confianza: puesto que el software tiene relación con todos los aspectos de nuestra vida, es esencial que podamos confiar en él. Esto es especialmente importante en sistemas remotos de software a los que se accede a través de páginas web o de interfaces de servicios web. El reto de la confianza es desarrollar técnicas que demuestren que los usuarios pueden confiar en el software.

Por supuesto, estos no son independientes. Por ejemplo, es necesario hacer cambios rápidos a los sistemas heredados para proveerlos de una interfaz de servicio web. Para tratar estos retos, necesitaremos nuevas herramientas y técnicas, así como formas innovadoras de combinación y uso de métodos de ingeniería del software existentes.

EVOLUCIÓN DEL SOFTWARE: CRISIS Y MITOS

Evolución del software

Durante los primeros años de la era de la computadora, el software se contemplaba como un añadido. La programación de computadoras era un <<arte de andar por casa>> para el que existían pocos métodos sistemáticos. El desarrollo del software se realizaba virtualmente sin ninguna planificación, hasta que los planes comenzaron a descalabrarse y los costos a crecer. Los programadores trataban de hacer las cosas bien, y con un esfuerzo heroico, a menudo salían con éxito.

1ra ERA

Durante los primeros años lo normal era que el hardware fuera de propósito general. Por otra parte, el software se diseñaba a medida para cada aplicación y tenía una distribución relativamente pequeña. El software como producto (es decir, programas desarrollados para ser vendidos a uno o más clientes) estaba en su infancia. La mayoría del software se desarrollaba y era utilizado por la misma persona u organización. La misma persona lo escribía, lo ejecutaba y, si fallaba, lo depuraba. Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban seguros de que esa persona estará allí cuando se encontrara algún error. Debido a este entorno personalizado del software, el diseño era un proceso implícito, realizado en la mente de alguien, y la documentación normalmente no existía.

2da ERA

6

La segunda era en la evolución de los sistemas de computadora se extiende desde la mitad de la década de los sesenta hasta finales de los setenta. La multiprogramación y los sistemas multiusuario introdujeron nuevos conceptos de interacción hombre-máquina. Las técnicas interactivas abrieron un nuevo mundo de aplicaciones y nuevos niveles de sofisticación del hardware y del software. Los sistemas de tiempo real podían recoger, analizar y transformar datos de múltiples fuentes, controlando así los procesos y produciendo salidas en milisegundos en lugar de en minutos. Los avances en los dispositivos de almacenamiento en línea condujeron a la primera generación de sistemas de gestión de bases de datos.

La segunda era se caracterizó también por el establecimiento del software como producto y la llegada de las <<casas de software>>. El software ya se desarrollaba para tener una amplia distribución en un mercado multidisciplinar. Los programas se distribuían para computadoras grandes y para minicomputadoras, a cientos e incluso a miles de usuarios.

Conforme crecía el número de sistemas informáticos, comenzaron a extenderse las bibliotecas de software de computadora. Las casas desarrollaban proyectos en los que se producían programas de decenas de miles de sentencias fuente. Los productos de software comprados al exterior incorporaban cientos de miles de nuevas sentencias. Una nube negra apareció en el horizonte. Todos esos programas, todas esas sentencias fuente tenían que ser corregidas cuando se detectaban fallas, modificadas cuando cambiaban los requisitos de los usuarios o adaptadas a nuevos dispositivos hardware que se hubieran adquirido. Estas actividades se llamaron colectivamente mantenimiento del software. El esfuerzo gastado en el mantenimiento del software comenzó a absorber recursos en una medida alarmante.

Aún peor, la naturaleza personalizada de muchos programas los hacía virtualmente imposible de mantener. Había comenzado una crisis del <<software>>.

3ra ERA

La tercera era en la evolución de los sistemas de computadora comenzó a mediados de los años setenta y continuó más allá de una década. El sistema distribuido, múltiples computadoras, cada una ejecutando funciones concurrentemente y comunicándose con alguna otra, incrementó notablemente la complejidad de los sistemas informáticos. Las redes de área local y de área global, las comunicaciones digitales de alto ancho de banda y la creciente demanda de acceso <<instantáneo>> a los datos, supusieron una fuerte presión sobre los desarrolladores del software. Aún más, los sistemas y el software que lo permitían continuaron residiendo dentro de la industria y de la academia. El uso personal era extraño.

La conclusión de la tercera era se caracterizó por la llegada y amplio uso de los microprocesadores. El microprocesador ha producido un extenso grupo de productos

7

inteligentes, desde automóviles hasta hornos de microondas, desde robots industriales a equipos de diagnósticos de suero sanguíneo, pero ninguno ha sido más importante que la computadora personal.

4ta ERA

La cuarta era de la evolución de sistemas informáticos se aleja de las computadoras individuales y de los programas de computadoras, dirigiéndose al impacto colectivo de las computadoras y del software. Potentes máquinas personales controladas por sistemas operativos sofisticados, en redes globales y locales, acompañadas por aplicaciones de software avanzadas se han convertido en la norma. Las arquitecturas informáticas están cambiando de entornos centralizados de grandes computadoras a entornos descentralizados cliente/servidor. Las redes de información en todo el mundo proporcionan una infraestructura que iguala a expertos y políticos en pensar sobre una <<superautopista de información>> y una <<conexión del ciberespacio>>. De hecho Internet se puede observar como un <<software>> al que pueden acceder usuarios individuales.

La industria del software ya es la cuna de la economía del mundo. Las decisiones tomadas por gigantes de la industria tales como Microsoft arriesgan billones de dólares. A medida que la cuarta generación progresa, han comenzado a surgir nuevas tecnologías. Las tecnologías orientadas a objetos están desplazando rápidamente los enfoques de desarrollo de software más convencionales en muchas áreas de aplicaciones. Los sistemas expertos y el software de inteligencia artificial han salido del laboratorio para entrar en aplicaciones prácticas de una gran variedad de problemas del mundo real. El software de redes neuronales artificiales junto con la aplicación de lógica difusa han abierto posibilidades excitantes para el reconocimiento de patrones y habilidades de procesamiento de información de carácter humano.

La programación de realidad virtual y los sistemas multimedia ofrecen formas radicalmente diferentes de comunicar información al usuario final. <<Los algoritmos genéticos>> ofrecen el potencial para el software que reside dentro de las computadoras biológicas masivamente en paralelo.

8

CRISIS DEL SOFTWARE

La crisis del software se fundamentó en el tiempo de creación de software, ya que en la creación del mismo no se obtenían los resultados deseados, además de un gran costo y poca flexibilidad.

Es un término informático acuñado en 1968, en la primera conferencia organizada por la OTAN sobre desarrollo de software, de la cual nació formalmente la rama de la ingeniería del software. El término se adjudica a F.L.Bauer, aunque previamente había sido utilizado por Edsger dijkstra, en su obra The Humble Programmer.

Básicamente, la crisis del software se refiere a la dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables. Las causas son, entre otras, la complejidad que supone la tarea de programar, y los cambios a los que se tiene que ver sometido un programa para ser continuamente adaptado a las necesidades de los usuarios.

Además, no existen todavía herramientas que permitan estimar de una manera exacta, antes de comenzar el proyecto, cuál es el esfuerzo que se necesitará para desarrollar un programa. Este hecho provoca que la mayoría de las veces no sea posible estimar cuánto tiempo llevará un proyecto, ni cuánto personal será necesario. Cuando se fijan plazos normalmente no se cumplen por este hecho. Del mismo modo, en muchas ocasiones el personal asignado a un proyecto se incrementa con la esperanza de disminuir el plazo de ejecución.

Por último, las aplicaciones de hoy en día son programas muy complejos, inabordables por una sola persona. En sus comienzos se valoró como causa también la inmadurez de la ingeniería de software, aunque todavía hoy en día no es posible realizar estimaciones precisas del coste y tiempo que necesitará un proyecto de software.

Englobó a una serie de sucesos que se venían observando en los proyectos de desarrollo de software:

Los proyectos no terminaban en plazo. Los proyectos no se ajustaban al presupuesto inicial. Baja calidad del software generado. Software que no cumplía las especificaciones. Código inmantenible que dificultaba la gestión y evolución del proyecto.

Aunque se han propuesto diversas metodologías para intentar subsanar los problemas mencionados, lo cierto es que todavía hoy no existe ningún método que haya permitido estimar de manera fiable el coste y duración de un proyecto antes de sus comienzos.

9

Factores que afectan:

Aumento del poder computacional. Reducción del costo del hardware. Rápida obsolescencia de hardware y software. Aceptación de la computarización en las empresas. Incremento en el número de usuarios de los sistemas de software. Tipo de usuario no homogéneo aun en sistemas hechos a la medida. Personal de desarrollado y mantenimiento diferente. La magnitud del proyecto impacta en: Tiempo costo y número de desarrolladores, Control administrativo y detalles técnicos Aumento en el conocimiento del problema.

En un trabajo de investigación me tocó exponer sobre "La crisis del Software" y quise compartir parte de la recopilación que hice.

La crisis del software es el hecho de que el software que se construye no solamente no satisface los requerimientos ni las necesidades pedidos por el cliente, sino que además excede los presupuestos y los horarios de tiempos. La industria del software no ha podido satisfacer la demanda, la complejidad del software producido y demandado se incrementa constantemente, el software es solicitado para ejecutar las tareas demandantes de hoy y está presente en todos los sistemas que van desde los más sencillos hasta los de misión crítica. Las aplicaciones de software son complejas porque modelan la complejidad del mundo real. En estos días, las aplicaciones típicas son muy grandes y complejas para que un individuo las entienda y, por ello, lleva gran tiempo implementar software.

Síntomas

Uno de los principales problemas en el desarrollo de software de hoy en día es que muchos proyectos empiezan la programación tan pronto se definen y concentran mucho de su esfuerzo en la escritura de código. Últimamente el desarrollo de software se ralentizado. El estudio de este fenómeno es importante porque la existencia de software científico libre facilita que cualquier laboratorio del mundo pueda desarrollar ciencia libre usando este software como herramienta de trabajo.

Algunos "síntomas" que indican que el software se encuentra en un periodo de crisis son:

Baja Calidad del Software.

Tiempo y Presupuesto Excedido.

Confiabilidad Cuestionable.

10

Altos Requerimientos de Personal para desarrollo y mantenimiento.

Factores de influencia

Para poder llevar el estado del proceso de software como un estado de crisis, los críticos han destacado ciertas características que han permitido esta postura del software respecto a otras etapas de su corta historia. Algunos de esos factores son:

Aumento del poder computacional Reducción del costo del hardware. Rápida obsolescencia de hardware y software. Aceptación de la computarización en las empresas. Incremento en el número de usuarios de los sistemas de software. Tipo de usuario no homogéneo aun en sistemas hechos a la medida. Personal de desarrollado y mantenimiento diferente. La magnitud del proyecto impacta en: Tiempo costo y número de desarrolladores, Control administrativo y detalles técnicos Aumento en el conocimiento del problema.

Cambios en el entorno Tecnológicos(Internet, redes, ERP, CRM, SCM) Económicos (crisis económicas, globalización, etcétera). Sociales (nuevas necesidades, costumbres nuevas, etcétera).

Posibles causas de la crisis del software

Hay varias razones que pueden ser propuestas como causa de la crisis. No son mutuamente excluyentes; de hecho, es posible que la verdadera causa sea una mezcla de todas ellas. Sin embargo, todas tienen en común que son causadas por el método de valorar los avances científicos y el mecanismo actual de financiación de la actividad científica. Las causas de la crisis del software fueron vinculadas a la complejidad en general del proceso de software y a la relativa inmadurez de la ingeniería de software como una profesión. La crisis se manifestó a sí misma en varias maneras:

Proyectos gestionados con un sobre-presupuesto. Proyectos gestionados con sobre tiempo. Software de baja calidad. El software a menudo no satisfacía los requerimientos deseados. Los proyectos fueron inmanejables, con un código difícil de mantener.

11

MITOS DEL SOFTWARE

¿Qué son los mitos?

Los mitos son creencias que se tienen sobre el software, tanto los desarrolladores como los que los emplean; poseen la característica de repetirse a lo largo del tiempo y pueden ser rastreados a los inicios de la computación. Una de las razones por las cuales estos mitos son tan populares radica en que parecen lógicos y en ocasiones son empleados por expertos en el tema.

Tipos de mitos

Se tienen identificados 3 categorías de mitos asociados al software. Mitos de la Administración Mitos del Cliente Mitos del Desarrollador

Mitos de la Administración.

Los administradores de proyectos de software normalmente deben preocuparse por garantizar que se cumplan los itinerarios, que se mantengan los costos y que todo funcione como fue planeado. Lo anterior genera una serie de presión que muchas veces provoca que ellos se aferren a mitos a manera de salvavidas liberador de estas situaciones estresantes.

MITO 1: Se tiene un libro con estándares y procedimientos para el desarrollo de software. Esto proporcionará todo el conocimiento necesario a mi personal

REALIDAD: Se puede tener el libro, pero ¿se está empleando?, ¿Los desarrolladores conocen su existencia?, ¿El libro está actualizado?, ¿Es claro?, ¿Está orientado al alcance de la calidad?

MITO 2: Si se tiene un retraso en el itinerario es factible contratar más programadores para terminar a tiempo

REALIDAD: El desarrollo de software no es un proceso mecánico que permita adicionar más personas para acelerar su desarrollo. De hecho es posible que vincular nuevo personal al proyecto provoque mayores contratiempos y retrasos, considerando el tiempo de capacitación y el acople al equipo del personal nuevo.

MITO 3: ¿Si dejo el desarrollo del proyecto de software a un tercero (subcontrato), puedo relajarme y dejar que esa compañía lo construya?

REALIDAD: No se puede descuidar el proyecto aunque se subcontrate, si una compañía no comprende cómo administrar y controlar sus proyectos de software de forma interna, sin lugar a

12

dudas se presentaran problemas cuando trate de efectuar una subcontratación.

Mitos del Cliente

Los clientes pueden llegar de cualquier lugar y tienen características muy diferentes, llegan con creencias predefinidas y mitos arraigados que en muchas oportunidades se explica por el poco esfuerzo de los profesionales del software por corregir esta desinformación. La presencia de estos mitos en el cliente produce falsas expectativas e insatisfacción con el trabajo del desarrollador.

MITO 1: Una descripción general de los objetivos es suficiente para iniciar los trabajos de construcción del software, los detalles se afinaran más adelante.

REALIDAD: No siempre se tendrá claridad con los objetivos, si estos presentan una ambigüedad producirán todo un desastre. La comunicación constante y efectiva entre el cliente y el desarrollador son la mejor manera de identificar los requerimientos del software.

MITO 2: Los requerimientos de un software cambian constantemente, pero esto no se considerará un problema y se ajustarán rápidamente porque el software es flexible.

REALIDAD: Es verdad que los requerimientos del software cambian, pero el impacto de estos cambios depende mucho del momento en que ellos ocurran. En etapas tempranas el costo de asimilar los cambios no son tan altos, pero a medida que las etapas están más adelantadas el cambio en los requerimientos puedo involucrar el adicionar más recursos y tiempos, incluso cambiar todo el software.

Mitos del Desarrollador

Los diferentes mitos que acompañan a los programadores se han mantenido durante muchos años. El desprenderse de estos mitos se hace difícil pues se vuelven un elemento de costumbre en los programadores.

MITO 1: Cuando el programa ha sido escrito y se colocó a funcionar, el trabajo quedó terminado.

REALIDAD: Entre el 60 y 80 % del trabajo se realiza posterior a la entrega al cliente (de acuerdo a estudios).

MITO 2: Mientras el programa no se esté ejecutando no hay forma de evaluar su calidad.

13

REALIDAD: El software se debe probar en cada una de sus etapas, esto con el fin de garantizar su calidad. Incluso desde el inicio del proyecto con las revisiones técnicas formales y la verificación de los requisitos dados por los clientes.

MITO 3: El único producto que debe entregarse para considerar un proyecto de software exitoso es el programa funcionando.

REALIDAD: El programa funcionando es solo una parte. La documentación del software permite garantizar su calidad, realizarle mantenimiento y transformarse en una guía para nuevos desarrolladores.

MITO 4: La ingeniería del software obliga a realizar documentación voluminosa he innecesaria, teniendo como resultado un proceso más lento.

REALIDAD: La ingeniería del software no es realizar documentación, es la búsqueda de calidad y con la calidad se reducen los trabajos redundantes lo que permite un proceso más ágil. Con ello el cliente no solo recibe a tiempo un producto si no tiene la garantía que el mismo es de calidad.

SISTEMAS HEREDADOS

Un sistema heredado (o sistema legacy) es un sistema informático (equipos informáticos o aplicaciones) que ha quedado anticuado pero continúa siendo utilizado por el usuario (típicamente una organización o empresa) y no se quiere o no se puede reemplazar o actualizar de forma sencilla.Los sistemas heredados no son sólo sistemas de software de aplicación. Son sistemas socio-técnicos, por lo que incluyen procesos de negocio, software de aplicación, software de apoyo y sistema hardware.Muchos sistemas heredados todavía se utilizan porque solucionan bien el problema y reemplazarlos sería demasiado costoso.

14

Las compañías gastan mucho dinero en sistemas informáticos y, para obtener un beneficio de esa inversión, el software o el hardware debe utilizarse varios años. El tiempo de vida de los sistemas informáticos es muy variable, pero muchos sistemas grandes se pueden llegar a utilizar hasta más de 20 años. Muchos de estos sistemas antiguos aún son importantes para sus respectivos negocios, es decir, las empresas cuentan con los servicios suministrados por estos sistemas y cualquier fallo en estos servicios tendría un efecto serio en el funcionamiento de la organización. Estos sistemas antiguos reciben el nombre de sistemas heredados.

PARTES LOGICAS DE UN SISTEMA HEREDADO Y SUS RELACIONES

1.1 Sistema Hardware: en muchos casos, los sistemas heredados se crearon para hardware mainframe que ya no está disponible, es costoso de mantener y no está compatible con las actuales políticas de compras de IT organizacionales.

1.2 Software de Apoyo: los sistemas heredados cuentan con una gran variedad de software de apoyo que va desde sistemas operativos y utilidades suministradas por el fabricante de hardware hasta los compiladores utilizados para el desarrollo de sistemas. De nuevo, estos pueden ser obsoletos o ya no recibir soporte de sus proveedores originales.

1.3 Software de aplicación: el sistema de aplicación que proporciona los servicios de negocio por lo general está compuesto de varios programas independientes desarrollados en momentos diferentes, algunas veces, el término sistema heredado significa este software de aplicación en lugar del sistema completo.

1.4 Datos de aplicación: son los datos procesos por el sistema de aplicación. En muchos sistemas heredados, se ha acumulado un inmenso volumen de datos a lo largo del tiempo de vida del sistema. Estos datos pueden ser incongruentes y estar duplicados en varios archivos.

1.5 Procesos de Negocio: son los procesos utilizados en los negocios para lograr algún objetivo del negocio. Un ejemplo de un proceso de negocio en una compañía de seguros seria emitir una política de seguros; en una fábrica, un proceso de negocio seria aceptar un pedido para los productos y estipular el proceso de fabricación asociado. Los procesos de negocio pueden ser diseñados alrededor de un sistema heredado y restringirlos por la funcionalidad que este proporciona.

1.6 Políticas y reglas de negocio: son las definiciones de cómo llevar a cabo los negocios y las restricciones sobre estos. La utilización del sistema de aplicación heredado está contenida en estas políticas y reglas.

15

2. Riesgos de un sistema heredado

Los sistemas heredados son considerados potencialmente problemáticos por numerosos ingenieros de software por diversos motivos. Dichos sistemas a menudo operan en ordenadores obsoletos y lentos, cuyo mantenimiento tiene elevados costes y son difíciles de actualizar por falta de componentes adecuados o de mantenimiento.

3. Costes de mantenimiento de un sistema heredado

Seguir utilizando los sistemas heredados evita los mencionados riesgos del reemplazo, pero hacer cambios al sistema existente en vez de cambiarlo por uno más moderno puede ser más costoso puesto que éste es cada vez más viejo.

4. Alternativas

Los negocios que tienen sistemas informáticos anticuados se enfrentan a un dilema fundamental. Si continúan utilizando los sistemas heredados y realizan los cambios requeridos, sus costos se incrementarán de forma inevitable. Si deciden reemplazar sus sistemas heredados con nuevos sistemas, esto tendrá un coste y puede ocurrir que los nuevos sistemas no provean apoyo efectivo al negocio como lo hacen los sistemas heredados.

5. Mantener el sistema heredado

Muchos negocios están buscando técnicas de ingeniería de software que prolonguen el tiempo de vida de los sistemas heredados y que reduzcan los costos de seguir utilizando estos sistemas

Los sistemas heredados son considerados por las organizaciones de TI como elementos destacados dentro del nuevo concepto de empresa. Los usuarios ya no preguntan cómo librarse de sus sistemas heredados, sino que buscan formas para aprovechar el valor de negocio de estos sistemas heredados.

PRINCIPIOS DE INGENIERÍA DE SOFTWARE

16

Apuntan al proceso de ingeniería y el producto final: el proceso correcto ayudará a obtener el producto correcto. Asimismo, el producto afectará la elección de qué proceso usar.

Los principios son afirmaciones abstractas que describen propiedades deseables del proceso y del producto. Para aplicarlas, los ingenieros deben contar con métodos y técnicas que incorporen dichos principios.

Métodos: guías para la ejecución de alguna actividad, aproximaciones rigurosas, sistemáticas y disciplinadas.

Técnicas: son más mecánicas que los métodos y tienen aplicabilidad más restringida.

Rigor y formalidad.

El rigor es un complemento de la creatividad en la ingeniería. Con la aproximación rigurosa podremos tener productos más confiables y mejores controles (de tiempo, costos, etc.). El rigor mejora la creatividad, optimizando la confianza en los resultados creativos, una vez analizados en base a una planificación rigurosa.

Hay varios grados de rigurosidad. El más alto es la formalidad, que es un requerimiento más restrictivo que el rigor, que exige que el proceso de software sea dirigido y evaluado con leyes matemáticas. La formalidad implica rigor, pero uno puede ser riguroso e informal.

En ingeniería, el proceso de diseño son pasos bien definidos y con bases sólidas. En cada paso el ingeniero sigue algún método o técnica basados en resultados teóricos de un modelado formal de la realidad o en ajustes empíricos de fenómenos no considerados por el modelo, o en reglas heurísticas que dependen de la experiencia. Todo está resuelto en una aplicación rigurosa y sistemática (metodología), fácilmente explicada y aplicada una y otra vez.

El ingeniero debe saber cómo y cuándo ser formal, además de entender el nivel de rigurosidad y formalidad a alcanzar, dependiendo de la dificultad de la tarea y su criticidad. Ej.: podemos ser muy formales para las partes críticas de un problema y para las partes estandarizadas aplicar una aproximación más simple.

El rigor y la formalidad benefician también la mantenibilidad, reusabilidad, portabilidad, comprensión e interoperabilidad del software. Ej.: la documentación nos permite prever la evolución del proyecto, los recursos a usar, etc., así como nos ayuda a mantener el producto, al usarla para cualquier modificación que se requiera; y por último nos permite monitorear el software en forma precisa, para garantizar el cumplimiento de los puntos de control y mejorar la productividad.

17

Separación de intereses.

Es involucrarse con distintos aspectos de un problema para concentrarse en ellos separadamente. En cada proyecto debemos separar aspectos: primero, aislar los factores relacionados más débilmente y luego considerar los factores en la medida en que impactan el análisis.

Separación en base al tiempo: permite planificar las actividades de manera precisa.

Separación en términos de calidades: manejar separadamente la eficiencia y la corrección de un programa, diseñando software cuidadoso y estructuradamente, tal que su corrección esté garantizada a priori y luego reestructurada para mejorar su eficiencia.

Separación por vistas: separar los datos que fluyen de una actividad a otra en el flujo de control que gobierna la sincronización de las actividades.

La separación implica separación de responsabilidades para tratar los distintos aspectos. Es la base para la asignación del trabajo en asignaciones específicas para distintas personas con distintas habilidades.

Modularidad.

División de un sistema en partes más simples (módulos). Esto nos permite separar los contextos en fases: cuando relacionamos cada módulo aislado y cuando relacionamos todos los módulos globalmente, analizando sus conexiones e integración.

Objetivos de la modularidad:

Capacidad de descomposición de un sistema complejo: división del problema original en subproblemas y luego dividir cada subproblema.

Composición de un sistema a partir de componentes existentes: partir de componentes elementales hasta llegar al sistema terminado. Cuando un componente falla, se reemplaza por uno nuevo. Podemos usar módulos de una biblioteca, que al ser reutilizables, aceleran el proceso de construcción.

Comprensión del sistema mirándolo en partes: Nos facilita la reparación y modificación, al buscar los errores en un componente en particular.

Para lograr los tres objetivos, los módulos deben tener:

Alta cohesión: sus elementos internos están muy relacionados y agrupados por razones lógicas.

Bajo acoplamiento: es la relación entre módulos y mide la interdependencia entre 2 módulos. La idea es lograr que los módulos tengan un nivel bajo.

Las estructuras que cumplan esto nos permiten ver los módulos como cajas negras cuando describimos la estructura total y verlos separadamente cuando analizamos la funcionalidad de cada uno.

18

Abstracción.

Es identificar los aspectos importantes de un fenómeno e ignorar los detalles. Esto depende de cada persona o de cada enfoque o propósito que se le dé a un problema.

Los modelos que construimos son abstracciones de la realidad, válidas también para modelos de software. Los lenguajes de programación son abstracciones que nos permiten construir sin preocuparnos por los detalles de hardware.

Este principio es importante para aplicarlo a productos y procesos software. Cuando la documentación de un programa o procedimiento se analiza, se supone que suministra toda la información necesaria para entender las otras partes del programa que usan ese procedimiento.

Anticipación al cambio.

Se refiere a la mantenibilidad. Es poder predecir los cambios y trabajar para que los cambios futuros sean fáciles de aplicar. Esto es importante en el software, ya que los productos están en ambientes donde permanentemente surgen nuevos requerimientos.

La reusabilidad también se ve afectada por esto. Un componente es reusable si se puede emplear para generar un nuevo producto o si solo requiere pequeños cambios para ello. La reusabilidad es la capacidad de evolucionar que tienen los componentes. Para anticiparse al cambio debemos contar con herramientas de administración de versiones y revisiones de software. Debemos poder almacenar y recuperar información, módulos fuente y objetos, todo desde una base de datos central.

Asimismo se afecta al proceso de software, al considerar el mantenimiento de una aplicación y asignando estructura y costos para apoyar la evolución del software.

Generalidad.

Poder descubrir un problema más general en la resolución de un primer problema. Este puede ser menos complejo y proveer soluciones reutilizables. Puede surgir de un paquete ya existente o lo podemos crear nosotros.

Sin embargo, puede ser más costoso en términos de velocidad de ejecución, requerimientos de memoria o tiempos de desarrollo. Este principio es fundamental si se busca desarrollar herramientas software para uso amplio en el mercado.

Si el problema puntual se puede reformular como una instancia de un problema general, es conveniente adoptar el paquete en vez de una solución específica.

Incrementalidad.

19

Desarrollar paso a paso con incrementos, logrando aproximaciones sucesivas. Esto nos da un proceso evolutivo.

Debemos identificar subconjuntos primarios útiles para desarrollar y distribuir a los clientes, de manera de obtener realimentación temprana. Esto nos permite que la aplicación evolucione de manera controlada, en casos donde los requerimientos iniciales no se comprendieron bien.

Las etapas intermedias son prototipos del producto final, lo cual beneficia el entendimiento de los requerimientos y permite usar un modelo de desarrollo iterativo más flexible.

Debemos tener mucho cuidado en la manipulación de documentos, programas, datos de prueba y todo lo que usemos en las distintas versiones. Cada paso incremental significativo debe ser registrado.

V. CONCLUSIONES

El software se ha convertido en el elemento clave de la evolución de los sistemas y productos informáticos.

En las pasadas cuatro décadas, el software ha pasado de ser una resolución de problemas especializadas y una herramienta de análisis de información, a ser una industria por sí misma. Pero la temprana cultura e historia de la programación ha creado un conjunto de problemas que persisten todavía.

El software se ha convertido en un factor que limita la evolución de los sistemas informáticos.

El software se compone de programas, datos y documentos. Cada uno de estos elementos componen una configuración que se crea como parte del proceso de la Ingeniería del Software. El intento de la Ingeniería del Software es proporcionar un marco de trabajo para construir software con mayor calidad.

20

VI. BIBLIOGRAFÍA

PRESSMAN, ROGER S., Ingeniería de software, un enfoque práctico,

sexta edición. Editorial McGrawHill, México, año 2006 (Libro de texto).

Requirements Engineering: From System Goals to UML Models to

Software Specifications

o Axel van Lamsweerde Wiley, 2009

Piattini et al., 2007. Análisis y diseño de Aplicaciones Informáticas de

Gestión. Una perspectiva de Ingeniería del Software. Ra-Ma. Junio

2007.

VII. LINKOGRAFÍA

http://www.monografias.com/trabajos73/evolucion-software/evolucion-

software.shtml

http://es.slideshare.net/josefabiandiazs/mitos-del-software-30680129

http://es.slideshare.net/marfonline/evolucion-de-la-ingenieria-de-software

http://acis.org.co/ingesoftware/?p=1

https://books.google.com.pe/books?

id=gQWd49zSut4C&pg=PA35&dq=sistemas+heredados+de+la+ingenieria+de+soft

ware&hl=es419&sa=X&ei=vP2qVOLqKMm_ggSs2oPQBw&redir_esc=y#v=onepag

e&q=sistemas%20heredados%20de%20la%20ingenieria%20de

%20software&f=false