Introduccion

La calidad del software es una de las problematicas mas importantes en los procesos de desarrollo de software. Garantizar el correcto funcionamiento bajo situaciones no determinadas es una tarea que tiene que ser realizada con cuidado extremo. En algunos casos, este tipo de pruebas son de mayor importancia, ya que involucran ambientes sensibles e informacion critica en donde es necesario garantizar que cada uno de los componentes involucrados (hardware, software y componentes humanos) actue de manera correcta ante situaciones especificas, con una variedad de ejemplos que cubren areas tan diversas como planeacion de trafico, aplicaciones militares y sistemas medicos, entre muchas otras.

Los modelos formales presentan una alternativa practica para solucionar estos problemas. Constituyen un enfoque analitico para la especificacion, diseño y verificacion de sistemas de hardware y software. Su caracteristica principal es la rigurosidad en la que sus modelos se encuentran basados, con fundamentos en solidos principios matematicos que permiten definir con precision y sin temor a ambiguedades las necesidades de un sistema. Gracias a estos fundamentos, el software generado mediante metodos formales puede ser verificado mediante el cumplimiento de propiedades derivadas de la especificacion. Este enfoque ha resultado ser exitoso frente a otras tendencias, encontrando errores en diseño que dificilmente habrian podido ser considerados usando otras tecnicas.

Definiciones: Metodos Formales

Una de las metas de la Ingenieria del Software es lograr que los desarrolladores construyan sistemas confiables independientemente de su complejidad. Una forma de alcanzar esta meta es a través del uso de Métodos Formales (MF): técnicas, lenguajes y herramientas definidos matemáticamente, para especificar y verificar tales sistemas. El uso de MF propicia la confiabilidad y la seguridad de un sistema, al aumentar la comprensión acerca de un sistema revelando inconsistencias, ambigüedades e incompletitudes, que de otra manera pasan desapercibidas. [L. Mendoza, M. Pérez y M. Capel]

Los métodos formales que se utilizan para desarrollar sistemas de computadoras son técnicas de base matemática para describir las propiedades del sistema. Estos métodos formales proporcionan marcos de referencia en el seno de los cuales las personas pueden especificar, desarrollar y verificar los sistemas de manera sistemática, en lugar de hacerlo ad hoc. [John J. Marciniak]

Los metodos formales representan un conjunto de tendencias de desarrollo de software y hardware en donde la especificacion, verificacion y diseño de componentes se realiza mediante notaciones, lenguajes, herramientas y tecnicas basadas en teorias con solida fundamentacion matematica. El uso de notaciones y lenguajes formales permite plantear de manera clara los requerimientos de un sistema, generando especificaciones que definen el comportamiento en terminos del “que debe hacer” y no del “como lo hace”. [Hugo A. Lopez A.]

Los metodos formales permiten al ingeniero del software crear una especificación sin ambigüedades que sea más completa y constante que las que se utilizan en los métodos convencionales u orientados a objetos. La teoría de conjuntos y las notaciones lógicas se utilizan para crear una sentencia clara de hechos (o de requisitos). Esta especificación matemática entonces se puede analizar para comprobar que sea correcta y constante. Como esta especificación se crea utilizando notaciones matemáticas inherentemente es menos ambigua que los nodos informales de presentación. [Roger Pressman]

En Ingenieria del Software un método formal es un camino a la construcción y análisis de modelos matemáticos que permitan una automatización del desarrollo de sistemas informáticos. Los métodos formales se caracterizan por emplear técnicas y herramientas matemáticas para lograr una facilitación a la hora de encarar la construcción o el análisis de un modelo matemático de un sistema. [Wikipedia]

Los diez mandamientos de los metodos formales

La decisión de hacer uso de los métodos formales en el mundo real no debe de adoptarse a la ligera. Bowen y Hinchley  han acuñado los diez mandamientos de los métodos formales, como guía para aquellos que estén a punto de embarcarse en este importante enfoque de la Ingenieria del Software.

1. Seleccionarás la notación adecuada. Con objeto de seleccionar eficientemente dentro de la amplia gama de lenguajes de especificación formal existente, el ingeniero del software deberá considerar el vocabulario del lenguaje, el tipo de aplicación que haya que especificar y el grado de utilización del lenguaje.
2. Formalizarás, pero no de más. En general, resulta necesario aplicar los métodos formales a todos los aspectos de los sistemas de cierta envergadura. Aquellos componentes que sean críticos para la seguridad serán nuestras primeras opciones, e irán seguidos por aquellos componentes cuyo fallo no se pueda admitir (por razones de negocios).
3. Estimarás los costes. Los métodos formales tienen unos costes de arranque considerables. El entrenamiento del personal, la adquisición de herramientas de apoyo y la utilización de asesores bajo contrato dan lugar a unos costes elevados en la primera ocasión. Estos costes deben tenerse en cuenta cuando se esté considerando el beneficio obtenido frente a esa inversión asociada a los métodos formales.
4. Poseerás un experto en métodos formales a tu disposición. El entrenamiento de expertos y la asesoría continua son esenciales para el éxito cuando se utilizan los métodos formales por primera vez.
5. No abandonarás tus métodos formales de desarrollo. Es posible, y en muchos casos resulta deseable, integrar los métodos formales con los métodos convencionales y/o con métodos orientados a objetos. Cada uno de estos métodos posee sus ventajas y sus inconvenientes. Una combinación de ambos, aplicada de forma adecuada, puede producir excelentes resultados.
6. Documentarás suficientemente. Los métodos formales proporcionan un método conciso, sin ambigüedades y consistente para documentar los requisitos del sistema. Sin embargo, se recomienda que se adjunte un comentario en lenguaje natural a la especificación formal, para que sirva como mecanismo para reforzar la comprensión del sistema por parte de los lectores.
7. No comprometerás los estándares de calidad. Los métodos formales no tienen nada de mágico, y por esta razón, las demás actividades de SQA deben de seguir aplicándose cuando se desarrollen sistemas.
8. No serás dogmático. El ingeniero de software debe reconocer que los métodos formales no son una garantía de corrección. Es posible (o como algunos probablemente dirían) que el sistema final, aun cuando se haya desarrollado empleando métodos formales, siga conteniendo pequeñas omisiones, errores de menor importancia y otros atributos que no satisfagan nuestras expectativas.
9. Comprobarás, comprobarás y volverás a comprobar. Los métodos formales no absuelven al ingeniero del software de la necesidad de llevar a cabo unas comprobaciones exhaustivas y bien planeadas.
10. Reutilizarás cuanto puedas. A la larga, la única forma racional de reducir los costes del software y de incrementar la calidad del software pasa por la reutilización. Los métodos formales no modifican esta realidad. De hecho, quizás suceda que los métodos formales sean un enfoque adecuado cuando es preciso crear componentes para bibliotecas reutilizables.

Los siete mitos sobre los metodos formales

Los siete mitos mas generalizados sobre los metodos formales son variaciones de los siguientes:

1. Los metodos formales garantizan que el software esta perfecto. El mito mas importante es que los metodos formales serian todopoderosos, si nosotros humildes mortales pudiesemos aplicarlos. Este mito es pernicioso porque nos lleva a expectativas irreales y a la idea de que los metodos formales son de alguna forma todo o nada.
2. Los metodos formales se centran en demostrar correccion. En los Estados Unidos, gran parte del trabajo desarrollado en metodos formales se ha concentrado en la verificacion de programas. Esto ha hecho que los metodos formales parezcan muy dificiles y no muy relevantes para la vida real.
3. Los metodos formales son utiles solo para sistemas criticos. Esta creencia se basa en la percepcion de la dificultad que implica la aplicacion de metodos formales. La verdad es que los sistemas criticos requieren un uso mas acucioso de metodos formales, pero cualquier sistema puede beneficiarse con el uso de algunas tecnicas de especificacion formal.
4. Los metodos formales requieren matematicos entrenados. Los metodos formales se basan en notaciones matematicas, y muchas personas creen que esto los hace dificiles para la practica de los ingenieros de software. Este mito, a su vez, se basa en la percepcion de que las matematicas son intrinsicamente dificiles.
5. Los metodos formales aumentan el costo del desarrollo. Se acostumbraba decir que a pesar que el costo que significaba usar metodos formales era muy alto, de todas formas era conveniente porque resultaba en menores costos de mantenimiento del software.
6. Los metodos formales son incomprensibles para los usuarios. Una especificacion formal esta llena de simbolos matematicos que resultan incomprensibles para cualquiera que no este familiarizado con la notacion. De ahi que se suponga que son inutiles para clientes no matematicos.
7. Los metodos formales no se usan en grandes proyectos reales. Los metodos formales se asocian comunmente con departamentos academicos y organizaciones de investigacion. Se piensa que solo estas organizaciones tienen la capacidad necesaria para usar metodos formales y que estos solo son apropiados para las aplicaciones idealizadas que estos grupos desarrollan.

