Avisar de contenido inadecuado

ingenieria de software

{
}

ingenieria de software

Ingeniería de software


Ingeniería de software es la disciplina o área de la informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad.


Esta ingeniería trata con áreas muy diversas de la informática y de las ciencias de la computación, tales como construcción de compiladores, sistemas operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a infinidad de áreas (negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, derecho, Internet, Intranet, etc.

Una definición precisa aún no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los más prestigiosos autores:

    * Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
    * Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software ( Bohem, 1976).
    * Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).
    * Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).

En el 2004, en los Estados Unidos, la Oficina de Estadísticas del Trabajo (U. S. Bureau of Labor Statistics) contó 760.840 ingenieros de software de computadora.[1] El término "ingeniero de software", sin embargo, se utiliza en forma genérica en el ambiente empresarial, y no todos los ingenieros de software poseen realmente títulos de Ingeniería de universidades reconocidas.

Algunos autores consideran que Desarrollo de Software es un término más apropiado que Ingeniería de Software (IS) para el proceso de crear software. Personas como Pete McBreen (autor de "Software Craftmanship") cree que el término IS implica niveles de rigor y prueba de procesos que no son apropiados para todo tipo de desarrollo de software.

Indistintamente se utilizan los términos Ingeniería de Software o Ingeniería del Software. En hispanoamérica el término usado normalmente es el primero de ellos.

 Modelos de desarrollo de software [editar]

La ingeniería de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos:

    * Modelo en cascada o Clásico (modelo tradicional)
    * Modelo en espiral (modelo evolutivo)
    * Modelo de prototipos
    * Desarrollo por etapas
    * Desarrollo iterativo y creciente o Iterativo e Incremental
    * RAD (Rapid Application Development)

Naturaleza de la IS [editar]

La Ingeniería de Software tiene que ver con varios campos en diferentes formas:
Matemáticas [editar]

Los programas tienen muchas propiedades matemáticas. Por ejemplo la corrección y la complejidad de muchos algoritmos son conceptos matemáticos que pueden ser rigurosamente probados. El uso de matemáticas en la IS es llamado métodos formales.
Creación [editar]

Los programas son construidos en una secuencia de pasos. El hecho de definir propiamente y llevar a cabo estos pasos, como en una línea de ensamblaje, es necesario para mejorar la productividad de los desarrolladores y la calidad final de los programas. Este punto de vista inspira los diferentes procesos y metodologías que encontramos en la IS.
Gestión de Proyectos [editar]

El software comercial (y mucho no comercial) requiere gestión de proyectos. Hay presupuestos y establecimiento de tiempos. Gente para liderar. Recursos (espacio de oficina, computadoras) por adquirir. Todo esto encaja apropiadamente con la visión de la Gestión de Proyectos.
Arte [editar]

Los programas contienen muchos elementos artísticos. Las interfaces de usuario, la codificación, etc. Incluso la decisión para un nombre de una variable o una clase. Donald Knuth es famoso porque ha argumentado que la programación es un arte.
Responsabilidad [editar]

La responsabilidad en la Ingeniería del Software es un concepto complejo, sobre todo porque al estar los sistemas informáticos fuertemente caracterizados por su complejidad, es difícil apreciar sus consecuencias.

En la Ingeniería del Software la responsabilidad será compartida por un grupo grande de personas, que comprende desde el ingeniero de requisitos, hasta el arquitecto software, y contando con el diseñador, o el encargado de realizar las pruebas. Por encima de todos ellos destaca el director del proyecto. El software demanda una clara distribución de la responsabilidad entre los diferentes roles que se dan en el proceso de producción.

El ingeniero del Software tiene una responsabilidad moral y legal limitada a las consecuencias directas.
Educación ética [editar]
Organizaciones [editar]

    * Software Engineering Institute (SEI)
    * Association for Computing Machinery (ACM)
    * British Computer Society (BCS)
    * IEEE Computer Society
    * RUSSOFT Association
    * Society of Software Engineers

Bibliografía [editar]

    * Ingeniería de Software (sexta edición), Ian Sommerville. Addison Wesley. Sitio en Inglés
    * Ingeniería del software. Un enfoque práctico (sexta edición), R. S. Pressman. McGraw Hill Higher Education. Sitio en Inglés

