Ciclo de vida del software.

Ingeniería del Software [Bases de Datos]

El desarrollo de software va unido a un ciclo de vida compuesto por una
serie de etapas que comprenden todas las actividades, desde el momento
en que surge la idea de crear un nuevo producto software, hasta aquel en
que el producto deja definitivamente de ser utilizado por el último de sus
usuarios.

Etapas en el ciclo.

Veamos, a grandes rasgos, una pequeña descripción de etapas con que

podemos contar a lo largo del ciclo de vida del software; una vez
delimitadas en cierta manera las etapas, habrá que ver la forma en que
estas se afrontan (existen diversos modelos de ciclo de vida, y la
elección de un cierto modelo para un determinado tipo de proyecto puede
ser de vital importancia; el orden de las etapas es un factor importante,
p.ej. tener una etapa de validación al final del proyecto, tal como sugiere
el modelo en cascada o lineal, puede implicar serios problemas sobre la
gestión de determinados proyectos; hay que tener en cuenta que retomar
etapas previas es costoso, y cuanto más tarde se haga más costoso
resultará, por tanto el hecho de contar con una etapa de validación tardía
tiene su riesgo y, por su situación en el ciclo, un posible tiempo de
reacción mínimo en caso de tener que retornar a fases previas):
Expresión de necesidades
Esta etapa tiene como objetivo la consecución de un primer
documento en que queden reflejados los requerimientos y
funcionalidades que ofrecerá al usuario del sistema a desarrollar
(qué, y no cómo, se va a desarrollar).
Dado que normalmente se trata de necesidades del cliente para el
que se creará la aplicación, el documento resultante suele tener
como origen una serie de entrevistas cliente-proveedor situadas en
el contexto de una relación comercial, siendo que debe ser
comprendido por ambas partes (puede incluso tomarse como base
para el propio acuerdo comercial).

Especificaciones
Ahora se trata de formalizar los requerimientos; el documento
obtenido en la etapa anterior se tomará como punto de partida para
esta fase. Su contenido es aún insuficiente y lleno de imprecisiones
que será necesario completar y depurar.
Por medio de esta etapa se obtendrá un nuevo documento que
definirá con más precisión el sistema requerido por el cliente (el
 empleo de los casos de uso, use cases, de Jacobson es una muy
buena elección para llevar a cabo la especificación del sistema).

Lo más normal será que no resulte posible obtener una buena

especificación del sistema a la primera; serán necesarias sucesivas
versiones del documento en que irán quedando reflejada la evolución
de las necesidades del cliente (por una parte no siempre sabe en los
primeros contactos todo lo que quiere realmente, y por otra parte
pueden surgir cambios externos que supongan requerimientos
nuevos o modificaciones de los ya contemplados).

Análisis
Es necesario determinar que elementos intervienen en el sistema a
desarrollar, así como su estructura, relaciones, evolución en el
tiempo, detalle de sus funcionalidades, ... que van a dar una
descripción clara de qué sistema vamos a construir, qué
funcionalidades va a aportar y qué comportamiento va a tener. Para
ello se enfocará el sistema desde tres puntos de vista relacionados
pero diferentes:
 Funcional.

 Estático.

 Dinámico.

Diseño
Tras la etapa anterior ya se tiene claro que debe hacer el sistema,
ahora tenemos que determinar como va a hacerlo (¿cómo debe ser
construido el sistema?; aquí se definirán en detalle entidades y
relaciones de las bases de datos, se pasará de casos de uso
esenciales a su definición como casos expandidos reales, se
seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases
de Datos a utilizar en su caso, librerías, configuraciones hardware,
redes, etc.).
Observación:
Aunque todo debe ser tratado a su tiempo, y sería muy deseable que
las decisiones correspondientes en esta etapa fueran tomadas
precisamente en esta etapa, muchas veces nos vamos a encontrar
con unas decisiones previamente impuestas sobre lenguaje,
plataforma, etc. Unas veces se dirán justificadas en simple política
de empresa y por mantener "compatibilidad" en lo que respecta a los
 demás proyectos de la propia empresa, y en otras ocasiones por
