Reconverción a Ingenieros de software
https://t.co/Vj8AcL4GCi
#EmpleosTI
— EmpleosTI (@EmpleosTI) enero 2, 2016
Mostrando entradas con la etiqueta Software. Mostrar todas las entradas
Mostrando entradas con la etiqueta Software. Mostrar todas las entradas
lunes, 4 de enero de 2016
Ojo, Chequen el temario...
Ojo, chequen el temario, no se vayan a quedar sin chamba algunos!!!
miércoles, 24 de junio de 2015
viernes, 6 de marzo de 2015
GProSW Tema 2 Proyectos de Calidad comienzan con Requisitos de Calidad
Les comparto este video tomado de SG Campus, esta muy interesante y justifica el valor que adquiere realizar un buen levantamiento de requerimientos
Saludos
Saludos
jueves, 24 de junio de 2010
viernes, 30 de abril de 2010
martes, 10 de febrero de 2009
Blog interesante sobre Marcas de Agua
Felicito a mi amigo y M.C. Pedro Aaron Hernandez Avalos por su nuevo blog
visitenlo , muy interesante y con informacion confiable y nueva
visitenlo , muy interesante y con informacion confiable y nueva
martes, 6 de enero de 2009
El Pastor y el Jefe de Proyectos {Fabula...?}
Un buen ingeniero Jose Israel Ramirez Martinez me recomendo la sig. fabula que comparto con ustedes...
La fábula del pastor y el jefe de proyectos
{http://geeks.ms/blogs/rcorral/archive/2008/11/24/la-f-225-bula-del-pastor-y-el-jefe-de-proyectos.aspx}
{Feb. 06 2009}
Paseaba un día un jefe de proyectos por el campo. Tras años de rayos catódicos era su primer paseo por el páramo castellano en mucho tiempo. Lo necesitaba. La ocasión merecía los pantalones y las botas que estrenaba, recién compradas en la tienda de Timberland del aeropuerto. Iba pensando en lo bucólico del paisaje y la paz que se respiraba y lo lejos que estaba ahora de las reuniones 'tressesenta' , cuando vio, en la lejanía, para un informático 350 metros son la lejanía, un pastor de ovejas con rebaño de discreto tamaño. No más de cincuenta recursos eran los que el pastor gestionaba.
"...el trabajo del gestor de proyectos no es hacer que la gente trabaje, sino construir el entorno en el que trabajar sea posible."
La fábula del pastor y el jefe de proyectos
{http://geeks.ms/blogs/rcorral/archive/2008/11/24/la-f-225-bula-del-pastor-y-el-jefe-de-proyectos.aspx}
{Feb. 06 2009}
Paseaba un día un jefe de proyectos por el campo. Tras años de rayos catódicos era su primer paseo por el páramo castellano en mucho tiempo. Lo necesitaba. La ocasión merecía los pantalones y las botas que estrenaba, recién compradas en la tienda de Timberland del aeropuerto. Iba pensando en lo bucólico del paisaje y la paz que se respiraba y lo lejos que estaba ahora de las reuniones 'tressesenta' , cuando vio, en la lejanía, para un informático 350 metros son la lejanía, un pastor de ovejas con rebaño de discreto tamaño. No más de cincuenta recursos eran los que el pastor gestionaba.
En ese preciso instante el modesto pastor vio al 'pimpollo' y pensó… vaya, otro que estrena botas, mañana con ampollas… mientras arrancaba un lasca de queso con su navaja. En esto el 'pinpollo' ya estaba a su lado. El pastor levanto la cabeza, miro a nuestro jefe de proyecto y le tendió un trozo de queso. Ya se sabe, que en la castilla profunda, la hospitalidad se muestra más de gesto que de palabra. {continua aqui}
"...el trabajo del gestor de proyectos no es hacer que la gente trabaje, sino construir el entorno en el que trabajar sea posible."
martes, 7 de octubre de 2008
viernes, 3 de octubre de 2008
"Beta" para aplicaciones sobre internet
Google: "Beta" no es sinónimo de inconcluso
{http://www.diarioti.com/gate/n.php?id=19568}
Google explica la razón de que la mitad de sus servicios continúan en versión beta.
Diario Ti: Actualmente, Google tiene 49 servicios en línea, de los cuales la mitad está en etapa beta. Entre los productos que continúan en versión beta después de varios años figuran Gmail y Google Docs.
¿Significa lo anterior que la mitad de los servicios de Google son programas inconclusos? En otras palabras, ¿Gmail , que ha estado disponible desde 2004, aún no ha sido terminado?
El sitio NetworkWorld ha preguntado a Google qué quiere decir exactamente con la denominación “beta". Anteriormente, esta palabra implicaba un producto que aún no estaba terminado, o que estaba en su última etapa de pruebas antes del lanzamiento del producto final.
En un mensaje de correo electrónico, Google explica su interpretación de la palabra.
“Consideramos que la palabra beta tiene un significado distinto al tratarse de aplicaciones en Internet, donde la gente espera actualizaciones y mejoras constantes del producto. En Internet no es necesario que esperes a la próxima versión, que esta llegue a la tienda, o esperar una actualización. Las actualizaciones son incorporadas al servicio en la medida en que son concluidas", explica un portavoz de Google.
“En lugar de cooperar con paquetes estancados de software como en la antigüedad, ahora avanzamos hacia un mundo con actualizaciones regulares, y un mejoramiento constante de las aplicaciones en Internet, concluye el portavoz de Google.
Ahora que la explicación ha sido lanzada por Google, quizá se observen diversos sitios en Internet que incorporarán una pequeña etiqueta “Beta" junto a su logotipo, sólo para imitar a Google.
Claro está, al incorporar la palabra Beta junto al nombre de un producto se asegura también una explicación extra en el caso que las cosas resulten mal.
comentario: independientemente de que las apps en internet sean 100% funcionales o no, lo mas importante es el concepto de actualizacion regular a partir de los comportamientos de los usuarios, una nueva forma de captar requerimientos...?
martes, 9 de septiembre de 2008
Tips para la recoleccion de Requisitos
Excelentes tips para tomar en cuenta cuando levantamos requerimientos...
Que tal la leyenda urbana del 2 tip ehh!!!, excelente
gracias a http://liderdeproyecto.com/
Que tal la leyenda urbana del 2 tip ehh!!!, excelente
gracias a http://liderdeproyecto.com/
Lo Dificil que puede ser recoger los requerimientos de un cliente
Aqui les dejo un video corto pero muy representativo de lo complicado que puede ser el proceso de recoger los requerimientos de un cliente, la escena exagera por supuesto el asunto, pero si analizamos bien, no esta muy lejos de la realidad... :-)
viernes, 6 de junio de 2008
El Cliente Ideal para el Desarrollo de Software
[I.T.Minatitlán]
[Curso Desarrollo de Proyectos de Software]
Compañeros del curso de Desarrollo de Proyectos de Software (en general), les invito a que juntos tratemos de definir el "perfil ideal" (caracteristicas) del Cliente para un proceso de Desarrollo de Software, esto tomando como referencia la experiencia vivida durante el curso.
No olviden firmar con su nombre completo al final del comentario por favor
[Curso Desarrollo de Proyectos de Software]
Compañeros del curso de Desarrollo de Proyectos de Software (en general), les invito a que juntos tratemos de definir el "perfil ideal" (caracteristicas) del Cliente para un proceso de Desarrollo de Software, esto tomando como referencia la experiencia vivida durante el curso.
No olviden firmar con su nombre completo al final del comentario por favor
Para los Lideres de Desarrollo de Proyectos de SW
[I.T. de Minatitlán]
[Curso Desarrollo de Proyectos de Software]
Estimados Lideres de los proyectos de Desarrollo de Software (disculpen, solo uno comentario por equipo), con el unico objetivo de crear un repositorio de experiencias sobre el Desarrollo de Proyectos de Software del Curso Feb-Jun 2008, les pido por favor compartan con la comunidad las principales experiencias adquiridas en el rol de Lider de Proyectos, les sugiero la sig. lista de temas para establecer un orden al proceso:
[Curso Desarrollo de Proyectos de Software]
Estimados Lideres de los proyectos de Desarrollo de Software (disculpen, solo uno comentario por equipo), con el unico objetivo de crear un repositorio de experiencias sobre el Desarrollo de Proyectos de Software del Curso Feb-Jun 2008, les pido por favor compartan con la comunidad las principales experiencias adquiridas en el rol de Lider de Proyectos, les sugiero la sig. lista de temas para establecer un orden al proceso:
- Manejo del Equipo de Desarrollo (Las relaciones humanas y los perfiles-roles de los integrantes del equipo de desarrollo)
- Manejo de los Riesgos (Como se trabajo con los riesgos analizados)
- Manejo de los Imprevistos (Como se trabajo con los sucesos imprevistos)
- Que te deja la experiencia de liderear un proyecto de desarrollo de software
jueves, 22 de mayo de 2008
Las Pruebas de Software
10 Mejores Prácticas para la Generación de Software
Elsa Ramírez, Directora de Tecnología y Calidad para Praxis.
{ http://www.sg.com.mx/content/view/684/1/ }
...La disciplina de pruebas ha evolucionado en una práctica de especialización que puede ser ofrecida como un servicio hacia clientes internos y externos, garantizado que tanto la metodología como las herramientas automatizadas son aprovechadas eficientemente para alinear el desarrollo a las expectativas del cliente.
Se debe reconocer que las pruebas son una especie de administradores de riesgos; al igual que en los problemas de combinatorias complejas, se puede definir cuál debe considerarse buen resultado, aunque no necesariamente sea el mejor resultado; con esto quiero decir que las pruebas sólo deben obtener un producto práctico con la calidad y funcionalidad requeridas.
A continuación se sugieren 10 mejores prácticas para la generación de software:
comentario: como se puede apreciar, las actividades de pruebas han dejado de ser una etapa secuencial, es decir, se entraba a ella cuando habia concluido la etapa anterior y posterior a ella continuaba otra etapa; la validacion de todo el proceso, implica necesariamente el testeo, que desde mi punto de vista se podria llamar tambien monitoreo y control, este proceso inicia y termina a la par de todo el desarrollo y si me permiten la afirmacion, es una de las caracteristicas principales de un liderazgo efectivo en la administracion de los proyectos de desarrollo de software...
Elsa Ramírez, Directora de Tecnología y Calidad para Praxis.
{ http://www.sg.com.mx/content/view/684/1/ }
...La disciplina de pruebas ha evolucionado en una práctica de especialización que puede ser ofrecida como un servicio hacia clientes internos y externos, garantizado que tanto la metodología como las herramientas automatizadas son aprovechadas eficientemente para alinear el desarrollo a las expectativas del cliente.
Se debe reconocer que las pruebas son una especie de administradores de riesgos; al igual que en los problemas de combinatorias complejas, se puede definir cuál debe considerarse buen resultado, aunque no necesariamente sea el mejor resultado; con esto quiero decir que las pruebas sólo deben obtener un producto práctico con la calidad y funcionalidad requeridas.
A continuación se sugieren 10 mejores prácticas para la generación de software:
- Hacer una evaluación del trabajo de cada integrante del equipo. Conscienciar al equipo de la importancia que tienen las pruebas y el valor que tienen para cada miembro del equipo y así generar cooperación y coordinación entre los miembros del mismo.
- Establecer un plan maestro integrado. Establecer claramente las funciones y responsabilidades de los equipos de desarrollo y pruebas
- Considerar las pruebas preventivas como parte de las especificaciones de trabajo. Diseñar previamente los escenarios de prueba, dentro del desarrollo de software, y realizar revisiones para asegurarse de que lo que se está construyendo cumple con los requerimientos solicitados.
- Usar las pruebas como puntos de control y progreso. Realizar pruebas y revisiones formales para verificar y demostrar que todos los productos claves del proyecto han sido realmente terminados.
- Inventario de los objetivos de pruebas y diseño para factibilidad. Revisar la factibilidad en la realización de las pruebas.
- Probar pronto y frecuentemente. Hay que probar lo antes y más frecuentemente posible; esto permitirá detectar los problemas tan pronto surjan, de esta manera el desarrollador será más eficiente en las correcciones.
- Diseñar y desarrollar el testware como el software. Esto implica planear, analizar, diseñar, supervisar, controlar los cambios, administración; en suma, desarrollar el testware con la misma disciplina con que se desarrolla el software.
- Proporcionar una herramienta integrada de pruebas, evaluación y de soporte de infraestructura. Proporcionar herramientas que incluyan: Base de datos o repositorio, Administración de pruebas, que permita documentar, ejecutar y clasificar pruebas, Soporte automático, Simuladores, Analizadores de software, Manejadores de pruebas, Herramientas de captura y repetición (playback) y utilerías.
- Medir el costo, el alcance, los resultados y la efectividad de las pruebas y evaluación. Coleccionar información que permita conocer el costo, los resultados y los beneficios así como el alcance.
- Entrenar y administrar al equipo. Proporcionar el liderazgo y administración al equipo con el fin de que sepa lo que se espera de él para que se tomen las pruebas seriamente. Definir los criterios de "mejores prácticas".
comentario: como se puede apreciar, las actividades de pruebas han dejado de ser una etapa secuencial, es decir, se entraba a ella cuando habia concluido la etapa anterior y posterior a ella continuaba otra etapa; la validacion de todo el proceso, implica necesariamente el testeo, que desde mi punto de vista se podria llamar tambien monitoreo y control, este proceso inicia y termina a la par de todo el desarrollo y si me permiten la afirmacion, es una de las caracteristicas principales de un liderazgo efectivo en la administracion de los proyectos de desarrollo de software...
lunes, 19 de mayo de 2008
Nueva Empresa de Servicios de TI
Amigos todos, me complace anunciar el nacimiento de una nueva empresa de aplicaciones de TI, caekattzcorp estara a sus ordenes a partir otoño de 2008, visiten nuestro portal...
viernes, 7 de marzo de 2008
Administrando Desarrolladores de SW
Diez tips para trabajar con su desarrollador de software
Por: Mariano Garza-Cantú
http://www.politicadigital.com.mx/nota.php?id_rubrique=11&id_article=401&color=39A6D9
07.03.2008
El mundo de los administradores es muy diferente al de los desarrolladores de software y con frecuencia tienen problemas para comunicarse entre sí.
¿Por qué ocurre esto? Buena parte se debe a que el desarrollo de aplicaciones es una habilidad difícil de adquirir y dominar. A un desarrollador le preocupan más el aspecto técnico que el económico -negativo o positivo- de sus acciones. Su visión muchas veces es limitada y no tiene “sentido del impacto político que puede causar”, como argumentan algunos administradores de dependencias gubernamentales.
El autor del libro sobre programación The Ruby Way, Hal Fulton, con una amplia experiencia como desarrollador en la industria de cómputo, nos comparte sus consejos para motivar a los desarrolladores de código, comunicarse mejor con ellos, y entender a esas “extrañas personas” que diseñan las aplicaciones en que tanto confiamos.
1. Recuerde al desarrollador que “la excelencia técnica no es garantía de éxito”.
2. Señale el impacto económico siempre que pueda y sea lo más específico posible.
3. Explore las razones que tiene el desarrollador para estar en desacuerdo, porque pueden ser válidas.
4. Explique al desarrollador las limitaciones y las suposiciones sobre las cuáles está usted trabajando, así como la razón de sus decisiones.
5. Para que la comunicación sea posible es necesario que ambas partes hablen el mismo lenguaje.
6. Tampoco hace daño que el administrador estudie algo en un nivel más técnico.
7. No sujete demasiado a los desarrolladores a la burocracia que suele existir dentro de las organizaciones.
8. Aleje a sus desarrolladores de la burocracia tanto como pueda.
9. Ayude a hacer más eficientes los procesos, e incluso reducirlos, si esto ayuda a la productividad.
10. Léa la tira cómica Dilbert.
comentario: una lista recomendable, lo caotico del proceso de desarrollar software es precisamente su gestion lean el articulo completo, el enlace esta en la parte superior...
Por: Mariano Garza-Cantú
http://www.politicadigital.com.mx/nota.php?id_rubrique=11&id_article=401&color=39A6D9
07.03.2008
El mundo de los administradores es muy diferente al de los desarrolladores de software y con frecuencia tienen problemas para comunicarse entre sí.
¿Por qué ocurre esto? Buena parte se debe a que el desarrollo de aplicaciones es una habilidad difícil de adquirir y dominar. A un desarrollador le preocupan más el aspecto técnico que el económico -negativo o positivo- de sus acciones. Su visión muchas veces es limitada y no tiene “sentido del impacto político que puede causar”, como argumentan algunos administradores de dependencias gubernamentales.
El autor del libro sobre programación The Ruby Way, Hal Fulton, con una amplia experiencia como desarrollador en la industria de cómputo, nos comparte sus consejos para motivar a los desarrolladores de código, comunicarse mejor con ellos, y entender a esas “extrañas personas” que diseñan las aplicaciones en que tanto confiamos.
1. Recuerde al desarrollador que “la excelencia técnica no es garantía de éxito”.
2. Señale el impacto económico siempre que pueda y sea lo más específico posible.
3. Explore las razones que tiene el desarrollador para estar en desacuerdo, porque pueden ser válidas.
4. Explique al desarrollador las limitaciones y las suposiciones sobre las cuáles está usted trabajando, así como la razón de sus decisiones.
5. Para que la comunicación sea posible es necesario que ambas partes hablen el mismo lenguaje.
6. Tampoco hace daño que el administrador estudie algo en un nivel más técnico.
7. No sujete demasiado a los desarrolladores a la burocracia que suele existir dentro de las organizaciones.
8. Aleje a sus desarrolladores de la burocracia tanto como pueda.
9. Ayude a hacer más eficientes los procesos, e incluso reducirlos, si esto ayuda a la productividad.
10. Léa la tira cómica Dilbert.
comentario: una lista recomendable, lo caotico del proceso de desarrollar software es precisamente su gestion lean el articulo completo, el enlace esta en la parte superior...
viernes, 11 de enero de 2008
El Valor del Software para el Cliente
Navegando por la red en busca de documentos sobre gestion agil de proyectos me encontre con este:
lo considero excelente y fundamental para los interesados en el desarrollo de software
Comentario: En muchas ocasiones se hace mas enfasis en el "como" dejando de lado el impacto del "que"; es para los ingenieros de sw, imprescindible el uso de estrategias, metodologias, frameworks (denle el nombre que deseen), pero no debemos perdernos en eso, lo mas importante de nuestro quehacer, de nuestro negocio, el ofrecer a nuestro cliente una "SOLUCION", piensen en ello...
Suscribirse a:
Entradas (Atom)