SDLC Fase Planeación y Definición de Requerimientos

Definición de
Planeación de Requerimientos
Proyecto
Fase de Planeación y Definición

de Requerimientos
ESTÁNDARES PARA DESARROLLO DE SISTEMAS
Preparado por: Ing. Jorge Reyes C. | Metodología SDLC |

Metodología SDLC (Software Development Life Cycle)
Guía para desarrollo de pequeñas y medianas aplicaciones Versión 1.0a
TABLA DE CONTENIDO
Pág.
I. INTRODUCCIÓN …………………………………………………………... 3
Metodología SDLC en cascada ……... 3
Variaciones Permitidas ……... 4
Otros Modelos SDLC ……... 5
II. PROCESOS RECURRENTES DURANTE LAS FASES ……………… 7
Proceso de Reunión Inicial ……... 7
Proceso de Interacción Informal ……... 8
Proceso de Interacción Formal ……... 8
Proceso de Evaluación durante las Fases ……... 9
Proceso de Terminación de las Fases ……... 10
III FASES SDLC ………………………………………………………………. 11
Generalidades ……... 11
Fase de Planeación del Proyecto ……... 12
III.2.1 Objetivo ……... 12
III.2.2 Tareas y Actividades ……... 13
III.2.2.1 Afinar la estrategia de adquisición en ……... 13
el documento que establece los límites
del sistema
III.2.2.2 Analizar el Programa del Proyecto ……... 13
III.2.2.3 Crear los Procesos Internos ……... 13
III.2.2.4 Creación del Equipo de Oficina del ……... 13
Proyecto.
III.2.2.5 Establecer acuerdos con las partes ……... 14
interesadas
III.2.2.6 Desarrollar el Plan de Administración ……... 14
del Proyecto
III.2.2.7 Desarrollar el Plan de Administración ……... 14
de
Ingeniería de los Sistemas
III.2.2.8 Revisar la factibilidad de las ……... 14
Alternativas del Sistema
III.2.2.9 Estudiar y Analizar las Implicaciones ……... 14
de
Seguridad
III.2.2.10 Planear la Solicitud, Selección y ……... 14
Adjudicación
III.2.2.11 Desarrollar el CONOPE ……... 14
III.2.2.12 Revisar documentación previa ……... 14
III.2.3 Roles y Responsabilidades ……... 15
III.2.4 Entregables ……... 15
PÁGINA 1
III.2.4.1 Plan de Adquisición ……... 15

III.2.4.2 Plan de Administración de la ……... 15
Configuración
III.2.4.3 Plan de Aseguramiento de Calidad ……... 16
III.2.4.4 Concepto de Operaciones (CONOPE) ……... 16
III.2.4.5 Plan de Seguridad del Sistema ……... 16
III.2.4.6 Plan de Administración del Proyecto ……... 16
III.2.4.7 Plan de Verificación y Validación ……... 16
III.2.4.8 Plan de Administración de Ingeniería ……... 17
del Sistema (PAIS)
III.2.5 Tópicos de Consideración ……... 17
III.2.5.1 Auditorías de Seguimiento ……... 17
III.2.5.2 Acceso basado en perfiles de ……... 17
seguridad
III.2.6 Actividad de Revisión de la Fase ……... 17
Fase de Definición de Requerimientos ……... 18
III.3.1 Objetivo ……... 18
III.3.2 Tareas y Actividades ……... 18
III.3.2.1 Analizar y documentar requerimientos ……... 18
III.3.2.2 Desarrollar Planes y Criterios de
Prueba
III.3.2.3 Desarrollar un Documento de Control
de la Interface
III.3.2.4 Revisar y Evaluar Requerimientos
III.3.2.5 Conducir una Revisión Funcional
III.3.2.6 Revisar la Documentación Previa
III.3.3 Roles y Responsabilidades
III.3.4 Entregables
III.3.4.1 Documento de Requerimientos
Funcionales
III.3.4.2 Plan Maestro de Evaluación y Pruebas
III.3.4.3 Documento de Control de la Interface
III.3.4.4 Convenio de Confidencialidad y
Evaluación del Impacto a la Privacidad
III.3.5 Tópicos de Consideración
III.3.6 Actividad de Revisión de la Fase
Apéndice A-1 Contenido de un Plan de Adquisiciones
Apéndice A-2 Contenido de un Plan de Administración de la
Configuración
Apéndice A-3 Contenido de un Plan de Aseguramiento de
Calidad
Apéndice A-4 Contenido del Concepto de Operaciones
Apéndice A-5 Contenido de un Plan de Seguridad del Sistema
Apéndice A-6 Contenido de un Plan de Administración del
Proyecto
Apéndice A-7 Contenido de un Plan de Verificación y
Validación
PÁGINA 2
Apéndice A-8 Contenido de un Plan de Administración de

Ingeniería del Sistema
I. INTRODUCCIÓN
Este documento describe el ciclo de vida de desarrollo de un Sistema enfocado a

esfuerzos para bases de datos de pequeñas y medianas. En este capítulo se
presentan generalidades de la metodología y modelos de ciclo de vida alternos.
Los tres siguientes capítulos describen los procesos internos que son comunes a
través de las fases de planeación, análisis de requerimientos y diseño. En estas
etapas veremos las entradas, salidas y procesos de cada una de ellas.
I.1 Metodología SDLC en cascada.
Los proyectos de desarrollo de software de bases de datos de pequeñas a

medias, son generalmente administrados en seis fases:
Planeación
Planeación del
del
Proyecto
Proyecto
Definición de
Definición de
Requerimientos
Requerimientos
Diseño
Diseño
Desarrollo
Desarrollo
Intergración
Intergración yy
Pruebas
Pruebas
Instalación
Instalación
PÁGINA 3 yy
Aceptación
Aceptación
La relación entre cada fase puede ser descrita como una cascada, donde la
salida de una fase específica sirve de entrada a la siguiente fase.
Durante cada fase, información adicional es obtenida o desarrollada, combinada
con sus entradas y usada para producir los entregables de la fase.
Es importante remarcar que la información adicional es limitada en alcance ya
que nuevas ideas podrían tomar forma en el proyecto en direcciones no
anticipadas por el conjunto inicial de requerimientos de alto nivel y no ser
incorporadas dentro del proyecto. Sin embargo, ideas como nuevas capacidades
o características que están fuera del alcance se preservan para consideración
posterior.
Después que el proyecto haya sido aprobado, el Grupo de Desarrollo Primario
(GDP) y el Grupo de Usuarios-Finales Primario (GUFP) en coordinación con otros
clientes y equipo de desarrolladores deben desarrollar una lista de
recomendaciones para mejorar los procesos actuales del negocio y obtener una
aplicación más completa y enriquecida.
PROTOTIPOS
El equipo de desarrollo de software, para aclarar los requerimientos y/o

