CAPITULO 2

Control de Proyectos de Software

Ing. de Software III

Facultad Politecnica

Control de Proyectos de Software

El control es un función que se realiza mediante parámetros que han sido establecidos anteriormente, es decir, el mecanismo de control es fruto de un planificación y por tanto, apunta al futuro.

Ing. de Software III

Facultad Politecnica

Control de Proyectos de Software

Punto de Partida
Disponemos de la programación del proyecto. Disponemos de la aplicación de recursos en cada instante. Disponemos de un flujo de caja aceptado y uno coste global
Ing. de Software III
Tarea: Diseño Programas Recursos: … Duración: 4 semanas Tarea: Especifica Necesidades Recursos: … Duración: 2 semanas Tarea: Realización Esquema Recursos: … Duración: 1 semanas Tarea: Codificación Program. Recursos: … Duración: 7 semanas Tarea: Pruebas Recursos: … Duración: 2 semanas

Tarea: Diseño B.D. Recursos: … Duración: 2 semanas

TAREAS Especificar Necesidades Diseño Programas Diseño Base de Datos Realización Esquema Codificación Programas Pruebas 0 2 4 6 8 10 12 14 16 SEMANAS

6 5 4 3 2 1 1 2 3 4 5 6 7 8 9 1 0

Facultad Politecnica

Control de Proyectos de Software

Actividades de control
Desarrollar estándares de productividad. Establecer las condiciones o medidas que deben darse cuando las tareas se realizan de forma correcta. Establecer sistemas de monitorización e informes. Determinar que datos son necesarios, quien y cuando los debe recibir. Medir los resultados Determinar los niveles de cumplimiento, o alcance de desviaciones, sobre metas y estándares.
Ing. de Software III Facultad Politecnica

Escrito. Elogiar. remunerar. regular Formal. Oral. Documentar los métodos de control. Oral. Documentar los estándares. Oral. o replanificar. de Software III Discusión en ronda Información sobre de tereré problemas futuros Facultad Politecnica .. Recompensar y disciplinar. Informe Semanal regular Formal. de Software III Formas de obtener información del proyecto Tipo de Informe Formal. especifico Ing. métodos de informar y control.Control de Proyectos de Software Actividades de control • • • Iniciar acciones correctivas Reforzar estándares. planes de primas y recompensas etc.. puntos de decisión. ajustar metas. Informe de especifico Excepción Informal. y disciplinar al personal. Facultad Politecnica Ing. especifico Ejemplo Reunión Semanal Final de Etapa Comentarios Notas de la reunión Formal. Escrito.

Cuenta con los siguientes pasos: • • • • • Definición de los parámetros de control Medición de los resultados Evaluación de los errores Definición de las correcciones Ejecución de las correcciones Facultad Politecnica Ing.Control de Proyectos de Software Comparar lo ESPERADO y con lo REAL Cumple lo Cumple el Acción Planificado Estándar SI SI Todo va bien SI NO Estudiar la desviación del estándar y ajustarlo si es necesario. de Software III NO Control de Proyectos de Software Proceso de Control El control consiste en un conjunto de actividades indicadas anteriormente y efectuadas por un o unos agentes con el propósito de que las mismas se realicen lo mas cerca posible del plan inicial. disciplinar Replanificar y estudiar la situación para crear medidas correctivas Estudiar con cuidado. Facultad Politecnica NO SI NO Ing. de Software III . plicar las dos medidas anteriores.

de Software III Facultad Politecnica . En ese momento se funden planificación y control.Control de Proyectos de Software Proceso de Control Definición de los parámetros de control Los parámetros (metas y objetivos) son los elementos que permiten al sistema de control determinar si las acciones están o no conduciendo al receptor en dirección a la situación deseada de acuerdo a los estándares de productividad desarrollados o definidos. de Software III Facultad Politecnica Control de Proyectos de Software Proceso de Control Definición de los parámetros de control (cont. Ing. cosa que el sistema de control solo actúe cuando se sobrepase este margen por cualquiera de sus limites. La definición de los parámetros debe prever un margen de normalidad.) La determinación de esos parámetros ocurre durante el proceso de planificación. en la etapa en que se definen determinados componentes del sistema de control. inferior o superior Ing.

de Software III Facultad Politecnica . como esa modalidad esta sujeta a deformaciones introducidas por quien hace la verificación. Sin embargo. Ing. y cuando no es posible la verificación cuantitativa directa. se procura efectuarla de modo subjetivo. su valor es relativo Ing. de Software III Facultad Politecnica Control de Proyectos de Software Proceso de Control Evaluación de los errores La evaluación consiste en la comparación entre los resultados que se pretendía obtener y aquellos que efectivamente se obtuvieron. Esta verificación puede presentarse bajo una forma cuantitativa.Control de Proyectos de Software Proceso de Control Medición de los resultados Todo sistema de control debe poseer medios para verificar el resultado de cada actividad.

