Telefónica de Perú atribuye a un error del software los

problemas de acceso a Internet

Actualizado 27-09-2008

Lima.- La empresa Telefónica de Perú atribuyó hoy los problemas de acceso a Internet sufridos
el pasado miércoles en Chile, Bolivia, Uruguay y este país a un error de configuración del
software de su proveedora del servicio.

La compañía de capital español explicó en un comunicado que las fallas en su proveedora

TIWS provocaron una saturación en el tráfico del servicio en Perú y Chile, y de manera parcial
en Bolivia y Uruguay.

Sin embargo, puntualizó que "la red de TIWS se encuentra supervisada y gestionada desde un
centro internacional de control en Madrid, España, las 24 horas del día, los siete días de la
semana".

En ese sentido, "este centro localizó y corrigió el problema en el menor plazo posible", agregó
Telefónica.

La gigante de telecomunicaciones ha pedido a TIWS las acciones que se implementarán para

evitar que se repita este tipo de problemas y además ha decidido ampliar sus sistemas de
respaldo con un proveedor alternativo.

Telefónica insistió en que "las páginas web situadas en el Perú pudieron ser accedidas
prácticamente con normalidad", aunque se conoció que en algunos distritos de Lima fue
prácticamente imposible durante unas dos horas.

El ministerio de Transportes y Comunicaciones (MTC) de Perú solicitó ayer a la filial peruana de

Telefónica un informe preliminar sobre los problemas ocurridos el miércoles de acceso a
Internet, que afectó a varios países de la región.

La viceministra de Comunicaciones, Lucía Cayetana Aljovín, dijo que se solicitó a Telefónica

que entregue el informe a la mayor brevedad posible y que además, las autoridades del país
investigan los hechos.

Chevrolet Perú revisará automóviles por error en software de modelos Suburban, Silverado y
Tahoe

Jueves, 13 de octubre del 2016

Las unidades involucradas en esta campaña de prevención corresponden a las

fabricadas entre los años 2014 y 2016.

Un total de 133 vehículos de la Chevrolet que involucra los modelos Suburban,

Silverado y Tahoe serán sometidos a revisión por un defecto en el módulo de
detección y diagnóstico, informó General Motors Perú S.A. al Instituto Nacional de
Defensa de la Competencia y de la Protección de la Propiedad Intelectual (Indecopi).

Los vehículos involucrados en esta campaña corresponden a los fabricados entre los
años 2014 y 2016. De estas unidades, 49 están en poder del consumidor final, 78 en
stock del concesionario y seis en stock de la empresa.

Además, General Motors Perú indicó que, en algunos vehículos se detectó que el
módulo de detección y diagnóstico presenta un error de software.

Este módulo controla el despliegue del airbag (bolsa de aire) y los pretensionadores
del cinturón de seguridad (dispositivo que compensa el alargamiento de los cinturones
bajo la acción del cuerpo y lo mantiene apoyado contra el respaldo del asiento).

De esta manera se impediría el despliegue de los airbags frontales y

‘pretensionadores’, por lo que existiría un mayor riesgo de lesiones de producirse un
accidente.

La empresa se comunicará con los propietarios de los vehículos a fin de informarles los
alcances de la revisión. Incluso, los usuarios pueden acercarse al
concesionario Chevrolet más cercano para que se realice la inspección de sus
vehículos.

Indecopi estará atenta al cumplimiento de tales acciones para garantizar que los
derechos de los consumidores sean respetados, de acuerdo al Código de Protección y
Defensa del Consumidor.

REVELAN ERRORES EN LOS PASAPORTES BIOMÉTRICOS 23 oct. 2016

Un informe interno de la misma Oficina de Dirección de Migraciones

corrobora lo que se venía sospechando. Y es que el apuro del gobierno de
Ollanta Humala para la emisión del famoso pasaporte biométricoterminó
generando una serie de problemas que incluso podrían poner en peligro el
actual abastecimiento de los mismos.
Uno de los errores más frecuentes de los pasaportes biométricos es el
desprendimiento de la lámina de seguridad, así como también errores en la
información, en el software e impresión. Todo ello en un sistema
recientemente implementado y que costó 102 millones de soles a todos los
peruanos.
Estos problemas se dieron debido a que la empresa francesa que ganó la
licitación de los pasaportes biométricos, se saltó fases, no terminó la etapa de
implementación y empezó a emitir los pasaportes antes de la fecha estipulada
en el contrato. Más detalles en el siguiente informe.

Tarea Plus

Errores en el mundo:

Un error de software de JBoss

Un error de software de JBoss Deja al descubierto millones de escuelas en
todo el mundo

[20/04/2016] Era una cuestión de tiempo que los colegios se vieran expuestos a los
peligros que implica el aula conectada; uno de los primeros casos se ha dado en
EE.UU., con el descubrimiento de un importante agujero de seguridad en el servidor de
aplicaciones JBoss.
Según ha alertado la organización Talos de Cisco, especializada en detección de
amenazas, cerca de 3,2 millones de máquinas están en peligro de ser atacadas en todo el
mundo. En concreto, más de dos mil máquinas han sido ya infectadas mediante una
versión de JBoss sin parchear, y podrían ser usadas en cualquier momento como
ventana al ransomware.

2. El hundimiento del Hartford Coliseum (1978)

Coste: 70 millones de dólares, más otros 20 millones en daños a la economía local.

Desastre: Sólo unas horas después de que miles de aficionados al hockey abandonaran
el Hartford Coliseum, la estructura de acero de su techo se desplomaba debido al peso de
la nieve.

Causa: El desarrollador del software de diseño asistido (CAD) utilizado para diseñar el
coliseo asumió incorrectamente que los soportes de acero del techo sólo debían aguantar
la compresión de la propia estructura. Sin embargo, cuando uno de estos soportes se
dobló debido al peso de la nieve, inició una reacción en cadena que hizo caer a las demás
secciones del techo como si se tratara de piezas de dominó.

3. La CIA le da gas a los soviéticos (1982)

Coste: Millones de dólares, daño significativo a la economía soviética.

Desastre: El software de control se volvió loco y produjo una presión excesiva en la

tubería de gas transsiberiana, provocando la mayor explosión no nuclear, causada por el
hombre, de la historia de la tierra.

Causa: los agentes de la CIA supuestamente introdujeron un error en el sistema

informático canadiense adquirido por los soviéticos para controlar sus tuberías de gas. La
compra era parte de un estratégico plan soviético para robar u obtener de forma encubierta
tecnología secreta de los Estados Unidos. Cuando la CIA descubrió la compra, sabotearon
el software de forma que éste superara la inspección soviética pero fallara una vez
operativo.

4. La Tercera Guerra Mundial… o casi (1983)

Coste: prácticamente toda la humanidad.

Desastre:: El sistema soviético de alerta temprana indicó erróneamente que los Estados
Unidos habían lanzado cinco misiles balísticos. Afortunadamente, el oficial de servicio, con
un gran instinto, razonó que si realmente les estuvieran atacando les habrían lanzado más
de cinco misiles, por lo que informó del aparente ataque como una falsa alarma.

Causa: un error en el software soviético hizo que los efectos de la reflexión de la luz solar
en las nubes fueran considerados misiles por el sistema.

5. La máquina asesina (1985)

Coste: Tres personas muertas, otras tres heridas gravemente.

Desastre: La máquina de terapia radiactiva canadiense Therac-25 falló y emitió dosis

letales de radiación a los pacientes.

Causa: Debido a un sutil bug llamado race condition (condición de carrera), un técnico
pudo accidentalmente configurar el Therac-25 de forma que el haz de electrones se
disparase en modo de alta potencia sin que el paciente contara con la protección
apropiada.

7 motivos de fracaso de un proyecto

de software
¿Por qué razones concretas fracasan los proyectos de
software? ¿Cómo podemos evitarlo? Conociendo las razones más
comunes que conducen al fracaso de un proyecto de software
podemos intentar no caer en ellas o al menos poner en práctica
medidas para paliar sus efectos de antemano, anticipándonos para
controlarlos daños. En este post recogemos 7 motivos de fracaso de
un proyecto de software en modo numerus apertus ya que seguro
que por vuestra experiencia podéis aportar más razones.
Para los que tenemos empresas de desarrollo de software siempre
nos resulta interesante explorar las razones por las cuales fracasan
los proyectos de software. Y a menudo se suscita la pregunta
contraria: ¿Y qué es lo que hace que los proyectos de software
tengan éxito? Quizás esta última pregunta sea la realmente
importante. Por ello, no basta examinar únicamente las razones por
las que fracasa un proyecto de software sino también qué se puede
hacer para incrementar las probabilidades de éxito de proyectos
futuros.
Según un estudio publicado por IDC, el 25% de los proyectos de
software fracasan desde su concepción. Por otro lado, del 20 al 25%
no generan ROI (retorno de la inversión) y hasta un 50% requieren
rehacer y reprogramar cosas.
¿Te suenan estas historias? Probablemente hayas visto proyectos
que, incluso sí no fracasaban desde el origen, no cumplían los
objetivos financieros o necesitaban mucho trabajo de reprogramación.
Muchos informes sobre gestión de proyectos detectan que una
mayoría -el 54%- de las causas documentadas de fracaso de un
proyecto es atribuible a la gestión del proyecto.
Sorprendentemente para algunos, los desafíos/escollos técnicos son
el factor menos citado (3%).

La disciplina de gestión de proyectos ha estado ligada al software ya

desde hace muchos años. Entonces, ¿por qué aún la mayoría de los
problemas están relacionados con la gestión de proyectos? Las
razones al final se reducen a 7 motivos que llevan al fracaso. Al
escarbar un poco e identificar baches potenciales, podemos ver qué
podemos hacer para evitar tropiezos y mejorar las oportunidades de
éxito.

#1 Mala Gestión y Dirección de Proyectos

La mejora de la gestión de proyectos y dirección es uno de los
factores claves en el éxito de proyectos de software. Esto requiere un
método compuesto de normas, procedimientos y herramientas para la
planificación de los proyectos y la gestión, apoyados por una
herramienta de software. Una parte fundamental de la planificación es
asignar a las personas adecuadas la tarea correcta y repartir tareas de
forma clara entre los miembros del equipo, con metas y
responsabilidades bien definidas. Si las tareas no van bien, ajusta los
roles de la forma apropiada.

#2 Comunicación insuficiente
Los informes objetivos, el contacto fluido con socios y clientes, y la
implicación de agentes externos como proveedores son cruciales a la
hora de evitar que se rompa la cadena de comunicación que pueden
llevar a que desacrrile un proyecto de software.

Las pequeñas acciones sí cuentan, tales como tener la agenda

ordenada, actas de las reuniones al día e Emails que compartan
información. Las agendas fuerzan al gestor del proyecto que conduce
la reunión a planificar el tiempo y proporcionar cualquier información
preliminar para la reunión. El pararse a pensar y preparar que incluir
en el orden del día de una reunión es la parte más importante de la
agenda, incluso más importante que la agenda en si.
#3 Gestión directiva ineficiente
Evita este bache siendo proactivo en el cambio de objetivos, metas y
riesgos, coordinando esfuerzos entre los departamentos técnicos y
financieros, y midiendo el rendimiento.

Implementa un proceso claro de gestión del cambio con pasos que

incluyan la valoración y la aprobación de las decisiones. Debe ser un
proceso ligero, pero que a la vez permita a los directivos entender el
impacto del cambio de los requisitos en un proyecto. Usa una
herramienta de valoración de riesgos para desvelar los riesgos que
deben ser considerados durante y al final del proyecto. Asegúrate de
haya un representante del departamento financiero en el equipo y
formaliza un plan de negocio. Por último, identifica mediciones del
rendimiento simples tales como tareas ya comenzadas y aquellas
planificadas, e inclúyelas en los informes periódicos del estado del
proyecto.

#4 No estar alineados con los socios o inversores

de la empresa
Crear confianza y conexión con los socios de la empresa es esencial
para tener un resultado exitoso, especialmente cuando los socios
forman parte de diferentes empresas y midan las cosas de forma
distinta en función de las diferentes motivaciones que tengan.

Para estar bien alineados, hay que fomentar iniciativas muy

específicas para asegurar estar entrelazados y la comunicación con
socios y accionistas. Esto se puede hacer mediante reuniones para
recibir opiniones y anotar expectativas, mediante notificaciones por
email para recibir validaciones de proyectos. En las primeras etapas
de los proyectos de software resulta muy útil tener al menos una
reunión con los socios y miembros del equipo. Una reunión bien
organizada tipo kick-off, donde se fortalecen las relaciones, es de gran
ayuda para apoyar el proyecto durante los meses venideros.

#5 Falta de implicación efectiva del Equipo Directivo

La participación de los cargos directivos en las operaciones clave de
trabajo es crucial a la hora de establecer las prioridades. Con el kick-
off del proyecto no basta. La implicación de los directivos debe ir
enfocada a reuniones sobre el estado y evolución del proyecto,
especialmente en aquellas reuniones en las que se deben tomar
decisiones para avanzar en el desarrollo del proyecto.

#6 Falta de capacidad, de destrezas, de

conocimiento o la no adaptación al cambio
Para evitar situaciones en las que los miembros del equipo carezcan
de los conocimientos necesarios para sacar adelante el proyecto, se
debe usar un enfoque que permita tutorizar y hacer de mentor de los
empleados con menos experiencia. Además, se deben incluir cursos
de formación dentro de los plazos y tiempos globales del proyecto: el
factor humano y el conocimiento es decisivo: es imposible obtener un
buen resultado sin las personas con los recursos adecuados.

#7 Mala metodología y herramientas

Los proyectos con éxito se basan en una metodología y un marco que
incluye herramientas de gestión de proyectos. Este enfoque
incrementa la efectividad y ahorra tiempo al automatizar actividades
como el seguimiento de las diferentes tareas y actividades.

¿Cómo lograr tener éxito en un proyecto de

desarrollo?
Mejorar el ratio de éxito de los proyectos de software es posible
poniendo más foco en las actividades de gestión en general. Puede
resultar desalentador al principio de un proyecto saber que las
probabilidades indican que se tendrán que reprogramar muchas cosas
o incluso el fracaso del proyecto. Pero con una buena planificación,
metas bien definidas, tareas bien asignadas y una comunicación
efectiva, los gestores proactivos pueden sobreponerse a las
dificultades y sacar adelante incluso los proyectos más difíciles.

Simplemente saber prever y reconocer las trampas del camino evita

los retrasos tan costosos del futuro.

¿Por qué fracasan los proyectos?

Por Alfonso Núñez el 4 de Febrero 2013 10:12 AM

Varias encuestas sostienen que solo el 20% de los proyectos

finalizan con el objetivo planteado en el tiempo y con los recursos
estimados. Una problemática que se da en todo tipo de proyectos,
pero que se acentúa particularmente en los relacionados con la
tecnología.

Que el 80% de proyectos no tuviera la misma

suerte -por diferentes motivos- genera un aumento de costos directos (en los casos que
los proyectos finalicen con mayores recursos que los previstos) e indirectos por la no
disponibilidad de los beneficios previstos que brindaría dicho proyecto si hubiera finalizado
en tiempo y forma. Dichos beneficios seguramente han sido destacados en el momento de
desmenuzar el plan estratégico de la organización, el cual dio origen y justificación al
nacimiento de dicho proyecto.
Del último análisis surge entonces que, además de los costos directos que son fácilmente
contabilizables, existen los indirectos que seguramente son mucho más importantes que lo
que pueda suponerse (de no ser así entonces la falla estuvo en promover un proyecto que
no aportaba demasiado valor a la organización). Esto fundamentalmente impacta en una
baja de productividad de alguna área de la organización y en un costo de oportunidad al
no disponer de un resultado que seguramente será un eslabón importante para la cadena
de factores críticos de éxito previstos en la estrategia global.
Esto nos lleva a darles una importancia superior a los motivos que generan estos fracasos
y a desarrollar lineamientos para corregirlos. En Perú, particularmente, y dada la situación
de los últimos años, muchos proyectos han seguido la misma suerte que la estadística
general.
La permanente búsqueda en reducción de costos de Recursos Humanos ha llevado a las
empresas a generar proyectos de alta criticidad y exigencia, con el fin de que los mismos
aporten algún beneficio tangible a la organización que necesita aumentar ingresos y bajar
costos. Pero, al introducir esa baja de costos casualmente en las áreas que deben ejecutar
dichos proyectos, se generan dos malos escenarios: o se tiene gente preparada para
liderar dichos proyectos, pero sobrecargada de trabajo (lo cual implica no poder ejecutarlos
como se debe y por lo tanto se ingresa en el 80%) o se recambia personal con menor
costo y menor experiencia para la función, lo cual produce el mismo resultado.

