Material-Teoría |
 |
 |
Planificación docente Teórico/Práctica de Fundamentos de Ingeniería del SW. Material necesario  |
|||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
 |
Tema 1.- Introducción a la Ingeniería del Software. Material necesario |
|||||||||||||||||||||||||||||
| Abstract/Resumen: | ||||||||||||||||||||||||||||||
Con Fundamentos de Ingeniería del Software (FIS) se pretende introducir al alumno en los conceptos fundamentales de la ingeniería del software, prestando más atención al paradigma estructurado, mostrando la necesidad de establecer un método disciplinado de desarrollo de software, que se dirija a solucionar los problemas inherentes a la producción del mismo, como por ejemplo: ¿Por qué muchas veces no somos capaces de entregar el software que el cliente requiere, dentro de los plazos y presupuestos establecidos? ¿Por qué es tan difícil cuantificar el tiempo y recursos que va a necesitar un desarrollo de software? ¿Por qué tantos proyectos de desarrollo fracasan? ¿Por qué se dedican tantos recursos a mantenimiento? . |
||||||||||||||||||||||||||||||
 |
MÉTRICA. Versión 3. |
|||||||||||||||||||||||||||||
 |
Tema 2.- Análisis Estructurado. Material necesario Catálogo General de Requisitos Catálogo General de Requisitos  |
|||||||||||||||||||||||||||||
| Abstract/Resumen: | ||||||||||||||||||||||||||||||
Se pretente proporcionar una visión general de los procedimientos, herramientas, tareas y resultados del análisis esturcturado, el cual tiene como objetivo la obtención de una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base
para el posterior diseño del sistema. A pesar de que el elemento central del tema es el análisis estructurado se completa como una somera introducción a los procesos de Planificación y Estudio de Viabilidad, en este marco el Estudio
de Viabilidad del Sistema nos propociona un conjunto concreto de necesidades para proponer una solución a corto
plazo, que tenga en cuenta restricciones económicas, técnicas, legales y operativas y la Planificación de futuro sistema nos permitirá la obtención de un marco de referencia para el desarrollo de
sistemas de información que responda a los objetivos estratégicos de la organización |
||||||||||||||||||||||||||||||
 |
Tema 3.- Prototipado. Material necesario |
|||||||||||||||||||||||||||||
| Abstract/Resumen: | ||||||||||||||||||||||||||||||
En el desarrollo de un Sistema de Información la visión lógica de los requerimientos/requisitos del software presenta las funciones que ha de resolver y la información que ha de procesarse independientemente de los detalles de implementación, mientras que la visión física de los requerimientos del software presenta una manifestación del mundo real de dichas funciones y las estructuras de información. Como herramienta de trabajo en algunos casos se desarrolla una representación física como el primer paso del diseño del software, es decir un modelo o maqueta (PROTOTIPO) del sistema que se pretende construir para comprender mejor el problema y sus posibles soluciones. En este ámbito y relacionado con el tema 6 "El Proceso Software. Paradigmas del Ciclo de Vida", nos encontramos con el Modelo de construcción de prototipos, paradigma de construcción de prototipos con tres pasos: (1) Escuchar al cliente. Recolección de requisitos. Se encuentran y definen los objetivos globales, se identifican los requisitos conocidos. (2) Construir y revisar la maqueta (prototipo). y (3) El cliente prueba la maqueta (prototipo) y lo utiliza para refinar los requisitos del software. Este modelo es útil cuando el cliente no identifica los requisitos detallados y el responsable del desarrollo no está seguro de la eficiencia de un algoritmo, sistema operativo o de la interface hombre-máquina. |
||||||||||||||||||||||||||||||
 |
Tema 4.- Diseño Estructurado. Material necesario Ejercicios |
|||||||||||||||||||||||||||||
| Abstract/Resumen: | ||||||||||||||||||||||||||||||
El objetivo del proceso de Diseño Del Sistema de Información es la definición de la arquitectura del sistema y del entorno tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información. A partir de dicha información, se generan todas las especificaciones de construcción relativas al propio sistema, así como la descripción técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial, éstos últimos cuando proceda. En el diseño estructurado orientado al flujo de datos, partimos de la representación del flujo de la información obtenida en la fase de análisis, donde la información puede representarse como un flujo continuo que sufre una serie de transformaciones conforme va de la entrada a la salida. El diagrama de flujo de datos DFD se utiliza como herramienta gráfica para la descripción del flujo de la información. El objetivo principal del diseño es desarrollar una estructura de programa modular y representar las relaciones de control entre los módulos. Mezcla la estructura de programas y la estructura de datos y define las relaciones que facilitan el flujo de los datos a lo largo del programa. |
||||||||||||||||||||||||||||||
 |
Tema 5.- Prueba Software. Material necesario Ejercicios/Ejemplos |
|||||||||||||||||||||||||||||
| Abstract/Resumen: | ||||||||||||||||||||||||||||||
Las pruebas Sw han tomado importancia al ser reconocidas como parte del ciclo de desarrollo de un producto de Software, actualmente no hay una sola empresa interesada en calidad que se dedique al desarrollo de software que no haya implementado alguna metodología y/o tenga un equipo dedicado a verificar la calidad de sus productos. Siendo este un campo relativamente nuevo es también generador de muchos empleos, teniendo como objetivo establecer las bases sólidas en técnicas y herramientas a emplear dando elementos para que el alumno ponga a prueba y sea capaz de identificar las áreas vulnerables de cualquier programa de software. Al término de la materia, el alumno será capaz de generar un plan completo de pruebas y ejecutarlo para determinar si un desarrollo cumple con el objetivo para el que fue diseñado y es aceptable el nivel de calidad, además de dar sus recomendaciones para mejora. Establecerá un nuevo concepto de calidad que le permita cuestionar inclusive los programas que el mismo genera. |
||||||||||||||||||||||||||||||
 |
Ejercicios ADPSw. | |||||||||||||||||||||||||||||
 |
Tema 6.- El Proceso Software. Paradigmas del Ciclo de Vida. Material necesario |
|||||||||||||||||||||||||||||
| Abstract/Resumen: | ||||||||||||||||||||||||||||||
El proceso SW es uno de los campos de la Ingeniería del Software que está teniendo más desarrollo en los últimos años. Esta materia aporta nuevas y más potentes maneras de abordar la complejidad del desarrollo y mantenimiento del software mediante la integración y automatización de los aspectos de gestión con los aspectos puramente ingenierles. Podemos definirlo como un conjunto coherente de políticas,
estructuras organizacionales, tecnologías,
procedimientos y artefactos que son
necesarios para concebir, desarrollar,
instalar y mantener un producto software. |
||||||||||||||||||||||||||||||
 |
Tema 7.- Métodos de desarrollo SW. Material necesario |
|||||||||||||||||||||||||||||
| Abstract/Resumen: | ||||||||||||||||||||||||||||||
Una metodología de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información. A lo largo del tiempo, una gran cantidad de métodos han sido desarrollado diferenciandose por su fortaleza y debilidad. El framework para metodológía de desarrollo de software consisten en: Una filosofía de desarrollo de software con el enfoque del proceso de desarrollo de software y Herramientas, modelos y métodos para asistir al proceso de desarrollo de software. |
||||||||||||||||||||||||||||||
 |
