Los expertos responden cómo aprender a determinar correctamente los plazos para completar el trabajo. Planificación (informática) - Director técnico de programación (informática) del centro de tecnologías y soluciones innovadoras "Jet Infosystems"

Una versión cambiada del algoritmo anterior es el algoritmo de tiempo de ejecución restante más corto. Según este algoritmo, el programador selecciona cada vez el proceso con el tiempo de ejecución restante más corto. En este caso, también es necesario conocer de antemano el tiempo de finalización de la tarea. Cuando llega una nueva tarea, su tiempo total de ejecución se compara con el tiempo de ejecución restante de la tarea actual. Si el tiempo de ejecución de la nueva tarea es más corto, el proceso actual se suspende y el control se transfiere a la nueva tarea. Este esquema le permite atender rápidamente solicitudes breves.

Planificación de tres niveles

Los sistemas de procesamiento por lotes permiten una programación de tres niveles, como se muestra en la figura. A medida que llegan nuevas tareas al sistema, primero se colocan en una cola almacenada en el disco. Entrada planificador de acceso selecciona una tarea y la transfiere al sistema. Las tareas restantes permanecen en la cola.

Tan pronto como un trabajo ingresa al sistema, se creará el proceso correspondiente y podrá comenzar inmediatamente a competir por el acceso al procesador. Sin embargo, es posible que haya demasiados procesos y no quepan todos en la memoria, por lo que algunos de ellos se paginarán en el disco. El segundo nivel de programación determina qué procesos se pueden almacenar en la memoria y cuáles en el disco. Esto es lo que él hace programador de memoria .

El programador de memoria examina periódicamente los procesos en el disco para decidir cuáles mover a la memoria. Entre los criterios utilizados por el planificador se encuentran los siguientes:

1. ¿Cuánto tiempo ha pasado desde que el proceso se intercambió al disco o se cargó desde el disco?

2. ¿Cuánto tiempo lleva el proceso usando la CPU?

3. ¿Cuál es el tamaño del proceso (los procesos pequeños no interfieren)?

4. ¿Cuál es la importancia del proceso?

El tercer nivel de programación es responsable de permitir que los procesos en estado listo accedan al procesador. Cuando hablamos de un "programador", generalmente nos referimos programador de CPU . Este planificador utiliza cualquier algoritmo adecuado a la situación, tanto con interrupción como sin ella. Ya hemos analizado algunos de estos algoritmos y conoceremos otros más adelante.

Planificación en sistemas interactivos.

Planificación cíclica.

Uno de los más antiguos, simples, justos y utilizados con mayor frecuencia es el algoritmo de programación cíclica. A cada proceso se le asigna una cierta cantidad de tiempo de procesador, el llamado intervalo de tiempo. Si el proceso todavía se está ejecutando al final del intervalo de tiempo, finaliza y el control se transfiere a otro proceso. Por supuesto, si el proceso se bloquea o termina antes de tiempo, en este punto se produce una transición de control. La implementación de la programación por turnos es sencilla. El programador solo necesita mantener una lista de procesos en estado listo. Cuando un proceso ha alcanzado su límite de tiempo, se envía al final de la lista.

El único aspecto interesante de este algoritmo es la longitud del cuanto. Pasar de un proceso a otro lleva algún tiempo: es necesario guardar y cargar registros y mapas de memoria, actualizar tablas y listas, guardar y recargar la memoria caché, etc. La conclusión se puede formular de la siguiente manera: un cuanto demasiado pequeño conducirá a frecuentes cambios de procesos y una pequeña eficiencia, pero una cantidad demasiado grande puede dar como resultado una respuesta lenta a solicitudes interactivas breves. Un valor cuántico de alrededor de 2 0 -5 0 ms suele ser un compromiso razonable.

Planificación prioritaria.

La programación por turnos parte del supuesto importante de que todos los procesos son iguales. En el caso de una computadora con una gran cantidad de usuarios, este puede no ser el caso. Por ejemplo, en una universidad, primero se debe atender a los decanos, luego a los profesores, secretarias, limpiadores y solo después a los estudiantes. La necesidad de tener en cuenta estos factores externos conduce a una planificación prioritaria. La idea básica es simple: a cada proceso se le asigna una prioridad y el control se transfiere al proceso listo con la mayor prioridad.

Varias colas.

Uno de los primeros programadores de prioridad se implementó en el sistema CTSS (sistema de tiempo compartido compatible). El principal problema con el sistema CTSS era que el cambio de procesos era demasiado lento, ya que la computadora IBM 7094 solo podía mantener un proceso en la memoria. Cada cambio significó descargar el proceso actual al disco

y leer el nuevo proceso desde el disco. Los desarrolladores de CTSS rápidamente se dieron cuenta de que la eficiencia sería mayor si a los procesos limitados por el procesador se les diera un intervalo de tiempo mayor que si se les diera intervalos de tiempo pequeños, pero con frecuencia. Por un lado, esto reducirá el número de transferencias de la memoria al disco y, por otro, provocará un deterioro en el tiempo de respuesta, como ya hemos visto.

Como resultado, se desarrolló una solución con clases prioritarias. A los procesos de la clase de mayor prioridad se les asignó un cuanto, a los procesos de la siguiente clase se les asignaron dos cuantos, a los procesos de la siguiente clase se les asignaron cuatro cuantos, etc. Cuando un proceso había utilizado todo el tiempo asignado, se movía a una categoría inferior. clase.

Como ejemplo, considere un proceso que necesita calcular más de 100 cuantos. Primero, se le dará un cuanto y luego se bombeará al disco. La próxima vez obtiene 2 cuantos, luego 4, 8,16, 32, 64, aunque de 64 solo usa 37. En este caso, solo serán necesarias 7 transferencias (incluida la carga inicial) en lugar de las 100 que serían necesario utilizando el algoritmo de operación por turnos. Además, a medida que se adentra en la cola de prioridad, el proceso se iniciará cada vez con menos frecuencia, lo que permitirá que la CPU se dedique a procesos más cortos.

“El proceso más corto es el siguiente”

Dado que el algoritmo Shortest Task First minimiza el tiempo de respuesta promedio en los sistemas de procesamiento por lotes, a uno le gustaría usarlo también en sistemas interactivos. Hasta cierto punto esto es posible. Los procesos interactivos suelen seguir el patrón de "esperar un comando, ejecutar un comando, esperar un comando, ejecutar un comando..." Si trata la ejecución de cada comando como una tarea separada, puede minimizar la respuesta promedio general. tiempo ejecutando primero la tarea más corta. El único problema es

es entender cuál de los procesos de espera es el más corto.

Un método se basa en estimar la duración del proceso basándose en el comportamiento previo del proceso. En este caso se inicia el proceso con el menor tiempo estimado. Supongamos que el tiempo de ejecución esperado del comando es T 0 y el tiempo esperado de próxima ejecución es T 1. Es posible mejorar la estimación del tiempo tomando la suma ponderada de estos tiempos aT 0 + (1 - a)T 1. Al elegir el valor apropiado para a, podemos hacer que el algoritmo de estimación se olvide rápidamente de ejecuciones anteriores o, por el contrario, las recuerde durante mucho tiempo. Tomando a = 1/2, obtenemos una serie de estimaciones:

T 0, T 0/2 + T 1/2, T 0/4 + T 1/4 + T 2/2, T 0/8 + T 1/8 + T 2/4 + T 3/2.

Después de tres ejecuciones, el peso de T 0 en la estimación disminuirá a 1/8.

El método de estimar el siguiente valor de una serie mediante un promedio ponderado del valor anterior y la estimación anterior a menudo se denomina envejecimiento. Este método es aplicable en muchas situaciones en las que es necesaria una estimación a partir de valores anteriores. La forma más sencilla de implementar el envejecimiento es a = 1/2. En cada paso solo necesitas

agregue un nuevo valor a la estimación actual y divida la suma por la mitad (desplazándose hacia la derecha 1 bit).

Planificación garantizada.

Un enfoque de planificación fundamentalmente diferente es hacer promesas reales a los usuarios y luego cumplirlas. Aquí hay una promesa que es fácil de decir y de cumplir: si comparte un procesador con n usuarios, recibirá 1/n de la potencia del procesador.

Y en un sistema con un usuario yn procesadores en ejecución, cada uno obtendrá 1/n ciclos de procesador.

Para cumplir esta promesa, el sistema debe realizar un seguimiento de la asignación de CPU entre procesos desde el momento en que se crea cada proceso. Luego, el sistema calcula la cantidad de recursos de CPU a los que tiene derecho el proceso, como el tiempo desde la creación dividido por n. Ahora podemos calcular la relación entre el tiempo dedicado al proceso y el tiempo al que tiene derecho. El valor resultante de 0,5 significa que el proceso recibió solo la mitad de la cantidad asignada y 2,0 significa que el proceso recibió el doble de lo que se suponía. Luego se inicia el proceso con la proporción más pequeña, hasta

no será más grande que el de su vecino más cercano.

Planificación de lotería.

El algoritmo se basa en la distribución de billetes de lotería a los procesos para acceder a diversos recursos, incluido el procesador. Cuando el planificador necesita tomar una decisión, se selecciona un billete de lotería al azar y su propietario obtiene acceso al recurso. En términos de acceso a la CPU, la "lotería" puede ocurrir 50 veces por segundo, y el ganador obtiene 20 ms de tiempo de CPU.

A los procesos más importantes se les pueden otorgar boletos adicionales para aumentar la probabilidad de ganar. Si solo hay 100 tickets y 20 de ellos están en un proceso, obtendrá el 20% del tiempo de procesamiento. A diferencia del programador de prioridades, en el que es muy difícil evaluar lo que significa, digamos, prioridad 40, en la programación de lotería todo es obvio. Cada proceso recibirá un porcentaje de recursos aproximadamente igual al porcentaje de tickets que tenga.

La planificación de loterías tiene varias propiedades interesantes. Por ejemplo, si durante la creación un proceso recibe varios billetes, en la siguiente lotería sus posibilidades de ganar son proporcionales al número de billetes.

Los procesos en comunicación pueden intercambiar billetes si es necesario. Entonces, si un proceso cliente envía un mensaje a un proceso servidor y luego lo bloquea, puede pasar todos sus tickets al proceso servidor para aumentar las posibilidades de que el servidor se inicie. Cuando finaliza el proceso del servidor, puede devolver todos los boletos.

Planificación justa.

Hasta ahora hemos asumido que cada proceso se controla independientemente de quién sea su propietario. Por lo tanto, si el usuario 1 crea 9 procesos y el usuario 2 - 1 proceso, entonces, utilizando la programación por turnos o en el caso de prioridades iguales, el usuario 1 obtendrá el 90% del procesador y el usuario 2 solo 10.

Para evitar este tipo de situaciones, algunos sistemas prestan atención al propietario del proceso antes de programarlo. En este modelo, cada usuario obtiene una determinada parte del procesador y el programador selecciona un proceso de acuerdo con este hecho. Si en nuestro ejemplo cada usuario tuviera

prometieron el 50% del procesador, entonces obtendrán el 50% del procesador, independientemente de la cantidad de procesos.

Planificación en sistemas de tiempo real.

En los sistemas de tiempo real, el tiempo juega un papel esencial. Muy a menudo, uno o más dispositivos físicos externos generan señales de entrada y la computadora debe responder adecuadamente a ellas dentro de un período de tiempo determinado.

Los sistemas de tiempo real se dividen en sistemas duros en tiempo real , lo que significa la presencia de plazos estrictos para cada tarea (deben cumplirse), y sistemas flexibles en tiempo real , en el que las violaciones del cronograma son indeseables, pero aceptables. En ambos casos, el programa se divide en varios procesos, cada uno de los cuales es predecible. Estos procesos suelen ser breves y completan su trabajo en un segundo. Cuando aparece una señal externa, es el planificador quien debe asegurarse de que se mantenga el cronograma.

Los eventos externos a los que el sistema debe responder se pueden dividir en periódico(que ocurre a intervalos regulares) y no PERIODICO(que ocurre de manera impredecible). Puede haber varios flujos periódicos de eventos que el sistema deba procesar. Dependiendo del tiempo que lleve procesar cada evento, es posible que el sistema no pueda procesar todos los eventos de manera oportuna.

Información relacionada.

A menudo, los desarrolladores, especialmente los inexpertos, se confunden cuando se les pide que establezcan plazos para completar las tareas. Sin embargo, la capacidad de planificar es una habilidad muy útil y necesaria que ayuda no sólo en el trabajo, sino también en la vida. Decidimos preguntar a los expertos cómo aprender a planificar correctamente y entregar proyectos a tiempo.

Al final del artículo se pueden encontrar breves conclusiones.

Un desarrollador normalmente necesita tener en cuenta varios parámetros a la vez para estimar el tiempo que lleva completar una tarea:

1. Experiencia en la realización de tales tareas y trabajando con esta pila de tecnología. Si tiene que hacer algo fundamentalmente nuevo, debe tener especial cuidado con su evaluación.
2. Experiencia trabajando con este cliente. Conociendo al cliente, se pueden predecir aproximadamente algunos requisitos adicionales y el alcance de los cambios.
3. La calidad del código con el que trabajará. Este es el factor más influyente, por lo que todo puede llevar mucho tiempo y, en general, no salir según lo planeado. Si el proyecto tiene pruebas, solo hay dependencias explícitas en todas partes y la funcionalidad está bien aislada, no todo da tanto miedo. Es mucho peor si se trata de código heredado sin pruebas o con código sobrecargado con dependencias implícitas. Cosas como "funciones mágicas" (cuando es difícil ver la pila de llamadas final del código) y la duplicación de código (cuando necesitas editar varias secciones independientes para cambiar alguna funcionalidad) también pueden complicar las cosas.

Para aprender a estimar adecuadamente los plazos de trabajo, es necesario practicar constantemente. Al comienzo de mi trabajo, hice exactamente esto: estimé el tiempo para completar cualquier tarea entrante, incluso si nadie la necesitaba, y luego miré con qué precisión logré llegar a mi estimación. Mientras completaba la tarea, observó qué acciones llevaban más tiempo. Si algo aumentó notablemente el plazo, fue que recordé este momento y lo tuve en cuenta en las siguientes valoraciones.

