Subido por Sebastián Álvarez Velásquez

IIC3143-00-Presentación

Anuncio
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.
Descargar
Fichas aleatorios
test cards set

10 Tarjetas Антон piter

tarjeta del programa pfizer norvasc

0 Tarjetas joseyepezsumino

tarjeta del programa pfizer norvasc

0 Tarjetas joseyepezsumino

notas de enfermeria

0 Tarjetas Karen LCHB

free fire garena

1 Tarjetas Rene Jonathan Ramos Reyes

Crear fichas