rumores de que tal o cual herramienta mejoraría la velocidad de
desarrollo u otro aspecto de interés (en parte de los casos no serán
rumores con fundamento o estudios previos realizados al efecto, sino
más bien debidos a la propia publicidad como consejera).

Implementación
Llegado este punto se empieza a codificar algoritmos y estructuras
de datos, definidos en las etapas anteriores, en el correspondiente
lenguaje de programación y/o para un determinado sistema gestor
de bases de datos.
Observación:
Lamentablemente en la actualidad, año 2.000, quedan bastantes
empresas en las que, tras una reunión comercial en que tan solo se
ha conseguido recabar una breve lista de requerimientos, a pesar de
tener que enfrentarse a proyectos grandes-medios, se pasa
directamente a la etapa de implementación; son proyectos guiados
por el riesgo que supone adoptar un modelo de ciclo de vida de
codificar-corregir (code and fix) donde se eliminan las fases de
especificaciones, análisis y diseño con la consiguiente pérdida de
control sobre la gestión del proyecto.

Pruebas
El objetivo de estas pruebas es garantizar que el sistema ha sido
desarrollado correctamente, sin errores de diseño y/o programación.
Es conveniente que sean planteadas al menos tanto a nivel de cada
módulo (aislado del resto), como de integración del sistema (según
sea la naturaleza del proyecto en cuestión se podrán tener en cuenta
pruebas adicionales, p.ej. de rendimiento).

Validación
Esta etapa tiene como objetivo la verificación de que el sistema
desarrollado cumple con los requisitos expresados inicialmente por el
cliente y que han dado lugar al presente proyecto (para esta fase
también es interesante contar con los use cases, generados a través
de las correspondientes fases previas, que servirán de guía para la
verificación de que el sistema cumple con lo descrito por estos).
Mantenimiento y evolución
Finalmente la aplicación resultante se encuentra ya en fase de
producción (en funcionamiento para el cliente, cumpliendo ya los
objetivos para los que ha sido creada). A partir de este momento se
entra en la etapa de mantenimiento, que supondrá ya pequeñas
operaciones tanto de corrección como de mejora de la aplicación
(p.ej. mejora del rendimiento), así como otras de mayor
importancia, fruto de la propia evolución (p.ej. nuevas opciones para
el usuario debidas a nuevas operaciones contempladas para el
producto).
La mayoría de las veces en que se desarrolla una nueva aplicación, se piensa
sólamente en un ciclo de vida para su creación, olvidando la posibilidad de
que esta deba sufrir modificaciones futuras (que tendrán que producirse con
casi completa seguridad para la mayor parte de los casos).
 Etapas del ciclo de vida de una
aplicación:
 CICLO DE VIDA ESTRUCTURADO

ESTUDIO
 La etapa de Estudio de viabilidad o estudio inicial.

 Su principal objetivo es el estudio e identificación de las

deficiencias actuales en el ambiente del usuario (a través de relevamientos, en cuentas), establecer
nuevos objetivos, y proponer "escenarios" viables

ANALISIS
 Conforme a las alternativas generadas por el estudio, en esta etapa se "Modelan" las
necesidades del usuario a través de DIAGRAMAS especiales (DFD, ER),dando como resultado las
Especificaciones estructuradas.

DISEÑO
 En esta etapa se "diseña" el sistema, determinando los módulos componentes del Sistema, de
acuerdo a una jerarquía apropiada, a los procesadores (hardware) y a la función

IMPLANTACION (DESARROLLO)
 Esta actividad incluye la codificación e integración de los módulos con técnicas de
programación estructurada

GENERACIÓN DEL TEST DE ACEPTACIÓN

 Consiste en preparar un conjunto de casos para efectuar las pruebas del sistema
 GARANTIA DE CALIDAD
 En esta etapa se efectúa el TEST final de aceptación del Sistema

