Fases del desarrollo de Software


El Software (Sistemas Operativos, Programas, Juegos, Utilidades,…) que desarrollan los fabricantes pasan por varias fases antes hacerse públicos. Las fases más comunes son:

  • Alpha: Es la primera versión funcional de programa aunque contiene gran cantidad de fallos que se corregiran en posteriores revisiones, no suelen ser versiones para el público ya que son bastante inestables, normalmente a las versiones Alpha suele añadirse la letra “a” o bien se les denomina “Alpha” directamente.
  • Beta: Son versiones más pulidas que las anteriores, que si bien siguen teniendo algunos fallos su proporción es menor y en muchos casos se hace “públicas” para su descarga, aún asi al ser versiones no terminadas pueden ser inestables y dar algún que otro error, normalmente siempre suele ser mejor esperar a la versión definitiva en lugar de usar una “Beta”, aunque es cierto que muchas “Betas” funcionan bastante bien. Normalmente a estas versiones suele añadirse la letra “b” o denominarse “Beta” directamente.
  • RC (Release Candidate, Candidata a Definitiva o Candidata para el Lanzamiento): Son versiones que están muy perfeccionadas y apenas tienen errores. A veces se usan letras griegas como Gamma, Delta e incluso Omega (la última letra del alfabeto griego) que denota una versión libre de errores.
  • RTM (Release to Manufacturing): También se denomina Versión de Disponibilidad General, estas versiones son las que se distribuyen al público, en princio no tienen errores, aunque en el caso de los programas de Microsoft (y de muchos otros fabricantes de software) siempre salen los típicos “parches” que solucionan algunos pequeños fallos no documentados hasta la fecha de publicación, es decir que son fallos a posteriori no como en los casos anteriores (Versiones RC y anteriores) que al ser versiones con “errores” en caso de detectar un fallo lo normal es corregirlo.

Por otro lado en el mundo Linux para indicar si una version del Kernel (Núcleo del Sistema Operativo) es estable o inestable se usaba el número de versión que estaba formado por 4 números separados por puntos, si el segundo número era:

  • Par (ej: 2.2.1.1) la versión se cataloga como “estable”, siendo totalmente funcional, siendo utilizable en sistemas de producción sin problemas.
  • Impar (ej: 2.1.3.4) la versión se catalogaba como “inestable” y es poco recomendable su utilización, incluso algunas versiones se acompañan del texto “-dontuse”  (No usar) para indicar que son versiones pocos estables dedicadas a sistemas experimentales y nada aconsejables para sistema de producción.

Actualmente los Kernel independientemente de su versión ya sea par o impar, se consideran versiones estables.

Así mismo los fabricantes de software para diferenciar versiones suelen usar dos tipos de nomenclatura:

  • Versiones numeradas (ej: 2.x.x.x) que indican:
    • Pequeños cambios si la versión se mantiene, por ejemplo pasar de la versión 3.0 a la 3.1 o incluso a la 3.9 implicaría que los cambios en la aplicación no son muy importantes ya que se mantiene el número de versión inicial.
    • Grandes cambios si cambia el primer número de versión, por ejemplo pasar de la version 3.5 a la versión 4.0 implicaría grandes cambios en la aplicación, bien en su interfaz de usuario o en sus capacidades técnicas.
  • Versiones por año, por ejemplo:
    • Windows 98 es anterior a Windows 2000.
    • Windows 2000 Server es anterior a Windows 2003 Server.
    • Office 2.003 en anterior al Office 2.007.

Más Información en:

Anuncios
A %d blogueros les gusta esto: