Carrera: Licenciatura en Sistemas

Materia: INGENIERIA DE SOFTWARE I

Profesor Titular:

Dr. Ramón García-Martínez

Profesores Adjuntos: Dr. Darío Rodríguez

Mg. Hernán Amatriain Instructores:

Lic. Ezequiel Baldizzoni Lic. Sebastian Martins

Año: 2016 Cuatrimestre: 2º Año – 1º Cuatrimestre

-1-

1- Fundamentación de la Asignatura: La rápida expansión de la Informática ha llevado a la escritura de millones de líneas de código antes de que se empezaran a plantear de manera seria metodologías para la construcción y el diseño de sistemas software, así como métodos para resolver los problemas de mantenimiento, fiabilidad, entre otros. Esta expansión sin control tuvo como consecuencia lógica la llamada crisis del software. Los síntomas que hicieron palpable la aparición de la crisis son los siguientes: Expectativas:

a menudo los sistemas no responden a las expectativas que de ellos tienen los usuarios.

Fiabilidad:

los programas fallan demasiado a menudo.

Costo:

los costos del software son muy difíciles de prever y, a menudo, son muy superiores a lo esperado.

Facilidad de modificación: la modificación de software es una tarea compleja, costosa y propensa a errores. Plazos:

el software se suele entregar tarde y con menos prestaciones de las ofertadas.

Portabilidad:

es difícil cambiar un programa de su entorno hardware. incluso cuando las tareas a realizar son las mismas.

Eficiencia:

los esfuerzos que se hacen para el desarrollo de software no suelen hacer un aprovechamiento óptimo de los recursos accesibles (personas, tiempo, dinero, herramientas, entre otros).

Hoy en día muchos de los sistemas software que se están desarrollando son tan complejos que ninguno de sus gestores individuales lo comprende por completo. En estos casos los procesos tradicionales de desarrollo de software se vienen abajo. Hay estudios que señalan que por cada seis nuevos sistemas software de gran tamaño que entran en servicio, otros dos quedan cancelados. Los proyectos de desarrollo de sistemas de tamaño medio suelen consumir vez y media el tiempo previsto, situación que empeora en los grandes. Y alrededor de tres cuartas partes de todos los sistemas de gran tamaño son fracasos operativos, lo que significa que o no funcionan como se quería o no se utilizan para nada. La construcción de software esta en proceso de adoptar muchas de las características de las ramas de la ingeniería, que están firmemente entroncadas en la ciencia y en las matemáticas. Se ha aprendido bastante sobre cómo medir, cuantitativa y consistentemente, el caos de los procesos de desarrollo de software, la densidad de errores de los productos y el estancamiento de la productividad de los programadores. Los investigadores están empezando ya a dar el paso siguiente, es decir, están -2-

empezando a hallar soluciones prácticas y reproducibles para los problemas de esta naturaleza. La intuición va cediendo paso al análisis y los constructores de software comienzan a utilizar medidas cuantitativas de la calidad de los sistemas que construyen para mejorar la forma en que los producen. Los fundamentos matemáticos de la programación se están consolidando merced a la investigación de métodos para la expresión algebraica de los diseños de sistemas software, lo que ayuda a evitar la comisión de errores graves. La combinación de esfuerzos de las universidades, las empresas y las administraciones públicas orientadas a elevar el desarrollo de software hasta el nivel de una disciplina ingenieril propia de la era industrial se articula en el campo disciplinar llamado Ingeniería del Software. El área de asignaturas de Ingeniería del Software se orienta a proporcionar a los estudiantes esta concepción ingenieril del proceso de construcción de software mediante la formación en: el Modelado de Sistemas de Información (Ingeniería del Software I), el Control y Gestión de Proyectos de Software (Ingeniería del Software II) y la Calidad y Seguridad de Proyectos de Software (Ingeniería del Software III).

