La Ingeniera de Software

Segn la definicin del IEEE, citada por [Lewis 1994] "software es la suma total de los programas de computadora, procedimientos, reglas, la documentacin asociada y los datos que pertenecen a un sistema de cmputo". Segn el mismo autor, "un producto de software es un producto diseado para un usuario". En este contexto, la Ingeniera de Software (SE del ingls Software Engineering) es un enfoque sistemtico del desarrollo, operacin, mantenimiento y retiro del software", que en palabras ms llanas, se considera que "la Ingeniera de Software es la rama de la ingeniera que aplica los principios de la ciencia de la computacin y las matemticas para lograr soluciones costo-efectivas (eficaces en costo o econmicas) a los problemas de desarrollo de software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costo-efectivos" [Cota 1994]. El proceso de ingeniera de software se define como "un conjunto de etapas parcialmente ordenadas con la intencin de logra un objetivo, en este caso, la obtencin de un producto de software de calidad" [Jacobson 1998].El proceso de desarrollo de software "es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseo y el diseo implementado en cdigo, el cdigo es probado, documentado y certificado para su uso operativo". Concretamente "define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo" [ Jacobson 1998]. El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodologa y un lenguaje propio. A este proceso tambin se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepcin, elaboracin, construccin y transicin. La concepcin define le alcance del proyecto y desarrolla un caso de negocio. La elaboracin define un plan del proyecto, especifica las caractersticas y fundamenta la arquitectura. La construccin crea el producto y la transicin transfiere el producto a los usuarios. Actualmente se encuentra en una etapa de madurez el enfoque Orientado a Objetos (OO) como paradigma del desarrollo de sistemas de informacin. El Object Management Group (OMG) es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnologa de informacin OO. El OMG tiene como objetivo central la promocin, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especificaciones entorno a la tecnologa OO. Una de las especificaciones ms importantes es la adopcin en 1998 del Lenguaje de Modelado Unificado o UML (del ingls Unified Modeling Language) como un estndar, que junto con el Proceso Unificado estn consolidando la tecnologa OO.

El Paradigma de lo Orientado a Objetos

Antes de analizar los pasos del proceso de desarrollo de software se expondrn los conceptos fundamentales del paradigma que gua la tecnologa OO. Existen conceptos ligados en torno a la tecnologa orientada a objetos: el paradigma, los principios, el anlisis y el diseo, mismos que a continuacin se comentan.

La Programacin Orientada a Objetos

La Programacin Orientada a Objetos (OOP por sus siglas en ingls de Object Oriented Programming) como paradigma, "es una forma de pensar, una filosofa, de la cual surge una cultura nueva que incorpora tcnicas y metodologas diferentes. Pero estas tcnicas y metodologas, y la cultura misma, provienen del paradigma, no lo hacen. La OOP como paradigma es una postura ontolgica: el universo computacional est poblado por objetos, cada uno responsabilizndose por s mismo, y comunicndose con los dems por medio de mensajes" [Greiff 1994]. Se debe distinguir que la OOP como paradigma (enfoque o manera de visualizar la realidad) y como metodologa (coleccin de caractersticas para la ingeniera de software) no son la misma cosa. Sin embargo, la publicidad nos confunde asociando la OOP ms a una metodologa, que al paradigma. De aqu que "el inters en la OOP radica ms en los mecanismos que aporta para la construccin de programas que en aprovechar un esquema alterno para el modelado de procesos computacionales" [Greiff 1994]. La Programacin Orientada a Objetos desde el punto de vista computacional "es un mtodo de implementacin en el cul los programas son organizados como grupos cooperativos de objetos, cada uno de los cuales representa una instancia de alguna clase, y estas clases, todas son miembros de una jerarqua de clases unidas va relaciones de herencia" [ Greiff 1994].

Fundamentos de lo Orientado a Objetos

