{"id":65,"date":"2016-05-13T17:35:19","date_gmt":"2016-05-13T15:35:19","guid":{"rendered":"http:\/\/binalia.es\/blog\/?p=65"},"modified":"2016-05-14T17:30:33","modified_gmt":"2016-05-14T15:30:33","slug":"la-flotabilidad-del-iceberg-y-el-desarrollo-de-software","status":"publish","type":"post","link":"https:\/\/www.binalia.es\/blog\/articulo\/la-flotabilidad-del-iceberg-y-el-desarrollo-de-software\/","title":{"rendered":"La flotabilidad del iceberg y el desarrollo de software"},"content":{"rendered":"

Toda aplicaci\u00f3n inform\u00e1tica, desde un simple juego de tres en raya hasta una completa gesti\u00f3n empresarial, conlleva una serie de tareas que pasan desapercibidas pero son necesarias para el correcto funcionamiento del software. El resultado final para el cliente y futuro usuario es fruto de un trabajo que requiere much\u00edsimas horas de reflexi\u00f3n, ensayos,\u00a0prototipos y\u00a0cambios. Este art\u00edculo s\u00f3lo trata de reflejar la cantidad de aspectos a tener en cuenta que, a\u00fan no siendo percibidos directamente por el usuario final, resultan de vital importancia si queremos acabar con \u00e9xito un desarrollo.<\/strong><\/p>\n

El proceso\u00a0de desarrollo de software<\/h1>\n

El desarrollo de una aplicaci\u00f3n inform\u00e1tica aparenta ser, en muchas ocasiones, un proceso m\u00e1s art\u00edstico que cient\u00edfico. No entraremos en teor\u00eda de computaci\u00f3n ni en bibliograf\u00eda sobre el an\u00e1lisis de software, que lo hay para aburrir, s\u00f3lo queremos resaltar que no deber\u00edamos de tomar el desarrollo de software como un tema menor<\/strong>\u00a0ya que posee m\u00e1s complejidad de la que parece. Pero, no nos pongamos trascendentales, tras este \u00abarte\u00bb existe una metodolog\u00eda con una base cient\u00edfica suficiente para garantizar el \u00e9xito, siempre y cuando tomemos las decisiones acertadas y nos apoyemos en aquellos que ofrecen garant\u00edas, confianza y responsabilidad.<\/p>\n

Un buen desarrollador deber\u00eda de pasar m\u00e1s tiempo pensando que tecleando.<\/p><\/blockquote>\n

El analista y programador de aplicaciones puede ahorrar mucho tiempo (y dinero) evitando desarrollos innecesarios. Para ello basta con sentarse junto a todos los implicados en el proyecto, incluyendo el cliente \u00abpagador\u00bb y el usuario final. Todos han de reflexionar sobre aquello que se quiere lograr<\/strong> mediante el uso de la aplicaci\u00f3n inform\u00e1tica que pretendemos\u00a0desarrollar. Ni se trata de reinventar la rueda, ni mucho menos \u00abredescubrirla\u00bb, se trata de ser realistas y abarcar s\u00f3lo aquello que es asumible\u00a0y resultar\u00e1 \u00fatil<\/strong> para alcanzar la meta propuesta.<\/p>\n

\u00bfHabr\u00e1 fallos? Por supuesto, somos humanos.<\/p><\/blockquote>\n

Es evidente que, por mucho que pensemos, en alg\u00fan momento hemos de ponernos manos a la obra y comenzar a teclear c\u00f3digo para probar nuestros dise\u00f1os pero, si sabemos hacia donde queremos dirigirnos, es mucho m\u00e1s probable que no andemos perdidos y sin rumbo. Aunque sea una idea l\u00f3gica y evidente, no est\u00e1 tan extendida como parece. La programaci\u00f3n directa sin una reflexi\u00f3n profunda previa puede ocasionar frustraci\u00f3n en un programador<\/strong> que nunca \u00abacierta\u00bb con aquello que le han encargado. El proceso de desarrollo ha de estar dirigido, pensado y consensuado para evitar que el trabajo vaya a la basura.<\/p>\n

Pero el cliente sabe lo que necesita y s\u00f3lo quiere que alguien lo programe… o no.<\/p><\/blockquote>\n

Si alguna vez se ha enfrentado al desarrollo de una aplicaci\u00f3n inform\u00e1tica, bien como cliente, bien como desarrollador, habr\u00e1 observado que, cuando los objetivos no est\u00e1n claros y bien definidos el desarrollo de software termina enred\u00e1ndose<\/strong>\u00a0hasta el punto en que nadie comprende como resulta\u00a0tan dif\u00edcil finalizar el proyecto. \u00a1Si la idea estaba clara! Pues, \u00a1sorpresa! Si un desarrollo de software no avanza ni tiene pinta de acabar nunca lo m\u00e1s probable es que no est\u00e9 tan claro aquello que se pretende conseguir, eso suponiendo que no haya cambiado varias veces durante la implantaci\u00f3n. \u00bfLe suena esta situaci\u00f3n? Entendemos que esto frustra a cualquiera.<\/p>\n

La complejidad en el desarrollo de software a medida<\/h1>\n

Insistimos en que el objetivo y planteamiento inicial ha de ser cristalino. Tanto cliente como desarrollador han de comprender a la perfecci\u00f3n la situaci\u00f3n de partida y consensuar el objetivo que se persigue con el proyecto. Un desarrollo a medida no es barato (le recomendamos que huya de aquellos que lo sean) precisamente porque es algo complejo y requiere de experiencia, capacidad reflexiva y mucha seguridad para no \u00abdejarse llevar\u00bb por el que paga.<\/p>\n

Dejarse aconsejar<\/h2>\n

Sentimos si el lector est\u00e1 en el lado \u00abde los que paga\u00bb pero, sin \u00e1nimo de ofender, ha de saber que, el que paga, no siempre lleva la raz\u00f3n, aunque est\u00e1 en\u00a0todo su derecho a conocer los motivos por los que no la lleva.<\/p>\n

La actitud de un buen analista-programador es la de actuar como asesor, pero para ello hay que dejarse asesorar.<\/p><\/blockquote>\n

Llegados a este punto, donde todo son trabas y problemas, no queremos que nadie se asuste y abandone su idea de contratar a un desarrollador para llevar a cabo su proyecto. M\u00e1s bien todo lo contrario. El desarrollador es imprescindible y todos los d\u00edas se abarcan proyectos que acaban en \u00e9xito. Nosotros queremos que desarrolle su idea. S\u00f3lo hemos de encontrar a un buen analista-programador. Alguien capaz de captar lo que queremos hacer, asesorarnos y, quiz\u00e1, razonablemente, modificar el modo o enfoque para llevarlo a cabo. La idea original seguir\u00e1 siendo suya y permanecer\u00e1 intacta. El desarrollador s\u00f3lo modifica el modo de llevarla a cabo.<\/p>\n

Caracter\u00edsticas de un desarrollo de software<\/h2>\n

Pero \u00bfpor qu\u00e9 tanto jaleo para un programita? \u00bfTan dif\u00edcil es programar? Bueno, f\u00e1cil no es, desde luego.<\/p>\n

Cuanto m\u00e1s acertado es el desarrollo, menos lo sufre el usuario.<\/p><\/blockquote>\n

Para comenzar, nunca es un programita… aunque lo parezca. Programar una aplicaci\u00f3n conlleva una serie de trabajos que el cliente no aprecia directamente. Al igual que ocurre con la cobertura de nuestro m\u00f3vil, si no se hicieran estos trabajos, notar\u00edamos su ausencia.<\/p>\n

Tengamos en cuenta que, donde el cliente ve \u00abun programa que hace lo que ya se hac\u00eda antes pero por ordenador\u00bb, un analista ha de crear un software que cumpla las siguientes\u00a0caracter\u00edsticas<\/strong>:<\/p>\n

Fiabilidad<\/h3>\n

La fiabilidad es una caracter\u00edstica que se da por supuesta pero cumplirla es importante ya que no podemos estar utilizando una aplicaci\u00f3n\u00a0en la que no confiamos. El cliente no est\u00e1 probando el software desarrollado. \u00a1Lo est\u00e1 utilizando para su trabajo!<\/strong> No podemos suponer que el cliente avisar\u00e1 cuando \u00abdetecte\u00bb errores. El software ha de entregarse probado y comprobado, tantas veces como sea necesario, hasta obtener un producto estable y con garant\u00edas.<\/p>\n

Desatenci\u00f3n y automatizaci\u00f3n<\/h3>\n

Otra caracter\u00edstica fundamental es que una aplicaci\u00f3n inform\u00e1tica funciona sin necesidad de hacerla funcionar. Parece evidente, \u00bfverdad? Nadie est\u00e1 vigilando si la aplicaci\u00f3n deja de funcionar. El dise\u00f1o de procesos ha de orientarse hacia la automatizaci\u00f3n. La idea que debe residir en el desarrollo ser\u00eda la de convertir en autom\u00e1tico todo aquello que sea automatizable<\/strong>. El ser humano ha de intervenir s\u00f3lo en aquellos aspectos que, por definici\u00f3n, necesiten intervenci\u00f3n humana.<\/p>\n

Solidez e inquebrantabilidad<\/h3>\n

Cualquier aplicaci\u00f3n inform\u00e1tica ha de tener presente que el usuario no tiene porqu\u00e9 conocer su funcionamiento<\/strong>. Adem\u00e1s, la aplicaci\u00f3n deber\u00eda\u00a0contemplar posibles errores humanos que, inconscientemente, todos podr\u00edamos cometer. Se ha de tener presente siempre la integridad de los datos almacenados.\u00a0La introducci\u00f3n y validaci\u00f3n de datos es uno de los aspectos m\u00e1s cr\u00edticos<\/strong> a la hora de desarrollar un interfaz de usuario. La validaci\u00f3n de fechas y otros tipos de datos es fundamental para ofrecer un software s\u00f3lido y estable.<\/p>\n

Durabilidad y sostenibilidad<\/h3>\n

El desarrollo de una aplicaci\u00f3n ha de enfocarse como inversi\u00f3n.\u00a0<\/strong>Ha de garantizarse que el desarrollo acabado permitir\u00e1 su explotaci\u00f3n a largo plazo. Puede existir fecha de caducidad pero hemos de evaluar que ya le habremos sacado el partido suficiente y la inversi\u00f3n ha sido rentable. Un software basado en tecnolog\u00edas o procesos caducos y obsoletos se convertir\u00e1 en un coste y un lastre para el negocio. Un buen desarrollador no deber\u00eda aceptar esta situaci\u00f3n al menos que est\u00e9 completamente justificada.<\/p>\n

Responsabilidad, calidad y confianza<\/h3>\n

Cuando se asume la tarea de poner en marcha una aplicaci\u00f3n inform\u00e1tica, el desarrollador siempre adquiere una responsabilidad impl\u00edcita. Al fin y al cabo alguien va a poner en sus manos los datos de su negocio para su tratamiento\u00a0y gesti\u00f3n diarios. Hemos de ser conscientes que nos est\u00e1n derivando cierta responsabilidad sobre la rentabilidad del negocio y no podemos defraudar. Nos convertimos, parcialmente, en responsables de su funcionamiento. Si el negocio de nuestro cliente gana, el desarrollador tambi\u00e9n<\/strong>. Si adoptamos esta actitud podremos ofrecer un desarrollo de calidad y un socio tecnol\u00f3gico de confianza<\/strong>.<\/p>\n

Adaptabilidad y crecimiento<\/h3>\n

Los modelos de negocio son din\u00e1micos, ning\u00fan negocio se gestiona ahora como se hac\u00eda hace unos a\u00f1os, al menos, no deber\u00eda. La aplicaci\u00f3n inform\u00e1tica a desarrollar ha de contemplar la posibilidad de\u00a0modificaciones y cambios en el modelo<\/strong>. Todo aquello que podamos prever ser\u00e1 m\u00e1s asumible en el futuro y redundar\u00e1 en mayor comodidad (y menor coste) para el cliente y el desarrollador. No hablamos de adivinar el porvenir, s\u00f3lo conocer si hay previsiones de cambio y tendencias probables para estar preparados en la medida de lo posible.<\/p>\n

Conclusi\u00f3n<\/h1>\n

Volviendo a la met\u00e1fora del iceberg y retomando el t\u00edtulo de este art\u00edculo, hemos de tener en cuenta que, aunque s\u00f3lo vemos la punta del mismo, lo que hace flotar a esta poderosa\u00a0monta\u00f1a de hielo es, precisamente, la parte que no podemos ver (si tiene tiempo y curiosidad en conocer\u00a0el motivo, le recomendamos que consulte el Principio de Arqu\u00edmedes<\/a>).<\/p>\n","protected":false},"excerpt":{"rendered":"

Toda aplicaci\u00f3n inform\u00e1tica, desde un simple juego de tres en raya hasta una completa gesti\u00f3n empresarial, conlleva una serie de tareas que pasan desapercibidas pero son necesarias para el correcto funcionamiento del software. El resultado final para el cliente y futuro usuario es fruto de un trabajo que requiere much\u00edsimas horas de reflexi\u00f3n, ensayos,\u00a0prototipos y\u00a0cambios.…<\/p>\n","protected":false},"author":2,"featured_media":71,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,2],"tags":[37,40,39,36,38],"class_list":["post-65","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-aplicaciones-web-multiplataforma","category-servicios","tag-analisis","tag-aplicacion-informatica","tag-consultoria","tag-desarrollo-de-software","tag-programacion"],"_links":{"self":[{"href":"https:\/\/www.binalia.es\/blog\/wp-json\/wp\/v2\/posts\/65"}],"collection":[{"href":"https:\/\/www.binalia.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.binalia.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.binalia.es\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.binalia.es\/blog\/wp-json\/wp\/v2\/comments?post=65"}],"version-history":[{"count":6,"href":"https:\/\/www.binalia.es\/blog\/wp-json\/wp\/v2\/posts\/65\/revisions"}],"predecessor-version":[{"id":74,"href":"https:\/\/www.binalia.es\/blog\/wp-json\/wp\/v2\/posts\/65\/revisions\/74"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.binalia.es\/blog\/wp-json\/wp\/v2\/media\/71"}],"wp:attachment":[{"href":"https:\/\/www.binalia.es\/blog\/wp-json\/wp\/v2\/media?parent=65"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.binalia.es\/blog\/wp-json\/wp\/v2\/categories?post=65"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.binalia.es\/blog\/wp-json\/wp\/v2\/tags?post=65"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}