Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

modelo de estimacion Probe

No description
by

PueBlank Puebla

on 28 May 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of modelo de estimacion Probe



M- Estimación PROBE


Calidad y Diseño


Revisiones de Diseño y código usados por PSP



Contenido:
Estimación con PROBE
El PSP utiliza el método PROBE para estimar y planificar proyectos. 
PROBE significa PROXY basado en Estimación.
PROBE utiliza PROXIES para estimar el tamaño y desarrollo de programas de tiempo.
El método de estimación de PROBE
Diseño conceptual
El primer paso de estimación es hacer un diseño conceptual. 
• relacionarse con los requisitos para el producto 
• definir los elementos de productos que producirán las funciones deseadas 
• estimar el tamaño de lo que va a construir 


El diseño de Software juega un papel importante en el desarrollo de software lo cual permite al ingeniero de software producir varios modelos del sistema o producto de que se va a construir el mismo que forman una especie de plan de la solución de la aplicación.

Estos modelos puede evaluarse en relación con su calidad y mejorarse antes de generar código, de realizar pruebas y de que los usuarios finales se vean involucrados a gran escala. El diseño es el sitio en el que se establece la calidad del software.
Calidad y Diseño
Proceso Personal de Software
Incluye declaraciones y otras funciones generales El tamaño de este código de sobrecarga adicional es generalmente proporcional al tamaño de las partes del programa.
Estimar el tiempo de desarrollo
El tamaño real del programa estará estrechamente relacionado con el tamaño estimado del programa.
Las diferencias serán debido a la sobrecarga de código y el error de la estimación. Tiempo de desarrollo actual también es a menudo relacionada con el tamaño estimado del programa. 

Las estimaciones basadas en estadísticas PROBE utiliza datos históricos, regresión lineal, y el intervalo de predicción para producir estimaciones de exactitud conocida. Regresión proporciona el mejor ajuste, o de mínima varianza, de una línea para estos datos.
La varianza de los datos es utilizado para determinar el error de estimación probable. Cuanto mayor sea la varianza, el más grande el error probable.

El diseño de la arquitectura de software se describe cómo se descompone y como están organizados los componentes en el software. [IEEEP1471-00]
• Diseño Detallado.
El diseño detallado se describe el comportamiento específico de estos componentes.
• Técnicas Permitidas.
• Abstracción
Abstracción es el proceso o el resultado de la generalización de la reducción del contenido de la información de un concepto o un fenómeno observable, por lo general, con el fin de conservar únicamente la información que es relevante para un propósito en particular. Cuando se considera una solución modular a cualquier problema se pueden exponer muchos grados de abstracción.



Estimación de tamaños de Proxies La cuestión básica 

• Se detallan las medidas de buen tamaño. 

• En general, es difícil de visualizar los detalles del producto a principios de un proyecto. 

Un buen indicador (PROXY) debe correlacionar estrechamente a los costos de desarrollo. Un buen indicador (PROXY) debe ser fácil de visualizar en el desarrollo temprano. También debe ser una entidad física que se puede medir La estimación del tamaño del programa Los programas tienen un código que no está en las partes del programa.
Diseño es definido como: "El proceso de definición de la arquitectura,
componentes, interfaces y otras características de un sistema o componente que resulta de este proceso" [IEEE610.12-90].
Palabras Claves
Definición de Documentos de Software (IEEE)
SQAP: Software Quality Assurance Plan IEEE 730
SCMP: Software Configuration Management Plan IEEE 828
STD: Software Test Documentation IEEE 829
SRS: Software Requirements Specification IEEE 830
SVVP: Software Validation & Verification Plan IEEE 1012
SDD: Software Design Description IEEE 1016
SPMP: Software Project Management Plan IEEE 1058

• Contexto del diseño de software.
El diseño del software se encuentra en el núcleo técnico de la respectiva ingeniería y se aplica de manera independiente al modelo de software que se utilice. Una vez que se analizan y especifican los requisitos, el diseño del software es la última acción de la ingeniería correspondiente dentro de la actividad del modelado, la cual establece una plataforma para la construcción (generación de código y prueba).
Proceso del Diseño de Software.
• Diseño Arquitectónico.
El diseño arquitectónico puede representarse al usar uno o más de muchos modelos diferentes. Los modelos estructurales representan la arquitectura como una colección organizada de componentes del programa. Los modelos del marco de trabajo repetible incrementan el grado de abstracción del diseño al intentar identificar marcos de trabajo repetibles del diseño arquitectónico que se encuentran en tipos de aplicaciones similares.

El diseño de la arquitectura de software se describe cómo
se descompone y como están organizados los componentes en el software. [IEEEP1471-00]
• Diseño Detallado.
El diseño detallado se describe el comportamiento específico de estos componentes.
• Técnicas Permitidas.
• Abstracción
Abstracción es el proceso o el resultado de la generalización de la reducción del contenido de la información de un concepto o un fenómeno observable, por lo general, con el fin de conservar únicamente la información que es relevante para un propósito en particular. Cuando se considera una solución modular a cualquier problema se pueden exponer muchos grados de abstracción.

REVISIONES DE DISEÑO Y CÓDIGO
Entre los métodos para verificar nuestro software tenemos:
1 Inspecciones: siguen un proceso estructurado y son útiles para requerimientos, diseños, casos de prueba, planes y todo lo que se les parezca. Cuentan con las siguientes características:
• son realizadas por los compañeros.
• los administradores no asisten.
• cada participante tiene un papel definido.
• el objetivo es encontrar problemas.
2. Recorridas: Siguen el formato de las juntas o reuniones. Son útiles para
aspectos de requerimientos o diseño del sistema.
• La audiencia puede incluir compañeros, administradores u otras partes
interesadas.
• El objetivo es comunicar u obtener la aprobación.
• No se requiere ninguna preparación.
MOTIVOS PARA REALIZAR REVISIONES
Es mucho más eficiente encontrar defectos
en las revisiones que en las pruebas.
En las pruebas unitarias, por lo regular sólo se
encuentran alrededor de 2 a 4 defectos por hora. En las revisiones de código se encuentran de 6 a 10 defectos
por hora. Mientras que los revisores con experiencia pueden encontrar 70% o
más de los defectos de un producto.