elementos de diseño, podría generar prototipos de pantallas, reportes y
especificaciones de procesos. Sin embargo, algunos de los prototipos podrían ser
muy substanciales, generalmente a las acciones similares a una puesta de
película… todo luce bien por enfrente,… pero no hay nada por detrás.
Cuando un prototipo es generado, los desarrolladores producen el mínimo de
código necesario para aclarar los requerimientos o elementos de diseño bajo
consideración. No se realizan esfuerzos para el cumplimiento con código
estándar, generación de errores o integración tablas de la base de datos o
módulos. El objetivo de realizar el prototipo es planear lo que sería el módulo
funcional de manera anticipada previendo lo que deberá registrarse en el
documento de diseño final del sistema o aplicación.
Por éstas razones, los prototipos nunca deberán ser considerados para uso de
negocios y serán generalmente direccionados de una forma para prevenirnos de
que sean usados como módulos de producción por usuarios finales.
I.2 Variaciones permitidas.
En algunos casos, información adicional se obtiene para el equipo de desarrollo

cuando se requieren cambios en las salidas de fases previas. En estos casos, el
esfuerzo de los desarrolladores usualmente se suspenderá hasta que los
cambios sean conciliados con el diseño actual, y los nuevos resultados son
pasados hacia las fases posteriores hasta que el proyecto encuentre el punto
donde fue suspendido.
PÁGINA 4
El GDP y el GUFP podrían, a discreción, permitir que el esfuerzo de desarrollo

continúe mientras los entregables en fases previas sean actualizados en los
casos donde los impactos sean mínimos y estrictamente limitados en los
alcances. En este caso, los cambios pueden ser cuidadosamente monitoreados
para asegurar que sus impactos sean apropiadamente administrados.
I.3 Otros modelos de SDLC.
El modelo de cascada es uno de los 3 más comunes en los modelos de ciclo de

vida citados. Otros modelos incluyen el modelo Espiral y el modelo de Desarrollo
de Aplicaciones Rápidas RAD (Rapid Application Development), frecuentemente
referenciado como el modelo de Prototipos.
Modelo ESPIRAL
El modelo espiral empieza con un paso inicial mediante un ciclo de vida en

cascada, usando un subconjunto del total de requerimientos a fin de desarrollar
un prototipo robusto. Después de un período de evaluación, el ciclo de vida es
iniciado otra vez, agregando nuevas funcionalidades y reconformando el próximo
prototipo. Este proceso continúa, con un prototipo que empieza a crecer y crecer
en cada iteración, creando la espiral.
La teoría de este modelo es que el conjunto de requerimientos se va
fundamentando jerárquicamente de manera natural, con funcionalidades
edificadas desde el primer esfuerzo, sin embargo esto suena práctico para
sistemas donde los problemas/oportunidad son definidos desde el inicio, tal como
el modelado y simulación de software. Los proyectos de bases de datos
orientados a negocios no son objeto de estas ventajas. La mayoría de las
funciones en una solución de base de datos es esencialmente independiente una
de otra, sin embargo se podría hacer usar para datos comunes.
Modelo de Desarrollo de Aplicaciones Rápidas RAD (Rapid Application

Development).
RAD es, en esencia, el tratar de comprar antes de desarrollar software. La teoría

de este modelo es que el usuario puede evaluar cuando examina un sistema o
aplicación ya existente. El ciclo de desarrollo basado en RAD tiene como
resultado un bajo nivel de rechazo cuando la aplicación es colocada en
producción, pero su éxito viene más frecuentemente y de manera directa a los
gastos de un largo costo y tiempo de implementación de un proyecto.
Las ventajas con el RAD son posibles con ventajas significativas en ambientes de
desarrollo de software que permiten una generación rápida de ventanas e
interfaces de usuario futuras.
PÁGINA 5
El usuario final tendrá la ventaja de trabajar con pantallas en línea como si

estuviera en un ambiente de producción, pero estas ventajas podrían representar
estar atrapado también en un significante número de errores al usar este
proceso.
La desventaja del RAD es estar propenso a que el usuario final propicie cambios
en los alcances establecidos para los desarrolladores. Las fallas más comunes
en este modelo es que tanto desarrolladores como usuarios finales han sido
atrapados en un ciclo de cambios sin fin, con usuarios preguntando por más y
más requerimientos, y los desarrolladores tratando de satisfacerlos. Los
participantes pierden el enfoque de las metas para producir lo básico, sin usar el
sistema a su favor.
PÁGINA 6
II. PROCESOS RECURRENTES DURANTE LAS FASES
Cada una de las fases de los ciclos de vida de los sistemas sigue 5 procesos
internos de forma estándar. Estos procesos establecen un patrón de
comunicación y documentación con la intención de familiarizar a todos los
participantes de la situación actual y por ende minimizar los riesgos del plan de
proyecto actual. La descripción de la etapa inicial es proporcionada para evitar
descripciones repetitivas de los procesos internos en cada una de las
descripciones de las fases.
Los 5 procesos estándar son: Reunión Inicial, Interacción Informal, Interacción
Formal, Evaluación durante las Fases, Terminación de las Fases.
Reunión Inicial
Reunión Inicial
Interacción
Informal
Informal
Interacción
Formal
Evaluación
durante las
durante las
II.1 Proceso de Reunión Inicial.
Fases
Cada fase es iniciada por una reunión inicial, cuyo propósito es revisar las salidas
de previas fases, ir sobre cualquier entrada adicional requerida por alguna Terminación
fase
en particular, examinar de manera anticipada actividades y salidas requeridas de las Fases
para la fase actual, revisar y actualizar el programa calendarizado del proyecto y
verificar algún tema específico abierto.
El GDP es responsable de preparar la agenda y materiales a ser presentados en
la reunión. Todos los participantes son invitados para atender estas reuniones
para cada fase del proyecto.
PÁGINA 7
PÁGINA 8
II.2 Proceso de Interacción Informal.
La mayoría del trabajo creativo en las diversas etapas ocurre aquí. Los
participantes trabajan de manera conjunta para obtener la información adicional y
refinar las entradas para obtener los entregables preliminares.
Las actividades para esta etapa pueden incluir entrevistas, reuniones, generación
de prototipos y formas de correspondencia electrónica. Todas estas
comunicaciones son consideradas informales, y no son registradas como
minutas, documentos de registros, software controlado o memorándums oficiales.
La intención con este proceso es fomentar, más que inhibir el proceso de

