Centro Función de Cambio

PRESENTACION DE ANALISIS DE SISTEMAS

2011-04-09T14:34:00.000-07:00

INFORME.-
DEFINIR PUNTOS PRIMARIOS PARA MEJORAR EL SISTEMA
MODELADO DE PROCESOS (PROCESO A ANALIZAR -- PROCESO MEJORADO)
DEFINIR ESTRATEGIAS PARA EL MEJORAMIENTO DEL SISTEMA
(REUBICACION DE ACTORES, ELIMINACION DE PROCESOS, ETC)
INFORME GENERADO POR LA HERRAMIENTA DE MODELADO
OBSERVACIONES Y RECOMENDACIONES

EXAMEN DE 2DA OPORTUNIDAD

2010-12-12T17:55:00.000-08:00

ALGEBRA 2 NOCHE CENTRAL

6845246
4877641
4896646

CALCULO 1 NOCHE CENTRAL

4810405
6003938
7746589

EXAMEN DE 2DA OPORTUNIDAD LUNES 12 DE DICIEMBRE DE 2010 HRS 19:00 A 20:00

REVISTAS

2010-10-03T08:14:00.000-07:00

Muy Interesante es una revista mensual de divulgación científica que se ocupa de hechos y acontecimientos de actualidad, tales como el desarrollo de la nanotecnología, las nuevas investigaciones e inventos, y los asuntos mundiales. Creado y publicado en España en mayo de 1981 (Grupo G + J España Ediciones, SL), actualmente se publica también en México (Editorial Televisa), Argentina (Editorial García Ferré, 1986), Colombia (Editorial Cinco), y como Super Interessante en Brasil (Editora Abril, 1987), Portugal (Edimpresa Editora, 1998) y Chile (Editorial Lord Cochrane, 1987).

IR AL SITIO DE DESCARGA
Enlace alternativo
IR AL SITIO DE DESCARGA

Conozca Más - Revista para mentes curiosas.
Divertida y perspicaz, este título es el ideal para acercarse al lector que busca temas controversiales. Con novedosas imágenes e interesantes reportajes sobre la repercusión de la ciencia y la tecnología en la vida cotidiana. Conozca Más atrae al lector ávido de conocimiento.

IR AL SITIO DE DESCARGA
Enlace alternativo
IR AL SITIO DE DESCARGA

La revista española Guía completa iPad - el guía lleno en todos los modelos iPad, describe muchos programas, juegos, bromas etc.

IR AL SITIO DE DESCARGA

So you want to go to business school…An MBA prepares you for a multitude of careers— and for life. Whether you want to be a financial analyst or the next Steve Jobs, this book tells you when, why, and where to apply for the B-school that’s right for you.

Descargar - Download

Edición en formato Pdf de la revista Harvard Business Review correspondiente al mes de octubre de 2010.

Descargar - Download

libros para todos

2010-10-03T08:07:00.000-07:00

Autor: Harvey M Deitel - Paul J Deitel
Editorial: Librisite

Hemos agregado bastante código resaltado para facilitar a los lectores la identificación de los segmentos representativos de cada programa. Esta característica ayuda a los estudiantes a revisar rápidamente el material cuando se preparan para exámenes o para algún laboratorio. También resaltamos en nuestra pantalla los diálogos que los usuarios introducen, para diferenciar los de las salidas de programa. Para promover buenas prácticas de programación, actualizamos todo el código fuente de los programas correspondientes a la parte de C de este libro con nuevos estándares de codificación. Las definiciones de variables ahora se ubican en líneas separadas para facilitar su lectura, y cada instrucción de control tiene una llave que abre y una que cierra, incluso si resulta redundante.

DESCARGAR
Enlace alternativo
DESCARGAR

Autores: Grady Booch - Ivar Jacobson - James Rumbaugh
Editorial: Addison Wesley

Este libro enseña cómo utilizar UML de forma efectiva. Proporciona sugerencias y consejos sobre cómo utilizar UML para resolver varios problemas de modelado comunes, pero no enseña cómo modelar. En este sentido es parecido a una guía de usuario de un lenguaje de programación, que enseña cómo utilizar el lenguaje pero no enseña a programar.
Se actualiza y completa con nuevos detalles de la descripción sobre interfaces requeridas y proporcionadas, colaboraciones y perfiles UML.
Sin duda un excelente libros, si estas comenzando el hermoso mundo de la ingeniería del software, recomendado.

DESCARGAR
Enlace alternativo
DESCARGAR

Autor: Guadalupe Pacheco, Dora Gutierrez
Editorial: McGraw-Hill

Metodología de la Programación: a través de pseudocódigo
El pseudocódigo es un lenguaje algorítmico, de alto lenguaje utilizado para escribir con mucha más abstracción instrucciones de un lenguaje de programación.
El pseudocódigo está pensado para facilitar a las personas el entendimiento de un algoritmo, y por lo tanto puede omitir detalles irrelevantes que son necesarios en una implementación. Programadores diferentes suelen utilizar convenciones distintas, que pueden estar basadas en la sintaxis de lenguajes de programación concretos. Este libro le enseñará los aspectos básicos del pseudocódigo, entrando así en una compresión al implementar un programa o aplicación, si estas comenzando y quieres aprender a programar el pseudocódigo es la base de todo lo que vendrá después.

Miguel Ángel Rodríguez excelente programador hispanoamericano, nos dará en su libro los conocimientos y la entrada al mundo de la programación con bucles, convenciones, algoritmos, búsquedas, constructores, destructores, tipos de datos, Arrays, etc.

DESCARGAR

Autor: Hamdy A. Taha
Editorial: Prentice Hall

La séptima edición de esta reconocida obra ofrece una cobertura equilibrada de la teoría, las aplicaciones y el cálculo en la investigación de operaciones, e incluye situaciones prácticas completamente analizadas. Cada capítulo contiene ejemplos y aplicaciones tomadas de estudios de casos ya publicados. Para destacar la efectividad de la investigación de operaciones para la toma de decisionés, esta edición hace énfasis en las herramientas de cálculo modernas -los programas de cómputo. Prácticamente cada algoritmo es respaldado y explicado por medio de una herramíenta de software apropiada, lo que facilita considerablemente la comprensión de los conceptos.
La obra incluye los siguientes apoyos tecnológicos:
- Poderoso software TORA, con características tutoriales nuevas y únicas.
- Las plantillas Excel, diseñadas para resolver problemas generales cambiando simplemente en una plantilla los datos de entrada.
- Excel Solver para resolver problemas de transportación, de red y de programación lineal y no lineal.

DESCARGAR

Autores: Hillier, Lieberman
Editorial: McGraw-Hill

Esta nueva edición mejora las características de la anterior, con una fuerte orientación hacia las aplicaciones a problemas reales. Incluye abundantes ejemplos y el desarrollo de 25 casos inéditos constituye un reto para el trabajo del alumno, ya
sea de forma individual o en equipo.
Se han incorporado 10 secciones dedicadas a los tipos y tamaños de problemas que se resuelven en las aplicaciones prácticas tanto en el sector de manufactura como en el de servicios.

