Desarrollo de sistemas y nuevas tecnologías

El modelo en cascada (ウォータフォールモデル) es un modelo de desarrollo que avanza por las fases en orden, de las iniciales a las finales, como una cascada, y cierra los entregables (成果物) de cada fase antes de pasar a la siguiente. Construir en iteraciones cortas es el desarrollo ágil, concretar los requisitos con prototipos es el modelo de prototipado, y combinar servicios existentes describe un mashup (マッシュアップ).

El modelo de prototipado (プロトタイピングモデル) busca construir pronto un prototipo (プロトタイプ) y dejar que los usuarios lo prueben, para resolver en una etapa temprana las ambigüedades de los requisitos y las diferencias de entendimiento entre el cliente y los desarrolladores. Reducir las líneas de código no es su propósito, y no permite omitir las pruebas ni eliminar el mantenimiento.

El desarrollo ágil (アジャイル開発) es un enfoque que acumula software que funciona en cada iteración corta y responde con flexibilidad partiendo de la premisa de que las especificaciones cambiarán; Scrum (スクラム) y XP son métodos representativos. Cerrar todos los requisitos antes de desarrollar de una vez, esperar a tener los documentos completos para empezar e implicar a los usuarios solo al final se acercan al enfoque en cascada y no son características ágiles.

Un sprint (スプリント) es el periodo corto y fijo que forma la unidad de desarrollo en Scrum; en cada periodo se repite el ciclo de planificar, desarrollar, producir software que funciona y hacer una retrospectiva (振り返り). No es un término para la fase de definición de requisitos ni para el periodo de la prueba de aceptación, ni tampoco un periodo dedicado solo a corregir errores.

El modelo en cascada avanza con la premisa de no volver atrás, así que cuando aparecen errores de requisitos o de diseño en la fase de pruebas, al final del proceso, el costo de volver a las fases iniciales para rehacer el trabajo (retrabajo, 手戻り) es muy grande. Como cada fase cierra entregables como las especificaciones y los documentos de diseño, seguir el avance es en realidad un punto fuerte, y el modelo es adecuado para desarrollos grandes. Tampoco es cierto que no pueda documentar los requisitos.

El modelo incremental (インクリメンタルモデル) divide el sistema en unidades funcionales y acumula el desarrollo y las publicaciones por etapas; al igual que los modelos de desarrollo iterativo (反復型開発モデル), tiene la ventaja de que algunas funciones pueden usarse pronto. La cascada desarrolla el conjunto en una sola pasada secuencial, el análisis estructurado (構造化分析手法) es un método de análisis que usa DFD y similares, y un mashup es una combinación de servicios existentes; ninguno encaja.

Básicamente, el desarrollo empieza con el análisis de requisitos (要求分析), que organiza las necesidades de los usuarios, y luego pasa al diseño externo (外部設計) de las partes visibles para los usuarios, al diseño interno (内部設計) de la implementación interna, a la programación y a las pruebas. Los órdenes en los que el diseño precede al análisis de requisitos, o las pruebas preceden a la programación, no pueden sostenerse dadas las dependencias entre los entregables.

El diseño externo (外部設計) abarca las partes visibles para los usuarios y el exterior: especificaciones de pantallas, especificaciones de informes (帳票) e interfaces con otros sistemas. Decidir los algoritmos internos y la disposición física de almacenamiento corresponde al diseño interno y al diseño de programas, y verificar los módulos individuales es trabajo de la prueba unitaria.

La prueba unitaria (単体テスト) es la primera etapa del proceso de pruebas y comprueba módulo por módulo que cada uno funciona según su diseño detallado. Combinar módulos para comprobar las interfaces es la prueba de integración (統合テスト), el juicio de aceptación del cliente es la prueba de aceptación (受け入れテスト), y comprobar el rendimiento con carga elevada describe las pruebas de carga y de rendimiento.

Las pruebas se construyen desde las unidades más pequeñas: primero las pruebas unitarias (単体テスト) por módulo, luego las pruebas de integración (統合テスト) que combinan los módulos, después la prueba de sistema (システムテスト) que comprueba todo el sistema y, por último, la prueba de aceptación (受け入れテスト) por parte del cliente y los usuarios. Comprobar primero el conjunto o la aceptación supondría ejecutar pruebas de nivel superior con defectos de los componentes todavía mezclados, lo cual no es razonable.

