1.1 El software y su importancia.

1.1.1 Evolución del Software.

Para que el hardware o parte del material de una computadora pueda funcionar, es necesario tener un conjunto de normas y órdenes para coordinar todos los procesos que realicen. Este conjunto se denomina Software o parte inmaterial del sistema. Gracias al Software (integrado por multitud de programas que interactúan unos con otros) pueden ser manejados todos los recursos de que dispone un sistema para resolver cualquier aplicación Informática.

El software es el material que convierte a una computadora en una herramienta. Sin el software, una computadora es justo un grande, caro, inútil, pedazo corto y grueso de plástico, acero y silicón.

El software es lo que hace a una computadora compórtese la manera que se necesita. Por ejemplo, el software del procesador de palabras (Word) hace a la computadora comportarse como una máquina de escribir. El software de un sistema informático es el conjunto de elementos lógicos necesarios para realizar las tareas encomendadas al mismo.

Podemos definirlo del siguiente modo: El software es la parte lógica que dota al equipo físico de capacidad para realizar cualquier tipo de trabajos.

Para nombrar al software de un modo más formal tomaremos la siguiente definición:

Software: Definido por la IEEE como "programas de computadora, procedimientos, documentación asociada y datos relativos a la operación de un sistema informático".

1.1.1 Evolución del Software.

Las etapas de evolución que sufrió el software a través de los años se peden clasificar como a continuación se muestra:

Primera 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.

Segunda era:

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 conocimientos 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 del software . El software ya se desarrollaba para tener una amplia distribución en un mercado multidisciplinario. Los programas se distribuían para computadoras grandes y para minicomputadoras, a cientos e incluso a miles de usuarios.

Tercera era:

La tercer 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 ejecutando funciones concurrentemente

y comunicándose con alguna otra, incremento notablemente la complejidad de los sistemas informáticos .

Las redes de área local y de área global, las comunicaciones digitales de alto y ancho de banda y la creciente demanda de acceso instantaneo 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 se caracterizó por la llegada y amplio uso de los microprocesadores. El microprocesador ha producido un extenso grupo de productos inteligentes, desde automóviles hasta hornos de microondas, desde robots industriales hasta equipos de diagnóstico de suero sanguíneo, pero ninguno ha sido más importante que la computadora personal.

Cuarta 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. De hecho Internet se puede observar como un software al que pueden acceder usuarios individuales.

Resumen de la evolución del Software:

Primera Era Segunda Era Tercera Era Cuarta Era

Orientación por lotes (batch).

Distribución Limitada.

Software a medida.

Multiusuario.

Tiempo Real.

Bases de Datos.

Producto de software.

Sistemas Distribuidos.

Incorporación de "Inteligencia"

Hardware de bajo costo.

Impacto en el consumo.

Sistemas personales potentes.

Tecnologías Orientadas a Objetos.

Sistemas expertos.

Computación en Paralelo.

Redes de computadora

Sin embargo, un conjunto de problemas relacionados con el software ha persistido a través de la evolución de los sistemas basados en computadora, y estos problemas continúan aumentando.

1. Los avances del software continúan dejando atrás nuestra habilidad de construir software para alcanzar el potencial del hardware.

2. Nuestra habilidad de construir nuevos programas no pueden ir al ritmo de la demanda de nuevos programas, ni podemos construir programas lo suficientemente rápido como para cumplir las necesidades del mercado y de los negocios.

3. El uso extenso de computadoras ha hecho de la sociedad cada vez más dependiente de la operación fiable del software. Cuando el software falla, pueden ocurrir daños económicos enormes y ocasionar sufrimiento humano.

4. Luchamos por construir software informática que tenga fiabilidad y alta calidad.

5. Nuestra habilidad de soportar y mejorar los programas existentes se ve amenazada por diseños pobres y recursos inadecuados.

.2 Características y Aplicaciones.

1.2.1 Evolución hacia la Industria del Software.

Características del software

Para poder comprender lo que es el software (y consecuentemente la ingeniería del software) es importante examinar las características del software que lo diferencian de otras cosas que los hombres pueden construir. El software es un elemento del sistema que es lógico, en lugar de físico, por tanto el software tiene unas características considerablemente distintas a las del hardware:

1. El software se desarrolla, no se fabrica en sentido clásico. Aunque existen similitudes en el desarrollo del software y la construcción del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la buena calidad se adquiere mediante un buen diseño, pero la fase de construcción del hardware puede introducir problemas de calidad que no existen (o son fácilmente corregibles) en el software. Ambas actividades dependen de las personas, pero la relación entre las personas dedicadas y trabajo realizado es completamente diferente para el software. Ambas actividades requieren la construcción de un "producto", pero los métodos son diferentes.

2. El software no se "estropea". El hardware exhibe relativamente muchos fallos al principio de su vida (estos fallos son atribuibles normalmente a defectos del diseño o de la fabricación); una vez corregidos los defectos, la tasa de los fallos cae hasta un nivel estacionario (bastante bajo con un poco de optimismo) donde permanece durante un cierto periodo de tiempo. Sin embargo, conforme pasa el tiempo, los fallos vuelven a presentarse a medida que los componentes del hardware sufren los efectos acumulativos de la sociedad, la vibración. Los malos tratos, las temperaturas extremas y muchos otros males externos. Sencillamente, el hardware comienza a estropearse. El software no es susceptible a los males del entorno, que hacen que el hardware se estropee. Por tanto, los defectos no detectados harán que falle el programa durante las primeras etapas de su vida. Una vez que se corrigen estos errores, se llega a un nivel optimo de trabajo y podemos afirmar que el software no se estropea. ¡Pero se deteriora!. Esto que parece una contradicción, durante su vida el software, sufre cambios (mantenimiento). Conforme se hacen los cambios, es bastante probable que se introduzcan nuevos defectos, lentamente, el nivel mínimo de fallos comienza a crecer, el software se va deteriorando debido a los cambios. Otro aspecto de ese deterioro ilustra la diferencia entre el hardware y el

