TEMA 11. DISTRIBUCIÓN DE APLICACIONES · PDF fileDistribución de aplicaciones...

11.1Programación .NET (II). Distribución de aplicaciones Windows

TEMA 11. DISTRIBUCIÓN DE APLICACIONES WINDOWS

11.1. CICLO DE VIDA DE UNA APLICACIÓN

Aunque este curso está enfocado a aprender técnicas de programación es

importante que veas esta tarea dentro del conjunto que supone el desarrollo

de una aplicación software.

Embarcarse en un proyecto de programación supone avanzar a través de unas

etapas que van desde la idea inicial, o la necesidad que el programa pretende

cubrir, hasta el programa final terminado y funcionando correctamente.

Para poder gestionar completamente el desarrollo de aplicaciones de cierta

envergadura existe lo que se denominan metodologías de desarrollo, dentro

del ámbito de estudio de lo que se conoce por Ingeniería del software.

El modelo aplicado al ciclo de vida de una aplicación no es único y existen

distintos acercamientos a la idea de cómo debe llevarse un proyecto de

programación. En nuestro caso vamos a centrarnos en el ciclo de vida clásico,

también llamado modelo en cascada.

Dado que desarrollar una aplicación siguiendo alguna de estas metodologías

es una tarea ardua, ¿Qué beneficios se pretenden obtener de este esfuerzo

extra?

Principales beneficios de usar una metodología de desarrollo

Organización. Al dividir un proyecto en fases es más sencillo organizar

el desarrollo en tareas y asignar los recursos

Rapidez. Si se plantean bien cada una de las etapas del desarrollo se

pueden evitar los retrasos

Economizar. Es más fácil abordar una planificación y un control de

costes cuando las etapas están definidas

Asegurar la calidad. Tal vez uno de los puntos más importantes, es

que utilizando una metodología podemos detectar errores en fases

tempranas y asegurar la calidad del producto final

Programación .NET (II). Distribución de aplicaciones Windows11.2

Modelo de ciclo de vida en cascada

Este modelo de ciclo de vida es una de las primeras metodologías que vieron

la luz a finales de los años 60 y principios de los 70, y aunque han aparecido

otros muchos modelos desde entonces, es una metodología aún utilizada y

puede servirte como punto de partida.

El modelo de ciclo en cascada no es más que una división en etapas que deben

ir cumpliéndose a lo largo del desarrollo de software, dichas etapas son:

Según este paradigma, y de manera ideal, debería llevarse a cabo cada una

de las fases siendo el final de cada fase el principio de la siguiente:

1. Especificación de requisitos2. Análisis3. Diseño4. Codificación5. Pruebas6. Implantación7. Mantenimiento


Pero en la práctica estas fases no solo se solapan sino que además se

retroalimentan , es lo que se conoce como modelo de cascadaretroalimentado:

Pasaremos ahora a describir las fases que componen este paradigma.

Especificación de requisitos

Aunque podemos entender esta fase como la primera etapa del proyecto hay

que considerar que en algunos casos se marca como inicio del proyecto una

fase previa que no es más que la necesidad por parte del usuario final de tener

un programa que cumpla con sus expectativas.

En la fase de especificación de requisitos se plantean las necesidadesque debe cubrir el nuevo software, que problemas debe solventar, aquien va dirigido y con qué fin.

En esta fase no nos interesa cómo lo vamos a hacer simplemente es importante

definir qué es lo que queremos.


¿Quiénes intervienen en esta fase?

En esta fase intervienen:

El director del proyecto

Los usuarios finales / cliente

¿Qué herramientas se utilizan?

Durante esta fase la herramienta principal para captar y recoger todos los

requisitos es la entrevista. Otra forma de obtener requisitos pueden ser los

cuestionarios, donde mediante preguntas claras se pueda obtener una idea de

lo que se espera como resultado del desarrollo.

¿Qué obtenemos al concluir esta fase?

Al final de esta fase se debe tener un documento el que se especifiquen todos

los requerimientos de la aplicación. A este documento se le denomina catalogo

de requisitos y no es más que un listado con lo que se espera que el programa

debe hacer (o no hacer).

Análisis

Durante la fase de análisis es importante determinar qué información estará

presente en el sistema, como fluye esta información y los roles de los

principales usuarios de la aplicación.

Como punto de partida el analista debe utilizar el catálogo de requisitos de la

fase previa pero también es importante determinar si existe una aplicación

previa o cuáles son las actividades y procesos que se llevan a cabo y que deben

quedar representados en el programa.

Gracias a este análisis se definirá con claridad la estructura de losdiferentes elementos que intervienen en el programa, sus relaciones,la posible evolución en el tiempo de los mismos así como sus distintasfuncionalidades.




El jefe de proyecto

El analista


Para esta fase el analista puede utilizar diagramas de modelado, generalmente

