Está en la página 1de 20

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
Notación
Metodología
Herramientas
Discusión

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

Herramient Metodolog
as ía

6
 www.dsic.upv.es/~letelier/pub
II. Notación

“El modelado captura las


partes esenciales del
sistema”
Orde
n

I
tem

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” 9
 www.dsic.upv.es/~letelier/pub
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 Sistema
nuevos nuevo
Proceso de
o Desarrollo o
modificados modificad
de Software o
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 desarrollar-se


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

Activ
idad
es
Herr
Pers amie
onas ntas

Proc
eso
SW
Artef Nota
Role acto ción
s s

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 Computer
A Aided
Assisted
Automated
S Software
Systems

E
www.dsic.upv.es/~letelier/pub
Engineering 16
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 17


metodo-logías de desarrollo”
 www.dsic.upv.es/~letelier/pub
Proceso Subproceso Tarea de desarrollo apoyada por una herramienta CASE
Representación • Representación de objetos, relaciones o procesos
Análisis • Análisis de objetos relaciones o procesos
• Automatización de tareas de planificación o diseño
• Generación de código/esquema de base de datos
Producción • Generación de código procedural
Transformación • 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
Control • Administración de recursos: presupuesto, programación de tareas y
seguimiento
Coordinación • Control de acceso: auditoría, control de configuración y manejo de
autorizaciones
• Mensajes y comunicación electrónica
Cooperación • 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
Soporte • Facilidades de explicación para acciones recomendadas
• Uso de conocimiento del dominio para diagnosticar problemas del
Organización usuario y recomendar acciones apropiadas
• Estructuras estandarizadas para representar diseños
Infraestructura • 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