Virtual Bosco

herramientas de modelo de software

“El desarrollo de Software es un proceso complejo y a menudo difícil que requiere la síntesis de muchos sistemas. Desde el modelado y diseño hasta el código, administración del proyecto, pruebas, despliegue, administración de cambios y más, Enterprise Architect una herramienta de modelado basada en UML se ha convertido en una parte esencial para administrar esa complejidad. ”
Si necesita:

Administrar Requisitos

Modelar y analizar los procesos de negocios

Construir diseño y modelos de comportamientos

Generar e importar código fuente en una variedad de lenguajes

Generar e importar esquema de base de datos

Generar e importar XSD

Crear modelos de componentes y de despliegue

Rastrear cambios

Administrar pruebas

Confirmar la trazabilidad desde los requisitos a través y hasta el despliegue

Documentar su desarrollo de software

Comunicar y desarrollar proyectos de ingeniería de software basados en el equipo

Modelado/ingeniería rápida de su desarrollo de software

El desarrollo de software ha progresado bastante en la última década, y las herramientas de modelado forman un componente importante en el entorno de desarrollo de hoy en día. Las demandas en la industria han incrementado enormemente, particularmente en las áreas de robustez, portabilidad y reusabilidad, por esto combinar el poder de UML 2.1 y tecnologías MDA puede cumplir con esas demandas.

Lenguajes

El UML es principalmente un lenguaje para describir sistemas orientados a objetos independientes de cualquier lenguaje de programación específico. Es simple de aprender, y bastante flexible, y consistente desde el planeamiento hasta el despliegue. Los beneficios de usar UML incluyen la trazabilidad, mejorada, inteligibilidad entre los usuarios y un mantenimiento realmente simplificado. Enterprise Architect soporta el UML 2.1 estándar, y Sparx Systems tiene disponible extensiones personalizadas para UML con los propósitos de modelar los procesos de negocios, esquemas XSD y más.

La estructura MDA mejora las capacidades de UML para proveer transformaciones de modelo a modelo, proporcionándole así la capacidad de mantener modelos de plataformas independientes de un sistema, y generar y mantener modelos de plataformas específicas sincronizadas, a través de una variedad de plataformas concurrentemente.

Metodologías

Hay un extenso rango de prácticas de desarrollo, por ejemplo métodos como el Proceso unificado y el Desarrollo ágil. Ninguna práctica en particular es la mejor, ya que los requisitos pueden variar enormemente de proyecto a proyecto, y por esto EA facilita un amplio rango de metodologías.

El rol que Enterprise Architect juega en la Ingeniería de Software

El objetivo de Enterprise Architect es proveer todos estos elementos juntos en un entorno que sea tanto coherente como flexible. Un soporte extenso para la notación de UML 2.1 se combina con las herramientas de administración de procesos que le permiten decidir sobre una metodología.

soporta un amplio rango de diagramas del UML 2.0, permitiendo modelar casi cualquier sistema, desde aplicaciones Web hasta sistemas embebidos. La generación de diagramas UML es fácil y rápida, y la maquina de gráficos produce diagramas altamente legibles. El explorador de proyectos hace que la navegación de procesos enteros sea un asunto simple. Además, las características de la amplia documentación de EA le permiten generar, personalizar y mantener soluciones de software completas fácilmente.

Combine transformaciones MDA con las características de la generación de código de las ediciones profesionales y corporativas de EA y así tendrá un espacio de trabajo en el cual planear, modelar y realizar sistemas complejos. Los vínculos MDG opcionales proveen el potencial para integrar directamente con Visual Studio.NET o Eclipse para obtener una solución de desarrollo completa.

Ingenieria de soiftware

Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software (IEEE 1993) , y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software.1 Integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería.
Se citan las definiciones más reconocidas, formuladas por 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).

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

La ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarollo, operación, y mantenimiento del software (IEEE, 1993
)

Objetivos

La ingeniería de software aplica diferentes normas y métodos que permiten obtener mejores resultados, en cuanto al desarrollo y uso del software, mediante la aplicación correcta de estos procedimientos se puede llegar a cumplir de manera satisfactoria con los objetivos fundamentales de la ingeniería de software.
Entre los objetivos de la ingeniería de software están:

Mejorar el diseño de aplicaciones o software de tal modo que se adapten de mejor manera a las necesidades de lasorganizaciones o finalidades para las cuales fueron creadas.

Promover mayor calidad al desarrollar aplicaciones complejas.

Brindar mayor exactitud en los costos de proyectos y tiempo de desarrollo de los mismos.

Aumentar la eficiencia de los sistemas al introducir procesos que permitan medir mediante normas específicas, la calidad del software desarrollado, buscando siempre la mejor calidad posible según las necesidades y resultados que se quieren generar.

