los problemas en el dísero y construcción de unrascacielos contra los de una vivienda unifamiliar de unasola planta. Aunque ambos pertenecen a la clase deedificaciones, un arquitecto nunca disef\aría y construiríael rascacielos pensando en la simple ampliación deldisero y construcciónde la casa.

María Eugenia Ualencia.Profesor Rsociado.

Departamento de Información y Sistemas.Uniuersidad del Ualle.

Cali - Colombia.

RESUMEN

Este artículo hace una presentación de los orígenes ydefiniciones de la Ingeniería de Sofware ( 1.S.). Estable-ce una caracterización de lo que es un producto deSoftware y destaca las diferentes etapas que aquellaconsideradeben seguirse en su proceso de desarrollo.

Senala para cada una de las ac...¡idades que deben reali-zarse, los documentos a producirse y sus contenidos aligual que la conformación y características del equipohumanode trabajo.

1. INTRODUCCION.

El término -'ngeniería de Sofware- se introdujo al final dela década del 60 en una conferencia donde se discutió lallamada -Crisis del Software- (1968 Alemania Oriental y1969 Italia) (7). La aparición de los computadores de latercera generación, mucho más ,poderosos que los de lasegunda, abrieron un abanico de posibilidades de imple-mentación de aplicaciones que hasta el momento seconsideraban imposibles de realizar. Dicha implemen-tacón requeríadesarrolar grandes sistemasde Software.

Los problemas encontrados en el desarrollo de talessistemas no son en ninguna forma una versión ampliadade los problemas de escribir programas cortos de compu-tador. Se puede ilustrar lo anterior comparando

10

El nivel de complejidad de los programas pequenos (odiseflo de casas) puede fácilmente entenderlos una solapersona y los detalles del diseno e imp!ementación (oconstrucdón), manejark>sen su cabeza.

Las especificaciones son informales y ei efecto de loscambios es inmediatamenteobvio.

Sin embargo, la corrolelldad de grandes sistemas deSoftware hace imposible que una sola persona manejementalmente y mantenga presente todos los detalles decada aspecto del proyecto. Se necesita de técnicas for-males para establecer requerimientos y especificacio-nes, técnicas de diseno y una documentación cuidadosade cada etapadel proyecto.

2. DEFINICIONES.

2.1 Ingenieríade Software (1.5.).

1. Sommerville, define la Ingeriería de Software comoaquella que se ocupa del desarrollo de grandes sistemasde Software, que son más grandes de lo que normal-

Los productos de Software se caracterizan porque sonusados por gran cantidad de usuarios, son diferentes per-sonas quienes desarrollan y dan mantenimiento a talesproductos y, requieren de un enfoque más sistemáticopara su desarrollo que el usado para el Software de usopersonal.

_____ ~u_~ r~:I } ~b~t~a_c:~n _

I II II Requerimientos Especificaciones I

I --- ---" II (necesidad) (modelo) I

I I

I ~ II II II Manteni- I

mente pueden ser desarrolados por un solo individuo,usa principios de ingeniería en el desarrollo de esos siste-mas y se compone de aspectos técnicos y no técnicos(8).

Boehm, la define como la aplicación práctica del cono-cimiento científico en el diseno y construcción de progra-mas para computadores y la documentación asociadarequerida para desarroUanos, usanos y mantenenos (4).

La IEEE, en su glosario de términos, la define como elenfoque sistemático para el desarrollo, operación, mante-nimiento y eliminación de Software (6).

2.2 Productos de Software.

Son el conjunto de programas, reglas, procedimientos ydocumentación posible asociada con la computación, asfcomo los datos pertenecientes a la operación de un siste-ma de cómputo.

2.3 Software de uso personal.

Son aquellos programas escritos por el programador paraque le realice una tarea determinada, donde los aspectosde especificación de requerimientos y documentacióndurante su desarrollo se han tomado informalmente (9).

3. INFORMACIONFUNDAMENTAL.

Cuando se habla de desarrollar productos de softwaredebe establecerse una caracterización de éstos, parapoderlos diferenciar del "Software de Uso Personal" yentender por qué el desarrollarlos trasciende el simplehecho de escribir un programa.

Qué?

Para desarrollanos:

Deben determinarse explícitamente limitaciones ynecesidades de los usuarios.

El producto debe disenarse considerando tanto aquienes lo implementan como a quienes lo usan y ledan mentenimiento.

Debe prepararse documentación de apoyo comoprincipios de operación, manual de usuario, instruc-ciones de implementación y guías de entrenamiento.

