Su guía completa para todo lo relacionado con el desarrollo de software

Publicado: 2020-08-13

¿Qué tan similares son el piso de producción de una fábrica y una oficina de desarrolladores de software?

Imagine una sala llena de programadores escribiendo código en sus computadoras. ¿Qué sucede si trata su producción como widgets ensamblados en una línea de ensamblaje de fábrica? ¿Las cosas que maximizan la producción también funcionarán aquí? ¿O el proceso de desarrollo se parece más a otras disciplinas de ingeniería?

Los gerentes de proyecto han estado tratando de resolver esto desde que comenzó el desarrollo del software. De estas preguntas ha surgido la definición del ciclo de vida del desarrollo de software.

¿Qué es el desarrollo de software?

Es el proceso de crear software desde cero. Si bien escribir código es la actividad central, es mucho más que eso.

El proceso de desarrollo incluye la ideación y el diseño antes de escribir cualquier código. La planificación es fácil de pasar por alto. No se siente como desarrollo de la forma en que se escribe código. Sin embargo, responder preguntas cruciales primero fortalece el producto terminado. ¿Vale la pena seguir con el proyecto? Si es así, ¿cuál es la mejor manera de hacerlo? ¿Qué características son necesarias y qué características es bueno tener? Las respuestas dan al proyecto una mejor oportunidad de éxito.

Si bien los pasos son constantes, su aplicación varía. La razón por la que el desarrollo de software es una nueva disciplina. Las disciplinas de ingeniería son maduras con cientos de años de historia. El desarrollo de software solo se remonta a finales de la década de 1940. Todavía es una nueva disciplina. El método ágil tiene solo 20 años. Sin embargo, es una de las cosas más influyentes que suceden en la teoría de la creación de software. Independientemente, las seis fases del ciclo de vida del desarrollo de software son comunes a todos los sistemas.

6 etapas del ciclo de vida del desarrollo de software (SDLC)

Un equipo de desarrollo puede utilizar el ciclo de vida de desarrollo de software en un proyecto completo o en una característica. La evolución del uso del SDLC se ha centrado en reducir el riesgo al acortar la duración de cada paso. En un momento, veremos más en las diferentes metodologías. Primero, examinemos los pasos mismos.

Además, vale la pena señalar que verá variantes en términos de la cantidad de pasos o sus nombres. A veces, los pasos se fusionan, como el desarrollo y las pruebas. Otras veces, verá un paso dividido en dos, como si la planificación se convirtiera en planificación y análisis. En nuestro caso, nos quedaremos con estos seis, ya que definen claramente las fases.

1. Planificación

La fase de planificación es el paso más importante. Las partes interesadas deben considerar todo, incluida la viabilidad del proyecto en sí. Está bien matar todo el proyecto aquí. Una organización saludable empoderará a las partes interesadas para hacerlo si es necesario. Los programadores tendrán menos participación durante esta fase en un entorno empresarial. Los propietarios de productos, analistas comerciales y otras partes interesadas expresan sus necesidades en este paso.

2. Diseño

3. Desarrollo

La etapa de diseño también incluye el diseño de la experiencia del usuario (UX). Si la aplicación tiene componentes orientados al usuario, el diseño de UX es imprescindible. Esto incluye la investigación de usuarios al ver a personas reales interactuar con maquetas de productos. La razón por la que esto sucede en la fase de diseño en lugar de la fase de desarrollo es el tiempo. Las sesiones de usuario toman tiempo. A menudo, también se producen más debates de ida y vuelta con las partes interesadas de la empresa a partir de los datos recopilados.

4. Pruebas

A continuación, el equipo de desarrollo prueba el código. El escritor del código y el evaluador deben ser personas diferentes. Aún mejor es un probador de control de calidad que no sea desarrollador. Los desarrolladores tienden a pensar solo en escenarios felices. Los profesionales dedicados a las pruebas de control de calidad tienden a pensar mejor en cómo pueden romper el software. Es más probable que encuentren errores antes de la implementación de esta manera. El resultado es un software más estable en el momento del lanzamiento.

Pruebas automatizadas vs. manuales

Las pruebas unitarias y las pruebas de integración suelen estar automatizadas. A menudo, una plataforma DevOps ejecuta estas pruebas en código nuevo antes de fusionarlo con la rama maestra.

Las pruebas manuales están lejos de ser obsoletas. Las pruebas automatizadas hacen lo mismo una y otra vez. Sin embargo, una persona que realiza una prueba manual puede encontrar errores por accidente durante la prueba. Es la variabilidad en las pruebas manuales lo que constituye su punto fuerte.

Examen de la unidad

Una prueba unitaria verifica solo un método, nada más. La función bajo prueba es la frontera. El desarrollador escribe las pruebas unitarias y algunos marcos SDLC las exigen. La programación extrema los requiere. También prescribe el desarrollo basado en pruebas. Esta es la práctica de escribir pruebas unitarias primero. Luego escribir el código del programa real.

Pruebas de integración

Las pruebas de integración verifican secciones o características del código base. Suelen estar automatizados y ejecutados por la plataforma DevOps. Lo que verifican abarca más de un solo método. Un ejemplo es verificar que una llamada API persistió en un nuevo registro en una base de datos. Compare esto con una prueba unitaria que también verifique el método API. La prueba unitaria solo podría verificar que debería ocurrir una llamada a la base de datos. La prueba de integración puede probar que los datos fluyeron a través de la aplicación como se esperaba.

Pruebas del sistema

La última forma de prueba es la prueba completa del sistema. En resumen, las pruebas unitarias solo verifican una función. Las pruebas de integración verifican una función. Pero las pruebas del sistema tratan toda la aplicación como una sola unidad. La prueba de humo es una forma ligera de prueba del sistema. En él, el probador interactúa con el sistema como lo haría un usuario natural y se asegura de que se comporte como se espera. En contraste con la prueba completa del sistema de extremo a extremo, que es más rigurosa. Una prueba completa del sistema verifica todas las partes de un sistema como una sola entidad. Además, un conjunto de pruebas de integración puede servir como una prueba completa del sistema.

5. Despliegue

La fase de implementación está empujando el código probado a la producción. La automatización de la implementación la hace más confiable. Además, practicar implementaciones de producción también aumenta las probabilidades de una implementación sin problemas. El equipo de desarrollo practica con un entorno de prueba llamado entorno de prueba. Debe ser idéntico al de producción. Cuanto más parecidos sean los dos entornos, más valor tiene la implementación de la práctica.

6. Mantenimiento

Todo hasta este punto en el SDLC será solo alrededor de una cuarta parte del costo total de propiedad. El costo inicial de desarrollo del software es el 25% de lo que gastará la empresa. La fase de mantenimiento le costará a la empresa alrededor del 75% del costo total de propiedad. La defensa contra el aumento de los costos de mantenimiento es prestar más atención a las primeras fases. Esto significa un mejor diseño técnico, desarrollo y pruebas más exhaustivas. La alternativa es la deuda técnica. Al igual que la deuda real, se vuelve más cara con el tiempo.

5 principales metodologías de desarrollo de software

Si bien los pasos de SDLC no cambian, su orden de implementación y ejecución varía. Veamos las formas más populares en que las organizaciones realizan el proceso de desarrollo de software.

1. Ágil

Lo que hace único a Agile es el enfoque en las personas. Las metodologías ágiles reenfocaron la atención de la industria. Antes, el foco estaba en el producto, el software. Agile desafió eso y se centró en las personas que realizan el proceso. Además, antes del Manifiesto Ágil, la Programación Extrema (XP) y Scrum no tenían conexión. Sin embargo, después, sus practicantes se unieron bajo la bandera Agile.

Agile no es un marco en sí mismo. Es un marco para marcos. En esencia, se trata de centrarse en las personas y las iteraciones rápidas. Es exactamente lo que dice el nombre, ágil. Bien hecho, hay flexibilidad para lograr el resultado. Los procesos nunca se realizan a expensas de las personas, que obtienen valor de ellos.

