Link de video Técnicas de estimación
Link
jueves, 7 de marzo de 2019
miércoles, 6 de marzo de 2019
Puntos de función
¿Qué
es el método de puntos de función?
Es una técnica de estimación de software desarrollada originalmente por Allan Albrecht en 1979 mientras trabajaba para IBM, quien definió conceptos para medir el software a partir de valoraciones de funcionalidades entregadas al usuario y no a partir de aspectos técnicos, con la intención de producir valoraciones independientes de la tecnología y fases del ciclo de vida utilizado.
El trabajo de Albrecht fue continuado por el grupo internacional de usuarios de puntos de función, quienes plasmaron sus conceptos en el método IFPUG-FPA.
IFPUG-FPA realiza las valoraciones a
partir de la funcionalidad del sistema, primero clasificándolas, luego
asignando una complejidad y ponderación a cada una según unas tablas
predefinidas, determinando así el valor de puntos de función.
Sumando los puntos de todas las
funcionalidades se obtiene la valoración de todo el proyecto y finalmente se
puede aplicar un factor de ajuste, que puede depender de características
generales del sistema como por ejemplo requerimientos no funcionales como el rendimiento,
reusabilidad, facilidad de instalación y operación entre otros aspectos.
Los puntos de función permiten traducir
el tamaño de funcionalidades de software a un número, a través de la suma
ponderadas de las características que este tiene.
Una vez que tenemos los puntos de
función, podemos traducirlos en horas hombre o días de trabajo, según factor de
conversión que dependería de mediciones históricas de nuestra productividad.
Con las horas hombre, podemos determinar el costo y presupuesto de los proyectos.
¿Existen
otros métodos de puntos de función distintos de IFPUG-FPA?
Si, desde que surgió el IFPUG-FPA, los métodos de puntos de función se han diversificado, produciendo las siguientes variantes:
NESMA: Método definido por la
Netherlands Software Metrics Association.
MkII: Método definido por el
United Kingdom Software Metrics Association.
COSMIC: Denominado Full Function Points o COSMIC-FFP, fue desarrollado por el Common Software Metrics
Internacional Consortium.
FiSMA: De la asociación finlandesa
de medición de software.
¿Para
qué se utiliza el método de puntos de función?
Estimación de proyectos de software
Una de las principales aplicaciones del
método es en la determinación de valoraciones (estimaciones) del producto de software a desarrollar,
que es una parte fundamental de todo proceso de ingeniería de software y de la
gerencia de estos proyectos.
Dentro del ciclo de ingeniería de
software, lo normal es que la estimación del proyecto ocurra después que la
ingeniería de requerimientos produzca una primera versión de la especificación
de requisitos con suficiente información para elaborar la estimación.
Proceso PSP
¿Qué es el Proceso Personal del
Software?
Es un proceso de
auto mejora diseñado para ayudarnos a controlar, administrar y mejorar la forma
en que trabajamos.
·
PSP se
concentra en las prácticas de trabajo de los ingenieros en una forma
individual.
·
El PSP
se caracteriza porque es de uso personal y se aplica a programas pequeños de
menos de 10.000 líneas de código.
·
El PSP
sirve para producir software de calidad, donde cada ingeniero debe
trabajar en la necesidad de realizar trabajo de calidad.
·
El PSP
se centra en la administración del tiempo y en la administración de la calidad
a través de la eliminación temprana de defectos.
·
El
PSP busca proporcionar un marco de trabajo para el personal involucrado en
el proceso de desarrollo de software.
·
PSP
demuestra cómo manejar la calidad desde el principio del trabajo.
Es una alternativa
dirigida a los ingenieros de sistemas que les permite mejorar la forma en la
que construyen software, Considerando aspectos como la planeación, calidad,
estimación de costos y productividad.
·
Cada
ingeniero es diferente; para ser el más eficaz, los ingenieros deben planificar
su trabajo y deben basar sus proyectos en sus propios datos personales.
·
Para
mejorar coherentemente su funcionamiento, los ingenieros deben usar procesos
bien definidos.
·
Para
producir productos de calidad, los ingenieros deben sentirse personalmente
responsables de la calidad de sus productos.
·
Es
menos costoso encontrar defectos antes en un proceso que más tarde.
·
Es más
eficiente prevenir defectos que encontrarlos durante el desarrollo.
·
El
camino correcto es siempre el modo más rápido y más barato de hacer un trabajo.
·
Proceso
Personal de desarrollo de Software PSP
·
El
Proceso Personal Software, conocido por sus siglas como PSP, es una metodología
de reciente creación, proveniente del Instituto de Ingeniería del Software
(SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, que les
permite mejorar la forma en la que construyen software. Considerando aspectos
como la planeación, calidad, estimación de costos y productividad, PSP es una
metodología que vale la pena revisar cuando el ingeniero de software está
interesado en aumentar la calidad de los productos de software que desarrolla
dentro de un contexto de trabajo individual.
·
Atendiendo
a la premisa de que existe una fuerte relación entre las habilidades de los
ingenieros de software y la calidad de los productos que desarrollan, las
actividades establecidas en PSP están orientadas al conocimiento,
administración y mejora de sus habilidades al construir programas.
·
En PSP
todas las tareas y actividades que el ingeniero de software debe realizar
durante el proceso de desarrollo de un producto de software, están puntualmente
definidas en un conjunto de documentos conocidos como scripts. Los scripts son
el punto medular de PSP, por lo que se hace mucho énfasis en que deben ser
seguidos en forma disciplinada, ya que de ello dependerá el éxito de la mejora
que se busca. Gran parte de las tareas y actividades definidas en los scripts
generará en su realización un conjunto de datos, fundamentalmente de carácter
estadístico. La aplicación de PSP en varios procesos de desarrollo, y el
análisis de la información estadística generada en cada uno de éstos,
permitirán al ingeniero de software identificar, tanto sus fortalezas como sus
debilidades, y crecer a través de un proceso de autoaprendizaje y auto-mejora.
·
Los
scripts se organizan en cuatro niveles, identificados del 0 al 3, atendiéndose
en cada nivel un conjunto de aspectos a mejorar del proceso de desarrollo de
software. Al primer nivel se le conoce como 0 o de medición personal, al
segundo como nivel 1 o de planeación personal, al tercero, como nivel 2 o de
calidad personal, y al cuarto, como nivel 3 o cíclico personal. Cada uno de
estos niveles, con excepción del 3, tiene una versión que los extiende,
introduciendo tareas y actividades para un mejor manejo de los aspectos de
interés en nivel, o bien para incluir nuevos aspectos.
• Lograr
una disciplina de mejora continua en el proceso de desarrollo.
• Medir,
estimar, planificar, seguir y controlar el proceso de desarrollo.
• Mejorar
la calidad del proceso de desarrollo.
• En
general, PSP provee calidad y productividad.
•
El tiempo requerido para conocerlo.
•
El costo emocional por mantener una disciplina.
•
El ego del cambio en las costumbres.
•
La idea de que ganamos en talento y habilidad
•
La estimulación por nuevas ideas
•
Una estructura de trabajo de mejoramiento personal
•
Tomar control del propio trabajo
•
La sensación de logro
•
Una base mejorada para el trabajo en grupo (TSP)
•
La convicción de que es lo mejor que se puede hacer
En PSP todas las
tareas y actividades que el ingeniero de software debe realizar durante el
proceso de desarrollo de un producto de software, están puntualmente definidas
en un conjunto de documentos conocidos como scripts, los cuales deben de
ser seguidos en forma disciplinaria, ya que de ello dependerá el éxito de la
mejora que se busca.
Los Scripts se
organizan en cuatro niveles, identificados del 0 al 3, atendiendo en cada
nivel un conjunto de aspectos a mejorar del proceso de desarrollo de
software.
Los aspectos
de interés en este nivel se relacionan con la estimación del tiempo para
desarrollar un producto software y la identificación, clasificación y manejo de
los Defectos producidos durante el proceso de desarrollo. Los datos
recopilados mediante la aplicación de los scripts sirven de base para
la realización de estimaciones más reales en procesos futuros.
Es un nivel que
extiende y complementa a PSP0, a través del establecimiento de estándares de
codificación orientados a mejorar las estimaciones de tamaño, así como la
consideración de propuesta de mejora al nivel por parte de los ingenieros.
Le agrega pasos de
planeamiento a PSP0. El primer paso agrega estimaciones de tamaño y recursos y
un reporte de prueba.
Se introduce
planeamiento de cronograma y seguimiento del proyecto. Los desarrolladores
son enseñados a:
•Entender la
relación entre el tamaño de los programas que escriben y el tiempo que les toma
desarrollarlos.
•Aprender a
realizar compromisos que puedan cumplir.
•Preparar un plan
ordenado para realizar su trabajo
•Establecer una
base para realizar un seguimiento de su trabajo.
La calidad, es un
aspecto fuertemente relacionado con la cantidad de defectos que el producto de
software contiene. En este nivel se introducen las inspecciones en las
fases de diseño y codificación, como un mecanismo para aumentar la calidad
de los productos.
El Proceso de
diseño es contemplado.
El objetivo no es
decirles a los desarrolladores como diseñar sino orientar el criterio para la
finalización del diseño, es decir cuando han terminado que es lo que deben
haber obtenido.
Presenta métodos
para ser usados por individuos en la realización de programas de gran escala.
Para escalar PSP2
a proyectos más grandes la estrategia consiste en subdividir el proceso
personal de desarrollo de grandes programas en elementos en la escala de PSP2.
Estos programas son entonces diseñados para ser desarrollados en pasos
incrementales. La primera construcción consiste en un módulo base o kernel que
es ampliado en ciclos iterativos. En cada iteración se utiliza un PSP2 completo,
incluyendo diseño, codificación, compilación y pruebas.
•De esta manera
los desarrolladores pueden concentrarse en la verificación de la calidad del
último incremento sin preocuparse por defectos en ciclos anteriores.
•Si un incremento
anterior tiene muchos defectos, la prueba será más compleja y los beneficios de
escalar PSP se pierden. Esta es una razón para enfatizar revisiones de diseño y
código en los pasos anteriores de PSP.
Suscribirse a:
Comentarios (Atom)
-
Cierre del proyecto ¿El proyecto acaba con la aceptación del último entregable?. Pues lo cierto es que no, una vez se han ejecutado, y acept...
-
Ver video: https://www.youtube.com/watch?v=V6TMhsgo5Ac
