Tutorial sobre Ingeniería de Software

La Ingeniería de Software es una rama de la Ingeniería asociada al desarrollo

de productos de Software usando principios, métodos y procedimientos
científicos bien definidos. La finalidad de la Ingeniería de Software es obtener
un producto de Software eficiente y fiable.

La gestión de Proyectos de Software tiene muchas más posibilidades que el

proceso de Ingeniería de Software, ya que implica comunicación, soporte previo
y posterior de entrega, etc.

Este tutorial le aportará un entendimiento básico sobre el producto software, su

diseño y proceso de desarrollo, la gestión de un producto software, el diseño de
sus complejidades, etc. Al final del tutorial Usted estará totalmente equipado
con un amplio conocimiento de los conceptos de la Ingeniería de Software.

Público
Este tutorial está diseñado para lectores interesados en aprender a
dominar y desarrollar Software, futuros profesionales para Pruebas de
programas y por supuesto para todos los lectores entusiastas.

Requisitos previos
Este tutorial está diseñado y desarrollado para principiantes. No
obstante, un conocimiento previo sobre sistemas de software y su
proceso de desarrollo, así como algunas nociones informáticas básicas
sería beneficioso.

Software - Visión General

Para empezar entendamos a qué se refiere el concepto de Ingeniería
de software. El término consta de dos palabras, software e ingeniería.

Software es mucho más que un código de programa. Un programa

es un código ejecutable, usado para propósitos computacionales. El
Software se considera una colección de códigos ejecutables de
programación, asociada a las bibliotecas y a la documentación. El
Software, cuando se ha hecho para cubrir requisitos específicos se
llama producto software.

Ingeniería Por otro lado, trata de desarrollar productos, utilizando

métodos y principios científicos bien definidos.

La ingeniería de Software es una rama de la ingeniería asociada al

desarrollo del producto software que usa métodos, principios y
procedimientos científicos. El resultado de la Ingeniería de software
es un producto software eficiente y de confianza.

Definiciones
El IEEE (Instituto de Ingeniería Eléctrica y Electrónica) define la
Ingeniería de software como:
(1) La aplicación de una aproximación sistemática, disciplinada y cuantificable,
al desarrollo, las operaciones y al mantenimiento del software; Esto es
básicamente la aplicación de la Ingeniería al software.

(2) El estudio de la aproximación, tal y como se ha mencionado anteriormente.

Fritz Bauer, un informático teórico alemán, define Ingeniería de

software como:

La ingeniería de Software es el establecimiento y uso de los principios de la

Ingeniería de sonido con tal de obtener software fiable y eficiente en máquinas
reales de forma económica.

Evolución del Software

El proceso de desarrollo de un producto software usando principios y
métodos de Ingeniería de software, se denomina Evolución del
Software. Esto incluye el desarrollo inicial del software,
mantenimiento y actualizaciones, hasta que el producto deseado
finalmente es desarrollado, lo que satisface los requerimientos
esperados.

La evolución empieza con un proceso de recogida de requisitos. Luego

los desarrolladores crean un prototipo inicial del software y se muestra
a los consumidores para tener un feedback en una etapa temprana
del desarrollo del producto de software. Los consumidores sugieren
cambios, los cuales irán mejorando con actualizaciones y tareas de
mantenimiento de manera progresiva. Este proceso cambia el
software original hasta llegar al producto deseado.
Incluso después de que el consumidor tenga el software en sus manos,
el avance de la tecnología y los cambios de requisitos fuerzan al
producto software a cambiar en acorde a estos. Volver a cerrar
software desde cero, e ir cumpliendo uno por uno los requisitos no es
viable. La única solución viable y económica es actualizar el software
ya existente para que se adecue satisfactoriamente con los requisitos
más recientes.

Leyes de evolución del software

Lehman formuló leyes para la evolución del software. Dividió el
software en 3 categorías distintas:

• 'S-type' ('static-type', tipo estático) - Es un tipo de software, que

funciona estrictamente según se ha definido especificaciones y
soluciones. La solución y el método mediante el cual se consigue, se
deben entender de inmediatamente antes de empezar a codificar. El
software 's-type' está menos sujeto a cambios, de ahí que sea el más
simple de todos. Por ejemplo, el programa de calculadora, para
computación matemática.

• 'P-type' ('practical-type', tipo práctico) - This is a software with a

collection of procedures. This is defined by exactly what procedures can
do. In this software, the specifications can be described but the solution
is not obvious instantly. For example, gaming software.

• 'E-type' ('embedded-type', tipo embebido o empotrado) - This

software works closely as the requirement of real-
world environment. This software has a high degree of evolution as there
are various changes in laws, taxes etc. in the real world situations. For
example, Online trading software.

Evolución del software 'E-Type'

Lehman dictó 8 leyes de evolución del software 'E-Type' -

• Cambio continuo - Los sistemas de software 'E-type' deben adaptarse

de forma progresiva a los cambios del mundo real, de no ser así se
volverá progresivamente menos útil.

• Complejidad creciente- A medida que el sistema software 'E-type'

evoluciona, sus complejidades tienden a incrementar a menos que se
trabaje en ello con el fin de mantenerlas o reducirlas.
 • Conservación de la familiaridad - La familiaridad con el software o con
el conocimiento sobre cómo y por qué fue desarrollado de una manera
en concreto, etc. debe ser retenido a cualquier coste, con tal de poder
implementar cambios en el sistema.

• Crecimiento continuado- Para que un sistema 'E-type' intente resolver

problemas de negocios, su magnitud para implementar cambios crece en
acorde con los cambios de estilo de vida del negocio.

• Decremento de la calidad - Los sistemas software 'E-type' reducen su

calidad a menos que se mantengan de forma rigurosa o se adapten a los
cambios operativos del entorno.

• Sistemas de retroalimentación- Los sistemas software 'E-type' son

sistemas de retroalimentación multi-loop y multi-nivel, deben ser
considerados como tal con el fin de ser modificados o mejorados con
éxito.

• Autorregulación- Los procesos de evolución del sistema 'E-type', se

regulan a sí mismos con la distribución del producto y las medidas del
proceso de una manera casi normal.

• Estabilidad organizacional - La tasa media de actividad efectiva global

en un sistema evolutivo de 'E-type', no varía en toda la vida del producto.

Paradigmas de Software
Los paradigmas de Software son métodos y pasos, que se llevan a
cabo mientras el software se diseña. Hay muchos métodos que se han
propuesto y que funcionan hoy en día, pero necesitamos ver donde se
ubican estos paradigmas en el marco de la Ingeniería de software.
Estos se pueden combinar en varias categorías, en las que cada uno
de ellos contiene a la otra:
El paradigma de programación es una parte del paradigma de diseño
de Software y más adelante también se considera parte del paradigma
de desarrollo de Software.

Paradigma del desarrollo Software

Este paradigma es conocido como paradigma de ingeniería de
software, en el que todos los conceptos de ingeniería pertenecientes
al desarrollo de software son implementados. Incluye varias
investigaciones y recogida de requisitos lo que ayuda a la construcción
del producto software. Consiste de –

• Recogida de requisitos

• Diseño de Software

• Programación

Paradigma de diseño de Software

Este paradigma forma parte del desarrollo software e incluye –

• Diseño

• Mantenimiento

• Programación
Paradigma de programación
Este paradigma se relaciona de estrechamente a aspectos de
programación en el desarrollo de software. Esto incluye –

• Codificación

• Pruebas

• Integración

Necesidad de la Ingeniería de
Software
La necesidad de la Ingeniería de software viene de la alta tasa de
cambio en los requisitos y en el entorno en que trabaja el software.

• Software de gran tamaño- Es más fácil construir una pared que

construir una casa, de la misma manera, a medida que el software
aumenta su tamaño, la ingeniería debe entrar para darle un proceso
científico.

• Escalabilidad- Si el proceso software no estuviera basado en conceptos

científicos y de ingeniería, sería más fácil volver a crear nuevo software
que escalar uno ya existente.

• Costes- A medida que la industria del hardware ha mostrado sus

capacidades y grandes fabricaciones, ha bajado el precio del hardware
electrónico e informático. Pero el coste del software sigue siendo alto si
el proceso no se ha adaptado a los nuevos avances.

• Naturaleza dinámica - La naturaleza del software, creciente y

adaptable, depende en gran medida del entorno en el que el consumidor
trabaje. Si la naturaleza del software siempre cambia, se necesitará
mejorar el ya existente. Aquí es donde la ingeniería de software juega un
gran papel.

• Gestión de calidad- Los mejores procesos de desarrollo de software

producen productos mejores y de calidad.

Características de un buen software

Un producto software puede ser juzgado según lo que ofrece y la
manera en que se puede usar. El software debe satisfacer en los
siguientes aspectos:
 • Operacional

• Transicional

• Mantenimiento

Un software que se ha creado con buena ingeniería, debe tener los

siguientes rasgos:

Operacional
Esto nos cuenta lo bien que funciona el software en operaciones. Se
puede medir en base a:

• Presupuesto

• Usabilidad

• Eficiencia

• Exactitud

• Funcionalidad

• Confiabilidad

• Seguridad informática

• Seguridad

Transicional
Este aspecto es importante cuando el software se mueve de una
plataforma a la otra:

• Portabilidad

• Interoperabilidad

• Reutilización

• Adaptabilidad

Mantenimiento
Estos aspectos resumen la capacidad que tiene el software para
mantenerse en entornos contantemente cambiantes:

• Modularidad

• Sostenibilidad

• Flexibilidad

• Escalabilidad
En resumen, La Ingeniería de Software es una rama de las ciencias de
la computación, que usa conceptos de Ingeniería bien definidos
requeridos para producir productos software eficientes, duraderos,
escalable, y asequibles a tiempo.

Software - Ciclo de Vida de

Desarrollo
El ciclo de vida del desarrollo Software (SDLC en sus siglas inglesas),
es una secuencia estructurada y bien definida de las etapas en
Ingeniería de software para desarrollar el producto software deseado.

Actividades del SDLC

El SDLC aporta una serie de pasos a seguir con la finalidad de diseñar
y desarrollar un producto software de manera eficiente. El borrador
del SDLC incluye los pasos que veremos a continuación:
Comunicación
Este es el primer paso donde l usuario inicia la petición de un producto
software determinado. Contacta al proveedor de servicios e intenta
negociar las condiciones. Presenta su solicitud al proveedor de
servicios aportando la organización por escrito.

Recolección de solicitudes
A partir de este paso y en adelante el equipo de desarrollo software
trabaja para tirar adelante el proyecto. El equipo se reúne con varios
depositarios de dominio del problema, e intentan conseguir la máxima
cantidad de información posible sobre lo que requieren. Los requisitos
se contemplan y agrupan en requisitos del usuario, requisitos
funcionales y requisitos del sistema. La recolección de todos los
requisitos se lleva a cabo como se especifica a continuación -
 • Estudiando el software y el sistema actual u obsoleto,

• Entrevistando a usuarios y a desarrolladores de Software,

• Consultando la base de datos o

• Recogiendo respuestas a través de cuestionarios.

Estudio de viabilidad
Después de la recolección de requisitos, el equipo idea un plan para
procesar el software. En esta fase, el equipo analiza si el software
puede hacerse para cubrir todos los requisitos del usuario y si hay
alguna posibilidad de que el software ya no sea necesario. Se investiga
si el proyecto es viable a nivel financiero, práctico, y a nivel
tecnológico para que la organización acepte la oferta. Hay varios
algoritmos disponibles, los cuales ayudan a los desarrolladores a
concluir si el proyecto software es factible o no.

Análisis del sistema

En este paso los desarrolladores trazan su plan e intentan crear el
mejor y más conveniente modelo de software para el proyecto. El
análisis del sistema incluye el entendimiento de las limitaciones del
producto Software; el aprendizaje de los problemas relacionados con
el sistema; los cambios que se requieren en sistemas ya existentes
con antelación, identificando y dirigiendo el impacto del proyecto a la
organización y al personal, etc. El equipo del proyecto analiza las
posibilidades del proyecto y planifica la temporalización y los recursos
correspondientes.

Diseño de Software
El siguiente paso es diseñar el producto software con la ayuda de toda
la información recogida sobre requisitos y análisis. Los inputs
(aportaciones) de los usuarios y los resultados de la recogida de
información hecha en la fase anterior serán las aportaciones base de
la fase actual. El output (o resultado) de esta etapa toma la forma de
2 diseños; El diseño lógico y el diseño físico. Los ingenieros crean
meta-data (Metadatos), Diagramas dilógicos, diagramas de flujo de
datos, y en algunos casos pseudocódigos.

Codificación
Esta fase también se puede denominar 'fase de programación'. La
implementación del diseño de software empieza con el lenguaje de
programación más conveniente, y desarrollando programas
ejecutables y sin errores de manera eficiente.

Pruebas
Se estima que el 50% de todos los procesos de desarrollo de software
deberían ser evaluados. Los errores pueden arruinar el software tanto
a nivel crítico y hasta el punto de ser eliminado. Las pruebas de
Software se hacen mientras se codifica y suelen hacerlo los
desarrolladores y otros expertos evaluadores a varios niveles. Esto
incluye evaluación de módulos, evaluación del programa, evaluación
del producto, evaluación interna y finalmente evaluación con el
consumidor final. Encontrar errores y su remedio a tiempo es la llave
para conseguir un software fiable.

Integración
El Software puede necesitar estar integrado con las bibliotecas, Bases
de datos o con otro u otros programas. Esta fase del SDLC se focaliza
en la integración del software con las entidades del mundo exterior.

Implementación
Aquí se instala el software en máquinas de clientes. A veces, el
software necesita instalar configuraciones para el consumidor final con
posterioridad. El Software se evalúa por su adaptabilidad y su
portabilidad, en cuanto a las cuestiones relacionadas con la
integración y conceptos asociados, se resuelven durante la
implementación.

Mantenimiento y Funcionamiento
Esta fase confirma el funcionamiento del software en términos de más
eficiencia y menos errores. Si se requiere, los usuarios se forman, o
se les presta documentación sobre como operar y como mantenerlo
en funcionamiento. El software se mantiene de forma temprana
actualizando el código en acorde a los cambios que tienen lugar en
entornos del usuario o tecnológicos. Esta fase puede que tenga que
encarar retos originados por virus ocultos o problemas no identificados
del mundo real.

Disposición
Con el paso del tiempo, puede que el software falle en su ejecución.
Puede que se vuelva totalmente obsoleto o que necesite
actualizaciones. De ahí surge una necesidad urgente de eliminar una
parte importante del sistema. Esta fase incluye archivar datos y
componentes software requeridos, cierre del sistema, planificación de
la actividad de disposición y terminación de sistema en el momento
final del sistema.

Paradigma de desarrollo de Software

El Paradigma de desarrollo de Software ayuda al desarrollador a
escoger una estrategia para desarrollar el software. El paradigma de
desarrollo software tiene su propio set de herramientas, métodos y
procedimientos, los cuales son expresados de forma clara, y define el
ciclo de vida del desarrollo del software. Algunos paradigmas de
desarrollo de software o modelos de proceso se definen a
continuación:

Modelo de cascada
El modelo de cascada es el modelo de paradigma más simple en
desarrollo de software. Sigue un modelo en que las fases del SDLC
funcionarán una detrás de la otra de forma lineal. Lo que significa que
solamente cuando la primera fase se termina se puede empezar con
la segunda, y así progresivamente.

Este modelo asume que todo se lleva a cabo y tiene lugar tal y como
se había planeado en la fase anterior, y no es necesario pensar en
asuntos pasados que podrían surgir en la siguiente fase. Este modelo
no funcionará correctamente si se dejan asuntos de lado en la fase
previa. La naturaleza secuencial del modelo no permite volver atrás y
deshacer o volver a hacer acciones.

Este modelo es recomendable cuando el desarrollador ya ha diseñado

y desarrollado softwares similares con anterioridad, y por eso está al
tanto de todos sus dominios.

Modelo repetitivo
Este modelo guía el proceso de desarrollo de software en repeticiones.
Proyecta el proceso de desarrollo de forma cíclica repitiendo cada paso
después de cada ciclo en el proceso de SDLC.

El software primero se desarrolla en menor escala y se siguen y tienen

en consideración todos los pasos. Entonces, por cada repetición, más
módulos y características son diseñados, codificados, evaluados y
añadidos al software. Cada ciclo produce un software completo, con
más características y capacidad que los previos.

Después de cada repetición, el equipo directivo puede concentrarse

en la gestión de riesgos y prepararse para la siguiente repetición.
Como el ciclo incluye pequeñas porciones de la totalidad del proceso
software, es más fácil gestionar el proceso de desarrollo, pero a la vez
se consumen más recursos.

Modelo en espiral
El modelo en espiral es una combinación de ambos modelos, el
repetitivo y uno del modelo SDLC. Se puede ver como si se combina
un modelo de SDLC combinado con un proceso cíclico (modelo
repetitivo).
Este modelo considera el riesgo, factor que otros modelos olvidan o
no prestan atención en el proceso. El modelo empieza determinando
los objetivos y las limitaciones del software al inicio de cada repetición.
En la siguiente etapa se crean los modelos de prototipo del software.
Esto incluye el análisis de riesgos. Luego un modelo estándar de SDLC
se usa para construir el software. En la cuarta etapa es donde se
prepara el plan de la siguiente repetición.
Modelo V
El mayor inconveniente del modelo de cascada es que solo se pasa a
la siguiente fase cuando se completa la anterior, por tanto no es
posible volver atrás si se encuentra algún error en las etapas
posteriores. El Modelo V aporta opciones de evaluación del software
en cada etapa de manera inversa.

En cada etapa, se crea la planificación de las pruebas y los casos de

pruebas para verificar y validar el producto según los requisitos de la
etapa. Por ejemplo, en la etapa de recogida de requisitos, el equipo
de evaluadores prepara las pruebas de caso correspondientes a los
requisitos. Más tarde, cuando el producto se desarrolla y está
preparado para ser evaluado, las pruebas de caso en esta etapa
verifican el software y su validez según sus requisitos.

Esto hace que tanto la verificación como la validación vayan en

paralelo. Este modelo también se conoce como modelo de validación
y verificación.

Modelo Big Bang

Este modelo es el modelo con la forma más simple. Requiere poca
planificación, mucha programación y también muchos fondos. Este
modelo se conceptualiza alrededor de la teoría de creación del
universo 'Big Bang'. Tal como cuentan los científicos, después del big
bang muchas galaxias, planetas y estrellas evolucionaron. De la
misma manera, si reunimos muchos fondos y programación, quizá
podemos conseguir el mejor producto de software.

Para este modelo, se requiere poca planificación. No sigue ningún

proceso concreto, y a veces el cliente no está seguro de las futuras
necesidades y requisitos. Por tanto la entrada o input respecto a los
requisitos es arbitraria.

Este modelo no es recomendable para grandes proyectos de software,

pero es bueno para aprender y experimentar.

Para una lectura en profundidad del SDLC y de sus modelos, Pulse

aquí.

Software - Gestión del Proyecto

El patrón de trabajo de cualquier compañía informática relacionado
con el desarrollo software se puede dividir en dos partes:

• Creación Software

• Gestión del proyecto Software

Un proyecto es una tarea bien definida, que constituye una colección
de muchas operaciones realizadas con tal de lograr un objetivo
concreto (Por ejemplo, desarrollo software y entrega). Un proyecto se
puede caracterizar como:

• Cada proyecto debe tener un objetivo único y distintivo.

• Proyecto no significa actividad rutinaria u operaciones diarias.

• El proyecto viene con un tiempo inicial y un tiempo final.

• El proyecto termina cuando se logra el objetivo deseado, por tanto, es

una fase temporal de la organización.

• El proyecto necesita recursos adecuados en lo que se refiere al tiempo,

mano de obra, finanzas, material, etc.

Proyecto Software
Un proyecto software es todo el procedimiento del desarrollo de
software, desde la recogida de requisitos, pasando por las pruebas y
el mantenimiento, y llevado a cabo en acorde a las metodologías de
ejecución, en un momento concreto en el tiempo para lograr el
producto software deseado.

Necesidad de la gestión del proyecto

software
Se dice que el software es un producto no tangible. El desarrollo
Software contiene aspectos de todas las corrientes del mundo de los
negocios pero tiene poca experiencia en construir productos software.
La mayor parte de los productos software se diseñan para satisfacer
las necesidades de los clientes. Lo más importante es que la tecnología
subyacente cambia y avanza tan frecuente y rápidamente que la
experiencia de un producto quizá no se pueda aplicar a otro. Todo este
tipo de negocios y limitaciones del entorno traen con ellos riesgo en
el desarrollo del software, por eso es esencial gestionar los proyectos
software de manera eficiente.
La imagen de arriba muestra las limitaciones triples para los proyectos
software. Es una parte esencial de la organización del software
entregar un producto de calidad, manteniendo el coste dentro de las
limitaciones del presupuesto del cliente y entregar el proyecto a
tiempo. Hay muchos factores, internos y externos, que pueden causar
un impacto en este triángulo de triples limitaciones. Cada uno de los
3 factores puede causar un impacto en los otros dos de forma grave.

Por tanto, la gestión del proyecto software debe incorporar los

requisitos del usuario junto con el presupuesto y las limitaciones de
temporales.

Gestión del proyecto Software

El directivo de un proyecto software es la persona que se
responsabiliza de la ejecución del proyecto software. Debe estar al
tanto y seguir todas las fases del SDLC por las que el software pasará.
Puede que no se implique de forma directa en la producción del
producto final, pero sí que controla y dirige las actividades incluidas
en esta fase.

El Director del proyecto sigue de cerca el proceso de desarrollo,

prepara y ejecuta varios planes, organiza los recursos adecuados y
necesarios, se mantiene comunicado con todos los miembros del
equipo con tal de dirigir asuntos de costes, presupuesto, recursos,
tiempo, calidad, y satisfacción del cliente.

Veamos algunas de las responsabilidades que el Director de un

proyecto asume.
Gestión de personas

• Actuar como líder del proyecto

• Intermediar con accionistas

• Gestionar los recursos humanos

• Armar informes de jerarquía, etc.

Gestión del Proyecto

• Definir y armar el alcance del proyecto

• Gestionar las actividades de gestión del proyecto

• Seguimiento de la actuación y del progreso

• Análisis de riesgos en cada fase

• Tomar la iniciativa para evitar o salir de problemas

• Actuar como representante del proyecto

Actividades de la gestión de Software

La gestión del proyecto Software comprende un gran número de
actividades, que contienen la planificación del proyecto, decidir el
alcance del producto software, estimar el coste respecto a la
temporalización de tareas y eventos, y la gestión de los recursos. Las
actividades de gestión del proyecto pueden incluir:

• Planificación del proyecto

• Gestión del alcance

• Estimación del proyecto

Planificación del proyecto

La planificación del proyecto Software es una tarea que se realiza
antes de la producción del software empiece. Está ahí para la
producción de software pero no implica una actividad concreta que
tenga una conexión directa con la producción de software; más bien
es un conjunto de procesos, que facilitan la producción de software.
La planificación del proyecto puede incluir:

Gestión del alcance

Define el alcance de un proyecto; esto incluye todas las actividades y
procesos que se requieren para crear un producto software
distribuible. La gestión del alcance es esencial porque crea condiciones
del proyecto por medio de la definición de lo que se debe realizar en
el proyecto y lo que no. Esto hace que el proyecto contenga tareas
limitadas y cuantificables, con lo que puede ser documentado
fácilmente y por tanto evitar costes y tiempo excedidos.

Durante la gestión del alcance del proyecto, es necesario -

• Definir el alcance

• Decidir su verificación y control

• Dividir el proyecto en pequeñas partes para facilitar su gestión.

• Verificar el alcance

• Controlar el alcance incorporando cambios a éste

Estimación del proyecto

Para una gestión efectiva, es necesario que se realice una estimación
exacta de varias medidas. Los Directores pueden gestionar y controlar
el proyecto de forma más eficiente y efectiva haciendo estimaciones
correctas.

La estimación del proyecto puede incluir los siguientes aspectos:

• Estimación del tamaño del Software

El tamaño del Software se puede estimar en KLOC (Kilo Línea de código)

o calculando el número de puntos de función en el software. Las líneas
de código dependen de las prácticas de codificación y los puntos de
función, que cambian según el usuario o los requisitos del software.

• Estimación del esfuerzo

Los directores estiman los esfuerzos en términos de requisitos de

personal y las horas de trabajo requeridas para producir el software. Para
la estimación de esfuerzos se debe conocer el tamaño del software. Esto
lo pueden aportar la experiencia misma de los directores, los datos
históricos de la organización, o el tamaño del software se puede convertir
en esfuerzos usando alguna formulación estándar.

• Estimación del tiempo

Una vez el tamaño y los esfuerzos se han estimado, podemos proceder a

estimar el tiempo que requeriremos para producir el software. Los
 esfuerzos requeridos se dividen en categorías según los requisitos del
sistema y la interdependencia de varios componentes del software. Las
tareas del Software se dividen en pequeñas tareas, actividades o eventos
por la 'Work Breakthrough Structure(WBS)' en español 'Estructura de
descomposición del trabajo'. Las tareas se temporalizan diariamente o en
los meses del calendario.

La suma del tiempo requerido para completar todas las tareas en horas
o días es el tiempo total que se invierte para terminar el proyecto.

• Estimación del coste

Este debe de ser considerado como el más difícil de todos porque depende
de más elementos que los anteriormente mencionados. Para estimar el
coste de un proyecto, se requiere considerar -

o El tamaño del software

o La calidad del Software

o El Hardware

o Herramientas o software adicional, licencias, etc.

o Personal formado para tareas concretas

o Implicaciones de viaje

o Comunicación

o Formación y soporte

Técnicas de estimación del proyecto

Ya hemos hablado de los parámetros en la estimación del proyecto,
como el tamaño, esfuerzo, tiempo y costes.

El director puede estimar los factores mencionados usando 2 técnicas

ampliamente reconocidas –

Técnica de descomposición
Esta técnica toma el software como un producto de varias
composiciones.

Hay dos modelos fundamentales -

• Línea de código La estimación se realiza en representación al número

de línea de códigos en el producto software.
 • Puntos de función La estimación se realiza en representación al
número de puntos de función que hay en el producto software.

Técnica de estimación empírica

Esta técnica usa fórmulas empíricamente derivadas para hacer
estimaciones. Estas fórmulas se basan en LOC (línea de control) o FPs
(lenguajes de programación).

• Modelo Putnam

Este modelo hecho por Lawrence H. Putnam, que se basa en la

distribución de frecuencia de Norden ('Rayleigh curve'). El modelo
Putnam dibuja el mapa de esfuerzos y tiempo que se requiere para el
tamaño del software.

• COCOMO

COCOMO significa 'COnstructive COst MOdel' (Modelo de coste

constructivo), desarrollado por Barry W. Boehm. Divide el producto
software en 3 categorías de software: orgánica, semi-independiente e
incrustado.

Temporalización del proyecto

La Temporalización del proyecto se refiere al mapa de actividades a
realizar en un orden concreto y con un tiempo adjudicado para cada
una de ellas. Los jefes del proyecto tienden a definir varias tareas, y
proyectos 'milestones' para luego organizar y mantener varios
factores en mente. Buscan tareas que van por un camino crítico en la
temporalización, y que necesitan completarse de una forma
determinada (a cause de la interdependencia de tareas) y
estrictamente en el tiempo adjudicado. La organización de tareas, la
cual se mantiene fuera de un camino crítico tienen menos
posibilidades de causar un impacto sobre toda la temporalización del
proyecto.

Para temporalizar un proyecto, es necesario -

• Partir el proyecto en tareas pequeñas, dirigibles desde

• buscar varias tareas y relacionarlas entre ellas

• Estimar el marco requerido para cada tarea

• Dividir el tiempo en unidades de trabajo

 • Asignar un adecuado número de unidades de trabajo a cada tarea

• Calcular el tiempo total requerido des del inicio hasta el final del
proyecto

Gestión de recursos
Todos los elementos usados para desarrollar el producto software se
pueden tomar como recursos para ese proyecto. Esto puede incluir
recursos humanos, herramientas productivas y bibliotecas software.

Los recursos están disponibles en cantidades limitadas y se quedan en

la organización como una piscina de ponderaciones. La falta de
recursos obstaculiza el desarrollo del proyecto y puede demorar la
temporalización prevista. Distribuir recursos adicionales aumenta el
desarrollo del coste al final. Por eso se hace necesario estimar y
distribuir los recursos adecuados para el proyecto.

La gestión de los recursos incluye -

• Definir la organización del proyecto satisfactoriamente creando un equipo

de proyecto y distribuyendo las responsabilidades a cada uno de los
miembros de éste.

• Determinar los recursos requeridos para cada fase concreta y su

disponibilidad

• Gestionar recursos generando recursos cuando se requieren y retirarlos

cuando ya no son necesarios.

Gestión de riesgo del proyecto

La gestión del riesgo incluye todas las actividades pertenecientes a la
identificación, analizando y haciendo provisiones para riesgos
predecibles o no predecibles en el proyecto. El riesgo puede incluir lo
siguiente:

• El personal con experiencia que deja el proyecto y el nuevo personal que

entra.

• Cambio en la gestión organizativa.

• Cambios requeridos o requisitos mal interpretados.

• Estimación baja de tiempo y recursos requeridos.

• Cambios tecnológicos y de entorno, y competición empresarial.

Proceso de gestión de riesgos
Hay varias actividades en el proceso de gestión de riesgos:

• Identificación - Anota todos los riesgos posibles, que pueden ocurrir en

el proyecto.

• Categorizar - Categorizar riesgos ya conocidos en riesgo de intensidad

alta, media y baja, según el posible impacto que puedan tener en el
proyecto.

• Gestionar - Analizar la probabilidad de ocurrencia de riesgos en las

distintas fases. Planificar para evitar o tener que afrontar riesgos.
Intentar minimizar sus efectos secundarios.

• Monitorear - Hacer un seguimiento de cerca de los riesgos potenciales y

de sus síntomas iniciales. También monitorear los efectos de los pasos
que se han seguido para mitigarlos o evitarlos.

Ejecución del proyecto & Monitoreo

En esta fase, las tareas descritas en los planes del proyecto se
ejecutan de acuerdo con su temporalización correspondiente.

La ejecución necesita monitoreo con tal de evaluar si todo está yendo

de acuerdo con el plan. Monitorizar es observar y evaluar la
probabilidad de riesgo, y tomar medidas para redirigir el riesgo o
informar del estatus de varias tareas.

Estas medidas incluyen -

• Actividades de monitoreo - Todas las actividades programadas en una

tarea se pueden monitorear a diario. Cuando todas las actividades de una
tarea se completan, se considera completo.

• Informes de estatus - Los informes contienen estatus de actividades y

tareas completadas en un marco temporal, generalmente en una
semana. El estatus puede marcarse como finalizado, pendiente, en
progreso, etc.

• Lista de verificación 'Milestones' - Cada proyecto se divide en varias

fases donde la mayoría de las tareas se performan (milestones) en base
a las fases del SDLC. Esta lista de verificación milestone se prepara un
par de veces al mes aproximadamente y se emite el estatus de
milestones.
Gestión comunicativa del proyecto
Una comunicación efectiva juega un rol vital en el proceso de un
proyecto. Crea vacíos en las conexiones entre el cliente y la
organización, entre los miembros del equipo así como con los
proveedores de hardware, etc.

La comunicación puede ser oral o por escrito. La gestión comunicativa

puede contener los siguientes pasos procedimentales:

• Planificación - Este paso incluye la identificación de los accionistas, y la

forma en que se van a comunicar entre ellos. También considera si se
requiere alguna facilidad comunicativa adicional.

• Compartir - Después de determinar varios aspectos de la planificación,

el director se centra en compartir información correcta con la persona
correcta y en el momento correcto en el tiempo. Esto mantiene a todos
los miembros del proyecto al día del progreso y del estatus del proceso.

• Retroalimentación - Los jefes del proyecto usan varias medidas y

mecanismos de retroalimentación y crean informes de estatus y de
acción. Este mecanismo asegura que la entrada desde varios accionistas
llega al jefe del proyecto como su retroalimentación.

• Cierre - Al final de cada evento mayor, de cada fase del SDLC o del
proyecto mismo, se anuncia el cierre administrativo para actualizar a
cada accionista vía email, o distribuyendo una copia por escrito del
documento o a través de otro medio de comunicación efectivo.

Después del cierre, el equipo pasa a la siguiente fase o proyecto.

Gestión de la configuración
La gestión de la configuración es un proceso de seguimiento y control
de cambios en el software en términos de requisitos, diseño, funciones
y desarrollo del producto.

El IEEE la define como un proceso de identificación y definición d los

elementos del sistema, controlando los cambios en éstos a través de
su ciclo vital, grabando e informando del estatus de cada uno de ellos,
de sus peticiones de cambio, y verificando si están completos y
correctos.

Generalmente, una vez que el SRS (especificación de requisitos de

software) se termina, hay menos posibilidades de que cambien los
requisitos del usuario. Si ocurren, los cambios son dirigidos con
aprobación previa a los altos directivos, ya que puede haber una
posible demora en costes y tiempo.

Línea de Base
Una fase del SDLC se considera completa si se hace la línea base de
este, esto es, la línea de base es una medida que define el fin de una
fase. La fase se completa cuando todas las actividades pertenecientes
a ésta se han terminado y documentado satisfactoriamente. S no fuera
la fase final, su resultado u output se usaría en la siguiente fase.

La gestión de la configuración es una disciplina de organización

administrativa, que se ocupa de la ocurrencia de cualquier cambio
(proceso, requisito, tecnológico, estratégico, etc.) cuando la fase ya
se ha 'baselined'. La gestión de la configuración evalúa los cambios
realizados en el software.

Control de cambios
El control de cambios es una función de gestión de la configuración, la
cual asegura que todos los cambios realizados al sistema software son
consistentes y se han hecho siguiendo regulaciones y normas de
organización.

Un cambio en la configuración del producto pasa por los siguientes

pasos -

• Identificación - La solicitud de un cambio llega desde fuentes internas

o externas. Cuando la solicitud de cambio se identifica de manera formal,
está documentada correctamente.

• Validación - La validez de la solicitud de cambio es evaluada y su

procedimiento para llevarla a cabo se confirma.

• Análisis - El impacto de una solicitud de cambio se analiza en términos

de temporalización, costes, y esfuerzos requeridos. El impacto general de
los posibles futuros cambios en el sistema es analizado.

• Control - Si los cambios esperados crean un impacto en demasiadas

entidades del sistema o son inevitables, es obligatorio tener la aprobación
de altas autoridades antes que el cambio se incorpore en el sistema. Se
decide si vale la pena incorporar el cambio o no. Si es que no, la solicitud
de cambio se rechaza formalmente.
 • Ejecución - Si la fase previa determina ejecutar la solicitud de cambio,
esta fase toma las acciones apropiadas para ejecutar los cambios, y hace
una revisión general si fuera necesario.

• Cierre de la solicitud - El cambio es verificado por su correcta

implementación y combinación con el resto del sistema. El nuevo cambio
incorporado en el software se documenta y luego se cierra formalmente
la solicitud.

Herramientas de gestión del proyecto

El riesgo y la incertidumbre crecen de forma múltiple en respecto al
tamaño del proyecto, Aún y cuando el proyecto se desarrolla según el
conjunto de metodologías.

Hay herramientas disponibles, que contribuyen a la gestión efectiva

del proyecto. Algunas son descritas a continuación -

Gráfico Gantt
Los gráficos Gantt fueron concebidos por Henry Gantt (1917).
Representan la temporalización del proyecto respecto a los periodos
de tiempo. Es un gráfico de barras horizontal que representa las
actividades y la temporalización para éstas en el proyecto.
Gráfico PERT
El diagrama PERT (Técnicas de Revisión y & Evaluación de Proyectos)
es una herramienta que representa el proyecto como un diagrama de
red. Es capaz de representar de forma gráfica eventos principales del
proyecto de forma paralela y consecutiva. Los eventos, que se dan
uno tras otro, muestran dependencia con el evento más reciente por
encima del previo.
Los eventos se muestran en número de nódulos. Se conectan con
flechas etiquetadas representando la secuencia de tareas en el
proyecto.

Histograma de recursos
Es una herramienta gráfica que contiene un esquema representando
el número de recursos (normalmente personal formado) requeridos
conforme avanza el tiempo para el evento de un proyecto o fase. El
histograma de recursos es una herramienta efectiva para el personal
de planificación y de coordinación.
Análisis de la ruta crítica o del camino crítico
Esta herramienta es útil para reconocer tareas interdependientes en
el proyecto. También contribuye a encontrar el camino más corto para
completar el proyecto con éxito. Como los diagramas PERT, a cada
evento se le adjudica un marco temporal. Esta herramienta muestra
dependencia de evento asumiendo que un evento puede proceder al
siguiente solamente si el previo a éste se ha completado.

Los eventos se organizan en acorde según el tiempo de inicio más

temprano posible. El camino entre en inicio y el nódulo es el camino
crítico, el cual no puede reducirse en un futuro en todos los eventos,
necesita ser ejecutado en el mismo orden.
 Software - Requisitos
Los requisitos software son la descripción de las características y las
funcionalidades del sistema 'target'. Los requisitos nos comunican las
expectativas de los consumidores de productos software. Los
requisitos pueden ser obvios o estar ocultos, conocidos o
desconocidos, esperados o inesperados, des del punto de vista del
cliente.

Ingeniería de requisitos
El proceso de recogida de información, análisis y documentación sobre
los requisitos software des del cliente, se conoce como ingeniería de
requisitos.

El objetivo de este tipo de Ingeniería es el de desarrollar y mantener

un documento de especificación de requisitos del sistema de forma
sofisticada y descriptiva.

Proceso de la Ingeniería de requisitos

Es un proceso que consta de cuatro pasos –

• Estudio de viabilidad

• Recogida de requisitos

• Requisitos del Software

• Validación de los requisitos de Software

Veamos el proceso de manera breve -

Estudio de viabilidad
Cuando el cliente se acerca a la organización para obtener el producto
deseado desarrollado, expone una idea aproximada de las funciones
que el software debe cumplir y qué características se esperan del
software.

Refiriéndose a esta información, los analistas elaboran un estudio

detallado sobre la viabilidad del sistema deseado y de sus
funcionalidades, para proceder a desarrollarlo.
Este estudio de viabilidad se centra en el objetivo de la organización.
El estudio analiza la materialización práctica del producto software
respecto a su implementación, la contribución de proyecto a la
organización, los límites de costes, y según los objetivos y valores de
la organización. Explora aspectos técnicos del proyecto y del producto,
como la utilidad, el mantenimiento, la productividad y la capacidad de
integración.

El resultado u output de esta fase debe ser un informe del estudio de

viabilidad, conteniendo comentarios adecuados y recomendaciones
para la gestión sobre si se debe tirar adelante o no el proyecto.

Recogida de requisitos
Si el informe de viabilidad es positivo en relación a tomar el proyecto,
la siguiente fase empieza con la recolección de requisitos por parte del
consumidor. Analistas e Ingenieros se comunican con el cliente y los
consumidores para conocer sus ideas sobre qué debe aportar el
software y qué características quieren que incluya éste.

Requisitos del Software

El SRS es un documento creado por los analistas de sistema después
de recoger los requisitos.

El SRS define cómo va a interactuar el software que quiere crearse

