Unidad 1. Desarrollo del software ................................................................................................

3
Introducción .............................................................................................................................. 3
Software basado en el tipo de tarea que realiza ...................................................................... 3
Software basado en el método de distribución ........................................................................ 4
Desarrollo de software .............................................................................................................. 5
Ciclos de vida del software ........................................................................................................ 5
Modelo en cascada................................................................................................................ 5
Modelo en cascada con retroalimentación........................................................................... 6
Modelos evolutivos ............................................................................................................... 6
Modelo iterativo incremental ........................................................................................... 6
Modelo en espiral ............................................................................................................. 7
Fases de desarrollo.................................................................................................................... 8
Análisis................................................................................................................................... 8
Requisitos .......................................................................................................................... 9
Herramientas de apoyo al desarrollo del software......................................................... 10
Clasificación de las herramientas CASE ........................................................................... 10
Clasificación de las técnicas para representar requisitos ............................................... 10
1. Diagrama de flujo de datos, DFD............................................................................. 10
2. Diagrama de flujo de control, DFC .......................................................................... 13
3. Diagrama de transición de estados, DTE ................................................................. 13
4. Diagrama entidad-relación, DER ............................................................................. 13
5. Diccionario de datos, DD ......................................................................................... 13
Diseño.................................................................................................................................. 13
Diseño estructurado ........................................................................................................ 14
Diseño a nivel de componentes .................................................................................. 14
Construcción secuencial .......................................................................................... 14
Construcción condicional ........................................................................................ 15
Construcción repetitiva ........................................................................................... 15
Notaciones gráficas para el diseño ............................................................................. 16
Diagrama de flujo .................................................................................................... 16
Diagrama de cajas (Diagrama Nassi-Shneiderman) ................................................ 16
Tablas de decisión ................................................................................................... 17
Pseudocódigo .......................................................................................................... 18
Diseño orientado a objetos ............................................................................................. 19
Codificación ......................................................................................................................... 19
Código fuente .................................................................................................................. 19
 Código objeto .................................................................................................................. 20
Código ejecutable ............................................................................................................ 20
Máquinas virtuales .......................................................................................................... 20
Frameworks ..................................................................................................................... 21
Entornos de ejecución ..................................................................................................... 21
Entornos de desarrollo .................................................................................................... 22
Pruebas................................................................................................................................ 22
Documentación ................................................................................................................... 24
Explotación .......................................................................................................................... 24
Mantenimiento ................................................................................................................... 25
Unidad 1. Desarrollo del software
El objetivo es aprender a reconocer los elementos y herramientas que intervienen en el
desarrollo de un programa informático, analizando sus características y las fases en las que
actúan hasta llegar a su puesta en funcionamiento.

Introducción
El ordenador se compone de dos partes:
 Hardware: es la parte física del ordenador. Los componentes que se pueden ver y
tocar.
 Software: es la parte lógica del ordenador. No se puede tocar. Está formada por el
conjunto de programas y aplicaciones que actúan sobre el hardware y facilitan la
realización de tareas.

Software basado en el tipo de tarea que realiza

Se distinguen tres tipos:

 Software de sistema: intermedia entre el usuario y el hardware, permitiendo que éste
funcione.
Ejemplos: SO, drivers, herramientas de diagnóstico, corrección, optimización, etc.
 Software de aplicación: programas que ayudan al usuario a hacer tareas específicas
que puedan ser automatizadas o asistidas.
Ejemplos: ofimática, CAD, contabilidad, educativas, etc.
 Software de programación o desarrollo: proporciona a los programadores
herramientas que facilitan la escritura de programas informáticos.
Entre ellos se encuentran los entornos de desarrollo integrados (IDE) que agrupan
herramientas que evitan que el programador tenga que introducir múltiples comandos
para compilar, interpretar, depurar, etc.
Suelen contar con una interfaz gráfica de usuario (GUI) avanzada.
Software basado en el método de distribución
Son los llamados programas enlatados, software desarrollado por compañías y vendido
principalmente por distribuidores:
 Shareware: el software se distribuye para que el usuario pueda evaluar gratuitamente
el producto durante un tiempo específico. La licencia para usar el producto de forma
completa se tendrá que pagar.
Ejemplos: WinRAR, PC File, Virus Scan, etc.
 Freeware: el software se distribuye gratuitamente. A veces se incluye el código fuente.
 Adware: suelen ser programas shareware que descargan publicidad automáticamente
cuando lo ejecutamos o instalamos. La publicidad se elimina al comprar la licencia.
 Software multimedia: presentan de forma integrada textos, gráficos, sonidos y