Una mejor organización de equipos de trabajo, en el área de desarrollo y mantenimiento de software.

Detectar a través de pruebas, posibles mejoras para un mejor funcionamiento del software desarrollado.

Recursos

Recurso humano

Son todas aquellas personas que interviene en la planificación de cualquier instancias de software (por ejemplo: gestor, ingeniero de software experimentado, etc.), El número de personas requerido para un proyecto de software sólo puede ser determinado después de hacer una estimación del esfuerzo de desarrollo...

Recursos de software reutilizables

Son aquellos componentes de un software que son usados en otras aplicaciones. De la misma índole, ya sea para reducir costos o tiempo.

Recursos de entorno

Es el entorno de las aplicaciones (software y hardware) el hardware proporciona el medio físico para desarrollar las aplicaciones (software), este recurso es indispensable

Implicaciones Socioeconomicas

Económicamente

En los Estados Unidos, el software contribuyó a una octava parte de todo el incremento del PIB durante la década de 1990 (alrededor de 90,000 millones de dólares por año), y un noveno de todo el crecimiento de productividad durante los últimos años de la década (alrededor de 33.000 millones de dólares estadounidenses por año). La ingeniería de software contribuyó a US$ 1 billón de crecimiento económico y productividad en esa década. Alrededor del globo, el software contribuye al crecimiento económico de maneras similares, aunque es difícil de encontrar estadísticas fiables.
Además, con la industria del lenguaje está hallando cada vez más campos de aplicación a escala global.

Socialmente

La ingeniería de software cambia la cultura del mundo debido al extendido uso de la computadora. El correo electrónico (e-mail), la WWW y la mensajería instantánea permiten a la gente interactuar de nuevas maneras. El software baja el costo y mejora la calidad de los servicios de salud, los departamentos de bomberos, las dependencias gubernamentales y otros servicios sociales. Los proyectos exitosos donde se han usado métodos de ingeniería de software incluyen a GNU/Linux, el software del transbordador espacial, los cajeros automáticos y muchos otros.

Notaciones

LUM (lenguaje unificado de modelado) o UML

Es un lenguaje de modelado muy reconocido y utilizado actualmente que se utiliza para describir o especificar métodos. También es aplicable en el desarrollo de software. Las siglas UML significan lenguaje unificado de modelado esto quiere decir que no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado.

Un lenguaje de modelado consiste de vistas, elementos de modelo y un conjunto de reglas: sintácticas, semánticas y pragmáticas que indican cómo utilizar los elementos.

BPMN (notación para el modelado de procesos de negocios)

El objetivo de la notación para el modelado de procesos de negocios es proporcionar de una manera fácil de definir y analizar los procesos de negocios públicos y privados simulando un diagrama de flujo. La notación ha sido diseñada específicamente para coordinar la secuencia de los procesos y los mensajes que fluyen entre los participantes del mismo, con un conjunto de actividades relacionadas.

Características básicas de los elementos de BPMN:
Objetos de flujo: eventos, actividades, rombos de control de flujo (gateways).
Objetos de conexión: flujo de secuencia, flujo de mensaje, asociación.
Swimlanes (carriles de piscina): pool, lane.
Artefactos: objetos de datos, grupo, anotación.

Diagrama de flujo de datos (DFD)

Un diagrama de flujo de datos permite el movimiento de datos a través de un sistema por medio de modelos que describen los flujos de datos, los procesos que tranforman o cambian los datos, los destinos de datos y los almacenamientos de datos a la cual tiene acceso el sistema.

Su inventor fue Larry Constantine, basado en el modelo de computación de Martin y Estrin: flujo gráfico de datos. Con los diagramas de flujo de datos determina la manera en que cualquier sistema puede desarrollarse, ayuda en la identificación de los datos de la transacción en el modelo de datos y proporciona al usuario una idea física de cómo resultarán los datos a última instancia.

Metodos

Los métodos son herramientas computacionales que están destinadas a asistir en los procesos de ciclo de vida de un software, estos son estructurados para el desarrollo del software, también facilitan la producción del software y se basan principalmente en la idea de un modelo gráfico. No existe un método ideal para la elaboración de un software. Son enfoques estructurados para el desarrollo del software.

Metodologia

Un objetivo de décadas ha sido el encontrar procesos y metodologías, que sean sistemáticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software, en pocas palabras, determina los pasos a seguir y como realizarlos para finalizar una tarea.

etapas del pproceso

La ingeniería de software requiere llevar a cabo numerosas tareas agrupadas en etapas, al conjunto de estas etapas se le denomina ciclo de vida. Las etapas comunes a casi todos los modelos de ciclo de vida son las siguientes:

Obtención de los requisitos