Otro inquilino clave de Agile es un enfoque iterativo. La idea es hacer bloques de trabajo en períodos de tiempo más cortos. De esa manera, la empresa puede adaptarse más rápido a los cambios en el mercado. La capacidad de cambiar rápidamente la dirección del desarrollo es lo que lo hace ágil. Al mismo tiempo, el equipo de desarrollo puede aprender de lo que ha hecho en cada iteración y mejorar. Los equipos ágiles hacen esto en reuniones retrospectivas después de cada iteración.

2. Programación extrema

La programación extrema (a menudo abreviada XP) comenzó a principios de la década de 1990. Martin Fowler fue uno de los firmantes originales del Manifiesto Ágil. Él piensa que Agile obtuvo su popularidad debido al marco XP. Además, sostiene que es la mejor manera de comenzar a desarrollar software Agile.

XP recibe su nombre de su enfoque. Toma buenas prácticas comunes de software y las requiere. Eso es lo que lo hace "extremo". XP requiere cosas como pruebas unitarias, programación en pares, lanzamientos más frecuentes.

Lo que hace que XP sea un método único es:

Ciclos de iteración cortos (lo común es de 1 a 2 semanas)
Apertura para reemplazar elementos de trabajo en la iteración actual (algo que Scrum no permite)
Énfasis en pruebas automatizadas y programación de pares.

3. Esbelto

Lean no era ágil técnicamente, pero tiene una sensación similar en la práctica. Ahora, la mayoría lo acepta como parte de Agile. Su enfoque es diferente al Agile tradicional. Según el manifiesto Agile, "Individuos e interacciones sobre procesos y herramientas". Lean se enfoca más en el software que en los fabricantes.

Sus raíces son los principios de manufactura esbelta de Toyota. Aquí están las siete partes que lo definen. Si está familiarizado con la fabricación Lean, estos sonarán similares. Están:

Eliminar residuos
Amplificar el aprendizaje
Decidir lo más tarde posible
Entregar lo más rápido posible
Empoderar al equipo
Construir integridad en
optimizar el conjunto

4. melé

Scrum es el método ágil más popular. Según el 14º informe State of Agile, el 58 % de las empresas de software utilizan Scrum. Si incluye híbridos Scum, el porcentaje salta al 84%. Lo que plantea la pregunta, ¿por qué es el más popular?

La respuesta es Scrum se trata de hacer más trabajo en menos tiempo. Eso atrae a las empresas. Cada iteración en Scrum es un "sprint". El nombre refuerza la idea de velocidad. Por lo general, un sprint dura de 2 a 3 semanas. Una vez que un equipo Scrum ha planificado un sprint, nadie debe modificarlo. El nuevo trabajo tiene que esperar hasta el inicio del próximo sprint. Esto requiere disciplina por parte de las partes interesadas del negocio. En la práctica, esta regla de Scrum se viola a menudo. Es por eso que los equipos informan que hacen Scrum híbrido con frecuencia.

Otra característica de Scrum es el Scrum Master. Este es un miembro del equipo designado para estar a cargo de mantener el sprint en el objetivo. A menudo, Scrum Master es un desarrollador del equipo de desarrollo.

La variante más común de Scrum es ScrumBan, que es una combinación de Scrum y Kanban. Kanban tiene sus raíces en el proceso de fabricación japonés de Toyota como Lean. Es un sistema de trabajo justo a tiempo.

Cada elemento de trabajo es como una iteración propia. Un desarrollador solo trabaja en una cosa a la vez. La regla es un elemento "en curso" por desarrollador. Este límite estricto de trabajo en curso arroja luz sobre cualquier cuello de botella. Los desarrolladores realizan un seguimiento de los elementos de trabajo en curso a través de un tablero Kanban. Como nota al margen, de ahí viene el nombre. En japonés, Kanban significa "letrero".

5. Cascada

El método de cascada es la primera de todas las prácticas de desarrollo de software. Es anterior a Agile por varias décadas al menos. Este método también es más antiguo que su nombre.

