Introducción al análisis de sistemas
"Los sistemas bien diseñados no se construyen, se cultiván. Requieren entender el problema antes de escribir la primera línea de código."
Qué vas a aprender en este capítulo
Antes de escribir una sola línea de código hay un trabajo previo crucial: entender el problema, definir qué hay que construir y planificar cómo. Este capítulo explica qué es el análisis y diseño de sistemas, por qué existe como disciplina, cuáles son los modelos de proceso de software más usados en la industria, y por qué tantos proyectos fallan (y cómo evitarlo).
1.1 ¿Qué es el análisis y el diseño?
💡 Intuición
Imaginate que te contratan para construir la casa de alguien. Hay dos formas de hacerlo:
Forma A: El cliente dice "quiero una casa" y vos empezás a poner ladrillos. A mitad de la construcción, descubrís que quería 3 cuartos y ya construiste 2. El baño quedó en el lugar equivocado. La cocina no tiene ventilación.
Forma B: Primero te sentás con el cliente, entendés cómo vive, cuántas personas son, cuánto presupuesto tienen, qué estilo prefieren. Después dibujás los planos. El arquitecto revisa. Luego empezás a construir.
En software:
- Análisis: La etapa de "sentarse y entender". ¿Qué necesita el sistema? ¿Qué problema resuelve? ¿Quiénes lo usan? ¿Bajo qué restricciones?
- Diseño: La etapa de "hacer los planos". ¿Cómo se va a estructurar el código? ¿Qué clases? ¿Qué bases de datos? ¿Cómo se comunican las partes?
- Implementación: Construir lo que dicen los planos.
Sin análisis y diseño, estás en la Forma A. Y la mayoría de los proyectos de software fallidos lo son por exactamente esa razón.
📐 Fundamento
Definiciones:
- Análisis de sistemas: proceso de comprender y documentar los requerimientos del sistema. Responde: ¿qué debe hacer el sistema?
- Diseño de sistemas: proceso de definir la arquitectura, componentes, módulos, interfaces y datos del sistema. Responde: ¿cómo va a funcionar internamente?
- Sistema de información: conjunto organizado de datos, procesos, personas y tecnología que trabajan juntos para soportar las operaciones y decisiones de una organización.
El ciclo de vida del software (SDLC — Software Development Life Cycle):
Todo software pasa por estas fases (en distintos órdenes según la metodología):
- Planificación: ¿Es factible? ¿Cuánto cuesta? ¿Cuánto tarda?
- Análisis de requerimientos: ¿Qué necesita el cliente?
- Diseño: ¿Cómo lo vamos a construir?
- Implementación (codificación): Escribir el código.
- Pruebas: Verificar que funciona correctamente.
- Despliegue: Poner el sistema en producción.
- Mantenimiento: Corregir bugs, agregar funcionalidades.
🛠️ En la práctica
El proyecto: Pupusería La Esquina
El dueño de La Esquina tiene un problema: los pedidos se anotan en papel, los mozos a veces se equivocan, y al final del día no sabe con certeza cuánto vendió de cada platillo. Quiere un sistema informático.
Análisis: Necesitamos entender cómo trabajan ahora (flujo actual), qué problemas tienen, qué esperan del sistema y cuáles son sus restricciones (presupuesto, dispositivos disponibles, si tienen internet).
Diseño: Decidiremos si hacemos una app web o de escritorio, cómo estructuramos las clases (Pedido, Producto, Mesa, Empleado), qué base de datos usar, cómo calcular el total con IVA.
Implementación: Recién aquí codea el programador.
1.2 Por qué fallan los proyectos de software
💡 Intuición
El Standish Group publica cada dos años el "Chaos Report" sobre proyectos de software a nivel mundial. Los resultados son consistentes:
- ~30% de proyectos se cancelan antes de terminar
- ~50% termina con sobrecosto o retraso significativo
- Solo ~20% se entrega a tiempo, dentro del presupuesto y con las funciones prometidas
Las causas principales (en orden):
- Requerimientos incompletos o mal entendidos (el error más frecuente)
- Falta de involucramiento del usuario
- Cambios de alcance en medio del proyecto (scope creep)
- Falta de soporte ejecutivo
- Tecnología inadecuada
Los problemas técnicos (bugs, performance) son una minoría. La mayoría de los fallos son de comunicación y proceso. Por eso existe el análisis y diseño: para reducir la brecha de comunicación entre lo que el cliente quiere y lo que el programador construye.
📐 Fundamento
Tipos de requerimientos:
- Requerimientos funcionales (RF): Lo que el sistema debe hacer. Ej: "El sistema debe calcular el total de la factura incluyendo IVA del 13%."
- Requerimientos no funcionales (RNF): Cómo debe hacerlo, o restricciones del entorno. Ej: "El sistema debe responder en menos de 2 segundos." (rendimiento), "Solo el administrador puede ver reportes." (seguridad), "Debe funcionar sin internet." (disponibilidad).
- Requerimientos de dominio: Reglas del negocio que el sistema debe respetar. Ej: "Los pedidos cancelados no se pueden modificar."
La brecha de comunicación. El cliente habla en términos de negocio. El programador habla en términos técnicos. El analista de sistemas traduce entre ambos mundos.
Artefactos del análisis (documentos que se producen):
- Documento de requerimientos (especificación de requerimientos de software — ERS o SRS)
- Casos de uso
- Historias de usuario
- Diagramas UML
1.3 Modelos de proceso de software
💡 Intuición
¿En qué orden hacés las cosas? ¿Primero analizás todo, luego diseñás todo, luego codeás todo? ¿O vas haciendo pedazos pequeños y mostrando al cliente cada semana?
Modelo en cascada: Primero análisis completo, luego diseño completo, luego código completo, luego pruebas completas. Como una cascada donde el agua solo baja.
Ventaja: Bien documentado, predecible. Desventaja: Si al final el cliente dice "esto no era lo que quería", ya gastaste todo el presupuesto.
Metodologías ágiles (Scrum, Kanban): Trabajás en ciclos cortos (2 semanas = un "sprint"). Cada ciclo entregás algo funcional. El cliente puede cambiar lo que quiere al principio de cada ciclo.
Ventaja: Adaptable, el cliente ve resultados rápido. Desventaja: Más difícil estimar costo total desde el inicio.
📐 Fundamento
Modelo en cascada (Waterfall):
Requerimientos → Diseño → Implementación → Pruebas → Despliegue
Cada fase debe completarse antes de iniciar la siguiente. Adecuado para proyectos con requerimientos estables y bien definidos (sistemas de misión crítica, contratos gubernamentales).
Modelo iterativo e incremental:
Se divide el sistema en módulos. Cada módulo pasa por todas las fases del SDLC. Al final de cada iteración hay un producto parcial funcional.
Modelo en espiral: Cada vuelta de la espiral agrega funcionalidad y evalúa riesgos. Énfasis en gestión de riesgos.
Scrum (metodología ágil):
- Sprints: iteraciones de 1-4 semanas.
- Backlog: lista priorizada de todo lo que el sistema debe hacer.
- Sprint Planning: al inicio de cada sprint, el equipo elige qué ítems del backlog va a completar.
- Daily Standup: reunión diaria de 15 minutos (¿qué hice ayer? ¿qué haré hoy? ¿hay bloqueos?).
- Sprint Review: al final del sprint, se muestra lo construido al cliente.
- Sprint Retrospective: el equipo reflexiona sobre qué mejorar en el proceso.
Roles en Scrum:
| Rol | Responsabilidad |
|---|---|
| Product Owner | Representa al cliente; prioriza el backlog |
| Scrum Master | Facilita el proceso; elimina bloqueos |
| Development Team | Desarrolla; se autoorganiza |
🛠️ En la práctica
¿Cuándo usar cada metodología?
| Criterio | Cascada | Ágil |
|---|---|---|
| Requerimientos cambian mucho | ❌ Mal | ✅ Bien |
| Cliente disponible frecuentemente | No necesario | ✅ Necesario |
| Equipo distribuido globalmente | ✅ Funciona | Más difícil |
| Contrato de precio fijo | ✅ Más fácil | Difícil |
| Tiempo al mercado es crítico | ❌ Lento | ✅ Rápido |
Para La Esquina: El cliente (el dueño de la pupusería) puede reunirse con el equipo semanalmente. Los requerimientos pueden cambiar (quizás decida agregar delivery más adelante). Recomendación: metodología ágil con sprints de 2 semanas.
Sprint 1: Login y gestión de empleados. Sprint 2: Gestión de productos y menú. Sprint 3: Toma de pedidos. Sprint 4: Facturación y reportes.
Al final de cada sprint, el dueño puede probar el sistema y dar retroalimentación.
1.4 Roles en el desarrollo de software
📐 Fundamento
En un proyecto de software hay múltiples roles. En equipos pequeños, una persona puede ocupar varios:
| Rol | Qué hace |
|---|---|
| Analista de sistemas | Levanta requerimientos, modela el sistema, escribe ERS |
| Arquitecto de software | Define la estructura de alto nivel, tecnologías, capas |
| Desarrollador / Programador | Codifica según el diseño |
| DBA (Database Administrator) | Diseña y mantiene la base de datos |
| QA (Quality Assurance) | Diseña y ejecuta pruebas |
| DevOps | Automatiza despliegue, CI/CD, infraestructura |
| Scrum Master | Facilita el proceso ágil |
| Product Owner | Voz del cliente; prioriza funcionalidades |
| UX Designer | Diseña la experiencia de usuario (interfaz, flujos) |
En equipos pequeños (startups, microempresas), el desarrollador generalmente hace análisis, diseño, código y pruebas. Por eso es crítico que todos los programadores entiendan ADS, no solo los "analistas".
1.5 Ejercicios
✏️ Ejercicio 1.1 — Clasificar requerimientos
Clasificá cada enunciado como RF (funcional) o RNF (no funcional):
a. "El sistema debe generar facturas en formato PDF." b. "El sistema debe soportar al menos 100 usuarios simultáneos." c. "El usuario puede filtrar pedidos por fecha." d. "La interfaz debe cargarse en menos de 3 segundos en una red 3G." e. "Solo el administrador puede eliminar productos del menú."
Solución
a. RF — es una funcionalidad específica del sistema. b. RNF — es un requerimiento de rendimiento (performance). c. RF — es una funcionalidad que el usuario puede ejecutar. d. RNF — es un requerimiento de rendimiento con restricción de red. e. RF con matiz de seguridad — es una regla de negocio sobre quién puede hacer qué.
✏️ Ejercicio 1.2 — Elección de metodología
Una empresa de logística en San Miguel quiere un sistema para rastrear sus camiones en tiempo real. El contrato con el Gobierno es de precio fijo por $80,000 con entrega en 12 meses. Los requerimientos están completamente documentados y el cliente no puede reunirse más de una vez al mes.
¿Qué metodología recomendarías? Justificá.
Solución
Recomendación: Modelo en cascada (o iterativo con fases bien definidas).
Razones:
- Contrato de precio fijo: Las metodologías ágiles son difíciles de presupuestar fijamente porque el alcance puede cambiar. Con cascada, el alcance está cerrado desde el inicio.
- Requerimientos completos y estables: No hay ambigüedad que requiera iteración frecuente con el cliente.
- Cliente disponible solo mensualmente: Scrum requiere al menos un Sprint Review cada 2 semanas con el Product Owner. Con reuniones mensuales, no es viable.
- Plazo de 12 meses definido: Se puede planificar cada fase con hitos claros.
Precaución: Si durante el desarrollo descubrís requerimientos no documentados (inevitable en sistemas complejos), debés tener un proceso de control de cambios formal para no comprometer el presupuesto.
✏️ Ejercicio 1.3 — Proyecto propio
Pensá en un sistema de información que podría beneficiar a algún negocio de tu comunidad (no uses La Esquina). Describí:
a. El problema que resuelve. b. Los roles involucrados (usuarios del sistema). c. Tres requerimientos funcionales. d. Dos requerimientos no funcionales. e. ¿Qué metodología usarías? ¿Por qué?
Solución
Respuesta abierta — no hay solución única. Aquí un ejemplo:
Sistema de citas médicas para clínica privada en San Miguel:
a. Problema: los pacientes llaman por teléfono para citas, el personal anota en cuaderno, hay doble agendamiento y los médicos no tienen historial accesible en consulta.
b. Roles: Paciente, Recepcionista, Médico, Administrador.
c. RF: (1) Agendar, modificar y cancelar citas. (2) Ver historial de citas del paciente. (3) Enviar recordatorio por SMS 24h antes.
d. RNF: (1) La aplicación debe funcionar en teléfonos Android 8+. (2) Los datos del paciente deben estar encriptados (HIPAA o equivalente).
e. Ágil / Scrum, porque el cliente (la clínica) puede reunirse semanalmente y los requerimientos probablemente cambiarán al ver los primeros prototipos.
1.6 Para profundizar
- Pressman, Ingeniería del Software, cap. 1-4 — el texto clásico de la materia.
- Schwaber & Sutherland, La Guía de Scrum — el documento oficial de Scrum, gratis en scrumguides.org.
- Bases de Datos I — el modelo de datos del sistema se diseña aquí.
- Siguiente: Levantamiento de requerimientos — aprenderás a documentar exactamente qué debe hacer el sistema.
Definiciones nuevas: análisis de sistemas, diseño de sistemas, SDLC, ciclo de vida del software, requerimiento funcional, requerimiento no funcional, modelo en cascada, metodología ágil, Scrum, sprint, backlog, Product Owner, Scrum Master.