Resumen: El desarrollo de proyectos de software requiere una gran cantidad de mano de obra, recursos materiales y financieros, pero existen muchas incertidumbres y variabilidad en el proceso de desarrollo, por lo que es necesario gestionar y controlar los riesgos de los proyectos de software. A través de la identificación, análisis, respuesta y monitoreo de riesgos de todo el proyecto de software, este artículo realiza activamente trabajos de prevención y control de riesgos en cada etapa del desarrollo del proyecto para lograr el propósito de reducir los riesgos y las pérdidas de riesgos del proyecto.
Palabras clave: desarrollo de proyectos de software; gestión de riesgos; prevención y control de riesgos
1 Introducción
El riesgo se refiere a algunos eventos inesperados en el proceso de realización de una actividad. Se refiere a la probabilidad de que factores inesperados e inciertos causen daños a los participantes del evento y causen daños al medio ambiente natural [1]. Al igual que otros proyectos de ingeniería, el desarrollo de proyectos de software también implica varios riesgos, como sobregiro del fondo del proyecto, extensión del período de construcción y falla del sistema para satisfacer la demanda. Por lo tanto, en el proceso de desarrollo de software, una buena gestión de riesgos ayudará a reducir los riesgos de desarrollo y garantizar la calidad del desarrollo.
2 Clasificación de Riesgos de Proyectos de Software
2.1 Riesgo Técnico
Los posibles problemas técnicos que pueden ocurrir durante el análisis, diseño, prueba e implementación de un software traen grandes riesgos a proyectos de software. El daño causado se denomina riesgo técnico, como el uso de tecnología antigua o inmadura, documentación del sistema no estándar, etc.
2.2 Riesgo de Gestión
El riesgo de gestión se refiere al impacto adverso en los proyectos de software debido a la falta de planificación, control y gestión de los proyectos en términos de presupuesto, personal, cronograma, recursos, etc.
2.3 Riesgo empresarial
El riesgo empresarial también se denomina riesgo de mercado, incluido el desarrollo de productos de software que no satisfacen la demanda del mercado, el posicionamiento poco claro de los productos de software y la falta de competitividad en el mercado, y Competencia en el mercado. Hay muchos productos y una competencia feroz.
2.4 Riesgos de Seguridad
Los riesgos de seguridad incluyen principalmente riesgos naturales, riesgos provocados por el hombre, riesgos ambientales externos, como piratería, virus, etc.
3 Pasos de la gestión de riesgos del proyecto de software
3.1 Identificación de riesgos
La etapa de identificación de riesgos necesita identificar qué riesgos afectarán el desarrollo del proyecto de software, incluido el categorías de estos riesgos, factores, fuentes, consecuencias, etc.[2]. Los métodos comunes de identificación de riesgos incluyen los siguientes.
(1) Método de investigación pericial. En cuanto a las cuestiones de riesgo del desarrollo de proyectos de software, consultamos a expertos en los campos de la industria relacionados con los proyectos, compilamos las opiniones y sugerencias recopiladas en un informe y luego enviamos el informe a los expertos para consultas adicionales. Después de varias rondas de este proceso, se podrá llegar a la conclusión final cuando las opiniones de los expertos converjan.
(2) Método de lluvia de ideas. Reúna a los miembros del equipo de desarrollo del proyecto, representantes de la unidad del proyecto y consultores expertos invitados para discutir e intercambiar los riesgos del desarrollo del proyecto a través de reuniones, con miras a identificar, analizar y predecir con precisión los riesgos del proyecto.
(3) Método de la tabla de detección de riesgos. Diseñe y utilice varios formularios de detección de riesgos basados en elementos para ayudar al equipo del proyecto a identificar diversos riesgos. Por ejemplo, la tabla de detección de riesgos del desarrollador puede enumerar cosas como el nivel técnico del desarrollador, si el desarrollador tiene experiencia similar en el desarrollo de proyectos, si el número de desarrolladores es apropiado, si el desarrollador puede participar en el trabajo de desarrollo de software de principio a fin, y si el desarrollador puede concentrarse Todos los esfuerzos deben dedicarse al trabajo de desarrollo de software, si los desarrolladores han recibido la capacitación necesaria y si el flujo de desarrolladores puede garantizar la continuidad del trabajo. A través del análisis y las respuestas a estas preguntas, se pueden identificar los riesgos que traen los factores humanos a los proyectos de software.
3.2 Análisis de Riesgos
El análisis de riesgos evalúa principalmente la probabilidad de ocurrencia de eventos de riesgo y sus consecuencias [3]. Para completar la evaluación de diversos riesgos, es necesario establecer un sistema de índice de medición de riesgos, aclarar las consecuencias y pérdidas causadas por diversos riesgos, estimar el impacto de los riesgos en los proyectos de software y, finalmente, proporcionar los resultados de la estimación de riesgos [4 ]. Durante el análisis de riesgos, la cuádruple [R, P, I, W] se utiliza a menudo para describir los riesgos. Entre ellos, R representa el riesgo, P representa la probabilidad de que ocurra el riesgo, I representa el impacto del riesgo y W representa el peso del impacto del riesgo en el proyecto.
Si el trabajo de desarrollo de software se puede completar de acuerdo con el rendimiento del software, el tiempo y la cantidad estipulados en el contrato juega un papel vital en la aceptación sin problemas del proyecto. Por lo tanto, nos enfocamos en seleccionar tres aspectos: costo, cronograma y rendimiento del software para medir los riesgos del proyecto de software. Cuando el valor de medición de un determinado aspecto alcanza o excede el punto crítico, el proyecto de software se verá obligado a terminar.
Por lo general, el proceso de evaluación de riesgos se puede dividir en cuatro pasos:
(1) Con base en los resultados de la identificación de riesgos, analizar la probabilidad de ocurrencia de cada riesgo y el impacto de cada riesgo en el costo y el cronograma del proyecto, el impacto de los tres aspectos en el rendimiento del software y asignar diferentes ponderaciones de riesgo a cada riesgo de acuerdo con la gravedad de las consecuencias del riesgo.
(2) Defina la cuádruple [R, P, I, W] de cada riesgo.
(3) Definir el punto crítico en el que el proyecto se ve obligado a terminar.
(4) Predecir el impacto integral de las combinaciones de riesgos en el proyecto [5].
3.3 Respuesta al riesgo
Es necesario formular estrategias de respuesta correspondientes para los diversos riesgos que puedan ocurrir. Las estrategias de afrontamiento más utilizadas incluyen la prevención de riesgos, la transferencia de riesgos, la evitación de riesgos, etc. La prevención de riesgos generalmente se refiere a reducir la probabilidad de que ocurran riesgos mejorando la confiabilidad y estandarización de cada etapa de un proyecto de software. La transferencia de riesgo se refiere al uso de contratos, seguros, garantías, ventas, subcontratación, etc.[6] para transferir parte de las pérdidas cuando ocurren riesgos a un tercero para reducir las propias pérdidas por riesgo. La evitación de riesgos significa que cuando la ocurrencia de ciertos riesgos es inevitable y las consecuencias son graves, el plan del proyecto se puede ajustar o, peor aún, el proyecto se puede abandonar voluntariamente para evitar pérdidas irreparables. Después de completar la identificación de riesgos, el análisis y la selección de la estrategia de respuesta, se debe formar una tabla de respuesta y análisis de riesgos fácil de entender, como se muestra en la Tabla 1.
3.4 Monitoreo de riesgos
El monitoreo de riesgos se refiere al monitoreo de la implementación de medidas de respuesta al riesgo basadas en los resultados del análisis temprano de riesgos y al fortalecimiento de la gestión y el control de los riesgos durante todo el proyecto [7] . El propósito del monitoreo de riesgos es monitorear el efecto real de la implementación de las estrategias y contramedidas de gestión de riesgos para ver si logran los objetivos esperados. Al mismo tiempo, el análisis de riesgos y la tabla de respuesta se pueden revisar de manera oportuna en función del riesgo actual. Los resultados del seguimiento o los nuevos riesgos identificados en el proyecto pueden analizarse y formularse las correspondientes medidas de respuesta a los riesgos [8].
4 Medidas de control y prevención de riesgos
4.1 Etapa de análisis de requisitos
Los requisitos de software son la base para el desarrollo de software y el estándar para la aceptación del software, por lo que la precisión de Requisitos de software Determinar los puntos clave y las dificultades en el desarrollo de proyectos de software. Por un lado, al principio es difícil para los usuarios expresar completa y claramente sus necesidades de funciones del sistema de software, rendimiento, entorno operativo, etc. Sin embargo, a medida que avanza el proyecto, las necesidades del software de los usuarios pueden volverse más claras y numerosas y, a veces, incluso durante la fase de prueba, los usuarios pueden solicitar cambios en los requisitos del software. Esto es inaceptable para los analistas de sistemas y desarrolladores de software. Por otro lado, los usuarios, analistas de sistemas y desarrolladores de software también difieren en cómo describen los requisitos de software. Los usuarios esperan utilizar lenguaje natural para describir los requisitos del software, mientras que los profesionales esperan utilizar lenguajes de descripción estructurados, como diagramas de flujo de datos, diccionarios de datos, etc. Esto no sólo puede evitar la ambigüedad y la incertidumbre que fácilmente causa el lenguaje natural, sino que también facilita el siguiente paso en el trabajo de diseño de software.
Las medidas de prevención y control para este tipo de situaciones incluyen:
(1) Fortalecer la comprensión de la estructura organizacional, los procesos de trabajo y los sistemas de software existentes de la unidad del proyecto.
(2) Los analistas de sistemas necesitan dominar algunas técnicas y métodos para satisfacer las necesidades de los usuarios.
(3) Un software similar que la empresa haya puesto en uso se puede utilizar como prototipo de software y enviarlo a los usuarios para su uso, lo que facilita a los analistas del sistema recopilar las necesidades de los usuarios.
(4) Organizar una reunión de revisión de requisitos en la que participen el patrocinador del proyecto, analistas de sistemas y diseñadores de sistemas para, en última instancia, llegar a un resultado acordado de la etapa de análisis de requisitos: una especificación de requisitos.
(5) Los nuevos requisitos planteados por los usuarios una vez completada la fase de análisis de la demanda se pueden dejar en futuras actualizaciones de la versión. Si el patrocinador del proyecto requiere que se agreguen, podemos discutir con el cliente para ampliar el desarrollo. tiempo y agregar requisitos adicionales.
4.2 Fase de diseño y desarrollo
Si los productos de software se desarrollan utilizando el método de prototipo, aunque los riesgos del proyecto causados por requisitos poco claros se pueden reducir, el método de prototipo utiliza un método de iteración cíclica. Para satisfacer continuamente las necesidades de los usuarios, esto puede hacer que el diseño y desarrollo del software sea costoso y demore más de lo esperado, y en el proceso de modificaciones repetidas, es fácil que los clientes tengan dudas sobre si el proyecto se puede completar con éxito. Para abordar este tipo de riesgo, por un lado, el método del ciclo de vida y el método del prototipo se pueden combinar para complementarse entre sí. En el desarrollo de software, el método del ciclo de vida estructurado es el método principal y, en algunos enlaces, el método del prototipo. se utiliza para obtener rápidamente información sobre comentarios de los usuarios [9]. Por otro lado, comunicarse bien con los clientes e informarles rápidamente sobre el progreso y el proceso de diseño e implementación del software [10].
4.3 Fase de prueba
Un riesgo común al que se enfrenta durante la fase de prueba son los casos de prueba incompletos. Esto puede provocar pruebas incompletas, no detectar errores en el software y reducir el rendimiento del software. Las medidas de prevención y control que se pueden tomar incluyen:
(1) Capacitar a los evaluadores sobre los requisitos del software.
(2) Fortalecer la revisión de casos de prueba.
(3) Si las condiciones lo permiten, se puede invitar a los usuarios a participar en las pruebas de software.
4.4 Fase de implementación Durante la fase de implementación, los clientes pueden enfrentar el riesgo de depender demasiado del personal técnico y ser reacios a aceptar el proyecto. Las medidas de prevención y control tomadas incluyen:
(1) Confeccionar un “Manual de Usuario” estandarizado y fortalecer la capacitación a los usuarios del software.
(2) Hacer un buen trabajo como líder.
(3) Promover el alcance posterior de los servicios de la empresa y la estandarización de la gestión de servicios. También existen ciertos riesgos en el proceso de cambio entre el sistema antiguo y el nuevo. Si los trabajos de conversión carecen de una gestión estandarizada y de garantías de seguridad confiables, inevitablemente causarán graves consecuencias e incluso afectarán el trabajo normal. Ante esta situación, en primer lugar, debemos prestar especial atención a la protección de archivos del sistema original y del nuevo sistema, y fortalecer la gestión del personal y la copia de seguridad de datos; en segundo lugar, debemos ajustar el proceso de cambio del sistema según los requisitos del usuario; el estado de la unidad del proyecto y el progreso del proceso de conversión.
5 Conclusión
Existen varios riesgos en el proceso de desarrollo de software y es necesario implementar una gestión de riesgos para cada riesgo. Se puede ver que la propia gestión de riesgos también puede constituir un subproyecto en un proyecto de software. Formule científicamente planes de gestión de riesgos de proyectos de software y, con el apoyo de los recursos humanos y los fondos necesarios, continúe completando los pasos de gestión de riesgos, como la identificación, el análisis, la respuesta y el seguimiento de los riesgos [11], y haga un buen trabajo en la prevención y el control de riesgos. en cada etapa del desarrollo del proyecto, esto puede lograr el propósito de controlar los riesgos al mínimo, reducir el impacto de los riesgos en los proyectos de software y controlar mejor los costos y el progreso del desarrollo de software.
Referencias
[1] Yang Yiping, Lu Shan. Sistema de información de gestión. Beijing: Machinery Industry Press, 2018
[2] Proyecto de software Suo Hongjun. Análisis e investigación de riesgos. Guía de software, 2017,16(08):128-131
[3] Gu Dan. Investigación sobre la estrategia de adquisición de materiales de la empresa S [tesis de maestría, Shanghai, Shanghai]. 2015
[4] Baidu Wenku. Análisis de riesgos de proyectos de software
[5] Han Zuijiao Fundamentos de ingeniería de software Beijing: Tsinghua University Press, 2009
[6] Wang Hui. Gestión de riesgos de costos y control de análisis durante la etapa de construcción de proyectos de carreteras, 2019(24):259-260
[7] Investigación sobre Mei Xudong. Gestión de riesgos del proyecto de la central nuclear de Karachi de la empresa M [Tesis de maestría, Universidad de Donghua, Shanghai, 2018
[8] Gestión de riesgos basada en el ciclo de vida completo de proyectos de ingeniería internacionales. of Civil Engineering and Management ,2017,34(06):1-9+16
[9] Yuan Longyin Investigación sobre el papel de las bibliotecas en el desarrollo coordinado urbano y rural y los servicios de conocimiento [tesis de maestría] Universidad de Chongqing, Universidad de Chongqing, 2012
[10] Proyecto de análisis de sistemas y diseño de plataforma de análisis integral en universidades [tesis de maestría, Liaoning, 2011]. [11] Zhan Hongyan. Investigación de software sobre estrategias de control de riesgos en la gestión de proyectos, 2019,40(06):230-232
Autor: Yang Hui Unidad: Escuela de Información sobre Transporte, Técnica y Vocacional de Hubei. Facultad de Comunicaciones