Principales Metodos Formales utilizados en el desarrollo de software

• Metodos formales basados en Lógica de Primer Orden: Z, B, VDM, Object-Z, Z++ y VDM++.
• Metodos formales basados en Formalismos Algebraicos: HOSA (Hidden Order Sorted Algebras), TROLL, OBLOG, Maude y AS-IS (Algebraic Specifications with Implicit States).
• Metodos formales basados en Redes de Petri: CO-OPN (Concurrent Object-Oriented Petri Nets)
• Metodos formales basados en Lógica Temporal: TRIO, OO-LTL y ATOM.
• Metodos Semiformales: Syntropy, Statemate, UML y OCL (Object Constraint Language)

Referencias:

• Roger Pressman. Ingenieria del Software: Un Enfoque Practico. McGraw-Hill. 2006
• Ian Sommerville. Ingenieria de Software. Pearson. 2005

Introduccion

El origen del interes actual por la calidad se puede explicar recurriendo al estudio de la evolucion en la comercializacion de los productos. En el mercado actual tan competitivo no basta con producir y distribuir masivamente los productos o servicios, vender es lo importante y solo se produce con la seguridad de la aceptacion por parte del cliente.

Sin embargo la calidad del software es un concepto complejo que no es directamente comparable con la calidad de la manufactura de producto. Los productos de software se han convertido hoy en dia en uno de los principales objetivos estrategicos de las organizaciones debido a que, cada vez mas, los procesos mas importantes de las organizaciones y por lo tanto su supervivencia dependen del buen funcionamiento de los sistemas de software.

Definiciones: Calidad

Podemos encontrar muchas definiciones en los textos de calidad, todas ellas muy similares:

• Propiedad o conjunto de propiedades inherentes a un objeto que permiten apreciarlo como mejor, igual o peor que otros objetos de su especie [DRAE: Diccionario de la Real Academica Española]
• Conjunto de propiedades y de caracteristicas de un producto o servicio que le confieren capacidad para satisfacer necesidades expresadas o implicitas. [ISO 8042:1994]
• Grado en el que un conjunto de caracteristicas inherentes cumple con los requisitos. [ISO 9000: 2000]

Las definiciones mas completas o formales:

• Calidad, significa desarrollar, diseñar y producir y mantener un producto que sea el mas economico, el mas util y siempre satisfactorio para el consumidor. [Kaoru Ishikawa]
• Calidad, es la aplicacion de los principios y tecnicas estadisticas en todas las fases de la produccion, dirigida a la fabricacion mas economica de un producto (servicio) que es util en grado maximo y que tiene mercado. [William Edwards Deming]

Definiciones: Calidad del Software

• La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario. [IEEE, Std 610-1900]
• Concordancia del software producido con los requerimientos explicitamente establecidos, con los estandares de desarrollo prefijados y con los requerimientos implicitos no establecidos formalmente, que desea el usuario. [Pressman, 1998]

Terminologia: Calidad del Software

Para poder afrontar el estudio de calidad del software debemos conocer primeros los principales terminos empleados en esta area:

• Gestion de la Calidad de Software (Software Quality Management): Conjunto de actividades de la función general de la dirección que determina la calidad, los objetivos y las responsabilidades. Se basa en la determinación y aplicación de las políticas de calidad de la empresa. La gestión o administración de la calidad se aplica normalmente a nivel empresa o dentro de la gestión de cada proyecto. El propósito de la gestión de la calidad del software es entender las expectativas del cliente en términos de calidad, y poner en práctica un plan proactivo para satisfacer esas expectativas.
• Aseguramiento de la Calidad Software (Software Quality Assurance): Conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) satisfará los requisitos dados de calidad.
• Control de la Calidad de Software (Software Quality Control): Conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los requisitos relativos a la calidad, centradas en mantener bajo control el proceso de desarrollo y eliminar las causas de los defectos en las diferentes fases del ciclo de vida.
• Verificacion y Validacion de Software (Software Verification and Validation): Conjunto de técnicas y actividades ligadas al control de calidad del software se trata de comprobar si los productos construidos en una fase de ciclo de vida satisfacen los requisitos establecidos en una fase anterior y/o si el software construido satisface los requisitos del usuario, es decir si el producto de software funciona como el usuario quiere y realiza las funciones que se habian solicitado.

Modelos: Calidad del Software

• CMM (Capability Maturity Model): El CMM  tiene como objetivo evaluar los procesos en sus distintos niveles de madurez, identificar los niveles a través de los cuales una organización debe formarse para establecer una cultura de excelencia en la ingeniería de software. El modelo de madurez de procesos fue generado a través de la experiencia colectiva de los proyectos más exitosos de software, generando así un conjunto de prácticas importantes que deben ser implantadas por cualquier entidad que desarrolla o mantiene software.
• ISO (International Standard Organization): La norma ISO/IEC 9003 proporciona una guia necesaria en las organizaciones para la aplicacion de la ISO 9001 a la adquisicion de sumistro, desarrollo, operacion y mantenimiento de software y sus servicios relacionados. Identifica todos los aspectos que deberian ser tratados y es independiente de la tecnologia, modelos de ciclos de vida, procesos de desarrollo y estructuras organizacionales. La norma ISO 9001, especifica los requisitos para un sistema de gestion de la calidad cuando una organizacion necesita demostrar su capacidad de proporcionar de forma coherente productos que satisfagan los requisitos del cliente y aspira a aumentar su sastisfaccion a traves de la aplicacion eficaz del sistema, incluyendo los procesos para la mejora continua del sistema y el aseguramiento de la conformidad con los requisitos y de acuerdo a las reglamentaciones existentes.
• PSP (Personal Software Process) /TSP (Team Software Process): El PSP  es una tecnología que tiene como justificación la premisa de que la calidad de software depende del trabajo de cada uno de los ingenieros de software y de aquí que el proceso diseñado debe ayudar a controlar, manejar y mejorar el trabajo de los ingenieros. El objetivo de PSP es lograr una mejor planeación del trabajo, conocer con precisión el desempeño, medir la calidad de productos y mejorar las técnicas para su desarrollo. La instrumentación de esta tecnología consiste en lo que se denomina “evolución del PSP”. El TSP se concentra en los aspectos del desarrollo de software realizados por equipos de trabajo, definiendo aspectos como la asignación y control de tareas para los diversos miembros del equipo.
• SPICE (Software Process Improvement and Capability dEtermination): El SPICE es un modelo de madurez de procesos internacional. SPICE fomenta productos de calidad, promueve la optimización de procesos y facilita la evaluación del producto a través de los procesos de desarrollo. SPICE tiene diversos alcances, se aplica tanto a nivel directivo como a nivel de usuarios para asegurar que el proceso se encuentra alineado con las necesidades del negocio, apoya en que los proveedores de software tengan que someterse a una sola evaluación para aspirar a nuevos negocios y busca que las organizaciones de software dispongan de una herramienta universalmente reconocida para dar soporte a su programa de mejoramiento continuo.
• PEMM (Performance Engineering Maturity Model): El PEMM presenta un modelo para evaluar los niveles de integración, aplicación, ejecución y diseño, llamado ingeniería de la ejecución del modelo de madurez. Al igual que SPICE se apoya en el modelo de madurez de capacidades CMM. El objetivo de PEMM es poder evaluar la Ejecución de la Ingeniería así como la integración del proceso. El modelo sirve tanto para evaluar una organización como los propios desarrollos de procesos tecnológicos específicos. Sirve también para definir el criterio al escoger un proveedor de software para los productos críticos o semi-críticos de la compañía.
• TickIt: Desarrollado por el Departamento de Comercio e Industria del Reino Unido, surge por la poca adopción de las normas internacionales de calidad ISO 9000 para el área de desarrollo de software. TickIt es primordialmente una guía que presenta las estrategias para lograr la certificación en la producción de software a través de la interpretación de los estándares ISO. Los objetivos principales de TickIt son, además de desarrollar un sistema de certificación aceptable en el mercado, estimular a los desarrolladores de software a implementar sistemas de calidad, dando la dirección y guías necesarias para tal efecto.

