Desarrollo de software
| ||||||
Desarrollo de software. Desarrollar un software significa construirlo simplemente mediante su descripción. Esta es una muy buena razón para considerar la actividad de desarrollo de software como una ingeniería. En un nivel más general, la relación existente entre un software y su entorno es clara ya que el software es introducido en el mundo de modo de provocar ciertos efectos en el mismo.
Aquellas partes del mundo que afectarán al software y que serán afectadas por él será el Dominio de Aplicación. Es allí donde los usuarios o clientes observarán si el desarrollo del software ha cumplido su propósito.
Una de las mayores deficiencias en la práctica de construcción de software es la poca atención que se presta a la discusión del problema. En general los desarrolladores se centran en la solución dejando el problema inexplorado. El problema a resolver debe ser deducido a partir de su solución.
Esta aproximación orientada a la solución puede funcionar en campos donde todos los problemas son bien conocidos, clasificados e investigados, donde la innovación se ve en la detección de nuevas soluciones a viejos problemas.
Pero el desarrollo de software no es un campo con tales características. La versatilidad de las computadoras y su rápida evolución hace que exista un repertorio de problemas en constante cambio y cuya solución software sea de enorme importancia.
Sumario
Desarrollo del Software
Cuando se va desarrollar un software intervienen muchas personas como lo es el cliente que es el que tiene el problema en su empresa y desea que sea solucionado, para esto existe el Analista de Sistema que es el encargado de hacerle llegar todos los requerimientos y necesidades que tiene el cliente a los programadores que son las personas encargadas de realizar lo que es la codificación y diseño del sistema para después probarlo y lo instalan al cliente. Es así como intervienen varias personas ya que una sola persona no podría determinar todo lo necesario lo más seguro que le haga falta algún requerimiento o alguna parte del nuevo sistema y entre más estén involucradas mejor para cubrir con todos los requerimientos del sistema.
Fases del proceso de desarrollo de software
Análisis de requisitos
Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relación, en el que se plasman las principales entidades que participarán en el desarrollo del software. La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la Ingeniería de Requisitos. La IEEE Std. 830-1998 normaliza la creación de las Especificaciones de Requisitos Software (Software Requirements Specification).
Diseño y arquitectura
Se refiere a determinar cómo funcionará de forma general sin entrar en detalles. Consiste en incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se definen los casos de uso para cubrir las funciones que realizará el sistema, y se transforman las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a la programación orientada a objetos.
Programación
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no es necesariamente la porción más larga. La complejidad y la duración de esta etapa está íntimamente ligada al o a los lenguajes de programación utilizados.
Pruebas
Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación]entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en que condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.
Documentación
Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.
Mantenimiento
Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la Ingeniería civil, Arquitectura y trabajo de construcción es dar mantenimiento.
Se puede decir que con la mejora continua garantiza la calidad del producto, ya que el estarla aplicando día con día es la mejor decisión que puede llegar a tener cualquier empresa, porque de esta manera evita grandes problemas en la elaboración o desarrollo de los productos. Esto es fundamental para todas las empresas ya que se vuelven competitivas, con mayor productividad y eficiencia. No hay que olvidar que la mejora se da porque el cliente es el rey y hay que satisfacer todas y cada una de sus necesidades siempre garantizando la calidad.
Metodología
Todo desarrollo de software es riesgoso y difícil de controlar, pero si no llevamos una metodología de por medio, se obtiene clientes insatisfechos con el resultado y desarrolladores aún más.
Sin embargo muchas veces no se toma en cuenta el utilizar una metodología adecuada, sobre todo cuando se trata de proyectos pequeños de dos o tres meses.
Con relación a los proyectos que se desarrollan con mayor envergadura, hay si se toma el sentido de basarse en una metodología de desarrollo y se empieza a buscar cuál sería la más apropiada para dicho caso. A fin de cuenta no encontramos muchas veces la más adecuada y se termina por hacer un diseño propio de metodología, por supuesto no está mal siempre y cuando sirva para alcanzar el objetivo.
Muchas veces se realiza el diseño del software de manera rígida, tal como el cliente lo solicitó, de esa manera cuando el cliente en la "etapa de prueba" solicita un cambio se hace muy difícil de realizarlo, pues si se hace altera las cosas que no se habían previsto, y este es uno de los factores que atrasan el proyecto y crea incomodidad al desarrollador y en muchas oportunidades no llegan a cumplir con el cambio solicitado, esto conlleva malestar en el cliente puesto que no ha sido tomado en cuenta su pedido; para evitar estos incidentes se debe llegar a un acuerdo formal con el cliente al inicio del proyecto de manera que no perjudique el desarrollo del mismo.
Muchas veces los usuarios finales se dan cuenta que dejaron de mencionar algunas cosas y lo manifiestan en la etapa inicial del proyecto cuando se le muestra el prototipo del mismo.
Algunas Metodologías conocidas:
- La metodología RUP es la más adaptable para proyectos de largo plazo.
- La metodología XP en cambio, se recomienda para proyectos de corto plazo.
- La metodología MSF se adapta a proyectos de cualquier dimensión y de cualquier tecnología.
Se puede decir además que lo más importante antes de elegir la metodología que se debe usar para implementar el software, es determinar el alcance que tendrá y luego de allí ver cuál es la que más se acomoda a la aplicación.
Ejemplos:
El ejemplo del software lo hacen numerosas empresas, cada vez más gobiernos (registro gratis). Los expertos lo recomiendan, lo hacen particulares a millones. Hasta (a regañadientes) Microsoft. La idea absurda de dejar abierta las tripas del software y permitir que la gente las mire, e incluso que las modifique, copie y use en condiciones diferentes, en la industria de la informática es muy común. De hecho se extiende a los más pequeños rincones del mundo desde una orden mágica hermética de tradición masónica y rosacruciana a telefónica I+D. Si hasta las empresas en filosofía más expuestas o menos rápidas en novación y las sociedades secretas son capaces de ver las ventajas del "Open Source" (abierto o libre).
No ha sido sencillo la idea conocida como dicho software (abierto o libre) ha tenido una vida larga pero difícil, dirigida por polémicas aparentemente absurdas pero que contienen un profundo debate ideológico y práctico; a veces dividido en partes enfrentadas con mucha pasión; siempre descalificada, lo cierto es que la comunidad del software abierto hoy es una fuerte y sana realidad.
Importancia
Actualmente la transición que estamos viviendo hacia una sociedad del conocimiento ha cambiado profundamente las relaciones entre las personas, empresas y gobiernos: las empresas usan la red para comunicarse con los clientes, utilizan también herramientas de gestión del conocimiento para hacer más eficientes, los gobiernos mejoran su presencia en Internet y los servicios a los ciudadanos a través de la red, los usuarios usan las herramientas para sus relaciones personales, etc. Se va de forma imparable hacia una sociedad altamente interconectada donde el eje fundamental es la información.
El software es el intermediario cada vez más grande entre la información y la inteligencia humana. De la misma manera que preocupa para poder acceder a la información, si existe la censura, es tema de preocupación de quien controla este intermediario y las garantías de su transparencia y confiabilidad.
En principio, el software es un programa informático o conjunto de ellos que tiene un fin determinado, es el de procesar los textos que usamos, el controlador de grabación de nuestros espacios favoritos o las aplicaciones que permiten operar un teléfono móvil.
Está compuesto por un conjunto de instrucciones que el usuario realiza para ejecutar una función específica. Normalmente los programadores escriben en un lenguaje en el que todos pueden entender y que después es traducido al lenguaje binario el único que las máquinas entienden. El conjunto de órdenes en el lenguaje que todos trabajan se llaman código fuente.
Sino se accede al código solo se puede usar el programa, no se puede ver cómo está hecho o introducir comentarios. Un ejemplo muy utilizado es el de la receta de cocina, en el que el código fuente son las instrucciones que permite confeccionar un plato. Sin la receta solo se pude degustar el plato, pero no se sabe si se le añade algo vaya en contra de algunos de esos ingredientes ya que se desconocen su composición y proporción. En este sentido, el código fuente juega un papel fundamental en la manera como se debe entender el software.
Se podrían poner varios ejemplos para entender dicha importancia. A finales de los 90 se pudo ver en todo el mundo la preocupación por parte de empresa y gobiernos por las consecuencias que podían tener el llamado efecto 2000. El famoso error informático era debido al hecho de que muchos programas almacenaban la parte de la fecha correspondiente al año utilizando únicamente dos dígitos, de tal manera, que después del año 99 (el 1999) podíamos pasar al año 00 (¿ año 2000 o año 1900?) causando todo tipo de errores en el cálculo de período de tiempo.
Los ordenadores de las empresas eléctricas, centrales nucleares, sistema de control de aviación, bancos y en general, todo el software de uso cotidiano, tuvieron que ser revisados. Finalmente algunas aplicaciones fueron corregidas, otras ya funcionaban correctamente y no hubo que lamentar ninguna catástrofe, pero hubo miles de predicciones apocalípticas sobre las consecuencias que se podría llegar a obtener este error, así podría haber sido si no se hubiera reparado a tiempo.
Es por eso, el software tiene un papel muy importante en la sociedad sobre manera garantizar métodos trasparentes en sus diferentes fases de producción y explotación.
Modelos del Proceso de Desarrollo Software
No existe consenso sobre cuál es el mejor modelo del proceso software. Distintos equipos de desarrollo pueden utilizar diferentes modelos de proceso software para producir el mismo tipo de sistema software. Sin embargo, algunos modelos son más apropiados para producir ciertos tipos de sistemas, de forma que si no se utiliza un modelo adecuado puede ocurrir que el sistema software resultante sea de menor calidad.
El reparto de costes entre las distintas fases del proceso de desarrollo es difícil de determinar dado los distintos modelos de proceso existentes. Sin embargo, en dependencia del modelo que se adopte, al menos el 60% del coste total se emplea en la actividad de evolución del sistema. La estimación de este porcentaje es pesimista, ya que la tasa de crecimiento de nuevos productos software es mucho mayor que la tasa de productos software que quedan en desuso (no tienen que ser mantenidos), por lo que el número de operaciones de mantenimiento que se realizan sigue aumentando. El proceso de diseño software debería, por tanto, tener en cuenta la posterior evolución del sistema.
Las características deseables de un proceso de desarrollo software son:
Claridad: El proceso de desarrollo es claro cuando se entiende con facilidad.
Visibilidad: Un proceso de desarrollo es visible cuando sus actividades producen resultados claros identificables externamente.
Facilidad de soporte: Exige disponer de herramientas CASE (Computer-Aided Software Engineering) que den soporte a todas o alguna de las actividades del proceso de desarrollo.
Fiabilidad: Un proceso de desarrollo es fiable cuando es capaz de detectar posibles errores.
Facilidad de mantenimiento: Requiere capacidad para incorporar nuevos requisitos o modificar alguno o algunos de los existentes.
Rapidez: Un proceso software es rápido cuando se puede obtener, a partir de la especificación, una implementación del sistema en un tiempo reducido.
Modelo en cascada o convencional
Tomado de otras ingenierías es el primer modelo de desarrollo software propuesto. Ampliamente usado en la industria por su facilidad de gestión y visibilidad. En la figura 1 se representa el secuenciamiento de las actividades de este modelo de desarrollo.
Figura 1: Modelo en cascada o convencional.
Sin embargo, su principal problema reside en su poca flexibilidad al separar el proceso de desarrollo en etapas totalmente distintas. En la práctica estas etapas no tienen fronteras tan bien definidas, lo que hace que, en no pocas ocasiones, se solapen y compartan información.
Los principales problemas de este modelo son: dificultad para realizar prototipos, reutilizar software y realizar pruebas sin disponer de una implementación del sistema.
Modelo evolutivo
En este modelo se entrelazan las actividades de especificación, desarrollo y validación. Inicialmente, se desarrolla rápidamente un sistema inicial a partir de una especificación muy abstracta. El sistema se va refinando con la información que van suministrando los clientes y/o usuarios hasta que se obtiene un sistema final que satisfaga todas las necesidades previstas. El sistema final obtenido puede rediseñarse para producir otro más robusto y más fácil de mantener. En la figura 2 se esquematiza este modelo.
Figura 2: Modelo evolutivo.
Existen dos tipos de procesos de desarrollo evolutivos:
Exploratorio: Su objetivo es trabajar con el cliente para identificar y construir el sistema final a partir de una especificación informal. El resultado del proceso es el sistema final.
Prototipado desechable: Su objetivo es entender los requisitos del cliente. El resultado del proceso es la especificación del sistema (el prototipo se deshecha).
Los principales problemas de este modelo son: escasa visibilidad; los continuos cambios que hacen que los sistemas desarrollados estén deficientemente estructurados; y la necesidad de disponer, en muchos casos, de un equipo de desarrollo altamente calificado. Estos problemas hacen que la aplicación de este modelo se suela limitar a sistemas interactivos de tamaño pequeño o mediano. La deficiente estructura dificulta las tareas de mantenimiento de ahí que se suela aplicar a sistemas con una vida corta y a partes de grandes sistemas, especialmente a sistemas de inteligencia artificial y a interfaces de usuario.
Modelo transformacional
Se basa en disponer de una especificación formal del sistema y en transformar, con métodos matemáticos, esta especificación en una implementación. Si las transformaciones que se aplican son correctas es posible asegurar que el sistema construido satisface la especificación, es decir, es posible obtener programas correctos por construcción.
Figura 3: Modelo transformacional.
Otra de sus ventajas es la posibilidad de realizar el mantenimiento a nivel de especificación. Por lo que es necesario disponer de una especificación inicial correcta y de diseñadores altamente calificados. Además no existe apenas experiencia en la aplicación de este modelo a grandes proyectos.
Modelo basado en reutilización: En este modelo se supone que alguno de los componentes del sistema final ya existe. El proceso de desarrollo se centra en integrar las partes ya existentes más que en construir todo el sistema desde el principio.
Las ventajas que desde un punto de vista económico puede producir este modelo actualmente empiezan a ser estudiadas en profundidad. Prácticamente no existe experiencia sobre el empleo de este modelo, si bien, se están haciendo numerosos estudios e investigaciones para posibilitar su uso.
Modelo en espiral
Desarrollado por Boehm en el año 1988 con el objetivo de reunir las ventajas de los modelos de proceso software en cascada y de prototipado. Se incluye el análisis de riesgo como una parte importante del proceso de desarrollo software.
El modelo tiene la forma de una espiral en la que cada vuelta representa cada una de las fases en las que se estructura el proceso software y está organizada en cuatro sectores:
1. Definición de objetivos, alternativas y restricciones de cada fase del proyecto.
2. Evaluación de alternativas y análisis de riesgos.
3. Desarrollo y validación. Se elige el modelo de proceso de desarrollo que se considere más adecuado.
4. Planificación de las siguientes fases del proyecto.
Bibliografía
ARTUR BORONAT, J. I., JOSÉ Á. CARSÍ, ISIDRO RAMOS, ABEL GÓMEZ. Del método formal a la aplicación industrial en Gestión de Modelos: Maude aplicado a Eclipse Modeling Framework1, 2003.
- Bernd Bruegge & Allen H.Dutoit. Object-Oriented Software Engineering, Prentice Hall, Pag. 11.
- Castro, Díaz-Balart, Fidel: CIENCIA, INNOVACIÓN Y FUTURO. Ediciones especiales. Instituto Cubano del Libro, La Habana. 2001.
- Campderrich Falgueras, Benet (2002): Ingeniería de software. Barcelona: Editorial UOC, 2002. 320 páginas.
- Franquet, R.: COMUNICAR EN LA SOCIEDAD DE LA INFORMACIÓN. Universidad Autónoma de Barcelona. 2005
- Ingeniería de Software Código de Ética y Práctica Profesional. SEERI, East Tennessee State University. 1999.
- Ingeniería de software (sexta edición), Ian Sommerville. Addison Wesley. Sitio en Inglés
- Ojalvo, V. y otros: LA COMUNICACIÓN EDUCATIVA. Universidad de la Habana. En formato digital.
- ONET Code Connector - Software Developers, Systems Software - 15-1133.00. Onetcodeconnector.org.
- Pasquali, A.: COMPRENDER LA COMUNICACIÓN. Caracas: Monte Ávila Editores. 1979.
- Proceso unificado del desarrollo de software, artículo en el sitio web Yaqui.
- Presman, Roger, 2002. Ingeniería de Software: un enfoque práctico, Sexta edición, McGraw.Hill/Interamericana de España, 824 páginas. pág. 39, 53-54, 67-72.
- Software Development Manager Position Description. interfacing.com.
- Urribarri, R.: “EL USO DE INTERNET Y LA TEORÍA DE LA COMUNICACIÓN”. Universidad de Zulia, Venezuela. 10-O3-1999.
- What is Rapid Application Development?
