Mantenimiento de Software

Definición de Mantenimiento:

El estándar IEEE 1219 [IEEE, 1993] define el Mantenimiento del  Software como: “la modificación de un producto de software después de Haber sido entregado [a los usuarios o clientes] con el fin de corregir defectos, mejorar el rendimiento u otros atributos, o adaptarlo a un cambio en el entorno”.

En el estándar ISO 12207, de Procesos del Ciclo de Vida del Software [ISO/IEC, 1995] se establece que “el Proceso de Mantenimiento contiene las actividades y tareas realizadas por el mantenedor. Este proceso se activa cuando el producto software sufre modificaciones en el código y la documentación asociada, debido a un problema o a la necesidad de mejora o adaptación. El objetivo es modificar el producto software existente preservando su integridad. Este proceso incluye la migración y retirada del producto software. El proceso termina con la retirada del producto software”. El mantenedor es la organización que proporciona el servicio de mantenimiento.

 En otras fuentes bibliográficas clásicas aparecen definiciones similares a las anteriores.

Pressman [1998] dice que “la fase mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software, y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente”.

En las anteriores definiciones de mantenimiento aparecen indicados, directa o indirectamente, cuatro tipos de mantenimiento: correctivo, adaptativo, perfectivo y preventivo.

         Mantenimiento Correctivo

El mantenimiento correctivo tiene por objetivo localizar y eliminar los posibles defectos de los programas. Un defecto en un sistema es una característica del sistema con el potencial de causar un fallo. Un fallo ocurre cuando el comportamiento de un sistema es diferente del establecido en la especificación.

Entre otros, los fallos en el software pueden ser de:

• Procesamiento, por ejemplo, salidas incorrectas de un programa.
• Rendimiento, por ejemplo, tiempo de respuesta demasiado alto en una búsqueda de información.
• Programación, por ejemplo, inconsistencias en el diseño de un programa.
• Documentación, por ejemplo, inconsistencias entre la funcionalidad de un programa y el manual de usuario.

Origen de los defectos del software

          Mantenimiento Adaptativo

Este tipo de mantenimiento consiste en la modificación de un programa debido a cambios en el entorno (hardware o software) en el cual se ejecuta.

Estos cambios pueden afectar al sistema operativo (cambio a uno más moderno), a la arquitectura física del sistema informático (paso de una arquitectura de red de área local a Internet/Intranet) o al entorno de desarrollo del software (incorporación de nuevos elementos o herramientas como ODBC).

El tipo de cambio necesario puede ser muy diferente: desde un pequeño retoque en la estructura de un módulo hasta tener que re escribir prácticamente todo el programa para su ejecución en un ambiente distribuido en una red. 

Los cambios en el entorno software pueden ser de dos clases:

En el entorno de los datos, por ejemplo, al dejar de trabajar con un sistema de ficheros clásico y sustituirlo por un sistema de gestión de bases de datos relacionales.

En el entorno de los procesos, por ejemplo, migrando a una nueva plataforma de desarrollo con componentes distribuidos, Java, ActiveX, etc.

El mantenimiento adaptativo es cada vez más usual debido principalmente al cambio, cada vez más rápido, en los diversos aspectos de la informática: nuevas generaciones de hardware cada dos años, nuevos sistemas operativos -ó versiones de los antiguos- que se anuncian regularmente, y mejoras en los periféricos o en otros elementos del sistema.

Frente a esto, la vida útil de un sistema software puede superar fácilmente los diez años. [Pressman, 1993].

          Mantenimiento Perfectivo

Cambios en la especificación, normalmente debidos a cambios en los requisitos de un producto software, implican un nuevo tipo de mantenimiento llamado perfectivo.Desde algo tan simple como cambiar el formato de impresión de un informe, hasta la incorporación de un nuevo módulo aplicativo. Podemos definir el mantenimiento perfectivo como el conjunto de actividades para mejorar o añadir nuevas funcionalidades requeridas por el usuario.

