Mostrando las entradas con la etiqueta ingenieria de software. Mostrar todas las entradas
Mostrando las entradas con la etiqueta ingenieria de software. Mostrar todas las entradas

domingo, enero 04, 2009

TSP promises

Microsoft india antes y despues de TSP:

Non-TSP TSP
Project Plan Developed by Project Manager Team develops the project plan - high confidence & commitment to meet the plan
Estimates are usually guesstimates Estimates are based on historical data OR work-life balance
Long office hours Predictable office hours (40-50hrs) Better work-life
Problems and issues are found very late in the project Weekly meetings help the team to find probelms very early in cycle
Usually 3-8 bugs in UAT + Production Much better quality (64% projects with zero defects). Defects are found early in the cicle
Fire fighting to meet the deadlines. Schedules slippage and poor quality Objetive project management based on data.

http://www.sei.cmu.edu/tsp/symposium/2006/deliver.pdf

martes, octubre 07, 2008

Estandar ISO/IEC 12207 procesos de ciclo de vida del software

Estos son los procesos descritos en el estándar:


Procesos principales del ciclo de vida
Son los procesos para iniciar o llevar a cabo el desarrollo, operación o mantenimiento del software

Procesos de apoyo del ciclo de vida
Un proceso de apoyo es el que apoya a otro proceso como parte esencial del mismo. Un proceso de apoyo se emplea y ejecuta por otro proceso, según sus necesidades.

Procesos organizativos del ciclo de vida
Se emplean por una organización para establecer e implementar una infraestructura constituida por procesos y personal asociado al ciclo de vida y para mejorar continuamente esta infraestructura. Se usan habitualmente fuera del ámbito de proyectos y contratos, contribuye a la mejora de la organización.

Una definición de cada proceso puede ser vista en el articulo de la wikipedia en español sobre la ISO/IEC 12207 pero si desea mas precisión es mejor mirar el articulo Software Lifecycle Processes de la wikipedia en ingles, por ultimo si el tema verdaderamente llama su atención, se puede descargar la Norma Técnica Peruana NTC ISO/IEC 12207 que es una traducción prácticamente literal de la segunda modificación del estándar.

miércoles, septiembre 17, 2008

Ventas sin fuerza

Esta es una traducción al español de ventas sin fuerza un articulo escrito por Christopher Seiwald para el boletín de perforce software The Head Revision / This is an Spanish translation of Sales Without Force an article originally wrote by Christopher Seiwald for the perforce software newsletter The Head Revision

Ventas sin fuerza
Por que usted no necesita siempre un equipo de ventas para llegar al éxito.
Por: Christopher Seiwald

Una compañía rentable que escoge permanecer privada a veces es llamada una compañía "estilo de vida" - apoyando el confortable estilo de vida de sus dueños. Mientras que para un tienda de comestibles esto es respetado, en el mundo del software hay la hipótesis que el confort le roba a la empresa la fuerza necesaria para ser agresiva y lograr algo grande. Pero hay otro camino donde el producto disfruta de un estilo de vida confortable. Nosotros llamamos a esto una compañía "estilo-producto".

Un talentoso amigo motociclista una vez me contó como consiguió su velocidad: "Trabaja en la forma y la velocidad te seguirá. Trabaja en la velocidad y terminaras en una zanja preguntándote que paso." Una compañía estilo-producto aplica el anterior enfoque, modificandolo para sus negocios: trabaja en el producto y las riquezas te seguirán. La pregunta cambia de " ¿ Que nos dará mas dinero ? " a "¿ Que hará al producto mas útil para mas gente ?"

Ventas de zanja

¿ Donde comienza una empresa estilo-producto ? En particular empieza sin un equipo de ventas. En teoría, un equipo de ventas es una poderosa herramienta de comercialización, amplificando las oportunidades donde cliente y producto se encuentran. Pero en la practica, los equipos de ventas son impulsados por el dinero. Como resultado, su meta principal no es acomodar los productos a los clientes, sino forzarlos en ellos. Esto es rara vez de utilidad para el producto o el cliente. Peor, un equipo de ventas fuerte puede crear problemas en una segunda direccion. Puede obligar a los desarrolladores del producto al exceso de funcionalidades y frustrar el crecimiento de una profunda funcionalidad.

