FACULTAD DE INGENIERIA

I.S.C.

Ingeniería de proyectos
Administración de Proyectos

Ing. Joaquín Isaías Can May

JESUS ARMANDO REYNA QUEN

MATRICULA
25562
7° Semestre Grupo:”A”
Fecha de Entrega

San francisco de Campeche, camp. A 2 de Enero de 2011

 Ingeniería de Proyectos

2
2 0
2
0
 Ingeniería de Proyectos

INDICE

1. Anti patrones de la administración de proyectos 5

2. Modelo de madurez de capacidades (CMM) 6

3. Personal Software Process (PSP) 8

4. Administración de riesgos 9

5. Métricas del software 9

2
3 0
2
0
 Ingeniería de Proyectos

6. Arquitectura de Software – Modelo, Marcos de trabajo y Patrones de diseño 10

7. Integración, verificación y validación del sistema 11

8. Aseguramiento de la Calidad dentro de un proyecto de software 12

9. Administración de requerimientos de software 12

10. Rational Unified Process (RUP) 14

11. UML aplicado a la ingeniería de software 15

12. Metodología ágiles de desarrollo de software 16

13. Gestión de la configuración del software 17

Bibliografía 20

2
4 0
2
0
 Ingeniería de Proyectos

2
5 0
2
0
 Ingeniería de Proyectos

1.- Antipatrones de la administración de proyectos

Un patrón software es una solución común, adaptable y probada para un problema conocido. Algo así como una
plantilla de encaje que se ajusta a según qué condiciones de manera que aporta una solución implementable y
ejecutable.

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”:

•Desarrollo de Software: Se centran en problemas asociados al desarrollo de software a nivel de aplicación.

•Arquitectura de Software: Se centran en la estructura de las aplicaciones y componentes a nivel de
sistema y empresa.
•Gestión de Proyectos de Software: En la ingeniería del software, más de la mitad del trabajo consiste en
comunicación entre personas y resolver problemas relacionados con éstas. Los antipatrones de gestión de
proyectos de software identifican algunos de los escenarios clave donde estos temas son destructivos para
el proceso de software.

2.- Modelo de madurez de capacidades (CMM)

El Modelo de Madurez de Capacidades o CMM (CapabilityMaturityModel), es un modelo de evaluación de los
procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al desarrollo e
implementación de software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).

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:

• Definidas en un procedimiento documentado

• Provistas (la organización) de los medios y formación necesarios
• Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)
• Medidas
• Verificadas

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.

Los niveles son:

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.

Estas 5 características son:

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.

3.- Personal Software Process (PSP)

El proceso personal de software Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la
productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de
sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO
15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el
lanzamiento del libro "An introduction to the Personal Software Process" se dirige ahora a ingenieros juniors.

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

4.- Administración de riesgos

La identificación y gestión de los riesgos asociados a los requisitos del software, individuales y a grupos de
ellos, desde la fase se ingeniería de requisitos puede permitir minimizarlos, evadirlos y controlarlos. El
enfrentamiento proactivo de los riesgos que pueden afectar al desarrollo o a la calidad de los requisitos y las
acciones para evitarlos, permitirían minimizar problemas que persisten en el desarrollo de software. Son de
mayor importancia los riesgos asociados a las principales características de calidad de los requisitos.

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.

5.- Métricas del software

Las métricas son la maduración de una disciplina, que, según Pressman van a ayudar a la evaluación de los
modelos de análisis y de diseño, en donde proporcionarán una indicación de la complejidad de diseños
procedimentales y de código fuente, y ayudaran en el diseño de pruebas más efectivas; Es por eso que propone un
proceso de medición, el cual se puede caracterizar por cinco actividades:

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:

• Cuantificables, deben basarse en hechos, no en opiniones.

• Independientes, los recursos no deben poder ser alterados por los miembros que las apliquen o utilicen.
• Explicable, debe documentarse información acerca de la métrica y de su uso.
• Precisas, debe de conocerse un nivel de tolerancia permitido cuando se mide [12].
• Los beneficios los podemos enumerar de la siguiente forma:
• El proceso del software (para mejorarlo)
• El proyecto del software (para ayudar a estimar, control de calidad,¬ evaluación de productividad, control
de proyectos)
• Calidad del producto (para ayudarse en la toma de decisiones tácticas a medida¬ que el proyecto
evoluciona)

Con esto alcanzamos a responder tres preguntas fundamentales deseadas de una métrica

• ¿Cuánto mide? - la complejidad en la medida

• ¿Qué tan bien mide? - la calidad en la medida
• ¿Qué tanto tiempo mide? - la predicción

6.- Arquitectura de Software – Modelo, Marcos de trabajo y

Patrones de diseño
La arquitectura del software nos proporciona una visión global del sistema a construir. Describe la estructura y la
organización de los componentes del software, sus propiedades y las conexiones entre ellos. Los componentes del
software incluyen módulos de programas y varias representaciones de datos que son manipulados por el programa.
La arquitectura marca decisiones de diseño tempranas y proporciona el mecanismo para evaluar los beneficios de
las estructuras de sistema alternativas.
El diseño de datos traduce los objetos de datos definidos en el modelo de análisis, en estructuras de datos que
residan dentro del software. Los atributos que describen el objeto, las relaciones entre los objetos de datos y su uso
dentro del programa influyen en la elección de la estructura de datos. Mientras mayor sea el nivel de abstracción ,

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:

• las representaciones de la arquitectura facilitan la comunicación entre todas las partes