El paradigma OO se basa en el concepto de objeto. Un objeto es aquello que tiene estado (propiedades ms valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos). La estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento comn. La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstraccin, la "esencia" de un objeto, tal como son. De aqu que un objeto no es una clase, sin embargo, una clase puede ser un objeto. En el enfoque OO las propiedades del objeto son claves. Los principios del modelo OO son: abstraccin, encapsulacin, modularidad y jerarqua, fundamentalmente, y en menor grado tipificacin (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.

Abstraccin. Es una descripcin simplificada o especificacin de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros. Encapsulacin. En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus caractersticas esenciales. Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes.

Jerarqua o herencia. Es el orden de las abstracciones organizado por niveles. Tipificacin. Es la definicin precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida. Concurrencia . Es la propiedad que distingue un objeto que est activo de uno que no lo est. Persistencia. Es la propiedad de un objeto a travs de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o el espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue creado).

Segn [Booch 1986], los beneficios del enfoque OO son:

Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos los lenguajes de programacin basados en objetos y los orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, y recientemente Java . Segundo, el uso del modelo OO alienta el reuso no solo del software, sino de diseos completos. Tercero, produce sistemas que estn construidos en formas intermedias estables y por ello son ms resistentes al cambio en especificaciones y tecnologa.

El mismo autor considera que el principal beneficio del OOD es que da un mecanismo para formalizar el modelo de la realidad. Las relaciones entre objetos definen el comportamiento del sistema. Se dice que un objeto es un actor, si su nica funcin es operar sobre otros objetos. El objeto es un servidor si solo es manejado por otros objetos y es un agente si tiene ambas propiedades. Se dice que los objetos actan entre s mediante mensajes, es decir, acciones que pide el objeto transmisor que ejecute el objeto receptor. Dependiendo del comportamiento definido para un objeto, ste tomar las acciones para ejecutar o no el mensaje, de manera apropiada. [Greiff 1994] comenta que el Anlisis Orientado a Objetos (OOA por sus siglas en ingls de Object Oriented Analysis) "es un mtodo de anlisis que examina los requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario de del dominio del problema". Segn [Booch 1986], el Diseo Orientado a Objetos "es un mtodo de diseo abarcando el proceso de descomposicin orientado a objetos y una notacin para representar ambos modelos lgico y fsico tal como los modelos estticos y dinmicos del sistema bajo diseo". En cuanto a las metodologas OO, diremos que hay un gran nmero de mtodos orientado a objetos actualmente. Muchos de los mtodos pueden ser clasificados como orientados a objetos porque soportan de manera central los conceptos de la orientacin a objetos. Algunos de las metodologa ms conocidas y estudiadas hasta antes del UML segn [ Jacobson 1992] son:

Object-Oriented Design (OOD), Booch. Object Modeling Technique (OMT), Rumbaugh. Object Oriented Analysis (OOA), Coad/Yourdon. Hierarchical Object Oriented Design (HOOD), ESA.

Object Oriented Structured Design (OOSD), Wasserman. Object Oriented Systems Analysis (OOSA), Shaler y Mellor. Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.

Actualmente las metodologas ms importantes de anlisis y diseo de sistemas han confluido en lo que se es el UML, bajo el respaldo del Object Management Group.

El Proceso Unificado
El Proceso Unificado "es un proceso de desarrollo de software configurable que se adapta a travs de los proyectos variados en tamaos y complejidad. Se basa en muchos aos de experiencia en el uso de la tecnologa orientada a objetos en el desarrollo de software de misin crtica en una variedad de industrias por la compaa Rational", donde confluyen 'los tres amigos' como se llaman a s mismos o los tres grandes OO: Grady Booch, James Rumbaugh e Ivar Jacobson [M&R 1998]. El Proceso Unificado gua a los equipos de proyecto en cmo administrar el desarrollo iterativo de un modo controlado mientras se balancean los requerimientos del negocio, el tiempo al mercado y los riesgos del proyecto. El proceso describe los diversos pasos involucrados en la captura de los requerimientos y en el establecimiento de una gua arquitectnica lo ms pronto, para disear y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El proceso describe qu entregables producir, cmo desarrollarlos y tambin provee patrones. El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administracin de cambios y las pruebas.