animaciones.
Ejemplos: enciclopedias educativas, etc.
 Software de uso específico: desarrollado para resolver un problema determinado.
Ejemplos: generador de calendarios, controlador de clientes y cuentas, etc.

*Mirar el trabajo de clase sobre tipos de software para ampliar.

Desarrollo de software
El desarrollo de software es todo proceso que ocurre desde que se tiene una idea hasta que el
programa está implementado y funcionando.
El proceso de desarrollo consta de una serie de pasos de obligado cumplimiento. Sólo así
garantizaremos que los programas son eficientes, fiables, seguros, y responden a las
necesidades de los usuarios.
Etapas en el desarrollo de software:

Según el orden y la forma en que se lleven a cabo las etapas anteriores hablaremos de
diferentes ciclos de vida del software.
La construcción de software es un proceso que puede llegar a ser muy complejo y exige gran
coordinación y disciplina por parte de quienes lo desarrollen.
Los errores en la planificación inicial pueden propagarse en escala al resto de etapas del
desarrollo.

Ciclos de vida del software

El ciclo de vida del software se compone de la serie de pasos a seguir para desarrollar un
programa.
Se han planteado distintos modelos de ciclos de vida.
Modelo en cascada
Requiere que se conozcan de antemano todos los requisitos del sistema. Sólo se puede aplicar
a pequeños desarrollos, ya que no se puede regresar a una etapa anterior (se presupone que
no habrá errores ni variaciones del software).
Características:
 Requiere conocimiento previo y absoluto de los requisitos del sistema.
 No hay retorno en las etapas: si hay algún error se tendrá que volver al principio.
 No permite modificaciones ni actualizaciones de software.
 Es un modelo utópico.

Para poder empezar una etapa en este modelo, habrá que finalizar la anterior. Después de
cada etapa se realiza una revisión para comprobar si se puede pasar a la etapa siguiente (1).

Si durante la etapa de mantenimiento, por ejemplo, el cliente quiere hacer una mejora, habrá
que modificar algo en el diseño, lo que
significa que habrá que volver a cambiar
la codificación y realizar las pruebas.
En conclusión, si se tiene que volver a
una de las etapas anteriores, habrá que
recorrer el resto de etapas de nuevo (2).
Modelo en cascada con retroalimentación
Es uno de los modelos más utilizados. Introduce realimentación entre etapas al modelo
anterior, de forma que podemos volver atrás para corregir, modificar o depurar. De todas
formas, si se prevén muchos cambios durante el desarrollo no es el modelo más idóneo.
Es el mejor modelo si el proyecto es rígido (pocos cambios) y los requisitos están claros.
Características:
 Es uno de los modelos más utilizados.
 Se puede retornar a etapas anteriores.
 Idóneo para proyectos más o menos rígidos y con requisitos claros.
 Los errores detectados una vez haya concluido el proyecto
pueden provocar que haya que empezar desde cero.

Por ejemplo, si la etapa de análisis (captura de requisitos) hubiera

finalizado, pasamos a la etapa de diseño. Si se detectan fallos, será
necesario retornar a la etapa anterior, realizar los cambios y
continuar con la etapa de diseño.
Esto es lo que se conoce como retroalimentación. También
podríamos dar marcha atrás varias veces, de una etapa a otra.
Modelos evolutivos
Son más modernos. Tienen en cuenta la naturaleza cambiante y
evolutiva del software. Hay dos variantes: modelo iterativo
incremental y modelo en espiral.
Modelo iterativo incremental
Está basado en el modelo en cascada con retroalimentación. Las fases se repiten y refinan para
propagar su mejora a las fases siguientes.
Características:
 En el mercado no se ponen productos completos, se ponen versiones.
 Permite una fácil evolución temporal.
 Se trata de varios ciclos en cascada que se repiten y refinan en cada incremento.
 Las sucesivas versiones del producto son cada vez más completas, hasta llegar al
producto final.

Se compone de varios ciclos cascada realimentados aplicados repetidamente. El software se

entrega en partes pequeñas utilizables llamadas incrementos. Cada incremento suele
construirse sobre el que ya ha sido entregado.
Por ejemplo, un procesador de textos. En el primer incremento se realizan funciones básicas
de gestión de archivos y producción de documentos; en el segundo incremento se desarrollan
funciones
avanzadas de
paginación, etc.
Seguiremos hasta
tener el producto
completo.
Modelo en espiral
Es una combinación del modelo iterativo incremental con el modelo en cascada. El software se
va construyendo repetidamente en forma de versiones cada vez mejores, la funcionalidad se
incrementa en cada versión. Es un modelo bastante complejo.
Características:
 Se divide en 6 zonas llamadas regiones de tareas:
Comunicación con el cliente, planificación, análisis de riesgos, representación de la
aplicación, codificación y explotación, y evaluación del cliente.
 Se adapta a la naturaleza evolutiva del software.
 Reduce los riesgos antes de que sean problemáticos.

Es un modelo de software evolutivo. Enlaza la naturaleza iterativa de la construcción de

prototipos conservando las propiedades del modelo en cascada, es decir, podremos modificar
todas las veces que sea necesario las etapas en una versión pero, en la siguiente versión, no
modificaremos la versión anterior: los cambios se harán sobre nuestra versión actual.
Todas las fases se realizan de forma
simultánea teniendo en cuenta el
trabajo de los otros departamentos
(análisis, diseño, etc.) hasta su
entrega al cliente. De esta forma se
reduce el tiempo total, ya que no hay
que realizar una fase detrás de otra.
Fases de desarrollo
Si ya hemos examinado el proyecto y escogido el modelo tendremos que seguir una serie de
etapas independientemente del modelo elegido.
Análisis
Es muy importante entender y comprender bien el problema para poder darle solución. El
éxito dependerá de ello.
En esta fase se analizan y especifican los requisitos o capacidades que el sistema debe tener
según las exigencias del cliente.
Es importante que los requisitos estén bien definidos, así que los desarrolladores deben tener
una buena comunicación con el cliente.
Para facilitar la comunicación se utilizan varias técnicas:
  Entrevistas: consiste en hablar con el cliente. Hay que tener conocimientos de
psicología.
 Desarrollo conjunto de aplicaciones (JAD): es un tipo de entrevista estructurada que
se hace a un grupo que contenga representantes de las partes interesadas (usuarios,
administradores, analistas de sistemas, etc.). Lo que se hace en ella está bien
reglamentado para mejorar la participación, agilidad, etc. de la misma.
 Planificación conjunta de requisitos (JRP): es un tipo de JAD; está dirigida a la alta
dirección, de manera que los requisitos resultantes serán de alto nivel o estratégicos.
 Brainstorming: consiste en reunir a un grupo de personas en un ambiente informal en
el que se proponen ideas sin parar. El objetivo es dar con ideas originales
aprovechando toda la creatividad del grupo. En principio ninguna idea será rechazada,
se almacenarán y se valorarán cuando termine la sesión.
 Prototipos: consiste en realizar una versión inicial del sistema. El objetivo es ver más
claro el problema y sus posibles soluciones. Dependiendo de la conclusión a la que se
llegue, se desecha el prototipo o se usa como base.
 Casos de uso: técnica definida en UML. Consiste en describir qué es lo que hará el
sistema representando sus requisitos funcionales, pero sin entrar en la forma en que
realiza las cosas.

Ejemplo: la descripción de una actividad que

realizará alguien o algo para llevar a cabo un
proceso. Las entidades que participan en un
diagrama de caso de uso reciben el nombre de
actores.

Requisitos
Dentro del análisis encontramos dos tipos de requisitos:
 Requisitos funcionales: describen cómo funciona
el sistema: la función que realiza, cómo reacciona ante determinadas entradas, cómo
se comporta ante determinadas situaciones, etc.
 Requisitos no funcionales: describen las características del sistema: fiabilidad,
mantenibilidad, sistema operativo, hardware, restricciones, limitaciones, etc.

Ejemplo de requisitos funcionales y no funcionales en una aplicación de gestión de contactos:

Herramientas de apoyo al desarrollo del software
Para llevar a cabo varias de las etapas del desarrollo contamos con herramientas informáticas
cuya función es automatizar las tareas y ganar fiabilidad y tiempo.
Así podremos centrarnos en los requerimientos del sistema y su análisis, las causas principales
de los fallos en el software.
Las herramientas CASE son un conjunto de aplicaciones que se utilizan en el desarrollo de
software para reducir costes y tiempo.
Estas herramientas permiten:
 Mejorar la planificación del proyecto.
 Darle agilidad al proceso.
 Reutilizar partes del software en otros proyectos.
 Adaptar las aplicaciones a estándares.
 Mejorar el mantenimiento de los programas.
 Visualizar las fases del desarrollo de forma gráfica.

Clasificación de las herramientas CASE

Normalmente se clasifican en función de las fases del ciclo de vida del software en las que
ofrecen ayuda:
 U-CASE: ayudan en la fase de planificación y análisis de requisitos.
 M-CASE: ayuda en análisis y diseño.
 L-CASE: ayuda en la programación, la detección de errores en el código, la depuración
y las pruebas, y la generación de la documentación del proyecto.

