Please enable JavaScript.
Coggle requires JavaScript to display documents.
11 AMPLIANDO EL PROCESO PERSONAL DE SOFTWARE - Coggle Diagram
11 AMPLIANDO EL PROCESO PERSONAL DE SOFTWARE
11.1 USANDO ABSTRACCIONES
EL PODER DE LAS ABSTRACCIONES
Se pueden crear abstracciones y combinar.
Un sistema más complejo > dificultad para captar detalles críticos.
Propias reglas > Ajustamos a nuestras capacidades y las del sistema que apoyamos, creamos una estructura lógica.
Debido a la fiabilidad humana, nuestras reglas y conceptos son defectuosos, incompletos o inconsistentes.
Nombrar y usar abstracciones conociendo las especificaciones externas importantes
LOS ELEMENTOS DEL TRABAJO INTELECTUAL
HABILIDAD EXPERTA
Obtener términos más ricos y nuevas habilidades para manejar la complejidad.
Construcciones más grandes y que se pueden juzgar rápidamente cómo usarlas.
La construcción de vocabularios fragmentados, aunque se haga de forma inconsciente depende de las habilidades y experiencia.
EL PODER DE LOS MÉTODOS
Al refinar procesos y definir métodos, desarrolla un vocabulario de fragmentos sofisticados.
MEMORIA EXPERTA
Patrones significativos que recuerdan como fragmentos.
Mediante el uso de trozos, almacena patrones completos de información en la memoria a corto plazo. > útil el vocabulario extenso.
Nosotros recordamos en trozos que tienen estructura y contenido.
11.2 LAS ETAPAS DEL TAMAÑO DEL PRODUCTO
Los límites de escalabilidad están determinados en gran parte por la habilidad y capacidad, por lo que cambian según la experiencia.
ETAPA 2 EL COMPONENTE
Ahora el diseño se compone de múltiples abstracciones en un nivel más complejo.
El diseño debe ser más preciso y riguroso para evitar tener un diseño inadecuado y pasando por alto algunos detalles.
Los programadores comienzan a pensar en programas completos como abstracciones.
PSP necesita extensos controles de calidad y sus prácticas deben ser disciplinadas para usar estos controles de manera consistente.
Trabajo en equipo = Producto con estructura limpia y descritos claramente.
Para pasar a la etapa 3 se debe tener prioridad en la prevención de defectos y eliminación temprana de ellos. El diseño requiere prácticas de programación defensivas que advierten sobre condiciones inesperadas, protejan al sistema de datos y proporcionen datos diagnóstico y recuperación. > El proyecto crece al igual que los equipos.
ETAPA 3 EL SISTEMA
El desafío técnico es diseñar sistemas de modo que su complejidad quede enmascarada y los usuarios vean que funcionan.
Si los componentes no coinciden, la integración se dificulta. El ciclo de prueba y reparación se pueden extender indefinidamente.
Abstraer la esencia del sistema y relega gran parte de la complejidad a los niveles inferiores.
En esta etapa PSP puede cambiar mucho porque se requieren más especialidades y mantener la calidad.
Comprende sistemas con múltiples componentes y su complejidad ha aumentado.
Cuando se avance a la etapa 4 se debe entender que ya no hay un grupo central que pueda controlar, guiar o dirigir el trabajo.
ETAPA 1 EL PROGRAMA O MÓDULO DE PROGRAMA
No se desarrollan habilidades para programas más grandes con la intuición.
Usar mismos métodos para los proyectos incorrectos.
Cajas blancas o trozos.
Para pasar a la etapa 2 se debe considerar que la intuición ya no es suficiente porque las funciones son más sofisticadas y aplicaciones desconocidas
Combinar construcciones de la etapa 0. Varía el tamaño.
ETAPA 4 MULTISISTEMA
Se necesita arquitectura de interconexión y los estándares utilizados.
Se debe considerar calidad, considerar implicaciones del sistema de todas las acciones locales, manejo de anomalías, seguridad, privacidad y seguridad.
Dividir las responsabilidades del sistema entre subsistemas, otorgando independencia para gestionar y centrarse en las especialidades.
ETAPA 0 RUTINAS SIMPLES
La experiencia te permite construirlos en tu mente sin tener que implementar una visualización física.
Si no le es fácil a uno construir pequeños elementos de programación, indica que necesita capacitación y experiencia.
Se trabaja con los bloques de construcción más pequeños, lenguaje básico.
11.4 UN PROBLEMA POTENCIAL CON LAS ABSTRACCIONES
La reutilización no soluciona el problema de la escalabilidad.
No sólo se debe tomar en cuenta los requerimientos de escalabilidad física, sino también capturar una función significativa del sistema en las partes.
11.5 LA ESTRATEGIA DE DESARROLLO
Conecta PSP con el proyecto en general y proporciona el marco para desintegrar y reintegrar el producto. Estructura lógica del producto final > Permite secuencia de mejoras progresivas.
ESTRATEGIA DE MEJORA FUNCIONAL
La versión inicial debe dar contexto operativo, ser pequeño, revisado y probado. Las mejorar se agregan en pequeños pasos.
Ventaja: Construye un sistema de trabajo en el punto más temprano. Permite identificación temprana de errores, temprana medición de rendimiento y para la exposición preliminar del usuario.
Define versión inicial y agrega mejoras.
Desventaja: el primer paso suele ser bastante grande.
ESTRATEGIA DE MEJORA DEL CAMINO RÁPIDO
Se identifican los problemas críticos de sincronización y se implementa el sistema de control.
Ventaja: expone problemas de sincronización. Se pueden ir agregando mejoras.
Similar a la mejora funcional, pero el núcleo se enfoca en el rendimiento de la vía rápida.
Desventaja: el primer paso suele ser bastante grande.
LA ESTRATEGIA PROGRESIVA
Se prueba de arriba hacia abajo, se implementa y prueba cada ciclo.
Ventaja: Fácil de definir e implementar. Proco que reconstruir o rediseñar entre ciclos.
La estructura se controla por una rutina principal y se ensancha con las funciones relacionadas.
Desventaja: No hay forma fácil de probar el comportamiento de cada slice.
Forma natural de desarrollar sistemas que se componen de una serie de funciones que se ejecutan secuencialmente
ESTRATEGIA DUMMY
Ventaja: Flexible y su construcción es en pequeños pasos.
Desventaja: El desarrollo puede que avance bastante antes de que sea visible el comportamiento útil del sistema.
Comienza de las funciones de alto nivel y simula el resto con stubs que proporciona respuestas predefinidas. Luego los stubs se aplican a las demás funciones.
11.6 PSP3
DESARROLLO CÍCLICO
Cada ciclo es esencialmente un proceso PSP2.1 que produce una parte del producto.
Se deben hacer revisiones y pruebas completas, porque un ciclo es la base para el siguiente.
REVISIÓN Y DESARROLLO DE PRUEBAS
Las pruebas se escriben antes del código para identifica tempranamente problemas de diseños y pruebas.
En las pruebas cíclicas, la primera prueba generalmente comenzará con borrón y cuenta nueva. Los ciclos subsiguientes agregan funciones y las integra progresivamente el producto. Después el ciclo final, completa unan unidad combinada y una prueba de integración del sistema.
DISEÑO DE ALTO NIVEL
Identifica las divisiones naturales del producto y diseña una estrategia cíclica.
VOLVER A EVALUAR Y RECICLAR
Después de cada ciclo, reevalúa el trabajo para determinar el estado y reevaluar el plan. Un informa al final del ciclo.
REQUERIMIENTOS Y PLANEACIÓN
Con los requerimientos y planeación se produce un diseño conceptual para todo el sistema, estimando tamaño
SELECCIÓN DE UNA ESTRATEGIA DE DESARROLLO
Un problema de las estrategias es que algunas funciones críticas sólo se desarrollen hasta ciclos de desarrollo posteriores. Retrasa la prueba más compleja o identificar riesgos.
Se escoge la que permita mejor según el producto actual probar los elementos más difíciles tempranamente con la menor cantidad de código