Transcript Introducción al Proceso de Desarrollo de Software Patricio Letelier Universidad Politécnica de Valencia

Introducción al Proceso
de Desarrollo de Software
Patricio Letelier
Centro de Formación de Postgrado – Depto. Sistemas Informáticos y Computación
Universidad Politécnica de Valencia
Contenidos
Motivación
II. Notación
III. Metodología
IV. Herramientas
V. Discusión
I.
2

www.dsic.upv.es/~letelier/pub
I. Motivación
Construcción de una casa para “fido”
Puede hacerlo una sola persona
Requiere:
Modelado mínimo
Proceso simple
Herramientas simples
3

www.dsic.upv.es/~letelier/pub
I. Motivación
Construcción de un Chalet
Construido eficientemente y en un tiempo
razonable por un equipo
Requiere:
Modelado
Proceso bien definido
Herramientas más sofisticadas
4

www.dsic.upv.es/~letelier/pub
I. Motivación
Construcción de un Rascacielos
5

www.dsic.upv.es/~letelier/pub
I. Motivación
Claves en el Desarrollo de SI
Notación
Herramientas
Metodología
6

www.dsic.upv.es/~letelier/pub
II. Notación
“El modelado captura las
partes esenciales del sistema”
Orden
Item
envío
Proceso de Negocios
Sistema Computacional
7

www.dsic.upv.es/~letelier/pub
II. Notación
Modelado para manejar la Complejidad
8

www.dsic.upv.es/~letelier/pub
II. Notación
Modelado de la Arquitectura del SW
Interface de Usuario
(Visual Basic,
Java, ..)
Lógica del Negocio
(C++, Java, ..)
Servidor de BDs
(C++ & SQL, ..)
“Modelar el sistema independientemente
del lenguaje de implementación”

www.dsic.upv.es/~letelier/pub
9
II. Notación
Modelado para promover la Reutilización
Múltiples Sistemas
Componentes
Reutilizados
10

www.dsic.upv.es/~letelier/pub
III. Metodología
¿Qué es una Metodología?
 En un proyecto de desarrollo de software la
metodología define Quién debe hacer Qué,
Cuándo y Cómo debe hacerlo
Requisitos nuevos
o modificados
Proceso de Desarrollo
de Software
Sistema nuevo
o modificado
 No existe una metodología de software
universal. Las características de cada proyecto
(equipo de desarrollo, recursos, etc.) exigen
que el proceso sea configurable
11

www.dsic.upv.es/~letelier/pub
III. Metodología
Procesos y Metodologías
 La Ingeniería de Software como disciplina
 Algunos modelos de proceso de desarrollo son:
desarrollo en Cascada, usando Prototipos, Basado
en Componentes, en Espiral (Incremental,
Iterativo), Programación Automática. Las
metodologías se basan en alguna combinación de
estos enfoques
 Las metodologías (tanto comerciales como en el
ámbito académico y de investigación) pueden ser
agrupadas en dos grandes corrientes:
Metodologías Estructuradas y Metodologías
Orientadas a Objetos
12

www.dsic.upv.es/~letelier/pub
III. Metodología
Metodologías Estructuradas
 Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación
Estructurada, luego a mediados de los 70’s
aparecieron técnicas para el Diseño primero y luego
para el Análisis. Enfocados a implementaciones
usando lenguajes de 3ra generación
 Ejemplos de metodologías estructuradas
gubernamentales: MERISE (Francia), MÉTRICA 3
(España), SSADM (Reino Unido)
 Ejemplos de métodos estructurados en el ámbito
académico: Gane & Sarson, Ward & Mellor, Yourdon &
DeMarco e Information Engineering
13

www.dsic.upv.es/~letelier/pub
III. Metodología
Metodologías Orientadas a Objetos (OO)
 Su historia va unida a la evolución de los lenguajes de
programación orientada a objeto, los más representativos: a
fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la
primera versión de C++ por Bjarne Stroustrup en 1981 y
actualmente Java o C#. A fines de los 80’s comenzaron a
consolidarse algunos métodos Orientadas a Objeto
 En 1995 aparece el Método Unificado, que posteriormente se
reorienta para dar lugar al Unified Modeling Language
(UML), la notación OO más popular en la actualidad
 Algunos métodos OO con notaciones predecesoras de UML:
OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler &
Mellor y OMT (Rumbaugh)
 Algunas metodologías orientadas a objetos basadas en UML:
Rational Unified Process (RUP), OPEN, MÉTRICA 3
14

www.dsic.upv.es/~letelier/pub
III. Metodología
Elementos de un Proceso SW
Actividades
Herramientas
Personas
Proceso
SW
Roles
Artefactos
Notación
15

www.dsic.upv.es/~letelier/pub
IV. Herramientas CASE
 CASE es un acrónimo para Computer-Aided
Software Engineering, aunque existen algunas
variaciones para lo que actualmente se
entiende por CASE:
C
A
S
E
Computer
Aided
Assisted
Automated
Software
Systems
Engineering
16

www.dsic.upv.es/~letelier/pub
IV. Herramientas CASE
¿Qué es una CASE?
 En “Terminology for Software Engineering and
Computer-aided Software Engineering”, B.Terry &
D.Logee, Software Engineering Notes, Abril 1990,
CASE es definido como:
“Herramientas individuales para ayudar al
desarrollador de software o administrador de
proyecto durante una o más fases del desarrollo de
software (o mantenimiento).”
 En “The CASE Experience”, Carma McClure, BYTE
Abril 1989 p.235 se ofrece la siguiente definición:
“Una combinación de herramientas de software y
metodo-logías de desarrollo”
17

www.dsic.upv.es/~letelier/pub
Proceso
Producción
Subproceso
Tarea de desarrollo apoyada por una herramienta CASE
Representación  Representación de objetos, relaciones o procesos
 Análisis de objetos relaciones o procesos
Análisis



Transformación 




Control


Coordinación
Cooperación
Soporte
Organización
Infraestructura










Automatización de tareas de planificación o diseño
Generación de código/esquema de base de datos
Generación de código procedural
Generación de datos de prueba
Análisis de la estructura del programa
Reestructuración automática del código del programa
Análisis de la estructura de la base de datos
Ayuda al cumplimiento de reglas, políticas o prioridades que gobiernan
las actividades del proceso de desarrollo
Administración de recursos: presupuesto, programación de tareas y
seguimiento
Control de acceso: auditoría, control de configuración y manejo de
autorizaciones
Mensajes y comunicación electrónica
Asociación electrónica de notas a los objetos
Soporte de interacción de grupo
Ayuda en línea para comandos y características
Plantillas para tutoriales o demos
Facilidades de explicación para acciones recomendadas
Uso de conocimiento del dominio para diagnosticar problemas del
usuario y recomendar acciones apropiadas
Estructuras estandarizadas para representar diseños
Consistencia de definición de estructuras de datos
Repositorio del proyecto
Communications of the ACM, Enero 2000, pp.80-88.
18

www.dsic.upv.es/~letelier/pub
V. Discusión
¿Cuál es vuestro contexto?
¿Cuál es vuestra Situación Actual
Notación - Metodología - Herramientas?
19

www.dsic.upv.es/~letelier/pub
Introducción al Proceso
de Desarrollo de Software
Patricio Letelier
Centro de Formación de Postgrado – Depto. Sistemas Informáticos y Computación
Universidad Politécnica de Valencia