IIC 3143 Desarrollo de Software Presentación Curso Rodrigo Sandoval Profesor Adjunto Asociado DCC - Escuela de Ingeniería rsandova@ing.puc.cl ¿Cuáles son los atributos de un buen producto de software? • Cumple con los Requisitos • Desempeño adecuado • Usabilidad • Robustez • Mantenibilidad • Confiabilidad • Seguridad • Escalabilidad • Integridad Standish Group Chaos Report • • Más que productos, este reporte habla del éxito y fracaso en proyectos de desarrollo de software. Se ve que regularmente, sólo 1 de cada 3 proyectos termina exitosamente. Un ejemplo DE: Germany freezes development of its employment portal eGovernment News – 02 March 2004 – Germany – eServices for citizens On 25 February 2004, the German Federal Labour Office (Arbeitsamt) announced it was freezing its job portal development plans due to skyrocketing costs. Although the original costs were evaluated at EUR 65 million, new estimates indicate the portal would cost EUR 165 million up to 2008. Due to be one of the office's flagship projects, the new employment portal - Arbeitsagentur.de suffered from a number of technical problems since it went online in December 2003. However, its freeze was brought about by a financial scandal, with the new head of the German Federal Labour Office Frank-Jürgen Weise denouncing an out-of-control budget and the public prosecutor investigating corruption suspicions. In this context, Mr Weise decided to fire the head of the Arbeitsagentur.de project. . . . The website, which was developed by Accenture, has been criticized for being slow, instable and failing to deliver requested information. On 27/02/2004, a press release by Accenture denied any corruption in the bidding procedure and stated that the second stage of the project was running according to schedule. . . . The portal was supposed to be further developed in the coming years, with for instance an enhanced matching system to be implemented in May and a Service Centre for job intermediation and consultation to be launched in August 2004. © European Communities 2004 Arbeitsagentur.de - Análisis Problemas: – Preparación • ¿Estimaciones? • ¿Levantamiento adecuado de los requisitos y condiciones/restricciones? – Desarrollo • ¿Control de Calidad? – Errores (estabilidad) – Desempeño ante carga real – No entrega la información requerida – Administración del Proyecto • Dimensionamiento adecuado: plazos de entrega vs. Funcionalidades. • Visibilidad hacia los interesados. Otro Ejemplo • FBI's Virtual Case File (VCF) – Software desarrollado por el Federal Bureau of Investigation (FBI), entre el 2000 y el 2005.. – El proyecto no estaba ni cerca de ser terminado cuando fue abandonado en Enero 2005, habiéndose transformado en un completo fiasco para el FBI. – Además de haber desperdiciado al menos US$100 millones, la falla trajo una amplia y dura crítica dura al Bureau y su director, Robert S. Mueller III. Fuente: Wikipedia http://en.wikipedia.org/wiki/Virtual_Case_File Virtual Case File (FBI) - Análisis Fallas en prácticas de Ingeniería de Software detectadas en este proyecto: • • • • • Falta de planos sólidos desde el comienzo llevaron a decisiones pobres en arquitectura. Cambios reiterados en la especificación. Cambios reiterados en el management, lo que contribuyó a los cambios en especificaciones. Micromanagement de los desarrolladores. La inclusión de mucho personal del FBI que tenía poco o ningún entrenamiento formal en ciencia de la computación, como managers e incluso como ingenieros en el proyecto. • • • • Problemas de alcance a medida que los requisitos eran continuamente agregados al sistema, incluso frente a atrasos en las entregas. Problemas en el código debido al alcance y las especificaciones cambiantes. En un punto se estima que el software tenía sobre 700.000 líneas de código. Adición de más gente y recursos al proyecto a medida que se iba atrasando, lo cual lo hizo atrasarse aún más (Ley de Brooks). Planificación de una liberación muy drástica al final, lo cual hizo muy difícil la adopción del sistema hasta que se fuese perfeccionando. Razones para fallas (en general) • La gestión de requisitos es ad hoc. • La comunicación es ambigua e imprecisa. • Las arquitecturas de sistemas/software son frágiles. • La complejidad es abrumadora. • Hay inconsistencias inadvertidas en requisitos, diseños e implementaciones. • Las pruebas son insuficientes. • La evaluación del estado del proyecto es subjetiva. • Se omite enfrentar los riesgos. • Hay propagación descontrolada de cambios. • La automatización es insuficiente. Diferencia entre Cascada y Ágil • Si bien, la agilidad aporta capacidad de éxito en los proyectos, por sobre el esquema cascada, aún no es suficiente para reducir los proyectos con problemas a cero (49% + 9% tienen algún tipo de problema). Conocimientos de Desarrollo Buenas Prácticas y Aplicación de Enfoques Procesos / Metodologías Patrones de Diseño Plataformas / Tecnologías Estructuras y Algoritmos Lenguajes de Programación Conceptos Básicos de Programación Aspectos Generales Sigla IIC 3143 – Desarrollo de Software Pre-Requisitos IIC 2143 – Ingeniería de Software Créditos 10 Profesor Rodrigo Sandoval U. rsandova@ing.puc.cl / +562 2570 8864 Horario L-W: 1 - Sala B15 Pre-requisitos del Curso • Introducción a la Programación • Programación Avanzada • Ingeniería de Software: – Patrones, UML, Scrum, XP, diseño, análisis. • Algunos posibles lenguajes y plataformas → Web: Front/Back/Full (Ruby, ASP.NET, Python/Django, …) → Mobile: Android (Java), iOS (Swift) otro framework → Bases de Datos: SQL, NoSQL → Inglés, al menos en lectura fluida. → OK, castellano también. Descripción • Este curso se basa en el aprendizaje adquirido en el curso de ingeniería de software, donde se enseña el proceso de producción de un sistema de software completo. • Este curso profundiza en la fase de desarrollo. Para ello enseña marcos de trabajo y métodos, prácticas de análisis, prácticas de desarrollo, prácticas de gestión, medición de resultados y calidad y cómo pasar de la teoría a la práctica. Objetivos 1. Aprender a encontrar requisitos usando las técnicas de análisis de necesidades, análisis de objetivos, y análisis de casos de uso. 2. Conocer formas de organizar y priorizar requisitos. 3. Validar requisitos usando criterios de factibilidad, claridad, no ambigüedad, etc. 4. Representar requisitos funcionales y no funcionales para distintos tipos de sistemas usando técnicas formales e informales. 5. Especificar y medir atributos de calidad. 6. Negociar entre diversos interesados para acordar un conjunto de requisitos. Contenido según Programa 1. Enfoques de Desarrollo y sus Fortalezas – Repaso de Enfoques: UP, XP y Scrum – Profundización en otros: MSF, CMMI → ¿Cómo se aplican en la práctica? 2. Del Análisis a la Especificación – – – Métodos y lenguajes de análisis. Especificación de Software. Aplicación en contextos: riguroso y ágil 3. De la Especificación al Desarrollo. – – – – Gestión del Proyecto. Agilidad (en serio). Prácticas de Desarrollo y Codificación. Herramientas modernas. Contenido – la letra chica • ¿Cómo lograr el salto exitoso de la teoría a la práctica? • ¿Cómo lograr que un enfoque de desarrollo sirva en un proyecto … y más aún, se aplique correctamente en un proyecto? • ¿Qué pasa con un proyecto que ya viene con problemas? • ¿Qué pasa cuando tengo un equipo grande (N > 10) o muy chico (N < 3)? • ¿A quién le importa que se usen las buenas prácticas? • Más importante: ¿qué puede pasar cuando no se aplican? Contenido adicional • • • • • Gestión del factor humano en un proyecto. Gestión pro-activa de riesgos. Rapidez vs. Mantenibilidad. Recuperación de proyectos en problemas. Adaptación de procesos de software a un contexto particular. • Conformación de equipos. • Reconocimiento de los involucrados “riesgosos”. • Ejemplos de casos y proyectos reales. Profesor - Rodrigo Sandoval U. • Ingeniero Civil de Industrias, mención computación, PUC, 1995 • Magíster Ciencias Ingeniería, Enero 1996 – Investigación área inteligencia artificial. – Trabajo en Laboratorio IA y Optimización. • Desde Marzo 1996, profesor del DCC. – Actualmente Profesor Adjunto Asociado. – Premio excelencia docente 2002. www.RodrigoSandoval.net • Experiencia Laboral: – Proyectos software desde 1994. – Empresas: ORDEN (Sonda), Tata (TCS), DICTUC, y Synopsys (2006-2011). – R:Solver desde 2011 • Experiencia Relevante: – Grupo Ingeniería Software en ORDEN. – Arquitecto y gerente proyectos de tecnología en TCS. – Technical Lead en grupo TCAD de Synopsys Inc. – Consultor en adopción de agilidad, Scrum y otros frameworks. → Liderazgo y gestión exitosa de proyectos de misión crítica y gran envergadura para empresa privada, empresas internacionales, y gobierno. Metodología • Clases expositivas, L-W, Mod 1. • Un trabajo grupal: – Grupos de tres (ó cuatro) alumnos (*). – Cuatro entregas durante el semestre. • Un control y dos interrogaciones escritas: – Con computador, trabajo individual. – Duración: hora de clases. • Un examen. (*) Cada grupo deberá trabajar en forma individual y auto-organizarse. Metodología • La presentación es una “guía” de la clase, pero la idea es discutir, analizar, experimentar, descubrir las verdaderas buenas prácticas de desarrollo de software. • La materia formal se puede leer … • … pero algo iremos viendo en las clases de todos modos. Evaluaciones y Consideraciones Nota Final = 0.06*Con + 0.12*Int1 + 0.12*Int2 + 0.2*Ex + 0.08*Proy1 + 0.1*Proy2 + 0.1*Proy3 0.22*Proy4 • Consideraciones adicionales: – La nota de la 4a entrega (Proy4) y final debe ser > 4.5, de lo contrario, se reprueba el ramo. – El promedio de notas de pruebas escritas debe ser ≥ 4,0 – Cualquier inasistencia a interrogaciones se reemplaza automáticamente con el examen, sólo por una vez, sin necesidad de justificativos. – No hay eximición del examen. En caso de inasistencia se debe comunicar al profesor a la brevedad para coordinar evaluación alternativa – sólo en casos de justificación mayor. (Problemas de salud severos o problemas personales de fuerza mayor.) Calendario 2019-1 / Fechas relevantes • • • • • • • • • • • Lun 11/Mar: Inicio de clases Mié 13/Mar: Planteamiento proyectos Mié 20/Mar: Cierre inscripciones de proyecto Mié 3/Abr: Control 1 Mié 10/Abr: Entrega (y presentación) Inception (Proy1) Mié 24/Abr: Entrega (y presentación) Elaboration (Proy2) Mié 8/May: Interrogación 1 – horario clases Mié 15/May: Entrega (y presentación) Const1 (Proy3) Mié 29/May: Interrogación 2 – horario clases Lun 24/Jun: Cierre Proyecto – Entrega MVP Jue 27/Jun: Examen (*) Se les recuerda que las interrogaciones se realizan en la fecha indicada, en horario de clases, por lo que no interferiere con otras evaluaciones en la misma fecha.
