El ciclo de vida del desarrollo de software tradicional(SDLC, por sus siglas en inglés) es el más utilizado para diseñar productos de software en tres partes principales:
1. Análisis de requisitos
2. Modelado de datos
3. Normalización
Durante la primera fase, el análisis de requisitos, el equipo de desarrollo y diseño lleva a cabo entrevistas con el fin de capturar todas las necesidades del negocio relacionadas con el sistema propuesto. La fase de modelado de datos consiste en la creación del modelo de datos lógico, que posteriormente se utilizará para definir el modelo de datos físico o las estructuras de la base de datos. Una vez que la base de datos ha sido modelada y diseñada, se implementa la fase de normalización para ayudar a eliminar o reducir tanto como sea posible cualquier dato redundante. A continuación, se presenta una descripción más específica de las actividades incluidas en el ciclo de desarrollo.
Desarrollo
El ciclo de vida del desarrollo incluye cuatro componentes generales. Desde esta perspectiva, el «desarrollo» consistiría en todos los pasos necesarios para llevar a cabo la creación de la aplicación.
Esto incluye la viabilidad, el análisis, el diseño y la codificación propiamente dicha. La viabilidad representa las tareas necesarias para determinar si el proyecto de desarrollo de software tiene sentido desde el punto de vista empresarial. La mayoría de las organizaciones integrarían el proceso de retorno sobre la inversión (ROI, por sus siglas en inglés) durante este paso.
El ROI consiste en los pasos financieros que determinan matemáticamente si el proyecto proporcionará los rendimientos monetarios necesarios para el negocio. Centrarse únicamente en los retornos monetarios puede ser una trampa grave, ya que hay muchos beneficios que pueden obtenerse a través de retornos no monetarios.
La viabilidad a menudo contiene lo que se conoce como un pronóstico o presupuesto de alto nivel. El «alto» representaría el «peor caso» en términos de costos y el «bajo», el mejor caso o el costo más bajo. La esperanza, por supuesto, es que el costo real y el cronograma queden en algún punto intermedio entre el alto y el bajo.
Pero la viabilidad va más allá del presupuesto; también representa si la empresa considera que el proyecto es alcanzable dentro de un cronograma específico. Por lo tanto, la viabilidad es una declaración tanto de los objetivos financieros como empresariales, y una creencia general de que el costo vale la recompensa.
El análisis en el ciclo de vida del desarrollo de software
El análisis es el paso final para crear los requisitos lógicos detallados o la arquitectura de las aplicaciones y la base de datos. En última instancia, el analista crea un documento de requisitos que describe todas las necesidades para que los codificadores trabajen sin tener que regresar directamente a los usuarios en busca de aclaraciones.
El análisis, como responsabilidad arquitectónica en el ciclo de vida del desarrollo de software, se basa mucho en una progresión matemática de pasos predecibles. Estos pasos son bastante iterativos por naturaleza, lo que requiere que los profesionales comprendan la naturaleza gradual de la finalización de este paso vital en el desarrollo.
Otro aspecto de las matemáticas del análisis es la descomposición. La descomposición establece la creación de los componentes más pequeños que conforman el todo. Es como los huesos, la sangre y los músculos del cuerpo humano que, en última instancia, conforman lo que físicamente vemos en una persona.
Una vez que un sistema está descompuesto, el analista puede estar seguro de que las «partes» que componen el todo están identificadas y pueden reutilizarse en el sistema según sea necesario.
Estas partes descompuestas se denominan «objetos» y comprenden el estudio y la aplicación del análisis y diseño orientado a objetos. Por lo tanto, la base de trabajar con los usuarios lleva en última instancia a la creación de partes conocidas como objetos, que actúan como componentes intercambiables que pueden utilizarse cuando sea necesario.
Se puede pensar en los objetos, dentro del ciclo de vida del desarrollo de software, como en partes intercambiables de un automóvil. A veces se les llama «estándar», ya que pueden reutilizarse en múltiples modelos. Los beneficios son obvios. El mismo objetivo aplica al software: cuanto más reutilizable, más eficiente y rentable.
El diseño en el SDLC
El diseño es mucho menos lógico que el análisis, pero es un paso mucho más creativo. El diseño es la fase que requiere decisiones físicas sobre el sistema, desde qué lenguaje de programación utilizar, qué base de datos de proveedor seleccionar (por ejemplo, Oracle, Sybase, DB2), hasta cómo se identificarán las pantallas y los informes.
La fase de diseño también puede incluir decisiones sobre hardware y comunicaciones de red o la topología. A diferencia del análisis, el diseño requiere menos enfoque matemático e ingenieril, y más uno que realmente sirva a la perspectiva del usuario.
El proceso de diseño es quizás el más iterativo, lo que podría requerir múltiples sesiones con los usuarios mediante un enfoque de prueba y error hasta que se complete la interfaz de usuario correcta y la selección del producto.
El diseño a menudo requiere «expertos» en diseño de bases de datos, arquitectura de pantallas, así como profesionales que comprendan las necesidades de rendimiento de los servidores de red y otros componentes de hardware requeridos por el sistema.
Codificación
La codificación representa otro enfoque arquitectónico y matemático. Sin embargo, sugiero que las matemáticas no son la descripción más precisa de una estructura de codificación, sino que se trata más bien de entender cómo opera la lógica.
Esta componente de las matemáticas se conoce como «álgebra booleana» o las matemáticas de la lógica. El álgebra booleana es la base de cómo el software se comunica con la máquina real. El software es la abstracción física que nos permite interactuar con la máquina de hardware.
Entonces, la codificación es la mejor manera de desarrollar realmente la estructura del programa. Se ha escrito mucho sobre estilos y formatos de codificación. El más conocido se llama «programación estructurada». La programación estructurada fue desarrollada originalmente para que los programadores crearan código cohesivo, es decir, que fuera autosuficiente.
La autosuficiencia en la codificación significa que el programa es autocontenido porque toda la lógica relacionada con sus tareas está dentro del programa. Lo opuesto a la cohesión es el acoplamiento.
El acoplamiento es la lógica de los programas que dependen unos de otros, lo que significa que un cambio en un programa implica un cambio en otro. El acoplamiento se considera peligroso desde una perspectiva de mantenimiento y calidad, simplemente porque los cambios causan problemas en otros sistemas dependientes o «acoplados».
La relación entre la codificación y el análisis puede ser crítica, dado que la decisión sobre qué código conformará un módulo puede determinarse durante el análisis en lugar de durante la codificación.