lean empresa software

8/19/2019 Lean Empresa Software

1/34

UNIVERSIDAD NACIONAL DE

EDUCACIÓN A DISTANCIA

MÁSTER UNIVERSITARIO EN INGENIERÍA

INDUSTRIAL

INGENIERÍA DE ORGANIZACIÓN Y LOGÍSTICA

Metodología Lean aplicada en empresa deIngeniería del Software

Autor: Pablo López Chaves

Profesor: Javier Conde


2/34

1

ContenidoINTRODUCCIÓN ............................................................................................................................. 3

Ingeniería de Software .............................................................................................................. 3

Problemas asociados a la Ingeniería del Software .................................................................... 4

Metodologías tradicionales y metodologías ágiles ................................................................... 4

FILOSOFÍA LEAN APLICADA A LA INGENIERÍA DEL SOFTWARE ..................................................... 7

Definición .................................................................................................................................. 7

Marco histórico ......................................................................................................................... 8

Flujo de la cadena de valor........................................................................................................ 9

Eliminar el desperdicio .............................................................................................................. 9

Personas y equipos de trabajo ................................................................................................ 11

Gestión Visual .......................................................................................................................... 12Mejora Continua ..................................................................................................................... 12

Procesos estables y trabajo estándar ...................................................................................... 12

Carga de trabajo nivelada ....................................................................................................... 13

Just in Time .............................................................................................................................. 13

Jidoka ....................................................................................................................................... 14

Caso práctico en empresa de software ....................................................................................... 15

Fase de desarrollo de productos ............................................................................................. 17

Análisis ................................................................................................................................. 17

Diseño y Construcción ......................................................................................................... 20

Ejecución de pruebas .......................................................................................................... 23

Aprobación del cliente ........................................................................................................ 24

Herramientas utilizadas en el desarrollo ................................................................................ 24

Herramientas de diseño ...................................................................................................... 24

Herramientas de programación .......................................................................................... 25

Herramientas de gestión de la documentación .................................................................. 25

Herramientas de gestión de requisitos ............................................................................... 27

Herramientas de gestión de proyectos ............................................................................... 29

Metodología de revisiones ...................................................................................................... 30

Conclusiones ............................................................................................................................... 32

Bibliografía .................................................................................................................................. 33


3/34

2

Listado de imágenes Imagen 1. Casa Lean ...................................................................................................................... 7

Imagen 2: Las 7 mudas ................................................................................................................ 10

Imagen 3: Método en V ............................................................................................................... 15

Imagen 4: Diagrama de Dependencias Externas ......................................................................... 18

Imagen 5: Diagrama de Flujo ...................................................................................................... 19

Imagen 6: Errores MISRA ............................................................................................................ 21

Imagen 7: Errores MISRA ............................................................................................................ 22

Imagen 8: Interfaz Enterprise Architect ...................................................................................... 25

Imagen 9: Repositorio ClearCase ................................................................................................ 26

Imagen 10: Version Tree ClearCase ............................................................................................ 27

Imagen 11: IBM Rational DOORS ................................................................................................ 28

Imagen 12: Requisitos de Diseño en IBM Rational DOORS ......................................................... 28

Imagen 13: Gestión de Procesos Microsoft Project .................................................................... 29

Imagen 14: Estado del proyecto Microsoft Project .................................................................... 30

Listado de tablas

Tabla 1: Ingeniería del Software ................................................................................................... 3

Tabla 2: Gestión Lean vs Gestión Convencional .......................................................................... 16


4/34

3

INTRODUCCIÓN

Ingeniería de Software

La primera parte del trabajo va a consistir en explicar qué es la ingeniería delsoftware.Actualmente prácticamente todos los países dependen en mayor o menor medidade sistemas informáticos. Tanto la fabricación industrial, los sistemas financieros, ladistribución, o prácticamente cualquier industria que nos imaginemos estácompletamente informatizada.La ingeniería del software es una meta de ingeniería cuya meta es el desarrollocosteable de sistemas de software. Éste es abstracto e intangible y no estásometido a materiales o procesos de manufactura. Estos aspectos puedensimplificar la ingeniería del software debido a que no existen limitaciones físicas delpotencial del software. Pero esta falta de restricciones naturales también puedellevar a que el software sea un campo extremadamente complejo.

La ingeniería del software es una disciplina de la ingeniería que comprende todos ycada uno de los aspectos de la producción de software, desde las etapas inicialesdonde se especifica el sistema que se va a desarrollar hasta el mantenimientodespués de que se utiliza.La siguiente tabla ayuda a comprender la ingeniería del software respondiendo auna serie de preguntas:

¿Qué es software? Programas de ordenador y su documentaciónasociada

¿Qué es la Ingenieríadel Software?

Es una disciplina de la ingeniería que comprendetodos los aspectos de la producción de software.

¿Cuál es la diferencia

entre Ingeniería delSoftware y Ciencia dela Computación?

La Ciencia de la Computación comprende la teoría y

los fundamentos; la Ingeniería del Softwarecomprende las formas prácticas para desarrollar yentregar un software útil.

¿Cuál es la diferenciaentre Ingeniería delSoftware e Ingenieríade Sistemas?

La Ingeniería de Sistemas se refiere a todos losaspectos del desarrollo de sistemas informáticos(incluye hardware, software e ingeniería deprocesos); la Ingeniería del Software es parte de eseproceso.

¿Cuáles son los costosde la Ingeniería delSoftware?

A grandes rasgos, el 60% de los costos son dedesarrollo y el 40% restante son de pruebas.

¿Qué atributos tiene

un buen software?

Debe tener la funcionalidad y el rendimiento

requeridos por el usuario, además de ser mantenible,confiable y fácil de usar.¿Cuáles son losprincipales retos a losque se enfrenta laIngeniería delSoftware?

Enfrentarse con la creciente diversidad, las demandaspara reducir los tiempos de entrega y crear unsoftware cada vez más fiable y de mayor calidad.

Tabla 1: Ingeniería del Software


5/34

4

Problemas asociados a la Ingeniería del Software

Como se ha dicho anteriormente, la Ingeniería del Software desarrolla productosintangibles que, por lo tanto, llevan consigo una alta complejidad. Es debido a elloque es muy difícil definir con exactitud los requisitos a cubrir y casi siempre son

necesarios cambios durante el desarrollo con respecto a lo que se estableció en elinicio del proceso.Esta complejidad lleva a cabo que sea prácticamente imposible conseguir el 100%de fiabilidad en un producto software dado que son muy numerosos los factoresque intervienen en la ejecución del mismo, como pueden ser datos almacenados enel sistema, interacción entre diferentes productos software, interacción sobre elhardware, interacción con el software base… Para garantizar en la medida de lo posible la fiabilidad del software, se definen tresfases genéricas dentro del marco de trabajo de la Ingeniería del Software:

Definición: donde se identifica qué se pretende obtener. Se recopilainformación sobre qué funcionalidad se debe implementar, cómo debecomportarse o qué información debe procesar el sistema.

Desarrollo: en esta fase se da solución a las necesidades definidas en la fasede la definición, incluyéndose las pruebas de software.

Mantenimiento: una vez el producto está listo, éste puede requerir sercorregido, revisado o mejorado.

Metodologías tradicionales y metodologías ágiles

