Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Encuentra los documentos específicos para los exámenes de tu universidad
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
Asignatura: Metodologia del software, Profesor: Tona Mozota, Carrera: Enginyeria tècnica en informàtica de sistemes, Universidad: URL
Tipo: Apuntes
1 / 24
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
El contenido de este documento es sólo una tabla de contenidos con la relación de imágenes y direcciones de internet vistas o recomendadas en el curso. Se recomienda estudiar los temas directamente de las fuentes citadas en la bibiografía.
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
principal: interacción con el hardware
Software de Inteligencia Artificial. Algoritmo para la resolución de problemas complejos
[Sommerville6ed] 1.1.2 , pág. 6
Definición
Es una disciplina de la ingeniería que comprende todos los aspetos de la producción de software desde las etapas de la especificación del sistema hasta el mantenimiento posterior.
Disciplina de la ingeniería : Los ingenieros hacen que las cosas funcionen, aplicando teorías, métodos y herramientas a conveniencia. También tienen en cuenta restricciones financieras y organizacionales.
Todos los aspectos de la producción de software : No sólo se trata de procesos técnicos sino también se trata de actividades como gestionar proyectos, desarrollar herramientas, métodos y teorías de apoyo a la producción del software.
Los roles de los actores implicados en el software
Hay dos grupos de agentes implicados: ¾ Clientes y usuarios Cliente : Quien paga el proyecto de software Usuario : Quien finalmente usará el software creado ¾ Equipo de desarrollo Jefe de proyectos : Gestiona los recursos asignados a los proyectos, elige tecnológías y arquitecturas. Es quien suele hacer la primera reunión con el cliente. Analista : Recoge e interpreta los requerimientos, analiza el problema ( analista ) Diseñador: Diseña las soluciones ( diseñador ). A veces hay especialista en diseño de IU. Programador : Implementa (programa) los diseños siguiendo las directrices de los analistas Probador : Se encarga de verificar que el producto generado cumpla con las especificaciones recogidas. Documentador
Ingeniería del software vs Informática. El papel del ingeniero
La ciencia de la computación se refiere a las teorías y métodos subyacentes a las computadoras y los sistemas de software. Mientras que la ingeniería de software se refiere a los problemas prácticos de producir software.
Objetivos de la Ingeniería del Software [Sommerville6ed] 1.1.10 pág. 12
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
[Pressman] 1.2.1 pág. 34)
9 Calidad (producto que cumple objetivos) Mantenibilidad : Han de poder hacerse cambios según las necesidades del cliente , el entorno de los negocios actuales es cambiante. Confiabilidad : Fiable y seguro. No deben causar pérdidas económicas sus fallos Eficiencia : No malgastar recursos del sistema (memoria, procesador, ...) Usabilidad : Debe ser usable sin esfuerzos , interfaz adecuada y adecuada documentación 9 Bajo coste 9 A tiempo
Algunos datos: Del año 99 de IBM y otras fuentes: en el 55% de los proyectos es + del coste esperado en el 68% de los proyectos es + del tiempo esperado
Un proceso del software es un conjunto de actividades y resultados asociados que producen un producto de software.
Estas actividades, a muy grandes rasgos, se repiten de diferente forma en la práctica totalidad de los procesos. Se aplicarán con diferente émfasis y profundidad, orientadas a diferentes perspectivas y repetidas un diferente número de veces ... pero básicamente encontraremos siempre las mismas actividades:
[ODorcherty] cap 5
Requerimientos
Requirements capture is about discovering what we’re going to achieve with our new piece of software and has two aspects. Business modeling involves understanding the context in which our software will operate – if we don’t understand the context, we have little chance of producing something to enhance that context. The sort of question we ask during the business modeling phase is ‘How does a customer purchase a television from this shop?’
System requirements modeling (or functional specification ) means deciding what capabilities the new software will have and writing down those capabilities. We need to be clear about what our software will do and what it won’t do, so that the development doesn’t veer
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
To understand why, consider buying a new house and spending vast amounts of time and money refurbishing it from top to bottom. It’s unlikely that you would want to whack the structures and fixtures with a sledgehammer to see if they’re durable, ask passing strangers whether they think that you have good taste or pretend to be a burglar to see if you can break in. These are exactly the kinds of things that we need to be doing during software testing. (It helps if members of the test team have a cruel streak.)
Despliegue
In the deployment phase, we’re concerned with getting the hardware and software to the end users, along with manuals and training materials. This may be a complex process, involving a gradual, planned transition from the old way of working to the new. The sort of task we carry out during the deployment phase is ‘Run the program setup.exe on each server machine fand follow the instructions that appear’.
Mantenimiento
When our system is deployed, it has only just been born. A long life stretches before it, during which it has to stand up to everyday use – this is where the real testing happens. The sort of problem we discover during the maintenance phase is ‘When the log-on window opens, it still contains the last password entered.’
As software developers, we’re normally interested in maintenance because of the faults (bugs) that are found in our software. We must find the faults and remove them as quickly as possible, rolling out fixed versions of the software to keep the end users happy. As well as faults, our users may discover deficiencies (things that the system should do but doesn’t) and extra requirements (things that would improve the system). From the business point of view, we would hope to .x and improve our software over time to maintain competitive advantage.
Otras actividades (fuera del alcance de la asignatura) 9 Seguimiento y control del proyecto : permite que se evalúe el proceso comparándolo con el plan original 9 Gestión del riesgo : evalúa los riesgos que pudieran afectar los resultados del proyecto o la calidad del mismo. Riesgos de proyecto (incremento de costes, personal,...), riesgos técnicos, riesgos del negocio (de gestión, de presupuesto, de estrategia, ...) 9 Aseguramiento de la calidad del sofware 9 Gestión de la configuración : control de versiones, ... 9 ...
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
Modelo de procesos (ciclo de vida) de software : Es una descripción de un proceso del software que se presenta desde una perspectiva particular. Son simplificaciones, abstracciones de un proceso real. Incluyen actividades que son parte de los procesos y productos del software y el papel de la gente involucrada en la ingeniería del software. Se trata de algo teórico, abstracto.
No trataremos una clasificación exhaustiva de los modelos pues existen diferentes criterios para clasificarlos.
Cascada o “ Waterfall ” , publicado por primera vez por Winston Royce el 1970. Es el modelo de ciclo de vida clásico.
Motivación
Fue de los primeros en aparecer: Primera necesidad = disponer de un modelo Nace a partir del modelo secuencial lineal del desarrollo de hardware Hacía falta un modelo simple que fuera comprendido por los clientes, que presentara una visión muy clara de cómo se va a suceder la secuencia de actividades
Características
Separar el proceso en unas etapas básicas claramente definidas, cada una de las cuales debe completarse antes de comenzar la siguiente.
Etapas:
1 Comunicación Inicio del proyecto Recopilación de requisitos qué datos se manejarán, cuál es la función que el software desempeñará, cuáles son las interficies requeridas y qué rendimiento se espera obtener
Estos requisitos deben de documentarse y deben ser revisados por el cliente.
2 Planificación Estimación Itinerario Seguimiento
3 Modelado Análisis Diseño
Se traducen los requerimientos en una representación del software de manera que se pueda conocer la arquitectura, la funcionalidad y la calidad del mismo antes de comenzar la
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
Se trata de desarrollar el software de forma que algunas de las actividades típicas se repitan en sucesivas iteraciones. Cada una de estas iteraciones tiene un producto resultante que cada vez más se acerca al producto requerido por el cliente.
Esto además permite obtener resultados antes del final del proceso.
[Sommerville7ªEd.] 4.2.2 pág. 68
Modelo en espiral , propuesto por Boehm en 1988.
Motivación
Toma en consideración explícitamente el riesgo (a diferencia de los otros modelos). Esta es una actividad importante en la administración del proyecto. El estudio de la gestión de riesgos está fuera del alcance de esta asignatura.
Características
El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Cada ciclo de la espiral representa una fase del proceso del software.
Fuente: [Sommerville 7ªEd.]
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.
Cada ciclo de la espiral se divide en cuatro sectores:
Ventajas 9 Incluye el análisis de riesgos durante todo el proceso 9 Útil para proyectos grandes. 9 Permite usar el prototipado en todas las etapas de la evolución para reducir el riesgo. 9 El cliente “ve” evolucionar el proyecto 9 Mantiene el enfoque sistemático de los pasos sugeridos por el lineal secuencial, pero lo incorpora dentro de un marco iterativo más real. 9 El mantenimiento se trata al mismo nivel que el desarrollo (en una espiral mas)
Inconvenientes
9 Difícil de convencer a los clientes de que es controlable. 9 Requiere mucha habilidad para el análisis de riesgos y de esta habilidad depende su éxito. 9 No ha sido utilizado tanto como el lineal secuencial (cascada) o el de prototipos.
[Sommerville6ed], 3.2. [Pressman5ed], 2.7.1 , pág. 23
Modelo incrementa l, formulado por primera vez por Mills el 1980.
Motivación
El modelo en cascada requiere el conocimiento completo de los requerimientos. Si se producen cambios durante el desarrollo hay que rehacer la captura de requerimientos, el diseño y la implementación. El cliente no tiene una idea de cómo será el sistema hasta que no esté acabado.
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
Desventajas 9 Los incrementos no pueden ser demasiado grandes (no més de 20.000 líneas de código) 9 Cada nuevo incremento debe ser integrado sin afectar a los previos 9 Diseño y desarrollo paralelos de los diferente módulos deben de ser coherentes entre sí 9 Proyecto poco controlable, por falta de visión como un todo 9 No hay especificación completa hasta el final y hay proyectos (gobierno) cuyas especificaciones deben de estar completamente en el contrato inicial
Una de las metodologías que actualmente está más de moda es “ Extreme Programming ” (Beck,
[Pressman 6Ed] 3.4.1 pág. 83
[Bennet] 3.2.2 pág. 54
Motivación
El cliente puede tener una definición general del sistema pero no identificar todos los requisitos detalladamente. La construcción de prototipos se usa para la definición y refinamiento de requisitos.
En las aplicaciones que requieren mucha interacción con el usuario, la construcción de prototipos puede ayudar a que el cliente se haga una idea del sistema final ayudando a detectar deficiencias o errores en la especificación.
En las aplicaciones que requieren el uso de tecnologías o algoritmos o herramientas nuevas para el equipo, la construcción de prototipos ayuda a la formación del equipo, a la prueba de la eficiencia de los algoritmos, etc.
Características
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
fuente: ….
Recolectar junto al cliente los requisitos Se hace un diseño rápido. El diseño se focaliza en lo que “ve” el cliente (normalmente interfaz y salidas) Se construye/desarrolla rápido el prototipo Uso de herramientas especializadas Uso de fragmentos(componentes) ya existentes Uso de generadores de informes, gestores de ventanas (cualquier Visual …) Es evaluado por el cliente/usuario. El feedback se usa para refinar los requerimientos y construir un nuevo prototipo y así sucesivamente hasta que los requisitos quedan totalmente especificados Se desarrolla el producto final
El prototipo obtenido puede ser usado como “the first system” pero no necesariamente. De hecho podría haberse construido con una herramienta (lenguaje) diferente a la que se usará para el desarrollo real. Los prototipos construidos pueden ser: descartables o evolutivos/reaprovechables.
Descartable:
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
Fuente: www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc
Metodología ( [Bennet] y otros ) = una estrategia para el desarrollo de software (por ejemplo, la orientación a objetos)
un modelo de proceso (por ejemplo espiral incremental)
un conjunto de técnicas y notaciones (por ejemplo UML)
guías para la gestión/dirección del proyecto
políticas y procedimientos para garantizar la calidad del software
un conjunto de métricas
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
herramientas
…….
Metodologías basadas en desarrollo estructurado
Análisis y diseño estructurado, programación estructurada, uso de diagramas de flujo orientado a funcionalidades
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 (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta generación.
Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE (Francia), MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco e Information Engineering.
Metodologías basadas en orientación a objetos
Análisis y diseño orientado a objetos, programación OO, modelo de objetos, modelo dinámico, modelo funcional
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# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, 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 son: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh).
Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified Process (RUP), OPEN, MÉTRICA (que también soporta la notación estructurada), …
Metodologías ágiles [Sommerville 7ªEd] 17.1 p
Basadas en los principios definidos por el Manifiesto of Agil Software Development (http://agileManifiesto.org) en 2001
El descontento con los enfoques “pesados” condujo en los años 90 a proponer nuevas metodologías
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
Por ejemplo, Andersen Consulting (ahora Accenture) usa METHOD-
El RUP es un refinamiento detallado del proceso unificado definido por Jacobson, Booch y Rumbaugh (los tres amigos) en 1999. Proviene por lo tanto de:
o OMT o Booch o OOSE
Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la investigación. En 1995 Rational Software compró una compañia sueca llamada Objectory AB, fundada por Ivar Jacobson (OOSE), famoso por haber incorporado los casos de uso a los métodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory (el proceso de la empresa Objectory AB). El primer resultado de esta fusión fue el Rational Objectory Process, la primera versión de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten.
Características principales:
9 Modelo iterativo e incremental
9 Uso de tecnologías de objetos Análisis y diseño orientado a objetos Programación orientada a objetos
9 Dirigido por casos de uso
9 Centrado en la arquitectura
9 Soporta al estándar del OMG: UML (Lenguaje Unificado de Modelado)
Los elementos del RUP son:
Actividades , Son los procesos que se llegan a determinar en cada iteración.
Trabajadores , Vienen a ser las personas o entes involucrados en cada proceso.
Artefactos , Un artefacto puede ser un documento, un modelo, o un elemento de modelo.
Una particularidad de esta metodología es que, en cada ciclo de iteración, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologías más importantes para alcanzar un grado de certificación en el desarrollo del software.
Capítulo: 1 LA INGENIERÍA DEL SOFTWARE
[Sommerville 7ed] (pag 79 a 83) [Sommerville 6ed] (pag 63 a 69)
La tecnología CASE (Computer-aided Software Engineering/Ingeniería del Software asistida por Ordenador) proporciona ayuda al proceso del software automatizando algunas de sus actividades, así como porporcionando información acerca del software en desarrollo.
Algunos ejemplos de la actividades que pueden automatizarse son:
Clasificación funcional
Fuente: [Sommerville 7ªEd.]
