Introducción al proceso de

desarrollo de Software

Harold Adrian Bolaños Rodriguez, MSc

Arquitecto de Soluciones
 Objetivos
● Describir el proceso de desarrollo de Software
con un paradigma Orientado a Objetos (OOSD)
● Describir como el “modelamiento” soporta los
procesos de OOSD
● Explicar el propósito, actividades y artefactos
de los flujos de trabajo en un proceso de OOSD
 Preguntas Iniciales
● Cuales son las características esenciales de un
proceso de desarrollo de Software?

● Desde su experiencia, cuales son los flujos de

trabajo o las actividades necesarias para llevar
a cabo un proceso de desarrollo de Software
Orientado a Objetos?
 Metodología
● “Conjunto de métodos, reglas y postulados
empleados por una disciplina”. [Webster New
Collegiate Dictionary]

● En un proceso de OOSD, se refiere a el nivel

mas alto de organización en un proyecto de
software

● ¿Cual es la herramienta de desarrollo de

Software más importante?
 Metodología
● Esta organización puede ser descompuesta en
fases.
● Las fases pueden ser descompuestas en flujos
de trabajo.
● Los flujos de trabajo pueden ser
descompuestos en actividades
● Finalmente, las actividades transforman los
“artefactos”
 Metodología
● El resultado final de la metodología es un
artefacto.

● El artefacto final es el producto de software que

“satisface” el artefacto inicial, los requisitos del
sistema de software.
Metodología
 Flujos de Trabajo
● Tradicionalmente se involucran los siguientes
flujos de trabajo en un proceso de OOSD.
– “Elicitación” de requisitos
– Análisis de requisitos
– Arquitectura
– Diseño
– Implementación
– Pruebas
– Despliegue
 Comparemos dos paradigmas
Paradigma procedimental Paradigma OO

Estructura Jerarquía de Red de Objetos

Organizacional (Sub)Tareas Colaborando

Capacidad de modificar el Software es difícil de cambiar Software es relativamente

Software Más fácil de cambiar

Reutilización de código Predomina el “Copy-paste” o Reutilización de código con

1001 parámetros o uso de El uso de extensión e
Variable globales Instanciación de objetos

Configuración de casos Predomina los condicionales Comportamiento polimórfico

Especiales Anidados if o switch

Separación funcional Las pruebas son construidas Código modular ayuda a

Dentro del código. Difícil Separar bloques funcionales
Separación funcional
Roles involucrados en el proceso
Cliente Equipo de trabajo

Administrador
Proyecto
Propietario(s) del
Negocio Analista del
Negocio
Administrador(es)
Arquitecto
De solución
Usuarios
Diseñador de
Software

Programador
Tester

Especialista de
despliegue
 Qué es un modelo?
● Un modelo es la simplificación de la realidad.
[Booch UML User Guide]

● Un modelo es una conceptualización abstracta

de una entidad o sistema
● Diferentes vistas muestran el modelo desde
diferentes perspectivas
 Por qué modelar Software?
● “Modelamos SW por que podemos entender
mejor lo que estamos desarrollando”
● Modelar Software nos permite:
– Visualizar el sistema (nuevo o existente)
– Comunicar las decisiones a los integrantes del
proyecto
– Documentar las decisiones que se tomaron
– Especificar la estructura y el funcionamiento del
sistema
– Usar una “plantilla” para construir el sistema
 Mapa del curso
Modelo de
arquitectura
Requisitos
No funcionales

Modelo de Modelo de
Código
requisitos solución

Interesado
En el Requisitos
proyecto funcionales
Modelo de
diseño
 Definición de UML
● UML = Unified Modelling Language (Lenguaje
Unificado de Modelado)
● UML es un lenguaje gráfico que sirve para visualizar,
especificar, construir y documentar los artefactos de
un sistema de Software [UML v2.5]
 Composición de los modelos UML
