Etapas de desarrollo de software

Captura, anlisis y especificacin de requisitos

En simple palabras y bsicamente, durante esta fase, se adquieren, renen y especifican las
caractersticas funcionales y no funcionales que deber cumplir el futuro programa o sistema a
desarrollar.
El artefacto ms importante resultado de la culminacin de esta etapa es lo que se conoce
como especificacin de requisitos software o simplemente documento ERS.
La especificacin de requisitos de software (ERS) es una descripcin completa del
comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que
describe todas las interacciones que tendrn los usuarios con el software. Los casos de uso
tambin son conocidos como requisitos funcionales. Adems de los casos de uso, la ERS tambin
contiene requisitos no funcionales (o complementarios). Los requisitos no funcionales son
requisitos que imponen restricciones en el diseo o la implementacin, como, por ejemplo,
restricciones en el diseo o estndares de calidad.
Las caractersticas de una buena ERS son definidas por el estndar IEEE 830-1998. Una buena
ERS debe ser:
Completa. Todos los requerimientos deben estar reflejados en ella y todas las referencias
deben estar definidas.
Consistente. Debe ser coherente con los propios requerimientos y tambin con otros
documentos de especificacin.
Inequvoca. La redaccin debe ser clara de modo que no se pueda mal interpretar.
Correcta. El software debe cumplir con los requisitos de la especificacin.
Trazable. Se refiere a la posibilidad de verificar la historia, ubicacin o aplicacin de un
tem a travs de su identificacin almacenada y documentada.
Priorizable. Los requisitos deben poder organizarse jerrquicamente segn su relevancia
para el negocio y clasificndolos en esenciales, condicionales y opcionales.
Modificable. Aunque todo requerimiento es modificable, se refiere a que debe ser
fcilmente modificable.
Verificable. Debe existir un mtodo finito sin costo para poder probarlo.





Desde un punto de vista conceptual, las actividades para definir requisitos son:
Obtener requisitos: a travs de entrevistas o comunicacin con clientes o futuros usuarios,
para saber cules son sus expectativas.
Analizar requisitos: detectar y corregir las carencias o falencias comunicativas,
transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas
para ser tratados en el diseo.
Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente
documentados.
Verificar los requisitos: consiste en comprobar la implementacin de los requerimientos.
Validar los requisitos: comprobar que los requisitos implementados sean funcionales para lo
que inicialmente se construy el producto.

Existen varios tipos de requisitos como lo son:
1. Requisitos de Usuarios: Necesidades que los usuarios expresan verbalmente
2. Requisitos del Sistema: Son los componentes que el sistema debe tener para realizar
determinadas tareas
3. Requisitos Funcionales: Servicios que el sistema debe proporcionar
4. Requisitos no funcionales: Restricciones que afectan al sistema

Un primer paso para realizar el relevamiento de informacin es el conocimiento y definicin
acertada lo que se conoce como Universo de Discurso del problema, que se define y entiende
por:
Universo de Discurso (UdeD): es el contexto general en el cual el software deber ser
desarrollado y deber operar. El UdeD incluye todas las fuentes de informacin y todas las
personas relacionadas con el software. Esas personas son conocidas tambin como actores de
ese universo. El UdeD es la realidad circunstanciada por el conjunto de objetivos definidos por
quienes demandaron el software.
A partir de la extraccin y anlisis de informacin en su mbito se obtienen todas las
especificaciones necesarias y tipos de requisitos para el futuro producto software.

En la figura se muestra un esquema, ms o menos riguroso, aunque no detallado, de los pasos y
tareas a seguir para realizar la captura, anlisis y especificacin de requisitos software. Tambin
all se observa qu artefacto o documento se obtiene en cada etapa del proceso.