DESCARGAR

Autor: Andrew S. Tanenbaum
Editorial: Prentice Hall

A partir de la popularización de Internet y de las redes de cómputo, esta obra alcanza su tercera edición. También se presentan nuevos ejemplos operativos como Internet y las redes ATM, al igual que algunas redes de gigabits y otras redes bien conocidas. Además se ha actualizado el material acerca de los sistemas telefónicos, incorporando ahora la ISDN de banda amplia. El material sobre el radio celular se ha incrementado de manera considerable y la obra cuenta con un nuevo capítulo sobre satélites de órbita baja.
DESCARGAR
Enlace alternativo
DESCARGAR

Autores: James Kurose - Keith Ross
Editorial: Pearson

Este texto esta organizado de una forma que los autores denominan “top-down”, que significa que el manual empieza con las capas de aplicación y sus trabajos y sigue bajando hacia las capas físicas. Las capas de aplicación han sido el área de mayor crecimiento en lo que se refiere a Redes de computadores, muchas de las más recientes revoluciones en redes, incluyendo Internet, audio y vídeo, y sistemas distribuidos, han tenido lugar en las capas de aplicación.
Una importante característica del manual es que está desarrollado bajo los principios esenciales de las redes de computadores y el roll de estos principios en la práctica. Cada capítulo incluye una referencia a un importante principio, estas referencias ayudan a los estudiantes a apreciar algunos de los conceptos fundamentales que están siendo aplicados en la más actual tecnología de redes.
También cada capítulo en forma de recuadro hace referencia a lo que ha sido las historia de las redes de computadores, viendo así la progresión que está teniendo este campo.
Se incluyen en cada capítulo una entrevista con personas que han realizado importantes innovaciones en este campo.
DESCARGAR
Enlace alternativo
DESCARGAR

Autor: Carlos Suárez Salazar
Editorial: Limusa

Análisis del costo en la edificación, considerando como variables aleatorias la ubicación, el tiempo de realización y la estructura administrativa necesaria. con esta obra, el profesionista y la empresa constructora podrán reducir costos en proyectos de construcción, y el estudiante de ingeniería civil contará con elementos de juicio producto de la experiencia estadística de varias compañías constructoras.

Contenidos
Costos indirectos de operación.- Costos indirectos de obra.- El factor sobrecosto de obra.- El factor sobrecosto para obtener el precio de venta.- Tablas y gráficas.- Costos base material.- Costos base mano de obra.- Costos preliminares.- Costos finales.- Presupuestos.- Programación.- Concursos.

DESCARGAR
Enlace alternativo
DESCARGAR

Lanzamiento Intercup Bolivia

2010-09-17T14:55:00.000-07:00

Hora	Viernes, 24 de septiembre · 15:00 - 19:30

Lugar	Universidad de Aquino Bolivia Sede La Paz - Auditorio Martin Cardenas CALLE CAPITAN RAVELO PASAJE ISAAC EDUARDO #2643 Ed. UDABOL La Paz, Bolivia
Primer Torneo de interoperabilidad Tecnológica en Bolivia Cuéntanos tu experiencia en interoperabilidad entre plataformas Microsoft y Open Source a través de un artículo y gana fabulosos premios!!! INSCRIPCIÓN Y PARTICIPACIÓN ... - Todos los participantes deben agregarse como contactos en los sitios de Facebook y twitter: http://twitter.com/intercupboliva http://www.facebook.com/intercupbolivia - Descarga gratuitamente todo el software Microsoft que necesites en: http://www.dreamspark.com/

Lapazvalley

2010-09-17T14:52:00.000-07:00

Hora	Sábado, 18 de septiembre · 9:00 - 13:00

Lugar	Club de Ejecutivos, Edificio Herrman Piso 22, Plaza Venezuela 1440

El objetivo de este evento es el de juntar ideas innovadoras (por la presencia de tu proyecto) con financiamiento (por la presencia de inversionistas, bancos e incubadoras de empresas) para considerar el financiamiento de tu proyecto o la creación de tu empresa dinámica y de base tecnológica.
La Paz Valley es un evento sin fines de lucro que busca convertirse en el encuentro semestral entre los actores del emprendimiento tecnológico boliviano. Su objetivo es ser el espacio donde se encuentra la respuesta a las necesidades de financiamiento y asesoría de los emprendedores de base tecnológica del país.
Confirma tu asistencia en http://www.lapazvalley.org/asiste

SOFTWARE FREEDOM DAY

2010-09-17T14:49:00.000-07:00

softwarefreedomday.org

Guias para Censos y Encuestas

2010-09-09T08:42:00.000-07:00

Estimados alumnos les adjunto en esta entrada los documentos guia para realizar Investigacion de Mercados

Manual del Coordinador
Manual del Supervisor
Manual del Entrevistador
Estududio Mercado Laboral Femenino - Bolivia
http://www.crearcuestionarios.com/

Guias para Analisis de Sistemas 2

2010-09-09T07:58:00.000-07:00

Para la Materia de Analisis de sistemas 2 pongo para su consulta los siguientes documentos
Introduccion.-
Documento de Vision (ejemplo)

RESUMEN CONTINUACIÓN

UML en LINEA

2010-09-09T07:37:00.000-07:00

¡Diagramemos!

Existen muchas aplicaciones que nos ayudarán a crear diagramas UML, la lista es muy extensa así que mejor nos saltamos esa parte y exploramos por nuestra cuenta en esta lista publicada en Wikipedia.
Pero hay una aplicación en particular que me ha resultado muy simple pero a la vez atractiva y fácil de usar (además de ser la que he venido usando últimamente), sumado a la singularidad de estar basada en la web: yuml.me merece la pena echar una mirada a esta interesante aplicación.

)
(CONTINUACIÓN)

Por qué UML no sirve (lectura para Analisis de Sistemas 2)

2010-09-09T07:10:00.000-07:00

DEL BLOG DE JAVIER
En el año 1999 cursé una materia de ingeniería de software y tuve la desdicha de encontrarme con el “lenguaje” de moda para el análisis y diseño (supuestamente) orientado a objetos: UML (“Unified Modelling Language” o “Lenguaje Unificado de Modelado“) y su metodología asociada: el “Proceso Unificado“.

Ya desde el comienzo (al leer el manual de referencia de este lenguaje visual y el libro que describe la metodología), me resultó bastante incómodo, poco expresivo y hasta inconsistente en algunos aspectos. Con el correr del tiempo (al conocer otras metodologías de diseño de sistemas y al adquirir mayor experiencia en el campo), fui afianzando mi opinión sobre UML: es totalmente inútil y contraproducente.
Se que quizás estas afirmaciones suenen un poco fuertes, pero realmente no puedo utilizar términos más suaves para describir a este “lenguaje visual” y su metodología asociada. Reconozco que algunos de sus diagramas pueden ser útiles para modelar algunos aspectos de algunos tipos de sistemas, pero en general, es una pésima idea utilizar UML para documentar el proceso de desarrollo de software y el Proceso Unificado para conducirlo.

