[Type text]

Proceso de Desarrollo de Software

[Type text]

Revisión Histórica

Fecha Versión Descripción Autor12/12/2006 1.0 Generación del documento Fabiola Moreno

[Type text]

Tabla de Contenidos1 INTRODUCCIÓN............................................................................................42 OBJETIVO.....................................................................................................4

2.1 OBJETIVOS ESPECÍFICOS:.................................................................................................43 METODOLOGÍA.............................................................................................4

3.1 DESCRIPCIÓN DE FASES..................................................................................................53.1.1 Inicio..................................................................................................................53.1.2 Elaboración........................................................................................................63.1.3 Construcción.....................................................................................................63.1.4 Transición..........................................................................................................6

4 DEFINICIÓN DEL CICLO DE DESARROLLO DE SOFTWARE..................................74.1 MODELAMIENTO DE NEGOCIO..........................................................................................74.2 REQUERIMIENTOS..........................................................................................................74.3 ANÁLISIS......................................................................................................................94.4 DISEÑO.......................................................................................................................94.5 IMPLEMENTACIÓN.........................................................................................................104.6 PRUEBAS...................................................................................................................104.7 DESPLIEGUE...............................................................................................................124.8 DISCIPLINAS DE APOYO AL PROCESO................................................................................12

4.8.1 Administración de la Configuración.................................................................124.8.2 Administración de Proyectos...........................................................................124.8.3 Ambiente.........................................................................................................13

[Type text]

1 IntroducciónEl uso de procesos de desarrollo de software, son parte fundamental a la hora de desarrollar proyectos de software, ya que nos ayudan a cumplir con los tres objetivos principales que persigue cualquier empresa dedicada al desarrollo de software los cuales son: alta calidad, bajo costo y en el menor tiempo. Cumplir con estos objetivos no es tarea fácil, debido a que depende del nivel de madurez de la empresa y del nivel de conocimiento de sus integrantes.

La construcción e implantación de un proceso de desarrollo de Software en las pequeñas compañías desarrolladoras no es algo común, porque el enfoque normalmente está en el desarrollo por la asistencia inmediata del problema del cliente. A los requisitos están asociados los problemas principales del desarrollo del software. [BLASCHEK 2002], siendo así, la administración de los requisitos y de los cambios a lo largo del proyecto se vuelve un proceso bastante costoso, dado que no hay documentación formal estandardizado de las necesidades del cliente.

Software Inc. no se encuentra ajena a este tipo de problemas debido a la falta de documentación formal y estandarizada de requerimientos, esto afecta el proceso de mantenimiento adaptativo o evolutivo del Software, impidiendo la identificación de los impactos del cambio de algún requerimiento en el desarrollo del sistema, aumentando la ocurrencia de errores y por consiguiente la insatisfacción del usuario final.

2 ObjetivoEl objetivo de este documento es la definición e implementación del proceso de desarrollo de software realizadas por Software Inc. y la definición de los artefactos necesarios para la documentación del trabajo realizado.

2.1 Objetivos específicos:

a) Definición de metodología a utilizar (Desarrollos Nuevos).b) Determinación de roles y responsabilidad a utilizar en un proyecto.c) Definición de actividades y artefactos por cada una de ellas.

3 Metodología La metodología que a continuación se describe está basada bajo el concepto de desarrollo de software UP (Proceso Unificado). La definición de cada una de las fases mostrará las actividades que se llevan a cabo y los artefactos que deberán ser construidos en cada una de estas, los cuales servirán para que la siguiente fase pueda llevarse a cabo. El proceso Unificado es un método iterativo de diseño de software que describe como desarrollar software de mejor forma, utilizando técnicas utilizadas en la industria de software, es uno de los más utilizados en proyectos de software orientado a objeto. UP es una base de procesos que debe ser adaptado a los proyectos que se van a realizar y a la realidad de la empresa.A continuación se muestra una figura que representa la estructura de cómo esta organizado el proceso unificado.

[Type text]

Figura 1. Fases (eje horizontal) y disciplinas (eje vertical) de UP.

3.1 Descripción de Fases

3.1.1 Inicio

El propósito de esta fase es el de cerrar el alcance del software a construir; estimar costos, riesgos y cronograma; identificar los requerimientos del mismo; y preparar el ambiente del proyecto.

