blog de Israel-69

¡Arquitectura, cada cosa en su lugar!!

El término de arquitectura abarca temas de Solución, Software, Hardware y Datos, por lo que solo me enfocare a describir a nivel general el área de arquitectura de Software. (Aquí solamente la llamaré Arquitectura para abreviar)

Dentro de las primeras etapas (según UP – “elaboration”) la labor del equipo de proyecto se enfoca a determinar la estructura base de desarrollo, dicha estructura deberá de alinearse a las características de calidad esperada por el usuario (stakeholders)

Durante la recopilación de requerimientos a través de crear un equipo multidisciplinario para que se vayan clasificando y revisando su viabilidad y tipos de los requerimientos, los arquitectos toman vital relevancia para identificar los QoS (Quality of Service) que conformarán al sistema, así como orientar al usuario sobre su pedido y sus prioridades.

Requerimientos Arquitectónicos

¿Cuál es el Plan?

Como normalmente las cosas nunca salen como lo planeamos; sin embargo el plan nos da una idea de las tareas que tenemos que realizar y los tiempos que deberíamos de estar invirtiendo, con el plan podemos ir viendo cual es la desviación y nos puede ayudar a tener mejor visibilidad de los tiempos para aplicar alguna corrección, ya sea a nivel de recursos, tareas o tiempos.

¿Cuántos de nosotros hacemos cosa sin planear y cuantas veces salen bien?

Considerando desarrollos donde el nivel de calidad y efectividad es punto esencial, debemos de tener un plan que permita tener claro el esfuerzo y objetivo.

El plan para que tenga mayor efectividad y certidumbre debería de ser considerado por todas las partes (Cliente, stakeholders y equipo de trabajo) en función de los requerimientos y entregables establecidos con el cliente.

¿Que son los Requerimientos?

La definición formal nos dice:

  1. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo
  2. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal
  3. Una representación documentada de una condición o capacidad como en (1) o (2)

Los encontramos en formas variadas como lista de pedido, casos de uso, historias, escenarios de negocio, reglas de negocio, condiciones de sistema entre otras.

Pero lo que es muy cierto es que los requerimientos deberán de ser claros, descritos o bosquejados de manera atómica además de saber cómo serán probados, por dichas razones hay que documentarlos y colocarles un identificador único (el documentado del requerimiento puede ser: escritos, dibujados o modelados) tal que podamos transmitirlos, implementarlos, verificarlos y obtener la aprobaciones correspondiente.

División básica de los requerimientos

¿Cómo inicia un desarrollo? (Abstracción y Encapsulación)

¿Cómo inicia un desarrollo?

Antes de preguntarnos como, deberemos de preguntarnos el porqué?; cualquier cosa que se codifique tiene que tener un fin y un objetivo, sino de otra manera nadie lo va utilizar

Normalmente el motivo se asocia a una o varias necesidades, de ahí empezaremos a desprender todas las actividades que realizaremos para poder cubrir de manera satisfactoria dichas necesidades.

Si al comenzar un desarrollo no has ubicado los motivos y las necesidades que pretendes cubrir es mejor indagar un poco, lo suficiente para establecer un objetivo claro.

De las primeras preguntas que se tienen que hacer son:

  1. ¿Quién lo va a utilizar?
  2. ¿Qué es lo que actualmente le hace falta?
  3. ¿Dónde se va utilizar?
  4. ¿Qué es lo que más utiliza o utilizará?
  5. ¿Quién es el que tiene el poder de decisión? normalmente será quien paga!

Plantearnos estas pregunta nos lleva a determinar una visión a alto nivel de lo que probablemente será el sistema.

Cuanto mas rápido empieces a programar más tarde terminaras

Que tal comunidad Javera!!

Estoy incorporándome al grupo y creo que será muy interesante intercambiar conocimiento.

Actualmente mi rol esta en el área de Análisis de Negocio, sin embargo, el mayor de mi tiempo en el desarrollo de sistema lo he pasado programando y diseñando, con Java por supuesto. Gracias a ello me ayudo entender como proceder a la resolución de los problemas así como el identificar los comoponentes de Sotware que se tenia que codificar.

Una de las primeras reglas que conocí y que fue después de un largo camino, fue que entre más rápido comenzamos a programar más tiempo nos lleva en terminar el proyecto, o no?

Cuantos de ustedes han pasado por el interminable camino de los cambios(totalmente descontrolados) o del "ya merito terminamos", "estamos en la recta final". Palabras huecas de nuestro Project Managers (o Líder de proyecto), que no tiene claro el alcance o el objetivo que se persigue

Distribuir contenido