Desarrollo y comercialización de productos de software [El proceso unificado]

(1)

Desarrollo y comercializaci ´on de productos de

software [El proceso unificado]

M. en C. Sergio Luis P ´erez P ´erez

UAM CUAJIMALPA, M ´EXICO, D. F.

(2)

An ´alisis del negocio para el desarrollo de software

An ´alisis del negocio para el desarrollo de software I

Elan ´alisis del negocioconsiste en comprender cu ´ales son las necesidades del cliente/negocio, con la finalidad de articular claramente los objetivos del software a desarrollar.

Unanalista de negocio(business analyst) es el responsable de identificar las necesidades del negocio de sus clientes

interes ´andose en ayudarlos determinar las soluciones a sus problemas.

(3)

An ´alisis del negocio para el desarrollo de software II

Responsabilidades de un analista de negocios

Desarrollo y administraci ón de los requerimientos del sistema. An álisis de requerimientos organizacionales y operacionales. Validaci ón de requerimientos para la ingenier´ıa de procesos. An álisis y recomendaci ón de soluciones y de mejora continua. Validaci ón y documentaci ón de problemas.

(4)

An ´alisis del negocio para el desarrollo de software III

El analista durante la fase de desarrollo

Primero debe recoger las necesidades de los usuarios (los requerimientos o requisitos) y aglutinarlos en un documento que ser ´a entregado al departamento de desarrollo.

Participar á en el ciclo de vida del desarrollo, sobre todo en la construcci ón del dise ño del sistema donde se especifican los elementos con los que debe cumplir el software.

Se encargar ´a de la validaci ´on.

Durante la fase de construcci ón, resolver á las dudas de los t écnicos para garantizar que las aplicaciones sean construidas de

(5)

An álisis del negocio para el desarrollo de software ¿C ómo realizar el an álisis del negocio?

¿C ´omo realizar el an ´alisis del negocio? I

Los analistas deben de ser capaces de utilizar t ´ecnicas para la captura de requisitos en diferentes situaciones.

Realizando un correcto an ´alisis de negocio se podr ´a guiar el desarrollo hacia el sistema correcto.

Un flujo de trabajo sugerido para documentar todo el an ´alisis del negocio es el siguiente:

1 _{Enumerar los requisitos candidatos.} 2 _{Comprender el contexto del sistema.} 3 _{Capturar requisitos funcionales.} 4 _{Capturar requisitos no funcionales.}

(6)

¿C ´omo realizar el an ´alisis del negocio? II

Enumerar los requisitos candidatos

Durante el desarrollo del sistema, los clientes, usuarios, analistas y desarrolladores proponen ideas que pudieran convertirse en verdaderos requisitos.

Lo ideal es realizar unalista de caracter´ısticasque permita llevar un control sobre el estados de las propuestas.

Cada caracter´ıstica debe poseer los siguientes puntos: 1 _{Estado (propuesto, aprobado, validado).}

(7)

¿C ´omo realizar el an ´alisis del negocio? III

Comprender el contexto del sistema

Generalmente est ´an involucrados los analistas y el arquitecto del software.

Se puede realizar mediante modelos de dominio y de negocio. Elmodelo de dominiopermite identificar algunas de las clases durante el desarrollo del sistema.

Elmodelo de negociodescribe los procesos y ayuda en la identificaci ´on de los casos de uso.

El arquitecto y el jefe de proyecto deciden la forma de proceder (utilizan uno, ambos o ninguno).

(8)

¿C ´omo realizar el an ´alisis del negocio? IV

Capturar requisitos funcionales

Es el dise ˜no de los casos de uso.

Se debe tener en claro el contexto del sistema. Se sugiere entrevistar a los usuarios.

Se deben analizar y discutir propuestas para un mismo caso de uso.

(9)

¿C ´omo realizar el an ´alisis del negocio? V

Capturar requisitos no funcionales

Entender cu ´ales son las propiedades que debe tener el sistema. Entender las restricciones del entorno.

Entender cu ál debe ser el rendimiento del sistema en t érminos de velocidad, tiempo de respuesta, uso de memoria, entre otros. Algunos requerimientos no funcionales pueden ser gen éricos y otros mas espec´ıficos, lo que los relaciona con muchos o un s ólo caso espec´ıfico.

(10)

¿C ´omo realizar el an ´alisis del negocio? VI

¿Qu ´e es un modelo de dominio?