Los datos de PSP muestran que las revisiones encuentran de 2 a 5 veces más defectos por hora que las pruebas unitarias.
Después de las pruebas unitarias, la eliminación de defectos se vuelve más costosa.
• En las pruebas de integración y de sistema, toma de 10 a 40 horas de programador encontrar y eliminar cada defecto.
• Las inspecciones por lo regular toman menos de una hora por defecto.
Los defectos deben ser eliminados tan pronto como sea posible, por las siguientes razones.
• Cada revisión, inspección, compilación y pruebas encuentran sólo una fracción de los defectos.

Por lo mismo, mientras más limpio sea el código que entra a una fase, más limpio será al salir de la misma.
La eliminación temprana de defectos ahorra tiempo y dinero.

• Los defectos son más costosos mientras más tarde se encuentren y eliminen en el proceso de desarrollo.

• Los defectos son mucho más costosos cuando se encuentran y eliminan después de la terminación del producto.

LA ESTRATEGIA DE REVISIÓN EN EL PSP
El objetivo del PSP es producir la más alta calidad de programa posible en cada fase del proceso.
La estrategia de revisión para lograrlo es:
• recolectar datos de sus revisiones
• estudiar estos datos
• decidir que le está funcionando mejor
• ajustar su proceso de acuerdo con esto
Las revisiones en PSP siguen un proceso disciplinado con
• criterios de entrada y salida
• una estructura de la revisión
• guías, listas de comprobación y estándares

El objetivo de la revisión sugerido por el PSP es encontrar todo defecto antes de la primera compilación o prueba.
Para lograr ese objetivo, usted debe:
• usar estándares de codificación
• usar criterios que aseguren que el diseño es completo
• medir y mejorar su proceso de revisión

Principios de la revisión de diseño:
1. Producir diseños que puedan ser revisados.
2. Seguir una estrategia explicita de revisión.
3. Revisar el diseño en etapas.
4. Verificar que la lógica implanta correctamente los requerimientos.

Producir Diseños que puedan ser revisados Un diseño revisable tiene
• un contexto definido
• una representación precisa
• una estructura clara y consistente
Esto sugiere que
• el propósito y función del diseño están explícitamente establecidas
• usted tiene un criterio para asegurar que el diseño está completo
• el diseño está estructurado en elementos lógicos
Siguiendo una Estrategia de Revisión
La estrategia de revisión especifica el orden en el que usted revisa los elementos
de diseño.
• Esto depende de la estructura del producto.
• De esta forma, la estrategia de revisión debe ser considerada durante
el diseño.
El objetivo debe ser producir un diseño que pueda ser
• revisado en etapas
• probado en etapas
• integrado en etapas

Revisar el Diseño en Etapas
Al revisar en etapas, usted asegura que todos los temas seleccionados se revisan cuidadosamente.
Las etapas sugeridas de la revisión son las siguientes:
Revise que todos los elementos han sido diseñados.
1. Verifique el flujo y la estructura del programa completo.
2. Revise que sean correctas las estructuras lógicas.
3. Revise para asegurar la robustez.
4. Revise las llamadas a funciones, métodos y procedimiento para asegurar
su uso apropiado.
5. Revise variables especiales, parámetros, tipos y archivos para asegurar su uso apropiado.
Verifique que la Lógica Implementa Correctamente los Requerimientos
Revise los requerimientos para asegurar que cada función requerida es tomada en cuenta por el diseño.
Revise cuidadosamente por equivocaciones u omisiones.

CONSIDERACIONES DE LAS REVISIONES
Listas de Comprobación se definen como los pasos de la revisión en el orden
sugerido de su realización.
Al revisar cada punto, es más probable que esta se realice apropiadamente.
Construya una lista de chequeo personal que esté ajustada a su experiencia de
defectos.
Revisión antes de compilar, el PSP exige revisiones de código antes de la
primera compilación, esto se debe a que:
• El tiempo de revisión es el mismo si se hace antes o después de la
compilación.
• Las revisiones de código encuentra defectos que el compilador deja
pasar.


• Las revisiones de código compilado tiende a ser mucho menos efectivas.
• El compilador es igualmente efectivo antes o después de las revisiones.
El PSP usa la compilación como un chequeo de la calidad de las revisiones.
• SI se encuentran demasiados defectos en la compilación, se requiere otra
revisión.

Si la compilación es limpia, es probable que la mayoría de los defectos
hayan sido encontrados.
Revisiones e Inspecciones
El principal objetivo de las inspecciones debe ser encontrar aquellos problemas
de requerimientos y diseño que usted no haya encontrado.
Cuando los programas tienen muchos defectos sencillos, los inspectores se
distraen y con frecuencia pierden problemas más importantes.
Al revisar primero el código
• proporciona un producto de calidad para la inspección
• muestra respeto al tiempo de los inspectores
• produce inspecciones de más alta calidad

Presentan:
Jennifer Vázquez Hernández
Blanca Puebla Ortega

¿Qué es PROXY ?
Un PROXY es un objeto que representa un elemento a nivel conceptual (clases, reportes, formularios), pero
que tiene un tamaño en líneas de código (LOC’s).
Full transcript