Alex's Barn

Modele un buen título para este post.

Las entradas que he estado generando, en lo que va del curso de Analisis y Modelado de Software, tienen una historia que contar.
O más que una historia, se trata de una larga (y mal hecha) fábula que canta como moraleja:

Planea y modela la estructura tu software, 

para poder construir grandes proyectos 
a partir de bloques pequeños, 
para que tu equipo de trabajo se halle 
en la misma sintonía, 

para que la comunicación fluya
 entre las distintas partes,
 para que puedan dosificar 
adecuadamente el trabajo 

y  finalmente resulte 
un producto de calidad, 
que el usuario final 
termine realmente usando.

Así se vería tu equipo si no hicieras caso omiso al diseño de tu producto.

Hasta ahora, este largo relato nos ha enseñado que todo proyecto de software tiene orden intrínseco en su fabricación: a grosso modo, un inicio, un desarrollo y un final ( Si quieres ver más click AQUI), luego de haber comparado los distintos ciclos de vida
vislumbramos un cierto orden específico para construir software: el Proceso Unificado de Desarrollo de Software, que aplicaba las mejores características de los distintos ciclos de vida para generar un proceso aplicable a una gama amplia de proyectos.

Hemos aprendido a plasmar lo que el cliente y los usuarios dicen necesitar con las historias de usuario por otro lado, hemos aprendido a plasmar un bosquejo de como solventaremos las necesidades del cliente con los casos de uso.

El siguiente paso para nosotros, es transformar los requerimientos del cliente, en un mapa detallado de la arquitectura de nuestro sistema a construir. Siguiendo con la analogía del post Mastery02, en nuestro proceso para construir nuestro edificio (producto de Software) es tiempo de transformar las ideas en un plano de construcción.
Para realizar planos en arquitectura, se utilizan ciertas convenciones para que el plano sea comprendido por cualquiera que siga dichas reglas. Si las reglas fueran universales, todos podrían entender el plano.

Todo gran proyecto, conlleva un gran plano.

Por ejemplo, recuerdo que en mis clases de dibujo técnico en la prepa, nos hacían utilizar estilógrafos de distintos diámetros, para indicar distintos significados en los trazos. Los trazos con lineas delgadas y punteadas implicaban contornos de la parte posterior del objeto, las lineas gruesas y continuas, referían a contornos directamente visibles.
Para generar los planos que describirán la arquitectura de nuestro software, se ha desarrollado un conjunto de reglas que expresan de forma consistente las relaciones e interacciones entre los componentes de nuestro sistema. Estas reglas han sido representadas en un distintos lenguajes: Los lenguajes de modelado de Software.

Lenguajes de modelado de Software

Para podernos entender entre seres humanos, necesitamos un lenguaje de por medio. Poco serviría hacer nuestros diagramas, si nadie más ( compañeros de trabajo, clientes, proveedores) los entendiera a primera vista!
Por lo tanto, para modelar software se han formulado distintos lenguajes. No voy a adentrarme en lenguajes similares o intentar compararlos. Me dí cuenta que existen distintos lenguajes de modelado ( fuera de UML cof cof ), que son válidos y útiles porque atacan necesidades específicas.

IFML ( Interaction Flow Modeling Language)

Este lenguaje está diseñado para expresar el contenido, la interacción y los comportamientos de control de aplicaciones de front end.

En lo personal,considero muy valioso que exista un lenguaje de modelado que se enfoque en la interacción del usuario con la aplicación web. Que el lenguaje propine diagramas de navegación entre componentes, hace más intuitiva la idea de diseño del producto.

Herramientas para modelado de Software

Al crear estos «planos» que modelen nuestro producto, tenemos la capacidad de automatizar el proceso de producción de software. El acto de modelar nuestro software nos da la oportunidad de estructurar nuestro producto en componentes, clases y objetos.
Al aplicar jerarquias entre nuestras clases y su comunicación, podemos controlar el flujo de datos en nuestra aplicación, reutilizar codigo y se genera un proyecto con una estructura más clara.
Si leemos nuestros diagramas, podremos entender el funcionamiento de nuestro producto, aunque este aún no exista!
Conforme pasa el tiempo, los productos de software se vuelven más complejos, mientras que necesitamos que dichos sistemas se vuelvan más sencillos para mantener y reparar. En definitiva, crear construir sin planos ya no es una opción.