Referencias:

• Mario G. Piattini y Otros. Calidad de Sistemas Informaticos. Editorial Ra-Ma. 2006
• Roger Pressman. Ingenieria del Software: Un Enfoque Practico. McGraw-Hill. 2006
• Ian Sommerville. Ingenieria de Software. Pearson. 2005
• Alfredo Weitzenfeld. Ingenieria de Software Orientada a Objetos: Teoría y Práctica con UML y Java. Thomson Paraninfo. 2005
• Mario G. Piattini y Otros. Analisis y Diseño de Aplicaciones Informáticas de Gestión: Una perspectiva de Ingenieria del Software. Editorial Ra-Ma. 2003
• Mario G. Piattini y Otros. Calidad en el Desarrollo y Mantenimiento del Software.. Editorial Ra-Ma. 2003

El Análisis comienza en la descripción del problema el analista construye un modelo de la situación del mundo real que muestra sus propiedades importantes. Dicho analista debe trabajar con quien hace la solicitud para comprender el problema porque las definiciones del mismo no suelen ser completas ni correctas. El modelo de análisis es una abstracción resumida y precisa de lo que debe hacer el sistema deseado y no de la forma en que se hará. Los objetos del modelo deberán ser conceptos del dominio de la aplicación y no conceptos de implementación de la computadora tales como estructuras de datos. Un buen modelo podrá ser comprendido y criticado por expertos de la aplicación que no sean programadores. El modelo de análisis no deberá contener ninguna decisión de implementación, los objetos se describirán en términos de atributos y operaciones que son visibles para el usuario.

Modelo Funcional

El propósito del Modelo Funcional es capturar lo que hace el sistema, sin preocuparse del como ni del cuando.

El modelo funcional, representado en UML con Diagramas de Caso de Uso, describe la funcionalidad del sistema desde el punto de vista del usuario.

Modelo de Objetos

Describe la estructura estática (de datos), de los objetos del sistema (identidad y atributos) y también sus relaciones entre objetos.

El modelo de objetos, representado en UML con Diagramas de Clase, describe la estructura de un sistema desde el punto de vista de objetos y asociaciones.

Modelo dinámico

Describe los aspectos de comportamiento (de control) de un sistema que cambian con el tiempo. El modelo dinámico se utiliza para especificar e implementar los aspectos del control del sistema.

El modelo dinamico, representado en UML con Diagramas de Secuencia, Diagramas de Colaboracion, Diagramas de Actividad y Diagramas de Estado, describe el comportamiento del sistema.

DISEÑO

Diseño de Objetos

En el Diseño de Objetos se construye un modelo de diseño basándose en el modelo de análisis. El foco de atención del diseño de objetos son las estructuras de datos y los algoritmos necesarios para implementar cada una de las clases.

Diseño del Sistema

En el Diseño del Sistema se toman decisiones de alto nivel acerca de la arquitectura global. Durante el diseño, el sistema de destino se organiza en subsistemas basados tanto en la estructura del análisis como en la arquitectura propuesta. El diseñador de sistemas deberá decidir qué características de rendimiento hay que optimizar. Seleccionando una estrategia para atacar el problema y efectuando las reservas de recursos tentativas.

