Вы находитесь на странице: 1из 15

PLANIFICACIÓN DE PROYECTOS DE SOFTWARE

Autor: Pedro Concepción

1. Que es un proyecto de Sistema o Software.

Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un


conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo al
futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimación, es mas
un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma
descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la
estimación es la base de todas las demás actividades de planificación del proyecto y sirve
como guía para una buena Ingeniería Sistemas y Software.

Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto,


sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es
otro factor importante que puede afectar la precisión de las estimaciones. A medida que el
tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del
Software.

La disponibilidad de información Histórica es otro elemento que determina el riesgo de la


estimación.

2. Objetivos de la Planificación del Proyecto.

El objetivo de la Planificación del proyecto de Software es proporcionar un marco de


trabajo que permita al gestor hacer estimaciones razonables de recursos costos y
planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado
al comienzo de un proyecto de software, y deberían actualizarse regularmente medida que
progresa el proyecto. Además las estimaciones deberían definir los escenarios del mejor
caso, y peor caso, de modo que los resultados del proyecto pueden limitarse.

El Objetivo de la planificación se logra mediante un proceso de descubrimiento de la


información que lleve a estimaciones razonables.

3. Actividades asociadas al proyecto de software.

1.3.1 Ambito del Software.

Es la primera actividad de llevada a cabo durante la planificación del proyecto de Software.

En esta etapa se deben evaluar la función y el rendimiento que se asignaron al Software


durante la Ingeniería del Sistema de Computadora para establecer un ámbito de proyecto
que no sea ambiguo, e incomprensible para directivos y técnicos
Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se
evalúan las funciones del ámbito y en algunos casos se refinan para dar mas detalles antes
del comienzo de la estimación. Las restricciones de rendimiento abarcan los requisitos de
tiempo de respuesta y procesamiento, identifican los límites del software originados por el
hardware externo, por la memoria disponible y por otros sistemas existentes.

El Ámbito se define como un pre-requisito para la estimación y existen algunos elementos


que se debe tomar en cuenta como es:

La Obtención de la Información necesaria para el software. Para esto el analista y el cliente


se reúnen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de interés
para su desarrollo.

4. Recursos.

La Segunda tarea de la planificación del desarrollo de Software es la estimación de los


recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una
pirámide donde las Herramientas (hardware y Software), son la base proporciona la
infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se
encuentran los Componentes reutilizables.

Y en la parte mas alta de la pirámide se encuentra el recurso primario, las personas (el
recurso humano).

Cada recurso queda especificado mediante cuatro características:

· Descripción del Recurso.

Informes de disponibilidad.
Fecha cronológica en la que se requiere el recurso.
Tiempo durante el que será aplicado el recurso.

1.4.1 Recursos Humanos.

La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo


puede ser determinado después de hacer una estimación del esfuerzo de desarrollo (por
ejemplo personas mes o personas años), y seleccionar la posición dentro de la organización
y la especialidad que desempeñara cada profesional.

1.4.2 Recursos o componentes de software reutilizables.

Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la


reutilizacion, esto es la creación y la reutilizacion de bloques de construcción de Software.

Tales bloques se deben establecer en catálogos para una consulta más fácil, estandarizarse
para una fácil aplicación y validarse para la también fácil integración.
El Autor Bennatan sugiere cuatro categorías de recursos de software que se deberían tener
en cuenta a medida que se avanza con la planificación:

· Componentes ya desarrollados.

Componentes ya experimentados.
Componentes con experiencia Parcial.
Componentes nuevos.

1.4.3 Recursos de entorno.

El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de


Ingeniería de Software, incorpora Hardware y Software.

El Hardware proporciona una plataforma con las herramientas (Software) requeridas para
producir los productos que son el resultado de la buena practica de la Ingeniería del
Software, un planificador de proyectos debe determinar la ventana temporal requerida para
el Hardware y el Software, y verificar que estos recursos estén disponibles. Muchas veces
el desarrollo de las pruebas de validación de un proyecto de software para la composición
automatizada puede necesitar un compositor de fotografías en algún punto durante el
desarrollo. Cada elemento de hardware debe ser especificado por el planificador del
Proyecto de Software.

5. Estimación del proyecto de Software.

