miércoles, 4 de mayo de 2011

Ingeniería de software

Ingeniería de software

La ingeniería de software se conoce también como Desarrollo de Software o Producción de Software y es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas 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.

La Ingeniería del Software trata de sistematizar el proceso de la creación del software, con el fin de disminuir el riesgo del fracaso en la consecución del objetivo, por medio de diversas técnicas. 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.

Metodología

La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas como:

Análisis de requerimientos

Extraer los requisitos y requerimientos de un producto de software es la primera etapa para crearlo. El resultado del análisis de requerimientos con el cliente se plasma en el documento ERS, Especificación de Requerimientos del Sistema, en el cual se plasman las principales entidades que participarán en el desarrollo del software.

Especificación

La Especificación de Requisitos describe el comportamiento esperado en el software una vez desarrollado. Hace la identificación de las necesidades del negocio, e interacción con los usuarios funcionales para la recolección, clasificación, identificación, priorización y especificación de los requisitos del software.

Entre las técnicas utilizadas para la especificación de requisitos se encuentran:

§ Casos de Uso: es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas.

§ Historias de usuario: Las historias de usuario son una forma rápida de administrar los requerimientos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las historias de usuario permiten responder rápidamente a los requerimientos cambiantes.

Arquitectura

La Arquitectura de Sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de Software. La Arquitectura de Software consiste en el diseño de componentes de una aplicación (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y además poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se construirá una aplicación de software. Para ello se documenta utilizando diagramas, por ejemplo:

§ Diagramas de clases

§ Diagramas de base de datos

§ Diagramas de despliegue plegados

§ Diagramas de secuencia multidireccional

Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qué diagramas elaborar.

Programación

Reducir un diseño a código. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.

Prueba

Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas.

Documentación

Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML: Lenguaje Unificado de Modelado), casos de uso diagramas, pruebas, manuales de usuario, manuales técnicos, etc; con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

Mantenimiento

Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. La ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas.

Modelos de desarrollo de Software

La ingeniería de software tiene varios modelos, paradigmas o filosofías 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): es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.

§ Modelo de prototipos: el diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará.

§ Modelo en espiral: las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

§ Desarrollo por etapas: el modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código.

§ Desarrollo iterativo y creciente o Iterativo e Incremental: es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada. El desarrollo incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming y los demás frameworksg de desarrollo rápido de software.

§ RAD (desarrollo rápido de aplicaciones): es un proceso de desarrollo de software, El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades.

§ Desarrollo concurrente.

§ Proceso Unificado: es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

§ RUP (Proceso Unificado de Rational): es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización.

Utilidad de un manual de usuario

El manual de usuario tiene como objetivo instruir al usuario en el uso del sistema y la solución de los problemas que puedan suceder en la operación.

Utilidad de un manual técnico

El manual técnico va dirigido a la dirección de IT, al administrador del sistema y a otros desarrolladores de software para que puedan darle mantenimiento en caso que se requiera. También puede ser utilizado por el departamento de auditaría de sistemas.

Cómo elaborar un manual de usuario

Pasos del manual del usuario:

1. Portada: De qué se trata el documento y quien lo elaboró

2. Introducción: Describe el uso del documento (para qué sirve) y de qué habla

3. Análisis y requerimientos del sistema (¿qué se ocupa para poder instalarlo y usarlo?)

3. Explicación del funcionamiento: Debes de poner paso a paso y con pantallas bien explicadas cómo funciona el programa

4. Glosario

• Debe ser escrito de tal manera, que cualquier persona pueda entenderlo con la menor dificultad posible.

• Es recomendable, detallar todos aquellos pasos que se llevan a cabo para usar el programa.

• Especificar los alcances y las limitaciones que tiene el programa.

• Un buen punto de partida para un manual de usuario, es hacer de cuenta que las personas que lo van a leer no tienen el más mínimo conocimiento sobre computadores.

Cómo elaborar un manual técnico

Lleva una descripción muy bien detallada sobre las características físicas y técnicas de cada elemento. Por ejemplo: características de procesadores, velocidad, dimensiones del equipo, garantías, soporte, proveedores y equipo adicional.

Estructura del manual técnico

1. Índice

Relación de los capítulos y páginas correspondientes que forman parte del documento

2. Introducción.

Se debe presentar una breve descripción del sistema desarrollado, que contemple el ámbito abarcado, cual es su función principal y un detalle de las funciones macros o partes que lo componen. Puede incluir un mensaje de la máxima autoridad de las áreas comprendidas en el manual.

2.1. Objetivo general del sistema

Se debe de describir el objetivo general del sistema.

2.2. Objetivos específicos

Se deben describir brevemente los objetivos específicos que se cumplieron con el desarrollo del sistema.

3. Contenido técnico

3.1. Definición de reglas del negocio implementadas en el sistema desarrollado.

3.2. Diagramas de flujo de datos, junto con su respectivo diccionario de datos.

3.3. Controles de auditoría implementados en el sistema.

3.4. Descripción de campos requeridos por pantalla con presentación de pantallas.

3.5. Diagrama de navegación del sistema.

3.6. Requerimientos de interface con otros sistemas.

3.7. Modelo lógico de datos, diagrama entidad-relación.

3.8. Modelo de datos físico, junto con su respectivo diccionario de datos.

3.9. Matriz de procesos versus organización.

3.10. Matriz de programas versus entidades.

3.11. Plataforma de usuario. Aquí se describen los requerimientos mínimos que se deben tener tanto de hardware como de software para que el sistema se pueda instalar y ejecutar correctamente (en caso de que se considere necesario).

3.12. Áreas de aplicación y/o alcance de los procedimientos. Esfera de acción que cubren los procedimientos

4. Responsables.

Para iniciar los trabajos que conducen a la integración de un manual, es indispensable prever que no queda diluida la responsabilidad de la conducción de las acciones en diversas personas, sino que debe designarse a un coordinador, auxiliado por un equipo técnico, al que se le debe encomendar la conducción del proyecto en sus fases de diseño, implantación y actualización. De esta manera se logra homogeneidad en el contenido y presentación de la información. Por lo que respecta a las características del equipo técnico, es conveniente que sea personal con un buen manejo de las relaciones humanas y que conozca a la organización en lo que concierne a sus objetivos, estructura, funciones y personal. Para este tipo de trabajo, una organización puede nombrar a la persona que tenga los conocimientos y la experiencia necesarios para llevarlo a cabo. Por la naturaleza de sus funciones puede encargarlo al titular del área específica. Asimismo, puede contratar los servicios de consultores externos.

4.1. Mapa de navegación. muestra de forma gráfica la interconexión entre cada una de las pantallas del sistema, lo que serviría para saber cómo llegar a determinada parte de la aplicación. En este se muestran los menús, submenús y pantallas a las que nos lleva cada uno de ellos

4.2. Descripción gráfica del mapa de navegación. En el anterior aparece de forma de diagrama de flujo y en esta sección deberá aparecer ya con las respectivas pantallas.

4.3. Describe paso a paso los procesos, así como pantallas, botones, cuadros de texto, etc., pero también se muestra el código de cada rutina, pantalla, botón, etc. es decir, se muestra lo que hay detrás de la interfaz del usuario