Suprimir al equipo de ventas no elimina el ciclo de ventas, por el contrario lo puede hacer mas fuerte. Como un policía que no lleva un arma, para lograr sus metas una empresa si un equipo de ventas debe confiar en otras habilidades, unas que estén presentes, pero menos valoradas por aquellos que pueden usar la fuerza.

Primero, la sola comercialización debe crear interés, como no hay gente de ventas que necesite cumplir con sus cuotas, asumiremos la holgura. Afortunadamente con un producto solido, una porcion significativa de la comercialización se hará de boca en boca lo cual es efectivo, barato y auto-sostenible.

El paso siguiente es que la consultoria pre-venta ayude a acomodar el producto a los usuarios. Esta parte es la que mas se asemeja a las ventas sin equipo de ventas. Un producto complicado (o un producto simple implementado en un ambiente complicado), necesita experticia de la empresa para demostrar el producto y guiar su evaluación. Esto puede involucrar invertir en una implementacion prueba-de-concepto

Durante el ciclo de ventas, el apoyo preventa debe impresionar al cliente con la promesa de completa satisfacción, y después en la postventa debe entregar lo que prometió. Para todos excepto tal vez los programas mas triviales, el soporte es tan parte del producto como el software mismo. Y una empresa estilo-producto - si es exitosa es por obtener su reputación de su producto - la cual debe coincidir con la calidad del producto y su soporte técnico.

Finalmente, la administracion de ordenes de compras debe consumar el trato. La falta de un equipo de ventas, deja poco espacio para la negociación, y debido a ello una compañía estilo-producto debe tener un producto de calidad con un contrato de calidad con términos justos y claros.

Desde todos los lados, estos grupos cooperativos facilitan la venta, en vez de conseguirla por la fuerza. Y sin esa fuerza, estos grupos debes ser de primera categoría en sus ofertas y ejecución. Así que cuando estan, pueden ofrecer un mecanismo de ventas mas fuerte y consistente, que esperar a que el vendedor estrella vaya a traer la comida a casa. Todos estos grupos (comercialización, consultoria, soporte, y administracion de ventas) deben estar conectados en los mismos 2 puntos centrales: el cliente y el producto. Ya hablamos sobre el lado cliente así que ahora nos moveremos al lado del producto.

Haz que el producto funcione

No es sorprendente que sean los desarrolladores del producto quienes estén a la cabeza en una empresa estilo-producto. Ellos deben dirigir hábilmente el producto para cumplir las necesidades del cliente mientras se mueven del soporte preventa al soporte postventa.

La comercialización puede ser interesante si se le da un solo objetivo: funcionalidad para el producto. El producto debe hacer algo obviamente útil. Las funcionalidades relampagueantes pueden darle al equipo de ventas un empuje a corto plazo en las ventas, pero a medida que pase el tiempo los usuarios necesitaran funcionalidad real. Para los desarrolladores del producto, esta es tal vez la lección mas importante de la era puntocom.

Sin un equipo de ventas para presionar, el producto debe funcionar. Para que el soporte preventa haga que el producto se acomode sin martillazos del equipo de ventas, los desarrolladores deben dotar al producto de una simple instalación e implementacion. Y esencial para el beneficio del soporte postventa, los desarrolladores del producto deben ir por el lado de la simplicidad y la estabilidad.

Esto es extraño con el patrón de exceso de funcionalidades de la mayoría del desarrollo de software actual, pero es enteramente compatible con la madurez de la funcionalidad de un producto perfectamente mantenido.

Este producto debe estar continuamente en buen estado para asegurar que su crecimiento no compromete su funcionalidad, simpleza o estabilidad. Tal refactorizacion mantiene comercialización , soporte preventa, y soporte postventa fuera del modo de crisis. Esto a su vez mantiene tranquilos a los desarrolladores de producto y les da importante tiempo para dedicar a la funcionalidad.

No es para el débil de corazón

Una empresa estilo-producto no es para el débil de corazón: toma mucha fe renunciar a un equipo de ventas, no tendrás a quien culpar por que las ventas no sucedieron. Pero cuando muevas el foco de las ventas al producto, ganaras algo ademas de un buen producto: ganas un siguiente.

Externamente, usted tiene clientes que son felices de tener un producto que es funcional, simple y confiable. Internamente, usted tiene gente que ses enorgullece de un producto que es comercializable, vendible y soportable. Y esto no es un mal estilo de vida, para el producto o la gente.