En un aspecto más conceptual, la dirección o

liderazgo de proyectos no ha tenido la categorización de una especialidad en sí misma, lo
cual implica que se improvisa muchísimo. Este escenario nos lleva a replantarnos la forma
en cómo se ejecutan los proyectos. Se necesitan más líderes para concretar los proyectos
de cambio en las organizaciones, de manera tal que se aumente la productividad de las
mismas.
Hacia fines del 2001 he realizado un estudio con unos 50 responsables de proyectos, para
analizar las causas que alimentan los fracasos según los parámetros definidos. Este
estudio que se nutrió de experiencias personales -más allá de los números-, me permitió
detectar diversos factores que entorpecen el camino de un proyecto y que se analizan en
el libro recientemente editado "Liderando Proyectos".
Motivos que originan fracasos en el cumplimiento de los proyectos:

 Cambios en los objetivos definidos a nivel estratégico: 21%

 No utilización o mala utilización de metodologías de trabajo: 31%
 Problemas humanos, de conducción, comunicación y conflictos entre la gente:
48%.
 TestLink

1. Entorno
Este tutorial está escrito usando el siguiente entorno:

 Hardware: Portátil Intel Core 2 CPU T7200 @ 2.00GHz x 2

 Sistema Operativo: Ubuntu 13.04 x32
 netBeans IDE 7.3

2. Introducción
Ya sabemos toda la importancia de realizar test de nuestras aplicaciones, pero
también es necesario tener los test bien organizados, documentados, descritos y
seguros.

Para optimizar la calidad de nuestro software, es importante tener un control de

calidad de nuestros test.
Disponemos de muchas herramientas en internet para todo esto, pero voy a
hablaros de una en concreto, TestLink.

3. ¿Qué es TestLink?
Es una herramienta Open Source con la que mantendremos una mejor calidad de
nuestros test.

Nos permite responder a las siguientes preguntas:

 ¿Para qué requisitos necesitamos escribir o actualizar casos de test?

 ¿Que test queremos ejecutar para esta versión?

 ¿Cuanto hemos progresado testeando esta versión?

 ¿Qué test están fallando? ¿Cuales son los errores?

 ¿Necesitamos algún cambio en esta versión?

Con TestLink tenemos todo esto bajo control.

Podemos descargarla desde Sourceforge: aquí.

Soporta todos los navegadores desde Internet Explorer 6.
Las dependencias de fondo de TestLink son:

 Un servidor web como Apache 1.3 y 2 o superior

 Un gestor de bases de datos como MySQL 4 o superior.

 Php 5.2 o superior.

 Y un sistema de trazas de bug, como colaborador opcional. (Ej: Bugzilla.)

4. Instalación de la aplicación
Para tener esta aplicación instalada en nuestro servidor web, es muy sencillo.
Pasos:

 Tener un servidor web como Apache con Php5 y un servicio SQL de base de datos.
Por ejemplo XAMPP.
 Tener descargado el paquete de SourceForge.

 Descomprimimos el paquete de TestLink en el directorio que queramos dentro de

nuestro servidor.

 TestLink posee un script de instalación automática, que te ayudará a instalar todas las
directivas de configuración, así como la estructura de la base de deatos. Desde nuestro
navegador acceder a: http://nuestroServidor/testlink/install/index.php

Este nos hará aceptar unas condiciones.

 Completar la información para nuestra base de datos
 Y cumplir ciertos requisitos que nos indicará a continuación:
 Una vez hecho esto la instalación estará completada y podremos continuar:

 El siguiente paso será configurar.

 Si queremos instalar manualmente seguir la documentación en este manual: Enlace a
manual.

5. Configurando la aplicación
 Todos los parámetros de configuración están en el fichero config.inc.php y todos los
ficheros incluidos en él.
 config.inc.php: contiene configuración principal.

 config_db.inc.php: contiene parametros de configuración de acceso a la bd.

 custom_config.inc.php: sirve para modificar los valores por defecto de los

parametros de config.inc.php, esto nos facilita la modificacion.
  Antes de cambiar nada es recomendable tener una copia de seguridad de nuestra
configuración tras la instalación.

 Se recomienda usar custom_config.inc.php para nuestros cambios, esto nos permite

guardar nuestra configuración en caso de una actualización.

 Testlink nos permite una comunicación directa con nuestro bug tracker. Para
habilitarlo tenemos que cambiar el parámetro

1 $g_interface_bugs = 'NO';

entre los siguientes valores posibles: ‘NO’, ‘BUGZILLA’, ‘MANTIS’, ‘JIRA’,

‘TRACKPLUS’, ‘EVENTUM’, ‘SEAPINE’ o ‘TRAC’

 Para más opciones de configuración consultar el manual.

6. Terminología y flujo de trabajo

Una vez instalado y configurado a nuestro gusto vamos a profundizar.

Esta aplicación nos proporciona un mecanismo de documentación para nuestros

test bastante completo.
Desde organizar un Test Project hasta la misma documentación del resultado de
nuestros test.

Tenemos un usuario Administrador creado en la misma instalación, el cual creará

un Test Project y minimo dos usuarios:

 un Leader, encargado de definir los requisitos de nuestro software y organizar los casos de
prueba vacíos(Test Case) en Suites de prueba (Test Suite).
 un usuario “Senior Tester” en cargado de rellenar esos Test Case vacíos con el escenario de
prueba. (Steps)
Una vez creados estos Steps, podemos linkear los Test Cases a un Test Plan y a
un Build creados anteriormente. Podemos crear unas palabras clave “Keyword”
para tener un filtro de test. Una vez creado todo esto probaremos los test, y
reflejaremos los resultados en esta aplicación.

7. Uso de la aplicación
Nos conectaremos con el usuario admin que hemos creado:

– Test project :
Vamos a crear un projecto para test (necesitamos derechos de administrador). Se
nos presenta la siguiente gui:
Lo rellenamos y al crearlo llegamos a una tabla con nuestros projectos:
Despues crearemos dos usuarios:

 Leader user

 Senior Tester

El leader del test project declara los requisitos del Software y con estos crea unos
casos de test que incluira en unos suites. En esta aplicación crearemos primero un
Suite de pruebas:
Y a continuacion de este estableceremos los casos de test.
En sumary indicaremos la especificacion que queremos de nuestro software, por
ejemplo:
– “Posibilidad de logear en la aplicacion”

En preconditions especificaremos las precondiciones para esa summary:

– “Tener iniciada la aplicación”

Otro ejemplo más claro seria:

– Summary: “Quiero que se cargue un menú de inicio”

– Preconditions: “El usuario se haya conectado”

De momento dejamos los steps sin definir.

Ahora crearemos un Test Plan, al que ligaremos todos los test cases.

En el panel de “Test Plan” hacemos click en build y nos dice que tenemos que
crear uno, sera nuestro control de versión de cada test.
Es decir para el test “Probar un caso de test” creamos una build “Probar un caso
de test 0.1” por ejemplo.

Luego vamos a establecer una serie de Steps en nuestros casos de prueba. Que
van a ser nuestros propios test.

 Step1: Step actions: “Usuario y contraseña correctos”

Expected results: “Login true”

 Step2: Step actions: “Usuario correcto y contraseña incorrecta”

Expected results: “Login false”
Si queremos asignar previamente un caso de test a un usuario, en el panel
principal buscamos “Assigning Test Case Execution” y lo hacemos, es muy
intuitivo:
Clicamos en save.

Ahora con todo esto vamos a ver como podemos documentar que nuestros test
pasan o no. Logeamos con el usuario al que se lo asignamos. Clicamos en Test
Execution, y accedemos mediante el panel lateral a nuestros casos.
Aquí podremos documentar si pasan o no los test. Save and move next guardará y
nos moverá al siguiente caso.

