Introducción al Proceso de Desarrollo de Software

Presentación del tema: "Introducción al Proceso de Desarrollo de Software"— Transcripción de la presentación:

1 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

2 Contenidos Motivación Notación Metodología Herramientas Discusión

3 I. Motivación Construcción de una casa para “fido”
Puede hacerlo una sola persona Requiere: Modelado mínimo Proceso simple Herramientas simples Extraida desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).

4 I. Motivación Construcción de un Chalet
Extraida desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software). Construido eficientemente y en un tiempo razonable por un equipo Requiere: Modelado Proceso bien definido Herramientas más sofisticadas

5 I. Motivación Construcción de un Rascacielos
Extraida desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).

6 I. Motivación Claves en el Desarrollo de SI
Notación Figura “Triangle for Success” adaptada desde “Visual Modeling with Rational Rose and UML” de Terry Quatrani Herramientas Metodología

7 II. Notación “El modelado captura las partes esenciales del sistema”
Orden Item envío Proceso de Negocios Sistema Computacional

8 II. Notación Modelado para manejar la Complejidad
“... Hay dos formas de construir software: una es hacerlo tan simple que obviamente no existan deficiencias, otra es hacerlo tan complejo que no existan deficiencias obvias” C:A.R. Hoare, Turing Award Lecture 1980.

9 II. Notación Modelado de la Arquitectura del SW
Interface de Usuario (Visual Basic, Java, ..) Lógica del Negocio (C++, Java, ..) Extreme Programming in the Quick-change Era 'Beware of the religion of the code-generating modeling tool.' by Alexandra Weber Morales About 30 years ago, Barry Boehm theorized that the cost of software change increased exponentially over time; that is, if an error caught in requirements gathering cost $1, an error caught during deployment would cost $1000. "What if," said Robert Martin, a former preacher who now uses his persuasive speaking skills to promote Smalltalk guru Kent Beck's Extreme Programming (XP) methodology, "you took a moment to suspend disbelief and considered that--due to today's technology--the cost of change is essentially flat. When costs don't change over time, up-front speculative work is a liability. Ambiguity and volatility are reasons to delay." In such a world, Martin told a packed room at the UML World conference in New York city on June 14, developers need a process that exploits a flat change/cost curve?and XP is that process. The five-year-old methodology values communication (but not on paper), simplicity, feedback and courage. It's designed for small to medium-sized teams of no more than 12 people who work in a common area, integrate and test their code constantly, pair program on single computers and use whiteboards hung on the periphery to hash out designs. Source code is the preferred archival medium, and cards containing "user stories"(requirements written by customers) and tasks are the "high-density storage mechanism," according to Martin, who runs a training firm called Object Mentor out of Green Oaks, IL. "Where does modeling fit in?" asked an audience member, reminding Martin that his talk, at this point nearly over, had promised to describe the interaction between the UML and XP. "Paper and pencil or whiteboards are the best CASE tools I know of. In Kent's case, he uses CRC cards, not the UML," said Martin. "But whether it's Booch notation or UML, you do the highest-level map you can, but you don't do all your design up front. Remember, in XP it's not an archival resource, it's a communication device. The only archive I want is the code and a few poignant, incisive documents explaining why I made certain decisions." Does this mean that ever more sophisticated modeling tools have no place in XP? Not exactly, said Martin. "If a code-generating tool works for you, use it. After all, that's what a compiler does. But beware of the religion of modeling tools that spit out executable prototypes. Sometimes getting the code from the tool is more time-consuming than writing it yourself." Servidor de BDs (C++ & SQL, ..) “Modelar el sistema independientemente del lenguaje de implementación”

10 II. Notación Modelado para promover la Reutilización
Múltiples Sistemas Componentes Reutilizados

11 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 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 Sistema nuevo o modificado Requisitos nuevos o modificados Proceso de Desarrollo de Software

12 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

13 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

14 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

15 III. Metodología Elementos de un Proceso SW
Actividades Herramientas Personas Proceso SW Roles Artefactos Notación

16 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

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

18

19 V. Discusión ¿Cuál es vuestro contexto? ¿Cuál es vuestra Situación Actual Notación - Metodología - Herramientas?

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