Unmodelo de dominiocaptura los tipos m ´as importantes de objetos/clases en el contexto del sistema.

Los principales objetos del dominio a considerar son:

Objetos del negocio. Representan las cosas que se manipulan en el negocio, como pedidos, cuentas, contratos, entre otros.

Objetos del mundo real. Son los objetos f´ısicos que se deben tomar en cuenta.

(11)

¿C ´omo realizar el an ´alisis del negocio? VII

Desarrollo de un modelo de dominio

El modelo de dominio solo contribuye a la comprensi ón de del problema, el c ómo se resolver á en el dise ño e implementaci ón del sistema.

Lo ideal es utilizarUMLu otros lenguaje de modelado para documentar los resultados.

Los dominios peque ños pueden requerir menos de 10 clases, los de tama ño moderado entre 10 y 50, y los grandes m ás de 50. Es importante desarrollar un glosario de t érminos.

(12)

¿C ´omo realizar el an ´alisis del negocio? VIII

¿Qu ´e es un modelo de negocio?

Unmodelo de negociodescribe los procesos del negocio de una empresa en t ´erminos de casos de uso y actores del negocio. El objetivo es esquematizar como el sistema proporcionar ´a un valor a sus usuarios.

Unmodelo de objetos del negociodescribe c ´omo es llevado a cabo el proceso por parte de un conjunto de actores que utilizan un conjunto de entidades y unidades de trabajo.

Unaentidad del negocioes algo f´ısico que es inspeccionado, manipulado, producido o utilizado en un caso de uso del negocio.

(13)

¿C ´omo realizar el an ´alisis del negocio? IX

Desarrollo de un modelo de negocio

Crear el modelo de casos de uso (diagrama de casos de uso) con los actores y casos involucrados.

Desarrollar el modelo de objetos, entidades y unidades de trabajo del negocio.

En realidad el modelo de dominio es una variante simplificada del modelo de negocio, la diferencia es que el modelo de dominio busca

ser m ´as concreto y compacto y el de negocio mucho m ´as general y detallado.

(14)

El Proceso Unificado

El Proceso Unificado I

El Proceso Unificado o Proceso Unificado Racional -Rational Unified Process RUP- fue creado por Philippe Kruchten en 2003.

ElProceso Unificadoes un proceso de desarrollo de software.

Su antecesor es fue el Rational Objectory Process de 1998.

Este es un modelo h´ıbrido que considera la buena pr áctica en especificaci ón y dise ño y esta de acuerdo con la entrega de prototipos y entrega incremental.

(15)

El Proceso Unificado II

Se basa en el uso de componentes software interconectados a trav ´es de interfaces.

Se ayuda de UML para la generaci ´on de los esquemas del sistema.

El Proceso Unificado se consiste de una serie de ciclos que en conjunto forman la vida del sistema.

Cada ciclo se lleva a cabo en cuatro fases: 1 _Inicio.

2 _{Elaboraci ón.} 3 _{Construcci ón.} 4 _{Transici ón.}

(16)

El Proceso Unificado III

Cada fase se compone de iteraciones.

Cada ciclo da como resultado una nueva versi ´on (completa) del sistema.

Durante cada ciclo se deben considerar flujos de trabajo que consideren lo siguiente:

1 _{Un modelo de casos de uso (requerimientos).} 2 _{Un modelo de an ´alisis.}

(17)

El Proceso Unificado IV

Requerimientos

Se modelan los procesos del negocio utilizando los casos de uso de la empresa y su relaci ´on con los usuarios.

Debe existir una planificaci ´on que cumpla con las restricciones de costo y tiempo.

Se deben cubrir las necesidades y expectativas del cliente.

An ´alisis

Se identifican los actores del sistema y se desarrollan los propios casos de uso.

Descubrir el conjunto de objetos que proporcionan el comportamiento requerido por algunas funcionalidades del sistema.

(18)

El Proceso Unificado V

Dise ˜no

Se crea y documenta el dise ˜no del sistema mediante modelos arquitect ´onicos, de componentes, de objetos y de secuencias. Lo ideal es tener un sistema en forma de subsistemas, clases e interfaces.

Los casos de uso deben ser mapeados a diagramas de colaboraciones.

(19)

El Proceso Unificado VI

Implementaci ´on

Se proporciona al equipo de desarrollo las herramientas adecuadas para el producto a desarrollar.

