martes, 25 de septiembre de 2012

Lenguaje Unificado de Modelado


Lenguaje Unificado de Modelado:

 (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos.

 Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

Estandarización del UML.

Desde el año 1995, UML es un estándar aprobado por la ISO como ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Versión 1.4.2.

Critica.
A pesar de su estatus de estándar internacionalmente reconocido y utilizado, UML siempre ha sido criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con facilidad al diseño de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisión, serialización, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para señalar que un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecución del sistema analizado. Sin embargo, UML sí acepta la creación de nuestros propios elementos para este tipo de modelado, incluso cuenta con la posibilidad de agregar comentarios en forma de notas en las cuales se puede detallar todo aquello que no pueda ser expresado por la versión actual de la notación. Algo parecido ocurría anteriormente con el diseño de Base de Datos y para ello se utilizaban las restricciones explícitas escritas en lógica simbólica.

Entorno de desarrollo integrado

Herramienta CASE

Técnica de Modelado a Objetos

Programación orientada a objetos

XMI, un formato estándar basado en XML para el intercambio de modelos UML.

OCL, Lenguaje de especificación para los diferentes modelos en UML.

EEYORE¹

Webml, Metodología para el diseño de Sistemas de Información Web.

Categoría:Herramientas UML


Metodología de RUP

Metodología de RUP.

El Rational Unified Process o Proceso Unificado de Racional. Es un proceso de ingeniería de software que suministra un enfoque para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es asegurar la producción de software de alta calidad que satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto previsible. Es una metodología de desarrollo iterativo enfocada hacia “los casos de uso, manejo de riesgos y el manejo de la arquitectura”.

El RUP mejora la productividad del equipo ya que permite que cada miembro del grupo sin importar su responsabilidad específica acceda a la misma base de datos de conocimiento. Esto hace que todos compartan el mismo lenguaje, la misma visión y el mismo proceso acerca de cómo desarrollar software.

El RUP maneja el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable.

FASES

FASE DE INICIO:

Durante esta fase de inicio las iteraciones se centran con mayor énfasis en las actividades de modelamiento de la empresa y en sus requerimientos.

FASE DE ELABORACIÓN:

Durante esta fase de elaboración, las iteraciones se centran al desarrollo de la base de la diseño, encierran más los flujos de trabajo de requerimientos, modelo de la organización, análisis, diseño y una parte de implementación orientada a la base de la construcción.

FASE DE CONSTRUCCIÓN:

Durante esta fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones las cuales se seleccionan algunos Casos de Uso, se redefine su análisis y diseño y se procede a su implantación y pruebas. En esta fase se realiza una pequeña cascada  para cada ciclo, se realizan tantas iteraciones hasta que se termine la nueva implementación del producto.

FASE DE TRANSICIÓN

Durante esta fase de transición busca garantizar que se tiene un producto preparado para su entrega al usuario.

PRINCIPALES CARACTERÍSTICAS
  • Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
  • Pretende implementar las mejores prácticas en Ingeniería de Software
  • Desarrollo iterativo
  • Administración de requisitos
  • Uso de arquitectura basada en componentes
  • Control de cambios
  • Modelado visual del software
  • Verificación de la calidad del software 

Comentario del alumno:
Como ya se ha mencionado la Metodología de RUP es importante en el momento de la planeación y el desarrollo de un proyecto en Ing. de Software ya que nos ayudara a tener una correcta planeación y asignación de las diferentes tareas del desarrollo del proyecto, otra gran ventaja que es que sin importar que tarea tenga asignada cada integrante del proyecto podrá tener acceso a la información y a la idea principal del proyecto esa es una ventaja que considero importante ya que en algunos trabajos muchos de los integrantes no tienen la idea principal o se pierden en el proceso del desarrollo ya que se enfocan a la tarea que seles asigno y solo tienen acceso a todo el desarrollo del proyecto, por eso considero que esta es otra característica importante por mencionar.


domingo, 2 de septiembre de 2012

Conclusión de los 3 vídeos

Chiquitos:
Este vídeo ya tenia un tiempo que lo había visto y me gusta mucho por que habla de muchas cosas como nunca dejar que otras personas te digan que lo que tu quieres hacer esta mal o que es una locura y que jamas podrás lograr la meta que te haz propuesto, que siempre hay que confiar en nuestras deciciones y en lo que hacemos para que asi las personas que nos rodean veran el cambio veran que todo se puede siempre y cuando uno se esfuerce al maximo por alcanzar esa meta deseada, nunca hay que meterle a los retos por mas grandes y difíciles que parezcan hay que tenerles. Siempre insistir e insistir hasta poderlo lograr, que la clave de todo éxito es nunca tener el miedo a fracasar y si por alguna razón no se logra la meta en el primer intento, detenerte analizar el problema que es lo que nos esta faltando para poder lograrlo y segir intentando con mas y mas ganas hasta tratando de solucionar lo que nos falto y por lo que fallamos. Ese es el mensaje que yo entendí de el vídeo de los chiquitos es un vídeo que la verdad me agrada mucho por los mensajes que este contiene y que si los sabes apreciar y tomar para ti pueden servirte a lo largo de toda tu vida.

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

¿Quien movió mi queso?
Este vídeo me pareció sumamente interesante ya que habla de la comodidad que siente uno al tener algo que quiere mucho y es  muy cierto cuando nos sentimos codos con algo nos aferramos a ello y no buscamos mejorar buscar nuevas cosas, conocer algo mejor, explorar nuestro entorno y disfrutar lo bueno o nuevo que tiene para nosotros. Hay que recordar que el cambio las nuevas cosas siempre están presentes y que si uno no se adapta a esas nuevas cosas nuevos entornos esta perdido por que no estará actualizado perderá todo por que alguien le quito esa comodidad que tenia de lo fácil y de lo cotidiano, esto nos dice que siempre siempre hay que estar activos y buscar nuevas cosas siempre con las ganas y el gusto de llegar a conocer algo nuevo así nunca te quedaras atrás siempre estar con algo nuevo y claro en el trascurso de ese cambio disfrutarlo siempre nuca hay que hacer las cosas disgustado por que así nada saldrá bien tenemos que siempre hacer las cosas con gusto para que todo mejore lo que tenga que mejorar siempre sea bueno. En pocas y resumidas palabras, nunca hay que conformarnos con lo que ya tenemos, siempre hay que ir en búsqueda de algo nuevo, disfrutar del proceso de cambio y siempre estar alertar por que alguien en cualquier momento puede mover tu queso y si no estas listo para cuando eso pase estarás perdido.


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

Delfines
El mensaje o lo que yo puedo concluir de el vídeo de los delfines es que siempre trabajando en equipo las cosas pueden ser mejores algo nuevo puede surgir y es curioso pero en los otros vídeos se muestra que siempre el trabajo en equipo sera de suma importancia por que eso nos puede ayudar a poder alcanzar nuestras metas poder lograr trascender con el apoyo y la ayuda de nuestros comprañeros como en el video de lso chiquitos o como en el video de quien movio mi queso si hay alguien pesimista y conformista que no le guste apoyar que no le guste buscar crear estar trabajando y en constante movimiento nos nos puede retrasar en nuestro porceso de alcanzar la meta. En tonces es importante trabajar en aquipo y sabes cuando alguien no nos ara bien por que esa persona sin querer nos puede frenar o hasta incluso convenser de fallar ates de intentarlo. Ese es el mensaje que yo entendi del video de los delfines






Algunos de los errores informáticos


Error de división del Intel Pentium (1994)


Intel llegó, en octubre de 1994, a crear el P54C, una versión revisada del Pentium que, además de bajar el voltaje a 3.3v, también permitió elevar las velocidades de reloj a 75, 90 y 100 mega hertz respectivamente. Sin embargo, hubo dos puntos muy importantes que jugaron en contra de la adopción del Pentium: Los nuevos P54C requerían un nuevo zócalo, el socket 5, que no era retrocompatible con el zócalo anterior. Y lo más importante, fue que se descubrió un bug en la unidad de punto flotante integrada en el diseño del Pentium, que se popularizó como el "bug FDIV". Lo que realmente causó problemas no fue el error en sí, sino el hecho de que Intel hubiera estado consciente del mismo cinco meses antes de que fuera reportado por el profesor Thomas Nicely del Lynchburg College, mientras trabajaba con el procesador sobre la Constante de Brun.

Estas comprobaciones crearon una gran polémica. Pero Intel negó inicialmente la existencia del problema.

Más tarde, Intel remarcó la insignificancia de los defectos de sus microprocesadores, queriendo tranquilizar a los usuarios. Intel se negó a sustituir sistemáticamente los microprocesadores defectuosos; sin embargo, si una persona podía demostrar que había sido afectada por el error, entonces Intel procedería a cambiar su procesador. Aunque evaluaciones efectuadas por organismos independientes mostraron la poca importancia de las consecuencias de error y que el efecto era desdeñable en la mayoría de las ocasiones, se provocó una situación en la que los usuarios de Intel Pentium demandaban el reemplazo de los procesadores defectuosos. Empresas como IBM se unieron a la denuncia. Al final, Intel se vio forzada a aceptar sustituir todos los microprocesadores defectuosos, lo que le representó un coste enorme.

La empresa Intel pierde 475 millones de dólares y credibilidad en sus porocesadores


Opinión del Alumno:

He aquí la falta de un buen diseño a la hora de elaborar un dispositivo y mas aun mas grabe es que al momento de reconocer he identificar el problema no se tomaron acciones inmediatas y pues todo el problema que le causo a Intel en esos momentos por que no solo fue la gran perdida monetaria que seles presento al momento de verse obligados a cambiar todos los procesadores defectuosos si no el prestigio que se pierde con los clientes ya que me imagino que muchos de los que fueron retribuidos ya desconfiaban del diseño o la capacidad que tenia Intel para el desarrollo y la inovación de sus procesadores es por ellos que un equipo software o lo que se quiera sacar al mercado debe ser revisado meticulosamente para evitar fallas como esta y así evitar perdidas a las empresas


&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&



MIM-104 Patriot

El MIM-104 Patriot es un sistema de misiles tierra-aire de largo alcance fabricado por la compañía norteamericana Raytheon. Creados para reemplazar a los Nike-Hercules como misiles de altitud media-alta, los Patriot se hicieron populares tras la Guerra del Golfo, donde se usaron masivamente.

El sistema Patriot fue concebido en los años 60, fabricado a partir del año 1976 para usos antiaéreos y fue distribuido en 1984. Años después fue adaptado para funcionar como un sistema de interceptación de misiles balísticos denominado PAC (Patriot Advanced Capability). El sistema usa el sistema de guía Track-vía-Missile y un terminal de radar.


Antes de la Guerra del Golfo, los sistemas de defensa antimisiles eran un concepto de guerra sin probar. El objetivo de los Patriot era abatir los misiles Scud o Al Hussein lanzados por Irak sobre Israel y Arabia Saudí. La primera vez que se usaron los Patriot fue el 18 de enero de 1991, consiguiendo interceptar y destruir un misil Scud iraquí lanzado sobre Arabia Saudí. Fue la primera vez en la historia que un sistema antiaéreo destruía un misil balístico enemigo


El error de Dharan


El 25 de febrero de 1991, un Scud iraquí alcanzó un cuartel norteamericano en Dharan, Arabia Saudí, matando a 28 soldados.

Una investigación del Gobierno de los Estados Unidos dictaminó que el error de interceptación en Dharan se debió a un error de software en el reloj del sistema. La batería Patriot de Dharan había estado activada durante 100 horas, tras las cuales el reloj se había retrasado un tercio de segundo, equivalente a un error de posición de 600 metros. El sistema de radar detectó el Scud y buscó el lugar donde estaría instantes después para poder interceptarlo. Pero debido al error del reloj, el radar buscó en un lugar que no era y no encontró misil alguno. De este modo el sistema asumió que se trataba de una falsa alarma y dejó de rastrear al Scud. Los israelíes habían identificado el problema y habían informado al ejército norteamericano y al Proyecto Patriot (programador del software) el 11 de febrero de 1991. Los expertos israelíes habían recomendado reiniciar el sistema informático como solución temporal; sin embargo, los oficiales estadounidenses no entendieron con qué frecuencia debían llevar a cabo esta operación. El fabricante de los Patriot envió el software actualizado al ejército el 26 de febrero, pero llegó al lugar de operaciones demasiado tarde: justo el día después del ataque.

Opinión del alumno:

En mi opinión un error fatal en el diseño del software y un problema muy grave fue que no estaba actualizado con lo que he visto que refiere a la ingeniera de sftware se deben tomar todas las medidas y todas las variables que pueda existir para que el sistema nunca falle y mas en sistemas de gran importancia como el que tenia el Patriot por la falla que hubo en el software ocaciona que 28 soldados murieron por esa falla. Por eso siempre es importante revisar y diseñar bien un software para que al momento de salir al mercado no tenga fallas y no ocacione perdidas tan trágicas.


&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&




He aquí algunos de los desastres mas grandes de la 
historia relacionadas por el fallo del software 



Los fallos en software cuestan a la economía de los Estados Unidos 60.000 millones de dólares en revisiones, pérdida de productividad y daños reales. Todos sabemos que los errores de programación puede ser molestos, pero además, un software defectuoso puede salir caro, incómodo, destructivo e incluso mortal.



1. Marinero sin rumbo (1962) 

Coste: 18,5 millones de dólares. 

Desastre: El cohete Mariner 1, en una investigación espacial destinada a Venus, se desvió de su trayectoria de vuelo poco después de su lanzamiento. El control de la misión destruyó el cohete pasados 293 segundos desde el despegue. 

Causa: Un programador codificó incorrectamente en el software una fórmula manuscrita, saltándose un simple guión sobre una expresión. Sin la función de suavizado indicada por este símbolo, el software interpretó como serias las variaciones normales de velocidad y causó correcciones erróneas en el rumbo que hicieron que el cohete saliera de su trayectoria.


2. El hundimiento del Hartford Coliseum (1978) 

Coste: 70 millones de dólares, más otros 20 millones en daños a la economía local. 

Desastre: Sólo unas horas después de que miles de aficionados al hockey abandonaran el Hartford Coliseum, la estructura de acero de su techo se desplomaba debido al peso de la nieve. 

Causa: El desarrollador del software de diseño asistido (CAD) utilizado para diseñar el coliseo asumió incorrectamente que los soportes de acero del techo sólo debían aguantar la compresión de la propia estructura. Sin embargo, cuando uno de estos soportes se dobló debido al peso de la nieve, inició una reacción en cadena que hizo caer a las demás secciones del techo como si se tratara de piezas de dominó.


3. La CIA le da gas a los soviéticos (1982) 

Coste: Millones de dólares, daño significativo a la economía soviética. 



Desastre: El software de control se volvió loco y produjo una presión excesiva en la tubería de gas transsiberiana, provocando la mayor explosión no nuclear, causada por el hombre, de la historia de la tierra. 

Causa: los agentes de la CIA supuestamente introdujeron un error en el sistema informático canadiense adquirido por los soviéticos para controlar sus tuberías de gas. La compra era parte de un estratégico plan soviético para robar u obtener de forma encubierta tecnología secreta de los Estados Unidos. Cuando la CIA descubrió la compra, sabotearon el software de forma que éste superara la inspección soviética pero fallara una vez operativo. 


4.- La Tercera Guerra Mundial… o casi (1983) 

Coste: prácticamente toda la humanidad. 

Desastre:: El sistema soviético de alerta temprana indicó erróneamente que los Estados Unidos habían lanzado cinco misiles balísticos. Afortunadamente, el oficial de servicio, con un gran instinto, razonó que si realmente les estuvieran atacando les habrían lanzado más de cinco misiles, por lo que informó del aparente ataque como una falsa alarma. 

Causa: un error en el software soviético hizo que los efectos de la reflexión de la luz solar en las nubes fueran considerados misiles por el sistema. 


5.- Muerte de las líneas de AT&T (1990)

Coste: 75 millones de llamadas telefónicas afectadas; 200.000 reservas de vuelo perdidas. 

Desastre: un simple conmutador de uno de los 114 centros de conmutación de AT&T sufrió un pequeño problema mecánico y desactivó el centro. Cuando éste volvió a estar habilitado, envió un mensaje a los otros nodos haciendo que todos ellos dejaran de funcionar, lo que provocó una caída de 9 horas en la red de la compañía. 

Causa: Una simple línea de código errónea en una compleja actualización de software destinada a acelerar las llamadas provocó una reacción que echó abajo la red. 


Opinión  del Alumno:

Como se menciona al principio de esta parte de los errores mas grandes en el software, se pierde mucho dinero por causa de estos problemas y en ocaciones no solo es dinero lo que se llega a perder como el caso del sistema del Patriot que hubo perdidas humanas implicadas en la tragedia. Es claro que un error no puede ser aceptado en la creación de un software ya que esto puede araigar una gran cantidad de problemas y perdidas, por ellos se debe ser extremanada mense cuidadoso al momento de elaborar un software, ser minucioso en los detalles para poder entregar un producto de calidad y que la eficiencia sea casi perfecta. 








domingo, 26 de agosto de 2012

Ingeniería en software


Opinión:

La Ingeniería en software es una materia o disciplina en la cual requiere como objetivo resolver todo tipo de problemas con métodos y técnicas desarrolladas para implementar un software que nos ayude en la solución de dicho problema con la mejor calidad y eficiencia a un precio justo, esto es importante ya que las empresas hoy en día lo que busca en un ingeniero es que resuelva las problemáticas de la empresa con gran eficiencia aprovechando los recursos al 100% y con un coto menor para así obtener mayor utilidad, en opinión mía la ingeniera en software hoy en día es una disciplinas demandadas ya que la necesidad de empresas es la creación de sistemas o software que les brinden mayor producción y elevación de rendimiento y utilidad con el menor gasto posible, eso es lo que se busca en un ingeniero en software buena calidad, buena habilidad identificando problemas e implementar soluciones a ellos con el menor coto pábleme.

Visión:

Elaborar software de aplicación como una herramienta que nos permita simplificar el trabajo, reducir los cotos en las industrias y resolver o prevenir posibles problemas. 

miércoles, 22 de agosto de 2012

mi primer aporte en este blog

bueno este es uno de muchos aportes o cometario que are para la profesora de Ing. de Software

esto mas que nada es para aprender sobre los blogs por que sinceramente sera la primera vez que lo utilizare  

Blog de tareas Ing. software