1. Gestin de Proyectos de Desarrollo de Software http://www.freewebs.com/jobsystemspersonal/apps/blog/show/1978087-gesti-eproyectos-de-desarrollo-de-software http://html.rincondelvago.com/analisis-y-diseno-de-sistemas-informaticos.

html

Posted by Ariel Alejandro Wagner on October 22, 2009 at 12:11 AM

Gestin de Proyectos
Todo diseo de proyecto requiere de una coordinacin satisfactoria. Dentro de este escenario, girar lo que concierne al tiempo de desarrollo, los personajes que intervendrn en el diseo, los costes, etc. Por tanto, las preguntas que nos debemos hacer inicialmente son las siguientes:

Qu es? Quin lo hace? Por qu es tan importante? Cules son los pasos? Cul es el producto obtenido? Cmo puedo estar seguro de que lo he hecho correctamente?

Muchos son los temas en que gira este proceso. En el terreno de lo personal, podemos citar los tan discutidos y promulgados expertos y la madurez de la capacidad de gestin humana. Ello hace nfasis enlos expertos del software y como motivar a que estos produzcan lo mejor de si y el mejor software posible. Adems de esto, la organizacin y la bsqueda de desarrolladores o ingenieros con dotes de capacidad y talento, etc. Luego, aparece el producto como punto departida del desarrollo. Esta fase resulta ser tan crucial cuando el desarrollador y el cliente se sientan a conversar y a trazar el objetivo general en base a la necesidad del cliente y las pautas que este impone en dicho escenario. La fase del proceso, que emerge de las trazas de los objetivos y donde se planifica la mecnica operacional del desarrollo que contempla las actividades, los hitos, los requisitos del proyecto, las mediciones, la calidad del software, etc. Por ltimo, hablamos del proyecto en los que sumergen las planificaciones y que son controlados por la razn principal. Esto se practica a los efectos de evitar desviaciones durante las fases evolutivas del proyecto. El secreto y el xito de producir software con bajos mrgenes de errores, quiz, depender de tener presente tanto los objetivos, los datos de relevamiento lo ms fidedignos posibles y los improvistos controlados. Todo esto mejorar la calidad productiva de la construccin y gua del proyecto engeneral.

El Personal

El capital ms poderoso, creativo e incidente del xito de una empresa resulta ser la calidad de sus profesionales y sus empleados en una compaa. As mismo, para el caso del

desarrollo de software esta regla es similar. El personal es clave en el xito del desarrollo del software. Ahora bien, para lograr que esta sinergia de personas realice sus actividades de forma eficiente y eficaz se requiere de una basta estrategia de organizacin. Por tanto, la coordinacin y la organizacin sern claves en el desarrollo exitoso del software. Es por ello que la organizacin debe ser coordinada por un gestor que administre competencias humanas ms que competencias tcnicas y es all donde surge la brecha entre organizadores humanos y tcnicos. En consecuencia, lo que se debe preconizar es la administracin humana y como lograr el mejor xito coordinado de las mismas para que estas produzcan en el terreno de la creatividad y el esfuerzo tcnico. El ingeniero Mantei considera que un equipo puede administrarse mediante tres pilares bsicos y ellos son: Descentralizado Democrtico DD - Este equipo no tiene un jefe permanente. Se nombran coordinadores a corto plazo y se sustituyen por otras diferentes tareas. Se utiliza el consenso como poder comunicativo, es decir, se trata de una comunicacin horizontal. Descentralizado Controlado DC - Este equipo posee un jefe de cabeza y otros por debajo de este. Se mantiene el grupo pero la implementacin de soluciones se reparte en subgrupos por el jefe del equipo. La comunicacin entre subgrupo e individuos es horizontal y vertical a lo largo de la jerarqua de control. Centralizado Controlado CC - El jefe se encarga de la resolucin de los problemas a alto nivel y la coordinacin interna del equipo. La comunicacin entre el jefe y el equipo es vertical. Adems de estas caractersticas, el ingeniero Mantei ha descripto esta tarea de coordinacin en siete etapas, las cuales, le pueden ayudar a replantear la organizacin de equipos de produccinde proyectos y estos son los siguientes:

Dificultad del Problema a Resolver El Tamao del Programa - Resultante en lneas de cdigo o puntos de funcin El Tiempo que el Equipo Permanecer Unido - Tiempo de vida del equipo El Grado del Problema puede ser Modularizado Calidad y Fiabilidad del Sistema a Construir Rigidez de Fecha de Entrega Grados de Sociabilidad - Comunicacin requerida para el proyecto

