{"id":2902,"date":"2014-03-28T18:00:05","date_gmt":"2014-03-28T18:00:05","guid":{"rendered":"http:\/\/kasperskydaily.com\/spain\/?p=2902"},"modified":"2020-02-26T17:22:12","modified_gmt":"2020-02-26T15:22:12","slug":"la-regla-del-seis","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/la-regla-del-seis\/2902\/","title":{"rendered":"La regla del “Seis”"},"content":{"rendered":"

Uno de los momentos m\u00e1s importantes que llevaron Kaspersky Lab a ser una de las empresas protagonistas en el campo de la seguridad TI fue el lanzamiento de la revolucionaria versi\u00f3n de Kaspersky Anti-Virus 6.0<\/a>. Presentado oficialmente en 2006, el producto fue un verdadero \u00e9xito en el mercado global de antivirus; a partir de entonces y en los a\u00f1os que siguieron, Kaspersky Lab se convirti\u00f3 en empresa l\u00edder en el sector. Decir que nuestro producto es la mejor soluci\u00f3n antivirus en el mundo<\/a> ser\u00eda pecar de presunci\u00f3n, pero es lo que opinaron muchas revistas especializadas y portales independientes<\/a>.<\/p>\n

\"KASPERSKY\"<\/a><\/p>\n

El camino hacia el \u00e9xito fue duro y lleno de imprevistos y tal vez un d\u00eda alguien de Hollywood har\u00e1 una pel\u00edcula sobre nosotros; de momento, os contaremos nuestra historia de \u00e9xito con fotos, notas y recuerdos proporcionados por el equipo original de desarrolladores. Esperemos que esta historia sea un ejemplo para los j\u00f3venes desarrolladores que hoy en d\u00eda crean servicios y aplicaciones, para que aspiren a ser los mejores, como fueron los que crearon la versi\u00f3n \u201cSeis\u201d.<\/p>\n

\"\"

Una foto hist\u00f3rica, sacada el d\u00eda del lanzamiento t\u00e9cnico de la versi\u00f3n \u201cSeis\u201d<\/p><\/div>\n

2003: un a\u00f1o dif\u00edcil<\/h2>\n

El \u00e9xito de \u201cSeis\u201d se debi\u00f3 a la versi\u00f3n anterior del producto, que fue un desastre total. De hecho la quinta versi\u00f3n nunca vio la luz del sol tal y como se pens\u00f3 al principio.<\/p>\n

Para entender la raz\u00f3n de este fracaso, tenemos que volver al a\u00f1o 2002: Windows XP acababa de salir, por fin las CPU pod\u00edan llegar al 1 GHz de memoria de reloj y la industria antivirus, relativamente joven, todav\u00eda no era capaz de detectar muchas amenazas. Todas las empresas antivirus extend\u00edan las funcionalidades de sus productos: por entonces, una soluci\u00f3n competitiva ten\u00eda que comprender un firewall, un monitor de sistema de archivos en continuo funcionamiento y otra decena de caracter\u00edsticas.<\/p>\n

Con un potente sistema de an\u00e1lisis construido en los a\u00f1os 90, el equipo de desarrolladores de Kaspersky admiti\u00f3 que una soluci\u00f3n con m\u00e1s caracter\u00edsticas habr\u00eda sido demasiado lenta (ya la versi\u00f3n 4.0 no hab\u00eda gustado nada a los usuarios, sus comentarios de que \u201cKaspersky era lento\u201d estaban a la orden del d\u00eda). Por eso durante el proceso de desarrollo de la versi\u00f3n 5.0 se analizaron todos los m\u00e1s m\u00ednimos detalles y en particular se prest\u00f3 mucha atenci\u00f3n y se hicieron algunos cambios: se nombr\u00f3 a otro Director de tecnolog\u00edas de la informaci\u00f3n, se adopt\u00f3 un nuevo sistema de desarrollo y se eligi\u00f3 una nueva arquitectura antivirus.<\/p>\n

La empresa invirti\u00f3 todos sus recursos en este proyecto. Despu\u00e9s de un a\u00f1o, se lleg\u00f3 a la conclusi\u00f3n que todas las nuevas reglas en el desarrollo no habr\u00edan garantizado la creaci\u00f3n de un producto competitivo. El sistema, que recordaba a las aplicaciones cliente-servidor (fue \u00e9sta la l\u00ednea establecida por el Director de tecnolog\u00edas), no era capaz de cumplir con los requisitos que otros productos antivirus del mercado cumpl\u00edan. Se trataba de un software lento y pesado y, pese a las pruebas llevadas a cabo frecuentemente, el n\u00famero de bug segu\u00eda creciendo.<\/p>\n

\u201cEmpec\u00e9 a pedir opini\u00f3n a los veteranos de la empresa. Me contestaron que todo depend\u00eda de la arquitectura. Era como un casillo de naipes, cuando arreglabas una cosa, se ven\u00eda abajo toda la estructura\u201d, admiti\u00f3 Eugene Kaspersky. No ten\u00eda sentido continuar con el proyecto de esa forma: hab\u00eda que volver a empezar desde cero.<\/p>\n

\u00a1Lo conseguiremos!<\/h2>\n

El equipo de desarrolladores de Kaspersky Lab se dividi\u00f3 en dos grupos: uno intentaba arreglar el producto aunque la arquitectura elegida no fuera la m\u00e1s adecuada, otro intentaba mejorar la versi\u00f3n 4.0 para que pudiera valer como nuevo producto.<\/p>\n

Al mismo tiempo, un grupo de cuatro personas decidi\u00f3 crear un producto completamente nuevo que no solo pudiera satisfacer los requisitos del mercado, sino que pudiera hacer de referente en el futuro. El objetivo establecido por los desarrolladores de la versi\u00f3n \u201cSeis\u201d era f\u00e1cil de explicar pero dif\u00edcil de concretar. La nueva versi\u00f3n ten\u00eda que bloquear todos los virus y las amenazas que pudieran entrar en el sistema, ten\u00eda que ser r\u00e1pida, \u00e1gil, transparente y\u2026 tambi\u00e9n agradable a la vista.<\/p>\n

\u201cSolo quer\u00edamos hacer el mejor producto\u201d, recuerda el equipo de \u201cSeis\u201d. Un equipo muy reducido que iba a enfrentarse a un reto enorme: era esto lo que pensaba el resto de los 200 empleados de la empresa. No obstante, el equipo ten\u00eda sus razones para ser optimista acerca esta misi\u00f3n tan desafiante: los fundadores de la empresa, Eugene Kaspersky y Alexey De-Monderik estaban buscando alternativas para una nueva arquitectura y hab\u00edan descubierto que exist\u00eda una alternativa v\u00e1lida, que solo el\u00a0 equipo de Kaspersky Lab hab\u00eda encontrado.<\/p>\n

Ayuda desde Praga<\/h2>\n

\"\"<\/p>\n

Hay que decir que en la versi\u00f3n 4.0., los dos n\u00facleos antivirus (los \u201cmotores\u201d) trabajaban juntos. Los archivos se controlaban a trav\u00e9s del antiguo y todav\u00eda activo motor desarrollado en 1996 de la versi\u00f3n 3.0 (cuya licencia se vendi\u00f3 a muchas compa\u00f1\u00edas internacionales, desde G-Data a F-Secure). El nuevo objetivo de hacer m\u00e1s eficaz el proceso de filtro del tr\u00e1fico Web estaba en las manos de un nuevo y potente mecanismo ideado durante una sesi\u00f3n de brainstorming que tuvo lugar en Praga en 1998.<\/p>\n

En honor de la ciudad, se bautiz\u00f3 el motor con el nombre de \u201cPraga\u201d (Prague en ingl\u00e9s), no obstante Andrey Doukhvalov, que no acudi\u00f3 a las reuniones en la capital de la Rep\u00fablica Checa lo desarroll\u00f3 en Mosc\u00fa. De todas formas, las ideas m\u00e1s importantes nacieron en Praga y Andrey entr\u00f3 en la empresa para aportar m\u00e1s ideas e implementar el proyecto.<\/p>\n

Praga ten\u00eda que ser \u00fanicamente un n\u00facleo anti-virus, pero su flexibilidad y genialidad pod\u00eda suportar incluso los sistemas m\u00e1s complicados. La duda m\u00e1s importante, es decir, si era posible crear un producto entero<\/b> con Praga como base, era la que m\u00e1s preocupaba \u00a0a Eugene Kaspersky. \u00c9l mismo nos cuenta:<\/p>\n

\u201cUna vez pregunt\u00e9 a Victor Matyushenko si Praga pod\u00eda encajar bien con el producto y \u00e9l me contest\u00f3 que el n\u00facleo era \u201c\u00a1s\u00f3lido como una roca!\u201d, lo que era el nudo de la cuesti\u00f3n. Entonces hice la <\/i>pregunta. Entr\u00e9 en la habitaci\u00f3n donde trabajaban Graf [De-Monderik] y Petrovich [Doukhvalov] y les hice la<\/i> pregunta: \u2018\u00bfPor qu\u00e9 no basamos el producto entero en Praga?\u2019 Graf dijo algo como \u2018imposible, no hemos dise\u00f1ado Praga por esto\u2019, mientras Petrovich dud\u00f3. Al d\u00eda siguiente vino con una peque\u00f1a pila de hojas y me dijo: \u2018he pensando en algunos casos de uso para Praga\u2019. Graf le mir\u00f3 y dijo \u2018tenemos que hablar\u2019. Luego los dos vinieron hacia m\u00ed y me confirmaron que val\u00eda la pena intentarlo\u201d.<\/p>\n

El ensayo empez\u00f3 con un equipo muy reducido de personas, que escribi\u00f3 las primeras l\u00edneas del c\u00f3digo; \u00e9sta fue la base\u00a0 de lo que luego fue la versi\u00f3n \u201cSeis\u201d.<\/p>\n

El ensayo empez\u00f3 con un equipo muy reducido de personas, que escribi\u00f3 las primeras l\u00edneas del c\u00f3digo; \u00e9sta fue la base de lo que luego fue la versi\u00f3n \u201cSeis\u201d.<\/div>\n

\u201cEmpezamos a buscar personas que pudieran aportar ideas creativas y organizamos un grupo m\u00e1s extenso\u201d, nos cuenta De-Monderik. \u201cEstaba Pavel Mezhuev, un programador que acababa de llegar pero era muy bueno. Luego estaba Mike Pavlyuschik, con quien trabaj\u00e1bamos desde hac\u00eda tiempo, capaz de sacar ideas y conceptos de la nada. Era uno de los creadores m\u00e1s prol\u00edficos y con m\u00e1s talento en el sector\u201d.<\/p>\n

\"\"<\/p>\n

Despu\u00e9s de dos meses de investigaci\u00f3n y experimentos libres sobre los c\u00f3digos, decidimos que se pod\u00eda pensar en un producto para la venta. En ese punto solo necesit\u00e1bamos un gestor de proyectos.<\/p>\n

\u201c\u00bfTe acuerdas de Nikolay Grebennikov del despacho de al lado? Lee mucho, es joven y es nuevo en la empresa. \u00a1Le elegimosl!\u201d nos cuenta Andrey Doukhvalov sobre una conversaci\u00f3n que tuvo con De-Monderik. \u00a0Andrey Sobko, ingeniero de driver software, entrar\u00eda en el equipo un poco m\u00e1s tarde.<\/p>\n

Qu\u00e9 es \u2018Praga\u2019<\/h2>\n

Esta secci\u00f3n interesar\u00e1 sobre todo los ingenieros de software. El resto de los lectores puede saltarla tranquilamente.<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

A principios de los a\u00f1os 90, como la industria antivirus acababa de mover sus primeros pasos, hab\u00eda algunos virus que no se pod\u00edan detectar por su firma. Por ejemplo no se puede individuar un virus polimorfo que cifra su c\u00f3digo analizando las firmas. Con el tiempo, los software antivirus llegaron a ser m\u00e1s complejos y tambi\u00e9n los virus: si al principio crear piezas de malware era una especie de juego, con el tiempo pas\u00f3 a ser un mercado muy lucrativo. Incluso despu\u00e9s de integrar m\u00e1s funcionalidades al algoritmo capaz de detectar las firmas (como hac\u00eda Kaspersky), los desarrolladores se vieron obligados a actualizar constantemente el antivirus, y no solo las bases de datos de las firmas, sino tambi\u00e9n su estructura para encontrar un nuevo m\u00e9todo de detecci\u00f3n de las amenazas. De este modo se ralentizaba de manera significativa el tiempo de reacci\u00f3n frente a los nuevos virus: el \u00e9xito que Kaspersky Lab obtuvo despu\u00e9s de ser la primera empresa capaz de curar el peligroso virus CIH (Chernobyl), demostr\u00f3 que merec\u00eda la pena esforzarse para reducir estos tiempos de reacci\u00f3n.<\/p>\n

Considerando esta situaci\u00f3n, en 1998 Eugene Kaspersky dijo a sus compa\u00f1eros que hab\u00eda llegado el momento de crear un nuevo motor antivirus. \u00bfAd\u00f3nde habr\u00eda llevado todo esto?<\/p>\n

\u201cLa empresa no ten\u00eda dinero\u201d, nos cuenta Eugene Kaspersky \u201cy ten\u00edamos que encontrar un lugar no tan lejos de Mosc\u00fa, el m\u00e1s barato posible, donde alejarnos de todo y concentrarnos. El sitio ten\u00eda que ser lo m\u00e1s aislado posible. Por entonces no hab\u00eda redes WiFi en los alrededores. El lugar m\u00e1s barato result\u00f3 ser una capital europea, Praga\u201d.<\/p>\n

Despu\u00e9s de reflexionar sobre una nueva versi\u00f3n del motor antivirus, el equipo de Kaspersky Lab lleg\u00f3 a la conclusi\u00f3n de que lo mejor para el motor era mejor utilizar una programaci\u00f3n orientada a objetos; eso quiere decir que cada archivo u objeto ten\u00eda que ser diseccionado en todas las partes que formaban su estructura. Luego se detectaban, analizaban y verificaban los diferentes objetos en su interior. La gesti\u00f3n total del objeto ten\u00eda que realizarse en tiempo de ejecuci\u00f3n.<\/p>\n

Se analizaros todos los entornos orientados a objetos disponibles y todos fueron rechazados porque eran poco flexibles, utilizaban mucha memoria o eran muy lentos. Durante varias reflexiones surgi\u00f3 una idea: desarrollar un nuevo entorno, capaz de incluir funcionalidades para la gesti\u00f3n de la memoria y otros procedimientos, para que el antivirus pudiera diseccionar y analizar cualquier potencial c\u00f3digo malicioso de manera r\u00e1pida y eficaz.<\/p>\n

Esta idea innovadora se debe a Andrey Kyrkov y De-Monderik en Praga, soportada por las primeras l\u00edneas del c\u00f3digo de Doukvalov y Kryukov.<\/p>\n

Durante m\u00e1s de un a\u00f1o, sobre todo Doukhvalov continu\u00f3 trabajando sobre Praga, de hecho Kaspersky Lab lo contrat\u00f3 por esto. Gracias a su experiencia en el campo de la arquitectura, Doukhvalov hizo que Praga fuera un sistema flexible, escalable y que se pudiera insertar en los productos sin limitaciones desde el punto de vista de la arquitectura. Finalmente, el objetivo fue construir una soluci\u00f3n multiplataforma.<\/p>\n

Fue bastante dif\u00edcil remover la jerarqu\u00eda de los objetos pero, gracias a un c\u00f3modo sistema de intercambio de mensaje entre los objetos y a una interfaz de programaci\u00f3n minimalista, Praga lleg\u00f3 a ser una arquitectura integrada y lista para usarse.<\/p>\n

\u201cIdeamos un sistema basado en componentes\u201d, nos especifica Doukhvalov con orgullo. \u201cEsto significa que se pueden a\u00f1adir componentes a un programa existente. Se trata de un sistema muy abierto que ofrece la posibilidad de a\u00f1adir elementos\u00a0 y modificar los esquemas de comportamiento\u201d.<\/p>\n

Una arquitectura basada en componentes, compacta y que no utilizase muchos recursos constitu\u00eda los requisitos fundamentales para introducir unas tecnolog\u00edas totalmente nuevas en KAV 6.0. La implementaci\u00f3n fue f\u00e1cil. Adem\u00e1s, cuando se decidi\u00f3 que Praga iba a ser la base del producto entero y no solo un motor antivirus, Pavel Mezhuev se esforz\u00f3 mucho en refinar la arquitectura:<\/p>\n

\u201cImplementamos otra soluci\u00f3n para la arquitectura, utilizando un modelo con l\u00f3gica de negocio e interfaz separadas. Adem\u00e1s, Doukhvalov y Mezhuev crearon un administrador de tareas capaz de controlar cada proceso del producto, y tambi\u00e9n la reciprocidad de los procesos era muy sencilla\u201d, nos explica Nikolay Grebennikov, el gestor de proyecto de entonces para KAV 6.0.<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

El principio de \u201cSeis\u201d<\/span><\/strong><\/p>\n

Ya que un peque\u00f1o grupo de personas se ocup\u00f3 del ensayo y de la fase inicial de desarrollo, una gesti\u00f3n del proyecto a lo grande no encajaba bien con un equipo tan reducido. As\u00ed que se decidi\u00f3 adoptar un marco de trabajo similar al modelo SCRUM: los desarrolladores trabajaban en un espacio abierto e interactuaban continuamente; as\u00ed se pod\u00edan cubrir todos los aspectos del proceso de desarrollo. De este modo el equipo trabaj\u00f3 en el \u201cSeis\u201d.<\/span><\/p>\n

Definici\u00f3n: SCRUM<\/strong><\/h3>\n

SCRUM es un modelo de gesti\u00f3n de proyectos para el desarrollo de software. Se basa en la idea de que el cliente (usuario) no sabe exactamente lo que necesita y podr\u00eda cambiar sus peticiones en el acto. De ese modo, el proceso de desarrollo est\u00e1 caracterizado por la presencia de diferentes fases: construcci\u00f3n, demonstraci\u00f3n, an\u00e1lisis de respuestas, y finalmente actualizaci\u00f3n de la versi\u00f3n.<\/p>\n

La distribuci\u00f3n de los roles de SCRUM cambi\u00f3 de manera significativa. Eugene Kaspersky defino seis roles principales:<\/p>\n

Arquitecto<\/b><\/p>\n

Es la persona (involucrada activamente en el proceso de creaci\u00f3n de c\u00f3digos) que sabe qu\u00e9 construir y c\u00f3mo hacerlo.<\/p>\n

Dise\u00f1ador t\u00e9cnico<\/b><\/p>\n

No hay una definici\u00f3n \u00fanica para este rol, de todas formas es una persona que se ocupa de hacer realidad algunas ideas y soluciones. Tal vez lo m\u00e1s importante es que el dise\u00f1ador t\u00e9cnico sabe c\u00f3mo NO se deben hacer las cosas.<\/p>\n

Inventor<\/b><\/p>\n

El inventor encuentra\u00a0 soluciones no convencionales a los problemas. En el caso de \u201cSeis\u201d siempre surg\u00edan nuevos problemas. La cuesti\u00f3n m\u00e1s importante era proporcionar a los usuarios el mejor nivel de protecci\u00f3n intentando utilizar la menor cantidad de recursos del sistema.<\/p>\n

Gestor de proyectos<\/b><\/p>\n

En el SCRUM el rol del gestor de proyectos no sigue reglas establecidas. Se ocupa de controlar los recursos y que se respeten los tiempos de entrega, pero no es un jefe. No da \u00f3rdenes a los que se ocupan de crear los c\u00f3digos pero les anima para que tomen sus decisiones y hagan bien su trabajo.<\/p>\n

\u201cComo se trataba de un equipo peque\u00f1o, al principio ni ten\u00edamos un jefe\u201d, recuerda Doukhvalov. \u201cEl gestor de proyectos se ocupaba de organizar y hacer informes, pero tom\u00e1bamos todas las decisiones de manera conjunta\u201d.<\/p>\n

Gestor de marketing<\/b><\/p>\n

Un producto se crea para los clientes y no para el equipo de desarrolladores. Por eso es fundamental saber lo que los usuarios esperan del nuevo producto y como lo van a utilizar. Si los expertos se ocupan de todos los aspectos t\u00e9cnicos del producto antivirus, es necesario tambi\u00e9n pensar en otros detalles como definir las opciones de configuraci\u00f3n, los mensajes y crear una interfaz de usuario intuitiva. Todas estas caracter\u00edsticas tienen en consideraci\u00f3n las necesidades del usuario y el gestor de marketing se ocupa de entender estas necesidades.<\/p>\n

Psic\u00f3logo<\/b><\/p>\n

Trabajar bajo presi\u00f3n, dormir muy poco, conflictos entre algunos miembros del grupo, inestabilidad\u2026 Es necesario que alguien cree un ambiente relajado y productivo. De todo esto se encarg\u00f3 Eugene Kaspersky que, por un lado proporcionaba a su equipo apoyo y recursos para que pudiera y, por el otro, le proteg\u00eda de influencias externas.<\/p>\n

Hay que decir que, en los proyectos SCRUM, existe otro rol fundamental, o sea quien se ocupa de tomar nota<\/b> de todo lo que ocurre durante el proceso de desarrollo. Pero no hab\u00eda nadie con este cargo y eso fue un problema.<\/p>\n

\u201cEn serio, no sabemos el porqu\u00e9, pero introducimos este rol solo hace un a\u00f1o\u201d, nos dice Kaspersky.<\/p>\n

Te\u00f3ricamente, un rol puede estar cubierto por m\u00e1s personas y, viceversa, una persona sola puede ocupar roles diferentes.<\/p>\n

\u201cAunque ten\u00edamos una organizaci\u00f3n formal, actu\u00e1bamos como un equipo, as\u00ed que no hab\u00eda una distinci\u00f3n exacta entre los diferentes roles: en particular, todo se mezclaba durante las sesiones de brainstorming\u201d, confiesa Nikolay Grebennikov. \u201cPor ejemplo, una persona que se ocupaba de crear los c\u00f3digos pod\u00eda expresar su opini\u00f3n sobre el dise\u00f1o de la aplicaci\u00f3n y esta opini\u00f3n se tomaba muy en cuenta. Yo era Gestor de proyectos pero participaba activamente en los debates; a esta flexibilidad debemos el \u00e9xito del proyecto, porque todos juntos nos preocup\u00e1bamos de cada detalle\u201d.<\/p>\n

Seg\u00fan De-Monderik, los roles eran intercambiables: \u201cCada miembro del equipo era el mejor en su campo, pero el 50% de las habilidades de cada uno coincid\u00edan con las de alguien m\u00e1s en el equipo.\u00a0 Mike pod\u00eda ocuparse de los c\u00f3digos si Sobko no estaba, los especialistas que se ocupaban de la interfaz pod\u00edan ocuparse de algunas tareas de ingenier\u00eda y viceversa. Yo pod\u00eda ocuparme del dise\u00f1o en lugar de Max Yudanov y a veces Kolya Grebennikov pod\u00eda ocuparse del dise\u00f1o tambi\u00e9n\u201d.<\/p>\n

Es importante decir que cada rol se ocupaba de una fase espec\u00edfica del proyecto. Durante la fase inicial, el arquitecto es la figura m\u00e1s importante. Luego llega el inventor en la fase intermedia del proceso de desarrollo cuando se crean las nuevas funcionalidades. Durante la fase final, es el gestor de proyecto el que tiene el papel m\u00e1s importante porque gestiona diferentes recursos para que todo el equipo respete los tiempos de entrega establecidos.<\/p>\n

En b\u00fasqueda de la perfecci\u00f3n<\/h2>\n

Con el modelo SCRUM y un proyecto tan ambicioso, para \u201cSeis\u201d no se hab\u00eda establecido un listado fijo de requisitos pero s\u00ed exist\u00edan unas especificaciones b\u00e1sicas. El producto ten\u00eda que:<\/p>\n