Para empeorar la situación, es tal la campaña publicitaria que se ha montado alrededor de UML desde su aparición, que en la actualidad es la notación preferida por muchos que dicen utilizar metodologías orientadas a objetos (entre ellos el Object Management Group). El por qué del éxito y la inutilidad de UML parecen estar explicados en un sólo párrafo (extraído del artículo “A Comparison of the Business Object Notation and the Unified Modeling Language” de Richard Paige y Jonathan Ostroff, cuya lectura recomiendo ampliamente):

En 1995, existían entre 20 y 50 notaciones y lenguajes de este tipo. A menudo, los usuarios tenían que elegir entre varios lenguajes de modelado similares con diferencias menores en poder expresivo global. Pero en un encuentro decisivo en Silicon Valley en 1995, metodistas y productores de herramientas acordaron que los usuarios necesitaban un estándar mundial para el metamodelado y la notación. En ese momento nació UML, y ha sido adoptado por desarrolladores de software principales.

Está claro entonces que UML nació de la necesidad de unificar un gran número de notaciones diferentes, y más como un acuerdo comercial que como el producto de una investigación profunda. Esto también queda en evidencia por el hecho que sus tres principales autores (Grady Booch, Ivar Jacobson y James Rumbaugh) se asociaron para crear una empresa (Rational Software, luego adquirida por IBM). Nada demasiado bueno puede surgir de la unión apresurada de un montón de cosas incompletas guiada por objetivos comerciales. UML y el Proceso Unificado nunca fueron más que eso.
Afirmo esto sin importarme que UML sea quizás la notación más utilizada en la industria actualmente. Como bien dijo Dijkstra, “los errores industriales no son sacrosantos sólo porque se cometan a gran escala“. (Si lo que usted busca es trabajo, probablemente necesite conocer UML, pero eso no lo transforma en una mejor herramienta.)
En 1997 Bertrand Meyer (creador del lenguaje Eiffel que se apega al método BON) escribío un artículo de tono gracioso (en el que un supuesto estudiante escribe a su profesor) llamado “UML: The positive spin” en el que desnuda las principales falencias de UML (en un tono para nada respetuoso, debo decir).
Después de años de tenerlo en mi lista de artículos a traducir, finalmente me he decidido a hacerlo. Ojalá sirva de utilidad a quienes hayan sido víctimas de la campaña publicitaria en favor de UML.
(También puede descargar la versión en PDF de este artículo.)

UML: El giro positivo

Por Bertrand Meyer

De: Cándido Smith, alumno de OO-101
A: Profesor Severa Stern
Asunto: Mi solicitud para el cambio de calificación

Estimado Profesor Stern:

El auxiliar de cátedra de su clase OO-101 me ha indicado que le escriba directamente sobre la calificación D-menos que obtuve en mi artículo “Una evaluación sobre el Lenguaje de Modelado Unificado (UML) propuesto“. Espero que usted considere cambiarla por una mejor (¿quizás una D?), ya que sería un alivio para mi promedio de calificaciones, ya debilitado luego del “Reprobado” que me puso en su última clase. (Quizás recuerde que en el examen final escribí “debe haber otras cosas entre las rebanadas de pan y Java“. Ahora me doy cuenta de lo poco aconsejable que fue ese comentario, y sinceramente pido disculpas si herí los sentimientos de alguien.)
Por supuesto, me doy cuenta del motivo de mi D-menos y aprecio su generosidad en no ser haber sido más duro. Como el auxiliar de cátedra me indicó, ¡no hay nada positivo sobre UML en mi artículo! Seguramente no puede ser correcto. Todo el mundo sabe que UML abre una brecha en la ingeniería de software, ¿y quién soy yo para cuestionar esto? Este es el por qué no le pido que cambie mi nota sólo por el efecto en mi promedio, aunque espero entenderá que no es agradable perder mi seguro de Buen Estudiante, por no mencionar novias y cosas por el estilo. No, admito que estaba equivocado y quiero enmendar mi error. Debe haber algo bueno que decir sobre UML.
Y puedo asegurarle que aprenderé la lección: ser positivo. Cualquiera sea el tema, siempre es posible darle un giro positivo. ¡El diario de esta mañana hasta imprimió un adjetivo que puede ser interpretado como no poco favorecedor en un artículo sobre Newt Ginrich! ¿Por qué entonces no sobre UML?

¡Se positivo!

Por lo tanto he seguido el consejo del auxiliar de cátedra. Por ejemplo, podría haber cosas buenas que decir sobre la notación misma. Podría ser simple, usable, convincente, fácil de aprender. Y hay de hecho tal notación para el análisis y el diseño orientados a objetos, cuyo conjunto completo de símbolos gráficos cabe en una página y cubre todas las técnicas básicas de descripción de sistemas Orientadas a Objetos, y el cual es particularmente bueno al escalar hasta la descripción de sistemas de gran envergadura: la Notación de Objetos de Negocios (BON) de Waldén y Nerson, como está descripta en su libro [3]. Por supuesto UML no tiene ninguna de esas propiedades. En su intento de mostrar que ha incluido las ideas de todos, es un desborde de símbolo tras símbolo bizarros. Solo el “Resumen de la notación” ocupa 60 páginas y ¡tiene su propio índice! UML es, de hecho, tan complejo como un lenguaje de programación grande y críptico, con un uso generoso de “$” y “#” y “-” y “*” y “triángulos sólidos sin cola” y rectángulos y diamantes y líneas sólidas y líneas punteadas y elipses sólidas y elipses punteadas y flechas de todo tipo y palabras reservadas tomo “const” y “sorted” (no confundir con “ordered“) y semánticas distintas para una clase dependiendo si su nombre aparece en letra “romana” o “itálica”. ¡Pero al menos un lenguaje de programación, incluso el peor de ellos, es ejecutable! Aquí hay que aprender toda esa complejidad monstruosa para construir diagramas de un posible sistema futuro.
Lo cual nos lleva a la pregunta del desarrollo continuo (“seamless”). Una vez que usted tiene su hermoso (o no tan hermoso) diagrama, querrá construir un sistema, salvo que el presupuesto ya se haya gastado en herramientas CASE (algo común para empresas que toman demasiado enserio la publicidad exagerada de la “metodología” y terminan sin dinero para el desarrollo real). Pero entonces debe recomenzar con un lenguaje de programación para hacer el trabajo real. ¿Y cómo mantiene la consistencia entre el programa y los diagramas? Waldén y Nerson convincentemente discuten el objetivo de continuidad (proveer un proceso único y continuo) y reversibilidad (ser capaces de moverse hacia atrás y hacia adelante entre el análisis, el diseño y la implementación). Herramientas como EiffelBench y EiffelCase soportan esta inquietud, pero no parece ser para nada una inquietud con UML. Pero por supuesto cualquiera que use UML debe ser listo -no solamente para aprender todos los símbolos- y por lo tanto hará un análisis correcto desde la primera vez, luego un diseño correcto desde la primera vez y luego nunca tendrá que cambiar nada en los próximos diez años de la vida del proyecto. O quizás UML es para proyectos cuyas especificaciones nunca cambian. Mi abuela me contó que una vez escuchó sobre un proyecto así en su juventud. Creo que dijo que tenía algo que ver con calcular el 6to. número de Fibonacci.