En consecuencia, la organizacin de los grupos depende del tipo de proyecto y su envergadura. Resulta interesante saber, que segn las recomendaciones del ingeniero Mantei, que el manejo de soluciones sencillas conviene que las administre equipos tanto DC o CC. Sin embargo, cuando los problemas no resultan ser sencillos, resulta recomendable pensar en un equipo DD.

El Producto
Quiz uno de los pasos ms complejos es la de determinar los costes y los valores cuantitativos del producto. La complejidad de un proyecto y la difcil situacin de ponderar componentes y personas, surge de la necesidad de encontrar un punto que determina la forma en cmo obtener el beneficio del coste de forma segura. Algunos tienden a aplicarla ley de Maquiavelo, "divide y vencers". De hecho suele ser una estrategia interesante. Un problema muy complejo puede ser dividido en problemas ms pequeos o atomizados. Si esto es posible, Ud., puede cuantificar mejor los costes de desarrollo de cada rea y juntarlos para obtener el coste global. Sin embargo, no resulta en una tarea sencilla. Peor an, puede que sus costes se vayan distorsionando con el correr del avance del proyecto dado que la inconsistencia de los recursos se hace notar en estas etapas. Es por ello que la cuantificacin de los costes se establezca con un meditado plan de desarrollo que contemple estas y otras desviaciones posibles de la presupuestacin.

El gran problema que se tiene de entrada es que no se puede determinar con precisin la calidad del software.Lamentablemente, la calidad se podr notar cuando el modelo emprico y de prueba inicie sus primeras horas de vida. Es por ello que crear prototipos de modelos resulta en una locura despus de todo. Yo dira que el prototipo podra ser un generador de cuantificaciones que pueden servir para obtener los costes finales o, al menos, contar con un tanteo del coste del producto a simple vista. En resumen, la clave est en la coordinacin, los objetivos y el desarrollo evolutivo del proyecto ms el prototipo de muestra y evaluacin.

El Proceso
Ha de estudiarse con mucho cuidado el proceso que se aplicar para el desarrollo del proceso. Si bien se ha estudiado que existen varias formas de practicar esta fase, la clave del proceso erradica en aplicar el mtodo adecuado. Pasamos a recordarlos a continuacin:

Modelo Secuencial Modelo de Prototipo Modelo DRA (Desarrollo Rpido de Aplicaciones) Modelo Incremental Modelo Espiral y Espiral WINWIN Modelo de Desarrollo de Ensamblaje y Componentes Modelo de Desarrollo Concurrente Modelo de Mtodos Formales Modelos de Tcnicas de Cuarta Generacin

Por tanto, toda planificacin comienzacon un proceso de maduracin del desarrollo. Esta fase de maduracin permite establecer las siguientes pautas evolutivas del proyecto: Comunicacin con el Cliente - Tareas requeridas para establecer la obtencin de requisitos eficiente entre el desarrollador y el cliente. Planificacin - Tareas requeridas para definir los recursos, la planificacin temporal del proyecto y cualquier informacin relativa a l. Anlisis del Riesgo - Tareas requeridas para valorar los riesgos tcnicos y de gestin. Ingeniera - Tareas requeridas para construir una o ms representaciones de la aplicacin. Construccin y Entrega - Tareas requeridas para construir, probar, instalar y proporcionar asistencia al usuario (por ejemplo: documentacin y formacin) Evaluacin del Cliente - Tareas del cliente basadas en la evaluacin de las representaciones de software creadas durante la fase de ingeniera e implementadas durante la fase de instalacin. La descomposicin de los procesos resulta una tarea muy importante y, como hace mencin el ingeniero Mantei en sus observaciones, resulta importante considerar el modo ECP (Estructura Comn de Procesos). Por ejemplo, para un pequeo proyecto se tiene los siguientes pasos: 1. 2. 3. 4. 5. Desarrollar una lista de aspectos que se han de clarificar Reunirse con el cliente para resolver los aspectos que se han de clarificar Desarrollar conjuntamente una exposicin del mbito del proyecto Revisar al alcance del proyecto con todos los implicados Modificar el alcance del proyecto cuando se requiera