Se implementan y estructuran los componentes del sistema. La generaci ón autom ática de c ódigo puede acelerar esta actividad. Se realiza el ensamblaje de los componentes, librer´ıas, datos y la compilaci ón para crear el ejecutable del sistema.

Pruebas

Son un proceso iterativo que va de la mano con la implementaci ´on.

(20)

(21)

El Proceso Unificado Fases del Proceso Unificado

Fases del Proceso Unificado I

Inicio

Consiste en modelar el problema del cliente/empresa.

Se deben identificar todas las entidades externas (personas y sistemas) que interactuar ´an con el sistema.

Se deben identificar los requisitos necesarios para resolver el problema.

Se valora la aportaci ´on del sistema al cliente/empresa. Se establece el alcance del proyecto y su costo. Se proponen arquitecturas para el sistema

(22)

Fases del Proceso Unificado II

Elaboraci ´on

Se desarrolla la comprensi ´on del problema.

Puede que se encuentren m ás requisitos y se redefina el alcance. Se establece un marco conceptual arquitect ónico del sistema. Se establecen los casos de uso UML, el dise ño arquitect ónico y la planificaci ón del proyecto.

(23)

Fases del Proceso Unificado III

Construcci ´on

Consiste en el dise ˜no, programaci ´on y pruebas del sistema. La arquitectura debe crecer hasta convertirse en un software estable.

El producto debe contener los casos de uso aprobados. No necesariamente el software est ´a libre de defectos.

Debe evaluarse si la versi ´on actual cubre las necesidades de los cliente como para liber ´arselas.

(24)

Fases del Proceso Unificado IV

Transici ´on

Consiste en liberar la versi ´on (beta) a los usuarios para que la usen en el entorno real.

Los desarrolladores corrigen los problemas e incorporan las sugerencias/mejoras proporcionadas por los usuarios que probaron el sistema.

Lo ideal es dividir los defectos seg ´un su impacto y agregarlos en la misma versi ´on o como parte de una nueva.

(25)

Fase de inicio I

De modo general, esta fase consiste en arrancar el proyecto.

Se realizar ´a el an ´alisis del negocio tal que se logre justificar la puesta en marcha del proyecto.

Se comprender ´an los procesos o actividades que ser ´an cubiertas por el nuevo software.

Se delimitar ´a el alcance del proyecto.

Se realizar á una primera aproximaci ón de la arquitectura que ser á el soporte del sistema.

(26)

Fase de inicio II

¿Compensar ´an las ganancias procedentes del uso o la venta del software, su costo de desarrollo?

¿Llegar ´a el producto al cliente o al mercado a tiempo de obtener tales ganancias?

Gran parte de la justificaci ´on del proyecto puede entenderse mejor si se considera para qui ´en va dirigido el sistema.

El mercado en general.

Otros departamentos de la misma empresa.

(27)

Fase de inicio III

1 _{Recabar toda la informaci ´on posible antes de que comience el} proyecto.

2 _{Organizar la informaci ´on de forma ´util}_.

3 _{Reunir a los especialistas que sepan analizar la informaci ´on}_. 4 _{Descubrir los objetivos que hacen falta para terminar con ´exito esta}

fase.

Es importante considerar los siguientes criterios de evaluaci ´on: 1 _{Decidir el entorno del sistema}_.

2 _{Resolver ambig ¨uedades en los requerimientos}_. 3 _{Determinar una arquitectura candidata}_.

4 _{Mitigar los riesgos cr´ıticos}_.

(28)

Fase de inicio IV

Decidir el entorno del sistema

¿Est ´a claro lo que va a formar parte del sistema? ¿Se han identificado todos los actores?

¿Se podr´ıa generar un sistema funcional con los elementos del entorno existente?

¿Queda claro el papel de los actores y su interacci ´on con el sistema?

Resolver ambig ¨uedades en los requerimientos

¿Se han identificado los requerimientos funcionales? ¿Se han identificado los requerimientos no funcionales?

(29)

Fase de inicio V

Mitigar los riesgos cr´ıticos

Un riesgo cr´ıtico es aquel que en caso de no eliminarse pone en riesgo al proyecto.

¿Se han identificado los riesgos cr´ıticos? ¿Existe alg ´un plan para eliminar los riesgos?

Juzgar el valor aportado al negocio

¿El sistema aporta un valor agregado al negocio? ¿Vale la pena desarrollar un nuevo sistema? ¿Qu ´e valor podr´ıa aportar otro software ya existente?