Por ahora, para realizar estos planos de nuestro producto de software, necesitamos herramientas que nos faciliten el proceso. Existe una infinidad de productos útiles para modelar software.

yEd
StarUML
Visio
Modelio
Drawio
MagicDraw
Creately
IBM Rational Rose
Visual Parardigm
Astah
Poseidon
IBM Rational
Pacestar UML IBM Rational
Pacestar UML yEd
StarUML
Visio
Modelio
Drawio
MagicDraw
Creately
IBM Rational Rose
Visual Parardigm
Astah
Poseidon
IBM Rational
Pacestar UML
y muchos más…

( Edit: encontré una lista inmensa de herramientas de modelado, afortunadamente, hallé otros post que se toman el tiempo de explicar sus herramientas favoritas, como este blog).

Es difícil declarar una herramienta mejor o peor. En general, lo importante es que tu te sientas cómodo con tu herramienta y sea una forma fácil para documentar tu proyecto. Hasta hacer diagramas en pizarrón o a papel funciona, pero recordemos que a veces es necesario darles un formato a nuestros diagramas para futura referencia y visualización con los clientes.

Los diagramas a mano son útiles, pero recuerda que otros más los usarán como documentación.

¡Arma tu propia fiesta aplicando casos de uso!

Imagina esto: tu hijo ( o sobrino ) preferido te pide una fiesta de cumpleaños. La realidad es que comienza a lloriquear, hace pataletas en el suelo, dando la ilusión de una hélice de helicóptero suelta. ¡El niño quiere un una fiesta para su cumpleaños!.
Tu comienzas a desesperarte y debido a que ese niño es tu debilidad deseas complacerlo. Comienzas a preguntarle que quiere exactamente. Imaginemos dicha tertulia:
-¿Quieres que haya un mago?
-No, No quiero un mago! ¡Quiero payasos!
-¿Pastel de chocolate?
-No! Quiero un pastel de fresa, unas piñatas de (Inserte personaje de caricatura aquí), bolos, un brincolín y mucha comida.

Y en tu cabeza comienza a formarse la idea de lo que el niño quiere. Luego de un par de preguntas, lloriqueos y respuestas cortas, el niño te describe su fiesta perfecta:
El quiere una fiesta de vaqueros, con sombreros de vaquero, que haya un DJ que ponga la canción de El ratón vaquero una y otra vez, payasos que les maquillen la cara y les hagan show, pastel, piñatas, hamburguesas de comer y helado de postre (vaya niño exigente).

Detengamonos un momento. Como ya se habrán dado cuenta en mis anteriores entradas, estas historias intentan explicar conceptos de software de forma sencilla.
Como ingenieros de software, nos topamos con clientes que pocas veces saben lo que quieren. Los requermientos (representados por el acto anterior) nos ayudan a darnos una idea concreta sobre lo que el cliente quiere y (cree) que necesita. Evidentemente, el producto final debe cumplir con las necesidades del cliente.
Así como le preguntarías al pequeño cual es la fiesta perfecta para él, al grado de poderte hacer una idea específica de lo que desea.

Volvamos a la historia. Le dices al niño que tendrá su fiesta (vaya que lo tienes consentido). El niño para este entonces ya tiene fantasías con su cumpleaños. El no se preocupa de donde lo vas a obtener.
Sin embargo, tú como adulto, has comenzado a pensar y hacer planes: ¿Le voy a dar bolo solo a los niños o a todos los invitados? Es necesario contar cuantos invitados necesito, cuantos niños y cuantos adultos. ¿Haré las hamburguesas yo solo, le pido ayuda a mi madre o contrato un servicio de comida? ¿Contrataré payasos? Entonces debo buscar una agencia, llamarles y contratarlos. ¿Y si hacemos la fiesta en casa?, sería divertido tener una pequeña pijamada para sus amigos. ¿O que tal si realizo una fiesta de disfraces y les pido que vengan disfrazados? ¿Le pediré a mi tía, que es buena con manualidades, que haga la decoración? ¿Que tal si solo contrato una agencia de eventos y delego este dolor de cabeza que me acaba de asaltar?

Al niño no le interesa el modo en que vas a organizar la fiesta. Así como el cliente no se interesa en absoluto el funcionamiento del producto, mientras se ajuste a sus requerimientos.

Sin embargo, para nosotros los desarrolladores, es importante hacernos una idea muy clara de como van a interactuar los distintos usuarios y componentes en nuestro producto.
Para describir las distintas acciones a realizar entre dichos elementos, realizamos casos de uso.
En nuestra historia, los casos de uso serían los posibles escenarios que ocurren en la fiesta. Mientras los niños están en el show de payasos, ofreceré cervezas a los padres de familia. Mis familiares se sentarán en una misma mesa, los vecinos en otra. La piñata solo la romperán los pequeños, para los adolescentes y adultos tendremos una rifa de regalos. A los amigos más cercanos se les dará un juguete, la decoración la realizará un servicio contratado.
Lo importante aquí, es definir claramente los actores involucrados, así como las acciones (relaciones) que ejercen sobre otros componentes.
Aún no nos adentramos en el diseño de la arquitectura de nuestro proyecto. Los casos de uso describen solamente las interacciones entre componentes y actores, las enuncian. El cómo viene después.

Entrados en contexto, podemos ya explicar de forma más concreta que es un caso de uso:

El caso de uso es una descripción más detallada de un conjunto de interacciones entre el sistema y uno o más actores, donde un actor es un usuario u otro sistema.

El caso de uso se crea como un documento que incluye:

Breve descripción con el objetivo
El trigger (evento o secuencia de eventos que inician el caso de uso)
La especificación de los actores
Condiciones previas (las cosas que deben suceder en el sistema)
Flujo normal, flujo alternativo, excepciones (desviaciones del flujo normal)
Publicar condiciones (qué sistema debe haberse logrado al final de los pasos de flujo normales o alternativos)

Como ya mencionamos, los casos de uso tienen más que ver con el comportamiento que el equipo técnico tendrá que incorporar al software. Se describe claramente todo lo que un desarrollador necesita construir para satisfacer las necesidades de los usuarios. ¡Y los desarrolladores tendrán una buena idea de lo que debe hacer el software!
Si quieres seguir leyendo, encontré una entrada que aterriza a nivel profesional la utilización de los casos de uso. El link lo encuentras Aquí.
Los casos de uso son comúnmente representados como diagramas. La notación que recomienda UML para dichos diagramas la presentaremos a continuación.

Simbología de los casos de uso
Sistema: El rectángulo representa los límites del sistema que contiene los casos de uso. Los actores se ubican fuera de los límites del Sistema.
Caso de uso: Se representan con óvalos. La etiqueta en el óvalo indica la función del sistema. ( Es fundamental que cada caso de uso conlleve una acción específica. Es decir, el caso de uso conlleva un verbo involucrado, así como al objeto al cual se le aplica la acción).
Actor: Un diagrama de caso de uso contiene los símbolos del actor y del caso de uso, junto con líneas conectoras. Los actores son similares a las entidades externas; existen fuera del sistema. El término actor se refiere a un rol específico de un usuario del sistema. ( Generalmente son asociados los actores con sustantivos, ya sea otros componentes, sistemas o usuarios).

Relaciones
Las relaciones entre un actor y un caso de uso, se dibujan con una línea simple. Para relaciones entre casos de uso, se utilizan flechas etiquetadas “incluir” o “extender.” Una relación “incluir” indica que un caso de uso es necesitado por otro para poder cumplir una tarea. Una relación “extender” indica opciones alternativas para un cierto caso de uso. ( Las palabras incluir y extender, son ampliamente utilizadas en el paradigma orientado a objetos! ).
Relaciones de los casos de uso
Las relaciones activas se conocen como relaciones de comportamiento y se utilizan principalmente en los diagramas de casos de uso. Hay cuatro tipos básicos de relaciones de comportamiento: comunica, incluye, extiende y generaliza.

Conclusiones
Por ahora, no me adentraré en detalles técnicos en esta entrada de blog. Mi objetivo principal es que al leer este pequeño escrito, tengas una idea clara de en que situaciones se aplica un caso de uso y lo sepas diseñar. No es mi intención que te vuelvas un maestro en diagramas de casos de uso en UML, o forzarte a realizarlos de una u otra manera. Lo importante aqui, es que nos demos cuenta que, en las actividades cotidianas que solemos planear y diseñar, aplicamos de forma implícita buenas prácticas para diseño de software.

Mi objetivo principal, es que te vuelvas observador, que identifiques en las situaciones de la vida cotidiana patrones de modelado y de diseño. Que tu mente se acostumbre a abstraer, a ver en tus problemas y proyectos potencial para aplicar estos conceptos de modelado.

Los lenguajes, terminologías, aspectos técnicos, buenas practicas y estándares generados por UML, o cualquier otra organización, nos ayudan aplicar de forma ordenada estas ideas de diseño, que por mucho tiempo, han sido intuitivas, pero ocultas para nuestro entendimiento.

Si quieres seguir aprendiendo, no te limites y adéntrate en la red. Algunos consejos útiles para hacer casos de uso están por aquí.

Si eres más de comprender con ejemplos, manzanitas y peritas, te recomiendo esta entrada.

Nota random: los artistas del modernismo nos mostraron el objeto cotidiano, abstrajeron sus percepciones y nos llevaron a la unidad mínima de expresión. Los artistas modernos comprendieron el paradigma orientado a objetos antes de que incluso existiera.

Unified Software Development Process: El secreto de la magia.

Proceso Unificado de Desarrollo de Software. Cuando leí el título del tema de esta semana, quedé bastante confundido. Jamás había oído al respecto. Comencé la búsqueda en la web y poco hallé. Lo más sustancial en esa primera búsqueda fue un artículo más o menos decente en Wikipedia.
Creo que mi asombro es justificable, a fin de cuentas, tenía la impresión de que cada producto de software puede seguir un ciclo de vida distinto ( hice una curiosa analogía entre los ciclos de vida con las distintas formas de crear arte, por si quieres saber al respecto, click AQUÍ).
Entonces, el hablar de un proceso unificado para hacer software sonaba . . . ilógico. Sin embargo, pasaban los días ( mientras procrastinaba casi toda mi tarea) y me di cuenta de algo. A pesar de que todos los ciclos de vida son distintos, podemos decir que la estructura básica de todos ellos tiene cierta similitud. Nacer, crecer, madurar.

Dejé el tema a un lado por unos días. Algo se me ocurriría. En este fin de semana, curioso sucedió mientras andaba por la ciudad. Me di cuenta que, en toda construcción, por grande o chica que fuera, sin importar el tipo de obra, cuanta gente trabaja en ella, como se fue desarrollando el proyecto ( por partes, como algunas casas que van construyendo cuarto por cuarto, o como los grandes edificios que se construyen de forma simultanea varias áreas) en todas las edificaciones, para su construcción necesitan ciertos lineamientos lógicos para realizaras.
Todas ellas son creadas por una necesidad latente, para algún cliente ( del cual depende el presupuesto, casi siempre limitado), utilizan planos que todos los ingenieros civiles puedan entender, fijan presupuestos, costos y tiempos estimados, hay un estudio del diseño de la obra, etc.

Toda construcción, por grande o pequeña que sea sigue ciertos lineamientos para su construcción.

Voilá! Encontramos un patrón. Y como se darán cuenta, me encantan los patrones. Todo proyecto, es realizado para usuarios, con ciertos clientes y con un equipo de trabajadores. Y debido a que, esta actividad implica (tristemente en) lidiar con personas, se deben fijar ciertos lineamientos para que el proyecto sea realizado de la forma más eficiente posible.
En ese momento lo entendí.
El proceso unificado de software es ese conjunto de protocolos, reglas y lineamientos que nos ayudarán a crear un producto de software a través de un proyecto organizado, planeado y documentado.
Este marco de lineamientos, al ser bastante generalizado, se debe amoldar a cada proyecto (de software).