Estos son aspectos que pueden resolver pequeos problemas y establecer un lineamiento de fases bastante fciles de seguir y con resultados satisfactorios a corto plazo. Sin embargo, en un proyecto ms complejo surgen otras variantes que pueden complicar este tipo de lineamientos. Por ejemplo, para el caso de un proyecto cuyas fases muestren un escenario ms amplio, las fases evolutivas del proceso podran ser las siguientes:

1. 2. 3. 4. 5. 6.

Revisar la peticin del cliente Planificar y programar una reunin formal con el cliente Realizar una investigacin para definir soluciones propuestas y enfoques existentes Preparar un documento de trabajo y una agenda para la reunin formal Realizar la reunin Desarrollar conjuntamente mini-especificaciones que reflejen la informacin, funcin y caractersticas de comportamiento del software 7. Revisar todas las mini-especificaciones para comprobar su correccin, su consistencia, la ausencia de ambigedades 8. Ensamblar mini-especificaciones un documento de alcance del proyecto 9. Revisar ese documento general con todo lo que pueda afectar 10. Modificar el documento de alcance del proyecto cuando se requiera.

El Proyecto
Cuando se establece el seguimiento de un proyecto, la mayor preocupacin estriba en la desviacin y en que las cosaspuedan ir yendo en un sentido inadecuado. Si esta desviacin se nota en las fases del proyecto, deber de inmediato, tomarse decisiones acertadas. Existenlas famosas reglas de seales de peligro definidas por el ingeniero John Reelen el que ha elaborado una tabla de notaciones negativas de la evolucin de un proyecto que tiene una tendencia al desvo de los objetivos. Estas reglas son las siguientes: 1. La gente del software no comprende las necesidades de los clientes 2. El mbito del producto est definido pobremente 3. Los cambios estn mal realizados 4. La tecnologa elegida cambia 5. Las necesidades del negocio cambian o estn mal definidas 6. Las fechas de entrega no son realistas 7. Los usuarios se resisten 8. Se pierden los patrocinantes o nunca se obtuvieron adecuadamente 9. El equipo del proyecto carece del personal con habilidades propias 10. Los gestores y los desarrolladores, evitan buenas prcticas y sabias lecciones Bien, para conducir el proyecto bajo un carril adecuado, el ingeniero John Reel establece el llamado "sentido comn" y lo ha especificado en cinco reglas bsicas y estas son las siguientes: Empezar con el pie derecho - Esta tarea se realiza trabajando duro, pero muy duro, para comprender el problema a solucionar y estableciendo entonces objetivos y expectativas realistas para que cualquiera que vaya a estar involucrado en el proyecto. Se refuerza construyendo el equipo adecuado y dando al equipo la autonoma, autoridad y la tecnologa necesaria para realizar el trabajo. Mantenerse - Muchos proyectos no realizan un buen comienzo y entonces se desintegran lentamente. Para mantenerse, el gestor del proyecto debe proporcionar incentivos para conseguir una rotacin del personal mnimo, el equipo debera destacar la calidad en todas las tareas que desarrolle y los gestores veteranos deberan hacer todo lo posible por permanecer fuera de la forma de trabajo del equipo. Seguimiento del Progreso - Para un proyecto de software, el progreso se sigue mientras se realizan los productos del trabajo (por ejemplo, especificaciones, cdigo fuente, conjunto de casos de prueba) y se aprueban (utilizando revisiones tcnicas formales) como parte de una actividad de garanta de calidad. Adems, el proceso del software y las medidas del proyecto pueden ser reunidas y utilizadas para evaluar el progreso frente a promedios desarrollados por la organizacin de desarrollo de software. Tomar Decisiones Inteligentes - En esencia, las decisiones del gestor del proyecto y del equipo de software deberan "seguir siendo sencillas". Siempre que sea posible, utilice software del mismo comercial o componentes de software existentes. Evite personalizar interfaces cuando estn disponibles aproximaciones estndar. Identifique y elimine entonces riesgos obvios. Asigne ms tiempo del que pensaba necesitar para tareas arriesgadas o complejas (necesitar cada minuto).

Realizar Anlisis Postmorten, despus de finalizar el proyecto - Establecer un mecanismo consistente para extraer sabias lecciones de cada proyecto. Evaluar la planificacin real y la prevista, reunir y analizar mtricas del proyecto de software y realimentar con datos de los miembros del equipo y de los clientes y guardar los datos obtenidos en formato escrito.

