jueves, 23 de julio de 2009

Artículo de MisiónPyme - La retención del mejor talento

El sitio MisiónPyme encuentro publicado este artículo que nos pone a pensar acerca de las condiciones de retención de personal en las empresas. En este artículo nos presentan la realidad que vivimos en el país: en lugar de incentivar y premiar el talento, nos sentimos presionados a sobreesforzarnos porque alguien más podría hacer lo que nosotros hacemos y nuestra individualidad y profesionalismo deja de tener validez.

El artículo lo puenden encontrar en MisiónPyme - La retención del mejor talento

Shared via AddThis

sábado, 13 de septiembre de 2008

Tips para especificar las funcionalidades requeridas por los usuarios

Cuando iniciamos el proceso de identificación de las funcionalidades que los usuarios esperan que les ofrezca un software especifíco, si no se tiene mucha experiencia en esto de especificar funcionalidades, puede ser difícil saber qué preguntar y qué no preguntar.

Normalmente, especificamos las funcionalidades requeridas mediante entrevistas con los usuarios o co los responsables de la ejecución del proyecto que se ha definido para la construcción del software. Así que es bueno saber qué temas empezar a tratar.

Estas son algunas de las preguntas generales que tengo en mente cuando voy a especificar una funcionalidad de un software:
  • ¿En qué punto del proceso de negocio interviene la funcionalidad que estamos especificando?
  • ¿Qué tan importante es la funcionalidad dentro del proceso de negocio?
  • ¿Quiénes son los usuarios y áreas interesados en la funcionalidad?
  • ¿Quiénes tiene la responsabilidad de ejecutar la funcionalidad?
  • ¿Quiénes no deberían tener acceso a la funcionalidad?
  • ¿Con qué periodicidad se ejecuta la funcionalidad?
  • ¿Qué datos son obligatorios en la funcionalidad?
  • ¿Cómo se debe reportar las fallas en la funcionalidad y a quién se le debe reportar?
  • ¿Bajo qué condiciones la funcionalidad no debe estar disponible para su uso?
  • ¿Se requieren controles de auditoría y seguimiento a las operaciones realizadas en la funcionalidad?
  • ¿Qué actividades deben haberse ejecutado antes de usar la funcionalidad?

sábado, 6 de septiembre de 2008

Documentación Gratis de SQL Server 2008

Pues bueno, como consecuencia del acelerado ritmo de evolución de los productos Microsoft, ya tenemos en las manos la nueva versión de SQL Server: SQL Server 2008.

¡Y nosotros los que trabajamos con SQL Server sin terminar de aprender SQL Server 2005!

Para reducir el impacto de ese cambio, aquí les incluyo una URL donde pueden obtener, gratis, algunos documentos de SQL Server 2008:


La documentación está muy orientada a los DBA, pero me pareció bastante útil.
¡Espero que les sirva!

jueves, 28 de agosto de 2008

Yo quiero ser arquitecto de software...

Después de haber pasado unos cuantos años estudiando Ingeniería de Sistemas y luego de estar otros más en el área de desarrollo de software, pues termina uno preguntándose ¿y entonces yo qué soy finalmente?
De repente nos damos cuenta de que en el medio está de moda el tema de especializar los roles en el desarrollo de software.

Antes, todos éramos "toderos": analizábamos, diseñábamos, desarrollábamos, probábamos e instalábamos. Gangazo: todo en uno.
Pero el medio ha cambiado bastante y ahora se busca especializar a la gente, así como es en medicina.

Pues uno de estos roles especializados es el de Arquitecto de Software.
Les dejo una URL donde se encuetra información bastante interesante acerca del rol del Arquitecto de software: http://www.bredemeyer.com.

lunes, 19 de mayo de 2008

Y... ¿cómo me preparo para ser Analista de Negocio?

El conocimiento del negocio del cliente para el cual se desarrollará un sistema informático es un factor esencial para el éxito de la solución dentro de la organización.

Sea porque nuestro cliente es interno o porque es un cliente externo, es fundamental saber a qué se dedica la organizacion y precisar, con mucho detalle, el punto en que la solución informática tendrá apoyará los procesos de negocio del cliente.

Sin este conocimiento del negocio y de los procesos productivos y de apoyo en los que está enmarcado el proyecto de la solución informática, es muy posible que fracasemos en el intento.

En los últimos años se ha venido desarrollando un perfil profesional que apoye y soporte la obtención de este conocimiento. Algunos los llaman Analista de Requisitos, otros, Ingeniero de Requisitos y otros, lo enmarcan todo bajo la concepción de Analista de Negocio.