Algunos autores dividen este tipo de mantenimiento en dos:

             Mantenimiento de Ampliación: orientado a la incorporación de nuevas funcionalidades.

            Mantenimiento de Eficiencia: que busca la mejora de la eficiencia de ejecución.

Este tipo de mantenimiento aumenta cuando un producto software tiene éxito comercial y es utilizado por muchos usuarios, ya que cuanto más se utiliza un software, más peticiones de los usuarios se reciben demandando nuevas funcionalidades o mejoras en las existentes.

         Mantenimiento Preventivo

Este último tipo de mantenimiento consiste en la modificación del software para mejorar sus propiedades (por ejemplo, aumentando su calidad y/o su mantenimiento) sin alterar sus especificaciones funcionales. Por ejemplo, se pueden incluir sentencias que comprueben la validez de los datos de entrada, re estructurar los programas para mejorar su legibilidad, o incluir nuevos comentarios que faciliten la posterior comprensión del programa. Este tipo de mantenimiento es el que más partido saca de las técnicas de ingeniería inversa y reingeniería.

En algunos casos se ha planteado el Mantenimiento para la Reutilización, consistente en modificar el software (buscando y modificando componentes para incluirlos en bibliotecas) para que sea mas fácilmente reutilizable. En realidad este tipo de mantenimiento es preventivo, especializado en mejorar la propiedad de reusabilidad del software.

ACTIVIDADES DE MANTENIMIENTO

         Tipos de Actividades

Basili et al. [1996] identifican las siguientes once actividades, que se realizan con cada modificación del software:

• Análisis de impacto y de costes/beneficios: se dedica esta actividad a analizar diferentes alternativas de implementación y/o a comprobar su impacto en la planificación, coste y facilidad de operación.
• Comprensión del cambio: puede consistir en localizar el error y determinar su causa, o en comprender los requisitos de una mejora solicitada.
• Diseño del cambio: se refiere al diseño propuesto para el cambio, pudiéndose incluir un rediseño del sistema.
• Codificación y pruebas unitarias: se codifica y prueba el funcionamiento de cada componente modificado.
• Inspección, certificación y consultoría: esta actividad se dedica a inspeccionar el cambio, comprobar otros diseños, reuniones de inspección, etc.
• Pruebas de integración: se refiere a comprobar la integración de los componentes modificados con el resto del sistema.
• Pruebas de aceptación: en esta actividad, el usuario comprueba, junto al personal encargado del mantenimiento, la adecuación del cambio a sus necesidades.
• Pruebas de regresión: en esta actividad se somete el software modificado a casos de pruebas previamente almacenados y por los que ya pasó.
• Documentación del sistema: se revisa y reescribe, en caso necesario, la documentación del sistema para que se ajuste al producto software ya modificado.
• Otra documentación (del usuario, por ejemplo): se revisa y reescribe, en caso necesario, los diferentes manuales de usuario y otra documentación, excepto la documentación del sistema.
• Otras actividades, como las dedicadas a la gestión del proyecto de mantenimiento.
• Otros resultados interesantes de este mismo estudio se refieren a la distribución del esfuerzo en cada grupo de actividades según se trate de mantenimiento correctivo o perfectivo, resultando que:
• La proporción de esfuerzo dedicado a comprensión es mucho mayor en el caso de mantenimiento correctivo que en perfectivo.
• La proporción de esfuerzo empleado en inspección, certificación y consultoría es mucho mayor en el caso de mantenimiento perfectivo que en correctivo.
• La proporción de esfuerzo dedicado a diseño, codificación y pruebas es muy similar en ambos tipos de mantenimiento. 

Distribución del esfuerzo en actividades de mantenimiento

          Dificultades del Mantenimiento

           La problemática del mantenimiento se resume en realizar el mantenimiento del software de forma tan rigurosa que la calidad no se deteriore como resultado de este proceso. 

