You are on page 1of 12

1- LA INGENIERÍA DEL SOFTWARE FUNDAMENTOS Uno de los problemas más importantes con los que se enfrentan los ingenieros

en software y los programadores en el momento de desarrollar un software de aplicación, es la falta de marcos teóricos comunes que puedan ser usados por todas las personas que participan en el desarrollo del proyecto informático para aplicaciones generales. El problema se agrava cuando el desarrollo corresponde al ámbito educativo debido a la total inexistencia de marcos teóricos interdisciplinarios entre las dos áreas de trabajo. Aunque algunos autores como Galvis [1996] reconocen la necesidad de un marco de referencia, teniendo en cuenta que se debe lograr la satisfacción de los requisitos en las diversas etapas del desarrollo, de lo que constituye un material didáctico informatizado. Esta necesidad sigue vigente, ya que en la mayoría de los casos analizados, se trata de software hipermedial diseñado a partir de herramientas de autor. Marquès [1995], es uno de los autores que plantea un ciclo de desarrollo para software educativo de programas en diez etapas, con una descripción detallada de las actividades y recursos necesarios para cada una de ellas. El inconveniente principal de esta metodología es que centra el eje de la construcción de los programas educativos en el equipo pedagógico, otorgándoles el rol protagónico. Es por este motivo, que en este artículo se sintetizan las metodologías, métodos, herramientas y procedimientos de la ingeniería de software, que deben ser utilizados para lograr un producto óptimo desde el punto de vista técnico. Su conocimiento y aplicación conjuntamente con las teorías: educativa,

epistemológica y comunicacional permitirán el logro de un producto óptimo desde el punto de vista educativo La ingeniería de software está compuesta por una serie de modelos que abarcan los métodos, las herramientas y los procedimientos. Estos modelos se denominan frecuentemente paradigmas de la ingeniería del software y la elección de un paradigma se realiza básicamente de acuerdo al tipo del proyecto y de la aplicación, los controles y las entregas a realizar.

Por lo tanto. Un ciclo de vida establece el orden de las etapas del proceso de software y los criterios a tener en cuenta para poder pasar de una etapa a la siguiente. los procesos. definir en todas las etapas del ciclo de vida del producto. la instalación. la codificación y las pruebas del sistema. utilizando en su lugar proceso de software. ya que se deben tener en cuenta los aspectos pedagógicos y de la comunicación con el usuario. en su desarrollo pasa por una serie de etapas que se denominan ciclo de vida. el diseño del sistema de software (diseño preliminar y diseño detallado). en cada caso en particular. El proceso de construcción está formado por etapas que son: la obtención de los requisitos. el diseño del sistema. que han publicado normas tituladas “Standard for . Para la construcción de un sistema de software. el código respectivo y por último el sistema de software. la implementación. el proceso puede describirse sintéticamente como: la obtención de los requisitos del software. las pruebas. se habla de ciclo de desarrollo. se parte de una necesidad. El tema del ciclo de vida lo han tratado algunas organizaciones profesionales y organismos internacionales como la IEEE (Institute of of Electrical and Electronics Engineers) y la ISO/IEC (International Standards Organization/International Electrochemical Commission). se obtiene el diseño del mismo. aunque a veces. el mantenimiento y la ampliación o actualización del sistema. Desde la perspectiva del producto. siendo necesario. se puede decir que se denomina ciclo de vida a toda la vida del software. El software o producto. para denominar al subconjunto del ciclo de vida que empieza en el análisis y finaliza la entrega del producto. la respuesta a la problemática debe basarse en una adaptación de los actuales paradigmas de desarrollo a las teorías educativas que permitan satisfacer una demanda en especial. las actividades y las tareas a desarrollar. cambiando la perspectiva de producto a proceso.Debido a las características particulares de los desarrollos educativos. comenzando con su concepción y finalizando en el momento de la desinstalación del mismo. se especifican los requisitos. Algunos autores sostienen que el nombre ciclo de vida ha sido relegado en los últimos años.