Control de Proyectos de Software Proceso de Control Definición de las correcciones Una vez verificado un error y evaluada su gravedad. de Software III Facultad Politecnica Control de Proyectos de Software Proceso de Control Ejecución de las correcciones Las soluciones encontradas deben traducirse en lenguaje apropiado para quien se encargue de ejecutarlas y con un grado de detalle mas elevado tomando en cuenta el nivel jerárquico del agente ejecutor Ing. de Software III Facultad Politecnica . se hace necesario analizar las posibles soluciones existentes y seleccionar aquella que parezca mas adecuada Ing.

Flujo de trabajo en el Seguimiento y Control Inicio del Desarrollo Obtener Información del Avance del Proyecto Planificación Estándares Productividad Comparar lo Esperado con los datos REALES ¿Satisfactorio? SI ¿Fin del Proyecto? SI Ing. de Software III Replanificar o Corregir NO NO Fin del Desarrollo Facultad Politecnica Control de Proyectos de Software Tipos de control Dependiendo del momento en que se realice la acción de control se tienen los siguientes tipos de control: • Control direccional • Control aprobado-reprobado • Control post-operacional Ing. de Software III Facultad Politecnica .

Reprobado En este caso. el proceso se interrumpe definitivamente o hasta que se subsanen las irregularidades. Ejemplo Este es el caso típico del control de calidad Ing. de Software III Facultad Politecnica Control de Proyectos de Software Tipos de control Control Aprobado . de Software III Facultad Politecnica . el receptor del control se somete a un examen después de concluidas determinadas actividades. Ing. de modo que cada elemento de la acción sea el resultado de la rectificación casi instantánea de la acción anterior. En caso de aprobación se permite la realización de la actividad siguiente. Si hubiera una rectificación. En este caso el control se realiza de modo continuo y no en puntos determinados.Control de Proyectos de Software Tipos de control Control direccional El mecanismo de control actúa antes de que la actividad este totalmente concluida.

Estos controles se pueden hacer al interior del proyecto (control por dentro) o por intermedio de firmas. para asegurarse de la buena marcha del mismo Ing. los contratistas exigen que se haga un control externo al proyecto. deben ser complementarios. de Software III Facultad Politecnica . En algunos casos. solo se utilizara en un periodo/proyecto futuro cuando se inicie la planificación para un nuevo ciclo de actividades.Control de Proyectos de Software Tipos de control Control Post-operacional El mecanismo de control sólo se pone en funcionamiento después de concluida toda la operación. esta en función del carácter del sistema que se desea controlar y del nivel de complejidad que se intenta introducir en los mecanismos de control. sino que más bien. La decisión de emplear un tipo aislado de control o una combinación de los tipos antes mencionados. especializadas en control (control por fuera) Ing. de Software III Facultad Politecnica Control de Proyectos de Software Tipos de control Vale la pena mencionar que estos tres tipos de control no son mutuamente excluyentes. La información para la acción correctiva en este tipo de control. externas al proyecto.

de Software III Facultad Politecnica Descripción . Evaluación formal del estado del Recomendar acciones correctivas proyecto en relación al plan de éste Asegurar la adecuada localización de recursos Entrada Criterio de Entrada Objetivos de revisión La revisión puede iniciarse cuando el jefe Lista de temas a tratar de proyecto: Calendario actual del proyecto Establece o confirma los objetivos de revisión Informe de revisiones anteriores Informes sobre los elementos del Establece que los elementos de SW y la software terminados o en proceso documentación pertinente esta suficientemente completada de desarrollo Ing.Control de Proyectos de Software Revisiones Las revisiones son instancias de control administrativo y técnico que permiten documentar el proceso. de Software III Facultad Politecnica Control de Proyectos de Software Revisión Administrativa Objetivos Asegurar el progreso del proyecto. Estas se clasifican en: • Revisiones Administrativas • Revisiones Técnicas • Inspecciones / Recorridos (Walkthroughs) Ing.

de Software III Facultad Politecnica . decisiones y recomendaciones Registrador hechas por el equipo de revisión Prepararse individualmente para la revisión Formular recomendaciones para mejorar anomalias detectadas Personal responsable de lo que va ser examinado Revisores Proveer la información necesaria para entender el objeto de revisión Preparar el material de entrada que corresponda Ing. de Software III Criterio de Salida La revisión se considera completa cuando incluye: Todos los aspectos considerados en los objetivos de la revisión han sido tratados El informe de la revisión ha sido producido Liderazgo Usualmente el jefe de proyecto Facultad Politecnica Control de Proyectos de Software Revisión Administrativa RESPONSABILIDADES Planificar la revisión Líder Conducir la revisión Asegurar que se produzca el informe de revisión Documentar los problemas.Control de Proyectos de Software Revisión Administrativa Salida Informe de revisión que incluya: Las entradas para la revisión El estado actual del proyecto Lista de recomendaciones Equipo de Trabajo Líder Registrador Revisores Responsables de lo que va a ser examinado (dos o mas personas) Ing.