A una evaluación objetiva del tiempo necesario exclusivamente para trabajar, habría que añadir un pequeño margen para cubrir situaciones de fuerza mayor. A menudo se evalúa como un porcentaje de la finalización de la tarea principal, pero para cada uno es diferente: algunos añaden el 20% del tiempo, otros el 10% y otros el 50%.

También es útil analizar las razones del incumplimiento de los plazos después de cada incumplimiento grave de los plazos. Si carece de calificaciones, debe trabajar en sus puntos débiles. Si el problema fue organizativo, comprenda qué impidió que funcionara normalmente.

Promocionar Degradar

, director técnico del centro de tecnologías y soluciones innovadoras "Jet Infosystems"

Una gran cantidad de artículos están dedicados a métodos para evaluar la intensidad laboral de un proyecto, incluida la duración del trabajo y las tareas individuales. Sin embargo, esto todavía causa conflictos tanto dentro del equipo del proyecto como en la comunicación con el cliente.

El principal asistente en la evaluación es la experiencia. Intente comparar de alguna manera la nueva tarea con las ya realizadas. Si está haciendo un informe, observe cuánto tiempo tomó un informe similar en el pasado. Si estás haciendo algo nuevo, intenta dividirlo en partes conocidas y evaluarlas. Si la tarea es completamente nueva, reserve tiempo para estudiar (mejor aún, coordine este tiempo con la persona que establece la tarea).

Preste atención a las etapas que lo acompañan: si necesita desarrollar un servicio, entonces la evaluación también debe incluir pruebas unitarias (y tal vez no solo pruebas unitarias), la preparación de los datos de prueba llevará algún tiempo. Debe considerar la integración con otros servicios, etc. Deje tiempo para corregir los defectos que encuentre usted mismo o con la ayuda de evaluadores. Se puede perder mucho tiempo en tareas “invisibles”. Por ejemplo, hay una evaluación para el desarrollo y una evaluación para las pruebas, pero la transferencia de un artefacto para las pruebas puede implicar el despliegue de soportes. Por eso, es importante visualizar mentalmente todo el proceso para no perdernos nada.

Una vez determinada la complejidad, es necesario incluir nuevos trabajos en el calendario, sin olvidar otras tareas y actividades que van en paralelo.

Y no olvides que los planes no sirven de nada, pero la planificación no tiene precio. Aprenda a ajustar los planes de manera oportuna, mantenga informados a todos los involucrados y escale de manera oportuna para que el incumplimiento de los plazos no sorprenda a nadie.

Promocionar Degradar

Una pregunta que no se puede responder de forma breve. Si fuera sencillo, entonces no existiría el problema del incumplimiento de los plazos.

Para que los plazos de desarrollo sean más predecibles, primero debemos comprender las razones por las que los programadores cometen errores todo el tiempo.

La primera razón es que la mayoría de las tareas que realiza un programador son únicas en un grado u otro. Es decir, lo más probable es que el programador realice una tarea similar por primera vez. No tiene una idea clara de cuánto tiempo llevará este trabajo. Si se trata de un programador con sólida experiencia y tuvo que realizar una tarea similar, su valoración se acercará más a la realidad.

Usemos una analogía simple: si nunca ha cavado zanjas, no podrá decir exactamente cuánto tiempo le llevará cavar una zanja de 30 cm de ancho, 60 cm de profundidad y 20 metros de largo. Si ha excavado antes, su estimación del tiempo de trabajo será mucho más cercana a la duración real del trabajo.

La segunda razón es que los programadores son optimistas por naturaleza. Es decir, al considerar una tarea, seleccionar una opción de implementación para ella y evaluar mejoras, el desarrollador espera que todo funcione como él espera. Y no piensa en los problemas que encontrará en el camino. A menudo no puede preverlos. Por ejemplo, existe una tarea que un programador puede implementar utilizando una biblioteca de software de código abierto de terceros. En la etapa de evaluación, lo encontró en Internet, leyó su descripción: le conviene. E incluso estimó correctamente la cantidad de trabajo que tendría que hacer para aprovechar esta biblioteca. Pero no previó en absoluto que en esta biblioteca se produciría un error en el entorno de su producto de software.

El desarrollador no sólo tendrá que incorporar el uso de la biblioteca en su código, sino también corregir un error en la propia biblioteca. Y a menudo el desarrollador no da tiempo para corregir sus errores. Las estadísticas muestran que probar y corregir errores puede ocupar aproximadamente el 50% del tiempo dedicado a la codificación. La cifra depende de las calificaciones del desarrollador, el entorno y las prácticas de desarrollo utilizadas (por ejemplo, las pruebas unitarias reducen significativamente este tiempo y la duración final/intensidad de mano de obra de la tarea de desarrollo es menor).

Si volvemos a la analogía con el excavador, éste no esperaba que su pala se rompiera y tendría que pasar dos horas buscando un nuevo corte.

La tercera razón son las necesidades imprevistas. En ningún otro ámbito de la producción de materiales, con el que a los clientes les gusta tanto comparar el desarrollo de software, existe tal flujo de nuevas necesidades. Imagínese el paso de un excavador que excavó 19 metros de 20 y escuchó del cliente el deseo de que la zanja no fuera en línea recta, sino en una serpiente con un brazo de 97 centímetros de largo.

¿Cómo afrontar todo esto y cómo vivir en condiciones de tanta incertidumbre? Reducir la incertidumbre y crear reservas de tiempo.

La forma más sencilla de acercar sus expectativas a la realidad es utilizar la divertida regla general de Pi. Habiendo recibido una estimación del desarrollador (en términos de tiempo o intensidad de mano de obra), debe multiplicarla por Pi (= 3,14159). Cuanto más experiencia tenga el desarrollador en la evaluación, menor será esta proporción.

Es obligatoria la práctica de descomponer el problema original en pequeñas tareas de no más de 4 horas de duración. Cuanto más detallada sea la descomposición, mayores serán las posibilidades de que la estimación se acerque a la complejidad/duración real.
Si volvemos a la asignación de reserva, este tiempo debería asignarse al final del proyecto. Es una mala práctica hacer una reserva e incluirla para cada tarea. Se sigue estrictamente la ley de Parkinson: “El trabajo ocupa todo el tiempo que se le asigna”.

En resumen, para determinar correctamente los plazos de finalización del trabajo, serán útiles las siguientes acciones:

• realizar una descomposición del trabajo, dividiendo la tarea en pasos lo más detallados posible;
• realizar prototipos;
• limitar la implementación de requisitos previamente imprevistos. Esto no significa que no sea necesario realizarlos, pero es recomendable resaltar estos requisitos y acordar con el cliente los cambios en los tiempos y costos para su implementación;
• tener en cuenta el tiempo necesario para estabilizar la solución;
• utilizar prácticas para mejorar la calidad del código, como escribir pruebas unitarias;
• establecer una reserva general.

Bueno, recuerde que si un hecho excede su estimación en un 30%, entonces es un muy buen resultado.

Promocionar Degradar

Para una evaluación más precisa, necesita experiencia en desarrollo real, y específicamente en un área específica. Pero también existen reglas generales que te ayudarán a evitar errores en la planificación y problemas a la hora de entregar el trabajo al cliente. Yo describiría estas reglas así.

Primero, necesitas entender el problema. Esto parece obvio y no se relaciona directamente con las estimaciones de tiempo, pero de hecho es un punto clave. Incluso en proyectos grandes y serios, uno de los principales factores de fracaso y retraso es el problema a la hora de definir los requisitos. Desafortunadamente, para los desarrolladores principiantes, este es un problema grave: no leen las especificaciones técnicas o las leen y las comprenden de manera muy selectiva (de diez puntos, recordaron y completaron cinco, y recordaron el resto al enviar el resultado). Está claro que una tarea mal entendida no se puede implementar correctamente a tiempo.

Lo siguiente es estimar el tiempo de desarrollo en sí. La peculiaridad de la programación es que no existen tareas absolutamente idénticas. Esto hace que nuestro trabajo sea más interesante, pero estimar los plazos es más difícil. La descomposición funciona bien aquí, es decir dividir un problema complejo y único en una secuencia de subtareas pequeñas y familiares. Y cada uno de ellos ya se puede evaluar de forma bastante adecuada en horas. Sumemos las estimaciones de las subtareas y obtengamos una estimación para toda la tarea.

Como regla general, dicha estimación sólo incluye los costos de codificación en sí. Esta es, por supuesto, la parte más importante del desarrollo, pero está lejos de ser la única (y a menudo no la más voluminosa). La finalización completa de la tarea también incluye la lectura y aclaración de las especificaciones, reuniones con compañeros o con el cliente, depuración y pruebas, redacción de documentación, entrega del resultado (demostración al cliente y posibles modificaciones basadas en sus comentarios). Sólo la experiencia le dirá exactamente cuánto tiempo le llevará completar estas acciones. En un principio, es importante, como mínimo, no olvidarse de tenerlos en cuenta en los cálculos, pudiendo pedir a compañeros más experimentados una estimación aproximada del tiempo.

Entonces, tomamos una estimación de los costos laborales para la codificación, agregamos una estimación de los costos de trabajo adicional y obtenemos la estimación requerida del tiempo para completar la tarea. ¡Pero eso no es todo! Debe indicar la fecha prevista de finalización de la tarea. Sería un error simplemente dividir los costos laborales (en horas) entre 8 horas y sumarlos a la fecha actual. En la práctica real, un desarrollador nunca (bueno, casi nunca) trabaja el 100% del tiempo en una tarea específica. Definitivamente dedicará tiempo a otro trabajo, importante, pero no directamente relacionado con el principal. Por ejemplo, ayudar a compañeros, formar, redactar informes, etc. Normalmente, al planificar, se cree que entre el 60 y el 70% del tiempo de trabajo se dedica directamente a trabajar en el proyecto actual. Además, debe tener en cuenta posibles retrasos que le impedirán trabajar continuamente en la tarea. Por ejemplo, si para ello necesita interactuar con otras personas (colegas, clientes), tenga en cuenta su disponibilidad, horario de trabajo, etc.

Estas son las reglas básicas que, en mi opinión, ayudarán al desarrollador a evitar problemas a la hora de estimar y cumplir los plazos. Además, la clave es acumular experiencia propia tanto en la implementación de tareas como en la evaluación. Por ejemplo, es muy útil después de completar una tarea comparar su estimación inicial con los plazos reales y sacar conclusiones para el futuro. Y, por supuesto, vale la pena estudiar las experiencias de otras personas. Recomendaría los libros sobre el tema de S. McConnell "Cuánto cuesta un proyecto de software" y S. Arkhipenkov "Conferencias sobre gestión de proyectos de software".

Promocionar Degradar

Al estimar y planificar los plazos, debe:

1. Descomponga la tarea en pequeñas partes funcionales de tal manera que haya una comprensión clara de cuánto tiempo llevará desarrollar cada una de esas partes.
2. Paralelamente a la descomposición, seguramente surgirán preguntas adicionales sobre funcionalidades que no se describieron en el planteamiento del problema. Es necesario obtener respuestas a estas preguntas, ya que esto está directamente relacionado con el alcance del trabajo y, por tanto, con el calendario.
3. Añadir un determinado porcentaje de riesgos a la evaluación final. Esto se determina empíricamente. Puede empezar, por ejemplo, con riesgos del 10 al 15%.
4. Comprenda cuántas horas al día está dispuesto a dedicar un programador para completar una tarea.
5. Dividimos la estimación final por la cantidad de horas que asignamos por día y obtenemos la cantidad de días necesarios para la implementación.
6. Nos centramos en el calendario y en el número de días necesarios para completar. Tenemos en cuenta los fines de semana y otros días en los que el programador no podrá trabajar en la tarea, así como la fecha de inicio del trabajo (el desarrollador no siempre está listo para asumir la tarea el mismo día). Así, obtenemos la fecha de inicio y finalización del trabajo.

Promocionar Degradar

En nuestra empresa, la planificación de tareas siempre pasa por varias etapas. En el aspecto empresarial, formulamos 5 o 6 objetivos estratégicos para el año. Se trata de tareas de alto nivel, por ejemplo, aumentar algún parámetro en tanto por ciento. A continuación, varias divisiones de la empresa formulan tareas comerciales para todos los equipos de TI. Los plazos para estas tareas reciben una estimación inicial aproximada, que a menudo la elaboran todos los miembros del equipo: gerente, analista, desarrollador y evaluador. Una vez que la empresa recibe esta evaluación, prioriza las tareas en función de los objetivos estratégicos de la empresa. En esto ayudan los objetivos estratégicos transversales; con ellos, resulta obvio que todos trabajamos por una causa común; no existe tal situación en la que alguien solo tira en su propia dirección. Recopilamos sprints de tareas estimadas con precisión en términos de plazos. Para algunos equipos son trimestrales, para otros son mensuales. Para varias tareas que, según estimaciones preliminares, caerán en el próximo sprint, los equipos dan una estimación precisa. Las tareas grandes se dividen en otras de nivel inferior, de cada una de las cuales es responsable un ejecutante específico, y es él quien da una evaluación precisa.

En esta etapa, es importante no olvidar agregar una reserva de tiempo para corregir errores, porque solo quien no hace nada no comete errores. Tanto los Product Owners como los clientes empresariales lo entienden muy bien. Al mismo tiempo, el tiempo necesario debe ser el adecuado: nadie entenderá a un desarrollador que fija un plazo demasiado largo para una tarea sencilla; se le pedirá que justifique su decisión. Lo más difícil es explicarle a la empresa por qué lleva tiempo refactorizar. Agradecemos a nuestra empresa el hecho de que de vez en cuando lo logramos, porque en última instancia, la refactorización conduce a la simplificación de la infraestructura y al ordenamiento del código, lo que aumenta la estabilidad del sistema y puede acelerar significativamente el desarrollo. de nuevas funciones.

A veces todavía se producen errores en la evaluación. En mi opinión, esto es imposible para el departamento de desarrollo de grandes empresas con infraestructura desarrollada. En este caso, es importante que el desarrollador informe rápidamente a su gerente sobre lo que está sucediendo, y él, a su vez, logra advertir a la empresa y "reproducir" algo en los planes generales de la empresa. Trabajar en este modo es mucho más correcto que intentar desesperadamente hacer en 3 días lo que lleva 5 y luego ahogarse en una gran cantidad de errores que surgieron debido a tanta prisa.