En el principio el costo del Software constituía un pequeño porcentaje del costo total de los
sistemas basados en Computadoras. Hoy en día el Software es el elemento mas caro de la
mayoría de los sistemas informáticos.

Un gran error en la estimación del costo puede ser lo que marque la diferencia entre
beneficios y perdidas, la estimación del costo y del esfuerzo del software nunca será una
ciencia exacta, son demasiadas las variables: humanas, técnicas, de entorno, políticas, que
pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo.

Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles:

· Deje la estimación para mas adelante (obviamente podemos realizar una estimación
al cien por cien fiable después de haber terminado el proyecto.

Base las estimaciones en proyectos similares ya terminados.


Utilice técnicas de descomposición relativamente sencillas para generar las estimaciones de
costos y esfuerzo del proyecto.
Desarrolle un modelo empírico para él calculo de costos y esfuerzos del Software.
Desdichadamente la primera opción, aunque atractiva no es practica.

La Segunda opción puede funcionar razonablemente bien si el proyecto actual es bastante


similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Las
opciones restantes son métodos viables para la estimación del proyecto de software. Desde
el punto de vista ideal, se deben aplicar conjuntamente las técnicas indicadas usando cada
una de ellas como comprobación de las otras.

Antes de hacer una estimación, el planificador del proyecto debe comprender el ámbito del
software a construir y generar una estimación de su tamaño.

1.5.1 Estimación basada en el Proceso.

Es la técnica más común para estimar un proyecto es basar la estimación en el proceso que
se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeño
de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimación de cada
tarea.

Al igual que las técnicas basadas en problemas, la estimación basada en el proceso


comienza en una delineación de las funciones del software obtenidas a partir del ámbito del
proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como
ultimo paso se calculan los costos y el esfuerzo de cada función y la actividad del proceso
de software.

6. Diferentes modelos de estimación.

Existen diferentes modelos de estimación como son:

1.6.1 Los Modelos Empíricos:

Donde los datos que soportan la mayoría de los modelos de estimación obtienen una
muestra limitada de proyectos. Por esta razón, el modelo de estimación no es adecuado para
todas las clases de software y en todos los entornos de desarrollo. Por lo tanto los resultados
obtenidos de dichos modelos se deben utilizar con prudencia.

1.6.2 El Modelo COCOMO.

Barry Boehm, en su libro clásico sobre economía de la Ingeniería del Software, introduce
una jerarquía de modelos de estimación de Software con el nombre de COCOMO, por su
nombre en Ingles (Constructive, Cost, Model) modelo constructivo de costos. La jerarquía
de modelos de Boehm esta constituida por los siguientes:

Modelo I. El Modelo COCOMO básico calcula el esfuerzo y el costo del desarrollo de


Software en función del tamaño del programa, expresado en las líneas estimadas.

Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software
en función del tamaño del programa y de un conjunto de conductores de costos que
incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos
del proyecto.
Modelo III. El modelo COCOMO avanzado incorpora todas las características de la versión
intermedia y lleva a cabo una evaluación del impacto de los conductores de costos en cada
caso (análisis, diseño, etc.) del proceso de ingeniería de Software.

1.6.3 Herramientas Automáticas De Estimación.

Las herramientas automáticas de estimación permiten al planificador estimar costos y


esfuerzos, así como llevar a cabo análisis del tipo, que pasa si, con importantes variables
del proyecto, tales como la fecha de entrega o la selección del personal. Aunque existen
muchas herramientas automáticas de estimación, todas exhiben las mismas características
generales y todas requieren de una o más clases de datos.

A partir de estos datos, el modelo implementado por la herramienta automática de


estimación proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto,
los costos, la carga de personal, la duración, y en algunos casos la planificación temporal de
desarrollo y riesgos asociados.

En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de
que comience el proyecto: cuanto durara, cuanto esfuerzo requerirá y cuanta gente estará
implicada. Además el planificador debe predecir los recursos de hardware y software que
va a requerir y el riesgo implicado.

Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos
de las tres técnicas referidas anteriormente. Mediante la comparación y la conciliación de
las estimaciones obtenidas con las diferentes técnicas, el planificador puede obtener una
estimación más exacta. La estimación del proyecto de software nunca será una ciencia
exacta, pero la combinación de buenos datos históricos y técnicas puede mejorar la
precisión de la estimación.
---------------------------------
7. Errores

ERRORES CLASICOS EN UN PROYECTO DE SOFTWARE

1. Mal análisis en los requerimientos.

2. Una mala planeación.

3. No tener una negociación (documento, contrato) con el cliente.

4. No hacer un análisis costo beneficio.

5. Desconocer el ambiente de trabajo de los usuarios.

6. Desconocer los usuarios que trabajan con el sistema.

7. Mala elección de recursos (hardware, software, humanos).


8. Herramientas para la planificación y Gestión de productos Software.

Para poder completar con éxito un proyecto de software, se necesita tener un control
riguroso sobre el tiempo, las personas o los imprevistos que puedan surgir, como por
ejemplo cambios en el software. Para ayudarnos en la planificación y gestión de proyectos,
Microsoft nos proporciona dos herramientas básicas: Microsoft Project y Microsoft
Solutions Framework.

· Microsoft Solutions Framework (MSF): es una flexible e interrelacionada serie de


conceptos, modelos y prácticas de uso que controlan la planificación, el desarrollo y la
gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de equipo
dejando en un segundo plano las elecciones tecnológicas. Originalmente creado en 1994
para conseguir resolver los problemas a los que se enfrentaban las empresas en sus
respectivos proyectos, se ha convertido posteriormente en un modelo práctico que facilita el
éxito de los proyectos tecnológico.

Trabajo realizado por Pedro Concepción.


http://www.monografias.net/trabajos/anaydisesis/anaydisesis.shtml

CRISIS DEL SOFTWARE

Durante los últimos años la industria del software ha ido experimentado una crisis creciente
de problemas, más o menos comunes a las distintas categorías de software.

Las principales tendencias de la llamada crisis del software son:

Calidad insuficiente del producto final


Estimaciones de duración de proyectos y asignación de recursos inexactas
Retrasos para entregar los productos terminados
Costos de desarrollo y mantención de productos fuera de control
Escasez de personal calificado en un mercado laboral de alta demanda
Tendencia al crecimiento del volumen y complejidad de los productos

La crisis se fundamentó en el tiempo de creación de software, ya que en la creación del


mismo no se obtenían los resultados deseados y además de un gran costo y una poca
flexibilidad.

La crisis del software es un término informático acuñado en 1968, en la primera


conferencia organizada por la OTAN sobre desarrollo de software, de la cual nació
formalmente la rama de la Ingeniería de Software. El término se adjudica a F. L. Bauer,
aunque previamente había sido utilizado por Edsger Dijkstra en su obra The Humble
Programmer.

Básicamente, la crisis del software se refiere a la dificultad en escribir programas libres de


defectos, fácilmente comprensibles, y que sean verificables. Las causas de la crisis del
software son, entre otras, la complejidad que supone la tarea de programar, y los cambios a
los que se tiene que ver sometido un programa para ser continuamente adaptado a las
necesidades de los usuarios.

Además, no existen todavía herramientas que permitan estimar de una manera exacta, antes
de comenzar el proyecto, cuál es el esfuerzo que se necesitará para desarrollar un programa.
Este hecho provoca que la mayoría de las veces no sea posible estimar cuánto tiempo
llevará un proyecto, ni cuánto personal será necesario. Cuando se fijan plazos normalmente
no se cumplen por este hecho. Del mismo modo, en muchas ocasiones el personal asignado
a un proyecto se incrementa con la esperanza de disminuir el plazo de ejecución.

Por último, las aplicaciones de hoy en día son programas muy complejos, inabordables por
una sola persona.

En sus comienzos se valoró como causa también la inmadurez de la Ingeniería de Software,


aunque todavía hoy en día no es posible realizar estimaciones precisas del coste y tiempo
que necesitará un proyecto de software.

La crisis del software englobó a una serie de sucesos que se venían observando en los
proyectos de desarrollo de software:

Los proyectos no terminaban en plazo


Los proyecto no se ajustaban al presupuesto inicial
Baja calidad del software generado
Software que no cumplía las especificaciones
Código inmantenible que dificultaba la gestión y evolución del proyecto
Aunque se han propuesto diversas metodologías para intentar subsanar los problemas
mencionados, lo cierto es que todavía hoy no existe ningún método que haya permitido
estimar de manera fiable el coste y duración de un proyecto antes de sus comienzos.

La crisis del software

“El software está en crisis”. A los que nos dedicamos a la informática esto nos suena a
tópico, es algo que hemos oído en la carrera y hemos ido leyendo a lo largo de muchos años
en multitud de lugares. Además, es algo en lo que todos están de acuerdo y que aún no se
ha arreglado, ni tiene pinta de arreglarse en los años venideros.

Pero, ¿qué es la crisis del software? Este término fue acuñado ya en los años 70, cuando la
industría del software ya había producido los suficientes programas para darse cuenta de
que había algo que fallaba. En concreto estas eran sus principales inquietudes:

¿Por qué lleva tanto tiempo terminar los programas?


¿Por qué es tan elevado el coste?
¿Por qué no podemos encontrar todos los errores antes de entregar el software a nuestros
clientes?
¿Por qué es tan difícil constatar el progreso durante el desarrollo?
¿Por qué es tan difícil calcular cuánto tiempo va a costar?
Esto pasaba entonces y pasa ahora, y por eso se dice que el software está en crisis. Ante
dicha situación se planteó el aplicar métodos científicos y rigurosos al proceso de desarrollo
de programas, apareciendo en escena la Ingeniería del Software y la Ingeniería de
Requerimientos. ¿Han solucionado el problema? No, pero algo han aportado. Ahora lo
mejor que sabemos hacer para afrontar de forma seria el desarrollo de una aplicación es
análisis y requisitos + programación + ciclo de pruebas. Y esto funciona, pero tiene dos
inconvenientes: el primero es que es muy difícil hacer un buen análisis que sepa abarcar
todas las necesidades del cliente antes de que éste vea el producto final (entre otras cosas
porque el cliente no sabe lo que quiere); el segundo es que nadie hace el esfuerzo de
analizar y especificar requisitos, teniendo dicha parte el menor peso específico dentro de
todo el desarrollo.

Una de las formas de abordar el primer problema son las consultoras enfocadas al usuario.
Una de ellas es The Cocktail, y cito literalmente un fragmento de su web en el que explican
una de las cosas que hacen:

es decir, conseguimos que el usuario se entere de qué va el servicio, qué puede hacer y
cómo. Para que lo haga lo mejor posible. que no es poco.

Si el cliente tiene claro qué quiere, interferirá mucho menos en el proceso de desarrollo
obligando a cambiar aspectos que ya habían sido combenidos previamente. Y, aún así, a
pesar de todo, lo hará.

Decía un profesor mío de Ingeniera del Software:

“El software no está en crisis, menuda tontería. La crisis le viene desde que nació. Lo que
hay que plantearse es por qué no ha salido de esa crisis en todo este tiempo.“

Y creo que tiene razón.

*****

Hay varias razones que pueden ser propuestas como causa de la crisis, todas tienen en
común que son causadas por el método de valorar los avances científicos y el mecanismo
actual de financiación de la actividad científica. Las causas de la crisis del software fueron
vinculadas a la complejidad en general del proceso de software y a la relativa madurez de la
ingeniería de software como una profesión. La crisis se manifestó con proyectos
gestionados con un sobre-presupuesto, proyectos gestionados con sobre tiempo y software
de baja calidad. El software a menudo no satisfacía los requerimientos deseados. Los
proyectos fueron inmanejables, con un código difícil de mantener.

RUP (Rational Unified Process)


El Proceso Racional Unificado (RUP) es un proceso de desarrollo de software que junto
con el UML, constituye la metodología estándar más utilizada para el análisis,
implementación y documentación de sistemas orientados a objetos. Se caracteriza por la
forma disciplinada de asignar tareas y responsabilidades y porque pretende implementar el
desarrollo iterativo, la administración de requisitos, el uso de arquitectura basada en
componentes, el control de cambios, el modelado visual del software y la verificación de la
calidad del software.

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental,


estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son
los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código
fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una
persona puede desempeñar distintos roles a lo largo del proceso).