IMPLEMENTACION

En la Implementación las clases de objetos y las relaciones desarrolladas durante su diseño se traducen finalmente a un lenguaje de programación concreto, a una base de datos o a una implementación en hardware.

Referencias:

• James E. Rumbaugh, Michael R. Blaha, William J. Premerlani, Frederick Hedí y William E. Lorensen. Modelado y Diseño Orientado a Objetos. Metodología OMT. Prentice-Hall. 1996
• Bernd Bruegge, Allen H. Dutoit. Ingenieria del Software Orientado a Objetos. McGraw-Hill. 2002

Fuente Original:
Grady Booch, Ivar Jacobson, James Rumbaugh. El Proceso Unificado de Desarrollo de Software. Addison Wesley, 2000

Fuente Original:

Grady Booch, Ivar Jacobson, James Rumbaugh. El Lenguaje Unificado de Modelado. Addison Wesley. 2000

La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna es tan difícil de corregir más adelante… Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto. [Frederick P. Brooks, 1987]

Introduccion:

Es muy frecuente escuchar entre los conocedores del desarrollo de software (programas de computadoras), que un gran número de los proyectos de software fracasan por no realizar una adecuada definición, especificación, y administración de los requerimientos. Dentro de esa mala administración se pueden encontrar factores como la falta de participación del usuario, requerimientos incompletos y el mal manejo del cambio a los requerimientos.

La Ingeniería de Requerimientos (IR) cumple un papel primordial en el proceso de producción de software, ya que se enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, las necesidades de los usuarios o clientes; de esta manera, se pretende minimizar los problemas relacionados por la mala gestión de los requerimientos en el desarrollo de sistemas.

Definicion: Requerimientos

• Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. [Std 610.12-1900, IEEE: 62]
• Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. [Std 610.12-1900, IEEE: 62]
• Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste. [Sommerville, 2005: 108]

Definicion: Ingenieria de Requerimientos

• Ingeniería de Requerimientos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software. [Pressman, 2006: 155]
• La ingeniería de requerimientos es el proceso de desarrollar una especificación de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema. [Sommerville, 2005: 82]
• La Ingeniería de Requerimientos se define, como un conjunto de actividades en las cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución (a veces más de una). [Ortas 1997]

Actividades de la Ingenieria de Requerimientos:

• Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema.
• Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento.
• Especificación: En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle.
• Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos.

Técnicas y Herramientas utilizadas en las actividades de Ingenieria de Requerimientos:

• Entrevistas y cuestionarios
• Sistemas existentes
• Grabaciones de video y de audio
• Brainstorming (tormenta de ideas)
• Arqueología de documentos
• Aprendiz.
• Observación
• Run Use Case WorkShop (talleres de trabajo basados en los Casos de Uso)
• Prototipos
• Análisis FODA (Fortalezas, Oportunidades, Debilidades y Amenazas)
• Cadena de valor
• Modelo de clase conceptual, Diagrama Conceptual, Diagrama de Clases Conceptual
• Diagrama de pescado (Ishikawa Diagram, Cause-and-Effect o Fishbone Diagram)
• Glosario
• Diagrama de actividad
• Documento ESRE, Casos de uso
• Lista de requerimientos
• Casos de uso
• Casa de calidad o QFD (Quality Function Deployment)
• Checklist (lista de verificación)

Referencias:

• Nicolás Davyt Dávila. Ingeniería de Requerimientos: Una guía para extraer, analizar, especificar y validar los requerimientos de un proyecto. Universidad ORT Uruguay, 2003
• Michael Arias Chaves. La Ingeniería de Requerimientos y su importancia en el desarrollo de proyectos de software. Revista Intersedes, Universidad de Costa Rica, 2006
• Roger Pressman, Ingenieria de Software: Un enfoque practico. Mcgraw Hill, 2006
• Ian Sommerville, Ingenieria de Software. Pearson, 2005

