metodologia
Descargar como PPTX, PDF0 recomendaciones316 vistas
La ingeniería del software trata con áreas diversas de la informática como sistemas operativos e Internet, abordando todas las fases del ciclo de vida del desarrollo de sistemas de información. Para desarrollar software de manera disciplinada se requiere una metodología que incluya especificaciones, análisis, diseño e implementación, así como pruebas y mantenimiento. El ciclo de vida del software comprende todas las actividades desde la concepción inicial de un producto hasta que deja de usarse.
metodologia
- 1. 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.
- 2. 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 Maddison Como un conjunto de filosofías, fases, “Un conjunto de procedimientos, procedimientos, reglas, técnicas, técnicas, herramientas, y un soporte herramientas, documentación y documental que ayuda a los aspectos de formación para los desarrolladores a realizar nuevo desarrolladores de sistemas de software”. información.
- 3. 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.
- 4. 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.
- 5. 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.
- 7. 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).
- 8. Ahora 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).
- 9. 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.
- 10. 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.).
- 11. 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: 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.
- 12. 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).
- 13. 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).
- 14. 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).
- 16. 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.
- 17. Es 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.
- 18. 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. 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.
- 19. 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.
- 20. En 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.
- 21. 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.
- 22. 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 cliente El revolucionario: Es un modelo parcialmente construido que puede pasar de ser prototipo a ser software pero no tiene una buena documentación y calidad.
- 23. SOFTWARE CONCEPTO: 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.
- 24. 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.
- 25. 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.
- 26. FACTORES DE CALIDAD DE SOFTWARE
- 27. 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.
- 28. 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.
- 30. PRINCIPIOS DE INGENIERÌA EN LA ETAPA DE DISEÑO