Fichas de asignaturas 2015-16
![]() |
DISEÑO DE SISTEMAS SOFTWARE |
![]() ![]() ![]() |
|
Asignatura |
![]() |
| |
Profesorado |
![]() |
| |
Competencias |
![]() |
| |
Resultados Aprendizaje |
![]() |
| |
Actividades Formativas |
![]() |
| |
Sistemas de Evaluación |
![]() |
| |
Contenidos |
![]() |
| |
Bibliografía |
![]() |
Código | Nombre | |||
Asignatura | 21714040 | DISEÑO DE SISTEMAS SOFTWARE | Créditos Teóricos | 2.5 |
Título | 21714 | GRADO EN INGENIERÍA INFORMÁTICA | Créditos Prácticos | 5 |
Curso | 3 | Tipo | Obligatoria | |
Créd. ECTS | 6 | |||
Departamento | C137 | INGENIERÍA INFORMÁTICA |
Requisitos previos
El alumno deberá poseer conocimientos básicos de programación e ingeniería de software.
Recomendaciones
Se recomienda tener aprobadas las asignaturas de Ingeniería del Software y de Metodología de la Programación.
Profesorado
Nombre | Apellido 1 | Apellido 2 | C.C.E. | Coordinador | |
Daniel | Molina | Cabrera | Profesor Contratado Doctor | S |
![]() |
Competencias
Se relacionan aquí las competencias de la materia/módulo o título al que pertenece la asignatura, entre las que el profesorado podrá indicar las relacionadas con la asignatura.
Identificador | Competencia | Tipo |
IS01 | Capacidad para desarrollar, mantener y evaluar servicios y sistemas software que satisfagan todos los requisitos del usuario y se comporten de forma fiable y eficiente, sean asequibles de desarrollar y mantener y cumplan normas de calidad, aplicando las teorías, principios, métodos y prácticas de la Ingeniería del Software. | ESPECÍFICA |
IS04 | Capacidad de identificar y analizar problemas y diseñar, desarrollar, implementar, verificar y documentar soluciones software sobre la base de un conocimiento adecuado de las teorías, modelos y técnicas actuales | ESPECÍFICA |
IS06 | Capacidad para diseñar soluciones apropiadas en uno o más dominios de aplicación utilizando métodos de la ingeniería del software que integren aspectos éticos, sociales, legales y económicos | ESPECÍFICA |
Resultados Aprendizaje
Identificador | Resultado |
R2 | Aprendizaje y aplicación de criterios de valoración de un diseño de un sistema software. |
R3 | Conocer y aplicar distintos patrones de diseño. |
R4 | Plantear y discutir distintas alternativas de diseño de un sistema software. |
R1 | Realizar un diseño orientado a objetos de un sistema software a partir de un documento de requisitos. |
R5 | Saber adaptar el diseño de un sistema software antes problemas acontecidos durante su implementación, adaptando de forma adecuada el documento de diseño. |
Actividades formativas
Actividad | Detalle | Horas | Grupo | Competencias a desarrollar |
01. Teoría | Impartición de la parte teórica de los contenidos. |
20 | ||
02. Prácticas, seminarios y problemas | Ejercicios sobre planteamiento y discusión de diseño de sistemas software. |
10 | ||
03. Prácticas de informática | Explicación del diseño de aplicaciones. Seguimiento de las prácticas realizadas. |
30 | ||
10. Actividades formativas no presenciales | Lectura de bibliografía. Realización de las prácticas en grupos. Realización de los ejercicios de diseño planteados. |
85 | Reducido | IS04 |
12. Actividades de evaluación | Defensa de las prácticas realizadas. Realización de examen de evaluación. |
5 | Reducido |
Evaluación
Criterios Generales de Evaluación
- Aplicación adecuada de los principios de diseño vistos en clase. - Coherencia y facilidad de uso en el API diseñado. - Aplicación apropiada de los patrones de diseño. - Adecuada documentación del diseño. - Sincronización del documento de diseño con la implementación. La copia de exámenes o prácticas o cualquier otro tipo de fraude que detecten los profesores de la asignatura será motivo de suspenso en todas las convocatorias del curso académico.
Procedimiento de Evaluación
Tarea/Actividades | Medios, Técnicas e Instrumentos | Evaluador/es | Competencias a evaluar |
Ejercicios de planteamiento de diseño ante distintos posibles sistemas software, a partir de una serie de requisitos. Se planteará el uso de patrones de diseño. |
|
||
Examen final. |
|
||
Parte de diseño de una práctica conjunta con la asignatura de "Implementación e Implantación de Sistemas Software". | Evaluación de que el diseño planteado siga los principios indicados, así como la correcta coordinación entre diseño e implementación. |
|
IS01 IS04 IS06 |
Procedimiento de calificación
En la primera convocatoria el sistema de evaluación por defecto es un sistema de evaluación continua. En el resto de las convocatorias se aplicará el sistema de evaluación final. En el sistema de evaluación continua, hay dos opciones. Por un lado, si todas las prácticas se han realizado de forma correcta, con una calificación final de cada una superior a 7, y no ha habido dudas durante su defensa, su calificación será la final de las prácticas (en donde también se han debido resolver dudas de carácter teórico). En caso contrario, la nota final de la asignatura se calculará mediante la siguiente fórmula: Nota Final = (0.6 * Nota Exámenes) + (0.4 * Nota Actividades Aprendizaje) Por tanto, en el sistema de evaluación continua, la Nota Final se establecerá no sólo considerando un examen final, sino la media de las calificaciones obtenidas en ejercicios/prácticas entregables realizados durante el curso. Dado que existen múltiples elementos de evaluación: ejercicios, prácticas, ... mientras que en evaluación continua el examen será conciso, centrado en aspectos no valorados en el resto de elementos anteriores. En el sistema de evaluación final es únicamente la calificación obtenida en el examen final de la asignatura. La Nota Actividades Aprendizaje se calcula a partir de las calificaciones obtenidas en la práctica realizada durante el cuatrimestre. En el caso de una evaluación final el mismo día del examen se presentará una serie de problemas considerados como Actividades de Aprendizaje. La idea de esas actividades es valorar las competencias que se deberían haber adquirido mediante la realización de las prácticas y ejercicios. Por tanto, se recomienda encarecidamente la realización de la evaluación continua. En evaluación continua, para poder obtener una calificación de Actividades de Aprendizaje es OBLIGATORIO entregar los resultados de los ejercicios y/o prácticas mediante el campus virtual en las fechas indicadas por el profesor y siguiendo las instrucciones de entrega. Los profesores podrán convocar a los alumnos para que defiendan sus prácticas. El objetivo de esta defensa podrá ser para valorar la suficiente participación de cada integrante del grupo en las prácticas, e incluso la defensa ante sospechas de copia o fraude en el material entregado. Se mantendrán la Nota Actividades Aprendizaje obtenida durante el cuatrimestre en todas las convocatorias del curso académico. Para poder aplicar la fórmula de cálculo de la Nota Final de la asignatura es necesario obtener una calificación mínima de 3 puntos (sobre 10 puntos) tanto en la Nota Exámenes como en la Nota Actividades Aprendizaje.
Descripcion de los Contenidos
Contenido | Competencias relacionadas | Resultados de aprendizaje relacionados |
Tema 1. Diseño Software: 1.1- Concepto de Diseño Software 1.2- Proceso de Diseño Orientado a Objeto |
||
Tema 2. Principios de Diseño Orientado a Objeto 2.1- Conceptos y Principios de DOO 2.2- Ejemplos de los principios de diseño |
R2 R4 | |
Tema 3. Implementación y Diseño, retroalimentación y ReIngeniería. |
R5 | |
Tema 4. Patrones de Diseño 4.1- Introducción a los Patrones 4.2- Patrones Estrategia, Decorador y Observador 4.3- Patrones de Creación. 4.4- Patrones de Delegación: Fachada, Adaptador, Command 4.5- Otros Patrones: MVC, Iterador, ... 4.6- Aplicando Patrones |
IS04 | R3 R4 |
Bibliografía
Bibliografía Básica
- Gamma, E., et.al. Patrones de diseño. Addison-Wesley, 2003.
- Larman, C., UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al proceso unificado, 2ª ed., Prentice Hall, 2003.
- Booch, G., Rumbaugh, J., Jacobson, I. El lenguaje unificado de modelado: manual de referencia. Addison-Wesley, 1999.
Bibliografía Específica
- Brett D. McLaughlin, Gary Pollice, Dave West, Head First Object-Oriented Analysis and Design, O'Reilly, 2006.
- Eric Freeman & Elisabeth Freeman. Head First Design Patterns, O'Reilly, 2004.
- Patterns of Software, Tales from the Software Community, Richard P. Gabriel, 1998.
- Buschmann, F.et.al. Pattern-Oriented Software Architecture. A System of Patterns. Wiley & Sons, 1996.
Bibliografía Ampliación
- Refactoring: Improving the Design of Existing Code
by Martin Fowler, Kent Beck, John Brant, William Opdyke and Don Roberts.
- The Pragmatic Programmer: From Journeyman to Master. Andrew Hunt and David Thomas. Addison-Wesley.
- Making Software. What Really Works, and Why We Believe It. A,ndy Oram, Greg Wilson, O'Reilly Media, 2010.
- Beatiful Code, Editors: Andy Oram, Greg Wilson, O'Really Media, 2007.
El presente documento es propiedad de la Universidad de Cádiz y forma parte de su Sistema de Gestión de Calidad Docente. En aplicación de la Ley 3/2007, de 22 de marzo, para la igualdad efectiva de mujeres y hombres, así como la Ley 12/2007, de 26 de noviembre, para la promoción de la igualdad de género en Andalucía, toda alusión a personas o colectivos incluida en este documento estará haciendo referencia al género gramatical neutro, incluyendo por lo tanto la posibilidad de referirse tanto a mujeres como a hombres.