CAPÍTULOS:
- QUÉ ES ORGANIZACIÓN DE COMPUTADORES
- EL SOFTWARE
- EL HARDWARE
4.-INTERNET
- SISTEMAS OPERATIVOS
- PROTOCOLOS
- DOMINIOS DE LA WEB
- TERRORISMO INFORMÁTICO
- VIRUS INFORMÁTICOS
- LOS HACKERS
- ATAQUES CIBERNÉTICOS
- SECUESTROS INFORMÁTICOS
ORGANIZACION DE COMPUTADORES
SECUESTROS INFORMÁTICOS
El Secuestro Virtual: Es un secuestro que no existe, en donde los “secuestradores” se aprovechan la ausencia de una persona para extorsionar a su familia y obtener montos de cifras fáciles de reunir en un par de horas.
El fenómeno de los secuestros “virtuales” empezó a presentarse aproximadamente en el año 2003. La base de esta estafa está en que quien pide el rescate no tiene a nadie secuestrado. Busca, en general al azar, alguien a quien llamar y lo hace entrar en el engaño. Lo apura para que pague antes de que pueda confirmar, por algún lado, que ninguno de sus familiares está cautivo. Y cobra el rescate también en forma virtual: obliga a la víctima a comprar tarjetas prepagas con pulsos telefónicos. Ya que el falso secuestrador, se determinó, suele estar encerrado en una cárcel, donde las tarjetas equivalen a efectivo en la mano.
SECUESTROS WAP
Una realidad que las autoridades tratan, con poco éxito, de erradicar. En los últimos meses los delincuentes dedicados al “secuestro virtual” han obtenido, con tan solo una tercera parte de las llamadas cerca de 20 millones de dólares, llevando a la ruina moral y económica a sus víctimas, mientras sus seres queridos están a salvo y ajenos a este drama.
CARLOS MACHADO HISTORIA
El 20 de agosto Carlos Machado leyó lo que nunca quiso leer: su hija había sido secuestrada. El mensaje había llegado al correo electrónico de su otra hija y en él se pedía un monto en dólares por el rescate y se adjuntaba como prueba del secuestro una foto de la menor ausente, que estaba cautiva desde hacía nueve días. En la imagen, la quinceañera sostenía un diario del día, lo que aseguraba que era una foto actual.
El último sábado fue liberada sana y salva, y Carlos respiró por fin tranquilo luego de 38 días de incertidumbre. El padre dice que todo fue como una pesadilla, que recibía correos electrónicos advirtiéndole que si no pagaba el monto exigido matarían su hija. Los e-mails los enviaba Julio César Quiroz Hipólito, el cabecilla de la banda de secuestradores, hoy detenido.
La hija de Carlos, como muchas chicas y chicos de su generación, entienden el mundo con Internet. Hacen amigos a través de redes sociales, conversan con ellos mediante servicios de chat y se enteran de trabajos por la web. Y fue justamente a través de Internet que los plagiarios captaron su atención. El jefe de la División de Secuestros, coronel PNP Jorge Mejía, dijo que esta ha sido la primera vez que se realiza un secuestro con este método en el país.
Ella vio en Internet una oferta de trabajo de solo dos días y mil soles de remuneración. Le llamó la atención y se contactó. Finalmente, el 11 de agosto la hoy detenida Miriam Quispe Carhuachi condujo a la joven hasta una supuesta entrevista de trabajo. Era en una casa en la urbanización San Germán, en San Martín de Porres. Ahí la mantuvieron en cautiverio.
Carlos Machado siguió recibiendo correos de los captores. Acordaron un monto. Manuel siguió las órdenes que le dieron: fue a Huancayo y depositó el dinero en una cuenta bancaria. En La Victoria, Juan Nicomedes Arocutipa Ramos retiraba el dinero y salía sin saber que era vigilado por los agentes de la Dirincri. Luego fue capturado en San Juan de Lurigancho.
Ninguno de los cinco detenidos por la policía (los otros dos son Wilfredo Quispelaya Jipa y Wilfredo Taracaya Yupanqui) tenía antecedentes.
SECUESTROS WAP
Ciudad de México– La llamada telefónica empieza con los gritos de un niño angustiado que llama a uno de sus padres. “¡Mamá! ¡Papá!” El llanto del niño va seguido de una ronca voz masculina que no se anda con cuentos.
“Tenemos a su hijo”, dice rápidamente, y por lo general añade una grosería para intimidar; luego expone una lista de exigencias que podrían ser dinero o joyas que deben dejarse en cierta esquina, o un considerable depósito que ha de hacerse en una cuenta de un banco local.
El giro de esta historia es que Pablito o Teresita están a salvo en la escuela, y no atados con cinta plateada a una silla en una destartalada casa, ni metidos en el portaequipaje de un taxi. Pero cuando llega la llamada desde un teléfono celular, eso no se sabe.
Esto es un “secuestro virtual”, el nombre que se da en México a la última modalidad criminal, que se ha aprovechado de los maltrechos nervios de un país aterrorizado por los secuestros reales desde hace muchos años.
“Esto refleja el temor de la sociedad mexicana, la psicosis colectiva en torno a los secuestros”, dice Adrienne Bard, periodista de radio estadounidense que ha vivido en México por más de 20 años y quien recibió una llamada en marzo de una joven en lágrimas que ella, por el susto, pensó que era su propia hija, estudiante universitaria. “Caí completamente en la trampa”, confiesa. Lo mismo les ha ocurrido a muchos otros. Joel Ortega, jefe de la policía de la Ciudad de México, anunció recientemente que una nueva línea de emergencia que se abrió para atender este problema recibió más de 30 mil quejas desde el pasado diciembre hasta principios de enero. Ha habido ocho arrestos y se han identificado tres mil 415 números telefónicos usados por los extorsionadores, dice.
Pero identificar los números de teléfono –hoy aparecen en un sitio Web del gobierno– ha servido de muy poco para detener las llamadas criminales. Casi todas se hacen desde teléfonos celulares, la mayor parte robados.
Por si fuera poco, se cree que muchos extorsionadores operan desde las cárceles.
Dicen las autoridades que hay cientos de bandas criminales involucradas en diversos timos telefónicos. Además de los falsos secuestros, quienes llaman anuncian a las personas que se han ganado un auto o dinero. A veces les piden que apaguen sus celulares durante una hora para que pueda repararse el servicio; luego llaman a los familiares y les dicen que el dueño del teléfono celular ha sido secuestrado. Estos falsos secuestradores han recurrido incluso a los mensajes de texto.
De los relativamente pocos arrestos que se han hecho hasta ahora, tres sospechosos eran hermanos, de 19, 31 y 34 años, a quienes se atrapó cuando recibían dinero de una víctima. Los dos hermanos menores culparon al mayor de obligarlos a delinquir.
Además de las líneas de emergencia para reportar las llamadas, los funcionarios han pedido a las compañías de telefonía celular que lleven un mejor registro de sus usuarios para ayudar en las investigaciones. Pero los intentos de proscribir los celulares de las prisiones no han fructificado aún. Este tipo de teléfonos no se permite en las cárceles, pero los internos casi siempre sobornan a los guardias para que hagan la vista gorda.
Unos periodistas locales visitaron recientemente una prisión al norte de la Ciudad de México y vieron que los teléfonos celulares se usaban abiertamente. Los internos calcularon que había en la prisión entre 500 y 600 celulares, y dijeron que la suma para sobornar a los guardias era de 50 dólares a la semana, reportó el periódico El Norte.
En esa prisión, las autoridades trataron de bloquear la señal, pero los internos al parecer descubrieron ciertos lugares en el patio donde aún llegaba.
HISTORIA
Hace un año, cuando Tatiana Kaler contestó al teléfono, se quedó sin palabras, el hombre que la llamaba afirmó que había secuestrado a su madre. Tatiana acababa de despertarse, estaba sola en su casa y alguien le estaba pidiendo dinero a cambio de la vida de su madre.
Tatiana cooperó y le dio al hombre su número de celular, al cual él llamó en seguida. El teléfono de la casa y su celular estaban ocupados: todo estaba perfectamente arreglado.
“Tuve miedo porque no había visto a mi madre la noche anterior, y me llamaban en ese momento… y estaba sola,” dijo Tatiana, 24 años. “Parecía muy extraño, pero creí en esa historia.”
Para salvar la vida de su madre, Tatiana siguió las instrucciones del secuestrador: puso un poco más de 900 pesos en un bolso y lo tiró por el balcón del departamento. Una vez que los criminales – en realidad eran dos – tuvieron el dinero, colgaron los dos teléfonos.
La madre de la porteña, sin embargo, nunca había estado en peligro: sólo se encontraba fuera de la ciudad. Tatiana había sido engañada creyendo que su madre había sido secuestrada. Ella se había vuelto una víctima de un falso secuestro.
Secuestro virtual
Todo comenzó a las 9.30 de hoy cuando Azulay recibió un llamado en su oficina de la calle Chile al 800, en el barrio de San Telmo, en el que un delincuente le advirtió que tenía secuestrado a un familiar suyo, aunque en realidad se trataba de una farsa.
Desesperado ante la posibilidad de que algún pariente estuviera cautivo, Azulay acordó con el delincuente pagar un rescate de mil pesos en un sitio que la policía aún no pudo determinar.
Los investigadores creen que los delincuentes, al ver llegar a Azulay al sitio pactado bien vestido y con un buen auto, decidieron transformar lo que era un secuestro virtual en un verdadero secuestro extorsivo, por lo que lo amenazaron con un arma y lo capturaron.
Los voceros indicaron que los captores se comunicaron nuevamente con la oficina de Azulay, donde atendió su socio, a quien le comunicaron que querían 10 mil pesos de rescate por el despachante de aduanas.
El socio de Azulay pactó el pago del rescate en el barrio porteño de Mataderos, en la esquina de las calles White y Eva Perón.
Tanto el funcionario Marino como el jefe policial Seisdedos revelaron que, en ese lugar, el socio de Azulay le entregó los 10 mil pesos a los delincuentes, quienes prometieron liberar a su víctima en pocos minutos.
Sin embargo, Azulay recién apareció al mediodía, cuando fue encontrado por un remisero tirado al costado de la avenida General Paz, del lado de provincia, en inmediaciones de la villa Las Antenas de La Matanza.
La hermana de la víctima dijo a Canal 13 que los propios delincuentes habrían sido quienes llamaron a la remisería para decir que tenían que trasladar a "una persona mayor que estaba enferma".
Un vocero judicial indicó a Télam que el remisero y un policía bonaerense llegaron a las 12.15 con Azulay baleado al Hospital Santojanni, donde finalmente murió.
Fuentes judiciales porteñas y de la Policía Federal indicaron que ni el secuestro virtual inicial, ni el secuestro de Azulay fueron denunciados mientras transcurrían.
La historia del secuestro recién fue contada por el socio de la víctima cuando apareció Azulay en el Hospital Santojanni.
El caso es investigado por dos fiscales que luego discutirán la competencia.
Por la aparición de Azulay en la General Paz, interviene el fiscal de La Matanza Claudio Polero, pero como su muerte fue en el Hospital Santojanni, intervino la comisaría 42, con la que está de turno el fiscal de instrucción porteño Joaquín Rovira.
Sin embargo, como se trató de un secuestro extorsivo, la investigación podría terminar en las manos del fiscal federal porteño de turno, Carlos Rívolo, quien, según fuentes judiciales, ya se anticipó y pidió que la Brigada Antisecuestros de la Policía Federal trabaje en el caso.
Secuestro virtual
La historia se repite con leves modificaciones todo el tiempo: llaman a tu casa, indagan con poca sutileza acerca de la composición familiar y luego (en el mismo o en otro llamado) afirman que justo ese miembro de la familia que no se encuentra en la casa está secuestrado y a veces malherido, y que el pago de un rescate con lo que tengas en ese momento es la condición para liberarlo.
El secuestrado, ignorante de la situación, está fuera de casa pero por los motivos más triviales (trabajando, en una fiesta, haciendo mandados, o simplemente ya se ha independizado y no vive más allí).
Anoche le sucedió a mi suegro, con un relato ya trillado, pero que la confusión del sueño (la llamada fue a las tres de la madrugada) y el susto convierten en verosímil. Es más o menos así:
-”Disculpe la hora, ha habido un accidente y una de las personas heridas nos ha dado este teléfono. Lamentablemente no puede hablar mucho porque se encuentra muy mal. ¿Falta alguien en su casa?”
Si la persona que contestó la llamada dice algo como “sí, mi hijo Pedro, ¿cómo está, qué pasó?”, la conversación cambia instantáneamente de un accidente a un secuestro: “tenemos a Pedro, si queréis que lo soltemos (y sigue el pedido de rescate)”.
En circunstancias normales esto sonaría un poco raro, pero en estos tiempo violentos más la circunstancia de la hora del llamado, más el tono imperativo e impiadoso del interlocutor, tornan urgente la respuesta y el rescate.
Una compañera de trabajo recibió, hace meses, un llamado que repitió, punto por punto, la misma historia, y conozco una buena cantidad de personas que pasaron por la misma experiencia con un relato que sufría leves variaciones. En todos los casos se indagaba acerca de nombres y detalles familiares antes de brindar ninguna información concreta acerca de la supuesta víctima. Ésa es la primer clave: al pasar por una situación similar hay que intentar mantener la cabeza fría y exigir información acerca del accidentado antes de revelar ningún dato (cómo es la persona, en qué auto viajaba, dónde se encontraba, etc.). Y bajo ninguna circunstancia dar información acerca de la familia a extraños que no pueden explicar con precisión los motivos de su indagatoria.
La alternativa es contestar con un dato falso y así probar al interlocutor: si su hijo es Pedro, preguntar por su (inexistente) hija Viviana. Si efectivamente hubo un accidente y Pedro se encuentra en verdaderos problemas le dirán que se trata de un hombre en ese mismo instante.
Parecería ser que los llamados son hechos al azar. Según he consultado, no hay una elección deliberada de la víctima, y en casos sucedidos hace meses no ha existido ningún tipo de contacto posterior por más que la persona que haya contestado al llamado se haya dado cuenta de la trampa y haya cortado entre insultos. Es, dentro de todo, un alivio: pasado el susto no hay motivos para preocuparse más allá de lo razonable.
Cuento esta breve anécdota familiar intentar prevenir: que circulen estas historias ayuda a que este tipo de llamadas sean menos creíbles y que el mal momento termine cuando se cuelga el teléfono con el fracaso de los extorsionadores.
ATAQUES CIBERNÉTICOS
Los ataques a las computadoras "plantean el riesgo más importante para la seguridad nacional, fuera de una arma de destrucción masiva o una bomba en una de nuestras principales ciudades", dijo Shawn Henry, director asistente de la división informática del FBI en una conferencia en Nueva York.
"Fuera de un artefacto nuclear o de otro tipo de arma destructiva, la amenaza a nuestra infraestructura, la amenaza a nuestros servicios de inteligencia, la amenaza a nuestro sistema de computadoras es la más crítica que pesa sobre nosotros", agregó.
Los expertos norteamericanos prevén un 'cybergeddon' o Apocalipsis cibernético en el que una economía avanzada, sería saboteada por los 'hackers' (piratas informáticos).
Grupos terroristas están trabajando para crear un 11 de septiembre virtual "que causaría el mismo tipo de daño a nuestro país, en todas partes, en todas las redes, así como lo hicieron en 2001 estrellando aviones contra edificios", comentó Henry.
Un ataque en línea de esa escala nunca sucedió hasta el momento en Estados Unidos, pero la piratería informática está evolucionando rápidamente en el mundo hacia un arma bélica.
Piratas rusos supuestamente montaron ataques en las redes de Internet de Estonia y Georgia el año pasado, así como simpatizantes palestinos realizaron ataques contra cientos de sitios israelíes en los últimos días.
Tras años de combate contra los grupos criminales que actúan en Internet, el FBI y los servicios de seguridad de otros países saben que los 'hackers' son uno de los enemigos más furtivos e innovadores.
"Antes perseguíamos a la gente que literalmente trasportaba bolsas con efectivo", comentó Donald Codling, encargado de la coordinación entre el FBI y el departamento de seguridad interior.
"Ahora el delincuente puede utilizar su tarjeta SIM y mover dinero a todo el mundo, y sus socios pueden retirar ese dinero en cajeros automáticos en la moneda de su elección. Para nosotros es sumamente difícil atraparlos".
Codling, al igual que otros encargados de la lucha contra la criminalidad informática, manifestó una contrariada admiración por la habilidad de adversarios altamente motivados que a menudo les llevan un paso de ventaja.
De otro lado, Christopher Painter, especialista del FBI encargado de la coordinación internacional, describió otro punto débil fundamental en la lucha contra la criminalidad cibernética: la amenaza a menudo es invisible y por ende no se la toma en serio.
"No es como un incendio", dijo. "Es difícil de tomar conciencia de la envergadura de la amenaza. A menudo descubrimos que una empresa ha sido atacada, se lo decimos y ellos ni siquiera los saben".
EL ARQUITECTO INFORMÁTICO
EL ARQUITECTO DE SOFTWARE
La integración de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. El Arquitecto de Software es la persona que añade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnológicas. La Arquitectura de Sistemas en general, es una actividad de planeación, ya sea a nivel de infraestructura de red y hardware, o de Software. La Arquitectura de Software consiste en el diseño de componentes de una aplicación (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseño arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y además poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseño arquitectónico describe en general el cómo se construirá una aplicación de software. Para ello se documenta utilizando diagramas, por ejemplo:
- Diagramas de clases
- Diagramas de base de datos
- Diagramas de despliegue
- Diagramas de secuencia
- Diagramas de infraestructura física
Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un proyecto que iniciará a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qué diagramas elaborar. Entre las herramientas para diseñar arquitecturas de software se encuentran:
- Enterprise Archit
- Microsoft Visio for Enterprise Architects
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado.
Prueba
Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no consideraría.
Documentación
Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales técnicos, etc. todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.
Mantenimiento
Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniería civil, arquitectura y trabajo de construcción es dar mantenimiento.
Funciones Principales de un Arquitecto de Software
Me han preguntado recientemente cuales son las funciones de un Arquitecto de Software, término que me suele hacer reír y que siempre digo que en menor y mayor medida casi todos somos un poco Arquitectos de Software, yo he recopilado estas funciones:
Arquitectura: Definición de arquitectura de los sistemas, vista física, vista lógica, principios de arquitectura, seguridad, etc.
- Selección de Software: Pilas de aplicaciones, bases de datos, librerías, frameworks, estándares tecnológicos, etc.
- Selección de Infraestructura: Sistemas Operativos, hardware, redes, sistemas de recuperación, etc.
- Requisitos no Funcionales: Rendimiento, escalabilidad, seguridad, etc.
- Liderazgo: Liderazgo Técnico, responsabilidad y autoridad, dirección de equipos, etc.
- Coaching y Mentoring: Ayuda sobre problemas técnicos, ayuda en la evolución profesional, etc.
- Metodología de Proyectos: Estructura de Proyectos, Metodologías (Waterfall, Scrum, RUP, XP...).
- Procesos de Desarrollo: Control de versiones de código fuente, procesos de construcción, integración continua, automatización de pruebas y otros procesos y herramientas de desarrollo.
- Prácticas y Estándares: Estándares de codificación y libros blancos, selección de herramientas, etc.
- Diseño, Desarrollo y Pruebas: Diagramas UML, codificación, pruebas unitarias, etc.
- Experiencia: Conocimiento sobre tecnologías y arquitecturas.
- Estar al día en cuanto a tendencias tecnológicas: Agile, Web 2.0, SOA, Lightweight Java EE, etc.
PERFIL
Tal vez no debe conocer a súper fondo el lenguaje, pero sí debe tener bastantes conocimientos en cuanto a la manera de estructurar aplicaciones, patrones de diseño, los frameworks más populares (y los no tan populares pero que puedan servir a un proyecto), tendencias, etc.
Y cuando digo que debe conocer los frameworks no me refiero a simplemente saber de la existencia de Spring o Hibérnate por ejemplo, sino saber qué módulos tiene, qué hace, cómo lo hace, si es recomendable su uso, qué soporte hay tanto en comunidad como a nivel empresarial, hacia dónde va, en qué estado se encuentra actualmente (puede haber un framework muy bueno y estable pero que ya fue abandonado por su autor y por lo tanto no sería recomendable meterlo a proyectos que requieren mantenimiento a largo plazo porque en algún momento va a dejar de funcionar por cambios en JVM y cosas así, o bien se va a estancar todo el proyecto por no poder actualizar dicho framework). Lo mismo aplica para contenedores (que si JBoss, Glassfish, WebLogic, etc.), sistemas operativos, versiones de Java, bases de datos, etc.; debe saber las ventajas y desventajas de cada uno y saber cuál conviene en cada proyecto.
En mi opinión, también debe poder ayudar a programadores a encontrar problemas en su código, realizar optimizaciones, etc. Y debe ser quien defina los procedimientos para pruebas unitarias, de integración, de regresión, etc.; para deployment, para entregas parciales, correcciones, mantenimiento...
ARQUITECTO DE SISTEMAS
Los arquitectos de sistemas son las personas responsables de:
- Servir de interfaz con los usuarios y patrocinadores, así como cualquier otro que está involucrado en determinar sus necesidades.
- Generar los niveles más altos de requisitos del sistema, basados en las necesidades del usuario, así como, algunas otras limitantes tales como costos y tiempos.
- Asegurarse de que este alto conjunto de requisitos sea consistente, completo, correcto, y operacional.
- Llevar a cabo análisis costo-beneficio para determinar que costos se cumplen mejor ya sea manualmente, por software o con hardware; maximizando así los componentes ya desarrollados o los comerciales.
- Desarrollar algoritmos de particionado (y otros procesos) para economizar los requisitos en particiones discretas de manera que se necesite un mínimo de comunicación entre las particiones y los usuarios con el sistema.
- Particionar grandes sistemas en (capas sucesivas de) subsistemas y componentes los cuales puedan ser manipulados por un solo ingeniero, equipo de ingenieros o arquitectos subordinados.
- Asegurar que se alcance el máximo de robustez de arquitectura.
- Generar una serie de requisitos de pruebas de aceptación, las cuales junto con los diseñadores, ingenieros de pruebas, y el usuario determinen si se han cumplido los requisitos, especialmente para las interfaces de usuario.
- Generar bosquejos, modelos, guías de usuario y prototipos que mantengan en acuerdo y al corriente a los ingenieros con los usuarios.
Antecedentes
La arquitectura de grandes sistemas se desarrolló como una vía de manejar los sistemas que son demasiado amplios de concebir para una sola persona. Los sistemas de esta envergadura se están convirtiendo en la norma.
Usuarios y Patrocinadores
Los ingenieros en grupo no tienen una buena reputación en cuanto a su respuesta a las necesidades humanas, como resultado de ello los productos resultantes que producen son poco estéticos. De los arquitectos se espera que entiendan las necesidades humanas, y por lo tanto produzcan productos estéticos y humanamente funcionales. Un buen arquitecto es aquél que traduce entre los usuarios/patrocinadores e ingenieros, e incluso sólo entre ingenieros de distintas especialidades. Un buen arquitecto es también aquél que se esfuerza por mantener la visión del producto final del usuario, así como, los procesos que se derivan de los requisitos y de la implementación de esa visión.
El hecho de determinar qué es lo que los usuarios/patrocinadores realmente desean, en vez de lo que ellos dicen querer, no es ingeniería- es un arte. Un arquitecto nunca sigue un procedimiento en especial. Él/Ella se comunica con los usuarios/patrocinadores de una manera altamente interactiva, de manera que pueda extraer los verdaderos requisitos necesarios para llevar a cabo la ingeniería del sistema. El arquitecto debe mantener una constante comunicación con sus usuarios finales. Es más, los arquitectos deben familiarizarse íntimamente con el ambiente de los usuarios y su problemática.
Requisitos de Alto Nivel (High Level Requirement)
El usuario/patrocinador debe ver al arquitecto como el representante del usuario al que debe proporcionar toda la información. No se recomienda que haya una interacción directa con los ingenieros de proyecto, ya que existen grandes posibilidades de que haya problemas de entendimiento. La especificación de los requisitos del usuario deben ser un producto de empalme entre el usuario y el arquitecto: el usuario expresa sus necesidades y su lista de deseos, el arquitecto aporta conocimientos respecto a que es lo que puede ser más factible en términos de costo y tiempo. Cuando las necesidades del usuario han sido traducidas a un conjunto de requisitos de alto nivel, se recomienda que se inicien las primeras versiones de pruebas de aceptación, las cuales debieran ser, actualizadas religiosamente con los requisitos. De esta manera, el usuario tendrá siempre en claro que es lo que obtiene. También sirven como un escudo en contra de requisitos no probados y desentendidos.
El desarrollo del primer nivel de ingeniería de requisitos es un ejercicio no completamente analítico que debe involucrar a los arquitectos e ingenieros. En caso de que se hagan compromisos acordes a los costos, tiempos, energía o espacio, el arquitecto debe asegurarse de que el producto final no se aleje de lo que el usuario desea. El ingeniero debe enfocarse en desarrollar algo que optimice las limitaciones pero a su vez debe asegurarse de que se produzca un producto confiable. Al arquitecto le concierne el confort y usabilidad, mientras que al ingeniero le corresponde la productividad y utilidad del producto principalmente.
La función de un sistema de ingeniería es principalmente proveer de los servicios necesarios al usuario. Debido a que los sistemas se están volviendo cada vez más grandes y complejos, se ha encontrado que los sistemas tradicionales de desarrollo se han vuelto insuficientes, se ha visto la necesidad de recurrir a la aplicación de principios de arquitectura de sistemas, hardware y software para el diseño de subsistemas. La arquitectura es un modelo simplificado del producto final— su función principal es la de definir sus partes y las relaciones entre cada una de ellas, de manera que el sistema sea consistente, completo y represente lo que el usuario tiene en mente— especialmente las interfaces hombre-máquina. También se utiliza para asegurarse de que todas las partes encajan correctamente y se relacionan en la manera deseada.
Es necesario distinguir entre la arquitectura del mundo de usuario y la arquitectura de ingeniería de sistemas. El anterior representa y trata los problemas y soluciones en el mundo de usuario. Su acción se captura principalmente en las interfaces hombre-máquina del sistema. El sistema representa las soluciones de ingeniería— la manera en que el ingeniero propone el desarrollo y/o selecciona y combina los componentes de la infraestructura técnica para darle soporte a las interfaces de usuario. Cuando no hay arquitectos, existe una desafortunada tendencia a confundir las dos arquitecturas, esto debido a que el ingeniero piensa las cosas en términos de hardware y software, mientras que el usuario pudiera estar pensando en términos de resolver el problema de llevar a las personas desde un punto A al punto B en un periodo razonable de tiempo y con una utilización razonable de energía. Mientras que del arquitecto de sistemas se espera que haya una combinación de conocimientos, tales como del arquitecto del mundo de usuario y (todo el potencial) de los arquitectos de ingeniería de sistemas. La anterior es una actividad que articula con el usuario; la otra es una actividad que articula con los ingenieros. El producto es una serie de requisitos de alto nivel que reflejan aquellos requisitos del usuario que pueden ser utilizados por los ingenieros para desarrollar requisitos de diseño de sistemas.
Los arquitectos son necesitados hasta que los sistemas son aceptados por el usuario debido a que los requisitos evolucionan en el transcurso de los proyectos, especialmente aquellos que son muy largos.
Análisis costo/beneficio
La mayoría de los ingenieros son especialistas. Saben cuál es la aplicación de algún campo de la ingeniería de manera íntima, aplican sus conocimientos a situaciones prácticas— esto es, resuelven problemas del mundo real, evalúan el costo/beneficio de distintas soluciones de acuerdo a su especialidad y se aseguran de la correcta operación de lo que diseñan. Los arquitectos son más generales. Por lo general no son expertos en alguna tecnología específica, más bien de varias tecnologías de las cuales puedan decidir qué tan aplicables son a situaciones específicas. También aplican sus conocimientos a situaciones prácticas, pero evalúan el costo/beneficio de distintas soluciones utilizando diversas tecnologías, por ejemplo, hardware contra software contra procesos manuales, y se aseguran de que el sistema como un todo se comporte de acuerdo a las expectativas del usuario.
Existen diversos productos comerciales así como componentes de hardware y software previamente desarrollados que pueden ser seleccionados independientemente de acuerdo a limitaciones como costo, respuesta, rendimiento de procesamiento, etc. En algunos casos el arquitecto puede ensamblar el sistema final sin ser ayudado.
Capas y particionado
El arquitecto que planea la construcción de un edificio se esfuerza en todos los detalles de su diseño, asegurándose de que sea placentero y útil para sus hospedados. Mientras que un arquitecto puede ser suficiente para construir la casa para una familia, muchos ingenieros se podrían necesitar, en conjunto, para resolver problemas detallados que pudieran surgir al construir y diseñar un edificio. En caso de que el trabajo sea lo suficientemente grande y complejo, algunas partes del trabajo pueden ser sub arquitectadas. Esto significaría que si fuéramos a construir un complejo habitacional, podríamos tener un arquitecto por cada complejo, y uno por cada tipo de edificio como parte de un equipo arquitectónico.
Los grandes sistemas de automatización requieren de un arquitecto y un gran talento en ingeniería.
El arquitecto debe subasignar los requisitos del sistema a componentes mayores o subsistemas que se encuentren en el ámbito de un ingeniero de software, hardware, supervisor de ingeniería o arquitecto subordinado. (Si el objeto es lo suficientemente grande y/o complejo, el arquitecto en jefe debe sub asignar algunas porciones a arquitectos más especializados). Todos y cada uno de los componentes/subsistemas son objetos lo suficientemente independientes que pueden ser probados como componentes individuales, separados del todo utilizando pruebas y simulaciones que proporcionen entradas y salidas. En otras palabras, no es necesario saber cómo trabaja un sistema de control de tráfico aéreo para diseñar y construir un subsistema. Sólo es necesario saber bajo que restricciones operará el subsistema.
Pruebas de aceptación
Las pruebas de aceptación son la responsabilidad principal de los arquitectos. Significa también que los arquitectos tienen que probarles a los usuarios que el sistema es tal cual se planeó y que todos los arquitectos subordinados e ingenieros han cumplido con sus objetivos. Los grandes proyectos tienden a ser dinámicos, con cambios solicitados por el usuario, o esperados por ellos. Esto no sucede con las pruebas de aceptación, en donde las pruebas deben mantenerse al día en todo momento. Esto se traduce en que el usuario debe ser informado respecto a cómo debe realizarse el producto final. También actúan como el principal objetivo hacia el cual todo el personal subordinado debe diseñar y probar.
Proporcionar una buena comunicación entre usuarios e ingenieros
Un arquitecto de edificios utiliza bosquejos, modelos y dibujos. Es recomendable que un arquitecto de software de automatización de sistemas (de software o hardware) utilice modelos, dibujos y bosquejos para discutir las distintas soluciones y resultados con los usuarios, ingenieros y otros arquitectos. Las versiones preliminares de los manuales de usuario son invaluables, especialmente en conjunto con los prototipos. Una serie de (ingeniería) requisitos establece que se evite comunicar con los usuarios explícitamente. Sin embargo, es importante que se genere un set de requisitos bien escritos o especificaciones, que sean comprensibles por el cliente.
Contador Gratis
Suscribirse a:
Comentarios (Atom)
Entradas