Los artefactos principales de esta fase son el Plan de Proyecto; Modelamiento de procesos de negocio; el Documento de Visión, Lista de Requerimientos; la Lista de Riesgos.

La fase de inicio es una de las fases claves del proyecto ya que garantiza la factibilidad del proyecto. En general tiene una sola iteración que permite asegurar que se logro el detalle suficiente y la calidad en los artefactos mencionados para garantizar la factibilidad. Si el proyecto fuera de gran tamaño puede llegar a tener dos o más iteraciones.

3.1.2 Elaboración

La fase de Elaboración tiene como propósito la realización de los artefactos construidos en la fase de Inicio. El foco esta en el diseño de los casos de uso, y en la definición de la

[Type text]

arquitectura del proyecto. En la misma se refina la estimación de esfuerzo obtenida en la fase anterior, de acuerdo al detalle del diseño que se va armando.

Al fin de esta fase se deberá tener estabilizado en un 80% el diseño de los casos de uso, y la arquitectura deberá estar validada mediante un prototipo que garantice que la misma funciona con relación a los requerimientos no funcionales relevados en la fase de Inicio. También se debe garantizar la estabilidad de las Especificaciones de CUS para entrar a la Construcción.

Durante la mitad de la Elaboración se realizará una revisión tendiente a validar el diseño Es clave que las especificaciones que se hagan sean correctas y que estén validadas por el Cliente para poder llevar a cabo la Construcción sin sobresaltos.

Los artefactos que deben estar completados para esta fase son los siguientes: el Modelo de CUS; las Especificaciones de CUS; los Diagramas Dinámicos de Diseño; Casos de Prueba.

El objetivo principal es poder llevar a cabo la construcción sin riesgos funcionales ni técnicos de ningún tipo.

3.1.3 Construcción

En esta fase se realiza la implementación y el testing de los componentes definidos durante la Elaboración. A esta altura deben estar terminadas aquellas actividades de modelado del negocio, análisis, diseño.

Se debe finalizar la fase con una versión beta de los componentes en los cuales se ha estabilizado el alcance. A partir de esta fase las tareas estarán concentradas en las pruebas aplicadas a los sistemas, se realizarán pruebas unitarias, funcionales y de integración. Las pruebas unitarias serán realizadas por los integrantes de Software Inc., y las pruebas funcionales y de integración serán realizadas en conjunto con el usuario final.

Los artefactos que se deben cerrar son los componentes de la aplicación; el Modelo de Datos; los Manuales de usuario.

3.1.4 Transición

En esta fase se lleva a cabo la entrega de versiones para ser instaladas en un ambiente productivo. En particular el énfasis está en la disciplina de despliegue en la que se lleva a cabo la preparación del empaquetado de deploy, la migración de datos, la capacitación al usuario, y la entrega formal del producto.

Es también importante llevar a cabo el Post Mortem del proyecto, en el cual se relevan aquellos aspectos negativos y positivos del proyecto, haciendo hincapié en las cosas a mejorar a futuro.

La fase de Transición finaliza cuando existe una aprobación formal de entrega por todos los involucrados.

[Type text]

4 Definición del ciclo de desarrollo de software La definición del ciclo de desarrollo estará definido sobre la base de actividades y artefactos para cada disciplina (se llamará disciplina a: Modelamiento de Negocio, Requerimientos, Análisis, Diseño, Construcción y Pruebas) este ciclo es ejecutado iterativamente a través de las fases definidas en el punto anterior.

4.1 Modelamiento de Negocio

El objetivo de esta disciplina es entender y modelar el proceso de negocio para el cual se pretende construir un sistema que apoye las distintas actividades que realizan los usuarios involucrados. Además con el modelamiento de negocio se pretende conocer y entender la estructura y dinámica de la organización en la cual el sistema será implementado.

El modelamiento de negocio quedará plasmado mediante un modelo de casos de uso de negocio realizados con UML y utilizando la herramienta EA. En esta disciplina tendrá una fuerte participación del usuario, ya que será quien defina y valide las actividades que se realizan en el negocio.