Podemos clicar en Show completed execution history, y veremos todos los

“commits” realizados:
8. Conclusiones
TestLink es una gran herramienta para mantener el control de nuestros test.
Tendremos mejor organizados nuestros test, así como mejor control de las
pruebas de nuestra aplicación y una documentación más optimizada.

Además TestLink nos provee de un volcado de los resultados en una base de

datos, por lo que podremos hasta realizar backups.
Os recomiendo que probéis esta aplicación. Para más información teneis la página
oficial: Enlace

Cualquier duda o sugerencia podéis comentar.

Testlink para la gestión de requerimientos

He conocido varias herramientas para gestionar requerimientos, pero siempre me he enfocado
en herramientas gratuitas.

Es bien sabido que ninguna herramienta te podrá ofrecer TODO lo que requieres y al no
encontrarla, puede ser que se te haya ocurrido desarrollar tu propia herramienta, pero también
es cierto que no contamos con el tiempo para hacer eso, pues bien, les presento una
herramienta que me ha sacado de apuros y que es personalizable hasta cierto punto: Testlink.
¿Qué es Testlink? Pues como decía al principio, es una herramienta para gestión de
requerimientos basada en Web, y no solo gestiona de la manera tradicional los requerimientos,
como los famosos estados de nuevo, en curso, etc; más bien Testlink está dirigido a la calidad
del Software, es decir, es toda una plataforma diseñada para crear casos de prueba de un
sistema, que pueden dividirse según la versión liberada que se quiera probar.

Obviamente al ser un sistema Web, se requiere un administrador de usuarios, contraseñas y

todo lo que implica montar un sistema de este tipo.

No quisiera entrar a detalles a explicarles paso a paso como se usa, ya existen manuales
circulando por ahí, pero sin duda me pareció importante compartir con ustedes está
herramienta, por que en lo personal, me ha servido más que otras herramientas de gestión que
he usado.

Incidencias en el peru

Fallas en plataforma
informática de Sunat-
Aduanas preocupa a los
exportadores
02/10/2013

La institución anunció que el sistema venía presentando fallas que evidencian el

desborde de las capacidades del sistema y si bien Sunat-Aduanas ya cuenta con un plan de
contingencia cuando se programan los procesos de mantenimiento, lo cierto es que no son
implementados de la mejor manera al punto de no tener el número adecuado de oficiales
que respondan a la demanda de las empresas del sector.
En un comunicado alertaron que el pasado domingo se quedó carga en el
aeropuerto por el reducido número de oficiales asignados. Como consecuencia,
los productos perdieron sus vuelos generando problemas a las empresas, pues
en muchos casos la carga no llega directamente a sus destinos, sino que
hacen transbordo.

Según información de los exportadores y de los representantes de las líneas

aéreas, el plan de contingencia nunca funcionó de forma coherente. Lo más
grave aún es que se daña la imagen del Perú como proveedor de productos
frescos y la competitividad de nuestras exportaciones, justamente ahora que
empieza la temporada alta de varios productos (hortalizas y frutas,
principalmente).

"Esta situación debe obligar a crear conciencia de que la competitividad es

tarea de todos", reza la misiva.

Hay que tomar en cuenta también que los productos frescos deben llegar
oportunamente y en óptimas condiciones a sus destinos y estas demoras
perjudican su calidad lo que obliga a “castigar el precio”, en perjuicio de la
empresa. Esto sucede solo si el comprador internacional siga interesado en el
producto.

No aprenden de sus errores: MINSA

A raíz de las investigaciones que inició la Sub-Comisión de Fiscalización del Congreso de
la República integrada por los congresistas Segundo Tapia Bernal, Héctor Becerril y
Mauricio Mulder, por presuntas irregularidades en la contratación del software Galenhos
entre USAID y el MINSA, luego que los ex Funcionarios Técnicos de Informática del
MINSA en el mismo Congreso confirmaran a la comisión que ellos opinaron en contra de la
implementación de este software por diversas carencias técnicas en el mismo, esta
institución de salud, luego de varios años habría decidido, por fin, prohibir el uso de este
software en los hospitales del Estado. Pero lo que sigue es lamentable.

