¿QUÉ ES LA INGENIERÍA DE SOFTWARE? ¿QUÉ ES LA
Area de Ingeniería de Sistemas y Automática (informática IndustrialEscuela Superior Politécnica del Litoral Facultad de Ingeniería Eléctrica
Escuela Técnica Superior de Ingeniería del Diseño Asignatura Fisicoquimica
Universidad Nacional de Ingeniería Recinto Universitario Augusto c Sandino
Universidad Nacional de la Plata Facultad de Ingeniería
Universidad Tecnológica de Querétaro Ingeniería en Procesos y Operaciones
¿Qué es la ingeniería de Software
¿Qué es la ingeniería de Software?
¿Qué es la ingeniería de software? ¿Existe alguna visión alternativa que resuelva su desafío? Fundamentalmente, estas son las dos preguntas que intenta responderse en esta página web que originalmente fue un ensayo como parte de mi tesis de Maestría en Ciencia de la Computación ([Zavala 2000]), sin embargo, nunca la defendí. Con los años, ese ensayo se ha convertido muy popular y ello me obligó a profundizar mis investigaciones al respecto. En 2011, finalmente presenté mi tesis de grado que se centra en este tema, del cual muestro algunos detalles.
En la primera parte se aborda la concepción técnica o tradicional de lo que se le atribuye a la definición de ingeniería de software. Información complementaria pueden obtenerla en Wikipedia y en la Guide to Software Engineering Body of Knowledge (SWEBoK).
En la segunda parte se remite al lector a un ensayo que se publicó en el libro de H. Oktaba y M. Piattini (Eds.) Software Process Improvement for Small and Medium Enterprises: Techniques and Case Studies, en 2008.
En la tercera parte se expone brevemente una concepción ecléctica de lo que es la ingeniería de software a partir de mis últimas investigaciones, condensadas en la tesis de maestría con la cual obtuve el grado en 2011. En este ensayo se desnudan los mitos que se han generado en torno a la ingeniería de software a partir de investigar sus fundamentos. La tesis estará en línea próximamente en la biblioteca de la Universidad Autónoma Metropolitana - Unidad Azcapotzalco.
Parte 1: ¿Qué es la Ingeniería de Software?: La visión tradicional
El Paradigma de lo Orientado a Objetos
La Programación Orientada a Objetos
Fundamentos de lo Orientado a Objetos
Proceso Unificado y MSF; complementos tecnológicos
El ciclo de vida del software en el Proceso Unificado
Figura 1. Estructura del Proceso Unificado
Figura 2. Arquitectura lógica de tres capas de una aplicación cliente/servidor
Figura 3. Arquitectura física de tres capas de la aplicación cliente/servidor
Comentario Final... para reflexionar
Según la definición del IEEE, citada por [Lewis 1994] "software es la suma total de los programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo". Según el mismo autor, "un producto de software es un producto diseñado para un usuario". En este contexto, la Ingeniería de Software (SE del inglés Software Engineering) es un enfoque sistemático del desarrollo, operación, mantenimiento y retiro del software", que en palabras más llanas, se considera que "la Ingeniería de Software es la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas (eficaces en costo o económicas) a los problemas de desarrollo de software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costo-efectivos" [Cota 1994].
El proceso de ingeniería de software se define como "un conjunto de etapas parcialmente ordenadas con la intención de logra un objetivo, en este caso, la obtención 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 diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo". Concretamente "define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo" [Jacobson 1998].
El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodología y un lenguaje propio. A este proceso también se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepción, elaboración, construcción y transición. La concepción define le alcance del proyecto y desarrolla un caso de negocio. La elaboración define un plan del proyecto, especifica las características y fundamenta la arquitectura. La construcción crea el producto y la transición 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 información. El Object Management Group (OMG) es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnología de información OO. El OMG tiene como objetivo central la promoción, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especificaciones entorno a la tecnología OO. Una de las especificaciones más importantes es la adopción en 1998 del Lenguaje de Modelado Unificado o UML (del inglés Unified Modeling Language) como un estándar, que junto con el Proceso Unificado están consolidando la tecnología OO.
Para mayor información consulta las siguientes direcciones electrónicas:
Carnegie Mellon's Software Engineering Institute (SEI) donde encontrarás información y documentos relacionados con la Ingeniería de Software, análisis y diseño, metodologías, métricas, certificación, calidad (CMM), seguridad (CERT), etc.
The Rational Edge e-Magazine Es una revista electrónica donde mensualmente se publican artículos sobre la importancia de la ingeniería en el software, con experiencias de la industria
Herramientas de Ingeniería de Software Aquí encontrarás información sobre las herramientas líderes que implementan la ingeniería de software, desde el modelado de sistemas con UML hasta el proceso unificado que tiene que ver con la administración de proyectos.
El Paradigma de lo Orientado a Objetos
Antes de analizar los pasos del proceso de desarrollo de software se expondrán los conceptos fundamentales del paradigma que guía la tecnología OO.
Existen conceptos ligados en torno a la tecnología orientada a objetos: el paradigma, los principios, el análisis y el diseño, mismos que a continuación se comentan.
La Programación Orientada a Objetos
La Programación Orientada a Objetos (OOP por sus siglas en inglés de Object Oriented Programming) como paradigma, "es una forma de pensar, una filosofía, de la cual surge una cultura nueva que incorpora técnicas y metodologías diferentes. Pero estas técnicas y metodologías, y la cultura misma, provienen del paradigma, no lo hacen. La OOP como paradigma es una postura ontológica: el universo computacional está poblado por objetos, cada uno responsabilizándose por sí mismo, y comunicándose con los demás por medio de mensajes" [Greiff 1994].
Se debe distinguir que la OOP como paradigma (enfoque o manera de visualizar la realidad) y como metodología (colección de características para la ingeniería de software) no son la misma cosa. Sin embargo, la publicidad nos confunde asociando la OOP más a una metodología, que al paradigma. De aquí que "el interés en la OOP radica más en los mecanismos que aporta para la construcción de programas que en aprovechar un esquema alterno para el modelado de procesos computacionales" [Greiff 1994].
La Programación Orientada a Objetos desde el punto de vista computacional "es un método de implementación en el cuál 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 jerarquía de clases unidas vía 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 más valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los demás objetos). La estructura y comportamiento de objetos similares están definidos en su clase común; los términos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento común.
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 abstracción, 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: abstracción, encapsulación, modularidad y jerarquía, fundamentalmente, y en menor grado tipificación (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.
Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros.
Encapsulación. En el proceso de ocultar todos los detalles de un objetoque no contribuyen a sus características esenciales.
Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.
Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles.
Tipificación. Es la definición 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 través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado).
Según [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 programación 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 diseños completos.
Tercero, produce sistemas que están construidos en formas intermedias estables y por ello son más resistentes al cambio en especificaciones y tecnología.
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 función 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 actúan 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 Análisis Orientado a Objetos (OOA por sus siglas en inglés de Object Oriented Analysis) "es un método de análisis que examina los requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario de del dominio del problema". Según [Booch 1986], el Diseño Orientado a Objetos "es un método de diseño abarcando el proceso de descomposición orientado a objetos y una notación para representar ambos modelos lógico y físico tal como los modelos estáticos y dinámicos del sistema bajo diseño".
En cuanto a las metodologías OO, diremos que hay un gran número de métodos orientado a objetos actualmente. Muchos de los métodos pueden ser clasificados como orientados a objetos porque soportan de manera central los conceptos de la orientación a objetos. Algunos de las metodología más conocidas y estudiadas hasta antes del UML según [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 metodologías más importantes de análisis y diseño de sistemas han confluido en lo que se es el UML, bajo el respaldo del Object Management Group.
El Proceso Unificado "es un proceso de desarrollo de software configurable que se adapta a través de los proyectos variados en tamaños y complejidad. Se basa en muchos años de experiencia en el uso de la tecnología orientada a objetos en el desarrollo de software de misión crítica en una variedad de industrias por la compañía 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 guía a los equipos de proyecto en cómo 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 guía arquitectónica lo más pronto, para diseñar y probar el sistema hecho de acuerdo a los requerimientos y a la arquitectura. El proceso describe qué entregables producir, cómo desarrollarlos y también provee patrones. El proceso unificado es soportado por herramientas que automatizan entre otras cosas, el modelado visual, la administración de cambios y las pruebas.
Proceso Unificado y MSF; complementos tecnológicos
Según [M&R 1998], "más que una metodología, Microsoft Solutions Framework (MSF) es una serie de modelos flexibles interrelacionados que guían a una organización sobre como ensamblar los recursos, el personal y las técnicas necesaria para asegurar que su infraestructura tecnológica y sus soluciones cumplan los objetivos de negocio. MSF mantiene una relación clara entre los objetivos de negocio y las implementaciones tecnológicas".
"MSF se puede utilizar por sí mismo o con otras herramientas y técnicas 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 varían en tamaño y complejidad. Se basa en muchos años de experiencia en el uso de la tecnología de objetos en el desarrollo de software de misión crítica en una variedad de industrias. Uno de los componentes clave es el UML" [M&R 1998].
MSF proporciona las técnicas ligadas a la tecnología y el Proceso Unificado la guía detallada para el desarrollo de software minimizando los riesgos.
El Proceso Unificado ha adoptado un enfoque que se caracteriza por:
Interacción con el usuario continua desde un inicio
Mitigación 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 organización y de cómo son apoyados por una infraestructura tecnológica basada en servicios.
Arquitectura de Aplicación – Adopta un modelo de aplicación de toda la empresa para diseñar y desarrollar sistemas de negocios que puedan compartir un conjunto de componentes back-end de alto valor.
Arquitectura de Información – Define qué información es necesaria para apoyar el proceso de negocios y como poner esa información eficientemente en manos de quienes que la necesitan sin crear islas de datos inaccesibles ni sistemas redundantes.
Arquitectura Tecnológica – Define los estándares y guías para la adquisición y despliegue de herramientas, bloques de construcción 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 desempeño para crear soluciones más rápido, mejor y más 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 más detalle y guía para algunos de los roles en el proyecto.
Una vista arquitectónica es "una descripción simplificada (una abstracción) 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].
Según el mismo autor, las características primordiales del Proceso Unificado son:
Iterativo e incremental
Centrado en la arquitectura
Guiado por casos de uso
Confrontación de riesgos
El Proceso Unificado es un proceso porque "define quién está haciendo qué, cuándo lo hacer y cómo alcanzar cierto objetivo, en este caso el desarrollo de software" [Jacobson 1998]. Según [Booch 1998], los conceptos clave del Proceso Unificado son:
|
Fase e iteraciones |
¿Cuándo se hace? |
|
Flujos de trabajo de procesos (actividades y pasos) |
¿Qué se está haciendo? |
|
Artefactos (modelos, reportes, documentos) |
¿Qué se produjo? |
|
Trabajador: un arquitecto |
¿Quién lo hace?) |
El ciclo de vida del software en el Proceso Unificado
Las fases del ciclo de vida del software son: concepción, elaboración, construcción y transición. La concepción es definir el alcance del proyecto y definir el caso de uso. La elaboración es proyectar un plan, definir las características y cimentar la arquitectura. La construcción es crear el producto y la transición es transferir el producto a sus usuarios [Booch 1998].
Figura 1. Estructura del Proceso Unificado
Según [Microsoft 1997], el diseño de software se realiza a tres niveles: conceptual, lógico y físico.
Figura 2. Arquitectura lógica de tres capas de una aplicación cliente/servidor
Para mayor información consulta las siguiente dirección electrónica:
Herramientas de Ingeniería de Software Aquí encontrarás información sobre las herramientas líderes que implementan la ingeniería de software, desde el modelado de sistemas con UML hasta el proceso unificado que tiene que ver con la administración de proyectos.
SourceForge.net Es una base de datos de proyectos de software de código abierto u open source software.
Un ingeniero de software necesita de herramientas, entre ellas las herramientas de Rational son las más avanzadas, pero son muy costosas. También puede utilizar las herramientas de oficina como un editor de textos, un modelador de datos, etc., muchas de ellas son de código abierto y aún están de desarrollo. Utiliza las que más te sean de utilidad.
El diseño conceptual se considera como un análisis de actividades y consiste en la solución de negocios para el usuario y se expresa con los casos de uso. El diseño lógico es la solución 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 información
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 quién, qué, cuándo, dónde y por qué de la solución.
El diseño lógico traduce los escenarios de uso creados en el diseño conceptual en un conjunto de objetos de negocio y sus servicios. El diseño lógico se convierte en parte en la especificación funcional que se usa en el diseño físico. El diseño lógico es independiente de la tecnología. El diseño lógico refina, organiza y detalla la solución de negocios y define formalmente las reglas y políticas específicas de negocios.
Un objeto de negocios es la encapsulación de un servicio que abstrae las cualidades esenciales de algo de interés.
Un servicio es una unidad con capacidad de cómputo. Un servicio debe satisfacer lo siguiente:
Ser seguro, lo que equivale a un uso correcto y con autorización
Ser válido, qué tareas o reglas se pueden aplicar
Manejar excepciones, informando al cliente
Contar con un catálogo de servicios que constituye un repositorio de servicios.
Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los módulos operen como unidades completas de trabajo. Las tareas de verificación incluyen:
Una verificación independiente:
Pre y post condiciones
Lógica y funcionalidad individual
Una verificación dependiente:
Verificación de dependencias
Que operan como una unidad específica de trabajo
El diseño lógico 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 técnica de análisis nombre-verbo de los escenarios de uso. También se puede emplear la técnica sujeto-verbo-objeto directo. En estas técnicas 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, pseudocódigo, función matemática)
Dependencias
La tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realización 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 regulación de tiempo crítica
Considerar algún problema organizacional (transacciones)
Identificar y auditar los requerimientos de control
Determinar lugares y dependencias a través de la ubicación
Determinar cuando el servicio que controla la transacción es dependiente de los servicios contenidos en otros objetos de negocio
La validación del modelo lógico debe ser tal que éste sea:
Completo – debe representar todos los escenarios de uso,
Correcto – el comportamiento lógico debe corresponder con el comportamiento conceptual, y
Claro – los objetos de negocio y servicios no deben ser ambiguos
En el diseño lógico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicación resulte flexible ante los cambios de requerimientos y/o de tecnología 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 interacción. Un servicio de usuario son personas, aplicaciones, otros servicios o la combinación de éstos. Generalmente involucra una interfase gráfica de usuario (GUI) o pude ser no visual (mensajes o funciones), maneja todos los aspectos de la interacción con la aplicación. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la información. Un servicio de usuario incluye un contenido (qué se necesita comunicar al usuario) y una forma (cómo se comunica el contenido) cuando es necesaria la comunicación.
Los servicios de negocio (bussines services) convierten datos recibidos de los servicios de datos y de usuario en información (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 información
Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transacción.
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 categorías como las siguientes:
Declaración del esquema y su evolución (estructuras de datos, tipos, acceso indexado, SQL, APIs)
Respaldo y recuperación (recuperación de datos si un evento falla)
Búsqueda y Lectura (búsquedas, compilación, optimización y ejecución de solicitudes, formación de un conjunto de resultados)
Inserción, actualización y borrado (procesar modificaciones consistentemente transaccional). Una transacción es atómica (ocurre o no), consistente (preserva integridad), aislada (otras transacciones ocurren antes o después) y durable (una vez completada, ésta sobrevive).
Bloqueo (permite al acceso concurrente a los datos)
Validación 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)
Administración de la conexión (mecanismos básicos para establecer una sesión de los servicios de datos). Establecer una conexión involucra: una identificación, la colocación y provisión de datos, tiempo de sesión, el tipo de interacción (conversacional, transaccional, multiusuario, monousuario).
Distribución de datos (Distribuye información, a múltiples unidades de recuperación, bases de datos heterogéneas, según la topologías de la red).
El diseño físico traduce el diseño lógico en una solución implementable y costo-efectiva o económica.
El componente es la unidad de construcción elemental del diseño físico. Las características de un componente son:
Se define según cómo interactúa con otros
Encapsula sus funciones y sus datos
Es reusable a través de las aplicaciones
Puede verse como una caja negra
Puede contener otros componentes
En el diseño físico se debe cuidar el nivel de granularidad (un componente puede ser tan grande o tan pequeño según su funcionalidad, es decir, del tamaño tal que pueda proveer de una funcionalidad compleja pero de control genérico) y la agregación y contención (un componente puede reusar utilizando técnicas de agregación y contención, sin duplicar código).
El diseño físico debe involucrar:
El diseño para distribución – debe minimizarse la cantidad de datos que pasan como parámetros entre los componentes y éstos deben enviarse de manera segura por la red.
El diseño para multitarea – debe diseñarse en términos de la administración concurrente de dos o más tareas distintas por una computadora y el multithreading o múltiples hilos de un mismo proceso)
El diseño para uso concurrente – el desempeño de un componente remoto depende de si está corriendo mientras recibe una solicitud.
El diseño con el manejo de errores y prueba de eventos:
Validando los parámetros- a la entrada antes de continuar con cualquier proceso.
Protegiendo recursos críticos –manejar excepciones para evitar la falla o terminación sin cerrar archivos, liberar objetos sincronizados o memoria.
Protegiendo datos importantes – contar con una excepción a la mitad de la actuación en las bases de datos.
Debugging – crear una versión para limpiar errores.
Protección integral de transacciones de negocios – los errores deben regresarse al componente que llama.
Figura 3. Arquitectura física de tres capas de la aplicación cliente/servidor
El diseño físico comprende las siguientes tareas:
Definir los componentes
Refinar el empaquetamiento y distribución de componentes
Especificar las interfases de los componentes
Distribuir los componentes en la red
Distribuir los repositorios físicos de datos
Examinar la tolerancia a fallas y la recuperación de errores
Validar el diseño físico
De las tareas anteriores la más importante es la distribución de los datos que pueden ser centralizados, una partición, un extracto o una réplica.
Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos.
Una partición de datos es una segmentación de la base de datos maestra. Es útil cuando los datos se pueden fragmentar fácilmente y actualizarse en un sitio local con cambios frecuentes. No hay sobreposición entre particiones. En una partición horizontal cada hilera existe en una sola base de datos. En una partición vertical cada columna es contenida en una y solo una base de datos.
Un extracto de datos es una copia de toda o una porción de la base de datos maestra. No se permite la actualización. Se usa un timestamp o etiqueta de tiempo para indicar qué tan viejos son los datos.
Una réplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. Una réplica de datos es cuando el sitio de actualización cambia a un sitio local. No se permiten actualizaciones en la base de datos réplica y en la base de datos maestra a la vez, por lo que debe de haber sincronización entre ambas.
El diseño físico está íntimamente ligado a una alternativa tecnológica. Ante la acelerada evolución tecnológica es importante considerar los estándares del momento y las tendencias ya que una mala decisión 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 comunicándose entre sí en una plataforma internet con protocolos estándar en redes heterogéneas.
Comentario final ... para reflexionar
Todo lo que se expresó en este artículo, muestra tal como la teoría aconseja que se deben hacer las cosas. En la práctica, en la ingeniería de software comúnmente se menosprecia el valor de una metodología para crear el software. Esto, a mi juicio, está demeritando la incipiente profesión de Ingeniero de Software en particular, la del especialista en Tecnología de Información, en general y a las empresas de consultoría en software, ya que generalmente se cede al "chantaje" profesional del jefe o del cliente quien ordena la construcción del software, con argumentos como "no hay tiempo para eso, pónte a programar".
Para reflexionar, pregunto, lo siguiente:
¿Qué pasaría, si el ingeniero civil o el arquitecto construye una casa o un edificio sin hacer sus planos, proyectos o maquetas? ¿Crees que la obra pueda concluirse cubriendo las necesidades, con la calidad necesaria y a tiempo? Simplemente observa la calidad de las viviendas "en obra negra perpetua" en la mayoría de las calles de México. Y todavía más allá, ¿Permitirías que tu propio cirujano te interviniera sin hacer los estudios respectivos para obtener las evidencias del problema de salud que te aqueja? O ¿permitirías a tu abogado que te defendiera sin conocer las pruebas y sin un plan para tu defensa? Entonces, ¿por qué los ingenieros en software a veces cedemos al "chantaje de la falta de tiempo" y construimos software sin el análisis y diseño expresado en un proyecto, más allá de las ideas existentes "en nuestra cabeza"? ¿Por qué lo intentamos hacer sobre la marcha, pero nunca lo concluimos pues ya no hay tiempo? ¿Dónde quedó la ética profesional?...
Sugiero que consultes, como referencia, el Código de Etica del Ingeniero en Software y de la Práctica Profesional en el site de la Association for Computing Machinery aquí: http://www.acm.org/serving/ethics.html.
|
Booch G. 1998. Software Architecture and the UML. Presentación disponible en: http://www.rational.com/uml como arch.zip. |
|
|
Booch, G. 1988. Object Oriented Development. Trans. of Soft. Eng. Vol. SE-12. Num. 2. Feb. 1986. pp. 211-221. |
|
|
Conallen, J. "Modeling Web Applications with UML" Conallen, Inc. 9-Mar-1999 Disponible en: http://www.conallen.com/whitepapers/webapps/ModelingWebApplications.htm |
|
|
Conallen, J. "UML Extension for Web Applications 0.91" Drafted Conallen, Inc. 22-Mar-1999 Disponible en: http://www.conallen.com/technologyCorner/webextension/WebExtension091.htm |
|
|
Cota A. 1994 "Ingeniería de Software". Soluciones Avanzadas. Julio de 1994. pp. 5-13. |
|
|
Greiff W. R. Paradigma vs Metodología; El Caso de la POO (Parte II). Soluciones Avanzadas. Ene-Feb 1994. pp. 31-39. |
|
|
Jacobson, I. 1998. "Applying UML in The Unified Process" Presentación. Rational Software. Presentación disponible en http://www.rational.com/uml como UMLconf.zip |
|
|
Jacobson, I. et. al. 1992. Object-Oriented Software Engineering; A Use Case Driven Aproach. ACM Press. Adison-Wesley Publishing. Co. U.S.A. 524 p. Ilus. pp. 465-493. |
|
|
Lewis G. 1994. "What is Software Engineering?" DataPro (4015). Feb 1994. pp. 1-10. |
|
|
Microsoft 1997. Microsoft Solutions Framework 1.0. Microsoft Corporation. USA. |
|
|
Microsoft y Rational 1998. A White Paper on the Benefits of Integrating Microsoft Solutions Framework and The Rational Process. Rational Software Corporation y Microsoft Corporation. Documento msfratprocs.doc Disponible en http://www.rational.com/uml/papers. |
|
|
Object Management Group. 1999. OMG Unified Modeling Language Specification (Draft). Versión 1.3. alfa R5, marzo de 1999. Disponible en: http://www.rational.com/uml |
|
|
Zavala R. 2000. Diseño de un Sistema de Información Geográfica sobre internet. Tesis de Maestría en Ciencias de la Computación. Universidad Autónoma Metropolitana-Azcapotzalco. México, D.F. En prensa. |
Parte 2: Análisis organizacional de empresas de software. Una primera aproximación a una visión alterna de la Ingeniería de Software
Zavala-Ruiz, J. (2008) "Organizational Analysis of Small Software Organizations: Framework and Case Study" en H. Oktaba y M. Piattini (Eds.) Software Process Improvement for Small and Medium Enterprises: Techniques and Case Studies . Abstract
The intention of this chapter is twofold. On the one hand, I illustrate the complexity of the small software organization, because it is not a reduced version of a large company. Rather, it has very important advantages and challenges. Then, I use organization studies as a multi-disciplinary and multi-paradigmatic link between disciplines, able to reconcile those distinct visions. On the other hand, I open the discussion on the state of crisis affecting software engineering as a discipline. For that, I try to sensitize the reader to the facts surrounding this crisis, but also to the most promising alternative, which is the redefinition of software engineering as a discipline. One of the possible options for that paradigmatic shift requires a multi-disciplinary orientation because their positivist roots and the adoption of a constructivist ontology and epistemology facilitating the inclusion of visions non-qualified for a systematic, disciplined and quantitative approach. My position is that only by opening up this discussion is it possible to begin transforming and consolidating software engineering as a strengthened and more terrain-attached discipline because of its powerful theoretical and practical explanatory capacity.
Disponible como "Free Sample Chapter" en la Editorial IGI-Global o aquí
Parte 3. ¿Qué es la ingeniería de software?: Una visión alterna
La Ingeniería de Software: Su filosofía y su desafío
En mis investigaciones, de campo y bibliográficas, llevadas a cabo desde 2005 a la fecha, me han llevado a concluir que la Ingeniería 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 ingeniería, ésta dista mucho de ser tal.
La ingeniería de software, no es una disciplina de ingeniería sino más bien una disciplina técnica y de administración (o management) impulsada desde sus orígenes por el Departamento de Defensa de los Estados Unidos (DoD), como lo demuestra la investigación histórica.
La esencia del objeto de estudio de la Ingeniería de Software como disciplina teórico-práctica, es decir, su ontología es de naturaleza más organizacional que ingenieril, aunque tiene un componente tecnológico muy importante.
Descarga la presentación de la ponencia "La Ingeniería de Software: Su filosofía y su desafío" presentada por mí y por la M.C.C. Rafaela Blanca Silva López de la Universidad Autónoma Metropolitana - Unidad Azcapotzalco, en el XXIV Congreso de la ANIEI en Colima, Colima, México, el 26 de octubre de 2011.
La Ingeniería de Software: Una Discusión Epistemológica
Tesis de maestría en ciencias de la computación, Universidad Autónoma Metropolitana, Unidad Azcapotzalco, México. 2011.
Descarga las primeras páginas aquí:aquí
Resumen
La Ingeniería de Software se encuentra en una crisis disciplinaria por la falta de fundamentos bien establecidos. El impulso de la iniciativa Software Engineering Method And Theory (SEMAT) ignorando la Guide to Software Engineering Body of Knowledge (SWEBoK) confirma esa situación que se prolonga ya por más de 40 años. Partiendo de una propuesta epistemológica interdisciplinaria, esta investigación propuso la creación de la Ciencia del Software.
Despues de una profunda revisón histórica y del contexto, se propuso un marco conceptual de cuatro niveles ontológicos complementarios. El primer nivel aborda el “software” como lenguaje de programación, algoritmo, cálculo y como sistema de software acotado por el hardware; es la dimesión técnica. El segundo nivel ontológico abordó el “proceso de producción” o “desarrollo de software” como un proceso de organización del trabajo, un tema central en la teoría de la organización. El tercer nivel se centró en el “proyecto de software” como proceso social y organización temporal, dominio de la teoría de la administración de proyectos. Y el cuarto nivel abordó la “fábrica de software” como una empresa de naturaleza organizacionl y empresarial.
Se propusieron dos modelos en complemento, el primero originado en la psicología social para delinear una estrategia de cambio paradigmático y el segundo, un modelo filosófico originado en la administración, para integrar todos los elementos en una propuesta integral. Así, las “mejores prácticas” estarán basadas en fundamentos ontológicos y epistemológicos sólidos y en un comportamiento ético, que lleve al establecimeinto de la filosofía de la ciencia del software.
Palabras clave: ciencias de la computación, ingeniería de software, ciencia del software, filosofía de la ciencia, crisis desciplinaria, filosofía del software, cambio paradigmático.
Descarga las primeras páginas del capítulo 3 aquí.
Software Engineering: An Interdisciplinary Epistemological Discussion
(in Spanish)
Master's dissertation in Computer Science, Universidad Autónoma Metropolitana, Unidad Azcapotzalco, México.
Download first pages:here.
Abstract
Software Engineering, as discipline, is on a profound crisis because it has not a clear-cut definition on its fundamentals for a better theory and practice fitting. The Software Engineering Method And Theory (SEMAT) Initiative that overrides the Guide to Software Engineering Body of Knowledge (SWEBoK), confirms this status which extends over more than 40 years.
First, after a deep historical review and context discussion, using an interdisciplinary epistemological framework, founded on a basic element set, this research proposed to create the Science of Software. For that, an ontological four-level framework is propossed. The first ontological level, is organized nearby software as programming language, algorithm, calculus (computation) in a broad sense, and software system but constrained by hardware. The second level focuses on “software development” as a work organization process, a core subject in organization theory. The third level is “software project” as a social process and a temporary organization, a core domain in project management theory. And, fourth level addesses the “software factory” as a wide organizational and entrepreneurial enterprise, more magerial and administrative in nature. But, only the first one level is a computer domain in essence and the best choice for the core or essence on the proposed Science of Software.
As an alternative, if the Science of Software pretends to be all-inclusive, then it requires be a multidisciplinary umbrella and approach. Next, two model-set has suggested, first to define the strategy for the paradigmatic change, and second, to integrate all these items in a well-defined and complimentary framework. Therefore, ‘best practices’ are best fitted with knowledge, ethical behaviorbut, and rooted on its ontology.
Keywords: computer science, software engineering, science of software, philosophy of science, philosophy of software, paradigm shift.
Download first pages of this chapter here.
(Finalmente, un contador, después de muchos años, a partir del 7 de noviembre de 2008.!!!! ;) que se colapsó en 2010 después de alcanzar más de 220,000 hits). Este contador, se reinició en noviembre de 2010 y esperamos lograr, por lo menos, otras 100 mil visitas por año...
Copyright. 2000-2011. Todos los derechos reservados.
Se prohibe la copia y distribución de este material para fines de lucro. Se autoriza la copia para fines personales siempre y cuando se cite la fuente íntegramente.
http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware.html
Tags: ingeniería de, computación, ingeniería, ingeniería, software?
- (1 PANO IN 2 PANO) JUDOVSKI VOJAKI AVSTROOGRSKE VOJSKE
- IS THE ACADEMY READY FOR LEARNING OBJECTS? STEPHEN R
- SPECIAL CIRCUMSTANCES INFRINGEMENT REVIEW A MODEL OPERATING POLICY FOR
- TABLA 1 DATOS CLIMÁTICOS CORRESPONDIENTES A LA ESTACIÓN DE
- [EXASOL2763] VALIDATION OF COMMANDLINE PARAMETERS ON DATABASE STARTUP CREATED
- SE PODRÁ OBTENER EL CARNÉ DE CONDUCIR PAGÁNDOLO
- P OWIATOWY URZĄD PRACY W ŚWIDNICY UL MC SKŁODOWSKIEJ
- MASTER LICENSE AGREEMENT 1 INTRODUCTION THIS MASTER LICENSE AGREEMENT
- MUTUAL EXCHANGE PERMISSION APPLICATION 1 YOUR DETAILS TENANT’S NAME
- NA TEMELJU ČLANKA 110 I 111 ZAKONA O VATROGASTVU
- HOME LANGUAGE SURVEYRACIALETHNIC CATEGORY ENGLISH SITE THE CALIFORNIA EDUCATION
- APPENDIX 1 – GLOSSARY OF TERMINOLOGY ALTERED FOREST
- EWING HIGH SCHOOL CONCERT CHOIR PROCEDURES AND EXPECTATIONS WELCOME
- Domnule Director Executiv Subsemnatula Medic Rezident (locpost) Unitatea
- LA CENSURA AL MINISTRO ROSPIGLIOSI SALTANDO AL VACÍO EL
- LISTEN A MINUTECOM ROAD RAGE HTTPWWWLISTENAMINUTECOMRROADRAGEHTML ONE MINUTE A
- Universidad Nacional de Ingeniería Recinto Universitario Augusto c Sandino
- the Substance use and Addictions Workforce and Organizational
- LA IGUALDAD DE TRATO EN EL EMPLEO GUÍA PRÁCTICA
- MPM SIMULATIONS OF DAMBREAK FLOODS XUANYU ZHAO1 2 DONGFANG
- EXAMPLES OF FINAL EXAMS EXAMPLE 1 THIS EXAM IS
- KULTURDEPARTEMENTET BEGJÆRING OM GRAVLEGGING OGELLER KREMASJON GRAVFERDSMELDING TIL GRAVPLASSMYNDIGHETEN
- ROOTS OF INEQUALITY QUESTIONS TO ACCOMPANY THE NATIONAL GEOGRAPHIC
- GUÍA Y MENSAJES PARA CATEQUISTAS INDICE DE MATERIAS EN
- ITS NOT HOW SMART YOU ARE ITS HOW
- PODER LEGISLATIVO DE SANTA CRUZ DO SUL CÂMARA MUNICIPAL
- ESTADO PLURINACIONAL DE BOLIVIA EMPRESA NACIONAL DE ELECTRICIDAD
- EU VET PROGRAMME II BOSNIA AND HERZEGOVINA FAMILIJA ŠUMARSTVO
- ELLÆRE SONJA PRÜHS ELEKTRICITET SKYLDES FORSKELLEN MELLEM LADNINGER
- PROCEDIMIENTO ACELERADO PARA EL ESTABLECIMIENTO DE NORMAS (ADOPTADO POR
ELLIPSIS IN CONVERSATION 1 DIALOGUE ABOUT A JOURNEY WITHOUT
ORDEN FORAL 472015 DE 13 DE OCTUBRE (MODELO 591)
UKŁAD POKARMOWY I TRAWIENIE ABY ORGANIZM CZŁOWIEKA PRAWIDŁOWO FUNKCJONAWAŁ
RÜCKWARENANMELDUNG 1 BEVOR SIE WAREN AN UNS ZURÜCKSENDENKEDVES ‘TEJIVÓK ÉS KŐFEJTŐK’! HA KENYÉRRE ÉHEZTETEK IS
REGIONÁLNÍ ODBORNÁ PRACOVIŠTĚ PRO PÉČI O TRADIČNÍ LIDOVOU KULTURU
LA PROTECCIÓN DE LOS CONOCIMIENTOS TRADICIONALES EN LOS FOROS
ROLE THERAPEUTIC CHILD CARER ACCOUNTABLE TO REGISTERED MANAGER ORPROJET D’ARRETE DE MISE EN DETACHEMENT POUR EFFECTUER UN
F22A TC GAZİANTEP ÜNİVERSİTESİ FEN BİLİMLERİ ENSTİTÜSÜ JEŠTĚ JEDNOU POVODNĚ – VÝKONNÁ RADA ROZHODLA O PŘIDĚLENÍ
CHAPTER 2 THE BASICS OF SUPPLY AND DEMAND CHAPTER
CHAPTER 13—UNIVERSAL GRAVITATION MULTIPLE CHOICE 1 A SATELLITE CIRCLES
MINISTERSTWO SPRAWIEDLIWOŚCI KRAJOWY REJESTR KARNY NAZWA I ADRES PODMIOTU
35000367 CEIP LA GOLETA FICHA DE DATOS FAMILIARES ESCRIBIR
№ НАИМЕНОВАНИЕ МЕСТО ОБИТАНИЯ ФОТО РАМКА (СМ) ЦЕНА 1LIBRERÍA PRAGA WWWLIBRERIAPRAGACOM 958 520 101 CATÁLOGO DE
SOLICITUD DE AMPLIACIÓN DE ESTANCIA APPLICATION FOR EXTENSION OFTERMS OF REFERENCE (DOCUMENT NO APTPP1002) CORRESPONDENCE GROUP 1
RUSIA Y POLONIA REF E 4147 11 DÍAS