software. Cuando un componente de hardware se estropea, se sustituye por una "pieza de repuesto". No hay piezas de repuesto para el software. Cada fallo en el software indica un error en el diseño o en el proceso mediante el que se tradujo el diseño a código máquina ejecutable. Por tanto, el mantenimiento del software tiene una complejidad considerablemente mayor que la del mantenimiento del hardware.

3. La mayoría del software se construye a medida, en vez de ensamblar componentes existentes. Se puede comprar software ya desarrollado pero sólo como una unidad completa, no como componentes que pueden reensamblarse en nuevos programas. Aunque se ha escrito mucho sobre "Reutilización de Sotware" sólo estamos comenzando a ver la primera implementaciones con éxito de este concepto.

Aplicaciones del software

El software puede aplicarse en cualquier situación en la que se haya definido previamente un conjunto especifico de pasos procedimientos (es decir, un logaritmo). El contenido y determinismo de la información son factores importantes a considerar para determinar la naturaleza de una aplicación del software. El contenido se refiere al significado y a la forma de la información de entrada y de salida. Algunas veces es difícil establecer categorías genéricas para las aplicaciones del software que sean significativas. Las siguientes áreas del software indican la amplitud de as aplicaciones potenciales:

Software de sistemas. El software de sistemas es un conjunto de programas que han sido escritos para servir a otros programas. Algunos programas de sistemas (p. Ej.: compiladores, editores y utilidades de gestión de archivos) procesan estructuras de información complejas pero determinadas. Otras aplicaciones de sistemas (p. Ej.: ciertos componentes del sistema operativo, utilidades de manejo de periféricos, procesadores de telecomunicaciones) procesan datos en gran medida indeterminados. En cualquier caso el área del software de sistemas se caracteriza por una fuerte interacción con el hardware de la computadora; una gran utilización por múltiples usuarios; una operación concurrente que requiere una planificación, una comparación de recursos y una sofisticada gestión de procesos; unas estructuras de datos complejas y múltiples interfaces externas.

Software de tiempo real. El software que mide/analiza/controla sucesos del mundo real conforme ocurren, se denomina de tiempo real. Entre los elementos del software de tiempo real se incluyen: un componente de adquisición de datos que recolecta y da formato a la información recibida del entrono externo, un componente de análisis que transforma la información según lo requiera la aplicación, un componente de control/salida que responda al entorno externo y un componente de monitorización que coordina todos los demás componentes, de forma que pueda mantenerse la respuesta en tiempo real (típicamente en el rango

de 1 milisegundo a 1 minuto). Un sistema de tiempo real debe responder dentro de unas ligaduras estrictas de tiempo.

Software de gestión. El procesamiento de información comercial constituye la mayor de las áreas de aplicación del software. Los sistemas discretos (p. Ej.: nóminas, cuentas de haberes/débitos, inventarios, etc.) han evolucionado hacia el software de sistemas de información de gestión (SIG), que accede a una o más bases de datos grandes que contienen información comercial. Las aplicaciones en esta área reestructuran los datos existentes para facilitar las operaciones comerciales o gestionar la toma de decisiones. Además de las tareas convencionales de procesamiento de datos, las aplicaciones de software de gestión también realizan cálculo interactivo (p. Ej.: procesamiento de transacciones en puntos de ventas).

Software de ingeniería y científico. El software de ingeniería y científico esta caracterizado por los algoritmos de manejo de números. Las aplicaciones van desde la astronomía a la vulcanología, desde el análisis de la presión de los automotores a la dinámica orbital de las lanzaderas espaciales y desde la biología molecular a la fabricación automática. Sin embargo, las nuevas aplicaciones del área de ingeniería/ciencia se han alejado de los algoritmos convencionales numéricos.

Software empotrado. Los productos inteligentes se han convertido en algo común en casi todos los mercados de consumo e industriales. El software empotrado reside en memoria de sólo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo. El software empotrado puede ejecutar funciones muy limitadas y curiosas (p. Ej.: el control de las teclas de un horno de microondas) o suministrar una función significativa y con capacidad de control (p. Ej.: funciones digitales en un automóvil, tales como control de gasolina, indicaciones en el salpicadero, sistemas de frenado, etc.).

Software de computadoras personales. El mercado del software de computadoras personales ha germinado en la pasad década. El procesamiento de textos, las hojas de cálculo, los gráficos por computadora, multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras, de negocios y personales, y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones.

Software de Inteligencia Artificial. El software de inteligencia artificial (IA) hace uso de algoritmos no numéricos para resolver problemas complejos para los que no son adecuados el cálculo o el análisis directo. Actualmente, el área más activa de la IA es la de los sistemas expertos, también llamados sistemas basados en el conocimiento. Sin embargo, otras áreas de aplicación para el software de IA es el reconocimiento de patrones (imágenes y voz), la prueba de teoremas y juegos. En los últimos años se ha desarrollado una rama del software de IA llamada redes neuronales artificiales.