La prueba de aceptación (受け入れテスト) es la prueba de la etapa final en la que el cliente y los usuarios examinan el sistema entregado desde la perspectiva del negocio y juzgan si lo aceptan (検収). Comprobar la lógica interna es la prueba unitaria que hacen los desarrolladores (prueba de caja blanca), comprobar sin ejecutar es la prueba estática (静的テスト) y comprobar las conexiones entre módulos es la prueba de integración; ninguna describe la prueba de aceptación.

La prueba de caja negra (ブラックボックステスト) trata el interior del programa como una «caja negra» y solo comprueba si la relación entre entradas y salidas coincide con la especificación. La prueba de caja blanca (ホワイトボックステスト) se centra en cubrir las ramas y rutas internas, la prueba estática comprueba mediante revisiones sin ejecutar el programa, y la prueba de regresión (回帰テスト) comprueba que las correcciones no han estropeado nada más.

La prueba unitaria (単体テスト) es la primera etapa del proceso de pruebas y comprueba módulo por módulo que cada uno funciona según su diseño detallado. Combinar módulos para comprobar las interfaces es la prueba de integración (統合テスト), la decisión de aceptación del cliente es la prueba de aceptación (受け入れテスト), y comprobar el rendimiento con carga elevada describe las pruebas de carga y de rendimiento.

El documento de definición de requisitos (要件定義書) recoge, como resultado del análisis de requisitos, las funciones, el rendimiento y las restricciones que debe ofrecer el sistema, y se acuerda entre el cliente y el desarrollador, sirviendo como base de referencia para el diseño, las pruebas y la aceptación posteriores. El manual de operación es un documento práctico para los usuarios, el informe de prueba unitaria registra resultados de pruebas y el diagrama de red es un plano de diseño; ninguno es el documento de referencia acordado.

Una WBS es una técnica que descompone jerárquicamente y estructura los entregables del proyecto y el trabajo necesario para ellos, lo que evita omisiones y aclara las unidades para la estimación y la asignación. Mostrar el calendario con barras horizontales es un diagrama de Gantt (ガントチャート), la gestión del valor ganado es la EVM, y evaluar los riesgos describe el análisis de riesgos (リスク分析).

Un diagrama de Gantt (ガントチャート) muestra el inicio y el fin previstos de cada tarea como barras horizontales y se usa mucho para visualizar el calendario y el avance. Un diagrama de flujo de datos (データフロー図) muestra el flujo de los datos, un diagrama E-R las relaciones entre entidades y un diagrama de casos de uso (ユースケース図) las interacciones entre el sistema y sus usuarios; ninguno es un diagrama para gestionar el calendario.

Hay 2 rutas: A→B→D→F (3 + 5 + 4 + 2 = 14 días) y A→C→E→F (3 + 4 + 6 + 2 = 15 días). Como F debe esperar a que terminen ambas rutas, la duración total mínima es la más larga, 15 días. Esta ruta más larga, A→C→E→F, es la ruta crítica (クリティカルパス). 14 días solo considera el lado A→B→D→F, y 12 y 13 días no coinciden con el total de ninguna ruta.

Hay 3 rutas: A→B→D→F (2 + 4 + 3 + 1 = 10 días), A→C→D→F (2 + 6 + 3 + 1 = 12 días) y A→C→E→F (2 + 6 + 4 + 1 = 13 días). La más larga, A→C→E→F con 13 días, es la ruta crítica (クリティカルパス). 10 y 12 días son los totales de las otras rutas, y 14 días no coincide con ninguna. Cualquier retraso en las tareas de la ruta crítica (A, C, E, F) retrasa todo el proyecto en la misma medida.

El método de puntos de función (ファンクションポイント法) puntúa el número y la complejidad de las funciones —entradas, salidas, consultas, archivos internos, etc.— para estimar el tamaño del software, y puede aplicarse al principio del desarrollo sin depender de las líneas de código. LOC es una medida distinta basada en el recuento de líneas, el método Delphi (デルファイ法) hace converger las opiniones de expertos mediante encuestas repetidas y el método KJ (KJ法) es una técnica de generación de ideas que organiza y agrupa la información en tarjetas.

La gestión de riesgos sigue este orden: identificación de riesgos (リスク識別), que saca a la luz los riesgos; análisis de riesgos (リスク分析; cualitativo y cuantitativo), que evalúa la probabilidad y el impacto; planificación de la respuesta a los riesgos (リスク対応計画), que decide las contramedidas; y seguimiento y control de riesgos (リスクの監視・コントロール), que vigila la situación durante la ejecución. Planificar respuestas o hacer seguimiento antes de la identificación no puede funcionar, porque los riesgos en cuestión aún no están determinados.

