domingo, 3 de marzo de 2013
miércoles, 27 de febrero de 2013
domingo, 24 de febrero de 2013
GESTION DE PROCESOS parte 3
Segun mi bibliografia:
Para determinar si una actividad realizada por una organización es un proceso o subproceso, debe cumplir los siguientes criterios:
Una de mis mayores era, porque tantas definiciones, porque tantas recetas. A veces, por lo menos para mi, es mas facil aprenderse una pregunta que toda la respuesta. A veces una pregunta bien hecha te permite reproducir nuevamente toda una larga respuesta. En mi caso que lei por primera vez las preguntas que vinieron a mi cabeza fueron.
¿Que es lo que no es una actividad? ¿Porque toda esta receta? Pues a mi forma de ver, todo era una actividad de alguna manera. Y la receta que tenemos anteriormente, debe salir de algun lado. Luego de esas preguntas las respuestas me empiezan a salir. Una de los principales objetivos de esta asignatura es tener una organizacion y clasificacion clara de las cosas. Los cuatro ultimos puntos, tienen que ver con eso. El primer punto era el que mayor confusion me hacia. Que es la tarea que no tiene objetivo claro? Bueno al parecer, las Tareas. Lo que se quiere decir, en esa lista, es que para que una tarea sea un proceso, tiene que tener un unico objetivo. Tiene que estar direccionado hacia un lado. No importa si es muy grande o muy pequeño, el objetivo es que si una tarea tenga varias subtareas esta tenga un solo objetivo y no varios. Un ejemplo sencillo de una actividad que puede ser una tarea.
Tarea (o Actividad):
Cojer un plato sucio, ponerlo en el lavaplatos, encender el lavaplatos.
La tarea tiene un objetivo claro. Lavar el plato. Lo que se desea siempre, es que ese conjunto de tareas siempre sean para un mismo fin. Que al final, al parecer, siempre se puede conseguir una tarea mas global que cubre todos esos subprocesos. Por ejemplo, una actividad que aparentemente no tiene objetivo o mision.
Tarea:
Cojer un plato sucio, cojer ropa sucia, poner en el lavaplatos el plato sucio, poner en la lavadora la ropa sucia, encender el lavaplatos, encender la lavadora.
¿Tiene una mision clara la actividad? Al parecer no, porque ¿es lavar los platos o lavar la ropa?
Sin embargo, un lector podria decir, que el objetivo es Limpiar o Lavar. Y la respuesta estaria correcta. Pero la idea entonces quedaria de otra manera.
La activdad que se considere proceso, es recomendable dividirlo hasta tal punto, que este claro su objetivo final (ya que cualquier tarea tiene un objetivo).
Para determinar si una actividad realizada por una organización es un proceso o subproceso, debe cumplir los siguientes criterios:
- La actividad tiene una misión o propósito claro.
- La actividad contiene entradas y salidas, se pueden identificar los clientes,
proveedores y producto final. - La actividad debe ser susceptible de descomponerse en operaciones o tareas.¿Que significa ser suceptible?¿Acaso las actividades tienen sentimientos?(lo que quieren decir es que se puede descomponer en operaciones o tareas).
- La actividad puede ser estabilizada mediante la aplicación de la metodología de gestión por procesos (tiempo, recursos, costes).
- Se puede asignar la responsabilidad del proceso a una persona.
Una de mis mayores era, porque tantas definiciones, porque tantas recetas. A veces, por lo menos para mi, es mas facil aprenderse una pregunta que toda la respuesta. A veces una pregunta bien hecha te permite reproducir nuevamente toda una larga respuesta. En mi caso que lei por primera vez las preguntas que vinieron a mi cabeza fueron.
¿Que es lo que no es una actividad? ¿Porque toda esta receta? Pues a mi forma de ver, todo era una actividad de alguna manera. Y la receta que tenemos anteriormente, debe salir de algun lado. Luego de esas preguntas las respuestas me empiezan a salir. Una de los principales objetivos de esta asignatura es tener una organizacion y clasificacion clara de las cosas. Los cuatro ultimos puntos, tienen que ver con eso. El primer punto era el que mayor confusion me hacia. Que es la tarea que no tiene objetivo claro? Bueno al parecer, las Tareas. Lo que se quiere decir, en esa lista, es que para que una tarea sea un proceso, tiene que tener un unico objetivo. Tiene que estar direccionado hacia un lado. No importa si es muy grande o muy pequeño, el objetivo es que si una tarea tenga varias subtareas esta tenga un solo objetivo y no varios. Un ejemplo sencillo de una actividad que puede ser una tarea.
Tarea (o Actividad):
Cojer un plato sucio, ponerlo en el lavaplatos, encender el lavaplatos.
La tarea tiene un objetivo claro. Lavar el plato. Lo que se desea siempre, es que ese conjunto de tareas siempre sean para un mismo fin. Que al final, al parecer, siempre se puede conseguir una tarea mas global que cubre todos esos subprocesos. Por ejemplo, una actividad que aparentemente no tiene objetivo o mision.
Tarea:
Cojer un plato sucio, cojer ropa sucia, poner en el lavaplatos el plato sucio, poner en la lavadora la ropa sucia, encender el lavaplatos, encender la lavadora.
¿Tiene una mision clara la actividad? Al parecer no, porque ¿es lavar los platos o lavar la ropa?
Sin embargo, un lector podria decir, que el objetivo es Limpiar o Lavar. Y la respuesta estaria correcta. Pero la idea entonces quedaria de otra manera.
La activdad que se considere proceso, es recomendable dividirlo hasta tal punto, que este claro su objetivo final (ya que cualquier tarea tiene un objetivo).
sábado, 23 de febrero de 2013
Arduino Motor DC con 3 estados Parte 1
Recien empeizo hacer algo con Arduinos, y bueno la electronica no es muy fuerte ya que no se casi nada o nada de ella. Pero a los pocos siento que voy avanzando. En este tutorial, intento explicar como hacer un motor dc, pueda rotar en una direccion, en la opuesta y sin moverse.
Muchas maquinas su funcionalidad basica envuelve encender y apagar motores o invertir su direccion. Sin embargo hay muchos motores que ya vienen con un integrado dando la posibilidad de hacerlo mas facil, pero tambien se eleva su coste. Sin embargo lo unico que se necesita, para tener esta funcionalidad es un relay.
Para entender los relays en los diseños a seguir, debemos entender lo basico de la logica de interruptores (switch logic). Un interruptor es un dispositivo que abre o cierra un circuito, o sea, que deja pasar corriente o no. Un ejemplo de un interruptor, es el encendedor de una lampara, cuando la encendemos, dejamos pasar corriente y asi se enciende la lampara (circuito cerrado) y cuando la apagamos (circuito abierto). En terminologia de logica, un circuito cerrado, representa 1 y un circuito abierto representa 0.
Los interrupores son diseñados con una cantidad de poles y throws, terminologia que no se en español, ya que lo aprendi investigando en ingles, cualquier electronico podria comentarme los nombres y los añadaria a los articulos sin problem. Los Throws, son contactos fijos, mientras los poles son los contactos que se mueven cuando el interruptor es activado. En el ejemplo de una lampara los poles, es la palanca interior, que hace contacto con las dos terminales haciendo que pase la corriente.
La tipica nomenclatura de los interruptores es P para poles y T para throws, con el numero que se especifica con la primera letra, yo realmente criticaria esta forma, ya que se usaria la notacion inglesa, si fuera con numeros al menos causaria menos dudas en otros ideomas. Por ejemplo, un interruptor podria ser SPDT, que significa S de Single (Uno), P de Pole, D de Double (Dos) T Throw.Sin embargo cuando tienen mas Poles y Throws, si es dado con numeros.
Para poner un poco mas integro el conocimiento, los interruptores pueden ser Momentanios o Continuos. Un timbre de puerta, es un ejemplo de un interruptor momentanio. Mientras el boton no esta siendo presionado el circuito esta abierto, sin embargo, cuando presionamos el boton, el circuito esta cerrado y pasa corriente. En la representacion de abreviaturas los interruptores momentanios, tendrian como throws, n.o y n.c, que significan, normalmente abierto (normally open) y normalmente cerrado y el pole se usa la expresion com (de commun).
Para interruptores com mas de dos poles o throws podemos ver el siguiente ejemplo "4PDT" que significaria, 4 Poles, Double Trows. En este diagrama, las lineas discontinuas indican que todos los poles del interruptor operan juntos.
Muchas maquinas su funcionalidad basica envuelve encender y apagar motores o invertir su direccion. Sin embargo hay muchos motores que ya vienen con un integrado dando la posibilidad de hacerlo mas facil, pero tambien se eleva su coste. Sin embargo lo unico que se necesita, para tener esta funcionalidad es un relay.
Para entender los relays en los diseños a seguir, debemos entender lo basico de la logica de interruptores (switch logic). Un interruptor es un dispositivo que abre o cierra un circuito, o sea, que deja pasar corriente o no. Un ejemplo de un interruptor, es el encendedor de una lampara, cuando la encendemos, dejamos pasar corriente y asi se enciende la lampara (circuito cerrado) y cuando la apagamos (circuito abierto). En terminologia de logica, un circuito cerrado, representa 1 y un circuito abierto representa 0.
Los interrupores son diseñados con una cantidad de poles y throws, terminologia que no se en español, ya que lo aprendi investigando en ingles, cualquier electronico podria comentarme los nombres y los añadaria a los articulos sin problem. Los Throws, son contactos fijos, mientras los poles son los contactos que se mueven cuando el interruptor es activado. En el ejemplo de una lampara los poles, es la palanca interior, que hace contacto con las dos terminales haciendo que pase la corriente.
La tipica nomenclatura de los interruptores es P para poles y T para throws, con el numero que se especifica con la primera letra, yo realmente criticaria esta forma, ya que se usaria la notacion inglesa, si fuera con numeros al menos causaria menos dudas en otros ideomas. Por ejemplo, un interruptor podria ser SPDT, que significa S de Single (Uno), P de Pole, D de Double (Dos) T Throw.Sin embargo cuando tienen mas Poles y Throws, si es dado con numeros.
Para poner un poco mas integro el conocimiento, los interruptores pueden ser Momentanios o Continuos. Un timbre de puerta, es un ejemplo de un interruptor momentanio. Mientras el boton no esta siendo presionado el circuito esta abierto, sin embargo, cuando presionamos el boton, el circuito esta cerrado y pasa corriente. En la representacion de abreviaturas los interruptores momentanios, tendrian como throws, n.o y n.c, que significan, normalmente abierto (normally open) y normalmente cerrado y el pole se usa la expresion com (de commun).
Para interruptores com mas de dos poles o throws podemos ver el siguiente ejemplo "4PDT" que significaria, 4 Poles, Double Trows. En este diagrama, las lineas discontinuas indican que todos los poles del interruptor operan juntos.
martes, 19 de febrero de 2013
LA GESTIÓN POR PROCESOS parte 2
En esta segunda seccion, vienen definiciones un poco mas formales, pero a mi forma de ver no completas e confusas. Intentare dar ejemplos y decir que parte de mi bibliografia dice una cosa y que pienso yo al respecto. Dejando al lector la posibilidad de debatir con comentarios y llegar a una metodologia o definiciones mas completas.
Segun mi bibliografia:
Segun mi bibliografia:
Un proceso es un conjunto de actividades interrelacionadas entre sí que, a partir de
una o varias entradas de materiales o información, dan lugar a una o varias salidas
también de materiales o información con valor añadido.
Que problema tiene la definicion anterior?
1- Ambigua, no pudiendo reestringir en ningun momento, sobre ninguna teoria las entradas de materiales o informacion, al final, esa entrada se puede siempre reducir a elementos basicos, o una medida.
2-Tendra confusion cuando se defina que es un procedimiento.
3-Obliga tener un valor añadido(Ambiguo).
Un proceso lo definiria como una funcion matematica, que dado unos parametros (entrada de materiales o informacion) tiene una salida (dan lugar a una o varias salidas también de materiales o información con valor añadido).
Mi definicion de proceso:
donde N se consideran los naturales. Y cada dimension la propiedad que necesitamos de la entrada.
NOTA: Esta definicion, no es la que el cliente final se enfrenta, sino es la definicion formal, para integrarla a un sistema sin ambiguedades y ademas sustentarse sobre teorias ya existentes.
Ejemplo:
Para el cliente final:
Proceso: Limpiar un carro
Entrada:
13 Litros de Agua
500 ml de detergente
10 ml de aromatizante
Salida:
Coste:10 €
Tiempo: 30 min
Proceso para nuestro sistema:
Proceso: Limpiar un carro
Entrada:
X-Cantidad de litros de Agua
Y- Cantidad de Detergente
Z-Aromatizante
Salida:
C- Coste
T- Tiempo
Al final no es mas que una sucesion de pasos, que se siguen para realizar una determinada actividad.
Una definicion menos formal y mas facil de entender es transformar el conjunto de elementos de entrada en un resultado.
Segun mi bibliografia:
Un proceso no es lo mismo que un procedimiento:
Un procedimiento es el conjunto de reglas e instrucciones que determinan la manera de
proceder o de obrar para conseguir un resultado.
Segun mi definicion:
Son iguales, ya que al final , se puede ver como entrada el conjunto de reglas e instrucciones y como salida la manera de proceder o de obrar para conseguir un resultado.
La definicion matematica, no trae ambiguedad en ese caso, ya que de forma matematica, las funciones son de por si metafunciones (funciones que usan funciones como parametros y como salida).
Una funcion es una manera de proceder para tener un resultado (definicion de procedimiento).
Una funcion es un conjunto de entrada que transforma en una salida (definicion de proceso).
Al final, esa definicion ambigua se debe, a que se quiere expresar que:
Que problema tiene la definicion anterior?
1- Ambigua, no pudiendo reestringir en ningun momento, sobre ninguna teoria las entradas de materiales o informacion, al final, esa entrada se puede siempre reducir a elementos basicos, o una medida.
2-Tendra confusion cuando se defina que es un procedimiento.
3-Obliga tener un valor añadido(Ambiguo).
Un proceso lo definiria como una funcion matematica, que dado unos parametros (entrada de materiales o informacion) tiene una salida (dan lugar a una o varias salidas también de materiales o información con valor añadido).
Mi definicion de proceso:
NOTA: Esta definicion, no es la que el cliente final se enfrenta, sino es la definicion formal, para integrarla a un sistema sin ambiguedades y ademas sustentarse sobre teorias ya existentes.
Ejemplo:
Para el cliente final:
Proceso: Limpiar un carro
Entrada:
13 Litros de Agua
500 ml de detergente
10 ml de aromatizante
Salida:
Coste:10 €
Tiempo: 30 min
Proceso para nuestro sistema:
Proceso: Limpiar un carro
Entrada:
X-Cantidad de litros de Agua
Y- Cantidad de Detergente
Z-Aromatizante
Salida:
C- Coste
T- Tiempo
Al final no es mas que una sucesion de pasos, que se siguen para realizar una determinada actividad.
Una definicion menos formal y mas facil de entender es transformar el conjunto de elementos de entrada en un resultado.
Segun mi bibliografia:
Un proceso no es lo mismo que un procedimiento:
Un procedimiento es el conjunto de reglas e instrucciones que determinan la manera de
proceder o de obrar para conseguir un resultado.
Segun mi definicion:
Son iguales, ya que al final , se puede ver como entrada el conjunto de reglas e instrucciones y como salida la manera de proceder o de obrar para conseguir un resultado.
La definicion matematica, no trae ambiguedad en ese caso, ya que de forma matematica, las funciones son de por si metafunciones (funciones que usan funciones como parametros y como salida).
Una funcion es una manera de proceder para tener un resultado (definicion de procedimiento).
Una funcion es un conjunto de entrada que transforma en una salida (definicion de proceso).
Al final, esa definicion ambigua se debe, a que se quiere expresar que:
Un proceso define que es lo que se hace, y un procedimiento, cómo hacerlo. En otras palabras un proceso te dice como hacer una receta de comida y un procedimiento como hacerlo.
¿Vale la pregunta?
Si hacemos un procedimiento, que sea definir lo que se hace en un problema. ¿No seria un proceso?
Si nos fijamos en un detalle, el proceso dice QUE es lo que se hace, y un procedimiento COMO se hace. La diferencia de esas dos palabras realmente son, que el cliente cliente usa QUE y los programadores COMO. El cliente usa lenguaje natural y nosotros formal. Si lo vemos como paradigma de programacion, los lenguajes como Prolog, se programan usando el QUE y los clasicos como C#, se programa usando COMO.
Mas una razon para decir que son lo mismo. Aunque admito que quieren definir dos estados diferentes de una misma cosa, o sea, que algo se puede definir tanto desde un procedimiento como desde un proceso. Que ambos tienen el mismo alcance.
Despues de un largo debate con un profesor de la asignatura, termino con la definicion de que si, son lo mismo. Lo que simplemente uno es dicho y otro es hecho. O sea, receta para hacer el pan, seria un proceso, pero los pasos de esa receta es lo que se llama procedimiento. Al final y al cabo, no deberia ser implementacion?
Creo que esta area, esta dispuesta a ser muy generica y esta dejando atras las areas en que se aplica. Ya que tanto la informatica como la Ciencia de la Computacion tienen bien claros conceptos de los mismos. Creo que ademas deberia hacerse especifica de nuestra area y no intentar dejarla de la manera que se desarrolla.
¿Vale la pregunta?
Si hacemos un procedimiento, que sea definir lo que se hace en un problema. ¿No seria un proceso?
Si nos fijamos en un detalle, el proceso dice QUE es lo que se hace, y un procedimiento COMO se hace. La diferencia de esas dos palabras realmente son, que el cliente cliente usa QUE y los programadores COMO. El cliente usa lenguaje natural y nosotros formal. Si lo vemos como paradigma de programacion, los lenguajes como Prolog, se programan usando el QUE y los clasicos como C#, se programa usando COMO.
Mas una razon para decir que son lo mismo. Aunque admito que quieren definir dos estados diferentes de una misma cosa, o sea, que algo se puede definir tanto desde un procedimiento como desde un proceso. Que ambos tienen el mismo alcance.
Despues de un largo debate con un profesor de la asignatura, termino con la definicion de que si, son lo mismo. Lo que simplemente uno es dicho y otro es hecho. O sea, receta para hacer el pan, seria un proceso, pero los pasos de esa receta es lo que se llama procedimiento. Al final y al cabo, no deberia ser implementacion?
Creo que esta area, esta dispuesta a ser muy generica y esta dejando atras las areas en que se aplica. Ya que tanto la informatica como la Ciencia de la Computacion tienen bien claros conceptos de los mismos. Creo que ademas deberia hacerse especifica de nuestra area y no intentar dejarla de la manera que se desarrolla.
LA GESTIÓN POR PROCESOS parte 1
LA GESTIÓN TRADICIONAL
DIVISION DE TRABAJOS EN UN SOFTWARE
Todo proyecto tiene unos fines ligados a la obtención de un producto o servicio. Para llegar a este producto o servicio, se recomiendo dividir estas actividades y agruparlas en fases, (como en programacion que dividimos los problemas en subproblemas para que la resolucion de cada subproblema sea mas facil y asi mas facil la resolucion del problema general). El conjunto de estas fases, se denominan ciclo de vida.
Esta claro, que es muy general la forma de atacar a cualquier produccion de producto o de servicio, luego la forma de agrupar estas actividades, los objetivos de los mismos, etc. Son diferentes dependiendo de las tecnologias y del producto en si.
La relacion entre estas actividades son muy grandes , luego es muy importante que la division de los proyectos sea organizada en fases sucesivas consiguiendo asi una reduccion muy grande de la complejidad del proyecto.
Cada fase tienen sus tareas planificadas. Dependiendo del proyecto este puede tener fases que generan bucles de realimentacion, de manera que lo que se considera una fase puede repetirse varias veces a lo largo del proyecto.
NOTA: Asumo que los que les interesa la gestion de proyectos, son programadores (y tambien de otras carreras) que nunca han gestionados grandes proyectos y necesitan cierta organizacion. Luego, para poner un poco claro pondre dos simples ejemplos de lo dicho anteriormente.
Ejemplo 1:
Supongamos que una empresa hipotetica 2A&M tiene cinco departamentos. Programacion, Diseño , Contabilidad y Finanzas, Recursos Humanos y Limpieza. Todo proyecto que se resive en la empresa, va tener una separacion, que sera enviada a cada seccion. Ese proceso de separacion es un ejemplo de fases.
Primero los recursos humanos entrega define la cantidad de personas para un Proyecto X, despues la Contabilidad y Finanzas establece un primer aproximado de presupuesto, los departamentos de Diseño y de Programacion establecen el tiempo que creen que se podria demorar con la gente asignada por el departamento de Recursos Humanos. Y al final de cada tiempo, el departamento de Limpieza hace limpieza en el local. Este departamento fue puesto, para ilustrar un ejemplo sencillo de repeticion de una misma tarea en un Proyecto. Cada fase(Departamento) esta llena de actividades y cada actividad tiene sus objetivos y asi sucesivamente. Al final y al cabo es aplicar recursivamente el proceso.
Ejemplo 2:
Este ejemplo es mas sencillo y mas parecido a un algoritmo. Imaginemos que tenemos un rollo de papel con numeros, los cuales tenemos que ordenarlos de menor a mayor y ponerlo en otro rollo de papel. Si los numeros son 5 o 10, puede ser que no tengamos problemas pero si son 10000 ya la situacion cambia un poco. Luego, hemos decidio llevar el problema a las siguientes fases:
Primero lo dividimos en dos listas, uno con una lista ordenada y otra con el resto si ordenar. Entonces tenemos dos nuevos problemas.
1. Insertar un nuevo elemento en la lista ordenada y reordenar la lista (Un problema mas sencillo que el anterior)
2. Ordenar una lista desordenada pero con menos numeros (Un problema mas sencillo que el anterior)
De esa manera terminaremos organizando las dos listas. Pero a mitad de proyecto nos damos cuenta de algo, que si dividimos en N listas donde cada lista representa el numero de digitos y ordenamos cada lista por separados, despues seria solo unir las listas. Y estaria ordenado. De esta forma de ataque, hemos divido el problema en N diferentes problemas. Muchos mas sencillos y con menos numeros. E hicimos una retroalimentacion, que fue organizar listas, en cada sublista. Otra realimentacion, fue el cambio de estrategia, ya que nos dimos cuenta en un punto avanzado del proyecto.
Caracteristicas
DIVISION DE TRABAJOS EN UN SOFTWARE
Todo proyecto tiene unos fines ligados a la obtención de un producto o servicio. Para llegar a este producto o servicio, se recomiendo dividir estas actividades y agruparlas en fases, (como en programacion que dividimos los problemas en subproblemas para que la resolucion de cada subproblema sea mas facil y asi mas facil la resolucion del problema general). El conjunto de estas fases, se denominan ciclo de vida.
Esta claro, que es muy general la forma de atacar a cualquier produccion de producto o de servicio, luego la forma de agrupar estas actividades, los objetivos de los mismos, etc. Son diferentes dependiendo de las tecnologias y del producto en si.
La relacion entre estas actividades son muy grandes , luego es muy importante que la division de los proyectos sea organizada en fases sucesivas consiguiendo asi una reduccion muy grande de la complejidad del proyecto.
Cada fase tienen sus tareas planificadas. Dependiendo del proyecto este puede tener fases que generan bucles de realimentacion, de manera que lo que se considera una fase puede repetirse varias veces a lo largo del proyecto.
NOTA: Asumo que los que les interesa la gestion de proyectos, son programadores (y tambien de otras carreras) que nunca han gestionados grandes proyectos y necesitan cierta organizacion. Luego, para poner un poco claro pondre dos simples ejemplos de lo dicho anteriormente.
Ejemplo 1:
Supongamos que una empresa hipotetica 2A&M tiene cinco departamentos. Programacion, Diseño , Contabilidad y Finanzas, Recursos Humanos y Limpieza. Todo proyecto que se resive en la empresa, va tener una separacion, que sera enviada a cada seccion. Ese proceso de separacion es un ejemplo de fases.
Primero los recursos humanos entrega define la cantidad de personas para un Proyecto X, despues la Contabilidad y Finanzas establece un primer aproximado de presupuesto, los departamentos de Diseño y de Programacion establecen el tiempo que creen que se podria demorar con la gente asignada por el departamento de Recursos Humanos. Y al final de cada tiempo, el departamento de Limpieza hace limpieza en el local. Este departamento fue puesto, para ilustrar un ejemplo sencillo de repeticion de una misma tarea en un Proyecto. Cada fase(Departamento) esta llena de actividades y cada actividad tiene sus objetivos y asi sucesivamente. Al final y al cabo es aplicar recursivamente el proceso.
Ejemplo 2:
Este ejemplo es mas sencillo y mas parecido a un algoritmo. Imaginemos que tenemos un rollo de papel con numeros, los cuales tenemos que ordenarlos de menor a mayor y ponerlo en otro rollo de papel. Si los numeros son 5 o 10, puede ser que no tengamos problemas pero si son 10000 ya la situacion cambia un poco. Luego, hemos decidio llevar el problema a las siguientes fases:
Primero lo dividimos en dos listas, uno con una lista ordenada y otra con el resto si ordenar. Entonces tenemos dos nuevos problemas.
1. Insertar un nuevo elemento en la lista ordenada y reordenar la lista (Un problema mas sencillo que el anterior)
2. Ordenar una lista desordenada pero con menos numeros (Un problema mas sencillo que el anterior)
De esa manera terminaremos organizando las dos listas. Pero a mitad de proyecto nos damos cuenta de algo, que si dividimos en N listas donde cada lista representa el numero de digitos y ordenamos cada lista por separados, despues seria solo unir las listas. Y estaria ordenado. De esta forma de ataque, hemos divido el problema en N diferentes problemas. Muchos mas sencillos y con menos numeros. E hicimos una retroalimentacion, que fue organizar listas, en cada sublista. Otra realimentacion, fue el cambio de estrategia, ya que nos dimos cuenta en un punto avanzado del proyecto.
Caracteristicas
- Dependencia casi total de las personas responsable por cada fase: La calidad conseguida en el trámite administrativo depende de las personas que lo realizan. Esto es debido a que al ser los responsables de una determinada etapa, tienen el conocimiento completo del estado en que se encuentra.
- Materialización sobre papel: Todos los trámites generan papel, produciéndose problemas de almacenamiento y archivo del mismo con riesgo de pérdida o deterioro, ineficiencias en la localización, excesos en el uso de copias, etc. El cual hoy en dia se puede gestionar de forma digital.
- Poca información sobre la situación de los procesos o haciendo costosa y complicada su determinación
- Insatisfacción en el personal: Gran parte de las tareas que se realizan aportan muy poco valor añadido a los procesos.
Calidad de proyectos de Informática Avanzada I
Recien empiezo a estudiar esta asignatura en mi Master y creo que es una de las asignaturas mas aburridas, pero creo tambien que pueden dar una buena idea de como organizar los proyectos grandes, que puede ser intuitivamente correcto, y ademas sacarle un costo y tiempo de finalizacion apropiado. Lo cual ya no entra en la parte de intuitivo, ya que depende de la sociedad y muchos factores externos.
Desde la introducción en 1916 de la primera función de control y garantía de
calidad formal en los laboratorios Bell de Estados Unidos, las organizaciones
productoras de bienes de cualquier tipo y las suministradoras de servicios han
ido incorporando mecanismos, cada vez más efectivos, que aseguren la calidad
de los productos elaborados y de los servicios realizados. El interés por la
calidad ha dado lugar a la proliferación de asociaciones nacionales e
internacionales sobre el tema y a un esfuerzo normativo por parte de los
organismos de estandarización para unificar criterios y proponer normas y guías
universalmente aceptadas.
En este sentido, hay que destacar que el cenit normativo se pude situar en marzo de 1987 con la aparición, después de cinco años de trabajo del “Comité Técnico de Gestión y Aseguramiento de la Calidad” de ISO, de las primeras normas de la serie ISO 9000, que definían “los requisitos de los sistemas de calidad que pueden utilizarse para el aseguramiento externo de la calidad, es decir, para que un suministrador demuestre su capacidad y para la evaluación de la capacidad de un suministrador por partes externas”.
La situación actual de la calidad en el ámbito informático está condicionada principalmente por las normas ISO de aseguramiento de la calidad, como ISO 9000, ISO 9126, ISO 15504 o ISO 20000; por el modelo de evaluación y mejora de la calidad del proceso software CMMI (Capability Maturity Model Integration); por el modelo ITIL (Information Technology Infrastructure Library); y, en el ámbito europeo, también por el modelo EFQM (European Foundation for Quality Management).
Todas estas normas y modelos se caracterizan por aplicar un enfoque basado en procesos. La gestión por procesos es un esquema que permite organizar los esfuerzos y la utilización de los recursos para lograr la satisfacción balanceada de todos los entes vinculados a cada uno de los procesos que definen a un sistema organizacional. Este esquema de gestión requiere que las partes que lo componen se caractericen por crear relaciones coordinadas, para lograr niveles de eficacia y eficiencia en el sistema, que cumplan con los tres elementos básicos de una gestión de calidad: alcanzar los requerimientos de los clientes finales, en los tiempos establecidos y a los costos presupuestados.
Son tales los beneficios del esquema de gestión por procesos, que las normas y modelos de calidad citados, lo consideran como un requisito. Así, por ejemplo, en la norma ISO 9001 “se promueve la adopción de un enfoque a procesos para el desarrollo, implantación y mejora de la eficacia de un sistema de gestión de la calidad, para aumentar la satisfacción del cliente mediante el cumplimiento de sus requisitos”; y en el modelo EFQM se señala la importancia del diseño y gestión sistemática de los procesos críticos, su revisión y mejora continua con base a las necesidades y expectativas de los clientes y demás entes que se relacionan con los procesos de una organización.
En esta asignatura se estudian los principales estándares relacionados con la calidad informática, comenzando previamente por el estudio de los principios que rigen el enfoque de la gestión por procesos, dado que es la base en la que se sustentan los estándares sobre calidad.
En este sentido, hay que destacar que el cenit normativo se pude situar en marzo de 1987 con la aparición, después de cinco años de trabajo del “Comité Técnico de Gestión y Aseguramiento de la Calidad” de ISO, de las primeras normas de la serie ISO 9000, que definían “los requisitos de los sistemas de calidad que pueden utilizarse para el aseguramiento externo de la calidad, es decir, para que un suministrador demuestre su capacidad y para la evaluación de la capacidad de un suministrador por partes externas”.
La situación actual de la calidad en el ámbito informático está condicionada principalmente por las normas ISO de aseguramiento de la calidad, como ISO 9000, ISO 9126, ISO 15504 o ISO 20000; por el modelo de evaluación y mejora de la calidad del proceso software CMMI (Capability Maturity Model Integration); por el modelo ITIL (Information Technology Infrastructure Library); y, en el ámbito europeo, también por el modelo EFQM (European Foundation for Quality Management).
Todas estas normas y modelos se caracterizan por aplicar un enfoque basado en procesos. La gestión por procesos es un esquema que permite organizar los esfuerzos y la utilización de los recursos para lograr la satisfacción balanceada de todos los entes vinculados a cada uno de los procesos que definen a un sistema organizacional. Este esquema de gestión requiere que las partes que lo componen se caractericen por crear relaciones coordinadas, para lograr niveles de eficacia y eficiencia en el sistema, que cumplan con los tres elementos básicos de una gestión de calidad: alcanzar los requerimientos de los clientes finales, en los tiempos establecidos y a los costos presupuestados.
Son tales los beneficios del esquema de gestión por procesos, que las normas y modelos de calidad citados, lo consideran como un requisito. Así, por ejemplo, en la norma ISO 9001 “se promueve la adopción de un enfoque a procesos para el desarrollo, implantación y mejora de la eficacia de un sistema de gestión de la calidad, para aumentar la satisfacción del cliente mediante el cumplimiento de sus requisitos”; y en el modelo EFQM se señala la importancia del diseño y gestión sistemática de los procesos críticos, su revisión y mejora continua con base a las necesidades y expectativas de los clientes y demás entes que se relacionan con los procesos de una organización.
En esta asignatura se estudian los principales estándares relacionados con la calidad informática, comenzando previamente por el estudio de los principios que rigen el enfoque de la gestión por procesos, dado que es la base en la que se sustentan los estándares sobre calidad.
Suscribirse a:
Entradas (Atom)