Segun Nonaka y Takeuchi (1995) proponen estos procesos de creación de conocimiento para entender su naturaleza dinámica y lo describen en cuatro procesos:
1) De tácito a tácito: El paso de conocimiento de tácito a tácito se produce a través de procesos de socialización, es decir, a través de la adquisición de conocimientos e información mediante la interacción directa con el mundo exterior, esto es experiencias compartidas por medios de expocisiones orales, documentos, con otras personas, con otras culturas, etc.
2) De tácito a explícito: Se produce a través de la externalización, que podríamos definir como el proceso de expresar algo de forma tangible, el diálogo. Externalizar es convertir imágenes y/o palabras a través del diálogo, permitiendo la comunicación.
3) De explícito a explícito: Este paso se denomina combinación. Como su propio nombre indica, se combinan diferentes formas de conocimiento explícito mediante documentos o bases de datos.
4) Explicito a tácito: es la Interiorización del conocimiento, y consiste en la incorporación del conocimiento tácito por parte de los individuos de cualquier organización en la forma de modelos mentales compartidos o practicas de trabajo.
viernes, 19 de septiembre de 2008
lunes, 11 de agosto de 2008
Simulación de Atención del Departamento de Soporte Técnico de UTPL
1. INTRODUCCIÓN2. DESCRIPCIÓN DEL SISTEMA
Actualmente el Departamento de Soporte Técnico se encuentra funcionando en el tercer piso del edificio de
Administración y centralización de impresoras.
Administración del antivirus del campus.
Garantía de computadores.
Asistencia técnica.
Las mismas, que atienden los diferentes problemas que se suscitan en los diversos departamentos de
Los datos son recogidos en el periodo de Abril y principios de Mayo.
El funcionamiento de la atención de Soporte Técnico se basa en receptar las llamadas realizadas por los diferentes departamentos de
El tema se centra en la simulación de la respuesta a resolver los problemas técnicos de los diferentes departamentos de
HELPDESK (Emite la solicitud de atención)
Becario (Recibe y atiende la solicitud)
Becario acude al departamento afectado (Tiempo de solución del problema).
En vista del desconocimiento de los datos recopilados de tiempo requerido para la atención de los diferentes problemas técnicos de los departamentos de
2. DESCRIPCIÓN DEL SISTEMA
El esquema de resolución propuesto por nuestra parte es el de clasificar los problemas y entregar esta tarea a un determinado becario que resolverá esta solicitud, y las peticiones que no se puedan ser atendidas por el becario en cuestión, pasaran a un estado de pendientes, todo este esquema nos proporciona los datos requeridos para resolver nuestros siguientes objetivos:
Objetivos:
· Determinar si el número de personal del Departamento de Soporte Técnico de
· Determinar que tipo de problema es más frecuente al entrar en estado pendiente.
· Determinar el número de problemas que puede resolver un técnico del departamento de soporte técnico de
Aquí se describe el diseño del modelo de simulación.
1. Gráfico del Sistema.
Figura 1
2. Elementos del Sistema.
- Entidades.
Problema
- Atributos.
Tipo de Problema:
Problemas de Impresoras
Conexión a Internet
Problemas con Antivirus
Problemas de Aplicaciones
Problemas de SW y HW
- Actividades.
HELPDESK:
o Se verifica si un técnico está disponible, en caso contrario dejar en pendiente el problema.
o Emitir la asignación de problema a becario.
BECARIO:
o El técnico ira al departamento que solicito ayuda para dar solución al problema.
Localizaciones:
o HelpDesk
o Becario
o Departamentos de UTPL
3. Análisis del Sistema.
- Eventos.
Asignación de Problema.
o Dependiendo la probabilidad de ocurrencia de los tipos de solicitud de problema, se asigna el becario provisto para el mismo.
- Eventos Principales.
Llegada de la solicitud.
Verifica disponibilidad de técnico.
Asignar el becario.
4. Variables.
- Tiempo.
Tiempo de llegada de solicitud de resolución de problema, proporcionada por la distribución.
Tiempo de solución del problema.
- Contadores.
Cantidad de problemas (designación de técnico).
Problemas Solucionados (solución del problema).
- Estado del Sistema.
Desde el momento que se obtiene una petición a través HELPDESK que durará un promedio de 45 minutos, luego se verifica que exista un técnico disponible para emitir la solicitud de atención del problema caso contrario se dejara como pendiente. Luego el técnico acudirá al departamento que reporto el problema, en donde el técnico dará solución inmediatamente.
5. Diagrama de Flujo.
- Programa Principal.
Figura 2
Organizational Learning: Combinaciones de conocimiento tácito y explícito para crear conocimiento personal
Abstract
El conocimiento se simenta como una capacidad humana unica, su transmisición implica un proceso intelectual de enseñanza y aprendizaje, en ello se puede establecer dos tipos que tienen una interacción intrínseca que es el conocimiento explícito y el conocimiento implícito (tácito). Ademas el conocimiento al no ser de carácter estático pues el conocimiento se genera continuamente por el uso de la capacidad de razonamiento o inferencia por tanto su valor se acrecenta y apoyado mediante los medios de distribución en el entorno actual, crece y crea nuevo conocimiento, por tanto la relación entre conocimiento tácito y explicito descrito en el proceso de creación del conocimiento (Nonaka, Takeuchi) muestra esta naturaleza dinamica y continua.
En el presente artículo presenta la interacción del conocimiento tácito y explicito para crear conocimiento, su fundamentación y las diversas fases de relacion de estas para su dinámica creativad.
Palabras Claves: Conocimiento implícito (tácito), Conocimiento explícito.
Introducción
Desde los inicios del la humanidad, el ser humano a buscado el conocimiento desde su adquisición y asi replicarla para de esta manera conservarla y enseñarla a su progenie, su ubicación geográfica en zonas que le permitierón su desarrollo en un menor tiempo y con un mayor volumen, dando el tiempo para alimentarse de información de valor emocional, de relación con su entorno, permitió la relación de abstracción o representatividad entre el signo y el hecho, estos estimulos generarón el desarrollo de la relación hombre/realidad, permitiendo así la evolución y sofisticación de este tipo de representación de signos abstractos. Observando este desarrollo continuo di pie a elementos de mediación interpretativa, acrecentando la capacidad humana de intervención de la realidad, es asi que se desarrollo nuevos medios tecnológicos y organizacionales.
Desde el punto filosófico, se establecido un diferenciación del conocimiento, el “saber que” que se conoce como conocimiento teórico y generalmente esta asociado con la mente, y el “saber como” que esta vinculado conmúnmente con lo corporeo y se lo conoce como conocimiento práctico.
En nuestro entorno, la creación del conocimiento se da dentro de las personas y situaciones entre ellas y su realidad, ademas con ayuda de los nuevos procesos tecnológicos de la información de manera importante integran el componente principal de la gestion del conocimiento.
El informe de la OCDE de 1996 subdivide al conocimiento en 4 tipos de saber:
1. Saber QUÉ: hechos y realidades, conocimineto cercano a la información.
2. Saber POR QUÉ: los principios y las leyes de la naturaleza, que se producen en los laboratorios y/o universidades.
3. Saber CÓMO: habilidades o capacidades para hacer algo.
4. Saber QUIÉN: supone saber quien sabe que y quien sabe como hacer qué.
Metodología para la Creación de conocimiento
Los procesos que debe seguir la información para transformarse en conocimiento son percepción, creación de conocimiento y toma de decisiones, y los mismos estan estrechamente relacionados, pues cada proceso lleva consigo una nueva generacón de conocimiento e información, de esta manera estos tres procesos se retroalimentan interactuan todos contra todos y no en un flujo lineal.
El proceso de Percepción, se interpreta la información que se generan en nuestro entorno o medio ambiente que desde luego sea relevante en un determinado ambito en el cual se requiere el conocimiento, el cual debe someter a discución.
El proceso de Creación del Conocimiento, se lleva la información a un nuevo plano de discución y compartiendo el conocimiento personal que es conocimiento tácito, experiencias previas en conjunto con la nueva información esto se refiere a conocimiento explícito.
El preceso de Toma de Decisiones, se revisan las conclusiones anteriores para revisar sus ventajas y desventajas, pero estas decisiones estan limitadas por habilidades dentro del ambito.
Nonaka y Takeuchi (1995)
Existen dos tipos de conocimiento. Dadas sus características el conocimiento explícito se ha definido como el conocimiento objetivo y racional que puede ser expresado con palabras, números, fórmula, etc., también se le denomina explícito. Por otro lado tenemos el conocimiento tácito, que es aquel que una persona, comunidad, organización o país, tiene incorporado o almacenado en su mente, en su cultura y es difícil de explicar. Es necesario explicar que este conocimiento puede estar compuesto por:
- Ideas, experiencias, destrezas, habilidades, costumbres, valores, historia, creencias...
- Conocimiento del contexto o ecológico (geografía, física, normas no escritas, comportamientos de personas y objetos, etc.),
- Conocimiento como destreza cognitiva (compresión de la lectura, resolución de problemas, analizar, visualizar ideas, etc.) que le permite acceder a otro más complejo o resolver problemas nuevos.
Cuando estos conocimientos nos permiten actuar se llaman competencias o conocimiento en acción. El problema que presenta este tipo de conocimiento es su dificultad a la hora de transmitirlo, por ello es necesario gestionarlo creando códigos que faciliten su transmisión. [1]
Conocimiento Explícito
Este conocimiento se basa en el saber que que ha sido llamado proposicional, explicito, objetivo, teórico e impersonal, su enfasis en la estructura de la esperiencia por medio de conceptos, causas, efectos, razones y en leyes cientíificas universales, y sus resultados son las ideas y abstracciones, su caracteristica principal es su objetividad de alli que el ser humano puede comunicarlo para hacerlo saber estableciendo una red de ideas capaces de representarlo en un lenguaje (verbal, gráfico, modelodo, etc) obtenidas mediante métodos deductivos e inductivos de razonamiento.
Cuando se tiene el conocimiento de forma explicita la sociedad se beneficia de ello ya que es de facil acceso y comprención, esto impulsa el conocimiento transmitiendolo en diversos medios para una facíl comprensión de ellos.
Conocimiento Tácito
Este recide en la percepcion y comportaminetos de los seres humanos, permanece a un nivel “inconsiente”, se encuentra desarticulado y lo implementamos y ejecutamos de una manera mecanica sin darnos cuenta de su contenido, esto es que no se analiza lo sucedido, lo realiza de forma intuitiva sin buscar una explicación, y se vuelve conciente cuando el individuo lo analiza.
Al tratar de obtener el conocimiento tácito es una tarea dificil pues la mayoria de veces mediante acciones externas se puede lograr ya que es de estilo unico y muy dificil de igualar.
Este conocimiento constituye comunmente hábitos y aspectos culturales.
El Ciclo de Conversión del Conocimiento
La transmisión del conocimiento tácito no resulta fácil y para que pueda ser rentabilizado es necesario sustraerlo del contexto de origen y formalizarlo, con lo que se genera un "ciclo de conversión" que Nonaka y Takeuchi (1995) proponen estos procesos de creación de conocimiento para entender su naturaleza dinámica y lo describen en cuatro procesos:
1) De tácito a tácito: El paso de conocimiento de tácito a tácito se produce a través de procesos de socialización, es decir, a través de la adquisición de conocimientos e información mediante la interacción directa con el mundo exterior, esto es experiencias compartidaspor medios de expocisiones orales, documentos, con otras personas, con otras culturas, etc.
2) De tácito a explícito: Se produce a través de la externalización, que podríamos definir como el proceso de expresar algo de forma tangible, el diálogo. Externalizar es convertir imágenes y/o palabras a través del diálogo, permitiendo la comunicación.
3) De explícito a explícito: Este paso se denomina combinación. Como su propio nombre indica, se combinan diferentes formas de conocimiento explícito mediante documentos o bases de datos.
4) Tácito a tácito: es la Interiorización del conocimiento, y consiste en la incorporación del conocimiento tácito por parte de los individuos de cualquier organización en la forma de modelos mentales compartidos o practicas de trabajo.
La creación del conocimiento es un proceso contínuo de interacciones dinámicas entre el conocimiento tácito y el explícito. Los cuatro modos de la conversión del conocimiento interactúan en una espiral de creación del conocimiento. La espiral llega a tener una escala más grande cuando se eleva a través de los niveles de organización, y puede activar nuevos espirales de creación de conocimiento, mostrado en las figura 1.
Figura 1: Proceso de conversión del conocimiento en la organización (Nokata y Takeuchi, 1995)
Ventajas
• Aprecia la naturaleza dinámica del conocimiento y de la creación del conocimiento.
• Proporciona un marco para la gerencia de procesos relevantes.
Desventajas:
• Se basa en un estudio de las organizaciones japonesas, que confían fuertemente en el conocimiento tácito: los empleados están a menudo con una compañía para toda la vida.
• La linealidad del concepto: ¿puede el espiral saltar pasos? ¿Puede ir hacia la izquierda?
Conclusiones
El factor importante en la creación de conocimiento, siempre será el factor humano pues es aquel y solo a él le compete la analisis y comunicación, para asi crear nuevo conocimiento continuamente.
No se debe solo enfatizar que al utilizar una herramineta tecnologica o por medio de la evolución tecnologica, proveera los siguiente banco de conocimiento, esto es en nuestro entorno actual de la sociedad de conocimiento, pero si mediante este medio es mucho mas fácil y rápido la involucración de la comunidad en dar su analisis y desarrollar nuevos conocimientos.
Desde los inicios hasta la actualidad se ha buscado un esquema que determine la generación de conocimiento pero siempre dependera o estara limitado de las caracteristicas de los miembros de la comunidad que lo componen, ya que los mismos atraves del modelo de Nokata y Takeuchi (1995) de conversión del conocimiento es necesario llegar a tener una metodología de trasmitir el conocimiento de tácito a explicito ya que esta es la clave para potenciar el desarrollo de la sociedad.
Referencias Bibliográficas
[1] RED Científica, Ciencia Tecnología y Pensamiento, 11 de Agosto de 2008, http://www.redcientifica.com/doc/doc200405180600.html
Sánchez González, Cesar Augusto, 2005, Creacion de Conocimiento en las Organizaciones y las Tecnologias de Información como Herramienta para alcanzarlo, http://www.cibersociedad.net/archivo/articulo.php?art=211
Belly, Pablo, 2003, Niveles de Conocimiento, http://www.gestiopolis.com/canales/gerencial/articulos/59/niveles.htm
12MANAJE, The executive fast track, Modelo SECI, http://www.12manage.com/methods_nonaka_seci_es.html
Gestion del Conocimiento.com, Proceso de creación del conocimiento (Nonaka, Takeuchi, 1995), http://www.gestiondelconocimiento.com/modelo_nonaka.htm
El conocimiento se simenta como una capacidad humana unica, su transmisición implica un proceso intelectual de enseñanza y aprendizaje, en ello se puede establecer dos tipos que tienen una interacción intrínseca que es el conocimiento explícito y el conocimiento implícito (tácito). Ademas el conocimiento al no ser de carácter estático pues el conocimiento se genera continuamente por el uso de la capacidad de razonamiento o inferencia por tanto su valor se acrecenta y apoyado mediante los medios de distribución en el entorno actual, crece y crea nuevo conocimiento, por tanto la relación entre conocimiento tácito y explicito descrito en el proceso de creación del conocimiento (Nonaka, Takeuchi) muestra esta naturaleza dinamica y continua.
En el presente artículo presenta la interacción del conocimiento tácito y explicito para crear conocimiento, su fundamentación y las diversas fases de relacion de estas para su dinámica creativad.
Palabras Claves: Conocimiento implícito (tácito), Conocimiento explícito.
Introducción
Desde los inicios del la humanidad, el ser humano a buscado el conocimiento desde su adquisición y asi replicarla para de esta manera conservarla y enseñarla a su progenie, su ubicación geográfica en zonas que le permitierón su desarrollo en un menor tiempo y con un mayor volumen, dando el tiempo para alimentarse de información de valor emocional, de relación con su entorno, permitió la relación de abstracción o representatividad entre el signo y el hecho, estos estimulos generarón el desarrollo de la relación hombre/realidad, permitiendo así la evolución y sofisticación de este tipo de representación de signos abstractos. Observando este desarrollo continuo di pie a elementos de mediación interpretativa, acrecentando la capacidad humana de intervención de la realidad, es asi que se desarrollo nuevos medios tecnológicos y organizacionales.
Desde el punto filosófico, se establecido un diferenciación del conocimiento, el “saber que” que se conoce como conocimiento teórico y generalmente esta asociado con la mente, y el “saber como” que esta vinculado conmúnmente con lo corporeo y se lo conoce como conocimiento práctico.
En nuestro entorno, la creación del conocimiento se da dentro de las personas y situaciones entre ellas y su realidad, ademas con ayuda de los nuevos procesos tecnológicos de la información de manera importante integran el componente principal de la gestion del conocimiento.
El informe de la OCDE de 1996 subdivide al conocimiento en 4 tipos de saber:
1. Saber QUÉ: hechos y realidades, conocimineto cercano a la información.
2. Saber POR QUÉ: los principios y las leyes de la naturaleza, que se producen en los laboratorios y/o universidades.
3. Saber CÓMO: habilidades o capacidades para hacer algo.
4. Saber QUIÉN: supone saber quien sabe que y quien sabe como hacer qué.
Metodología para la Creación de conocimiento
Los procesos que debe seguir la información para transformarse en conocimiento son percepción, creación de conocimiento y toma de decisiones, y los mismos estan estrechamente relacionados, pues cada proceso lleva consigo una nueva generacón de conocimiento e información, de esta manera estos tres procesos se retroalimentan interactuan todos contra todos y no en un flujo lineal.
El proceso de Percepción, se interpreta la información que se generan en nuestro entorno o medio ambiente que desde luego sea relevante en un determinado ambito en el cual se requiere el conocimiento, el cual debe someter a discución.
El proceso de Creación del Conocimiento, se lleva la información a un nuevo plano de discución y compartiendo el conocimiento personal que es conocimiento tácito, experiencias previas en conjunto con la nueva información esto se refiere a conocimiento explícito.
El preceso de Toma de Decisiones, se revisan las conclusiones anteriores para revisar sus ventajas y desventajas, pero estas decisiones estan limitadas por habilidades dentro del ambito.
Nonaka y Takeuchi (1995)
Existen dos tipos de conocimiento. Dadas sus características el conocimiento explícito se ha definido como el conocimiento objetivo y racional que puede ser expresado con palabras, números, fórmula, etc., también se le denomina explícito. Por otro lado tenemos el conocimiento tácito, que es aquel que una persona, comunidad, organización o país, tiene incorporado o almacenado en su mente, en su cultura y es difícil de explicar. Es necesario explicar que este conocimiento puede estar compuesto por:
- Ideas, experiencias, destrezas, habilidades, costumbres, valores, historia, creencias...
- Conocimiento del contexto o ecológico (geografía, física, normas no escritas, comportamientos de personas y objetos, etc.),
- Conocimiento como destreza cognitiva (compresión de la lectura, resolución de problemas, analizar, visualizar ideas, etc.) que le permite acceder a otro más complejo o resolver problemas nuevos.
Cuando estos conocimientos nos permiten actuar se llaman competencias o conocimiento en acción. El problema que presenta este tipo de conocimiento es su dificultad a la hora de transmitirlo, por ello es necesario gestionarlo creando códigos que faciliten su transmisión. [1]
Conocimiento Explícito
Este conocimiento se basa en el saber que que ha sido llamado proposicional, explicito, objetivo, teórico e impersonal, su enfasis en la estructura de la esperiencia por medio de conceptos, causas, efectos, razones y en leyes cientíificas universales, y sus resultados son las ideas y abstracciones, su caracteristica principal es su objetividad de alli que el ser humano puede comunicarlo para hacerlo saber estableciendo una red de ideas capaces de representarlo en un lenguaje (verbal, gráfico, modelodo, etc) obtenidas mediante métodos deductivos e inductivos de razonamiento.
Cuando se tiene el conocimiento de forma explicita la sociedad se beneficia de ello ya que es de facil acceso y comprención, esto impulsa el conocimiento transmitiendolo en diversos medios para una facíl comprensión de ellos.
Conocimiento Tácito
Este recide en la percepcion y comportaminetos de los seres humanos, permanece a un nivel “inconsiente”, se encuentra desarticulado y lo implementamos y ejecutamos de una manera mecanica sin darnos cuenta de su contenido, esto es que no se analiza lo sucedido, lo realiza de forma intuitiva sin buscar una explicación, y se vuelve conciente cuando el individuo lo analiza.
Al tratar de obtener el conocimiento tácito es una tarea dificil pues la mayoria de veces mediante acciones externas se puede lograr ya que es de estilo unico y muy dificil de igualar.
Este conocimiento constituye comunmente hábitos y aspectos culturales.
El Ciclo de Conversión del Conocimiento
La transmisión del conocimiento tácito no resulta fácil y para que pueda ser rentabilizado es necesario sustraerlo del contexto de origen y formalizarlo, con lo que se genera un "ciclo de conversión" que Nonaka y Takeuchi (1995) proponen estos procesos de creación de conocimiento para entender su naturaleza dinámica y lo describen en cuatro procesos:
1) De tácito a tácito: El paso de conocimiento de tácito a tácito se produce a través de procesos de socialización, es decir, a través de la adquisición de conocimientos e información mediante la interacción directa con el mundo exterior, esto es experiencias compartidaspor medios de expocisiones orales, documentos, con otras personas, con otras culturas, etc.
2) De tácito a explícito: Se produce a través de la externalización, que podríamos definir como el proceso de expresar algo de forma tangible, el diálogo. Externalizar es convertir imágenes y/o palabras a través del diálogo, permitiendo la comunicación.
3) De explícito a explícito: Este paso se denomina combinación. Como su propio nombre indica, se combinan diferentes formas de conocimiento explícito mediante documentos o bases de datos.
4) Tácito a tácito: es la Interiorización del conocimiento, y consiste en la incorporación del conocimiento tácito por parte de los individuos de cualquier organización en la forma de modelos mentales compartidos o practicas de trabajo.
La creación del conocimiento es un proceso contínuo de interacciones dinámicas entre el conocimiento tácito y el explícito. Los cuatro modos de la conversión del conocimiento interactúan en una espiral de creación del conocimiento. La espiral llega a tener una escala más grande cuando se eleva a través de los niveles de organización, y puede activar nuevos espirales de creación de conocimiento, mostrado en las figura 1.
Figura 1: Proceso de conversión del conocimiento en la organización (Nokata y Takeuchi, 1995)
Ventajas
• Aprecia la naturaleza dinámica del conocimiento y de la creación del conocimiento.
• Proporciona un marco para la gerencia de procesos relevantes.
Desventajas:
• Se basa en un estudio de las organizaciones japonesas, que confían fuertemente en el conocimiento tácito: los empleados están a menudo con una compañía para toda la vida.
• La linealidad del concepto: ¿puede el espiral saltar pasos? ¿Puede ir hacia la izquierda?
Conclusiones
El factor importante en la creación de conocimiento, siempre será el factor humano pues es aquel y solo a él le compete la analisis y comunicación, para asi crear nuevo conocimiento continuamente.
No se debe solo enfatizar que al utilizar una herramineta tecnologica o por medio de la evolución tecnologica, proveera los siguiente banco de conocimiento, esto es en nuestro entorno actual de la sociedad de conocimiento, pero si mediante este medio es mucho mas fácil y rápido la involucración de la comunidad en dar su analisis y desarrollar nuevos conocimientos.
Desde los inicios hasta la actualidad se ha buscado un esquema que determine la generación de conocimiento pero siempre dependera o estara limitado de las caracteristicas de los miembros de la comunidad que lo componen, ya que los mismos atraves del modelo de Nokata y Takeuchi (1995) de conversión del conocimiento es necesario llegar a tener una metodología de trasmitir el conocimiento de tácito a explicito ya que esta es la clave para potenciar el desarrollo de la sociedad.
Referencias Bibliográficas
[1] RED Científica, Ciencia Tecnología y Pensamiento, 11 de Agosto de 2008, http://www.redcientifica.com/doc/doc200405180600.html
Sánchez González, Cesar Augusto, 2005, Creacion de Conocimiento en las Organizaciones y las Tecnologias de Información como Herramienta para alcanzarlo, http://www.cibersociedad.net/archivo/articulo.php?art=211
Belly, Pablo, 2003, Niveles de Conocimiento, http://www.gestiopolis.com/canales/gerencial/articulos/59/niveles.htm
12MANAJE, The executive fast track, Modelo SECI, http://www.12manage.com/methods_nonaka_seci_es.html
Gestion del Conocimiento.com, Proceso de creación del conocimiento (Nonaka, Takeuchi, 1995), http://www.gestiondelconocimiento.com/modelo_nonaka.htm
sábado, 9 de agosto de 2008
herramienta de microbloggin- Plurk
El plurk, es una herramienta entretenida y muy dinámica, permite el seguimineto en una pantalla que al parecer se adapta a los usuarios y muy amigable, pero cuando hay muchos plurs de contestacion es un poco tedioso, y permite un seguimiento por tiempo y de forma ordenada, y como una herramienta social permite un flujo de información muy interesante. Es una herramienta mucho mas atractiva que el Twitter.
Mi link a mi plurk: http://www.plurk.com/user/SagFenix
Mi link a mi plurk: http://www.plurk.com/user/SagFenix
jueves, 17 de julio de 2008
नुएवा Patria
“La Patria ya es de todos”?? Seguro que de todos? Los asambleístas aprobaron un articulo con el cual prácticamente se legaliza el aborto… osea que no hay Patria para aquellos que están en el vientre de sus madres… porque el estado no garantiza la vida sino hasta después del nacimiento… esa es la Patria que queremos? Mientras unas piden ser complacidas sexualmente un bebe NO PUEDE exigir LA VIDA?
Con un mensaje no se logra mucho pero quizás sirva para que todos se den cuenta
Con un mensaje no se logra mucho pero quizás sirva para que todos se den cuenta
Estimación para de Software
Fundamentos de Ingeniería de Software
Informe Ejecutivo
Stalin Rojas Morocho
Estimación para de Software
1 Introducción
El gestor de proyectos y el equipo del software deben estimar el trabajo que se realizará, luego de realizarce estas actividades, el equipo de software debe establecer un plan del proyecto que se defina las tareas y fechas claves de la ingeniería del software.
Estas estimaciones se basab en datos de las métricas de software recopiladas en proyectos previos.
La descripción del ámbito del producto da pie inicio, la complegidad y el riesgo del problema se consideran antes de realizar una estimación final, es difícil asegurar si la estimación a sido correcta, pero se puede llegar a cierto nivel de eficacia se se tiene experiencia y se sigue un enfoque sistemático, que las estimaciones se basen en datos históricos sólidos.
2 Desarrollo del tema
2.1 Observación acerca de la estimación
La estimación de recursos, costo y programa de trabajo para una tarea de ingeniería de software requiere experiencia, acceso a buena información histórica y el valos para comprometerse con predicciones cuantitativas cuando la información cualitativa es todo lo que existe. La estimación implica riesgo inherente, y esto conduce a la incertidumbre.
El riesgo de estimación se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidad para recursos, costos y programa de trabajo, además el cliente debe reconocer que la variabilidad en los requisitos del software significa inestabilidad e costs y programa de trabajo.
Las estimaciones no deben obsecionarse en el plano de planificación, pues un cambio el gestor del proyecto debería reexaminar las estimaciones.
2.2 El proceso de planificación del proyectos
El objetiv de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor estimar recursos, costos y programa de trabajo.
2.3 Ámbito del Software y factibilidad
El ámbito del software describe las funciones y características que se entregarán a los usuarios finales, se define al usar las dos técnicas:
• Despues de la comunicación con todos los participantes se desarrolla una descropción narrativa del ámbito del software.
• Los usuarios finales desarrollan un conjunto de casos de uso.
2.4 Resursos
Los recursos son discutiblemente los pilares dentro del desarrollo del software, estos son: personal, componentes de software y entorno de desarrollo (Hardware y herramientas de desarrollo), se caracteriza el recurso por descripción, informe de disponibilidad, urgencia del recurso, tiempo de uso.
Recurso humano se describe como las personas involucradas en el desarrollo del proyecto, en proyectos pequeños se usa una persona, pero en el caso contrario de debe describir la ubicación de cada recurso humano, los mismos que serán requeridos dependiendo de las habilidades y el ámbito del producto, y su numero es determinado después de la estimación.
Recursos de Software reutilizables se enfocan en que se deben catalogarse, estandarizarse, y validarse, debido a su reutilización inherente, pero se debe evaluar los requerimientos para optar por las diversas alternativas de componentes existentes o realizar su creación.
Bennatan categoriza el recurso en:
• Componentes ya desarrollados, provienen de terceros o producidos previamente, sin riesgo.
• Componentes experimentados, desarrollados en proyectos previos, los miembros del equipo tienen la experiencia en la aplicación y modificaran los componentes requeridos, bajo riesgo.
• Componentes de experiencia parcial, proviene de previos desarrollos, pero el equipo es parcialmente experimentado en la aplicación y los componentes deben ser modificados sustancialmente, riesgo alto.
• Componentes nuevos, se debe construir basado en la especificaciones del proyecto actual.
Recursos del entorno llamado también entorno de ingeniería de software (EIS), es en el cual se incorpora hardware y software indispensable para el desarrollo del proyecto, por esta razón se debe planificar la disponibilidad de los mismos.
2.5 Estimación de proyectos de software
La estimación del coste y el esfuerzo nunca será una ciencia exacta, debido a demasiadas variables que afectan el costo final y el esfuerzo al desarrollarlo, para ello se define una estimación con riesgo aceptable, y se tiene 4 opciones:
• Demorar la estimación en el proyecto hasta tener cierta aceptación, no es practica.
• Basar estimaciones de proyectos similares.
• Emplear técnicas de descomposición relativamente simples.
• Usar modelos empíricos.
2.6 Técnicas de descomposición
Tamaño del software, la presión de la estimación en este aspecto se manifiesta en varios factores: 1) grado de estimación del tamaño del producto. 2) habilidad de emplear la estimación manifestándola en esfuerzo humano, programa de trabajo y dinero. 3) grado de habilidad del equipo de software dentro del proyecto, y 4) la estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo de ingeniería de software.
Dependiendo del enfoque de representación del tamaño tenemos, el directo que se puede medir en líneas de código (LDC), y si es indirecto, como puntos de función (PF).
Putnam y Myers, sugieren con respecto al enfoque:
• Tamaño de “lógica difusa”, identificación de tipo de aplicación, magnitud en la escala cualitativa y refine la magnitud dentro del rango original.
• Tamaño de punto de función, estimación de las características del dominio.
• Tamaño de componentes estándar, estimar las ocurrencias de cada componente estándar y contrastar con datos previos de similares componentes estándar definiendo el tamaño.
• Tamaño del cambio, cuando se reutiliza componentes de previos proyectos se estima el número y tipo de las modificaciones a realizar.
Estimaciones basadas en el problema, las LDC y PF son utilizados de dos formas al estimar el proyecto: como una variable de estimación para el tamaño de cada elemento de software y como métricas de línea base recolectadas a partir de proyectos previos y utilizados en conjunción con variables de estimación para desarrollar proyecciones de costo y esfuerzo.
Se puede dividir el problema para estimar las diversas partes del proyecto de una mejor forma.
Estimación basada en el proceso, se descompone el proceso en un conjunto relativamente pequeño de tareas y se estima el esfuerzo para cada tarea, parte del bosquejo de funcionalidades a partir del ámbito del proyecto, estas se contraponen con las actividades del proceso.
Estimación con casos de uso, tiene sus complicaciones:
Los casos de uso tienen muchos formatos y estilos.
• Representan la visión externa y difieren en sus grados de abstracción.
• No reflejan la complejidad de las funciones ni sus características.
• No describen el comportamiento complejo de funciones y características.
2.7 Modelos Empíricos de estimación
La estructura global de tales modelos toma la forma:
E=A+B*(e_{y})^{c}
El modelo COCOMO II
Abordan las áreas siguientes:
Modelo de composición de la aplicación.
Modelo de etapas de diseño temprano.
Además, hay disponibles tres opciones diferentes de tamaño: puntos objeto, puntos de función y líneas de código.
2.8 La decisión desarrollar-comprar
Los gestores de ingeniería del software enfrentan una decisión de desarrollar-comprar, se puede complicar por su licencia, experiencia en el campo de aplicación sea parcial o completa, o se puede construir de forma personalizada, todo esta decisión está en torno de los análisis de costos para un mejor desenvolvimiento de los desarrolladores
Informe Ejecutivo
Stalin Rojas Morocho
Estimación para de Software
1 Introducción
El gestor de proyectos y el equipo del software deben estimar el trabajo que se realizará, luego de realizarce estas actividades, el equipo de software debe establecer un plan del proyecto que se defina las tareas y fechas claves de la ingeniería del software.
Estas estimaciones se basab en datos de las métricas de software recopiladas en proyectos previos.
La descripción del ámbito del producto da pie inicio, la complegidad y el riesgo del problema se consideran antes de realizar una estimación final, es difícil asegurar si la estimación a sido correcta, pero se puede llegar a cierto nivel de eficacia se se tiene experiencia y se sigue un enfoque sistemático, que las estimaciones se basen en datos históricos sólidos.
2 Desarrollo del tema
2.1 Observación acerca de la estimación
La estimación de recursos, costo y programa de trabajo para una tarea de ingeniería de software requiere experiencia, acceso a buena información histórica y el valos para comprometerse con predicciones cuantitativas cuando la información cualitativa es todo lo que existe. La estimación implica riesgo inherente, y esto conduce a la incertidumbre.
El riesgo de estimación se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidad para recursos, costos y programa de trabajo, además el cliente debe reconocer que la variabilidad en los requisitos del software significa inestabilidad e costs y programa de trabajo.
Las estimaciones no deben obsecionarse en el plano de planificación, pues un cambio el gestor del proyecto debería reexaminar las estimaciones.
2.2 El proceso de planificación del proyectos
El objetiv de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor estimar recursos, costos y programa de trabajo.
2.3 Ámbito del Software y factibilidad
El ámbito del software describe las funciones y características que se entregarán a los usuarios finales, se define al usar las dos técnicas:
• Despues de la comunicación con todos los participantes se desarrolla una descropción narrativa del ámbito del software.
• Los usuarios finales desarrollan un conjunto de casos de uso.
2.4 Resursos
Los recursos son discutiblemente los pilares dentro del desarrollo del software, estos son: personal, componentes de software y entorno de desarrollo (Hardware y herramientas de desarrollo), se caracteriza el recurso por descripción, informe de disponibilidad, urgencia del recurso, tiempo de uso.
Recurso humano se describe como las personas involucradas en el desarrollo del proyecto, en proyectos pequeños se usa una persona, pero en el caso contrario de debe describir la ubicación de cada recurso humano, los mismos que serán requeridos dependiendo de las habilidades y el ámbito del producto, y su numero es determinado después de la estimación.
Recursos de Software reutilizables se enfocan en que se deben catalogarse, estandarizarse, y validarse, debido a su reutilización inherente, pero se debe evaluar los requerimientos para optar por las diversas alternativas de componentes existentes o realizar su creación.
Bennatan categoriza el recurso en:
• Componentes ya desarrollados, provienen de terceros o producidos previamente, sin riesgo.
• Componentes experimentados, desarrollados en proyectos previos, los miembros del equipo tienen la experiencia en la aplicación y modificaran los componentes requeridos, bajo riesgo.
• Componentes de experiencia parcial, proviene de previos desarrollos, pero el equipo es parcialmente experimentado en la aplicación y los componentes deben ser modificados sustancialmente, riesgo alto.
• Componentes nuevos, se debe construir basado en la especificaciones del proyecto actual.
Recursos del entorno llamado también entorno de ingeniería de software (EIS), es en el cual se incorpora hardware y software indispensable para el desarrollo del proyecto, por esta razón se debe planificar la disponibilidad de los mismos.
2.5 Estimación de proyectos de software
La estimación del coste y el esfuerzo nunca será una ciencia exacta, debido a demasiadas variables que afectan el costo final y el esfuerzo al desarrollarlo, para ello se define una estimación con riesgo aceptable, y se tiene 4 opciones:
• Demorar la estimación en el proyecto hasta tener cierta aceptación, no es practica.
• Basar estimaciones de proyectos similares.
• Emplear técnicas de descomposición relativamente simples.
• Usar modelos empíricos.
2.6 Técnicas de descomposición
Tamaño del software, la presión de la estimación en este aspecto se manifiesta en varios factores: 1) grado de estimación del tamaño del producto. 2) habilidad de emplear la estimación manifestándola en esfuerzo humano, programa de trabajo y dinero. 3) grado de habilidad del equipo de software dentro del proyecto, y 4) la estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo de ingeniería de software.
Dependiendo del enfoque de representación del tamaño tenemos, el directo que se puede medir en líneas de código (LDC), y si es indirecto, como puntos de función (PF).
Putnam y Myers, sugieren con respecto al enfoque:
• Tamaño de “lógica difusa”, identificación de tipo de aplicación, magnitud en la escala cualitativa y refine la magnitud dentro del rango original.
• Tamaño de punto de función, estimación de las características del dominio.
• Tamaño de componentes estándar, estimar las ocurrencias de cada componente estándar y contrastar con datos previos de similares componentes estándar definiendo el tamaño.
• Tamaño del cambio, cuando se reutiliza componentes de previos proyectos se estima el número y tipo de las modificaciones a realizar.
Estimaciones basadas en el problema, las LDC y PF son utilizados de dos formas al estimar el proyecto: como una variable de estimación para el tamaño de cada elemento de software y como métricas de línea base recolectadas a partir de proyectos previos y utilizados en conjunción con variables de estimación para desarrollar proyecciones de costo y esfuerzo.
Se puede dividir el problema para estimar las diversas partes del proyecto de una mejor forma.
Estimación basada en el proceso, se descompone el proceso en un conjunto relativamente pequeño de tareas y se estima el esfuerzo para cada tarea, parte del bosquejo de funcionalidades a partir del ámbito del proyecto, estas se contraponen con las actividades del proceso.
Estimación con casos de uso, tiene sus complicaciones:
Los casos de uso tienen muchos formatos y estilos.
• Representan la visión externa y difieren en sus grados de abstracción.
• No reflejan la complejidad de las funciones ni sus características.
• No describen el comportamiento complejo de funciones y características.
2.7 Modelos Empíricos de estimación
La estructura global de tales modelos toma la forma:
E=A+B*(e_{y})^{c}
El modelo COCOMO II
Abordan las áreas siguientes:
Modelo de composición de la aplicación.
Modelo de etapas de diseño temprano.
Además, hay disponibles tres opciones diferentes de tamaño: puntos objeto, puntos de función y líneas de código.
2.8 La decisión desarrollar-comprar
Los gestores de ingeniería del software enfrentan una decisión de desarrollar-comprar, se puede complicar por su licencia, experiencia en el campo de aplicación sea parcial o completa, o se puede construir de forma personalizada, todo esta decisión está en torno de los análisis de costos para un mejor desenvolvimiento de los desarrolladores
domingo, 20 de abril de 2008
Conceptos de Gestión de Proyectos
Fundamentos Ingeniería del Software
Informe Ejecutivo
Stalin Rojas Morocho
Conceptos de Gestión de Proyectos (Ingeniería del Software Enfoque Practico)
Introducción
La gestión de Software siendo una disciplina de administración para una mejor guía en la creación de Software se realizara un determinado número de actividades para poder alcanzar los objetivos planteados, además de los recursos para que este se empleara como es el personal, tiempo, costo presupuestado, tecnología; todo esto se conjugara para obtener un producto de software pero las diversas acciones sin una medida de organización se convertiría en un caos.
La iniciación a un proyecto de software se podría iniciar con las preguntas de ¿Cuánto tiempo nos tomará? ¿Cuántos participarán? ¿Qué actividades se realizarán? ¿Qué producto se obtendrá?, al contestar estas preguntas nos dará un escenario preliminar y basado en las personas, procesos, proyecto y producto, son pilares relevantes en la gestión y esenciales en el proceso de planeamiento.
Desarrollo del tema
El Personal, siendo el primer pilar comprendido en la gestión de proyectos, es importante tener en cuenta la idoneidad de las personas para desempeñar un rol, en correspondencia con su conocimiento, habilidad y destreza las cuales garantiza la eficiencia. No se debe tener solo en cuenta los aspectos técnicos sino también los elementos culturales y conductuales que permita el acoplamiento entre los miembros del equipo.
Los participantes se clasifican en:
1. Gestores ejecutivos, define aspectos del negocio.
2. Gestores de Proyecto, Planifican, motivan, organizan, y controlan a los profesionales.
3. Profesionales, Poseen habilidades técnicas para la realización de la aplicación.
4. Clientes.- especifican los requerimientos para la aplicación.
5. Usuarios finales.- Interactúan con el software.
Los lideres de equipo, planteado por el modelo de liderazgo MOI (Motivación, organización e innovación), nos permite un entorno de responsabilidad con capacidad individual pero con una visión común del problema evitando el forzar restricciones a los miembros del equipo a sus aportaciones y respetando sus ideas y comentarios; en este permite a los miembros del proyecto involucrarse, participar y ser autónomos en sus decisiones pues se confía en ellos; dentro de la organización nos aporta una canalización de todo tipo de aportaciones y fluidez de información sin caer en la frustración que llegaríamos sin la organización; obtener la innovación o ideas dentro de un ambiente generoso, abierto y respetuoso es donde emergen las ideas para ser escuchadas y mejoradas las cuales resolverán los obstáculos de manera estructurada manteniendo la flexibilidad de su resolución, la responsabilidad principal del jefe de proyecto es asegurar que el producto cumpla los requisitos, su tarea es clarificar los objetivos del proyecto, especificándolos en términos cuantificables.
Estructura de Equipo de Software, depende del estilo de gestión, miembros de equipo, habilidad de participantes (técnicas, comunicativas, personales y aspectos culturales), ámbito del problema, estas estructuras se adaptan a estos aspectos son:
o Organigrama Centralizado Controlado, y paradigma cerrado, el jefe coordina tareas, comunicación vertical, actúan mejor si el proyecto es similar a anteriores.
o Organigrama Descentralizado Democrático, coordinadores diferentes para tareas diferentes, decisión por consenso en el grupo, comunicación horizontal.
o Organigrama Descentralizado Controlado, y paradigma abierto, jefe de equipo coordina tareas y subjefes de tareas, decisiones por consenso en el grupo, comunicación horizontal y vertical.
o Paradigma aleatorio, caracterizada por libertad, iniciativa, poco rendimiento de forma organizada.
o Paradigma sincronizado, caracterizado por intervención conjunta dentro del problema y equipo, poca comunicación.
Para mejorar la comunicación se debería establecer mecanismos formales e informales, como reuniones, entregables, registros utilizando las herramientas disponibles.
El Producto, al definir el proyecto se establece las diferentes estimaciones, que servirán para gestionar el proyecto, lo principal dentro de está definición serán las aspectos como el ámbito que describirá que cantidad de información será manejada y sus respectivas restricciones, definir los objetivos y su alcance pues identificará datos primarios, funciones y comportamientos que caracterizan el producto, de una forma cuantitativa permitiéndonos saber el desempeño en el transcurrir del proyecto pues puede cambiar en su desarrollo. Como mejor táctica se divide o se descompone, para un mejor despliegue de actividades identificando los requisitos primordiales.
El Proceso, el gestor del proyecto decide el modelo adecuado para su desarrollo, definiendo un plan preliminar y sus respectivos planes genéricos futuros y descomposición de los procesos, dentro de plan definido debe esté estar fundamentado bajo los requerimientos esenciales, consistentes y sólidos requeridos por las características del producto a desarrollar. Esté plan debidamente detallado proporcionara una estructura de actividades dependiendo del tamaño y complejidad permitiendo adaptarse a la gestión de cambio en el transcurso del desarrollo, esto se basa siempre y cuando desde sus inicios el modelo escogido proporcione las base estructurales suficientes para llevar su respectivo control, para apoyo de esta descripción presenta la creación de una matriz que percibirá las tareas o actividades a desarrollar y la cronología que esto se cumplirá. La posible estructura genérica aplicada se conformará de: comunicación con el cliente, planificación, análisis de riesgos, ingeniería, construcción y entrega, evaluación de cliente.
El Proyecto, se debe realizar un análisis minucioso del proyecto, pues este definirá las bases importantes, se debe tener mayor énfasis en entender de que ámbito y el alcance de esté, sus objetivos es decir el contesto del problema, y este debe ser de conocimiento de todos los participantes y establecer una base de que todos los que intervienen estén de acuerdo y no existan dudas, una mejor aplicación de este aspecto es la aplicación de la regla 90-90, que consiste en que el primer 90% de un sistema absorbe el 90% del esfuerzo y tiempo invertido, el ultimo 10% se lleva otro 90% del esfuerzo y tiempo asignado; el impulso desde su inicio debe ser el mismo con el que llegue a su termino el proyecto pues es desfavorecido por obstáculos de carácter técnicos, personales, culturales; el monitoreo es esencial dentro de la vida de desarrollo de software este actividad nos permitirá el mejoramiento del control de calidad, este tipo de actividades no solo debe estar dentro del desarrollo sino cuando se ha terminado esta tarea para tener una información tangible que sirve de comparación histórica para una mejor estimación de otros proyectos similares o para establecer una referencia en un nuevo proyecto.
Conclusiones
Los componentes dentro de una gestión de software están debidamente definidos, y es factible su debida identificación, permitiendo su íntegro gestionamiento.
Las especificaciones respectivas dentro de ámbito del proyecto serán entendidas de carácter asequible, cuantificable con una duración comprendida en la vida del proyecto bien especificada.
Se debe identificar las responsabilidades del equipo de desarrollo para desenvolver el rol respectivo, y así identificar cualquier desviación de actividades no correspondidas.
La especificación de estos conceptos primordiales dentro de la gestión de software es que se identificara una parte estructural que se identifica los relevantes métodos, estructuras organizacionales y procedimientos que integran la gestión y la parte cambiante de que es impredecible que es la personas que depende de sus conjunto de actitudes y características el acoplamiento dentro de un proyecto, las cuales rigen el desenvolvimiento de la resolución de proyecto y llegar a su culminación, esto es iniciando con el cliente proporcionando la información, la inteligencia de los miembros de equipo de resolución del problema, y con énfasis en el líder de gestión, estas decisiones proveerán el escenario de integración con la parte estructural.
Bibliografía
PIATTINI VELTHUIS, Mario G., CALVO-MANZANO VILLALÓN, José Antonio, CERVERA BRAVO, Joaquín FERNÁNDEZ SANZ Luís. Análisis y diseño detallado de Aplicaciones Informáticas de Gestión (Primera Edición)
PRESSMAN, Roger S. Ingeniería del Software Un enfoque práctico (Sexta Edición)
PEREZ, Margarita Cecilia de la Cruz. Procedimiento para la conformación de Equipos de Desarrollo de Software (On line). Feb. 2008 (citado 30 mar. 2008) www.ilustrados.com/Procedimiento-desarrollo-de-software.pdf
COLTELL, Óscar. El Proyecto Informatico (On line). 2003 (citado 30 mar. 2008) www3.uji.es/~coltell/Docs/IngSw_Apuntes/ISW_2004_TC04.pdf
JIMENEZ GARZON, Darwin. Gestión de Proyectos de Software (On line). 24 oct. 2007 (citado 30 mar. 2008) ingenieriadjg.blogspot.com/
members.fortunecity.es/analisissw/trabajo_01_parte_1.htm
GRACIA, Joaquin. Liderazgo técnico MOI - Motivación, Organización e Innovación (On line). 15 jun. 2005 (citado 30 mar. 2008) www.ingenierosoftware.com/equipos/motivacion-organizacion-innovacion.php
Informe Ejecutivo
Stalin Rojas Morocho
Conceptos de Gestión de Proyectos (Ingeniería del Software Enfoque Practico)
Introducción
La gestión de Software siendo una disciplina de administración para una mejor guía en la creación de Software se realizara un determinado número de actividades para poder alcanzar los objetivos planteados, además de los recursos para que este se empleara como es el personal, tiempo, costo presupuestado, tecnología; todo esto se conjugara para obtener un producto de software pero las diversas acciones sin una medida de organización se convertiría en un caos.
La iniciación a un proyecto de software se podría iniciar con las preguntas de ¿Cuánto tiempo nos tomará? ¿Cuántos participarán? ¿Qué actividades se realizarán? ¿Qué producto se obtendrá?, al contestar estas preguntas nos dará un escenario preliminar y basado en las personas, procesos, proyecto y producto, son pilares relevantes en la gestión y esenciales en el proceso de planeamiento.
Desarrollo del tema
El Personal, siendo el primer pilar comprendido en la gestión de proyectos, es importante tener en cuenta la idoneidad de las personas para desempeñar un rol, en correspondencia con su conocimiento, habilidad y destreza las cuales garantiza la eficiencia. No se debe tener solo en cuenta los aspectos técnicos sino también los elementos culturales y conductuales que permita el acoplamiento entre los miembros del equipo.
Los participantes se clasifican en:
1. Gestores ejecutivos, define aspectos del negocio.
2. Gestores de Proyecto, Planifican, motivan, organizan, y controlan a los profesionales.
3. Profesionales, Poseen habilidades técnicas para la realización de la aplicación.
4. Clientes.- especifican los requerimientos para la aplicación.
5. Usuarios finales.- Interactúan con el software.
Los lideres de equipo, planteado por el modelo de liderazgo MOI (Motivación, organización e innovación), nos permite un entorno de responsabilidad con capacidad individual pero con una visión común del problema evitando el forzar restricciones a los miembros del equipo a sus aportaciones y respetando sus ideas y comentarios; en este permite a los miembros del proyecto involucrarse, participar y ser autónomos en sus decisiones pues se confía en ellos; dentro de la organización nos aporta una canalización de todo tipo de aportaciones y fluidez de información sin caer en la frustración que llegaríamos sin la organización; obtener la innovación o ideas dentro de un ambiente generoso, abierto y respetuoso es donde emergen las ideas para ser escuchadas y mejoradas las cuales resolverán los obstáculos de manera estructurada manteniendo la flexibilidad de su resolución, la responsabilidad principal del jefe de proyecto es asegurar que el producto cumpla los requisitos, su tarea es clarificar los objetivos del proyecto, especificándolos en términos cuantificables.
Estructura de Equipo de Software, depende del estilo de gestión, miembros de equipo, habilidad de participantes (técnicas, comunicativas, personales y aspectos culturales), ámbito del problema, estas estructuras se adaptan a estos aspectos son:
o Organigrama Centralizado Controlado, y paradigma cerrado, el jefe coordina tareas, comunicación vertical, actúan mejor si el proyecto es similar a anteriores.
o Organigrama Descentralizado Democrático, coordinadores diferentes para tareas diferentes, decisión por consenso en el grupo, comunicación horizontal.
o Organigrama Descentralizado Controlado, y paradigma abierto, jefe de equipo coordina tareas y subjefes de tareas, decisiones por consenso en el grupo, comunicación horizontal y vertical.
o Paradigma aleatorio, caracterizada por libertad, iniciativa, poco rendimiento de forma organizada.
o Paradigma sincronizado, caracterizado por intervención conjunta dentro del problema y equipo, poca comunicación.
Para mejorar la comunicación se debería establecer mecanismos formales e informales, como reuniones, entregables, registros utilizando las herramientas disponibles.
El Producto, al definir el proyecto se establece las diferentes estimaciones, que servirán para gestionar el proyecto, lo principal dentro de está definición serán las aspectos como el ámbito que describirá que cantidad de información será manejada y sus respectivas restricciones, definir los objetivos y su alcance pues identificará datos primarios, funciones y comportamientos que caracterizan el producto, de una forma cuantitativa permitiéndonos saber el desempeño en el transcurrir del proyecto pues puede cambiar en su desarrollo. Como mejor táctica se divide o se descompone, para un mejor despliegue de actividades identificando los requisitos primordiales.
El Proceso, el gestor del proyecto decide el modelo adecuado para su desarrollo, definiendo un plan preliminar y sus respectivos planes genéricos futuros y descomposición de los procesos, dentro de plan definido debe esté estar fundamentado bajo los requerimientos esenciales, consistentes y sólidos requeridos por las características del producto a desarrollar. Esté plan debidamente detallado proporcionara una estructura de actividades dependiendo del tamaño y complejidad permitiendo adaptarse a la gestión de cambio en el transcurso del desarrollo, esto se basa siempre y cuando desde sus inicios el modelo escogido proporcione las base estructurales suficientes para llevar su respectivo control, para apoyo de esta descripción presenta la creación de una matriz que percibirá las tareas o actividades a desarrollar y la cronología que esto se cumplirá. La posible estructura genérica aplicada se conformará de: comunicación con el cliente, planificación, análisis de riesgos, ingeniería, construcción y entrega, evaluación de cliente.
El Proyecto, se debe realizar un análisis minucioso del proyecto, pues este definirá las bases importantes, se debe tener mayor énfasis en entender de que ámbito y el alcance de esté, sus objetivos es decir el contesto del problema, y este debe ser de conocimiento de todos los participantes y establecer una base de que todos los que intervienen estén de acuerdo y no existan dudas, una mejor aplicación de este aspecto es la aplicación de la regla 90-90, que consiste en que el primer 90% de un sistema absorbe el 90% del esfuerzo y tiempo invertido, el ultimo 10% se lleva otro 90% del esfuerzo y tiempo asignado; el impulso desde su inicio debe ser el mismo con el que llegue a su termino el proyecto pues es desfavorecido por obstáculos de carácter técnicos, personales, culturales; el monitoreo es esencial dentro de la vida de desarrollo de software este actividad nos permitirá el mejoramiento del control de calidad, este tipo de actividades no solo debe estar dentro del desarrollo sino cuando se ha terminado esta tarea para tener una información tangible que sirve de comparación histórica para una mejor estimación de otros proyectos similares o para establecer una referencia en un nuevo proyecto.
Conclusiones
Los componentes dentro de una gestión de software están debidamente definidos, y es factible su debida identificación, permitiendo su íntegro gestionamiento.
Las especificaciones respectivas dentro de ámbito del proyecto serán entendidas de carácter asequible, cuantificable con una duración comprendida en la vida del proyecto bien especificada.
Se debe identificar las responsabilidades del equipo de desarrollo para desenvolver el rol respectivo, y así identificar cualquier desviación de actividades no correspondidas.
La especificación de estos conceptos primordiales dentro de la gestión de software es que se identificara una parte estructural que se identifica los relevantes métodos, estructuras organizacionales y procedimientos que integran la gestión y la parte cambiante de que es impredecible que es la personas que depende de sus conjunto de actitudes y características el acoplamiento dentro de un proyecto, las cuales rigen el desenvolvimiento de la resolución de proyecto y llegar a su culminación, esto es iniciando con el cliente proporcionando la información, la inteligencia de los miembros de equipo de resolución del problema, y con énfasis en el líder de gestión, estas decisiones proveerán el escenario de integración con la parte estructural.
Bibliografía
PIATTINI VELTHUIS, Mario G., CALVO-MANZANO VILLALÓN, José Antonio, CERVERA BRAVO, Joaquín FERNÁNDEZ SANZ Luís. Análisis y diseño detallado de Aplicaciones Informáticas de Gestión (Primera Edición)
PRESSMAN, Roger S. Ingeniería del Software Un enfoque práctico (Sexta Edición)
PEREZ, Margarita Cecilia de la Cruz. Procedimiento para la conformación de Equipos de Desarrollo de Software (On line). Feb. 2008 (citado 30 mar. 2008) www.ilustrados.com/Procedimiento-desarrollo-de-software.pdf
COLTELL, Óscar. El Proyecto Informatico (On line). 2003 (citado 30 mar. 2008) www3.uji.es/~coltell/Docs/IngSw_Apuntes/ISW_2004_TC04.pdf
JIMENEZ GARZON, Darwin. Gestión de Proyectos de Software (On line). 24 oct. 2007 (citado 30 mar. 2008) ingenieriadjg.blogspot.com/
members.fortunecity.es/analisissw/trabajo_01_parte_1.htm
GRACIA, Joaquin. Liderazgo técnico MOI - Motivación, Organización e Innovación (On line). 15 jun. 2005 (citado 30 mar. 2008) www.ingenierosoftware.com/equipos/motivacion-organizacion-innovacion.php
sábado, 19 de abril de 2008
BiteFight
http://s7.bitefight.es/c.php?uid=130878
Link para caza de mi vampiro o si quierres ser mordido para comvertirte dentro den juego BiteFight game Online
Link para caza de mi vampiro o si quierres ser mordido para comvertirte dentro den juego BiteFight game Online
Suscribirse a:
Entradas (Atom)