DESCRIPCION DE PROCEDIMIENTO
 Consiste en la elaboración de la "descripción formal" del nuevo sistema: Manuales del
Usuario, Manuales del Sistema, Manuales de procedimiento

CONVERSIÓN DE LA BASE DE DATOS

 Esta actividad sólo se realiza cuando existen sistemas funcionando

INSTALACION
 Es la actividad FINAL.

 Existen varias estrategias de INSTALACION: Gradual, distribuida, completa

 Un aspecto importante de esta actividad es la CAPACITACION

EL CICLO DE VIDA

Todo proyecto de ingeniería tiene unos fines ligados a la obtención de un producto, proceso o servicio
que es necesario generar a través de diversas actividades. Algunas de estas actividades pueden
agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para
continuar hacia el producto final y facilitar la gestión del proyecto. Al conjunto de las fases
empleadas se le denomina “ciclo de vida”.

Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos
intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o
proceso a generar y de las tecnologías empleadas.

La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el
tamaño, con lo que rápidamente se haría inabordable si no fuera por la vieja táctica de “divide y
vencerás”. De esta forma la división de los proyectos en fases sucesivas es un primer paso para la
reducción de su complejidad, tratándose de escoger las partes de manera que sus relaciones entre sí
sean lo más simples posibles.

La definición de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar
recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye
subcontratación de partes a otras organizaciones, el control del trabajo subcontratado se facilita en
la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad
también se ve facilitado si la separación entre fases se hace corresponder con puntos en los que ésta
deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos).

De la misma forma, la práctica acumulada en el diseño de modelos de ciclo de vida para situaciones
muy diversas permite que nos beneficiemos de la experiencia adquirida utilizando el enfoque que
mejor de adapte a nuestros requerimientos.

ELEMENTOS DEL CICLO DE VIDA

Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas
planificables. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de
realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda
ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución
aportaciones de los resultados intermedios que se van produciendo (realimentación).

Para un adecuado control de la progresión de las fases de un proyecto se hace necesario especificar
con suficiente precisión los resultados evaluables, o sea, productos intermedios que deben resultar de
las tareas incluidas en cada fase. Normalmente estos productos marcan los hitos entre fases.

A continuación presentamos los distintos elementos que integran un ciclo de vida:

 Fases. Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo

del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir
un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas
impone requisitos temporales correspondientes a la asignación de recursos (humanos,
financieros o materiales).

Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la definición
de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada
fase de un proyecto puede considerarse un “micro-proyecto” en sí mismo, compuesto por un
conjunto de micro-fases.

Otro motivo para descomponer una fase en subfases menores

puede ser el interés de separar partes temporales del proyecto que
se subcontraten a otras organizaciones, requiriendo distintos
procesos de gestión.

Cada fase viene definida por un conjunto de elementos observables externamente, como son
las actividades con las que se relaciona, los datos de entrada (resultados de la fase
anterior, documentos o productos requeridos para la fase, experiencias de proyectos
anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia
acumulada, pruebas o resultados efectuados) y la estructura interna de la fase.
 Esquema general de operación de una fase

 Entregables ("deliverables"). Son los productos intermedios que generan las fases. Pueden
ser materiales (componentes, equipos) o inmateriales (documentos, software). Los
entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su
adecuación o no a los requisitos funcionales y de condiciones de realización previamente
establecidos. Cada una de estas evaluaciones puede servir, además, para la toma de
decisiones a lo largo del desarrollo del proyecto.

TIPOS DE MODELO DE CICLO DE VIDA

Las principales diferencias entre distintos modelos de ciclo de vida están en:

o El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un

proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o
su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su
desarrollo, fabricación, y modificaciones posteriores hasta su retirada del mercado.

o Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender
del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse
para proyectar un avión que un puente), o de la organización (interés de reflejar en la división
en fases aspectos de la división interna o externa del trabajo).

o La estructura de la sucesión de las fases que puede ser lineal, con prototipado, o en espiral.
Veámoslo con más detalle:

Ciclo de vida lineal

Es el más utilizado, siempre que es posible, precisamente por ser el más sencillo. Consiste
en descomponer la actividad global del proyecto en fases que se suceden de manera lineal,
es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que
la siguiente. Con un ciclo lineal es fácil dividir las tareas entre equipos sucesivos, y prever
los tiempos (sumando los de cada fase).

Requiere que la actividad del proyecto pueda descomponerse de manera que una fase no
necesite resultados de las siguientes (realimentación), aunque pueden admitirse ciertos
supuestos de realimentación correctiva. Desde el punto de vista de la gestión (para
decisiones de planificación), requiere también que se sepa bien de antemano lo que va a
ocurrir en cada fase antes de empezarla.
 Ejemplo de ciclo lineal para un proyecto de construcción

Ciclo de vida con prototipado

A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se

prevé la utilización de tecnologías nuevas o poco probadas, que las incertidumbres sobre los
resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las
tecnologías, impiden iniciar un proyecto lineal con especificaciones cerradas.

Si no se conoce exactamente cómo desarrollar un determinado producto o cuáles son las

especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para
hacer un prototipo, o sea, un producto parcial (no hace falta que contenga funciones que se
consideren triviales o suficientemente probadas) y provisional (no se va a fabricar realmente
para clientes, por lo que tiene menos restricciones de coste y/o prestaciones). Este tipo de
procedimiento es muy utilizado en desarrollo avanzado.
La experiencia del desarrollo del prototipo y su
evaluación deben permitir la definición de las
especificaciones más completas y seguras
para el producto definitivo.

A diferencia del modelo lineal, puede decirse

que el ciclo de vida con prototipado repite las
fases de definición, diseño y construcción dos
veces: para el prototipo y para el producto real.

Ciclo de vida en espiral

El ciclo de vida en espiral puede considerarse como una generalización del anterior para los
casos en que no basta con una sola evaluación de un prototipo para asegurar la
desaparición de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo
puede así considerarse como una sucesión de prototipos que progresan hasta llegar a
alcanzar el estado deseado. En cada ciclo (espirales) las especificaciones del producto se
van resolviendo paulatinamente.
 A menudo la fuente de incertidumbres es el propio cliente, que aunque sepa en términos
generales lo que quiere, no es capaz de definirlo en todos sus aspectos sin ver como unos
influyen en otros. En estos casos la evaluación de los resultados por el cliente no puede
esperar a la entrega final y puede ser necesaria repetidas veces.
El esquema del ciclo de vida
para estos casos puede
representarse por un bucle
en espiral, donde los
cuadrantes son,
habitualmente, fases de
especificación, diseño,
realización y evaluación (o
conceptos y términos
análogos).

En cada vuelta el producto gana en

“madurez” (aproximación al final
deseado) hasta que en una vuelta la
evaluación lo apruebe y el bucle pueda
abandonarse.

OBJETIVOS DE CADA FASE

Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de
objetivos y tareas que lo caracterizan.

Fase de definición (¿qué hacer?)

o Estudio de viabilidad.

o Conocer los requisitos que debe satisfacer el sistema (funciones y

limitaciones de contexto).

o Asegurar que los requisitos son alcanzables.

o Formalizar el acuerdo con los usuarios.

o Realizar una planificación detallada.

Fase de diseño (¿cómo hacerlo? Soluciones en coste, tiempo y calidad)
o Identificar soluciones tecnológicas para cada una de las funciones del
sistema.

o Asignar recursos materiales para cada una de las funciones.

o Proponer (identificar y seleccionar) subcontratas.

o Establecer métodos de validación del diseño.

o Ajustar las especificaciones del producto.

Fase de construcción
o Generar el producto o servicio pretendido con el proyecto.
 o Integrar los elementos subcontratados o adquiridos externamente.