Las labores de mantenimiento incluyen solicitudesde análisis de cambio, redisel'lo y modificación de có-digo objeto, actualización de la documentación conlos cambios realizados, pruebas completas de la ver-sión modificada y distribución de la nueva versión enlos lugares apropiados.

3.1 Ciclo de Vida de Desarrollode Software.

El desarrollo de productos de Software supera la habi-lidad de un solo individuo para entenderlo y realizarlo.Para controlar mejor el desarrollo de proyectos de estetipo, la Ingeniría de Software ha identificado varias etapaspor las que debe pasar el proyecto y se conocen comoCICLO DE VIDA DE DESARROLLO DESOFTWARE. Se pueden representar así (1):

miento.

Cómo?Implernentación

(codificación y Prueba)

VoL 2 No. 2 11

IIIIIIIII----------------------~

Diseno

(algoritmos)

3.1.1 Etapa de Análisis y Requeri-mientos.

Aquí se establecen en forma precisa las necesidades enel rrundo real que dan origen al proyecto a desarrollar esdecir, se dice QUE es lo que hay que hacer sin me~io-nar cómo y cuáles son las restricciones que se tienen.

Consta de dos fases: definición del sistema y planeacióndel proceso de desarrollo.

Definición del Sistema.

Para hacer1a se re<J.Iiere:

Enunciar el problema a resolver: descripción de lasituación actual, restricciones del problema y metas alograr. Debe emplearse terminología del cliente.

Justificar la estrategia de solución computarizadapara el problema.

- . Identificar las funciones y restricciones a realizar aligual q~e el equipo, personal y programas que' seprcoorconan (recursos).

Determinar objetivos y prioridades para las caracterís-ticas del sistema.

Establecer criterios de aceptación del sistema.

Conformar unglosario de términos.

Plan de Desarrollo deJ Proyecto.

Son los mecanismos que se usarán para lograr las metasy requerimientos. El alcanzar un objetivo se puedeexpresar en términos de los logros importantes aalcanzar a tiempo. Un logro es un hecho significativo enel ciclo de vida de desarrollo del producto. Ejemplo:terminación del análisis de requerimientos del diseno.

Para planear cómo alcanzar cada logro a tiempo, debenresponderse preguntas como las siguientes:

- Cuántos logros son apropiados?

- Cuándo ocurren?

- Qué recursos se necesitan para alcanzar cada logro?

- Exáctamente qué significa alcanzar cada logro?

Para realizar la planeacióndel proceso de desarrollo delproyecto debe definirse:

12 J!I

Un modelo del ciclo de vida con estimado de tiemposy costos de cada fase.

3.1.2 Etapa de Especificación deRequerimientos.

- Estructura del equipo de trabajo.

- Programa de desarrollo: logros y revisiones.

- Lenguajes de programación y herramientas de desa -rrollo.

- Requisitos de prueba y forma de demostración.

- Fuentes de información y glosario de términos.

Como memorias de esta etapa debe producirse elDOCUMENTO DE REQUERIMIENTOS, cuya guía depreparación se presenta en el artículo de referencia (2).

Represe~ta la parte abstracta del QUE es lo que hay quehacer. Mientras los requerimientos describen las necesi-dades en el lenguaje del cliente, las especificacioneshacen una descripción de las necesidades en un lengua-je técnico, sin decir cómo.

Esta etapa se basa en la definición del sistema. Su objeti-vo es especificar total, consistenternente y sin ambigüe-dades los requerimientos técnicos del producto. Seconcreta en el documento de especificaciones, el cualdebe contener (5):

Resumen y panorama del producto.

Es la elaboración de las características del productocon un resumen del ambiente de procesamiento,operación y mantenimiento presentados en ladefinición del sistema.

Interfaces externas y flujo de datos.

Despliegues que verá el usuario, formatos de infor-mes, resumen de comandos del usuario, opcionesde informes, diagramas de flujo de datos y diccionariode datos.

Los diagramas de flujo de datos especifican fuentesy destino de datos, almacenamiento de datos, trans-formaciones y flujo entre ellos.

El almacenamiento de datos es la estructura de datosconceptual sin detalles de implementación.

HEURISTICA. VoL 2 No. 2

de

Si por el contrario es mal disenado, será un producto conaltos costos de mantenimiento, que presenta muchasdificultades para realizarle las pruebas y será pococonfiable.

Especificación de requerimientos funcío- de fácil implementación y mantenimiento, muy enten-naíes, dible y confiable.