Se debe identificar sobre que se está trabajando es decir, el tema principal que motiva el inicio del estudio y creación del nuevo software o modificación de uno ya existente. a su vez identificar los recursos que se tienen, en esto entra el conocer los recursos humanos y materiales que participan en el desarrollo de las actividades.

Se tienen que tener dominio de información de un problema lo cual incluye los datos fuera del software(usuarios finales, otros sistemas o dispositivos externos), los datos salen del sistema (por la interfaz de usuario, interfaces de red, reportes, gráficas y otros medios) y los almacenamientos de datos que recaban y organizan objetos persistentes de datos (por ejemplo, aquellos que se conservan de manera permanente).

También hay que ver los puntos críticos lo que significa tener de una manera clara los aspectos que entorpecen y limitan el buen funcionamiento de los procedimientos actuales, los problemas más comunes y relevantes que se presentan, los motivos que crean insatisfacción y aquellos que deben ser cubiertos a plenitud. Por ejemplo:
¿El contenido de los reportes generados, satisface realmente las necesidades del usuario? ¿Los tiempos de respuesta ofrecidos, son oportunos?, etc.

Hay que definir las funciones que realizara el software ya que estas ayudan al usuario final y al funcionamiento del mismo programa.

Se tiene que tener en cuenta como será el comportamiento del software antes situaciones inesperadas como lo son por ejemplo una cantidad de usuarios enormes usando el software o una gran cantidad de datos entre otros.

Análisis de requisitos

Extraer los requisitos de un producto software es la primera etapa para crearlo. Durante la fase de análisis, el cliente plantea las necesidades que se presenta e intenta explicar lo que debería hacer el software o producto final para satisfacer dicha necesidad mientras que el desarrollador actúa como interrogador, como la persona que resuelve problemas. Con este análisis, el ingeniero de sistemas puede elegir la función que debe realizar el software y establecer o indicar cual es la interfaz más adecuada para el mismo.

El análisis de requisitos puede parecer una tarea sencilla, pero no lo es debido a que muchas veces los clientes piensan que saben todo lo que el software necesita para su buen funcionamiento, sin embargo se requiere la habilidad y experiencia de algún especialista para reconocer requisitos incompletos, ambiguos o contradictorios. Estos requisitos se determinan tomando en cuenta las necesidades del usuario final, introduciendo técnicas que nos permitan mejorar la calidad de los sistemas sobre los que se trabaja.

El resultado del análisis de requisitos con el cliente se plasma en el documento ERS (especificación de requisitos del sistema), cuya estructura puede venir definida por varios estándares, tales como CMMI. Asimismo, se define un diagrama de entidad/relación, en el que se plasman las principales entidades que participarán en el desarrollo del software.

La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos metódicos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la ingeniería de requisitos.

La IEEE Std. 830-1998 normaliza la creación de las especificaciones de requisitos de software (Software Requirements Specification).

Finalidades del análisis de requisitos:

Brindar al usuario todo lo necesario para que pueda trabajar en conjunto con el software desarrollado obteniendo los mejores resultados posibles.

Tener un control más completo en la etapa creación del software, en cuanto a tiempo de desarrollo y costos.

Utilización de métodos más eficientes que permitan el mejor aprovechamiento del software según sea la finalidad de uso del mismo.

Aumentar la calidad del software desarrollado al disminuir los riesgos de mal funcionamiento.

No siempre en la etapa de "análisis de requisitos" las distintas metodologías de desarrollo llevan asociado un estudio de viabilidad y/o estimación de costes. El más conocido de los modelos de estimación de coste del software es el modelo COCOMO

Limitaciones

Los software tienen la capacidad de emular inteligencia creando un modelo de ciertas características de la inteligencia humana pero sólo posee funciones predefinidas que abarcan un conjunto de soluciones que en algunos campos llega a ser limitado. Aun cuando tiene la capacidad de imitar ciertos comportamientos humanos no es capaz de emular el pensamiento humano porque actúa bajo condiciones.

Otro aspecto limitante de los software proviene del proceso totalmente mecánico que requiere de un mayor esfuerzo y tiempos elevados de ejecución lo que lleva a tener que implementar el software en una máquina de mayor capacidad.

Especificación

La especificación de requisitos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del éxito de un proyecto de software radicará en la identificación de las necesidades del negocio (definidas por la alta dirección), así como la 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:
-Caso de uso

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores. En el contexto de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. 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. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.
Los más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.

Pasos para la Definición de un Caso de Uso:

ID

NOMBRE

REFERENCIAS CRUZADAS

CREADO POR

ULTIMA ACTUALIZACION POR

FECHA DE CREACION

FECHA DE ULTIMA ACTUALIZACION

ACTORES

DESCRIPCION
*
TRIGGER

