WIXLIB

de técnicas eficientes y seguras tales como introspección, entrevistas de cuestionarios,entrevistas de final abierto y discusiones, etc.3.1.1.2 Análisis y Negociación de Requerimientos: En el análisis de requerimientosse descubre problemas en la captura de requerimientos, se evalúa la necesidad detodos los requisitos, se analiza su consistencia y completitud, se asegura la viabilidaden cuanto a la parte técnica, de costes, y planificación. Seguidamente se pasa a lanegociación de requerimientos donde se discute las inconsistencias, limitaciones,carencias encontradas y finalmente llegar a un mutuo acuerdo que satisfaga a todoslos usuarios para así poder realizar la priorización de requerimientos.3.1.1.3 Especificación de Requerimientos: Es el proceso por medio del cual sedescribe a manera de borrador los requerimientos ya que está sujeto a modificaciones.3.1.1.4 Validación de Requerimientos: La validación la realiza un equipo integral quepuede estar conformado por ingeniero de requerimientos, desarrollador, cliente yusuarios con el fin de detectar y corregir errores, ambigüedades u omisiones paragarantizar la consistencia y precisión de los requerimientos. También se evalúa quelos requerimientos acordados son los que realmente definen el sistema que el clientenecesita y quiere ver como producto final.3.1.1.5 Documentación de Requerimientos: Se realiza la documentación oficial decada uno de los requerimientos acordados, de forma clara, detallada y verificable.3.1.2 FASE DE DISEÑOEl diseño de un sistema de información produce los elementos que establecen cómoel sistema cumplirá los requerimientos identificados durante la fase de análisis. A estafase se le conoce también con el nombre de Diseño Lógico.El primer paso en el diseño de sistemas es identificar los informes y las salidas que elsistema producirá; a continuación los datos específicos de cada uno de éstos seseñalan, incluyendo su visualización exacta sobre el papel, la pantalla de despliegueo cualquier otro medio.El diseño también describe los datos calculados y/o almacenados en la base de datos.Los datos y los procedimientos de cálculo se describen con detalle. Se seleccionan lasestructuras de los archivos y los dispositivos de almacenamiento, como son discos ocintas magnéticas o papel. Los procedimientos deben mostrar cómo se van a procesarlos datos y cuáles van a ser las salidas. Los documentos que contiene lasespecificaciones del diseño se pueden representar por medio de diagramas, tablas ysímbolos especiales. El último paso del diseño es pasar el documento de diseño algrupo de desarrollo para que se inicie la fase de codificación del software. Por lo tantodespués de realizar el análisis respectivo de la fase se propone los procesos de Diseñode datos, Diseño Arquitectónico, Diseño Procedimental, Diseño de Interfaz de usuario,Documento de Diseño Preliminar, Documento de Diseño Detallado como se puedeobservar en la siguiente figura. [7].

Figura 2. Procesos de la Fase de Diseño.3.1.2.1 Diseño de Datos: Se toma el documento de requerimientos y se definenaspectos, como los tipos de datos que se requieren para lograr el funcionamientocorrecto de toda la aplicación, al igual, estos datos pueden ser registros, archivos obases de datos. De igual forma se tiene que definir aquellas personas o entidades quevan a estar involucradas, al igual que las relaciones que se pueden presentar entreestos dependiendo el tipo de procesos u operaciones que deba cumplir la aplicación.Es de suma importancia definir las reglas que se deben seguir esto para establecer loscriterios de cómo se deben realizar los procesos para que ejecuten estrictamente loque se desea.El diseño de datos consiste en definir completamente los procesos y las característicasde los datos de la aplicación, este puede ser un proceso donde se perfecciona desdelo elemental como los datos que requiere la aplicación hasta los procesos en los cualesintervienen, con un buen diseño de datos se puede garantizar, que el acceso a losdatos de la aplicación se llevara de manera ágil, y se podrán mantener, al igual quepuede aceptar mejoras a los datos que se requieran realizar más adelante. En esteproceso se identifican los datos, la definición de tipo de estos datos, y los mecanismosde almacenamiento adecuados, también se definen reglas de empresa y mecanismosde exigencia los cuales garanticen la integridad de los datos [8].3.1.2.2 Diseño Arquitectónico: En este se define la relación entre los principaleselementos estructurales del software. Patrones de diseño que se puedan presentar, yque ayuden a cumplir los requisitos que se han definido para el sistema. Y lasdiferentes restricciones que puedan afectar la aplicación de los patrones de diseñoarquitectónico. Es el proceso que identifica todos los subsistemas existentes yestablece un marco para el control y la comunicación entre todos estos subsistemas,se identifican los principales componentes del sistema y las comunicaciones quepuedan existir entre estos. Existen ventajas con el diseño arquitectónico que pueden

facilitar este proceso, la comunicación con los usuarios, esto facilita la discusión entrediferentes usuarios involucrados, otra es el análisis del sistema, lo que permite tenercontrol sobre los requerimientos críticos del sistema, rendimiento, fiabilidad, ymantenibilidad y por último la reutilización a gran escala, esto dado a que laarquitectura del sistema es a menudo la misma para sistemas con requerimientossimilares, y esto permite que se pueda llevar a cabo una reutilización a gran escala, aveces es posible desarrollar arquitecturas que se pueden utilizar en varios sistemas[8].3.1.2.3 Diseño Procedimental: Este transforma los elementos estructurales en unadescripción procedimental del software. Es la especificación mediante herramientasde modelado (Star UML, Vsparading) tales como algoritmos, diagramas de flujo, delfuncionamiento interno de cada uno de los módulos que compone el sistema, definidosen los subproceso Arquitectónico y las relaciones u operaciones que deben realizardentro de la aplicación final, esto permite al desarrollador tener una visión másdetallada del procedimiento de desarrollo que se debe realizar, estos diagramas yalgoritmos definidos se convertirán en parte funcional de la aplicación ya que contienenlos componentes primarios y secundarios, las relaciones y operaciones que se debenrealizar entre ellos para cumplir cada uno de los requerimientos del cliente [9].3.1.2.4 Diseño de Interfaz: En esta se define cada una de las interfaces que se van autilizar para permitir la interacción de la aplicación como tal, existen diversos aspectosque se deben tener en el diseño de interfaz, aspectos como navegación, amigabilidad,colores, ayuda, control de acceso, textos, entre otros. Teniendo en cuenta losanteriores aspectos podemos garantizar que el diseño de interfaz va a cumplir con lanecesidad para la cual es creado, ya que este finalmente va ser el utilizado por elcliente como mecanismo para interactuar y operar los diferentes componentes quevienen inmersos en la aplicación final [10].3.1.2.5 Documento de Diseño Preliminar: Se centra en la transformación de losrequerimientos de la fase de análisis, en datos y la arquitectura propia del desarrollode software.3.1.2.6 Documentos de Diseño Detallado: Se ocupa del refinamiento y de larepresentación arquitectónica que lleva a una estructura de datos refinada y a lasrepresentaciones a través de diagramas de flujo del software.3.1.3 FASE DE CODIFICACIÓNDespués de terminar la fase de diseño, se inicia la fase de codificación lo que en ellenguaje de ingeniería se conoce como la programación, se toman los algoritmos y sellevan a un lenguaje de programación determinado, este lenguaje es escogidodependiendo su utilidad y la necesidad de la aplicación si es adaptable o no a lorequerido por el programador. Después de realizar un análisis a la base teórica de estafase se procede a proponer los subprocesos de codificación, depuración del código,pruebas de unidad, pruebas de componentes, pruebas de integración, documentotécnico como se observa en la siguiente figura.

Figura 3. Procesos de la Fase de Codificación3.1.3.1 Codificación: Este proceso lo compone los subprocesos de “Código Fuente”el primer paso en la codificación y consta de líneas de texto, que son instruccionesque se deben seguir para ejecutar el programa, “Código Objeto” es el resultado dellevar a cabo la compilación del código fuente, “Código Ejecutable” es el que nospermite saber que la compilación tuvo éxito, y verifica que en el programa no existanerrores de manejo, de esta forma si no se encuentran errores se dice se dice que elprograma funciona correctamente, ya que está libre de errores de variables, signo yotros, “Código Compilador” es el programa informático que permite traducir el códigofuente de un programa en lenguaje de alto nivel (Lenguaje cercano a cómo piensa elhumano), a un lenguaje de bajo nivel (Lenguaje de máquina), de esta forma elcompilador reporta los posibles errores encontrados en el código fuente, “CódigoMáquina” es el que proviene de la tarea de compilación efectuada directamente sobreel código fuente, con el que se obtiene posteriormente el (Bytecode), que es laintegración de distintos archivos que forman parte de ejecutables para que elordenador pueda hacer uso del código programado anteriormente [11].3.1.3.2 Depuración Del Código: Es el proceso de identificar la raíz de un error ycorregirlo, la depuración representa el 50% del tiempo de desarrollo de un programa,la mayoría de errores y fallas son mecanográficas, las cuales pueden ser detectadascon facilidad, con la ayuda de la observación del código o con ayuda del depurador.3.1.3.3 Pruebas De Unidad: Estas también llamadas pruebas de caja blanca, opruebas modulares ya que estas nos permiten determinar si un módulo del programaestá listo y correctamente terminado, para estas pruebas se debe tener en cuenta eltamaño de los módulos y preferiblemente separarlos acuerdo a su funcionalidad. Elobjetivo de las pruebas unitarias es el aislamiento de partes de código y demostrar queestas no contienen errores. Los beneficios de estas pruebas son Simplificación de laintegración, Refactorización del código, Documentación, y Diseño.3.1.3.4 Pruebas De Componentes: En este se llevan a cabo pruebas a componentesde manera individual, con este se logra encontrar defectos internos dentro de este.Por medio de un caso de prueba se debe probar la funcionalidad de ese componentede esta manera se confirma la buena ejecución del componente, de igual forma conestas pruebas se determina la resistencia que este pone a entradas de datos inválidos.

3.1.3.5 Pruebas De Integración: También llamadas pruebas de interfaz compruebala integración entre los diferentes componentes después de la integración de todos losmódulos o componentes que integran el sistema.3.1.3.6 Documento Técnico: En el documento se describe de forma general laejecución de cada proceso que se ha codificado, de igual forma se debe describir lafuncionalidad y operatividad de cada componente. También se especifica los paquetesque intervienen si se debe realizar algún despliegue, especificación e interacción de labase de datos, especificar como se deben ingresar cada uno de los datos para laejecución de los componentes o de la aplicación, especificar y demostrar la correctautilización de cada una de las interfaces utilizadas, y la correcta navegación y ejecuciónde cada uno de los procesos que se ejecutan dentro de la aplicación por parte delusuario [11].3.1.4. FASE DE PRUEBASEn esta fase se realiza una verificación dinámica del comportamiento de la codificacióndel software contra el comportamiento esperado según los requerimientos definidosen el documento de la fase de análisis, haciendo uso de un conjunto de casos depruebas, seleccionados de manera adecuada según los diferentes escenarios que sepueden presentar por cada validación puntual del software que se desee probar.Las pruebas están enfocadas principalmente en la evaluación o valoración de laCalidad de los productos software, permitiendo Encontrar y documentar defectosexistentes, Sugerir mejoras según la calidad percibida, Validar que los requisitos esténimplementados correcta y completamente [5,6]. A partir del estudio realizado de la fasese dedujo los subprocesos, los cuales contribuyen a la eficiente ejecución de pruebasde software, para posteriormente certificar el desarrollo del software, los cuales seobservan en la siguiente figura.Figura 4. Procesos de la Fase de Pruebas3.1.4.1 Planeación: Se define como una preparación y planificación en la cual secontextualiza al grupo de pruebas sobre la aplicación o software a probar, se estableceel entorno de pruebas, se disponen de los procedimientos y los criterios a aplicar enlas pruebas, también se selecciona la estrategia de pruebas adecuada. La planificación

de pruebas es de suma importancia en la fase de pruebas ya que es la base para lossubsiguientes procesos de la misma fase, por tanto se debe tener claro los TiposPruebas, Numero de Ciclos de pruebas, Recursos Físicos, Recursos humanos,Calendario de pruebas, Restricciones/Limitaciones, Dependencias.3.1.4.2 Diseño: Identificar y describir los casos de prueba y escenarios identificadosen los requerimientos recibidos del cliente, los cuales serán ejecutados posteriormenteen la fase de ejecución. Además, permite identificar el conjunto de datos que serviránpara ejecutar las pruebas, crear nuevos casos de prueba necesarios que seandetectados en el transcurso del proyecto y controlar la cobertura de los requerimientosdados.3.1.4.3 Ejecución: Realizar la ejecución de todos los casos de prueba que fuerondiseñados en la fase de Diseño y lograr los objetivos propuestos en la fase dePlaneación, mediante la adecuada gestión de incidencias encontradas, elmantenimiento de la trazabilidad de los casos de prueba ejecutados y el seguimientoy control del estado de las pruebas.3.1.4.4 Evaluación: Determinar si los criterios de completitud definidos para unrequerimiento han terminado a satisfacción y valorar los resultados generados. Sepretende igualmente establecer la calidad del producto desarrollado y del procesomismo. Para ello se prepara un informe final con un balance del proyecto,proporcionando una valoración del cumplimiento de las actividades planeadas y de lacalidad en general del proyecto y del producto obtenido. Generando como entregablesel resumen de pruebas, carta de certificación y el documento de lecciones aprendidas.3.1.5 FASE DE ENTREGAEn esta fase se realizan las diferentes actividades para poner a disposición de losusuarios la aplicación desarrollada, se hace la preparación de la infraestructuranecesaria para configurar el entorno, la instalación de los componentes, la activaciónde los procedimientos manuales y automáticos asociados, y cuando sea necesario lamigración o carga inicial de datos. Adicional a esto se debe cumplir con la capacitacióna los usuarios finales, en esta se debe garantizar la correcta puesta en marcha, y lacorrección de los errores que se lleguen presentando al momento de la integración conel ambiente del cliente. Donde finalmente se debe obtener la firma del acta de entregapor parte del cliente. [12] En esta fase se entrega la última versión del proyecto probaday aprobada; con el análisis realizado a la base documental se procese a proponer lossubprocesos más importantes como se plasman en la siguiente figura.

Figura 5. Procesos de la Fase de Implementación3.1.5.1 Instalación de Hardware y Despliegue de Software: En esta se procede arealizar la instalación de todos los elementos tecnológicos que permitirán instalar yejecutar la aplicación de proyecto, los cuales deben cumplir requisitos mínimos que sedeterminaron en la fase de pruebas del proyecto, con esto se garantiza que se poseela estructura de hardware sobre la cual va a estar bien sementado el software que seva a requerir para garantizar la funcionalidad del producto de software.3.1.5.2 Personalización: En esta se debe adaptar la aplicación a los requerimientosdel usuario final, en esta se ajustan los parámetros establecidos en el software a lasparticularidades que necesita el cliente.3.1.5.3 Capacitación a Usuarios Finales: En esta fase se realiza un plan decapacitación a usuarios finales, donde se debe impartir tanto conocimiento de lainformación que controlara la aplicación, como la forma de operación de la misma, conesto se cumple con un requisito indispensable. Se imparte capacitación a losadministradores de la aplicación, como a los usuarios finales, el objetivo es no creardificultades ni resultados erróneos con la ejecución de la aplicación.3.1.5.4 Prueba Piloto: Es aquella que se realiza en un ambiente vivo del cliente endonde se observa su funcionamiento y los errores que se van evidenciando se vancorrigiendo sobre la marcha de esta prueba esta es indispensable ya que es la antesalaa la entrega final del proyecto al cliente.3.1.5.5 Estabilización: En este proceso se van integrando cada una de lasfuncionalidades contenidas en el proyecto, donde se realizan unas pruebas llamadas“pruebas beta”, con estas al ejecutarlas se va observando su operación y se vancorrigiendo los errores, esto se realiza hasta que se hayan incorporado todas lasfuncionalidades, con esto lo que se busca es tener un producto estableoperacionalmente.

3.1.5.6 Puesta en Marcha de la Aplicación Completa: En esta se tiene la aplicaciónen funcionamiento directamente en el ambiente del cliente, en esta finalmente esdonde se obtiene la aceptación del cliente y se firma el acta de entrega del productode software [13].3.2 GESTIÓN DE RIESGOS EN LAS FASES DEL DESARROLLO DE SOFTWAREEN LA EMPRESA PRIVADALos riesgos según el PMBOOK se define como la probabilidad de que ocurra un eventoya sea positivo o negativo, en caso de ser positivo se considera como una oportunidady si es negativo representa una amenaza, que puede afectar la ejecución del proyectoya sea en el alcance, tiempo, costo, y calidad del producto o servicio.Los Tipos de Riesgos son “Riesgos Conocidos” que hacen referencia a los que hansido identificados y analizados, lo cual permite planificar el plan de respuesta a estosy se les debe asignar una reserva para contingencias, los “Riesgos Desconocidos”hacen referencia a los riesgos que se desconocen y se les puede asignar una reservade gestión. También es importante tener en cuenta que existe una “Probabilidad deOcurrencia” que hace referencia a la medida para estimar la posibilidad de que ocurraun incidente o evento.3.2.1 Relación del Riesgo con las fases del desarrollo de softwareLos riesgos se reflejan desde el inicio del proyecto, por esta razón se debe realizar lagestión en el grupo de procesos de planificación del proyecto. De igual forma estagestión debe ser aplicada a cada una de las fases del desarrollo de software, lo cualpermitirá garantizar la disminución de riesgos presentes en estas, evitando sobrecostos y demoras en el proyecto. Lo anterior se representa en la siguiente figura.Figura 6. Relación del Riesgo con las fases del desarrollo de Software

3.2.2 Gestión De RiesgosLa gestión de riesgos puede definirse como el

importancia de gestionar los riesgos en los proyectos de Software es conocida de forma general, no lo es a un nivel más particular, orientado a las fases del ciclo de vida del desarrollo de software; por tal razón las fuentes de información trabajadas son "Fuentes Secundarias" que son las búsquedas en Internet de bases virtuales,