1.2.1 Evolución hacia la Industria del Software

A inicios de la informática la preocupación de desarrollo se centraba en el hardware, se buscaba mejorar su costo y eficiencia; el software era visto como un "complemento", se vivía la época de desarrollo de software como "ARTE" , el desarrollo del software estaba supeditado a la disponibilidad de recursos, de programas, de hardware y a la concepción y capacidad del programador. En este contexto surgieron problemas tanto para el programador como par los usuarios.

Problemas para el Usuario Problemas para el Desarrollador

Gran inversión en aprendizaje, pues el software resultaba difícil de manejar, los usuarios a parte del costo del software, debían incurrir en costos de capacitación.

Mantenimiento del Software caro.

Sistemas independientes, no se enlazaban unos con otros "ni siquiera dentro de un departamento" por lo que pensar en enlazar sistemas con otras empresas era imposible.

Programas de software complejos y difíciles de comprender.

Reutilización de código muy limitada.· Mantenimiento complejo.

Aplicaciones no portables, el software se desarrollaba para funciones en un determinado equipo; las plataformas eran independientes, las tecnologías propietarias.

El software desarrollado no era amigable, el diseño y la interfaz variaban según la aplicación.

Hoy en día, el software agrega valor a la empresa, pues es uno de los principales encargados del manejo de la información. Vivimos en le "era de la información" , las empresas se preocupan por la correcta administración de su información, la tecnología de información desempeña función primordial en las organizaciones, convirtiéndose en el factor que marca la diferencia para el logro de "ventaja competitiva" . Así, el software realizó su propia revolución industrial, variando en su entorno de tal manera que es inconcebible cometer los errores de desarrollo que se presentaban en la época del desarrollo de software como "Arte".

1.3 Mitos del Software

Muchas de las causas de las crisis del software se pueden encontrar en una mitología que surge durante los primeros años del desarrollo del software. Hoy, la mayoría de los profesionales competentes consideran a los mitos por lo que son actitudes erróneas que han causado serios problemas, tanto a los gestores como a los técnicos. Sin embargo, las viejas actitudes y hábitos son difíciles de modificar, y todavía se cree en algunos restos de los mitos del software.

Mitos de gestión.

Los gestores con responsabilidad sobre el software, como los gestores en la mayoría de las disciplinas, están normalmente bajo la presión de cumplir los presupuestos, hacer que no se retrase el proyecto y mejorar la calidad.

Mito.

Tenemos ya un libro que esta lleno de estándares y procedimientos para construir software. ¿No le proporciona ya a mi gente todo lo que necesita saber?.

Realidad.

Esta muy bien que el libro exista, pero ¿se usa?, ¿conocen los trabajadores su existencia?, ¿refleja las prácticas modernas de desarrollo de software?, ¿es completo?. En muchos casos, la respuesta a todas estas preguntas es "no".

Mito.

Mi gente dispone de las herramientas de desarrollo de software más avanzadas, después de todo, les compramos las computadoras más modernas.

Realidad.

Se necesita mucho más que el último modelo de computadora grande (o de PC) para hacer desarrollo de software de gran calidad. Las herramientas de ingeniería del software asistida por computadora (CASE), aunque la mayoría todavía no se usen, son más importantes que el hardware para conseguir buena calidad y productividad.

Mito.

Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido (el llamado algunas veces "concepto de la horda mongoliana").

Realidad.

El desarrollo de software no es un proceso mecánico como la fabricación. En palabras de Brooks [BRO75]: << ... añadir gente a un proyecto de software retrasado lo retrasa aún más>>. Al principio, esta declaración puede parecer un contra sentido. Sin embargo, cuando se añaden nuevas personas, le necesidad de aprender y comunicarse con el equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo productivo. Puede añadirse gente, pero sólo de una manera planificada y bien coordinada.

Mitos del cliente.

Un cliente que solicita una aplicación de software puede ser una persona del despacho de al lado, un grupo técnico de la sala de abajo, el departamento de ventas o una compañía exterior que solicita un software bajo contrato. Los mitos conducen a que el cliente se cree una falsa expectativa y finalmente, quede insatisfecho con el que desarrolla el software.

Mito.

Una declaración general de los objetivos es suficiente para comenzar a escribir los programes; podemos dar los detalles más adelante.

Realidad.

Una mala definición inicial es la principal causa del trabajo baldío en software. Es esencial una descripción formal y detallada del ámbito de la información, funciones, rendimiento, interfaces, ligaduras del diseño y criterios de validación. Estas características pueden determinarse sólo después de una exhaustiva comunicación entre el cliente y el analista.

Mito.

Los requisitos del proyecto cambian continuamente, pero os cambios pueden acomodarse fácilmente, ya que el software es flexible.

Realidad.

Es verdad que los requisitos del software cambian, pero el impacto del cambio varía según el momento en que se introduzca. La Figura 1.5 ilustra el impacto de los cambios. Si se pone cuidado al dar la definición inicial, los cambios solicitados al principio pueden acomodarse fácilmente. El cliente puede revisar los requisitos y recomendar las modificaciones con relativamente poco impacto en el costo. Cuando los cambios se solicitan durante el diseño del software, el impacto en el costo crece rápidamente. Ya se han acordado los recursos a utilizar y se ha establecido un esqueleto del diseño. Los cambios pueden producir trastornos que