interesadas en el desarrollo de un sistema basado en computadora;
• la arquitectura destaca decisiones tempranas de diseño que tendrán un profundo impacto en
todo el trabajo de ingeniería del software que sigue, y es tan importante en el éxito final del
sistema como una entidad operacional;
• la arquitectura constituye un modelo relativamente pequeño e intelectualmente comprensible
de cómo está estructurado el sistema y de cómo trabajan juntos sus componentes.

7.- Integración, verificación y validación del sistema

VERIFICACION

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:

1. Las inspecciones del software.

2. Las pruebas de software.

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

8.- Aseguramiento de la Calidad dentro de un proyecto de

software
La calidad es el conjunto de propiedades inherentes a una entidad, que permiten juzgar su valor. Está
cuantificada por el valor que se le da al conjunto de propiedades seleccionadas. De esta manera la
calidad es subjetiva y, como dice James Bach, es circunstancial. Es subjetiva porque
depende de los atributos elegidos para medirla y es circunstancial porque el conjunto de
atributos elegidos puede variar en situaciones diferentes.

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.

9.- Administración de requerimientos de software

Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas
definiciones que existen para requerimiento, a continuación se presenta la definición que aparece en el
glosario de la IEEE .

 Una condición o necesidad de un usuario para resolver un problema o alcanzar un

objetivo.

 Una condición o capacidad que debe estar presente en un sistema o componentes de

sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

 Una representación documentada de una condición o capacidad como en las

anteriores.
2
13 0
2
0
 Ingeniería de Proyectos

Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales.

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.

Características de los requerimientos

Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos

en estado de madurez, deben presentar una serie de características tanto individualmente como en

grupo. A continuación se presentan las más importantes.

Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a

construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados

por otras capacidades del producto o del proceso.

Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y

clara para aquellos que vayan a consultarlo en un futuro.

Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si

se proporciona la información suficiente para su comprensión.

Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.

No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. lenguaje usado en

su definición, no debe causar confusiones al lector.

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

Dificultades para definir los requerimientos

• Los requerimientos no son obvios y vienen de muchas fuentes.

• Son difíciles de expresar en palabras (el lenguaje es ambiguo).

• Existen muchos tipos de requerimientos y diferentes niveles de detalle.

• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.

• 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.

• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.

• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

10.- Rational Unified Process (RUP)

El Proceso Unificado de Rational es una Ingeniería de Software Process. Proporciona un enfoque disciplinado para
la asignación de tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es garantizar la
producción de alta calidad. Software que satisfaga las necesidades de sus usuarios finales, dentro de un horario
predecible y presupuesto.

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

11.- UML aplicado a la ingeniería de software

UML] es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de
software orientado a objetos (OO). Un artefacto es una información que es utilizada o producida mediante
un proceso de desarrollo de software.

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.

Se derivan de los diagramas de proceso y módulos de la metodología de Booch, aunque presentan

algunas modificaciones. Los diagramas de implementación muestran los aspectos físicos del sistema.
Incluyen la estructura del código fuente y la implementación, en tiempo de implementación.
2
16 0
2
0
 Ingeniería de Proyectos
UML no define un proceso concreto que determine las fases de desarrollo de un sistema, las empresas
pueden utilizar UML como el lenguaje para definir sus propios procesos y lo único que tendrán en común
con otras organizaciones que utilicen UML serán los tipos de diagramas.

12.- Metodologías ágiles de desarrollo de software

El desarrollo ágil de software es un marco de trabajo conceptual de la ingeniería de software que promueve
iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo
ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en
una unidad de tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo
de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Una
iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la
meta es tener un demo (sin errores) al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar
las prioridades del proyecto.

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.

Algunas metodologías ágiles de desarrollo de software:

• Adaptive Software Development (ASD).

• Agile Unified Process (AUP).
• Crystal Clear.
• Essential Unified Process (EssUP).
• Feature Driven Development (FDD).
• Lean Software Development (LSD).
• Kanban.
• Open Unified Process (OpenUP).
• Programación Extrema (XP).
• Scrum.

13.- Gestión de la configuración del software

2
17 0
2
0
 Ingeniería de Proyectos
Verificación del software

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.

Hay dos acercamientos fundamentales a la verificación:

· Verificación dinámica, también conocido como prueba o Experimentación

· Verificación estática, también conocido como Análisis

Verificación dinámica (prueba, experimentación)

La verificación dinámica se realiza durante la ejecución del software, y comprueba dinámicamente su

comportamiento; se conoce comúnmente como Prueba fase. La verificación es un proceso de la revisión.
Dependiendo del alcance de pruebas, podemos categorizarlas en tres familias:

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 módulo (un solo módulo)

Prueba de la integración (más de un módulo)

Prueba del sistema (el sistema entero)

Prueba de aceptación: una prueba formal definida para comprobar los criterios de la aceptación para saber si hay un
software

Prueba funcional

Prueba no funcional (funcionamiento, prueba de tensión)

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:

· Convenciones de código verificación

· El malo practica la detección

· Métrica del software cálculo

· Verificación formal

Validación del software

Es necesaria ya que proporciona un alto grado de confianza y seguridad en el software y en los resultados que se
obtienen al aplicarlo.

Principios generales para validación

Especificación de los requisitos: Es la base para la validación.

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:

· Requisitos definidos por el usuario

2
19 0
2
0
 Ingeniería de Proyectos
· El plan de desarrollo de software

· El protocolo de validación utilizado

· El criterio de aceptación

· Las pruebas y sus resultados

· Las conclusiones sobre si el software se ajusta o no al uso previsto

· El manual de usuario del software

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