Con el fin de que todos vayamos aclarando algunas ideas sobre estos roles, los invito a visitar estas URL:

En ambos sitios encontramos información que puede ayudarnos a formarnos como Analistas de Negocio, o como Analistas de Requisitos o com Ingenieros de Requisitos.

viernes, 25 de abril de 2008

Sobre el Analista de Sistemas

Cuando ingresé a la Universidad de Antioquia (Medellín, Colombia) a estudiar Ingeniería de Sistemas, se me quedó grabada una afirmación hecha por la persona que nos daba la inducción al iniciar el primer semestre. En esta afirmación, se definía la orientación profesional de la Ingeniería de Sistemas en la UdeA: la Universidad de Antioquia forma Analistas de Sistemas.

No nos explicaron qué significaba ser Analista de Sistemas y creo que es difícil tener una definición precisa.

Con este blog busco explorar las diferentes facetas (técnicas, profesionales y humanas) que, para mí, hacen parte de ser Analista de Sistemas.

Pero, ¿qué significa entonces ser Analista de Sistemas?

Una definición que me ha parecido que da una idea inicial acertada es la publicada en http://es.wikipedia.org/wiki/Analista_de_sistemas:

"Un analista de sistemas o a veces simplemente analista, en la disciplina de la ingeniería del software, es aquel individuo que ejerce las tareas de análisis de los sistemas informáticos, con el fin de automatizarlos. También es una categoría profesional de rango superior a la de programador y a la de diseñador, generalmente ejercida por titulados superiores en Ingeniería Informática."

Como Analista de Sistemas, yo he realizado en general tareas como:
- Análisis, diseño y construcción de Software
- Mantenimiento de Sistemas
- Documentación de Sistemas
- Mejora de proceso
- Capacitación de usuarios
- Verificación del software
- Planeación de actividades

La frontera entre el Analista de Sistemas y el Programador no está muy claramente definida, pero en mi concepto, el Analista de Sistemas no corresponde a un nivel superior a programador o diseñador. Éstas últimas son líneas profesionales de la Ingeniería de Sistemas que apoyan y complementan la labor del Analista de Sistemas y hacen un aporte igual de valioso que el del Analista de Sistemas.

El Analista de Sistemas tiene, dentro de su rol, la responsabilidad de conocer el proceso y el negocio del Cliente que tiene la necesidad de sistematizar o modernizar una actividad o procedimiento de sus procesos productivos o de apoyo. El Analista de Sistemas se apropia de los conceptos de negocio y puede incluso llegar a plantear mejoras a los procesos del cliente, como resultado del análisis realizado.

La línea de Análisis de Sistemas en Ingeniería de Sistemas, debe estar apoyada en otras líneas de conocimiento.

Así pues, en general el Analista de Sistemas tiene responsabilidad en:
  • El conocimiento del proceso de negocio a sistematizar
  • El planteamiento de la mejor solución funcional para la sistematización a realizar
  • El apoyo al diseño de la solución
  • El apoyo a la construcción de la solución planteada, incluso si esto implica asumir el rol de programador
  • La verificación de la coherencia entre la solución planteada y la implantada
En general, el Analista de Sistemas deberá ser un profesional integral, que se encuentre en capacidad de asumir algunos de los diferentes roles que participan en la sistematización de procesos o actividades.

En el caso de la sistematización con base al desarrollo de software, es importante que el Analista de Sistemas tenga conocimiento sobre:
  • Procesos y metodologías de desarrollo de software
  • Planeación de actividades
  • Técnicas de elicitación y análisis de requisitos
  • Diseño de software
  • Arquitectura de software
  • Lenguajes de programación
  • Métodos de verificación y validación
Hay que ser multi-facético y multi-rol en cuanto a lo técnico.

En cuanto a las habilidades personales y grupales, sería deseable que un Analista de Sistemas presentara características y habilidades como (sólo para mencionar algunas):
  • Orientación al logro
  • Habilidades de expresión oral y escrita
  • Habilidades investigativas y de autoestudio
  • Manejo de relaciones personales con personas de diferentes roles y grados de formación
  • Responsabilidad
  • Liderazgo
  • Compromiso
  • Independencia
  • Creatividad e innovación
Total, que un buen Analista de Sistema debe ser un profesional integral para llevar a cabo su labor con calidad y ser efectivo en su labor.

De ahí en adelante, sólo queda continuar formándose y continuar desarrollando todas estas facetas que implica ser Analista de Sistemas.