con el hardware, las interfaces externas, la velocidad operativa, el
tiempo de respuesta del sistema, la portabilidad del software en las
diversas plataformas, el mantenimiento, la velocidad de reponerse
después de estropearse, su seguridad, calidad, limitaciones, etc.

Los requisitos recibidos por parte del cliente se escriben en lenguaje

natural. Es responsabilidad del analista de sistemas documentar sobre
los requisitos en lenguaje tecnológico para que puedan ser útiles y
comprendidos por el equipo de desarrollo de software.

El SRS debe venir con las siguientes características:

• Los requisitos del usuario se deben expresar en lenguaje natural.

• Los requisitos técnicos se deben expresar en lenguaje estructurado, el

cual se usará dentro de la organización.

• La descripción del diseño se debe escribir en pseudocódigo.

• El formato de Forms y GUI impresiones de pantalla.

 • Anotaciones condicionales y matemáticas para DFDs etc.

Validación de los requisitos de Software

Después del desarrollo de los requisitos, los que se mencionen en este
documento serán validados. El usuario puede que pida soluciones
ilegales y poco prácticas, y los expertos puede que interpreten los
requisitos de forma incorrecta. Estos resultados se incrementan en
coste si no se cortan de raíz. Los requisitos se pueden evaluar en
contraste con las siguientes condiciones -

• Si pueden ser implementados de manera práctica.

• Si son válidos a nivel de funcionalidad y dominio del software

• Si hay alguna ambigüedad

• Si se han completado

• Si se pueden demostrar

Proceso de educción de requisitos

El Proceso de educción de requisitos se puede representar usando el
siguiente diagrama:

• Recogida de requisitos - Los desarrolladores hablan con el cliente y los

consumidores finales para conocer sus expectativas respecto al software.

• Organizar requisitos - Los desarrolladores priorizan y organizan los

requisitos en orden de importancia, urgencia, y conveniencia.

• Negociación y debate - Si los requisitos son ambiguos o hay algún

conflicto en los requisitos de varios accionistas, hay una negociación y un
debate con ellos. Los requisitos entonces, se priorizan y se acuerdan de
manera razonable.

Los requisitos vienen de varios accionistas. Para eliminar cualquier

ambigüedad o conflicto, se debate para encontrar claridad y corrección.
Los requisitos surrealistas se acuerdan de forma razonable.

• Documentación - Los requisitos formales y no formales, funcionales y

no funcionales, son documentados y se ponen disponibles para procesar
en la siguiente fase.
Técnicas de educción de requisitos
Las educción de requisitos es un proceso para encontrar los requisitos
para un sistema de software que se intenta desarrollar, usando la
comunicación con el cliente, los consumidores finales, usuarios del
sistema y otros que tienen algún papel en el desarrollo del sistema de
software.

Hay varios caminos para descubrir requisitos

Entrevistas
Las entrevistas son medios de recogida de requisitos medianamente
fuertes. La organización puede conducir muchos tipos de entrevistas,
tales como:

• Entrevistas estructuradas (cerradas), donde cada información que se

recoge es decidida con antelación, siguen patrones y temas de debate de
forma firme.

• Las entrevistas no estructuradas (abiertas), donde la información que se

busca no se decide con antelación, es más flexible y menos tendenciosa.

• Entrevistas orales

• Entrevistas por escrito

• Entrevistas cara a cara entre 2 personas

• Entrevistas de grupo que se llevan a cabo entre grupos de participantes.

Ayudan a destapar cualquier requisito que falte, ya que mucha gente está
incluida.

Encuestas
La organización puede conducir encuestas o sondeos entre varios
accionistas pidiendo sus expectativas y requisitos para el sistema que
se va a desarrollar.

Cuestionarios
Un documento con preguntas objetivas definidas previamente con sus
opciones respectivas. Se entrega a todos los accionistas para que las
respondan, se recogen y se recopilan.

Una limitación de esta técnica es que, si una opción por algún asunto
no se menciona en el cuestionario, el asunto puede quedar
desatendido.
Análisis de tareas
El equipo de ingenieros y de desarrolladores puede analizar la
operación por la cual se requiere el nuevo sistema. Si el cliente ya
tiene algún software para realizar ciertas operaciones, se estudia y los
requisitos del sistema propuesto se recogen.

Análisis de dominio
Cada software pertenece a una categoría de dominio. Los expertos en
dominio pueden ser de gran ayuda para analizar requisitos generales
y específicos.

Lluvia de ideas
Un debate informal se lleva a cabo entre varios accionistas y todos los
inputs o entradas se graban para el análisis de requisitos posterior.

Modelo de prototipos
Se basa en construir interfaces de usuario sin añadir detalles de las
funcionalidades para que el usuario interprete las características del
producto software que se quiere desarrollar. Ayuda aportando una
mejor idea de los requisitos. Si el consumidor final no tiene el software
instalado para que el desarrollador lo tome como referencia y el cliente
no sabe cuáles son sus propios requisitos, el desarrollador crea un
prototipo basado en los requisitos mencionados al inicio. El prototipo
se muestra al cliente y el feedback que se obtiene se registra. El
feedback del cliente sirve d input o entrada para la recogida de
requisitos.

Observación
El equipo de expertos visita la organización o el lugar de trabajo de
los clientes. Observan el funcionamiento de los sistemas instalados ya
existentes. También observan el flujo de trabajo y cómo se tratan los
problemas de ejecución. El equipo traza las conclusiones que ayudan
a formar los requisitos esperados para el software.

Características de los requisitos del

Software
La recogida de requisitos de software es la fundación de la totalidad
del proyecto de desarrollo software. Por ello, debe de ser clara,
correcta y bien definida.
Una completa especificación de requisitos Software debe ser:

• Clara

• Correcta

• Consistente

• Coherente

• Comprensible

• Modificable

• Verificable

• Priorizada

• sin ambigüedades

• Trazable

• Origen creíble

Requisitos de Software
Debemos intentar entender qué tipo de requisitos pueden aparecer en
la fase de educción de requisitos y qué tipo de requisitos se esperan
del sistema de software.

En líneas generales los requisitos de software se deben caracterizar

en dos categorías:

Requisitos funcionales
Requisitos que se relacionan a aspectos funcionales del software irían
en esta categoría.

Definen las funciones y la funcionalidad en y desde el sistema de

software.

EJEMPLOS -
• Buscar una opción dada al usuario para buscar desde varias facturas.

• El usuario debe ser capaz de enviar por correo electrónico cualquier

informe a la Dirección.

• Los usuarios se pueden dividir en grupos y los grupos pueden tener

derechos diferentes.

• Debe cumplir reglas empresariales y funciones administrativas.

 • El Software se desarrolla manteniendo intacta la compatibilidad en
descenso.

Requisitos no funcionales
Los requisitos, los cuales no están relacionados con aspectos
funcionales del software, están en esta categoría. Son características
del software implícitas o esperadas, asumidas por los usuarios.

Los requisitos no funcionales incluyen -

• Seguridad

• Acceso

• Almacenaje

• Configuración

• Actuación

• Coste

• Interoperabilidad

• Flexibilidad

• Recuperación de desastre

• Accesibilidad

Los requisitos se categorizan de forma lógica como

• Tienen que tener: El Software no puede ser operacional sin ellos.

• Deben tener: Motivando la funcionalidad del software.

• Pueden tener: El Software aún puede funcionar bien con estos

requisitos.

• Lista de deseo: Estos requisitos no contienen ningún objetivo de

software.

Mientras se desarrolla el software, el ‘tiene que tener’ se debe

implementar, el ‘debe tener’ es un asunto de debate y negociación, en
cambio el ‘puede tener’ y la ‘lita de deseo’ se pueden mantener para
futuras actualizaciones del software.

Requisitos de la interfaz de usuario

La UI es una parte importante de cualquier software, hardware o
sistema híbrido. Un software es ampliamente aceptado si es -
 • Fácil de manejar

• rápido en responder

• efectivo tratando errores operacionales

• aportando interfaces de usuario simples y consistentes

La aceptación del usuario mayormente depende de cómo éste pueda

usar el software. La UI es el único camino para percibir el sistema por
parte de los usuarios. Un sistema software de buena actuación
también debe estar equipado con interfaces de usuario atractivas,
claras, consistentes y receptivas. En caso contrario las funcionalidades
del sistema software no pueden usarse de una manera conveniente.
A system is said be good if it provides means to use it efficiently. User
interface requirements are briefly mentioned below -

• Presentación de contenido

• De fácil navegación

• Interfaces simples

• Receptivo

• Elementos consistentes de UI

• Mecanismo de retroalimentación

• Configuración Default

• Disposición significante

• Uso estratégico del color y la textura.

• Aportar información de ayuda

• Aproximación centrada en el usuario

• Vista de la configuración basada en el grupo.

Analista de sistemas Software

El analista de sistemas es una persona de una organización
informática, que analiza los requisitos del sistema propuesto y asegura
que los requisitos sean concebidos y documentados correctamente. El
papel del analista empieza durante la fase del SDLC de análisis del
Software. El analista tiene la responsabilidad de asegurar que el
software que se desarrolle cumpla los requisitos del cliente.

Los analistas de sistemas tienen las siguientes responsabilidades:

• Analizar y entender los requisitos del software deseado

 • Entender cómo será la contribución del proyecto en los objetivos de la
organización

• Identificar el origen de los requisitos

• Validación de requisitos

• Desarrollo e implementación el plan de gestión de requisitos

• Documentación empresarial, técnica, de proceso, y requisitos del

producto.

• Coordinación con los clientes para priorizar requisitos y eliminar

ambigüedad

• Terminar la aceptación de criterios con el cliente y otros accionistas

Métricas y medidas de Software

Las medidas de Software se pueden entender como un proceso para
cuantificar y simbolizar varios atributos y aspectos del software.

Las métricas de Software aportan medidas para varios aspectos del

proceso y del producto software.

Las medidas de Software son requisitos fundamentales de la

ingeniería de software. No solamente ayudan a controlar el desarrollo
del proceso software sino que también contribuyen a mantener la
calidad del producto final excelente.

Según Tom DeMarco, un ingeniero de Software, “No se puede

controlar lo que no se puede medir.” Con esta frase, deja muy clara
la gran importancia de las medidas de software.

Veamos algunas métricas de software:

• Métrica de tamaño - Las LOC (Líneas de código), se calculan

mayoritariamente en miles de líneas de código de origen entregadas,
llamado KLOC.

La medida del punto de función, se focaliza en la funcionalidad aportada

por el software. La medida del punto de función define el tamaño de los
aspectos funcionales del software.

• Métrica de complejidad - La complejidad ciclomática de McCabe

cuantifica el nivel más alto en cuanto al número de caminos
independientes en un programa, lo que se percibe como complejidad del
 programa o de sus módulos. Se representa siguiendo los conceptos de
teoría gráfica usando gráficos de flujo de control.

• Métrica de calidad - Defectos, tipos y causas, consecuencias, intensidad

en la severidad y sus implicaciones definen la calidad del producto.

El número de defectos encontrados en el proceso de desarrollo y el

número de defectos encontrados por el cliente después de la instalación
o entrega al consumidor final, define la calidad del producto.

• Métrica de Proceso - En varias fases del SDLC, los métodos y

herramientas usados, los estándares y la actuación de desarrollo de la
compañía, son métrica de procesos software.

• Métrica de recursos - El esfuerzo, el tiempo y varios recursos usados,

representan la métrica para la medida de recursos.

Software - Básicas de Diseño

El diseño de Software es un proceso que transforma los requisitos del
usuario de una manera conveniente, lo que ayuda al programador a
en la codificación e implementación del software.

Para evaluar los requisitos del usuario, un documento SRS (Software

Requirement Specification, en español 'ERS' especificación de
requisitos de software) se crea tanto para codificar como para
implementar, hay una necesidad de especificar de un modo más
detallado los requisitos en términos de Software. El resultado de este
proceso puede ser usado directamente en la implementación de
lenguajes de programación.

El diseño de Software es el primer paso en el SFDLC (Software Design

Life Cycle, en español ciclo de vida del diseño de software), lo que
cambia la atención e importancia desde problema de dominio a
solución de dominio. Intenta especificar cómo satisfacer los requisitos
mencionados en el SRS.
Diseño de niveles o entornos de
Software
El diseño de Software produce 3 niveles de resultados:

• Diseño arquitectónico - El Diseño arquitectónico, es la versión más

abstracta del sistema. Identifica el software como un sistema con
distintos componentes que interactúan entre ellos. En este momento es
cuando los diseñadores conciben la idea de posibles soluciones de
dominio.

• Diseño de alto nivel- El Diseño de alto nivel, rompe con el concepto de

diseño arquitectónico que se refiere a ‘Componente de única entidad
múltiple', por lo contrario tiene un punto de vista menos abstracto de los
sub sistemas y módulos y representa la existente interacción entre ellos.
El Diseño de alto nivel se centra en cómo el sistema junto con todos sus
componentes se puede implementar en forma de módulos. Reconoce
estructuras modulares de cada sub sistema y su relación e interacción
entre las mismas.

• Diseño detallado- El Diseño detallado diseña acuerdos con la parte de

implementación de lo que se ve como sistema y sus sub sistemas con los
dos tipos de diseño mencionados con anterioridad. Es más detallado en
cuanto a los módulos y a su implementación. Define estructuras lógicas
de cada módulo y de sus interfaces para comunicarse con los otros
módulos.

Modularización
La Modularización es una técnica para dividir sistemas de Software en
múltiples separados e independientes módulos, los cuales se espera
que sean capaces de llevar a cabo tareas(s) de forma independiente.
Estos módulos pueden funcionar como creaciones básicas para la
totalidad del software. Los diseñadores tienden a diseñar módulos que
se pueden ejecutar y/o almacenar por separado y de manera
independiente.

El diseño modular involuntariamente sigue las normas de la estrategia

de resolución de problemas centradas en ‘dividir y conquistar’, esto se
da porque hay muchos otros beneficios relacionados con el diseño
modular de un software.
Ventajas de la modularización:

• Los componentes más pequeños son más fáciles de mantener

• El programa se puede clasificar según los aspectos funcionales

• El nivel deseado de abstracción se puede aplicar al programa

• Los componentes con gran cohesión pueden reutilizarse de nuevo

• La ejecución simultánea es posible

• Es apropiado des del punto de vista de la seguridad

Concurrencia informática
Hace un tiempo, todos los softwares se hacían con la idea de que
fueran ejecutados de forma secuencial. Por secuencial se entiende que
las instrucciones codificadas serán ejecutadas una después de la otra
implicando solo una parte del programa activado en cualquier
momento. Pongamos que un software tiene múltiples módulos, en
este caso solo uno de entre todos los módulos puede estar activo en
cualquier momento de la ejecución.

En Diseño de software, la concurrencia se implementa dividiendo el

software en varias unidades de ejecución independientes, como si
fueran módulos ejecutándolos en paralelo. En otras palabras, la
concurrencia aporta capacidad al software para poder ejecutar más de
una parte del código de forma paralela a las otras.

Es necesario para programadores y diseñadores poder reconocer estos

módulos, los cuales se pueden crear de forma paralela a la ejecución.

Ejemplo
El corrector ortográfico del procesador de textos Word es un módulo
de software, que funciona de forma independiente al procesador de
textos mismo.

Acoplamiento y cohesión
Cuando un programa software está modularizado, sus tareas se
dividen en varios módulos en base a algunas características. Como
sabemos, los módulos son sets de instrucciones agrupados con la
finalidad de lograr ciertas tareas. Son complicados, si se consideran
como una sola entidad, pero pueden consultar al otro y trabajar de
manera conjunta. Hay formas de medir la calidad del diseño de los
módulos y de sus interacciones. Estas medidas se denominan
acoplamiento y cohesión.

Cohesión
La Cohesión es una medida que define el grado de interdependencia
entre los elementos que conforman los módulos. A mejor cohesión,
mejor diseño de programa obtenemos.

Hay siete tipos de cohesión, llamados –

• Cohesión coincidente - Es una cohesión no planificada y random, la cual

puede romper el programa en pequeños módulos por el bien de la
modularización. Como que no tiene una planificación, puede confundir a
los programadores. Por eso este tipo no está generalmente aceptado.

• Cohesión lógica - La categorización de manera lógica en la que los

elementos se colocan juntos en un mismo módulo, se denomina Cohesión
lógica.

• Cohesión temporal - Cuando los elementos del módulo se organizan de

manera que se procesan en un momento similar en el tiempo, hablamos
de Cohesión temporal.

• Cohesión procedimental - Cuando los elementos del módulo se

agrupan juntos, y se ejecutan de forma secuencial para poder llevar a
cabo una tarea, hablamos de Cohesión procedimental.

• Cohesión comunicativa - Cuando los elementos del módulo se agrupan

juntos, y se ejecutan y funcionan en los mismos datos (información) de
forma secuencial, hablamos de Cohesión comunicativa.

• Cohesión secuencial - Cuando los elementos del módulo se agrupan

porque el resultado de un elemento sirve de entrada a otro y así
sucesivamente, hablamos de Cohesión secuencial.

• Cohesión funcional - Se considera la mejor en cuanto a mayor grado de

cohesión, y es altamente previsible. Los elementos del módulo en
cohesión funcional se agrupan porque todos ellos contribuyen a conseguir
una función única y bien definida. También se puede reutilizar.

Acoplamiento
El acoplamiento es una medida que define el nivel de interdependencia
entre los módulos del programa. Nos muestra el nivel en que los
módulos interfieren e interactúan entre ellos. A menor acoplamiento,
mejor programa se obtiene.

Hay cinco niveles de acoplamiento, llamados -

• Acoplamiento de contenido - Cuando un módulo puede acceder,

modificar o consultar directamente el contenido de otro módulo hablamos
de acoplamiento del nivel de contenido.

• Acoplamiento común- Cuando múltiples módulos han leído y escrito el

acceso a algún dato global, hablamos de acoplamiento global o común.

• Acoplamiento de Control- Dos módulos se denominan acoplados de

control si uno de ellos decide la función del otro o cambia su flujo de
ejecución.

• Acoplamiento 'stamp'- Cuando múltiples módulos comparten la misma

estructura de datos y funcionan en diferentes partes de la misma,
hablamos de acoplamiento 'stamp'.

• Acoplamiento de datos- Se da cuando dos módulos interactúan entre

ellos con la finalidad de pasarse información (como parámetro). Si un
módulo pasa una estructura de datos como parámetro, el módulo
receptor debe usar todos sus componentes.

No hay un tipo de acoplamiento que se considere el mejor.

Verificación del Diseño

El resultado del proceso de diseño de Software es diseñar
documentación, pseudo códigos, diagramas lógicos y detallados,
diagramas de proceso, y descripción detallada de todos los requisitos
funcionales y no funcionales.

La siguiente fase, la implementación del software, depende de los

resultados mencionados con anterioridad.

En este momento es cuando se necesita verificar los resultados antes

de proceder con la siguiente fase. Cuanto antes de detecte un error
mejor, ya que puede que no se detecte hasta que se realicen las
pruebas de software del producto al final del proceso. Si los resultados
de la fase de diseño son anotaciones formales, sus herramientas
asociadas para la verificación deben ser usadas, en caso contrario se
puede usar una revisión del diseño para la verificación y la validación.
En la aproximación de verificación estructurada, los evaluadores
pueden detectar defectos que se han ocasionado por haber omitido
algunas condiciones. Un buen evaluador de diseño es importante para
conseguir un buen diseño de software con calidad y acurado.

Herramientas de Análisis y de
Diseño
El análisis y el diseño del Software incluye todas las actividades, que
ayudan a transformar los requisitos requeridos en implementación.
Los requisitos especifican la previsión operativa o no operativa del
software. La especificación de requisitos se da en documentos con un
lenguaje humano comprensible, con el que el ordenador no tiene
ninguna relación.

El análisis y el diseño de Software es la fase intermedia, que ayuda a

los requisitos legibles por humanos a ser transformados en códigos
reales.

