Reflexión Final

Ya estamos terminando el semestre, el año y con esto también la década, por lo que para mi es momento de reflexionar de lo que he aprendido a lo largo de este tiempo, por lo menos en esta materia, aunque no limitado.

Uno cuando piensa en los alumnos de la carrera de Sistemas Computacionales piensa en personas que siempre están frente a una computadora, sentados todo el día sin hablar con otra persona, mas con las que se comunica por medio de la misma computadora, que en parte es verdad, pero esto solo es una pequeña parte. Como alumno de esta carrera puedo dar otro punto de vista que muchas personas ni se podrían imaginar y que como yo lo veo es el colmo, este punto de vista es que en verdad esto no pasa, la verdad es que para poder trabajar de manera correcta se tiene que hablar con muchas personas tanto físicamente como virtualmente, esto se debe a que la gran mayoría de los proyectos se tienen que hacer en equipo por la complejidad de estos y porque, como todos sabemos, vivimos en una sociedad donde una persona no puede hacer todo, si no que tiene que ayudarse de los otros para poder lograr lo que quiere.

Ya declarado que los proyectos tienen que ser trabajados en equipo, se necesitan tanto tiempo como herramientas para poder comunicar el proyecto así como ponerse de acuerdo de el cuándo, dónde y cómo se va a trabajar, como he mencionado antes, la planeación lleva 1/3 parte de el tiempo total del proyecto, por lo que se han hecho muchas herramientas para poder hacer este proceso de manera correcta y con lo mínimo de errores posibles. Estas herramientas ayudan con cada parte de la planeación, por lo que van así:

  1. Ciclos de Vida del Software
PrepInsta, 2019. Page

La primera cosa que se tiene que decidir cuando se va a empezar con un proyecto nuevo es la manera en la cual se va a trabajar, dependiendo del modelo seleccionado es el orden en el que se harán las cosas, por ejemplo, si se va a hacer testing después de cada proceso o solo hasta el final. Los modelos más comunes son los siguientes:

    • Modelo de Cascada
    • Modelo en V
    • Modelo de Prototipos
    • Modelo en Espiral
    • Modelo Ágil
  1. Casos de Uso
Warren Lynch, 2015, Page

El siguiente paso es hacer los casos de uso, estos son diagramas que describen Quién va a usar cada parte de el software, Cómo se va a usar y de Qué manera va a afectar tanto a otros usuarios como a otras partes del software. Esto se hace para poder tener claro lo que se va a hacer, esto se le muestra al cliente para que pueda dar retro alimentación y que el proyecto no vaya por la dirección equivocada.

  1. Lenguajes de Modelado
GeeksForGeeks, Page

Ya que se tienen claras las acciones que el sistema debe de tener, se pasa a la fase del modelado de estas, dependiendo del enfoque del proyecto es el lenguaje que se debe de escoger, esto se debe a que como hay tantos tipos de software es necesario tener diferentes diagramas para poder plasmarlos de manera correcta. Los tipos de lenguajes que más comúnmente se usan son los siguientes:

    • Lenguaje de Modelado de Sistemas
    • Lenguaje de Modelado de Objetos
    • Lenguaje de Modelado de Datos
  1. Patrones de Diseño
Paul Ballard, 2015, Page

Así como se debe de escoger el Lenguaje de Modelado que se va a utilizar en el proyecto, también se debe de escoger el Patrón de Diseño que se va a utilizar, esto se refiere a las mejores prácticas adoptadas por desarrolladores con muchas experiencia en el paradigma orientado a objetos y se hacen para que se pueda seguir su ejemplo. Algunos ejemplos de estos patrones son los siguientes:

    • Patrón de Diseño Creacional
    • Patrón de Diseño Estructural
    • Patrón de Diseño basado en Comportamiento
  1. UML
UML, Page

El siguiente paso es crear diagramas que describan el sistema, de esta manera el grupo de desarrolladores tienen la misma imagen de lo que se tiene que va a hacer cada parte del software así como la comunicación entre ellas. Existen una gran cantidad de modelos UML ya que también hay una gran cantidad proyectos diferentes, y estos tratan de modelar de la mejor manera cada proyecto. Ejemplos de estos diagramas son los siguientes:

    • Diagramas Secuenciales
    • Diagramas de Clase
    • Diagramas de Objetos
    • Diagramas de Estado
    • Diagramas de Paquetes
    • Diagramas de Componentes
  1. De Diagrama a Código

Después de hacer tantos diagramas y tantos dibujitos por fin es la hora para ponerse a programar, ya con los diagramas sabemos qué es lo que tenemos que hacer y basta con solo saberlos leer e interpretar, que aunque suena sencillo, no lo es por el mero hecho de que hay muchos tipos de diagramas. Ya empezando a programar se vuelve diferente el trabajo, esto es lo que hemos aprendido a lo largo de toda la carrera y se supone que sabemos hacerlo de una manera correcta, pero para sacar errores está el siguiente paso.

  1. Revisión de Código
edx, Page

La primera parte para revisar un código y sacar posibles errores que se cometieron en el momento del desarrollo es leerlo por tu mismo un poco de tiempo después, a veces se nos van errores obvios a la primera, pero a la segundo ya podemos verlos y arreglarlos.

La segunda parte es poner a un compañero a leer nuestro código, esto ayuda a que una persona con otra perspectiva pueda ver posibles errores, así como verificar que tu código pueda ser entendido por otra persona que no tiene el contexto que uno tiene, así verificando que nuestro código se pueda leer y de esta manera que sea escalable para otras personas, lo peor que puede pasar es que al momento de que se quiere cambiar un código, ya sea para crecerlo o porque los requerimientos cambiaron, este solo pueda ser cambiado por la persona que lo escribió, que es muy posible que ya ni trabaje en el mismo lugar.

La última parte es ya se podría decir la última alternativa, se hacen pruebas automáticas como si fuera un usuario y se hace una prueba de estrés al software para ver si es que puede llegar a fallar, si falla se tiene que corregir antes de que se entregue al cliente.


Después de haber tomado esta y otras clases parecidas me doy cuenta de la importancia de primero modelar lo que se va a hacer antes de querer ponerse a programar, uno dice, en la escuela primero nos ponen a programar así que lo primero que deberíamos de hacer es programar. Por esto considero que en la carrera las primeras clases que deberíamos de ver son estas, de esta manera nos enseñarían que primero debemos de tener claro lo que queremos hacer antes de ponernos directamente a la acción, esto evitaría muchos errores y nos ayudaría a ser mucho más ordenados, ya que actualmente lo que nos enseñan es primero programar y esto lleva a veces que no tenemos claro lo que haremos y nos tardamos más en las cosas que nos piden, así perdiendo el tiempo.

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website at WordPress.com
Get started
%d bloggers like this: