Proyecto Educativo Informático

DEFINICIÓN DEPROYECTO EDUCATIVO

Un proyecto puede ser una idea, un plan o un programa. El concepto se emplea para nombrar al conjunto de las acciones que se ejecutan coordinadamente con el objetivo de alcanzar una cierta meta.

Educativo, por su parte, es un adjetivo que califica lo que está vinculado con la educación (la

instrucción o formación que se desarrolla en el marco de un proceso de enseñanza y aprendizaje).

Con estas ideas en claro, ya podemos centrarnos en el concepto de proyecto educativo. Se trata de una propuesta formativa que alguien planea llevar a cabo en un cierto ámbito. Por ejemplo: “Me gustaría implementar un proyecto educativo en el club para que las personas mayores aprendan informática”, “La asociación de fomento anunció un proyecto educativo destinado a los niños del barrio”, “Las autoridades se comprometieron a reformar el proyecto educativo antes de someterlo a votación”.

Puede decirse que un proyecto educativo consiste en la planificación de un proceso para que los alumnos alcancen ciertos objetivos de aprendizaje. Como cualquier proyecto, surge a partir de la detección de una necesidad o de un problema y su finalidad es la satisfacción o resolución de aquello detectado.

Muchas veces, los problemas y las necesidades no son aparentes, independientemente de su gravedad. Por ello no se debe esperar a que se manifiesten, sino que conviene observar de cerca y con frecuencia la realidad de los distintos ámbitos de la sociedad para gozar del tiempo prudente de planeamiento y dar lugar a una ejecución efectiva y con resultados duraderos. Nunca se debe subestimar la importancia de esta primera fase, ya que constituye la base sobre la cual se apoya la acción.

Supongamos que, en un pueblo, los educadores advierten sobre la falta de conocimientos de los jóvenes sobre sexualidad. Con el objetivo de prevenir el contagio de enfermedades de transmisión sexual y minimizar las probabilidades de embarazos no deseados, deciden desarrollar un proyecto educativo que implique la formación de los adolescentes en estos temas. A partir de entonces, se acuerda dictar clases de educación sexual en las escuelas, repartir folletos informativos en los clubes y enseñar sobre métodos anticonceptivos en eventos públicos.

Se conoce como proyecto educativo de centro al documento de naturaleza pedagógica que elabora la Comunidad Educativa para definir y enumerar los rasgos que identifican a un centro determinado, formular los objetivos que desea alcanzar y expresar su estructura funcional y organizativa. Se trata de una serie de declaraciones coherentes que persiguen la dirección de un proceso de intervención, para lo cual proveen los puntos fundamentales que dan lugar a la acción y la evolución.

El proyecto educativo de centro debe definir claramente todos los objetivos que desea alcanzar la Comunidad, haciendo especial hincapié en los rasgos que distinguen al centro en cuestión del resto. Este documento debe facilitar la jerarquización de los diferentes puntos, los cuales deben hacerse operativos en las programaciones de la actividad de los maestros y en el plan anual, para llegar a los alumnos y ser evaluados. Es importante señalar que este tipo de proyecto no es inalterable.

Una de las prioridades de un proyecto educativo de centro en un colegio inclusivo es asumir la diversidad de sus alumnos y, por lo tanto, posibilitar la creación de un proyecto curricular y de una organización que los beneficien a todos por igual, a través del trabajo de docentes y demás profesionales del instituto. En otras palabras, el proyecto debe ofrecer respuestas a ciertas preguntas que definan tanto la identidad del centro como los fines que se plantea, sin dejar de lado la observación de su contexto histórico, económico y social, las herramientas y los recursos que usará y el grupo humano involucrado

Desde un punto de vista muy general puede considerarse que todo proyecto tiene tres grandes etapas:

·         Fase de planificación. Se trata de establecer cómo el equipo de trabajo deberá satisfacer las restricciones de prestaciones, planificación temporal y costo. Una planificación detallada da consistencia al proyecto y evita sorpresas que nunca son bien recibidas.

·         Fase de ejecución. Representa el conjunto de tareas y actividades que suponen la realización propiamente dicha del proyecto, la ejecución de la obra de que se trate. Responde, ante todo, a las características técnicas específicas de cada tipo de proyecto y supone poner en juego y gestionar los recursos en la forma adecuada para desarrollar la obra en cuestión. Cada tipo de proyecto responde en este punto a su tecnología propia, que es generalmente bien conocida por los técnicos en la materia.