El RUP divide el proceso de desarrollo en ciclos, cada ciclo se divide en fases que finalizan
con un hito donde se debe tomar una decisión importante:

Inicio: se hace un plan de fases, se identifican los principales casos de uso y se identifican
los riesgos.
Elaboración: se hace un plan de proyecto, se completan los casos de uso y se eliminan los
riesgos.
construcción: se concentra en la elaboración de un producto totalmente operativo y
eficiente y el manual de usuario.
Transición: se implementa el producto en el cliente y se entrena a los usuarios. Como
consecuencia de esto suelen surgir nuevos requisitos a ser analizados.

SCRUM
Siguiendo el simil deportivo, se compara al nuevo modelo de desarrollo, basado en el
solapamiento de las fases y en un único equipo multi-disciplinar, con la evolución del juego
del rugby; y de él se toma el término scrum.
Es una metodología expuesta por Hirotaka Takeuchi e Ikujiro Nonaka que se emplea para
el desarrollo de productos que trabajan con entornos de requisitos inestables y que
requieren rapidez y flexibilidad. Los elementos de proceso son:
Roles. Propietario del producto, manager del scrum, equipo e interesados.
Componentes del proceso: Pila del producto, pila del sprint, incremento.
Reunión: Planificación del sprint, revisión diaria, revisión del sprint.
La finalidad de estas reuniones es alinear a todas las personas en la misma dirección y sacar
a la luz los problemas e impedimentos que hay para conseguir el objetivo.
Las claves de este sistema son priorizar la solución de errores, tener el mismo objetivo para
todo el equipo, organización del trabajo.

XP (EXTREME PROGRAMMING)
Proceso de desarrollo de software que usa desarrollo iterativo, pruebas unitarias continuas,
programación por parejas, suponiendo que la mayor calidad del software escrito de esta
manera es más importante que la pérdida de productividad. Interacción del equipo de
programación con el usuario, correción de todos los errores antes de añadir, reescribir
ciertas partes del código para aumentar su legibilidad, y realizar el mantenimiento sin
modificar el comportamiento del software, todos participan en el proyecto y pueden
corregir errores, se simplifica el código.
Pair Programming (programación por parejas)
Se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo
puesto. El código es revisado y discutido mientras se escribe- es más importante que la
posible pérdida de productividad inmediata por dos programadores XP.

PSP (Personal Software Process)


El Proceso Personal de Software fue propuesto por Watts Humphrey en 1995 y estaba
dirigido a estudiantes. Se caracteriza porque es de uso personal y se aplica a programas
pequeños de menos de 10.000 líneas de código. Se centra en la administración del tiempo y
en la administración de la calidad a través de la eliminación temprana de defectos. El PSP
se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando
trabaja de forma individual.

TSP (Team Software Process)


Se utiliza para el desarrollo de proyectos de alto nivel con procedimientos para la mejora
continua del proceso de desarrollo, mejorar la calidad del software producido, mejorar la
estimación del tiempo de desarrollo, disminución de defectos en integración del equipo de
desarrollo.

DESARROLLO DE SOFTWARE

Las claves para el éxito de un proyecto de desarrollo de software son:

Independencia tecnológica: La utilización de tecnologías estándares y herramientas libres


garantiza la independencia de plataformas y asegura la posibilidad de mantenimiento futuro
de las aplicaciones.
Metodologías de desarrollo ágiles: Las metodologías de desarrollo basadas en una
fuerte interacción con el cliente y usuarios, permiten obtener productos adecuados a las
necesidades reales, ahorrando esfuerzo y aumentando la satisfacción del usuario final.

Uso de la tecnología adecuada: No existe un paradigma de diseño ni un lenguaje de


programación que se ajuste a todas las necesidades, por lo cual debe escogerse en cada caso
la tecnología que mejor satisfaga los requerimientos. Para esto, obviamente, es necesario un
conocimiento amplio de las ciencias de la computación.

Utilización de código libre: Cuando es posible, la utilización de programas libres


existentes (su modificación, integración o corrección), permite obtener productos de
excelente calidad, en menor tiempo y, por consiguiente, con menores costos.

Utilización de licencias libres: El producto terminado debe ser entregado al cliente


con toda la documentación y el código fuente. De esta manera no se impone ninguna traba
a la futura extensión del mismo, asegurando un trato justo, claro y transparente.

Algunas herramientas utilizadas