2 - Objetivos: - Que los alumnos manejen fluidamente el proceso de construcción de software y los criterios de selección del correspondiente ciclo de vida. - Que los alumnos tengan los elementos conceptuales necesarios para especificar, analizar y diseñar software. - Que el alumno comprenda la importancia de custodiar la calidad y la seguridad en un proyecto de software.

3 - Contenidos: UNIDAD 1: TEORÍA GENERAL DE LOS SISTEMAS Conceptos de Teoría General de Sistemas. Sistema. Entradas. Proceso. Cajas negra y blanca. Salidas relaciones: simbióticas, sinérgica, superflua. Atributos. Contexto. Rango. Subsistemas. Variables. Parámetro. Operadores. Retroalimentación. Homeostasis y entropía. Permeabilidad. Integración e independencia. Centralización y descentralización. Adaptabilidad. Mantenibilidad. Estabilidad. Armonía. Optimización y suboptimización. Jerarquía de los sistemas. Teoría analógica o modelo de isomorfismo sistémico. Modelo procesal o del sistema adaptativo complejo. Las organizaciones como sistemas. Definición de Sistemas de Información. -3-

Bibliografía: Von Bertalanffy, L. 1982. Teoría General de los Sistemas. Editorial Fondo de Cultura Económica. UNIDAD 2: PROCESO Y CICLOS DE VIDA DE SOFTWARE Modelos de Procesos de Software. Modelo lineal secuencial. Modelo de construcción de prototipos. Modelo DRA. Modelos evolutivos. Modelo incremental. Modelo espiral. Modelo espiral WINWIN. Modelo de desarrollo concurrente. Desarrollo basado en componentes. Herramientas y técnicas para modelado de procesos. Mapa de actividades de un proyecto. Definición de un proceso software. Madurez del proceso software. Herramientas para el proceso de software. Bibliografía: Ochoa, A. Fernández, E., Britos, P., García-Martínez, R. 2008. Metodologías de Ingeniería Informática. Editorial Nueva Librería. Pressman, R. 2002. Ingeniería del Software. Un Enfoque Práctico. 5ta Edición. Editorial Mc Graw Hill. Pressman, R. 2004. Software Engineering: A Practitioner's Approach. Editorial Mc Graw Hill. Van Vliet, H. 2008. Software Engineering: Principles and Practice. Editorial John Wiley and Sons. UNIDAD 3: INGENIERIA DE REQUERIMIENTOS DE SOFTWARE El proceso de requerimientos. Tipos de requerimientos. Características de los requerimientos. Notaciones adicionales. Prototipado de requerimientos. Documentación. Participantes en el proceso de especificación de requerimientos. Validación y medición de requerimientos. Selección de técnicas de especificación de requerimientos. Bibliografía: Pfleeger, S. 2002. Ingeniería del Software. 3ra Edición. Editorial Prentice

Hall. Pfleeger, S. y and Atlee, J. 2005. Software Engineering. 3ra Edición.

Editorial Prentice Hall. UNIDAD 4: ANALISIS Y DISEÑO DE SOFTWARE Objetivo del análisis. Modelado conceptual. Técnicas de análisis. Enfoque orientado a procesos, diagrama de flujo de datos: modelo, proceso, -4-