·         Fase de entrega o puesta en marcha. Como ya se ha dicho, todo proyecto está destinado a finalizarse en un plazo predeterminado, culminando en la entrega de la obra al cliente o la puesta en marcha del sistema desarrollado, comprobando que funciona adecuadamente y responde a las especificaciones en su momento aprobadas. Esta fase es también muy importante no sólo por representar la culminación de la operación sino por las dificultades que suele presentar en la práctica, alargándose excesivamente y provocando retrasos y costos imprevistos.

A estas tres grandes etapas es conveniente añadir otras dos que, si bien pueden incluirse en las ya mencionadas, es preferible nombrarlas de forma independiente ya que definen un conjunto de actividades que resultan básicas para el desarrollo del proyecto:

·         Fase de iniciación. Definición de los objetivos del proyecto y de los recursos necesarios para su ejecución. Las características del proyecto implican la necesidad de una fase o etapa previa destinada a la preparación del mismo, fase que tienen una gran trascendencia para la buena marcha del proyecto y que deberá ser especialmente cuidada. Una gran parte del éxito o el fracaso del mismo se fragua principalmente en estas fases preparatorias que, junto con una buena etapa de planificación, algunas personas tienden a menospreciar, deseosas por querer ver resultados excesivamente pronto.

·         Fase de control. Monitorización del trabajo realizado analizando cómo el progreso difiere de lo planificado e iniciando las acciones correctivas que sean necesarias. Incluye también el liderazgo, proporcionando directrices a los recursos humanos, subordinados (incluso subcontratados) para que hagan su trabajo de forma efectiva y a tiempo.

Los periodos generales de duración los podemos ver a continuación:

Estas etapas citadas presentan, sin embargo, características bastante diferentes según se trate de proyectos internos o de proyectos externos. Las principales diferencias aparecen en la etapa de planificación. En el proyecto externo existen un conjunto de acciones que se relacionan con la necesidad de presentar una oferta al cliente y lograr la adjudicación del contrato en competencia con otras empresas o personas. Si, por la razón que fuere, el contrato no se consigue el proyecto queda abortado antes de haberse comenzado y carece de sentido preocuparse de cómo debe ser gestionado. La exigencia comercial tiene, pues, un carácter prioritario para las empresas, siendo la consecución del contrato paso imprescindible para poder acometer un proyecto concreto y, con una perspectiva más amplia, condición esencial para la supervivencia de la empresa. Puedes ver más sobre la importancia del perfil comercial en el capítulo de oferta.

Haciendo referencia a las tres grandes etapas nombradas al principio, podemos ver la diferencia entre ambos tipos de proyectos:

Cuando se abordan proyectos grandes y complejos, la consecución del resultado final depende de la realización armónica del conjunto de las etapas pertinentes con ayuda de los medios materiales y humanos requeridos en cada momento. La concepción de las fases que han de ejecutarse, el orden de encadenamiento lógico de las mismas y la estimación de la naturaleza y cantidad de recursos a emplear en cada momento, precisan de un conocimiento profundo de las tecnologías que concurren en el proyecto y de una experiencia que permita prever y superar las dificultades que en la práctica suelen aparecer.

A continuación se presentan las distintas etapas en el desarrollo de una aplicación informática:

ETAPA 1	Nacimiento de la idea del proyecto
	El "cliente o promotor" expone sus necesidades y el deseo de resolver el problema por medios informáticos. Se crea un primer documento breve que recoge el anteproyecto y es aprobado por la dirección o el comité correspondiente.
ETAPA 2	Estudio de oportunidad
	El estudio de oportunidad concreta los objetivos y resultado a aportar por el proyecto, los plazos y costos previstos y los medios a emplear.
ETAPA 3	Estudio detallado
	El jefe de proyecto define, ya en detalle, con el apoyo de los técnicos de su equipo, el contenido del proyecto, su análisis funcional,, las cargas de trabajo previstas y la metodología a desarrollar.
ETAPA 4	Cuaderno de cargas para informática
	A partir del análisis funcional se determinan en forma definitiva los volúmenes, cargas de trabajo, calendario y medios a utilizar, dando lugar al contrato formal entre cliente, usuarios e informáticos, frecuentemente conocido con el nombre de cuaderno de cargas o, más concretamente, "pliego de especificaciones".