Promocionar Degradar

La respuesta correcta a ambas partes de la pregunta [cómo aprender a planificar correctamente y entregar un proyecto a tiempo - Rojo.] - experiencia. No hay otras formas de “conocer el Zen”. Según la teoría de la decisión, sólo se pueden sacar conclusiones precisas basándose en el análisis de una serie de datos ya disponibles. Y cuantos más datos haya, más precisa será la previsión y la evaluación final.

En palabras de Herbert Shaw: “La experiencia es la escuela en la que un hombre aprende lo tonto que era antes”. Esto lleva a una conclusión bastante simple: si un programador ya tiene experiencia que se correlaciona con la tarea en cuestión, puede confiar en ella; si no, puede confiar en la experiencia de sus "colegas".

A continuación, es necesario comprender que la planificación directa de los plazos es una tarea que la gente afronta muy, muy mal, especialmente en el desarrollo. Al estimar las fechas de vencimiento, se considera una buena práctica introducir “factores de ajuste” en la estimación original. Esta métrica puede oscilar entre 1,5 y 3, dependiendo de la experiencia del desarrollador y de la totalidad de grados de incertidumbre de las tareas que se resuelven dentro del proyecto.

Promocionar Degradar

Es importante considerar muchos factores al determinar los plazos.

Por ejemplo, experiencia laboral. ¿Con qué claridad entiende el alcance del trabajo por delante? ¿Has hecho algo como esto antes? Está claro que cuanta más experiencia, más rápido se completará el trabajo.

Una especificación técnica bien redactada juega un papel importante a la hora de determinar los plazos. Las cosas son muy difíciles con esto en nuestra zona. A menudo, el propio cliente no sabe lo que quiere, por lo que le aconsejo que dedique uno o dos días más, pero que el cliente le dé una idea clara del resultado deseado. Es importante que este entendimiento sea mutuo. Y solo después de esto podrás comenzar a negociar el monto y las condiciones.

Además, incluya siempre los riesgos. Para principiantes, recomiendo multiplicar el tiempo estimado de finalización por dos. Después de todo, es mejor entregar un proyecto antes de lo previsto y crecer como especialista ante los ojos del cliente, que entregarlo más tarde y arruinar su reputación.

Promocionar Degradar

Una recomendación general es que el desarrollador debe aprender a dividir correctamente las tareas, buscar siempre posibles errores, confiar en su propia experiencia y no olvidar advertir oportunamente a los clientes y colegas si la tarea no se puede resolver dentro del tiempo especificado. marco.

Elaborar un plan claro es mucho más difícil que determinar la fecha límite para completar una sola tarea. Al mismo tiempo, es importante no sólo entregar el proyecto a tiempo, sino también garantizar que el sistema que desarrolle resuelva correctamente los problemas comerciales. Aquí, los equipos de TI cuentan con la ayuda de varias metodologías de desarrollo de software: desde RUP y MSF hasta SCRUM y otros formatos ágiles. La elección de herramientas es muy amplia y muchos de nuestros clientes quieren saber de antemano cómo trabajaremos con ellas en el proyecto y a qué principios nos adherimos.

Por cierto, el tema Agile hoy se está acercando tanto a las empresas como a los proyectos individuales del sector público, ya que los principios de esta metodología permiten implementar proyectos muy rápidamente, gestionando las expectativas de los clientes en cada iteración. Por ejemplo, en un equipo Agile prácticamente no hay discusiones prolongadas con el cliente. Olvídese de docenas de páginas que describen detalles técnicos innecesarios, como la rapidez con la que aparece una lista desplegable. Ofrezca al cliente la oportunidad de probar una versión intermedia del sistema, entonces será mucho más fácil para ustedes entenderse.

El equipo Agile planifica todo en conjunto y determina el nivel óptimo de mano de obra que se necesitará para resolver un problema en particular. Por ejemplo, una de las técnicas se llama "Planificación del póquer", donde cada participante da de forma anónima su evaluación de los costos laborales necesarios para una tarea específica. Después de esto, el equipo determina el peso promedio de la tarea en puntos de historia u horas de trabajo y distribuye las tareas según el principio de "a quién le gusta qué". Al mismo tiempo, todos los días el equipo se reúne para una reunión de 15 minutos, cuando todos hablan en un par de minutos sobre el estado de sus tareas actuales, incluido informar sobre las dificultades que hayan surgido. El equipo soluciona rápidamente el problema detectado, de modo que el cliente pasa a la siguiente etapa del trabajo del programador lo más rápido posible. Los desarrolladores no retrasan la finalización de las tareas debido a la renuencia a molestar al equipo una vez más o intentos inútiles de resolverlo por sí mismos, matando un tiempo precioso. Por cierto, en estos mini-estados, los desarrolladores desean mostrar su mejor lado, demostrar que abordan su trabajo de manera responsable. Realmente motiva y autodisciplina.

(el tiempo de trabajo se incluye hasta que se completa en el caso de actividad periódica, o hasta que el sistema responde y entrega al primer usuario la salida en el caso de actividad interactiva); o maximización justicia(una cantidad igual de tiempo de CPU para cada proceso, o más generalmente tiempos correspondientes según la prioridad y carga de trabajo de cada proceso). En la práctica, estos objetivos suelen estar en conflicto (por ejemplo, rendimiento versus latencia), por lo que el programador realizará una compensación adecuada. La preferencia se mide por cualquiera de las cuestiones mencionadas anteriormente, dependiendo de las necesidades y objetivos del usuario.

OS/360 y sucesores

AIX

En AIX Versión 4, hay tres configuraciones posibles para la política de programación de subprocesos:

• Primero, primero en salir: una vez que se programa un subproceso con esta política, se ejecuta hasta su finalización, a menos que se bloquee, renuncie voluntariamente al control del procesador o se pueda distribuir un subproceso de mayor prioridad. Sólo los subprocesos de prioridad fija pueden tener una política de programación FIFO.
• Round Robin: Esto es similar al programador de circuitos de AIX Versión 3 que realiza ciclos basados ​​en intervalos de tiempo de 10 ms. Cuando un subproceso PP tiene control al final de un intervalo de tiempo, se mueve al final de la cola de subprocesos con la misma prioridad. Sólo los subprocesos de prioridad fija pueden tener una política de programación Round Robin.
• OTRO: Esta política está definida por la implementación en POSIX1003.4a. En AIX Versión 4, esta política se define como equivalente a RR, excepto que se aplica a subprocesos de prioridad no fija. Recalcular el valor de prioridad de un subproceso en ejecución para cada interrupción significa que un subproceso puede perder el control porque su valor de prioridad ha aumentado más que el de otro subproceso. Este es el comportamiento de AIX Versión 3.

Los subprocesos son de interés principalmente para aplicaciones que actualmente constan de múltiples procesos asincrónicos. Estas aplicaciones pueden imponer una carga ligera al sistema si se convierten a una estructura de subprocesos múltiples.

AIX 5 implementa las siguientes políticas de programación: FIFO, round robin y round robin justo. La política FIFO consta de tres implementaciones diferentes: FIFO, FIFO2 y FIFO3. La política de operación por turnos se llama SCHED_RR en AIX y la política de operación por turnos justa se llama SCHED_OTHER.