Tomando en cuenta los criterios de evaluaci ´on, es necesario ejecutar los flujos de trabajo fundamentales.

(30)

Fase de inicio VI

Esta fase es mas complicada cuando el producto a desarrollar es totalmente nuevo e innovador.

Cada iteraci ´on puede visualizarse como un peque ˜no ciclo de vida en cascada.

En esta fase los flujos de trabajo m ´as importantes son: 1 _{La recopilaci ´on de los requisitos.}

2 _{El an ´alisis.} El dise ˜no.

(31)

Fase de inicio VII

Recopilaci ´on de los requisitos

Enumerar los requisitos candidatos.

Comprender el contexto del sistema.

Representar los requisitos funcionales como casos de uso.

(32)

Fase de inicio VIII

An ´alisis

De la arquitectura.

El arquitecto debe construir una primera versi ón delmodelo de an álisisque ayudar á a visualizar las partes del sistema.

El primer modelo de an ´alisis puede ser la base de las siguientes versiones o s ´olo una gu´ıa.

De casos de uso.

Se deben identificar los casos de uso que comparten recursos. El modelo de an ´alisis permita visualizar tales recursos.

(33)

Fase de inicio IX

Dise ˜no

Realizar un modelo de dise ˜no que contemple los casos de uso como colaboraciones entre subsistemas o clases.

Se deben definir las interfaces.

(34)

Fase de inicio X

Implementaci ´on

Dilema

Arquitectura→Prototipo Prototipo→Arquitectura

Lo ideal es al menos desarrollar una arquitectura candidata.

(35)

Fase de elaboraci ´on I

Al inicio de esta fase se tiene un modelo de casos de uso casi completo y una descripci ´on de la arquitectura candidata.

Tambi én pueden existir las primeras aproximaciones de un modelo de an álisis y el de dise ño.

Se deben recopilar los requisitos que a ´un queden pendientes y formularse como casos de uso.

Establecer una arquitectura s ´olida del sistema.

(36)

Fase de elaboraci ´on II

Al finalizar esta fase, lo ideal es contar con aproximadamente el 80%de los casos de uso bien definidos.

En esta fase se realiza un mejor an ´alisis del negocio.

Se desarrollan los fundamentos s ´olidos para avanzar a la fase de construcci ´on.

La planificaci ´on de esta fase contempla tres puntos importantes: 1 _{Formaci ´on del equipo de trabajo.}

(37)

Fase de elaboraci ´on III

Formaci ´on del equipo de trabajo

Si hay necesidades especiales, integrar al equipo al personal capacitado para esas funciones.

Las personas que se incorporen a partir de esta fase, se ver ´an involucradas cuando menos hasta la siguiente fase.

Modificaci ´on del entorno de desarrollo

Conforme se descubren los nuevos requisitos el entorno de desarrollo puede sufrir cambios.

(38)

Fase de elaboraci ´on IV

Establecimiento de los criterios de evaluaci ´on Ampliar los requisitos.

¿Est án identificados todos los requisitos, actores y casos de uso que permitan el correcto dise ño de la arquitectura b ásica? ¿Se encuentran bien detallados los requisitos y los casos de uso?

Definir la arquitectura b ´asica.

¿La arquitectura satisface las necesidades de todos los usuarios? ¿La arquitectura permitir ´a posibles adecuaciones?

Juzgar la validez del an ´alisis del negocio.

(39)

Fase de elaboraci ´on V

Si el proyecto es grande, puede llevar bastante tiempo reunir al equipo de trabajo.

Mientras se conforma el equipo de trabajo lo ideal es proponer y ensayar soluciones.

El desarrollo de cada nueva arquitectura propuesta es en realidad una iteraci ´on incremental de esta fase.

(40)

Fase de elaboraci ´on VI

Recopilaci ´on de los requisitos

Encontrar casos de uso y actores.

Desarrollar prototipos de las interfaces de usuario.

Determinar la prioridad de los casos de uso.

(41)

Fase de elaboraci ´on VII

An ´alisis I

Generar el modelo b ´asico de la arquitectura.

Se desarrollan los siguientes diagramas estructurales:

1 _{Diagrama de clases.}

2 _{Diagrama de paquetes.}

3 _{Diagrama de componentes.}

Se refinan los casos de uso de mayor prioridad.

Tambi ´en se refinan los casos de uso que den soporte a los casos de uso prioritarios.

Cada caso de uso se queda especificado en funci ´on de las clases que lo soportan.