Referencias [editar]

   1. ↑ Bureau of Labor Statistics, U.S. Department of Labor, USDL 05-2145: Occupational Employment and Wages, November 2004, Table 1.

La Ingeniería de Software

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

 Diseño Conceptual

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.

 

Diseño Lógico

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:
          o Pre y post condiciones
          o Lógica y funcionalidad individual
    * Una verificación dependiente:
          o Verificación de dependencias
          o 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).

 

Diseño físico

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:
          o Validando los parámetros- a la entrada antes de continuar con cualquier proceso.
          o Protegiendo recursos críticos –manejar excepciones para evitar la falla o terminación sin cerrar archivos, liberar objetos sincronizados o memoria.
          o Protegiendo datos importantes – contar con una excepción a la mitad de la actuación en las bases de datos.
          o Debugging – crear una versión para limpiar errores.
          o 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.

Envíame tus comentarios por e-mail.

Literatura citada
[Booch 1998]     Booch G. 1998. Software Architecture and the UML. Presentación disponible en: http://www.rational.com/uml como arch.zip.
[Booch 1986]     Booch, G. 1988. Object Oriented Development. Trans. of Soft. Eng. Vol. SE-12. Num. 2. Feb. 1986. pp. 211-221.
[Conallen 1999A]     Conallen, J. "Modeling Web Applications with UML" Conallen, Inc. 9-Mar-1999 Disponible en: http://www.conallen.com/whitepapers/webapps/ModelingWebApplications.htm
[Conallen 1999B]     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 1994]     Cota A. 1994 "Ingeniería de Software". Soluciones Avanzadas. Julio de 1994. pp. 5-13.
[Greiff 1994]     Greiff W. R. Paradigma vs Metodología; El Caso de la POO (Parte II). Soluciones Avanzadas. Ene-Feb 1994. pp. 31-39.
[Jacobson 1998]     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 1992]     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 1994]     Lewis G. 1994. "What is Software Engineering?" DataPro (4015). Feb 1994. pp. 1-10.
[Microsoft 1997]     Microsoft 1997. Microsoft Solutions Framework 1.0. Microsoft Corporation. USA.
[M&R 1998]     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.
[OMG 1999]     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 2000]     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.

Última publicación

He aquí una referencia actualizada a mi última publicación:

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 readerto 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 change 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 en http://www.igi-global.com/downloads/excerpts/OktabaExc.pdf

Envíame tus comentarios por e-mail.


Ingeniería de software

El término ingeniería de software abarca al grupo de métodos, técnicas y herramientas que se utilizan en la producción del software, más allá de la actividad principal de programación.

El término "ingeniería" es una referencia directa a la ingeniería civil, una referencia al estudio de la construcción. En programación se aplica el mismo principio que en la construcción de un edificio: poner simplemente ladrillos y cemento no es suficiente. La construcción de un edificio consta de diversos pasos antes de comenzar con la fase de construcción, tales como el diseño arquitectónico, la albañilería, la fontanería, el diseño eléctrico, y durante este período se calculan los presupuestos y los plazos.

Por lo tanto, la ingeniería de software requiere la gestión de proyectos para que se pueda desarrollar una aplicación en el plazo previsto y con el presupuesto establecido que sea satisfactoria para el cliente (el concepto de calidad).



1. Introducción

Este término fue introducido a finales de los 60 a raíz de la crisis del software.

Esta crisis fue el resultado de la introducción de la tercera generación del hardware.

El hardware dejo de ser un impedimento para el desarrollo de la informática; redujo los costos y mejoro la calidad y eficiencia en el software producido

La crisis se caracterizo por los siguientes problemas:

    * Imprecisión en la planificación del proyecto y estimación de los costos.
    * Baja calidad del software.
    * Dificultad de mantenimiento de programas con un diseño poco estructurado, etc.

Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en la compra.

Tambien se requiere una serie de características como fiabilidad, facilidad de mantenimiento y de uso, eficiencia, etc.

2. Objetivos de la ingeniería de software

En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la ingeniería de software.

    * mejorar la calidad de los productos de software
    * aumentar la productividad y trabajo de los ingenieros del software.
    * Facilitar el control del proceso de desarrollo de software.
    * Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.
    * Definir una disciplina que garantice la producción y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.

Objetivos de los proyectos de sistemas

Para que los objetivos se cumplan las empresas emprenden proyectos por las siguientes razones: "Las cinco C "

