Caso de estudio DEVELOP SOFTWARE Como ingeniero de software has iniciado labores profesionales en la empresa DEVELOP SOF
Views 41 Downloads 3 File size 201KB
Caso de estudio DEVELOP SOFTWARE Como ingeniero de software has iniciado labores profesionales en la empresa DEVELOP SOFTWARE, la que tiene como giro principal la creación de aplicaciones hechas a medida para los clientes que solicitan sus servicios. La empresa está compuesta por un gerente general, un jefe de departamento de desarrollo, tres programadores, un diseñador, un ingeniero de testing y dos analistas. Adicionalmente laboran en la organización tres encargados de ventas una recepcionista y un guardia de seguridad. Como parte de tus obligaciones profesionales se te ha encomendado realizar la propuesta de un plan SQA para asegurar la calidad de un proyecto que se iniciará. El proyecto se trabajará con un modelo de desarrollo ágil basado en la creación de prototipos, y se tiene un alto grado de acceso a los usuarios finales y a la gerencia por lo que la interacción con los clientes será cercana y permanente
Instrucciones 1.- En base a la información proporcionada complementar el plan para el aseguramiento de la calidad del software desarrollando el proyecto de mantenimiento de software que contenga lo siguiente: 2.- Identificar el tipo de mantenimiento al que corresponda el caso. (Para cada una de sus etapas) 3.- Identifica las pasará 4.- Realiza
fases de evolución del mantenimiento por las cuales el sistema
el estudio de viabilidad y costos con base en los requerimientos.
5.- Integra esta información con lo ya desarrollado en la unidad 1 y 2 y modifica las conclusiones del documento para incluir tu opinión sobre la importancia del informe de viabilidad y análisis de riesgos de un proyecto de mantenimiento de software. Plan de aseguramiento de pruebas El plan a desarrollar se enfoca en establecer las pautas y actividades a implementarse para garantizar la calidad del proyecto a desarrollar, el plan brinda elementos de apoyo a la gestión del proyecto con lo cual se pueden realizar verificaciones sobre la adecuación al proceso y, de esta manera, detectar desvíos y posibles errores que puedan resultar en acciones correctivas en las etapas tempranas, el ciclo de vida relacionadas que se tendrá en cuenta para el presente plan es: elaboración, construcción, evaluación y transición, siguiendo una línea de trabajo sobre los siguientes pasos: requerimientos, análisis, diseño, implementación, verificación y mantenimiento.
Objetivo de la calidad del programa Desarrollar cada etapa del proyecto con la seguridad de que se está cumpliendo con todos los requisitos y funcionalidades que se espera obtener, evitando costos futuros en reparación o mantenimiento prematuro del software, garantizando al cliente un producto apto para su uso e implementación con un grado de error mínimo. Actividades de revisión propuestas para el plan
Revisar cada producto El alcance de esta actividad consiste en revisar los productos que se hallan definido como principales para verificar en el plan de calidad empleado, inspeccionando que no queden correcciones sin resolver identificadas en los informes de revisión previos, en caso de que se encuentre alguna no resuelta, esta deberá ser incluida en la siguiente revisión. También se deberá identificar, documentar y mantener en continua revisión las desviaciones encontradas así como verificar que se hayan realizado las correcciones necesarias, como resultado se obtiene el Informe de revisión de SQA, el cual debe ser entregado a los responsables del producto, asegurándoles que son conscientes de desviaciones o discrepancias encontradas. Los responsables de ejecutar la actividad son: el jefe de departamento de desarrollo y el ingeniero de testing. Revisar el ajuste al proceso Su alcance consiste en revisar los productos que se definieron como principales para verificar el cumplimiento de las actividades definidas en el proceso, para asegurar la calidad en el producto final del desarrollo, se realizaran revisiones sobre los productos durante todo el ciclo de vida del software y a su vez se recogerá la información necesaria de cada producto, buscando que cumplan con los requerimientos planteados inicialmente. Hay que debe verificar en los informes de revisión previos que todas las desviaciones fueron corregidas, de no ser este el caso, las faltantes se incluyen para ser probadas en un futuro no lejano, con el fin de pasar a la siguiente etapa de desarrollo, de esta actividad se puede obtener el Informe de revisión de SQA correspondiente a la evaluación de ajuste al proceso, el cual deberá ser entregado a los programadores y gerente general, con el fin de corregir posibles errores encontrados y darle seguimiento al desarrollo del proyecto. Los responsables de ejecutar esta actividad son: el ingeniero de testing y los analistas. Realizar Revisión Técnica Formal La actividad consiste en descubrir los errores que se generen en la función, la lógica o la implementación de cualquier producto del software, verificando que satisface las especificaciones y que se ajusta a los estándares establecidos, mostrando las posibles desviaciones detectadas en el
producto, con esta actividad se espera detectar lo antes posible, los defectos y/o desviaciones en los productos que se van generando en todo el desarrollo, estas revisiones se hacen mediante reuniones donde se convoca a todo el equipo de desarrollo, gerente general, jefe de departamento de desarrollo, ingeniero de testing, programadores, analistas y el diseñador, los cuales pueden hacer preguntas sobre las dudas que les han surgido durante las revisiones y pruebas del producto, estas reuniones serán de dos horas o menos, ya que no se debe invertir mucho tiempo en ellas, como resultado se obtiene el informe de la revisión técnica formal. Asegurar que las desviaciones son documentadas. El fin de esta actividad es documentar cada una de las desviaciones que se hayan detectado en el proyecto, manejándolas de acuerdo a un correcto procedimiento, el cual será implementado por el responsable del área que lo requiera. Los responsables de realizar esta actividad son los analistas, el encargado de desarrollo y el gerente general, los cuales se encargaran de checar continuamente a los encargados de cada área, para que resuelvan las desviaciones encontradas de una manera oportuna.
Gestión de la configuración: Especificación de requerimientos del software Los requerimientos en el desarrollo del producto software son de suma importancia al momento de iniciar con el proyecto, ya que estos sirven de base para las siguientes etapas, estos son: Funcionalidad
adecuación a las necesidades precisión de los resultados interoperabilidad seguridad de los datos
Confiabilidad
madurez tolerancia a faltas
Usabilidad
comprensible aprendible operable atractivo
Eficiencia
utilización de recursos
Mantenibilidad
analizable modificable estable verificable
Portabilidad
adaptable instalable co-existencia
En conjunto estos atributos deberán cumplir con las normas y regulaciones aplicables a cada uno. Descripción del diseño del software Este documento es elaborado por los desarrolladores en conjunto con los clientes, es aquí donde se describen los componentes y subcomponentes del diseño del software, incluyendo interfaces internas, las cuales cubren los requerimientos iniciales en función de la importancia que estos presenten y de sus conexiones lógicas.
Verificación y validación Se verifica que los requerimientos descritos en el documento de requerimientos han sido aprobados por el encargado de desarrollo y el cliente, y se verifica que los requerimientos planteados son implementados en el diseño plasmado en el documento de diseño, el cual a su vez deberá estar implementado en el código, validando este último al ser ejecutado. Documentación de usuario En este apartado se especifica y describen los datos y entradas de control requeridos, así como la secuencia de entradas, opciones, limitaciones del proyecto y los elementos necesarios para la ejecución exitosa del software. Mantenimiento del software Para esta etapa se realizan revisiones paulatinas al software por parte del encargado de desarrollo el cual considera que se debe dar mantenimiento o no al software que se está desarrollando, también se realizan las revisiones por el cliente, si este considera que hace falta mantenimiento, se lo hará saber al encargado, quien a su vez lo re direccionara con el técnico principal. Norma para evaluar el proyecto
La norma empleada para la evaluación del proyecto es IEEE 730-2002, la cual permite emplear un ciclo de vida apto para cada proyecto, dependiendo el software que se desea desarrollar, la ventaja principal de este estándar es que describe los procesos en un plan integral, el cual se ha definido con anterioridad, elaborándose sistemáticamente para su correcta ejecución. Plan de pruebas Revisar cada producto
El elemento del desarrollo que se va a probar Se probara el sistema completo Tipo de prueba La prueba a utilizar en esta actividad es la de Implantación Nivel de prueba Tercer nivel Justificación de la utilización de la prueba Se ha optado por la utilización de la prueba de implantación debido a que este tipo de prueba permite realizar una sobrecarga en la ejecución del sistema, lo cual permitirá encontrar algún posible error en la ejecución del mismo.
Planificación En específico se evaluara la reacción del sistema ante una sobrecarga de ejecución, con lo cual se le pedirá al programa que realice una misma acción un mínimo de 5 veces, tomando en cuenta las ordenes que puede ejecutar la aplicación, o producto que se halla desarrollado, cabe mencionar que la prueba a implementar es dinámica. Procedimientos La aplicación se ejecutara las veces que se halla planeado, en este caso 5 veces una misma orden, con el fin de sobrecargar el sistema y que arroje algún error, de ser así se documentaran y se procederá a su corrección o modificación, según sea el caso. Personal que ejecutará la actividad El jefe de departamento de desarrollo y el ingeniero de testing.
Revisar el ajuste al proceso
El elemento del desarrollo que se va a probar Se probara la aplicación por módulo de código Tipo de prueba Prueba de integración Nivel de prueba Segundo nivel
Justificación de la utilización de la prueba La prueba de integración es la adecuada para el ajuste al proceso, pues permite checar la funcionalidad del código que se está estructurando, teniendo en cuenta que este integra la información que se está procesando en la elaboración y ejecución de la aplicación. Planificación Se evalúa el desarrollo del sistema en su etapa media, en la cual ya se cuenta con clases estructuradas que desempeñan cada una diferente función, la prueba se aplicara un mínimo de 5 veces, los requerimientos que se hallan definido para esta etapa son los que se tendrán en cuenta, esperando cumplir con los mismo, este tipo de prueba es estática, pues se realiza durante la programación del componente. Procedimientos El código de la aplicación se divide en módulos, para poder realizar modificaciones o mejoras a la misma en un futuro, por tal motivo se prueba el modulo en el desarrollo medio de la misma, en donde se realizan peticiones de integración por parte del usuario a las clases existentes, las cuales deben arrojar el resultado previsto, de igual forma se documenta cada uno de los resultados que se obtengan en las ejecuciones, si el positivo se procede a dar como aprobado este módulo. Personal que ejecutará la actividad El ingeniero de testing y los analistas.
Realizar revisión técnica formal
El elemento del desarrollo que se va a probar El programa en su totalidad Tipo de prueba Prueba de aceptación Nivel de prueba Cuarto nivel Justificación de la utilización de la prueba La prueba de aceptación permite al desarrollador determinar si el programa cumple con los criterios necesarios para su implementación, verificando si satisface con las especificaciones y que se ajusta a los estándares establecidos, por tal motivo se procede a realizar las interacciones necesarias. Planificación Se evaluara la capacidad que presenta el programa al momento de manipular los datos y el resultado que arroje, la prueba se llevara a cabo un mínimo de 4 veces, buscando que los requerimientos descritos en el documento inicial se cumplan en su totalidad, tales como funciones que deben presentar
resultados al usuario, esta prueba es dinámica, ya que permite probar el componente cuando está terminado. Procedimientos Se ejecutan una serie de ordenes en el sistema de software, introduciendo y manipulando información para que el sistema lleve a cabo el proceso de la misma, y nos arroje el resultado final, esto se debe realizar el número de veces prevista, para asegurarnos que el programa cumple con los criterios de aceptación requeridos. Personal que ejecutará la actividad Gerente general, jefe de departamento de desarrollo, ingeniero de testing, programadores, analistas y el diseñador.
Asegurar que las desviaciones son documentadas
El elemento del desarrollo que se va a probar Por módulo, dependiendo de cada actividad realizada Tipo de prueba Pruebas de regresión Nivel de prueba Quinto nivel Justificación de la utilización de la prueba En este tipo de prueba se espera que el modulo seleccionado entregue los resultados finales al usuario, mediante la revisión de los datos documentados, los cuales deberán mostrar resultados finales aceptos para entregar el producto software. Planificación Se evaluara el cumplimiento de los puntos previstos en la documentación inicial, los cuales se van mencionando conforme se desarrolla la actividad, se realizara la revisión como mínimo 3 veces, esperando que la configuración del hardware y software se registren correctamente, el tipo de prueba es dinámica, pue se realiza al final del desarrollo. Procedimientos Se realiza una revisión exhaustiva al documento de la actividad y se anotan las posibles incongruencias encontradas, esto se debe hacer un mínimo de 3 veces, para que al final se esté totalmente seguro de haber atendido a los avisos necesarios, entregando una actividad correctamente documentada. Personal que ejecutará la actividad Ingeniero de testing y analistas
Informe de viabilidad y análisis de riesgo Tipos de mantenimiento
Mantenimiento preventivo: Se realiza tan pronto se entregue el producto software, en este caso se debe hacer una revisión minuciosa a los productos al momento de ejecutarlos por primera vez en su entorno donde se implementara, de existir algún error, hay que realizar los cambios necesarios a la brevedad posible, con el fin de que el error no se convierta en efectivo y resulte más complejo y costoso corregirlo, los encargados de hacerlo serán los mismos desarrolladores y diseñador. Mantenimiento correctivo: Después de entregar el producto de software que se ha desarrollado, pueden surgir inconvenientes en su ejecución, ya sea en el procesamiento de datos o en los resultados que se obtienen al final, cabe mencionar que estos errores se originan después de que el sistema estuvo ejecutándose de una manera correcta, ante este tipo de situaciones hay que implementar el mantenimiento correctivo. Mantenimiento adaptativo: El producto software se desarrolla en determinado entorno operativo y para que funcione tomando en cuenta ciertas herramientas administrativas, pero al paso del tiempo, tanto el entorno operativo como las herramientas administrativas se actualizan, o bien el cliente desea cambiar ambas cosas y desea adaptar el producto, en este caso es necesario realizar el mantenimiento adaptativo, tomando en cuenta los nuevos requerimientos mostrados por el cliente, este tipo de mantenimiento se centra en realizar modificaciones de actualización para que el producto se implemente en cualquier entorno. Mantenimiento perfectivo: Después de que el producto lleva un tiempo en el mercado y ejecutándose tal y como el usuario lo esperaba, surgen cambios a implementar por parte del usuario, quien requiere que el sistema realice nuevas funcionalidades o bien que las funcionalidades actuales, sean mejoradas para que el producto se mantenga con su rendimiento inicial.
Fases de evolución Versión alfa: Pertenece al desarrollo inicial, es aquí donde se definen con precisión los requerimientos del sistema, una vez identificados estos, se procede a estructurar la aplicación, ya que se tiene la versión completa, se pueden realizar pruebas, tanto por el usuario como por los desarrolladores, con el fin de saber si se realizaran más cambios y modificaciones en la estructura, por el momento solo se muestran escenarios y casos de estudio, pero con los conocimientos adquiridos mediante las pruebas realizadas, se puede emplear el dominio de la aplicación, soluciones a los problemas encontrados, nuevos requerimientos del usuario, entre otros. Etapa de madurez: Se aplica al momento de que el cliente muestra como necesarias nuevas implementaciones en el mismo, con el fin de adaptarlo a los entornos actuales que se manejen en su área de aplicación, un ejemplo seria la
aplicación que se desarrolla únicamente para uso de escritorio, pero, con el uso continuo de otro tipos de dispositivos (tablets, smarthphone, IPad) de debe mejorar la aplicación a un diseño responsivo, el cual permitirá que esta sea manejada desde cualquier dispositivo, dándole mayor probabilidad de éxito en el mercado a sus clientes. Etapa de salida: Después de haber realizado diferentes tipos de mantenimiento a las aplicaciones que se desarrollan en la empresa Develop Software, se llega al punto donde el sistema ya no es adaptable, debido al alto costo que supone realizar una siguiente modificación, por tal motivo, es necesario aplicar la reingeniería de sistemas, la cual nos ayuda a identificar el código reutilizable para tomarlo de base en un nuevo componente, modulo o sistema para iniciar un nuevo proyecto. Estudio de viabilidad y costos (Registro de trabajadores) 1. Identificar los requerimientos - El sistema debe asignar a cada trabajador un número de clave conforme se registre al nuevo integrante de la empresa. - El sistema debe permitir a los trabajadores registrar su hora de salida y llegada, mediante la huella digital.
2. Identificar el tipo de mantenimiento Para el ejemplo tomado sería un mantenimiento perfectivo, pues este tipo de mantenimiento logra adaptar al sistema existente, nuevas funcionalidades, que le permitirán a la aplicación, permanecer más tiempo en el mercado. 3. Identificar la solución a tales requerimientos Requerimientos - El sistema debe asignar a cada trabajador un número de clave conforme se registre al nuevo integrante de la empresa. - El sistema debe permitir a los trabajadores registrar su hora de salida y llegada, mediante la huella digital. Restricciones al usuario
El sistema se debe centralizar y cifrar, para que el usuario solo acceda a los datos a manera de lectura. Se debe adaptar al sistema operativo Windows 10 Utilizar Phpmyadmin para la administración de la base de datos, a la cual solo podrán acceder los usuarios administrativos mediante contraseña.
Requisitos del sistema Módulos del sistema
Actualización de datos Generación de informes
Equipo de hardware
Número de procesador E3-1125C Cantidad de núcleos 4 Cantidad de subprocesos 8 Velocidad del reloj 2 GHz Memoria caché L 38 MB Conjunto de instrucciones 64-bit Extensiones de conjunto de instrucciones AVX, AES-NI Disco duro de 1 TB Un quemador para respaldar la información Lector de huella digital
Software
Phpmyadmin 4.6.6 Windows 10
4. Identificación de riesgos y medidas de prevención Tipo de riesgo Riesgo Medidas preventivas Del proyecto Siniestros Ninguna
Nuevos requerimientos por parte del usuario
Técnico
Medidas correctivas Restablecer la funcionalidad de los equipos dañados a la brevedad posible. Comunicarse Replantear el estudio continuamente de factibilidad y hacer con el usuario saber al usuario las para que todos consecuencias que los parámetros a esto supone. tomar en cuenta, sean definidos antes de concluir con el estudio de factibilidad. Realizar Aplicar mantenimiento mantenimiento preventivo correctivo
Equipo dañado durante el desarrollo del proyecto Pérdida de datos Configurar el Ingresar nuevamente sistema para que los datos al sistema. realice una copia de seguridad del
Tecnológico
Asociado con el tamaño y experiencia de la plantilla del personal
Necesidad de una interfaz adicional para el administrador del sistema. Pérdida de algún miembro del equipo de desarrollo.
mimo cada determinado tiempo. Fijar permisos Crear una para cada tipo de interfaz usuario del sistema.
Tener una lista de espera sobre posibles candidatos para el puesto. Experiencia Capacitar al insuficiente por personal antes de parte del equipo iniciar el proyecto. en el uso del software
nueva
Contratar a un nuevo personal y redistribuir las actividades.
Capacitar continuamente al personal, para que se actualicen en información y experiencia.
5. Estudio de factibilidad operativa Se desarrollan los siguientes módulos de acuerdo a los requerimientos que se tienen, estos podrán ser utilizados asociándose a los módulos que ya existen y adaptándolos al proyecto, los nuevos módulos son: Actualización de datos Generación de informes 6. Estudio de factibilidad técnica Hardware 20 Computadoras personales marca LENOVO modelo AIO 300-22ACL con las siguientes características: Procesador: AMD A6-7310 Memoria Ram: 4G Disco duro: 1 TB Pantalla: 21.5 Pulgadas LED Puertos USB: 2 USB 2.0 / 1 USB 3.0 Teclado: Standard PS–2 Red: RJ-45 Sistema Operativo: Windows 10 Mouse: OMEGA PS–2 DVD-RW: LG Unidad de disco flexible 3½” Estabilizador ProNet de1000 W 2 Impresoras: HP color LaserJet 8550-PS y Canon Bubblet -Jet S450 Matricial EPSON LQ 570-e
Plataforma software actual Windows 10, x86-64, NT 10.0, híbrido. Programas instalados Office 360 SQL Server EnterPrice Manager + Service Pack 4 Visual Basic 2015 WinZip 21 WinRar 5.40 Nitro Pro 9 Nero Burning ROM 2014 Servidor wampserver 64 Editor de texto MySQL 5.6
Para cumplir con los requerimientos de Develop Software, es necesario hacer las siguientes adquisiciones: Phpmyadmin Lector de huella digital 7. Estudio de factibilidad económica Alternativa 1.- Lector de huella digital con Phpmyadmin Construcción 2 programadores 650 al mes 1 Ingeniero de testing 450 al mes 1 analista 400 al mes Tiempo real: 226.52+4*283.15+353/6 Tiempo real: 285.35 Coste real: 3.2+4*3.5+3.7/6 Coste real: 3.48 Hardware y software Lector de huella digital 570.00 Phpmyadmin 300.00 Insumos 3 paquetes de papel 15.00 1 caja de lápices 12.00 Llamadas telefónicas 30.00 Impresión 10.00 Costos variables 2 paquetes de papel 10.00 Cartucho de tinta negra 50.00 Cartucho de tinta a color 70.00 Alternativa 2.- Lector de huella digital con MySQL Worckbench 6.3 CE
Construcción 2 programadores 700 al mes 1 Ingeniero de testing 480 al mes 1 analista 400 al mes Tiempo real: 196.22+4*245.28+306.6/6 Tiempo real: 247.32 Coste real: 3.3+4*3.5+3.8/6 Coste real: 3.51 Hardware y software Lector de huella digital 570.00 MySQL Worckbench 6.3 CE 450.00 Insumos 3 paquetes de papel 15.00 1 caja de lápices 12.00 Llamadas telefónicas 30.00 Impresión 10.00 Costos variables 2 paquetes de papel 10.00 Cartucho de tinta negra 50.00 Cartucho de tinta a color 70.00 8. Estudio de factibilidad de tiempo Tarea Tiempo estimado Asignación de roles en el equipo Creación de los nuevos módulos Adaptación del lector de huellas dactilares Pruebas de sistema
7 días
Tiempo disponible 15 días
4 semanas
5 semanas
2 semanas
3 semanas
2 semanas
3 semanas
9. Estudio de factibilidad de derechos de autor Para cumplir con las normas necesarias en cuanto a derechos de autor, se realiza la compra de las licencias de los softwares incluidos en el desarrollo y los hardware se compraran en lugares donde hagan constar que la adquisición de los mismos es completamente legal. 10. Selección de alternativas Alternativa Descripción Costo de la inversión
Lector de huella digital con Phpmyadmin
Lector de huella digital con MySQL Worckbench 6.3 CE
Esta alternativa se enfoca en $3, 700.00 utilizar el lector de huellas digitales en conjunto con el software phpmyadmin, lo que permitirá a los usuarios detectar si están en la base de datos o no. En esta alternativa se utiliza el $4, 300.00 lector de huellas digitales en conjunto con MySQL Worckbench 6.3 CE, siendo este último quien permite manejar los datos de los trabjadores.
Alternativa Ventaja Lector de huella - Precio digital con - Se pueden generar Phpmyadmin las bases de datos y su administración en línea - Puede trabajar con un gran número de leguajes de programación. - En intuitivo Lector de huella - Mayor flexibilidad digital con MySQL en el manejo de Worckbench 6.3 CE datos - Es más segura esta alternativa, ya que los datos solo se manejan d manera local y no en línea
Desventaja - Solo administra bases de datos en MySQL - Su código se basa principalmente en PHP - La cantidad de bases de datos administradas se ven muy limitadas. La utilidades usadas no están documentadas - No es intuitivo
11. Conclusiones del estudio de viabilidad y análisis de riesgos Reporte Se observa que la alternativa numero 1 es la que más se ajusta al presupuesto, tanto de tiempo, economía y ventajas de los equipos técnicos utilizados, por tal motivo se considera factible y viable implementar este tipo de mantenimiento en el sistema, que como habíamos dicho, es mantenimiento perfectivo, ya que busca agregar funcionalidad al sistema existente, cabe mencionar que los riesgos encontrados en el proyecto, se pueden controlar con facilidad por los miembros del equipo de desarrollo.