comunicación. Este proceso concluye cuando la mayoría de los participantes
acuerdan que el trabajo es sustancialmente completo y es el tiempo de evaluar
los entregables preliminares para una revisión formal y sus respectivos
compromisos.
II.3 Proceso de Interacción Formal.
En este proceso, los entregables preliminares son generados para una revisión
formal y sus respectivos compromisos. Cada entregable preliminar es introducido
durante el proceso de la reunión inicial, y se asume que satisface una o más
salidas para la fase actual. A cada entregable preliminar le es otorgado un
número de versión y colocado bajo la administración de control de cambios.
Cada integrante de los equipos, bajo la perspectiva de su función, revisa los
entregables preliminares, teniendo la responsabilidad de reportar errores
encontrados y notas que deben ser notificados al GDP vía correo electrónico.
El GDP en turno, consolida estos reportes dentro de una serie de compromisos
asociados con una versión específica de un entregable. La persona o grupo
encargado de desarrollar el entregable trabajará para resolver cada tópico, luego
liberará otra versión del entregable para revisión. Este proceso tendrá un proceso
iterativo hasta que todos los tópicos sean resueltos. No hay un formato formal
con firmas para validar esta parte del proceso, pero se puede instituir para
controlar los cambios.
La intención de esta etapa es fomentar la revisión y la retroalimentación para
mejorar la calidad del producto final.
A discreción de los GDP y GUFP, ciertos tópicos pueden ser reservados para una
resolución en fases posteriores del ciclo de desarrollo. Estos tópicos no son
asociados a un entregable específico y son marcados como tópicos abiertos. Los
tópicos abiertos son revisados durante las reuniones iniciales de las
subsecuentes fases del proyecto. Una vez que cada tópico abierto se vaya
resolviendo para un entregable específico hasta completarse, una versión final
del entregable preliminar será preparada para entregarse al GDP.
PÁGINA 9
Cuando se ha recibido un preliminar final con todas sus salidas requeridas para una fase
específica, el GDP revisa el paquete final de entregables, la cantidad de trabajo gastado
contra lo programado en el proyecto y usa esta información para actualizar el Plan de
Proyecto.
El Plan de Proyecto actualizado incluye el detalle de tareas, su calendarización y el nivel
estimado de esfuerzo para la siguiente fase.
Para poder continuar a la siguiente fase, el Plan de Proyecto es actualizado para incluir un
alto nivel estimado de calendario y de esfuerzo, basado en la experiencia actual del
proyecto.
La actualización del Plan de Proyecto y su programa de actividades es un entregable
importante para cada fase del proyecto. El GDP notifica a todo el equipo la actualización
del Plan de Proyecto y su programa para revisión y comentarios de forma iterativa, hasta
que todos los tópicos hayan sido resueltos.
Una vez que el Plan de Proyecto y su programa han sido finalizados, todos los entregables
finales de la fase actual son publicados a todos los participantes del proyecto, y el GPD
inicia el siguiente proceso.
II.4 Proceso de Evaluación durante las Fases.
Este es el proceso de revisión y aseguramiento formal de calidad para cada fase. En un

proyecto pequeño de desarrollo de software, los entregables para cada fase son
generalmente pequeños y suficientes que no impactan el costo para su revisión a fin de
cumplir con los estándares de calidad antes de que los entregables sean completamente
liberados. Como resultado, solamente una evaluación durante cada fase es programada.
Este proceso es iniciado cuando el GDP calendariza una evaluación durante la fase junto
con el grupo encargado para el aseguramiento de la Calidad de los Productos.
El grupo de Calidad, conformado generalmente por un grupo independiente, un grupo
perteneciente al cliente y un experto técnico o especialista en la materia, revisa
formalmente cada entregable para emitir un juicio en referencia a la calidad y validación
del producto trabajado, validando el cumplimiento de los estándares de calidad definidos
para cada entregable. Generalmente los estándares de calidad son definidos en la Sección
de Aseguramiento de Calidad del Software del Plan de Proyecto.
Los inspectores de calidad por parte del cliente verifican la integridad y exactitud de los
entregables en términos de la funcionalidad deseada del software. El inspector, experto en
la materia determina si los entregables están de acuerdo a las especificaciones de la
información técnica definida en los procesos establecidos.
El inspector de control de calidad se encarga únicamente de verificar la integridad
y cumplimiento de la entrega con el estándar de clase para el entregable
asociado. El inspector puede hacer recomendaciones, pero no puede cambiar la
naturaleza formal de los estándares definidos para los entregables. Cada
inspector de calidad sigue un check-list formal durante la revisión, indicando su
nivel de concurrencia con cada ítem en su check-list.
Un entregable se considera aceptado cuando cada inspector indica una
considerable concurrencia con el contenido de los entregables y de la revisión de
cada ítem en el check-list.
PÁGINA 10
Una vez que los tres equipos de inspectores de calidad indiquen una
concurrencia considerable con el entregable, el GDP liberará un reporte de
evaluación final e iniciará el siguiente proceso.
II.5 Proceso de Terminación de las Fases.
La etapa de terminación de una fase es el vehículo para asegurar la concurrencia

de la mayoría de los participantes a fin de continuar el proyecto y moverse a la
siguiente fase del desarrollo. El propósito de esta etapa es permitir a todo el
personal involucrado con el proyecto a revisar el Plan de Proyecto actual y los
entregables de la fase, proporcionar también un foro para plantear cuestiones y
preocupaciones, y asegurar que exista un plan de acción aceptable para todos
los tópicos abiertos.
El proceso inicia con la notificación del GDP a todos los participantes del proyecto
de que los entregables de la fase actual han sido terminados y aprobados
mediante el reporte de Aseguramiento de Calidad. El GDP inmediatamente
programa una revisión con los ejecutivos del proyecto y el GUFP. Todos los
participantes interesados son invitados para atender la revisión.
Esta etapa finaliza con la recepción de la concurrencia de quienes aprueban que
se proceda a la siguiente fase. Esto generalmente se complementa con el
levantamiento de una minuta como un documento formal de registro y que deberá
ser firmada por el ejecutivo del proyecto, el GUFP y el GDP.
PÁGINA 11
III. FASES SDLC
III.1 GENERALIDADES
Las seis fases del SDLC son diseñadas para ir construyendo una sobre la otra,
tomando las salidas de la etapa anterior, agregando esfuerzos adicionales y
produciendo resultados que aprovechan el esfuerzo anterior y son directamente
trazables a las fases anteriores.
Este enfoque de arriba hacia abajo pretende dar a lugar un producto de calidad
que satisfaga las intenciones iniciales del cliente.
Planeación del
Planeación del
Proyecto
Proyecto
Definición de
Definición de
Requerimientos
Requerimientos
Diseño
Diseño
Desarrollo
Desarrollo
Intergración
Intergración yy
Pruebas
Pruebas
Instalación
Instalación yy
Aceptación
Aceptación
Demasiados esfuerzos de desarrollo de software se conjugan cuando el equipo de
desarrollo y personal de los clientes se ven atrapados en las posibilidades de la
automatización. En lugar de enfocarse en características de alta prioridad, muchas veces el
equipo se ve inmerso en un mar de querer hacer utopías, características que no son
esenciales para resolver los problemas, pero por sí mismas son altamente atractivas. Esta
es la causa raíz de que un gran porcentaje de esfuerzos de desarrollo son abandonados.
Estas premisas son la razón principal para que el equipo de desarrollo utilice la
metodología en cascada de SDLC.
PÁGINA 12
III.2 FASE DE PLANEACIÓN DEL PROYECTO.
III.2.1 OBJETIVO
Muchos de los planes esenciales para el éxito de un proyecto están creados en