La pregunta a formular es la siguiente: ¿cómo debe mantenerse el software para preservar su fiabilidad? A continuación veremos las circunstancias que hacen que la respuesta a esta pregunta no sea fácil y esté muy condicionada.

            Código Heredado

       En la actualidad, la mayor parte de éste software está formado por código antiguo “heredado” (del inglés legacy code); es decir, código de aplicaciones desarrolladas hace algún tiempo, con técnicas y herramientas en desuso y probablemente por personas que ya no pertenecen al colectivo responsable en este momento del mantenimiento del software concreto.

En muchas ocasiones la situación se complica porque el código heredado fue objeto de múltiples actividades de mantenimiento. La opción de desechar este software y reescribirlo para adaptarlo a las nuevas necesidades tecnológicas o a los cambios en la especificación es muchas veces inadecuada por la gran carga financiera que supuso el desarrollo del software original y la necesidad económica de su amortización.

Los problemas específicos del mantenimiento de código heredado han sido caracterizados en las llamadas Leyes del Mantenimiento del Software [Lehman, 1980]:

Continuidad del Cambio – Un programa utilizado en un entorno del mundo real debe cambiar, ya que si no cada vez será menos usado en dicho entorno. En otras palabras, esto significa que, tan pronto como un programa ha sido escrito, está ya desfasado. Las razones que conducen a esta afirmación son varias: a los usuarios se les ocurren nuevas funcionalidades cuando comienzan a utilizar el software; nuevas características en el hardware pueden permitir mejoras en el software; se encuentran defectos en el software que deben ser corregidos; el software debe instalarse en otro sistema operativo o máquina; o el software necesita ser más eficiente.

Incremento de la Complejidad – A la par que los cambios transforman los programas, su estructura se hará progresivamente más compleja salvo que se haga un esfuerzo activo para evitar este fenómeno. Esto significa que al realizar cambios en un programa (excluyendo el mantenimiento preventivo), la estructura de dicho programa se hace más compleja cuando los programadores no pueden o no quieren usar técnicas de ingeniería del software

Evolución del Programa – La evolución de un programa es un proceso autorregulado. Las medidas de determinadas propiedades (tamaño, tiempo entre versiones y número de errores) revelan estadísticamente determinadas tendencias e invariantes.

Conservación de la Estabilidad Organizacional – A lo largo del tiempo de vida de un programa, la carga que supone el desarrollo de dicho programa es aproximadamente constante e independiente de los recursos dedicados.

Conservación de la Familiaridad – Durante todo el tiempo de vida de un sistema, el incremento en el número de cambios incluidos con cada versión (release) es aproximadamente constante. Casi veinte años después, el mismo autor vuelve a confirmar las leyes anteriores [Lehman et al., 1998]: la afirmación “los grandes programas no llegan nunca a completarse y están en constante evolución” se ve confirmada por el hecho de que, como ya hemos mencionado, algo más del 60% de las modificaciones que se realizan en el software se refieren a mantenimiento perfectivo.

Problemas de Mantenimiento

           Además de las dificultades de mantenimiento que señalan las leyes anteriores, existen otros problemas clásicos que complican el mantenimiento [Schneidewind, 1987]:

A menudo, el mantenimiento es realizado de una manera ad hoc en un estilo libre establecido por el propio programador (esta opinión también es compartida por Pressman [1993], quien afirma que “raramente existen organizaciones formales, de modo que el mantenimiento se lleva a cabo como se pueda”). No en todas las ocasiones esta situación es debida a la falta de tiempo para producir una modificación diseñada cuidadosamente. Prácticamente todas las metodologías se han centrado en el desarrollo de nuevos sistemas y no han tenido en cuenta la importancia del mantenimiento. Por esta razón, no existen o son poco conocidos los métodos, técnicas y herramientas que proporcionan una solución global al problema del mantenimiento.