requieran recursos adicionales e importantes modificaciones del diseño; es decir, costo adicional. Los cambios en la función, rendimiento, interfaces u otras características, impacto importante sobre el costo. Cuando se solicitan al final de un proyecto, los cambios pueden producir un orden de magnitud más caro que el mismo cambio pedido al principio.

Mitos de los desarrolladores.

Los mitos en los que aún creen muchos desarrolladores se han ido fomentando durante cuatro décadas de cultura informática. Durante los primeros días del desarrollo del software, la programación se veía como un arte. Las viejas formas y actitudes tardan en morir.

Mito.

Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado. Realidad. Alguien dijo una vez: << cuanto más pronto se comience a escribir código, tardara en terminarlo >>. Los datos industriales indican que entre el cincuenta y el sesenta por ciento de todo el esfuerzo dedicado a un programa se realizará después de que se le haya entregado al cliente por primera vez.

Mito.

Hasta que no tengo el programa << ejecutándose >> realmente no tengo forma de comprobar su calidad.

Realidad.

Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar la calidad del software: la revisión técnica formal. La revisión del software es un << filtro de calidad >> que se ha comprobado que es más efectivo que la prueba, para encontrar ciertas clases de defectos en el software.

Mito.

Lo único que se entrega al terminar el proyecto es el programa funcionando.

Realidad.

Un programa funcionando es sólo parte de una configuración del software que incluye programas, documentos, y datos. La documentación es la base de un buen desarrollo y, lo que es más importante, proporciona guías para la tarea de mantenimiento del software.

Mucho profesionales del software reconocen la falacia de los mitos descritos anteriormente. Lamentablemente, las actitudes y métodos habituales, fomentan una pobre gestión y malas prácticas técnicas, incluso cuando la realidad dicta un método mejor. El reconocimiento de la s realidades del software es el primer paso hacia la formulación de soluciones practicas para su desarrollo.

1.4 Ingeniería del Software.

La respuesta más concreta contra la creación y la generalización de nuevos mitos se encuentra en la ceración de una rama de la ingeniería que se encargará de las cuestiones que atañen al software, de esta manera surge la ingeniería del software:

[La ingeniería del software] es el establecimiento y uso de principios robustos de la ingeniería a fin de obtener económicamente software que sea fiable y que funcione eficientemente sobre máquinas reales.

E1 IEEE [IEEE93] ha desarrollado una definición más completa. Ingeniería de software: (1) La aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software; es decir, la aplicación de ingeniería al software. (2) El estudio de enfoques como en (1).

Para este curso en particular tomaremos la siguiente definición como nuestra línea base para todo el desarrollo futuro:

Ingeniería de Software: Es el establecimiento y la utilización de las técnicas de ingeniería orientadas a la elaboración de nsoftware económico, confiable y eficiente. La ingeniería de Software define estándares para el desarrollo de software de calidad.

Una visión general de la ingeniería del software

La ingeniería es el análisis, diseño, construcción, verificación y gestión de entidades técnicas (o sociales). Con independencia de la entidad a la que se va a aplicar ingeniería, se deben cuestionar y responder las siguientes preguntas:

¿Cuál es el problema a resolver?

¿Cuáles son las características de la entidad que se utiliza para resolver el problema?

¿Cómo se realizará la entidad (y la solución)?

¿Cómo se construirá la entidad?

¿Qué enfoque se va a utilizar para no contemplar los errores que se cometieron en el diseño y en la construcción de la entidad?

¿Cómo se apoyará la entidad cuando usuarios soliciten correcciones, adaptaciones y mejoras de la entidad?

El trabajo que se asocia a la ingeniería del software se puede dividir en tres fases genéricas, con independencia de área de aplicación, tamaño o complejidad del proyecto. Cada fase se enfrenta con una o varias cuestiones de las destacadas anteriormente.

La fase definición se centra sobre el qué. Es decir, durante la definición, el que desarrolla el software intenta identificar qué información ha de ser procesada, que función y rendimiento se desea, qué comportamiento del sistema, qué interfases van a ser establecidas, qué restricciones de diseño existen, y que criterios de validación se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y del software. Aunque los métodos aplicados durante la fase de la definición variarán dependiendo del paradigma de ingeniería del software (o combinación de paradigmas) que se aplique, de alguna manera tendrán lugar tres tareas principales:

Ingeniería de sistemas o de información.

Planificación del proyecto del software.

Análisis de los requisitos.

La fase de desarrollo se centra en el cómo. Es decir, durante el desarrollo un ingeniero de software intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función como una arquitectura del software, cómo han de implementarse detalles procedimentales , cómo han de caracterizarse las interfaces, cómo ha de traducirse el diseño el un lenguaje de programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba. Los métodos aplicados durante la fase de desarrollo variarán, aunque las tres tareas específicas técnicas deberían ocurrir siempre:

Diseño del software.

Generación de código.

Prueba del software.

La fase de mantenimiento se centra en el cambio. Que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software, y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. La fase de mantenimiento vuelve a aplicar los pagos de las fases de definición y de desarrollo, pero con el contexto del software ya existente. Durante la fase de mantenimiento se encuentran cuatro tipos de cambios:

Corrección. Incluso llevando a cabo la mejores actividades de garantía de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento correctivo modifica el software para corregir lo defectos.

Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (p. Ej.: CPU, el sistema operativo, las reglas de empresa, las características externas de productos) para el que se desarrolló el software. El mantenimiento adaptativo produce modificación en el software para acomodarlo a los cambios de su entorno externo.

Mejora. Conforme se utilice el software, el cliente/usuario puede descubrir funciones adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.

Prevención. El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo también llamado reingeniería del software, se debe conducir para permitir que el software sirva para las necesidades de los usuarios finales. En esencia, el mantenimiento preventivo hace cambios en programas de computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente.

1.5 Paradigmas de la Ingeniería de Software.

Definición de Paradigma: Para la Ingeniería de Software el paradigma es una agrupación de métodos, herramientas y procedimientos con el fin de describir u modelo.

Un "paradigma" es un modelo para comprender la realidad, que nos permite relacionarnos con el mundo circundante y tener un sentido de identidad dentro de lo que percibimos que es "el mundo real".

Fases Generales del Proceso de Desarrollo de Software:

Independientemente del procedimiento de desarrollo, la aplicación del software y el tamaño del proyecto; el desarrollo de software contiene tres fases genéricas definición, desarrollo y mantenimiento, desde la concepción de desarrollo estructurado de software.

Fase general Descripción

De definición.

Parte fundamental del desarrollo de software.

Identifica los requisitos clave del sistema.

Producto final: el ERS , documento base para el control del cumplimiento de requerimientos de usuario.

De desarrollo.

Referida a cómo han de diseñarse los componentes del software.

Comprende etapas como diseño de estructuras, modelo de requisitos, diseño de interfaz, estructura de la base de datos, codificación y prueba por parte del programador y del cliente.

De mantenimiento

Fase post implantación.

Aplica las etapas de las fases de definición y desarrollo sobre el software final.

Los paradigmas de la ingeniería de software conservan estas fases generales, variando los métodos, las herramientas y procedimientos para aplicarlos.

Paradigmas de la Ingeniería de Software:

La ingeniería del Software define paradigmas de desarrollo estructurado como base a seguir en un proyecto de Software. Si ninguno de estos paradigmas se

adecua al problema por resolver, entonces el desarrollador se verá obligado a combinar los paradigmas o definir uno nuevo.

Para resolver los problemas reales de una industria, un ingeniero del software o un equipo de ingenieros deben incorporar una estrategia de desarrollo que acompañe al proceso, métodos, capas de herramientas.

La estrategia a menudo se llama modelo de proceso o paradigma de ingeniería del software. Se selecciona un modelo de proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse, y los controles y entregas que se requieren.

Raccoon [RAC95] sugiere un << modelo del caos >> que describa el << desarrollo del software como una extensión desde le usuario hasta el desarrollador y la tecnología >>. Conforme progresa el trabajo hacia un sistema completo, las etapas descritas anteriormente se aplican recursivamente a las necesidades, del usuario y a la especificación técnica del desarrollador del software.

Modelo Lineal Secuencial o Cascada Pura (Waterfall)

Por supuesto Royce en 1970; es el paradigma más antiguo y fue el más utilizado durante la hegemonía del método estructurado. El número de etapas propuestas varía de acuerdo al proyecto a desarrollar, aunque existen etapas comunes para este paradigma.

Análisis de los requisitos del software. El proceso de reunión de requisitos se intensifica y se centra especialmente en el software. Para comprender la naturaleza de el (los) programa (s) a construirse, el ingeniero (<< analista >>) del software debe comprender el dominio de información del software (descrito en el Capitulo 1.1), así como la función requerida, comportamiento, rendimiento e interconexión. El cliente documenta y repasa los requisitos del sistema y del software.

Diseño. El diseño del software es real mente un proceso de muchos pasos que se centra en cuatro atributos de un programa: estructura de datos, arquitectura del software, representaciones de interfaz y detalle procedimental (algoritmo). El proceso de diseño traduce requisitos en una representación del software que se pueda evaluar por calidad antes de que comience la generación del código. Al igual que los requisitos, el diseño se documenta y se hace parte de la configuración del software.

Generación de código. El diseño se debe traducir en una forma legible por la máquina. El paso de generación de código lleva a cabo esta tarea. Si lleva a cabo el diseño de una forma detallada, la generación de código se realiza mecánicamente.

Pruebas. Una vez que se ha generado un código, comienzan las pruebas del programa. El proceso de pruebas se centra en los procesos lógico internos del software, asegurando que todas las sentencias se han comprobado, yen los proceso externos funcionales, es decir, la realización de las pruebas para le detección de errores y el sentirse seguro de que la entrada definida produzca resultados reales de acuerdo con los resultados requeridos.

Mantenimiento. El software indudablemente sufrirá cambios después de ser entregado al cliente (una excepción posible es el software empotrado). Se producirán cambios porque se han encontrado errores, porque el software debe adaptarse para acoplarse a los cambios de su entorno externo (p. Ej.: se requiere un cambio debido a un sistema operativo o dispositivo periférico nuevo), o porque el cliente requiere mejoras funcionales o de rendimiento. El mantenimiento vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo.

Este paradigma concibe las fases de desarrollo como proceso independientes en el tiempo, es decir, no se pueden realizar de manera simultánea; cada fase empieza cuando se ha terminado la fase anterior y para poder pasar a otra fase es necesario haber conseguido todos lo objetivos de la etapa previa.