Aquí debemos detenernos un momento. La mayoría de la gente cree que el crear software es una actividad individual. Las películas nos han vendido la idea de ese hacker solitario, que hace montones de código y entra a las bases de datos del pentágono.

NO. NO SOMOS ASÍ *todo el tiempo*, somos seres sociales ( a veces).

Este panorama, en su mayoría de veces es falso. La realidad es que, en todo proyecto decente existe un equipo de trabajo, que posee distintos desarrolladores, con distintos perfiles y expertises.
El construir software se realiza en equipo, es una actividad social.
Aquí es donde entra la magia. El proceso unificado de desarrollo de software es el ingrediente secreto para crear de la nada proyectos gigantescos.
A partir de ahora, daré una breve introducción al Proceso Unificado, utilizando como analogía la construcción de una casa.

Analogías locas a su servicio

Imagina que te encargan realizar una casa. Es más, te encargan realizar un pequeño edificio. Luego del periodo de pánico, lagrimas y desesperación por no saber que hacer, aceptas el reto.
Muy similar sucede con cualquier proyecto de software (¿o soy el único que llora cuando le dejan un nuevo proyecto?).

Etapa 1: Comenzando.
Lo primero que nos debería venir a la mente, es si el proyecto es viable o no. ¿Podrías imaginar una obra a medio terminar, porque a mitad del camino se dieron cuenta que no era posible realizar la obra? Tristemente pasa muy a menudo con las obras públicas en mi país.
Todo proyecto necesita evaluar su viabilidad, presupuestos, costos estimados, tiempos estimados, riesgos y el alcance del proyecto. Hasta aquí no hay diferencia entre un proyecto de construcción y un proyecto de software.
En el proceso unificado, se le conoce a esta etapa como Inception ( como la película). Esta etapa debería ser muy corta pero muy importante, para este punto deberíamos tener consolidado un modelo de negocio.

Antes de construir (software), evalúa si es viable tu proyecto!

Etapa 2: Elaboración.
En este punto, sabemos que es viable nuestro proyecto. Podremos realizar nuestro edificio, el suelo es bueno, el tiempo y los costos de producción son viables.
Ahora debemos diseñar nuestra construcción. Para hacerlo, debemos estar conscientes de la función del edificio y quien lo usará.
En software, tenemos un caso similar. El producto se construye a partir de las necesidades de los usuarios, como van a usar el proyecto. Se realiza investigación profunda al respecto, se realizan entrevistas a los futuros usuarios y a partir de sus necesidades se construyen los casos de usuario: diagramas que representan como interactuarán los usuarios con la aplicación.
Insistiré en este punto. Un proyecto de software se realiza para solucionar un problema, es por eso tan importante que, el diseño del producto se realice en función de las necesidades de los usuarios. ¡Queremos que nuestro software sea usado!
Encontré un ( libro? folleto?) muy interesante que me ayudó a aterrizar las ideas que hasta ahora plasmo. Encuéntralo AQUI.

Los casos de usuario sirven de planos y brújula para comenzar a diseñar nuestro producto.