Capacidad

Las actividades de la organización están influenciadas por la capacidad de ésta para procesar transacciones con rapidez y eficiencia.

Los sistemas de información mejoran esta capacidad en tres formas.

* Aumentan la velocidad de procesamiento:

Los sistemas basados en computadora pueden ser de ayuda para eliminar la necesidad de cálculos tediosos y comparaciones repetitivas.

Un sistema automatizado puede ser de gran utilidad si lo que se necesita es un procesamiento acelerado.

*Aumento en el volumen:

La incapacidad para mantener el ritmo de procesamiento no significa el abandono de los procedimientos existentes. Quizá éstos resulten inadecuados para satisfacer las demandas actuales. En estas situaciones el analista de sistemas considera el impacto que tiene la introducción de procesamiento computarizado, si el sistema existente es manual. Es poco probable que únicamente el aumento de la velocidad sea la respuesta. El tiempo de procesamiento por transacción aumenta si se considera la cantidad de actividades comerciales de la empresa junto con su patrón de crecimiento.

* Recuperación más rápida de la información:

Las organizaciones almacenan grandes cantidades de datos, por eso, debe tenerse en cuenta donde almacenarlos y como recuperarlos cuando se los necesita.

Cuando un sistema se desarrolla en forma apropiada, se puede recuperar en forma rápida la información.

Costo

* Vigilancia de los costos:

Para determinar si la compañía evoluciona en la forma esperada, de acuerdo con lo presupuestado, se debe llevar a cabo el seguimiento de los costos de mano de obra, bienes y gastos generales.

La creciente competitividad del mercado crea la necesidad de mejores métodos para seguir los costos y relacionarlos con la productividad individual y organizacional.

* Reducción de costos:

Los diseños de sistemas ayudan a disminuir los costos, ya que toman ventaja de las capacidades de cálculo automático y de recuperación de datos que están incluidos en procedimientos de programas en computadora. Muchas tareas son realizadas por programas de cómputo, lo cual deja un número muy reducido de éstas para su ejecución manual, disminuyendo al personal.

Control

*Mayor seguridad de información:

Algunas veces el hecho de que los datos puedan ser guardados en una forma adecuada para su lectura por medio de una máquina, es una seguridad difícil de alcanzar en un medio ambiente donde no existen computadoras.

Para aumentar la seguridad, generalmente se desarrollan sistemas de información automatizados. El acceso a la información puede estar controlado por un complejo sistemas de contraseñas, limitado a ciertas áreas o personal, si está bien protegido, es difícil de acceder.

*Menor margen de error: (mejora de la exactitud y la consistencia)

Esto se puede lograr por medio del uso de procedimientos de control por lotes, tratando de que siempre se siga el mismo procedimiento. Cada paso se lleva a cabo de la misma manera, consistencia y con exactitud: por otra parte se efectúan todos los pasos para cada lote de transacciones. A diferencia del ser humano, el sistema no se distrae con llamadas telefónicas, ni olvidos e interrupciones que sufre el ser humano. Si no se omiten etapas, es probable que no se produzcan errores.

Comunicación

La falta de comunicación es una fuente común de dificultades que afectan tanto a cliente como a empleados. Sin embargo, los sistemas de información bien desarrollados amplían la comunicación y facilitan la integración de funciones individuales.

* Interconexión: ( aumento en la comunicación)

Muchas empresas aumentan sus vías de comunicación por medio del desarrollo de redes para este fin, dichas vías abarcan todo el país y les permiten acelerar el flujo de información dentro de sus oficinas y otras instalaciones que no se encuentran en la misma localidad.

Una de las características más importantes de los sistemas de información para oficinas es la transmisión electrónica de información, como por ejemplo, los mensajes y los documentos.

* Integración de áreas en las empresas:

Con frecuencia las actividades de las empresas abarcan varias áreas de la organización, la información que surge en un área se necesita en otra área, por ejemplo.

Los sistemas de información ayudan a comunicar los detalles del diseño a los diferentes grupos, mantienen las especificaciones esenciales en un sitio de fácil acceso y calculan factores tales como el estrés y el nivel de costos a partir de detalles proporcionados por otros grupos.

{
}
{
}

Deja tu comentario ingenieria de software

Identifícate en OboLog, o crea tu blog gratis si aún no estás registrado.

Avatar de usuario Tu nombre