Las etapas de este paradigma se desarrollan en forma secuencial y cuando se detecta algún error en alguna etapa, lo más probable será abandonar todo lo avanzado y regresar a la etapa primera de análisis de requisitos del sistema; pues, aunque la vuelta atrás por etapas es posible, ésta demanda mucho esfuerzo y puede terminar en el colapso.

El paradigma de cascada puro presenta las siguientes ventajas y desventajas.

Ventajas Desventajas

Permite un mejor control de cada actividad, en cuanto a fechas de entrega, costos, revisiones y productos desarrollados.

Minimiza los gastos de la planificación del proyecto.

Los proyectos de software rar vez siguen un flujo secuencial.

No involucra al usuario en el desarrollo del producto.

Requiere mucho tiempo para el desarrollo del proyecto.·

Si el usuario olvida especificar un requerimiento se incurre un elevado costo.

La aplicación de este paradigma es recomendada para proyectos donde cada etapa sea independiente de la siguiente, para proyectos donde los requerimientos de información se puedan determinar de manera clara y exacta, y éstos no sean modificados conforme pase el tiempo, para proyectos donde nos enfrentemos a clientes pacientes, pues el software no estará disponible hasta el final del ciclo,

para proyectos donde se cuente con herramientas de calidad para el levantamiento acertado de información.

Modelos en Función de Prototipos

Cuando en la etapa de análisis se necesitan de técnicas amigables para la elaboración del ERS, es recomendable el empleo de herramientas de levantamiento de información como son los prototipos o modelos previos. Los modelos previos pueden ser en papel o computadora para mostrar la interacción hombre-máquina; un modelo que muestra algunas funciones del software; o, algún software anterior (parte o todo) parecido al que se desea, que luego será modificado y adaptado según los requerimientos del usuario.

El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos, y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un << diseño rápido >>.

El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente (p. Ej.: enfoques de entrada y formatos de salida). El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y lo utiliza para refinar los requisitos del software a desarrollar. La interacción ocurre cuando el prototipo satsface las necesidades del cliente, a la vez que permite que el desarrollador comprenda mejor lo que se necesita hacer.

Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de los fragmentos del programa ya existentes o aplica herramientas (p. Ej.: generadores de informes, gestores de ventanas, etc.) que permiten generar rápidamente programas de trabajo.

El paradigma de la elaboración por prototipos resulta una alternativa para el desarrollo rápido de aplicaciones de software; pues el analista acorta en tiempo entre la determinación de los requerimientos de información y la entrega de un sistema funcional, además que el usuario podrá modificar y depurar sus requerimientos conforme avance el desarrollo del proyecto.

El paradigma de desarrollo por prototipos presenta las siguientes ventajas y desventajas.

Ventajas Desventajas

Permite la retroalimentación por parte del usuario.

Desarrollo rápido.

El usuario se siente parte del grupo.

El desarrollador debe dar forma prematuramente a un sistema, incluso antes de comprender de manera básica el problema y su funcionamiento.

El usuario puede creer que un prototipo es un software final.

El paradigma de prototipos es aplicable a proyectos de análisis acelerado, donde sólo se cuente con requisitos generales; a proyectos con clientes impacientes de ver algo funcionando; a proyectos con clientes dispuestos a reaccionar abiertamente con el prototipo. No es recomendable aplicarlo a proyectos con clientes exigentes de calidad, pues los prototipos son susceptibles a muchos fallos, y el cliente se puede formar una idea equivocada de la seriedad del desarrollador.

Modelo de Desarrollo rápido de Aplicación (DRA)

Este es un modelo de proceso de desarrollo del software lineal, secuencias que enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA es una adaptación a << alta velocidad >> del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un << sistema completamente funcional >> dentro de periodos cortos de tiempo (p. Ej.: de 60 a 90 días) [MAR9]. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:

Modelado de Gestión. El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión?, ¿Qué información se genera?, ¿Quién la genera?, ¿A dónde va la información?, ¿Quién la procesa?.

Modelado de Datos. El flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

Modelado de Proceso. Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para

implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir o recuperar un objeto de datos.

Generación de Aplicaciones. El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

Pruebas y Entrega. Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

El modelo de proceso DRA se ilustra en la Figura 2.6. Obviamente las limitaciones de tiempo impuestas en un proyecto DRA demandan <<ámbito en escalas>> [KER94]. Si una aplicación de gestión puede modularse de forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un solo conjunto.

Desventajas:

Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA.

DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para complementar un sistema en un marco de tiempo abreviado. Si o hay compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasarán.

No todos los tipos de aplicaciones son apropiados para DRA. No es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de interoperatividad con programas de computadora ya existentes. DRA enfatiza el desarrollo de componentes de programas reutilizables.

Modelos de Procesos Evolutivos de Software

Modelo Incremental

Definido por Lehman en 1984; constituye una de las variantes del modelo en cascada puro; el modelo incremental o de cascada con subproyectos, corrige la necesidad de una secuencia no lineal de pasos de desarrollo.

El modelo Incremental se va creando el Software añadiendo componentes funcionales al sistema: incrementos.

Los sistemas presentan alguna áreas que incluyen sorpresas al momento de definir o desarrollar el producto, pero también presentan otras áreas que hemos implementado varias veces y no incluyen sorpresas, entonces, por qué retrasar la implementación de estas áreas que son fáciles de modelar solamente porque estamos considerando que en el proyecto existen algunas áreas difíciles.

Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial (núcleo). Es decir, se afrontan requisitos básicos, pero muchas

funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisión detallada). Como un resultado de utilización y/o de evaluación, se desarrolla un plan para el incremento siguiente.

Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. En este paradigma el software se ve como una integración de resultados sucesivos obtenidos después de cada interacción. Este modelo se adecua a entornos de alta incertidumbre.

Ventaja: Para desarrollos donde no se determinen de forma clara los requerimientos de usuario al comenzar el sistema.

Desventaja: El problema de este modelo radica en que los errores en los requisitos propuestos se detectan tarde y su corrección resulta tan costosa como en el modelo en cascada.

Modelo en Espiral

Propuesto por Boehm en 1988 con la finalidad de paliar los inconvenientes del modelo en cascad y adecuar el desarrollo por prototipos a problemas complejos. Este paradigma combina el paradigma de cascada y el de construcción por prototipos, agregando una etapa de "análisis de riesgo" . El paradigma de espiral es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en mini-proyectos y donde cada mini-proyecto se centra en uno o más riesgos importantes hasta que todos estos estén controlados. Este modelo se realiza en varias iteraciones; se parte de una escala pequeña la cual comienza con la identificación de objetivos, alternativas y restricciones; en medio de la espiral, se localizan riesgos, se genera un plan para manejarlos, y a continuación se establece una aproximación a la siguiente iteración.

Se proporciona el potencial para el desarrollo rápido de versiones increméntales del software. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones, la versión incrementar podría ser un modelo en papel prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas de ingeniería del sistema. El modelo en espiral se divide en un número de actividades estructurales también llamadas guiones de tareas. Estas inclusive pueden variar de 3 a 6 tareas.

Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software. Cada paso de la región de planificación produce ajustes en el plan del proyecto. El costo y la planificación se ajustan según la reacción ante la evaluación del cliente. Además, el gestor del proyecto ajusta el número planificado de iteraciones requeridas para completar el software.

En esencia, la espiral, cuando se caracteriza de esta forma, permanece operativo hasta que el software de se retira. Hay veces en que el proceso está inactivo, pero siempre que se inicie un cambio, el proceso arranca en el punto de entrada adecuado (p. Ej.: mejora el producto). El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software a gran escala. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos. El modelo en espiral utiliza la construcción de prototipos como mecanismos de reducción de riesgos, pero lo que es más importante, permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida clásico, pero lo incorpora al marco de trabajo interactivo que refleja de forma más realista el mundo real. El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto, y si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemáticos.

El paradigma espiral, al igual que los demás modelos, se puede combinar con otros paradigmas.

El paradigma de espiral presenta las siguientes ventajas y desventajas.

Ventajas Desventajas

Mientras los costos del modelo aumentan, los riesgos de proyecto disminuyen.

Buen control sobre el desarrollo del proyecto.

Es un modelo complicado.

Exige desarrolladores con mucha experiencia para manejar la complejidad de los problemas que enfrenta.

El modelo espiral es aplicable a proyectos donde no se trabaje bajo contrato, es decir, proyectos que no involucren fuentes externas de software.

Este paradigma es poco recomendable para grupos de trabajo donde no se cuenta con un equipo experto en análisis de riesgos, o para proyectos donde los riesgos sean menores y no se justifique la flexibilidad y gestión de riesgos que ofrece este paradigma.

El paradigma más adecuado para este caso es el espiral, debido a la complejidad y el riesgo elevado del proyecto (de fallar la aplicación se perderían vidas humanas) a desarrollar.

Modelo de Ensamblaje de Componentes

Las tecnologías de objetos proporcionan el marco de trabajo técnico para un modelo de proceso basado en componentes para la ingeniería del software. El paradigma de orientación a objetos enfatiza la creación de clases que encapsula tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se diseñan y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadora.

El modelo ensamblador de componentes configura aplicaciones desde componentes preparados de software (algunas veces llamados << clases >>). La actividad de la ingeniería comienza con la identificación de clases candidatas. Esto se lleva a cabo examinando los datos que se van a manejar por parte de la aplicación y el algoritmo que se va a aplicar para conseguir el tratamiento. Los datos y los algoritmos correspondientes se empaquetan en una clase.

El modelo de ensamblaje de componentes incorpora muchas de las características del modelo en espiral. Es evolutivo por naturaleza [NIE92], y exige un enfoque interactivo para la creación del software. Sin embargo, el modelo ensamblador de componentes configura aplicaciones desde componentes preparados de software (algunas veces llamados << clases >>).

El modelo ensamblador de componentes lleva a la reutilización del software, y la reutilización proporciona beneficios a los ingenieros del software.

Modelo de Desarrollo Concurrente

Definido por Davis y Sitaram [DAV94], el modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas, y estados asociados a ellas. Por ejemplo, la actividad de ingeniería definida para el modelo en espiral, se lleva a cabo invocando las tareas siguientes: modelado de construcción de prototipos y/o análisis, especificación de requisitos, y diseño.

El modelo de proceso concurrente define una serie de acontecimientos que disparan transiciones de estado a estado para cada una de las actividades de la ingeniería del software.