Etapa 3: Construcción
¡A codear se ha dicho! Ya que el proyecto ha sido planeado y diseñado, es posible comenzar la implementación. En el proceso unificado de software se realizan pequeñas iteraciones. Luego de cada iteración se entrega un producto ejecutable. Es como construir una casa por habitaciones, luego de cada etapa se entrega una habitación para ser utilizada ( puede aún que no esté terminada, pero ya es habitable).
Luego de cada iteración, es necesario realizar el testeo del producto. Esto sirve para encontrar bugs y así poder hacer correcciones o mejoras.
Conforme van completándose las iteraciones, se observa que un proyecto muy grande se va separando en pedazos pequeñitos, realizables.
( Como observarán, mis post buscan dar a entender conceptos complicados de forma informal y sencilla. Si quieres adentrarte más a fondo, te recomiendo leer este blog.

Etapa 4: Fase de transición.
En esta etapa se entrega el producto al cliente, se realiza seguimiento del uso del producto y se da mantenimiento a este. Me recuerda a cuando, en un fraccionamiento terminado, hay siempre un vendedor, un par de jardineros que mantienen la vista del coto y a veces hasta un par de albañiles que siguen haciendo pequeñas mejoras.
En el caso del software, también se incluyen la capacitación del usuario final.

Conclusiones
Como se puede observar, mis queridos amiguitos, el proceso unificado de software es el marco de reglas, lineamientos y documentación que se recomienda para la realización de software. Distintas empresas, en el afán de generar un proceso unificado robusto y bien documentado, han desarrollado su propio proceso unificado de desarrollo de software.
El más conocido, es el desarrollado por la empresa Rational ( adquirida por IBM). Se le conoce como el Rational Unified Process (RUP). Es el proceso unificado más documentado y tiene como arma secreta, el uso de los diagramas del Unified Modeling Language (UML) para la aplicación de la documentación. Es muy recomendado el uso del RUP para proyectos grandes y robustos.

Por otro lado, no es el único existente. Algunos procesos unificados más conocidos son:
Agile Unified Process (AUP).
Basic Unified Process (BUP).
Enterprise Unified Process (EUP).
Essential Unified Process (EssUP).
Open Unified Process (OpenUP).
Pero en general, las variaciones son mínimas de proceso a proceso. Lo importante aqui, radica en planear y diseñar tu código, en función de las necesidades de los clientes.

El arte de los ciclos de vida, los ciclos de la vida en el arte.

Escribir es un proceso lineal. Todas las frases salen de tu mente como un flujo sin parar, las ideas son perfectamente orquestadas y alineadas con las anteriores.

O al menos eso cree la mayoría de la gente.

Pero la realidad es que no es así. El fruto de la escritura viene de pequeñas notas mentales, conceptos importantes que atacar, errores en la escritura, correcciones, ideas infértiles que suelen borrarse. En el proceso de escribir, suele ser más importante el ejercicio de borrar, tachar, cortar.

Todo producto final ( y no me refiero solamente a la escritura o al arte, sino a todo objeto que se genere a partir de la imaginación del hombre) conlleva intrínsecamente un proceso creativo. Este proceso creativo lo llamaremos ciclo de vida.

Continuando con la analogía artística, podemos observar que según el producto, es el ciclo de vida que la obra lleva tatuada en su creación. La escultura, debido al proceso irreversible de la eliminación del material sobrante de la piedra, requiere por fuerza que sea un proceso lineal. Este ciclo de vida se le conoce como desarrollo en cascada. El escultor desde el principio tiene la idea general de la figura final y poco a poco va acercándose al producto deseado, sin hacer cambios en el diseño.

¿Cómo puedo hacer una escultura? Simplemente retirando del bloque de mármol todo lo que no es necesario.
Miguel Angel

El nivel de detalle aplicado a la obra depende de la calidad del autor, su tiempo empleado en el producto y la magnitud de la obra.

Por otro lado, si nos orientamos en la pintura, el artista, va aplicando varias capas a la obra. Comienza por generar una imagen mental de la obra final, hace un primer sketch, quizá con lapices y suavemente marcado en el oleo, pasa a los trazos mas gruesos y finalmente ataca los detalles de la obra.
La obra va siendo construida de forma incremental, los primeros trazos podrían por si mismos ser ya una representación de la imagen final o incluso, podrían ser una obra de arte por si mismos.

En software, el ciclo de vida iterativo cumple con estas características. Se especifica un conjunto de requerimientos, se implementan para luego ser validados. Conforme las iteraciones aumentan, el producto posee más y más componentes, satisface más requerimientos y por ende, el producto se vuelve más grande.

El cine, en contraste, al ser un proyecto tan grande ( y costoso ) es segmentado en pequeños subprocesos, conocidos como escenas, las cuales son producidas en función de una lista de documentos ( conocidos como guiones) los cuales, se hallan muy bien descritos, al grado que cubren exactamente las necesidades de dicho subproceso.

En software, todo proyecto posee documentación, es decir, un conjunto de documentos y comentarios que justifican, acorde a los requerimientos del cliente), cada componente del código.