o Validar que el producto obtenido satisface los requisitos de diseño

previamente definidos y realizar, si es necesario, los ajustes necesarios en
dicho diseño para corregir posibles lagunas, errores o inconsistencias.
Fase de mantenimiento y operación
o Operación: asegurar que el uso del proyecto es el pretendido.

o Mantenimiento (nos referimos a un mantenimiento no habitual, es decir,

aquel que no se limita a reparar averías o desgastes habituales -este es el
caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averías o
de desgaste):

LOS PROYECTOS DE I+D

En el caso de la investigación básica el resultado esperado son conocimientos científicos. No existe

ninguna fase de construcción y sí fases que recojan las tareas de experimentación.

En la investigación aplicada el resultado esperado suele ser alguna tecnología aplicable para
procesos o para productos. Dependiendo del grado de cercanía a la aplicación que llegue a
alcanzarse el modelo puede ser básicamente como el anterior o incluir una fase de aplicación piloto.

En el desarrollo de productos o procesos nuevos o significativamente modificados sí aparece ya

una fase de construcción, aunque normalmente se tratará de la realización de un prototipo.
Normalmente el cliente no será el usuario final, sino los departamentos de ingeniería de producción de
la propia empresa o de otra que contrata el desarrollo.

La I+D es costosa por depender de personal muy cualificado, por realizarse de modo generalmente
artesanal y por requerir bucles de realimentación que multiplican, para hacer frente a incidencias, la
duración del proyecto.

CICLO DE VIDA EN INTERNET

Con Internet de por medio, todo se transforma en algo más rápido. Internet ha conseguido en 5 o 6
años lo que televisión o teléfono han tardado décadas.
Tema: El ciclo de la vida en Internet
Autor: Pilar Navas
El conocido ciclo de vida, basado en considerar que
cualquier producto tiene una duración limitada y que
pasa por una serie de fases (nacimiento,
crecimiento y maduración) se ha acortado
notablemente.
http://www.commercenetcatalunya.org/boletin56/not4.htm

Fases para la Resolución de Problemas

Son los pasos a seguir para la resolución de problemas con ayuda de la computadora.

Análisis del Problema

Esta fase requiere una clara definición donde se contemple exactamente lo que debe hacer el programa y el resultado o solución
deseada.

Dado que se busca una solución se precisan especificaciones de entrada y salida.

Para poder definir bien un problema es conveniente responder a las siguientes preguntas:

 ¿Qué entradas se requieren? (cantidad y tipo)

 ¿Cuál es la salida deseada? (cantidad y tipo)

 ¿Qué método produce la salida deseada?

Diseño del Algoritmo

En la fase de análisis en el proceso de programación se determina que hace el programa. En la fase de diseño se determina como hac
el programa la tarea solicitada.

Los métodos utilizados para el proceso del diseño se basan en el conocido divide y vencerás. Es decir la resolución de un problema
complejo se realiza dividiendo el problema en subproblemas y a continuación dividir estos subproblemas en otros de nivel mas bajo
hasta que sea implementada una solución en la computadora. Este método se conoce técnicamente como diseño descendente (top-
down) o modular.

Cada programa bien diseñado consta de un programa principal (el módulo de nivel más alto) que llama a subprogramas (módulos) d
nivel mas bajo, que a su vez pueden llamar a otros subprogramas.

Los módulos pueden ser planeados, codificados, comprobados y depurados independientemente y a continuación combinarlos entre
Este proceso implica la ejecución de estos pasos hasta que el programa se ha terminado:

 Programar un módulo

 Comprobar el módulo

 Si es necesario, depurar el módulo

 Combinar el módulo, con el resto de los otros módulos

El diseño del algoritmo es independiente del lenguaje de programación en el que se vaya a codificar posteriormente.

Implementación del Algoritmo

