acerca de la ingeniería de softwareacerca de la ingeniería...

32
Acerca de la Ingeniería de Software Acerca de la Ingeniería de Software, el subdesarrollo, y otras cuestiones IX Jornada de Gerencia de Proyectos Marzo 24, 2011 Bogotá Colombia Bogotá, Colombia Jorge Aramburo Siegert CEO, PSL

Upload: others

Post on 12-Mar-2020

4 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería de Software, el subdesarrollo, y otras cuestiones

IX Jornada de Gerencia de ProyectosMarzo 24, 2011

Bogotá ColombiaBogotá, Colombia

Jorge Aramburo SiegertCEO, PSL

Page 2: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

Precaución!Precaución!

Esta presentación contiene opiniones

Page 3: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

Propósito de la presentación

La presentación tiene cuatro propósitos fundamentales:

Reflexionar un poco sobre lo que está aconteciendo Reflexionar un poco sobre lo que está aconteciendo con la “Ingeniería de software” en el mundo.Explorar brevemente algunas prácticas de la ingeniería en Latinoaméricaen Latinoamérica.Sembrar algunas inquietudes acerca del papel que debería jugar Latinoamérica en la evolución que se está dando en la profesiónestá dando en la profesión.No aburrirlos (la presentación es muy corta).

Page 4: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

ContextoLos siguientes son algunos de los logros de PSL Solo se Los siguientes son algunos de los logros de PSL. Solo se presentan para darle contexto a las reflexiones que planteamos.

Primera y única latinoamericana en alcanzar el nivel 5 en CMM (2002)Octava en el mundo en lograr el nivel 5 de CMMI (2003).Primera compañía de TI en la región en certificarse en ISO 9001 hace mas de once años.Certificada en ISO 27001 (seguridad de la información).Ganadora del IEEE / SEI Software Process Achievement AwardGanadora el premio a la excelencia en software 2010 otorgado por el SEI.Ad t t t d CMMI f S i ITIL SCMAdoptante temprano de CMMI for Services, ITIL y eSCM.

Page 5: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

La historia sin fin …

1945 – 1965 Codifique y arregle. Codifique mas y arregle mas.

1965 – 1985 La “crisis del software”1965 1985 La crisis del software .

1969 En la Conferencia de la OTAN en Alemania se acoge el término “Ingeniería de Software”.g g

1970 “Managing the development of largesoftware systems” por Winston Royce, dióorigen al modelo en cascada.origen al modelo en cascada.

1986 Los japoneses Hirotaka Takeuchi e IkujiroNonaka describen una nueva forma de organizar y gestionar grupos para desarrollo organizar y gestionar grupos para desarrollo de nuevos productos (SCRUM).

Page 6: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

La historia sin fin …

1989 “Managing the software Process” por Watts Humphrey. Se convirtió en el fundamento de CMM y su posterior evolución, CMMI.

1990’s UP, RUP. Se comenzaron a gestar XP, SCRUM aplicado al desarrollo de software, Lean y otras.

2001 El manifiesto ágil.

2009 – 2010 SEMAT: Volvamos a pensar en esto.

¿Sabemos realmente que es Ingeniería d S ft ? de Software?

Page 7: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

Los dos extremosA raíz del indudable éxito y utilidad de las aproximaciones Á il l úl i h l d di ió Ágiles, en los últimos años se ha planteado una discusión entre …

• Ceremoniosas • Ágiles • Pesadas • Prescriptivas• Predictivas

C lt d

• Livianas, • Adaptativas • Centradas en grupos

ltidi i li i • Con una cultura de comando y control

• Responsabilidad solo del grupo de ingeniería

multidisciplinarios y multifuncionales

• Responsabilidad colectiva de todos lo miembrosdel grupo de ingeniería

• Guiadas por planeación tradicional

de todos lo miembros

Con buena comprensión del papel del ser humano en el Poco abordan el papel del ser humano en el

éxito de los proyectosPoco abordan el

componente humano

Page 8: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

