metodologia

33
INTRODUCCIÒN Hoy día es cada vez mas frecuente la consideración de la Ingeniería del Software como una nueva área de la Ingeniería, y el Ingeniero del Software comienza a ser una profesión implantada en el mundo laboral internacional, con derechos, deberes y responsabilidades que cumplir, junto a una, ya, reconocida consideración social en el mundo empresarial y, por suerte, para esas personas con brillante futuro. La ingeniería del software trata con áreas muy diversas de la Informática y de las Ciencias de la Computación, tales como construcción de compiladores, sistemas operativos o desarrollos de Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a una infinidad de áreas tales como: negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, el mundo del derecho, la red de redes Internet, redes Intranet y Extranet, etc.

description

 

Transcript of metodologia

Page 1: metodologia

INTRODUCCIÒN

Hoy día es cada vez mas frecuente la consideración de la Ingeniería del Software como una nueva área de la Ingeniería, y el Ingeniero del Software comienza a ser una profesión implantada en el mundo laboral internacional, con derechos, deberes y responsabilidades que cumplir, junto a una, ya, reconocida consideración social en el mundo empresarial y, por suerte, para esas personas con brillante futuro.

La ingeniería del software trata con áreas muy diversas de la Informática y de las Ciencias de la Computación, tales como construcción de compiladores, sistemas operativos o desarrollos de Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a una infinidad de áreas tales como: negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, el mundo del derecho, la red de redes Internet, redes Intranet y Extranet, etc.

Page 2: metodologia

LA NECESIDAD DE UNA METODOLOGÌA DE DESARROLLO DE SOFTWARE

Para desarrollar un proyecto de software es necesario establecer un enfoque disciplinado y sistemático. Las metodologías de desarrollo influyen directamente en el proceso de construcción y se elaboran a partir del marco definido por uno o más ciclos de vida.

Según Piattini

“Un conjunto de procedimientos,técnicas, herramientas, y un soporte

documental que ayuda a los desarrolladores a realizar nuevo

software”.

Maddison

Como un conjunto de filosofías, fases, procedimientos, reglas, técnicas,herramientas, documentación y aspectos de formación para los desarrolladores de sistemas de

información.

Page 3: metodologia

La metodología persiguen tres necesidades principales:

Mejores aplicaciones, tendientes a una mejor calidad, aunque a veces no es suficiente.

Un proceso de desarrollo controlado, que asegure uso de recursos apropiados y costo adecuado.

Un proceso estándar en la organización, que no sienta los cambios del personal.

La metodología a veces tienen diferentes objetivos, pero los más representativos pueden ser:

Brindar un método sistemático, de modo de controlar el progreso del desarrollo.

Especificar los requerimientos de un software en forma apropiada. Construir productos bien documentados y de fácil mantenimiento. Ayudar a identificar las necesidades de cambio lo más pronto

posible. Proporcionar un sistema ágil que satisfaga a todas las personas

involucradas.

Page 4: metodologia

CARACTERÌSTICAS DE LA METODOLOGÌA DE DESARROLLO DEL SOFTWARE

Se pueden enumerar una serie de características que debe tener la metodología y que influirán en el entorno de desarrollo:

Reglas predefinidas. Determinación de los pasos del ciclo de vida. Verificaciones en cada etapa. Planificación y control. Comunicación efectiva entre desarrolladores y usuarios. Flexibilidad: aplicación en un amplio espectro de casos. De fácil comprensión. Soporte de herramientas automatizadas. Que permita definir mediciones que indiquen mejoras. Que permita modificaciones. Que soporte reusabilidad del software.

Page 5: metodologia

CICLO DE VIDA DEL SOFTWARE

El desarrollo de software va unido a un ciclo de vida compuesto por una serie de etapas que comprenden todas las actividades, desde el momento en que surge la idea de crear un nuevo producto software, hasta aquel en que el producto deja definitivamente de ser utilizado por el último de sus usuarios.

Page 7: metodologia

Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar). Dado que normalmente se trata de necesidades del cliente para el que se creará la aplicación, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial, siendo que debe ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo comercial).

EXPRESIÓN DE NECESIDADES

Page 8: metodologia

EspecificacionesAhora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar.

Por medio de esta etapa se obtendrá un nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de los casos de uso, use cases, de Jacobson es una muy buena elección para llevar a cabo la especificación del sistema).

Page 9: metodologia

Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, ... que van a dar una descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes:

Funcional.

Estático.

Dinámico.

Análisis

Page 10: metodologia

Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar como va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.).

Diseño

Page 11: metodologia

Lamentablemente en la actualidad, año 2.000, quedan bastantes empresas en las que, tras una reunión comercial en que tan solo se ha conseguido recabar una breve lista de requerimientos, a pesar de tener que enfrentarse a proyectos grandes-medios, se pasa directamente a la etapa de implementación; son proyectos guiados por el riesgo que supone adoptar un modelo de ciclo de vida de codificar-corregir (code and fix) donde se eliminan las fases de especificaciones, análisis y diseño con la consiguiente pérdida de control sobre la gestión del proyecto.

Implementación

Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos.

Observación:

Page 12: metodologia

El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.ej. de rendimiento).

Pruebas

Page 13: metodologia

Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).

Validación

Page 14: metodologia

Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto).

Mantenimiento y evolución

Page 15: metodologia

Modelos de ciclo de vida

Modelo de Cascada

Modelo de Concurrente

Modelo de desarrollo incremental

Modelo V