Ejemplos de herramientas CASE libres: ArgoUML, Use Case Maker, ObjectBuilder…

Clasificación de las técnicas para representar requisitos

Para representar los requisitos se utilizan diferentes técnicas:
1. Diagrama de flujo de datos, DFD.
2. Diagrama de flujo de control, DFC.
3. Diagramas de transición de estados, DTE.
4. Diagrama entidad-relación, DER.
5. Diccionario de datos, DD.

1. Diagrama de flujo de datos, DFD

Representa el flujo de datos entre los distintos procesos, entidades externas y almacenes
que forman el sistema.
  Los procesos identifican funciones dentro del sistema. Se representan mediante
burbujas.
 Las entidades externas representan componentes que no forman parte del sistema
(personas, departamentos, etc.) pero proporcionan datos al mismo o los reciben de él.
Se representan mediante rectángulos.
 Los almacenes representan el lugar donde se almacenan los datos procesados o desde
donde se recuperan para usarse en un proceso. Se representan mediante dos líneas
horizontales paralelas.
 El flujo de datos representa
el movimiento de datos en
el sistema. Se representa
mediante flechas.

Nota: al representar
estamos usando la notación
Yourdon.

Conviene tener en cuenta una serie de reglas:

 Los elementos tienen que tener un nombre con significado. En el caso del flujo de
datos que entra y sale de un almacén no hace falta indicar un nombre ya que se
asume que es la totalidad de los datos de un determinado registro.
 Los flujos de datos deben mostrar en qué sentido se mueven los datos.
 Se permiten flujos de datos entre: dos procesos, un proceso y un almacén, un proceso
y una entidad externa. Siempre tiene que haber un proceso como mínimo en uno de
los dos extremos del flujo de datos.
 No se permiten flujos de datos entre: dos almacenes, dos entidades externas, un
almacén y una entidad externa.
 Se realizará un DFD para cada parte del sistema que haya sido identificada.
 Los almacenes de datos y entidades externas se pueden representar varias veces si eso
mejora la legibilidad.
 En un DFD no puede haber elementos aislados.

Para representar un sistema se suelen usar varios DFDs siguiendo una estructura jerárquica. En
el nivel más alto de la jerarquía se suele representar un único proceso, identificado con un 0,
que representa el sistema completo. Se representan el proceso, los flujos de entrada y salida y
las entidades externas. Los almacenes no se representan en este nivel 0.
A continuación se descompone el proceso 0 en otro DFD en el que se representan las
funciones principales. El diagrama generado será un DFD de nivel 1. Los procesos de este DFD
se enumeran del 1 en adelante. En este nivel se representan los flujos de entrada y salida de
las entidades externas pero no las propias entidades externas. A partir de aquí, estas
entidades sólo se representarán si eso mejorara la comprensión del DFD.

Seguidamente se descompone cada uno de los procesos en nuevos procesos que representan
funciones más simples. Así podremos ver el sistema desde el ámbito general, pasando por
niveles intermedios, hasta el detalle.
El proceso enumerado como 1 se podría dividir en 3 subprocesos. Esto nos daría un DFD de
nivel 2. Al pasar de un nivel superior a uno inferior (nivel 1 a nivel 2) hay que asegurarse de
mostrar los flujos de entrada y salida del proceso de nivel anterior.
Se recomienda llegar como mucho al nivel 4 de descomposición de diagramas.
Los niveles de descomposición recomendados son:
 Nivel 0: Diagrama de contexto
 Nivel 1: Subsistemas
 Nivel 2: Funciones de cada subsistema
 Nivel 3: Subfunciones asociadas
 Nivel 4: Procesos necesarios para el tratamiento de cada subfunción

2. Diagrama de flujo de control, DFC

Similar a los DFD. La diferencia es que muestra el flujo de control en lugar del flujo de datos.
3. Diagrama de transición de estados, DTE
Representa cómo se comporta el sistema como consecuencia de sucesos externos.
4. Diagrama entidad-relación, DER
Representa los datos y la forma en que se relacionan entre ellos.
5. Diccionario de datos, DD
Es una descripción detallada de los datos utilizados por el sistema (representados por el
flujo de datos y los almacenes en el DFD).
Nota para concluir el apartado:
Todo lo realizado en el análisis debe quedar reflejado en el documento de “especificación
de requisitos de software (ERS)”. El documento debe ser claro, completo, consistente, fácil
de verificar y modificar, fácil de utilizar en la fase de explotación y mantenimiento, y
facilitar la identificación del origen y las consecuencias de los requisitos.
Diseño
A continuación, el sistema se debe dividir entre partes y establecer qué hará cada parte y qué
relaciones habrá entre ellas.
Debemos crear un modelo funcional-estructural teniendo en cuenta los requerimientos del
sistema para poder facilitar el proceso al dividirlo en partes.
Se deben tomar decisiones
importantes:
 Entidades y relaciones de las