esta fase; los planes creados son revisados y actualizados a través de las fases
remanentes del SDLC. En la fase de Planeación, el concepto se ha desarrollado
aún más para describir cómo funcionará el negocio una vez que el sistema
aprobado es implementado y evaluado, y cómo el sistema tendrá un impacto en
los empleados y la seguridad de los clientes. También se asegura que los
productos y / o servicios proporcionen la capacidad necesaria en tiempo y dentro
del presupuesto, los recursos del proyecto, las actividades, los horarios, las
herramientas, y que las revisiones sean definidas. Además, las certificaciones de
seguridad y las actividades acreditadas comienzan con la identificación de los
requerimientos de seguridad del sistema y la ejecución de una evaluación de
vulnerabilidad de alto nivel.
Fase de
Planeación
del Proyecto
Plan de
Plan de Gestión de
Aseguramiento de Plan de Proyecto y
la Configuración del
Calidad del Programa
Software
Sotware
Principales Entregables de la Fase de Planeación

La sección más crítica en el Plan de Proyecto es una lista de requerimientos de los
productos clasificados de alta prioridad, también conocidas como metas u objetivos. Todos
los requerimientos de productos de software para ser desarrollados durante la Fase de
Definición de Requerimientos fluyen de una o más de estas metas. La mínima información
para cada meta consiste de un título y una descripción textual, además de toda la
información adicional y documentos externos que puedan ser incluidos.
Las salidas de la Fase de Planeación del Proyecto son específicamente: El Plan de
Administración de Configuración, El Plan de Aseguramiento de Calidad y El Plan de
Proyecto y su Cronograma de Tiempo, junto a una lista detallada de actividades
programadas para la Fase de Requerimientos que viene, y el esfuerzo de alto nivel que
implica para las etapas de salida.
PÁGINA 13
III.2.2 TAREAS Y ACTIVIDADES
Las siguientes tareas son ejecutadas como parte de la Fase de Planeación del
Proyecto. El resultado de estas actividades es plasmado en varios planes de
proyecto y documentos solicitados.
III.2.2.1 Afinar la estrategia de adquisiciones en el documento que establece

los límites del Sistema.
Afinar el papel de los proveedores de desarrollo de sistemas durante las fases
subsecuentes. Por ejemplo: Una opción estratégica podría incluir la participación
activa de los proveedores del sistema en la Fase de Análisis de Requerimientos.
En este caso, la Fase de Planeación debe incluir una planeación completa, la
preparación de la solicitud, y selección de la fuente que proveerá la participación
de los proveedores (la adjudicación del contrato debe ser la primer actividad de la
siguiente fase). Si son contratados proveedores, documentos serán requeridos y
esenciales como parte de la planeación de adquisiciones.
III.2.2.2 Analizar el calendario o cronograma de tiempo del proyecto.
Analizar y afinar le calendario del proyecto, tomando en cuenta los riesgos y
recursos disponibles. Desarrollar un programa detallado para la Fase de Análisis
de Requerimientos y las Fases subsecuentes.
III.2.2.3 Crear procesos internos.

Crear, obtener, adaptar y/o adoptar la administración interna, ingeniería,
administración de negocios y procesos internos para la administración de
proveedores tal que sean usados para la oficina del proyecto y para todas las
fases del ciclo de vida del desarrollo del sistema. Esto podría dar lugar a la
creación de equipos o grupos de trabajo para tareas específicas, (por ejemplo,
aseguramiento de calidad, administración de configuración, control de cambios).
Planificar, articular y obtener la aprobación de los procesos resultantes.
III.2.2.4 Creación del Equipo de Oficina del Proyecto.

Conjuntar el personal de la oficina del proyecto con las habilidades necesarias a
través de la amplia gama de disciplinas técnicas y de negocios. Seleccionar los
miembros del Consejo Técnico de Revisión y documentar los roles y
responsabilidades. Si es necesario, solicitar y otorgar contratos de soporte para
proporcionar necesidades de servicios no personales que no están disponibles a
través de recursos de la empresa.
PÁGINA 14
III.2.2.5 Establecer acuerdos con las partes interesadas.

Establecer las relaciones y los acuerdos con las organizaciones internas y
externas tal que sean involucradas con el proyecto. Estas organizaciones podrían
incluir agencias, oficinas de supervisión, agencias para suministro de personal,
organizaciones de auditorías internas y externas, y proveedores de recursos en
general (como gente, espacios, equipamiento de oficina, comunicaciones, etc.)
III.2.2.6 Desarrollar el Plan de Administración del Proyecto.
Planear, articular y obtener la aprobación de la estrategia para ejecutar los
aspectos administrativos del proyecto (Plan de Administración del Proyecto).
Desarrollar una estructura de trabajo desglosada y detallada del proyecto.
III.2.2.7 Desarrollar el Plan de Administración de Ingeniería de los Sistemas.
Planear, articular y obtener la aprobación de la estrategia para ejecutar los
aspectos administrativos técnicos del proyecto (PAIS). Desarrollar una estructura
de trabajo desglosada y detallada del proyecto.
III.2.2.8 Revisar la factibilidad de las Alternativas del Sistema.
Revisar y validar la factibilidad de las alternativas del sistema desarrolladas
durante las fases previas (Estudio de Factibilidad). Confirmar la vigencia de la
necesidad.
III.2.2.9 Estudiar y Analizar las Implicaciones de Seguridad.
Estudiar y analizar las implicaciones de seguridad de las alternativas técnicas y
asegurar el direccionamiento de todos los aspectos o restricciones impuestas por
los requerimientos de seguridad (Plan de Seguridad del Sistema).
III.2.2.10 Planear la Solicitud, Selección y Adjudicación.
Durante esta fase o subsecuentes fases, puede ser requerido bajo requerimiento
de algún organismo regulador en materia de adquisiciones, el plan de solicitud,
selección y adjudicación de esfuerzos contratados y basados en las estrategias
seleccionadas en el plan estructurado de trabajo. Cuando sea apropiado, ejecutar
la solicitud y selección del soporte para proveedores del sistema en fases
posteriores.
III.2.2.11 Desarrollar el CONOPE.
Basado en las alternativas del sistema y con las entradas de la comunidad de
usuarios finales, desarrollar el concepto de cómo el sistema será usado,
mantenido y operado. Este el Concepto de Operaciones (CONOPE).
III.2.2.12 Revisar documentación previa.
Revisar documentación de previas fases y actualizarla si es necesario.
PÁGINA 15
III.2.3 ROLES Y RESPONSABILIDADES
PUESTO RESPONSABILIDAD
El jefe de proyecto asigna los recursos, gestiona las prioridades,