Para implementar un algoritmo en la computadora, se debe ejecutar los siguientes pasos:

  Codificación

 Compilación y ejecución

 Verificación

 Depuración

 Documentación

Codificación: Es la escritura en un lenguaje de programación de la representación de un algoritmo. Dado que el diseño del algoritmo
es independiente del lenguaje de programación utilizado en su implementación, el código puede ser escrito con igual facilidad en un
lenguaje o en otro.

Compilación y ejecución: Una vez que el algoritmo se ha convertido en un programa fuente, es preciso introducirlo en memoria
mediante el teclado y almacenarlo posteriormente en un disco. Esta operación se realiza con un editor de texto, posteriormente el
programa fuente se convierte en un archivo de programa que se guarda en un disco.

El programa fuente debe ser traducido a lenguaje máquina. Este proceso se realiza con el compilador y el sistema operativo que se
encarga prácticamente de la compilación. Si al compilar el programa fuente se presentan errores (errores de compilación), es necesa
volver a editar el programa, corregir los errores y compilar de nuevo. Esto se repite hasta que ya no se presenten mas errores,
obteniéndose el programa objeto, el cual todavía no es ejecutable directamente. Al ya no existir errores en el programa fuente se deb
instruir al sistema operativo para que efectúe la fase de montaje o enlace, del programa fuente con las librerías del programa del
compilador. Este proceso de montaje produce un programa ejecutable.

Cuando se ha creado un programa ejecutable este se puede ya ejecutar desde el sistema operativo con solo teclear su nombre.

Suponiendo que no existen errores durante la ejecución (errores en tiempo de ejecución), se obtendrá la salida de resultados correcto
del programa.

Verificación y depuración: Es el proceso de ejecución del programa con una amplia variedad de datos de entrada, llamados datos de
test o prueba como son: valores normales de entrada, valores extemos de entrada que comprueben los límites del programa y valore
de entrada que comprueben aspectos especiales del programa. Estos determinarán si el programa contiene errores o no.

Al ejecutar un programa se pueden producir tres tipos de errores:

 Errores de Compilación: Se producen normalmente por un uso incorrecto de las reglas del lenguaje de
programación, suelen ser errores de sintaxis.

 Errores de Ejecución: Se producen por instrucciones que la computadora puede comprender pero no ejecutar. En
estos casos se detiene la ejecución del programa y se imprime un mensaje de error. Ejemplo de esto puede ser una
división por cero.

 Errores Lógicos: Se producen en la lógica del programa y la fuente del error suele ser el diseño del algoritmo, son
mas difíciles de detectar puesto que el programa puede funcionar y no producir errores de compilación ni de
ejecución pero regresará resultados incorrectos. En este caso se debe regresar a la fase de diseño, modificar el
algoritmo, cambiar el programa fuente y compilar y depurar una vez mas.
 

Documentación: La importancia de la documentación debe ser destacada por su influencia en la etapa final, ya que programas
pobremente documentados son difíciles de leer, mas difíciles de depurar y casi imposibles de mantener y modificar.

Puede ser interna y externa. La documentación interna es la contenida en líneas de comentarios. La documentación externa incluye
análisis, diagramas de flujo y/o pseudocódigos, manuales de usuarios con instrucciones para ejecutar el programa y para interpretar
resultados.

La documentación es vital cuando se desea corregir posibles errores futuros o bien cambiar el programa. Estos cambios se denomina
mantenimiento del programa.

Además es de buena costumbre para todo buen programador, dejar comentado su código, esto es para que el futuro programador pue
darle mantenimiento fácilmente a el programa, o incluso, si es el mismo creador quien debe darle mantenimiento.

Herramientas de Programación

Las herramientas de programación más utilizadas comunmente para diseñar algoritmos son:

 Pseudocódigos

 Diagramas N-S

 Diagramas de flujo

Siendo el pseudocódigo el mas popular por su sencillez y su parecido al lenguaje humano.

cursos@educainformatica.com.ar

info@educainformatica.com.ar