¡Buscando el formato y modelo del informe de evaluación de necesidades de software! Si tiene puntuaciones altas, envíeme un correo electrónico a la canción 275143598 @ 163.com.
Evaluar los riesgos que pueden surgir por cambios en el entorno externo durante el proceso constructivo. Este artículo proporciona un desglose detallado de los riesgos mencionados.
Analizar y proponer las correspondientes medidas para evitar riesgos.
Debido a que los riesgos solo tendrán un impacto negativo en el desarrollo del proyecto una vez iniciado, la falta de análisis de riesgos o las medidas ineficaces para evitarlos pueden conducir fácilmente al fracaso del desarrollo de software. El análisis de riesgos es una estimación previa. Con ciertos medios técnicos y una rica experiencia, básicamente se puede hacer una estimación más precisa de los riesgos del proyecto y proponer un plan viable después de una cuidadosa consideración.
Resumen de los principales riesgos
Los principales riesgos de cualquier desarrollo de software provienen de dos aspectos, uno es la gestión del software y el otro es la arquitectura del software. Producción de software
El desarrollo de productos es una combinación orgánica de tecnología de ingeniería y creatividad personal. El desarrollo de software es la sabiduría colectiva de la humanidad y se desarrolla de acuerdo con ideas de ingeniería.
Este proceso. La gestión de software es un medio para garantizar la ingeniería del desarrollo de software. La racionalidad de la arquitectura del software depende de la inteligencia colectiva.
Grado y aplicación de la experiencia.
La gestión del software afectará los siguientes factores del software:
Si el software se puede completar dentro del límite de tiempo: el límite de tiempo del software es a menudo el principal factor que restringe la calidad. del software. En muchos casos,
bajo la presión de los plazos, los desarrolladores de software renuncian a la redacción y organización de documentos. Por lo tanto, en las últimas etapas del proyecto, se requiere una gran cantidad de documentación para la coordinación.
El progreso del software es cada vez más lento mientras trabaja. El desarrollo de software se diferencia de otros proyectos en que requiere personas en diferentes etapas de ingeniería.
Diferentes empleados requieren cooperación desde diferentes aspectos, todos los cuales requieren una garantía eficaz de gestión del software.
¿Es exhaustiva la investigación de los requisitos del software? Los requisitos del software son documentos importantes que garantizan que el software refleje correctamente el uso que hace el usuario.
Documentos, discutir los requisitos de software es el punto de partida del desarrollo de software, pero los requisitos de software abarcarán todo el proceso de desarrollo de software. Necesidades de gestión de software
Es necesario controlar y gestionar los cambios. en los requisitos de software. Este aspecto garantiza que los cambios en los requisitos de software no causarán cambios en la ingeniería del software.
Y no se puede completar a tiempo; al mismo tiempo, es necesario garantizar que el software desarrollado pueda ser aceptado por los usuarios. La gestión del software requiere el control de cada etapa del software.
El progreso no puede ser demasiado detallado y hacer perder tiempo, ni demasiado tosco y causar defectos en el software.
Si los medios técnicos de implementación del software pueden cumplir con los requisitos de rendimiento al mismo tiempo: la construcción del software debe utilizarse en el proceso de construcción del software.
Evaluar diversas tecnologías. La tecnología de construcción de software suele ser así: la tecnología más madura a menudo no puede reflejar el mejor rendimiento del software; la primera tecnología avanzada a menudo no es lo suficientemente familiar para las personas y los defectos ocultos no son lo suficientemente claros. La gestión de software es la preparación de planes de desarrollo de software.
Estos factores deben considerarse al mapear y definir hitos, y se deben tomar decisiones de compensación razonables.
Si el sistema de calidad del software se puede garantizar de manera efectiva: cualquier gestión de software que ignore el enlace de supervisión de la calidad del software afectará la producción de software.
Trae enormes riesgos. Para cualquier organización de desarrollo de software, establecer un sistema eficaz de seguimiento de la calidad del software es fundamental. Calidad del software
El sistema de aseguramiento de la calidad es la base para que el desarrollo de software se convierta en un proceso controlable, y también es la base y base para la comunicación entre desarrolladores y usuarios.
La arquitectura del software afecta a los siguientes factores de calidad del software:
Escalabilidad del software: se refiere a la capacidad del software para adaptarse a diferentes entornos de trabajo sin modificaciones. Debido a la contradicción entre el rápido desarrollo del hardware y el largo ciclo de desarrollo del software, la necesidad de actualizaciones de software es muy urgente.
Si las actualizaciones y trasplantes de software son muy difíciles
y el ciclo de vida del software debe ser muy corto, esto significa que los sistemas de software desarrollados con enormes recursos humanos y materiales sólo pueden ejecutarse en hardware o redes de bajo rendimiento.
Ejecutar en Internet, o incluso ser abandonado, genera un gran desperdicio.
Mantenibilidad del software: El mantenimiento del software también es inevitable. Para garantizar una larga vida útil del software, el software debe adaptarse a las necesidades comerciales cambiantes y modificar el software de acuerdo con los cambios en las necesidades comerciales. El costo y el tiempo del ciclo de las modificaciones están directamente relacionados con el software.
Relacionado con el edificio. Una buena arquitectura de software puede incluir los cambios del sistema en la configuración del sistema tanto como sea posible, es decir, la generación de software.
No es necesario modificar el código. Solo necesita realizar las modificaciones apropiadas en el archivo de configuración proporcionado por el sistema y luego recargar el software para ingresar al estado de ejecución.
Se completaron los cambios en algunas funciones del sistema y requisitos de rendimiento. Para cambios importantes, simplemente abra el código fuente y realice modificaciones.
Primero herede el código original y luego reemplace la interfaz de llamada original con nuevas funciones. Esto minimizará la cantidad de cambios de software.
Facilidad de uso del software: La facilidad de uso del software es un factor clave que afecta la aceptación del software por parte de los usuarios. En los productos de software, las configuraciones
son complejas en diseño, poderosas y completas en función, pero no es raro que sean archivadas debido a operaciones complejas. La razón principal es el desarrollo insuficiente de software.
Desarrollar una comprensión a nivel macro de la arquitectura de software. Por otro lado, faltan medios eficaces para determinar los requisitos de software y los requisitos potenciales.
Trabajos de excavación.
Riesgos de la gestión de proyectos
Los riesgos de la gestión de proyectos de software provienen de las características del propio proyecto de software:
Productos de software intangibles: Es difícil medir el El progreso del desarrollo y la calidad del software. Que la calidad cumpla con los requisitos trae dificultades a la gestión del software.
Date prisa.
No existe una forma de proceso absolutamente correcta en la producción de software: lo cierto es que diferentes proyectos de desarrollo de software deben utilizar diferentes métodos.
El mismo proceso de desarrollo de software o el específico, y el proceso de desarrollo de software verdaderamente adecuado es cuando se completa el desarrollo del proyecto de software.
Seguro. Por lo tanto, al comienzo del desarrollo del proyecto, solo podemos tomar decisiones basadas en las características del proyecto y la experiencia de desarrollo, y realizar ajustes continuos durante el proceso de desarrollo.
.
Los grandes proyectos de software suelen ser proyectos "únicos". No hay mucho que sacar de la experiencia pasada. Evitar y controlar la gestión del software
La única forma de asumir riesgos es establecer un sistema de supervisión. Cualquier decisión importante en el desarrollo de un proyecto debe tener aspectos técnicos e incluso usos significativos.
Participación familiar. En este proyecto, la supervisión del proyecto la lleva a cabo el equipo de supervisión de calidad en el desarrollo del proyecto.
El personal generalmente implicado en el desarrollo de software (incluidos directivos y personal técnico) y sus responsabilidades se analizan de la siguiente manera:
Participantes
1 Responsable del proyecto
Responsabilidades principales: comprender la situación general, centrarse en los aspectos comerciales del proyecto y servir como enlace de interfaz para la comunicación formal entre el equipo del proyecto y el cliente.
Líder del proyecto: 1
Principales responsabilidades: Formular el plan de desarrollo del proyecto y la estrategia de desarrollo, participar en el análisis y diseño del sistema central del proyecto y esforzarse por garantizar el desarrollo.
La finalización oportuna del plan y la implementación real de la estrategia de desarrollo.
1 o 2 expertos en el dominio
Responsabilidades principales: durante la etapa de análisis de software, ayudar a los analistas a definir los límites de la implementación del sistema y las funciones implementadas, y realizar puntos de detección específicos.
Revisión de algoritmos, al tiempo que proporciona opiniones de referencia sobre estrategias de prueba e interfaces de operación de software.
Equipo de supervisión de calidad de 1 o 2 personas
Responsabilidades principales: preparar el plan de control de calidad del software y ser responsable de su implementación, controlar la producción de los documentos necesarios y supervisar el proyecto a través de documentos; .
Resultar en la calidad del software durante el proceso de implementación, preparar informes de calidad del software y enviarlos al gerente y al líder del proyecto para su revisión; organizar reuniones de revisión de calidad para
problemas de calidad que surjan; durante el proyecto.
1 o 2 analistas de sistemas
Responsabilidades principales: Cooperar con el líder del proyecto para analizar y diseñar el sistema de software, y preparar el análisis de requisitos de software y el diseño del sistema.
Cerrar el documento. Durante la fase de implementación del software, escriba estrategias de prueba y oriente las pruebas de rendimiento.
Dos o tres programadores
Responsabilidades principales: ayudar a los analistas en el diseño detallado, la implementación del código y las pruebas de caja blanca adecuadas de los sistemas de software.
2 o 3 testers
Responsabilidades principales: Verificar y probar la corrección de los componentes, componentes o sistemas de software implementados, y probar el rendimiento del sistema integrado.
Espera. Redacte informes de prueba e informes estadísticos de prueba y envíelos al equipo de supervisión de calidad para su revisión.
Soporte técnico para 2 o 3 personas
Responsabilidades principales: Cooperar con analistas de sistemas para escuchar las necesidades de los usuarios y realizar revisiones de referencias para análisis de demanda. Trabajar con probadores.
Probar, escribir manuales de operación y ayuda en línea, y brindar servicios de seguimiento después de que el proyecto se entregue a los usuarios.
Equipo de documentación de 1 o 2 personas
Principales responsabilidades: especificación de formato, número de versión y control de los documentos producidos por cada departamento, recuperación de documentos archivados
<; p >El grupo de supervisión debe supervisar la calidad del software. La dotación de personal y la división de responsabilidades adecuadas pueden reducir eficazmente las pérdidas en las últimas etapas del desarrollo de software.Posibilidades de control y dependencia del software del personal clave.
Riesgos de la tecnología de software
Las dos tecnologías de software importantes utilizadas en este sistema son los componentes orientados a objetos y la tecnología de componentes COM basada en Microsoft. Los componentes y la tecnología de componentes son medios técnicos para mejorar la confiabilidad y escalabilidad del software. En términos de madurez tecnológica, no existe.
Existe un riesgo, pero para lograr una buena arquitectura de software y componentes estables, hay un trabajo extra considerable en comparación con los métodos de desarrollo tradicionales.
Es necesario hacerlo, lo que traerá mayores riesgos al cronograma del proyecto.
La forma de evitar y controlar esta parte del riesgo es estimar y especificar continuamente los riesgos durante esta fase del proyecto.
Hitos. Al mismo tiempo, el método de "ejemplo" se utiliza para mejorar la capacidad de los desarrolladores para analizar e identificar componentes y ajustar la cantidad de componentes de manera oportuna.
Y tamaño de partícula.
Riesgos del proceso de software
Riesgos en la etapa de requisitos de software
El desarrollo de software parte de las necesidades de los usuarios. En la mayoría de los casos, las necesidades de los usuarios sólo pueden garantizarse mediante la orientación de los desarrolladores de software.
Solicite que esté completo y luego forme un documento importante "requisitos del usuario" por escrito. El análisis de requisitos consiste más en que los desarrolladores confirmen los requisitos.
El proceso de viabilidad y coherencia requiere una amplia comunicación y confirmación con los usuarios en esta etapa. Cualquier omisión en los requisitos y el análisis de requisitos
Las pérdidas causadas por las fugas se magnificarán paso a paso en las etapas posteriores del sistema de software, por lo que el riesgo es mayor en esta etapa.
Riesgos en la fase de diseño
El objetivo principal del diseño es que las funciones del software reflejen correctamente los requisitos. Se puede ver que los requisitos están incompletos y el análisis de requisitos está incompleto.
Y los errores se multiplican durante la fase de diseño. La tarea principal de la fase de diseño es completar la definición de la arquitectura del sistema para que pueda completarse.
El objetivo establecido de la etapa de demanda; por otro lado, también es probar la consistencia de la demanda y la integridad y corrección del análisis de la demanda.
El riesgo del diseño en sí proviene principalmente del analista del sistema. Los analistas eran demasiado personalizados al diseñar la estructura del sistema y el sistema era escalable.
Una escalabilidad débil supondrá una gran carga para el mantenimiento posterior y los costos de mantenimiento aumentarán considerablemente. El usuario tendrá claro cuánto se utiliza el sistema.
Está muy comprometido e incluso provoca una corta vida útil del software. Por otro lado, la estructura del software es demasiado flexible y versátil, lo que inevitablemente provocará dificultades en la implementación del software.
Con el aumento, la complejidad del sistema aumentará, lo que traerá riesgos durante las fases de implementación y prueba, y la estabilidad del sistema también se verá afectada.
Por otro lado, los cambios en las reglas de negocio, o los cambios en las necesidades de los usuarios y los futuros entornos operativos del software son inevitables.
Se requiere un serio compromiso para determinar si la llamada "versatilidad" del diseño inicial de software puede adaptarse a los cambios en las necesidades y entornos operativos futuros.
. Este compromiso también implica enormes riesgos.
Otro riesgo durante la fase de diseño proviene de la documentación del diseño. Una documentación incompleta no sólo causará dificultades durante la fase de implementación, sino que también tendrá consecuencias catastróficas en las pruebas y el mantenimiento posteriores. Por ejemplo, el sistema de software no podrá actualizarse ni simplificarse en absoluto.
No hay manera de corregir un error.
Riesgos introducidos durante la fase de implementación
En cierto sentido, la implementación de software es la producción de código de software. El código original en sí es parte del documento mientras
se ejecuta en el sistema informático. La estandarización y la legibilidad de la escritura del código fuente son las principales fuentes de riesgo en esta etapa. La producción de código estándar
intentará reducir la proporción de componentes que pertenecen al estilo personal del programador, reduciendo así la integración del sistema.
Riesgo.
Riesgos en la fase de mantenimiento
El mantenimiento del software incluye dos fases de mantenimiento principales, una es el mantenimiento desde el final de la producción del software hasta la fase de operación de prueba
Es a El objetivo principal del mantenimiento de pruebas en un entorno real es descubrir problemas que no se pueden descubrir o que aún no se han descubierto en el entorno de prueba, la otra etapa es cuando la operación del software ya no puede satisfacer las necesidades comerciales del usuario o el funcionamiento del usuario; entorno (incluida la plataforma de hardware, el entorno de software, etc.). ).
El mantenimiento del software puede incluir actualizaciones de versiones de software o trasplantes de software, etc.
Desde la perspectiva de la ingeniería de software, los costos de mantenimiento del software representan aproximadamente el 55-70% del costo total. Cuanto más grande es el sistema, mayor es el costo. Sistema de derechos
Ignorar la mantenibilidad es el mayor riesgo para los grandes sistemas de software. Las reglas comerciales inevitablemente evolucionarán a lo largo de la larga vida útil del software.
El método científico para resolver este problema es actualizar continuamente la versión del sistema de software y expandir gradualmente el sistema garantizando al mismo tiempo la mantenibilidad.
.
Durante el funcionamiento del sistema software, el principal riesgo proviene del funcionamiento incorrecto del sistema de soporte técnico. El método científico es tener un cliente.
El equipo de soporte recopila continuamente los problemas descubiertos durante la operación y enseña soluciones a todos los usuarios del sistema de software.
Tabla de Riesgos del Proyecto
Los riesgos mencionados en la tabla de evaluación de riesgos existen objetivamente en el proceso de desarrollo de proyectos generales. Los coeficientes de riesgo enumerados en la tabla son los siguientes
<. p> se refiere a la probabilidad de que ocurra un proyecto riesgoso sin un análisis en profundidad y una evitación efectiva de los riesgos. Por ejemplo, el diseño de productos de software.El objetivo es funcionar durante diez años y el riesgo de una arquitectura irrazonable es 40, lo que significa que si el sistema no se analiza en profundidad, no se adoptará.
Diseñando la tecnología de software más razonable, la probabilidad de producir un sistema de software sin escalabilidad es del 40%. Dado que la empresa seguirá creciendo debido a la divulgación a los clientes, es extremadamente improbable que el sistema de software cumpla con los requisitos operativos de la empresa dentro de diez años. Esto puede surgir.
La desastrosa consecuencia de la salud es que las empresas deben desarrollar nuevos sistemas desde cero a medida que su negocio crece.
Proporcionar evaluaciones de riesgos a los clientes es una operación rutinaria en línea con la práctica internacional. Por un lado, hace que los clientes sean más conscientes de los riesgos potenciales.
La comprensión muestra la integridad de la empresa. Por otro lado, también se utiliza para estimular y motivar a todos los desarrolladores a implementar estrictamente los estándares de desarrollo.
* * *Supervisar el proceso de desarrollo del proyecto e intentar evitar riesgos.