. Es útil como control de fechas de entregas. la explotación y el mantenimiento de un producto de software. EL MODELO EN CASCADA La versión original del modelo en cascada. Para pasar a la fase posterior es necesario haber logrado los objetivos de la previa. Ambas consideran una actividad como un subconjunto de tareas y una tarea como una acción que transforma las entradas en salidas. 1994]. aunque son más conocidos los refinamientos realizados por Boehm [1981]. las actividades y las tareas involucradas en el desarrollo. En este modelo. fue presentada por Royce en 1970. el suministro. la explotación y el mantenimiento del software” y la norma ISO 12207 define como modelo de ciclo de vida al “marco de referencia. que contiene los procesos. pero en general suelen ser: Análisis de requisitos del sistema Análisis de requisitos del software Diseño preliminar Diseño detallado Codificación y pruebas Explotación (u operación) y mantenimiento Las características de este modelo son: Cada fase empieza cuando se ha terminado la anterior. Sommerville [1985] y Sigwart y col.Developing Software Life Cycle Proccesses” (Estándar IEEE para el desarrollo de procesos del ciclo de vida del software) [IEEE. el producto evoluciona a través de una secuencia de fases ordenadas en forma lineal y permitiendo iteraciones al estado anterior. abarcando la vida del sistema desde la definición de requisitos hasta la finalización de su uso”. 1991] y “Software life-cycle process” (Proceso de ciclo de vida del software) [ISO. El número de etapas suele variar. el desarrollo. Según la norma 1074 IEEE se define al ciclo de vida del software como “una aproximación lógica a la adquisición. [1990].

Además. Al final de cada fase el personal técnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto. recibe el primer producto al haber consumido casi la totalidad de los recursos. como el sistema no estará en funcionamiento hasta finalizar el proyecto. Este modelo incremental fue desarrollado por Lehman [1984]. o sea se pueden ampliar los requisitos y las especificaciones derivadas de la etapa anterior. el usuario. y que casi siempre hay iteraciones que van más allá de la etapa anterior. porque permite el refinamiento. También pueden utilizarse cuando el ingeniero de software tiene dudas acerca de la viabilidad de la solución pensada. Las etapas son las mismas que en el ciclo de vida en cascada y su realización sigue el mismo orden. Uno de los problemas que se puede presentar es la deteccción de requisitos tardíamente. DE REFINAMIENTO SUCESIVO O MEJORA ITERATIVA. EL MODELO INCREMENTAL. Este modelo es útil cuando la definición de los requisitos es ambigua e imprecisa. . Mc Cracken y Jackson [1982] han realizado algunas críticas al modelo: Sostienen que los proyectos reales rara vez siguen una linealidad tal. sobre todo si este no tiene una idea muy acabada de lo que desea. En cada paso sucesivo se agregan al sistema nuevas funcionalidades o requisitos que permiten el refinado a partir de una versión previa. Otra limitación que se argumenta es que el modelo supone que los requisitos pueden ser “congelados” antes de comenzar el diseño y esto significa un hardware asociado durante el tiempo que dure el proyecto. siendo su corrección tan costosa como en el caso de la cascada. PROTOTIPADO EVOLUTIVO El uso de prototipos se centra en la idea de ayudar a comprender los requisitos que plantea el usuario. pero corrige la problemática de la linealidad del modelo en cascada.

permitiendo la generalización de los componentes para que sean reutilizables. con una funcionalidad reducida. Refinamiento iterativo del prototipo Refinamiento de las especificaciones del prototipo Diseño e implementación del sistema final Explotación (u operación) y mantenimiento Si bien el modelo de prototipos evolutivos. existiendo un ciclo evolutivo del sistema en el sentido análisis-diseño-instrumentación-análisis. proponen un desarrollo interactivo e incremental. Al usar prototipos. [Piattini. podrá incrementarse paulatinamente a través de refinamientos sucesivos de las especificaciones del sistema. que se lleva a cabo en forma iterativa. en principio. las etapas del ciclo de vida clásico quedan modificadas de la siguiente manera: Análisis de requisitos del sistema Análisis de requisitos del software Diseño. evolucionando hasta llegar al sistema final.1996] Goldberg [1993]. Piattini [1996] presenta algunos de los modelos propuestos desde esta perspectiva: El modelo de agrupamiento o de clúster de Meyer [1990] El modelo fuente de Henderson-Sellers y Edwards [1990] El modelo de pinball de Amler [1994] Los expertos en tecnologías de objetos. Algunas metodologías hablan de diseños o metodologías recursivos pero como incrementales. desarrollo e implementación del prototipo Prueba del prototipo. dice que “la idea de la integración incremental es la diferencia clave de cómo debe ser gestionado un proyecto que utiliza tecnología orientada al objeto. fácilmente modificables y ampliables es muy usado. en muchos casos pueden usarse prototipos descartables para esclarecer aquellos aspectos del sistema que no se comprenden bien. LOS MODELOS ORIENTADOS AL OBJETO La tecnología de objetos permite acelerar el desarrollo de sistemas de manera iterativa e incremental.” .Esta versión temprana de lo que será el producto.

documentación y aspectos de formación para los desarrolladores de sistemas de información. [J. Un proceso normalizado en una organización. Los procesos se descomponen hasta el nivel de tareas o actividades elementales. pudiendo ser gráficos con textos. que no se han detallado en esta selección ya que aunque presenten ciertas potencialidades. Sintetizando lo anterior el autor dice que una metodología “representa el camino para desarrollar software de una manera sistemática”. no están muy extendidos. reglas. procedimientos. Juzgado. 1991] se detallan las etapas del proceso base de construcción de software. no dependiente del personal. Este estándar determina el conjunto de actividades esenciales (no están ordenadas en el tiempo) que deben ser incorporadas dentro de un modelo de ciclo de vida del software y la documentación a considerar. llega a la definición de metodología de desarrollo como “un conjunto de procedimientos. . conducentes a una mejor calidad. Para aplicar un procedimiento se pueden usar una o más técnicas. técnicas. herramientas. Un proceso de desarrollo controlado. y un soporte documental que ayuda a los desarrolladores a realizar nuevo software”. Las metodologías persiguen tres necesidades principales: Mejores aplicaciones. En el estándar IEEE 1074-1991 [IEEE.Existen otros modelos de ciclo de vida. donde cada tarea está identificada por un procedimiento que define la forma de llevarla a cabo. LA NECESIDAD DE UNA METODOLOGÍA DE DESARROLLO Maddison [1983] define metodología como un conjunto de filosofías. etapas. 1996]. Piattini [1996]. técnicas. herramientas.

definido como. La red de actividades. seguimiento y control. La selección de un modelo de ciclo de vida está asociada a un orden en la realización de las actividades a desarrollar. se debe recurrir a datos estadísticos propios o no. que han de ser desarrollados. . documentación del usuario y otros productos. la cantidad de código fuente. El diagrama de Gantt. Flexibilidad: aplicación en un amplio espectro de casos De fácil comprensión Soporte de herramientas automatizadas. 1996] que debe tener la metodología y que influirán en el entorno de desarrollo: Reglas predefinidas Determinación de los pasos del ciclo de vida Verificaciones en cada etapa Planificación y control Comunicación efectiva entre desarrolladores y usuarios. La estimación consiste en la predicción del personal. en cuanto a recursos. o los diagramas calendario permitirán establecer el estado del proyecto en un determinado momento a partir de su inicio. Que permita definir mediciones que indiquen mejoras Que permita modificaciones Que soporte reusabilidad del software EL CICLO DE VIDA Y LOS PROCESOS Todo proyecto tiene asociado. por más pequeño que éste sea. estimación de recursos. Para estimar el tamaño del producto o programa a desarrollar. una serie de pasos que se deben seguir tales como: planificación. y evaluación del mismo. como la secuencia de tareas más larga de principio al fin.CARACTERÍSTICAS Y CLASIFICACIÓN DE LAS METODOLOGÍAS Se pueden enumerar una serie de características [Piattini. especificaciones. es la que permitirá establecer a partir de la matriz de precedencia en camino crítico. casos de prueba. el esfuerzo y el costo asociado para llevar a cabo todas las actividades del mismo.

las bases de datos y las interfaces de usuario. plan de retiro Técnicas a utilizar CPM.[J. planificar la gestión. El análisis se realiza sobre las salidas resultantes. claro y preciso el conjunto de requisitos que deben ser satisfechos por el software a desarrollar. es el punto de partida para la puesta en marcha de un proyecto y la evaluación de las posibles soluciones que darán la viabilidad del mismo.LA PLANIFICACIÓN DE LA GESTIÓN PROYECTO Se la puede describir en términos de. prototipado. simulación (Montecarlo). Juzgado. el procesamiento de los mismos. la descomposición de los datos. PERT.(ver tabla debajo). asignar de los recursos. diagrama de Gantt. Documentos de salida Plan de gestión. 1996]. LA IDENTIFICACIÓN DE LA NECESIDAD Un enunciado en términos concretos. Técnicas a usar De adquisición de conocimientos. Técnicas de descomposición para estimación. es deseable. definir el proyecto. Por lo tanto. El objetivo es determinar en forma total y consistente los requisitos de software. confeccionar un informe de necesidades basados en las siguientes ítems de la tabla debajo: Identificación de la necesidad Actividades a realizar Identificar necesidades. estadísticas. diagramas de flujos de datos. Soluciones factibles. las actividades a realizar. los documentos de alida y de las técnicas a utilizar como se observa en la tabla debajo:lanifión de la gestión del proyecto Actividades a realizar Confeccionar el mapa de actividades para el modelo elegido del ciclo de vida. EL PROCESO DE ESPECIFICACIÓN DE LOS REQUISITOS Consiste en establecer de un modo conciso. Modelos de estimación (COCOMO). Alternativas de solución. puntos funcionales. modelización. Documentos de salida Informe de necesidades. Especificación de requisitos . análisis costo-beneficio. formular posibles soluciones y estudiar su viabilidad.

arquitectónico.Actividades a realizar Definir y desarrollar los requisitos del software y de las interfaces. axiomas algebraicos. procedimientos por capas funcionales. de interface con otros software y con hardware. de transición. Técnicas de prototipación. refinamiento sucesivo. Diagramas de actividades. EL PROCESO DE DISEÑO El proceso de diseño es la piedra angular para la obtención de un producto coherente que satisfaga los requisitos de software. diccionario de datos (DD). Técnicas orientadas a los objetos: Diagramas de clases/objetos Jerarquía de clases/objetos Técnicas formales de especificación: Técnicas relacionales: ecuaciones implícitas. Técnicas orientadas a los datos: Diagramas entidad relación y diagramas de datos. mecanismos de estado finitos. Se deben aplicar algunos principios conducentes a un software de calidad. ocultamiento de la información. etc. requisitos de interface de usuario. .. tales como: Abstracción. estructura jerárquica en módulos con control entre componentes. Técnicas orientadas al estado: tablas de decisión. aplicación de métodos sistemáticos y una revisión constante. El diseño desde el punto de vista técnico comprende cuatro tipos de actividades: diseño de datos. Documentos de salida Especificación de los requisitos del software. modularidad: consiste en la división en forma lógica de elementos en funciones y subfunciones. estructura de los datos. relaciones recurrentes. especificación de procesos. de eventos. procedimental y diseño de interfaces y desde el punto de vista del proyecto evoluciona desde un diseño preliminar al diseño detallado. Requisitos de interface con el medio. Técnicas a usar Técnicas orientadas a los procesos: Análisis estructurado: diagramas de flujo de datos (DFD). etc.

reproducibilidad del método de diseño con los datos de los requisitos. analizar el flujo de información. . Técnicas orientada a los objetos: Modelo clase/objeto. diseño lógico. diseñar las interfaces. Técnicas de prototipación. minimización de la complejidad de las conexiones entre las interfaces. diálogo de las interfaces. etc. Técnicas a usar Técnicas orientadas a los procesos: diseño estructurado.Para evaluar la calidad de un diseño se deben tener en cuenta criterios tales como: División en módulos con funciones independientes. diagrama de módulos. Jackson. Los módulos tienen una función específica y definida o sea cohesión máxima y mínima interacción con lo otros módulos o acoplamiento mínimo. del flujo de información. de los algoritmos. organización jerárquica de los módulos. Jackson. La cohesión es una medida de la fortaleza funcional del módulo y la el acoplamiento es una medida de interdependencia de los módulos de un programa. Programación orientada a objetos: diagrama de procesos. desarrollar los algoritmos. realizar el diseño detallado. de las interfaces. diseñar la base de datos. Modelo lógico y físico de datos. Técnicas de bajo nivel: Programación estructurada: diagramas de árbol. descripción de la base de datos. Documentos de salida Descripción del diseño del software de la arquitectura del software. Técnicas de refinamiento. Proceso de diseño Actividades a realizar Realizar el diseño arquitectónico. Representaciones de datos y procedimientos distintas. etc. HIPO (Hierarchy Input Process Output) Técnicas orientadas a los datos.

Documentos de salida Orden de mantenimiento y recomendaciones de mantenimiento Plan de retiro . mejoras solicitadas y cambios. realizar las operaciones en paralelo y retirar el sistema. realizar las prueba de aceptación. cargar la base de datos. Proceso de instalación Actividades a realizar Planificar la instalación. instalar el software. La salida de este proceso conduce a las pruebas de validación y verificación. generar el código fuente. Técnicas a usar Lenguajes de programación. código de la base de datos y documentación. crear la documentación. Plan de integración. Documentos de salida Plan de instalación del software e informe de instalación LOS PROCESOS DE MANTENIMIENTO Y RETIRO El proceso de mantenimiento se centra en el cambio asociado a los errores detectados. El retiro es la baja de un sistema existente. Jackson EL PROCESO DE INSTALACIÓN Este proceso se centra en la verificación de la implementación adecuada del software y en la conformidad del cliente. Se lo considera como una nueva aplicación del ciclo de vida pero a un software existente en una iteración de desarrollo.EL PROCESO DE IMPLEMENTACIÓN Este proceso (ver tabla debajo). planificar y realizar la integración de módulos. Proceso de implementación Actividades a realizar Crear los datos de prueba. fallas. de base de acuerdo a los estándares utilizados. Documentos de salida Datos de prueba. produce código fuente. a realizar Reaplicar el ciclo de vida Notificar al usuario. previa prueba de aceptación. documentación del sistema y del usuario. crear código fuente.

Informes de evaluación. Especificación de las pruebas. Plan de pruebas. Es necesaria la documentación del sistema en un momento determinado. Cuando ya existe código ejecutable. Recoger y analizar los datos de las métricas. desarrollar las especificaciones de las pruebas y ejecutarlas.EL PROCESO DE VERIFICACIÓN Y VALIDACIÓN Las tareas que abarca son las siguientes: pruebas de verificación. Procesos de verificación y de validación Actividades a realizar Planificar y ejecutar las tareas de verificación y validación. Las pruebas consisten en ejecutar el software con determinados datos de entrada y producir resultados que luego serán comparados con los teóricos. Documentos de salida Plan de verificación y validación. . planificar las pruebas. Técnicas a usar Técnicas de prueba de caja blanca: Técnicas de prueba de caja negra: Revisiones formales Auditorías. EL PROCESO DE LA GESTIÓN DE LA CONFIGURACIÓN El proceso llamado gestión de la configuración. Resultados de la pruebas. involucra la gestión de los cambios durante el ciclo de vida que a partir de la configuración del sistema en un dado momento: tiene como objetivo un control de los cambios producidos y la coherencia del mismo. el establecimiento de una configuración inicial y un control de los cambios. como verificación y validación del software. se pueden realizar las pruebas del mismo. revisiones y auditoría e incluye las tareas de validación y pruebas de validación que se realizan durante el ciclo de vida del software para asegurar la satisfacción con los requisitos.

5.9.424  -897.8O3 03 1472.7... ...080.O3 09.. 9F.4070390 6:0 8.43/:. 50/7.-.08/00850..O3/02F94/48 88902E9...08.089.4:.084 /0 /80N4 08 ./49..3.3.948  574. ..974 9548 /0 ../80N4/09.3.08 .20394/0...8/05749495.390  .08 4./80N4/039071.425703/0 .94 . 03 2O/:48 .48:3.O3  20./4  $0 /0-03 .08/08/005:394/0. /0 48 /. 07E76:.7/.:7703908 .3.42..  %F./.3.7 .4254303908  0897:.38248 /0 089.0-7.81:3.4308  8:-1:3.7 5.548 .4  24/:.70   /80N4 /08/0 0 5:394 /0 ./ .8O3.03948  /0 97.4 .70.8 /0 /0.31472.:348 573.03908 ../.8.7.1.89..76:90.8O3  /0 0.43974 03970 .48 %F.0/2039.43 ./0 5740.O3  7013..9.43./  9..:. /0 00203948 03 1:3.8  70..70 /0 .870.940.430825J..89.O3 /0 :3 574/:.0/203948 547.9O3.. O.. :3 8419.4308  0897:.430870./4 13948  09.5.4-0948 %F.948  .8.O3  !# $ $B   574./08 /80N4 /0 /.43..3:.:9.:. 48 706:8948 /0 8419.81472.4 574..4389. /./.438890 03 . .38.5. 4-903.20394 8:./08/0:3/80N457023.9:7.43.981..O3%F..847039.9:7.

 /0 8419.08 /048..-/.70/80N4/09.../.3...3..7 0 /80N4 .76:90.7.4  !  07..8. .80.35:9!74..948/048706:8948  !74.80 /0 /. .479248 70.948 . /0 482O/:48 #05708039.8O3 03 2O/:48 .8 .O3  /08.O3 /0 ./.948574..7 .7 #0.:039.8..3.948  /0 .08  /80N4O.!..7 .70 /0 ./.  %F.08 ..70  /0 1:4 /0 31472.48/./4 /E44/0.4304308 03970 .847039.O3  /80N. .0848/80N40897:.839071. -.843 09.41J8.9.774.43 1:3. -./4  4.9:7.7 48 .7 %F..4250/.7.....8 39071.088 :95:9  %F.0/203948/8939.7 .O3 /0 /80N4 /0 8419.3..8.O3 07E76:.8 39071. 70.847039../.:203948 /0 8. 08.9:7../ /0 :3 /80N4 80 /0-03 90307 03 .80 /0 /.8 232.48574.4308/0/.8 39071.O3 /0 .9O3.484-09484/04./08 .4308 3/0503/03908  47.424  .75..76:90.4  ..948 4/04O.4/0/.75.08  70574/:.. .:8. 0.:./.948  /80N.3.08  /08..479248  %F.4348/.3./ /0 .7 0 1:4 /0 31472.790748 9.084/0/80N4 ./.847039./ /0 2F94/4/0/80N4.

O3 0897:.  48 2O/:48 90303 :3.O3.  /013/.7..././0 574...2.3.     .8/05749495.43.J1.O3 %F.0..45. .843 09.7./03907/0503/03..O3 47039.3. 1:3.3./.2.20394 08:3. 4 80.408O3 2E2.8/07013.0848 %F. /0 .8 /0 E7-4  !747.O3 0850.9:7..20//.4-094 /.45.20394 2J324  . .0.. 4-0948/./02O/:48  %F.  2J32... /..0 !747.7.408O3 08 :3.. 1:3. 1479.2. ..2.43./02O/:4./0482O/:48/0:35747.2.8/0-.2.3907.43449748 2O/:48 4 .20394 . 20//.

.389..843 !# $ $%  890 574../. -..O3/088902././/0 . 70. /0 8419...O3  389.084 .. 2502039.O3 .4 /0 .084/02502039.O/4 1:0390  ./08 .  .57:0-.3907.8 57:0-./0 .9.7#0. 8.7 0 .:2039../4 .:203948/08..948/4....O3 ..70...:2039.08/05747.7 ./.O3/02O/:48  4..4  574/:. /0-.80 /0/./0.7 70.084 80 .7.. .7 !.O3  5.O3  !74.948 /0 57:0-. :8:.7.43/:.:..70 8419./0.390320394 70.O/4 1:0390  0307..7.31.857:0-.9... ../4.07 9..O3.. -.70.390320394 80 .884..7 ....907.:8.8 2047. /0 0890 574...70089039003:3.059...4/0.O3 .059.5074.9./.80 /0 /. ...4308 03 5.31.70....0397. 7/03/02..80/0 ...3/0389.7../48 1.084/0389.84.770.O3 /0-.0390 570...70  .0397.O/4 /0 .2.O3  %F.:2039.3:0.071.071.  4..7 0 88902.!.. 03 0 .0890390 ../08 ./. 70.948/057:0-.9./0:8:..:203948/08.O3/0 /08../48  .3/03907.O3  4.7../.8.8 4507./.O3  $!# $ $%% #%#   574.0 .0 .7003./.431472/. 48 0774708 /090.948 70..7 .74  !.438/07.!# $ !%  890 574..-.424:3.7. 03 .3../.7 48 /.708 :9..700314720/0389.084 /0 2.703:./0:388902.8. 48 089E3/.:38419..74  70.04  7097.390320394 !.084 .:203948/08./..O3/0.2-48 $04.5. /4.:07/4 .4203/.4308/02.O/41:0390 .. 491.8/0.7744 7097408.7.5.3/070974 .70./..-..O3 /0 .O3 .O3  !74.O3/08419.2-4 .

:2039.3/4 .7.O3  !. !./0.2-48  ...2.48  !74..4 /0 .2-48 574/:. /0 8419.948/0./4089O3/0.8 9..43974 /0 48 .797 /0 .70 ./48  ..3/057:0-.O3  57:0-.  :3 .1.8/0..43974 /0 48 .08:/947J.857:0-.071.03.O/4 00.8./.7.4 :3 .8 /0 ..8 8:03908 57:0-../4..7 %F..8 850..80:7.O3 /0 88902././48 /..70.390 0 .70  .8 57:0-..434890O7...8/057:0-. .4 /0 .:9././.071..:9.3.....8 57:0-.8 0850.7.8 57:0-.705.7.:9./4  0 089.4:.40703.071./48/0...3 /:7.7 !.89.425..8 /0 2824  ...20394 /0 :3.800..431:7.O3  #0..1.. .9..:0.:9..8.O3  70.:203948 /0 8..O3 3.089O3/048..390 0 .8/057:0-.8 /0 .O3/0.70.8 5.-0  80 5:0/03 70.43 48706:8948  :./.8  %F.3....-0....4308 /0.307.O3/0.0848/0.3..O3. 03 :3 /..O3 6:0 80 70.071.8 6:0 .8 #08:9.3./08..424.7.981..89.70.7.O3/088902. 0890 .!# $ '# '  ./.3 /0 . %F....7 0 8419.84308  . #0./....774.57:0-.. 5.7../.574/:..08./..700.748/.82F97./0...8/0 .4388903 03 00.407.-.03:32420394 /090723..857:0-..31.31./.O3 /0 8419.071.O3  3147208 /0 0..8  !# $ $%  &#  574.O3  ..424 4-09..084.-.O3 3./. 843 .O3 .8 /08. 6:0 .8 .3./02824 830.43 /090723.:/947J.O3./4 2420394 9030 .431:7.7708:9.O3.:.7.. .8  4.70.948/00397.7 .2-48 /:7./48./486:0 :04807E3.431:7.:8.843081472.7.7..