Veamos algunas herramientas de análisis y de diseño usadas por

Ingenieros de software:

Diagrama de flujo de datos

Un Diagrama de flujo de datos (DFD), es una representación gráfica
de los flujos de datos en un sistema de información. Es capaz de
representar flujos de datos entrantes y salientes y datos almacenados.
El DFD no menciona nada sobre la manera en que los datos floyen por
el sistema.

Hay una gran diferencia entre el DFD y el Diagrama de flujo. El

segundo representa el flujo de control en módulos de programación.
Y el primero representa el flujo de información en el sistema en varios
niveles. El DFD no contiene ningún elemento de control o de
secuencia.

Tipos de DFD
Los Diagramas de flujo de datos son o físicos o lógicos
 • DFD lógico - Este tipo de DFD se concentra en el proceso y en el flujo de
datos del sistema. Por ejemplo, en los sistemas de software de Banking,
se centra en cómo se mueven los datos entre distintas entidades.

• DFD físico - Este tipo de DFD muestra cómo se implementa el flujo de

datos en el sistema. Es más específico y cercano a la implementación.

Componentes del DFD

El DFD puede representar el origen, el destino, el almacenaje y el flujo
de datos usando los siguientes componentes-

• Snippet - Son el origen y destino de la información de datos. Se

representan con rectángulos y sus respectivos nombres.

• Proceso - Actividades y acciones sobre los datos son representadas con

un círculo o con rectángulos redondeados.

• Almacenamiento de datos - Hay dos tipos de almacenamiento de datos

- puede representarse con un rectángulo sin sus lados cortos o con uno
abierto por un lado, es decir con un lado menos.

• Flujo de datos - El movimiento de los datos se muestra a través de

flechas puntiagudas. El movimiento se muestra desde la base de la flecha
que representa el origen y va hacia la cabeza de la flecha que representa
su destino.

Niveles de DFD
• Nivel 0 - El mayor nivel de abstracción del DFD se conoce como Nivel 0
DFD, el cual representa la totalidad de información del sistema en un
diagrama ocultando todos los detalles subyacentes. Los Niveles 0 de DFD
son también conocidos como nivel de contexto de DFD.
• Nivel 1 - El nivel 0 DFD se desglosa en un Nivel 1 DFD más específico. El
Nivel 1 DFD representa los módulos básicos del sistema así como el flujo
de información entre los distintos módulos. El Nivel 1 DFD también alude
a los procesos básicos y a las fuentes de información.
 • Nivel 2 - En este nivel el DFD muestra cómo fluyen los datos en los
módulos mencionados en el Nivel 1.

El mayor nivel de DFD se puede transformar en niveles específicos de

DFD más bajos pero con un entendimiento más preciso, a menos que el
deseado nivel de especificación se consiga.

Esquema gráfico
Un Esquema gráfico es un esquema derivado del Diagrama de flujo de
datos. Representa el sistema con mucho más detalle que el DFD.
Desglosa la totalidad del sistema en módulos funcionales más bajos,
describe funciones y sub-funciones de cada módulo del sistema de una
forma más exhaustiva y detallada que el DFD.

El esquema gráfico representa la estructura jerárquica de los módulos.

En cada capa se lleva a cabo una tasca específica.

A continuación se exponen los símbolos usados para formar esquemas

gráficos -

• Módulo - Puede representar proceso, subrutina o tarea. El módulo de

control se divide en más de un sub-módulo. Los módulos de la biblioteca
son reutilizables y no comparables con ningún módulo.
• Condición - Se representa con un pequeño diamante en la base del
módulo. Muestra que el módulo de control puede seleccionar cualquiera
de las subrutinas en base a algunas condiciones.

• Salto - Se trata de una flecha apuntando dentro del módulo para mostrar
que el control saltará hacia el centro del sub-módulo.
• Curva - Un flecha curvada representa que hay una curva en el módulo.
Todos los sub-módulos cubiertos por una curva repiten la ejecución del
módulo.

• Flujo de datos - Es representado con una flecha señalando un círculo

vacío.
 • Flujo de control - Es representado con una flecha señalando un círculo
relleno con color o diseños.

Diagrama HIPO
El Diagrama HIPO (Hierarchical Input Process Output) es una
combinación de dos métodos organizados para analizar el sistema y
proveer técnicas de documentación. El modelo HIPO fue desarrollado
por la empresa IBM en el año 1970.

El Diagrama HIPO representa la jerarquía de los módulos en el sistema

de Software. Los analistas de Software usan el Diagrama HIPO para
obtener una visión en profundidad de las funciones del sistema.
Descompone las funciones en sub funciones de manera jerárquica.
Representa las funciones que ha hecho el sistema.
Los Diagramas HIPO son buenos para propósitos relacionados con la
documentación. Su representación gráfica facilita a diseñadores y
Directivos a entender de manera visual la estructura del sistema.

En contraste con el Diagrama IPO (Input Process Output), que

representa el flujo de control y datos que se da en un módulo, el HIPO
no aporta información sobre el flujo de datos ni del flujo de control.
Ejemplo
Las dos partes de un Diagrama HIPO, la presentación jerárquica y el
esquema IPO, son usadas para estructurar el diseño del programa de
Software así como de su documentación.

'Structured English'
La mayor parte de los programadores no tienen un conocimiento total
en lo que se refiere al software y solo confían en las instrucciones a
seguir dictadas por sus jefes. Es responsabilidad de los altos Directivos
de Software de proveer información exhaustiva a los programadores
para poder desarrollar códigos de forma rápida y acurada.

Otro tipo de metodologías que usan gráficos o diagramas, a veces

pueden ser interpretadas de distinta forma por diferentes personas.

Por eso, tanto analistas como diseñadores de software intervienen en

la problemática con herramientas como 'Structured English'. Esto es
básicamente la descripción de lo que se requiere para el código y cómo
decodificarlo. 'Structured English' ayuda al programador a escribir
códigos sin errores.

Otro tipo de metodologías que usan gráficos o diagramas, a veces

pueden ser interpretadas de distinta forma por diferentes personas.
En este tipo de casos, tanto 'Structured English' como 'Pseudo-Code'
intentan resolver esta falta de entendimiento.

Structured English usa palabras normales en inglés en paradigmas de

programación estructurada. No es el código más reciente pero es un
tipo de descripción que se requiere para codificar y saber cómo
hacerlo. Las siguientes son algunas muestras de programación
estructurada

IF-THEN-ELSE,

DO-WHILE-UNTIL

Los analistas de software usan el mismo nombre para la variable y los

datos, los cuales se almacenan en un Diccionario de Datos, haciendo
más simple la escritura y el entendimiento de códigos.
Ejemplo
Cojamos el ejemplo de una autentificación de un cliente en el marco
de una compra de producto online. El procedimiento para autentificar
al cliente se puede escribir en Structured English como:

Enter Customer_Name

SEEK Customer_Name in Customer_Name_DB file

IF Customer_Name found THEN

Call procedure USER_PASSWORD_AUTHENTICATE()

ELSE

PRINT error message

Call procedure NEW_CUSTOMER_REQUEST()

ENDIF

El tipo de lenguaje usado en inglés de una manera estructurada es

como el inglés hablado en el día a día de forma oral. Este tipo de
lenguaje no se puede implementar directamente como un lenguaje
software. Structured English es independiente del lenguaje de
programación.

Pseudo-Código
El Pseudo-Código se escribe de manera más cercana al lenguaje de
programación. Se puede considerar como un lenguaje de
programación popular, lleno de comentarios y de descripciones.

El Pseudo-Código ignora declaraciones variables, pero se escriben

usando construcciones reales de lenguaje de programación, como el
caso de C, Fortran, Pascal etc.

El Pseudo-Código contiene más detalles de programación que

Structured English. Nos provee con una metodología para llevar a cabo
la tarea, como si el ordenador estuviera ejecutando el código.

Ejemplo
Programa para imprimir Fibonacci a números n.

void function Fibonacci

Get value of n;

Set value of a to 1;
Set value of b to 1;

Initialize I to 0

for (i=0; i< n; i++)

if a greater than b

Increase b by a;

Print b;

else if b greater than a

increase a by b;

print a;

Tablas de decisión
Una tabla de decisión representa las condiciones y las respectivas para
dirigirlas, en un formato tabular estructurado.

Es una poderosa herramienta para eliminar fallos y prevenir errores.

Ayuda a agrupar información similar en la misma tabla y después
combinando tablas obtiene convenientes y fáciles tomas de
decisiones.

Creando Tablas de decisión

Para crear Tablas de decisión, el desarrollador de software debe seguir
4 pasos básicos:

• Identificar todas las condiciones posibles para ser direccionadas

• Determinar las acciones para todas las condiciones identificadas

• Crear el máximo número posible de normas

• Definir acciones a realizar para cada norma

Las Tablas de decisión deben ser verificadas por los consumidores
finales para poder ser posteriormente simplificadas eliminando
acciones y normas duplicadas.

Ejemplo
Veamos un simple ejemplo de un problema que nos ocurre día a día
con nuestra conexión de Internet. Empezamos identificando todos los
problemas que pueden surgir mientras iniciamos Internet y sus
posibles soluciones.

Haremos un listado de todos los posibles problemas en una columna

denominada 'condiciones' y otra sobre acciones esperadas en una
columna llamada 'acciones'.

Condiciones/Acciones Normas

Condiciones Se muestra conectado N N N N Y Y Y Y

Los recursos de red funcionan N N Y Y N N Y Y

Abre el sitio Web Y N Y N Y N Y N

Acciones Comprueba el cable de conexión a X

Internet

Examina el router X X X X

Reinicia el navegador Web X

Contacta con el Servicio de atención X X X X X X

al cliente

No realice ninguna acción /td>

Tabla: Tabla de decisión – Problema en la red de Internet doméstica

Modelo entidad-relación
El Modelo o diagrama entidad-relación (a veces denominado por sus
siglas en inglés, E-R "Entity relationship", o del español DER
"Diagrama de Entidad Relación") es un tipo de modelo de base de
datos basado en la noción de entidades mundiales reales y su relación
entre ellas. Podemos trazar un mapa del escenario mundial real en el
modelo ER de base de datos. Este modelo crea un set de entidades
con sus respectivos atributos, y un set de limitaciones y su relación
entre ellas.

El modelo ER se usa frecuentemente para el diseño conceptual de

Bases de datos. El modelo ER se puede representar de la siguiente
manera:

• Entidad - Una entidad en modelo ER Model es un ser del mundo real, que
tiene algunas propiedades llamadas atributos. Cada atributo se define
por sus correspondientes sets de valores llamados dominio.

Por ejemplo, considere una Base de datos de una escuela. En este caso,
un estudiante sería una entidad. El estudiante tiene varios atributos como
nombre, identidad, edad, clase, etc.

• Relación - La asociación lógica entre entidades se denomina relación.

Las relaciones son esquematizadas con las entidades de varias maneras.
Esquematizar la cardinalidad define el número de asociaciones entre dos
entidades.

Esquematizar cardinalidad:

o uno a uno

o uno a varios

o varios a uno
 o varios a varios

Diccionario de datos
El Diccionario de datos es la colección central de información sobre los
datos. Almacena el significado y el origen de los datos, su relación con
otros datos, su formato de uso etc. El diccionario de datos tiene
rigurosas definiciones de todos los nombres para facilitar al Usuario y
a los diseñadores de software.

El Diccionario de datos es frecuentemente mencionado como

Repositorio Metadato (son datos que describen otros datos). Fue
creado junto con el modelo de programa software DFD (Diagrama de
flujo de datos) y se espera que se actualice cuando el DFD se cambie
o sea actualizado.

Requisitos del Diccionario de datos

Los datos son mencionados a través del Diccionario de datos mientras
se diseña e implementa el Software. El Diccionario de datos elimina
posibles ambigüedades. Ayuda a mantener sincronizado el trabajo de
los programadores y de los diseñadores mientras se usa el mismo
objeto de referencia en todo el programa.

Los Diccionarios de datos aportan una vía de documentación para el

completo sistema de Base de datos en un lugar. La validación del DFD
se lleva a cabo usando Diccionarios de datos.

Contenidos
El diccionario de datos debe contener información sobre los siguientes

• Flujo de datos

• Estructura de los datos

• Elementos de los datos

• Almacenajes de datos

• Procesamiento de datos

El flujo de datos se describe por su significado en el DFD como se ha

mencionado anteriormente, y representado de manera algebraica.

= Compuesto por
{} Repetición

() Opcional

+ y

[/] O

Ejemplo
Domicilio = Número + (calle / barrio) + Ciudad + estado

Identificación del Curso = Número del curso + Nombre del curso +

Nivel del curso + Grado del curso

Elementos de los datos

Los elementos que conforman los datos son el nombre y la descripción
de los mismos y de los elementos de control, el almacenaje interno y
externo de datos, etc. con los siguientes detalles:

• Nombre principal

• Nombre secundario (Alias)

• Caso de uso (Cómo y dónde usar)

• Descripción del contenido (anotación, etc.)

• Información adicional (valores actuales, límites, etc.)

Almacenamiento de datos
Almacena la información desde donde entran y salen los datos al y del
sistema. El almacenamiento de datos puede incluir -

• Archivos

o Internos al software.

o Externos al software, pero en la misma máquina.

o Externos al software y al sistema, ubicados en una máquina

distinta.

• Tablas

o Acuerdo sobre nomenclatura

o Propiedad de Indexación
Procesamiento de datos
Hay dos tipos de procesamiento de datos:

• Lógico: Tal y como el usuario lo ve

• Físico: Tal y como el software lo ve

Software - Estrategias de Diseño

El Diseño de Software es un proceso para conceptualizar los requisitos
de software en implementación de software. El Diseño de Software
toma los requisitos del Usuario como retos e intenta encontrar
soluciones óptimas. Mientras el software se conceptualiza, se planea
el mejor diseño para poder implementar la solución deseable.

Hay muchas variantes de diseño de software. Estudiémoslas pues de

manera breve:

Diseño Estructurado
El Diseño estructurado es la conceptualización de un problema en
varios elementos organizados de solución. Está básicamente centrado
en el diseño de soluciones. El beneficio del diseño estructurado es que
da un mejor entendimiento sobre cómo se resuelve el problema. El
diseño estructurado también simplifica el proceso al diseñador, por
tanto, este último puede concentrarse en el problema de forma más
acurada.

El Diseño estructurado se basa en 'dividir y conquistar', estrategia

donde el problema se rompe en otros pequeños problemas y cada uno
es tratado por separado para finalmente resolver la totalidad del
problema.

Los pequeños problemas en los que se subdivide el problema principal

se solucionan y agrupan en módulos de solución. El Diseño
estructurado enfatiza en que los módulos estén bien organizados con
tal de que se consiga la solución precisa requerida.
Estos módulos se organizan de manera jerárquica. Se comunican
entre ellos. Un buen diseño estructurado siempre sigue algunas
normas de comunicación entre los diversos módulos, llamadas -

Cohesión - Agrupar todos los elementos relacionados por función.

Acoplamiento - comunicación entre los distintos módulos.

Un buen diseño estructurado tiene alta cohesión y bajo acoplamiento.

Diseño orientado a la función

En Diseño orientado a la función, el sistema es comprimido en varios
pequeños sub sistemas conocidos como funciones. Estas funciones
son capaces de llevar a cabo tareas significativas en el sistema. El
sistema es considerado como la vista superior de todas las funciones.

El diseño orientado a la función posee algunas propiedades inherentes

del diseño estructurado donde la metodología de dividir y conquistar
se usa.

Este mecanismo de diseño divide la totalidad del sistema en pequeñas

funciones, lo cual nos aporta por medio de la abstracción ocultando la
información y sus operaciones. Estos módulos funcionales pueden
compartir información entre ellos pasando información y usando
información disponible a nivel global.

Otra característica de las funciones es que cuando un programa acude

a una función, la función cambia el estado del programa, por lo que a
veces no es aceptado por otros módulos. El diseño orientado a la
función funciona bien cuando el estado del sistema no es importante
y programa/funciones funcionan con entradas en vez de con estados.

Proceso de diseño

• El sistema en su totalidad es visto según cómo fluyen los datos en éste

por medio de un diagrama de flujo de datos.

• El DFD representa cómo las funciones cambian los datos y el estado de

todo el sistema.

• El sistema se rompe de forma lógica en pequeñas unidades conocidas

como funciones en base a sus operaciones en el sistema.

• Cada función es descrita posteriormente en toda su extensión.

Diseño orientado al objeto
El diseño orientado al objeto funciona alrededor de entidades y sus
características en vez de involucrando funciones en el sistema de
software. Esta estrategia de diseño se centra en entidades y sus
características. Todo el concepto de solución de software se centra en
las entidades implicadas.

Veamos pues los conceptos importantes que abarca el Diseño

orientado al objeto:

• Objetos - Todas las entidades implicadas en el diseño de la solución son

conocidas como objetos. Por ejemplo, persona, bancos, empresa, y
clientes con tratados como objetos. Cada entidad tiene algunos atributos
asociados a éste y tiene algunos métodos para actuar sobre los atributos.

• Clases - Una clase es una descripción general de un objeto. Un objeto es

un ejemplo de una clase. La clase define todos los atributos que un objeto
puede tener y los métodos, lo cual define la funcionalidad del objeto.

En el diseño de la solución, los atributos se almacenan como variables y

las funcionalidades se definen por medio de métodos o procedimientos.

• Encapsulación - En OOD, los atributos (variables de los datos) y los

métodos (intervención en los datos) se juntan, hablamos de
encapsulación. La encapsulación no solo une la información importante
de un objeto en un mismo lugar, también restringe el acceso a datos y
métodos desde el mundo exterior. Esto es llamado ocultación de
información.

• Herencia - OOD permite clases similares para acumular de manera

jerárquica donde las sub clases pueden importar, implementar y reutilizar
variables y métodos permitidos de sus inmediatas súper clases. Esta
propiedad de OOD es conocida como herencia. Esto facilita a la hora de
definir clases y crearlas desde otras clases específicas.

• Polimorfismo - Los lenguajes OOD nos dan un mecanismo donde los

métodos llevan a cabo tareas similares, pero con variantes en los
argumentos, se le puede asignar el mismo nombre. Esto se llama
polimorfismo, lo que permite a una interfaz única llevar a cabo tareas de
diferente tipo. Dependiendo de cómo se aplique la función, la parte del
código respectiva se ejecuta.
Proceso de diseño
El proceso de diseño de Software se puede definir en una serie de
pasos bien definidos. Aunque cambie según el tipo de aproximación
(orientado a la función o al objeto), Debe seguir los siguientes pasos:

• Una solución de diseño se crea partiendo de un requisito o un sistema

usado con anterioridad y/o el diagrama de secuencia de un sistema.

• Los objetos se identifican y agrupan en clases según su similaridad con

las características del atributo.

• La jerarquía de clase y su relación entre ellos está definida.

• El borrador de la aplicación está definido.

Aproximaciones para diseño de

Software
Aquí tenemos 2 aproximaciones genéricas para diseñar software:

Diseño 'Top Down' (de arriba a abajo)

Sabemos que un sistema se compone por más de un sub sistema y
que contiene varios componentes. Además, estos subsistemas y
componentes pueden tener su set de sub sistemas y componentes y
crear estructuras jerárquicas dentro del sistema.

El Diseño Top-down toma la totalidad del sistema software como una

entidad y lo descompone para conseguir más de un sub sistema o
componente basado en algunas características. Cada sub sistema o
componente es entonces tratado como un sistema descompuesto
adicional. Este proceso continúa funcionando hasta llegar al nivel más
bajo del sistema en la jerarquía 'top-down'.

El Diseño Top-down empieza con un modelo generalizado de sistema

y continúa definiendo las partes más específicas de éste. Cuando todos
los componentes están formados el sistema empieza a existir.

El Diseño Top-down es más recomendable cuando la solución software