Todo proyecto necesita una buena descripción, para futuras referencias. En software tenemos la documentación, en el cine tenemos el guion.

Volviendo al cine, la forma de creación de dichas escenas se vuelve un proceso repetitivo, de constante mejora, hasta que, cada escena es aprobada para el proyecto.
Las escenas entre sí, aún conlleven una relación cronológica, muchas veces son independientes entre sí, o no son del todo indispensables.

En el desarrollo de software, existen ciclos de vida como el ciclo espiral, las técnicas AGILE o el desarrollo de software por componentes, que son útiles para proyectos más grandes, separables en componentes independientes y que cuentan con una mayor complejidad.

Debemos tomar en cuenta, que la obra de arte en si misma, es infértil en cuanto al impacto ante el consumidor final, si no posee un canal de distribución y un modelo de negocio que haga viable la producción de la obra. En el software es sumamente necesario que el ciclo de vida considere la llegada del producto al usuario final.
El ciclo de vida no acaba aquí. Constantemente se realizan restauraciones de obras, algunas otras son reconstruidas, se publican copias o impresiones, se hacen remakes de películas o finalmente las obras llegan a destruirse. En el software, se realiza mantenimiento, actualizaciones o nuevas versiones del producto.

Podríamos ahondar en la analogía, pero detengámonos un momento. Observe que si bien, al final tenemos como resultado una obra de arte, el proceso para idearla, producirla, distribuirla y mantenerla es distinto en cada caso.

Así también con el software.

Software Development Life Cicle – El ciclo de vida del desarrollo de software

Existen una infinidad de ciclos de vida diseñados específicamente para crear productos de software. Ningún ciclo de vida es mejor que el otro, cada uno se ajusta mejor a ciertos proyectos.

La gran diferencia en nuestra analogía artística, el objetivo de la creación de software, es generar un producto que solucione la problemática de nuestro cliente.

Phase 1: Requirement collection and analysis
Phase 2: Feasibility study:
Phase 3: Design:
Phase 4: Coding:
Phase 5: Testing:
Phase 6: Installation/Deployment:
Phase 7: Maintenance:

A pesar de que existen una infinidad de ciclos de vida distintos, todos siguen más o menos este esquema general. Es responsabilidad del ingeniero en software seleccionar y apegarse al ciclo de vida que más se le ajuste a un proyecto.

El objetivo de este pequeño post es explicar con peritas y manzanitas conceptos de software, pero si quieres explicaciones para niños grandes, te recomiendo este post: https://raygun.com/blog/software-development-life-cycle/

Si bueno, ahora que?

La moraleja de esta historia, mi querido lector, se encuentra oculta en las analogías. El desarrollar software puede llegar a ser un proceso intuitivo por naturaleza, en el cual, los fundamentos para generar software de calidad, los hallamos en las actividades cotidianas.

Si gustas aprender más sobre los ciclos de vida del software, te invito no solamente a leer las típicas paginas que te hallas en internet ( Wikipedia cof cof), sino que, día a día, busca en los objetos comunes su ciclo de vida. Busca su forma de fabricación y trata de conectarlo con los distintos modelos de ciclos de vida de software.

La mejor manera de aprender algo nuevo, es conectarlo con lo que ya conoces.

Back to school: First week, lost in Silicon Valley

Aug 16: It’s 5 am. «I supposed to be in my network class» I say, even the different time zome and the fact I’m a little bit drunk, I clearly remember I’m loosing a class. Today is my last day working at Facebook and maybe is the first day I would arrive late at work. Apparently, ( after looking for my position in google maps) I’m in an appartment in San Mateo. I just followed my friends to their place. Movies, friends and wine, it was a great night. But now, I have to go to work, and I can’t remember where should I take the shuttle. My friends are still sleeping, apparently they are bounded , in some strange way (are they a couple? Don’t know, don’t care) . Suddenly, all my thinkings just dissapear, I realize my time here is gone. Tomorrow I’ll be back in Guadalajara, and this internship will be just a dream.