(42)

Fase de elaboraci ´on VIII

An ´alisis II De clases.

Se refinan las clases derivadas de los an ´alisis anteriores. Deben quedar detallados los m ´etodos y atributos esenciales de cada clase.

De paquetes.

El arquitecto determinar ´a el agrupamiento de las clases como paquetes de servicio.

(43)

Fase de elaboraci ´on IX

Dise ˜no I

Identificar el tipo de arquitectura a desarrollar. Ej en capas. Identificar los subsistemas y sus interfaces.

Identificar las clases de dise ˜no de la arquitectura.

Identificar los nodos y las configuraciones de red (s ´olo si aplica).

Plantear los casos de uso (s ´olo los analizados) en t ´erminos de subsistemas.

Se especifican las operaciones utilizadas para la comunicaci ´on. Se empieza a echar un vistazo acerca de que subsistemas, marcos de trabajo o componentes es posible reutilizar.

(44)

Fase de elaboraci ´on X

Dise ˜no II De clases.

No necesariamente quedar ´an completas las clases.

Las operaciones deben encontrarse en clases consistentes.

De subsistemas.

Se dise ˜nan los subsistemas derivados del dise ˜no de la arquitectura.

(45)

Fase de elaboraci ´on XI

Implementaci ´on

Generalmente se implementan menos de la mitad de los casos de uso.

De las clases.

De los subsistemas.

De la arquitectura.

(46)

Fase de elaboraci ´on XII

Pruebas

El objetivo es asegurar que el sistema funcione a todos los niveles.

Lo ideal es probar por capas.

Las pruebas permiten visualizar la escalabilidad del sistema. Se consideran cuatro pasos para realizar este proceso:

1 _{Planificar las pruebas}_. 2 _{Dise ˜}_{nar las pruebas}_.

(47)

Fase de construcci ´on I

El objetivo de esta fase es crear un producto de software que sea operable.

Se deber ´an detallar los casos de uso faltantes.

Se implementar ´an el 90 % de los caos de uso.

Con ayuda de la representaci ón de la arquitectura como subsistemas e interfaces se lograr á una mejor distribuci ón del trabajo.

El jefe de proyecto asignar ´a un subsistema a cada desarrollador, quien es com ´unmente llamado ingeniero de componentes.

(48)

Fase de construcci ´on II

Otros de los involucrados en esta fase son: Analista de sistemas.

El ingeniero de pruebas.

El responsable de la integraci ´on del sistema. El encargado de las pruebas de integraci ´on. El encargado de las pruebas del sistema.

La labor del arquitecto de software es menor en esta parte.

Tambi ´en se comienza a preparar cierto material de evaluaci ´on, como:

(49)

Fase de construcci ´on III

Recopilaci ´on de los requisitos faltantes

El objetivo es tener identificados y detallados el 100 % de los requisitos al final de esta fase.

Encontrar actores y caso de uso faltantes.

Se desarrollan los prototipos para la interfaz de usuario. Si la interfaz de usuario es muy complicada, esta

evolucionar ´a conforme el usuario proporcione sus observaciones. Una vez creados los nuevos casos de uso se reorganizan sus prioridades y se desarrollan nuevamente seg ´un su orden. Se detallan todos los casos de uso.

No se recomiendan cambios grandes en el modelo de casos de uso pues pueden impactar negativamente en la arquitectura.

(50)

Fase de construcci ´on IV

An ´alisis I

Dado que el modelo de an álisis ser á m ás detallado, la arquitectura puede requerir ciertos cambios menores.

Se afinan los siguientes diagramas estructurales:

1 _{Diagrama de clases.}

2 Diagrama de paquetes.

(51)

Fase de construcci ´on V

An ´alisis II De clases.

Se analizan las clases faltantes y las que hayan aparecido debido a los nuevos casos de uso.

De paquetes.

Se refinan los paquetes involucrados.

La nuevas clases son clasificadas donde les corresponda.

De componentes.

El trabajo es menor, pocas veces se requiere crear componentes adicionales en este punto.

(52)

Fase de construcci ´on VI

Dise ˜no I

Se consideran los siguientes elementos de dise ˜no.

Modelo de dise ˜no.

Se describe el detalle, a trav ´es de modelos de objetos, de la realizaci ´on de los casos de uso faltantes.

Elaboraci ´on de clases de dise ˜no.