Modelo de Espiral

Modelo de Prototipos

Modelo de desarrollo evolutivo

Page 16: metodologia

Modelo V

El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones, ya deben haberse creado en la fase de diseño.

Page 17: metodologia

Modelo de desarrollo incrementalEs el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.

El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:

• Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.

• Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.

• Si un error importante es realizado, sólo la última iteración necesita ser descartada.

Page 18: metodologia

Este es el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida. La visión del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase.

Modelo de Cascada

El modelo de ciclo de vida cascada, captura algunos principios básicos:

• Planear un proyecto antes de embarcarse en él.• Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.• Documentar los resultados de cada actividad.• Diseñar un sistema antes de codificarlo.• Testear un sistema después de construirlo.

Una de las contribuciones más importantes del modelo cascada es para los administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.

Page 19: metodologia

Modelo de Desarrollo Evolutivo

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.

Page 20: metodologia

Modelo de EspiralEn este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:Establecer qué tienes terminado.• Determinar qué quieres lograr.• Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.• Seguir la alternativa seleccionada en el paso 2.

Captura algunos principios básicos:

•Decidir qué problema se quiere resolver antes de viajar a resolverlo.

•Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.

•Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.

• No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y conocer (comprender) los niveles de riesgo, que tendrás que tolerar.

El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatibles.

Page 21: metodologia

MODELO DE CONCURRENTE

Provee una meta-descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del proceso de desarrollo de software.

Page 22: metodologia

Modelo de Prototipos

Básicamente prueba error ya que si al usuario no le gusta una parte del prototipo significa que la prueba fallo por lo cual se debe corregir el error que se tenga hasta que el usuario quede satisfecho.Pero eso si al construir el prototipo nos asegura que nuestro software sea de mejor calidad, además de que su interfaz sea de agrado para el usuario. Un prototipo podrá ser construido solo si con el software es posible experimentar.DESVENTAJAS :

El usuario ve que el prototipo funciona piensa que este es el producto terminado y no entienden que recién se va a desarrollar el software.Otro problema es que el prototipo deber ir acompañado de otro modelo pasa su desarrollo.

CLASES DE PROTOTIPOS:

El desechable: Nos sirve para eliminar dudas sobre lo que realmente quiere el cliente además para desarrollar la interfaz que más le convenga al clienteEl revolucionario: Es un modelo parcialmente construido que puede pasar de ser prototipo a ser software pero no tiene una buena documentación y calidad.

Page 23: metodologia

SOFTWARECONCEPTO:

Software se refiere a los programas y datos almacenados en un ordenador. Los programas dan instrucciones para realizar tareas.

FUNCIONES DEL SOFTWARE:

Administrar los recursos de computacionales.

Proporcionar las herramientas para optimizar estos recursos.

Actuar como intermediario entre el usuario y la información almacenada.

Page 24: metodologia

PROGRAMAS DE SOFTWARE

Programa: Conjunto de argumentos o instrucciones para la computadora, almacenado en la memoria primaria de la computadora junto con los datos requeridos para ser ejecutado, en otras palabras hacer que las instrucciones sean realizadas por la computadora.

TIPOS DE SOFTWARE

Software del sistema: Es un conjunto de programas que administran los recursos de la computadora. Ejemplos: Unidad central de proceso, dispositivos de comunicaciones y dispositivos periféricos, el software del sistema administra y controla al acceso del hardware.

Page 25: metodologia

Software de aplicaciones: Programas que son escritos para o por los usuarios para realizar una tarea especifica en la computadora. Ejemplo: software para procesar un texto, para generar una hoja de calculo, el software de aplicación debe estar sobre el software del sistema para poder operar.

Software de usuario final: Es el software que permiten el desarrollo de algunas aplicaciones directamente por los usuarios finales, el software del usuario final con frecuencia tiene que trabajar a través del software de aplicación y finalmente a través del software del sistema.

Page 26: metodologia

FACTORES DE CALIDAD DE SOFTWARE

Page 27: metodologia

INGENIERÌA EN INFORMÀTICA

La ingeniería informática es la rama de la ingeniería que aplica los fundamentos de la ciencia de la computación, la electrónica y la ingeniería de software, para el desarrollo de soluciones integrales de cómputo y comunicaciones, capaces de procesar información de manera automática.

Page 28: metodologia

INGENIERÌA DEL SOFTWARE

CONCEPTO:

La Ingeniería del software es una disciplina o área de la Informática o Ciencias de la Computación, que ofrece métodos y técnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo.

Page 29: metodologia
Page 30: metodologia

PRINCIPIOS DE INGENIERÌA EN LA ETAPA DE DISEÑO

Page 31: metodologia
Page 32: metodologia
Page 33: metodologia

ENLACES

http://www.mitecnologico.com/Main/ConceptoIngenieriaSoftwarehttp://fraba.galeon.com/software.htmhttp://www.inf.utfsm.cl/~visconti/ili236/Documentos/01-IntroISw.pdfhttp://es.wikipedia.org/wiki/Ingenier%C3%ADa_inform%C3%A1ticahttp://laboratorios.fi.uba.ar/lsi/cataldi-tesisdemagistereninformatica.pdfhttp://upsg01.foroactivo.com/t12-tema-1-etapas-del-ciclo-de-desarrollo-del-softwarehttp://franciscovegafranco.blogspot.com/2010/09/ciclo-de-vida-del-software.htmlhttp://es.kioskea.net/contents/genie-logiciel/cycle-de-vie.php3