ETAPA 5	Análisis orgánico
	Los técnicos realizan el análisis orgánico y las especificaciones para programación.
ETAPA 6	Programación y pruebas
	Se realiza la programación de la aplicación y las pruebas para programación.
ETAPA 7	Recepción provisional
	Al resultar satisfactorias las pruebas se realiza la recepción provisional, dando lugar a los manuales de usuario y de explotación.
ETAPA 8	Puesta en marcha
	La puesta en marcha de la aplicación es una fase delicada que requiere una estricta vigilancia hasta comprobar su correcto funcionamiento. A continuación se realiza un balance de los resultados del proyecto.
ETAPA 9	Balance de funcionamiento
	Después de varios meses de funcionamiento de la aplicación se debe realizar un balance que permita apreciar los beneficios que realmente ha producido a la empresa.
ETAPA 10	Auditoría
	Transcurridos uno o dos años, debe efectuarse una auditoría de la aplicación que permita comprobar si sigue siendo adecuada o si es necesario introducir modificaciones.

Desde el punto de vista de la metodología de gestión de proyectos, también pueden identificarse varias fases que generalmente deberán darse en todo tipo de proyectos:

1. Decisión de acometer el proyecto.
2. Nombramiento del jefe de proyecto.
3. Negociación de objetivos.
4. Preparación.
5. Ejecución.
6. Información.
7. Control.

Dentro de la preparación, se integrarían actividades como la descripción de actividades, identificación de recursos, valoración de los mismos -presupuesto-, planificación y eventual reconsideración de los objetivos.

Objetivos de un proyecto.

Una de las fases más complejas del proyecto es la de definir los objetivos. La persona que encarga el proyecto rara vez conoce claramente los objetivos, tan solo tiene una idea general de querer informatizar algún proceso o gestionar algo. Este es uno de los inconvenientes con que se encuentra el informático en las primeras fases del proyecto. El no definir los objetivos correctamente es la causa de muchos de los problemas que se presentan durante el ciclo de desarrollo del proyecto como pueden ser: 

·         El cliente puede no quedar satisfecho con el producto final, ya que es posible que no haya definido correctamente lo que quiere.

·         El cliente puede introducir objetivos o restricciones durante la ejecución del proyecto que afecten de manera sustancial al mismo.

·         La no concreción o ambigüedad de los objetivos puede provocar que nadie se responsabilice de los fallos, ya que gran parte del proyecto habrá sido dejado al criterio del programador, en vez de ser este únicamente el técnico que permita obtener los objetivos impuestos por el cliente.

Los objetivos debe fijarlos quien encarga el proyecto, y estos deben ser claros, concretos y no ambiguos, además deben quedar definidos desde el primer momento en que se establezca el convenio de trabajo.

·         Ciclo de vida de un software.

Por ciclo de vida, se entiende: La sucesión de etapas por las que pasa el software desde que un nuevo proyecto es concebido hasta que se deja de usar. Cada una de estas etapas lleva asociada una serie de tareas que deben realizarse, y una serie de documentos (en sentido amplio: software) que serán la salida de cada una de estas fases y servirán de entrada en la fase siguiente.

La elección de un paradigma u otro se realizan de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos a usar y los controles y entregas requeridos

La elección del ciclo de vida más apropiado para un proyecto es una cuestión fundamental en la estrategia con la que se afronta, ya que incide muy decisivamente en la velocidad con la que se llevará a cabo el proyecto y la satisfacción que generará al cliente. El ciclo de vida claramente dominante hasta hace relativamente poco era el modelo en cascada donde existen las fases de recogida de requisitos, análisis, diseño, codificación, pruebas y mantenimiento del producto. Todas ellas se ejecutan en secuencia, lo que le ha dado a este tipo de ciclo de vida su nombre.

Modelos de ciclos de vida de un software

Existen diversos modelos de ciclo de vida, es decir, diversas formas de ver el proceso de desarrollo de software, y cada uno de ellos va asociado a un paradigma de la ingeniería del software, es decir, a una serie de métodos, herramientas y procedimientos que debemos usar a lo largo de un proyecto. Aquí veremos algunos de los principales modelos de ciclo de vida.

"Modelo en cascada".