bases de datos.
 Selección del lenguaje de
programación que se va a
utilizar.
 Selección del sistema gestor
de bases de datos.
 Etc.

El objetivo de esta fase es traducir los requisitos funcionales y no funcionales a una

representación del software.
Principalmente hay dos tipos de diseño:
 Diseño estructurado: está basado en el flujo de datos a través del sistema.
  Diseño orientado a objetos: el sistema se entiende como un conjunto de objetos que
tienen propiedades y comportamientos. También existen eventos que activan
operaciones que modifican el estado de los objetos.

Diseño estructurado
Es el diseño clásico. Produce un modelo de diseño con 4 elementos:

 Diseño de datos: está basado en los datos y las relaciones definidos en el diagrama
entidad-relación y en la descripción detallada de los datos del diccionario de datos.
 Diseño arquitectónico: usando el diagrama de flujo de datos establecemos una
estructura modular en el software. Entendemos que el programa está dividido en
componentes que pueden ser simples como un módulo o complicados como una base
de datos.
 Diseño de la interfaz: describe cómo se comunica el software consigo mismo, con los
sistemas que interactúan con él y con las personas que lo usan. El resultado es la
creación de formatos de pantalla.
 Diseño a nivel de componentes (diseño procedimental): se diseña cada componente
del software con un nivel de detalle tal que pueda usarse como guía a la hora de
generar código fuente. Para este diseño se usan representaciones gráficas.

Diseño a nivel de componentes

Sus fundamentos se establecieron al proponerse un conjunto de construcciones lógicas que
podían usarse para formar cualquier programa.
Las construcciones (fundamentales en la programación estructurada) son: secuencial,
condicional y repetitiva.
Construcción secuencial
Implementa los pasos básicos para especificar cualquier algoritmo.
Construcción condicional
Permite realizar un proceso u otro dependiendo de la comprobación de una condición lógica.
Si se cumple, se realiza la parte del SÍ; si no, se realiza la parte del NO.

La selección múltiple (switch - case) es una extensión de la estructura anterior. El parámetro

se comprueba en condiciones sucesivas hasta que una de ellas es verdadera.

Construcción repetitiva
Proporciona los bucles:

 Repetir - hasta: primero se ejecuta lo que contiene el bucle y luego se comprueba su

condición:
o Si no se cumple se vuelve a realizar la tarea.
o Si la condición se cumple, finaliza el bucle.
o La tarea se realiza al menos una vez.
 Hacer mientras: primero se comprueba la condición y después se realiza la tarea del
bucle repetidamente mientras se siga cumpliendo la condición:
o El bucle finaliza cuando la condición no se cumple.
Notaciones gráficas para el diseño
Para representar el diseño se emplean algunas herramientas gráficas como: diagramas de
flujo, diagramas de cajas, tablas de decisión o pseudocódigo.

Diagrama de flujo
Herramienta muy usada para el diseño procedimental. Se utilizan los siguientes símbolos:

Diagrama de cajas (Diagrama Nassi-Shneiderman)

Surgió por el deseo de desarrollar una representación del diseño procedimental que no
permitiera la violación de las construcciones estructuradas (como hacen las instrucciones
GOTO). Su elemento fundamental es la caja:

 Para representar una secuencia se conectan varias cajas seguidas.

 Para una condición se representa una caja para la parte SI y otra para la parte NO,
encima se indica la condición.
  En las repetitivas, el proceso a repetir se encierra en una caja que está dentro de una
caja donde, en la parte superior (do-while) o inferior (repeat-until), se indica la
condición del bucle.

 En la selección múltiple, en la parte superior se indica el caso de la condición. Se

definen tantas columnas como valores se vayan a comprobar y, debajo de la columna
de cada valor, se indica la acción a realizar.

Tablas de decisión
A veces es necesario que un programa evalúe una condición compleja de condiciones y actúe
en consecuencia.

Las tablas de decisión permiten representar en forma de tabla las condiciones y las acciones
que se llevan a cabo dependiendo de esas condiciones.

Se dividen en 4 cuadrantes:

 Cuadrante superior izquierdo: contiene la lista de condiciones.

 Cuadrante inferior izquierdo: contiene la lista de acciones.
 Cuadrante superior derecho: contiene el cumplimiento de las condiciones.
 Cuadrante inferior derecho: contiene la realización de las acciones.