Una posible lista, general y ordenada, de tareas recomendadas para obtener la definicin de lo que
se debe realizar, los productos a obtener y las tcnicas a emplear durante la actividad de elicitacin
de requisitos, en fase de Especificacin de Requisitos Software es:
1. Obtener informacin sobre el dominio del problema y el sistema actual (UdeD).
2. Preparar y realizar las reuniones para elicitacin/negociacin.
3. Identificar/revisar los objetivos del usuario.
4. Identificar/revisar los objetivos del sistema.
5. Identificar/revisar los requisitos de informacin.
6. Identificar/revisar los requisitos funcionales.
7. Identificar/revisar los requisitos no funcionales.
8. Priorizar objetivos y requisitos.
Algunos principios bsicos a tener en cuenta:
Presentar y entender cabalmente el dominio de la informacin del problema.
Definir correctamente las funciones que debe realizar el Software.
Representar el comportamiento del software a consecuencias de acontecimientos externos,
particulares, incluso inesperados.
Reconocer requisitos incompletos, ambiguos o contradictorios.
Dividir claramente los modelos que representan la informacin, las funciones y
comportamiento y caractersticas no funcionales.
Se pueden identificar dos formas de requisitos:
Requisitos de usuario: Los requisitos de usuario son frases en lenguaje natural junto a
diagramas con los servicios que el sistema debe proporcionar, as como las restricciones
bajo las que debe operar.
Requisitos de sistema: Los requisitos de sistema determinan los servicios del sistema y pero
con las restricciones en detalle. Sirven como contrato.
Es decir, ambos son lo mismo, pero con distinto nivel de detalle.
Ejemplo de requisito de usuario: El sistema debe hacer prstamos
Ejemplo de requisito de sistema: Funcin prstamo entrada: cdigo socio, cdigo ejemplar;
salida: fecha devolucin; etc.


Se clasifican en tres los tipos de requisitos de sistema:
Requisitos funcionales
Los requisitos funcionales describen:
Los servicios que proporciona el sistema (funciones).
La respuesta del sistema ante determinadas entradas.
El comportamiento del sistema en situaciones particulares.

Requisitos no funcionales
Los requisitos no funcionales son restricciones de los servicios o funciones que ofrece el sistema
(ej. cotas de tiempo, proceso de desarrollo, rendimiento, etc.)
Ejemplo 1. La biblioteca Central debe ser capaz de atender simultneamente a todas las
bibliotecas de la Universidad
Ejemplo 2. El tiempo de respuesta a una consulta remota no debe ser superior a 1/2 s
A su vez, hay tres tipos de requisitos no funcionales:
Requisitos del producto. Especifican el comportamiento del producto (Ej. prestaciones,
memoria, tasa de fallos, etc.)
Requisitos organizativos. Se derivan de las polticas y procedimientos de las
organizaciones de los clientes y desarrolladores (Ej. estndares de proceso, lenguajes
de programacin, etc.)
Requisitos externos. Se derivan de factores externos al sistema y al proceso de
desarrollo (Ej. requisitos legislativos, ticos, etc.)

Requisitos del dominio.
Los requisitos del dominio se derivan del dominio de la aplicacin y reflejan caractersticas de dicho
dominio.
Pueden ser funcionales o no funcionales.
Ej. El sistema de biblioteca de la Universidad debe ser capaz de exportar datos mediante el
Lenguaje de Intercomunicacin de Bibliotecas de Espaa (LIBE). Ej. El sistema de biblioteca no
podr acceder a bibliotecas con material censurado.
Diseo del sistema
Se basa en la especificacin de requisitos producido por el anlisis de los requisitos (fase de
anlisis), el diseo define cmo estos requisitos se cumplirn, la estructura que debe darse al
sistema de software para que se haga realidad.
El diseo, en particular, puede describir el funcionamiento interno de un sistema en diferentes
niveles de detalle, cada una de ellos se coloca en una posicin intermedia entre el anlisis y
codificacin.
Normalmente se entiende por "diseo de la arquitectura" al diseo de "muy alto nivel", que slo
define la estructura del sistema en trminos de la mdulos de software de que se compone y las
relaciones macroscpicas entre ellos. A este nivel de diseo pertenecen frmulas como cliente-
servidor o tres niveles, o, ms generalmente, las decisiones sobre el uso de la arquitectura de
hardware especial que se utilice, el sistema operativo, DBMS, Protocolos de red, etc.
Un nivel intermedio de detalle puede definir la descomposicin del sistema en mdulos, pero esta
vez con una referencia ms o menos explcita al modo de descomposicin que ofrece el
particular lenguaje de programacin con el que el desarrollo se va a implementar, por ejemplo, en
un diseo realizado con la tecnologa de objetos, el proyecto podra describir al sistema en
trminos de clases y sus interrelaciones.
El diseo detallado, por ltimo, es una descripcin del sistema muy cercana a la codificacin (por
ejemplo, describir no slo las clases en abstracto, sino tambin sus atributos y los mtodos con sus
tipos).