Manejadores de bases de datos


MySQL

MySQL, surgió como un manejador de pequeñas bases de datos, rápido y ágil. Con el paso
del tiempo y la reciente incorporación del código de la reconocida base de datos SapDB, se
ha sumado al mercado de las bases de datos profesionales.

Una de sus principales ventajas es que es soportada por la mayoría de los proveedores de
alojamiento web (webhosting), por lo cual se encuentra instalada en casi todos los
servidores web de Internet.

PostgreSQL

PostgreSQL es uno de los "decanos" de las bases de datos. Su desarrollo se inició en 1986 y
desde entonces ha incorporado características avanzadas, inclusive antes que costosos
manejadores privativos líderes del mercado.

Entre sus casos de éxito se encuentran bases de datos de tamaños superiores a los 50Gb, lo
cual demuestra su confiabilidad y eficiencia.

Lenguajes y herramientas de desarrollo

Ruby on Rails

Rails es un framework para el desarrollo de aplicaciones web basado en el lenguaje Ruby,


que reduce notablemente el tiempo de desarrollo, permitiendo lograr aplicaciones robustas
y de fácil mantenimiento y extensión.

Esta herramienta se presenta como una verdadera revolución en el desarrollo de


aplicaciones web, habiendo obtenido su creador el premio "OpenSource 2005", otorgado
por Google y O'Reilly, y gozando de las mejores críticas a nivel mundial.

PHP

PHP es el lenguaje más utilizado en su actualidad para el desarrollo de aplicaciones web.


Entre sus principales ventajas, se encuentran el soporte por parte de casi todos los
proveedores de alojamiento web y la gran cantidad de código desarrollado. PHP es,
actualmente, la mejor opción para desarrollar sistemas o sitios de pequeña envergadura.

Existen numerosas herramientas libres desarrolladas en PHP, como Joomla, un potente


sistema de gestión de contenidos (CMS) muy flexible y facilmente extensible, que puede
adaptarse para cubrir la mayoría de las necesidades en sistemas de publicación de
contenidos.

PHP es una buena herramienta que debe ser utilizada con cuidado: es indispensable realizar
un buen diseño (preferentemente, orientado a objetos) y separar la lógica del sistema de la
interfaz y el acceso a la base de datos (algo que, desafortunadamente, no muchos
programadores hacen en la actualidad).

Perl

Perl es un potente lenguaje de scripting, apto no solo para el desarrollo de aplicaciones


web, sino también para herramientas de administración de sistemas, herramientas de
conversión de formatos, software de acceso a redes, etc.

Con una larga trayectoria, y una extensa cantidad de módulos y aplicaciones desarrolladas,
es una elección ideal para aquellos programas que deben interactuar a un nivel medio/bajo
con sistemas Unix o funciones de red.

Otras herramientas

Apache webserver

El servidor web Apache, utilizado en más del 60% de los servidores de Internet, es la mejor
elección para alojar un sitio o sistema web. Con soporte de todas las tecnologías estándares
existentes (desde PHP hasta Java Servlets), se ejecuta en las plataformas de software más
difundidas.

Apache es apto aún en sistemas con alta demanda de servicio.

LENGUAJES DE PROGRAMACIÓN

Los lenguajes de programación son herramientas que nos permiten crear programas y software. Entre ellos
tenemos Delphi, Visual Basic, Pascal, Java, etc..

Una computadora funciona bajo control de un programa el cual debe estar almacenado en la unidad de
memoria; tales como el disco duro.

Los lenguajes de programación de una computadora en particular se conoce como código de máquinas o
lenguaje de máquinas.

Estos lenguajes codificados en una computadora específica no podrán ser ejecutados en otra computadora
diferente.

Para que estos programas funcionen para diferentes computadoras hay que realizar una versión para cada
una de ellas, lo que implica el aumento del costo de desarrollo.

Por otra parte, los lenguajes de programación en código de máquina son verdaderamente difíciles de
entender para una persona, ya que están compuestos de códigos numéricos sin sentido nemotécnico.

Los lenguajes de programación facilitan la tarea de programación, ya que disponen de formas adecuadas que
permiten ser leidas y escritas por personas, a su vez resultan independientes del modelo de computador a
utilizar.

Los lenguajes de programación representan en forma simbólica y en manera de un texto los códigos que
podrán ser leidos por una persona.
Los lenguajes de programación son independientes de las computadoras a utilizar.

Existen estrategias que permiten ejecutar en una computadora un programa realizado en un lenguaje de
programación simbólico. Los procesadores del lenguaje son los programas que permiten el tratamiento de la
información en forma de texto, representada en los lenguajes de programación simbólicos.

Hay lenguajes de programación que utilizan compilador.

La ejecución de un programa con compilador requiere de dos etapas:

1) Traducir el programa simbólico a código máquina


2) Ejecución y procesamiento de los datos.

Otros lenguajes de programación utilizan un programa intérprete o traductor, el cual analiza directamente la
descripción simbólica del programa fuente y realiza las instrucciones dadas.

El intérprete en los lenguajes de programación simula una máquina virtual, donde el lenguaje de máquina es
similar al lenguaje fuente.

La ventaja del proceso interprete es que no necesita de dos fases para ejecutar el programa, sin embargo su
inconveniente es que la velocidad de ejecución es más lenta ya que debe analizar e interpretar las
instrucciones contenidas en el programa fuente

8 lenguajes de programación que deberías aprender

Lo normal sería pensar que este gráfico es un indicador de las habilidades


necesarias en un futuro por un desarrollador web, pero la realidad es bien
distinta aquí en España, sólo habría que darse una vuelta por algún portal de
empleo y ver las habilidades que requieren las empresas...

Por eso vamos a hacer un pequeño análisis de los 8 lenguajes de programación


con más demanda en el mercado español, este análisis consta de 3 apartados:
¿Qué es?, ¿Por qué deberías aprenderlo?, Oferta de trabajo

1.PHP

¿Qué es?
PHP usa una mezcla entre interpretación y compilación para intentar ofrecer a los programadores la mejor mezcla entre
rendimiento y flexibilidad.

PHP compila para tu codigo una serie de instrucciones (llamadas opcodes) siempre que estas son accedidas. Estas
instrucciones son entonces ejecutadas una por una hasta que el script termina. Esto es diferente a la manera convencional
de compilacion de lenguajes como C++ donde el código es compilado a código ejecutable que es despues ejecutado. Php es
recompilado cada vez que se solicita un script.

Una ventaja importante de interpretar el código es que toda la memoria usada por tu código es manejada por PHP, y el
lenguaje automáticamente vacía esta memoria cuando el script finaliza. Esto significa que tu no tienes que preocuparte de
las conexiones a la base de datos, porque PHP lo hará por ti. leer más

¿Por qué deberías aprenderlo?


Es uno de los lenguajes de progrmación más populares, la gran fluidez y rapidez de sus scripts y su prometedor futuro,
desarrollar aplicaciones Webs utilizando lenguajes como C o COBOL son cosas del pasado.

2.C#

¿Qué es?
C# es un lenguaje de propósito general orientado a objetos creado por Microsoft para su plataforma .NET.
Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la plataforma .NET el cual es similar al de Java aunque
incluye mejoras derivadas de otros lenguajes. C# fue diseñado para combinar el control a bajo nivel de lenguajes como C y
la velocidad de programación de lenguajes como Visual Basic.

¿Por qué deberías aprenderlo?


Es una parte esencial de la plataforma .Net, C# combina los mejores elementos de múltiples lenguajes de amplia difusión
como C++, Java, Visual Basic o Delphi. De hecho, su creador Anders Heljsberg fue también el creador de muchos otros
lenguajes y entornos como Turbo Pascal, Delphi o Visual J++. La idea principal detrás del lenguaje es combinar la potencia
de lenguajes como C++ con la sencillez de lenguajes como Visual Basic, y que además la migración a este lenguaje por los
porgramadores de C/C++/Java sea lo más inmediata posible.

3.AJAX

¿Qué es?
AJAX no es un lenguaje exactamente su nombre viene dado por el acrónimo de Asynchronous JavaScript And XML y es
posiblemente la mayor novedad en cuanto a programación web en estos últimos años.

El corazón de Ajax es el objeto XMLHttpRequest que nos permite realizar una conexión al servidor y al enviarle una petición
y recibir la respuesta que procesaremos en nuestro código Javascript, estamos hablando del verdadero motor de Ajax, por
ejemplo gracias a este objeto podemos desde una página HTML leer datos de una web o enviar datos de un formulario sin
necesidad de recargar la página.

¿Por qué deberías aprenderlo?


La demanda de AJAX no sólo es amplía sino que de calidad debido a la dificultad de aprendizaje que conlleva, si la
herramienta de Microsoft, Atlas, destinada a la realización de aplicaciones AJAX tiene éxito puede suponee un aumento en la
demanda de esta tecnología.

4. JavaScript

¿Qué es?
Se trata de un lenguaje de programación del lado del cliente, porque es el navegador el que soporta la carga de
procesamiento. Gracias a su compatibilidad con la mayoría de los navegadores modernos, es el lenguaje de programación
del lado del cliente más utilizado.

¿Por qué deberías aprenderlo?


La razón de mayor peso es que es utilizado por millones de páginas webs para validar formularios, crear cookies, detectar
navegadores y mejorar el diseño, su fácil aprendizaje lo hace un lenguaje muy demandado.

5. Perl

¿Qué es?
Perl es la alternativa más popular a PHP, seguramente porque es el lenguaje más antiguo también dentro de las
alternativas. En internet nos encontramos numerosos recursos que utilizan Perl, muchos de las aplicaciones "open source"
requieren tener Perl instalado correctamente. Perl tiene una ventaja y es que es muy flexible, y también tiene un gran
cantidad de modulos ya escritos.

Bien escritos los scripts en Perl se asemejan bastante a PHP. La principal causa de la sucía apariencia de Perl es por la
afición de sus desarrolladores a la escritura en "una línea" empaquetanto numerosas funcionalidades en una sola línea de
código.

¿Por qué deberías aprenderlo?


La potencía de Perl a la hora de procesar grandes cantidades de datos lo hace realmente popular a la hora de desarrollar
aplicaciones del lado del servidor, aprender Perl o Php es básico a la hora de desarrollar aplicaciones Web.

6.C

¿Qué es?
Es un lenguaje de "medio nivel" pero con numerosas características de bajo nivel. Dispone de las estructuras típicas de los
lenguajes de alto nivel pero, a su vez, dispone de construcciones del lenguaje que permiten un control a muy bajo nivel.
¿Por qué deberías aprenderlo?
Aprender C es básico mientras aprendes C estas aprendiendo conceptos básicos de lenguajes cómo Java o C#, además no
sólo es mas sencillo que estos últimos sino que comporten gran parte de su sintaxis.

7.Ruby y Ruby on Rails

¿Qué es?
Ruby on Rails, también conocido como RoR o Rails es un framework de aplicaciones web de código abierto escrito en el
lenguaje de programación Ruby. Ruby apareció en el año 1995 y creo que su principal problema había sido
la falta de documentación en otro idioma que no sea japonés. Eso se ha ido solucionando y crece la popularidad del
lenguaje. Su aplicación insignia, por decirlo de algún modo parece ser RoR. Su mecanismo de gem se me parece
al CPAN de Perl y al Pear de PHP.

¿Por qué deberías aprenderlo?


Simple y funcional, el uso de Active Record de forma eficiente simplifica y agiliza el desarrollo de forma notable. Al
minimizar el trabajo con la base de datos (escribiendo triggers y procedimientos almacenados) y emplear un único lenguaje
para todo el desarrollo, se consigue acortar los tiempos de desarrollo (time2market).

8.ASP

¿Qué es?
Active Server Pages (ASP) y ASP.NET es un intendo de Microsoft para introducirse en el mercado del desarrollo Web, y viene
a ser como su estandar para su servidor Web, ISS. Asp ha sido atacado por la comunidad open source desde que este
apareció, y dan numerosas razones para ello:

El propietario, una única plataforma, la lentitud... Me gustaría decir "Si, si, y si", pero no me debo dejar llevar. La realidad
es que ASP ha sido implementado en otras plataformas y que cuando esta funcionando bajo su servidor predeterminado IIS
es relativamente rápido.

¿Por qué deberías aprenderlo?


Simplemente porqué en algunas ocasiones no tienes otra opción debido a la popularidad que ha alcanzado.