linux

Linux 2.4

Brain Fuck Scheduler (BFS), también creado por Kolivas, es una alternativa al CFS.

FreeBSD

FreeBSD utiliza una cola de comentarios de varios niveles con prioridades en el rango de 0 a 255. 0-63 están reservados para interrupciones, 64-127 para la mitad superior del kernel, 128-159 para subprocesos de usuario en tiempo real, 160-223 para subprocesos de usuario de tiempo compartido y 224-255 para subprocesos de usuario inactivos. Además, al igual que Linux, utiliza una configuración de cola activa, pero también tiene una cola inactiva.

Introducción

El objetivo del taller sobre organización de la producción es ampliar y profundizar los conocimientos teóricos, inculcar las habilidades necesarias para resolver los problemas más frecuentes en la práctica relacionados con la organización y planificación de la producción.

El taller incluye tareas para las secciones principales del curso. Al inicio de cada tema se presentan breves instrucciones metodológicas e información teórica, problemas típicos con solución y problemas para solución independiente.

La presencia de instrucciones metodológicas y breve información teórica en cada tema permite utilizar este taller para el aprendizaje a distancia.

Cálculo de la duración del ciclo de producción.

La duración del ciclo de producción sirve como indicador de la eficiencia del proceso de producción.

Ciclo productivo– el período de permanencia de los objetos de trabajo en el proceso de producción desde el momento del lanzamiento de las materias primas hasta el momento del lanzamiento de los productos terminados.

El ciclo de producción consiste en Horas Laborales, durante el cual se gasta trabajo, y Descansos. Las roturas, según los motivos que las provocaron, se pueden dividir en:

1) en natural o tecnológicos: están determinados por la naturaleza del producto;

2) organizativo(descansos entre turnos).

La duración del ciclo de producción consta de los siguientes componentes:

ciclo T = t esos + t come + t tr + t k.k. + t mes. + t m.ts.

Dónde t aquellos– tiempo de las operaciones tecnológicas;

t come - tiempo de los procesos naturales (secado, enfriamiento, etc.);

ttr- tiempo de transporte de objetos de trabajo;

t kk – tiempo de control de calidad;

t m.o – tiempo de atención interoperatoria;

t m.c. – tiempo de almacenamiento en almacenes entre tiendas;

(t tres t k.k. se puede combinar con t mes).

El cálculo del tiempo del ciclo de producción depende del tipo de producción. En la producción en masa, la duración del ciclo de producción está determinada por el tiempo que el producto está en producción, es decir,

ciclo T = t En m,

Dónde t V– carrera de liberación;

METRO- número de lugares de trabajo.

Bajo golpe de liberación es necesario comprender el intervalo de tiempo entre el lanzamiento de un producto fabricado y el siguiente.

La carrera de liberación está determinada por la fórmula.

t en = Teff /V,

Dónde tef– fondo efectivo de tiempo del trabajador para el período de facturación (turno, día, año);

EN– volumen de producción para el mismo período (en unidades naturales).

Ejemplo: Tcm = 8 horas = 480 min; T por = 30 min; → Tef = 480 – – 30 = 450 min.

B = 225 piezas; → t pulgadas = 450/225 = 2 min.

En la producción en serie, donde el procesamiento se realiza en lotes, la duración del ciclo tecnológico no se determina por unidad de producto, sino para todo el lote. Además, dependiendo del método de lanzamiento de un lote a producción, obtenemos diferentes tiempos de ciclo. Hay tres formas de mover productos en producción: secuencial, paralela y mixta (serie-paralelo).

I. En secuencial Al mover piezas, cada operación posterior comienza solo después de que finaliza la anterior. La duración del ciclo para el movimiento secuencial de piezas será igual a:

Dónde norte – número de partes del lote que se están procesando;

t piezasi- tiempo a destajo para una operación;

C yo– número de puestos de trabajo por iésima operación;

metro– número de operaciones del proceso tecnológico.

Se entrega un lote de productos compuesto por 5 piezas. El lote pasa secuencialmente por 4 operaciones; la duración de la primera operación es de 10 minutos, la segunda de 20 minutos, la tercera de 10 minutos y la cuarta de 30 minutos (Fig. 1).

Foto 1

t ciclo = túltimo = 5·(10+20+10+30) = 350 min.

El método secuencial de piezas móviles tiene la ventaja de que asegura el funcionamiento del equipo sin tiempos de inactividad. Pero su desventaja es que la duración del ciclo de producción en este caso es la más larga. Además, en los lugares de trabajo se crean importantes existencias de piezas, lo que requiere espacio de producción adicional.

II. En paralelo Durante el movimiento del lote, las piezas individuales no se detienen en los puestos de trabajo, sino que se transfieren individualmente a la siguiente operación inmediatamente, sin esperar a que finalice el procesamiento de todo el lote. Así, durante el movimiento paralelo de un lote de piezas, en cada lugar de trabajo se realizan simultáneamente varias operaciones sobre diferentes piezas de un mismo lote.

El tiempo de procesamiento de un lote con movimiento paralelo de productos se reduce drásticamente:

dl .

Dónde nn– número de piezas en transferir lote(lote de transporte), es decir el número de productos transferidos simultáneamente de una operación a otra;

Longitud: el ciclo operativo más largo.

Al lanzar un lote de productos en paralelo, las partes de todo el lote se procesan de forma continua sólo en aquellos lugares de trabajo donde las operaciones largas siguen a las cortas. En los casos en que las operaciones cortas siguen a las largas, es decir Más tiempo (en nuestro ejemplo, la tercera operación), estas operaciones se realizan de forma discontinua, es decir. el equipo está inactivo. Aquí, un lote de piezas no se puede procesar inmediatamente, sin demoras, ya que la operación anterior (larga) no lo permite.

En nuestro ejemplo: norte= 5, t 1 = 10; t 2 = 20; t 3 = 10; t 4 = 30; Con= 1.

t vapor = 1·(10+20+10+30)+(5-1)·30=70+120 = 190 min.

Consideremos el diagrama de movimiento paralelo de piezas (Fig.2):

Figura 2

III. Para eliminar interrupciones en el procesamiento de partes individuales de un lote en todas las operaciones, utilice serie paralela o mezclado un método de lanzamiento en el que las piezas (después del procesamiento) se transfieren a la siguiente operación una por una, o en forma de lotes de "transporte" (varias piezas) de tal manera que la ejecución de las operaciones no se interrumpa en ningún lugar de trabajo. En el método mixto, la continuidad del procesamiento se toma del método secuencial, y la transición de la pieza de operación a operación inmediatamente después de su procesamiento se toma del método paralelo. Con un método mixto de lanzamiento a producción, la duración del ciclo está determinada por la fórmula

centro .

donde esta el cor. – el ciclo operativo más corto (de cada par de operaciones adyacentes);

metro-1 – número de combinaciones.