Codificacin del software
Durante esta etapa se realizan las tareas que comnmente se conocen como programacin; que
consiste, esencialmente, en llevar a cdigo fuente, en el lenguaje de programacin elegido, todo lo
diseado en la fase anterior.
Mientras se programa la aplicacin, sistema, o software en general, se realizan tambin tareas de
depuracin, esto es la labor de ir liberando al cdigo de los errores factibles de ser hallados en esta
fase (de semntica, sintctica y lgica). Hay una suerte de solapamiento con la fase siguiente, ya
que para depurar la lgica es necesario realizar pruebas unitarias, normalmente con datos de
prueba; claro es que no todos los errores sern encontrados slo en la etapa de programacin,
habrn otros que se encontrarn durante las etapas subsiguientes. La aparicin de algn error
funcional (mala respuesta a los requisitos) eventualmente puede llevar a retornar a la fase de
diseo antes de continuar la codificacin.
Durante la fase de programacin, el cdigo puede adoptar varios estados, dependiendo de la
forma de trabajo y del lenguaje elegido, a saber:
Cdigo fuente: es el escrito directamente por los programadores en editores de texto, lo cual
genera el programa. Contiene el conjunto de instrucciones codificadas en algn lenguaje de
alto nivel. Puede estar distribuido en paquetes, procedimientos, bibliotecas fuente, etc.
Cdigo objeto: es el cdigo binario o intermedio resultante de procesar con un compilador el
cdigo fuente. Consiste en una traduccin completa y de una sola vez de ste ltimo. El
cdigo objeto no es inteligible por el ser humano (normalmente es formato binario) pero
tampoco es directamente ejecutable por la computadora. Se trata de una representacin
intermedia entre el cdigo fuente y el cdigo ejecutable, a los fines de un enlace final con las
rutinas de biblioteca y entre procedimientos o bien para su uso con un pequeo intrprete
intermedio [a modo de distintos ejemplos vase EUPHORIA, (intrprete
intermedio), FORTRAN (compilador puro) MSIL (Microsoft Intermediate Language) (intrprete)
y BASIC (intrprete puro, intrprete intermedio, compilador intermedio o compilador puro,
depende de la versin utilizada)].
Cdigo ejecutable: Es el cdigo binario resultado de enlazar uno o ms fragmentos de cdigo
objeto con las rutinas y bibliotecas necesarias. Constituye uno o ms archivos binarios con un
formato tal que el sistema operativo es capaz de cargarlo en la memoria RAM (eventualmente
tambin parte en una memoria virtual), y proceder a su ejecucin directa. Por lo anterior se dice
que el cdigo ejecutable es directamente inteligible por la computadora. El cdigo ejecutable,
tambin conocido como cdigo mquina, no existe si se programa con modalidad de intrprete
puro.