Cambio tras cambio, los programas tienden a ser menos estructurados. Esto se manifiesta en una documentación desfasada (como afirman Baxter y Pigdeon [1997] al indicar que “la documentación completa o inexistente del sistema es uno de los cuatro problemas más importantes del mantenimiento de software”), código que no cumple los estándares, incremento en el tiempo que los programadores necesitan para entender y comprender los programas o en el incremento en los efectos secundarios producidos por los cambios. Todas estas situaciones implican casi siempre unos costes de mantenimiento del software muy altos.

Es muy habitual que los sistemas que están siendo sometidos a mantenimiento sean cada vez más difíciles de cambiar (lo cual, como confirman Griswold y Notkin [1993], provoca que el mantenimiento sea cada vez más costoso). Esto se debe al hecho de que los cambios en un programa por actividades de mantenimiento dificultan la posterior comprensión de la funcionalidad del programa. Sommerville [1992] también apunta que “cualquier cambio conlleva la corrupción de la estructura del software y, a mayor corrupción, la estructura del programa se torna menos comprensible y más difícil de modificar”.

Por ejemplo, el programa original puede basarse en decisiones de programación no documentadas a las que no puede acceder el personal de mantenimiento. En estas situaciones, es normal que el software no pueda ser cambiado sin correr el riesgo de introducir efectos laterales no deseados debidos a interdependencias entre variables y procedimientos que el personal de mantenimiento no ha detectado.

La falta de una metodología adecuada suele conducir a que los usuarios participen poco durante el desarrollo del sistema software. Esto tiene como consecuencia que, cuando el producto se entrega a los usuarios, no satisface sus necesidades y se tienen que producir esfuerzos de mantenimiento mayores en el futuro.

Además de los problemas de carácter técnico anteriores, también pueden existir problemas de gestión. Muchos programadores consideran el trabajo de mantenimiento como una actividad inferior menos creativa- que les distrae del trabajo -mucho más interesante- del desarrollo de software. Esta visión puede verse reforzada por las condiciones laborales y salariales y crea una baja moral entre las personas dedicadas al mantenimiento. Como resultado de lo anterior, cuando se hace necesario realizar mantenimiento, en vez de emplear una estrategia sistemática, las correcciones tienden a ser realizadas con precipitación, sin pensarse de forma suficiente, no documentadas adecuadamente y pobremente integradas con el código existente. No es extraño, pues, que el propio mantenimiento conduzca a la introducción de nuevos errores e ineficiencias que conducen a nuevos esfuerzos de mantenimiento con posterioridad.

Todos estos problemas se pueden atribuir –parcialmente al gran número de programas existentes que han sido desarrollados sin tener en cuenta la ingeniería del software. Esta área de la informática no es una panacea, pero, por lo menos, aporta soluciones parciales a los diversos problemas planteados con el mantenimiento del software. 

Documentación de Software

Todos los grandes proyectos de desarrollo de software, con independencia de la aplicación, generan una gran cantidad de documentación asociada. Para los sistemas de tamaño moderado, la documentación probablemente llenará varios archivadores; para sistemas grandes, se puede llenar varias habitaciones. Una alta proporción de los costos del proceso de software se incurre en la producción de esta documentación. Por otra parte, los errores de documentación y omisiones pueden dar lugar a errores de los usuarios finales y los fallos del sistema con los consiguientes sus costos y las interrupciones asociadas. Por lo tanto, los gerentes y el software.  

Los ingenieros deben prestar tanta atención a la documentación y sus costos asociados como al desarrollo del software en sí.

Los documentos asociados con un proyecto de software y el sistema están desarrollados para cumplir una serie de requisitos asociados:

1. Deben actuar como medio de comunicación entre los miembros de la Equipo de desarrollo.

2. Deben ser un repositorio de información del sistema para ser utilizado por los ingenieros de mantenimiento.

3. Deben proporcionar información para la gestión de cómo facilitar la planificación, presupuesto y el calendario del proceso de desarrollo de software.

4. Algunos de los documentos debe indicar a los usuarios cómo utilizar y administrar el sistema.

La satisfacción de estas necesidades requiere de diferentes tipos de documentos,  desde los documentos de trabajo informales producidos profesionalmente a través de manuales de usuario.