Proceso Unificado y MSF; complementos tecnolgicos

Segn [M&R 1998], "ms que una metodologa, Microsoft Solutions Framework ( MSF) es una serie de modelos flexibles interrelacionados que guan a una organizacin sobre como ensamblar los recursos, el personal y las tcnicas necesaria para asegurar que su infraestructura tecnolgica y sus soluciones cumplan los objetivos de negocio. MSF mantiene una relacin clara entre los objetivos de negocio y las implementaciones tecnolgicas". "MSF se puede utilizar por s mismo o con otras herramientas y tcnicas como el Proceso Rational [Proceso Unificado] para planear, construir y administrar el desarrollo de soluciones de negocio a la medida" [M&R 1998]. "El proceso Unificado es un proceso de desarrollo de software configurable que se adapta a proyectos que varan en tamao y complejidad. Se basa en muchos aos de experiencia en el uso de la tecnologa de objetos en el desarrollo de software de misin crtica en una variedad de industrias. Uno de los componentes clave es el UML" [M&R 1998]. MSF proporciona las tcnicas ligadas a la tecnologa y el Proceso Unificado la gua detallada para el desarrollo de software minimizando los riesgos.

El Proceso Unificado ha adoptado un enfoque que se caracteriza por:

Interaccin con el usuario continua desde un inicio Mitigacin de riesgos antes de que ocurran Liberaciones frecuentes Aseguramiento de la calidad Involucramiento del equipo en todas las decisiones del proyecto Anticiparse al cambio de requerimientos

El Proceso Unificado y MSF se enfocan en la arquitectura como el centro del desarrollo para asegurar que el desarrollo basado en componentes sea clave para un alto nivel de reuso. MSF considera que hay cuatro perspectivas de arquitectura que cumplen los requerimientos de una empresa [M&R 1998]:

Arquitectura de Negocios - Describe como opera un negocio. Desarrolla una imagen clara de los procesos de flujo de trabajo de la organizacin y de cmo son apoyados por una infraestructura tecnolgica basada en servicios. Arquitectura de Aplicacin Adopta un modelo de aplicacin de toda la empresa para disear y desarrollar sistemas de negocios que puedan compartir un conjunto de componentes back-end de alto valor. Arquitectura de Informacin Define qu informacin es necesaria para apoyar el proceso de negocios y como poner esa informacin eficientemente en manos de quienes que la necesitan sin crear islas de datos inaccesibles ni sistemas redundantes. Arquitectura Tecnolgica Define los estndares y guas para la adquisicin y despliegue de herramientas, bloques de construccin de aplicaciones, servicios de infraestructura, componentes de conectividad de red y plataformas cliente servidor.

El Modelo de Equipo de MSF muestra como estructurar equipos de alto desempeo para crear soluciones ms rpido, mejor y ms baratas. El Modelo de Equipo de MSF se basa en las formas de organizar equipos para crear los propios productos de Microsoft. Hace nfasis en las comunicaciones claras y en un equipo de iguales con papeles y responsabilidades claras en todo el proyecto. La calidad del producto se asegura por cada miembro del equipo. El Proceso Unificado proporciona ms detalle y gua para algunos de los roles en el proyecto. Una vista arquitectnica es "una descripcin simplificada (una abstraccin) de un sistema desde una perspectiva particular o punto de vista, que cubre particularidades y omite entidades que no son relevantes a esta perspectiva" [Booch 1998]. Segn el mismo autor, las caractersticas primordiales del Proceso Unificado son:

Iterativo e incremental Centrado en la arquitectura Guiado por casos de uso Confrontacin de riesgos

El Proceso Unificado es un proceso porque "define quin est haciendo qu, cundo lo hacer y cmo alcanzar cierto objetivo, en este caso el desarrollo de software" [ Jacobson 1998]. Segn [Booch 1998], los conceptos clave del Proceso Unificado son:

Fase e iteraciones Flujos de trabajo de procesos (actividades y pasos) Artefactos (modelos, reportes, documentos) Trabajador: un arquitecto

Cundo se hace? Qu se est haciendo? Qu se produjo? Quin lo hace?)

El ciclo de vida del software en el Proceso Unificado Las fases del ciclo de vida del software son: concepcin, elaboracin, construccin y transicin. La concepcin es definir el alcance del proyecto y definir el caso de uso. La elaboracin es proyectar un plan, definir las caractersticas y cimentar la arquitectura. La construccin es crear el producto y la transicin es transferir el producto a sus usuarios [ Booch 1998].

Figura 1. Estructura del Proceso Unificado Segn [Microsoft 1997], el diseo de software se realiza a tres niveles: conceptual, lgico y fsico.

Figura 2. Arquitectura lgica de tres capas de una aplicacin cliente/servidor

Un ingeniero de software necesita de herramientas, entre ellas las herramientas de Rational son las ms avanzadas, pero son muy costosas. Tambin puede utilizar las herramientas de oficina como un editor de textos, un modelador de datos, etc., muchas de ellas son de cdigo abierto y an estn de desarrollo. Utiliza las que ms te sean de utilidad. Diseo Conceptual El diseo conceptual se considera como un anlisis de actividades y consiste en la solucin de negocios para el usuario y se expresa con los casos de uso. El diseo lgico es la solucin del equipo de proyecto del negocio y consiste de las siguientes tareas:

Identificar los usuarios y sus roles Obtener datos de los usuarios Evaluar la informacin Documentar los escenarios de uso Validar con los usuarios Validar contra la arquitectura de la empresa

Una forma de obtener estos requerimientos es construir una matriz usuarios-actividades de negocios, realizar entrevistas, encuestas y/o visitas a los usuarios, de tal manera que se obtenga quin, qu, cundo, dnde y por qu de la solucin. Diseo Lgico El diseo lgico traduce los escenarios de uso creados en el diseo conceptual en un conjunto de objetos de negocio y sus servicios. El diseo lgico se convierte en parte en la especificacin funcional que se usa en el diseo fsico. El diseo lgico es independiente de

la tecnologa. El diseo lgico refina, organiza y detalla la solucin de negocios y define formalmente las reglas y polticas especficas de negocios. Un objeto de negocios es la encapsulacin de un servicio que abstrae las cualidades esenciales de algo de inters. Un servicio es una unidad con capacidad de cmputo. Un servicio debe satisfacer lo siguiente:

Ser seguro, lo que equivale a un uso correcto y con autorizacin Ser vlido, qu tareas o reglas se pueden aplicar Manejar excepciones, informando al cliente Contar con un catlogo de servicios que constituye un repositorio de servicios.

Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los mdulos operen como unidades completas de trabajo. Las tareas de verificacin incluyen:

Una verificacin independiente: o Pre y post condiciones o Lgica y funcionalidad individual Una verificacin dependiente: o Verificacin de dependencias o Que operan como una unidad especfica de trabajo

El diseo lgico comprende las siguientes tareas:

Identificar y definir los objetos de negocio y sus servicios Definir las interfases Identificar las dependencias entre objetos Validar contra los escenarios de uso Comparar con la arquitectura de la empresa Revisar y refinar tanto como sea necesario

Para definir los objetos de negocios y sus servicios se puede usar la tcnica de anlisis nombre-verbo de los escenarios de uso. Tambin se puede emplear la tcnica sujeto-verboobjeto directo. En estas tcnicas los sujetos y el objeto directo son los candidatos a objetos de negocio y los verbos activos son los candidatos a servicios. Una interfase tiene las siguientes partes:

Nombre Precondiciones, lo que debe estar presente antes de ejecutarse Postcondiciones, estado final Capacidad o funcionalidad (SQL, pseudocdigo, funcin matemtica) Dependencias

La tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realizacin de tareas de negocios coordinadamente o transaccionalmente. Para ello se debe considerar lo siguiente:

Identificar los eventos disparadores (triggers) Determinar cualquier dependencia (existencial o funcional) Determinar cualquier problema de consistencia o secuencia Identificar cualquier regulacin de tiempo crtica Considerar algn problema organizacional (transacciones) Identificar y auditar los requerimientos de control Determinar lugares y dependencias a travs de la ubicacin Determinar cuando el servicio que controla la transaccin es dependiente de los servicios contenidos en otros objetos de negocio

La validacin del modelo lgico debe ser tal que ste sea:

Completo debe representar todos los escenarios de uso, Correcto el comportamiento lgico debe corresponder con el comportamiento conceptual, y Claro los objetos de negocio y servicios no deben ser ambiguos

En el diseo lgico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicacin resulte flexible ante los cambios de requerimientos y/o de tecnologa cambiando nicamente la capa o capas necesarias. Los tres niveles son: servicios de usuario, servicios de negocio y servicios de datos. Los servicios de usuario (user services) controlan la interaccin. Un servicio de usuario son personas, aplicaciones, otros servicios o la combinacin de stos. Generalmente involucra una interfase grfica de usuario (GUI) o pude ser no visual (mensajes o funciones), maneja todos los aspectos de la interaccin con la aplicacin. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la informacin. Un servicio de usuario incluye un contenido (qu se necesita comunicar al usuario) y una forma (cmo se comunica el contenido) cuando es necesaria la comunicacin. Los servicios de negocio (bussines services) convierten datos recibidos de los servicios de datos y de usuario en informacin (datos + regla de negocio) y pueden usar otros servicios de negocio para completar su tarea. Las tareas de los servicios de negocio son:

Dar formato a los datos Obtener y mover datos desde y hasta los servicios de datos Transformar los datos en informacin Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transaccin.

Los servicios de datos (data services) son los servicios de bajo nivel que apoyan los servicios de negocio y son de una amplia gama de categoras como las siguientes:

Declaracin del esquema y su evolucin (estructuras de datos, tipos, acceso indexado, SQL, APIs) Respaldo y recuperacin (recuperacin de datos si un evento falla)

Bsqueda y Lectura (bsquedas, compilacin, optimizacin y ejecucin de solicitudes, formacin de un conjunto de resultados) Insercin, actualizacin y borrado (procesar modificaciones consistentemente transaccional). Una transaccin es atmica (ocurre o no), consistente (preserva integridad), aislada (otras transacciones ocurren antes o despus) y durable (una vez completada, sta sobrevive). Bloqueo (permite al acceso concurrente a los datos) Validacin de datos (verifica la integridad del dominio, triggers y gateways para verificar el estado de los datos antes de aceptarlos, manejo de errores) Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios) Administracin de la conexin (mecanismos bsicos para establecer una sesin de los servicios de datos). Establecer una conexin involucra: una identificacin, la colocacin y provisin de datos, tiempo de sesin, el tipo de interaccin (conversacional, transaccional, multiusuario, monousuario). Distribucin de datos (Distribuye informacin, a mltiples unidades de recuperacin, bases de datos heterogneas, segn la topologas de la red).

Diseo fsico El diseo fsico traduce el diseo lgico en una solucin implementable y costo-efectiva o econmica. El componente es la unidad de construccin elemental del diseo fsico. Las caractersticas de un componente son:

Se define segn cmo interacta con otros Encapsula sus funciones y sus datos Es reusable a travs de las aplicaciones Puede verse como una caja negra Puede contener otros componentes

En el diseo fsico se debe cuidar el nivel de granularidad (un componente puede ser tan grande o tan pequeo segn su funcionalidad, es decir, del tamao tal que pueda proveer de una funcionalidad compleja pero de control genrico) y la agregacin y contencin (un componente puede reusar utilizando tcnicas de agregacin y contencin, sin duplicar cdigo). El diseo fsico debe involucrar:

El diseo para distribucin debe minimizarse la cantidad de datos que pasan como parmetros entre los componentes y stos deben enviarse de manera segura por la red. El diseo para multitarea debe disearse en trminos de la administracin concurrente de dos o ms tareas distintas por una computadora y el multithreading o mltiples hilos de un mismo proceso) El diseo para uso concurrente el desempeo de un componente remoto depende de si est corriendo mientras recibe una solicitud. El diseo con el manejo de errores y prueba de eventos:

o o o o o

Validando los parmetros- a la entrada antes de continuar con cualquier proceso. Protegiendo recursos crticos manejar excepciones para evitar la falla o terminacin sin cerrar archivos, liberar objetos sincronizados o memoria. Protegiendo datos importantes contar con una excepcin a la mitad de la actuacin en las bases de datos. Debugging crear una versin para limpiar errores. Proteccin integral de transacciones de negocios los errores deben regresarse al componente que llama.

Figura 3. Arquitectura fsica de tres capas de la aplicacin cliente/servidor El diseo fsico comprende las siguientes tareas:

Definir los componentes Refinar el empaquetamiento y distribucin de componentes Especificar las interfases de los componentes Distribuir los componentes en la red Distribuir los repositorios fsicos de datos Examinar la tolerancia a fallas y la recuperacin de errores Validar el diseo fsico

De las tareas anteriores la ms importante es la distribucin de los datos que pueden ser centralizados, una particin, un extracto o una rplica. Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos.

Una particin de datos es una segmentacin de la base de datos maestra. Es til cuando los datos se pueden fragmentar fcilmente y actualizarse en un sitio local con cambios frecuentes. No hay sobreposicin entre particiones. En una particin horizontal cada hilera existe en una sola base de datos. En una particin vertical cada columna es contenida en una y solo una base de datos. Un extracto de datos es una copia de toda o una porcin de la base de datos maestra. No se permite la actualizacin. Se usa un timestamp o etiqueta de tiempo para indicar qu tan viejos son los datos. Una rplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. Una rplica de datos es cuando el sitio de actualizacin cambia a un sitio local. No se permiten actualizaciones en la base de datos rplica y en la base de datos maestra a la vez, por lo que debe de haber sincronizacin entre ambas. El diseo fsico est ntimamente ligado a una alternativa tecnolgica. Ante la acelerada evolucin tecnolgica es importante considerar los estndares del momento y las tendencias ya que una mala decisin implicar un costo enorme (en dinero y en tiempo) al actualizarse a otra plataforma distinta. La tendencia actual en la arquitectura cliente/servidor es crear el back-end como un servidor robusto multitareas y multithreading y el front-end como un cliente muy delgado que no acapare al servidor comunicndose entre s en una plataforma internet con protocolos estndar en redes heterogneas.

La ingeniera de software NO es lo que piensas

En mis investigaciones, de campo y bibliogrficas, llevadas a cabo desde 2005 a la fecha, me han llevado a concluir que la Ingeniera de Software no es lo que uno supone que es, o en otras palabras, no es lo que institucionalmente se nos ha hecho creer. A pesar del nombre de ingeniera, sta dista mucho de ser tal. La ingeniera de software, no es una disciplina de ingeniera sino una disciplina de administracin (o management) impulsada desde sus orgenes por el Departamento de Defensa de los Estados Unidos (DoD), como lo demuestra la investigacin histrica. La esencia del objeto de estudio de la Ingeniera de Software como disciplina tericoprctica, es decir, su ontologa es de naturaleza ms organizacional que ingenieril, aunque tiene un componente tecnolgico muy importante. En otras palabras, la ingeniera de software, es ms que la codificacin del software en un lenguaje de programacin, ms que el Lenguaje Unificado de Modelado (UML, Unified Modeling Language) y la programacin orientada a objetos, ms que el Proceso Unificado Rational (RUP, Rational Unified Process), ms que la administracin de proyectos (project management), es una prctica social y una ocupacin en vas de convertirse en profesin y una de las pocas actividades econmicas que crecen a una tasa anual de dos dgitos, en todo el mundo.