Los pasos a seguir para modelar el negocio serán:1.- Identificación de la cadena de valor del proceso. 2.- Identificación de objetivo(s) del proceso a modelar.3.- Identificación de todos lo actores involucrados.4.- Identificación de input y output en cada una de las funciones que se realizan al interior del proceso. 5.- Modelamiento basado en Casos de Uso.

4.2 Requerimientos

El objetivo de esta disciplina es establecer acuerdos claros entre los involucrados del proyecto, acerca de lo que se quiere y lo que el sistema debería realizar basado en el marco funcional y del alcance definido en la disciplina de modelamiento de negocio. Se deberá especificar y validar los requerimientos funcionales, no funcionales y sus alcances, los que quedaran plasmados en el artefacto llamado “Documento Visión”. El objetivo del documento visión es establecer como un contrato de lo que el sistema hará y lo que no hará al ser implementado.

Existen distintos tipos de requerimientos que deben ser extraídos en reuniones con los usuarios, a continuación se presenta un cuadro con el detalle de éstos:

Tipo DescripciónFuncional Requerimiento asociado con la funcionalidad que debe proveer el

sistema para cubrir las necesidades de negocio.No Funcional Son cualidades sistémicas, anexas a las funcionalidades que debe

resolver el sistema. Algunos de estos requerimientos son:Disponibilidad es una medida del up time planificado al cual el sistema está disponible para su uso y operación. Un ejemplo de requerimiento de disponibilidad: El sistema debe estar al menos un 95 % disponible en días de semana entre las 09:00 y 14:00 hrs.Eficiencia es una medida de cuan bien el sistema utiliza la

[Type text]

capacidad de procesador, espacio en disco, memoria, o ancho de banda. Un ejemplo de requerimiento de Eficiencia: Se requiere 15 GB de espacio en disco para cargar los archivos enviados por los bancos.Seguridad, esta relacionada con el bloqueo de acceso no autorizado a las funciones del sistema, prevención de pérdida de información, y proteger la privacidad y seguridad de los datos ingresados al sistema. Un ejemplo de requerimiento de Seguridad: Solo los usuarios identificados con rol de administrador podrán modificar información.Auditoria, indica que información debe ser auditada cuando se produzcan cambios en ella. Un ejemplo de requerimiento de auditoria es: Se debe registrar información asociada a los Cierre de Caja (fecha, nombre trabajador y rut trabajador) cada vez que un usuario realice un cierre.Requerimientos de Performance y Volumen: Definen cuan bien o rápido el sistema debe llevar a cabo sus funciones. Los requerimientos de performance cubren velocidad (respuesta de la BD, por ejemplo), throughput (transacciones por segundo), capacidad (cargas de uso concurrente y volúmenes asociados), y tiempos (demandas en tiempo real). Algunos ejemplos de requerimientos de performances: (a) La autorización para extracción de dinero de un cajero automático no debe tomar más de 10 segundos. (b) Existen 100 usuarios concurrentes que hacen modificaciones sobre la información los últimos 5 días hábiles de cada mes. (c) Se estiman 2.000 matriculados los 10 primeros días de cada Noviembre.Exactitud, tiene que ver con la precisión que se requiere para los cálculos. Ejemplo de requerimiento de exactitud: (a) Se requiere que el cálculo de los cierres sea realizado con una aproximación de dos decimales. (b) Para todos los cálculos en UF se debe considerar una precisión de 5 decimales.Interoperabilidad indica cuan fácilmente el sistema puede intercambiar datos o servicios con otros sistemas o entidades externas. Para relevar este requerimiento se debe saber que otras aplicaciones o sistemas externos los usuarios usarán en conjunto con la aplicación, y que es lo que esperan intercambiar con estas.Un ejemplo de este requerimiento no funcional: (a) El sistema deberá poder importar archivos del banco que contengan los informes Pagos necesarios para la Cuadratura. La estructura de los mismos será de …...... Los volúmenes manejados son 3000 pagos y la periodicidad será mensual ........

Integración Con este requerimiento se pretende clarificar y especificar con que otras entidades se tendrán que comunicar un proyecto en desarrollo y la forma en que lo hará.

4.3 Análisis

El objetivo de la disciplina de análisis es transformar los requerimientos descritos en la etapa anterior en una solución sistémica. La representación de los requerimientos será utilizando el concepto de Casos de Uso el cual tiene como finalidad representar las funcionalidades sistémicas tal como son percibidas por los usuarios.Los casos de uso deberán ser conocidos y entendidos por todos los integrantes del equipo de proyecto, siendo el usuario parte de este equipo.

