1. Métricas: Las métricas nos ayudan a entender todo el proceso técnico que se utiliza para desarrollar un producto y al mismo tiempo, una persona pueden entender para que sirve o para que se crea el producto, esto desde el punto de vista técnico.
1.1. Las métricas también se utilizan para intentar mejorar un producto.
1.2. Las razones para medir un producto son las siguientes:
1.2.1. Para indicar la calidad del producto.
1.2.2. Para evaluar la productividad de la gente que desarrolla el producto.
1.2.3. Para evaluar los beneficios en términos de productividad y de calidad.
1.2.4. Para establecer una línea de base para la estimación.
1.2.5. Para ayudar a justificar el uso de nuevas herramientas o de formación adicional.
1.3. Las mediciones del mundo físico pueden englobarse en solo dos categorías las cuales son:
1.3.1. Medidas Directas. En las medidas directas se encuentran los aspecto de costo, esfuerzo aplicado, las líneas de código producidas, velocidad de ejecución y tamaño de memoria, entre otros aspectos.
1.3.2. Medidas Indirectas. En las medidas indirectas se encuentran los aspectos de funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento, etc.
1.4. Existen 6 tipos de métricas orientadas a un cierto tipo de proceso, las cuales son:
1.4.1. Métricas Técnicas: Se centran en las características de software por ejemplo: Mide la estructura del sistema, el cómo esta hecho.
1.4.2. Métricas de Calidad: proporcionan una indicación de cómo se ajustara el software a las necesidades que el cliente necesita, es decir, los características con las que debe de cumplir el softwarel
1.4.3. Métricas Productividad: Se centra en la productividad con la que contara el software a crear.
1.4.4. Métricas Orientadas a la Persona: Son las medidas que que se dan a conocer sobre las personas que se encuentran desarrollando el software.
1.4.5. Métricas Orientadas al Tamaño: Este tipo de métrica se centra en el conocimiento del tiempo y del personal aproximado que se necesitara para finalizar el proyecto.
1.4.6. Métricas Orientadas a la Función: Este tipo de métricas se centran en la funcionalidad o utilidad que tendrá el proyecto.
2. Estimación: La estimación no es mas que una pequeña planeación de lo que va a ser el proyecto
2.1. Durante la planeación de un proyecto se obtienen:
2.1.1. Estimaciones del esfuerzo humano requerido.
2.1.2. Duración cronológica del esfuerzo humano requerido.
2.1.3. Duración cronológica del proyecto.
2.1.4. Costos.
2.2. En muchos de los casos las estimaciones se hacen valiendose de la experiencia pasada pero estas estimaciones pueden fallar si los proyectos difieren en los siguientes puntos:
2.2.1. Tamaño.
2.2.2. Aproximación en tiempo del desarrollo del proyecto.
2.2.3. Esfuerzo humano requerido.
2.3. Si se desea realizar un proyecto basado en la experiencia de un proyecto anterior y estos son totalmente distintos, entonces puede que la experiencia obtenida no sea la suficiente para desarrollar el nuevo proyecto.
3. Planeación
3.1. Para que se lleve acabo una planeación efectiva de un proyecto de software es necesario que se detalle su avance para así, anticipar problemas que puedan surgir y tener preparadas soluciones eficaces en caso de que llegase haber un problema.
3.2. El administrador del proyecto es el único responsable de la planeación efectiva del proyecto, esto va desde la definición de los requisitos hasta la entrega del sistema terminado.
3.3. Ademas de los puntos ya mencionados para una planeación efectiva, los puntos que se mencionaran a continuación son requeridos tanto por grandes proyectos de software como los pequeños.
3.3.1. Panorama: Descripción general del proyecto, detalle del plan de la organización y resumen del resto del documento.
3.3.2. Plan de fases: Planificación exacta de cada ciclo del proyecto, esto quiere decir que debe de haber una fecha de inicio y de finalización para cada una de las fases del proyecto.
3.3.3. Plan de organización: Se definen las responsabilidades que tendrán cada uno de los grupos que se encuentran en el desarrollo del proyecto.
3.3.4. Plan de pruebas: Se realizan las pruebas prudentes para todas y cada una de las herramientas que conforman el sistema.
3.3.5. Plan de control de modificaciones: Este plan establece un mecanismo a través del cual se aplicaran las modificaciones pertinentes al sistema mediante el desarrollo del mismo.
3.3.6. Plan de documentación: Su función es definir y controlar la documentación pertinente al proyecto.
3.3.7. Plan de capacitación: Describe la preparación que tienen todos y cada uno de los miembros que participan en el desarrollo del proyecto así como las instrucciones pertinentes para el correcto uso del software que se les entregara.
3.3.8. Plan de revisión e informes: Este plan analiza el como se informa el estado del proyecto y se definen las fechas de revisiones formales concernientes con el progreso del proyecto.
3.3.9. Plan de instalación y operación: Descripción del correcto procedimiento para la instalación del sistema en el equipo del usuario.
3.3.10. Plan de recursos y entregas: Resumen de los detalles críticos del proyecto como fechas programadas, marcas de logros y todos los artículos que deben entrar bajo contrato.
3.3.11. Plan de mantenimiento: Bosquejo de los posibles tipos de mantenimientos que se tienen que dar a las futuras versiones del sistema en caso de existir.
4. Errores clásicos en un proyecto de software.
4.1. A continuación se mencionaran algunos de los errores mas comunes en un proyecto de software:
4.1.1. Mal análisis en los requerimientos del software.
4.1.2. Mala planeación del proyecto.
4.1.3. No tener una negociación con el cliente (contrato, acuerdo, documento firmado, etc.).
4.1.4. No realizar o realizar un mal analisis de costos/beneficios.
4.1.5. Desconocer el ambiente de trabajo de los usuarios finales.
4.1.6. Desconocer los usuarios que trabajaran directamente con el sistema a crear.
4.1.7. Mala elección de los recursos para el desarrollo del proyecto (hardware, software, trabajadores).