secuencia genérica de las actividades a realizar dentro de las metodologías estructuradas. Enfoque orientado a datos, diagrama entidad/relación: modelo, proceso secuencia genérica de las actividades a realizar dentro de las metodologías de la información. Enfoque orientado a objetos: Diagrama de Actividades, Casos de Uso y Diagramas de Casos de Uso, Diagramas de Clases, Diagrama de Secuencia. Enfoque orientado a estados, diagrama de estados: modelo. Diagrama de estados y statechart: proceso, secuencia genérica de las actividades a realizar dentro de las metodologías de tiempo real. Consideraciones finales. Mezcla de enfoques. Validación. Definición de Diseño. Descomposición y modularidad. Estilos arquitectónicos y estrategias. Problemas en la creación del diseño. Características. Técnicas, evaluación y validación del diseño. Documentación de diseño. Bibliografía: Sommerville, I. 2007. Software Engineering. 8va Edición. Editorial Pearson. Sommerville, I., Alfonso, M., Botia, A. 2005. Ingeniería del Software. Editorial Pearson. UNIDAD 5: CALIDAD DE SOFTWARE Modelos de calidad del software. Estructura de los modelos de calidad. El modelo de McCall. Otras métricas. Estrategias de uso de un modelo de calidad. Pasos para el uso de un modelo de calidad. Actividades de control de calidad del software. Controles estáticos. Controles estáticos manuales informales. Controles estáticos manuales disciplinados. Controles estáticos automáticos. Controles dinámicos. Tipos de pruebas. Métodos de caja negra. Métodos de caja blanca o caja transparente. Metodología de prueba. Actividades de garantía de calidad del software. La documentación. Los factores humanos. El costo de la calidad. Bibliografía: Boehm, B. 1981. Software Engineering Economics. Editorial Prentice Hall. Kan, S. 2002. Metrics and Models in Software Quality Engineering. 2da Edición. Editorial Adison Wesley. UNIDAD 6: SEGURIDAD DE SOFTWARE Conceptos de Privacidad, Integridad y Seguridad en Sistemas de Información. Necesidad de la protección de la información. Vulnerabilidad de los sistemas informáticos, amenazas y ataques. Bienes informáticos a -5-

los que proporcionar seguridad. Amenazas y ataques a los bienes informáticos. Ataques al hardware. Ataques al software. Ataque a los datos. Medidas de seguridad, servicios y mecanismos. Política de seguridad. Análisis de riesgos y planes de contingencia. Identificación y clasificación de riesgos. Pronóstico y evaluación de las consecuencias. Criptografía en la seguridad de la información. Componentes de un criptosistema. Medidas y técnicas de seguridad. Bibliografía: Sommerville, I. 2007. Software Engineering. 8va Edición. Editorial Pearson. Sommerville, I., Alfonso, M., Botia, A. 2005. Ingeniería del Software. Editorial Pearson. 4 - Metodología de Enseñanza: El equipo docente centra el proceso de enseñanza en la utilización de guias de estudio. El uso de este metodo se fundamenta en la concepcion que el alumno se apropia de conceptos con alto grado de abstracción a través de un proceso con tres instancias diferenciadas: [i] Lectura dirigida del material provisto por la cátedra mediante la utilización de guías de estudio y video tutoriales. En esta instancia el estudiante tiene un primer acercamiento a los conceptos y da comienzo la apropiación de los mismos. [ii] Discusión con pares. En esta instancia, el trabajo de resolución de las guías de estudio en el ámbito de grupos de trabajo permite que el estudiante discuta con pares la validez de sus apropiaciones conceptuales, y genere las primeras ratificaciones o rectificaciones de estas apropiaciones. Este proceso de ajuste (ratificación/rectificación) permite al estudiante identificar conceptos cuyo intento de apropiación basada en los saberes logrados hasta ese momento, esta fuera de su alcance. Esta situación motiva el proceso de consulta al docente. [iii]Discusión de la resolución de guía de estudio. En esta instancia, el docente revisa con el estudiante los aprendizajes realizados y mediante discusión mayeutica induce los ajustes en las apropiaciones del estudiante. Para la gestión de entrega de trabajos prácticos por parte de los estudiantes se utiliza un aula del Campus Virtual.

-6-

5- Desarrollo de Actividades Prácticas: Se desarrollarán distintas guías de estudio y trabajos prácticos. http://sistemas.unla.edu.ar/sistemas/sls/ls-2-Ingenieria-de-Software-I/ls-2-Ingenieria-deSoftware-I.htm 

Guía de Estudio 1: Ciclo de Vida. Material “Ciclo de Vida de Software, Proceso Software y Plan de Actividades". Apunte de Cátedra.



