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

I. Motivación
II. Notación
III. Metodología
IV. Herramientas
V. 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

onstruido eficientemente y en un tiempo


azonable por un equipo
equiere:
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” 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 nuevos Sistema nuevo


o modificados Proceso de Desarrollo o modificado
de Software

 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

Actividades

Personas Herramientas

Proceso
SW

Artefactos Notación
Roles

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 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


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