Estos son los dos tipos de metodología que se han usado en el campo de laIngeniería de SoftwareDefinimos metodología como el “plan de investigación que permite cumplir ciertosobjetivos en el marco de una ciencia”.

Para el desarrollo del software se requiere un conjunto de elementos que, una vezagrupados, hacen que el desarrollo del software sea o no exitoso.Las metodologías tradicionales hacen énfasis en la planificación total de todo eltrabajo a realizar antes de comenzar y, una vez que todo está detallado, comienzael desarrollo del producto. Este tipo de metodología lleva consigo un rigurosocontrol de roles, actividades y herramientas. El problema de esta metodología esque no se adapta fácilmente a los cambios cuando los requisitos no puedenpredecirse con total exactitud o estos pueden variar.Ante las dificultades de las metodologías tradicionales aparecieron las metodologíaságiles, las cuales constituyen una solución a la medida del entorno, simplificandolas prácticas y asegurando la calidad del producto.El término ágil aplicado al desarrollo de software nació en febrero de 2001 en una

reunión en Utah (EEUU), cuyo objetivo era establecer principios que permitieran alos equipos de desarrollo crear software rápidamente, respondiendo a los cambiossurgidos a lo largo del proyecto, ofreciendo una alternativa a los procesostradicionales. Durante el transcurso de dicha reunión se creó “The Agile Alliance”,una organización sin ánimo de lucro que fomenta el desarrollo ágil de software yayuda a empresas de software a implementar dicha metodología.Durante la reunión de Utah se asignó el término “Métodos Ágiles” a los nuevosmétodos los cuales se basaban en una serie de principios, recopilados en lo que seconoce como el “Manifiesto ágil”. Dicho Manifiesto Ágil fue firmado por Kent Beck,Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, MartinFowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, BrianMarick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y DaveThomas y especificaba lo siguiente:


6/34

5

“Estamos descubriendo formas mejores de desarrollar software tanto por nuestrapropia experiencia como ayudando a terceros. A través de este trabajo hemosaprendido a valorar:

Individuos e interacciones sobre procesos y herramientasSoftware funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractualRespuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de laizquierda.”

Estos valores del Manifiesto Ágil son explicados a continuación:

Valoramos más a los individuos y su iteración que a los procesos y lasherramientasEste puede considerarse como el valor más importante del manifiesto.Por supuesto que los procesos ayudan al trabajo. Es más, son una parte

imprescindible del mismo, pero para llevar a cabo dichos procesos se necesitatalento y, por tanto, personas que lo aporten.En la metodología ágil los procesos son considerados como una ayuda, un soportepara guiar el trabajo.

Valoramos más el software que funciona que la documentación exhaustivaPoder anticipar cómo será el funcionamiento del producto final, observandoprototipos previos o partes ya elaboradas ofrece un “feedback” estimulante quegenera ideas difíciles de concebir en un primer momento, y difícilmente se podríanincluir al redactar un documento de requisitos detallado en el comienzo delproyecto.El manifiesto ágil no da por inútil toda la documentación, sólo la documentación

innecesaria. La documentación es necesaria, pero su relevancia debe ser muchomenor que el producto final.

Valoramos más la colaboración con el cliente que la negociación finalLa metodología ágil está principalmente diseñada para productos cuyo detalleresulta difícil de prever al inicio del proyecto; y si se detallara al comenzar, elresultado final tendría menos valor que si se mejoran continuamente durante elmismo.Resulta por tanto más adecuada una relación de implicación y colaboracióncontinua con el cliente, más que una contractual de delimitación deresponsabilidades.

Valoramos más la respuesta al cambio que el seguimiento de un planPara desarrollar productos de requisitos inestables, que tienen como factorinherente el cambio y la evolución rápida y continua, resulta mucho más valiosa lacapacidad de respuesta que la de seguimiento y aseguramiento de planes. Por lotanto, los principales valores de la gestión ágil son la anticipación y la adaptación.

Para acabar con la metodología ágil, a continuación se enumeran los 12 principiosdel manifiesto ágil:

Nuestra principal prioridad es satisfacer al cliente a través de la entregatemprana y continua de software de valor.

Son bienvenidos los requisitos cambiantes, incluso si llegan tarde aldesarrollo. Los procesos ágiles se doblegan al cambio como ventajacompetitiva para el cliente.

Entregar con frecuencia software que funcione, en periodos de un par de

semanas hasta un par de meses, con preferencia en los periodos breves.


7/34

6

Las personas del negocio y los desarrolladores deben trabajar juntos deforma cotidiana a través del proyecto.

Construcción de proyectos en torno a individuos motivados, dándoles laoportunidad y el respaldo que necesitan y procurándoles confianza para querealicen la tarea.

La forma más eficiente y efectiva de comunicar información de ida y vuelta

dentro de un equipo de desarrollo es mediante la conversación cara a cara. El software que funciona es la principal medida del progreso. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,

desarrolladores y usuarios deben mantener un ritmo constante de formaindefinida.

La atención continua a la excelencia técnica enaltece la agilidad. La simplicidad como arte de maximizar la cantidad de trabajo que se hace,

es esencial. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se

autoorganizan. En intervalos regulares, el equipo reflexiona sobre la forma de ser más

efectivo y ajusta su conducta en consecuencia.


8/34

7

FILOSOFÍA LEAN APLICADA A LA INGENIERÍA DELSOFTWARE

Durante este apartado se realiza una guía de la metodología LEAN para tener una

visión genérica de ella para posteriormente ver cómo se pueden aplicar susprincipios en el campo de la ingeniería del software.La primera parte consistirá en una definición del término Lean seguido del marcohistórico y los acontecimientos que han tenido mayor relevancia.Posteriormente se tratarán los principios en los que se basa la metodología Leanpara, finalmente, su aplicación en el ámbito de la Ingeniería del Software

Definición

El método Lean toma su nombre del sistema de producción desarrollado en Toyota.El pensamiento Lean cambia radicalmente la forma en la que se organizan los

sistemas de producción. Entre sus principios están el diseño del conocimiento y lacreatividad de los trabajadores, la reducción de las dimensiones de los lotes, laproducción just-in-time y el control de los inventarios.Su objetivo fundamental es la satisfacción del cliente mediante la entrega deproductos de calidad y utilizando el menor número de recursos (materiales,equipamiento, espacio, trabajo y tiempo).La siguiente imagen muestra una imagen esquemática de los principales elementosde la filosofía Lean:

Imagen 1. Casa Lean


9/34

8

Una manera habitual de representar el método Lean es mediante una casa, y comotoda casa debe de ser construida desde sus cimientos. Necesitamos unos cimientosasentados y estables en la organización, puesto que para poder aplicar una gestiónLean en una organización es necesario entender que se trata de una filosofía alargo plazo que tiene que alinear a todos los miembros de la organización.

Otra razón de que se represente como una casa es que una casa representa unaestructura que es fuerte siempre que los cimientos y las columnas sean fuertes. Enel momento que cualquiera de las partes esté en mal estado debilitaría todo el restodel sistema.Podemos decir que la casa Lean se compone de 4 elementos:

Cimientos: están basados en la implantación de la filosofía Lean. Esta

cultura, esta filosofía es la que va a dar estabilidad a “la casa”. Todos losmiembros de la compañía deben de disponer de la información adecuada ytener los procesos y operaciones estandarizadas y confiables.

Corazón: es la mejora continua. Para ello los equipos y personas trabajanorientados a obtener dicha mejora, reduciendo para ello en la máximamedida posible el desperdicio.

Pilares: en los pilares aparecen las herramientas Lean. Estas herramientasson “Just in Time” (fabricar solo lo que se necesita y cuando se necesita) y

“Jidoka” (técnicas para detectar y corregir los defectos de la producciónutilizando para ello los procedimientos y mecanismos necesarios que nosavisen de las anomalías)

Tejado: aquí se representa todo lo que se ve (calidad, costes, plazos…).Representa los resultados de la solidez del resto de la casa. Se busca el LeadTime más bajo, la mejor calidad y el coste más bajo.

Marco histórico

La filosofía Lean deriva del Sistema de Producción de Toyota (Toyota ProductionSystem, TPS), desarrollado por Taiichi Ohno y Shigeo Shingo entre 1950 y 1980.Taiichi Ohno se incorporó a Toyota Motor Company en 1943, iniciando su carreraprofesional como responsable de las actividades de montaje, escalando diversospuestos directivos y llegando a vicepresidente en 1975. A partir de 1950 inicia sucolaboración con el ingeniero industrial Shigeo Shingo, quien actúa como consultoren el desarrollo del sistema de producción de la compañía.A partir de ahí, Ohno y Shingo inician el desarrollo de un sistema de producciónpropio para Toyota, enfocado en la utilización ajustada de los recursos para cubrirla demanda real en cada momento. De esta forma, adquieren conciencia delimpacto de los grandes lotes de producción y los inventarios intermedios sobre lostiempos de entrega, y cómo dificultan el ajuste a los cambios en la demanda, tanto

en cantidad como en variedad de productos, al tiempo que incrementan los costesglobales de producción.La forma de trabajar de Toyota también hace mayor énfasis en el papel que jueganlos trabajadores en las plantas de producción. Ohno y Shingo consideran que lostrabajadores de Toyota tienen capacidades y conocimientos que pueden seraprovechados para una eficiente implementación y mejora continua del Sistema deProducción de Toyota. Es habitual que en Toyota las personas se integren enequipos autónomos que se responsabilizan de la productividad y la calidad de susoperaciones.Durante la década de 1980 aumenta el grado de conocimiento sobre el Sistema deProducción de Toyota, y se producen los primeros casos de éxito en su emulación(General Electric, Omak Industries). En 1990 James P. Womack, Daniel T. Jones y

Daniel Roos publican el libro "La máquina que cambió el mundo", en el que realizanun compendio de la historia de la producción automovilística, y llevan a cabo un


10/34


11/34

10

Imagen 2: Las 7 mudas

Sobreproducción: Producir más de lo demandado o producir algo antes deque sea necesario. Es bastante frecuente la creencia de que es preferibleproducir grandes lotes para minimizar los costes de producción yalmacenarlos en stock hasta que el mercado los demande. No obstante, estamala costumbre es claramente un desperdicio, ya que utilizamos recursos de

mano de obra, materias primas y financieros, que deberían habersededicado a otras tareas más necesarias.

Esperas: La espera es el tiempo durante la realización del procesoproductivo en el que no se añade valor. Esto incluye esperas de material,información, máquinas, herramientas, retrasos en el proceso de lote,averías, cuellos de botella, recursos humanos… En términos fabriles estaríamos hablando de los citados “cuellos de botella”,donde se genera una espera en el proceso productivo debido a que una faseva más rápida que la que le sigue, con lo cual el material llega a la siguienteetapa antes de que se la pueda procesar.

Transporte: Cualquier movimiento innecesario de productos y materiasprimas ha de ser minimizado, dado que se trata de un desperdicio que noaporta valor añadido al producto. El realizar un transporte de piezas de ida yno pensar en la vuelta, representa un transporte eficaz al 50%, hay queprever un recorrido eficiente, ya sea dentro de la propia empresa como en elexterior. El transporte cuesta dinero, equipos, combustible y mano de obra ytambién aumenta los plazos de entrega.

Sobreprocesos: La optimización de los procesos y revisión constante del

mismo es fundamental para reducir fases que pueden ser innecesarias alhaber mejorado el proceso. Hacer un trabajo extra sobre un producto es undesperdicio que debemos eliminar, y que es uno de los más difíciles dedetectar, ya que muchas veces el responsable del sobreproceso no sabe quelo está haciendo. Por ejemplo: limpiar dos veces, o simplemente, hacer un

informe que nadie va a consultar.


12/34

11

Exceso de inventario: Se refiere al stock acumulado por el sistema deproducción y su movimiento dentro de la planta, que afecta tanto a losmateriales, como piezas en proceso, como producto acabado. Este excesode materia prima, trabajo en curso o producto terminado no agrega ningúnvalor al cliente, pero muchas empresas utilizan el inventario para minimizarel impacto de las ineficiencias en sus procesos. El inventario que sobrepase

lo necesario para cubrir las necesidades del cliente tiene un impactonegativo en la economía de la empresa y emplea espacio valioso. A menudoun stock es una fuente de pérdidas por productos que se convierten enobsoletos, posibilidades de sufrir daños, tiempo invertido en recuento ycontrol y errores en la calidad escondidos durante más tiempo.

Movimientos innecesarios: Todo movimiento innecesario de personas oequipamiento que no añada valor al producto es un despilfarro. Incluye apersonas en la empresa subiendo y bajando por documentos, buscando,escogiendo, agachándose, etc. Incluso caminar innecesariamente es undesperdicio. Estos desperdicios hacen que un aumento del cansancio deloperario con los consiguientes problemas dorsolumbares y demás dolencias,

así como una disminución del tiempo dedicado a realizar lo que realmenteaporta valor.

Defectos: Los defectos de producción y los errores de servicio no aportanvalor y producen un desperdicio enorme, ya que consumimos materiales,mano de obra para reprocesar y/o atender las quejas, y sobre todo puedenprovocar insatisfacción en el cliente. Es preferible, por tanto, prevenir losdefectos en vez de buscarlos y eliminarlos.

Personas y equipos de trabajo

Una de las características de la Filosofía Lean es que las personas son la piedraangular para conseguir el éxito. Hay cuatro claves para que el ser humano tenga unbuen desempeño en el desarrollo de un producto:

Autodeterminación: esto se refiere a conseguir que sean las personas lasencargadas de crear el cambio y participen en él.

Motivación: el primer elemento motivacional es dar un propósito al trabajode las personas, por encima de un simple conjunto de tareas, debenentender el propósito de su trabajo, de una forma clara, convincente yalcanzable. Cuestiones como facilitar la comunicación entre el equipo y elcliente, dejar al equipo alcanzar sus propios compromisos ayudan a darsentido al trabajo que se está realizando. En estas circunstancias, gestionarse convierte en ser un facilitador, detectar las necesidades del equipo para

realizar correctamente su trabajo. Liderazgo: se buscan líderes más que simples gestores, que hagan frente al

cambio, marcando el camino a seguir, alineando y motivando al equipo. Unliderazgo basado en el respeto del equipo hacia el líder, por su profundoconocimiento del cliente y de los aspectos técnicos, más allá de unaautoridad concedida.