jueves, septiembre 11, 2008

Deja que Watts S. Humphrey te ayude a mejorar la calidad de tu software

¿ Estas cansado de esforzarte y que pese a eso termines haciendo software de mala calidad: software que finalmente sale mas costoso de lo que se había planeado, software que se termina de desarrollar mucho tiempo después de lo que decía el contrato y no tiene todos los requerimientos que el usuario pidió ?


Si es así entonces Watts S. Humphrey tiene una sugerencia para ti, este señor quien recibio de la mano del presidente de los estados unidos la medalla nacional de tecnologia por su trabajo a favor de la ingeniera de software, te quiere mostrar la forma como el lleva a cabo sus proyectos (su proceso personal) y con ello espera que la calidad de tu trabajo mejore, pero te corresponde a ti al final de esta enseñanza ver si realmente has alcanzado mejores estandares de calidad usandolo tal cual como lo hace el o si al acaso debes adaptarlo a tus costumbres y/o ambiente antes que mejore tu productividad o simplemente no sirve para nada y deberas seguir buscando en otros lugares.


Si realmente estas cansado de este problema (Crisis del Software) y quieres escuchar el consejo de un experto entonces puedes empezar ya mismo leyendo gratuitamente el primer capitulo de PSP A Self-Improvement Process for Software Engineers y si las promesas que se hacen en este capitulo te agradan, entonces compra el libro, aprende psp y comprueba si son ciertas o no con tu propia experiencia.

lunes, septiembre 01, 2008

jueves, agosto 07, 2008

Litigios sobre proyectos de software como evitarlos y que hacer en caso de

Estve leyendo el articulo Litigation Support for Software Intensive Projects de Tom DeMarco y Tim Lister(los de peopleware) y me encanto, basicamente dice:

Para evitar un litigio hay que:

  • Hacer contratos que usted firmaria asi fuera el cliente o la empresa desarrolladora
  • Conducir exaustivos y reflexivos analisis de requerimientos 
  • Hacer un cuidadoso trabajo de medicion
  • Enfocarse en buenas practicas de gestion
  • Hacer una pequeña gestion del riesgo, solo por si acaso
 y si pese a todo su proyecto termina en litigio:
Pdt: En el enlace de The Condensed Guide to Software Acquisition Best Practices se pueden descargar otras guias sobre las mejores practicas en el software hechas por The Software Program Managers Network bajo el patrocinio del Departamento de Defensa de los Estados Unidos, precisamente ahora me encuentro disfrutando de una de estas guias, el Little Brown Book of Program Manager Bad Excuses (introduccion de Tom DeMarco)

miércoles, agosto 06, 2008

Productividad en modificaciones al software

Yo siempre había pensado que era mas fácil y rápido hacer nuevos proyectos de software que modificar los antiguos pero leyendo PSP: A Self-improvement Process for Software Engineers me encontré con un par de citas con las cuales avalar mis impresiones.

"the productivity for software modification is often much slower than for new development"  Flaherty, M. J. "Programming Process Productivity Measurement System for System/370." IBM Systems Journal 24, no. 2 (1985): 168–175.


"an unpublished IBM study found that small code modifications were 39 times as error-prone as new development when measured in defects per modified LOC" - Managing the Software Process by Watts S. Humphrey

martes, agosto 05, 2008

¿ Como evalar si un proyecto de software es exitoso o no ?

Si el gremio de los desarrolladores de software no esta de acuedo respecto a cuales son las prioridades, enfoques o que debe hacer un individuo en circunstancias especificas para cumplir con sus labores (Debates within software engineering) entonces ¿ como se puede diferenciar un proyecto con una mala ejecucion del que a tenido una buena ? ¿ Como 2 respetados autores de textos sobre el desarrollo de software como Ed Yourdon y Tom de Marco ofrecen sus servicios como expertos tecnicos en litigios sobre contratos de software y sobre que parámetros ellos definen si un contratista dejo de cumplir o no con sus obligaciones ?



¿ Sera que es tal el estado de la ingeniería de software como área del conocimiento que solo podemos decidir si un proyecto es exitoso o no, por criterios subjetivos ?