¿Y … por qué la ceremonia?Las aproximaciones tradicionales, ceremoniosas, pesadas,

El SEI (Software Engineering Institute), el modelo CMM y muchos Lead Assessor

Las aproximaciones tradicionales, ceremoniosas, pesadas, han encontrado fundamento, entre otras cosas, en…

muchos Lead AssessorCMM fue desarrollado para cumplir las exigencias del DoDde los EE.UU., en proyectos a precio fijo, de alta complejidad, altísimo riesgo, para desarrollar el p j , g , pcomponente de software de sistemas mayores (misiles, equipos médicos, aeronaves, etc.). Los lead assessor fueron educados para proceder de

d l d l d i d d l acuerdo con el modelo, es decir, de acuerdo con las exigencias de DoD. Las prácticas sugeridas se convirtieron en obligatorias y las áreas de proceso en procesos. El SEI permitió la expansión de CMM / CMMI El SEI permitió la expansión de CMM / CMMI incorrectamente aplicados.

Page 9: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

Las aproximaciones tradicionales, ceremoniosas, pesadas,

¿Y … por qué la ceremonia?Las aproximaciones tradicionales, ceremoniosas, pesadas, han encontrado fundamento, entre otras cosas, en…

El SEI (Software Engineering Institute), el modelo CMM y muchos Lead Assessor muchos Lead Assessor

El SEI no le prestó verdadera atención a las aproximaciones ágiles hasta fines del 2008. Solo la versión 1 3 liberada hace unos días (Octubre 29 / 2010) versión 1.3, liberada hace unos días (Octubre 29 / 2010), incorpora esas aproximaciones en todo el modelo.

El modelo en cascada (incorrecta interpretación del documento de Royce).

Los proyectos a precio fijo, y las compras utilizando solo RFP y procesos ceremoniales impersonales.y procesos ceremoniales impersonales.

Mala práctica profesional de compradores y vendedores.

Page 10: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

Las aproximaciones tradicionales, ceremoniosas, pesadas,

¿Y … por qué la ceremonia?Las aproximaciones tradicionales, ceremoniosas, pesadas, han encontrado fundamento, entre otras cosas, en…

El SEI (Software Engineering Institute), el modelo CMM y muchos Lead Assessormuchos Lead Assessor

El SEI no le prestó verdadera atención a las aproximaciones ágiles hasta fines del 2008. Solo la versión 1 3 liberada hace unos días (Octubre 29 / 2010)

El precio fijo obliga la utilización de modelos pesados con mucha versión 1.3, liberada hace unos días (Octubre 29 / 2010),

incorpora esas aproximaciones en todo el modelo.

El modelo en cascada (incorrecta interpretación del

modelos pesados, con mucha documentación y lentos. Cuando resultan bien, pocas veces, el cliente obtiene el sistema que contrató, pero no el que realmente necesita

documento de Royce).

Los proyectos a precio fijo, y las compras utilizando solo RFP y procesos ceremoniales impersonales.

realmente necesita

y procesos ceremoniales impersonales.

Mala práctica profesional de compradores y vendedores.

Page 11: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

¿Y … por qué la ceremonia?Las aproximaciones tradicionales, ceremoniosas, pesadas,

El proyecto es estratégico para la compañía [XXXX]….

• Las preguntas deben enviarse por escrito…Las aproximaciones tradicionales, ceremoniosas, pesadas, han encontrado fundamento, entre otras cosas, en…

El SEI (Software Engineering Institute), el modelo CMM y muchos Lead Assessor

Las preguntas deben enviarse por escrito…• No se aceptan reuniones con los proponentes….• Por favor enviar las hojas de vida de quien desarrollará el

proyecto en caso de ser seleccionado….• Al momento no se tienen requerimientos en detalle, el muchos Lead Assessor

El SEI no le prestó verdadera atención a las aproximaciones ágiles hasta fines del 2008. Solo la versión 1 3 liberada hace unos días (Octubre 29 / 2010)

Al momento no se tienen requerimientos en detalle, el proveedor debe levantarlos…

• Enviar cronograma detallado y el costo total….• Si el proyecto toma menos tiempo se pagará menos, si toma mas

se pagará lo ofertado…versión 1.3, liberada hace unos días (Octubre 29 / 2010), incorpora esas aproximaciones en todo el modelo.

El modelo en cascada (incorrecta interpretación del

se pagará lo ofertado…• Anexar procesos de desarrollo, administración de la

configuración, pruebas, entrenamiento, etc., etc.

Y si… hay proponentes ... y muchos problemas.documento de Royce).

Los proyectos a precio fijo, y las compras utilizando solo RFP y procesos ceremoniales impersonales.

Y si… hay proponentes ... y muchos problemas.

y procesos ceremoniales impersonales.

Mala práctica profesional de compradores y vendedores.

Page 12: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

Las aproximaciones tradicionales, ceremoniosas, pesadas,

¿Y … por qué la ceremonia?Las aproximaciones tradicionales, ceremoniosas, pesadas, han encontrado fundamento, entre otras cosas, en…

La utilización de CMM/CMMi, ISO, etc., como estrategia de mercadeo no como un vehículo de mejoramiento mercadeo, no como un vehículo de mejoramiento

La mala aplicación del cuerpo de conocimientos del PMI

La incorrecta aplicación de ISO 9001 ITIL etcLa incorrecta aplicación de ISO 9001, ITIL, etc.

Consultoría inadecuada, corrupción, desconfianza

Falta de reflexión Las personas / organizaciones “compran” Falta de reflexión. Las personas / organizaciones “compran” lo que mejor se mercadea

Ingenuidad con buenas intenciones, sobre todo de organizaciones gremiales.

Poca comprensión de las aproximaciones ágiles

Page 13: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

Las aproximaciones tradicionales, ceremoniosas, pesadas,

¿Y … por qué la ceremonia?Las aproximaciones tradicionales, ceremoniosas, pesadas, han encontrado fundamento, entre otras cosas, en…

La utilización de CMM/CMMi, ISO, etc., como estrategia de mercadeo no como un vehículo de mejoramiento

• Tome el curso de [ITIL, CMMI, PMI, PSP, TSP, etc.] y le garantizamos la certificación!

• No se quede atrás de sus competidores, certifíquese en [YYY]• ¿Ha perdido información valiosa? El modelo / estándar [XXXX] mercadeo, no como un vehículo de mejoramiento

La mala aplicación del cuerpo de conocimientos del PMI

La incorrecta aplicación de ISO 9001

¿ p [ ]tiene la solución perfecta para su compañía!

• [Nombre del gremio] está desarrollando la metodología para el [nombre del país]. Así lograremos ser mas competitivos!