Los objetivos de la RTF son: • Descubrir errores en la función. Generar una lista de tareas y recomendaciones para ser manejada por niveles administrativos superiores Recomendar el curso de acción a ser tomado en lo sucesivo Ing. Registrar todas las desviaciones con respecto al estado esperado. de Software III Facultad Politecnica . la lógica o la ejecución de cualquier representación del software • Verificar que el software bajo revisión cumple con los requerimientos • Garantizar que el software ha sido desarrollado bajo ciertos estándares definidos • Obtener un desarrollo uniforme • Hacer que los proyectos sean mas manejables Ing. de Software III Facultad Politecnica Control de Proyectos de Software Revisión Técnica Formal (RTF) Es una actividad de garantía de calidad del software. a los participantes el material de entrada a la revisión Preparación Revisar individualmente el material que se distribuye para la revisión Confeccionar una lista de preguntas y tópicos a discutir Examinación Examinar el estado del proyecto y determinar si se cumple con el estado esperado. Examinar el estado del proyecto y determinar si es constantemente restringido por factores externos o internos no considerados originalmente en los planes.Control de Proyectos de Software Revisión Administrativa PROCEDIMIENTOS Planificación Establecer el equipo de revisión Establecer la fecha y lugar para llevar a cabo la revisión Distribuir a tiempo. de acuerdo a la planificación predefinida.

de Software III Facultad Politecnica . de Software III Facultad Politecnica Control de Proyectos de Software Revisión Técnica Formal (RTF) Restricciones al realizar una RTF: • Convocar a reunión entre 3 a 5 personas • Preparar por adelantado. Ing. pero sin requerir mas de dos horas por persona • La duración no debe ser superior a 2 horas Al final de la reunión TODOS los participantes en la RTF deben decidir: • Si aceptan el producto sin posteriores modificaciones • Si rechazan el producto debido a serios errores encontrados • Si aceptan el producto provisionalmente.Control de Proyectos de Software Revisión Técnica Formal (RTF) Cada RTF se lleva acabo mediante una reunión y solo tendrá éxito si es bien planificada. Ing. controlada y atendida.

Control de Proyectos de Software Revisión Técnica Formal (RTF) Una vez tomada la decisión. estándares o guías para contrastar el elemento de software a revisar Ing. El centro de atención de la RTF es un PRODUCTO. Asegurar la integridad de los cambios Criterio de Entrada La revisión puede iniciarse cuando: Establecen los objetivos de revisión Los responsables de los elementos de software están listos para la revisión El líder establezca que los elementos de software y la documentación pertinente esta suficientemente completa Facultad Politecnica . de Software III Facultad Politecnica Control de Proyectos de Software Revisión Técnica Formal Descripción Evaluación formal de uno o varios elementos del software Entrada Objetivos de revisión Elemento (s) del software a tratar Especificaciones de los elementos de software a examinar Planes. de Software III Objetivos Evaluar la conformidad. todos los participantes firman un documento de revisión en el cual expresan que están de acuerdo con las conclusiones tomadas. Ing.

de Software III Facultad Politecnica . los Rehacer el trabajo necesario para que los elementos de elementos software satisfagan los criterios de salida de la revisión de SW Preparar el material de entrada que corresponda Ing.Control de Proyectos de Software Revisión Técnica Formal Salida Criterio de Salida Informe de Revisión que incluya: La revisión se considera completa cuando: Las entradas para la revisión Lista de deficiencias no resueltas Todos los aspectos considerados en los objetivos de la revisión han sido de los elementos de SW tratados examinados El informe de la revisión ha sido Recomendaciones para eliminar producido las deficiencias no resueltas Equipo de Trabajo Liderazgo Líder Usualmente el: Registrador Ingeniero líder o Revisores Analista líder Autor (es) (Tres o mas personas) Ing. de Software III Facultad Politecnica Control de Proyectos de Software Revisión Técnica Formal RESPONSABILIDADES Planificar la revisión Líder Conducir la revisión Asegurar que se produzca el informe de revisión Documentar los problemas. decisiones y recomendaciones Registrador hechas por el equipo de revisión Revisores Prepararse individualmente para la revisión Formular recomendaciones para mejorar anomalías detectadas Proveer la información necesaria para entender el elemento de Autor (es) de software a examinar.