coordina las interacciones con los clientes y usuarios, y mantiene al
equipo del proyecto enfocado en los objetivos. El jefe de proyecto
Jefe de Proyecto también establece un conjunto de prácticas que aseguran la integridad
y calidad de los artefactos del proyecto. Además, el jefe de proyecto se
encargará de supervisar el establecimiento de la arquitectura del
sistema. Gestión de riesgos. Planificación y control del proyecto.
Captura, especificación y validación de requisitos, interactuando con el

Analista de cliente y los usuarios mediante entrevistas. Elaboración del Modelo de
Sistemas Análisis y Diseño. Colaboración en la elaboración de las pruebas
funcionales y el modelo de datos.
Construcción de prototipos. Colaboración en la elaboración de las

Programador pruebas funcionales, modelo de datos y en las validaciones con el
usuario
Gestión de requisitos, gestión de configuración y cambios, elaboración

Ingeniero de del modelo de datos, preparación de las pruebas funcionales,
Software elaboración de la documentación. Elaborar modelos de implementación
y despliegue.
Ejemplo de Roles y Responsabilidades en un proyecto.
III.2.4 ENTREGABLES.
III.2.4.1 Plan de Adquisiciones (PA).
Este documento muestra como todos los recursos humanos, servicios de soporte
de proveedores, hardware, software y capacidades de telecomunicaciones son
adquiridos y proporcionados durante la vida del proyecto. El plan es desarrollado
para asegurar y ayudar a que los recursos requeridos sean obtenidos y
disponibles cuando sean necesarios. El apéndice A-1 detalla el tipo de
información que debe ser incluido en el Plan de Adquisición.
III.2.4.2 Plan de Administración de la Configuración (PAC).
Este plan describe el proceso que será usado para identificar, administrar,
controlar y auditar la configuración del proyecto. El plan también debe definir la
estructura de la gestión para la configuración, roles, y responsabilidades a ser
usadas en la ejecución de esos procesos. El apéndice A-2 proporciona un
formato para la creación de un PAC.
PÁGINA 16
III.2.4.3 Plan de Aseguramiento de Calidad (PAQ).
El PAC documenta lo que el producto entregable debe satisfacer bajo acuerdos

contractuales, encontrar o exceder los estándares de calidad, y cumplir con los
procesos aprobados del SDLC. El apéndice A-3 proporciona un formato para la
creación de un PAQ.
III.2.4.4 Concepto de Operaciones (CONOPE).
El CONOPE es un documento de requerimientos de alto nivel que proporciona un

mecanismo para que los usuarios describan sus expectativas del sistema.
Información que debe ser incluida en el documento CONOPE es mostrado en el
apéndice A-4.
III.2.4.5 Plan de Seguridad del Sistema (PSS).
Un plan formal detalla el tipo de seguridad que en la computadora es requerido

para el nuevo sistema, basado en el tipo de información que empieza a ser
procesada y el grado de sensibilidad. Usualmente los tipos de sistemas que
contienen información personal son más cercanamente resguardados que la
mayoría. Un índice es proporcionado en el apéndice A-5 detallando la
información que debe ser incluida en el PSS.
III.2.4.6 Plan de Administración del Proyecto (PAP).
Este plan debe ser preparado para todos los proyectos, independientemente del
tamaño o alcance. Documenta el alcance del proyecto, las tareas, el cronograma,
recursos asignados y la interrelación con otros proyectos.
El plan proporciona más detalles sobre las unidades funcionales involucradas,
tareas laborales requeridas, costos y el programa para la medición de
desempeño, hitos y calendarios o programas de revisión. Revisiones al PAP
ocurren al final de cada fase y en cuanto la información viene a ser disponible. El
PAP debe ser direccionado a las actividades de seguimiento para la
administración del proyecto. Ver el apéndice A-6 para la creación de un PAP.
III.2.4.7 Plan de Verificación y Validación (PVV).
El PVV describe la estrategia de pruebas que serán usadas a través de las fases
del ciclo de vida. El plan debe incluir descripciones del contratista que realizará
las pruebas y evaluaciones independientes apropiadas y requeridas para el
proyecto. El apéndice A-7 proporciona un índice para la creación de un PVV.
PÁGINA 17
III.2.4.8 Plan de Administración de Ingeniería del Sistema (PAIS).
El PAIS describe el proceso de ingeniería del sistema a ser aplicado al proyecto,

asigna actividades organizacionales específicas para los esfuerzos técnicos y
referencias de procesos técnicos a ser aplicados al esfuerzo. Información que
debe ser incluida en el PAIS son mostrados en el Apéndice A-8.
III.2.5 TÓPICOS DE CONSIDERACIÓN
III.2.5.1 Auditorías de Seguimiento
El objetivo de las auditorías de seguimiento es el de detectar problemas de

rendimiento, violaciones de seguridad y fallas en las aplicaciones. Incluye la
capacidad de dar seguimiento a la actividad desde que el usuario se da de alta
en el sistema (log-in), se identifica el equipo y su localización física, hasta que se
da de baja de la aplicación (log-off). Identificar cualquier evento que deba ser
mantenido respecto al sistema operativo, a la aplicación y a la actividad del
usuario sobre la aplicación.
III.2.5.2 Acceso basado en perfiles de seguridad
Mucho antes de permitir el acceso de forma individual al sistema, se debe