Si la operación posterior es más larga que la anterior o igual en tiempo, entonces esta operación se inicia individualmente, inmediatamente después de procesar la primera parte de la operación anterior. Si por el contrario el siguiente paso es más corto que el anterior, entonces se producen interrupciones durante la transferencia de piezas. Para evitarlos, es necesario acumular una reserva de transporte de un volumen tal que sea suficiente para garantizar el trabajo en la operación posterior. Para encontrar prácticamente este punto en el gráfico, es necesario transferir la última parte del lote y mover la duración de su ejecución hacia la derecha. El tiempo de procesamiento de todas las demás piezas del lote se representa a la izquierda del gráfico. El inicio del procesamiento de la primera parte indica el momento en que el retraso en el transporte de la operación anterior debe transferirse a esta operación.

Si las operaciones adyacentes tienen la misma duración, entonces solo una de ellas se considera corta o larga (Fig. 3).

figura 3

túltimos pares = 5·(10+20+10+30)-(5-1)·(10+10+10) = 350-120 = 230 min.

Las principales formas de reducir el tiempo del ciclo de producción son:

1) Reducir la intensidad de mano de obra en la fabricación de productos mejorando la capacidad de fabricación del diseño fabricado, utilizando computadoras e introduciendo procesos tecnológicos avanzados.

2) Organización racional de los procesos laborales, disposición y mantenimiento de los lugares de trabajo en base a la especialización y cooperación, amplia mecanización y automatización de la producción.

3) Reducción de diversas pausas laborales planificadas y no planificadas con base en el uso racional de los principios de organización científica del proceso productivo.

4) Aceleración de reacciones como resultado del aumento de presión, temperatura, transición a un proceso continuo, etc.

5) Mejorar los procesos de transporte, almacenamiento y control y combinarlos en el tiempo con el proceso de elaboración y montaje.

Reducir la duración del ciclo de producción es una de las tareas serias de la organización de la producción, porque afecta la rotación del capital de trabajo, reduciendo los costos laborales, reduciendo el espacio de almacenamiento, la necesidad de transporte, etc.

Tareas

1 Determinar la duración del ciclo de procesamiento de 50 piezas con tipos de movimiento secuencial, paralelo y serie-paralelo en el proceso de producción. El proceso de procesamiento de piezas consta de cinco operaciones, cuya duración es, respectivamente, mínima: t 1 =2; t 2 =3; t 3 =4; t 4 =1; t 5 = 3. La segunda operación se realiza en dos máquinas y cada una de las demás en una. El tamaño del lote de transferencia es de 4 piezas.

2 Determinar la duración del ciclo de procesamiento de 50 piezas con tipos de movimiento secuencial, paralelo y serie-paralelo en el proceso productivo. El proceso de procesamiento de piezas consta de cuatro operaciones, cuya duración es, respectivamente, mínima: t 1 =1; t 2 =4; t 3 =2; t 4 = 6. La cuarta operación se realiza en dos máquinas y cada una de las demás en una. El tamaño del lote de transferencia es de 5 piezas.

3 Durante el proceso de producción se procesa un lote de piezas de 200 piezas con movimiento secuencial paralelo. El proceso de procesamiento de piezas consta de seis operaciones, cuya duración es, respectivamente, mínima: t 1 =8; t 2 =3; t 3 =27; t 4 =6; t 5 =4; t 6 = 20. La tercera operación se realiza en tres máquinas, la sexta en dos y cada una de las operaciones restantes en una máquina. Determine cómo cambiará la duración del ciclo de procesamiento de un lote de piezas si la versión secuencial paralela del movimiento en producción se reemplaza por una paralela. El tamaño del lote de transferencia es de 20 piezas.

4 Durante el proceso de producción se procesa un lote de piezas de 300 piezas con movimiento secuencial paralelo. El proceso de procesamiento de piezas consta de siete operaciones, cuya duración es, respectivamente, mínima: t 1 =4; t 2 =5; t 3 =7; t 4 =3; t 5 =4; t 6 =5; t 7 = 6. Cada operación se realiza en una máquina. Lote de transferencia – 30 piezas. Como resultado de la mejora de la tecnología de producción, la duración de la tercera operación se redujo en 3 minutos, la séptima en 2 minutos. Determine cómo cambia el ciclo de procesamiento de un lote de piezas.

5 Se entrega un lote de espacios en blanco que consta de 5 piezas. El lote pasa por 4 operaciones: la duración de la primera es de 10 minutos, la segunda de 20 minutos, la tercera de 10 minutos y la cuarta de 30 minutos. Determinar la duración del ciclo mediante métodos analíticos y gráficos con movimiento secuencial.

6 Se entrega un lote de espacios en blanco que consta de cuatro piezas. El lote pasa por 4 operaciones: la duración de la primera es de 5 minutos, la segunda de 10 minutos, la tercera de 5 minutos y la cuarta de 15 minutos. Determinar la duración del ciclo mediante métodos analíticos y gráficos con movimiento paralelo.

7 Se entrega un lote de espacios en blanco que consta de 5 piezas. El lote pasa por 4 operaciones: la duración de la primera es de 10 minutos, la segunda de 20 minutos, la tercera de 10 minutos y la cuarta de 30 minutos. Determine la duración del ciclo mediante métodos analíticos y gráficos para el movimiento en serie-paralelo.

8 Determine la duración del ciclo tecnológico para procesar un lote de productos de 180 piezas. con variantes paralelas y secuenciales de su movimiento. Construir gráficos de procesos de procesamiento. El tamaño del lote de transferencia es de 30 unidades. Los estándares de tiempo y número de trabajos en operaciones son los siguientes.

Todo lo descrito en los apartados anteriores estuvo más orientado a una mayor investigación sobre el problema del tiempo propio del proceso y en mucha menor medida a sus aplicaciones prácticas. Cubriendo este vacío, esbozaremos una de las formas de calcular el tiempo adecuado de un proceso a partir de datos estadísticos sobre su evolución.

Consideremos un proceso unidimensional, cuyo estado se caracteriza por una variable real x. Supongamos que las observaciones de la dinámica del proceso se realizan en el tiempo astronómico t, de modo que t = t k y x = x k, k =1, ..., n son momentos fijos de observación y los valores correspondientes de afirma el proceso. Existen muchos métodos matemáticos diferentes que hacen posible construir curvas que pasen por los puntos (t k, Xk) o que se acerquen mejor a ellos. Las funciones x = x(t) así obtenidas nos dan la impresión de que el proceso considerado depende del movimiento mecánico de los cuerpos celestes y, por tanto, su estado se expresa a través del tiempo astronómico t. Esta conclusión podría tenerse en cuenta; si no surgieran constantes dificultades al intentar predecir el curso posterior del proceso. Para una gran cantidad de procesos diferentes que no están directamente relacionados con los movimientos mecánicos de los cuerpos celestes, las predicciones teóricas obtenidas utilizando la función x = x(t) fuera del intervalo de observación comienzan a desviarse significativamente de los datos experimentales posteriores. Por lo general, intentan explicar el motivo de la discrepancia entre teoría y experimento mediante un método de procesamiento seleccionado sin éxito, pero puede que esto no sea la esencia del asunto.