PRE-CONDICION

POST-CONDICION

FLUJO NORMAL

FLUJOS ALTERNATIVOS

INCLUDES

FRECUENCIA DE USO

REGLAS DE NEGOCIO

REQUERIMIENTOS ESPECIALES

NOTAS Y ASUNTO

-Historias de usuario

Una historia de usuario es una representación de un requisito de software escrito en una o dos frases utilizando el lenguaje común del usuario. Las historias de usuario son utilizadas en las metodologías de desarrollo ágiles para la especificación de requisitos (acompañadas de las discusiones con los usuarios y las pruebas de validación). Cada historia de usuario debe ser limitada, esta debería poderse escribir sobre una nota adhesiva pequeña. Dentro de la metodología XP las historias de usuario deben ser escritas por los clientes.
Las historias de usuario son una forma rápida de administrar los requisitos 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 requisitos cambiantes.

Caracteristicas

Las historias de usuario deben ser:
Independientes unas de otras: De ser necesario, combinar las historias dependientes o buscar otra forma de dividir las historias de manera que resulten independientes.
Negociables: La historia en si misma no es lo suficientemente explícita como para considerarse un contrato, la discusión con los usuarios debe permitir esclarecer su alcance y éste debe dejarse explícito bajo la forma de pruebas de validación.
Valoradas por los clientes o usuarios: Los intereses de los clientes y de los usuarios no siempre coinciden, pero en todo caso, cada historia debe ser importante para alguno de ellos más que para el desarrollador.
Estimables: Un resultado de la discusión de una historia de usuario es la estimación del tiempo que tomará completarla. Esto permite estimar el tiempo total del proyecto.
Pequeñas: Las historias muy largas son difíciles de estimar e imponen restricciones sobre la planificación de un desarrollo iterativo. Generalmente se recomienda la consolidación de historias muy cortas en una sola historia.
Verificables: Las historias de usuario cubren requerimientos funcionales, por lo que generalmente son verificables. Cuando sea posible, la verificación debe automatizarse, de manera que pueda ser verificada en cada entrega del proyecto.

Siendo los primeros más rigurosas y formales, los segundas más ágiles e informales.

Arquitectura

La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto.

El arquitecto de software es la persona que añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas.

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.

Lo principal en este punto es poner en claro los aspectos lógicos y físicos de las salidas, modelos de organización y representación de datos, entradas y procesos que componen el sistema, considerando las bondades y limitaciones de los recursos disponibles en la satisfacción de las pacificaciones brindadas para el análisis.

Hay que tener en consideración la arquitectura del sistema en la cual se va a trabajar, elaborar un plan de trabajo viendo la prioridad de tiempo y recursos disponibles. En los diseños de salidas entra los que es la interpretación de requerimientos lo cual es el dominio de información del problema, las funciones visibles para el usuario, el comportamiento del sistema y un conjunto de clases de requerimientos que agrupa los objetos del negocio con los métodos que les dan servicio.

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

Diagrama de despliegue

Diagrama de secuencia

Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser codificado. Dependiendo del alcance del proyecto, complejidad y necesidades, el arquitecto elegirá cuales de los diagramas se requiere elaborar.

Diagramas de clases

Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, orientados a objetos.

Diagramas

- Propiedad de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lógica de negocio, dependiendo de quién diseñe el sistema se pueden unir los datos con las operaciones.
- El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz gráfica.
- Presenta las clases del sistema con sus relaciones estructurales y de herencia.
El diagrama de clases es la base para elaborar una arquitectura MVC o MVP.

Diagramas de base de datos

Las herramientas para el diseño y modelado de software se denominan CASE (Computer Aided Software Engineering) entre las cuales se encuentran:

Enterprise Architect

Microsoft Visio for Enterprise Architects

Herramienta CASE

Captura de pantalla del editor UML Umbrello Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras. Ya en los años 70 un proyecto llamado ISDOS diseñó un lenguaje y por lo tanto un producto que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).

Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC.

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.

Objetivos

Mejorar la productividad del software 1 Aumentar la calidad del software
2 Reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informáticos.
3 Mejorar la planificación de un proyecto
4 Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.
5 Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.
6 Ayuda a la reutilización del software, portabilidad y estandarización de la documentación
7 Gestión global en todas las fases de desarrollo de software con una misma herramienta.
8 Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

Programación

Implementar un diseño en código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. 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.

Desarrollo de la aplicación
Para el desarrollo de la aplicación es necesario considerar cinco fases para tener una aplicación o programa eficiente, estas son:

Desarrollo de la infraestructu
ra: Esta fase permite el desarrollo y la organización de los elementos que formaran la infraestructura de la aplicación, con el propósito de finalizar la aplicación eficientemente.
Adaptación del paque
te: El objetivo principal de esta fase es entender de una manera detallada el funcionamiento del paquete, esto tiene como finalidad garantizar que el paquete pueda ser utilizado en su máximo rendimiento, tanto para negocios o recursos. Todos los elementos que componen el paquete son inspeccionados de manera detallada para evitar errores y entender mejor todas las características del paquete.
Desarrollo de unidades de diseño de interactivas:
En esta fase se realizan los procedimientos que se ejecutan por un
diálogo usuario-sistema. Los procedimientos de esta fase tienen como objetivo principal:
- Establecer específicamente las acciones que debe efectuar la unidad de diseño.
- La creación de componentes para sus procedimientos.
- Ejecutar pruebas unitarias y de integración en la unidad de diseño.

Desarrollo de unidades de diseño batch:

En esta fase se utilizan una serie de combinación de técnicas, como diagrama de flujo, diagramas de estructuras, tablas de decisiones, etc. Cualquiera a utilizar será beneficioso para plasmar de manera clara y objetiva las especificaciones y que así el programador tenga mayor comprensión a la hora de programar y probar los programas que le corresponden.

Desarrollo de unidades de diseño manuales:
En esta fase el objetivo central es proyectar todos los procedimientos administrativos que desarrollarán en torno a la utilización de los componentes computarizados.

Pruebas de software

Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica es probar por separado cada módulo del software, y luego probarlo de manera 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. En general hay dos grandes maneras de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta manera se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.

De acuerdo con Roger S. Pressman, el proceso de pruebas se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales, es decir, la realización de pruebas para la detección de errores. Se requiere poder probar el software con sujetos reales que puedan evaluar el comportamiento del software con el fin de proporcionar realimentación a los desarrolladores. Es importante que durante el proceso de desarrollo del software no se pierda contacto con los interesados o solicitantes del desarrollo de Software, de esta manera los objetivos del proyecto se mantendrán vigentes y se tendrá una idea clara de los aspectos que tienen que probarse durante el período de pruebas.

Implementación

Una Implementación es la realización de una especificación técnica o algoritmos con un programa, componente software, u otro sistema de cómputo. Muchas especificaciones son dadas según a su especificación o un estándar. Las especificaciones recomendadas según el ´
, y las herramientas de desarrollo del software contienen implementaciones de lenguajes de programación. El modelo de implementación es una colección de componentes y los subsitemas que contienen. Componentes tales como: ficheros ejecutables, ficheros de código fuente y todo otro tipo de ficheros que sean necesarios para la implementación y despliegue del sistema.

Documentación

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

Mantenimiento

Fase dedicada a mantener y mejorar el software para corregir errores descubiertos e incorporar nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo del software inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un proyecto20 está dedicado a su mantenimiento. Una pequeña parte de este trabajo consiste eliminar errores (bugs); siendo que la mayor parte reside en extender el sistema para incorporarle nuevas funcionalidades y hacer frente a su evolución.

Ventajas

Desde el punto de vista de gestión

Facilitar la tarea de seguimiento del proyecto

Optimizar el uso de recursos

Facilitar la comunicación entre usuarios y desarrolladores

Facilitar la evaluación de resultados y cumplimiento de objetivos

Desde el punto de vista de los ingenieros de Software

Ayudar a comprender el problema

Permitir la reutilización

Facilitar el mantenimiento del producto final

Optimizar el conjunto y cada una de las fases del proceso de desarrollo

Desde el punto de vista de cliente o usuario final

Garantizar el nivel de calidad del producto final

Obtener el ciclo de vida adecuado para el proyecto

Confianza en los plazos del tiempo mostrados en la definición del proyecto

Modelos y Ciclos de Vida del Desarrollo de Software

La ingeniería de software, con el fin de ordenar el caos que era anteriormente el desarrollo de software, dispone de varios modelos, paradigmas y filosofías de desarrollo, estos los conocemos principalmente como modelos o ciclos de vida del desarrollo de software, esto incluye el proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega y el retiro del sistema y representa todas las actividades y artefactos (productos intermedios) necesarios para desarrollar una aplicación,22 entre ellos se puede citar:

Modelo en cascada o clásico

En ingeniería de software el modelo en cascada ―también llamado desarrollo en cascada o ciclo de vida clásico― se basa en un enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, esto sugiere una aproximación sistemática secuencial hacia el proceso de desarrollo del software, que se inicia con la especificación de requisitos del cliente y continúa con la planificación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado.

Modelo de prototipos

En ingeniería de software, el modelo de prototipos pertenece a los modelos de desarrollo evolutivo. Este permite que todo el sistema, o algunos de sus partes, se construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se necesita así como también la solución que se propone para dicha necesidad y de esta manera minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se asegura su uso real.

Este modelo principalmente se aplica cuando un cliente define un conjunto de objetivos generales para el software a desarrollarse sin delimitar detalladamente los requisitos de entrada procesamiento y salida, es decir cuando el responsable no está seguro de la eficacia de un algoritmo, de la adaptabilidad del sistema o de la manera en que interactúa el hombre y la máquina.

Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos.

Modelo en espiral

El modelo en espiral, que Barry Boehm propuso originalmente en 1986, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada, es decir, cuando se aplica este modelo, el software se desarrolla en una serie de entregas evolutivas (ciclos o iteraciones), cada una de estas entregando prototipos más completas que el anterior, todo esto en función del análisis de riesgo y las necesidades del cliente. Aunque el modelo espiral representa ventajas por sobre el desarrollo lineal, el cálculo de los riesgos puede ser muy complicado y por lo cual su uso en el ámbito real es muy escaso.

Modelo de desarrollo por etapas

Es un modelo en el que el software se muestra al cliente en etapas refinadas sucesivamente. Con esta metodología se desarrollan las capacidades más importantes reduciendo el tiempo necesario para la construcción de un producto; el modelo de entrega por etapas es útil para el desarrollo de la herramienta debido a que su uso se recomienda para problemas que pueden ser tratados descomponiéndolos en problemas más pequeños y se caracteriza principalmente 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.
En este modelo pueden distinguirse las siguientes fases:
- Especificación conceptual.
- Análisis de requisitos.
- Diseño inicial.
- Diseño detallado (codificación, depuración, prueba y liberación).

Cuando es por etapas, en el diseño global estas fases pueden repetirse según la cantidad de etapas que sean requeridas.
Entre sus ventajas tenemos:

1 Detección de problemas antes y no hasta la única entrega final del proyecto.
2 Eliminación del tiempo en informes debido a que cada versión es un avance.
3 Estimación de tiempo por versión, evitando errores en la estimación del proyecto general.
4 Cumplimiento a la fecha por los desarrolladores.

Modelo Incremental o Iterativot

Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada, es decir, este modelo aplica secuencias lineales como el modelo en cascada, pero de una manera iterativa o escalada según como avance el proceso de desarrollo y con cada una de estas secuencias lineales se producen incrementos (mejoras) del software.

Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos, ya que como se mencionó anteriormente, este tipo de modelo es iterativo por naturaleza, sin embargo se diferencia en que este busca la entrega de un producto operacional con cada incremento que se le realice al software.

Este desarrollo incremental es útil principalmente cuando el personal necesario para una implementación completa no está disponible.

Modelo estructurado

Este modelo ―como su nombre lo indica― utiliza las técnicas del diseño estructurado o de la programación estructurada para su desarrollo, también se utiliza en la creación de los algoritmos del programa. Este formato facilita la comprensión de la estructura de datos y su control.27 Entre las principales características de este modelo se encuentan las siguientes:

Generalmente se puede diferenciar de una manera más clara los procesos y las estructuras de datos.

Existen métodos que se enfocan principalmente en ciertos datos.

La abstracción del programa es de un nivel mucho mayor.

Los procesos y estructuras de datos son representados jerárquicamente.
Este modelo también presenta sus desventajas entre las cuales podemos mencionar algunas:

Se podía encontrar datos repetidos en diferentes partes del programa.

Cuando el código se hace muy extenso o grande su manejo se complica demasiado.

En el modelo estructurado las técnicas que comúnmente se utilizan son:

El modelo entidad-relación, esta técnica se relaciona principalmente con los datos.

El diagrama de flujo de datos, esta es utilizada principalmente para los procesos.

Modelo orientado a objetos

Estos modelos tienen sus raíces en la programación orientada a objetos y como consecuencia de ella gira entorno al concepto de clase, también lo hacen el análisis de requisitos y el diseño. Esto además de introducir nuevas técnicas, también aprovecha las técnicas y conceptos del desarrollo estructurado, como diagramas de estado y transiciones. El modelo orientado a objetos tiene dos
características principales, las cuales ha favorecido su expansión:

Permite la reutilización de software en un grado significativo.

Su simplicidad facilita el desarrollo de herramientas informáticas de ayuda al desarrollo, el cual es fácilmente implementada en una notación orientada a objetos llamado UML.

Modelo RAD (rapid application development)

El RAD (rapid application development: ‘desarrollo rápido de aplicaciones’), es un modelo de proceso de software incremental, desarrollado inicialmente por James Maslow en 1980, que resalta principalmente un ciclo corto de desarrollo.

Esta es una metodología que posibilita la construcción de sistemas computacionales que combinen técnicas y utilidades CASE (Computer Aided Software Engineering), la construcción de prototipos centrados en el usuario y el seguimiento lineal y sistemático de objetivos, incrementando la rapidez con la que se producen los sistemas mediante la utilización de un enfoque de desarrollo basado en componentes.

