martes, 27 de mayo de 2014

¿Por qué no es bueno hacer lo que el cliente dice?

(Diseña en base a tu conocimiento y experiencia)

Una de las cosas que nos enseñan desde los primeros ciclos de la universidad es la creación de "modelos de datos" y cómo "normalizar" (ordenar, clasificar, agrupar, ...)  estos modelos.  También nos enseñan por qué es malo tener la información duplicada y uno de los motivos es lo difícil de mantener esa información actualizada (sincronizada) a lo largo del tiempo de vida del sistema.

Muchas veces, en realidad, casi siempre, he escuchado la siguiente excusa para tomar malas decisiones de diseño de sistemas: "Lo hicimos así porque el cliente nos lo pidió así".  Si vamos a tomar al pie de la letra lo que el cliente nos pide creo que deberíamos quitarnos el título de Gestor/Analista/Líder/Experto/[agrega el título que quieras] y cambiarlo por uno que diga "Documentador De Lo Que El Cliente Pide", con este  nuevo título de "Documentador ..." nuestro interlocutor tendrá claro que sólo está con una persona que "toma notas" y no con una persona capaz de "recoger la información, interpretarla, analizarla, evaluarla, descubrir la necesidad real del cliente y proponer una solución viable".

Para los que desconocen cómo está ordenado un sistema, sólo es necesario decir que el cliente sólo interactúa con "lo que ve" en la pantalla de su laptop, tablet o smartphone.  A esta parte la vamos a llamar "capa de presentación". A todas las demás partes del sistema las vamos a llamar "capas mágicas".  Y las vamos a llamar así porque  para el "cliente" todo lo que ocurre después que da un "click" en un botón de la pantalla es "magia" y lo bonito de la magia es verla sin necesidad de entenderla.

Con todo lo descrito anteriormente, lo que debe quedar claro es: lo que el cliente nos pide es lo que el cliente espera ver en su "capa de presentación", todo lo demás está implementado en las "capas mágicas"; y en una de estas "capas mágicas" esta el "modelo de datos", un modelo que debe ser diseñado basado en experiencia, conocimiento y luego de haber hecho un análisis de las necesidades del cliente, del sistema y de las restricciones que pudieran existir.

En conclusión, cada vez que nos encontremos a cargo de crear un sistema, debemos asegurarnos de que nuestras "capas mágicas" estén diseñadas teniendo como base toda nuestra experiencia y conocimiento y no se debe basar en la frase "Lo hicimos así porque el cliente nos lo pidió así".

lunes, 25 de octubre de 2010

Taller de Gestión Ágil

La semana pasada empece un taller sobre Gestión Ágil con un grupo de alumnos de la facultad de sistemas de la Universidad de Lima; hasta ahora es una muy buena experiencia y se nota que el grupo esta muy interesado en aprender y en poner en práctica lo aprendido.  Espero más adelante poder subir fotos y contar la experiencia completa.  También espero que este grupo se convierta en el inicio de una comunidad mas grande dentro de la universidad.

Abajo copio un resumen del contenido del taller:

Contenido del Taller

Trabajo manual y trabajo de conocimiento

Concepto de tipos de trabajo que se realizan en cualquier actividad; clasificación y características
Control sobre el trabajo (diferencia en tareas de control y tareas de creación de valor)

Trabajo de conocimiento y gestión de equipos de trabajo

Características de los equipos de trabajo que realizan trabajo de conocimiento.
Características de un administrador y un líder.

Gestión ágil de equipos de trabajo (manifiesto ágil)

Explicación del "manifiesto ágil"
Características de la gestión ágil
Inspección y adaptación al cambio

Principios lean (esbelto)

Desarrollo de producto
KISS y YAGNI

Gestión visual (Visual Management)

El proceso de creación de modelos mentales, como la mente crea significado.
Uso de la gestión visual en la gestión de equipos de trabajo
La importancia de la visibilidad de la información en el desarrollo del trabajo.

Gestión de procesos y de proyectos

Definición de procesos y proyectos
Principales diferencias entre ellos

Gestión y organización del tiempo

El proceso de gestión del tiempo personal, maneras de organización y planificación.
Explicación del método GTD

Gestión del conocimiento del equipo

Explicar del proceso de creación de conocimiento dentro del equipo
Como almacenar ese conocimiento y propagarlo mas allá del equipo (lecciones aprendidas).

Frameworks para la gestión ágil de equipos

SCRUM
KANBAN

/.

martes, 19 de octubre de 2010

Característica Técnicas para un Sitio Web

 

Me pidieron definir un documento inicial de las características técnicas que consideraría para un “sitio web” que tiene un tráfico aproximado de 40mil visitas diarias.  Estas son las características que consideré:

Desarrollo y Personalización

Uso de un framework (marco/forma de trabajo) de desarrollo y/o de gestión de contenido

  • Se refiere a la programación o la personalización del gestor de contenido.
  • En Drupal, como marco de trabajo se siguen las prácticas de Drupal.
  • En “Ruby on rails”, como marco de trabajo se sigue el modo de programación de “Ruby on rails”

Auditoría

Registro y reporte de accesos / usuarios / tipos de accesos / tipos de usuario

  • Lo que se pide es poder consultar la información de auditoría de manera sencilla.
  • Cada vez que una persona ingresa al sitio con su usuario y contraseña se pueda saber: quien ingreso, cuando ingreso, para que ingreso y desde donde ingreso.

Seguridad

Proceso de copias de seguridad del sitio web.

  • Proceso de copias de seguridad del sitio web (base de datos, aplicaciones, etc.)

Proceso de restauración del sitio web en caso de fallas

  • Proceso de restaurar las “copias de seguridad”.

Uso de HTTPS .

Integración

Integración con el directorio de usuarios de la organización (ldap)

Deseable Integración con un único punto de ingreso de usuario y contraseña (SSO - single sign on)

Deseable Integración con CDN (content delivery network) ¿?

  • Una Red de Distribución de Contenido, permite tener una copia del sitio web (documentos, imágenes, audios, video, etc) en servidores de distintos países o ciudades de manera que cuando un usuario quiere entrar al sitio web de la organización se conecta al servidor más cercano.
  • El objetivo es que el sitio web esté siempre disponible y que se muestre mas rápido al usuario.

Soporte

Deseable varios canales de soporte técnico (email, teléfono, chat, foros, blogs, presencial)

Disponibilidad del soporte (horario)

Estándares

Soporte para creación de RSS de cualquier contenido albergado en el sitio web

Acceso Móvil

Posibilidad de acceso a través de dispositivos móviles

Alta disponibilidad y Tolerancia a fallos

Velocidad de carga de las páginas del sitio web

Dimensionamiento de los requerimientos de hardware y software

Cluster de servidores web / aplicaciones / base de datos

  • Se refiere a que la organización proporciona los datos de cantidad de usuario por hora, número de páginas vistas por las usuarios, tiempo que los usuarios se quedan navegando en el sitio, etc. Y, en base a esos datos, el proveedor estima la cantidad de servidores necesarios y realiza la instalación y configuración.

Optimización para motores de búsqueda (Google)

Implementación automática de técnicas de SEO (search engine optimization)

Creación y actulización del “Mapa del sitio web”

  • Para facilitar que Google indexe las páginas se pueden usar 2 archivos: sitemap.txt (es el mapa del sitio) y robot.txt (que incluye una lista de páginas que pertenecen al sitio web, pero no deben ser indexadas)

Integración automática con Google Analytics

  • Se refiere a poder incluir en cualquier página y de manera automática el código javascript proporcionado por Google Analytics.

Adicionales

Manejo de páginas y enlaces rotos o no encontrados (error 404)

Capacitación a los diferenties tipos de usuarios

Manuales de uso y de sistema.

/.

martes, 5 de octubre de 2010

Regreso al blog

Despues de un año que vuelvo a escribir en el blog y tengo varios temas que he estado desarrollando y de los que espero escribir aquí:

  • Integración de youtube en un portal (como subir videos desde tu portal)
  • Instalación y configuración de Alfresco
  • Requisitos técnicos que debe cumplir la implementación de un nuevo sitio web
  • Taller de gestión y trabajo en equipo (basandose en el Manifiesto Ágil)

viernes, 11 de septiembre de 2009

Propuesta de Implementacion de Una Plataforma de Distribución de Videos

1. Resumen Ejecutivo

1.1. Objetivos

    • Mostrar a la mayor cantidad de personas la vida universitaria, los trabajos y el conocimiento generado en la Universidad.
      • Mostrar la vida universitaria dentro de la Universidad.
      • Mostrar los trabajos realizados por los alumnos.
      • Mostrar el conocmiento (clases, conferencias) generado en la Universidad
    • Crear una relación con las personas a través del uso de videos, integrando las herramientas necesarias que permitan establecer un diálogo con estas personas.

1.2. Antecendentes


Con la aparición de sitios web como YouTube, Vimeo o Dailymotion (año 2005) compartir videos a través de Internet se convirtió en una tarea sencilla. Pero estos sitios no solo son populares por poder compartir videos, también son populares porque te permiten establecer una relación entre las personas que suben los videos y las que ven los videos.

Cualquier institución que quiera compartir videos tiene 2 opciones, crear su propia infraestructura (servidores, ancho de banda, etc) o utilizar la infraestructura que te brindan los líderes del mercado.

Para implementar una solución de Distribución de videos es importante tener presente los siguientes puntos:

  • ¿Quién va a crear mis videos?
  • ¿Que voy a usar para distribuir mis videos?
  • ¿Quién va a ver mis videos (mis usuarios)?
  • ¿Cómo voy a conversar con mis usuarios?

1.3. Requisitos

Para elaborar una propuesta es necesario establecer las necesidades básicas que debe cumplir la solución:

    • Los videos serán creados por cualquier miembro de la universidad (docentes, alumnos, personal administrativo, etc) o dependecia.
    • La distribución de videos va realizarse mediante la transmisión de videos grabados y transmisión de videos en vivo.
    • Todos las personas con acceso a Internet son potenciales usuarios (mis usuarios), por lo tanto, se debe brindar las facilidades para clasificar y buscar los videos por temas o categorías.
      • Debido a que todas las personas con acceso Internet son potenciales usuarios se debe buscar una solución que tenga una gran base de usuarios (“cartera de usuarios”/”cartera de clientes”)
    • Se deben tener características que te permitan establecer canales de comunicación con los usuarios, estos canales deben percibirse como personales y cercanos.

1.4. Propuesta

Para implementar la solución de Distribución de Videos se ha elegido 2 UStream y YouTube como plataformas (sitios web).

      • UStream será usado para la transmisión de videos en vivo, una vez finalizada la transmisión estos videos pueden ser almacenados en YouTube.
      • YouTube será usado como el repositorio central de videos de la universidad donde se podrá clasificar, comentar y publicar los videos.

La solución propuesta tiene las siguientes características:

1. Se tendrá un inventario de videos grabados y videos en vivo (http://www.ustream.tv/ulimaperu)

2. Los videos serán almacenados en el canal principal creado en YouTube (http://www.youtube.com/ulimaperu)

El tener un repositorio central permite sacar estadísticas de los videos (mas visto, mas populares, etc)

 

3. Los videos serán clasificados y publicados a través de:

En el gráfico al final del documento se muestra un esquema de la solución:

 

1.5. Ventajas

· El espacio de almacenamiento de la Universidad no se ve afectado por la cantidad de videos

· No requiere hacer uso de un mayor ancho de banda hacia los servidores de la Universidad.

· Permite realizar búsquedas sobre los videos al tener un repositorio central de videos

· Mejora la disponibilidad del servicio (al tener servidores distribuidos en todo el mundo)

· Reduce la cantidad de equipos destinados a la solución de distribución de videos.

· Reduce la cantidad de horas hombre dedicada a la administración de la solución.

1.6. Desventajas

· El acceso a los videos desde el campus de la universidad es mas lento al no tener servidores de video dentro del campus      

· La universidad no tiene el control para la administración de la solución (copias de respaldo, recuperación, etc.)

· La solución depende de la disponibilidad del acceso a Internet.

· La administración y uso está limitado por las herramientas que te provee YouTube y UStream

1.7. Implementaciones

· Universidad Nacional Mayor de San Marcos usando Vimeo.com http://www.tvsanmarcos.com/

· Pontificia Universidad Católica del Perú usando desarrollo propio (http://videos.pucp.edu.pe/)

· Perunet.TV usando Yahoo video (http://perunet.tv/)

· Academic Earth (http://academicearth.org/)

· TED (http://www.ted.com/)

1.8. Conclusiones

La necesidad de tener una presencia relevante en Internet hace necesario hacer uso de todos los medios disponibles, una de estos medios es el uso del video. El poder implementar la solución propuesta para el uso de videos en la Universidad servirá para añadir valor a su labor educativa además que permitirá dar a conocer como se desenvuelve la vida universitaria.

clip_image003

viernes, 14 de agosto de 2009

Propuesta de Mejora del Servicio de Correo Electrónico

Hace más de un año, como parte de mi trabajo, prepare un piloto de cambio de plataforma de correo electrónico de Exchange a Google Apps.  Al realizar la presentación del piloto del proyecto muchas personas se mostraron interesadas, pero como me ha pasado muchas veces sólo quedo en propuesta y no se avanzó más.

El mes pasado asesoré a un amigo en la implementación de Google Apps para su empresa, despues de ayudarlo es que decidí crear un documento y esé documento es el que publico a continuación:

Propuesta de Mejora del Servicio de Correo Electrónico

1. Resumen Ejecutivo

1.1. Objetivos

· Mejorar la experiencia de uso del servicio de correo electrónico para los usuarios.

· Reducir el costo de administración del servicio de correo electrónico.

· Mantener la privacidad de las cuentas de correo electrónico de los usuarios.

1.2. Antecendentes


Debido al continuo avance en tecnología algunos de los servicios que antes se brindaban como exclusivos o que servían para diferenciarse se están convirtiendo en commodities.  Uno de los casos mas representativos es el "servicio de correo electrónico".
Desde los inicios del "correo gratuito" con hotmail y sus 2 MB de capacidad hasta el día de hoy con cuentas de correo gratuito de más de 5 GB (5 000 MB) de capacidad la "Institución" siempre se ha mantenido al día brindando un servicio confiable y seguro para toda la comunidad universitaria.  Sin embargo, tratar de seguir a los lideres en este servicio representa actualmente un costo (en equipos y capacitación de personal) demasiado grande.

1.3. Propuesta

Para que la institución pueda seguir brindando un servicio de calidad es necesario cambiar la forma en que brinda este servicio a la comunidad universitaria.  Este cambio de forma involucra la asociación de la institución con alguna de las empresas líderes en el mercado (Microsoft, Google, Yahoo) transfiriéndoles las cuentas de correo (inicialmente las de los usuarios).  Bajo este esquema la institución crea, elimina y actualiza las cuentas de correo de sus usuarios pero la administración del servicio la realiza otra empresa.

1.4. Ventajas

· Aumento de la capacidad de almacenamiento de correos.

· Mejora del filtro de correos basura (spam).

· Mejora de la capacidad de búsqueda dentro de la cuenta de correo del usuario

· Permite acceder al servicio de correo desde cualquier pc o dispositivo móvil.

· Integra el servicio de correo electrónico con otras herramientas de colaboración (calendario, manejo de documentos, etc).

· Mejora la disponibilidad del servicio (al tener servidores distribuidos en todo el mundo)

· Reduce la cantidad de equipos destinados al servicio de correo electrónico.

· Reduce la cantidad de horas hombre dedicada a la administración del servicio.

· Reduce la complejidad en el mantenimiento del servicio.

· Evita que el personal de sistemas tenga acceso a las cuentas de correo de los usuarios.

· Asegura la integridad de la información de las cuentas de correo.

1.5. Desventajas

· El acceso desde el campus de la institución es mas lento al no tener servidores de correo dentro del campus

· La institución no tiene el control para la administración del correo (copias de respaldo, recuperación de correo, control de espacio de cuentas, etc)

· El servicio de correo electrónico depende de la disponibilidad del acceso a internet.

· Cualquier solicitud de acceso a cuentas está restringido por las politicas de la empresa proveedora (Microsoft, Google, Yahoo)

1.6. Implementaciones en Perú

· Universidad de Piura (http://inicio.pregrado.udep.edu.pe/)

· Universidad del Pacífico (http://mail.up.edu.pe/)

· Universidad César Vallejo (http://www.ucvlima.edu.pe/campus/)

1.7. Conclusiones

La necesidad de mejorar y adecuar los servicios de correo electrónico y colaboración de la "Institución" hacen necesario el cambio de enfoque que se ha propuesto.  Este cambio permitirá  centrarse en el desarrollo de soluciones que de un valor agregado a la educación y reducir la demanda de recursos al trasladar el servicio de correo.

2. Descripción General de la Propuesta del Proyecto

2.1. Propósito

Este proyecto tiene como propósito la creación de nuevas cuentas de correos para todos los usuarios y exusuarios de la Institución en una nueva plataforma (Google Apps), así como la creación de las herramientas necesarias para administrar las nuevas cuentas.

2.2. Alcance

El alcance del proyecto es el siguiente:

· Evaluar y contratar (en el caso de ser necesario) el ancho de banda requerido para la solución de correo.

· Elaborar un plan de acción para todos los componentes del correo actual.

· Elaborar un plan de acción para todos los servicios afectados por el cambio de correo electrónico.

· Inscripción en “Google Apps Education Edition”

· Registro y configuración del nuevo dominio para el correo electrónico.

· Personalizar la presentación del correo (modificar colores, logos, etc)

· Desarrollar, Instalar y Configurar el módulo de Administración de Usuarios.

· Desarrollar, Instalar y Configurar el módulo de “autenticación unificada” (un solo login para los servicios del “Portal” y correo electrónico)

· Pruebas integrales

· Elaborar una campaña para informar a los miembros de la institución del cambio de plataforma de correo electrónico.

2.2.1. Evaluar y contratar (en el caso de ser necesario) el ancho de banda requerido para la solución de correo.

· Se evaluará el ancho de banda usado por la solución de correo actual (Microsoft Exchange), en base a la evaluación se decidirá si es necesario contratar “ancho de banda” adicional.

· Se debe evaluar también la necesidad de tener otro proveedor de servicio de Internet además de “Telefónica del Perú”

2.2.2. Elaborar un plan de acción para todos los componentes del correo actual

· Se elaborará una lista de componentes del sistema actual (correos, carpetas públicas, listas de correos –grupos-, envio masivo de correos, alias de correo, etc) y para cada uno de ellos se elegirá un plan de acción (migrar, no migrar, eliminar el componente)

· Se debe tener en cuenta que usando “Google Apps” cualquier envio de correo masivo puede ser tratado como SPAM.

2.2.3. Elaborar un plan de acción para todos los servicios afectados por el cambio de correo electrónico

· Se elaborará una lista de los servicios afectados por el cambio (Ejemplo: el envío de correos en el aula virtual) y su correspondiente “plan de acción”

2.2.4. Inscripción en “Google Apps Education Edition”

· Es el proceso de registro de la “Institución” para poder hacer uso de “Google Apps”

2.2.5. Registro y configuración del nuevo dominio para el correo electrónico

· Se configurará el nuevo dominio “nuevo.dominio” como dirección de correo electrónico (ejemplo: 19930845@nuevo.dominio). Una vez terminada la configuración y generación de los nuevos correos se registrara el antiguo dominio “antiguo.dominio” como alias.

2.2.6. Personalizar la presentación del correo

· Consiste en la modificación de los colores y logos del nuevo correo. Se debe tener en cuenta que el tipo de modificaciones es limitada (en muchas páginas el único cambio permitido es el logo que aparece en la parte superior derecha)

2.2.7. Desarrollar, Instalar y Configurar el módulo de Administración de Usuarios

· El módulo de administración de usuario permite adicionar, eliminar o modificar información de los usuarios.

· Para este módulo se instalará “Google Apps Directory Sync” y se integrará a la administración de usuarios del “Portal” de la Institución

· Se realizarán las modificaciones necesarias en la administración de usuarios del “Portal” para implementar la integración.

2.2.8. Pruebas integrales

· Consiste en probar todo lo referente al alcance del proyecto descrito en este documento.

2.2.9. Elaborar una campaña para informar a los miembros de la institución del cambio de plataforma de correo electrónico

· Consiste en la elaboración y puesta en marcha de una campaña informativa para informar sobre el cambio.

2.3. Plan de trabajo

El plan de trabajo consiste en desarrollar las actividades en el alcance, para tal fin se ha desarrollado un calendario de actividades (con duraciones estimadas) teniendo en cuenta los prerrequisitos de las actividades.

A continuación se muestra un cuadro resumen de las actividades/tareas y su duración estimada.

clip_image002[6]

3. Conclusiones

El cambio propuesto permitirá  centrarse en el desarrollo de soluciones que de un valor agregado a la educación y reducir la demanda de recursos al trasladar las casillas de correo electrónico.

La implementación del servicio de correo electrónico en “Google Apps” permite hacer uso de otros servicios de colaboración, comunicación e infraestructura.

o Mensajería Instantánea

o Suite ofimática

o Calendario

o Creación de sitios web

o Creación y alojamiento de aplicaciones.

Los nuevos servicios pueden usarse para mejorar la comunicación entre los usuarios para el desarrollo de los cursos (durante el dictado de clases y también en las labores fuera de clases –trabajos en grupo, etc-).

4. Anexos

· Esquema actual de Correo Electrónico

· Esquema propuesto de Correo Electrónico

· Diagrama de Gantt de la propuesta

· Estructura de Descomposición del Trabajo (WBS) del proyecto propuesto

· Malla PERT del proyecto propuesto.

· Evaluación de las diferentes opciones de correo electrónico externo (Live@edu-Microsoft y Google Apps)

· Comparación de las opciones del correo electrónico actual y el propuesto

4.1. Anexo 1 - Esquema Actual de Correo Electrónico

clip_image004[6]

4.2. Anexo 2 - Esquema Propuesto de Correo Electrónico

clip_image006[4]

4.3. Anexo 3 – Diagrama de Gantt de la Propuesta

clip_image008[6]

4.4. Anexo 4 – Estructura de Descomposición del Trabajo (WBS)

clip_image010[6]

4.5. Anexo 5 – Malla PERT del proyecto propuesto

clip_image012[6]

4.6. Anexo 6 – Evaluación de las diferentes opciones de correo electrónico externo

RFI-mail

4.7. Anexo 6 – Comparación del Correo Electrónico Actual y el Propuesto

Estado Actual Estado Propuesto
El proceso de autenticación del correo no es el mismo, el usuario tiene que autenticarse 2 o más veces por cada servicio (portal, correo, etc) El nuevo correo usa el mismo proceso de autenticación del portal de la institución(el usuario no necesita autenticarse 2 veces, puede usar cualquier ventana de autenticación)
Permite registrar un alias de correo electrónico (Ejemplo: alias@antiguo.dominio) La opción de registrar un alias existe, pero no debe ser habilitada. (debido a que existen varios “alias de correo” de un usuario y al mismo tiempo tambien son “nombres de usuario” de otra persona en el portal.

v Después de la implantación de la solución se puede habilitar el proceso de creación de alias pero debido a la duplicidad de nombres los alias actuales no pueden ser migrados al nuevo sistema.

La interfaz no es la misma; depende del navegador (ie, firefox, safari, opera, etc.) y del sistema operativo (Windows, osX, linux)

clip_image016[6]

La interfaz es la misma en cualquier navegador o sistema operativo

clip_image018[6]

La opción de búsqueda no esta disponible en todos los navegadores/sistemas operativos (solo IExplorer)

clip_image020[6]

La opción de búsqueda siempre esta disponible

clip_image022[6]

Tiene la opción de “Carpetas Públicas”

clip_image024[6]

No tiene la opción de “Carpetas Públicas”

Esta opción debe ser reemplazada por “foros de discusión”

No tiene clientes de correo para dispositivos móviles

(Puede utilizar clientes de correo de otras empresas)
Permite acceder al correo mediante dispositivos móviles

clip_image026[6]

Espacio limitado para guardar los correos Espacio de 7 GB para cada cuenta de correos

clip_image028[6]

lunes, 15 de junio de 2009

Instalación de MediaWiki

Las características de la instalación son las siguientes:

  • El usuario anónimo sólo tiene acceso de lectura
  • El usuario y contraseña se valida contra un LDAP
  • El usuario local usado en la instalación debe ser desactivado
  • Se debe poder acceder al wiki solo con la dirección del dominio (ejemplo: http://wiki.ulma.edu/)

Para instalar  y configurar el mediawiki es necesario:

Instalación:

Instalar XAMPP

  • Ejecutar xampp-win32-1.x.x-installer.exe.
  • Aceptar los valores que aparecen en las ventanas de instalación (sólo instalar "Apache" y "MySQL" como servicio).
  • Al final de la instalación verificar en el “XAMPP Control Panel” que los servicios Apache y MySql  se ejecutan sin problemas.

image

Instalar MediaWiki

  • Copiar el directorio "mediawiki-1.xx.x" al directorio "c:\xampp\htdocs"
  • Renombrar el directorio "c:\xampp\htdocs\mediawiki-1.xx.x" a "c:\xampp\htdocs\mediawiki"

image 

Instalar la extensión Ldap_Authentication

  • Copiar "Ldap_Authentication.php" a "C:\xampp\htdocs\mediawiki\extensions"

image

Instalar la extensión InputBox

  • Crear el directorio "InputBox" en "C:\xampp\htdocs\mediawiki\extensions\"
  • Copiar "InputBox.classes.php", "InputBox.hooks.php", "InputBox.i18n.php" y "InputBox.php" a "C:\xampp\htdocs\mediawiki\extensions\InputBox"

image

Configuración:

Configurar MediaWiki

image

  • Copiar el archivo "LocalSettings.php" de "C:\xampp\htdocs\mediawiki\config" a "C:\xampp\htdocs\mediawiki"
  • Borrar el directorio "config" de "C:\xampp\htdocs\mediawiki"
  • Editar el archivo "LocalSettings.php" de "C:\xampp\htdocs\mediawiki"

clip_image002[4]

clip_image002[6]

  • Crear el archivo "mediawiki.conf" en "C:\xampp\apache\conf\extra"
  • Editar el archivo "mediawiki.conf"

clip_image002[8]

  • Editar el archivo httpd.conf en "C:\xampp\apache\conf\"

clip_image002[10]

  • Editar el archivo "php.ini" en "C:\xampp\php\" (eliminar el ";")

clip_image002[14]

 

Configurar XAMPP

  • Editar el archivo "index.php" en "C:\xampp\htdocs"

clip_image002[16]

image

  • Reiniciar Apache y MySQL

image

.

Después de haber realizado los pasos descritos arriba solo las personas con usuario y contraseña serán capaces de crear artículos en el wiki y la validación se realiza en un servidor LDAP.