Experiencia: facilitar que los equipos adquieran y compartan su experiencia,que experimenten de manera autónoma, tolerando los errores durante elproceso de aprendizaje y fomentando la transmisión del conocimiento,especialmente el tácito. Por otra parte, la Ingeniería del Software ha delidiar con multitud de áreas de conocimiento especializado, tanto a niveltécnico como a nivel de negocio, este último tan o más importante como el

primero, dado que para conseguir dar valor al cliente es necesario conocerprimero su negocio en general y sus necesidades concretas en particular.


13/34

12

Por esta cuestión es importante facilitar la creación de comunidades deexpertos, especialmente en aquellas áreas críticas para el éxito de nuestraorganización. Estas comunidades, además, deben jugar un papel importanteen cuanto a la decisión de los estándares a seguir en el área de experienciaque cubren.

Por otra parte, hay factores como pueden ser el individualismo, el exceso derotación o la pertenencia a varios equipos que dificulten la existencia de equipos detrabajo.

Gestión Visual

Mediante la Gestión Visual se hacen evidentes las desviaciones sufridas en elproyecto, siendo más fáciles de identificar y haciendo más fácil recordarlas paraque no se repitan.En los últimos tiempos, las organizaciones están estableciendo más que nunca la

Gestión Visual mediante la comprensión de los principios fundamentales de cambiomediante el uso de Control Visual.Las organizaciones que tienen mayor visión en el futuro entienden el concepto deconstruir estabilidad y capacidad para mejorar a través de sistemas de GestiónVisual y Control Visual seguros y efectivos.El uso de controles visuales eficaces mejora la productividad, reduce los defectos yequivocaciones, facilita la comunicación, dando a las personas mayor control sobreelentorno en el que desarrollan su labor.Así, la filosofía Lean aboga por el uso de controles visuales para impedir que losproblemas pasen desapercibidos.

Mejora ContinuaPara hablar de mejora continua hay que hablar de “Kaizen”, palabra que en japonéssignifica “cambio para mejor” o “mejora”. El espíritu de mejora es uno de los pilares sobre los que se apoya el éxito de lafilosofía Lean.Kaizen se enfoca en las personas y en la estandarización de los procesos. Suobjetivo esincrementar la productividad mediante el control de procesos (reducción de tiemposdeciclo, la estandarización, etc.) y la eliminación de mudas.Dentro de las técnicas de mejora continua en el ámbito Lean, los eventos Kaizen

tienen gran importancia. Dichos eventos se componen de tres fases: preparación, elevento y mantenimiento del mismo.

Procesos estables y trabajo estándar

La estandarización de las tareas es una pieza clave para que se lleve a cabo lamejora continua.La producción eficiente se sostiene mediante la prevención dela aparición recurrente de defectos, errores de operación y accidentes y por laincorporación de las ideas de los trabajadores. La estandarización es debeconsolidareste conocimiento sobre el buen hacer y servir de base estable para la mejora.


14/34


15/34

14

Inventarios y tiempos de espera

Llevando esto al campo de la Ingeniería del Software, reducir los tiempos deproducción o tiempo de ciclo es una ventaja competitiva crítica en los proyectosSoftware, por las cada vez mayores exigencias de los clientes en cuanto a plazos ypor la competencia con otras empresas que evolucionan sus propios productos.

A continuación se exponen cuatro estrategias para reducir tiempos en el desarrollode Software:

Reducir el tiempo de aprendizaje: la correcta documentación y tener fácilacceso a ella es un factor clave en este sentido. Igualmente, laestandarización de herramientas y procedimientos a nivel de organizaciónfacilita el aprendizaje.

Reducir el tiempo debido al desperdicio: esta parte se ha desarrollado en elapartado “Eliminar el desperdicio”, donde se exponen causas y soluciones aeste problema.

Reducir los tiempos de espera: los tiempos de espera pueden ser debidos alcliente o a la tecnología utilizada. Algunos métodos para reducir dichostiempos son:

o Formar equipos de trabajo pequeños con responsabilidad compartidao Reducir el tiempo de set-up

Reducir los tiempos de repetición: esta estrategia se lleva a cabo mediantela reutilización del máximo número de recursos posibles, como pueden serdocumentación, código, etc. Esta reutilización debe llevarse a cabo conmucho cuidado, asegurándonos que la adaptación al nuevo proyecto escorrecta. Se podría decir que para una correcta reutilización se deben llevara cabo las siguientes fases:o Selección de los reutilizables posibleso Producción y evolución de los reutilizables.o Documentación de los archivos reutilizables.o Soporte y mantenimiento solucionando dudas o realizando correcciones

sobre errores detectados en los reutilizables.o Difusión de la información relevantes de los proyectos reutilizables.

Jidoka

El Jidoka es un término japonés que se refiere a la “automatización con un toquehumano”. Jidoka permite que el proceso tenga su propio autocontrol de calidad. Laidea es que los trabajadores no tengan que supervisar constantemente elfuncionamiento de las máquinas, sino dotar de mecanismos que hagan este controlautomático y que el trabajador sólo tenga que intervenir cuando algo va mal,disponiendo de medios para solucionar los problemas en el momento que se

producen y evitando que los defectos se propaguen aguas abajo del procesoproductivo.La idea de Jidoka es no resignarse ante la producción de defectos, ni al control decalidad por inspección. La calidad no se controla, se produce. Si un proceso producedefectos lo que se produce por sistema es no–calidad. Lo que habrá que hacer esmodificar el proceso productivo para que dichos defectos no se produzcan y no seanecesario desechar nada. Lógicamente, la modificación de un proceso productivosólo es posible cuando éste es flexible y está preparado para el cambio, mientrasque es inviable cuando las modificaciones son caras, lentas y burocráticamentepesadas. Por esto la adaptación al cambio es un requisito previo del aseguramientode la calidad.El concepto de calidad que predomina en el mundo de la Ingeniería de Software

suele estar ligado a dos aspectos: garantizar el seguimiento de un determinadoproceso de producción de software mediante el establecimiento de informes y


16/34

15

puntos de control, y garantizar la ejecución de un plan de pruebas exhaustivo porparte de un equipo de pruebas o certificación.Desde el enfoque Jidoka las pruebas deberían ser automáticas y los errores nodeberían propagarse nunca hasta el final del proceso de desarrollo.En este sentido, lo ideal es levar a cabo un sistema de revisiones continuas quedetecten los errores los más rápido posible sin tener que llevar a cabo grandes

controles de calidad al final del proyecto, lo que llevaría generalmente a tener quellevar a cabo grandes reestructuraciones de partes del proyecto con sucorrespondiente gasto de tiempo, dinero y recursos.También es importante llevar a cabo mecanismos que ayuden a localizar erroresautomáticamente.

Caso práctico en empresa de software

En este apartado se va a describir un caso particular de cómo se organiza y

