Estimaciones del proyecto
El método de Punto de Caso de Uso (UCP – Use Case Point), está basado en los tradicionales Puntos Función. Es un método originado de la tesis de master de Gustav Karner (Karner, 1993), desarrollada mientras trabajaba en Objectory AB, bajo supervisión de Ivar Jacobson (creador de los casos de uso). La técnica ha sido usada por la empresa Rational (posteriormente adquirida por IBM) durante varios años y con buenos resultados.
El método estima el tiempo de desarrollo de un proyecto mediante la asignación de pesos a un cierto número de factores que lo afectan. Finalmente se contabiliza el tiempo total estimado a partir de esos factores.
La especificación de requisitos de software (ERS)
IEEE 830 es una norma para Especificación de Requisitos de Software. Un buen documento de requisitos debería incluir de una forma o de otra toda la información contenida en esta norma, indica como deba organizarse un documento de requisitos. Esta no es una metodología para el análisis de requisitos sino una recomendación de como debe ser presentado la especificación de estos y no exige que sea presentada en el formato propuesto por la especificación.
Esta definición se extiende y aplica a las condiciones que debe cumplir un sistema y cada uno de sus componentes para cumplir para satisfacer un contrato, norma o especificación.
Una buena especificación de requisitos de software provee un conjunto de ventajas entre las que destacan:
- Reducción del esfuerzo en desarrollo.
- Constituye una buena base para estimación de costes y planificación.
- Constituye un punto de referencia para procesos de verificación y validación.
- Constituye una base para la mejora de los procesos analizados.
Características de una buena ERS
- Correcta: cada requisito que figura en ella refleja alguna necesidad real.
- No ambigua: cada requisito tiene una única interpretación.
- Completa: incluye todos los requisitos significativos.
- Verificable: es posible verificar el una ves entregado el producto que cumple con los requisitos.
- Consistente: ninguno de los requisitos es contradictorio o entra en conflicto con otros.
- Clasificada: los requisitos pueden clasificarse por diversos criterios, los más comunes son importancia y escalabilidad.
- Modificable: cualquier cambio puede realizarse de forma fácil completa y consistente, también es deseable evitar la redundancia.
- Explorable: se puede conocer tanto el origen como los componentes del sistema que realizan cada requerimiento.
- Utilizable durante las tareas de mantenimiento y uso: el personal que no ha intervenido directamente en desarrollo debe ser capaz de mantenerlo y modificarlo, la especificación actuá como un plano.
Metodología para el Análisis de Requisitos de Sistemas Software
No solo es muy clara sino que también se han dado a la tarea de complementarla con un software. REM (REquirements Management) es una herramienta experimental gratuita de Gestión de Requisitos diseñada para soportar la fase de Ingeniería de Requisitos de un proyecto de desarrollo software de acuerdo con la metodología definida en la Tesis Doctoral "Un Entorno Metodológico de Ingeniería de Requisitos para Sistemas de Información", presentada por Amador Durán en septiembre de 2000. en este enlace podrán encontrar la herramienta que es de uso libre solo para fines académicos y enlaces a otros documentos y tesis relacionadas.
El formato de salida se puede personalizar mediante XSL, algo que yo mismo he hecho y podemos tener el formato de salida que deseemos.
Tambien esta aNimble Platform que es una herramienta para la gestión de requerimientos descendiente directo de OSRMT. Quizá alguno de Uds. se anime a probar alguna de ellas.
Especificación de diseño de software
IEEE 1016 es un estándar para "descripción de un diseño de software", entendiendo por tal la representación que sirve para comunicar cómo está diseñado el sistema. Especifica la información que una descripción de este tipo ha de contener y la organización o esquema de presentación recomendada. Puede aplicarse a software de cualquier tipo destinado a funcionar en un ordenador. Su aplicación no está restringida por ninguna consideración relativa al tamaño, complejidad o carácter crítico del software.
Tampoco está condicionada por la aplicación de una determinada metodología de diseño, gestión de configuraciones o control de la calidad, pues se supone que la información relativa a la calidad o los cambios en el diseño de la descripción será gestionada por otras actividades del proyecto. Asimismo, la norma no apoya ni se ve limitada por una técnica descriptiva particular, pudiéndose aplicar a documentos en papel, bases de datos automatizadas, lenguajes de descripción de diseños, etc.
El estándar especifica que un SDD (software design descriptions) se organiza en una serie de vistas de diseño. Cada vista abarca a un conjunto específico de problemas de diseño de las partes interesadas. Cada vista de diseño es orientada por una perspectiva de diseño. Una perspectiva identifica los problemas de diseño que se centraban en el marco de su vista y selecciona el lenguaje de diseño que se utilizan para describir esta perspectiva de diseño. La norma establece un conjunto común de perspectivas para el diseño de vistas, como punto de partida para la preparación de un SDD, y una capacidad genérica para definir nuevas perspectivas y con ello ampliar la expresividad de un SDD.
Los contenidos necesarios de un SDD son los siguientes:
Podrán encontrar uds mismos mas información respecto de esta y otras normas y métodos en internet. Las especificaciones presentadas incluyen plantillas para su uso, las que son una recomendación y no obligadamente debe usarse pero si seguirse. Les invito a que la lean y la pongan en práctica en la organización de sus proyectos de software.
El estándar especifica que un SDD (software design descriptions) se organiza en una serie de vistas de diseño. Cada vista abarca a un conjunto específico de problemas de diseño de las partes interesadas. Cada vista de diseño es orientada por una perspectiva de diseño. Una perspectiva identifica los problemas de diseño que se centraban en el marco de su vista y selecciona el lenguaje de diseño que se utilizan para describir esta perspectiva de diseño. La norma establece un conjunto común de perspectivas para el diseño de vistas, como punto de partida para la preparación de un SDD, y una capacidad genérica para definir nuevas perspectivas y con ello ampliar la expresividad de un SDD.
Los contenidos necesarios de un SDD son los siguientes:
- Identificación de la SDD
- Los actores de diseño identificados
- Los problemas de diseño identificados
- Los puntos de vista de diseño seleccionados, cada uno con definiciones del tipo de elementos de diseño y lenguaje permitido.
- Los puntos de vista de diseño
- Los superficie de diseño
- Justificación del diseño
Podrán encontrar uds mismos mas información respecto de esta y otras normas y métodos en internet. Las especificaciones presentadas incluyen plantillas para su uso, las que son una recomendación y no obligadamente debe usarse pero si seguirse. Les invito a que la lean y la pongan en práctica en la organización de sus proyectos de software.