2. Administracin de Software Informtico

Posted by Ariel Alejandro Wagner on October 22, 2009 at 1:56 AM

Administracin de Software Informtico

Gran parte de los desarrollos de sistemas requieren, no solamente de mantenimientos, sino que incluso, requieren de correcciones del software que en un sentido amplio, podramos mencionar desde fallos operativos hasta incluso refinamientos. Uno de los ms grandes desafos del desarrollo y mantenimiento erradica de la construccin de un sistema slido de soporte tcnico y de respuestas a los clientes. El objetivo de aumentar la calidad de los servicios oblig a ms de muchos profesionales del software a elaborar distintos tipos de estrategias, que en la actualidad, algunas de ellas son estndares, propuestas, estrategias o una serie de recomendaciones que posibilitan las capacidades de mejorar el servicio de forma satisfactoria. Y cmo dira mi abuelita querida, el mercado y el cliente siempre tienen la razn. Por tanto y en sntesis, el objetivo ms importante se centra en el foco llamado Cliente.

Algunas Propuestas y Estndares

El ITIL (Information Technology InfrastructureLibrary) o Librera de Informacin de Estructura Tecnolgica, se compone de una serie de recomendaciones que son muy tiles para la administracin de servicios informticos. La CCTA (CentralComputer & Telecomunications Agency) o Agencia Central de Computadoras y Telecomunicaciones, ha desarrollado una biblioteca de ms de 40 libros en Inglaterra acerca de tems y conceptos en materia de desarrollos informticos y de software. Uno de los objetivos msimportantes de la CCTA fue la de centrar la eficacia empresarial en el uso de sistemas informticos. De esta manera, se podra beneficiar con el ahorro de costes, aumentar sensiblemente las mejoras en materia de soporte tcnico y calidad del producto informtico, etc. Esto ha contribuido a la concepcin de esta biblioteca tcnica ITIL que justifica los esfuerzos de dichos comits y que estn al servicio de los desarrolladores, tcnicos y profesionales del software. En resumen y en unsentido amplio, la propuesta permite generar a los profesionales y/a las empresas los siguientes beneficios y ventajas operativas:

Aumento de la Satisfaccin de los Clientes Reduccin del Coste de Desarrollo de Prcticas y Procedimientos Mejor en los Flujos de Comunicaciones entre el Personal de Informtica y los Clientes Aumento de la Productividad y del Uso de Capacidades y Experiencia

Estrategia MOF de Microsoft

MOF (Microsoft Operations Framework) o Marco de Operaciones de Microsoft, se trata de una estrategia desarrollada por la firma Microsoft Corporation y se trata de una coleccin de recomendaciones, principios y modelos. Consiste en una gua completa que se fundamenta como objetivo principal en la obtencin de lograr la confiabilidad, disponibilidad, capacidad de soporte tcnico y administracin de produccin, basadas en tecnologas Microsoft. MOF se compone de dos grandes modelos operativos y estos son los siguientes:

Modelo de Equipo Modelo de Procesos de Operaciones

La clave o estrategia de MOF para el diseo de software de calidad basado en tecnologas de Microsoft, hace nfasis en un proceso que consiste en una serie de ciclos sucesivos y que tienen repercusin e impacto directamente sobre el modelo de software. Acontinuacin, analizaremos los ciclos que representan este escenario sistmico y sus principales propsitos operativos.

Fases Operativas del Modelo MOF

Las fases operativas laspodemos dividir en tres partes importantes y ellas son las siguientes:

Modelo de Procesos - Procesos de Operacin Modelo de Equipo - El Rol de las Personas Disciplina de Gestin - Manejo del Riesgo

Modelo de Procesos
En mencin al modelo de procesos, si observamos en detalles, se asemeja muchsimo al modelo propuesto por el Dr. William Edwards Deming en su teora de la evolucin de los p rocesos sistmicos. El Dr. Deming describa a todo proceso de desarrollo o investigacin enmarcndolo en un ciclo circular que se compona de cuatro etapas o fases evolutivas principales. Microsoft ha asimilado este concepto y lo ha adoptado al marco productivo de desarrollo de sus sistemas con algunas caractersticas personalizadas. En consecuencia, Microsoft describe a estas fases en las siguientes:

Changing - Cambios Operating - Funcionamiento Supporting - Soporte tcnico Optimizing - Optimizacin