El modelo en cascada es el ciclo de vida clásico, su principal característica es la naturaleza estrictamente secuencial de la ejecución de sus fases. Al aprobar cada una de ellas se genera la documentación adecuada que permite comenzar con la siguiente, ante defectos que se detectan en la ejecución de una fase determinada posiblemente haya necesidad de volver a la fase inmediatamente anterior y corregir o modificar algunos de sus contenidos, pero es algo que se debe evitar en la medida de lo posible. Esta naturaleza se explica con el carácter más homogéneo de las aplicaciones y la plataforma tecnológica mucho más simple de hace unas décadas (las aplicaciones eran prácticamente siempre aplicaciones de gestión sobre host con un nivel de complejidad relativamente simple frente a las actuales). Este modelo resulta adecuado cuando los requisitos están bien definidos, son estables desde el comienzo del proyecto y se dominan las metodologías y herramientas utilizadas en el proyecto, ya que minimiza el tiempo dedicado a cada una de las tareas.

Ventajas:

·         Minimiza las tareas de desarrollo repetidas y por tanto el esfuerzo de desarrollo invertido en total.

·         Minimiza la carga de planificación de los ciclos iterativos de otros ciclos de vida.

·         Permite afrontar la complejidad de proyectos grandes de una manera muy ordenada y aumenta así las posibilidades de éxito.

·         Ayuda a trabajar mejor con equipos de desarrollo de relativamente baja calificación por el alto control de cada actividad y sus resultados.

Inconvenientes

·         Es muy inflexible, por tanto solamente resulta adecuado cuando hay requerimientos muy bien definidos y muy estables, algo que es difícil de encontrar.

·         Retroceder en las fases para corregir errores que se han cometido en fases previas o adaptar el proyecto a cambios resulta muy difícil y costoso en esfuerzo.

·         Aunque la documentación elaborada permite un seguimiento bueno del proyecto para una persona calificada, los resultados tangibles para el cliente aparecen prácticamente al final del proyecto, algo que muchas veces no aceptan los clientes.

"Modelo prototipo".

 

Fase A: El objetivo de la fase A es verificar la adecuación del sistema que se va a desarrollar a los requerimientos expresados por el usuario. Exige una evaluación por parte de éste: una vez el prototipo aceptado ya se tiene un modelo a escala del sistema completo que hay que construir.

Fase B: El punto de entrada en la fase B es el prototipo construido y aceptado en el que se han detallado los diseños de pantalla y listados, los encadenamientos de módulos y los flujos de datos. Con estas informaciones contrastadas ya se tiene la descomposición en programas, con lo que este modelo de ciclo de vida en la fase B se ocupa del desarrollo y prueba de los programas y de la integración de los mismos en la solución final.

Ventajas:

·         El caso de requerimientos cambiantes e incapacidad de parte del cliente para definirlos con el suficiente detalle se da con frecuencia, abordar el proyecto de esta manera es una solución muy natural ante este problema y evita en gran medida los conflictos con el cliente.

·         El cliente participa muy activamente en el desarrollo, por tanto, las posibilidades de alcanzar un producto que haga lo "que el quiere" son altas.

·         Aporta resultados tangibles que permiten al cliente medir el progreso del proyecto.

·         En muchas ocasiones el cliente gana tiempo en el sentido que ya le resultan útiles los primeros prototipos y amortiza la inversión desde un punto muy temprano mientras que se sigue mejorando el resultado final. Esta faceta frecuentemente hace que el cliente esté dispuesto a asumir una inversión global algo mayor a la que estaría dispuesto hacer si tuviera que esperar hasta la entrega final del producto, añade por tanto mucha flexibilidad a la negociación del proyecto

Inconvenientes:

·         En proyectos de cierta envergadura es prácticamente imposible saber cuando se llegará al producto final, ni cuantos prototipos intermedios serán necesarios hasta entonces.

·         No es fácil convencer al cliente de la necesidad de tirar determinados prototipos "a la basura", hay una gran tentación de no llegar al final con las iteraciones necesarias.

·         Desde el punto de vista de los desarrolladores, este ciclo de vida puede ser una tentación a desarrollar de forma anárquica, es decir, dejar de lado la modificación de la especificación de requisitos, análisis, etc. que corresponde a cada iteración.

"Modelo Desarrollo en espiral".

El desarrollo en espiral es un ciclo de vida muy orientado a la eliminación progresiva de los riesgos, es un ciclo de vida iterativo en cuyas iteraciones se enfocan uno o más riesgos objetivos que han de superarse hasta que el nivel de riesgo sea suficientemente bajo para continuar con un ciclo menos complejo.