Cada columna de los cuadrantes de la derecha forma una regla de procesamiento. Las reglas
establecen las acciones a realizar con cada combinación de condiciones. Al construir una tabla
se siguen los siguientes pasos:

1. Hacer una lista de todas las acciones y todas las condiciones.

2. Asociar conjuntos específicos de condiciones a acciones específicas evitando
combinaciones imposibles de condiciones.
3. Determinar las reglas indicando qué acción o acciones ocurren en cada caso.

Ejemplo:

Pseudocódigo
Utiliza texto descriptivo para realizar el diseño de un algoritmo. Mezcla lenguaje natural con
estructuras sintácticas que incluyen algunas palabras clave (si, mientras, etc.) que permiten
construir las estructuras básicas de programación estructurada, declarar datos, definir
subprogramas y establecer características de modularidad.

El pseudocódigo no está estandarizado, así que dependerá de quien lo escriba.

No puede ser compilado, pues no es un lenguaje de programación.

Representación y ejemplo:
Diseño orientado a objetos
El diseño de software orientado a objetos (DOO) es complejo. Es necesario partir de un análisis
orientado a objetos (AOO).

En dicho análisis se definen todas las clases relevantes para el problema, las operaciones y los
atributos asociados, las relaciones y comportamientos y las comunicaciones entre clases.

Para el AOO y el DOO se utiliza UML. UML es un lenguaje de modelado basado en diagramas
que sirve para expresar modelos (representación de la realidad donde se ignoran detalles sin
importancia).

Codificación
Durante esta fase se realiza el proceso de programación.

Se elegirá un determinado lenguaje de programación, se codificará toda la información

obtenida en las fases anteriores y se llevará a código fuente.

Esto es tarea del programador, que tiene que cumplir con todos lo impuesto en las fases de
análisis y diseño.

Las características deseables de todo código son:

 Modularidad: está estructurado en bloques pequeños.

 Corrección: hace lo que se le pide.
 Fácil de leer: es importante para que el mantenimiento y el desarrollo no se
compliquen.
 Eficiencia: hace buen uso de los recursos.
 Portabilidad: se debería poder implementar en cualquier equipo.

Durante esta fase el código pasa por diferentes estados: fuente, objeto y ejecutable.

Código fuente
Conjunto de instrucciones necesarias para el funcionamiento de un programa escrito por los
programadores en algún editor de texto. Se escribe usando algún lenguaje de alto nivel.

Para obtenerlo se seguirán los siguientes pasos:

1. Se tendrá en cuenta la información obtenido en las fases anteriores de análisis y

diseño.
2. Se elaborará un algoritmo.
3. Se elegirá algún lenguaje de alto nivel teniendo en cuenta las características del
software que se quiere codificar.
4. Se procederá a la codificación del algoritmo. Si el algoritmo ha sido elaborado en
pseudocódigo, la codificación a algún lenguaje de programación será más rápida.

Al completar los pasos anteriores tendremos un documento con la codificación de todos los
módulos, funciones, bibliotecas y procedimientos necesarios.

El código fuente tendrá que ser traducido a lenguaje máquina para que el ordenador lo pueda
entender y ejecutar.
Una característica del código fuente es que pueden dividirse por su licencia. Distinguimos dos
tipos:

 Código fuente abierto: cualquier usuario puede estudiarlo, modificarlo o reutilizarlo.

 Código fuente cerrado: no podemos editarlo.

Código objeto
Es un código intermedio entre el código fuente y el ejecutable, así que el ordenador no lo
puede leer.

Este código es el resultado de traducir el código a binario al compilar el código fuente. El

código sólo puede compilarse si el código fuente está libre de errores sintácticos y semánticos.
Este bytecode está distribuido en varios archivos, cada uno correspondiente a un programa
compilado.

El proceso de traducción se puede realizar de dos formas:

 Compilación: es la traducción completa del programa en un solo paso, la realiza

un compilador. Esta compilación se almacena.
 Interpretación: es la traducción y ejecución simultánea del programa línea a
línea, la realiza un intérprete. No existe código objeto. Si un bloque del programa
no se recorre durante la interpretación no será necesario compilarlo. Este
proceso es más lento que la compilación.

Código ejecutable
Es el código binario resultante de enlazar el código objeto con ciertas rutinas y librerías
necesarias. Ese enlace lo realiza un software llamado linker (enlazador). Ese linker se
encuentra en una máquina virtual, que será la encargada de traducir el bytecode del
código objeto a código ejecutable.

El sistema operativo es el encargado de cargar el programa en memoria y ejecutarlo.

Este código también se conoce como código máquina y es directamente legible por el
ordenador.