Es necesario un proceso que sirva como guia para todos los participantes clientes, usuarios, desarrolladores y directivos ejecutivos. No nos sirve ningun proceso antiguo; necesitamos uno que sea el mejor proceso que la industria pueda reunir en este punto de su historia. Por ultimo necesitamos un proceso que este ampliamente disponible de forma que todos los interesados puedan comprender su papel en el desarrollo en el que se encuentran implicados.

Un proceso de desarrollo de software deberia tambien ser capaz de evolucionar durante muchos años. Durante esta evolucion deberia limitar su alcance, en un momentodel tiempo dado, a las realidades que permitan las tecnologias, herramientas, personas y patrones de organizacion.

1. Tecnologias: El proceso debe contruirse sobre las tecnologias lenguajes de programacion, sistemas operativos computadores, estructuras de red, entornos de desarrollo, etc disponibles en el momento en que se va a emplear el proceso. Por ejemplo hace varios años el modealado visual no era realmente de uso general. Era demasiado caro. En aquellos tiempos, un creador de un proceso practicamente tenia que asumir que se usarian diagramas hechos a mano. Esa suposicion limitaba mucho el gado en el cual el creador del proceso podia establecer el modelado dentro del proceso.
2. Herramientas: Los procesos y las herramientas deben desarrollarse en paralelo. Las herramientas son esenciales en el proceso. Dicho de otra forma, un proceso ampliamente utilizado para soportar la inversion necesaria para crear las herramientas que lo soporten.
3. Personas: Un creador del proceso debe limitar el conjunto de habilidades necesarias para trabajar en el proceso a las habilidades que los desarrolladores actuales poseen, o apuntar aquellas que los desarrolladores puedan obtener rapidamente. Hoy es posible empotrar las herramientas software tecnicas que antes requieran amplios conocimientos, como la comprobacion de la consistencia en los diagramas del modelo.
4. Patrones de Organizacion: Aunque los desarralladores de software no pueden ser expertos tan independientes como los musicos de una orquestas, estan muy lejos de los trabajadores automatas en los cuales Frederick W. Taylor baso su “Direccion Cientifica” hace cien años. El creador del proceso debe adoptar el proceso a las realidades del momento hechos como mezcla(en empresas pequeñas recien montadas) de socios de la empresa, empleados asalariados, trabajadores de obra y subcontratas de outsourcing y la prolongada escacez de desarrolladores de software.

Los ingenieros del proceso deben equilibrar estos cuatro conjuntos de circunstancias. Ademas el equilibrio debe estar presente no solo ahora, sino tambien en el futuro. El creador del proceso debe diseñar el proceso de forma que pueda evolucionar, de igual forma que el desarrollador de software intenta desarrollar un sistema que no solo funciona este año, sino que evoluciona con exito en los años venideros. Un proceso debe madurar durante varios años antes de productos comerciales manteniendo a la vez un nivel razonable de riesgo de utilizacion. El desarrollo de un producto nuevo es bastante arriesgado en el mismo como para añadirle el riesgo de un proceso puede ser estable. Sin este equilibrio de tecnologias, herramientas, personas y organizacion, el uso del proceso seria bastante arriesgado.

Fuente Original:

Grady Booch, Ivar Jacobson, James Rumbaugh. El Proceso Unificado de Desarrollo de Software. Addison Wesley. 2000

Mas que una disciplina o un cuerpo de conocimiento, la ingenieria es un verbo, una palabra de accion, una manera de abordar un problema. [Scott Whitmire]

Introduccion

La Ingenieria del Software es una disciplina o area de la informatica o ciencias de la computacion, que ofrece metodo y tecnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. Hoy dia es cada vez mas frecuente la consideracion de la Ingenieria del Software como un nueva area de la ingenieria, y el Ingeniero del Software comienza a ser una profesion implantada en el mundo laboral internacional, con derechos, deberes y responsabilidades que cumplir, junto a una, y reconocida consideracion social en el mundo empresarial y, por suerte, para esas personas con brillante futuro.

Definicion: Ingenieria

La ingeniería es el estudio y la aplicación de las distintas ramas de la tecnología. El profesional en este ámbito recibe el nombre de ingeniero.