determinar y conocer las necesidades que permitan identificar los accesos
permitidos dentro del sistema para cada usuario. Por esta razón se deberán crear
perfiles de seguridad que garanticen la seguridad e integridad de la información.
Los perfiles de seguridad garantizan que a cada usuario le sea permitido acceder
solamente a las áreas para ejecutar adecuadamente su trabajo.
III.2.6 ACTIVIDAD DE REVISIÓN DE LA FASE
Una vez completadas las actividades de la Fase de Planeación y de recibir los

recursos para la próxima fase, el Administrador del Proyecto, en conjunto con su
equipo de trabajo deben preparar y presentar una revisión del status del proyecto
para quienes tomarán las decisiones y los interesados en el proyecto.
Las revisiones deben direccionar: (1) El status de las actividades de la Fase de

Planeación (2) El status planeado de las subsecuentes fases del ciclo de vida
(con un significante detalle para la próxima fase, para incluir el status de acciones
pendientes), (3) Status de la disponibilidad de los recursos, y (4) La evaluación de
riesgo de adquisiciones para las subsecuentes fases dando la estrategia de
adquisición planeada.
PÁGINA 18
III.3 FASE DE DEFINICIÓN DE REQUERIMIENTOS.
III.3.1 OBJETIVO
La Fase de Análisis de Requerimientos empezará cuando la documentación de la

fase anterior ha sido aprobada o por dirección de la administración. La
documentación relacionada a los requerimientos del usuario de la Fase de
Planeación debe ser usada como base para iniciar un mayor análisis de los
requerimientos de los usuarios y el desarrollo a detalle de los requerimientos. El
análisis puede revelar nuevos conocimientos del negocio y de funciones que
deben ser incluidas en los requerimientos de los sistemas de información, y en
tales casos los entregables deben ser revisados para reflejar este análisis.
Durante la Fase de Análisis de Requerimientos, el sistema se definirá con más
detalle en lo que respecta a las entradas del sistema, procesos, salidas e
interfaces. Esta definición de procesos ocurre a nivel funcional. El sistema se
describe en términos de las funciones que se deben realizar, no en términos de
programación de sistemas, archivos y flujos de datos. El énfasis de esta fase es
determinar qué funciones se deben realizar en lugar de cómo llevar a cabo esas
funciones.
III.3.2 TAREAS Y ACTIVIDADES
Las siguientes tareas son ejecutadas durante la Fase de Análisis de

Requerimientos. Las tareas y actividades ejecutadas dependen de la naturaleza
del proyecto.
III.3.2.1 Analizar y documentar requerimientos
En primer lugar consolidar y afirmar las necesidades del negocio. Analizar el uso
previsto del sistema y especificar los requisitos funcionales y de datos. Conectar
los requisitos funcionales para las necesidades de datos. Definir los requisitos
funcionales y de sistema que no son fáciles de expresar en datos y modelos de
procesos. Afinar la arquitectura de alto nivel y el diseño lógico para apoyar el
sistema y los requisitos funcionales.
Un modelo lógico es construido tal que describe los procesos fundamentales y
necesidades de datos para soportar la funcionalidad de negocios deseada. Este
modelo lógico mostrará como los procesos interactúan y como los procesos
crean y usan datos. Estos procesos serán derivados de las descripciones de
actividad proporcionadas en el documento de Alcances del Sistema.
Funciones y tipos de entidades que figuran en el modelo lógico se amplían y
perfeccionan a las previstas en la Fase de Desarrollo de Concepto. Los usuarios
finales y expertos en el área de negocios evaluarán todos los procesos
identificados y estructuras de datos para garantizar la precisión, la consistencia
lógica y validación de que están completos. Un análisis de las actividades de
PÁGINA 19
negocio y estructuras de datos se lleva a cabo para producir diagramas entidad-

relación, diagramas de jerarquía de procesos, diagramas de dependencia de los
procesos y la documentación asociada. Un análisis de la interacción se lleva a
cabo para definir la interacción entre las actividades de negocio y datos de
negocios. Este análisis produce la lógica de procesos y diagramas de acción, las
definiciones de los algoritmos de negocio, diagramas de ciclo de vida y matrices
de entidad de cambio de estado. Un análisis detallado de la arquitectura técnica
actual, el software de aplicación, y los datos se lleva a cabo para asegurar que
las limitaciones o requisitos únicos no han sido pasados por alto.
Incluya todos los requisitos posibles, incluyendo los de:
 especificaciones funcionales y de capacidad, incluyendo el rendimiento, las
características físicas y las condiciones ambientales en las que el elemento de
software se debe ejecutar
 interfaces externas al elemento de software
 requerimientos de calificación
 especificaciones de seguridad, incluyendo los relacionados a los métodos de
operación y mantenimiento, influencias ambientales, y lesiones personales
 especificaciones de seguridad, incluyendo las relacionadas al compromiso
con la sensibilidad de la información
 factores humanos de ingeniería (ergonómicos), incluyendo los relacionados a
operaciones manuales, interacción con equipamiento humano
 restricciones y limitaciones sobre acciones del personal, por ejemplo las áreas
susceptibles a la sensibilidad de cometer errores humanos y entrenamiento
 definición de datos y requerimientos de la base de datos
 instalación y requerimientos de aceptación de los entregables de los
productos de software en la operación y mantenimientos de los SITEs
 documentación de usuario
 operación de los usuarios y requerimientos de ejecución
 requerimientos de mantenimiento de usuario
PÁGINA 20
APÉNDICE A-1
CONTENIDO DE UN PLAN DE ADQUISICIONES
1.0 ANTECEDENTES Y OBJETIVOS
1.1 Declaración de la necesidad
1.1.1 Historial de Adquisiciones
1.1.2 Alternativas Viables para Adquisición
1.2 Condiciones Aplicables
1.3 Costo(s)
1.3.1 Costo(s) del Ciclo de Vida del Desarrollo
1.3.2 Costo para el Diseño
1.3.3 Evaluación de Costos
1.4 Capacidad y Rendimiento
1.5 Entrega o Requerimientos del Período de Ejecución
1.6 Costo de Oportunidad
1.7 Riesgos
1.8 Racionalización de la Adquisición
2.0 PLAN DE ACCIÓN
2.1 Fuentes
2.2 Competencia
2.3 Proceso de Selección-Fuente
2.4 Consideraciones de los Proveedores/ Contratistas
2.5 Presupuesto y Fondos
2.6 Descripción de los Productos
2.7 Prioridades, asignaciones y complementos
2.8 Funciones inherentemente gubernamentales
2.9 Administración de Requerimientos de Información
2.10 Hacer o Comprar
2.11 Evaluación y Prueba
2.12 Consideraciones de Logística
2.13 Objetivos Ambientales y de Conservación de la Energía
2.14 Consideraciones de Seguridad
2.18 Otras Consideraciones
2.19 Hitos para el ciclo de Adquisición
2.20 Contactos para el Plan de Adquisición
PÁGINA 21
APÉNDICE A-2
CONTENIDO DE UN PLAN DE ADMINISTRACIÓN DE LA CONFIGURACIÓN