Es la forma natural en que las empresas siempre han trabajado. Es un proceso lineal, y comienzas desde el principio. Primero, las partes interesadas compilan los requisitos. No están haciendo esto por una característica o dos. No, las partes interesadas del negocio analizan todo el proyecto a la vez. Después, comienza el trabajo. Los desarrolladores hacen todo el trabajo sin ninguna iteración hasta su finalización.

La forma de cascada es la más fácil de entender conceptualmente. La gente hace una cosa a la vez. Dicho esto, es el más arriesgado para el éxito empresarial. Si algo está fuera del objetivo, las partes interesadas no pueden corregirlo hasta que finalice el proyecto. La razón es que ni siquiera se notará hasta la finalización del proyecto.

3 subtipos principales de software

El software terminado es uno de tres tipos. Estos tipos son software de sistema, de programación y de aplicación. Para ilustrar, aquí hay una analogía de hornear pasteles. Una batidora o espátula es el software de programación. Le permite hacer más pasteles o más aplicaciones de software en esta analogía. Al armar un pastel, la capa inferior es el software del sistema. es la base Sin él, no puedes tener un pastel en capas. La capa superior sería entonces el software de aplicación. Es lo que es visible para la mayoría de los observadores casuales.

Software del sistema

El sistema operativo de una computadora es el software del sistema. Es crucial para la utilidad de la misma. Imagina una computadora sin un sistema operativo. Solo podrá interactuar con él a través del lenguaje de máquina. Eso es binario puro, solo unos y ceros. Le resultaría imposible trabajar con él en cualquier nivel de escala. El software del sistema abre la utilidad de una computadora.

Windows, macOS y Linux son los ejemplos más populares de software de sistema. Los controladores de dispositivos también son software del sistema. Extienden la funcionalidad básica de un sistema operativo. Los dispositivos inteligentes sin un sistema operativo usan firmware para habilitar su funcionalidad. También es software del sistema.

software de programacion

El software de programación es un subconjunto del software de aplicación. Cualquier programa que un desarrollador utilice para crear nuevos programas se clasificaría. Van desde simples editores de texto hasta complejos entornos de desarrollo integrado (IDE). La mayoría de los desarrolladores prefieren herramientas de software de programación más complejas. Programas como Visual Studio de Microsoft ayudan a acelerar el desarrollo.

Software de la aplicacion

El software de aplicación es el tipo más común. Es el software que te permite hacer cosas con una computadora. Hace que las computadoras sean útiles. Ejemplos populares son programas como Microsoft Word y Excel.

El software en la nube también entra en esta categoría. Google Docs, Dropbox e incluso Instagram son software de aplicación. Si alguna vez te sientes confundido si algo es un software de aplicación o no, aquí hay una prueba simple. ¿El programa necesita algo más para ejecutarse? Windows o Android no. Son software del sistema. PowerPoint, o incluso un juego como Call of Duty, necesitan que otras cosas se ejecuten para funcionar, lo que significa que son software de aplicación. Sin controladores de dispositivos y un sistema operativo, no se pueden ejecutar.

Conclusión

Los métodos de desarrollo de software aún están madurando. Sin embargo, independientemente del método utilizado, los pasos siguen siendo los mismos. Los equipos ágiles pueden iterar sobre ellos más rápido, y los practicantes de Waterfall se mueven lentamente de uno a otro. Sin embargo, para construir un mejor software, debe fortalecer el proceso para cada paso. Se construyen unos sobre otros. El ciclo de vida del desarrollo de software no es una cosa sin uno de sus pasos. Las partes hacen el todo.

Piensa en lo que pasaría si dejaras algún paso fuera. ¿Sin planificar lo que estás haciendo? Sin diseño, el proceso de desarrollo será desordenado. Omitir el paso de desarrollo es imposible. La falta de pruebas asegura que el producto no funcionará como se esperaba. Si no hay implementación, nadie tendrá acceso para usar el producto. Una aplicación sin mantenimiento cae en desuso. Cada paso es crucial para el éxito de un producto de software.