[Type text]

De esta forma mediante los casos de uso se podrá representar la interacción entre los actores y su entorno, entendiéndose como actores a todos los diferentes roles que desempeñan los usuarios del sistema.

Algunos de los conceptos básicos de esta disciplina son:Caso de uso: modela el diálogo entre un actor y un sistema. Se entiende como una secuencia de acciones realizadas por el sistema, que proporciona un resultado observable de valor para un usuario en particular; describiendo la funcionalidad como un todo, e incluyendo alternativas posibles, errores y excepciones que puedan ocurrir a lo largo de la ejecución del caso de uso.Actor: algo o alguien fuera del sistema, que interactúa con el sistema. Los actores ayudan a definir los límites del sistema.

Para documentar esta etapa del proyecto se utilizará el documento de “Especificación de Casos de Uso” y diagramas dinámicos y estáticos documentados en la herramienta EA, tales como diagramas de colaboración, diagrama de estado, diagramas de actividades, los cuales se utilizaran dependiendo del proyecto y problemática que se intente solucionar y el grado de claridad que se consiga utilizando estos diagramas.

4.4 Diseño

El objetivo de esta disciplina es tomar los artefactos de análisis e incorporar todos los aspectos tecnológicos necesarios para la construcción de las piezas de sw, además de incorporar aspectos de la arquitectura definida en las especificaciones de la solución establecida. Dentro de la metodología a implementar se propone que las personas que ejecuten este rol están involucradas de forma temprana en el proyecto. Dentro de las tareas que se deberán realizar en esta disciplina son:

a) Validación de Requerimientos: Esto implica una revisión de los requerimientos para validar factibilidad de diseño e implementación de los mismos. Revisión de los requerimientos para que no sean levantados en forma ambigua.

b) Realización de prototipo para mitigar riesgos: Esto significa analizar los requerimientos no funcionales de tal manera de de identificar aquellos mas críticos, detectar aquellos requerimientos que no sean soportados por la arquitectura definida. El objetivo del prototipo es implementar alguna funcionalidad que permita validar la factibilidad del requerimiento.

c) Generación de modelo de clases de diseño con sus correspondientes diagramas de estados en aquellos casos que sea necesario (Solo deben generarse estos diagramas para clases que tienen estados claramente identificables y estén tengan un comportamiento complejo).

d) Generación de diagramas de Secuencias o Colaboración para los CUS críticos.

4.5 Implementación

Esta disciplina tiene como objetivos fundamentales:a) Tomar los artefactos de análisis y diseño y llevar a cabo la construcción de los

mismos en la plataforma tecnológicab) Generar el código fuente necesario para la ejecución de los casos de uso del sistema.c) Generar las pruebas unitarias necesarias para garantizar el correcto funcionamiento

de las unidades elementales de implementación.Las actividades a desarrollar por los implementadotes o constructores, serán:

[Type text]

a) Lectura y comprensión de los artefactos desarrollados en las disciplinas anteriores.b) Construcción del código fuentec) Ejecución de un conjunto de pruebas unitarias para verificar que el código responde a

su funcionalidad.

4.6 Pruebas

El objetivo de esta disciplina será las pruebas de software con respecto a las definiciones establecida en las etapas anteriores, esto significa que las piezas de software responda a las especificaciones de requerimientos establecidos como línea base para la construcción de la aplicación.Existen distintos conceptos que deben ser considerados al momento de hacer pruebas sobre el software tales como:

ConfiabilidadSe refiere a la fiabilidad en el funcionamiento del producto. El producto es capaz de funcionar sin errores en cualquier circunstancia y siempre de acuerdo a las especificaciones definidas.

SeguridadConsidera si el producto de software, de acuerdo a las especificaciones definidas, contempla todos los aspectos de seguridad necesarios para garantizar el control de acceso y manejo de datos en el sistema.

UsabilidadSe relaciona con la cantidad de esfuerzo requerido para aprender a utilizar o manejar el producto. La pieza de software debe responder a los estándares de usabilidad definidos para el proyecto.