En resumen podemos especificar que las cuatro etapas de este ciclo permiten ir refinando los procesos de desarrollo y evolucin de los sistemas de forma eficiente. Por tanto, podemos reducir cuatro comentarios finales y ellos son los siguientes: La administracin de servicios informticos, como el desarrollo de software, tiene un ciclo de vida. El ciclo de vida se compone de diferentes fases lgicas que se ejecutan al mismo tiempo. Las revisiones de operaciones deben estar basadas en versiones y en el tiempo. La administracin de servicios informticos afecta a todos los aspectos de la compaa.

Modelo de Equipo
El modelo de Equipo que propone Microsoft es muy similar al modelo propuesto por McKinsey la cual en la jerga de administracin de sistemas es conocida con el nombre S7, "Las Siete S de McKinsey". Este modelo fue desarrollado para cimentar y estructurar todos los procesos que demandan empresas, industrias, gerencias, etc., la gestin de procesos y

sistemas complejos de administracin. La salvedad en este caso es que Microsoft oriento este tipo de ideas personalizando algunos puntos especficos de la teora S7 y encausndolas en un modelo de refinamiento de sus diversos productos desoftware. El modelo que propone Microsoft, consiste en siete estadios enumeradas como actividades en siete grupos distintos de reglas que representan las reas o, roles funcionales,dentro de las operaciones donde los miembros o los grupos particulares de personal estn realizando actividades hacia una meta compartida o una misin similar de servicios. Por tanto podemos resumirlas siguientes metas del modelo de equipo que propone este estndar y son lassiguientes:

Administracin controlada del lanzamiento y del cambio, seguir exacto el inventario de todos los servicios y sistemas (grupo del rol de lanzamiento) Administracin eficiente de ambientes y de herramientas fsicas de la infraestructura (grupo del rol de infraestructura) Soporte al cliente con calidad y una cultura del servicio (grupo del rol de la ayuda) Administracin de sistema cotidiana, fiable, repetible y automatizada (grupo del rol de las operaciones) Activos corporativos protegidos, autorizacin controlada a los sistemas y la informacin y planeamiento proactivo para la respuesta de emergencia (grupo del rol de la seguridad) Relaciones eficientes, rentables y mutuamente beneficiosas con los socios de servicio (grupo del rol del socio) Entrega de una lista de servicios alineados con el negocio (grupo del rol del servicio)

Disciplina de Gestin
En toda elaboracin de un proyecto o un desarrollo de sistema, se requiere de un profundo anlisis de riesgos. Tanto el impacto tecnolgico como el econmico son polos incondicionales del anlisis. Resulta recomendable hacer nfasis en todos los aspectos o perfiles de los mismos. Por ejemplo, dentro del terreno tecnolgico, existe un modelo amplio de espectros de puntos de anlisis. En este compendio de procesos tcnicos, se centran los fallos, la complejidad de escala, la recuperacin, etc. Los principios claves del modelo de riesgos tienen incidencia en las operaciones, en la observacin, la resultante si es bueno o es malo, de carcter administrativo y la responsabilidad individual o colectivadel producto desarrollado. En consecuencia, se puede enumerar cinco fases especficas que describen al modelo de riesgos o la llamada disciplina de gestin y ellos son los siguientes:

Caracterstica Observable o de Identificacin Adoptar la Administracin de Riesgos Agentes Principales de Riesgos Equipos de Respuesta de Emergencia Entrenamiento y Recursos Humanos

Ampliando las Funcionalidades del Modelo de Equipo

El modelo de equipopropone entonces:

Las actividades, tareas y capacidades clave de cada una de las funciones Los principios de gua que se deben mantener para tener el mayor xito en la ejecucin y el funcionamiento de entornos informticos distribuidos en la plataforma Microsoft.

Referencias: Dr.William Edwards Deming - Fue el mentor de una teora llamada Ciclo PDCA (Plain Do Control & Action) o el ciclo Deming en la que permita demostrar las fases evolutivas durante un proceso progresivo en el campo de los sistemas, desarrollo, calidad de productos, gerencias, etc. En la actualidad, sus teoras son aplicadas en muchas reas cientficas y comerciales. McKinsey - Se trata deuna consultora muy importante que operaba en los '60. Fue mentor de la teora S7 en la que se explica en siete procesos, el equilibrio que deba existir en toda compaa, empresa, institucin, sistema, etc., para lograr la mejor optimizacin, funcionalidad y eficiencia.