Se deben especificar las clases en el lenguaje de programaci ón. Tambi én para las operaciones, par ámetros, atributos y tipos.

De diagramas de clases.

(53)

Fase de construcci ´on VII

Dise ˜no II

De diagramas de interacci ´on.

Se lleva a cabo gracias a los diagramas de secuencia.

Los diagramas de secuencia permiten entender la interacci ´on que habr ´a con el sistema.

Cuando un subsistemarecibeun mensaje, es en realidad un objeto de una clase del subsistema el que recibe tal mensaje.

Lo mismo para cuando un subsistemaenv´ıaun mensaje.

De Interfaces.

Puede ser que la mayor´ıa se encuentren definidas, pero hay que especificarlas todas.

Del modelo de despliegue.

(54)

Fase de construcci ´on VIII

Implementaci ´on

La arquitectura ya debe contar con bases s ólidas. S ólo se realiza trabajo de actualizaci ón.

De las clases y de los subsistemas.

Los ingenieros de componentes llevan a cabo esta labor.

De pruebas de unidad.

Tambi én son realizadas por los ingenieros de componentes. Si es necesario se corregir á el dise ño y la implementaci ón.

(55)

Fase de construcci ´on IX

Pruebas I

Planificaci ´on de las pruebas.

Se seleccionan los objetivos que verifiquen el funcionamiento de las construcciones realizadas.

Dise ˜no de pruebas.

Se preparan los casos y procedimientos que verifiquen los requisitos.

Se preparan las pruebas individuales y en conjunto de los componentes.

Pruebas de integraci ´on.

El encargado de integraci ´on determinar ´a si son necesarias pruebas adicionales.

(56)

Fase de construcci ´on X

Pruebas II

Pruebas del sistema.

En ocasiones hay un encargado de las pruebas del sistema. El encargado de las pruebas del sistema debe comprobar la operativa de todo el sistema.

Evaluaci ´on de pruebas.

Los resultados obtenidos de las pruebas deben ser comparados contra los objetivos inicialmente planteados.

(57)

Fase de construcci ´on XI

Prueba de desarrollo

Es un proceso realizado por los programadores. Cada componente se prueba de forma independiente. Existen herramientas que automatizan este proceso o bien pueden ser creadas las propias.

JUnit in Action, Petar Tahchiev, Felipe Leme, Vincent Massol and Gary Gregory, 2nd Ed. 2010.

(58)

Fase de construcci ´on XII

Prueba de desarrollo

JUnit es un marco de trabajo dise ˜nado para automatizar la generaci ´on de casos de prueba. JUint es una instancia de la arquitectura xUnit, que fue creada para realizar pruebas de unidad.

http://junit.org/

Pruebas del sistema

El objetivo es descubrir errores de las interacciones entre los componentes.

(59)

Fase de transici ´on I

El principal objetivo de esta fase es que al final el sistema cumpla con los requisitos establecidos y todos los usuarios est ´en

satisfechos con el software.

Realizar las correcciones necesarias a la versi ´on beta del sistema.

Cuando se trata de un producto que saldr ´a al mercado general, las versiones beta suelen distribuirse a los posibles compradores de ciertas organizaciones.

Cuando es para un cliente en espec´ıfico simplemente se instala el producto en algunas de sus computadoras.

(60)

Fase de transici ´on II

(61)

Fase de transici ´on III

Esta fase es dif´ıcil de planificar pues la cantidad de trabajo depender ´a de la retroalimentaci ´on del cliente.

Lo ideal es tener a cierto personal atento a las recomendaciones o fallas reportadas por los usuarios del sistema.

El perfil del personal para esta fase est ´a orientado al servicio.

Incluso las mejoras mas peque ˜nas pueden requerir de expertos que las detecten.

(62)

Fase de transici ´on IV

Establecimiento de los criterios de evaluaci ´on Verificaci ´on de los requisitos.

¿Los usuarios han probado las funciones clave del sistema?

Pruebas de aceptaci ´on.

¿El producto ha superado las pruebas de aceptaci ´on realizadas por los usuarios?

Material para los usuarios y los cursos.

¿Tiene el material de usuario una calidad aceptable? ¿Est ´a listo el material para impartir los cursos referentes al

(63)

Fase de transici ´on V

An ´alisis

El an ´alisis esta enfocado en modificar las clases, y quiz ´as los componentes, en los que se hayan encontrado fallas.