El modelo de proceso concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones [SHE94]: una dimensión de sistemas y una dimensión de componentes. Los aspectos del nivel de sistemas se afrontan mediante tres actividades: diseño, ensamblaje y uso. La dimensión de componentes se afronta con dos: diseño y realización. La concurrencia se logra de dos formas:

1. Las actividades de sistemas y de componentes ocurren simultáneamente y pueden moderarse con el enfoque orientado a objetos descrito anteriormente.

2. Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.

En realidad, el modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. En vez de confinar las actividades de ingeniería del software a una secuencia de sucesos, define una red de actividades. Todas las actividades de la red existen simultáneamente con otras. Los sucesos generados dentro de una actividad dada o en algún otro lugar en la red de actividad inicia la s transiciones entre los estados de una actividad.

Modelo de Métodos Formales

El modelo de métodos formales acompaña a un conjunto de actividades que conducen a la especificación matemática del software de computadora. Los métodos formales permiten que un ingeniero del software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática.

La ambigüedad, lo incompleto y la inconsistencia se descubren y se corrigen más fácilmente, no mediante una revisión a propósito para el caso, sino mediante la aplicación del análisis matemático. Cuando se utilizan métodos formales durante el diseño, sirven como base para la verificación de programas y por consiguiente permiten que el ingeniero del software descubra y corrija errores que no se pudieron detectar de otra manera.

Aunque todavía no hay un enfoque establecido, los modelos de métodos formales ofrecen la promesa de un software libre de defectos. Sin embargo, se ha hablado de una gran preocupación sobre su aplicabilidad en un entorno de gestión:

1. El desarrollo de modelos formales actualmente es bastante caro y lleva mucho tiempo.

2. Se requiere un estudio caro porque pocos responsables del desarrollo de software tiene los antecedentes necesarios para aplicar métodos formales.

3. Es difícil utilizar los modelos como un mecanismo de comunicación con clientes que no tiene muchos conocimientos técnicos.

No obstante, es posible que el enfoque a través de métodos formales tenga más partidarios entre los desarrolladores del software que deben construir software de mucha seguridad (p. Ej.: los desarrolladores de aviónica y dispositivos médicos), y entre los desarrolladores que pasan grandes penurias económicas al aparecer errores de software.

Técnicas de Cuarta Generación

Abarca un amplio espectro de herramientas de software que tienen algo en común: todas facilitan al ingeniero del software, la especificación de lagunas características del software de alto nivel. Luego, la herramienta genera automáticamente el código fuente basándose en la especificación del técnico. Cada vez parece más evidente que en cuanto mayor sea el nivel en el que se especifique el software, más rápido se podrá construir el programa. El paradigma T4G para la ingeniería del software usando formas de lenguaje especializado o notaciones graficas que describan el problema que hay que resolver en términos que los entienda el cliente.

Al igual que otros paradigmas, T4G comienza con el paso de reunión de requisitos. Idealmente, el cliente describe los requisitos, que son, a continuación, traducidos directamente a un prototipo operativo. Estado actual de los enfoques de T4G:

1. El uso de T4G ha crecido considerablemente en la última década y ahora es un enfoque viable para muchas de las diferentes áreas de aplicación. Junto con las herramientas de ingeniería de software asistida por computadora (CASE) y los generadores de código, T4G ofrece una solución fiable a muchos problemas de software.

2. Los datos recogidos en compañías que usan T4G parecen indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeñas y de tamaño medio, y que la cantidad de análisis y diseño para las aplicaciones pequeñas, también se reduce.

3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o más tiempo de análisis, diseño y prueba (actividades de ingeniería del software), perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación de la codificación.

Tecnología de Procesos

Las herramientas de tecnología de procesos permiten que una organización de software construya un modelo automatizado de la estructura común del proceso, conjunto de tareas, y actividades de protección.

El modelo, presentado normalmente como una red, se puede analizar para determinar el flujo de trabajo típico y para examinar estructuras alternativas de procesos que pudieran llevar a un tiempo o costo de desarrollo reducidos. Una vez que se ha creado un proceso aceptable, se pueden utilizar otras herramientas de tecnología de procesos para asignar, supervisar, e incluso controlar todas las tareas de ingeniería del software definidas como parte del modelo de proceso. Cada uno de los miembros de un equipo de proyecto de software pueden utilizar tales herramientas para desarrollar una lista de control de tareas de trabajo a realizarse productos de trabajo a producirse, y actividades de garantía de calidad a conducirse.

Criterios Generales para Seleccionar un Paradigma:

El ingeniero de sistemas debe estar en capacidad de seleccionar de manera correcta la utilización de alguno de los paradigmas anteriormente mencionados o una combinación de ellos, evaluando las principales características del problema al cual se enfrentará.

Estas características se deben captar en la fase de análisis general del sistema y deberán reforzarse en la etapa de análisis detallado del sistema. Como puntos de evaluación para la selección del paradigma adecuado tenemos:

La naturaleza del proyecto, donde se agrupan criterios como la complejidad del producto final, el conocimiento de la aplicación por parte del grupo, la utilización final del software, etc..

El control del proyecto y la importancia de los avances, directamente relacionado con las características del cliente, sus perspectivas y deseos respecto al software, la importancia de su inclusión en el grupo de desarrollo del producto, etc..

Los métodos y las herramientas disponibles para el desarrollo de cada una de las fases a realizar.