Los ingenieros de software son generalmente responsables de la producción de la mayor parte de esta documentación, aunque los escritores técnicos profesionales puede ayudar con pulido final de información dada a conocer.

 (Ian Sommerville -Software documentation, Page 2- Lancaster University, UK)

El documento de desarrollo de software contiene todos los preparativos relacionados con el desarrollo de cada unidad o módulo, incluyendo el software, los casos de prueba, resultados de pruebas, homologaciones, y cualquier otro artículo que ayudarán a explicar la funcionalidad del software. El documento es dinámico y es mantenido por el equipo de desarrollo del sistema y en se actualiza constantemente a medida que avanza el desarrollo del sistema.

El modelo tradicional de Proyectos de Software

El modelo de desarrollo tradicional de los proyectos suele ser el modelo de cascada clásico de la ingeniería de software. El proyecto está concebido, financiado y atendido. En ese momento la fase de concepción se mueve en el análisis de requisitos, se desarrollan especificaciones funcionales, y se determina la arquitectura. A continuación, se especifica el diseño, una implementación creada, y la puesta en práctica se comprueba con las especificaciones de la arquitectura. Si todo va bien, el proyecto es aceptado.

En cada etapa del proyecto de software tradicional, se introducen nuevas partes interesadas y los interesados ​​tienen cada vez más bajos estos niveles de enfoque. Si la comunicación del concepto no está clara, los arquitectos pueden llegar a una propuesta que no coincide con el concepto original. Si la arquitectura es más o de menos restringida, la aplicación puede ser insostenible o incompleta. Si la especificación de la validación no coincide con la arquitectura de la aceptación puede no coincidir con el producto aplicado. Por último, si la documentación de usuario final no coincide con la arquitectura y la aplicación, el usuario final va a encontrar que el producto va a llevar mucho tiempo, y será frustrante y costoso. Cualquiera que haya jugado el juego de teléfono y observado cómo ilegible incluso un simple mensaje puede llegar a apreciar cómo un pequeño defecto en la cadena de comunicación de un proyecto complejo puede conducir a la catástrofe en el producto final.

El modelo de proyecto de desarrollo de software abierto

El modelo de desarrollo de software abierto difiere del modelo tradicional en varios aspectos importantes.

En primer lugar, el concepto y los requisitos normalmente vienen directamente desde el usuario final, y por lo general se acompañan de una implementación en bruto en forma de un prototipo.

En segundo lugar, en el modelo abierto las partes interesadas en cada etapa son diferentes. En el caso del modelo tradicional, las necesidades de la empresa (el caso de negocios) en última instancia, conducen el alcance y los requisitos de un proyecto; la fase de concepto está a punto de ponerse en piedra por el momento los ejecutores comienzan a participar. En el modelo de desarrollo abierto, la atención se centra más en general, el resultado deseado de los usuarios finales del producto. Los requisitos, e incluso los conceptos de alto nivel son más libres para evolucionar con el tiempo que el proyecto avanza.

El papel de la comunicación en el desarrollo de software

Los proyectos de software muy exitosos tienen éxito porque dan el nivel adecuado de atención a la comunicación clara de los conceptos y requisitos claves. Los expertos en ingeniería de software tienen diferentes opiniones sobre qué parte del esfuerzo total se debe dar a primeras fases de un proyecto.

Para hacer un proyecto abierto que se propone en la forma de un prototipo exitoso, es aún más importante tener en cuenta que los conceptos y requisitos deben estar bien documentados para la comunidad a un acuerdo sobre ellos. Hay varias razones para esto:

Los Ingenieros en proyectos de desarrollo tradicionales suelen ser geográficamente coincidentes, y utilizan formas de comunicación, tales como reuniones y sesiones de pizarra para llegar a decisiones y acuerdos. Los proyectos de desarrollo abiertos casi siempre están distribuidos geográficamente. El correo electrónico y las páginas web del proyecto, que son formas de comunicación, son típicamente las formas dominantes de la toma de decisiones y acuerdos; esto hace que una mayor precisión e integridad en una necesidad.

