En este parcial de la materia de Análisis y Modelación de Sistemas de Software he aprendido que para poder desarrollar un proyecto no basta con empezar a escribir código, lo que suele pasar la mayoría de las veces en este ramo, ya que nos enseñan a programar antes de a cómo organizar el proyecto y ver qué es lo que nos piden, siendo el diseño y análisis lo primero que deberíamos de hacer para poder comprender lo que se nos pide.
De los errores más comunes al desarrollar un sistema de software es la falta de entendimiento en los requerimientos, ya sea porque los clientes en verdad no saben qué es lo que quieren, no saben cómo explicarlo o no sabemos cómo entenderlo nosotros, por lo que pasa que un cliente pide un proyecto y el que se entrega es diferente, se piden cambios tan grandes que el proyecto termina cambiando completamente, lo que hace que se pierda mucho tiempo y dinero en estos casos.
- Ciclos de Vida del Software
El desarrollo de software se puede descomponer en diferentes procesos, a la suma de los procesos se les llama Ciclo de Vida de Software, ya que va desde el análisis de los requerimientos hasta el final del proyecto donde se le tiene que dar mantenimiento al sistema.
Hay diferentes modelos para poder plasmar el proyecto en diagramas y poder separarlos en los diferentes procesos, los cuales se enfocan en diferentes cosas cada uno, las opiniones de las personas son variadas en cuál es el mejor, pero es cuestión de perspectiva y de el tipo de proyecto que se quiere modelar, ya que algunos se basan en que se de feedback del proyecto cada pequeña entrega que se haga (normalmente cada semana o cada semana), mientras que otros se basan en que se tenga una separación marcada entre cada proceso.
Los modelos más comunes son:
- Modelo de cascada
- Modelo en V
- Modelo de prototipos
- Modelo en espiral
- Modelo ágil
- Proceso Unificado de Software
Al haber tantos modelos para el desarrollo de software lo que se trató de hacer es tomar las mejores partes de cada uno y hacer un modelo que se use en todos los proyectos.
Una de las mejores partes son los casos de uso los cuales nos sirven para poder tener las requerimientos claros, los escenarios de cada usuario que va a tener interacción con el sistema y cuáles serán las interacciones de los usuarios con el sistema, tomando paso por paso las interacciones para no saltarnos ningún paso importante o propenso a errores.
Del modelo ágil se toma la parte iterativa e incremental, la cual se refiere a que se hará por partes el proyecto, con entregas en poco tiempo, para que se pueda tener feedback del cliente, por si quiere cambiar algo del proyecto o fue completamente mal entendido lo que quería.
También se toma el enfoque centrado a la arquitectura, este se refiere a poder hacer un esquema de las partes del proyecto, para ver cuáles ya se han implementado y qué es lo que hace cada una, así teniendo un esquema claro del proyecto.
- Casos de Uso
Con esta imagen se puede explicar completamente por qué son necesarios los casos de uso en el desarrollo de un sistema de software, el cliente pide una cosa, pero ya sea por que pasa por demasiada gente o por la complejidad del proyecto, se hace algo que no termina siendo lo que se pidió, por lo que se necesita tener claro lo que el cliente pide y los casos de uso ayudan en eso al separar los usuarios y las acciones que estos tendrían con el sistema.
- Lenguajes de Modelado de Software
Otras herramientas que nos ayudan para poder tener la imagen clara del proyecto son los lenguajes de modelado de software, ya que estas son herramientas desarrolladas por personas o empresas que tienen experiencia en este ramo, por lo tanto pudieron hacer las herramientas para que cualquier persona modelando un proyecto puedo hacer eso de estos y se facilite más la tarea que tiene, los diferentes tipos que hay son:
- Lenguajes de Modelado de Sistemas
- Lenguajes de Modelado de Objetos
- Lenguajes de Modelado de Datos
Esta clase ha sido muy importante para mi para darme cuenta que en verdad es 100% necesario modelar el software que se quiere hacer antes de poder ponerte a programar.
Lo podemos ver como que una empresa quiere hacer un auto, con la pura idea de qué es lo que tiene que llevar no se puede hacer, se necesita hacer un plano con las especificaciones completas y exactas para poder fabricarlo, en el software pasa igual, aunque no hay un producto físico que se pueda ver, ya que un software puede ser tan complejo como para que se tenga que dividir en partes y hacer un plano de qué es lo que hace cada parte y cómo se relaciona con las demás. En un auto el motor se puede ver como la parte principal, mientras que en el software la parte principal del programa sería donde se procesa la información, pero como un auto, no solo se compone del motor, si no que necesita todas las partes para que funcione, el chasis para que pueda ser manejado por el usuario, lo cuál sería la interfaz del software en este caso, así como otras partes.
Lo que sigue es continuar viendo más temas sobre el modelado del desarrollo del software, el cual me va a permitir tener una visión más completa del proyecto antes de empezar a hacerlo, ya que como dice el libro The Mythical Man-Month (2013), el cuál recomiendo leer, el tiempo para desarrollar un proyecto se va en estas partes:
- 1/3 parte planeando
- 1/6 parte escribiendo código
- 1/4 parte probando los componentes en la versión temprana del sistema
- 1/4 parte probando los componentes cuando ya está terminado el proyecto
Por lo que nos damos cuenta que la parte que más tiempo toma es la planeación del proyecto, por lo que se debe de tomar muy en serio este proceso y por consiguiente su estudio para poder hacer un proyecto de la manera correcta y más eficiente. Entre más herramientas tengamos para esto, mejor saldrá esta parte, haciendo que el proyecto en general salga bien, ya que esta es la base del proyecto completo, hacer un proyecto sin la parte del análisis es como hacer una casa sin hacer un plano y la investigación necesaria para ver si el suelo necesita algún cambio, puede ser que funcione y salga bien, pero es muy probable que falte algún detalle y con un pequeño problema toda la casa se venga abajo.
Analysis and Modeling of Software 