Los cambios de especificación siguen el proceso de control de cambios (変更管理): se evalúa el impacto en el calendario, el costo y la calidad, y el comité de control de cambios (CCB, 変更管理委員会) decide su aprobación o rechazo. La aceptación incondicional provoca retrasos y pérdida de calidad, mientras que rechazarlo todo hace perder incluso los cambios necesarios. Las correcciones en el acto por parte de cada responsable generan incoherencias con la configuración y los documentos y destruyen el control.

Partes interesadas (ステークホルダ) es el término colectivo para las personas y organizaciones que tienen interés en el resultado del proyecto —el cliente, los usuarios, los desarrolladores, la dirección, etc.—, y comprender y conciliar sus expectativas es una actividad importante de la gestión de proyectos. El diagrama de calendario es un diagrama de Gantt, la descomposición jerárquica es la WBS y la lista de riesgos corresponde al registro de riesgos (リスク登録簿).

Un SLA es un acuerdo entre el proveedor y los usuarios de un servicio sobre niveles de calidad como la disponibilidad (稼働率), el tiempo de recuperación ante fallas y el horario de soporte, y sirve como base de evaluación del servicio en operación. Proteger los derechos de autor es un contrato de licencia, el diagrama de desglose del trabajo es una WBS y tomar prestado equipo es un arrendamiento (リース契約); ninguno de ellos es un SLA.

ITIL (Information Technology Infrastructure Library) es un conjunto de documentos que sistematiza las mejores prácticas (ベストプラクティス) para operar y gestionar servicios de TI, y se consulta ampliamente como marco de gestión de servicios que abarca la gestión de incidentes (障害管理), la gestión de cambios, la mesa de servicio y más. Los estándares de lenguajes de programación, la teoría de normalización y los estándares de LAN inalámbricas pertenecen a otros campos.

La disponibilidad (稼働率) se calcula como MTBF ÷ (MTBF + MTTR). 570 ÷ (570 + 30) = 570 ÷ 600 = 0.95. El MTBF es el tiempo medio de funcionamiento entre fallas y el MTTR es el tiempo medio de reparación. 0.90 y 0.98 no coinciden ni aunque se confundan el numerador y el denominador, y 0.93 no corresponde a ningún cálculo.

La gestión de la capacidad (キャパシティ管理) prevé el uso futuro —volúmenes de datos, número de accesos— y asegura y amplía de forma planificada la capacidad de los servidores, el almacenamiento y la red, previniendo la degradación del rendimiento y la falta de capacidad antes de que ocurran. Las estructuras de contacto ante fallas corresponden a la gestión de incidentes y de emergencias, la gestión de contraseñas a la gestión de usuarios y el recuento de licencias a la gestión de activos de software (ソフトウェア資源管理).

La virtualización de servidores (サーバ仮想化) es una tecnología en la que un software de virtualización ejecuta varias máquinas virtuales (仮想マシン) en 1 servidor físico, lo que mejora el aprovechamiento de los recursos mediante la consolidación de servidores (集約) y aporta flexibilidad en la reconfiguración y la recuperación. La distribución física y los chasis más pequeños son cuestiones de hardware, y el almacenamiento en papel no tiene nada que ver con la virtualización.

SaaS (Software as a Service) ofrece la propia aplicación como servicio a través de la red, lo que permite a los usuarios trabajar sin instalar el software. IaaS proporciona infraestructura como servidores, y PaaS proporciona todo hasta el entorno de ejecución de las aplicaciones. On-premises (オンプレミス) significa poseer y operar los equipos dentro de la propia organización, lo que no es un modelo de prestación en la nube.

Society 5.0 es la visión de una sociedad que reúne en el ciberespacio (サイバー空間) los datos del mundo real mediante el IoT y otros medios, los analiza y devuelve los resultados al mundo real: una fusión de alto nivel del ciberespacio y el espacio físico (フィジカル空間) que persigue a la vez el crecimiento económico y la solución de los problemas sociales. Superponer información a la realidad es la AR, repartir el cálculo es el procesamiento distribuido (分散処理), y el cuerpo de conocimientos de gestión de proyectos describe el PMBOK.

El aprendizaje supervisado (教師あり学習) proporciona al modelo datos con etiquetas correctas (正解ラベル) y lo entrena para predecir la respuesta a partir de la entrada; se usa para la clasificación de imágenes y la predicción de valores numéricos. Encontrar estructuras o grupos en los datos sin respuestas dadas es el aprendizaje no supervisado (教師なし学習). Capacitar a personas no es aprendizaje automático, y generar salidas aleatorias no tiene nada que ver con el aprendizaje.