Guía de Estudio 2: Ingeniería de Requisitos. Material: Capitulos “Especificación de requisitos" y "Recopilación de Información: Métodos Interactivos". K. Kendall y J. Kendall. 2005. Analisis y Diseño de Sistemas. (6ta Edicion) Pearson -Prentice Hall"



Guía de Estudio 3: Diseño Estructurado. Material “Diseño Estructurado". Apunte de Cátedra.



Guía de Estudio 4: Diseño Orientado a Objetos. Material Capítulo "Análisis y Diseño de Sistemas Orientado a Objetos Usando el Lenguaje Unificado de Modelación". K. Kendall y J. Kendall. 2005. Analisis y Diseño de Sistemas. (6ta Edición) Pearson - Prentice Hall.



Guía de Estudio 5: Gestión de Calidad. Material “Gestión de Calidad". Apunte de Cátedra.



Guia de Trabajos Ptracticos: Ciclo de Vida, diagramas de Flujo de Datos, diagramas de Entidad Relación, diseño de Sistemas OO

El objetivo de las mismas es afianzar y aplicar los conocimientos adquiridos en las clases teóricas. Cada Guía de Estudio y los Trabajos Prácticos (GTP) estarán conformados por una serie de preguntas y ejercicios que deberán desarrollar. 6 - Evaluación y Acreditación: Durante el desarrollo del curso, la valoración de manejo de conceptos, aplicación de conocimientos y dominio de técnicas se realiza mediante evaluaciones parciales. Estan previstos dos exámenes parciales: a mitad de curso y al finalizar el curso. Cada examen parcial comprenderá los temas del programa vinculados a las guías de estudio desarrolladas en el período evaluado. En el diseño de los parciales se utilizarán las siguientes técnicas de evalución: preguntas de eleccion multiple (multiple-choice), -7-

sentencias con determinación verdadero/falso y ejercicios de asociación de conceptos. Se prevén instancias de recuperación de parciales en acuerdo a las regulaciones vigentes de la Universidad Nacional de Lanús y en fechas a acordar con los estudiantes que deban repetir la evaluación. En estas instancias el diseño estará basado en preguntas de desarrollo basadas en las que se formularan en las guías de estudio. La evaluación de los trabajos practicos es por presentación en tiempo y forma (plazos y formatos establecidos), método de resolución (aplicación del método descripto en la guia de estudio correspondiente) y corrección del resultados (exposicion y coloquio con el equipo docente). 7- Normas de la Asignatura Ingeniería de Software 1 (para conocimiento de los estudiantes) Estas normas quedan sujetas a las reglamentaciones existentes y/o futuras de la Universidad Nacional de Lanús, las que tendrán prelación en caso de contradicciones. 7.1. Forma de Trabajo a) Dado el carácter teórico-práctico de la asignatura, es imprescindible el presentismo de estudiantes, el cumplimiento de entrega de los trabajos prácticos en las fechas establecidas, la presentación a evaluaciones conceptuales (evaluación continua), y exámenes parciales en las fechas acordadas por el equipo docente y estudiantes. b) Las guías de estudio y los trabajos prácticos que se realizan a lo largo de la asignatura están diseñados para lograr la apropiación de conceptos interdependientes y de complejidad creciente por parte del estudiante. Deben desarrollarse en un orden determinado, en el cual cada guía de estudio constituye la base para poder resolver las siguientes guías y trabajos prácticos. c) Los objetivos de los trabajos prácticos son: capacitar al estudiante en la aplicación práctica de los conocimientos trabajados en las guías de estudio, consolidando su destreza profesional y permitiendo al equipo docente verificar lo que el estudiante va aprendiendo, en calidad, cantidad y oportunidad. d) El estudiante debe complementar obligatoriamente el estudio de los temas con la bibliografía indicada para cada uno de ellos. e) En el marco del concepto de Aula Taller, los estudiantes integran grupos de trabajos prácticos (GTP), cuya cantidad de integrantes es definida por el equipo docente del curso. Los GTP son de libre formación, pero una vez constituidos y registrados como tales, no podrán ser modificados. Si sobre la marcha algún grupo pierde parte de sus integrantes, se considerará cada caso en particular. La formación de los grupos se concretará en las primeras dos semanas de clase. f) Cada estudiante debe tener la Guía de Trabajos Prácticos propuesta por el equipo docente para el año académico. El equipo docente decide que ejercicios son de resolución obligatoria en preparación a los exámenes parciales y cuál será la fecha de entrega de los mismos. -8-