En cada iteración se realizan los siguientes pasos:

·         Planificación: Determinar objetivos, alternativas y restricciones.

·         Análisis de riesgo: Análisis de riesgos y evaluación de alternativas.

·         Ingeniería: Desarrollo de los entregables o prototipos de la iteración.

·         Evaluación del resultado: Evaluación y validación del resultado.

Ventajas:

·         Puesto que se trata de un modelo orientado a los riesgos del proyecto da un nivel de seguridad muy elevado al proyecto, los riesgos se eliminan al principio que es cuando mejor se puede reaccionar a ellos y en el caso negativo extremo de detectar la inviabilidad del proyecto, minimiza la inversión realizada en él.

·         Una mayor inversión en esfuerzo (y con ello tiempo y dinero) se traduce directamente en mayor seguridad del proyecto, ya que permite gestionar con mayor dedicación los riesgos.

·         El cliente dispone mediante los prototipos de resultados tangibles en cada iteración y participa de una manera muy interactiva en la evolución del proyecto con lo cual se mejoran mucho las posibilidades de satisfacción del resultado. Inconvenientes:

·         El único inconveniente es la complejidad y carga de gestión de este modelo.

El desarrollo orientado a prototipos que se evalúa progresivamente no se debe confundir con este modelo en espiral, aunque tienen bastante parecido en cuanto a su carácter iterativo, en el modelo en espiral se trata de enfocar los mayores riesgos desarrollando primero las facetas relacionadas con ellos y eliminarlos así cuanto antes, es decir, los riesgos determinan la evolución del proyecto. En el desarrollo evolutivo de prototipos se parte de un concepto inicial de la aplicación y es este concepto el que evoluciona. Es decir, en este modelo se desarrolla un primer prototipo relativamente completo, frecuentemente destinado a ser ya utilizado por cliente. El cliente aporta realimentación y con ella se desarrolla la siguiente versión, y así sucesivamente hasta que se alcance una versión que le satisface. Resulta útil cuando el cliente tiene prisa en desarrollar la aplicación, pero no es capaz de definirla con exactitud y el mismo tiene que aprender más de la problemática que debe resolver con la aplicación. También resulta adecuado cuando se prevé que los requerimientos van a tener una tasa de cambio alta durante el desarrollo del proyecto.

"Modelo Desarrollo orientado a Hitos"

Con frecuencia se da el caso que el factor limitante es el tiempo más que el presupuesto o el detalle de la funcionalidad. En estos casos puede ser muy oportuno aplicar este ciclo de vida que asume ciertas indefinición en la envergadura final de las funcionalidades implementadas, pero fija claramente un punto final en el tiempo. En un desarrollo grande puede ser además muy útil para gestionar el desarrollo de módulos individuales no críticos con el fin de que no retrasen el progreso global del proyecto.

En este ciclo de vida básicamente se trabaja secuencialmente en la base estable del producto que incluye llegar hasta el diseño de la arquitectura, pero a partir de ahí se trabaja en ciclos iterativos sobre el diseño detallado, codificación y pruebas. Los contenidos de estos ciclos se priorizan para optimizar según la relevancia de las funcionalidades implementadas.

Ventajas:

·         Es una estrategia relativamente óptima ante una situación de fecha límite rígida.

·         Permite reducir mucho el riesgo en proyectos grandes si se gestionan sus módulos de menor prioridad con esta técnica.

Inconvenientes:

·         Si se consiguen implementar relativamente pocas funcionalidades de las previstas se habrá perdido mucho tiempo en la especificación y diseño de funcionalidades no implementadas al final, por tanto hay que medir bien la ambición del trabajo previo a los ciclos iterativos.

Nótese que se combina en cierta manera el enfoque clásico con el modelo en espiral dividiendo la parte más gruesa del desarrollo en fase priorizadas que permiten optimizar la relevancia del trabajo realizado dentro de unos límites de tiempo, obsérvese especialmente el matiz que la fase de diseño no iterativa se limita al diseño de la arquitectura ya que no varía con las iteraciones.

"Modelo de desarrollo en versiones sucesivas".

Este modelo de ciclo de vida pretende resolver uno de los problemas del modelo en cascada: La tardía aparición de un modelo funcional del sistema en desarrollo.