desarrolla un proyecto de ingeniería de software en la empresa donde actualmentetrabajo.La empresa se trata de una consultoría tecnológica, la cual se dedica a trabajar enmuchos campos de la ingeniería (ferroviario, automoción energía, aeronáutico…). El cliente para el cual trabajo yo es un cliente alemán del área de la automociónque se dedica principalmente al desarrollo del software integrado en losautomóviles.Dicho software es utilizado en los componentes electrónicos del coche, comopueden ser desde sensores de aparcamiento, agua o luz hasta limitadores develocidad.La empresa engloba toda la fase de vida del software, desde la captación derequisitos por parte del cliente hasta la integración del sistema completo.Dicho proceso se representa mediante el “Método en V”. Dicho método sirve paradefinir un procedimiento para el desarrollo de productos de software.Es un proceso que representa gráficamente los pasos del desarrollo de vida de unproyecto. Se describen las actividades y resultados que deben producirse durante eldesarrollo del producto. El lado izquierdo de la V representa la descomposición delas necesidades, y la creación de las especificaciones del sistema. El lado derechode la V representa la integración de las piezas y su verificación.La siguiente imagen muestra el método en v que sigue la empresa para la quetrabajo:

Imagen 3: Método en V


17/34

16

Los procesos marcados en negrita son los correspondientes a la fase de desarrollodel producto software, los cuales se llevan a cabo en la empresa consultora,mientras que los otros son desarrollados directamente por la empresa cliente.

En los siguientes apartados se desarrollarán cada una de las partes de la fase de

desarrollo, explicándose cómo se llevan a cabo cada una de ellas y cómo se aplicala metodología Lean anteriormente explicada.Esta aplicación de la metodología Lean se va a fundamentar principalmente enaportar valor real al cliente, dándole el producto que realmente necesitaminimizando el coste y el tiempo de realización y maximizando la calidad delmismo.También se hace hincapié en eliminar el desperdicio, intentando llevar a caboúnicamente tareas que aporten un valor al cliente.Para entender mejor en qué consiste la aplicación de la metodología Lean en laforma de trabajar de la empresa de la que formo parte, he creado la siguiente tablala cual muestra las diferencias entre la gestión Lean y la convencional.

GESTIÓN LEAN GESTIÓN CONVENCIONALPromueve los sistemas pull,en los que la demanda realactiva laproducción

promueve los sistemas push,es decir, los que empujan lademanda al mercado

Busca la excelencia y laperfección, observando yescuchando directamente alcliente

se mueve a través deprácticas de vigilancia a lacompetencia, conherramientas como elbenchmarking o los estudiosde mercado tradicionales

Se trabaja con una ofertaconstantemente ajustada almercado, con un stock queidealmente es igual a cero

Necesita las ofertas ydescuentos para colocar susaltos niveles de stock en elmercado

Persogue los resultados amedio / largo plazo, en variasetapas, a través de la mejoracontinua

Busca resultados a cortoplazo, en una única etapa

Tabla 2: Gestión Lean vs Gestión Convencional

En definitiva, la gestión lean promueve hacer las cosas con un foco apuntando haciael cliente, buscando darle lo que quiere, cuando lo quiere y cómo lo quiere, al

mínimo coste, siempre buscando la perfección y con una visión de sistema. Parauna empresa que trabaja según la filosofía de gestión lean, dar dos pasos adelantey uno hacia atrás es aceptable; no dar pasos adelante, no lo es. Es el “simplementehágalo”, el hecho de que cuando se acaba de conseguir que algo funcione bien, hallegado el momento de mejorarlo de nuevo.La gestión convencional, busca más satisfacer las necesidades inmediatas de losaccionistas, a través de una mentalidad económico-financiera que se ha puesto porencima de la realidad de crear valor para el consumidor. No baja al taller y seensucia las manos, sino que permite que la lo que suceda en él no tenga nada quever con lo que pasa en realidad, es decir, lo que dice el mercado. Gestionaoperaciones aisladas, en lugar de procesos, sin establecer flujos de tareas de formaencadenada. Es una forma de supervivencia pura y dura.


18/34

17

Fase de desarrollo de productos

En este apartado se explicará cómo se lleva a cabo la fase de desarrollo deproductos en esta empresa, explicando cómo se lleva a cabo en esta empresa parael desarrollo de un proyecto de software de automoción.

El proyecto está divido en capas según sus funcionalidades dentro del mismo.Dentro de cada capa se encuentran los sub-sistemas, que agrupan a su vez unaserie de componentes.El componente es la unidad sobre la que se trabaja, y cada uno de ellos tiene supropia documentación, código y pruebas propias.La fase de desarrollo está compuesta por las siguientes etapas:

Análisis

En esta fase se describe el producto a desarrollar basándose en las peticiones delcliente. Se debe valorar el coste del producto y determinar su viabilidad.

En esta fase se genera un documento llamado “Requisitos de Diseño” (a partir deahora RD) donde se determinan todas las necesidades o condiciones a satisfacerpara un software nuevo o modificado, teniendo en cuenta las necesidades delcliente.El primer paso para desarrollar los RD es establecer un diálogo con el clientedurante el cual se debe redactar un informe detallado de lo que nos están pidiendo.En esta fase se deben lleva a cabo las siguientes acciones:

Requisitos de Diseño del softwareEn esta etapa se detallan los requisitos que tiene que cumplir el software. Ennuestro caso, se crea un documento de requisitos de diseño para cada componente,y dentro del mismo se divide en las funciones que tiene cada componente.

Dicho documento también tiene un apartado en el que se especifica los requisitosde integración con otros componentes.Las funciones de los Requisitos de Diseño los las siguientes:

Detallar la funcionalidad del componente:Deben responderse las preguntas de qué hace el componente, cómo lo hacey cuándo lo hace. También deben definirse los requisitos no funcionalescomo pueden ser funcionalidades de seguridad o calidad.

Definir la solución técnica:Identificar la solución tecnológica más ventajosa para el nuevo desarrollo encaso de ser necesario.

Para el caso de software ya existente, el trabajo se realizará en base a laestructura previa y a partir de ahí se introducirán las mejoras propuestas.

Establecer las estrategias del proyecto:Se comienza a planificar cómo se va a realizar el desarrollo de loscomponentes, la duración del proyecto o si se necesitará alguna herramientaespecial que condicione el desarrollo.En esta parte del proyecto se decide algo clave relacionado con lametodología Lean, y es cuándo el cliente va a ver sus requisitosmaterializados.

Detallar el nivel de servicio del componente:

Identificar las características que debe satisfacer el componente, es decir,cómo debe comportarse.


19/34


20/34


21/34

20

Diseño y Construcción

En esta fase se desarrolla el detalle técnico de los componentes y su posteriorconstrucción.Para comenzar con esta parte del proceso, los requisitos de diseño y las

funcionalidades del componente deben estar correctamente realizadas y revisadas,ya que la construcción del software se va a hacer a partir de estos documentos.Una vez dichos documentos estén listos, se les envía a los programadores que seencargarán de desarrollar el código.Antes de comenzar a desarrollar el código de programación se debe preparar elentorno, asegurándose que se tiene todo el soporte tecnológico necesario.En esta parte del desarrollo de los componentes entra en juego de manera clara lafilosofía LEAN en el sentido de que debe aprovecharse al máximo todos los recursosde los que disponen los programadores. En este caso con recursos me refiero acomponentes de proyectos antiguos de los que se pueda reutilizar parte de sucontenido. Esto es muy habitual dado que ha habido proyectos similares para elmismo cliente en el pasado y, por lo tanto, muchos de los componentes han sido yadesarrollados con antigüedad. Todos los componentes son de complejidad máximay su desarrollo es muy costoso, por lo que cualquier parte de otros proyectos quese pudiera aprovechar, por pequeña que fuera, ayudaría al desarrollo del producto,ahorraría tiempo y mejoraría la calidad del producto al tomar como base uncomponente que ya ha sido desarrollado y revisado con anterioridad.La comunicación con el equipo de “arquitectos de software” debe ser continua pararesolver cualquier duda que pueda surgir en cuanto a la funcionalidad delcomponente o respecto a posibles modificaciones que el equipo de arquitectura desoftware pudiera proponer.El código se desarrolla en Microsoft Visual Studio y el lenguaje de programaciónque se usa es el C++. Los archivos de programación generados se dividen en dostipos: los archivos “.c” que son en los que se desarrollan todas las funciones delcódigo y los “.h” (llamados archivos header o cabeceras) en los cuales se declaran