¿Orientado a Objetos?

Así es que tengo que buscar en otra parte para encontrar algo positivo que decir sobre UML. Estoy tratando con esfuerzo, y espero que lo tome en cuenta antes de enviar las notas finales a la administración. (Recuerde, sólo estoy pidiendo una D, aunque por supuesto una C-menos sería más que apreciada.) Por ejemplo, he intentado ver si podría caracterizar a UML como “orientado a objetos”; todos sabemos que este es un gran logro. Gran oportunidad. Por supuesto los autores hacen uso de los requeridos “objeto“, “herencia“, etc. Pero una simple mirada a los diagramas muestra a UML como lo que es: una extensión del modelado de entidad-relación. Los ejemplos básicos muestran asociaciones binarias y ternarias, tales como (página 16 de [1]) asociaciones entre “vuelo“, “asiento” y “persona“; esto es diametralmente opuesto al diseño orientado a objetos, donde, como todos sabemos, el mundo está estructurado en clases, construido sobre tipos de objetos y cada operación o propiedad pertenece a una clase. Seguramente en diseño orientado a objetos, ¡no podrá tener un enlace “pasajero” que trate simétricamente a “asiento“, “vuelo” y “persona“! En un sistema orientado a objetos, pertenecerá a una de las clases; así es como se obtiene la consistencia, simplicidad, modularidad y reusabilidad de la arquitectura OO. Fíjese en BON o Eiffel y disfrute los resultados. Los autores de UML saben esto, por supuesto; para entender por qué llaman a UML orientado a objetos debemos apreciar su famoso sentido del humor. Obviamente lo dicen en broma. (¿Es esto lo suficientemente positivo?)
La evidencia posterior de la broma es provista por la referencia frecuente a los “casos de uso” como un elemento central del método. Cuando “caso de uso” era la consigna de la Web, traté de entender de qué se trataba, y me fue difícil hasta que le pregunté a mi abuelo, quien me lo explicó todo: es el nuevo nombre para el análisis funcional descendente (top-down) de su adolescencia. Uno se fija en qué debe hacer el sistema (“casos de uso”) y deduce su arquitectura de ese análisis. Esto es diametralmente opuesto al diseño orientado a objetos, el cual conscientemente rechaza prestar demasiada atención, durante las primeras etapas, a las funciones principales del sistema, porque están muy sujetas a cambios, porque reproducen el comportamiento de sistemas previos (aquellos que estamos tratando de reemplazar con el nuevo sistema), porque llevan a un compromiso temprano con el orden de operación (¿el aspecto más volátil del software?) y porque se enfocan en las cualidades superficiales del sistema -su interfaz con el resto del mundo- en vez de en sus propiedades fundamentales. En cambio, el diseño OO se concentra en el tipo de los objetos manipulados por el sistema, y define cada uno de esos tipos a través de la lista de todas las operaciones aplicables y sus propiedades abstractas -contratos- sin importar el orden de aplicación. Mi abuelo agregó que estaba agradecido de que los casos de uso estuvieran presentes en UML, porque le traían recuerdos de los buenos viejos tiempos y que nunca le gustaron los objetos. (Creo que este es un comentario positivo.)

Encontrando un uso para UML

Obviamente UML no será útil a ningún desarrollador de software. ¿Podría quizás ser útil a alguien más? ¿Líderes de proyectos, quizás? ¿Ejecutivos de empresas? ¿Las empresas mismas? Por supuesto, no. De hecho, la documentación no hace ninguna pretensión de tal utilidad, y por buenas razones. Es difícil de imaginar qué benericio podría obtener un negocio de páginas de diagramas crípticos sobre propiedades confusas de un sistema pobremente comprendido.
Por lo tanto, busco más allá. A veces una propuesta ofrece una solución fallida, pero tiene el mérito de plantear el problema correcto. ¿Podemos decir esto de UML? Espero que sí. Aunque sea podría ayudar a mi promedio y, haciendo esto, me ayudaría a levantar mi autoestima, por no mencionar las novias y cosas por el estilo, pero me estoy desviando. Dicho sea de paso, ¿a qué problema apunta UML? He tratado con empeño, en los interminables documentos del sitio web de Rational, de encontrar una descripción del problema (lo cual se nos enseñó en nuestros cursos de ingeniería, debería aparecer en la introducción de cualquier documento técnico). Me temo que no he encontrado nada útil que reportar.

Amanda al rescate

Para ver qué metas debería haber perseguido, revisé el artículo de mi amiga Amanda Suertuda, la única que obtuvo un A-mas:
“Los desafíos de la industria del software“. (De paso, profesor, no logro comprender por qué Amanda siempre consigue los temas interesantes.) Su reporte, muy agradable debo confesar, hace un buen trabajo al describir los obstáculos técnicos que los desarrolladores deben superar. El buen software debe ser correcto; olvidemos una aserción en una rutina, y tendremos un desastre de u$s500 millones como la reciente explosión del Ariane 5, resultado de un intento equivocado de reutilizar una rutina de Ada sin un mecanismo de aserciones como el de Eiffel (ver la edición de enero de 1997 de IEEE Computer). No veo nada en UML que ayude a la corrección; sólo algo de palabrería dedicada a la noción de contrato, pero los autores muestran que no entienden nada de la idea del Diseño por Contratos (por ejemplo, ¡mezclan requerimientos semánticos con simples declaraciones de tipos!). El buen software debe ser robusto. ¿Cómo ayuda UML? El buen software debe ser fácil de modificar (Amanda llama a esto “extensibilidad“); pero el aparato pesado de UML garantiza cualquier cosa menos que los desarrolladores serán capaces de producir alguna descripción del sistema en la cual no será horroroso cambiar algo. El buen software debe ser reutilizable; nada en UML apunta a los desafíos de la reutilización, tales como las convenciones de estandarización de interfaces, separación de comandos y opciones, separación de comandos y consultas, etcétera. El buen software debe ser eficiente -oh, lo lamento, esto está relacionado a la implementación, y no hablamos sobre implementación en compañía educada. (Si UML se ocupara de la implementación, debería ocuparse de cuestiones relacionadas con el software; lo bueno de las burbujas y flechas, en oposición a los programas, es que nunca se cuelgan.)
En cambio, los documentos de UML parecen tener un único objetivo: una y otra vez convencer al lector de que no ha omitido ninguna consigna, como en este extracto, página 31 de [2], que intenta explicar que los patrones (patterns) son interesantes pero están cubiertos por el concepto de los autores de “diagrama de interacción“, cualquier cosa que esto sea (no puedo imaginarlo):

El aspecto interesante de muchos patrones es su comportamiento dinámico. Ciertamente podemos mostrar esto con diagramas de interacción, pero sólo en el contexto de un modelo específico. Es difícil mantener la “patronidad” de los patrones abierta. A fin de cuentas, los patrones son plantillas (en algún sentido), en los cuales las clases, asociaciones, atributos y operaciones pueden estar asignadas a distintos nombres, manteniendo la esencia del patrón. Necesitamos una forma de parametrizar claramente los patrones. Sin embargo, creemos que tenemos suficientes formas de capturar patrones en UML expresándolos en términos de interacciones.

Francamente, ¿quién está interesado en esta farsa? ¿Cómo puede alguien creer que tiene algo que ver (en algún sentido) con la industria del software? Y ni siquiera he citado cosas sobre el “metamodelo“. Quizás usted podría pedirle a Amanda que dedique su próximo artículo a la “patronidad“. Hablando de desafíos.
Un amigo que asistió recientemente a una conferencia sobre orientación a objetos me contó sobre las bromas sobre UML que los expertos en OO -algunas de las personas más respetadas en el área- intercambiaron durante los intervalos y en el fondo de las salas. Él no podía creer el contraste entre el bombo público y el menosprecio privado. Pero los CEOs y otros tomadores de decisiones sólo escuchan el bombo publicitario; se les dice que UML es orientado a objetos o, más a menudo, que orientación a objetos significa UML. Cuando no pueda ayudar al desarrollo de software, UML le dará un mal nombre a todo el campo de la OO. Dado los bombardeos de mercadotecnia a su alrededor, UML, al no cumplir con sus promesas, tiene el potencial de retrasar el progreso de la tecnología de objetos por diez años.

¿La respuesta al final?

Así pues, profesor, ¿qué puedo decir, qué puedo decir? Fui con el auxiliar de cátedra y le pregunté si decir “La página principal de Rational tiene lindos colores” ayudaría. Pero me dijo que no, que tendría que encontrar algo más sustancioso. Intenté con “al menos en su última revisión han dejado de llamar a sus cosas “método”, lo que muestra que tienen algún sentido del ridículo“. Tampoco le bastó. Así que busqué y busqué y, finalmente -estoy tan excitado- ¡lo encontré! ¡Sí, UML tiene un propósito después de todo!
La razón por la cual no lo descubrí antes es que sólo aparece en la conclusión. Un lugar extraño para describir sobre qué uno estuvo escribiendo, pero mejor que no hacerlo en ninguna parte. Por supuesto que lo que encontré no es un objetivo técnico (UML, como ya dije, no sirve a ningún propósito relacionado con el software, lo cual está bien para mí -algunas personas tienen mejores cosas que hacer con sus vidas que tratar de mejorar la tecnología del software). No es un objetivo gerencial, al menos no para personas que administren proyectos de software. No es un objetivo de negocios, al menos no para negocios que usen UML. Pero es un objetivo.
Cuando finalmente descubrí el objetivo, casi rompo en llanto por el espíritu generoso y noble de los autores. Sería injusto decir que las parvas de documentación de UML están vacías de toda substancia, cuando de hecho contienen una idea genuina. La encontré en el último párrafo del último reporte que describe la revisión 0.91 [2]. Allí estaba, con toda franqueza, explicando todo lo que había malinterpretado en mi joven inocencia. ¿Cómo podría criticar el método por no ayudar a los desarrolladores de software o gerentes, cuando no se ocupa en absoluto del desarrollo de software, sino sólo de desarrollar un mercado para consultores y capacitadores? Todo comenzó a tener sentido: la complejidad y rareza de la notación, lo que tontamente tomé como una deficiencia, son de hecho unas de sus cualidades más atractivas, dado que crean infinitas oportunidades de negocios, para Rational y quizás también para otros; así como también su tibia adopción de las ideas de la orientación a objetos, lo que significa que un consultor no tiene que conocer ni apreciar la tecnología de objetos para sacar provecho de UML.
Mi larga búsqueda no ha sido en vano. Me ha llevado a una total comprensión de UML, su admirable máquina auto-alimentada, dedicada de la A a la Z a la creación de un nuevo mercado, libre de todas las dificultades asociadas al desagradable negocio del desarrollo de software: ¡Libros de UML! ¡Cursos de UML! ¡Cursos sobre los libros! ¡Libros sobre los cursos! ¡Revisiones! ¡Journals de UML! ¡Conferencias! ¡Workshops! ¡Tutoriales! ¡Estándares! ¡Comités! ¡Remeras! Mientras más se piensa en las posibilidades, más deslumbrante aparece. Y para cualquier lector valiente o lo suficientemente aburrido como para leer la documentación hasta el final, el esquema global está allí, presentado en el párrafo final.
Todo empezaba a encajar. Con el aire de inevitabilidad que revela una auténtica obra maestra, en toda la gloria del estilo inimitable del documento, las últimas seis líneas repentinamente dieron sentido a los centenares de páginas anteriores:

Hay varios cursos públicos, y tenemos conocimiento de que están siendo escritos varios otros libros, que se ocupan de distintos aspectos de UML, todos basados en nuestras publicaciones preliminares previas. Esperamos una amplia difusión de herramientas de soporte, cursos de capacitación y uso de consultores en el futuro. Alentamos fuertemente este tipo de soporte [¡Bien por ustedes al alentar el soporte de sus propios productos! ¡Qué desinteresado!] y trabajaremos conjuntamente con autores, capacitadores y consultores para asegurar que sus consultas sean atendidas, de manera de lograr una difusión y soporte consistentes para UML.

A la espera de una respuesta favorable a mi pedido,
Respetuosamente suyo,
Cándido Smith

Referencias

[1] Rational Software Corporation: 0.8 version of the Unified Method: Notation Summary, en http://www.rational.com.
[2] Rational Software Corporation: 0.91 Addendum to the Unified Modeling Language, en http://www.rational.com.
[3] Kim Waldén and Jean-Marc Nerson: Seamless Object-Oriented Software Architecture: Analysis and Design of Reliable Systems, Prentice Hall, 1995.

Mi conclusión

Más allá de la excelente ironía de Meyer, a modo de resumen me gustaría destacar los siguientes puntos sobre UML:

Es por demás complejo.
No es orientado a objetos.
Carece totalmente de una semántica formal.
Dificulta extremadamente la reversibilidad.

Para finalizar, una famosa frase de C.A.R. Hoare:

. . . Hay dos maneras de construir un diseño de software: una es hacerlo tan
simple que obviamente no tenga deficiencias, y la otra es hacerlo tan complicado
que no tenga deficiencias obvias.

Crear un Blog en Blogger

2010-09-07T05:58:00.001-07:00

El tutorial está dividido en 3 capítulos: Crear un blog , Publicar nuestro mensaje, y Configuración del blog

1º Crear nuestro blog en blogger

Lo primero que vamos a hacer es ir a www.blogger.com y pincharemos sobre el boton que pone Create your blog now:

Vemos cómo se ha abierto esta ventana

SEGUIR EL SIGUIENTE ENLACE
manual-blog-blogger

2010-08-29T19:49:00.000-07:00

(

UML: Casos de Uso. Use case

Desarrollo de Software Orientado a Objetos

Por Joaquin Gracia
27 de Septiembre de 2003

Quien más o quien menos ha visto algún diagrama UML, lo más probable es que te hayas topado con algún diagrama de clases. También es muy probable que hayas visto algún caso de uso (use case), pero… ¿sabes lo que son?
En los libros que tratan de UML, normalmente, los primeros diagramas que presentan, de entre todos los tipos de diagramas UML, son los Casos de Uso. Y como están en los primeros capítulos siempre son leídos y pocas veces bien entendidos.
)

(
Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué). De forma que al ser parte del análisis nos ayudan a describir qué es lo que es sistema debe hacer. Los Casos de Uso son qué hace el sistema desde el punto de vista del usuario. Es decir, describen un uso del sistema y cómo este interactúa con el usuario.

Si te has enfrentado alguna vez a UML normalmente habrás visto algún diagrama de clases y esperarás que los Casos de Uso sean también una forma visual de representar la información. Sin embargo estás muy equivocado, si bien los casos de usos se pueden agrupar en diagramas, los diagramas no son lo importante. Voy a repetirlo para que quede claro, "Los diagramas no son lo importante".

Se que alguno estará impaciente con los diagramas, así que luego los trataré. Pero primero vayamos con lo realmente interesante.
Si lo primordial de los casos de uso (use case) no son los diagramas, entonces ¿que es lo importante? Lo realmente útil de los casos de uso es el documento que describe el caso de uso (use case), en este documento se explica la forma de interactuar entre el sistema y el usuario.
Pero lo más claro es que te presente uno. Este podría ser el caso de uso (use case) de escribir un mensaje en un foro.

Nombre:	Crear mensaje foro
Autor:	Joaquin Gracia
Fecha:	24/08/2003
Descripción: Permite crear un mensaje en el foro de discusión.
Actores: Usuario de Internet logeado.
Precondiciones: El usuario debe haberse logeado en el sistema.
Flujo Normal: El actor pulsa sobre el botón para crear un nuevo mensaje. El sistema muestra una caja de texto para introducir el título del mensaje y una zona de mayor tamaño para introducir el cuerpo del mensaje. El actor introduce el título del mensaje y el cuerpo del mismo. El sistema comprueba la validez de los datos y los almacena.
Flujo Alternativo: El sistema comprueba la validez de los datos, si los datos no son correctos, se avisa al actor de ello permitiéndole que los corrija
Poscondiciones: El mensaje ha sido almacenado en el sistema.

Saltándome los campos evidentes como nombre, autor, fecha y descripción; los actores son aquellos que interactúan con el sistema. Las precondiciones son los hechos que se han de cumplir para que el flujo de evento se pueda llevar a cabo. Luego tenemos el flujo de eventos, que corresponde a la ejecución normal y exitosa del caso de uso (use case). Los flujos alternativos son los que nos permiten indicar qué es lo que hace el sistema en los casos menos frecuentes e inesperados. Por último, las poscondiciones son los hechos que se ha de cumplir si el flujo de eventos normal se ha ejecutado correctamente.
De forma que un caso de uso (use case) es un documento como el anteriormente presentado. Los casos de uso se pueden detallar más o menos dependiendo de la necesidad del problema. El que te he presentado no es completo, si te interesa puedes echar un vistazo a una plantilla completa de un caso de uso (use case), se les suele llamar casos de uso "full-dressed".
Pero no voy a terminar sin explicar, como he prometido antes, los diagramas de casos de uso, que a mi me gusta llamar diagramas de "muñecos y pelotas".

Muñecos y Pelotas

Cuando empiezas a tener un número considerable de casos de uso como el anterior, no resulta nada fácil situarlos y relacionarlos. Entonces empiezas a tener la necesidad de una visión general del asunto, y ahora si, es cuando los diagramas de casos de uso son de utilidad.

En los diagramas de casos de uso los muñecos son los actores y las pelotas son los documentos de casos de uso. Así que dibujas un muñeco por actor y una pelota por cada caso de uso (use case) y los enlazas con líneas cuando haya una relación entre ellos.

Con esto consigues una visión general de cómo los diferentes actores interactúan con los distintos casos de uno.
)

Trabajo de Analisis de Videos Expuestos en Clases

2010-08-29T07:12:00.000-07:00

Trabajo de Analisis de Videos Expuestos en Clases

COMPOSICIÓN DEL DOSIER A ELABORAR POR LOS ALUMNOS

a) Ficha técnica del film.
b) Objetivo que se persigue.
c) Trama (segun materia en la que fue expuesta el film), (de quince a veinte líneas).
d) Descripción de cada uno de los elementos de análisis, señalando su significado y refiriendo su presencia en alguna secuencia de la película.
e) Valoración de la Pelicula o documental dentro nuestro contexto (ocho o nueve líneas).
f) Fuentes de información consultadas.

En el desarrollo de los citados apartados se valorará la corrección en la expresión escrita y la presentación y la disposición estética de los contenidos.

Cómo presentar un Negocio en Powerpoint: La Regla 10/20/30 - Por Guy Kawasaki

2010-08-22T19:36:00.000-07:00

Yo sufro de algo llamado enfermedad de Ménière, pero no se preocupe, no se contagia con la lectura de este post. Los síntomas de la enfermedad de Ménière incluyen pérdida de la audición, tinnitus (un zumbido constante) y vértigo. Hay muchas teorías médicas sobre su causa: exceso de sal, cafeína o alcohol en la dieta, el exceso de estrés y las alergias. Por lo tanto, he trabajado para limitar el control de todos estos factores.

Sin embargo, tengo otra teoría. Como inversor de capital de riesgo, tengo que escuchar a cientos de empresarios en la presentación de sus emprendimientos. La mayoría de estas presentaciones son basura: Sesenta diapositivas sobre: "Una patente pendiente", "La ventaja de ser el primero", "todo lo que tenemos que hacer es conseguir un 1% de la gente en China para comprar nuestro producto" para comenzar. Estas presentaciones son tan malas que estoy perdiendo la vista, tengo un zumbido constante en mi oído, y de vez en cuando el mundo comienza a girar.