• Asista a la IX Jornada y …. (estas conferencias son informativas, La incorrecta aplicación de ISO 9001

Consultoría inadecuada, corrupción, desconfianza

Falta de reflexión Las personas / organizaciones “compran”

y ( ,no formativas. Reflexione y estudie sobre lo que le interesa. Sirven también para hacer relaciones).

Falta de reflexión. Las personas / organizaciones “compran” lo que mejor se mercadea

Ingenuidad con buenas intenciones, sobre todo de organizaciones gremiales.

Poca comprensión de las aproximaciones ágiles

Page 14: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

Trabaje con los modelos no para ellos

¿Entonces…?Trabaje con los modelos, no para ellos

El objetivo es el mejoramiento para crear el software que requiere el mundo y las organizaciones!

“T d í h id h i i í d f P “Todavía creo que hace sentido hacer ingeniería de software. Pero eso no es exactamente lo que ingeniería de software ha llegado a significar. El término abarca un conjunto específico de disciplinas

incluyendo procesos definidos, inspecciones y walkthroughs, i i í d i i i d bilid d é iingeniería de requerimientos, matrices de trazabilidad, métricas,

control de calidad preciso, planeación y control rigurosos y codificación y documentación estándar.

El d ll d ft i á d l … El desarrollo de software es y siempre será de alguna manera experimental. La construcción en si del software no, pero su

concepción si. Y aquí es donde nuestro foco debe estar”.

Tom DeMarcoIEEE, Agosto 2009

Page 15: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

¿Entonces…?SEMAT (Software Engineering Method and Theory)

Software engineering is gravely hampered today by immature practices. Specific problems include:

SEMAT (Software Engineering Method and Theory)

The prevalence of fads more typical of fashion industry than of an engineering discipline. The lack of a sound widely accepted theoretical basis. The lack of a sound, widely accepted theoretical basis. The huge number of methods and method variants, with differences little understood and artificially magnified. The lack of credible experimental evaluation and pvalidation. The split between industry practice and academic research.

Page 16: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

SEMAT (Software Engineering Method and Theory)

¿Entonces…?SEMAT (Software Engineering Method and Theory)

We support a process to refound software engineering based on a solid theory, proven principles and best practices that:

Include a kernel of widely-agreed elements, extensible for specific uses

y, p p p p

Addresses both technology and people issues Are supported by industry, academia, researchers and users Support extension in the face of changing requirements and t h ltechnology.

No sabemos que sucederá, pero la iniciativa es una muestra á d l d l d l i i í d más de lo poco maduro que es el campo de la ingeniería de

software

Page 17: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

Independientemente de la aproximación al desarrollo que

Hemos aprendidop p q

utilice, sus valoraciones, certificaciones, experiencia y poder económico, la primera condición para el éxito reside en las personas, los propósitos, valores y cultura de su organizaciónsu organización

“El paradigma las “Personas sobre los procesos” es muy importante hasta que usted cae en cuenta que su grupo importante, hasta que usted cae en cuenta que su grupo

consiste de dos trolls, un loro, una peluquera y un relativamente brillante gerente de proyecto que ocurre que

es ciego, sordo y mudo…. Ninguna cantidad de coachingd h d ll d t it ” puede hacer que ese grupo desarrolle un producto exitoso”

Jurgen AppeloManagement 3.0

Page 18: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

Todos sabemos que un mal cliente es tan perjudicial para

Hemos aprendidoTodos sabemos que un mal cliente es tan perjudicial para un proyecto como un mal grupo de ingeniería. Infortunadamente a los clientes no se les puede pedir hoja de vida (en Suramérica), y raramente se les puede cuestionar porque “el cliente siempre tiene la razón (lo cuestionar porque el cliente siempre tiene la razón (lo cual no es cierto)”.

Las compañías y los grupos internos de TI, deben estar preparados para manejar clientes conflictivos irrazonables y preparados para manejar clientes conflictivos, irrazonables y mal preparados.Es necesario aprender a decir “no”, a tiempo. No haga proyectos que sabe van a ser un problema!.p y q pAsegúrese de llegar a acuerdos razonables antes de aceptar un proyecto. Si el contrato es muy complicado y detallado, tenga cuidado. Seguramente ese cliente ha tenido malas experiencias y se fue para el otro extremo.

Page 19: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

CMMi es muy útil, si es correctamente implementado

Hemos aprendidoy , p

Es metodológicamente agnóstico.Reconoce, por fin, las aproximaciones ágiles, y les da un gran despliegue en la última versión La versión 1 3 tendrá gran despliegue en la última versión. La versión 1.3 tendrá un gran impacto pues obligará a cambiar de óptica a muchos lead assessors, e impulsará la adopción de aproximaciones ágiles en el mundo entero.Provee un contexto organizacional para el mejoramiento, lo que no ocurre con las aproximaciones al desarrollo, las cuales solo se centran, con excepción tal vez de Scrum, en el ciclo de vida del softwareel ciclo de vida del software.Provee muy buenas guías en áreas de proceso no abordadas por las aproximaciones metodológicas. Contiene mejores prácticas para proyectos riesgosos Contiene mejores prácticas para proyectos riesgosos, grandes, no colocados.

Page 20: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

A juicio del autor, la aproximación en cascada no es i d d ll f Si i ili l

Hemos aprendidoapropiada para desarrollar software. Si tiene que utilizarla conozca bien sus riesgos para administrarlos!

Requerimientos Deadline

Requerimientos

Análisis y diseño

Codificación yCodificación y prueba unitaria

Integración

Tiempo

Operación y mantenimiento

El software debe desarrollarse de manera iterativa e El software debe desarrollarse de manera iterativa e incremental, en iteraciones cortas.

Page 21: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

A juicio del autor, la planeación tradicional no funciona bi l d ll d f

Hemos aprendidobien para el desarrollo de software

Si va a utilizar diagramas de Gantt, hágalo solo para comunicar. Si está tratando de controlar un proyecto con ellos, está en problemas.

Page 22: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

A juicio del autor, la planeación tradicional no funciona bi l d ll d f (l l i!)

Si definitivamente tiene que utilizar la planeación

Hemos aprendidobien para el desarrollo de software (los planes si!). tradicional, utilice la teoría de restricciones (TOC) para

manejar el proyecto y el cronograma.

La ley de Parkinson existe. El síndrome del estudiante también!

Si va a utilizar diagramas de Gantt, hágalo solo para comunicar. Si está tratando de controlar un proyecto con ellos, está en problemas.

Page 23: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

A juicio del autor, la especialización de roles, como la d h dí d j di i l l

Hemos aprendidoentendemos hoy en día, puede ser muy perjudicial para el apropiado desarrollo de un proyecto

Crea dependencias y obliga al desarrollo en cascadap y gCrea rutas y cadenas críticas (TOC). Al contrario, deben tratar de eliminarse.Elimina el sentido colectivo que debe tener todo qemprendimiento

Cuando sea posible, elimine la restricción impuesta por ciertos roles especializados ciertos roles especializados.

Los desarrolladores hacen testing automáticoLos desarrolladores capturan requerimientosL i d llLos arquitectos desarrollanEl cliente hace requerimientos y especifica pruebas

Page 24: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

A juicio del autor, la metodología tradicional de pruebas i d

Hemos aprendidono es apropiada

Prueba de aceptación(Cliente)

Requerimientos y caso de negocios

Las pruebas deben ser automáticas, d ll d

Prueba de Sistema(G. Pruebas)

Prueba final y liberación

(G. Pruebas)

Especificaciones del sistema

Caso de negocios (vida real)

desarrolladas con TDD. Pruebas manuales, solo las estrictamente

R i ió d ódi

Prueba de integración

(G. Pruebas)

Di ñ d l

Diseño del sistema

necesarias.

Es impresionante ver el efecto que en toda

Prueba Individual(Desarrollador)

Revisión de código(Compañeros)

Diseño del componente

Diseño del componente y del

sistema

el efecto que en toda una industria han tenido tan pocas líneas de código

Construcción del componente

g(xUNIT, FIT, etc.)

Page 25: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

A juicio del autor, la metodología tradicional de pruebas i dI l i l ñí d di d l

Hemos aprendidono es apropiada

Prueba de aceptación(Cliente)

Requerimientos y caso de negocios

Las pruebas deben ser automáticas, d ll d

Inclusive las compañías dedicadas solo a testing experimentan grandes cambios. En las aproximaciones modernas, el testing inicia el ciclo de desarrollo (TDD). No se h d t d i i t b

Prueba de Sistema(G. Pruebas)

Prueba final y liberación

(G. Pruebas)

Especificaciones del sistema

Caso de negocios (vida real)

desarrolladas con TDD. Pruebas manuales, solo las estrictamente

hacen documentos de requerimientos sobre los cuales elaborar scripts y casos de prueba. Las pruebas automáticas son gran parte de la documentación de los requerimientos y son hechas por

R i ió d ódi

Prueba de integración

(G. Pruebas)

Di ñ d l

Diseño del sistema

necesarias.

Es impresionante ver el efecto que en toda

requerimientos, y son hechas por desarrolladores e, inclusive, el mismo usuario final.

Prueba Individual(Desarrollador)

Revisión de código(Compañeros)

Diseño del componente

Diseño del componente y del

sistema

el efecto que en toda una industria han tenido tan pocas líneas de código

Construcción del componente

g(xUNIT, FIT, etc.)

Page 26: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

A juicio del autor, los proyectos en entidades públicas y en ñí i d i i l

Hemos aprendidocompañías privadas muy ceremoniosas, impersonales y que buscan predictibilidad, seguirán siendo un fracaso

En el software no funciona una cultura de comando y controlLa participación del cliente es tan importante como la del grupo de ingeniería. No puede por lo tanto desentenderse del problema. Es co – rresponsable.L l jid d i h l bl l d La complejidad es inherente al problema, no al grupo de ingeniería.La creación de software no fue, no es y no será prescriptiva ni predictiva Las licitaciones públicas y los RFP privados de ni predictiva. Las licitaciones públicas y los RFP privados de naturaleza similar, son absurdos.

“Quiero ser ágil… ¿cuando me entrega el cronograma?”“Quiero ser ágil pero no tenemos tiempo para dedicar al

proyecto. Eso es problema suyo”

Page 27: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

A juicio del autor, no se puede hacer buen software con i di id li b ill

Hemos aprendidopersonas individualistas, por brillantes que sean

En todo emprendimiento exitoso existe una cultura colectiva colectiva. El grupo, no el gerente, puede decidir que no desean trabajar con algún miembro del equipo, incluido el gerente (Scrum Master, Coach, etc.).( , , )Todos ganan o todos pierden. Propiedad colectiva del código.Si tiene métricas (ojalá las tenga), debe también medir y premiar el desempeño colectivo.Nunca deje a un desadaptado en un grupo de desarrollo. Nunca!Quien siempre se defiende de sus errores y no los acepta, es

l i di id li i d d d generalmente individualista y sin deseos de aprender.

Page 28: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

A juicio del autor, el lenguaje es extremadamente i i i d f

Hemos aprendidoimportante para un ingeniero de software

Permite construir y articular conceptos, propósitos y visionesvisiones.Permite comunicar y motivar.Permite la creación de colectivos.

Los propósitos, principios y valores de un grupo de ingeniería, son tan importantes como la destreza técnica

Se comprometen.Se comprometen.Cumplen su palabra.Son honradosNo ocultan sus erroresNo mienten

Page 29: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

A juicio del autor, no puede afirmarse que todo lo que d á il bi

Hemos aprendidoemerge de un proyecto ágil, emerge bien

Las aproximaciones ágiles favorecen la adaptación frente a la predicción, pero no puede ser una regla. En ocasiones es predicción, pero no puede ser una regla. En ocasiones es necesario hacer arquitectura up-front, lo mismo la experiencia de usuario (por lo que son muy criticadas estas aproximaciones).

Predicción

• Planeación por iteración

• Diseño emergente• Testing integrado y

automático• Diseño Just in Time

Adaptación• Planeación al inicio

del proyecto• Requerimientos y

diseño al comienzo• Testing posterior

• Diseño Just in Time

Page 30: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

¿Y Latinoamérica?En Latinoamérica enfrentamos los mismos problemas que

l i d d d ll d l i en las sociedades mas desarrolladas y acceso al mismo conocimiento…

Pero no participamos en la creación de nuevo conocimiento en

E l i d d d ll d l

Pero no participamos en la creación de nuevo conocimiento en el campo del desarrollo (¿Ingeniería?) de software.

En las sociedades desarrolladas a los problemas les buscan soluciones

En las sociedades en vías de desarrollo y subdesarrolladas a los problemas les

b l blbuscamos culpables

Page 31: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

“El hombre razonable trata de adaptarse al mundo. El hombre irrazonable persiste

en que el mundo se adapte a él Por lo en que el mundo se adapte a él. Por lo tanto, todo el progreso depende del

hombre irrazonable”

George Bernard Shaw

Page 32: Acerca de la Ingeniería de SoftwareAcerca de la Ingeniería ...52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/IX_Jornada_Gerencia/Conferencia...• Las preguntas deben enviarse

Muchas graciasuc as g ac as