Al contrario que en el modelo tradicional en el que los grupos de interés son los jefes de productos, los proyectos abiertos tienen toda la comunidad (y los usuarios finales) como los actores. Si la comunidad no puede ponerse de acuerdo sobre los objetivos de alto nivel y los requisitos funcionales de un proyecto de software, el proyecto está condenado al fracaso desde el principio.

La documentación de conceptos, requisitos y Arquitectura

Los conceptos y requisitos comprenden la gran vista de los cuadros del proyecto de software. Estos definen aspectos como las principales capacidades del producto y el mercado objetivo previsto. La arquitectura define la entrada / salida de métodos, características de interoperabilidad, y la interfaz de usuario.

En las primeras fases de un proyecto los detalles aparentemente sin importancia, como la forma en que se reunieron los requisitos a menudo no se registran. Los intercambios de alto nivel realizados en la cartografía de los requisitos en la arquitectura a menudo no están bien documentados (en su caso).

Una trampa menos evidente en este punto es que los requisitos y la arquitectura se cuecen generalmente por los ingenieros de software experimentados con una idea buena, aunque incompleta, de los requisitos de los ejecutores. Por otro lado, los ejecutores son por lo general personas con menos experiencia, y tienen un enfoque más local - lo que significa que hay una oportunidad para la pérdida de la información inherente al traducir los requerimientos en las construcciones de software. Si un implementador no entiende cuan flexible es un requisito, o por qué el requisito esta allí en absoluto, la aplicación puede ser inadecuada o excesivamente limitada.

Este último efecto, se magnifica en el modelo de desarrollo abierto, donde los ejecutores no funcionan con el software como su trabajo del día; si lo hacen, a menudo no tienen el beneficio de años de experiencia en redes con los ingenieros dentro de una importante empresa de software. Si un proyecto de desarrollo abierto va a ser asumido por los ejecutores con menos experiencia, entonces la comunicación clara de los conceptos, las necesidades, y la arquitectura del software es de suma importancia.

La importancia de la documentación en el desarrollo de software

Para un programador una documentación fiable es siempre una necesidad. La presencia de la documentación ayuda a realizar un seguimiento de todos los aspectos de una aplicación y mejora de la calidad de un producto de software. Sus ejes principales son el desarrollo, el mantenimiento y la transferencia de conocimientos a otros desarrolladores. La documentación acertada hará que la información sea fácilmente accesible, proporciona un número limitado de puntos de entrada de los usuarios, ayuda a los nuevos usuarios a aprender rápidamente, simplifica el producto y ayuda a reducir los costos de soporte. La documentación se centra generalmente en los siguientes componentes que conforman una aplicación: entornos de servidores, reglas de negocio, bases de datos / archivos, resolución de problemas, instalación y despliegue de aplicaciones de código.

Entornos de servidor

La documentación detallada acerca de una aplicación y sus entornos es siempre una necesidad. Esta información le ayudará con la creación de nuevos entornos para su aplicación y se debe presentar la ubicación y función de los sistemas que ejecutan sus servicios. Cosas que deben ser especificados aquí son el nombre de la aplicación / versión, el nombre del servidor, IP, directorio de código, la URL de la aplicación, el sistema operativo, información de la cuenta de usuario y un punto de contacto.

Reglas del negocio

La documentación de las reglas de negocio ayuda al equipo a adaptarse a nuevas incorporaciones más rápidamente, y a los hábitos de trabajo de la empresa. Proporciona información sobre cómo funciona el producto y por qué. La documentación de las reglas de negocio puede ser fácilmente compatible con los documentos de requisitos si están disponibles. Esto acelerará la curva de aprendizaje de un desarrollador de manera significativa. Además de las reglas de negocio, un documento de ayuda, preguntas frecuentes, o guía del usuario puede ayudar a resaltar los puntos principales de una solicitud de un desarrollador que necesita un contexto para la aplicación que están apoyando.