● Un modelo construido en UML, estaría
compuesto de:

– Elementos (Cosas y relaciones entre ellas)

– Diagramas (Agrupación lógica de elementos)
– Vistas (Diagramas mostrando diferentes
perspectivas de un modelo)
Elementos en UML
O nodos O enlaces
Diagramas en UML
Vistas en UML
 Qué es y Qué no es UML
● UML NO es:
– Utilizado para crear un modelo “ejecutable”
– Un lenguaje de programación
– Una metodología

● UML es:
– Usado para generar “esqueletos” de programas
– Usado para “traducir” a varios lenguajes de
programación
– Usado como herramienta en actividades de algunas
metodologías de desarrollo
 Mapa de los flujos de trabajo que veremos en este curso
● “Elicitación” de requisitos
Entrevista al dueño Visión
● Análisis de requisitos En el proyecto para
Requisitos funcionales de
● Arquitectura Alto nivel

● Diseño Entrevista a los interesados

En el proyecto para SRS
● Implementación Requisitos funcionales y no
funcionales
● Pruebas
● Despliegue Identificar restricciones y riesgos
En el documento SRS

Crear el glosario del proyecto

Basado en los Rfs y el SRS

Crear un diagrama de casos de

Uso inicial desde el SRS
 Mapa de los flujos de trabajo que veremos en este curso
Formulario UCs

Analizar los escenarios de

Casos de uso

● “Elicitación” de requisitos Refinar el diagrama de casos de

Uso basado en el análisis
● Análisis de requisitos
● Arquitectura Verificar un caso de uso
Utilizando un diagrama de actividades
● Diseño SRS
Determinar las abstracciones
● Implementación Claves usando CRC
● Pruebas
Representar las relaciones de
● Despliegue Las abstracciones clave
Modelo de dominio

Verificar el modelo de dominio

Usando diagrama de objetos
 Mapa de los flujos de trabajo que veremos en este curso

SRS
Seleccionar un tipo de
Arquitectura para el sistema

Crear un diagrama de despliegue

Detallada para los casos de uso
significantes

“Elicitación” de requisitos
Refinar el modelo de arquitectura
Para satisfacer los RNFs
Análisis de requisitos
Arquitectura
Crear la línea base de la
Diseño Arquitectura del sistema

Implementación
Documentar la tecnología
Pruebas Escogida en un diagrama de
Niveles y capas
Despliegue
 Mapa de los flujos de trabajo que veremos en este curso

Formularios UCs
Crear un modelo de diseño
● “Elicitación” de requisitos Para un caso de uso utilizando
“Análisis Robusto”
● Análisis de requisitos
● Arquitectura Crear un modelo de solución
Integrando el modelo de diseño
● Diseño Y el modelo de arquitectura

● Implementación Refinar el modelo de dominio

Para satisfacer el modelo de
● Pruebas solución
● Despliegue
Aplicar patrones de diseño a los
Modelos de dominio y solución

Identificar y modelar estados

De objetos complejos usando un
Diagrama de estados
 Mapa de los flujos de trabajo que veremos en este curso

● “Elicitación” de requisitos Crear el plan de desarrollo

● Análisis de requisitos
● Arquitectura Arq
Cod
Crear una estructura de paquetes
Para la implementación
● Diseño
● Implementación Implementar la solución de
Software utilizando el modelo de Código
● Pruebas solución
● Despliegue

Plan de Pruebas
Probar la solución de software
Contra los escenarios de
Formularios UCs Casos de uso

Desplegar la solución de software

Utilizando el diagrama de
Despliegue
 Resumen
● El proceso de OOSD inicia con la “elicitación” de
requisitos del sistema y finaliza con el despliegue
del sistema funcional

● Los flujos de trabajo definen las actividades que

transforman los artefactos del proyecto desde el
modelo de requisitos hasta la implementación del
código

● UML soporta la creación de artefactos visuales

que representan vistas de los modelos