Máquinas virtuales
Es un tipo especial de software que separa el funcionamiento del ordenador del hardware.

Las funciones principales de una máquina virtual son las siguientes:

 Conseguir que las aplicaciones sean portables. Usando máquinas virtuales podremos
desarrollar y ejecutar una aplicación en cualquier equipo sin importar las
características del hardware.
 Reservar memoria para los objetos que se crean y liberar la no utilizada.
 Comunicarse con el sistema en el que se encuentra (huésped), para administrar el
control de los dispositivos hardware implicados en los procesos.
 Cumplir las normas de seguridad de las aplicaciones.
Características de una máquina virtual:

 Al compilar el código fuente se obtiene código objeto.

 Garantiza la independencia necesaria respecto al hardware para ejecutar el código en
cualquier máquina. Aísla la aplicación de los detalles físicos.
 Funciona como una capa de software de bajo nivel y hace de puente entre el bytecode
de la aplicación y el hardware del sistema.
 Verifica todo el bytecode antes de ejecutarlo.
 Protege las direcciones de memoria.

Frameworks
Es una estructura de ayuda al programador que podemos usar para desarrollar proyectos sin
empezar desde cero.

Se trata de una plataforma software donde están definidos programas soporte,

bibliotecas, lenguaje interpretado, etc. que ayuda a desarrollar y unir las diferentes
partes de un proyecto.

Gracias a la ayuda que proporciona podemos estar más tiempo analizando los
requerimientos del sistema y las especificaciones de la aplicación, ya que la tarea
pesada de la programación la realiza el framework.

Ventajas de utilizar un framework:

 Desarrollo rápido de software.

 Reutilización de partes de código para otras aplicaciones.
 Diseño uniforme del software.
 Portabilidad de un equipo a otro gracias a las máquinas virtuales.

Inconvenientes de utilizar un framework:

 Gran dependencia del código respecto al framework utilizado (si cambiamos de

framework habría que reescribir parte de la aplicaicón).
 El framework consume bastantes recursos del sistema.

Ejemplos de frameworks:

 .NET: el framework de Microsoft para realizar aplicaciones orientadas a Windows. Se

instala en la unidad del sistema operativo.
 Spring: framework de Java formado por conjuntos de bibliotecas (APIs) para el
desarrollo y ejecución de aplicaciones.

Entornos de ejecución
Es un servicio de la máquina virtual o conjunto de utilidades que sirve como base software
para la ejecución de programas. En algunos casos se instala encima del sistema operativo o
viene integrado ya en él, en otros casos se instala como software independiente que funciona
por debajo de la aplicación.
El tiempo que tarda un programa en ejecutarse recibe el nombre de runtime.

Durante la ejecución los entornos se encargan de una serie de cosas:

 Configurar la memoria principal disponible.

 Enlazar los archivos del programa con las bibliotecas existentes y los subprogramas
creados. La diferencia entre una biblioteca y un subprograma es que las bibliotecas
existen previamente y los subprogramas los creamos nosotros.
 Depurar los programas. Se comprueba si hay errores semánticos en el lenguaje. Los
sintácticos se comprobaron en la compilación.

El entorno está formado por la máquina virtual y las APIs. Se suelen distribuir en conjunto
porque tienen que ser compatibles.

El entorno hace de intermediario entre el código y el sistema operativo para poder ejecutar
aplicaciones. Si quisiéramos, además de ejecutar, desarrollar aplicaciones necesitaríamos
instalar un entorno de desarrollo ya que el entorno de ejecución no es suficiente.

Entornos de desarrollo
Vamos a explicarlos tomando como base el Java Runtime Environment.

Un entorno de desarrollo es un conjunto de utilidades que facilitan el desarrollo de

aplicaciones.

El JRE se compone de un conjunto de utilidades que permitirá ejecutar programas escritos en

Java en cualquier plataforma.

El JRE está formado por:

 Una máquina virtual Java (JVM), que interpretará el código de la aplicación escrito en
Java.
 Bibliotecas de clase estándar que forman el API de Java.

Tanto la máquina virtual como las APIs de Java son consistentes entre sí, así que se
distribuyen conjuntamente.

Pruebas
Una vez obtenido el software tenemos que realizar pruebas.

La realización de pruebas es fundamental para asegurarnos de que el software es válido y está

bien construido. La duración se pactará con el cliente.

Las pruebas se suelen realizar sobre un conjunto de datos de prueba, que consisten en un
conjunto seleccionado y predefinido de datos límite que queremos probar.

Entre las pruebas que se efectúan sobre el software podemos distinguir:

 Pruebas unitarias: se prueban, una a una, las diferentes partes del software y se
comprueba su funcionamiento por separado. JUnit es el entorno de pruebas de Java.
 Pruebas de integración: se realizan si tienen éxito las unitarias. Consisten en
comprobar el funcionamiento del sistema al completo.

La prueba final se suele llamar Beta Test y se realiza en el entorno de producción donde el
cliente utilizará el software.
 Flujo de proceso para probar el software:

1. Se empieza generando un plan de pruebas a partir de la documentación del

proyecto y la documentación del software a probar.
2. A partir del plan se diseñan las pruebas. Se identifican las técnicas que se van a
usar para probar el software.
3. Se generan los casos de prueba según las técnicas identificadas en el paso anterior.
4. Definición de los procedimientos de la prueba, es decir, explicaremos cómo se
llevará a cabo cada proceso, quién lo validará, cuándo lo hará, etc.
5. Ejecución de las pruebas aplicando los casos de prueba generados anteriormente.
6. Evaluación. Se identifican los posibles errores al comparar los resultados de la
ejecución con los resultados esperados. Se hará un informe con el resultado de la
ejecución, en qué casos se pasó la prueba, en cuáles no y qué fallos se detectaron.
7. Depuración. Se intentan localizar y corregir los errores. Cada vez que se corrija un
error se tiene que volver a probar el software. Si no se localiza el error se tendrán
que hacer más pruebas para obtener más información.
8. El análisis de errores nos sirve para predecir la fiabilidad del software y mejorar los
procesos de desarrollo en el futuro.

Para llevar a cabo el diseño de los casos de prueba se usan dos técnicas:

 Prueba de caja blanca: se centran en validar la estructura interna del programa

(necesitan conocer los detalles procedimentales del código).
 Prueba de caja negra: se centran en validar los requisitos funcionales sin importar el
funcionamiento interno del programa (necesitan saber la funcionalidad que el código
debe proporcionar).

Ambas pruebas no son excluyentes, se pueden combinar.

Documentación
Todas las etapas del desarrollo deben estar bien documentadas. De esta forma se podrá
informar al usuario de su funcionamiento y se facilitará el mantenimiento.

La documentación se irá realizando en cada una de las fases.

Si estamos siguiendo un diseño modular, una correcta documentación permitirá la

reutilización de parte del código en otras aplicaciones.

Se distinguen tres grandes documentos en el desarrollo de software:

Explotación
Hay autores que consideran que explotación y mantenimiento son la misma etapa. Nosotros
vamos a diferenciarlas según el momento en que se realizan.

La explotación es la instalación, configuración y funcionamiento de la aplicación en el equipo

final del cliente, es decir, es la fase en la que los usuarios conocen la aplicación y comienzan a
utilizarla.

En la instalación los programas son transferidos al ordenador del cliente, donde son
configurados y verificados. Sería buena idea que los clientes estuvieran presentes durante la
instalación para que conozcan el planteamiento.

Es en este momento cuando se realizan las Beta Test, las últimas pruebas que se realizan en los
equipos finales bajo cargas normales de trabajo.

Una vez finaliza la instalación, pasamos a la configuración.

La configuración la podemos realizar nosotros, los usuarios mediante la guía de instalación o, si

la aplicación es más sencilla, podemos hacer que la configuración se realice automáticamente
después de la instalación. Si el software es a medida, es mejor que la configuración la hagan
sus desarrolladores.

Una vez se ha realizado la configuración, la aplicación pasa a mano de los usuarios y comienza
la explotación del software en sí misma. Todo tiene que estar preparado antes de
presentárselo al cliente.
Mantenimiento
El software es cambiante y tendrá que actualizarse y evolucionar con el tiempo. Tendrá que
adaptarse a las mejoras de hardware del mercado y a situaciones nuevas que no existían
cuando el software se construyó.

También habrá que corregir los nuevos errores que vayan surgiendo para desarrollar nuevas
versiones mejores que las anteriores.

Debido a estas razones, se pacta con el cliente un servicio de mantenimiento (que supondrá un
coste temporal y económico).

El mantenimiento se define como el proceso de control, mejora y optimización del software.

La fase de mantenimiento es la más larga de todo el ciclo de vida del software ya que incluye
las actualizaciones y evoluciones del mismo.

Los tipos de cambios que hacen necesario el mantenimiento son los siguientes:

 Perfectivos: para mejorar la funcionalidad.

 Evolutivos: el cliente irá teniendo nuevas necesidades, serán necesarias
modificaciones, expansiones o eliminaciones del código.
 Adaptativos: modificaciones para adaptarse a las nuevas tendencias.
 Correctivos: se encontrarán nuevos errores con el paso del tiempo.