necesita ser diseñada des del inicio y los detalles específicos son
desconocidos.

Bottom-up Design
El modelo de Diseño 'bottom up' (de abajo a arriba) empieza con
componentes más básicos y específicos. Continúa formando un mayor
nivel de componentes usando un nivel básico o bajo de componentes.
Sigue creando componentes de alto nivel hasta el punto en el que el
sistema deseado no ha evolucionado en un solo componente. Como
mayor sea el nivel más incrementará la abstracción.

La estrategia de Bottom-up es más recomendable cuando un sistema

necesita ser creado desde uno ya existente, donde los elementos
primos pueden usarse para el sistema nuevo.

En Ambos, El diseño top-down y el diseño bottom-up, la aproximación

no es práctica de manera individual. Por tanto, se usa una buena
combinación de los dos.

Software - Diseño de UI
La interfaz de usuario es la parte visible de la aplicación front-end
(traducible al español como interfaz) con la que el usuario interacciona
a fin de usar el software. El usuario puede manipular y controlar el
software, así como el hardware por medio de las interfaces de usuario.
Hoy en día, la interfaz de usuario se encuentra casi en todos los
lugares donde existe tecnología digital, desde ordenadores, móviles,
coches, reproductores de música, aviones, barcos, etc.

La interfaz de usuario es parte del software y está diseñada de tal

manera que se espera proveer al usuario con un conocimiento sobre
la percepción del software. La UI (Interfaz de usuario) también aporta
una plataforma fundamental para la interacción entre los humanos y
el ordenador.

La UI puede ser gráfica, en forma de texto, audiovisual, dependiendo

del hardware subyacente y su combinación con el software. La UI
puede ser un hardware, un software o una combinación de ambos.

El software suele ser más popular cuando su UI es:

• Atractiva

• Fácil de usar

• De respuesta rápida
 • Clara de comprender

• Coherente en toda la pantalla de interfaz

La UI se divide en dos categorías:

• Interfaz de línea de comandos

• Interfaz gráfica de usuario (GUI)

Interfaz de línea de comandos (CLI en

sus siglas inglesas)
La interfaz de línea de comandos, traducción del inglés command-line
interface –la cual es, en realidad, una transcripción incorrecta de
Interfaz de línea de órdenes, por el falso amigo command
(orden/instrucción), ha sido una gran herramienta de interacción con
ordenadores hasta que llegaron los reproductores de video. La CLI es
la primera opción de muchos usuarios técnicos y programadores. La
CLI es la interfaz mínima que un software puede ofrecer a sus
usuarios.

La CLI ofrece un símbolo del sistema, el lugar donde el usuario escribe

el comando y alimenta al sistema. El usuario debe recordar la sintaxis
del comando y también su uso. Hace un tiempo las CLI no estaban
programadas para tratar los errores del usuario de forma eficiente.

Un comando es una referencia de instrucciones en modo texto, las

cuales serán ejecutadas por el sistema. Existen métodos como macros
macro (del griego μακρο, makro, que significa ‘grande’, es una
abreviatura de macroinstrucción), scripts (también llamado archivo de
órdenes, archivo de procesamiento por lotes o guion), que facilitan al
usuario operar con el software.

La CLI usa menos cantidad de recursos informáticos en comparación

con la GUI.
Elementos de la CLI

Una CLI en forma de texto puede tener los elementos que se exponen
a continuación:

• Símbolo de sistema - Es un notificador en texto que mayormente

muestra el contexto en el que el usuario trabaja. Es generado por el
sistema de software.

• Cursor - Es una línea horizontal o una barra vertical de la longitud de la

línea, para representar la posición del carácter mientras se escribe. El
cursor se encuentra por lo general en un estado de parpadeo. Se mueve
a medida que el usuario escribe o elimina algo.

• Comando (u Orden) - Un comando es una instrucción ejecutable. Puede

tener uno o más parámetros. El resultado de la ejecución del comando
se muestra alineado en la pantalla. Cuando se produce una salida, el
símbolo de sistema se muestra en la siguiente línea.
Interfaz gráfica de usuario
La Interfaz gráfica de usuario está diseñada para interactuar con el
sistema. La GUI puede ser una combinación de hardware y software.
Usando una GUI, el usuario puede interpretar el software.

Por lo general, la GUI consume más recursos que la CLI. Con

tecnología avanzada, los programadores y diseñadores diseños
complejos de GUI que funcionan con más eficiencia, velocidad y
precisión.

Elementos de la GUI
La GUI ofrece un conjunto de componentes para interactuar con el
software o con el hardware.

Cada componente gráfico ofrece un modo de trabajo con el sistema.

Un sistema de GUI tiene algunos de los elementos mencionados a
continuación:

• Ventana - Zona donde se muestran los contenidos de las aplicaciones.

Los contenidos de una ventana se pueden mostrar en forma de iconos o
de listas, si la ventana representa la estructura del archivo. Navegar es
 más fácil para el usuario en el sistema de archivos en una ventana de
exploración. Las ventanas se pueden minimizar, minimizar su tamaño, o
maximizar a la medida de la pantalla. Se pueden mover a cualquier lugar
de la pantalla. Una ventana puede contener otra ventana de la misma
aplicación, llamada ventana hija.

• Pestañas - Si una aplicación permite ejecutar más de una instancia de

ella misma, aparecen en la pantalla en una ventana separada.
Navegación por pestañas Ha aparecido para abrir más de un
documento en la misma ventana. Esta interfaz también contribuye en la
visión del panel de preferencia en la aplicación. Todos los exploradores
web modernos usan esta característica.

• Menú - El Menú es un despliegue de comandos estándar, agrupados

juntos y colocados en un lugar visible (normalmente en la parte superior)
dentro de la ventana de la aplicación. El menú se puede programar para
aparecer o mostrarse escondido usando los botones del ratón.

• Icono - Un icono es una pequeña imagen que representa una aplicación

asociada. Cuando se aprietan estos iconos o con uno o con doble click, la
ventana de aplicación se abre. Los iconos muestran aplicaciones y
programas instalados en un sistema en forma de pequeñas imágenes.

• Cursor - Usando dispositivos como el ratón, touch pad (panel táctil), el

lápiz digital son representados en GUI como cursores. En la pantalla el
cursor sigue las instrucciones del hardware casi en tiempo real. Los
cursores son también llamados puntero en sistemas de GUI. Se usan para
seleccionar menús, ventanas, y otras características de la aplicación.

Componentes GUI para aplicaciones específicas

La GUI de una aplicación contiene uno o más elementos que se
enumeran a continuación:

• Ventana de la aplicación - La mayoría de ventanas de la aplicación usan

los algoritmos de sistemas operadores, pero algunas usan su propia
creación de ventana de usuario para almacenar los contenidos de la
aplicación.

• Cuadro de diálogo - Es una ventana hija que contiene un mensaje de

petición para el usuario para que lleve a cabo una acción determinada.
Por ejemplo: Una aplicación genera un diálogo para tener confirmación
del usuario para eliminar un archivo.
• Caja de texto - Ofrece una zona para que el usuario escriba o para que
introduzca datos en texto.

• Botones - Imitan botones de la vida real y se usan para enviar entradas

al software.

• botón de Radio - Muestra opciones de selección disponibles. Sólo se

puede seleccionar una de entre todas las que se ofrecen.

• Casilla de verificación - Las funciones son similares a las del Cuadro de

lista. Cuando se selecciona una opción, la casilla aparece como marcada.
Se pueden seleccionar múltiples opciones representadas por casillas de
verificación.
 • Cuadro de lista - Aporta una lista de los ítems disponibles para la
selección. Se puede seleccionar más de un ítem.

Otros componentes sorprendentes de la GUI son:

• Sliders

• Combo-box (casilla combinada)

• Data-grid (Cuadrícula de datos)

• Drop-down list (Lista desplegable)

Actividades de diseño de la interfaz de

usuario
Se realizan muchas actividades para el diseño de la interfaz de
usuario. El proceso para el diseño de la GUI, así como su
implementación es como el SDLC. Se puede usar Cualquier modelo
para la implementación de una GUI entre los modelos de Cascada,
reiterativo, o en espiral.

Un modelo usado para el diseño y el desarrollo de la GUI debe

satisfacer estos pasos específicos.
• Recogida de requisitos de la GUI - A los diseñadores quizá les guste
tener una lista de todos los requisitos funcionales y no funcionales de la
GUI. Esto se puede obtener del usuario y de su solución software
existente.

• Análisis de usuario - El diseñador estudia qué va a usar el software de

la GUI. El target de consumidores es importante ya que los detalles del
diseño cambian según el conocimiento y el nivel de competencia del
usuario. Si el usuario es entendido en cuestiones técnicas, se puede
incorporar una GUI avanzada y compleja. Para un usuario novato, se
incluye más información sobre cómo usar el software.
 • Análisis de tarea - Los diseñadores deben analizar qué tareas tiene que
hacer la solución software. Para la GUI, no importa cómo se hará. Las
tareas se pueden representar de forma jerárquica tomando las tareas
mayores y dividiéndolas en sub tareas más pequeñas. Las tareas aportan
los objetivos para la presentación de la GUI. El flujo de información entre
sub tareas determina el flujo de contenidos de la GUI en el software.

• Diseño e implementación de la GUI - Los diseñadores una vez han

obtenido información sobre los requisitos, las tareas y el entorno del
usuario, diseñan e implementan el código de la GUI, incorporando
software simulado en el fondo. Luego se evalúa por los desarrolladores.

• Evaluación - Las pruebas para la GUI se pueden hacer de varias

maneras. La organización puede tener inspección interna, una implicación
directa de los usuarios, o se puede sacar una versión beta. Las pruebas
pueden incluir usabilidad, compatibilidad, aceptación por parte del
usuario, etc.

Herramientas de implementación de la
GUI
Hay muchas herramientas disponibles con las que los diseñadores
pueden crear la totalidad de las GUI. Algunas herramientas se pueden
incorporar en entorno software(IDE).

La implementación de las herramientas de la GUI ofrece un poderoso

despliegue de controles de GUI. Para la customización del software
customización, los diseñadores pueden cambiar el código en acorde.

Hay distintos segmentos de las herramientas GUI según su uso y su

plataforma.

Ejemplo
GUI para móvil, para ordenador, para pantalla táctil, etc. Aquí se
enumeran algunas herramientas útiles para la construcción de una
GUI:

• FLUID

• AppInventor (Android)

• LucidChart

• Wavemaker
 • Visual Studio

Reglas de oro para una interfaz de