g) Los ejercicios de resolución no obligatoria, son para que los estudiantes dispongan de material de ejercitación complementaria. Estos pueden ser realizados libremente por los estudiantes y entregados al equipo docente para su corrección. h) Al final de cuatrimestre y como condición necesaria (no suficiente) para obtener la cursada de la asignatura, cada estudiante deberá entregar una carpeta con todos los ejercicios obligatorios resueltos. i) En la fecha de examen final en la que el estudiante se presente a rendir la asignatura deberá traer una carpeta con todos los ejercicios resueltos (obligatorios y no obligatorios). 7.2 Presentación de los Trabajos Prácticos a) Cada trabajo práctico llevará una carátula según modelo provisto por equipo docente. b) Cada trabajo se resolverá en el formato de hoja según el modelo provisto por equipo docente. Se utilizará papel formato A4. Cada hoja tendrá los siguientes márgenes para perforar y encarpetar: izquierdo 2.5 cm restantes 2.0 cm c) Se recomienda para escribir los informes de TP el uso de procesador de texto d) Microsoft Word y para graficar la herramienta de modelado Microsoft Visio. e) No se aceptarán trabajos prácticos que no cumplan con las normas de la asignatura. 7.3 Aprobación de los Trabajos Prácticos a) El estudiante debe acreditar el porcentaje de asistencia a clase en acuerdo a las normas de la Universidad. Los trabajos son de carácter grupal y deben ser aprobados dentro de las fechas establecidas por el equipo docente, las que son previamente comunicadas. Una vez vencida la fecha, el trabajo práctico ya no podrá ser presentado para su aprobación. b) Cada estudiante debe tener, en forma individual, una carpeta con los trabajos prácticos desarrollados. En cada hoja debe figurar el nombre y apellido del estudiante. c) La no presentación de la carpeta de trabajos prácticos, implica considerar los trabajos prácticos como entregados fuera de término y no se considerarán para su evaluación. d) Antes de finalizar la cursada el equipo docente establecerá la fecha para la entrega de la carpeta impresa que deberá hacer cada estudiante. Los GTP deberán hacer una entrega en formato digital (preferentemente en CD). En el formato digital, se deben cumplir las siguientes reglas: d.1) Solo debe haber un archivo por trabajo práctico, en formato Microsoft Word (preferentemente 2007), cumpliendo con todos los requerimientos del apartado 7.2. No se pueden incluir archivos anexos. d.2) Se deben organizar los archivos por carpetas, según cada tipo de trabajo practico, como por ejemplo: TP1; TP2; TP3,... -9-

d.3) Los nombres de los archivos deben seguir el siguiente patrón: TP + numero del TP + titulo. Por ejemplo: “TP-1-Robot Asesino.doc”

7.4 Aprobación de la Cursada y de la Asignatura a) Para obtener la cursada de la asignatura el estudiante deberá cumplir: [i] aprobar el 80% de los trabajos prácticos obligatorios, [ii] aprobar las evaluaciones conceptuales periódicas que el equipo docente establezca, y [iii] aprobar los exámenes parciales. b) Para aprobar la materia el estudiante debe rendir un Examen final en las fechas establecidas en el calendario académico de la Universidad.

8. Pagina Web de la Asignatura y Canal Youtube de ingeniería de Software: http://sistemas.unla.edu.ar/sistemas/sls/ls-2-Ingenieria-de-Software-I/ls-2-Ingenieria-deSoftware-I.htm

https://www.youtube.com/channel/UCXvcDN6Cqf5qPenBGVXJOPg

- 10 -