aquellos que sirvan para representar comportamientos o interacciones como

los diagramas de casos de uso o los diagramas de actividades o los diagramas

de flujo.


Conjunto de documentación donde se incluyan los diagramas llevados a cabo

por el analista así como la documentación para poder evaluar que el análisis

es satisfactorio, como pueden ser una revisión de prototipos o unas pruebas

de escenarios de uso.

Diseño

En el modelo clásico en cascada las fases de análisis y diseño están bien

diferenciadas aunque en algunos casos suelen solaparse bastante (y a veces

hasta confundirse), de hecho por norma general y en proyectos no muy

grandes el analista y el diseñador suelen ser la misma persona o equipo de

personas.

Es en esta fase en la que se decide cómo se van a llevar los requisitosal programa, además de otras especificaciones más técnicas relacionadas con

el sistema gestor de base de datos o el lenguaje de programación, algunos

prototipos de interfaces de usuario, etc..




El Analista

Diseñador / Analista-Programador


Para esta fase se parte de la documentación generada en la etapa anterior. En

esta etapa es habitual hacer uso de herramientas de modelado que describan

la estructura de la aplicación como los diagramas de clases, diagrama de

componentes, de despliegue, etc.


La documentación generada debe incluir el diseño de la arquitectura del

sistema, el entorno tecnológico de la aplicación, detalles sobre los distintos

roles, operaciones y seguridad, además del modelo de datos, planes de

migración, requisitos de implantación y conjunto de pruebas.

Codificación

Es en esta fase en la que se incorpora el equipo de programación conla finalidad de desarrollar el código. Además de los programadores es

habitual contar con la participación del administrador de la base de datos

Gracias a las etapas anteriores el programador ya conoce que módulosson los que hay que desarrollar, con que funcionalidad y sobre quemodelo de datos va a trabajar.

Si el programa a desarrollar es muy grande lo normal es dividir estos módulos

y asignarlos a distintos programadores. La descripción del trabajo a llevar a

cabo se recoge en el denominado cuaderno de carga.




Analista/ Diseñador

Programador

Administrador Base de datos


Dependiendo de la tecnología y el lenguaje de programación a utilizar se usarán

las herramientas especificas para eso, como entornos de desarrollo o

herramientas de administración de bases de datos. Evidentemente se debe

contar con la documentación de fases previas en especial los que modelen

clases y objetos y de los distintos cuadernos de carga.


Los distintos módulos programados y la documentación específica de dichos

módulos.

Pruebas

En todo proceso de desarrollo de software debe existir una fase de pruebas

que nos ayuda a asegurar la calidad del producto terminado.

Dentro de las distintas pruebas podemos diferenciar las pruebas unitariasque se encargan de verificar cada módulo concreto de manera aislada y las

pruebas de integración que se usan para asegurar el correcto

funcionamiento de los distintos módulos un vez que estén trabajando de

manera conjunta como una sola aplicación.

Por norma general el programador es encargado de realizar pruebas unitarias

de los módulos, pero también es habitual preparar un grupo de pruebas no

relacionado con el desarrollo y que tenga relación con los usuarios finales, o

clientes, de la aplicación.




Analista/Diseñador

Programador / Equipo de pruebas


Durante las fases anteriores se ha debido preparar la batería de casos de

pruebas que se deben ejecutar sobre la aplicación. Existen multitud de sistemas

para llevar a cabo pruebas ya sean unitarias o de integración. Algunas de estas

técnicas son: pruebas de caja negra, de caja blanca, de regresión, de valores

frontera, de estrés, etc.


Código probado y verificado. Documentación de fallos encontrados y medidas

adoptadas para su rectificación

Implantación y mantenimiento

La implantación consiste en llevar una instalación del productoterminado para el usuario final. Es habitual que en esta fase también

participe el administrador de la base de datos si la aplicación así lo demanda.

Junto con la implantación es habitual proporcionar algún medio de formaciónal usuario para que pueda llevar la explotación del nuevo sistema de la manera

más eficiente posible.

También en esta fase se entregan los distintos manuales y otra documentación

complementaria que se ha debido generar durante las fases previas del

proyecto.


El mantenimiento es la etapa final de todo proyecto y puede verse como un

mantenimiento correctivo, solucionando errores no detectados durante las

fases de pruebas, o un mantenimiento evolutivo para añadir nuevas

funcionalidades al producto desarrollado.



El Usuario

Equipo de implantación

Administrador Base de datos

Director de proyecto


Diagrama de despliegue, Diseño de la arquitectura del sistema. Procedimientos

de seguridad, control de acceso, operación y administración del sistema


Plan de presentación del sistema, Pruebas, Implantación y Mantenimiento.-

Plan de formación para usuarios finales, Bases de Datos y/o ficheros cargados.

Aprobación del sistema, sistema en producción


11.2. EMPAQUETADO Y VERSIONADO

El paso previo a la entrega de un programa ya finalizado es el empaquetado.

Empaquetar un programa consiste en agrupar todos los ficherosbinarios y de recursos de los que consta la aplicación para queposteriormente puedan ser distribuidos e instalados. Para entendernos,

este proceso es el que creará el instalador de la aplicación.

Este proceso puede ser llevado a cabo de muchas maneras, y también

dependerá del tipo de producto a entregar.

Además de Visual Studio, existen múltiples soluciones, comerciales y gratuitas

para generar empaquetadores, como InstallShield, Wise Installer, Advanced

Installer o WiX

De los sistemas de empaquetado de Visual Studio podemos destacar ClickOncey Proyectos de tipo Setup.

ClickOnce

ClickOnce es una tecnología de implementación que le permite crear

aplicaciones con actualización automática basadas en Windows que se pueden

instalar y ejecutar con una mínima interacción del usuario.

Accedemos al sistema de empaquetado ClickOnce a través de las propiedades

del proyecto y seleccionando la pestaña Publicar. En esta ficha definimos la

ruta de instalación,las opciones de configuración de la instalación asi como de

la versión del producto.


La opción Archivos de aplicación nos permite discriminar entre los ficheros

que estrán disponibles en el empaquetado final.


Otra de las opciones que se pueden configurar es la necesidad de que existan

componente de .NET Framework previamente instalados así como otros

componentes redistribuibles, esto se hace a través del botón Requisitosprevios. A través de esta opción podemos marcar y desmarcar los

componentes que sean necesarios, así como determinar la forma de conseguir

dichos componentes en el caso de que no estén instalados.

Mediante la opción Actualizaciones se puede definir es la manera en que se

va a gestionar la aparición de actualizaciones y nuevas versiones del producto.

Dentro de esta opcíon indicamos si nuestro producto debe buscar o no

actualizaciones, en que momento debe hacerlo asi como la ubicación donde

debe comprobar la existencia de dichas actualizaciones. También desde esta

opción podremos forzar una versión mínima necesaria para poder ejecutar la

aplicación.


Mediante el botón Opciones se pueden definir otras opciones de publicación

como el idioma, el nombre del editor y del producto, dirección donde encontrar

soporte, etc..

Podemos valernos del asistente para la publicación para llevar a cabo la

misma mediante una serie de pasos guiados.

Este asistente nos preguntará las opciones de instalación imprescindibles, que

sin el asistente hemos podido ir definiendo en las opciones vistas

anteriormente, como la ubicación de publicación o la direción de actualización.

Una vez terminado el asistente nuestro instalador estará preparado en la

ubicación de publicación indicada.


Proyectos de tipo Setup

Es una de las plantillas instaladas en la versión comercial (no Express) de Visual

Studio. Mediante esta plantilla se puede desarrollar un empaquetador. Para ello,

lo que debemos hacer es crear un proyecto nuevo del tipo Proyecto deInstalación, ubicado en el apartado Otro tipo de proyectos.

En este tipo de proyecto las tareas principales son definir las propiedades del

proyecto y añadir los ficheros que se instalaran en la Carpeta de Aplicación,

El Escritorio del Usuario y en el Menu de Programas.

En las propiedades del proyecto definiremos el nombre de nuestro producto,

autor del contenido, ruta de instalación, empresa responsable...

Una vez definidos algunos parámetros del instalador es el momento de añadir

los ficheros de los que se compondrá la instalación, empezando por los que se

copiaran a la carpeta de instalación.


Esto se realiza desde el explorador de soluciones, con la opción añadir archivo:

Además de los ficheros que se incluirán en el directorio de instalación podemos

añadir otros elementos que se ubicarán en el escritorio del usuario y en el

menú de inicio del sistema del usuario. Bastará con situarse en la carpeta

indicada y añadir el elemento deseado.


Como sucedia anteriormente podemos cambiar las propiedades de estos

elementos de la instalación.

Entre las propiedades de los ficheros añadidos, se encuentra la propiedad Vital,que indicará que la instalación es correcta o no dependiendo de si se pudo

instalar dicho fichero sin problemas.

Una vez concluido el proceso de añadido de ficheros en las ditintas carpetas

podemos proceder a generar el instalador.

Antes que nada indicaremos al entorno de desarrollo que genere laconstrucción del proyecto como aplicación finalizada en lugar dehacerlo en modo depuración:

Tras realizar esto podremos generar el instalador a través del menú Generary su opción Generar instalador. Tras generar obtendremos archivos

necesarios para instalar nuestra aplicación, entre ellos el archivo setup.exe que

iniciará la instalación.

TEMA 11. DISTRIBUCIÓN DE APLICACIONES · PDF fileDistribución de aplicaciones...

Documents

Transcript of TEMA 11. DISTRIBUCIÓN DE APLICACIONES · PDF fileDistribución de aplicaciones...