Blog

Como muchas comodidades en el desarrollo de software, una base de datos compartida es un pozo de alquitrán esperando fosilizar un proyecto. Los desarrolladores sobrescriben los cambios de los demás. Los cambios que hago en el servidor rompen el código de su máquina de desarrollo. El desarrollo remoto es lento y difícil. Evite a toda costa el uso de una base de datos compartida, ya que, en última instancia, hacen perder tiempo y contribuyen a producir errores.

Hablamos sin cesar de mejorar la calidad del software y reducir los riesgos, pero el software implementable es el activo más tangible para los “externos”. como clientes o usuarios. No se puede subestimar la importancia de este punto.

Puede administrar los ámbitos de tiempo, costo y calidad de manera mucho más efectiva al basar sus decisiones en software funcional con comentarios y métricas reales, no solo elementos de tareas en un cronograma de proyecto.

Para encontrar la carga del sistema, utilice el siguiente fragmento de Perl: Carga del sistema del último minuto: my $system_load = exec('<a class="zem_slink" title="Uptime" rel="wikipedia" href="http://en.wikipedia.org/wiki/Uptime">uptime</a> | awk -F "load average: " \'{ print $2 }\' | cut -d, -f1'); my $system_load = qx('uptime | awk -F "load average: " \'{ print $2 }\' | cut -d, -f1'); Carga del sistema de los últimos 5 minutos: my $system_load = exec('uptime | awk -F "load average: " \'{ print $2 }\' | cut -d, -f2'); my $system_load = qx('uptime | awk -F "load average: " \'{ print $2 }\' | cut -d, -f2'); Carga del sistema de los últimos 15 minutos: my $system_load = exec('uptime | awk -F "load average: " \'{ print $2 }\' | cut -d, -f3'); my $system_load = qx('uptime | awk -F "load average: " \'{ print $2 }\' | cut -d, -f3');

Si recibe el siguiente error al ejecutar el código del cliente: No se puede llamar al método “syswrite” en un valor indefinido en /usr/local/share/perl/5.10.1/Gearman/Taskset.pm línea 202. … entonces cambia esto $client->job_servers('127.0.0.1'); a $client->job_servers('127.0.0.1:4730'); ¡eso es todo! 🙂

Un conjunto de requisitos está completo si y sólo si describe todos los requisitos importantes que preocupan al usuario, incluidos los requisitos asociados con la funcionalidad, el rendimiento, las restricciones de diseño, los atributos o las interfaces externas.

Así como no existe un lenguaje de programación adecuado para cada aplicación, tampoco existe una forma correcta de desarrollar especificaciones más detalladas. Diferentes entornos requieren diferentes técnicas, y los administradores y redactores de requisitos probablemente necesitarán desarrollar una combinación de habilidades adecuadas a diversas circunstancias.

El proceso de desarrollo del equipo define quién hace qué, cuándo y cómo. En el modelo en cascada, las actividades del software avanzan a través de una secuencia de pasos, y cada paso se basa en las actividades del paso anterior. El modelo en espiral comienza con una serie de prototipos basados ​​en riesgos, seguidos de un proceso estructurado en forma de cascada. El enfoque iterativo, un híbrido de los modelos en cascada y en espiral, desacopla las fases del ciclo de vida de las actividades de software que tienen lugar en cada fase. Independientemente del modelo que utilice, debe desarrollar al menos un prototipo inicial para obtener comentarios de los clientes.

Algunas personas pueden pensar que la mejor manera de estimar un proyecto es tener requisitos detallados e información de diseño para cada característica. Pueden argumentar que esta es la forma más profesional y precisa de abordar el problema. Sin embargo, no estoy de acuerdo con esta opinión. Creo que es más importante poder tomar decisiones rápidas sobre el alcance del proyecto sin gastar demasiado tiempo y recursos en estimaciones detalladas. ¿Por qué? Porque las estimaciones detalladas a menudo resultan erróneas o irrelevantes más adelante, y crean un “inventario desperdiciado” que podría haberse utilizado para actividades más valiosas. Le sugiero que sólo haga estimaciones detalladas cuando el cronograma lo permita y cuando tenga una comprensión clara del valor y la prioridad de cada característica.

In many projects, in order to provide a reasonable probability of success, it will be necessary to reduce the scope by as much as a factor of two.