Tema 8.- Elementos básicos en la planificación y gestión de proyectos. Material necesario |
|||||||||||||||||||||||||||||
| Abstract/Resumen: | ||||||||||||||||||||||||||||||
Los gestores de proyectos informáticos juegan un papel cada vez más crítico en el éxito
de las organizaciones actuales. Su conocimiento de las Tecnologías de la Información y
las prácticas de gestión pueden determinar si una organización triunfa o fracasa en sus
negocios. Los mercados de hoy en día requieren que los productos se desarrollen o fabriquen en ciclos cada vez más cortos y que obedezcan a unos límites de recursos y costes, se dirijan a las necesidades específicas de los clientes, y sean de alta calidad. Los directores de proyectos que traten con estos objetivos desafiantes (y a menudo conflictivos) deben ser muy hábiles en la planificación, coordinación y dirección de los esfuerzos asociados a los proyectos informáticos. Deben conocer aproximaciones alternativas que puedan ser utilizadas, y saber cuando y como adaptar las mejores practicas para ajustarse al proyecto concreto. Han de aprovechar las experiencias anteriores de sus organizaciones cuando diseñen sus planes. Deben saber como establecer métricas, con objeto de monitorizar el progreso del proyecto y revisar la calidad de sus productos. El gestor de proyectos del futuro debe ser también un líder de equipo en un escenario multidisciplinar. Por ello ejecutar un proyecto informático eficazmente es, evidentemente, una de las mayores preocupaciones de todo responsable informático. Misión difícil en la medida que cada proyecto relaciona numerosos actores con intereses diversos y variados, dentro de un contexto tecnológico cada vez más sofisticado. La mejor manera de aproximarse a la gestión y planificación de proyectos informáticos es plantearse algunas preguntas, tales como: ¿Que es un proyecto informático? ¿Cómo encaja el proyecto informático dentro de la estrategia de la empresa? ¿Cómo podemos organizar y planificar un proyecto informático? ¿Cómo podemos estimar los costes en un proyecto informático? ¿Cómo podemos hacer el seguimiento a un proyecto informático? ¿Cómo debemos de organizar los equipos de proyectos? ¿Cómo podemos garantizar la calidad en los proyectos informáticos? |
||||||||||||||||||||||||||||||
 |
Tema 9.- Mantenimiento del SW. Material necesario |
|||||||||||||||||||||||||||||
| Abstract/Resumen: | ||||||||||||||||||||||||||||||
La calidad en el desarrollo y mantenimiento del software se ha convertido hoy en día en uno de los principales objetivos estratégicos de las organizaciones, debido a que cada vez más, los procesos principales de las organizaciones (y su supervivencia) dependen de los sistemas informáticos para su buen funcionamiento. |
||||||||||||||||||||||||||||||
 |
Tema 10.- Reutilización del SW. Material necesario |
|||||||||||||||||||||||||||||
| Abstract/Resumen: | ||||||||||||||||||||||||||||||
El concepto de reutilización software no es una idea nueva en el mundo de la
informática. Los primero programadores ya copiaban y pegaban líneas de código realizadas en
desarrollos anteriores. De hecho la reutilización es cualquier procedimiento que produce o
ayuda a producir un sistema mediante el nuevo uso de algún elemento procedente de un
esfuerzo de desarrollo anterior (Freeman, 1987). En un proyecto software intervienen una gran
cantidad de procesos. La norma IEEE 12207 divide estos procesos en principales, de soporte,
de organización y de adaptación. Estos a su vez se dividen en otros subprocesos. Por tanto, en
el ciclo de vida del software son muchos los elementos susceptibles de ser reutilizados (Moore,
1997). En este marco tan extenso, este tema en mostrar que la reutilización no debe verse como una mera copia de código ya desarrollado sino
cualquier producto sw. obtenido en el ciclo de vida del software, con independencia de su nivel de abstracción. |
||||||||||||||||||||||||||||||
 |
Tema 11.- Métrica versión 3.
|
|||||||||||||||||||||||||||||
Material-Práctica |
|
|
Práctica 0: Seminario de System Architect 2001. |
|
Práctica 1: Caso de estudio – ATSCarm "Adjudicación Telemática de Secundaria” |
| Enunciado de la Práctica Catálogo General de Requisitos Catálogo General de Requisitos Ejemplo de CGR (2007/2008)  Anexos de la Práctica: ATSCarm |
|
|
Descarga de las herramienta y documentos: Descarga de "System Architect 2001 demo": Documentación de SA2001:
|