La actividad del ingeniero supone la concreción de una idea en la realidad. Esto quiere decir que, a través de técnicas, diseños y modelos, y con el conocimiento proveniente de las ciencias, la ingeniería puede resolver problemas y satisfacer necesidades humanas.

La ingeniería también supone la aplicación de la inventiva y del ingenio para desarrollar una cierta actividad. Esto, por supuesto, no implica que no se utilice el método científico para llevar a cabo los planes.

Definicion: Software

Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos asociados que forman parte de las operaciones de un sistema de computación. [Std. 729, IEEE]

El software no son solo programas, sino todos los documentos asociados y la configuracion de datos que se necesitan para hacer que estos programas operen de manera correcta. Un sistema de software consiste en diversos programas independientes, archivos de configuracion que se utilizan para ejecutar estos programas, un sistema de documentacion que describe la estructura del sistema, la documentacion para el usuario que explica como utilizar el sistema y sitios web que permitan a los usuarios descargar la informacion de productos recientes. [Sommerville, 2004]

El software de computadora es el producto que los ingenieros de software construyen y despues mantienen en el largo plazo. El software se forma con (1) las instrucciones (programas de computadora) que al ejecutar se proporcionan las caracteristicas, funciones y el grado de desempeño deseados; (2) las estructuras de datos que permiten que los programas manipulen informacion de manera adecuada; y (3) los documentos que describen la operacion y uso de los programas. [Pressman, 2005]

Definiciones: Ingenieria del Software

• Ingenieria del Software es el estudio de los principios y metodologias para desarrollo y mantenimiento de sistemas de software. [Zelkovitz, 1978]
• Ingenieria del Software es la aplicacion practica del conocimiento cientifico en el diseño y construccion de programas de computadora y la documentacion asociada requerida para desarrollar y operar (funcionar) y mantenerlos. Asi como tambien desarrollo de software o produccion de software. [Bohem, 1976]
• La Ingenieria del Software es el establecimiento y uso de principios solidos de la ingenieria para obtener economicamente un software confiable y que funcione de modo eficiente en maquinas reales. [Bauer, 1972]
• Ingenieria de Software es la aplicacion de un enfoque sistematico, disciplinado y cuantificable al desarrollo operacion (funcionamiento) y mantenimiento del software: es decir, la aplicacion de ingenieria al software. [IEEE, 1993]
• La Ingenieria de Software es una disciplina de la ingenieria que comprende todos los aspectos de la produccion de software desde las etapas iniciales de la especificacion del sistema hasta el mantenimiento de este despues que se utiliza. [Sommerville, 2004]
• La Ingenieria de Software es una disciplina que integra el proceso, los metodos, y las herramientas para el desarrollo de software de computadora. [Pressman, 2005]

Principales areas de estudio y/o investigacion

• Metodos y Metodologias de Desarrollo de Software
• Procesos de Desarrollo de Software
• Gestion de Proyectos de Software
• Medicion y Estimacion de Software
• Ingenieria de Requisitos / Requerimientos
• Ingenieria de Software Empirica
• Gestion de Riesgos
• Usabilidad de Software
• Evaluacion de Software
• Metricas de Software
• Calidad de Software
• Metodos Formales
• Ingenieria Web

Referencias:

• Roger Pressman. Ingenieria del Software: Un Enfoque Practico. McGraw-Hill. 2006
• Ian Sommerville. Ingenieria de Software. Pearson. 2005
• Alfredo Weitzenfeld. Ingenieria de Software Orientada a Objetos: Teoría y Práctica con UML y Java. Thomson Paraninfo. 2005
• Mario G. Piattini y Otros. Analisis y Diseño de Aplicaciones Informáticas de Gestión: Una perspectiva de Ingenieria del Software. Editorial Ra-Ma. 2003
• Eric J. Braude. Ingeniería de Software: Una perspectiva orientada a objetos. Editorial Ra-Ma. 2003
• Stephen R. Schach. Ingeniería de Software Clasica y Orientada a Objetos. McGraw-Hill. 2006