P15

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

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

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

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



www.dsic.upv.es/~letelier/pub

Computer Aided Assisted Automated Software Systems 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 metodo-logías de desarrollo”  www.dsic.upv.es/~letelier/pub

17

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