No aprenden de sus errores: MINSA

Equipo informático de esta institución pública ahora se dedica a desarrollar software

(americasistemas.com.pe. Lima, Perú – 21 de octubre de 2015) Como se recuerda se

ofrecía regalar el software Galenhos, pero luego se cobraba por la implementación. El
problema era que la implementación solo se podía realizar vía la empresa ABT
Associaties, quien era la que donaba el software. Esta empresa estaba representada antes
de ser Ministra de Salud, por la Dra. Midori de Habich y luego por Alfredo Sobrevilla, quien
es su CV en Linkedin ostentaba ser un consultor certificado para implementar Galenhos.
Además, se transfirieron varias partidas presupuestales para impulsar la implementación
del referido software, la comisión estableció que podían estar en el orden de 10 millones
de soles. El tema continúa en investigación y siguen declarando varios directores de los
hospitales comprometidos.
Ya se gastaron el primer millón de soles
Sin embargo, por increíble que parezca, el MINSA parece no aprender de sus errores.
Acaban de salir de este poco transparente proceso del software Galenhos y ya anunciaron
en una reciente Jornada Internacional sobre la historia clínica electrónica e
interoperabilidad en el sector salud, que lanzarán su software HIS-WEB, en el cual ya se
gastaron el primer millón de soles, que será el software que reemplace a Galenhos. El
enorme problema es que el software HIS-WEB solo tiene el módulo de control de
PACIENTES terminado; entendidos en el tema señalan que un software de gestión
hospitalaria tiene en promedio 30 módulos (farmacia, laboratorio, intervenciones
quirúrgicas, historia clínica, etc) por lo que se estima que esperan gastarse varios millones
de soles adicionales en los próximos años. El MINSA promovió Galenhos por 10 años y la
realidad informática de los hospitales nacionales es paupérrima. Hoy inician una nueva
aventura de otros 10 años, con dinero público. Realmente a estos funcionarios habría que
sancionarlos por incompetentes; no se puede estar dilapidando el dinero público de esta
manera.

Para hacer un paralelo entre facturación electrónica e historia clínica electrónica, es como
si SUNAT en lugar de normar el intercambio de datos electrónicos de las facturas, se
dedicara a desarrollar los ERPs que deberían tener las empresas, según ellos, porque solo
así será posible enviar la factura electrónica. Además, de obligar a todas las empresas a
usar el ERP desarrollado por ellos. Obviamente, esto no sucede en esta entidad
recaudadora, pero es lo que sucede en el MINSA, donde no existen estándares
electrónicos para compartir historias clínicas electrónicas como en Colombia o Chile, y
ellos insisten por enésima vez en seguir desarrollando software. Acaso no sería mejor que
dejen en libertad a los hospitales para que cada uno escoja su plataforma y luego
mediante un estándar se consolide la información?

Esperamos una respuesta del Dr. Javier Vargas Herrera, Director de la Oficina de
Estadística e Informática del MINSA, para que nos aclare el motivo de tamaño
despropósito tecnológico en su institución.

Software de Perú para trabajar la

comprensión lectora
Hacía tiempo que no comentaba ningún programa informático para trabajar la
comprensión lectora. En este caso se trata de un programa realizado en Perú
llamado Lektor High School 3.0, desarrollado por la empresa Softone. Lektor High School
3.0 está destinado a estudiantes de secundaria pero Softone también tiene otros programas
para adultos, para trabajar la velocidad lectora y el programa Lektor Home.
La presentación del programa en la web de la empresa es elegante, pero encuentro poca
información, y casi nada sobre lo que me suele interesar que es cómo se ha evaluado su
eficacia y qué resultados se han obtenido. Casi toda la información que doy la he
encontrado en vídeos de Youtube, o en noticias o reseñas de periódicos digitales.

La página de Softone ofrece la posibilidad de registrarse y, aunque lo he hecho, al ingresar

en la página se produce un error. Sí que es posible descargarse una demo del programa
Lektor Home.

10/18/2012 · 5:07 AM