Para ello se realiza una serie de iteraciones sobre el propio modelo en cascada. En la primera se obtiene una primera versión del sistema. En cada una de las demás iteraciones el modelo se refina hasta alcanzar una versión definitiva que satisfaga plenamente los requerimientos de usuario.

En cada iteración, se reelaboran los requerimientos según se encuentren carencias o inexactitudes con la idea original del usuario. Los nuevos requerimientos se someten a análisis, se modifican los diseños, y se procede a las modificaciones pertinentes del código. Finalmente se procede a probar la nueva versión del modelo. Si el resultado obtenido se ajusta a los deseos del usuario, el proceso finaliza, en caso contrario se procede a una nueva iteración.

Las versiones obtenidas pueden obedecer también a un único plan inalterable. En este caso lo que se hace es realizar una implementación gradual de los requerimientos, en la que se pasa de un esbozo funcional a versiones cada vez más refinadas y cercanas a las especificaciones. En esta forma se denomina Modelo evolutivo.

Los principales inconvenientes de este paradigma están en las tareas de modificación de código, que resultan complejas y sujetas a errores salvo que se haga uso de herramientas automáticas o lenguajes de cuarta generación. Otro problema es que las posibles incorrecciones, o los "parches" incorporados a una versión, permanecen en ella y se convierten en la base para el código posterior. De esta forma, una mala estructuración, arquitectura defectuosa osoluciones parciales que sirven para hacer operativamente correcta una versión, degradan el trabajo invertido en la construcción de las siguientes.

"Modelo de transformación".

Este modelo trata de resolver los problemas asociados a la dificultad de modificar el código en paradigmas como el de versiones sucesivas. Para ello parte de la premisa de la existencia de un sistema que pueda convertir fácilmente los requerimientos en código.

Los pasos seguidos en este modelo son:

·         Una especificación formal del sistema.

·         Una transformación automática (o asistida) de las especificaciones a código.

·         Una serie de iteraciones sobre el código obtenido con objeto de mejorarlo.

·         Prueba general del resultado.

·         Iteraciones para ajustar el resultado a las especificaciones. Si se realiza alguna modificación sobre éstas se repite el proceso hasta que requerimientos y código final sean válidos.

La principal dificultad para la aplicación de este modelo de desarrollo está en la falta de un sistema adecuado para transformar los requerimientos en código. Esta transformación puede ser llevada a cabo en pequeños proyectos dedicados a tareas específicas, pero no es posible generalizar su aplicación.

"Modelo Mixto"

Los modelos presentados solo son algunos de los existentes, ante un proyecto concreto cabe la posibilidad de combinar modelos diferentes si el perfil del proyecto lo hace aconsejable, es decir, los modelos presentados no se deben interpretar con un espíritu excesivamente purista, sino tomarlos comoestrategias de base ante una serie de características de un proyecto.

Lo importante es que se haga el ejercicio de plantear una estrategia de desarrollo que responda de una manera coherente a la situación previsible del proyecto al que se aplica. Los modelos aquí presentados pueden ser válidos para muchas ocasiones, y si no lo fueran constituirán una "inspiración" para diseñar

El nombre de dominio .com es un dominio de nivel superior (TLD por sus siglas en inglés) que forma parte del Sistema de Nombres de Dominio (DNS) de Internet. Su nombre deriva de la palabra «comercial»,¹​ lo que indica que originalmente estaba pensado para dominios registrados por organizaciones comerciales. Sin embargo, esta distinción finalmente se perdió cuando los registros para los dominios .com,.org y .net se abrieron de forma ilimitada.

El dominio .com fue uno de los primeros dominios de nivel superior en Internet cuando se implementó el Sistema de Nombres de Dominio en enero de 1985; los otros nombres de dominio eran .edu, .gov,.mil, .net, .org y .arpa. Desde entonces, este nombre ha crecido hasta convertirse en el mayor dominio de nivel superior.²​

Si bien cualquier compañía en el mundo puede registrar un dominio .com, muchos países ofrecen dominios de segundo nivel con un propósito similar. Estos Los nombres de dominios llevan nombres de la forma .com.xx o .com.xx donde xx es el dominio de nivel superior correspondiente al país. Algunos ejemplos son Australia (.com.au), Reino Unido (.com.uk),Colombia (.com.co), Perú (.com.pe) o Brasil (.com.br).