usuario
Las siguientes reglas se consideran reglas de oro para el diseño de
una GUI. Fueron descritas por Shneiderman y Plaisant en su libro
('Designing the User Interface', en español 'Diseñando interfaces de
usuario').

• Esfuerzo de coherencia - Las secuencias coherentes de acciones son

requeridas en situaciones similares. Se debe usar terminología idéntica
en menús, prompts, y pantallas de ayuda. Los comandos coherentes
deben ser empleados en de punta a cabo.

• Posibilitar el uso de atajos a usuarios frecuentes - El deseo del

usuario por reducir el número de interacciones se incrementa con la
frecuencia de uso. Las abreviaciones, funciones clave, comandos
escondidos, y facilidades macro son muy útiles para un usuario experto.

• Ofrecer retroalimentación informativa - Para cada acción del

operador, debe haber alguna retroalimentación de sistema. Para acciones
menores y frecuentes, la respuesta debe ser modesta, mientras que, para
acciones no frecuentes y mayores, la respuesta debe ser más substancial.

• Diseñar diálogo para permitir el cierre - Las secuencias de acciones

se deben organizar en grupos con un inicio, núcleo, y final. La
retroalimentación informativa cuando se completa un grupo de acciones
da a los operadores una gran satisfacción de logro, un sentimiento de
alivio, la señal de abandonar planes y opciones de contingencia de sus
mentes, y esto indica que el camino a seguir es claro y se pueden
preparar para el siguiente grupo de acciones.

• Ofrecer tratamientos de error simples - Diseñe tanto como sea

posible el sistema para que el usuario no haga errores graves. Si se
comete un error, el sistema debe poder detectarlo y ofrecer mecanismos
simples y comprensibles para tratar el error.

• Permitir deshacer acciones fácilmente - Esta característica reduce la

ansiedad, ya que el usuario sabe que los errores se pueden deshacer.
Esto motiva la exploración de opciones nuevas y no familiares. Las
unidades de reversibilidad pueden ser una sola acción, una entrada de
datos, o un grupo de acciones.
 • Permitir la ubicación interna de control - Los operadores con
experiencia desean de todo corazón poder sentir que tienen el control del
sistema y que el sistema responde a sus acciones. Diseñe el sistema de
modo que los usuarios puedan iniciar acciones en vez de ser los que
responden.

• Reducir la carga de memoria a corto plazo - La limitación humana

para procesar información con una memoria a corto plazo hace necesario
mantener la pantalla de forma simple, así como mostrar las páginas de
forma coherente, reducir la frecuencia de 'window-motion' y asignar un
tiempo de formación suficiente para los códigos, mnemónicos, y las
secuencias de acciones.

Software - Diseño Complejidad

El término de complejidad se refiere al estado de eventos o cosas, que
tienen múltiples interconexiones y una estructura altamente
complicada. En programación de software, a medida que el diseño de
software es obtenido, el número de elementos y sus interconexiones
gradualmente aparecen para ser mayores, lo que hace difícil que se
pueda entender en un solo intento.

La complejidad del diseño de Software es difícil de evaluar sin usar

complejos métodos de medida. Veamos pues 3 métodos de medida
importantes para complejidades de software.

Medidas de complejidad de Halstead

En 1977, el Señor Maurice Howard Halstead introdujo sistemas de
medida para medir la complejidad del software. Las medidas de
Halstead dependen de la implementación real del programa y de sus
medidas, las cuales son computadas directamente desde los
operadores y operandos del código de origen, de forma estática.
Permite evaluar el 'testing time', el vocabulario, la medida, dificultad,
errores, y esfuerzos para códigos de origen C/C++/Java.

Según Halstead, “Un programa de ordenador es una implementación

de un algoritmo considerado una colección de símbolos que se pueden
clasificar como operadores o como operandos”. Las medidas de
Halstead toman al programa como una secuencia de operadores y sus
operandos relacionados.

Define varios indicadores para evaluar la complejidad del módulo.

Parámetro Significado

n1 Número de un solo operador

n2 Número de un solo operando

N1 Número total de casos de operadores

N2 Número total de casos de operandos

Cuando seleccionamos origen del archivo para ver sus detalles de

complejidad en un Visor Métrico, se ven los siguientes resultados en
el Informa Métrico:

Métrico Significado Representación matemática

n Vocabulario n1 + n2

N medida N1 + N2

V Volumen Longitud * Log2 Vocabulario

D Dificultad (n1/2) * (N1/n2)

E Esfuerzos Dificultad * Volumen

B Errores Volumen / 3000

T 'Testing time' Tiempo = esfuerzos / S, donde S=18 segundos.

Medidas de Complejidad ciclomática
Cada programa incluye enunciados para ejecutar con tal de llevar a
cabo una tarea y otros enunciados de toma de decisiones que deciden,
qué órdenes son necesarias. Los enunciados de toma de decisiones
cambian el flujo del programa.

Si comparamos dos programas del mismo tamaño, el que tiene más

enunciados de toma de decisiones será más complejo ya que el control
de programa salta con frecuencia.

McCabe, en 1976, propuso la medida de complejidad ciclomática para

cuantificar la complejidad de un software. Es un modelo gráfico
determinado que se basa en las órdenes de toma de decisiones del
programa como el if-else, do-while, repeat-until, switch-case y goto
statements.

Proceso para realizar un gráfico de flujo de control:

• Rompa el programa en pequeños bloques, delimitados por las tomas de

decisiones.

• Cree nódulos representando cada uno de estos nódulos.

• Conecte los nódulos de la siguiente forma:

o Si el control se puede ramificar del bloque i al bloque j

Dibuje un arco

o Desde el nódulo de salida hasta el nódulo de entrada

Dibuje un arco.

Para calcular la complejidad ciclomática del nódulo de un programa,

usaremos la fórmula -

V(G) = e – n + 2

Where

e is total number of edges

n is total number of nodes

La complejidad ciclomática del módulo de encima es

e = 10

n = 8

Cyclomatic Complexity = 10 - 8 + 2 = 4

Según P. Jorgensen, la complejidad ciclomática de un módulo no debe

ser mayor a 10.

Métrica de punto función

Es ampliamente usada para medir el tamaño del software. La Métrica
de punto función, se centra en la funcionalidad que aporta el sistema.
Las características y funcionalidades del sistema se usan para medir
la complejidad del software.

La Métrica de punto función, cuenta con cinco parámetros, llamados

Entrada externo, Salida externa, Archivos de lógica interna, Archivos
de interfaz externa, y Consulta externa. Para considerar la
complejidad del software cada parámetro se categorizará como
simple, medio o complejo.
Veamos los parámetros de la métrica de punto de función:

Entrada externa
Cada entrada del sistema, desde fuera, se considera entrada externa.
La singularidad de la entrada se mide, ya que dos entradas no deben
tener el mismo formato. Estas entradas pueden ser o datos o
parámetros de control.

• Simple - Si una entrada es baja y afecta menos a los archivos internos

• Complejo - Si una entrada es elevada y afecta más a los archivos

internos

• Medio - Estaría entre el simple y el complejo

Salida externa
Todos los tipos de salida que da el sistema forman parte de esta
categoría. La salida se considera única si su formato de salida y/o su
procesamiento son únicos.

• Simple - Si la salida es baja

• Compleja - Si la salida es alta

• Media - Entre la simple y la compleja.

Archivos de lógica interna
Cada sistema de software mantiene archivos internos con tal de
mantener su información funcional y para funcionar mejor. Estos
archivos contienen datos lógicos del sistema. Estos datos lógicos
pueden contener tanto datos funcionales como datos de control.

• Simple - Si el número de tipos registrado es bajo

• Complejo - Si el número de tipos registrado es alto

• Medio - Entre el simple y el complejo.

Archivos de interfaz externa

El sistema de Software puede necesitar compartir sus archivos con
otro software externo o quizá necesite pasar archivos para el
procesamiento o como parámetro de alguna función. Todos estos
archivos son considerados archivos de interfaz externa.

• Simple - Si el número de tipos registrado en un archivo compartido es

bajo

• Complejo - Si el número de tipos registrado es alto

• Medio - Entre el simple y el complejo.

Consulta externa
Una consulta es la combinación de una entrada y una salida, cuando
el usuario envía algún dato para consultar como entrada y el sistema
responde al usuario con una salida de consulta procesada. La
complejidad de la consulta es más alta que la entrada externa y la
salida externa. La consulta es única si sus entradas y salidas son
también únicas en lo que se refiere al formato y a los datos.

• Simple - Si la consulta necesita un procesamiento menor y produce un

menor número de datos.

• Complejo - Si la consulta necesita un procesamiento alto y produce una

gran cantidad de salida de datos

• Medio - Entre el simple y el complejo.

A Cada uno de estos parámetros del sistema se les da un peso

determinado dependiendo de su tipo y complejidad. La tabla de abajo
menciona el peso dado a cada parámetro:
Parámetro Simple Medio Complejo

Entradas 3 4 6

Salidas 4 5 7

Consulta 3 4 6

Archivos 7 10 15

Interfaces 5 7 10

La tabla de encima produce Métrica de punto función pura. Esta se

ajusta de acuerdo con la complejidad del entorno. El sistema se
describe usando 14 características distintas:

• Comunicación de datos

• Computación distribuida

• Objetivos de actuación

• Funcionamiento de carga de Configuración

• Tasa de la transacción

• Entrada de datos Online

• Eficiencia del consumidor final

• Actualización online

• Procesamiento complejo y lógico

• Reutilización

• Facilidad de Instalación

• Facilidad operativa

• Webs Múltiples

• Intencionalidad para facilitar cambios

Estos factores característicos se puntúan de 0 al 5, como se menciona

a continuación:

• Sin influencia
 • Adicional

• Moderado

• Medio

• Significante

• Esencial

Todas las puntuaciones se resumen como N. El valor de N va del 0 al

70 (14 tipos de características x 5 tipos de puntuaciones). Se usa para
calcular los factores de ajuste de complejidad (CAF, en sus siglas en
inglés para 'Complexity adjustment factor'), usando la siguiente
fórmula:

CAF = 0.65 + 0.01N

Luego,

Delivered Function Points (FP)= CAF x Raw FP

Este FP puede usarse en varias medidas como por ejemplo:

Coste = $ / FP

Calidad = Errores / FP

Productividad = FP / persona-mes

Software - Implementación
En este capítulo, estudiaremos métodos de programación,
documentación y retos en la implementación de Software.

Programación estructurada
En el proceso de codificación, las líneas del código se multiplican
continuamente, por consiguiente, el tamaño del software se
incrementa. Se vuelve casi imposible recordar el flujo del programa
gradualmente. Si nos olvidamos cómo se construyen el software y sus
subyacentes programas, los archivos... resulta muy difícil compartir,
modificar y eliminar los fallos del programa. La solución yace en la
programación estructurada. Motiva al desarrollador a usar subrutinas
y estructuras de control (loops) en vez de usar simples saltos en el
código, de este modo haciendo el código más claro y mejorando su
eficiencia, la programación estructurada también ayuda al
programador a reducir el tiempo de codificación y a organizar el
lenguaje de programación correctamente.

La programación estructurada define cómo debe ser codificado el

programa. La programación estructurada usa principalmente 3
conceptos:

• Análisis 'Top-down'(de arriba a abajo) - El software se crea

principalmente para llevar a cabo un tipo de trabajo racional. Este tipo
de trabajo se conoce como problema en la jerga software. Por
consiguiente, es muy importante que entendamos cómo resolver el
problema. Según el análisis top-down, el problema debe romperse en
pequeñas piezas con un significado concreto. Cada problema se resuelve
de manera independiente y los pasos a seguir para resolver el problema
en su conjunto son dictados de manera clara.

• Programación modular - Mientras se programa, el código se rompe en

pequeños grupos de instrucciones. Estos grupos se denominan módulos,
subprogramas o subrutinas. La programación modular se basa en el
entendimiento del análisis top-down. Desmotiva los saltos usando
órdenes de 'Ir a' en el programa, lo que a menudo hace que el flujo del
programa no sea localizable. En programación modular Los saltos están
prohibidos y se fomenta el formato modular.

• Codificación estructurada - En referencia al análisis top-down, la

codificación estructurada divide los módulos en pequeñas unidades de
código para su satisfactoria ejecución. La programación estructurada usa
estructuras de control, las cuales controlan el flujo del programa,
mientras que la codificación estructurada usa estructuras de control para
organizar sus instrucciones en patrones definibles.

Programación funcional
La programación funcional es un estilo de lenguaje de programación,
que usa conceptos de funciones matemáticas. En matemáticas una
función siempre debe producir el mismo resultado si recibe el mismo
argumento. En un lenguaje procedimental, el flujo del programa
funciona a través de procedimientos, esto es, el control del programa
se transfiere al procedimiento mencionado. Mientras el flujo de control
se transfiere de un procedimiento a otro, el programa cambia su
estado.

En programación procedimental, es posible que un procedimiento

produzca resultados diferentes cuando es llamado con el mismo
argumento, ya que el programa puede estar en un estado diferente
mientras se llama al mismo. Esta es una propiedad, así como una
desventaja de la programación procedimental, en que la secuencia o
temporalización de la ejecución procedimental se vuelve importante.

La programación funcional aporta medios de computación, así como

funciones matemáticas, lo que genera resultados independientemente
del estado del programa. Esto posibilita la predicción del
comportamiento del programa.

La programación funcional usa los siguientes conceptos:

• Funciones de primera clase y de orden superior - Estas funciones

tienen la capacidad de aceptar otra función como argumento o de
devolver otras funciones como resultado.

• Funciones puras - Estas funciones no incluyen actualizaciones

destructivas, es decir, no afectan a ningún Periférico de Entrada/Salida o
a la memoria, y si no se usan pueden ser fácilmente eliminadas sin
dificultar al resto del programa.

• Recursión - La recursión es una técnica en que la función se llama a sí

misma y repite el código del programa en ésta, a menos que alguna
condición definida previamente se corresponda con la misma. La
recursión es el camino para crear estructuras de sistema en programación
funcional.

• Evaluación estricta - Es un método para evaluar la expresión que se ha

pasado a una función como argumento. La programación funcional tiene
dos tipos de métodos de evaluación, el estricto (entusiasta) y el no
estricto (vago). La evaluación estricta siempre evalúa la expresión antes
de aplicar la función. La evaluación no estricta no evalúa la expresión a
menos que sea necesario.

• Cálculo lambda (λ-calculus) - La mayor parte de lenguajes de

programación usan cálculo lambda como su sistema de tipos. Las
expresiones 'λ' se ejecutan evaluándolas tal y como ocurren.
Common Lisp, Scala, Haskell, Erlang y F# son algunos ejemplos de
lenguajes de programación funcional.

Estilo de programación
El estilo de programación se configura con reglas de codificación
seguidas por todos los programadores para escribir el código. Cuando
más de un programador trabaja en el mismo proyecto de software,
necesitan frecuentemente trabajar con el código del programa que ha
escrito otro desarrollador. Esto se vuelve tedioso o a veces imposible,
si todos los desarrolladores no siguen un estilo de programación
estándar para codificar el programa.

Un estilo de programación apropiado incluye el uso de funciones y

nombres variables y relevantes para la tarea que se va a llevar a cabo,
usando una sangría bien ubicada, comentando el código para la
conveniencia del lector y para la presentación general del código. Esto
facilita la inteligibilidad del código, lo que facilita que uno por uno se
eliminen y solucionen los errores. Además, un estilo de codificación
adecuado ayuda a facilitar el proceso de actualización y de
documentación.

Directrices de codificación
Las distintas prácticas de estilo de codificación varían en cada
organización, sistema operativo, y en el mismo lenguaje de
codificación.

Los siguientes elementos de codificación se pueden definir bajo las

directrices de una organización:

• Convención de nomenclatura - Esta sección define cómo nombrar

funciones, variables, constantes, y variables globales.

• Sangría - Este es el espacio que se encuentra al principio de cada línea,

normalmente incluye de 2 a 8 espacios en blanco o un solo tabulador
(véase tecla 'tab').

• Espacio en blanco - Generalmente se omite al final de cada línea.

• Operadores - Define las reglas para escribir operadores lógicos y tareas

matemáticas. Por ejemplo, operador de tarea ‘=’ debe tener un espacio
antes y después de éste, como en “x = 2”.
 • Estructuras de Control - Son las reglas para escribir 'SI..ENTONCES..SI
NO'(if..then..else), el SEGÚN (case o switch), declaraciones 'while-until'
para afirmaciones de flujo de control únicamente, y en lenguaje
ensamblador de moda.

• Longitud de línea y envoltorio - Define el número de caracteres que

debe haber en una línea, mayormente una línea tiene 80 caracteres de
longitud. Envolver define cómo se envolverá la línea, si es demasiado
larga.

• Funciones - Esto define cómo se deben aplicar y manifestar las

funciones, con y sin parámetros.

• Variables - Esto menciona cómo se deben manifestar y definir las

variables de diferentes tipos de datos.

• Comentarios - Este es uno de los componentes más importantes de la

codificación, ya que los comentarios que se incluyen en el código
describen describe lo que realmente hace el código y todas las otras
descripciones asociadas. Esta sección también ayuda a crear
documentación de ayuda para otros desarrolladores.

Documentación de Software
La documentación de Software es una parte importante del proceso
de software. Un documento bien escrito es una gran herramienta y es
un medio repositorio de información necesario para conocer el proceso
de software. La documentación de Software también aporta
información sobre cómo se debe usar el producto.

Una documentación mantenida correctamente debe incluir los

documentos que se citan a continuación:

• Documentación de requisitos - Esta documentación funciona como

herramienta clave para diseñadores de software, desarrolladores, y el
equipo de evaluadores, para llevar a cabo sus respectivas tareas. Este
documento contiene la descripción funcional, no funcional, y conductual
del software que se intenta lograr.

El origen de este documento pueden ser datos almacenados previamente,

software que ya está funcionando con el consumidor final, entrevistas con
clientes, cuestionarios e investigaciones. Generalmente se almacena en
forma de hoja de cálculo o de documento realizados con procesadores de
texto, con el equipo de gestión de software de mayor calidad.
 Esta documentación funciona como base para desarrollar el software y se
usa mayormente en las fases de verificación y de validación. La mayor
pare de casos de prueba se construyen partiendo de la documentación
de requisitos.

• Documentación de diseño de Software - Esta documentación

contiene toda la información necesaria, que se requiere para construir el
software. Incluye: (a) arquitectura de software de alto nivel, (b)Detalles
de diseño Software, (c) Diagramas de flujo de datos, (d)Diseño de bases
de datos

Estos documentos funcionan como repositorio para que los

desarrolladores implementen el software. A pesar de que estos
documentos no den ningún detalle de cómo codificar el programa, dan la
información necesaria que se requiere para las fases de codificación e
implementación.

• Documentación técnica - Esta documentación la mantienen

desarrolladores y programadores. Estos documentos, en su conjunto,
representan información sobre el código. Mientras escriben el código, los
programadores también suelen mencionar objetivos del código, quién lo
escribió, dónde se requerirá, qué hace y no hace, qué otros recursos usa
el código, etc.

La documentación técnica incrementa el entendimiento entre varios

programadores que trabajan en el mismo código. Incentiva la capacidad
de reutilización del código. Facilita el proceso de eliminación y localización
de errores.

Hay varias herramientas automatizadas disponibles y algunas ya vienen

con su propio lenguaje de programación. Por ejemplo, java viene con la
herramienta JavaDoc tool para generar documentación técnica del
código.

• Documentación del usuario - Esta documentación es diferente en

comparación con las mencionadas con anterioridad. Las que ya se han
expuesto se mantienen para la aportación de información sobre el
software y su proceso de desarrollo. Por el contrario, la documentación
de usuario explica cómo se debe usar y cómo debe funcionar el producto
software, con tal de lograr los resultados que se esperan.

Esta documentación puede incluir, procedimientos de instalación del

software, guías de instrucciones, guías para el usuario, método de
 desinstalación y referencias especiales para obtener más información
como actualización de licencias, etc.

Retos de la implementación de
Software
Hay algunos retos que el equipo de desarrollo debe afrontar mientras
se implementa el software. Algunos de ellos se explicitan a
continuación:

• Reutilización del código - Las interfaces de programación de los

lenguajes actuales son muy sofisticadas y están equipadas con grandes
funciones de librería. Aun así, y a fin de disminuir el coste del producto
final, la gestión organizacional prefiere reutilizar el código, el cual se creó
con anterioridad para algún otro software. Hay asuntos de gran magnitud
que deben ser confrontados por los programadores para tests de
compatibilidad y decidiendo la cantidad de código se reutilizará.

• Gestión de versiones - Cada vez que un nuevo software se entrega al

consumidor, los desarrolladores deben mantener la documentación
asociada a su configuración y a su versión. Esta documentación debe ser
muy acurada y disponible a tiempo.

• 'Target-Host'(target de receptores) - El programa software que se

está desarrollando en la organización, necesita ser diseñado para
máquinas receptoras para el consumidor final. Pero a veces, es imposible
diseñar un software que funciones en máquinas receptoras.

Software - Visión General de

Pruebas
Las pruebas de Software son una evaluación del software en contraste
con la recogida de requisitos de usuarios y especificaciones de
sistema. Las pruebas son conducidas al nivel de 'fase' en el SDLC o al
nivel de módulo en código de programa. Las pruebas de Software
incluyen la validación y la verificación.
Validación del Software
La validación es un proceso para examinar si el software satisface o
no los requisitos del usuario. Se lleva a cabo al final del SDLC. Si el
software cumple los requisitos por los cuales se diseñó, se valida.

• La validación asegura que el producto en desarrollo cumplirá los

requisitos del usuario.

• La validación contesta a las preguntas – "¿Se está desarrollando el

producto que intenta cumplir todos los requisitos que el usuario
necesita?".

• La validación enfatiza en los requisitos del usuario.

Verificación Software
La verificación es el proceso de confirmación del cumplimiento de los
requisitos empresariales por parte del software, y se desarrolla
ciñéndose a especificaciones y metodologías adecuadas.

• La verificación asegura que el producto que se está desarrollando va en

acorde con las especificaciones de diseño.

• La verificación responde a la pregunta– "¿Se está desarrollando el

producto siguiendo de manera estricta todas las especificaciones de
diseño?"

• Las Verificaciones se concentran en el diseño y las especificaciones del

sistema.

El Target de la prueba es -

• Errores - Son errores de codificación cometidos por los desarrolladores.

Además, si hay una diferencia en la entrada de software y el resultado u
output deseado, esto se considera un error.

• Defecto - Cuando ocurren errores, hay defectos. Un defecto, es el

resultado de un error que puede ocasionar fallos en el sistema.

• Fallo - Es la inhabilidad del sistema de realizar la tarea deseada. Un fallo

suele ocurrir cuando hay un defecto en el sistema.

Pruebas manuales Vs Automatizadas

La evaluación se puede hacer de forma manual o bien usando una
herramienta de evaluación automatizada:
 • Manuales - Esta evaluación se lleva a cabo sin ayuda de herramientas
de evaluación automatizadas. El evaluador de software prepara ejemplos
de pruebas para diferentes secciones y niveles del código, ejecuta las
pruebas y entrega los informes al director.

Las pruebas manuales consumen mucho tiempo y recursos. Los

evaluadores necesitan confirmar si los ejemplos de test se usan. La
mayoría de evaluaciones incluyen pruebas manuales.

• Automatizadas Esta evaluación sigue un procedimiento realizado con la

ayuda de herramientas de evaluación automatizada. Las limitaciones con
evaluaciones manuales se pueden subsanar con herramientas
automatizadas de evaluación.

La prueba necesita evaluar si la página web se puede abrir en Internet

Explorer. Esto se puede realizar de forma simple con pruebas
manuales. Pero para evaluar si el explorador web puede soportar la
carga de 1 millón de usuarios, es casi imposible hacerlo de forma
manual.

Hay herramientas de software y hardware que ayudan a los

evaluadores en la conducción de la evaluación de carga, pruebas de
estrés, y pruebas de regresión.

Aproximaciones para la evaluación

Las pruebas se pueden conducir basándose en dos aproximaciones –

• Pruebas funcionales

• Pruebas de implementación

Cuando se evalúa la funcionalidad sin considerar la implementación

real, se conoce como Prueba de caja negra. El otro lado se conoce
como prueba de caja blanca, donde no solo se evalúa la funcionalidad,
también se analiza el modo de implementación.

Los tests exhaustivos son los métodos más deseados para una
evaluación perfecta. Cada valor posible en el rango de valor de
entrada y salida es evaluado. No es posible evaluar cada valor del
mundo real si el rango d valores es grande.

Pruebas de caja negra

Se llevan a cabo para evaluar la funcionalidad del programa. También
se denominan pruebas de conducta. El evaluador en este caso, tiene
un conjunto de valores de entrada con su resultado deseado
respectivo. Cuando se aporta la entrada o input, si el resultado u
output cumple con los resultados deseados, el programa se puede
evaluar bien, en caso contrario la evaluación será problemática.

En esta metodología de evaluación, el diseño y la estructura del código

son desconocidos por el evaluador, así que ingenieros de evaluación y
usuarios conducen este test sobre el software.

Técnicas para pruebas de caja negra:

• Clases de equivalencia - El input o entrada se divide en clases similares.

Si un elemento de una clase pasa el test, se asume que todas las clases
también pasarán.

• Valores de los límites - El input o entrada se divide en valor final alto o

valor final bajo. Si estos valores pasan el test, se asume que todos los
valores que hay entre ellos también lo harán.

• Gráfico causa-efecto - En los dos métodos previos, solo se evalúa un

valor de entrada cada vez, nunca más de uno a la vez. La causa
(entrada)-efecto (salida) es una técnica de evaluación donde distintas
combinaciones de valores de entrada se evalúan de forma sistémica.

• Evaluación 'Pair-wise' - La conducta del software depende de muchos

parámetros. En este tipo de evaluación, los parámetros múltiples se
evalúan pair-wise (dos a la vez) para sus distintos valores.

• Evaluación basada en el estado - El sistema cambia su estado en

provisión de entradas. Este tipo de sistema se evalúa en base a su estatus
y sus inputs o entradas.
Pruebas de caja blanca
Se conducen para evaluar el programa y sus implementaciones, a fin
de mejorar la eficiencia del código o su estructura. También se conoce
como evaluación estructural.

En este tipo de metodología, el diseño y la estructura del código son

conocidos por el evaluador. Los programadores de código conducen
este test en el código.

A continuación, se exponen algunas técnicas de evaluación de caja

blanca:

• Evaluación del flujo de control - El propósito de este tipo de evaluación

es el de configurar ejemplos de test que cubran todas las condiciones de
la compañía. Las condiciones de la compañía se evalúan para ambos
siendo verdadero o falso, para que todas las declaraciones se puedan
cubrir.

• Evaluación del flujo de datos - Esta técnica enfatiza en cubrir todas las
variables de datos incluidas en el programa. Evalúa dónde se declaran,
definen, se usan o cambian las variables.

Niveles de evaluación
La evaluación por sí misma se puede definir en varios niveles de SDLC.
El proceso evaluador se lleva a cabo en paralelo al desarrollo del
software. Antes de lanzarnos a la siguiente etapa, la etapa se evalúa,
valida y verifica.
Evaluar de forma separada se hace para asegurar que no hay defectos
escondidos o asuntos que se han dejado de lado en el software. El
Software se evalúa en varios niveles -

Evaluación unitaria
Mientras se codifica, el programador hace algunos tests en esa unidad
de programa para saber si está libre de errores. La evaluación se lleva
a cabo con técnicas de caja blanca. La evaluación unitaria ayuda a los
desarrolladores a decidir que las unidades del programa funcionan
según los requisitos y están libres de errores.

Pruebas de integración
Aunque las unidades del software funcionen bien de forma individual,
se necesita encontrar si las unidades que están integradas y juntas
también funcionan sin errores. Por ejemplo, actualización de datos,
etc.

Evaluación del sistema

El software se compila como producto y entonces se evalúa en su
conjunto. Este proceso de cumple usando uno o más tests se los que
se mencionan a continuación:

• Evaluación funcional - Evalúa todas las funcionalidades del software en

contraste a los requisitos.

• Evaluación de la actuación - Este test nos informa de la eficiencia del

software. Evalúa la efectividad y el tiempo medio que tarda el software
en hacer las tareas deseadas. La evaluación de la actuación se realiza por
medio de tests de carga y de estrés donde el software se pone bajo
condiciones de alto usuario y carga de datos.

• Seguridad y portabilidad - These tests are done when the software is

meant to work on various platforms and accessed by number of persons.

Tests de aceptación
Cuando el software está listo para ser entregado al cliente tiene que
pasar por la última fase de evaluación donde se comprobará su
interacción con el usuario y su capacidad de respuesta. Esto es
importante porque, aunque el software cumpla todos los requisitos del
consumidor, si al usuario no le gusta su apariencia o su forma de
funcionar, puede ser que acabe por ser rechazado.
 • Pruebas Alpha - El equipo de desarrolladores hacen la evaluación 'Alpha'
usando el sistema como si ya se estuviera en un entorno de trabajo.
Intentan así averiguar cómo reaccionaría el usuario a alguna acción del
software, y cómo el sistema debe responder a entradas o inputs distintos.

• Pruebas Beta - Una vez se ha evaluado el software internamente, es

entregado a los usuarios para que lo utilicen en su contexto de
producción, simplemente para poder evaluarlo. Este no es aún el
producto entregado. Los desarrolladores esperan que los usuarios en esta
fase aporten problemas muy específicos, que podrían fácilmente pasarse
por alto en el proceso de desarrollo.

Pruebas de regresión
Cuando un producto software se actualiza con un nuevo código o con
nuevas características o funcionalidades, se evalúa para detectar si
hay algún impacto negativo con lo que se ha añadido. Este proceso se
conoce como prueba de regresión.

Documentación evaluativa
Los tests se preparan en diferentes etapas -

Antes de evaluar
Las pruebas empiezan con la generación de tests demo. Para ello se
necesitan los siguientes documentos de referencia –

• Documento ERS (especificación de requisitos de software) -

Documento de requisitos funcionales

• Documento de evaluación de normas - Describe la magnitud o alcance

que deben tener las pruebas antes de lanzar el producto al mercado.

• Documento evaluativo de estrategia - Menciona aspectos muy

detallados del equipo de evaluación, matriz de responsabilidades y
derechos/responsabilidad del jefe de evaluación y del ingeniero de
evaluación.

• Matriz de trazabilidad - Es un documento del SDLC, que se relaciona

con el proceso de recogida de requisitos. A medida que aparecen nuevos
requisitos, son añadidos a esta matriz. Estas matrices ayudan a los
evaluadores a averiguar el origen del requisito. Pueden ser delineados
hacia adelante o hacia atrás.
Mientras se evalúa
Los siguientes documentos pueden requerirse mientras se está
evaluando tanto al inicio como durante el proceso:

• Documento del caso de prueba - Este documento contiene una lista de

tests que se deben realizar. Incluye un plan de evaluación unitario, un
plan de evaluación integrado, un plan de evaluación del sistema y un plan
de evaluación para su aceptación.

• Descripción de la prueba - Este documento describe de forma

minuciosa todos los ejemplos de test y procedimientos para llevarlos a
cabo.

• Informe del caso de prueba - Este documento contiene un informe de

caso de prueba como resultado del test.

• Test logarítmico - Este documento contiene un test logarítmico para

cada informe de caso de prueba.

Después de las pruebas

Se pueden generar estos documentos después de las pruebas:

• Sumario del Test - Este sumario es un análisis colectivo de todos los

informes de test y accesos. Resume y concluye si el software está listo
para ser lanzado al mercado. En caso positivo el software se pone en el
mercado con una versión de sistema de control.

Pruebas vs. Control de calidad,

Aseguranza de calidad y Audit
Necesitamos entender que la evaluación de software es diferente de
la aseguranza de calidad de software, del control de calidad, y del
auditing (evaluación).

• Aseguranza de calidad del Software - Son técnicas de monitoreo para

procesos de desarrollo software, con los cuales se asegura que las
medidas se llevan a cabo siguiendo los estándares de la organización.
Este proceso se realiza para asegurar que se están siguiendo los métodos
de desarrollo de software adecuados.

• Control de calidad del Software - Es un sistema para mantener la

calidad del producto software. Puede incluir aspectos funcionales y no
funcionales del producto software, lo cual fomenta la reputación de la
organización. Este sistema asegura que el cliente recibe un producto de
 calidad para sus requisitos y el producto es considerado conveniente para
su uso.

• Evaluación del Software (audit) - Es una revisión del procedimiento

usado por la organización para desarrollar el software. Un equipo de
'auditors' (evaluadores) independientemente del equipo de desarrollo
examinan el proceso software, procedimientos, requisitos y otros
aspectos del SDLC. El objetivo de esta evaluación es comprobar que el
software y su proceso de desarrollo, se ciñen a los estándares, normas y
regulaciones.

Software - Mantenimiento
El mantenimiento del Software es hoy en día aceptado comparte del
SDLC. Se refiere a todas las modificaciones y actualizaciones que se
llevan a cabo después de la entrega del producto software. Hay
muchas razones por las que las modificaciones son necesarias,
algunas de ellas se mencionan de manera breve a continuación:

• Condiciones de mercado - Leyes, las cuales cambian con el paso del

tiempo, como los impuestos o limitaciones que se han introducido de
recientemente, como es el caso de: Cómo mantener la contabilidad,
puede desencadenar en una necesidad de modificación.

• Requisitos del cliente - A medida que pasa el tiempo, el consumidor

puede pedir nuevas funciones o características en el software.

• Modificaciones del servidor - Si algún tipo de hardware y/o plataforma

(como es el caso de un sistema operativo) del servidor target cambia, se
requerirán cambios en el software para mantener la adaptabilidad.

• Cambios organizativos - Si se produjera algún cambio a nivel de

negocio con el consumidor final, como por ejemplo una reducción de la
fuerza organizacional, adquiriendo otra compañía, un emprendimiento
organizacional en un nuevo negocio, puede que se necesite modificar algo
del software original.
Tipos de mantenimiento
En el ciclo vital del software, el tipo de mantenimiento puede variar
según la naturaleza del producto. Puede que sea simplemente una
tarea rutinaria de mantenimiento porque algún usuario ha encontrado
un virus, o puede tratarse propiamente de un gran evento basado en
la magnitud del mantenimiento o en su naturaleza. A continuación,
presentamos algunos tipos de mantenimiento fundamentados en sus
características:

• Mantenimiento correctivo - Este tipo incluye las modificaciones y

actualizaciones que se han hecho con tal de corregir o resolver problemas
descubiertos por el usuario o se han encontrado en informes de error de
algún usuario.

• Mantenimiento adaptable - Este tipo incluye modificaciones y

actualizaciones que se han aplicado para mantener el producto software
al día y en consonancia con el siempre cambiante mundo de las
tecnologías y entornos de negocio.

• Mantenimiento perfectivo - Esto incluye las modificaciones y

actualizaciones que se han realizado con tal de mantener el software
usable por un largo periodo de tiempo. Aquí se incluyen nuevas
características, nuevos requisitos para perfeccionar el software y mejorar
su fiabilidad y su rendimiento.

• Mantenimiento preventivo - Incluye las modificaciones y

actualizaciones para prevenir problemas de software en un futuro.
Pretende ocuparse de problemas, que no son muy significativos por el
momento pero que podrían ocasionar graves conflictos en un futuro.

Coste de Mantenimiento
Los informes insinúan que el coste de mantenimiento es alto. Un
estudio realizado para estimar el mantenimiento de software concluyó
que el coste de mantenimiento representa un 67% del coste total en
el ciclo del proceso de software.
El promedio del coste del mantenimiento de software constituye más
del 50% en todas las fases del SDLC. Hay varios factores, que inducen
el aumento del coste de mantenimiento, como es el caso de:

Factores reales que afectan al coste de

mantenimiento
• La edad media de un software se sitúa entre 10 y 15 años.

• Los softwares más viejos, diseñados para trabajar en máquinas lentas y

con menos memoria y capacidad de almacenaje, no pueden mantenerse
en el mercado con la competencia de nuevos y perfeccionados softwares
en hardware modernos.

• A medida que la tecnología avanza, se vuelve más caro mantener

software antiguo.
 • La mayoría de ingenieros de mantenimiento son principiantes y usan
métodos de error y de prueba para rectificar problemas.

• A menudo, los cambios que se hacen pueden fácilmente dañar la

estructura original del software, dificultando cambios posteriores.

• Los cambios se suelen dejar indocumentados, lo que puede ocasionar más

conflictos en el futuro.

Factores del software final que afectan a los

costes de mantenimiento

• Estructura del programa de Software

• Lenguaje de programación

• Dependencia a entornos externos

• Disponibilidad y fiabilidad de personal

Actividades de mantenimiento
El IEEE proporciona un borrador para las actividades del proceso
secuencial de mantenimiento. Se puede usar de forma reiterativa y
puede extenderse para que los artículos personalizados puedan
incluirse.
Estas actividades van cogidas de la mano con cada una de las
siguientes fases:

• Identificación & Seguimiento - Incluye las actividades que pertenecen

a la identificación de requisitos de modificación o mantenimiento. Es
generado por el usuario o el mismo sistema puede anunciar a través de
mensajes de error o registros. Aquí, el tipo de mantenimiento también se
clasifica.

• Análisis - La modificación se analizada por su impacto en el sistema,

incluyendo implicaciones de seguridad. Si un probable impacto es severo,
se busca una solución alternativa. Un conjunto de modificaciones
requeridas se materializa entonces en requisitos del sistema. El coste del
mantenimiento/modificación se analiza y se concluye con una estimación.

• Diseño - Nuevos módulos, que necesitan ser modificados o

reemplazados, se diseñan en contra de los requisitos que ya se han fijado
 en la fase previa. Las pruebas de casos se han creado para la validación
y la verificación.

• Implementación - Los nuevos módulos son codificados con la ayuda del

diseño estructurado creado en la fase de diseño. Cada programador debe
hacer pruebas unitarias en paralelo.

• Evaluación del sistema - Las pruebas de integración se hace entre

nuevos módulos creados. Las pruebas de integración también se llevan a
cabo entre módulos nuevos y el sistema. Finalmente, el sistema se evalúa
en su conjunto, siguiendo procedimientos evaluativos reaccionarios.

• Pruebas de aceptación - Después de evaluar el sistema de manera

interna, se evalúa la aceptación con la ayuda de los consumidores. Si en
esta etapa, los consumidores se quejan de algún asunto, son redirigidos
o se les notifica que se dirijan a la siguiente repetición.

• Entrega - Después del test de aceptación, el sistema se implementa en

la totalidad de la organización con pequeños paquetes de actualizaciones
o con la instalación nueva del sistema. La evaluación final se da con el
consumidor final después de entregar el software.

Se provee formación si se requiere, además de una copia en papel del

manual del usuario.

• Gestión de mantenimiento - La gestión de la configuración es una parte

esencial del mantenimiento del sistema. Es auxiliado con herramientas
de control de versiones, semi-versiones o Gestión de parches.

Refactorización de Software
Cuando necesitamos actualizar el software para mantenerlo en el
mercado actual, sin afectar a su funcionalidad, estamos ante un caso
de refactorización de software. Es un proceso en el que el diseño del
software se cambia y los programas se escriben de nuevo.

El software heredado no puede adaptarse a las nuevas y más recientes

tecnologías disponibles en el mercado. Como que el hardware se
vuelve obsoleto, la actualización de software se convierte en un dolor
de cabeza. Aunque el software envejezca con el tiempo, sus
funcionalidades no hacen los mismo.
Por ejemplo, Unix fue desarrollado en lenguaje ensamblador. Cuando
el lenguaje C empezó a existir, Unix fue refactorizado en C, porque
trabajando en el lenguaje previo era difícil.

A parte de este caso, a veces los programadores notan que en algunas

partes del software se necesita más mantenimiento que en otras, y
también necesitan refactorización.

Proceso de refactorización
• Decidir Lo que va a ser refactorizado, si va a ser una parte del software
o su totalidad.
 • Desarrollar La ingeniería inversa, con tal de obtener especificaciones de
software ya existentes.

• Reestructurar el programa Si se requiere. Por ejemplo, cambiar

programas orientados a la función en programas orientados al objeto.
• Reestructurar datos tal y como se requiera.

• Aplicar conceptos de Ingeniería directa o deductiva con tal de que

el software pase por un proceso de refactorización.

Hay varios conceptos importantes usados en la refactorización de

Software

Ingeniería inversa
Es un proceso para lograr especificaciones del sistema a través del
análisis y el entendimiento del sistema existente. Este proceso puede
verse como un modelo inverso de SDLC, esto es, intentamos lograr
mayor nivel de abstracción analizando niveles de abstracción más
bajos.

En un sistema existente se implementa un diseño previamente, sobre

el que no sabemos nada. Los diseñadores utilizan entonces ingeniería
inversa observando el código e intentan lograr el diseño. Con el diseño
en mano, intentan encontrar las especificaciones. Por consiguiente,
van al revés des del código hasta los requisitos del sistema.

Reestructurar el Programa
Es un proceso de reestructuración y construcción de software ya
existente. Se vuelve a organizar el código de origen, en el mismo
lenguaje de programación o con otro distinto. La reestructuración
puede tener su origen en la reestructuración del código, de los datos
o de ambos.

La reestructuración no tiene un impacto en la funcionalidad del

software, pero aumenta la fiabilidad y la capacidad de su
mantenimiento. Los elementos del Programa, que ocasionan errores
frecuentemente pueden cambiarse o actualizarse con la
reestructuración.

La dependencia del software en plataformas hardware obsoletas se

puede eliminar a través de la reestructuración.

Ingeniería directa
La ingeniería directa es un proceso para obtener el software deseado
a partir de los requisitos que se han obtenido mediante la ingeniería
invertida. Asume que había alguna ingeniería de software ya hecha en
el pasado.

La ingeniería directa es igual que en el proceso de ingeniería de

software, pero con una diferencia – Siempre se lleva a cabo después
de la ingeniería inversa.

Reutilización de componentes
Un componente es parte del código del programa software, el cual
ejecuta tareas independientes en el sistema. Puede ser un módulo
pequeño o un subsistema en sí mismo.

Ejemplo
Los procedimientos de acceso que se usan en las webs se pueden
considerar como componentes, el sistema de impresión en software
se puede considerar como componente del software.

Los Componentes tienen una alta cohesión de funcionalidad y una tasa

baja de acoplamiento, esto es, trabajan de manera independiente y
pueden llevar a cabo tareas sin tener que depender de otros módulos.

En programación orientada al objeto (OOP), los objetos se diseñan de

forma muy específica dependiendo de sus preocupaciones, y tienen
pocos cambios para ser usados en otro software.
En programación modular, los módulos se codifican para llevar a cabo
tareas concretas que se pueden usar sobre un gran número de otros
programas software.

Hay una nueva y completa vertical, que se basa en la reutilización de

componentes software, y se conoce como programación orientada a
componentes (que también es llamada basada en componentes y
tiene sus siglas en inglés 'CBSE').

La reutilización se puede hacer en varios niveles

• Nivel de aplicación - Cuando una aplicación entera se usa como

subsistema de software nuevo.

• Nivel de Componente - Cuando el subsistema de una aplicación es

usado.

• Nivel de módulos - Donde los módulos funcionales son reutilizados.

Los componentes del Software aportan interfaces, que pueden usarse

para establecer comunicación entre los distintos componentes.

Proceso de reutilización
Se pueden adoptar dos tipos de método: o manteniendo los requisitos
de la misma manera y ajustando los componentes, o manteniendo los
componentes igual, pero modificando los requisitos.
• Requisitos del sistema - Los requisitos funcionales y no funcionales del
producto software se especifican, y este debe cumplirlos, con la ayuda
del sistema existente, una entrada (input) de un usuario, o con ambos.

• Diseño - Esto es también un paso del proceso estándar de SDLC, donde

los requisitos se definen en términos de jerga de software. La
arquitectura básica del sistema en su totalidad y sus subsistemas son
creados.

• Especificar componentes - Mediante el estudio del diseño software, los

diseñadores dividen la totalidad del sistema en pequeños componentes o
subsistemas. Un diseño de software completado se vuelve una gran
colección de componentes trabajando juntos.
 • Buscar componentes adecuados - El repositorio de componentes
software es consultado por los diseñadores para buscar el componente
que combina, en base a la funcionalidad y a los requisitos del software.

• Incorporar Componentes - Todos los componentes emparejados y

combinados se empaquetan juntos para convertirlos en software
completo.

Software - CASE Herramientas

Las siglas 'CASE' se refieren a Computer Aided Software Engineering
(Ingeniería de Software Asistida por Computadora). Por tanto, se
refiere al desarrollo y mantenimiento de proyectos de Software con la
ayuda de varias herramientas automatizadas.

Herramienta CASE
Las herramientas CASE son un conjunto de aplicaciones informáticas,
usadas para automatizar actividades del ciclo de vida de desarrollo de
sistemas (SDLC). Las herramientas CASE son usadas por los
Directores de proyectos de software, analistas e Ingenieros para
desarrollar sistemas de software.

Hay un gran número de Herramientas CASE disponibles para

simplificar varias etapas en el desarrollo del ciclo vital del Software,
como por ejemplo herramientas de análisis, diseño de herramientas,
Gestión de proyectos de herramientas, Proyectos de gestión de
herramientas de Bases de datos, gestión de herramientas de Bases de
datos, deben nombrarse también algunas Herramientas de
Documentación.

El uso de Herramientas CASE acelera el desarrollo del proyecto con tal

de producir los resultados deseados y ayuda a encontrar
imperfecciones antes de proseguir con la siguiente etapa del desarrollo
de Software.
Componentes de las Herramientas
CASE
Las herramientas CASE se pueden dividir en las siguientes partes en
base a su uso en una etapa concreta del SDLC:

• Depósito central - Las herramientas CASE requieren un Depósito

central, el cual nos puede servir como fuente de común, consistente e
integrada información. El depósito central, es un lugar central de
almacenamiento, donde los requisitos del producto, los documentos
requeridos, los informes y diagramas relacionados, y otra información útil
sobre la gestión se almacena. El Depósito central también sirve como
Diccionario de datos.
 • Herramientas Upper CASE - Las Herramientas Upper CASE se usan en
las etapas de planificación, análisis y diseño del SDLC.

• Herramientas Lower CASE - Las Herramientas Lower CASE se usan en

la implementación, las pruebas y en el mantenimiento.

• Herramientas Integrated CASE - Las Herramientas Integrated CASE

son de utilidad en todas las fases del SDLC, desde la educción de
requisitos y las pruebas hasta la documentación.

La Herramientas CASE se pueden agrupar todas juntas si tienen una

funcionalidad similar, y procesa actividades y la capacidad de
integrarse con otras Herramientas.

Alcance de las herramientas CASE

Alcance de las herramientas CASE recorre el SDLC.

Tipos de Herramientas CASE

Ahora veremos de manera breve varios casos de herramientas CASE

Herramienta CASE Diagrama

Estas herramientas se usan para representar componentes del
sistema, datos, y a controlar la fluidez de varios componentes y
estructura del software de manera gráfica. Por ejemplo, la
herramienta 'Flow Chart Maker' para crear los más novedosos
Diagramas de flujos.

Herramientas para modelado de procesos

El modelado de procesos es un método para crear modelos de proceso
de software y se usa para desarrollar el software. Las herramientas
para el modelado de procesos ayudan a los Directores a escoger un
modelo de proceso o para modificarlo según los requerimientos del
producto software. Por ejemplo, el 'EPF Composer'

Herramientas de administración de procesos

Estas herramientas se usan para la planificación del proyecto, el coste
y esfuerzo estimados, la temporalización y la organización de los
recursos. Los Directivos deben coordinar de manera muy estricta la
ejecución del proyecto con cada uno de los pasos mencionados con
anterioridad para la buena gestión del proyecto software.
Herramientas de administración de procesos ayudan a almacenar y a
compartir información sobre el proyecto en tiempo real durante su
organización. Ejemplos de este tipo de herramienta son 'Creative Pro
Office', 'Trac Project', o 'Basecamp'.

Herramientas de documentación
La documentación de un proyecto de software empieza antes que el
proceso de software, pasa por todas las fases del SDLC y se concluye
con la terminación del proyecto.

Las Herramientas de documentación generan documentos tanto para

el consumidor final como para consumidores de soporte técnico. Estos
últimos son en su mayoría profesionales internos del equipo de
desarrollo que consultan manuales de sistemas, manuales de
referencia, manuales de formación, de instalación, etc. El consumidor
final describe el funcionamiento e instrucciones del sistema como por
ejemplo el manual para el usuario. Ejemplos de este tipo de
herramientas son: Doxygen, DrExplain, Adobe RoboHelp para
documentación.

Herramientas de análisis
Estas herramientas ayudan a cumplir con los requisitos, de manera
automática examinan si hay alguna inconsistencia, o informaciones no
acuradas en los diagramas, buscan posibles redundancias u omisiones
erróneas. Ejemplos de este tipo de herramienta son Accept 360,
Accompa, CaseComplete para análisis de requisitos, y Visible Analysts
para análisis total.

Herramientas de diseño
Estas herramientas ayudan a los diseñadores de software a crear la
estructura de los programas, la cual se puede más adelante desglosar
en pequeños módulos usando técnicas de perfeccionamiento. Estas
herramientas aportan los detalles de cada módulo y la interconexión
presente entre estos. Un ejemplo de herramienta puede ser el diseño
animado de software

Herramientas para la gestión de la

Configuración
Un ejemplo de software se lanza al mercado en una versión. Las
Herramientas para la gestión de la Configuración se ocupa de ello –

• Control de versiones

• Línea base
 • Gestión del control de cambios

Las herramientas CASE ayudan en esto usando un rastreo automático,

control de versiones y gestión de versiones. Por ejemplo, Fossil, Git,
Accu REV.

Herramientas de control de cambios

Estas herramientas son consideradas como una parte de la
configuración en la gestión de herramientas. Se ocupan de los cambios
hechos en el software después de que se haya fijado su línea de base,
o cuando el software se lanza por primera vez al mercado. Las
herramientas CASE automatizan la opción 'resaltar cambios', la
gestión de archivos, la gestión del código, entre otros. También ayuda
a ejecutar el cambio de principios en que se basa la organización.

Programming Tools
These tools consist of programming environments like IDE (Integrated
Development Environment), in-built modules library and simulation
tools. These tools provide comprehensive aid in building software
product and include features for simulation and testing. For example,
Cscope to search code in C, Eclipse.

Herramientas de desarrollo de software

El modelo de prototipo en Ingeniería de software, es una versión
simulada del producto software que se intenta conseguir. Este
prototipo da una idea inicial del producto y simula algunos aspectos
del producto real.

Las Herramientas de modelos de prototipo CASEP, esencialmente

vienen con bibliotecas gráficas. Pueden crear interfaces de usuario
independientes del hardware y diseño. Estas herramientas nos ayudan
a construir prototipos rápidos basados en información ya existente.
Además, producen prototipos de simulación de software. Por ejemplo,
Serena prototype composer, Mockup Builder.

Herramientas de desarrollo Web

Estas herramientas ayudan en el diseño de páginas Web con todos los
elementos relacionados como impresos, textos, secuencias de
comando, gráficos y demás. Las herramientas Web también producen
una vista preliminar en directo de lo que se está desarrollando y cómo
será una vez terminado. Por ejemplo, Fontello, Adobe Edge Inspect,
Foundation 3, Brackets.

Herramientas de Aseguramiento de la calidad

El aseguramiento de la calidad de una organización de Software es la
supervisión del proceso de Ingeniería y de los métodos adoptados para
desarrollar el producto software con tal de asegurar conformidad con
la calidad según los estándares organizativos. Las herramientas de
Aseguramiento de la calidad, constan de herramientas de control de
cambios y configuración y de herramientas para pruebas de software.
Por ejemplo, SoapTest, AppsWatch, JMeter.

Herramientas de mantenimiento
El mantenimiento del Software incluye modificaciones en el producto
software después de ser distribuido. Algunas de las herramientas
CASE que ayudan en la organización y la fase de mantenimiento del
software del SDLC son las técnicas de inicio automático y de reporte
de error, producción automática de etiqueta de error y de Análisis de
Causa Raíz (ACR o RCA en sus siglas en inglés). Por ejemplo, Bugzilla
para seguimiento de defectos, HP Quality Center.

Preguntas para entrevistas de

Ingeniería de Software
Queridos lectores, estas Preguntas para entrevistas de
Ingeniería de Software han sido especialmente diseñadas para
darles a conocer la naturaleza de las preguntas que pueden
encontrarse durante su entrevista en la materia de Ingeniería de
Software. Por mi experiencia, les diré que los buenos entrevistadores
difícilmente suelen planificar preguntas durante sus entrevistas,
normalmente las preguntas suelen empezar con conceptos básicos
sobre la materia y más tarde continúan basándose en la conversación
y las respuestas que van apareciendo:

Q. ¿Qué es el software de un ordenador?

A. El software de un ordenador es un completo paquete, que incluye
programas de software, y documentación y guía del usuario para
saber cómo usarlo.

Q. ¿Qué diferencias hay entre el software de un ordenador y

un programa de ordenador?

A. Un programa de ordenador es una parte del código de

programación, el cual crea tareas bien definidas. En cambio el
software incluye código de programación, y su documentación y guía
del usuario.

Q. ¿Qué es la Ingeniería de software?

A. La Ingeniería de Software es una rama de la Ingeniería asociada al

desarrollo de sistemas de software.

Q. Si ya se sabe programación, ¿Por qué es necesario aprender

conceptos de Ingeniería de Software?

A. Un persona que sabe construir una pared, quizá no pueda construir

una casa entera. Del mismo modo, una persona que quiere escribir
programas quizá no conozca otros conceptos de Ingeniería
informática. Los conceptos de Ingeniería informática guían a
programadores a evaluar los requisitos del consumidor final, a diseñar
algoritmos antes de empezar con la codificación, a codificar
programas, a evaluar lenguajes de software y su documentación.

Q. ¿Qué significan 'proceso de Software' y 'Ciclo de vida del

desarrollo Software (SDLC)'?

A. El ciclo de vida del desarrollo del Software, o proceso software es

el desarrollo sistemático siguiendo cada etapa del proceso de
desarrollo: Recogida de requisitos, Análisis del sistema, Diseño,
Codificación, evaluación, mantenimiento y documentación (en este
orden).

Q. ¿Qué modelos disponibles existen de SDLC?

A. Hay muchos modelos disponibles de SDLC, algunos ejemplos son:

el modelo de cascada, el modelo de repetición, el modelo en espiral,
el modelo V, el modelo 'Big Bang', etc.

Q. ¿Cuáles son las fases del SDLC?

A. Las fases genéricas del SDLC son: Recolección de requisitos,
análisis de sistema y diseño, Codificación, evaluación e
implementación. Las fases dependerán del modelo que escojamos
para desarrollar el software.

Q. ¿Qué modelo de SDLC es el mejor?

A. Los modelos SDLC se escogen según los requisitos del proceso de

desarrollo. El modelo más recomendable Puede variar de software a
software.

Podemos seleccionar los mejores modelos de SDLC si las siguientes

preguntas se contestan de manera satisfactoria -

• ¿El SDLC es recomendable para implementar el software en las

seleccionadas tecnologías?

• ¿El SDLC es apropiado para los requisitos y prioridades del cliente?

• ¿El modelo de SDLC es recomendable para el tamaño y la complejidad

del software?

• ¿El modelo de SDLC es recomendable para el tipo de proyecto e

Ingeniería que realizaremos?

• ¿El modelo de SDLC es apropiado a nivel geográfico para los

desarrolladores?

Q. ¿Qué es 'Gestión de un proyecto software'?

A. La Gestión de un proyecto software es un proceso donde se

gestionan todas las actividades como el tiempo, costes y gestión de
calidad que se dan en el desarrollo de un software.

Q. ¿Quién es el Director de un proyecto software?

A. El Director de un proyecto software es la persona que se

responsabiliza de llevar a cabo el proyecto software.

Q. ¿Cuáles son las tareas que debe hacer el Director de un

proyecto software?

A. El Director de un proyecto Software se ocupa de las actividades de

gestión del software. Es responsable de la planeación, de monitorear
el proceso, de la comunicación entre stakeholders (quienes pueden
afectar o son afectados por las actividades de una empresa), de la
gestión de riesgos y recursos, y de la satisfactoria ejecución de todo
el desarrollo y entrega del proyecto teniendo en cuenta las
limitaciones de tiempo, coste y calidad.

Q. ¿Qué es el 'scope' de software?

A. Es un límite bien definido, que incluye todas las actividades que se

hacen con la finalidad de desarrollar y entregar el producto software.

El scope del software define de manera clara todas las funcionalidades

y artefactos que serán entregadas como parte del software. El scope
identifica lo que hará o no hará el producto final, y lo que contendrá o
no.

Q. ¿Qué es la estimación del proyecto?

A. Es un proceso donde se estiman varios aspectos del producto

software, con tal de calcular el coste de desarrollo en cuanto a
esfuerzos, tiempo y recursos. Esta estimación puede obtenerse a raíz
de experiencias anteriores, consultando o usando fórmulas definidas
previamente.

Q. ¿Cómo podemos obtener el tamaño del producto software?

A. El tamaño del producto se puede calcular usando uno de estos dos

métodos -

• Contando las líneas del código entregado

• Contando los puntos de función entregados

Q. ¿Qué son los puntos de función?

A. Los puntos de función son las diversas características producidas

por el producto software. Se consideran como una unidad de medida
para el tamaño del software.

Q. ¿Cuáles son las técnicas de estimación de software

disponibles?

A. Hay muchas técnicas disponibles. Las más usadas son -

• Técnica de descomposición (Recuento de líneas y puntos de función)

• Técnica empírica (Putnam y COCOMO).

Q. ¿Qué es Línea de base?

A. La línea de base es una medida que define la integridad de una

fase. Cuando se completan todas las actividades asociadas a una fase
concreta, la fase se considera terminada y actúa como línea de base
para la siguiente fase.

Q. ¿Qué es Gestión de la configuración de un Software?

A. La Gestión de la configuración de un Software es un proceso de

control y seguimiento de los cambios en el software en cuanto a
requisitos, diseño, funciones, y desarrollo del producto.

Q. ¿Qué es el control de cambio?

A. El control de cambio es una función de la Gestión de la

configuración, la cual asegura que todos los cambios que se hagan
sobre el sistema de software sean consistentes y hechos siguiendo
ciertas normas y regulaciones de organización.

Q. ¿Cómo se puede medir la ejecución del proyecto?

A. Puede medirse a través del monitoreo de actividad, el informe de

actualización, Lista de control Milestone (Milestone checklist).

Q. Mencione algunas herramientas de gestión de proyectos.

A. Hay varias herramientas para gestión de proyectos usadas según

los requisitos del proyecto y las normas de organización. Entre ellas
se incluyen: El esquema Gantt, el esquema PERT, el histograma de
recursos, el método de la ruta crítica o del camino crítico, El estado de
las pruebas, etc.

Q. ¿Qué son los requisitos Software?

A. Los requisitos Software son descripciones funcionales de un

sistema de software concreto. Los requisitos abarcan la descripción
del sistema de objetivos, así como de sus funcionalidades y
características. Los requisitos expresan las expectativas del sistema
por parte de los usuarios.

Q. ¿Qué significa estudio de viabilidad?

A. Es una medida para evaluar los beneficios y practicidad del

desarrollo del proyecto software. El analizador software conduce un
estudio para entender la viabilidad técnica, económica y operativa del
proyecto.
 • Económica - Recursos para el transporte, costes de formación, coste de
servicios y herramientas adicionales, y estimación general de costes y
beneficios del proyecto.

• Técnica - ¿Es posible desarrollar este sistema? Evaluar la idoneidad de

máquina(s) y de sistema(s) operativos en los que se ejecutará el
software, conocimientos existentes para el desarrollo, formación, y
servicios y herramientas para el proyecto.

• Operativa - ¿Es posible que la organización se adapte a los cambios

realizados siguiendo las demandas del proyecto? ¿Vale la pena resolver
el problema?

Q. ¿Cómo se pueden recolectar los requisitos?

A. Los requisitos se pueden recoger a través de entrevistas,

encuestas, Análisis de tareas, lluvia de ideas, Análisis de dominio,
prototipos, estudiando versiones de software ya existentes, y a través
de la observación.

Q. ¿Qué es SRS?

A. SRS o Software Requirement Specification (Requisitos del

software) es un documento que se hace en el proceso de recogida de
requisitos. También se considera un proceso de perfección y
documentación de requisitos.

Q. ¿Qué son los requisitos funcionales?

A. Los requisitos funcionales son características esperadas por los

usuarios del producto software que se propone.

Q. ¿Qué son los requisitos no funcionales?

A. Los requisitos no funcionales son implícitos y tienen relación con la

seguridad, actuación, interoperabilidad, costes etc.

Q. ¿Qué es medida de software?

A. La medida del Software se entiende como un proceso para

cuantificar y simbolizar varios atributos y aspectos del software.

Q. ¿Qué es métrica de software?

A. La métrica de software aporta medidas para varios aspectos del

proceso y del producto de software. Se pueden agrupar en –
 • Métrica de requisitos: Requisitos de duración, integridad...

• Métrica de producto: Líneas de código, métrica orientada al objeto,

métrica de evaluación y diseño

• Métrica de proceso: Evaluación y seguimiento del presupuesto,

temporalización, recursos humanos.

Q. ¿Qué es modularización?

A. La modularización es una técnica para dividir el sistema de software

en distintos módulos, los cuales se encargan de llevar a cabo un o más
tareas de manera independiente.

Q. ¿Qué significa concurrencia y cómo se logra en el software?

A. La concurrencia es la tendencia de eventos o acciones a ocurrir de

manera simultánea. En software, cuando dos o más procesos se
ejecutan de manera simultánea, se denominan procesos
concurrentes.

Ejemplo
Mientras usted inicia el comando de impresión y comienza a imprimir,
puede abrir una nueva aplicación.

La concurrencia, se implementa dividiendo el software en múltiples

unidades de ejecución independientes llamadas procesos e hilos de
ejecución, y ejecutándolas en paralelo.

Q. ¿Qué significa cohesión?

A. La cohesión es una medida que define el grado de interdependencia

entre los elementos del módulo.

Q. ¿Qué es acoplamiento?

A. El acoplamiento es una medida que define el nivel de

interdependencia entre los módulos de un programa.

Q. ¿Puede mencionar un ejemplo de análisis de software y de

herramientas de desempeño?

A. Hay varios ejemplos: DFDs (Data Flow Diagrams en sus siglas en

inglés, diagramas de flujo de datos en español), esquemas
estructurados, Structured English, Diccionario de datos, Diagrama
HIPO (Hierarchical Input Process Output, en sus siglas inglesas), ER
(Entity Relationship en inglés, en español relación entre entidades)
Diagramas y tablas de decisión.

Q. ¿Qué es el nivel 0 de DFD?

A. Se da cuando hay un alto nivel de abstracción, también se

denomina nivel de contexto DFD, el cual representa la totalidad del
sistema de información en un diagrama incluyendo todos los detalles.

Q. ¿Cuál es la diferencia entre structured English y

peudocódigo?

A. Structured English es el lenguaje inglés nativo usado para escribir

la estructura del módulo de un programa usando palabras clave de
lenguaje de programación, mientras que el pseudocódigo es más
similar al lenguaje de programación y usa palabras o frases en lengua
inglesa nativa para escribir partes del código.

Q. ¿Qué es un diccionario de datos?

A. El diccionario de datos, también llamado Metadato, es un

repositorio de datos sobre los datos. Se usa para organizar los
nombres y sus referencias usadas en el sistema como objetos y
archivos con su nomenclatura.

Q. ¿Qué es el diseño estructurado?

A. Es la conceptualización de un problema en varios elementos de

solución bien organizados. Se ocupa del diseño de la solución y se
basa en la estrategia ‘dividir y conquistar’.

Q. ¿Cuál es la diferencia entre el diseño orientado a la función

y el que se orienta hacia el objeto?

A. El diseño orientado a la función se comprime en varios y pequeños

sub-sistemas llamados funciones. Cada función es capaz de llevar a
cabo tareas significantes en el sistema. El diseño orientado al objeto
se centra en los objetos del mundo real que nos rodean (entidades),
así como en sus clases (categorías) y en sus métodos aplicados a
objetos (funciones).

Q. Defina de manera breve los modelos de diseño 'top-down' y

'bottom-up'.

A. El modelo Top-down (‘de arriba abajo’) empieza con una vista

general del sistema y lo descompone en unidades específicas, en
cambio el modelo bottom-up (‘de abajo arriba’) empieza con los
componentes más básicos y continúa creando componentes para
lograr alto nivel de abstracción.

Q. ¿Cuál es la base de la medida de complejidad de Halstead?

A. La medida de complejidad de Halstead’s depende de la

implementación del programa y considera autentificadores o
identificadores usados en el programa para basarse en su medición.

Q. Mencione la fórmula para calcular Ciclomática complejidad

de un programa?

A. Complejidad Ciclomática utiliza de la teoría de grafos fórmula: V

(G) = e - n + 2

Q. ¿Qué es la programación funcional?

A. La programación funcional es estilo de lenguaje de programación,

que utiliza los conceptos de función matemática. Proporciona los
medios de cálculo como funciones matemáticas, que produce
resultados con independencia del estado del programa.

Q. Diferenciar la validación y verificación?

A. Comprobaciones de validación si el producto está hecho de acuerdo

a los requerimientos del usuario, mientras que las revisiones de
verificación si se siguen los pasos adecuados para desarrollar el
producto.

Validación confirma el producto adecuado y verificación confirma si el

producto está construido de una manera correcta.

Q. ¿Qué es negro-caja y pruebas de caja-blanca?

A. Negro-box prueba comprueba si se producen los resultados

deseados cuando se dan los valores de entrada válidos. No verifica la
aplicación efectiva del programa.

De caja-blanca pruebas no sólo comprueba la salida deseada y válida

cuando se proporciona una entrada válida sino también comprueba si
el código se aplica correctamente.

Criterios Pruebas de Caja- Pruebas de

Negro Caja-Blanca
El conocimiento del programa de No Sí
software, el diseño y la estructura
esencial

El conocimiento de software esencial No Sí

Implementación

Who conducts this test on software Software Testing Software

Employee Developer

base de referencia para el probador Especificaciones Diseño y

requisitos estructura de
datos

Q. ¿La garantía de calidad vs. Control de Calidad?

A. Aseguramiento de la Calidad supervisa para comprobar si el

proceso adecuado es seguido mientras que el software el desarrollo
del software.

Control de Calidad se ocupa de mantener la calidad de producto de

software.

Q. ¿Cuáles son los distintos tipos de mantenimiento del

software?

A. Tipos de mantenimiento son: correctivo, adaptativo, perfectivo y

preventiva.

• correctivo

Extracción de errores descubiertos por los usuarios

• Adaptado

hacer frente a los cambios en el entorno de hardware y software, donde

funciona el software

• Mantenimiento perfectivo

la implementación de cambios en los requisitos existentes o nuevas de

usuario

• El mantenimiento preventivo
 Tomar las medidas apropiadas para evitar problemas en el futuro

Q. ¿Qué es el software de reingeniería?

A. Software re-ingeniería es el proceso para actualizar la tecnología

en la que el software se construye sin cambiar la funcionalidad del
software. Esto se hace con el fin de mantener el software en sintonía
con la última tecnología.

Q. ¿Cuáles son las herramientas CASE?

A. CASE significa Computer Aided Software Engineering.

Herramientas CASE son un conjunto de programas de aplicaciones de
software automatizadas, que se utilizan para apoyar, acelerar y
suavizar las actividades SDLC.

¿Cuál es siguiente?.
Además, usted puede ir a través de sus asignaciones anteriores que
has hecho con el tema y asegurarse de que son capaces de hablar con
confianza en ellos. Si usted es más fresco luego entrevistador no
espera que usted contestará preguntas muy complejas, y no tienes
que hacer que sus conceptos básicos muy fuerte.

En segundo lugar, que realmente no importa mucho si usted no podría

responder algunas preguntas, pero es importante que cualquiera que
sea su respuesta, usted debe haber respondido con confianza. Por lo
que sienten confianza durante la entrevista. Nosotros en tutorialspoint
desea mejor suerte de tener un buen entrevistador y todo lo mejor
para su futuro emprendimiento. Saludos:-)