Cualquier proceso que nos interese ocurre en el Universo. Ciertamente "siente" la influencia del movimiento de los cuerpos celestes. Sin embargo, esta influencia puede resultar “no rígida”, no determinante. Esto, en particular, puede manifestarse en el hecho de que en ciertos intervalos de tiempo astronómico el estado del proceso permanece sin cambios. En este sentido, recordemos el ejemplo anterior de una habitación cerrada y vacía, aislada del mundo exterior. Dejemos que una sola persona viva entre en la habitación. A lo largo de varios días, los cambios en el estado del sistema “room-fly” dependerán de los movimientos de la mosca, ya que no se pueden esperar cambios en el estado de la habitación. Al mismo tiempo, es difícil imaginar que el comportamiento de una mosca esté estrictamente relacionado con el curso del tiempo astronómico.

Habiendo hecho una digresión tan larga, pasemos a describir el algoritmo para calcular el tiempo propio del proceso.

En este algoritmo, la unidad para calcular los máximos locales se elige como una medida natural de tiempo. Además, se tienen en cuenta posibles tramos del estado estacionario del proceso en los que, como se señaló anteriormente, se detiene el tiempo adecuado. Dado que la identidad de dos estados sólo puede determinarse dentro de los límites de la precisión de la medición, a continuación se utiliza un cierto número positivo e: el error de medición permisible.

Entonces, los datos de entrada para el algoritmo son el número natural n, el número positivo 8, matrices (tk) y (x k), k = 1, ..., n. Para facilitar la programación, el algoritmo se presenta en la forma de cuatro módulos ejecutados secuencialmente.

Módulo 1, utilizando los datos p, e, t k), (x k), en el caso general, se forman nuevas matrices 7 = (7+ X = (X t) y una matriz adjunta muy específica P = (?), donde 1 = 1, ..., t, y t<Сп. Основное назначение этого модуля -- выявление в массиве x k) последовательностей идентичных состояний процесса, сохранение первых элементов в таких последовательностях и удаление всех остальных и, наконец, уменьшение по определенному, правилу исходного интервала наблюдения от t до на сумму тех промежутков времени, в которых процесс протекает стационарно.

El módulo 1 incluye los siguientes procedimientos:

p: = 1, t: = 0, k: = 1.

En págs. 1, se introducen 2 contadores con valores iniciales específicos:

En págs. 3, 4 los valores del contador aumentan en 1.

Verifique la condición k^n. Si está completo, vaya al paso 6; de lo contrario, vaya al paso 11.

Verifique la desigualdad x k --x k = e. Si se cumple, vaya al paso 7; de lo contrario, vaya al paso 9.

7. tii = ti - (tkl - tk), i = k1, ..., pág.

Este procedimiento significa que si los valores de Xk y Xk 1 son indistinguibles dentro del error, entonces todos los puntos de tiempo a partir de tk se reducen en la cantidad tki-tk.

r=r. Volver al punto 4.

Tv = tk; Xv:=xk; p = p v = v+l., es decir Se forman elementos de las matrices T, X, P y se asigna el siguiente valor v.

• 10. Tome (t k, ..., t n AND (Xk, - X n) como las matrices originales de dimensión n--k 1 + 1 y luego regrese al paso 2.
• 11. Imprima m, (T), (X,) y (P,), donde i = l, ..., t. Fin.

Expliquemos el significado de los elementos de la matriz P que la acompaña. Del texto anterior se deduce que el valor de pk es igual al número de aquellos elementos de la matriz (xk) que siguen directamente y difieren de x pi+ ... +, + por menos que e. También observamos que pi+ ... +p m = n.

Ejemplo 1. Dado: n = 20, (/*) = (2, 4, 7, 10, 12, 13, 15, 17, 20, 22, 24, 25,

• 27, 30, 32, 33, 34, 35, 36) y (x,)= (4, 4, 6, 6, 6, 3, 2, 4, 3, 3, 3, 2, 2, 4, 5 , 5,
• 5, 4, 3), ver fig. 9, a.

Como resultado de ejecutar el módulo 1 se obtiene m = 11,

(G) = (2, 3, 4, 6, 8, 11, 1-2, 15, 17, 18, 19); (X,) = (4, 6, 3, 2, 4, 3, 2, 4,5,4,3)

yo(d.) = (2, 4, 1, 1, 1.3, 2, 1.3, 1, 1), ver fig. 9, b.

Módulo 2. Los datos de entrada para ello son un número natural m, así como matrices (7+ (X L), = 1, ..., m. Este módulo en la matriz (TJ identifica momentos de tiempo [TM a], 1 = 1 m (ml)

Ejemplo 2. Los valores m, (Ть) y (X,] están tomados del ejemplo anterior. Después de completar el módulo 2, obtenemos ml = 3, m2 = 8, (Ш,) = (3, 8, 17 ), (Т*) = (3, 4, 6, 8, 11, 12, 15, 17), ver también Fig. 9, b.

Módulo 3. Datos de entrada ml, m2, (TM n), 1 = 1, ..., ml, (G*), /2 = 1, ..., gn2.

Este módulo está diseñado para construir una matriz (t(-r) usando la fórmula

¿Dónde está TV 6 [TMp, TMn+i]

La variable t es el tiempo propio generado por el cambio en la variable x. Su medida natural es la unidad para calcular los máximos locales.

Ejemplo 3. Los datos iniciales para T 2) son los mismos que los valores de ml, m2 ITM, y en el ejemplo 2. . Después de los cálculos adecuados, obtenemos Н = (0; 0,2; 0,6; 1; 1,33; 1,78; 2).

Módulo 4. Genera la salida de resultados estableciendo una correspondencia entre los valores de m y los elementos x del arreglo (xk).

Ejemplo 4. Con base en los datos de los ejemplos 2 y 3, se produce el siguiente resultado, ver fig. 9, en:

t: 0; 0,2; 0,6; 1; 1,33; 1,44;

x: 6; 3; 2; 4; 3T 0 2;

Así, el algoritmo considerado nos permite desarrollar el concepto del tiempo propio del proceso a partir de información sobre los cambios en el estado del proceso registrados en la escala de tiempo astronómica. Está bastante claro que se pueden utilizar otros algoritmos, basados, por ejemplo, en el cálculo de una secuencia de mínimos locales o una secuencia mixta que consta de máximos y mínimos locales. Al procesar datos experimentales, probablemente deberían probarse varias opciones. Si por alguna razón el experimentador eligió uno de los tiempos adecuados específicos y recibió matrices (t4 y (xk), entonces en la siguiente etapa debería usar algunos métodos matemáticos para aproximar los puntos experimentales (t*, x) a alguna línea mundial aproximada de el proceso x = x(t).Al extrapolar esta línea más allá del período de observación inicial, puede hacer predicciones sobre el curso posterior del proceso.

Es interesante mencionar un experimento computacional destinado a evaluar las perspectivas de utilizar el algoritmo propuesto. Se eligieron como material experimental datos sobre los caudales anuales de los ríos. Vakhsh (Tayikistán) durante los 40 años anteriores. Durante el mismo período, se obtuvo información sobre la dinámica del número de Wolf, el índice integral de actividad solar más utilizado. Este último fue la base para desarrollar el momento adecuado del proceso de actividad solar. En los tiempos modernos, la información sobre los gastos fluviales se ha transformado. Vakhsh y luego, durante el período de observación, se dio una dependencia teórica del flujo de agua en función del momento adecuado de la actividad solar. Un rasgo característico del gráfico resultante es el comportamiento casi periódico de los gastos máximos y mínimos. Los costos, sin embargo, no permanecen constantes.