cambios autor posibles y mejoras en gral Entrada Criterio de Entrada El recorrido puede iniciarse cuando: El autor del elemento de SW esta Objetivos del recorrido listo para su presentación Elemento del SW a examinar El moderador establece que el Estándares para el desarrollo del elemento de SW esta elemento de SW a examinar suficientemente completo para su examinación Ing.Control de Proyectos de Software Revisión Técnica Formal PROCEDIMIENTOS Planificación Establecer el equipo de revisión Establecer la fecha y lugar para llevar a cabo la revisión Distribuir a tiempo. a los participantes el material de entrada a la revisión Preparación Revisar individualmente el material que se distribuye para la revisión Confeccionar una lista de preguntas y tópicos a discutir Examinación Examinar los elementos de SW para verificar si cumplen con las especificaciones y estándares definidos. de Software III Facultad Politecnica Control de Proyectos de Software Inspección/ Recorrido (Walkthrough) Consideraciones y procedimientos para realizar una inspección: Descripción Objetivos Evaluación formal de un elemento del Detectar defectos software o de su proceso de desarrollo El autor presenta el elemento de software a Examinar alternativas de desarrollo revisar. el resto de los participantes discute Ser fuente de aprendizaje para el sobre el progreso logrado. el líder de la revisión debe recomendar procesos de revisión adicionales Ing. Documentar los aspectos técnicos que solucionan las deficiencias encontradas en los elementos de software y determinar los responsables de su resolución Cuando las deficiencias son criticas o numerosas. de Software III Facultad Politecnica . errores.

omisiones. Equipo de Trabajo Moderador Lector Registrador Revisores Autor (dos o siete personas) Ing. omisiones.Control de Proyectos de Software Inspección/ Recorrido (Walkthrough) Consideraciones y procedimientos para realizar una inspección: Salida Criterio de Salida Informe de recorrido que incluya: La recorrido se considera completo cuando: Elemento de SW examinado El elemento de software ha sido presentado Lista de deficiencias. de Software III Facultad Politecnica . contradicciones Todas las deficiencias y mejoras han sido documentadas Recomendación para resolver deficiencias El informe de recorrido ha sido producido. entre otros Proveer la información necesaria para entender el elemento de software a examinar. contradicciones. mejoras. Facultad Politecnica Control de Proyectos de Software Inspección/ Recorrido (Walkthrough) Consideraciones y procedimientos para realizar una inspección: RESPONSABILIDADES Planificar la revisión Moderador Conducir la revisión Asegurar que se produzca el informe de revisión Documentar los comentarios hechos durante el recorrido Registrador Prepararse individualmente para la revisión Participar en la presentación del elemento de SW haciendo aportes Revisores sobre errores. en detalle. Autor (es) de Rehacer el trabajo necesario para que el elemento de SW los satisfagan los criterios de salida de la revisión elementos de Preparar el material de entrada que corresponda SW Dirigir al equipo de inspectores a través de los elementos de SW a examinar Ing. enfoques alternativos. de Software III Liderazgo Usualmente el autor del elemento de SW a examinar.

a los participantes el material de entrada a y tópicos a discutir la revisión Examinación Examinar el elemento de software. Ing. Obviar la dependencia de personas determinadas que acumulan el conocimiento de los sistemas en su mente. Ing. omisiones. de Software III Facultad Politecnica Razones para mantener una adecuada documentación: Dar transparencia a los sistemas respecto de las posibilidades de conocerlos. contradicciones Registrar recomendaciones y mejoras sugeridas. Reducir las consecuencias negativas de la rotación de personal. aplicarlos. Poder contar permanentemente con un respaldo actualizado de los sistemas de uso. obtener resultados. operarlos. Detectar y registrar defectos.Control de Proyectos de Software Inspección/ Recorrido (Walkthrough) Consideraciones y procedimientos para realizar una inspección: PROCEDIMIENTOS Planificación Preparación Establecer el equipo de revisión Revisar individualmente el material Establecer la fecha y lugar para que se distribuye para la revisión llevar a cabo la revisión Confeccionar una lista de preguntas Distribuir a tiempo. de Software III Facultad Politecnica .

la amplitud de posibilidades que brinda el sistema. en todos los niveles de usuarios. de Software III Facultad Politecnica . o reducir a condiciones de excepción. Si el sistema es adquirido a terceros.Razones para mantener una adecuada documentación (cont. Ing. la dependencia del proveedor para la explotación del mismo.) Reducir los costos y problemas de mantenimiento de los sistemas. (Facilidad de adecuación). Poder conocer. Permitir una mayor precisión en los cambios que se deseen introducir. eliminar.