Para evitar una epidemia de Ménière en la comunidad de capital de riesgo, estoy evangelizando con la Regla 10/20/30 de PowerPoint. Es muy simple: una presentación en PowerPoint debe tener diez diapositivas, que no duren más de veinte minutos, y que no utilicen ningún tipo de letra de tamaño menor a treinta puntos. A lo largo del tiempo que llevo en el negocio de capitales de riesgo, esta regla se aplica para cualquier presentación para llegar a un acuerdo: por ejemplo, la búsqueda de capital, para hacer una venta, para formar una sociedad, etc.

- Diez diapositivas. Diez es el número óptimo de diapositivas en una presentación de PowerPoint, porque un ser humano normal no puede comprender más de diez conceptos en una reunión y los capitalistas de riesgo son personas muy normales. (La única diferencia entre usted y el capitalista de riesgo es que a él le pagan por jugar con el dinero de otros). Si tiene que usar más de diez diapositivas para explicar su negocio, usted probablemente no tiene un negocio. Los diez temas que un capitalista de riesgo le interesan son los siguientes:

El Problema

Tu solución

El modelo de negocio

Ventaja Competitiva

Marketing y ventas

Competencia

El Equipo

Proyecciones Financieras

Situación Actual y Programa de avance

El Resumen y la necesidad de la acción

- Usted debe exponer las diapositivas diez en veinte minutos. Claro, usted cuenta con un margen de tiempo de una hora, pero estás usando una laptop con Windows, por lo tanto te llevará cuarenta minutos para lograr que funcione con el proyector. Incluso si la configuración va perfectamente, la gente llega tarde y tienen que salir temprano. En un mundo perfecto, usted haría su exposición en veinte minutos, y tendría cuarenta minutos de sobra para el debate.

- Fuente de treinta puntos. La mayoría de las presentaciones que veo tienen texto en una fuente de diez puntos. Se ha amontonado tanto texto como se pudo en la diapositiva y, por consecuencia, el presentador la lee. Sin embargo, tan pronto como la audiencia se da cuenta que usted está leyendo el texto, se hace notorio que puede leer más rápido de lo que puede hablar. El resultado es que usted y el público están fuera de sincronía.

La razón la gente utiliza una fuente pequeña es doble: primero, que no conocen su material lo suficientemente bien, en segundo lugar, piensan que el mucho texto es más convincente. Esfuérzate por no utilizar fuente más pequeña que treinta puntos. Yo le garantizo que va a mejorar su presentación, ya que le exige a usted que encuentre los puntos más importantes y que sepa cómo explicarlos bien. Si "treinta puntos", le parece demasiado dogmático, le ofrezco un algoritmo: averiguar la edad de la mayor persona de su público y lo dividen por dos. Ese es el tamaño óptimo de fuente.

Así que por favor observe la regla de 10/20/30 de PowerPoint. Por lo menos, la próxima vez que alguien en su público se queja de la pérdida de la audición, zumbido o vértigo, usted sabrá qué causó el problema.

Fuente: Extraido del blog de Guy Kawasaki

II CONGRESO DE INGENIERIA CIVIL

2010-08-22T12:25:00.000-07:00

Fábula empresarial: Un camellito Sabio

2010-08-09T22:26:00.000-07:00

Fábula empresarial: Un camellito Sabio

Una madre y un bebé camello estaban descansando, y de repente el bebé camello pregunta...

-...Madre; puedo preguntarte algunas cosas?

Mamá: Claro que sí! Por qué hijo, hay algo que te molesta?

Bebé: por qué los camellos tenemos joroba?

Mamá: mira hijo, nosotros somos animales del desierto, y necesitamos la joroba para guardar agua y podamos sobrevivir sin ella.

Bebé: ¿Bien, entonces por qué son nuestras piernas largas y nuestros patas redondas?

Madre: ¡Hijo, obviamente ellos se adaptan para andar en el desierto, con estas piernas nos podemos mover por el desierto mejor que nadie! Dijo la madre ogullosamente.

Bebé: ¿Bien, entonces por qué son nuestras pestañas tan grandes? A veces esto molesta mi vista

Madre: Hijo mío, aquellas pestañas largas y gruesas son su tapa protectora. Ellos ayudan a proteger tus ojos de la arena de desierto y viento, dijo su madre con ojos llenos de orgullo....

Bebé: ya entiendo. Entonces la joroba debe almacenar el agua cuando estamos en el desierto, las piernas son para andar por el desierto y estas pestañas protegen mis ojos del desierto...

¡Entonces qué demonios estamos haciendo aquí en el zoológico!

Moraleja:

"Habilidades, conocimiento, capacidades y experiencia unicamente son utiles si estas en el lugar correcto"

...¿Donde estas ahora?...

"Ama tu trabajo pero nunca te enamores de tu empresa, porque nunca sabes cuando tu empresa dejara de amarte!!"

Lectura FISH!

2010-08-07T11:58:00.000-07:00

La lectura de este libro les dotara de nuevas formas de afrontar problemas y/o crisis productivos en función a la observación en contexto donde se desarrolla el problema haciendo hincapié en la Actitud como motor del principio del cambio.

José Santander

Fish! No es sólo un libro sobre la empresa, ni sobre cómo mejorar la moral y motivar a los empleados. Es un libro sobre la Vida; sobre la manera en que debemos vivir nuestra vida cotidiana y cómo hemos de relacionarnos con nuestros familiares, nuetsros amigos y las personas que encontramos por la calle. Si utiliza lo que aporta este libro, no sólo mejorará en su trabajo, sinó también como persona lo qesmucho más importante.

Richard Salpizio
presidente de Qualcomun

1.- Desarrollar el Análisis y Resumen de la Obra en IDEOGRAMA y MAPA CONCEPTUAL para su defensa y discusión en Aula.

2.- Realizar el Ensayo de Fish! dentro el contexto nacional de una empresa.

Libro Sistemas Operativos, Andrew S. Tanenbaum

2010-08-06T12:59:00.000-07:00

El libro guía por excelencia de cualquier curso de Sistemas Operativos. Comprende todos conceptos para un curso completo de Sistemas Operativos

Contenido:

Introducción
Procesos
Entrada/Salida
Administración de memoria
Sistemas de archivos
Lista de lecturas y bibliografía
Apéndices
El código fuente de MINIX
Indice de archivos
Índice de símbolos

Descargar por MEGAUPLOAD
Descargar por HotShare

INGENIERIA DE LA PRODUCCION

2010-08-06T08:20:00.000-07:00

LAS CLASES DEL DIA SABADO 7 DE AGOSTO QUEDAN SUSPENDIDAS

FELIZ DIA DE LA PATRIA

Que Es Moodle?

2010-07-05T11:53:00.000-07:00

2do TURNO gestion 1/2010

2010-06-25T15:00:00.000-07:00

ALGEBRA

1.-9111069

2.-9234785

(MIERCOLES 30 DE JUNIO DE 2010 19:00)

SISTEMAS OPERATIVOS

1.-6146918
2.-4907717

3.-6086089

(JUEVES 01 DE JULIO DE 2010 09:00 LABORATORIO)

FISICA II

1.-7057123

2.-4964577

3.-6894139

(MIERCOLES 30 DE JUNIO DE 2010 11:00 AM)

ING. DE PRODUCCION

1.-5471898

2.-2201462

(MARTES 29 DE JUNIO DE 2010 PRESENTAR PROYECTO HASTA LAS 19:00)

INFORMATICA I EL ALTO

1.-6052428

(JUEVES 01 DE JULIO DE 2010 19:00 LABORATORIO)

INFORMATICA II EL ALTO

1.-6864121

2.-6058137

3.-4292940

4.-3408005

(JUEVES 01 DE JULIO DE 2010 19:00 LABORATORIO)

INFORMATICA II LA PAZ
(JUEVES 01 DE JULIO DE 2010 19:00 LABORATORIO EL ALTO)

1.-4946847

LIBRO de Hormigon Armado - J. Montoya

2010-06-17T13:58:00.000-07:00

Hormigon Armado - J. Montoya

Descripcion

Este libro, ya un clásico en su género, constituye la obra de mayor tirada en Europa sobre hormigón armado. Es un libro imprescindible, no sólo para los proyectistas y constructores sino también para los alumnos de las escuelas de ingeniería y arquitectura. La presente edición está totalmente reformada y se adapta a la nueva instrucción española EHE, con numerosas referencias al Código ACI norteamericano y al Eurocódigo europeo EC-2. Recoge los últimos avances en materia de diseño, cálculo y ejecución de estructuras de hormigón armado, desde el estudio, ensayo y control de calidad de los materiales hasta el proyecto, cálculo y armado de los distintos elementos estructurales, sin olvidar aspectos tan esenciales como la patología del hormigón armado y la durabilidad de las estructuras construidas en ese material. Los autores han preparado, aparte de de tablas, ábacos y diagramas de cálculos, numerosos ejemplos y formulas simplificadas para facilitar la aplicación de la normativa más moderna.

PDF | Español | 40Mb

(Descarga)

PRACTICA DE INFORMATICA UTB EL ALTO

2010-06-17T13:52:00.000-07:00

Desarrollar cada proyecto en Excel usando funciones y programación en VBA de tal manera que el uso de estas herramientas sea intuitivo.

PUEDEN VISITAR LA SIGUIENTE PAGINA:

http://elsergiodelpino.wordpress.com/

LOS ALUMNOS DESIGNADOS PARA DEFENDER EL PROYECTO NO PUEDEN CAMBIAR DE ROL.

EN CASO DE QUE ALGUN ESTUDIANTE NO PARTICIPE EL OTRO ALUMNO PUEDE DEFENDER Y ENTREGAR INDIVIDUALMENTE LO CUAL SERA PONDERADO

SI DESEAN CAMBIAR DE PROYECTO MANDEN AL CORREO josesantander@walla.com o llamar al 79158729 hasta el viernes y esperar confirmacion.

--------------------------------------------------------------------------

ALUMNO 1	ALUMNO 2 DEFIENDE EL PROYECTO	PROYECTOS
ESPINOZA QUINTEROS JORGE LUIS	CARRILLO CUSI SILVIO	DIMENSIONAMIENTO ZAPATA CON CARGA AXIAL
NINA MACHACA EDWIN	ARENAS CHAMBI CRISTHIAN RICHARD	Cálculo para Estructuras Mixtas ESTRUCTURAS
MAMANI MERCADO HANNS ROMER	ARUQUIPA AROBA ALFREDO	CALCULO DE ZAPATAS
NINA CHOQUE REMMY RAMIRO	MACHACA COTA JHONNY FRANKLIN	CALCULO DE VIGAS
LUQUE QUISPE MARINA ROXANA	ESCOBAR TITO SOFIA	CALCULO DE MUROS DE CONTENSION (Muros de contención)
QUISPE TAPIA DAVID	LIMACHI OSCO PORFIRIO STEPHEN	CALCULO DE ZAPATAS
RIVERA ASPIAZU WILLIAMS IVAN		Calculo de placas de Hormigon Armado Placas de hormigon
CAHUAYA QUISPE FREDDY	MARQUEZ CONDORI ISIDRO	Cálculo de soportes o de pilares tanto cuadrados como rectangulares Soportes Seccion cuadrada sin pandeo
QUISPE HUANCA FREDDY ANGEL	SARZURI HUANCA PRIMITIVO	Calculo de Punzonamiento en Pilares punzonamiento
ROSA MAMANI JAIME	PILLCO CALLA PRIMITIVO	Cálculo de Depósitos

CENTRO FUNCION DE CAMBIO

2010-06-11T15:42:00.000-07:00

PARA OFRECERLES UN MEJOR SERVICIO CAMBIAMOS NUESTRO DOMINIO

http://www.fundecam.net/

Centro Función de Cambio

PRESENTACION DE ANALISIS DE SISTEMAS

EXAMEN DE 2DA OPORTUNIDAD

REVISTAS

libros para todos

Lanzamiento Intercup Bolivia

Lapazvalley

SOFTWARE FREEDOM DAY

Guias para Censos y Encuestas

Guias para Analisis de Sistemas 2

UML en LINEA

¡Diagramemos!

Por qué UML no sirve (lectura para Analisis de Sistemas 2)

UML: El giro positivo

Estimado Profesor Stern:

¡Se positivo!

¿Orientado a Objetos?

Encontrando un uso para UML

Amanda al rescate

¿La respuesta al final?

Referencias

Mi conclusión

Crear un Blog en Blogger

UML: Casos de Uso. Use case

Desarrollo de Software Orientado a Objetos

Muñecos y Pelotas

Trabajo de Analisis de Videos Expuestos en Clases

Cómo presentar un Negocio en Powerpoint: La Regla 10/20/30 - Por Guy Kawasaki

II CONGRESO DE INGENIERIA CIVIL

Fábula empresarial: Un camellito Sabio

Fábula empresarial: Un camellito Sabio

Lectura FISH!

Libro Sistemas Operativos, Andrew S. Tanenbaum

El libro guía por excelencia de cualquier curso de Sistemas Operativos. Comprende todos conceptos para un curso completo de Sistemas Operativos

INGENIERIA DE LA PRODUCCION

Que Es Moodle?

2do TURNO gestion 1/2010

LIBRO de Hormigon Armado - J. Montoya

PRACTICA DE INFORMATICA UTB EL ALTO

Cálculo para Estructuras Mixtas

Cálculo de soportes o de pilares tanto cuadrados como rectangulares

CENTRO FUNCION DE CAMBIO