Si se entienden bien los requisitos y se limita el ámbito del proyecto, el proceso RAD permite que in equipo de desarrollo cree un producto completamente funcional dentro de un periodo muy limitado de tiempo sin reducir en lo más mínimo la calidad del mismo.

Modelo de desarrollo concurrente

El modelo de desarrollo concurrente es un modelo de tipo de red donde todas las personas actúan simultáneamente o al mismo tiempo. Este tipo de modelo se puede representar a manera de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.

El modelo de proceso concurrente define una serie de acontecimientos que dispararan transiciones de estado a estado para cada una de las actividades de la ingeniería del software. Por ejemplo:
durante las primeras etapas del diseño, no se contempla una inconsistencia del modelo de análisis. Esto genera la corrección del modelo de análisis de sucesos, que disparara la actividad de análisis del estado hecho al estado cambios en espera. Este modelo de desarrollo se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en dos dimensiones: una división de sistemas y una división de componentes. Los aspectos del nivel de sistemas se afrontan mediante dos actividades: diseño y realización.
La concurrencia se logra de dos maneras:

Las actividades del sistema y de componente ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos descrito anteriormente.

Una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.

En realidad, el modelo de desarrollo concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual de un proyecto. En vez de confinar actividades de ingeniería de software a una secuencia de sucesos, define una red de actividades, todas las actividades de la red existen simultáneamente con otras. Los sucesos generados dentro de una actividad dada o algún otro lado de la red de actividad inicia las transiciones entre los estados de una actividad.

Proceso unificado del desarrollo de software

Artículos principales:
Proceso Unificado y Rational Unified Process.
El proceso unificado es un proceso de software genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos.

Provee un enfoque disciplinado en la asignación de tareas y responsabilidades dentro de una organización de desarrollo. Su meta es asegurar la producción de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible.
El proceso unificado tiene dos dimensiones:

Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento

Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lógica de acuerdo a su naturaleza.

La primera dimensión representa el aspecto dinámico del proceso conforme se va desarrollando, se expresa en términos de fases, iteraciones e hitos (milestones).

La segunda dimensión representa el aspecto estático del proceso:

cómo es descrito en términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles.

El refinamiento más conocido y documentado del proceso unificado es el RUP (proceso unificado racional).

El proceso unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma manera, el proceso unificado de rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del proceso unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

Producto

El software se ha convertido en algo muy necesario en nuestra sociedad actual, es la maquina que conduce a la toma de decisiones comerciales, sirve para la investigacion científica moderna, es un factor clave que diferencia productos y servicios modernos, etc. Esto se da porque el software está inmerso en sistemas de todo tipo alrededor de nosotros.

El software de computadora es el producto que diseñan y construyen los ingenieros de software. Esto abarca programas que se ejecutan dentro de una computadora de cualquier tamaño y arquitectura, después de estar construido casi cualquier persona en el mundo industrializado, ya sea directa o indirectamente.
Los productos se pueden clasificar en:
Productos genéricos:
Son los producidos por una organización para ser vendidos al mercado.
Productos hechos a medida:
Sistemas que son desarrollados bajo pedido a un desarrollador específico.
Estos productos deben cumplir varias características al ser entregados, estas son: Mantenibles: El software debe poder evolucionar mientras cumple con sus funciones.
Confiabilidad: No debe producir daños en caso de errores.
Eficiencia: El software no debe desperdiciar los recursos.
Utilizacion adecuada: Debe contar con una interfaz de usuario adecuada y su documentacion.

Lo que constituye el producto final es diferente para el ingeniero y los usuarios, para el ingeniero son los programas, datos y documentos que configuran el software pero para el usuario el producto final es la información que de cierto modo soluciona el problema planteado por el usuario.

Naturaleza de la Ingeniería de Software

La ingeniería de software es una disciplina que está orientada a aplicar conceptos y métodos de ingeniería al desarrollo de software de calidad.

Matemáticas

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

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 se encuentran en la IS.

Gestión de Proyecto
El desarrollo de software de gran porte requiere una adecuada gestión del proyecto. Hay presupuestos, establecimiento de tiempos de entrega, un equipo de profesionales que liderar. Recursos (espacio de oficina, insumos, equipamiento) por adquirir. Para su administración se debe tener una clara visión y capacitación en gestión de proyectos.

Participantes y papeles

Para el desarrollo de un sistema de software es necesaria la colaboración de muchas personas con diversas competencias, capacidades e intereses. Al conjunto de personas involucradas en el proyecto se les conoce como participantes.