Base de datos / archivos

La información de base de datos es obligatoria. Es importante conocer el tipo de base de datos, la información del servidor, la versión pero lo más importante para tener un diagrama de modelo de datos. La documentación de la base de datos hará que el traer adiciones a la mesa, las modificaciones a la estructura y los tipos, las adiciones de índices y claves sea mucho más simple y más fácil de controlar y depurar. Además, si una aplicación presenta una funcionalidad de transferencia de archivos, se recomienda documentar en que forma se efectúa la transferencia, a través de qué protocolo y tipos de datos, y si SSL necesita certificados.

Solución de problemas

La documentación de la solución de problemas ayuda cuando se produzcan problemas de producción. La mayoría de los problemas técnicos deben tener los códigos de error que deberían ayudar a solucionar los problemas. En este documento también se debe incluir una sección de preguntas frecuentes para resolver los problemas más generales o habituales (tales como problemas de configuración). Los errores se deben documentar divididos por tipo de error, el módulo de dónde viene, y el nivel de error (excepción, advertencia, crítica, etc....).

Instalación de aplicaciones

Los Documentos de instalación y configuración son útiles para cuando los desarrolladores necesitan crear entornos nuevos o adicionales de aplicación. Si es posible, las medidas deben ser detalladas y fáciles de seguir y pueden incluir capturas de pantalla si es necesario. Cualquier persona debería ser capaz de seguir los pasos e instalar con éxito una aplicación. Tener los pasos identificados ayudará a prevenir al instalador problemas debido a la falta de piezas de una aplicación. Detalles como el software necesario, las bibliotecas y las versiones de servidor de aplicaciones, se pueden incluir para garantizar que el medio ambiente será compatible y configurado según lo previsto.

El Código

La documentación de código es la espina dorsal de cada aplicación. La documentación de código se puede dividir en varias partes. El primero de ellos, el más útil para los programadores son los bloques de comentarios. Estos se encuentran a través de todos los archivos que explica clases, métodos, parámetros posibles errores. Luego viene la documentación de archivos específicos. Estos normalmente se generan a través de una secuencia de comandos de terceros que analizar un archivo y, a partir de los bloques de comentarios, se creará un PDF explícito. Posteriormente debe haber información sobre el repositorio de código, donde se encuentran las actualizaciones de archivos, y donde tienen que ser movido. Además, no debe haber paso a paso las instrucciones sobre cómo crear un paquete de aplicación o una generación que se desplegarán.

10 señales de que una carrera en la codificación y el desarrollo de software podría ser adecuada para usted

En las últimas pruebas realizadas con la intención de evaluar los conocimientos y habilidades de los últimos 15 años en todo el mundo, el Reino Unido ocupó el 26to en matemáticas y 20mo para la ciencia, una baja general del 28 y 16, respectivamente, en 2009.

Estas pruebas no cuentan necesariamente la historia completa. Los empleadores buscan otros atributos y habilidades personales, más allá de las credenciales académicas, al evaluar la idoneidad de los candidatos, por ejemplo, la creatividad, el enfoque de colaboración y un espíritu empresarial son tan importantes como la aptitud y experiencia.

Así que para ayudar a presentar las habilidades necesarias para la programación de computadoras en una luz diferente, aquí hay 10 señales de que la codificación o programación de computadoras podría ser adecuada para usted; señales que no siempre se contabilizan en las pruebas académicas.

1. Usted es un profesional de resolución de problemas

Hay mucha gente que simplemente tolera los problemas sin buscar una manera proactiva para resolverlos, sobre todo si tolerar el problema es más fácil. Si usted no toma este enfoque, pero en realidad disfruta el desafío de resolver problemas de todo tipo, entonces eso es una gran señal de que usted podría ser adecuado para el desarrollo de software. Si, en su deseo de resolver los problemas, también se tienen en cuenta las limitaciones realistas - como los plazos y presupuestos - entonces esto podría ser un activo real en su búsqueda de una carrera.