Las relaciones entre entradas, acciones y salidas.

Especificaciónoperación.

de requerimientos

Características de operación tales como tiempo derespuesta de varias actividades, tiempo de procesa-miento de varios procesos, número de procesos eje-cutados, restricciones de memoria primaria ysecundaria, etc.

Manejo de excepciones.

Incluye acciones a tomar y mensajes de respuestas aenviar ante situaciones no deseadas. Se recomien-da preparar una tabla con las condiciones de excep-ción y sus respuestas.

- Subconjuntos Iniciales y prioridades deImplementaclón.

Ejemplo: desarrollo del proyecto por versiones. Ver-sión prototipo, versión modesta y versión mejorada.

- Modificaciones y mejoras previsibles.

Modificaciones al producto por cambio en presupues-to o en el objetivo, por adquisición de nuevo equipo,etc.

Cr1terlos de aceptación.

Especifican las pruebas funcionales y de rendimientoque se deben realizar, los estándares aplicables alcódigo fuente y documentación interna, y documen-tos de diseno, plan de pruebas, manual de usuario yprocedimientos de instalación y mantenimiento.

3.1.3 Etapa de Diseño.

Es la descripción conceptual de COMO va a ser elproducto que cumpla con las especificaciones.

Es en esta etapa donde se establece una estructura, seidentifican tipos de datos y su almacenamiento, se des-componen funciones de alto nivel en subfunciones, seestablecen relaciones e interconexiones entre compo-nentes y se especifican en forma detallada los algorit-mos.

Es la parte más crítica en el proceso de desarrollo desoftware, porque si el producto está bien diseñado será

HEURISTICA. VoL 2 No. 2 13

Existen varias técnicas de amplio uso en los últimos anospara el diseno de productos de software. Ellas incluyenel refinamiento paso a paso, los niveles de abstracción,el diseno estructurado, el desarrollo integrado jerárquicohacia abajo (TOP-DOWN), el desarrollo jerárquico haciaarriba (BOTTON-UP) y la programación estructurada deJackson. Todas ellas son metodologías de diseno queaportan un marco de trabajo a la actividad creativa deldiseno de productos de software.

Como en las fases anteriores, en esta fase debeproducirse el DOCUMENTO DE DISEÑO que contendrá:

Especificaciones de diseno externo, conformadaspor:

Despliegue para el usuario y formatos de informe.Resumen de comandos para el usuario.Diagramas de flujo de datos detallados.Archivos de datos lógicos.Diccionario de datos lógicos.Fonnatos lógicos de archivos de datos y bases dedatos.

Especificaciones de diseno arquitectónico, confor-madaspor:

Diagramas de estructura.Especificaciones de parámetros.Estructuras de datos lógicas.Descripciones funcionales.

Especificaciones de diseno detallado, conformadaspor:

Especificaciones de inferfaces de subprogramas.Prólogo de documentación para cada rutina.Seudocódigo para cada rutina.Estructura de datos físicos y especificaciones dearchivos de datos.

3.1.4 Etapa de Implementación.

Consta de dos fases, la de codificación y la de prueba.

La de codificación, comprende la escogencia de un

lef9Jaje de programación ac:lecuadoque facilite la pro-ducción de programas confiables y mantenibles y, laproducción del programa guardando un buen estilo deprogramación (uso de metodologías TOP-DOWN yBOTTOM-UP, doaJmentación interna, uso de nombressignificativos para las variables, manejo de módulos ymanipulaciónde errores, entre otros).

La de prueba, tiene como objetivo establecer existenciade errores, Iocalizarlos y corregirlos. Vale recordar que laprueba de software nunca puede demostrar la ausenciade errores.

Existen diversos niveles de prueba y pueden resaltarsecomo principales los siguientes: prueba de módulo ounidad, prueba de integración, prueba funcional, pruebadel sistema y prueba de instalación y prueba de vida.Una buena práctica para realizar procedimientos deprueba es seguir la metodología TOP-DOWN (detalle deprocedimientos y tipos de prueba, se presentan en elartículode la referencia (3)).

E.n esta etapa se producen, el programa fuente y eldocumento de prueba que contiene, el tipo de datosusados en los diferentes niveles de prueba y losresultadosde las mismas.

A lo largo de todo el proceso de desarrollo se haacurrulado información que facilita la producción de unMANUAL DE USUARIO. Este es un documentofundamental y debe contener:

Razón del producto y panorámica, terminología,características básicas resumen de formatos dedespliegue e infonnes y o~;;cripci6ndel manual;

Iniciación (con una corrida de nuestra):

Modos de operación (comandos I despliegues Iopciones);

Caracterrsticas avanzadas y sintaxis de comandos yopciones del sistema.

PERSONAL DEL PROYECTO O EQUIPOHUMANO DE TRABAJO.

Como se ha dicho antes, un producto de software esdesarrolladopor un equipo humanode trabajo.

Según el enfoque de Terry Baker de IBM el equipode trabajo debe estar constituido por:

Programadorjefe de equipo.Programadorprincipal (o de respaldo).Bibliotecario.

14

ProgramadoresJunior: programadores I analistas.El equipo es similar a un equipo de cirujanos donde cadamiembro tiene adiestramiento crítico y responsabilidadesseparadas. Aunque es una organización democrática,ellos deben ser una cadena con jerarquía para aseguraruna dirección consistente de esfuerzos y objetivoscomunes.

El programador jefe tiene el papel principal y elprogramador de respaldo tiene el segundo lugar en elcontrol. El tercer miembro es el bibliotecario del proyec-to que juega un papel de soporte. Todos ellos tienenresponsabilidadesespecíficas.

El programador jefe es el líder o director técnico delequipo. Todos los demás miembros deben informar1ede sus actividades. El es responsable por decisiones dediseño crítico y por algunas actividades de programacióncríticas, coordina actividades del equipo, supervisa lacalidad del producto final y el desarrollo de cada etapadel proceso.

Debe ser un profesional con experiencia en procesa-miento de datos, con suficientes conocimientos técni-cos y con probada habilidad de dirección.

El programador de respaldo es tan experimentadocomo el Programador Jefe, trabaja estrechamente con ély puede reemplazarlo en cualquier momento que serequiera.

El Bibliotecario es el responsable de toda la docu-mentación que se produzca durante el desarrollo delproyecto. El mantiene los módulos de programa fuente,módulos de carga, datos de prueba y demás datos delsistema. Es responsable de todo el control usado paramantener la integridad y separación de los diferentesniveles de los sistemas de biblioteca y proyectos relacio-nados con lastareas a ejecutar.

Programadores Junior tienen bajo su responsa-bilidad, junto con los tres miembros antes mencionadosel desarrollo detallado de los diversos módulos delprograma. A menudo, el trío conformado por el Progra-mador Jefe, el Programador de respaldo y el Bibliotecariodel proyecto se encargan de todas las tareas del ciclo dedesarrollo, es decir, desde la etapa de requerimientoshasta la de implementación.

CONCLUSIONES

Se puede concluir que existe una clara diferencia entre

HEURlSTICA. VoL 2 No. 2

ABAD lA, María Eugenia Valencia de. Guíapara lapreparación de un documento de Requeri-mientos. RevistaHeurística,V1, diciembre 1987.

lo que es desarrollar software de uso personal, yproductos de software.

- La ingeniería de software provee los elementos delenfoque sistemático y del conocimiento científico,para el desarrollo de productos de software.

- Es irnperante la conformación de un equipo de traba-jo liderado por su programador jefe, donde cadamierrbro tendrá responsabilidades bien definidas yenmarcadas dentro de un plan de desarrollo trazadopriviamente.

- Desarrollar productos de software implica una tareamuchísimo más seria que la simple escritura de unprograma. Lleva consigo procesos de análisis, deabstracción, de diseno, implernentación y manteni-miento que exigen el uso de metodologías apropia-das y contar con un verdadero trabajo en equipo.

REFERENCIAS BIBLlOGRAFICAS

(1) . ABAD lA, José Antonio. Ingeniería de Software.Univalle 1985.

HEURISTICA.

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

ABAD lA, María Eugenia Valencia de. Procedi-mientos para prueba de Software. PublicacionesICESI No. 18, Enero- Marzo 1986.

BOEHM, B. W. Software Engineering Econo-mies. Prentice Hall 1981.

FAIRLEY, Richard. Ingeniería de Software.McGraw-HiII,1987.

IEEE Standard Glossary o, SOftware EngineeringTerminology, IEEE Standard 729-1983.

KING, David. cútrem Practices in SoftwareDevelopment. Yourdon Press 1984.

SOMMERVILLE 1. Software Engineering.Addison Wesley Publishing Co. 1982.

ZELKOWITZ - SHAW - GANNON. PrincipIes o,Software Engineering and Design. Prentice Hall.1979.

•

!(

,1

15