Pruebas (unitarias y de integracin)
Entre las diversas pruebas que se le efectan al software se pueden distinguir principalmente:
Prueba unitarias: Consisten en probar o testear piezas de software pequeas; a nivel de
secciones, procedimientos, funciones y mdulos; aquellas que tengan funcionalidades
especficas. Dichas pruebas se utilizan para asegurar el correcto funcionamiento de secciones
de cdigo, mucho ms reducidas que el conjunto, y que tienen funciones concretas con cierto
grado de independencia.
Pruebas de integracin: Se realizan una vez que las pruebas unitarias fueron
concluidas exitosamente; con stas se intenta asegurar que el sistema completo, incluso los
subsistemas que componen las piezas individuales grandes del software funcionen
correctamente al operar e inteoperar en conjunto.
Las pruebas normalmente se efectan con los llamados datos de prueba, que es un conjunto
seleccionado de datos tpicos a los que puede verse sometido el sistema, los mdulos o los
bloques de cdigo. Tambin se escogen: Datos que llevan a condiciones lmites al software a fin
de probar su tolerancia y robustez; datos de utilidad para mediciones de rendimiento; datos que
provocan condiciones eventuales o particulares poco comunes y a las que el software
normalmente no estar sometido pero pueden ocurrir; etc. Los datos de prueba no
necesariamente son ficticios o creados, pero normalmente s lo son los de poca probabilidad de
ocurrencia.
Generalmente, existe un fase probatoria final y completa del software, llamada Beta Test, durante
la cual el sistema instalado en condiciones normales de operacin y trabajo es probado
exhaustivamente a fin de encontrar errores, inestabilidades, respuestas errneas, etc. que hayan
pasado los previos controles. Estas son normalmente realizadas por personal idneo contratado o
afectado especficamente a ello. Los posibles errores encontrados se transmiten a los
desarrolladores para su depuracin. En el caso de software de desarrollo a pedido, el usuario
final (cliente) es el que realiza el Beta Test, teniendo para ello un perodo de prueba pactado con el
desarrollador.
Mantenimiento
El mantenimiento de software es el proceso de control, mejora y optimizacin del software ya
desarrollado e instalado, que tambin incluye depuracin de errores y defectos que puedan
haberse filtrado de la fase de pruebas de control y beta test. Esta fase es la ltima (antes de iterar,
segn el modelo empleado) que se aplica al ciclo de vida del desarrollo de software. La fase de
mantenimiento es la que viene despus de que el software est operativo y en produccin.
De un buen diseo y documentacin del desarrollo depender cmo ser la fase de
mantenimiento, tanto en costo temporal como monetario. Modificaciones realizadas a un software
que fue elaborado con una documentacin indebida o pobre y mal diseo puede llegar a ser tanto
o ms costosa que desarrollar el software desde el inicio. Por ello, es de fundamental importancia
respetar debidamente todas las tareas de las fases del desarrollo y mantener adecuada y completa
la documentacin.
El perodo de la fase de mantenimiento es normalmente el mayor en todo el ciclo de vida.
7
Esta
fase involucra tambin actualizaciones y evoluciones del software; no necesariamente implica que
el sistema tuvo errores. Uno o ms cambios en el software, por ejemplo de adaptacin o evolutivos,
puede llevar incluso a rever y adaptar desde parte de las primeras fases del desarrollo inicial,
alterando todas las dems; dependiendo de cun profundos sean los cambios. El modelo cascada
comn es particularmente costoso en mantenimiento, ya que su rigidez implica que cualquier
cambio provoca regreso a fase inicial y fuertes alteraciones en las dems fases del ciclo de vida.
Durante el perodo de mantenimiento, es comn que surjan nuevas revisiones y versiones del
producto; que lo liberan ms depurado, con mayor y mejor funcionalidad, mejor rendimiento, etc.
Varias son las facetas que pueden ser alteradas para provocar cambios deseables, evolutivos,
adaptaciones o ampliaciones y mejoras.
Bsicamente se tienen los siguientes tipos de cambios:
Perfectivos: Aquellos que llevan a una mejora de la calidad interna del software en cualquier
aspecto: Reestructuracin del cdigo, definicin ms clara del sistema y su documentacin;
optimizacin del rendimiento y eficiencia.
Evolutivos: Agregados, modificaciones, incluso eliminaciones, necesarias en el software para
cubrir su expansin o cambio, segn las necesidades del usuario.
Adaptivos: Modificaciones que afectan a los entornos en los que el sistema opera, tales como:
Cambios de configuracin del hardware (por actualizacin o mejora de componentes
electrnicos), cambios en el software de base, en gestores de base de datos, en
comunicaciones, etc.
Correctivos: Alteraciones necesarias para corregir errores de cualquier tipo en el producto
software desarrollado.