UT1 Desarrollo de Software II PRESENTACION
UT1 Desarrollo de Software II PRESENTACION
de Software II
Entornos de Desarrollo
2019-2020
1º DAM/DAW
C.I. María Ana Sanz
3. Desarrollo de software
Todo el proceso que ocurre desde que se
concibe una idea hasta que un programa está
implementado en el ordenador y funcionando.
Todo proceso conlleva una serie de pasos
3. Desarrollo de software
o Análisis de requisitos: se especifican los requisitos
funcionales y no funcionales del sistema.
o Diseño: se divide el sistema en partes y se determina
la función de cada una.
o Codificación: se elige un lenguaje de programación
y se codifican los programas.
o Pruebas: se prueban los programas para detectar
errores y se depuran.
o Documentación: de todas las etapas, se
documenta y guarda toda la información.
o Explotación: instalamos, configuramos y probamos
la aplicación en los equipos del cliente.
o Mantenimiento: se mantiene el contacto con el
cliente para actualizar y modificar la aplicación en
el futuro.
3.1 Ciclos de vida de software
o La serie de pasos a seguir para desarrolla un
programa es lo que se conoce como Ciclo de
Vida del Software
o Siempre se debe aplicar un modelo de ciclo de
vida al desarrollo de cualquier proyecto de
software
o 1) MODELO EN CASCADA
o 2) MODELO EN CASCADA CON REALIMENTACIÓN
o 3) MODELOS EVOLUTIVOS
o A. MODELO ITERATIVO INCREMENTAL
o B. MODELO EN ESPIRAL
3.1 Ciclos de vida de software
MODELO EN CASCADA
o Para empezar una etapa es
necesario finalizar la etapa
anterior
o Después de cada etapa se
realiza una revisión para
comprobar si se puede pasar
a la siguiente
o Sólo es aplicable a pequeños
desarrollos
3.1 Ciclos de vida de software
MODELO EN CASCADA CON
RETROALIMENTACIÓN
o Podemos volver
atrás en cualquier
momento para
corregir, modificar
o depurar algún
aspecto
o El modelo
perfecto si el
proyecto es rígido
(pocos cambios) y
los requisitos están
claros
3.1 Ciclos de vida de software
MODELO ITERATIVO INCREMENTAL
o Entrega el software en partes pequeñas, pero
utilizables, llamadas “incrementos”. Cada
incremento se construye sobre aquel que ya ha
sido entregado.
o No se necesita
conocer todos
los requisitos
al comienzo
o Cuando es posible
que haya grandes
cambios
3.1 Ciclos de vida de software
MODELO EN ESPIRAL
o Combinación entre modelo en cascada e
incremental
o El software se va construyendo repetidamente
en forma de versiones que son cada vez
mejores
o Para proyectos de
gran tamaño y que
necesitan constantes
cambios
3.1 Ciclos de vida de software
Reflexiona
Según estimaciones, el 26% de los grandes
proyectos de software fracasan, el 48% deben
modificarse drásticamente y sólo el 26% tienen un
rotundo éxito. La principal causa del fracaso de
un proyecto es la falta de una buena
planificación de las etapas y mala gestión de los
pasos a seguir. ¿Por qué el porcentaje de fracaso
es tan grande? ¿Por qué piensas que estas causas
son tan determinantes?
3.2 Fases de desarrollo de SW
o Análisis de requisitos: se especifican los requisitos
funcionales y no funcionales del sistema.
o Diseño: se divide el sistema en partes y se determina
la función de cada una.
o Codificación: se elige un lenguaje de programación
y se codifican los programas.
o Pruebas: se prueban los programas para detectar
errores y se depuran.
o Documentación: de todas las etapas, se
documenta y guarda toda la información.
o Explotación: instalamos, configuramos y probamos
la aplicación en los equipos del cliente.
o Mantenimiento: se mantiene el contacto con el
cliente para actualizar y modificar la aplicación en
el futuro.
3.2 Fases de desarrollo de SW
o Análisis de requisitos: se especifican los requisitos
funcionales y no funcionales del sistema.
o Diseño: se divide el sistema en partes y se determina
la función de cada una.
o Codificación: se elige un lenguaje de programación
y se codifican los programas.
o Pruebas: se prueban los programas para detectar
errores y se depuran.
o Documentación: de todas las etapas, se
documenta y guarda toda la información.
o Explotación: instalamos, configuramos y probamos
la aplicación en los equipos del cliente.
o Mantenimiento: se mantiene el contacto con el
cliente para actualizar y modificar la aplicación en
el futuro.
ANÁLISIS
o Esta es la primera fase y la de mayor
importancia en el desarrollo del proyecto. Todo
lo demás dependerá de lo bien detallada que
esté.
o Es la más complicada, ya que no está
automatizada y depende en gran medida del
analista que la realice.
o ¿Qué se hace en esta fase? Se especifican y
analizan los requisitos funcionales y no
funcionales del sistema.
ANÁLISIS
o REQUISITOS
o Funcionales: Qué funciones tendrá que realizar la
aplicación. Qué respuesta dará la aplicación
ante todas las entradas. Cómo se comportará la
aplicación en situaciones inesperadas.
o No funcionales: Tiempos de respuesta del
programa, legislación aplicable, tratamiento ante
la simultaneidad de peticiones, etc.
o Lo fundamental es la buena comunicación
entre el analista y el cliente para que la
aplicación que se va a desarrollar cumpla con
sus expectativas.
ANÁLISIS
o La culminación de esta fase es el documento
ERS (Especificación de Requisitos Software). En
este documento quedan especificados:
o La planificación de las reuniones que van a tener
lugar.
o Relación de los objetivos del usuario cliente y del
sistema.
o Relación de los requisitos funcionales y no
funcionales del sistema.
o Relación de objetivos prioritarios y temporización.
o Reconocimiento de requisitos mal planteados o
que conllevan contradicciones, etc.
3.2 Fases de desarrollo de SW
o Análisis de requisitos: se especifican los requisitos
funcionales y no funcionales del sistema.
o Diseño: se divide el sistema en partes y se determina
la función de cada una.
o Codificación: se elige un lenguaje de programación
y se codifican los programas.
o Pruebas: se prueban los programas para detectar
errores y se depuran.
o Documentación: de todas las etapas, se
documenta y guarda toda la información.
o Explotación: instalamos, configuramos y probamos
la aplicación en los equipos del cliente.
o Mantenimiento: se mantiene el contacto con el
cliente para actualizar y modificar la aplicación en
el futuro.
3.2 Fases de desarrollo de SW
o Análisis de requisitos: se especifican los requisitos
funcionales y no funcionales del sistema.
o Diseño: se divide el sistema en partes y se determina
la función de cada una.
o Codificación: se elige un lenguaje de programación
y se codifican los programas.
o Pruebas: se prueban los programas para detectar
errores y se depuran.
o Documentación: de todas las etapas, se
documenta y guarda toda la información.
o Explotación: instalamos, configuramos y probamos
la aplicación en los equipos del cliente.
o Mantenimiento: se mantiene el contacto con el
cliente para actualizar y modificar la aplicación en
el futuro.
DISEÑO
o Durante esta fase, donde ya sabemos lo que
hay que hacer, lo que se decide es el siguiente
paso, cómo hacerlo.
o Se debe dividir el sistema en partes y se
establece qué
relaciones habrá
entre ellas.
Decidir qué hará
exactamente
cada parte.
DISEÑO
o En definitiva, se debe crear un modelo
funcional-estructural de los requisitos del sistema
global, para poder dividirlo y afrontar las partes
por separado.
o En este punto, se deben tomar decisiones
importantes, tales como:
o Entidades y relaciones de las bases de datos.
o Selección del lenguaje de programación que se
va a utilizar.
o Selección del sistema gestor de base de datos.
o Etc.
UML
o UML (Unified Modeling Language o Lenguaje
Unificado de Modelado) es un conjunto de
herramientas que permite modelar, construir y
documentar los elementos que forman un
sistema software orientado a objetos.
o ¿Por qué debemos modelar?
o Porque permite utilizar un lenguaje común que
facilita la comunicación entre el equipo de
desarrollo.
UML
Diagramas
Diagramasde
deCasos
Casos dede Uso
Uso
Diagrama de casos de uso
Actores
Representan un tipo de usuario del sistema
Se entiende como usuario a cualquier cosa externa que interactúa con el
sistema
No tiene por qué ser un ser humano, puede ser otro sistema informático o
unidades organizativas o empresas
Es posible que haya casos de uso que no sean iniciados por ningún usuario, o
algún otro elemento software, en ese caso se puede crear un actor “Tiempo”
o “Sistema”.
Elementos de casos de uso
Elementos de casos de uso
Casos de Uso
Su objetivo es especificar tareas que deben poder llevarse a cabo con el
apoyo del sistema que se está desarrollando
Un caso de uso especifica una secuencia de acciones, incluyendo variantes,
que el sistema puede llevar a cabo, y que producen un resultado observable
de valor para un actor concreto.
El conjunto de casos de uso forma el “comportamiento requerido” de un
sistema.
Elementos de casos de uso
Caso de uso
Elementos de casos de uso
Relaciones
Asociación: representa la relación entre el actor que lo inicia y el caso de uso.
Inclusión: se utiliza cuando queremos dividir una tarea de mayor envergadura
en otras más sencillas, que son utilizadas por la primera. Representa una
relación de uso, y son muy útiles cuando es necesario reutilizar tareas.
Extensión: se utiliza para representar relaciones entre un caso de uso que
requiere la ejecución de otro en determinadas circunstancias.
Generalización: se utiliza para representar relaciones de herencia entre casos
de uso o actores.
Elementos de casos de uso
Interacción o asociación
Hay una asociación entre un actor y un caso de uso si el actor interactúa con
el sistema para llevar a cabo el caso de uso o para iniciarlo.
Una asociación se representa mediante un línea continua que une un actor
con un caso de uso.
Por ejemplo, un usuario de un sistema de venta por Internet puede hacer un
pedido, lo que se representa del siguiente modo:
Elementos de casos de uso
Interacción o asociación
Elementos de casos de uso
Generalización
Igual que con los diagramas de clases, existan casos de uso que tengan
comportamientos semejantes a otros que los modifican o completan de
alguna manera.
El caso base se define de forma abstracta y los hijos heredan sus
características añadiendo sus propios pasos o modificando alguno.
Normalmente la herencia se utiliza menos en diagramas de casos de uso que
en diagramas de clases.
Elementos de casos de uso
Generalización
Por ejemplo, el usuario del sistema de venta por Internet puede a su
vez darse de alta en la página web para que tengan sus datos
registrados a la hora de hacer el pedido, en este caso el usuario es la
generalización del socio.
Ambos actores pueden hacer un pedido, pero solo el socio puede
modificar sus datos en el sistema.
Elementos de casos de uso
Generalización
Elementos de casos de uso
Extensión
La principal función de esta relación es simplificar el flujo de casos de uso
complejos.
Se utiliza cuando existe una parte del caso de uso que se ejecuta sólo en
determinadas ocasiones, pero no es imprescindible para su completa
ejecución.
Cuando un caso de uso extendido se ejecuta, se indica en la especificación
del caso de uso como un punto de extensión. Los puntos de extensión se
pueden mostrar en el diagrama de casos de uso
Elementos de casos de uso
Extensión
Por ejemplo, cuando un usuario hace un pedido si no es socio se le ofrece la
posibilidad de darse de alta en el sistema en ese momento, pero puede
realizar el pedido, aunque no lo sea
Elementos de casos de uso
Extensión
Elementos de casos de uso
Inclusión
Esta relación es muy útil cuando se desea especificar algún comportamiento
común en dos o más casos de uso
Es frecuente cometer el error de utilizar esta técnica para hacer subdivisión de
funciones, por lo que se debe tener mucho cuidado cuando se utilice.
Por ejemplo, a la hora de hacer un pedido se debe buscar la información de
los artículos para obtener el precio, es un proceso que necesariamente forma
parte del caso de uso, sin embargo, también forma parte de otros, como son
el que visualiza el catálogo de productos y la búsqueda de un artículo
concreto, y dado que tiene entidad por sí solo se separa del resto de casos de
uso y se incluye en los otros tres.
Elementos de casos de uso
Inclusión
Elementos de casos de uso
Inclusión
Ventajas
Las descripciones de los casos de uso son más cortas y se entienden mejor.
La identificación de funcionalidad común puede ayudar a descubrir el posible uso
de componentes ya existentes en la implementación.
Desventajas
La inclusión de estas relaciones hace que los diagramas sean más difíciles de leer,
sobre todo para los clientes.
Codificación
• Durante esta etapa se realiza el proceso de programación → elegir un
determinado lenguaje de programación, codificar toda la información
anterior y llevarlo a código fuente.
• Esta tarea la realiza el programador y tiene que cumplir
exhaustivamente con todos los datos impuestos en el análisis y en el
diseño de la aplicación.
• Las características deseables de todo código son:
1) Modularidad: que esté dividido en trozos más pequeños.
2) Corrección: que haga lo que se le pide realmente.
3) Fácil de leer: para facilitar su desarrollo y mantenimiento futuro.
4) Eficiencia: que haga un buen uso de los recursos.
5) Portabilidad: que se pueda implementar en cualquier equipo.
Codificación
• Durante esta fase, el código pasa por diferentes estados:
1) Código Fuente
o es el escrito por los programadores en algún editor de texto.
o se escribe usando algún lenguaje de programación de alto nivel y contiene el conjunto de
instrucciones necesarias.
2) Código Objeto
o es el código binario resultado de compilar el código fuente.
o no es directamente inteligible por el ser humano, pero tampoco por la computadora → es un
código intermedio entre el código fuente y el ejecutable y sólo existe si el programa se compila (si
se interpreta se traduce y se ejecuta en un solo paso).
3) Código Ejecutable
o es el código binario resultante de enlazar los archivos de código objeto con ciertas rutinas y librerías
necesarias.
o El sistema operativo será el encargado de cargar el código ejecutable en memoria RAM y proceder
a ejecutarlo.
o También es conocido como código máquina y ya sí es directamente inteligible por la computadora.
Proceso en la obtención del código ejecutable
1) A partir de un editor, escribimos el código fuente
usando algún lenguaje de programación.
2) El código fuente se compila obteniendo el código
objeto o bytecode.
3) Ese código objeto, a través de la máquina virtual,
pasa a código máquina, ya directamente ejecutable
por el ordenador.
Código fuente
• Conjunto de instrucciones que la computadora deberá realizar →
escritas por los programadores en algún lenguaje de alto nivel.
• No es directamente ejecutable por la máquina → ser traducido al
lenguaje máquina, que la computadora será capaz de entender y
ejecutar.
• IMPORTANTE → elaboración de un algoritmo → conjunto de pasos a
seguir para obtener la solución del problema → la codificación
posterior a algún lenguaje de programación determinado será más
rápida y directa.
• El algoritmo se diseña en pseudocódigo
Pseudocódigo
• Mezcla frases en lenguaje natural con estructuras sintácticas que
incluyen palabras clave → permiten construir las estructuras básicas
de la programación estructurada, declarar datos, definir
subprogramas y establecer características de modularidad.
• Depende mucho del que lo escriba → no hay un estándar definido.
• Al no ser un lenguaje de programación no puede ser compilado.
• Ejemplo: pseudocódigo de un proceso repetitivo de lectura y
tratamiento de los registros de un fichero secuencial:
Pseudocódigo
Código fuente
• Para obtener el código fuente de una aplicación informática:
1) Se debe partir de las etapas anteriores de análisis y diseño.
2) Se diseña un algoritmo que simbolice los pasos a seguir para la resolución
del problema.
3) Se elige un lenguaje de programación de alto nivel apropiado para las
características del software que se quiere codificar.
4) Se lleva a cabo la codificación del algoritmo antes diseñado.
• Aspecto importante a tener en cuenta → su licencia:
o Código fuente abierto: aquel que está disponible para que cualquier usuario
pueda estudiarlo, modificarlo o reutilizarlo.
o Código fuente cerrado: aquel que no tenemos permiso para editarlo.
Código objeto
• Es el resultado de traducir código fuente a un código equivalente que
aún no puede ser ejecutado directamente por la computadora → es
un código intermedio.
• Esa traducción recibe el nombre de compilación.
• Consiste en un bytecode → código binario (0s y 1s) resultante de la
traducción de código de alto nivel que aún no puede ser ejecutado.
• Está distribuido en varios archivos → cada uno corresponde a un
programa fuente compilado.
• Sólo se genera código objeto una vez que el código fuente está libre
de errores sintácticos y semánticos.
Código objeto
• El proceso de traducción de código fuente a código objeto puede realizarse
de dos formas:
o Compilación
. El proceso de traducción se realiza sobre todo el código fuente, en un solo paso.
. Se crea código objeto que habrá que enlazar.
. El software responsable se llama compilador → software que traduce, de una sola vez,
un programa escrito en un lenguaje de programación de alto nivel en su equivalente en
lenguaje máquina.
o Interpretación
. El proceso de traducción del código fuente se realiza
línea a línea y se ejecuta simultáneamente.
. No existe código objeto intermedio.
. El software responsable se llama intérprete →
software que traduce, instrucción a instrucción, un
programa escrito en un lenguaje de alto nivel en su
equivalente en lenguaje máquina.
. El proceso de traducción es más lento que en el caso
de la compilación, pero es recomendable cuando el
programador es inexperto, ya que la detección de
errores es más detallada.
Código ejecutable
• Principales funciones:
o Conseguir que las aplicaciones sean portables.
o Reservar memoria para los objetos que se crean y liberar la memoria no
utilizada.
o Comunicarse con el sistema donde se instala la aplicación (huésped), para el
control de los dispositivos hardware implicados en los procesos.
o Cumplimiento de las normas de seguridad de las aplicaciones.
Entornos de ejecución
• Servicio de la máquina virtual que sirve como base software para la
ejecución de programas.
• En ocasiones pertenece al propio sistema operativo, pero también se
puede instalar como software independiente que funcionará por
debajo de la aplicación.
• Durante la ejecución, los entornos se encargarán de:
o Configurar la memoria principal disponible en el sistema.
o Enlazar los archivos del programa con las librerías utilizadas (conjunto de
subprogramas que sirven para desarrollar o comunicar componentes
software que ya existen previamente) y con los subprogramas creados.
o Depurar los programas → comprobar la existencia o no de errores semánticos
del lenguaje (los sintácticos ya se detectaron en la compilación).
Entornos de ejecución. Funcionamiento
• El entorno de ejecución está formado por la máquina virtual y las
API´s → se suelen distribuir conjuntamente porque necesitan ser
compatibles entre sí.
• API´s → librerías de clases estándar, escritas en algún lenguaje de
programación, necesarias para que la aplicación pueda ser ejecutada.
• El entorno funciona como intermediario entre el lenguaje fuente y el
sistema operativo, y consigue ejecutar aplicaciones.
• Si lo que queremos es desarrollar nuevas aplicaciones, no es
suficiente con el entorno de ejecución → necesitamos un entorno de
desarrollo (próxima UT).
ID’s dedePRogramación
IDEs Programación
Concepto de Entorno de
Desarrollo
• Se debe ir documentando el proyecto en todas las fases del mismo, para pasar de
una a otra de forma clara y definida.
• Una correcta documentación permitirá la reutilización de parte de los programas
en otras aplicaciones, siempre y cuando se desarrollen con diseño modular.
• Distinguimos 3 grandes documentos en el desarrollo software:
Documentación
Documentación
Documentación
Reflexiona
Realizas un proyecto software por vez primera y no te das cuenta de documentarlo.
Consigues venderlo a buen precio a una empresa. Al cabo de un par de meses te
piden que actualices algunas de las funciones, para tener mayor funcionalidad.
Estás contento o contenta porque eso significa un ingreso extra. Te paras un
momento...
¿Dónde están los códigos?
¿Qué hacía exactamente la aplicación?
¿Cómo se diseñó?
No lo recuerdas... Probablemente hayas perdido un ingreso extra y unos buenos
clientes.
Etapas de desarrollo software
Explotación
• Una vez que se sabe que el software es fiable, carece de errores y
hemos documentado todas las fases → etapa de explotación → fase
en que los usuarios finales conocen la aplicación y comienzan a
utilizarla.
• Consiste en la instalación, puesta a punto y funcionamiento de la
aplicación en el equipo final del cliente.
• Los programas son transferidos al computador del usuario cliente,
configurados y verificados.
• Es entonces cuando se suelen llevan a cabo las Beta Test, que son las
últimas pruebas que se realizan en los propios equipos del cliente y
bajo cargas normales de trabajo.
Explotación
• Configuración:
o Puede que la realicen los propios usuarios finales → si previamente se les ha
dado la guía de instalación.
o Si la aplicación es sencilla → se puede programar la configuración de manera
que se realice automáticamente tras instalarla.
• Siguiente y último paso → fase de producción normal → la aplicación
pasa a manos de los usuarios finales y se da comienzo a la explotación
del software.
• Es muy importante tenerlo todo preparado antes de presentarle el
producto al cliente: será el momento crítico del proyecto.
Mantenimiento
• Sería lógico pensar que con la entrega de nuestra aplicación hemos
terminado nuestro trabajo → ERROR
• En cualquier otro sector laboral esto es así, pero el caso de la construcción
de software es muy diferente → la etapa de mantenimiento es la más
larga de todo el ciclo de vida del software:
o El software es cambiante y deberá actualizarse y evolucionar con el tiempo.
o Deberá ir adaptándose a las mejoras del hardware en el mercado.
o Deberá afrontar situaciones nuevas que no existían cuando el software se construyó.
o Siempre surgen errores que habrá que ir corrigiendo y nuevas versiones del producto
mejores que las anteriores.