O acaso los criterios deben ser exageradamente generales y muy cercanos a la sola revisión sobre si se cumplieron las estimaciones iniciales de:

  • Presupuesto

  • Tiempo de Desarrollo


  • Funcionalidad (Cantidad de cosas hechas)

Todo esto es lo que se me pasa por la cabeza cuando veo a ZettaByte diciendo en twitter: Necesito documentacion sobre malas practicas de implementacion de proyectos y desarrollo de software por que mirando las cosas desde alguna de las múltiples y contradictorias metodologías de desarrollo de software uno podría decir que falta o sobra determinado elemento para cumplir con ella, pero difícilmente tendría unas bases teóricas fuertes que sean reconocidas a lo largo de todo el gremio como para decir que el incumplimiento de esa practicas o de varias de ellas hace que el proyecto sea un fracaso.





Personalmente me quedo sin ideas pero el motivo detrás de esta entrada es esperar a que los lectores me den las suyas y/o repuestas contundentes a como hacer estas evaluaciones pues pese a llevar varios años en esto me declaro en la misma inquietud que ZettaByte

miércoles, julio 30, 2008

Los dibujos en Smart and Gets Things Done

Navegando por la red me encontré con el libro Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent que fue publicado en Mayo del 2007. Básicamente el libro se promueve como una guía para atraer, reclutar, entrevistar y contratar a los mejores desarrolladores de software, el autor Joel Spolsky es el famoso blogger de joelonsoftware.com un antiguo trabajador de Microsoft donde como miembro del equipo Excel diseño VBA y fundador de Fog Creek Software.


Y aunque con el anterior párrafo debería haber suficiente como para interesarse en leerlo, realmente falta otra buena razón LOS DIBUJOS, estuve mirándolo en google books y realmente son de lo mejor:

lunes, julio 14, 2008

Nivel de agilidad en las principales metodologías para desarrollo de software

En el texto Balancing Agility and Discipline de Barry W. Boehm y Richard Turner aparece una tabla indicando el nivel de agilidad de diferentes metodologías de desarrollo de software y me pareció interesante para mi aprendizaje del tema (y tal vez el suyo si es que le interesa este asunto) copiar la tabla tal cual como la ponen en el blog scrumlabs y añadirle el enlace a la wikipedia referente a cada metodología, con el fin de tener un indice de acceso rápido que pueda ir consultando con el tiempo y así tener aunque sea una idea básica de cada una.
Nivel de agilidadMetodologia
1SCRUM - [ES]
2Adaptive Software Development (ASD)
3Lean Development (LD)
4Crystal
5eXtreme Programming (XP) - [ES]
6Dynamic Systems Development Method (DSDM) - [ES]
6Rational Unified Process (RUP) - [ES]
6Team Software Process (TSP)
9Feature Driven Developmennt (FDD)
10Capability Maturity Model Integration (CMMI) - [ES]
11Capability Maturity Model for Software (SW-CMM) - [ES]
12Personal Software Process (PSP) - [ES]
13Cleanroom

miércoles, junio 18, 2008

Ingenieria de Software Academia vs Realidad

Según el swebok del IEEE se debería saber lo siguiente para ser un Ingeniero de Software:

Desafortunadamente lo que se suele ver en el gremio es un par de posiciones extremistas:
El problema es que ambas posiciones son erradas, radicales y conducen a malos Ingenieros de Software que solo pueden producir proyectos de escasa calidad (si es que consiguen terminarlos) y ademas son pésimos a la hora de trabajar en equipo por que el uno infravalora el trabajo del otro.

Actualización: recién acabo de leer el EWD 1165 y como de costumbre Dijkstra es notable.

lunes, febrero 19, 2007

Planear un proyecto de software es MUY dificil

Planear es dificil.
  • Nadie realmente sabe como estimar proyectos de software mas alla de un mes o algo asi.
  • Aun asi los administradores escriben calendarios de tareas para los siguientes seis meses.
  • Los programadores en secreto no creen en esos calendarios, aunque son presionados para aceptarlos.
  • El proyecto entonces se alarga, todos trabajan horas extras, el proyecto se entrega lleno de errores, y la gente se molesta.
Me suena a como si lo hubiera escrito yo, pero nada que ver por que es un texto extraido de una conferencia sobre Extreme Programming dictada por Dan Kegel, lo que no evita que me sienta profundamente de acuerdo.