Una menor parte del tiempo ser á dedicada al an álisis de los casos de uso que hayan quedado pendientes en la fase de construcci ón.

Dise ˜no

Puede ser necesario redise ˜nar algunas clases.

Generalmente s ólo se redise ñan aquellas clases que llagasen a fallar constantemente y a afectar a uno o m ás componentes.

(64)

Fase de transici ´on VI

Implementaci ´on

Se corrigen los errores encontrados por los usuarios. Se agregan las mejoras sugeridas.

Se implementan las clases redise ˜nadas.

Pruebas

Se realizan las pruebas de integraci ´on que est ´en pendientes. Se realizan las pruebas de sistema pendientes.

(65)

Fase de transici ´on VII

Pruebas de aceptaci ´on

El sistema se pone a prueba con datos reales.

Los datos reales suelen revelar problemas no detectados con los datos ficticios.

Permiten observar el rendimiento global del sistema.

¿Cu ´ando acaba el proyecto?

Cuando los usuarios est ´an satisfechos.

¿Cu ´ando los usuarios est ´an satisfechos?

(66)

El Proceso Unificado Buenas pr ´acticas del Proceso Unificado

Buenas pr ´acticas del Proceso Unificado I

Desarrollo de software de manera interactiva

Realizar el desarrollo en base a las prioridades del cliente.

Gesti ´on de requerimientos

Documentar expl´ıcitamente los requerimientos y realizar los cambios necesarios sobre estos. Evaluar el impacto de cambios en el sistema antes de aceptarlos.

(67)

El Proceso Unificado Buenas pr ´acticas del Proceso Unificado

Buenas pr ´acticas del Proceso Unificado II

Software modelado visualmente

Utilizar modelos UML para refresentar procesos en la fases y actividades de ingenier´ıa del Proceso Unificado.

Verificar la calidad del software

Asegurar que el software cumple con los est ´andares de calidad establecidos en la empresa.

Controlar los cambios al software

Gestionar los cambios mediante un controlador de versiones. Adem ´as se deben documentar los procedimientos y todo lo necesario para la configuraci ´on del sistema.

(68)

Comercializaci ´on de software

Comercializaci ´on de software I

Lacomercializaci ´on de softwarees parte de un proceso mas grande llamado industria del software y consiste en la venta de un producto de software.

Laindustria del softwarese encarga de la investigaci ón, desarrollo, distribuci ón y comercializaci ón de software.

Los gastos iniciales de desarrollo, marketing e infraestructura de soporte t ´ecnico para las versiones iniciales son altos.

(69)

Comercializaci ´on de software II

Para la parte de distribuci ´on, algunas empresas de desarrollo de software se ayudan de empresas distribuidoras de software. Unadistribuidora de softwarees una empresa intermediaria entre las empresas de desarrollo de software y los posibles

compradores.

La distribuidora es quien decide el modo de distribuci ´on. En ocasiones las distribuidoras realizan la investigaci ´on pertinente con la finalidad de ofrecer nuevos productos.

Tambi ´en se suelen encargar de vender las licencias de software bajo limitaciones temporales y geogr ´aficas, y retribuirle regal´ıas a la desarrolladora.

(70)

Comercializaci ´on de software III

Principales funciones de la distribuidoras de software

Contactar a otras empresas que hagan llegar el software a los posibles clientes.

Dar a conocer el producto de software mediante anuncios y eventos.

Dise ˜nar y producir el empaque en el caso de distribuci ´on f´ısica.

Regresando al tema de comercializaci ´on, existen dos formas de comercializar software:

(71)

Comercializaci ´on de software IV

Para un mercado general

El mercado es diversificado.

Existen diferentes variantes del sistema considerando: el pa´ıs, el idioma, la moneda y algunas otras unidades de medida.

Generalmente son instalados por el usuario o por el administrador de sistemas de la empresa.

El producto viene con una aplicaci ´on que gu´ıa a los usuarios en la instalaci ´on.

Generalmente se brinda asistencia telef ´onica de ser necesario. El proceso de instalaci ´on no debe variar mucho de un sistema operativo a otro.

(72)

Comercializaci ´on de software V

Para un cliente en espec´ıfico

El mercado es conocido.

Existen diferentes variantes del sistema considerando las necesidades del cliente.

Pueden ser instalados por los usuarios, pero tambi ´en por el equipo de distribuci ´on de la empresa de software.

El producto tambi én debe venir con una aplicaci ón que de soporte en el proceso de instalaci ón.