Professional Documents
Culture Documents
I.S.C.
Ingeniería de proyectos
Administración de Proyectos
MATRICULA
25562
7° Semestre Grupo:”A”
Fecha de Entrega
2
2 0
2
0
Ingeniería de Proyectos
INDICE
4. Administración de riesgos 9
Bibliografía 20
2
4 0
2
0
Ingeniería de Proyectos
2
5 0
2
0
Ingeniería de Proyectos
Un antipatrón es precisamente lo contrario. Dicho así de pronto parece claro que es algo así como un “lo que no
hay que hacer” y que por tanto lo que voy a tratar aquí es un compendio de malas prácticas. Pero un antipatrón no
es exactamente esto. Existen muchos libros que tratan de buenas y malas prácticas: en análisis, en diseño, en
implementación, en pruebas… Un antipatrón no es una mala práctica, aunque su consecuencia es un mal diseño y
por tanto puede abocar al fracaso de un producto software.
Un antipatrón es la aplicación de un patrón software bajo unas precondiciones erróneas, es decir: la aplicación de
un patrón software en un contexto equivocado. Es algo así como decir: “tu intención era buena pero no estudiaste
bien las fuerzas y el contexto que intervenían en tu situación particular, y por ello tu solución es inadecuada”. Se
documentan con cierto cinismo, lo cual los hace bastante graciosos y fáciles de recordar. Los nombres siempre
aluden al problema que tratan con humor. Se documentan mediante una plantilla (como los patrones de diseño) que
incluye secciones para documentar la solución origen (que es la causa del problema), el contexto, las fuerzas en
conflicto y las soluciones correctas propuestas. Un buen antipatrón explica por qué la solución original parece
atractiva, por qué se vuelve negativa y cómo recuperarse de los problemas que ésta genera. Entre otras cosas:
• Son un método eficiente para vincular una situación general a una clase de solución específica.
• Proveen experiencia del mundo real para reconocer problemas recurrentes en la industria del software,
ofreciendo también una solución para sus implicaciones más comunes.
• Establecen un vocabulario común para identificar problemas y discutir soluciones.
• Soportan la resolución holística de conflictos, utilizando recursos organizacionales a diferentes niveles.
2
6 0
2
0
Ingeniería de Proyectos
Para su estudio se dividen en 3 grandes categorías a las cuales se denominan “puntos de vista”:
Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Proceso (KPA - Key
Process Área). Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una organización que
tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado
ese nivel de madurez.
1 - Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y
mantenimiento de software. Aunque se utilicen técnicas correctas de ingeniería, los esfuerzos se ven
minados por falta de planificación. El éxito de los proyectos se basa la mayoría de las veces en el esfuerzo
personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los
proyectos es impredecible.
2 - Repetible. En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de
proyectos, existen unas métricas básicas y un razonable seguimiento de la calidad. La relación con
subcontratistas y clientes está gestionada sistemáticamente.
2
7 0
2
0
Ingeniería de Proyectos
3 - Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de
correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más
detallada y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por
pares.
4 - Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas
significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la
gestión de riesgos. El software resultante es de alta calidad.
5 - Optimizado. La organización completa está volcada en la mejora continua de los procesos. Se hace uso
intensivo de las métricas y se gestiona el proceso de innovación.
Así es como el modelo CMM establece una medida del progreso, conforme al avance en niveles de madurez. Cada
nivel a su vez cuenta con un número de áreas de proceso que deben lograrse. El alcanzar estas áreas o estadios se
detecta mediante la satisfacción o insatisfacción de varias metas claras y cuantificables. Con la excepción del
primer nivel, cada uno de los restantes Niveles de Madurez está compuesto por un cierto número de Áreas Claves
de Proceso, conocidas a través de la documentación del CMM por su sigla inglesa: KPA.
Cada KPA identifica un conjunto de actividades y prácticas interrelacionadas, las cuales cuando son realizadas en
forma colectiva permiten alcanzar las metas fundamentales del proceso. Las KPAs pueden clasificarse en 3 tipos
de proceso: Gestión, Organizacional e Ingeniería.
Las prácticas que deben ser realizadas por cada Área Clave de Proceso están organizadas en 5 Características
Comunes, las cuales constituyen propiedades que indican si la implementación y la institucionalización de un
proceso clave es efectivo, repetible y duradero.
Compromiso de la realización, La capacidad de realización, las actividades realizadas, las mediciones y el análisis,
la verificación de la implementación.
Las organizaciones que utilizan CMM para mejorar sus procesos disponen de una guía útil para orientar sus
esfuerzos. Además, el SEI proporciona formación a evaluadores certificados (Lead Assesors) capacitados para
evaluar y certificar el nivel CMM en el que se encuentra una organización. Esta certificación es requerida por el
Departamento de Defensa de los Estados Unidos, pero también es utilizada por multitud de organizaciones de todo
el mundo para valorar a sus subcontratistas de software.
Se considera típico que una organización dedique unos 18 meses para progresar un nivel, aunque algunas
consiguen mejorarlo. En cualquier caso requiere un amplio esfuerzo y un compromiso intenso de la dirección.
2
8 0
2
0
Ingeniería de Proyectos
Como consecuencia, muchas organizaciones que realizan funciones de factoría de software o, en general,
outsourcing de procesos de software, adoptan el modelo CMM y se certifican en alguno de sus niveles. Esto
explica que uno de los países en el que más organizaciones certificadas existan sea India, donde han florecido las
factorías de software que trabajan para clientes estadounidenses y europeos.
Se puede considerar como la guía de trabajo personal para ingenieros de software en organizaciones que emplean
un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medición cualitativa y mejora
de procesos. Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP tiene
obsesión por la toma de datos y elaboración de tablas. El PSP se orienta el conjunto de áreas clave del proceso que
debe manejar un desarrollador cuando trabaja de forma individual. Los niveles que se componen en:
• Nivel 1 - inicial:
o Seguimiento y control de proyectos.
o Planeación de los proyectos.
• Nivel 2 - repetible:
o Revisión entre colegas.
o Ingeniería del producto de software.
o Manejo integrado del software.
o Definición del proceso de software.
o Foco del proceso de software.
• Nivel 3 - Definido:
o Control de calidad.
o Administración cuantitativa del proyecto.
• Nivel 4 - Controlado:
o Administración de los cambios del proceso.
o Administración del cambio tecnológico.
o Prevención de defectos
2
9 0
2
0
Ingeniería de Proyectos
La Gestión, Monitorización y Mitigación de Riesgos (RMMM) tienen como objetivo marcar las estrategias y
formas de actuar del equipo de trabajo frente a los riesgos: cómo evitarlos, monitorizarlos, gestionarlos y actuar
ante contingencia. Escuetamente podemos establecer las tareas principales de cada una.
Para evitar el riesgo hay que definir las estrategias necesarias para que este no se produzca y tomar las medidas
encaminadas para que, aún cuando se produzca, se minimicen sus efectos. Para el monitoreo del riesgo hay que
definir los indicadores que influyen en la probabilidad de que este se produzca y revisar periódicamente dichos
factores, además de vigilar la efectividad real de las acciones encaminadas a evitarlo.
La gestión del riesgo y plan de contingencia asumen que la evitación y la monitorización han fallado y el riesgo se
ha producido. Por ello se definen las estrategias y acciones a tomar para lograr que los efectos se minimicen.
Nunca se podrá reducir a cero el coste del plan de contingencia, ya que él puede implicar algunos costes en sí
mismo, por lo cual se ha de valorar el beneficio que se espera obtener de éste.
Para la autora queda claro que cuanto antes se comience el proceso de gestión de riesgos en un proyecto mayores
serán las probabilidades de éxito del mismo, por tanto está convencida de que es en la etapa de la IR donde debe
comenzar, lo que se dificulta por estar poco tratado el tema para las actividades que componen el proceso de IR.
2
10 0
2
0
Ingeniería de Proyectos
Formulación: La obtención de medidas y métricas del software apropiadas para la representación de software en
cuestión.
Colección: El mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas.
Análisis: El cálculo de las métricas y la aplicación de herramientas matemáticas.
Interpretación: La evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de
la calidad de la representación.
Realimentación: Recomendaciones obtenidas de la interpretación de métricas técnicas trasmitidas al equipo de
software.
Se afirma que para que las métricas sean útiles estás deben tener las siguientes cuatro características:
Con esto alcanzamos a responder tres preguntas fundamentales deseadas de una métrica
2
11 0
2
0
Ingeniería de Proyectos
el diseño de datos se conducirá a lo que se define como una arquitectura para una base de datos o un almacén de
datos.
Bass y sus colegas identifican tres razones por las que la arquitectura del software es importante:
Comprende comprobar que el software está de acuerdo con su especificación. se comprueba que el sistema cumple
los requerimientos funcionales y no funcionales que se le han especificado.
VALIDACION
Es un proceso más general. se debe asegurar que el software cumple las expectativas del cliente. va mas alla de
comprobar si el sistema esta de acorde con su especificación, para probar que el software hace lo que el usuario
espera a diferencia de lo que se ha especificado. es importante llevar a cabo la validacion de los requerimientos del
sistema de forma inicial.
Dentro del proceso de verificación y validación se utiliza 2 técnicas de comprobación y analisis de sistema:
INTEGRACION
Es una técnica sistemática para construir la estructura del programa mientras al mismo tiempo se lleva a cabo
pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y
estructurar un programa que esté de acuerdo con el que dicta el diseño. Es la adaptación y mejora de los que otros
han realizado, pero buscando nuevos enfocas cubran los retos que nuestros clientes nos proponen.
2
12 0
2
0
Ingeniería de Proyectos
TIPOS DE INTEGRACION
• Integración descendente.
• Integración ascendente.
La integración depende de las características del software y a veces del plan de proyecto, en algunos casos se
pueden combinar ambas estrategias
Cuando aplicamos el concepto de calidad al software, éste deja de ser subjetivo porque se
determinan cuales son los atributos de calidad del software. Pero no deja de ser accidental
ya que en ciertas situaciones, un determinado conjunto de características de calidad puede
ser más importante que en ciertas otras.
objetivo.
anteriores.
2
13 0
2
0
Ingeniería de Proyectos
Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las
transformaciones que el sistema realiza sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar
el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad
(robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.
en estado de madurez, deben presentar una serie de características tanto individualmente como en
construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. lenguaje usado en
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita
hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.
2
14 0
2
0
Ingeniería de Proyectos
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.
• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.
El Rational Unified Process mejora productividad y equipo, proporcionando a cada miembro del equipo, con fácil
acceso a una base de conocimientos con las directrices, modelos y mentores de herramientas para todas las
actividades críticas de desarrollo. Al tener todos los miembros del equipo el acceso a la misma base de
conocimientos, no importa si usted trabaja con los requisitos, diseño, pruebas, proyectos o la gestión de la
configuración de gestión, nos aseguramos de que todos los miembros del equipo comparten una lengua común, el
proceso de y ver la manera de desarrollar software.
2
15 0
2
0
Ingeniería de Proyectos
Se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de
desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende
definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje
como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de
desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una
aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión, por poner un ejemplo.
Las diferencias son muy marcadas y afectan a todas las fases del proceso. El método del UML recomienda utilizar
los procesos que otras metodologías tienen definidos. Como objetivos principales de la consecución de un nuevo
método que aunara los mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente:
• El método debía ser capaz de modelar no sólo sistemas de software sino otro tipo de sistemas reales de la
empresa, siempre utilizando los conceptos de la orientación a objetos (OO).
• Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas.
• Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables.
• Manejar los problemas típicos de los sistemas complejos de misión crítica.
En la especificación del UML podemos comprobar que una de las partes que lo componen es un
metamodelo formal. Un metamodelo es un modelo que define el lenguaje para expresar otros modelos. Un
modelo en OO es una abstracción cerrada semánticamente de un sistema y un sistema es una colección de
unidades conectadas que son organizadas para realizar un propósito específico. Un sistema puede ser
descripto por uno o más modelos, posiblemente desde distintos puntos de vista.
Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software.
Pueden ser artefactos un modelo, una descripción o un software. Los artefactos de UML se especifican en forma de
diagramas, éstos, junto con la documentación sobre el sistema constituyen los artefactos principales que el
modelador puede observar.
Se necesita más de un punto de vista para llegar a representar un sistema. UML utiliza los diagramas gráficos para
obtener estos distintos puntos de vista de un sistema:
• Diagramas de Implementación.
• Diagramas de Comportamiento o Interacción.
• Diagramas de Casos de uso.
• Diagramas de Clases.
Los métodos ágiles enfatizan las comunicaciones cara a cara en vez de la documentación. La mayoría de los
equipos ágiles están localizados en una simple oficina abierta, a veces llamadas "plataformas de lanzamiento"
(bullpen en inglés). La oficina debe incluir revisores, escritores de documentación y ayuda, diseñadores de
iteración y directores de proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera
medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos
ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica.
Verificación del software es una disciplina amplia y compleja de tecnología de dotación lógica de quién meta es
asegurar que el software satisface completamente todos los requisitos previstos.
Pruebe en el pequeño: una prueba que comprueba una sola función o clase (Prueba de unidad)
Pruebe en el grande: una prueba que comprueba un grupo de clases, por ejemplo
Prueba de aceptación: una prueba formal definida para comprobar los criterios de la aceptación para saber si hay un
software
Prueba funcional
La verificación del software se confunde a menudo con la validación del software. La diferencia en medio
'verificación y validación:
Software verificación ¿hace la pregunta, “somos que construyen la derecha del producto? ”; es decir, hace el
software se conforman con su especificación.
Software validación ¿hace la pregunta, “somos que construyen el producto derecho? ”; es decir, está el hacer del
software qué el usuario realmente requiere.
La puntería de la verificación del software es encontrar los errores introducidos por una actividad, es decir.
Compruebe si el producto de la actividad está tan correcto como estaba al principio de la actividad.
La puntería de la validación del software es declarar si el producto de una actividad es de hecho qué espera, es
decir. La actividad extendió el producto con éxito.
2
18 0
2
0
Ingeniería de Proyectos
Verificación estática (análisis)
La verificación estática es el proceso de comprobar que el software resuelve requisitos haciendo una inspección
física de él. Por ejemplo:
· Verificación formal
Es necesaria ya que proporciona un alto grado de confianza y seguridad en el software y en los resultados que se
obtienen al aplicarlo.
Prevención de defectos: Es donde se fija la atención, la complejidad de la mayoría de software impiden que sea
probado exhaustivamente sin embargo es una actividad necesaria.
Tiempo y esfuerzo: Debe comenzarse con anticipación la conclusión final que muestre que el software fue validado
debe estar basada en evidencia recolectada.
Ciclo de vida del software: Contiene las tareas de ingeniería de software y la documentación necesaria para
soportar la validación del software.
Planificación: Define lo que será logrado a través del proceso de validación de software, y especifican aspectos
tales como el alcance, el método de validación, los recursos, el cronograma etc.
Procedimientos: Establecen el cómo, quién, y cuando se llevara a cabo la validación del software
Validación del software después de un cambio: Un cambio pequeño puede tener un impacto significativo, el estado
de validación debe ser restablecido cuando surjan cambios.
Alcance de la validación: Debe estar basado en la complejidad del software y en los riesgos, la selección de las
actividades y tareas a llevar a cabo durante la validación deben corresponderse con la complejidad del software.
Documentación:
Requisito importante y necesario del sistema de gestión de la calidad del laboratorio y debe incluir lo siguiente:
2
19 0
2
0
Ingeniería de Proyectos
· El plan de desarrollo de software
· El criterio de aceptación
BIBLIOGRAFIA
http://www.monografias.com/trabajos6/resof/resof.shtml
http://www.acis.org.co/index.php?id=851
2
20 0
2
0
Ingeniería de Proyectos
http://es.wikipedia.org/
2
21 0
2
0