Integridad entre componentesSe refiere a la correcta operación de la pieza de software en conjunto con otros componentes o módulos. La pieza de software debe procurar integridad dentro del sistema como también con sistemas externos, según corresponda.

VerificabilidadSe refiere a que la pieza de software debe ser verificable de acuerdo a las especificaciones definidas.

PrecisiónSe refiere a que la pieza de software debe proporcionan el grado de certeza requerido en los cálculos que contempla, de acuerdo a las especificaciones definidas.

MantenimientoSe relaciona con la capacidad de localizar y corregir defectos una vez que el producto esta funcionando.

Se entenderá como defecto o error a la desviación de la implementación del software respecto a la definición de requerimientos.Los defectos detectados en el proceso de pruebas de software, podrán ser catalogados en cuatro niveles de severidad, cuya clasificación dependerá del grado de desviación que la pieza de software presenta respecto de las especificaciones de requerimientos.

[Type text]

a) Crítico: Corresponde al defecto que impide acceder a la funcionalidad. Las pruebas de la pieza de software deben suspenderse o el defecto no permite continuar la operación del sistema.

b) Grave: En esta categoría es posible acceder a la funcionalidad, pero la misma no puede ser ejecutada en forma completa. La ejecución de la prueba no cumple con el resultado esperado. Existe una severa desviación respecto a los requerimientos. El defecto restringe la ejecución de gran parte de la funcionalidad definida. No existe un camino alternativo de solución.

c) Mediano: Es posible acceder a la funcionalidad, ésta no se ejecuta completamente o no cumple con el resultado esperado, pero existe un camino alternativo para cumplir la funcionalidad.

d) Menor: El defecto no afecta el correcto funcionamiento de la aplicación. No es crítico para el desempeño del usuario ni afecta la información del sistema.

La disciplina de pruebas dentro del desarrollo de software para Software Inc. será una mas de las actividades enmarcadas dentro de lo que se conoce por Aseguramiento de Calidad, que en este caso estará realizada por el líder de proyecto el cual se encargara de realizar revisiones periódicas orientadas a la forma de trabajar o sea al proceso de desarrollo, y de esta forma detectar posibles fallas o mejoras que nos permitan una mejora continua en el como se desarrollan los proyectos nuevos.

4.7 Despliegue

En esta fase del proyecto se realizan las actividades de entrega de las piezas de software y los artefactos asociados a la puesta en producción tales como:Guía de Usuario, donde se explica como la aplicación debe ser utilizada por los usuarios finales.Guía de Operaciones, explica como la aplicación debe ser mantenida durante la fase de Producción. La misma está orientada al Equipo del departamento de informática de la UCINF.Material de Capacitación, es todo el material necesario para dar la capacitación al usuario.Nota de Entrega, contiene los datos asociados a una entrega de artefactos o componentes de una aplicación desde el equipo de Software Inc. hacia Departamento de Informática.

4.8 Disciplinas de apoyo al proceso

Existen otras disciplinas orientadas a dar soporte o apoyo a las disciplinas descritas anteriormente estas son:

Administración de la ConfiguraciónAdministración de ProyectosAmbiente

4.8.1 Administración de la Configuración

El objetivo de esta disciplina es identificar los ítems a configurar, controlar los cambios a los ítems de configuración durante el ciclo de vida del proyecto registrando los cambios y los distintos estados de la configuración; verifica el cumplimiento de los requerimientos, describe la forma de generar las versiones; cómo se identificarán los releases, los distintos ambiente y los reportes a elaborar. Para la administración de la configuración se definirá un

[Type text]

plan de administración de la configuración donde se detallará los ítems a controlar y herramientas de control de versiones a utilizar. (Pendiente)

4.8.2 Administración de Proyectos

El objetivo de esta disciplina es el proveer un marco de trabajo para administrar proyectos de software, guías prácticas para planificación, ejecución y monitoreo de proyectos, y además el proveer practicas para el seguimiento de proyectos y administración de requerimientos. Se definirá Plan de Administración de Proyectos. (Pendiente)

4.8.3 Ambiente

Corresponde a la definición de todo el ambiente de trabajo, herramientas, ciclos de vida, etc. Todas las definiciones que se realizan al iniciar el proyecto y deben ser conocidas por todo el equipo de trabajo.