Requerimientos: es una necesidad documentada. En otras
palabras, los requerimientos muestran qué elementos y funciones son necesarias
para un proyecto.
2. Documento de especificación de requerimientos: Es en
documento donde se redactan los requerimientos funcionales y no funcionales de
un proyecto estos nos sirven para conocer el modelo del negocio
3. Riesgo: Es la posibilidad de que ocurra un peligro que no
permita el correcto funcionamiento del programa o la elaboración del proyecto.
4. Administración del riesgo: Es el gestionamiento de los riesgos para eliminar o reducir la
posibilidad de que ocurra un peligro que no permita el correcto funcionamiento
del programa o la elaboración del proyecto.
5. Gestión del proceso de desarrollo de sistemas de
software: Es administrar de manera adecuada los recursos con los que se cuentan
para desarrollar el ciclo de vida de software en todas sus etapas desde el
planeamiento,implementacion,pruebas.
.
6. Planeación de los recursos del proyecto de software,
recursos recursos humanos, Procesos y metodologías, y herramientas y equipo: Es
gestionar todos los recursos del proyecto tanto de software como de hadware con
una planeación especifica esta puede ser por diagramas de actividades
7. Calendario o cronograma de actividades: calendario de
trabajo o de actividades es una muy
importante herramienta en la gestión de proyectos. en el se anotan las
actividades y quien lo realizara
8. Gráfica de Gantt: Es mostrar el tiempo de dedicación
previsto para diferentes tareas o actividades a lo largo de un tiempo total
determinado. A pesar de esto, el diagrama de Gantt no indica las relaciones
existentes entre actividades
9. Método de ruta crítica - CPM.:(Crítical Path Method), el
segundo origen del método actual, fue desarrollado también en 1957 en los
Estados Unidos de América, por un centro de investigación de operaciones para
la firma Dupont y Remington Rand, buscando el control y la optimización de los
costos de operación mediante la planeación adecuada de las actividades
componentes del proyecto
10. PERT:(Program Evaluation and Review Technique)
desarrollo por la Armada de los Estados Unidos de América, en 1957, para
controlar los tiempos de ejecución de las diversas actividades integrantes de
los proyectos espaciales, por la necesidad de terminar cada una de ellas dentro
de los intervalos de tiempo disponibles. Fue utilizado originalmente por el
control de tiempos del proyecto Polaris y actualmente se utiliza en to
Tareas de análisis
Este sería un ejemplo de matriz de habilidades:
Este sería un ejemplo de grafica de gantt:
Tareas de análisis
El análisis de requisitos del software se puede subdividir en cinco áreas de esfuerzo:
1. Reconocimiento del problema
2. Evaluación y síntesis
3. Modelado
4. Especificación
5. Revisión
Todos los métodos de análisis se relacionan por un conjunto de principios operativos:
1. Debe representarse y entenderse el dominio de la información de un problema.
2. Deben definirse las funciones que debe realizar el software.
3. Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos),
4. Deben dividirse los modelos que representan información, función y comportamiento de manera que se descubran los detalles por capas (o jerárquicamente).
5. El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación.
Además de los principios operativos mencionados anteriormente, se sugiere un conjunto de principios directrices para la ingeniería de requerimientos:
1. Entender el problema antes de empezar a crear el modelo de análisis.
2. Desarrollar prototipos que permitan al usuario entender como será la interacción hombre-máquina.
3. Registrar el orden y la razón de cada requerimiento,
4. Usar múltiples planteamientos de requerimientos.
5. Priorizar los requerimientos.
Tipos de requisitos
Requisitos funcionales: Describen las interacciones entre el sistema y su ambiente, en forma independiente a su implementación. El ambiente incluye al usuario y cualquier otro sistema externo con el cual interactúe el sistema.
Requisitos no funcionales: Describen atributos sólo del sistema o del ambiente del sistema que no están relacionados directamente con los requisitos funcionales. Los requisitos no funcionales incluyen restricciones cuantitativas, como el tiempo de respuesta o precisión, tipo de plataforma (lenguajes de programación y/o sistemas operativos, etc.)
MATRIZ DE RIESGOS
Como sabéis, el primer paso en la gestión de estos riesgos
suele ser realizar un inventario de todos los riesgos que pueden afectar a
nuestra organización. Una vez obtenido este inventario de riesgos, se deben
analizar para evitar riesgos duplicados o equivalentes, agrupar los riesgos por
áreas para proponer planes de actuación y contingencia conjuntos y facilitar
las tareas de monitorización posteriores.
Pero sobre todo para realizar una priorización que permita
realizar una gestión ordenada y sistemática. Esta priorización suele realizarse
mediante la construcción de una matriz de riesgos, en la que se representen
claramente la probabilidad de ocurrencia de los riesgos y, al mismo tiempo, la
gravedad de las consecuencias que acarrean (impacto o coste).
Este sería un ejemplo:
.
Este eria un ejemplo de cronograma de actividades:
Este sería un ejemplo de ruta critica:
