Capítulo 29 — Construcción del proyecto final
Mapa de la lección
Lección 29 publicada. Mapa, ejemplo, EX085.
flowchart TD
N0["Resultados de aprendizaje"]
N1["29.1 El encargo del proyecto final"]
N2["29.2 Incrementos"]
N3["29.3 Registro de decisiones"]
N4["29.4 Listo para la evaluación"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX085"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["29.1 El encargo del proyecto final"]
N2["29.2 Incrementos"]
N3["29.3 Registro de decisiones"]
N4["29.4 Listo para la evaluación"]
N5["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX085"]
[Resultados de aprendizaje]
|
v
[29.1 El encargo del proyecto final]
|
v
[29.2 Incrementos]
|
v
[29.3 Registro de decisiones]
|
v
[29.4 Listo para la evaluación]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX085]
Resultados de aprendizaje
Usted será capaz de (1) construir un artefacto de proyecto final que resuelva un problema definido de NCS; (2) trabajar por incrementos con pruebas; (3) llevar un registro de decisiones; y (4) preparar el artefacto para la evaluación y el traspaso.
29.1 El encargo del proyecto final
El proyecto final de Priya: un «detector de deriva de TO» que se ejecuta cada semana en el equipo de gestión de NCS y combina la comparación de inventario del capítulo 11, la comparación de flujos del capítulo 12, la comprobación de interlocutores nuevos del capítulo 19 y la comprobación de certificados del capítulo 22 en un único informe con un único estado de salida. Solo lee archivos exportados y nunca contacta con los dispositivos. Cada una de las cuatro comprobaciones ya existe y se ha ejecutado con datos de NCS; el trabajo del proyecto final consiste en combinarlas, validar sus entradas y hacer del resultado algo que el responsable de instalaciones pueda ejecutar sin Priya.
29.2 Incrementos
Semana 1: un script que ejecuta las cuatro comprobaciones sobre archivos de ejemplo e imprime secciones. Semana 2: un formato de salida común (comprobación, elemento, estado, archivo de evidencia). Semana 3: pruebas de cada comprobación con pequeños datos de prueba, incluidas entradas vacías. Semana 4: programación, registro y la alerta de «el trabajo no se ejecutó». Cada incremento funciona de principio a fin antes de empezar el siguiente. La semana 3 encontró un defecto real: un archivo de captura vacío hacía que la comprobación de interlocutores nuevos informara de que faltaban todos los equipos de la línea base, en lugar de indicar «sin datos». Priya añadió un estado «sin datos» que hace fallar la ejecución, porque una entrada vacía suele significar que la captura falló.
29.3 Registro de decisiones
Ejemplos: «Decisión 3: devolver un estado de salida distinto de cero si alguna comprobación devuelve UNAPPROVED, EXPIRED o VERSION-CONFLICT; alternativa (siempre cero) rechazada porque el programador de tareas no podría alertar». «Decisión 5: sin corrección automática; todas las acciones mediante tiques». De la semana 3 salió otra decisión: «Decisión 6: un archivo de entrada vacío produce el estado NO-DATA y una salida distinta de cero; alternativa (tratarlo como cero eventos) rechazada porque informaba de que faltaban todos los equipos de la línea base, y una captura vacía suele significar que la captura falló». Cada entrada nombra la alternativa y la razón por la que se descartó, para que un evaluador pueda discrepar de la razón en lugar de tener que adivinarla.
29.4 Listo para la evaluación
La carpeta del artefacto contiene el código, las pruebas, las entradas de ejemplo, un README que explica cómo ejecutarlo, el registro de decisiones y una breve guía de operaciones. Un evaluador debe poder ejecutarlo desde una copia limpia del repositorio y obtener la salida documentada. La carpeta de Priya lo cumplía, con 23 pruebas que se superan desde una copia limpia. La guía de operaciones es donde su evaluador encontró más tarde la laguna: el responsable de instalaciones podía ejecutar el detector, pero todavía necesitaba ayuda para interpretar VERSION-CONFLICT. Un revisor puede seguir cada estado desde los archivos de entrada hasta el informe sin preguntarle a ella.
Ejemplo resuelto (NCS sintética)
En la semana 3, las pruebas de Priya revelan que un archivo de captura vacío hace que la comprobación de interlocutores nuevos informe de que faltan todos los equipos de la línea base, en lugar de indicar «sin datos». Añade un estado «sin datos» que hace fallar la ejecución, porque una entrada vacía suele significar que la captura falló, que es exactamente lo que el emplazamiento necesita saber.
Caso sintético — Northgate Cold Storage. El proyecto final es un ejemplo didáctico.
Errores y límites
Combinar comprobaciones multiplica las formas en que los archivos de entrada pueden estar mal; valide primero las entradas. Una herramienta que solo Priya puede ejecutar no está terminada.
Ejercicios — capítulo 29
- EX085 — Elegir los estados de salida. ¿Qué estados deberían hacer que el detector de deriva devuelva una salida distinta de cero? Rúbrica: 3 =
UNAPPROVED,EXPIRED,VERSION-CONFLICT, sin datos (cualquier problema); 2 = algunos; 1 = vago; 0 = nada. - EX086 — Un dato de prueba. Describa un dato de prueba que compruebe el límite de 30 días de la comprobación de certificados. Rúbrica: 3 = un certificado a exactamente 30 días espera
renew-now, a 31 esperaplan; 2 = uno; 1 = vago; 0 = nada. - EX087 — ¿Por qué sin corrección automática? Justifique la decisión 5 en dos frases. Rúbrica: 3 = las acciones en TO necesitan aprobación y contexto; los errores automatizados podrían detener las operaciones; 2 = una; 1 = vago; 0 = nada.
Síntesis del capítulo
Construir un proyecto final es avanzar por pequeños incrementos, probar los casos límite, registrar las decisiones y producir un artefacto que otra persona pueda ejecutar.
Siga estudiando — capítulo 29 de 30
← Capítulo 28 (borrador) · Índice de capítulos del curso · Capítulo 30 (borrador) →