Al conjunto de funciones y responsabilidades que hay dentro del proyecto o sistema se le conoce como roles o papeles. Los roles están asociados a las tareas que son asignadas a los participantes, en consecuencia, una persona puede desempeñar uno o múltiples roles, así también un mismo rol puede ser representado por un equipo.

Cliente

Es frecuente el uso de los términos "usuarios", "usuarios finales" y "clientes" como sinónimos, lo cual puede provocar confusión; estrictamente, el cliente (persona, empresa u organización) es quién especifica los requerisitos del sistema36 , en tanto que el usuario es quien utiliza u opera finalmente el producto software, pudiendo ser o no el cliente.

Desarrolladores

Esta clase de participantes están relacionados con todas las facetas del proceso de desarrollo del software. Su trabajo incluye la investigacion, diseño, implementación, pruebas y depuracion del software.

Gestores

En el contexto de ingeniería de software, el gestor de desarrollo de software es un participante, que reporta al director ejecutivo de la empresa que presta el servicio de desarrollo. Es responsable del manejo y coordinación de los recursos y procesos para la correcta entrega de productos de software, mientras participa en la definición de la estrategia para el equipo de desarrolladores, dando iniciativas que promuevan la visión de la empresa.

Usuarios finales

El usuario final es quien interactúa con el producto de software una vez es entregado.39 Generalmente son los usuarios los que conocen el problema, ya que día a día operan los sistemas.

Código ético de un ingeniero de software

Un ingeniero de software deben tener un código donde aseguran, en la medida posible, que los esfuerzos realizados se utilizarán para realizar el bien y deben comprometerse para que la ingeniería de software sea una profesión benéfica y respetada. Para el cumplimiento de esta norma, se toman en cuenta ocho principios relacionados con la conducta y las decisiones tomadas por el ingeniero; donde estos principios identifican las relaciones éticamente responsables de los individuos, grupos y organizaciones donde participen. Los principios a los que deben sujetarse son sobre la sociedad, cliente y empresario, producto, juicio, administración, profesión, colegas y por último el personal.

Sociedad: Los ingenieros de software deben actuar de manera congruente con el interés social, aceptando la responsabilidad total de su trabajo, moderando los intereses con el bienestar social, aprobando el software solamente si se tiene una creencia bien fundamentada, cooperando en los esfuerzos para solucionar asuntos importantes de interés social, ser justo y veraz en todas las afirmaciones relativas al software o documentos asociados.

Cliente y empresario: Se debe actuar de manera tal que se llegue a conciliar los mejores intereses de los clientes y empresarios, congruentemente con el interés social. Estos deberán prestar servicios en sus áreas de competencia, siendo honestos y francos sobre las limitaciones, no utilizar un software que se obtenga ilegalmente o sin ética, usar la propiedad de los clientes o empresarios de manera autorizada, mantener secreto cualquier documento de información confidencial.

Producto: Hay que asegurarse que los productos y sus modificaciones cumplan con los estándares profesionales más altos posibles, procurando la alta calidad, costos aceptables y una agenda razonable asegurando que los costos y beneficios sean claros y aceptados por el empresario y el cliente. Asegurar que las metas y objetivos de cualquier proyecto sean adecuados y alcanzables.

Juicio: Se debe mantener una integridad e independencia en el juicio profesional, moderando todo juicio técnico por la necesidad de apoyar y mantener los valores humanos, mantener la objetividad profesional con respecto a cualquier software o documento relacionado, no involucrarse en prácticas financieras fraudulentas.

Administración: Se deberá asegurar una buena administración para cualquier proyecto en el cual se trabaje, utilizando procedimientos efectivos para promover la calidad y reducir riesgos, asegurándose también que se conozcan las políticas y procedimientos del empresario para proteger contraseñas, archivos e información confidencial.

Profesión: Se debe incrementar la integridad y reputación de la profesión en conjunto con el interés social, ayudando al desarrollo de un ambiente organizacional favorable para actuar, promoviendo el conocimiento público de la ingeniería de software, extendiendo el conocimiento de la ingeniería de software por medio de participaciones en organizaciones, reuniones y publicaciones profesionales.

Colegas: Cada ingeniero deberá apoyar y ser justos con los colegas, motivando a sus colegas sujetándose al código, ayudando también a su desarrollo profesional, reconocer los trabajos de otros y abstenerse a atribuirse de méritos indebidos, revisar los trabajos de manera objetiva, sincera y propiamente documentada.

Personal: Los ingenieros de software participaran toda su vida en el aprendizaje con la práctica y promoverán un enfoque ético de la profesión, mejorando su conocimiento de los avances en el análisis, especificación, diseño, desarrollo, mantenimiento, pruebas del software y documentos relacionados en conjunto con administración del proceso de desarrollo.