todas las funciones y variables utilizadas en el código.Para comenzar con la programación se debe estar seguro de que los equipos que sevan a utilizar tienen todos los programas necesarios correctamente instalados, conel fin de que el trabajo de programación sea lo más cómodo posible y así evitar enmayor medida los paros durante el proceso.Una vez esté todo listo para comenzar con la construcción del software, se debeestablecer la duración del proceso. Para calcular esta duración se tienen en cuentadiferentes factores como el tamaño del componente, el número de “arquitectossoftware” que van a trabajar en él o la existencia de material de apoyo(componentes de otros proyectos) que tengan disponible.

Una vez construido el código se procede a comprobar la calidad del mismo. Esta

parte se llama “Análisis Estático del Software”. El nombre “estático” es debido aque en este análisis no se comprueba la funcionalidad del componente, si no que secomprueba que el código no tenga errores de compilación y que cumple con losestándares de codificación.Para esta parte se realizan tres tipos de análisis llamados “MISRA”,” Naming” y

“Polyspace”, los cuales se explican a continuación: Análisis MISRA: el análisis MISRA consiste una serie de criterios creados

para la utilización del lenguaje de programación C en la industria deautomoción para la aplicación y creación del software dentro de sistemas delsoftware del vehículo. Las siglas MISRA significan “Motor Industry SoftwareReliability Association”.Debido al aumento de la incorporación de electrónica en el vehículo,

especialmente en lo referente a software, el proyecto MISRA comenzó en1990 con el objetivo de proveer una guía práctica de cómo hacer para eldesarrollo de sistemas electrónicos seguros y fiables.


22/34

21

Al ejecutar el análisis MISRA sobre un componente, éste nos dará los “warning” (posibles errores de tipo MISRA) que hay en el desarrollo delcódigo.La siguiente imagen muestra un ejemplo del documento que se crea alrealizar el análisis MISRA:

Imagen 6: Errores MISRA

En ella aparece el número de “errores” de tipo MISRA que hay en eldocumento analizado. Dichos errores son clasificados según su nivel deimportancia. Por ejemplo, en la Imagen 6 hay 81 errores de nivel 4 y 5errores de nivel 5.


23/34

22

También aparece, como muestra la siguiente imagen, la especificación dedicho “error” en la línea del código que se encuentra:

Imagen 7: Errores MISRA

Al pinchar sobre el error en azul se abriría una ventana explicando lasposibles causas / soluciones del mismo.Todos los errores deben ser analizados para comprobar si son o noaceptados, justificando detalladamente la aceptabilidad o no de los mismos.

Análisis Naming: este análisis se utiliza básicamente para comprobar elnombre de las variables y funciones utilizadas en el código. Los nombres devariables y funciones deben seguir un criterio específico y una serie dereglas. Al ejecutar el análisis Naming, se reporta, al igual que para elanálisis MISRA, un archivo con los errores que se han encontrado en elcódigo, los cuáles hay que comprobar si son o no permitidos con sucorrespondiente justificación.

Análisis POLYSPACE: el POLYSPACE es otra herramienta más utilizada parael análisis estático de código, mediante el cual se detectan ciertos errores. ElPOLYSPACE reporta un documento “zip” con una serie de documentosexplicativos de los errores encontrados, clasificándolos por tipo y colorsegún su gravedad.

El análisis estático es la última fase de la construcción del código. Una vez elanálisis esté hecho y revisado, hay que asegurarse que el 100% del código estáconstruido y listo para poder probarlo funcionalmente.


24/34

23

Ejecución de pruebas

Durante la misma se comprueba que el componente desarrollado no tiene erroresde ejecución y que los resultados y funcionalidades de todos los componentes soncorrectos.

Se ejecutan tres tipos de pruebas, pruebas unitarias, pruebas de integración ypruebas funcionales.

Pruebas UnitariasEs la primera prueba a realizar una vez el código está construido y revisado. Estaspruebas también se conocen con el nombre de “Pruebas de Caja Blanca. Su misión es la de comprobar el funcionamiento de cada parte del código, es decir,comprobar que se puede alcanzar cada parte del código dando diferentes valores asus parámetros de entrada. Algunas de las ventajas del uso de las pruebasunitarias son:

Dan soporte a la refactorización y la implementación de mejoras en elcódigo, ya que, si se dispone de una batería de pruebas unitarias completa,

y tras efectuar modificaciones en el código se pasan las pruebas unitarias sinerrores, aumentará nuestro nivel de confianza respecto a los cambiosimplementados ya que podremos asegurar que el resto del código no sehabrá visto afectado negativamente por dichas modificaciones.

Simplifican la integración del proyecto: los errores, en caso de aparecerdurante la integración entre los componentes del proyecto, estarán másacotados y, por tanto, será más fácil solucionarlos.

Sirven como documentación sobre el uso del código implementado: Lasmismas pruebas unitarias sirven como ejemplo del uso correcto del mismo.

Cada vez se ven más proyectos en los que se hace uso de las pruebas unitariaspara verificar el código desarrollado. Sin embargo, no todas las pruebas unitarias

que se implementan se consideradas correctas desde un punto de vista académico.Las buenas pruebas unitarias se basan en una serie de características, entre las quese pueden destacar las siguientes:

Independencia: la ejecución de una prueba unitaria nunca podrá depender

de las ejecuciones previas de otras pruebas. Automatización: debe ser posible integrar las pruebas unitarias en un

sistema de integración frecuente. Completitud: los “Casos de Prueba” deben comprobar el mayor número de

casos posibles (por ejemplo, para verificar el código de un método conparámetros, los casos de prueba deben comprobar el uso de valoreshabituales, valores extremos, valores nulos...).

Pruebas de IntegraciónLas Pruebas de Integración son aquellas que permiten probar en conjunto distintoscomponentes del proyecto para verificar que interactúan de manera correcta y quese ajustan a los requisitos especificados (sean estos funcionales o no).Este tipo de pruebas deben ejecutarse a continuación de las pruebas unitarias, unavez éstas han sido finalizadas y, por tanto, se ha asegurado el correctofuncionamiento de cada componente implicado por separado.La aplicación de este tipo de pruebas en un proyecto proporciona una serie deventajas, especialmente relacionadas con la prevención de la aparición de erroresocasionados por:-un mal diseño de los interfaces de los componentes-un mal uso de los componentes


25/34

24

Además, al igual que las pruebas unitarias, las pruebas de integración sirven comodocumentación del uso de los componentes puesto que, en definitiva, de nuevopodrán considerarse como ejemplos de su uso.

Pruebas funcionales

Esta fase puede resumirse en “probamos que funciona”.El primer paso consiste en preparar el entorno de pruebas, donde se establece enqué van a consistir dichas pruebas y se establecen los diferentes casos. Dichaspruebas se realizan en los entornos de desarrollo, integración y aceptación deusuarios.Por lo tanto, al ejecutar las pruebas en el entorno de desarrollo se debe verificarque la solución cumple con los requerimientos funcionales identificados, el correctofuncionamiento de los interfaces (esto ya se hizo en las pruebas de integración) yque las modificaciones llevadas a cabo sobre el componente no afectan al resto defuncionalidades del componente.Una vez realizadas las pruebas funcionales ya solo queda su aprobación, que sellevará a cabo cuando se hayan corregido todas las incidencias. Entonces seimplantarán todos los componentes del proyecto y ya estará listo para entregárseloal cliente.

Aprobación del cliente

Una vez todos los componentes del proyecto estén listos, éste estará disponiblepara entregárselo al cliente.La fecha de entrega debe coincidir en la mayor medida de lo posible con laacordada al inicio del proyecto.Si ha sufrido alguna variación, ésta ha debido preverse con antelación, ya a lasconstantes revisiones que tiene cada fase del proyecto nos permite identificar los

fallos cuando todavía no afectan a una gran parte del proyecto y por la tanto elretraso en la fecha de entrega es fácilmente deducible.El cliente realizará una serie de pruebas para comprobar que el producto entregadoes lo que había demandado. Estas pruebas se llaman Pruebas de Usuario y, en casode que el funcionamiento de cada uno de los componentes sea el esperado, elproyecto estará listo para su aprobación y por lo tanto se podrá decir que elproyecto está finalizado.

Herramientas utilizadas en el desarrollo

A continuación, son mostradas las herramientas utilizadas durante todo el procesoseparándolas según su finalidad en el proceso de desarrollo:

Herramientas de diseño

Se usa para dar una representación gráfica a la hora de diseñar piezas de software.Estas representaciones gráficas ayudan a comprender cada uno de loscomponentes. La herramienta de diseño utilizada es UML, leguaje que se explicarádurante este apartado.Las siglas UML significan Unified Modeling Languaje y proporciona mecanismos paravisualizar, especificar, diseñar y documentar sistemas de software.Durante este proyecto, el programa que se ha utilizado para desarrollar todos losdiagramas UML ha sido el “Enterprise Architect”.


26/34

25

Este entorno de desarrollo contiene un editor muy completo de UML y dispone demúltiples características. La siguiente imagen muestra la interfaz del EnterpriseArchitect:

Imagen 8: Interfaz Enterprise Architect

Con esta herramienta se hace representación gráfica de numerosas partes delproyecto, como puede ser desde un esquema general de la totalidad del proyecto adiagramas de flujo de las funciones utilizadas en los componentes.

Herramientas de programación

Estas herramientas son las utilizadas por los desarrolladores para escribir y testear

el código utilizado por los componentes.La herramienta de desarrollo o IDE (Integrated Development Enviroment) utilizadaen este proyecto ha sido el Microsoft Visual Studio, ya que el proyecto ha sidodesarrollado en el lenguaje de programación C++.

Herramientas de gestión de la documentación

Este tipo de herramientas son muy importantes dentro de cualquier proyecto, ymás si quiere implantarse en ellos la metodología Lean (como es nuestro caso).Sirven para almacenar todo el código fuente generado, todos los testes y todadocumentación generada de forma que sea accesible para todos los miembros delequipo en cualquier momento.


27/34

26

La herramienta utilizada en este proyecto ha sido el IBM Clear Case. Todos loselementos se almacenan en un repositorio que en Clear Case se llama base deobjetos de versionado (VOB).Esta aplicación se utiliza como repositorio. Dentro del proyecto hay diferentescarpetas; en cada una se guarda un tipo de documentos (en una los requisitos dediseño, en otra el desarrollo del código, en otra los testes…) Dentro de cada carpeta

se encuentran los componentes del proyecto para acceder al documento quequeramos.Por ejemplo, la siguiente imagen muestra donde están guardados los test unitariosdel componente “ErrorHandlerSupp” del subsistema “ErrorHandling” en el proyecto

“jaguar_d7a”:

Imagen 9: Repositorio ClearCase

De esta manera todos los archivos son fácilmente localizables y dota al sistema deuna gran organización.Además, mediante esta herramienta, se puede acceder a cualquier versión decualquier elemento del proyecto.Para trabajar en Clear Case se crean “tareas” o “vistas”. En ellas se realizan lasmodificaciones de los elementos que consideremos necesarias. Las modificacionesque se llevan a cabo durante las tareas de desarrollo dentro de la ejecución de unproyecto se registran en actividades, que consisten en varias versiones de distintoselementos de un componente.Se crea una nueva versión de un elemento cada vez que se realiza un cambio sobreel mismo. Por lo tanto, aunque un elemento se haya modificado siempre se puedeacudir a la versión anterior.Cuando se ha terminado de trabajar sobre un elemento, éste se “libera” para quetodos los trabajadores del equipo tengan acceso a él.


28/34


29/34

28

En Rational DOORS también se crea un documento llamado “Data Modul”, al quevan linkados todas las variables que utilizan los componentes las cuales tienen unvalor fijo.Las siguientes imágenes muestran la interfaz del del programa IBM Rational DOORSy parte de un documento de Requisitos de diseño respectivamente:

Imagen 11: IBM Rational DOORS

Imagen 12: Requisitos de Diseño en IBM Rational DOORS

En DOORS se van guardando versiones de cada documento sobrescribiendo laversión anterior a base de crear “baselines”. Pioo lo tanto, siempre se puedeacceder a cualquier “baseline” por muy antigua que sea. Otro aspecto que hace al IBM Rational Doors muy interesante es la capacidad de

“linkar” distintos documentos de DOORS. Por ejemplo, se puede crear un link de unrequisito de diseño de un componente a uno de otro componente, acción que nopermiten otros editores de texto.


30/34

29

Herramientas de gestión de proyectos

Este tipo de herramientas ayudan al jefe del proyecto a planificar los distintoseventos del proyecto, así como a asignar las tareas a los diferentes miembros del

equipo.Durante este proyecto, la herramienta que se ha utilizado para gestionar elproyecto es el Microsoft Project.La siguiente imagen muestra los datos que aparecen en este programa los cualesson visibles para todo el equipo del proyecto:

Imagen 13: Gestión de Procesos Microsoft Project

Aquí aparece el proyecto al que pertenece la tarea, el componente y la parte delproyecto, la duración en días y en horas, el porcentaje completado, la fecha deinicio y de fin y el miembro del equipo que debe hacerla.


31/34

30

El programa también se ayuda de un gráfico para tener un control visual deldesarrollo del proyecto:

Imagen 14: Estado del proyecto Microsoft Project

Donde las barras azules representan el proyecto en el que se debería estartrabajando y las líneas rojas el punto exacto en el que nos deberíamos encontrar.

Los datos del control del proyecto se actualizan semanalmente. El jefe del proyectopregunta a todos los miembros del equipo cuál es su situación y cuáles son sus

perspectivas y, en base a eso, se modifican los tiempos de cada tarea y su fecha deinicio y final.

Metodología de revisiones