1.0 INTRODUCCIÓN
1.1 Propósito
1.2 Alcance
1.3 Descripción del Sistema
1.4 Definiciones
1.5 Documentos de Referencia
2.0 ORGANIZACIÓN
2.1 Actividades de Administración de la Configuración
2.2 Responsabilidades de Administración de la Configuración
3.0 IDENTIFICACIÓN DE LA CONFIGURACIÓN
3.1 Configuración de Identificación de Artículo
3.2 Convenios de identificación
3.3 Convenciones de Nomenclatura
3.4 Etiquetas
3.5 Gestión de Configuración para el Cronograma Base
4.0 CONTROL DE LA CONFIGURACIÓN
4.1 Administración de Cambios
4.2 Administración de Interface
5.0 CONFIGURACIÓN DEL ESTATUS CONTABLE
6.0 CONFIGURACIÓN DE AUDITORÍAS
7.0 REVISIONES
8.0 MANTENIMIENTO DEL PLAN DE CONFIGURACIÓN
9.0 ADMINISTRACIÓN DE DATOS
9.1 Librerías
9.2 Herramientas de Automatización
9.3 Control de Versiones
9.4 Administración de Espacio en Disco
9.5 Administración de la Construcción
9.6 Administración de la Documentación
10.0 CONTROL DE PROVEEDORES/ CONTRATISTAS
PÁGINA 22
APÉNDICE A-3
CONTENIDO DE UN PLAN DE ASEGURAMIENTO DE CALIDAD
1.0 GENERALIDADES
1.1 Propósito
1.2 Referencias
1.3 Objetivos
1.4 Glosario
2.0 DESCRIPCIÓN DE LA ORGANIZACIÓN
2.1 Organización del Cliente
2.2 Desarrollo del Sistema
2.4 Administración de la Configuración
2.5 Roles y Responsabilidades del Aseguramiento de Calidad
3.0 PROCESOS
3.1 General
3.2 Revisión por Pares
3.3 Proceso de Revisión
4.0 REPORTE DE PROBLEMAS Y ACCIONES CORECTIVAS

4.1 Reportes de Acciones de Calidad
4.2 Procedimientos para la Escalación del Aseguramiento de Calidad
5.0 HERRAMIENTAS, TECNICAS Y METODOLOGÍAS

5.1 SDLC
5.2 Políticas
5.3 Estándares
5.4 Herramientas
PÁGINA 23
APÉNDICE A-4
CONTENIDO DE UN DOCUMENTO QUE PLANTEA EL CONCEPTO DE

OPERACIONES
1.0 INTRODUCCIÓN
1.1 Descripción del Proyecto
1.1.1 Antecedentes
1.1.2 Supuestos y Limitaciones
1.2 Visión General del Sistema Propuesto
1.2.1 Generalidades
1.2.2 Alcance del Sistema
1.3 Referencia Documental
1.4 Glosario
2.0 METAS, OBJETIVOS Y RAZONAMIENTOS PARA EL NUEVO SISTEMA

2.1 Metas y Objetivos para el Nuevo Sistema (o Capacidades)
2.2 Razonamientos para el Nuevo Sistema (o Capacidades)
3.0 PROCESOS DE TRABAJO QUE SERÁN AUTOMATIZADOS/SOPORTADOS

3.1 Procesos Principales y Funciones
3.2 Flujo de los Procesos
4.0 REQUERIMIENTOS FUNCIONALES DE ALTO NIVEL

4.1 Especificaciones de Alto Nivel
4.2 Especificaciones Adicionales
4.3 Requerimientos de Trazabilidad
5.0 REQUERIMIENTOS OPERACIONALES DE ALTO NIVEL

5.1 Requerimientos No-Funcionales
5.2 Requerimientos de Implantación y Soporte
5.3 Configuración e Implementación
5.4 Ambiente del Sistema
6.0 CLASES DE USUARIOS Y MODOS DE OPERACIÓN

6.1 Clases/Categorías de Usuarios
6.2 Mapeo de Clases de Usuario a Especificaciones Funcionales
6.3 Ejemplo de Escenarios Operacionales
7.0 CONSIDERACIONES DE IMPACTO
7.1 Impactos Operacional y Organizacional
7.2 Riesgos Potenciales y Tópicos Relacionados
PÁGINA 24
APÉNDICE A-5
CONTENIDO DE UN PLAN DE SEGURIDAD DEL SISTEMA
1.0 GENERAL
1.1 Propósito
1.2 Referencias
1.3 Objetivo
1.4 Glosario
2.0 DESCRIPCIÓN DE LA ORGANIZACIÓN
2.1 Organización del Cliente
2.2 Desarrollo del Sistema
2.4 Administración de la Configuración
2.5 Roles y Responsabilidades del Aseguramiento de Calidad
3.0 PROCESOS
3.1 General
3.2 Revisión por Pares
3.3 Proceso de Revisión
4.0 REPORTE DE PROBLEMAS Y ACCIONES CORECTIVAS

4.1 Reportes de Acciones de Calidad
4.2 Procedimientos para la Escalación del Aseguramiento de Calidad
5.0 HERRAMIENTAS, TECNICAS Y METODOLOGÍAS

5.1 SDLC
5.2 Políticas
5.3 Estándares
5.4 Herramientas
PÁGINA 25
APÉNDICE A-6
CONTENIDO DE UN PLAN DE ADMINISTRACIÓN DEL PROYECTO
1.0 INTRODUCCIÓN
1.1 Descripción del Proyecto
1.2 Antecedentes del Proyecto
1.2.1 Estrategia del Plan de Desarrollo
1.2.2 Organización del Plan de Proyecto
1.3 Puntos de Contacto
1.4 Referencias del Proyecto
1.5 Glosario
2.0 ORGANIZACIÓN Y RESPONSABILIDADES
3.0 DESCRIPCIÓN DEL PROYECTO, CRONOGRAMA Y RECURSOS

3.1 Estructura Desglosada de Trabajo del Proyecto (WBS)
3.1.1 Sumario del WBS
3.1.2 WBS del Proyecto
3.1.3 Contrato del WBS
3.1.4 Diccionario del WBS
3.2 Estimación de Recursos
3.3 Cronograma
3.4 Plan de Adquisición
3.5 Plan de Comunicación
3.6 Estándares del Proyecto y Procedimientos
3.7 Evaluación de Riesgos
4.0 SEGURIDAD Y PRIVACIDAD

4.1 Tópicos de Privacidad
4.2 Actividades de Seguridad en Equipos Computacionales
PÁGINA 26
APÉNDICE A-7
CONTENIDO DE UN PLAN DE VERIFICACIÓN Y VALIDACIÓN
1.0 ANTECEDENTES E INTRODUCCIÓN
1.1 Planteamiento del Problema
1.2 Solución Propuesta
1.3 Documentos de Referencia/Relacionados
2.0 REQUERIMIENTOS DE V&V Y CRITERIO DE MEDICIÓN

2.1 Requerimientos de V&V y su Importancia
2.2 Criterios de Medición para cada Requerimiento
2.3 Documentos de Referencia/Relacionados
3.0 PLANES DE V&V FASE POR FASE

3.1 Información de Antecedentes del Proyecto y Sumario
3.2 Actividades de V&V en la Fase de Planeación
3.3 Fase de Definición de Requerimientos
3.4 Fase de Diseño
3.5 Fase de Desarrollo
3.6 Fase de Integración y Prueba
3.7 Fase de Instalación y Aceptación
PÁGINA 27
APÉNDICE A-8
CONTENIDO DE UN PLAN DE ADMINISTRACIÓN DE INGENIERÍA DEL

SISTEMA
1.0 INTRODUCCIÓN
1.1 Sumario Ejecutivo
1.2 Sumario del Proyecto
1.3 Alcance
1.4 Documentos Aplicables
2.0 PROCESO DE INGENIERÍA DEL SISTEMA

2.1 Proceso de Planeación de la Ingeniería del Sistema
2.2 Análisis de Requerimientos
2.3 Análisis/Asignación Funcional
2.4 Síntesis
2.5 Análisis de los Sistemas
2.6 Control de los Sistemas
3.0 ACTUALIZACIÓN DE TECNOLOGÍA
4.0 PLANEACIÓN DE LA IMPLEMENTACIÓN
5.0 PLANEACIÓN DE INGENIERÍA ESPECIALIZADA
PÁGINA 28

SDLC Fase Planeación y Definición de Requerimientos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SDLC Fase Planeación y Definición de Requerimientos

Cargado por

Copyright:

Formatos disponibles

Definición de

Fase de Planeación y Definición

Preparado por: Ing. Jorge Reyes C. | Metodología SDLC |

III.2.4.1 Plan de Adquisición ……... 15

Apéndice A-8 Contenido de un Plan de Administración de

Este documento describe el ciclo de vida de desarrollo de un Sistema enfocado a

I.1 Metodología SDLC en cascada.

Los proyectos de desarrollo de software de bases de datos de pequeñas a

El equipo de desarrollo de software, para aclarar los requerimientos y/o

I.2 Variaciones permitidas.

En algunos casos, información adicional se obtiene para el equipo de desarrollo

El GDP y el GUFP podrían, a discreción, permitir que el esfuerzo de desarrollo

I.3 Otros modelos de SDLC.

El modelo de cascada es uno de los 3 más comunes en los modelos de ciclo de

El modelo espiral empieza con un paso inicial mediante un ciclo de vida en

Modelo de Desarrollo de Aplicaciones Rápidas RAD (Rapid Application

RAD es, en esencia, el tratar de comprar antes de desarrollar software. La teoría

El usuario final tendrá la ventaja de trabajar con pantallas en línea como si

II. PROCESOS RECURRENTES DURANTE LAS FASES

II.2 Proceso de Interacción Informal.

La intención con este proceso es fomentar, más que inhibir el proceso de

II.3 Proceso de Interacción Formal.

II.4 Proceso de Evaluación durante las Fases.

Este es el proceso de revisión y aseguramiento formal de calidad para cada fase. En un

II.5 Proceso de Terminación de las Fases.

La etapa de terminación de una fase es el vehículo para asegurar la concurrencia

III. FASES SDLC

III.2 FASE DE PLANEACIÓN DEL PROYECTO.

Muchos de los planes esenciales para el éxito de un proyecto están creados en

Principales Entregables de la Fase de Planeación

III.2.2 TAREAS Y ACTIVIDADES

III.2.2.1 Afinar la estrategia de adquisiciones en el documento que establece

III.2.2.3 Crear procesos internos.

III.2.2.4 Creación del Equipo de Oficina del Proyecto.

III.2.2.5 Establecer acuerdos con las partes interesadas.

III.2.3 ROLES Y RESPONSABILIDADES

El jefe de proyecto asigna los recursos, gestiona las prioridades,

Captura, especificación y validación de requisitos, interactuando con el

Construcción de prototipos. Colaboración en la elaboración de las

Gestión de requisitos, gestión de configuración y cambios, elaboración

Ejemplo de Roles y Responsabilidades en un proyecto.

III.2.4.1 Plan de Adquisiciones (PA).

III.2.4.3 Plan de Aseguramiento de Calidad (PAQ).

El PAC documenta lo que el producto entregable debe satisfacer bajo acuerdos

El CONOPE es un documento de requerimientos de alto nivel que proporciona un

Un plan formal detalla el tipo de seguridad que en la computadora es requerido

III.2.4.8 Plan de Administración de Ingeniería del Sistema (PAIS).

El PAIS describe el proceso de ingeniería del sistema a ser aplicado al proyecto,

III.2.5 TÓPICOS DE CONSIDERACIÓN

III.2.5.1 Auditorías de Seguimiento

El objetivo de las auditorías de seguimiento es el de detectar problemas de

Mucho antes de permitir el acceso de forma individual al sistema, se debe

III.2.6 ACTIVIDAD DE REVISIÓN DE LA FASE

Una vez completadas las actividades de la Fase de Planeación y de recibir los

Las revisiones deben direccionar: (1) El status de las actividades de la Fase de

III.3 FASE DE DEFINICIÓN DE REQUERIMIENTOS.

La Fase de Análisis de Requerimientos empezará cuando la documentación de la

Las siguientes tareas son ejecutadas durante la Fase de Análisis de

negocio y estructuras de datos se lleva a cabo para producir diagramas entidad-

CONTENIDO DE UN PLAN DE ADQUISICIONES

CONTENIDO DE UN PLAN DE ADMINISTRACIÓN DE LA CONFIGURACIÓN

5.0 CONFIGURACIÓN DEL ESTATUS CONTABLE

8.0 MANTENIMIENTO DEL PLAN DE CONFIGURACIÓN