2. Usted tiene una pasión por los juegos de estrategia

Sí, puede ser cierto que el juego es bueno para ti, especialmente cuando a los juegos de estrategia se refiere. Estos ayudan a perfeccionar su capacidad de tomar decisiones en base a una serie de factores pertinentes, teniendo en cuenta las consecuencias tanto a corto como a largo plazo. Además de los juegos de ordenador, los que disfrutan de juegos fuera de línea como el ajedrez, un puente o de riesgo, también podría tener una aptitud fundamental para la programación. En Net-a-porter, por ejemplo, incluso tenemos un club de juegos semanal.

3. Usted tiene una mente musical

Mientras que la evidencia de la correlación entre la música y las matemáticas está todavía en debate, aparece un lugar común para las personas con talento musical que tienen habilidades matemáticas. En nuestro equipo, existen numerosos codificadores que componen música, cantan o tocar un instrumento. De hecho, aproximadamente la mitad de los cantantes en el coro de la empresa son del departamento de TI.

4. Usted tiene un talento para ganar discusiones

No, no estamos hablando de partidos y gritos en toda regla. Pero si su enfoque lógico para discutir sus puntos de vista de una manera estructurada significa que con frecuencia gana sobre sus oponentes, esto podría ser una señal de que usted tiene el pensamiento sistemático necesario para el desarrollo de software.

5. Te encanta hacer las cosas

Usted puede obtener el mismo sentido de la satisfacción al hacer algo en el mundo virtual como puedes en el mundo físico. De hecho, en el mundo digital, usted no está limitado por aspectos prácticos como los materiales y el espacio, por lo que la imaginación es su único límite. Tener una curiosidad natural de cómo funcionan las cosas, y cómo hacer que funcionen mejor, es una buena indicación de un desarrollador de software naciente.

6. Usted es una persona de personas

Contrariamente al estereotipo del equipo de TI escondido del resto de la compañía, trabajando como desarrollador en realidad puede implicar una gran cantidad de interacción con otros en todo el negocio. Esto significa que un disfrute de la comunicación y la capacidad de explicar las cosas de una manera que sea de fácil comprensión por otros, son a la vez muy importante.

7. ¿Le gustaría saber más sobre la teoría de la ciencia de la computación?

Aunque puede que no haya digerido la historia completa de la informática, un interés en la teoría detrás de la ingeniería de software es un aspecto importante de habilidades de un codificador. Usted no quiere gastar su tiempo en volver a inventar la rueda, por lo que esta interesado en lo que otros han descubierto, y esta preparado para construir sobre esos cimientos, será acelerar sus posibles logros.

8. Usted es un jugador de equipo

La codificación en sí es un proceso muy colaborativo; la revisión continua y la redefinición de código con los demás le ayuda a sacudir bichos, hace que su trabajo sea más probable de satisfacer las necesidades de los usuarios y es una de las mejores maneras de aprender. Por lo tanto, los desarrolladores lo necesitan para disfrutar de trabajar juntos y deben estar preparados para estudiar, criticar y mejorar el trabajo de otros.

9. Usted está motivado intrínsecamente

Poner un poco de psicología de aficionado a utilizar, parece ser cierto que los mejores desarrolladores están motivados intrínsecamente. Esto significa que tienen su recompensa y la motivación desde el proceso de encontrar una solución a un problema, o crear algo innovador en sí mismo. En otras palabras, los desarrolladores a menudo hacen lo que hacen por el amor de hacerlo, y no sólo se presta para hacerlo.

10. Te encanta la tecnología

Esto es bastante obvio, pero vale la pena reiterar que si quieres trabajar en ingeniería de software, es necesario tener una apreciación de las posibilidades increíbles que la tecnología trae al mundo. Estar interesado en cómo se puede aprovechar el potencial de la tecnología, para cualquier empresa en la que desea trabajar, definitivamente le va a colocar en una buena posición, y es un signo de que usted está en la pista de carrera correcta para el éxito en la codificación.