Una de las características de la metodología Lean es la optimización de recursos alo largo del proyecto. Uno de los recursos más importantes a optimizar es eltiempo. Otro de los principios más importantes es la eliminación del desperdicio.Para llevar a cabo esas dos acciones, en esta empresa se lleva a cabo un sistemade revisiones el cual detecta los errores cuando tienen la menor influencia posibleen el proyecto y, por tanto, el tiempo que se pierde el corregir es menor y el

trabajo que hay que repetir se minimiza.Este sistema de revisiones consiste en corregir cada documento creado del proyectonada más terminarlo, antes de comenzar con la siguiente parte del proyecto.De esta forma, cualquier fallo en el desarrollo del proyecto es detectado antes deque afecte a otra parte del proyecto. Por ejemplo, cuando se crea un documento dediseño de software unitario, este debe ser revisado antes de comenzar a desarrollarel código. De esa manera los fallos no son arrastrados.Cada documento o archivo tiene un sistema propio de revisión, la cual es llevada acabo por otro integrante del equipo. Esto hace que la comunicación durante larevisión sea constante y se puedan despejar todas las dudas que pudiera haberrespecto a alguna parte del producto.Las revisiones se llevan a cabo rellenando un archivo de tipo “.xls” llamado

“Review_NombreComponente_NombreArchivoARevisar”. Cada archivo a revisartiene una plantilla diferente para realizar la revisión, es decir, no es igual la plantilla


32/34

31

para revisar los requisitos de diseño que la plantilla para revisar el test unitario. Enla revisión hay dos apartados: uno con la información del revisor (fecha, nombre,número de teléfono, departamento) y del autor del documento a revisar y otro enel que están los datos de la revisión. En este último lo primero en hacer esintroducir el camino a la carpeta de ClearCase dónde están guardados los archivosa revisar (y los que tienen relación con él). Por ejemplo, en la revisión del test

unitario también habría que introducir el código y los requisitos de diseño, ya quehan de ser vistos a la hora de hacer la revisión. Una vez se introduce el camino dedichos documentos, se procede a realizar la revisión respondiendo una serie decuestiones, llamadas “Check List”, para verificar que el archivo a revisar está bienrealizado y que se ha respetado las correspondientes normas de calidad. DichaCheck list cambia dependiento el tipo de documento a revisar.Cuando la revisión se ha realizado, contestando a todas y cada una de las CheckList argumentando los fallos encontrados, se añade el archivo de revisión al controlde versiones para que pueda ser visto por los demás miembros del equipo y seavisa a la persona que ha hecho el documento para que vea la revisión y realice, sifuera necesario, el “rework”. A partir de este momento es fundamental la comunicación entre los miembros del

equipo, ya que la realización de los distintos archivos no tiene una forma “única” derealizarse y lo que uno considera que está mal, el otro puede considerar que estábien. Por lo tanto, basándose en dicha comunicación entre el “dueño” deldocumento y el revisor se crea una nueva versión del documento a realizar.Normalmente, esta debería ser la versión definitiva ya que se ha rehecho a partirde una revisión y las opiniones de dos integrantes del equipo; pero de no ser así, sevolvería a hacer otra revisión siguiendo el mismo procedimiento y otro “rework” delarchivo para crear otra nueva versión, hasta que este se considerara que estácorrectamente realizado.Es en este momento cuando se podría avanzar al siguiente paso, de forma que noshemos asegurado que los pasos anteriores están correctamente realizados y sepuede avanzar con seguridad en el proyecto.

Personalmente, encuentro esta forma de trabajar muy útil tanto para localizar loserrores cuando menos afectan al conjunto del proyecto como para fomentar lacomunicación entre los componentes del equipo, sabiendo los puntos de vista decada no respecto a la forma de trabajar y pudiendo transmitir conocimientos delproyecto mediante la corrección de errores.


33/34

32

Conclusiones

La literatura revisada pone de manifiesto el creciente interés en los últimos añospor extrapolar las técnicas y prácticas de la filosofía Lean a la Ingeniería delSoftware.

La aplicabilidad de las técnicas y prácticas Lean en esta disciplina se pone demanifiesto y los resultados obtenidos en las experiencias son notablementepositivos.En el caso estudiado, correspondiente a una empresa que se encarga del desarrollodel Software para componentes del sector de la automoción se ha explicado cómose utiliza la metodología Lean aplicada a la Ingeniería del Software, aplicando dichametodología en cada una de sus fases.La aplicación de este sistema de trabajar utilizando la metodología Lean enempresas de software ha tenido mucho éxito en los últimos años, siendo cada vezmás las empresas que lo utilizan debido a sus buenos resultados.Hay una serie de factores que posiblemente hayan sido los detonantes de empezara usar este método de trabajo:

Dificultad económica en las empresas Menos demanda

Emergencia de nuevos modelos de negocio Mayores exigencias de calidad y productividad

A continuación, se exponen las fortalezas, debilidades, amenazas y oportunidadesque se extraen de este modelo de trabajo aplicado a la ingeniería del software engeneral y al caso estudiado en particular.

Fortalezas: todas las experiencias expuestas durante este trabajo enrelación a la aplicación de la metodología Lean en la ingeniería del softwarehan dado resultados positivos y se pueden seguir aplicando con garantías deque es una buena forma de trabajar.

Debilidades: El número de estudios que abordan la implementación de la

metodología Lean en el ámbito de la Ingeniería del Software en empresasreales es bastante reducido. Faltan estudios y más ejemplos reales queavalen los resultados obtenidos.También el componente cultural puede llegar a ser un obstáculo a la hora deimplantar esta filosofía en las empresas, ya que muchas de ellas optan porseguir con los métodos tradicionales.

Amenazas: falta de aceptación por parte de la organización de algunasempresas. Falta de motivación por pare de empleados que consideren másapto el método tradicional y se opongan al cambio de metodología.También es una amenaza tener prisa por obtener los resultados eimpacientarse, ya que la aplicación de la metodología Lean es apta a medio-largo plazo.

Oportunidades: la implantación de dicha metodología en más empresas de

Ingeniería del Software las cuales utilicen métodos tradicionales. LaIngeniería del Software es una disciplina que requiere plazos máscompetitivos y, por lo tanto, una gestión más eficaz de todos los recursos dela empresa. Una cultura Lean en la empresa puede servir eficazmente anteun mercado cada vez más exigente y competitivo. Exportar estametodología a empresas de otros sectores que aún no la apliquen.


34/34

Bibliografía

Soomerville, Ingeniería del Software, 7ª edición. Madrid: Pearson Educación, 2005

R. Pressman, Ingeniería del Software: un enfoque práctico. Madrid: McGraw-HillHoward Williams; Rebecca Dura, Making IT Lean: Applying Lean Practices to the work of IT.

CRC Press

Alan Dennis; Barbara Haley, System Analysis and Design, 5ª edición. John Wiley & Sons, Inc

Raúl Herranz Serrano, Scrum Manager-En busca de la excelencia del Código

E. Parnell-Klabo, “Introducing Lean Principles with Agile Practices at a Fortune 500 Company”

in AGILE 2006

M. Poppendieck y T. Poppendieck, Lean Software Development: An Agile Toolkit

Manifiesto por el Desarrollo Ágil de Softwre: http://www.agilemanifesto.org/iso/es/

lean empresa software

Documents