Ingenieria de Software Diversión o Tedio

Mer av detta

Modelo de Cascada

av Celvin Usiel Hernández Velasco

M4 DE LA CONTESTACIÓN DE LA DEMANDA: Estudio teórico-práctico de una adecuada defensa

av UNIVERSIDAD SERGIO ARBOLEDA

M5 ¿CÓMO AFRONTAR CON ÉXITO EL PROCEDIMIENTO CONTENCIOSO ADMINISTRATIVO?

av UNIVERSIDAD SERGIO ARBOLEDA

INGENIERIA

av Jyfrel González

Ingeniería de Software, Diversión o Tedio

Climbieng over the "No Silver Bullet" Brick Wall (R. Geoff Dromey) (2006)

“Simples representaciones, son la clave para promover los avances en la Ingeniería de software”

"Una representación adecuada es el único camino."

Escoger la representación.

“Probablemente cometer errores.”

“Pude llegar a cambiar lo que se quiere representar.”

“Afecta la facilidad de entender.”

“Aumenta la dificultad de las tareas.”

“Afecta la complejidad de la aplicación.”

Frederick Brooks

"El software es invisible e invisualizable."

"El software no se puede comparar con los objetos de la vida real" para generar.

"los lenguajes de alto nivel han generado."

Simplicidad.

Confiabilidad.

Productividad.

"La esencia de una entidad de software es la construcción del conceptos interrelacionados."

No Silver Bullet: Essence and Accidents of Software Engineering (F.P. Brooks Jr) (1987)

Accidents (fault)

"Dificultades de producción."

• Alto nivel de los lenguajes • Tiempo Compartido • Entornos de programación • Análisis OO, Diseño, Programación • otros

Essence (failure)

"Dificultades por la naturaleza del Software."

• complejidad • conformidad • variabilidad • invisibilidad

¿Por qué Ingeniería de Software es un trabajo duro?

"No es un Simple Desarrollo." Hay que pensar en muchas partes.

"Las herramientas ayudan a reducir los accidentes."

"Generando nuevos problemas."

"Un accidente podría provocar serios problemas."

SE Is Fun (Robert L. Glass) (2007)

La brecha entre enfoques.

“Un proceso de software orientado para la diversión, es bueno si las tareas son cortas y la motivación por la calidad es el ideal.”

Corta Historia de la programación divertida

"Se introdujo la demostración de formalismos matemáticos."

"Los programadores trabajaban con prototipos."

"Fue una actividad para resolver problemas."

Fase de “mantenimiento.” (0-100)

Esta no se encuentra incluida entre las 6 primeras fases esta es una fase de pos Desarrollo.

La sexta parte es “pruebas.” (33 - 67)

“No ve positiva la comprobación formal.”

La quinta fase es “programación.” (75 -25)

“El desarrollo mejora” ya que Bruce ama programar.

La cuarta Fase del “diseño detallado.” (33-67)

“Solo empeora, más documentos.”

La tercera fase es el la “encargada del Diseño.” (40 - 60)

"Elaboración de una gran cantidad de documentos."

La segunda fase es la de “declaración de requerimientos.” (50- 50)

“El tedio aquí es transcribir y asegurar lo que escribiste haciéndolo correctamente y es conforme con lo prometido por otro lado lo divertido es crear.”

La primera fase del ciclo de desarrollo de Bruce es “Vender el concepto.” (100 - 50)

“El único tedio aquí es cuando se encuentran personas con mente pequeña.”

Offshoring is not silver bullet (Chad Dickerson)(2004)

"Creo que en el extranjero el desarrollo de software con enfoque (offshoring) es simplemente la última bala de plata."

“Si se le suman a las dificultades de desarrollo de Software, las diferencias culturales y horarias; el ambiente comienza a verse desalentador.”

Él cree que "las empresas con el enfoque (offshoring) no ven el desarrollo de software como una de las actividades principales ademas generalmente las especificaciones están en constante cambio."

“La codificación podría siempre ser difícil.”

“En China y en algunas firmas de Software, desarrollan aplicaciones con entregas seguras, de alta calidad y dentro del presupuesto.”

“Alto grado de agilidad en la metodología implementada por el equipo.”

"Es importante un alto grado de directa interacción entre el grupo de desarrollo y los usuarios finales."

“Los proyectos asociados a ventas en el extranjero, podrían ofrecer buenos resultados, si existe un dedicado gerente productivo.”

No Silver Bullet: Software Engineering Reloaded (Steven Fraser - Dennis Mancl) (2008

Martin Fowler

"Hay muchas ideas buenas orientadas a objetos, pero la gran cosa es que realmente nadie las usa correctamente."

"No hay bala de plata."

Ricardo Lopez

"La hipótesis de que la complejidad es la forma en que hemos personificado el miedo, pero miedo a la complejidad es el miedo a la vida."

"las mediciones de productividad no son difíciles."

Dave Thomas

"Generar conocimiento a las personas jóvenes para agilizar desarrollos y generar experiencia."

"Un certificado en lugar de competencias."

Critica a la industria del software por "procesos de certificación."

Aki Namioka

"Optimismo." No todo es tan complicado como lo dicen.

"Hay complejos y simples programas para construir, y no todos requieren balas de plata."

Linda Northrop

"Nosotros no lideramos, administramos."

"Focalizarnos en las necesidades de usuario no solo desarrollar nuevas ideas."

David Parnas

"Defiende las cascadas(waterfall) pero con sus inherentes iteraciones."

"Es un dilema definir la medidas."

"Lo que necesita tiempo de aprendizaje es BALA DE PLOMO Una bala de plata es algo que cualquiera puede utilizar eficazmente con poca formación."

Fred Brooks

"Los retos de la Ingeniería de Software son esenciales o accidentales."

"Elaborar un buen sistema para una aplicación y después generalizarlo."

Steven Fraser

"Tecnología que atacan dificultades accidentales, no resuelven los problemas de vida real."