La metodología para el desarrollo de software se entiende como el conjunto de estrategias, procesos y técnica gráfica que apoyan a los programadores a desarrollar nuevo software. Las metodologías se fundamentan en una composición de los modelos genéricos de proceso, como los de espiral, incremental, evolutivo o cascada, entre varios más. De manera complementaria, una metodología habría de precisar con claridad los artefactos, actividades y roles incluidos, aunados a técnicas y prácticas específicas, guías de aplicación de la metodología al software, guías de apoyo para uso de herramientas, etc. Comúnmente se utiliza el concepto “método” para dirigirse a técnicas, notaciones y guías relacionadas, que son ajustables a una (o algunas) acciones del proceso de desarrollo, por ejemplo, se hace mención de métodos de análisis y/o diseño. La comparativa y/o catalogación de metodologías no es una actividad sencilla, ya que la variedad de propuestas y diferencias en el nivel de detalle, disponibilidad de información e importancia de cada una de ellas es amplia. En conclusión, si nos basamos en el criterio de las claves utilizadas para detallar artefactos generados en actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos:
CARACTERÍSTICAS. Existen tres metodologías para el desarrollo de software: La metodología clásica del ciclo de vida de desarrollo de sistemas (estructurada), la metodología de desarrollo por análisis estructurado y la metodología de construcción de prototipos de sistemas(orientada a objetos). Las tres metodologías de desarrollo tienen un uso amplio en organizaciones de todo tipo y tamaño; cada metodología es efectiva cuando se emplea adecuadamente. Los analistas son los responsables del desarrollo de sistemas que tengan utilidad para los administradores y empleados de una organización, Las principales características de estas metodologías son: Ciclo de vida de desarrollo de sistemas:
Incluye investigación preliminar.
Recolección de datos.
Determinación de requerimientos.
Diseño del sistema.
Desarrollo del software.
Prueba del sistema.
Implantación del sistema.
Metodología de desarrollo por análisis estructurado:
Modela los componentes por medio de símbolos gráficos.
Utiliza diagramas de flujo de datos.
Señalización de flujo de datos entre dispositivos y medios de almacenamiento.
Se hace hincapié en los hechos y no en la forma en que estos se llevan a cabo.
Metodología de análisis estructurado:
También utiliza modelos gráficos.
Formula especificaciones funcionales.
Incluye una descripción de la interacción entre los diferentes módulos del sistema.
No muestra la lógica de las infecciones entre módulos.
ADMINISTRACIÓN DE REQUERIMIENTOS. La administración de requerimientos es un proceso que tiene por objetivo comprender y controlar los requerimientos. Como todo proceso de administración, inicia con la planeación y la identificación inicial de requerimientos. Este proceso tiene diferentes formas que dependen del proceso de desarrollo de software que se esté empleando. Independientemente de esto, se deben considerar las siguientes etapas:
Requerimientos duraderos y volátiles.
Planeación de la administración de requerimientos.
Administración del cambio de los requerimientos.
Durante esta etapa, para cada proyecto, es necesario establecer el nivel de detalle.
Se tiene que decidir sobre: 1. La identificación de los requerimientos. 2. Un proceso de administración del cambio. 3. Políticas de rastreo. 4. Ayuda de herramientas CASE.
La administración de requerimientos necesita: 1. Almacenar requerimientos. 2. Administrar los cambios. 3. Administrar el rastreo. Estudios de fiabilidad. Ya que las exigencias del negocio definen la necesidad del sistema de información, el comité de aprobación puede autorizar al analista de sistemas para crear un caso más detallado de negocio para entender las limitaciones y oportunidades asociadas con el proyecto de sistema propuesto. El análisis de factibilidad orienta a la empresa en la determinación si hay que seguir con un proyecto. El análisis de factibilidad también identifica los riesgos importantes inherentes al el proyecto que deben ser tomados en cuenta si el proyecto es aprobado. Como con la petición de sistema, cada empresa tiene su propio proceso y formato para el análisis de factibilidad, el cual debe incluir técnicas para evaluar tres áreas: factibilidad técnica, factibilidad económica y factibilidad de operación. Los resultados de estas técnicas se combinan en un estudio de factibilidad que se entrega al comité de aprobación al final de la iniciación del proyecto. Factibilidad técnica: este estudio se refiere a la posibilidad técnica y la conveniencia de una solución informática en el área del problema. Algunas de las cuestiones se solaparán con los puntos presentados en el análisis sobre los costos y beneficios. Factibilidad económica: el segundo elemento de un análisis de factibilidad debe realizar un análisis de factibilidad económica (también llamado análisis de costo-beneficio) que identifica el riesgo financiero asociado con el proyecto. Factibilidad operativa: la técnica final usada para el análisis de factibilidad debe evaluarla factibilidad operacional del sistema, en última instancia, será aceptado por sus usuarios e incorporado en las operaciones en curso de la organización. Obtención y análisis de requerimientos. En la etapa inicial, la estructura de preguntas y respuesta es benéfico, pero no es una estrategia que haya sido valiosa de manera definitiva para una obtención de requerimientos más detallada; de hecho, la reunión para preguntas y respuestas se debe utilizar solo para la primera reunión y después se debe sustituir por un formato de obtención de requerimientos que alterne elementos de la solución, elaboración, negociación y especificación del problema. Si se requiere iniciar un esfuerzo vinculado y dirigido al equipo de recopilación de requerimientos, un equipo de participantes y desarrolladores operan unidos para detectar el problema, facilitar elementos de solución, negociar distintos perfiles y detallar un conjunto inicial de requerimientos. Cada uno manipula un contexto muy distinto, pero todos emplean alguna diferenciación, por ejemplo:
Se establecen reglas para la preparación y la participación.
Las reuniones las guía alguno de los participantes, ya sea un analista de sistemas,un cliente o un ingeniero de software.
Se propone una orden del día formal que permita cubrir todos los puntos importantes, pero flexible como para considerar el flujo de ideas.
El análisis de requerimientos crea la descripción de especificaciones estratégicas de software, propone la interfaz del software con otros componentes del sistema y constituye las limitaciones que debe tener el software. El análisis de requerimientos admite que el ingeniero de software se extienda sobre requisitos y construya modelos que representen escenarios del usuario, actividades funcionales, clases de problemas y sus relaciones, el comportamiento de las clases y el sistema y, a medida que se transforma, el flujo de datos. El análisis de requerimientos le proporciona al diseñador de software un entorno de información, acción y procedimiento que pueden terminar en diseños de interfaz y en el nivel de elementos. Por otro lado, el modelo de análisis y la especificación de requerimientos facilitan al desarrollador y al cliente las formas para evaluar la calidad del software una vez desarrollado. LA NOTACIÓN. Numerosos métodos requieren desarrollar descripciones genéricas o modelos gráficos del software en el análisis y/o diseño de su metodología. Se desarrollan estos modelo sutilizando una clase de notación. La innovación de la notación proporciona el significado a los modelos. Las notaciones, para ser eficaces en el desarrollo de grandes sistemas requieren un mecanismo para dividir los componentes en secciones más manejables. Las herramientas comúnmente utilizadas en la notación de las metodologías del diseño de software se pueden ver a continuación:
Diagrama de transición de estados. El diagrama de estado es un método para representar el comportamiento de un sistema que muestra sus estados y los eventos que ocasionan que dicho sistema cambie de estado. Un estado es cualquier forma de comportamiento observable. Además, el diagrama de estado indica las acciones (por ejemplo, la activación del proceso en la figura siguiente) que se toma como consecuencia de un evento particular.
Un diagrama de estado representa visiblemente los estados y eventos más importantes de un objeto, así como su actuar ante un evento. Las transiciones se representan con flechas que contienen el nombre del evento correspondiente (ver figura siguiente). Los estados se representan con óvalos. Se suele considerar un pseudo estado inicial que efectúa automáticamente la trasformación a otro estado en el momento de crear una instancia.
Diagrama de objetos. Se usan para representar, explicar, elaborar y documentar la efectividad de ciertas instancias de elementos contenidos en los diagramas de clases. Con frecuencia, los diagramas de objetos se usan para crear estructuras de objetos, lo que involucra tomar una reproducción de los objetos de un sistema en ciertas circunstancias. Los diagramas de objetos también se utilizan para crear la perspectiva de diseño estática o la perspectiva de técnicas estáticas de un sistema de igual manera que se hace con los diagramas de clases, a partir las vistas reales o prototipeadas. En un diseño se pueden identificar varios diagramas de objetos, cada uno mostrando distintos estados del sistema (ver figura siguiente). Los diagramas de clases pueden contener instancias, por ejemplo: Objetos. Enlaces. Si un diagrama contuviese únicamente objetos, sería un diagrama de objetos: Representación: Tienen identidad y atributos. Son instancias particulares de una clase.
Un diagrama de interacción manifiesta detalladamente las interacciones que hay entre las instancias y las clases del modelo de éstas. El centro de inicio de las interacciones es el cumplimiento de las condiciones posteriores de los convenios de operación. El UML (Lenguaje Unificando de Modelado) especifica dos clases de estos diagramas. Los dos expresan interacciones idénticas o semejantes de mensaje: a) Los diagramas de colaboración representan las relaciones entre los objetos en forma de grafo o red, como se muestra en la figura siguiente:
b) Los diagramas de secuencia representan las relaciones existentes entre los objetos a través de mensajes consecutivos en una forma de cerca o muro, como se muestra en la figura:
Diagrama de módulos. Representan la ubicación de clases y objetos en forma de módulos del diseño físico de un sistema. Un diagrama de módulos muestra parte de la totalidad del diseño de módulos de los que está formado el sistema. Un módulo es una unidad lógica funcional, una arquitectura lógica para agrupar clases, asociaciones y generalizaciones. Sus alcances son materia de opinión. Para visualizar la designación de clases y objetos a módulos en el esquema físico de un sistema, utilizamos un diagrama de módulos, como se puede ver en la figura siguiente. Un solo diagrama de módulos visualiza una vista de la organización de módulos de un sistema. Los módulos y sus dependencias son los dos componentes principales de un diagrama de módulos.
Diagrama de procesos. El diagrama de procesos es una forma gráfica de representar las acciones involucradas en la fabricación de un bien y/o servicio entero por medio de símbolos (ver figura siguiente). Un diagrama de actividades visualiza un flujo de actividades (nodos que efectúan un proceso) que suelen ser secuenciales; además, muestra los resultados de dichas actividades. En la realidad, cuando se tiene un proceso de producción y se busca lograr mayor productividad, se analizan las diferentes operaciones para identificar potenciales o reales “cuellos de botella” y proporcionar soluciones usando técnicas de ingeniería de métodos.
¿Para qué sirve? Para visualizar flujos entre procesos del negocio. Para captar la especificación de un caso de uso. Para captar las actividades internas de un proceso. APLICACIÓN DE LA NOTACIÓN. La aplicación de la notación del diseño debe guiar a una representación procedimental sencilla de entender y revisar. Por otra parte, la notación facilita la capacidad decodificar para que éste sea parte de un subproducto natural del diseño. Por último, la representación de diseño debe tener la capacidad de darle mantenimiento fácilmente para que siempre represente el programa de manera correcta. Una pregunta que surge en cualquier análisis de la notación de diseño es: ¿cuál notación realmente es mejor, dados los atributos indicados? La aplicación de la notación puede incrustarse directamente en los listados de código fuente, mejorando la documentación y facilitando el mantenimiento del diseño. La edición se hace en cualquier editor de texto o sistema de procesamiento de palabras; ya existen procesadores automáticos y la posibilidad de “generación automática de código” es buena. Sin embargo, de esto no se desprende que cualquier otra notación sea necesariamente inferior a la aplicación de la notación, o que “no sea buena” en atributos específicos. La naturaleza gráfica de los diagramas de actividad y los de flujo proporcionan una perspectiva sobre el flujo de control que muchos diseñadores prefieren. En el análisis final, la elección de una herramienta de diseño estará relacionada de manera más estrecha con factores humanos que con atributos técnicos. EL PROCESO. El proceso unificado de modelado UML provee la tecnología para favorecer la práctica de la ingeniería del software orientada a objetos, pero no proporciona el marco de trabajo del procedimiento que guíe a los equipos en la aplicación de la tecnología. En el presente y siguientes años se ha desarrollado el proceso unificado, un marco de trabajo para la ingeniería del software orientada a objetos, mediante la utilización del UML. En el presente, el proceso unificado y el UML (ver figura siguiente) se utiliza de manera amplia en proyectos OO de todos tipos.
El estándar iterativo e incremental que plantea el proceso unificado PU puede y debe aplicarse para satisfacer requerimientos de proyecto específicas. Como consecuencia de la aplicación del UML se alcanza la promoción de un ajuste de productos de trabajo. Sin embargo, éstos los minimizan para conseguir que el desarrollo sea más rápido y reactivo ante el cambio. Microprocesadores de desarrollo. El microprocesador es considerado el cerebro de la computadora, el engranaje, la esencia de la máquina; es uno de los componentes de la computadora desarrollado para llevar acabo o ejecutar los programas. Ejecuta órdenes que se le indican al ordenador debajo nivel, realizando operaciones lógicas básicas, como sumar, restar, multiplicar y dividir. El microprocesador es un chip, un tipo de componente electrónico compuesto por miles de componentes llamados transistores que, cuando se combinan, facilitan el desarrollo de las funciones que tenga asignadas el chip. Los microprocesadores son el resultado del desarrollo en el camino iniciado por la electrónica digital dirigida a la miniaturización, inicialmente implementando una unidad de procesos integral en una sola base o chip de circuito integrado, y con el incremento de la rapidez, capacidad de trabajo y potencia de dicha unidad.El microprocesador es uno de los resultados más destacados del siglo XX. Su utilización en distintos dispositivos y distintas aéreas del conocimiento ha comenzado a cambiar la forma en que percibimos el mundo e incluso a nosotros mismos. Actualmente, el microprocesador es uno de los productos más importantes dentro de una larga lista de innovaciones tecnológicas. Macroprocesadores de desarrollo. Con la finalidad de evitar al programador la pesada reproducción de partes idénticas de un programa, los compiladores y ensambladores cuentan con macroprocesadores que facilitan definir una síntesis para simbolizar una parte de un programa y manipular esa síntesis cuantas veces se requiera. Para manipular una macro, primero hay que declararla, en la cual se crea el nombre que se le dará y el grupo de indicaciones que representará. El programador utilizará el nombre de la macro en los lugares donde se solicite la aplicación de las instrucciones por ella incorporadas. Solo una vez se realiza la declaración, pero la llamada o invocación a la macro puede hacerse cuantas veces sea requerida. El uso de macros propicia la reducción del tamaño del código fuente, sin embargo, el código objeto tiende a ser mayor que con el uso de funciones. Es tan usual el uso de macros que se les toma como una prolongación de los lenguajes de programación. De la misma forma, se toma al procesador de macroinstrucciones o macroprocesador como una amplificación del lenguaje ensamblador o compilador utilizado. El macroprocesador realiza en una instancia inicial, el registro de todas las declaraciones de macroinstrucciones y de seguir el programa fuente para identificar todas las macrollamadas. En cada parte donde se localice una macrollamada, el macroprocesador efectuará el intercambio por las instrucciones correspondientes. A este procedimiento de sustitución se le llama expansión de macroinstrucciones. Para el manejo de las macros, el macroprocesador genera dos tablas:
Tabla de macronombres. Contiene los nombres de los macroinstrucciones y el índice de la ubicación de la declaración de las macroinstrucciónes, referenciada en otra tabla de macrodefiniciones.
Tabla de macrodefiniciones. Aquí localizamos las definiciones de todas las macros a emplearse en el sistema.
