Contenido

Inicio de Ingeniería de Software

Descripción general de ingeniería de software
Ciclo de vida del desarrollo de programas
Gestión de proyectos de software
Requisitos de Software
Conceptos básicos de diseño de software
Herramientas de análisis y diseño
Estrategias de diseño de software
Diseño de interfaz de usuario de software
Complejidad del diseño de software
Implementación de software
Descripción general de las pruebas de software
Mantenimiento del software
Descripción general de herramientas CASE
 Descripción general de ingeniería de
software
Primero, comprendamos qué representa la ingeniería de software. El término
se compone de dos palabras, software e ingeniería.
El software es más que un simple código de programa. Un programa es un
código ejecutable, que sirve para algún propósito computacional. El software
se considera una colección de código de programación ejecutable, bibliotecas
asociadas y documentación. El software, cuando se hace para un requisito
específico, se llama producto de software.
La ingeniería, por otro lado, se trata de desarrollar productos, utilizando
principios y métodos científicos bien definidos.

La ingeniería de software es una rama de ingeniería asociada con el

desarrollo de productos de software utilizando principios, métodos y
procedimientos científicos bien definidos. El resultado de la ingeniería de
software es un producto de software eficiente y confiable.

Definiciones
IEEE define la ingeniería de software como:
(1) La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo,
operación y mantenimiento de software; es decir, la aplicación de la ingeniería al
software.
(2) El estudio de enfoques como en la declaración anterior.
Fritz Bauer, un informático alemán, define la ingeniería de software como:
La ingeniería de software es el establecimiento y uso de principios sólidos de ingeniería
para obtener económicamente un software que sea confiable y funcione de manera
eficiente en máquinas reales.

Evolución del software

El proceso de desarrollo de un producto de software utilizando principios y
métodos de ingeniería de software se conoce como evolución de
software. Esto incluye el desarrollo inicial del software y su mantenimiento y
actualizaciones, hasta que se desarrolle el producto de software deseado, que
satisfaga los requisitos esperados.

La evolución comienza desde el proceso de recopilación de

requisitos. Después de lo cual los desarrolladores crean un prototipo del
software previsto y lo muestran a los usuarios para obtener sus comentarios
en la etapa inicial del desarrollo del producto de software. Los usuarios
sugieren cambios, en los que varias actualizaciones consecutivas y
mantenimiento continúan cambiando también. Este proceso cambia al
software original, hasta que se logra el software deseado.
Incluso después de que el usuario haya deseado tener el software disponible,
la tecnología avanzada y los requisitos cambiantes obligan al producto de
software a cambiar en consecuencia. Volver a crear software desde cero y ser
uno a uno con los requisitos no es factible. La única solución factible y
económica es actualizar el software existente para que cumpla con los últimos
requisitos.

Leyes de evolución del software

Lehman ha dado leyes para la evolución del software. Dividió el software en
tres categorías diferentes:

 Tipo S (tipo estático): este es un software que funciona estrictamente de acuerdo

con especificaciones y soluciones definidas . La solución y el método para lograrlo,
ambos se entienden inmediatamente antes de la codificación. El software de tipo s
 está menos sujeto a cambios, por lo tanto, este es el más simple de todos. Por
ejemplo, programa de calculadora para cálculo matemático.
 Tipo P (tipo práctico): este es un software con una colección
de procedimientos. Esto se define exactamente por lo que pueden hacer los
procedimientos. En este software, se pueden describir las especificaciones, pero la
solución no es obvia al instante. Por ejemplo, software de juegos.
 Tipo E (tipo incrustado): este software funciona estrechamente como un requisito
del entorno del mundo real . Este software tiene un alto grado de evolución, ya que
hay varios cambios en las leyes, impuestos, etc. en las situaciones del mundo
real. Por ejemplo, software de comercio en línea.

Evolución del software E-Type

Lehman ha dado ocho leyes para la evolución del software E-Type:

 Cambio continuo: un sistema de software de tipo E debe continuar adaptándose

a los cambios del mundo real; de lo contrario, será cada vez menos útil.
 Complejidad creciente: a medida que evoluciona un sistema de software de tipo
E, su complejidad tiende a aumentar a menos que se trabaje para mantenerlo o
reducirlo.
 Conservación de la familiaridad: la familiaridad con el software o el conocimiento
sobre cómo se desarrolló, por qué se desarrolló de esa manera particular, etc.,
debe mantenerse a cualquier costo para implementar los cambios en el sistema.
 Crecimiento continuo: para un sistema de tipo E destinado a resolver algunos
problemas comerciales, su tamaño de implementación de los cambios crece de
acuerdo con los cambios en el estilo de vida de la empresa.
 Reducción de la calidad: un sistema de software tipo E disminuye su calidad a
menos que se mantenga rigurosamente y se adapte a un entorno operativo
cambiante.
 Sistemas de retroalimentación: los sistemas de software de tipo E constituyen
sistemas de retroalimentación de múltiples niveles y múltiples bucles y deben
tratarse como tales para ser modificados o mejorados con éxito.
 Autorregulación: los procesos de evolución del sistema de tipo E se autorregulan
con la distribución de productos y medidas de proceso cercanas a lo normal.
 Estabilidad organizacional: la tasa de actividad global efectiva promedio en un
sistema de tipo E en evolución es invariable durante la vida útil del producto.
www.postparaprogramadores.com
/
 Síguenos en Instagram para que estés al tanto de los
nuevos libros de programación. Click aqui

Paradigmas de software
Los paradigmas de software se refieren a los métodos y pasos que se toman
al diseñar el software. Hay muchos métodos propuestos y están en
funcionamiento hoy, pero necesitamos ver en qué parte de la ingeniería del
software se encuentran estos paradigmas. Estos se pueden combinar en
varias categorías, aunque cada una de ellas está contenida entre sí:

El paradigma de programación es un subconjunto del paradigma de diseño de

software que además es un subconjunto del paradigma de desarrollo de
software.

Paradigma de desarrollo de software

Este paradigma se conoce como paradigmas de ingeniería de software donde

se aplican todos los conceptos de ingeniería relacionados con el desarrollo de
software. Incluye varias investigaciones y recopilación de requisitos que
ayudan a construir el producto de software. Consiste en -
  Recopilación de requisitos
 Diseño de software
 Programación

Paradigma de diseño de software

Este paradigma es parte del desarrollo de software e incluye:

 Diseño
 Mantenimiento
 Programación

Paradigma de programación

Este paradigma está estrechamente relacionado con el aspecto de

programación del desarrollo de software. Esto incluye -

 Codificación
 Pruebas
 Integración

Necesidad de ingeniería de software

La necesidad de la ingeniería de software surge debido a la mayor tasa de
cambio en los requisitos del usuario y el entorno en el que está trabajando el
software.

 Software grande: es más fácil construir un muro que una casa o edificio, del
mismo modo, ya que el tamaño del software se convierte en una gran ingeniería
que tiene que avanzar para darle un proceso científico.
 Escalabilidad: si el proceso del software no se basara en conceptos científicos y
de ingeniería, sería más fácil recrear un nuevo software que escalar uno existente.
 Costo: a medida que la industria del hardware ha demostrado sus habilidades y la
gran fabricación ha bajado el precio de la computadora y el hardware
electrónico. Pero el costo del software sigue siendo alto si no se adapta el proceso
adecuado.
 Naturaleza dinámica: la naturaleza siempre creciente y adaptable del software
depende en gran medida del entorno en el que trabaja el usuario. Si la naturaleza
del software siempre está cambiando, se deben realizar nuevas mejoras en la
existente. Aquí es donde la ingeniería de software juega un buen papel.
 Gestión de calidad: un mejor proceso de desarrollo de software proporciona un
producto de software mejor y de calidad.

Características del buen software.

Un producto de software se puede juzgar por lo que ofrece y qué tan bien se
puede usar. Este software debe satisfacer los siguientes motivos:

 Operacional
  Transicional
 Mantenimiento
Se espera que el software bien diseñado y diseñado tenga las siguientes
características:

Operacional

Esto nos dice qué tan bien funciona el software en las operaciones. Se puede
medir en:

 Presupuesto
 Usabilidad
 Eficiencia
 Exactitud
 Funcionalidad
 Confianza
 Seguridad
 La seguridad

Transicional

Este aspecto es importante cuando el software se mueve de una plataforma a

otra:

 Portabilidad
 Interoperabilidad
 Reusabilidad
 Adaptabilidad

Mantenimiento

Este aspecto resume qué tan bien un software tiene las capacidades para
mantenerse en el entorno siempre cambiante:

 Modularidad
 Mantenibilidad
 Flexibilidad
 Escalabilidad
En resumen, la ingeniería de software es una rama de la informática, que
utiliza conceptos de ingeniería bien definidos necesarios para producir
productos de software eficientes, duraderos, escalables, dentro del
presupuesto y a tiempo.

Ciclo de vida del desarrollo de programas

Software Development Life Cycle, SDLC para abreviar, es una secuencia bien
estructurada y estructurada de etapas en ingeniería de software para
desarrollar el producto de software previsto.

Actividades SDLC
SDLC proporciona una serie de pasos a seguir para diseñar y desarrollar un
producto de software de manera eficiente. El marco SDLC incluye los
siguientes pasos:

Comunicación

Este es el primer paso donde el usuario inicia la solicitud de un producto de

software deseado. Se pone en contacto con el proveedor de servicios e intenta
negociar los términos. Presenta su solicitud a la organización proveedora de
servicios por escrito.

Recopilación de requisitos

En este paso, el equipo de desarrollo de software trabaja para llevar a cabo el

proyecto. El equipo mantiene conversaciones con varias partes interesadas
del dominio del problema y trata de sacar tanta información como sea posible
sobre sus requisitos. Los requisitos se contemplan y segregan en requisitos de
usuario, requisitos del sistema y requisitos funcionales. Los requisitos se
recopilan utilizando una serie de prácticas como se indica:

 estudiando el sistema y el software existentes u obsoletos,

 realización de entrevistas a usuarios y desarrolladores,
 refiriéndose a la base de datos o
 recolectando respuestas de los cuestionarios.

Estudio de factibilidad

Después de reunir los requisitos, el equipo elabora un plan aproximado de

proceso de software. En este paso, el equipo analiza si se puede hacer que un
software cumpla con todos los requisitos del usuario y si existe alguna
posibilidad de que el software deje de ser útil. Se descubre si el proyecto es
financieramente, práctica y tecnológicamente factible para que la organización
lo tome en cuenta. Hay muchos algoritmos disponibles, que ayudan a los
desarrolladores a concluir la viabilidad de un proyecto de software.

Análisis del sistema

En este paso, los desarrolladores deciden una hoja de ruta de su plan e

intentan presentar el mejor modelo de software adecuado para el proyecto. El
análisis del sistema incluye la comprensión de las limitaciones del producto de
software, los problemas relacionados con el sistema de aprendizaje o los
cambios que se deben realizar de antemano en los sistemas existentes,
identificar y abordar el impacto del proyecto en la organización y el personal,
etc. El equipo del proyecto analiza el alcance del proyecto y planifica el
cronograma y recursos en consecuencia.

Diseño de software

El siguiente paso es reducir el conocimiento completo de los requisitos y el

análisis en el escritorio y diseñar el producto de software. Las entradas de los
usuarios y la información recopilada en la fase de recopilación de requisitos
son las entradas de este paso. El resultado de este paso viene en forma de
dos diseños; Diseño lógico y diseño físico. Los ingenieros producen metadatos
y diccionarios de datos, diagramas lógicos, diagramas de flujo de datos y, en
algunos casos, pseudocódigos.

Codificación

Este paso también se conoce como fase de programación. La implementación

del diseño del software comienza en términos de escribir código de programa
en el lenguaje de programación adecuado y desarrollar programas ejecutables
sin errores de manera eficiente.

Pruebas
Una estimación dice que el 50% de todo el proceso de desarrollo de software
debe ser probado. Los errores pueden arruinar el software desde el nivel
crítico hasta su propia eliminación. Los desarrolladores realizan las pruebas de
software mientras los desarrolladores codifican y los expertos realizan pruebas
exhaustivas en varios niveles de código, como pruebas de módulos, pruebas
de programas, pruebas de productos, pruebas internas y pruebas del producto
al final del usuario. El descubrimiento temprano de errores y su solución es la
clave para un software confiable.

Integración

Es posible que el software deba integrarse con las bibliotecas, bases de datos
y otros programas. Esta etapa de SDLC está involucrada en la integración de
software con entidades del mundo exterior.

Implementación

Esto significa instalar el software en las máquinas de los usuarios. A veces, el

software necesita configuraciones posteriores a la instalación al final del
usuario. El software se prueba para portabilidad y adaptabilidad y los
problemas relacionados con la integración se resuelven durante la
implementación.

Operación y mantenimiento

Esta fase confirma la operación del software en términos de mayor eficiencia y

menos errores. Si es necesario, los usuarios reciben capacitación o se les
ayuda con la documentación sobre cómo operar el software y cómo
mantenerlo operativo. El software se mantiene a tiempo actualizando el código
de acuerdo con los cambios que tienen lugar en el entorno o la tecnología del
usuario final. Esta fase puede enfrentar desafíos de errores ocultos y
problemas no identificados del mundo real.

Disposición

A medida que transcurre el tiempo, el software puede disminuir en el frente de

rendimiento. Puede quedar completamente obsoleto o puede necesitar una
intensa actualización. Por lo tanto, surge una necesidad apremiante de
eliminar una parte importante del sistema. Esta fase incluye el archivo de
datos y los componentes de software necesarios, el cierre del sistema, la
planificación de la actividad de disposición y la terminación del sistema en el
momento adecuado de finalización del sistema.

Paradigma de desarrollo de software

El paradigma de desarrollo de software ayuda al desarrollador a seleccionar
una estrategia para desarrollar el software. Un paradigma de desarrollo de
software tiene su propio conjunto de herramientas, métodos y procedimientos,
que se expresan claramente y definen el ciclo de vida del desarrollo de
software. Algunos de los paradigmas de desarrollo de software o modelos de
proceso se definen de la siguiente manera:

Modelo de cascada

El modelo de cascada es el modelo más simple del paradigma de desarrollo

de software. Dice que todas las fases de SDLC funcionarán una tras otra de
manera lineal. Es decir, cuando finaliza la primera fase, solo se iniciará la
segunda fase y así sucesivamente.

Este modelo supone que todo se lleva a cabo y se lleva a cabo perfectamente
según lo planeado en la etapa anterior y no hay necesidad de pensar en los
problemas pasados que pueden surgir en la siguiente fase. Este modelo no
funciona sin problemas si quedan algunos problemas en el paso anterior. La
naturaleza secuencial del modelo no nos permite regresar y deshacer o
rehacer nuestras acciones.
Este modelo es más adecuado cuando los desarrolladores ya han diseñado y
desarrollado software similar en el pasado y conocen todos sus dominios.

Modelo iterativo

Este modelo lidera el proceso de desarrollo de software en

iteraciones. Proyecta el proceso de desarrollo de manera cíclica repitiendo
cada paso después de cada ciclo del proceso SDLC.
El software se desarrolló primero a muy pequeña escala y se siguen todos los
pasos que se tienen en cuenta. Luego, en cada próxima iteración, se diseñan,
codifican, prueban y agregan más funciones y módulos al software. Cada ciclo
produce un software, que es completo en sí mismo y tiene más características
y capacidades que el anterior.
Después de cada iteración, el equipo de gestión puede trabajar en la gestión
de riesgos y prepararse para la próxima iteración. Debido a que un ciclo
incluye una pequeña porción de todo el proceso de software, es más fácil
administrar el proceso de desarrollo, pero consume más recursos.

Modelo espiral

El modelo espiral es una combinación de ambos, el modelo iterativo y uno del

modelo SDLC. Puede verse como si elige un modelo SDLC y lo combina con
un proceso cíclico (modelo iterativo).
Este modelo considera el riesgo, que a menudo pasa desapercibido para la
mayoría de los otros modelos. El modelo comienza con la determinación de
objetivos y limitaciones del software al comienzo de una iteración. La siguiente
fase es la creación de prototipos del software. Esto incluye análisis de
riesgos. Luego se usa un modelo SDLC estándar para construir el
software. En la cuarta fase del plan de la próxima iteración se prepara.

V - modelo

El principal inconveniente del modelo de cascada es que pasamos a la

siguiente etapa solo cuando la anterior está terminada y no hubo posibilidad
de volver si algo se encuentra mal en etapas posteriores. V-Model proporciona
medios para probar el software en cada etapa de manera inversa.
En cada etapa, se crean planes de prueba y casos de prueba para verificar y
validar el producto de acuerdo con los requisitos de esa etapa. Por ejemplo,
en la etapa de recopilación de requisitos, el equipo de prueba prepara todos
los casos de prueba en correspondencia con los requisitos. Más tarde, cuando
el producto se desarrolla y está listo para la prueba, los casos de prueba de
esta etapa verifican el software contra su validez para cumplir con los
requisitos en esta etapa.
Esto hace que tanto la verificación como la validación vayan en paralelo. Este
modelo también se conoce como modelo de verificación y validación.

Modelo Big Bang

Este modelo es el modelo más simple en su forma. Requiere poca

planificación, mucha programación y muchos fondos. Este modelo está
conceptualizado en torno a la gran explosión del universo. Como dicen los
científicos, después del Big Bang, muchas galaxias, planetas y estrellas
evolucionaron como un evento. Del mismo modo, si reunimos mucha
programación y fondos, puede lograr el mejor producto de software.
Para este modelo, se requiere una cantidad muy pequeña de planificación. No
sigue ningún proceso o, en ocasiones, el cliente no está seguro de los
requisitos y las necesidades futuras. Por lo tanto, los requisitos de entrada son
arbitrarios.
Este modelo no es adecuado para grandes proyectos de software, pero es
bueno para aprender y experimentar.
Para una lectura en profundidad sobre SDLC y sus diversos modelos, haga
clic aquí.

Gestión de proyectos de software

El patrón de trabajo de una empresa de TI dedicada al desarrollo de software
puede verse dividido en dos partes:

 Creación de software
 Gestión de proyectos de software
Un proyecto es una tarea bien definida, que es una colección de varias
operaciones realizadas para lograr un objetivo (por ejemplo, desarrollo y
entrega de software). Un proyecto puede caracterizarse como:

 Cada proyecto puede tener un objetivo único y distinto.

 El proyecto no es una actividad de rutina u operaciones cotidianas.
 El proyecto viene con una hora de inicio y una hora de finalización.
 El proyecto termina cuando se logra su objetivo, por lo tanto, es una fase temporal
en la vida útil de una organización.
 El proyecto necesita recursos adecuados en términos de tiempo, mano de obra,
finanzas, material y banco de conocimiento.

Proyecto de software
Un proyecto de software es el procedimiento completo de desarrollo de
software, desde la recopilación de requisitos hasta las pruebas y el
mantenimiento, realizado de acuerdo con las metodologías de ejecución, en
un período de tiempo específico para lograr el producto de software previsto.
Necesidad de gestión de proyectos de software.
Se dice que el software es un producto intangible. El desarrollo de software es
una especie de flujo completamente nuevo en los negocios mundiales y hay
muy poca experiencia en la creación de productos de software. La mayoría de
los productos de software están hechos a medida para satisfacer los requisitos
del cliente. Lo más importante es que la tecnología subyacente cambia y
avanza con tanta frecuencia y rapidez que la experiencia de un producto
puede no aplicarse al otro. Todas estas restricciones comerciales y
ambientales conllevan riesgos en el desarrollo de software, por lo tanto, es
esencial administrar los proyectos de software de manera eficiente.

La imagen de arriba muestra restricciones triples para proyectos de

software. Es una parte esencial de la organización del software entregar
productos de calidad, mantener el costo dentro de las restricciones
presupuestarias del cliente y entregar el proyecto según lo programado. Hay
varios factores, tanto internos como externos, que pueden afectar este
triángulo de triple restricción. Cualquiera de los tres factores puede afectar
severamente a los otros dos.
Por lo tanto, la gestión de proyectos de software es esencial para incorporar
los requisitos del usuario junto con las limitaciones de presupuesto y tiempo.

Gerente de proyectos de software

Un gerente de proyecto de software es una persona que asume la
responsabilidad de ejecutar el proyecto de software. El administrador de
proyectos de software conoce perfectamente todas las fases de SDLC por las
que pasaría el software. El gerente de proyecto nunca puede involucrarse
directamente en la producción del producto final, pero controla y administra las
actividades involucradas en la producción.
Un gerente de proyecto monitorea de cerca el proceso de desarrollo, prepara y
ejecuta varios planes, organiza los recursos necesarios y adecuados,
mantiene la comunicación entre todos los miembros del equipo para abordar
los problemas de costo, presupuesto, recursos, tiempo, calidad y satisfacción
del cliente.
Veamos algunas responsabilidades que un gerente de proyecto asume:
La gestión de personas
 Actuar como líder del proyecto
 Lesión con partes interesadas
 Gestionar recursos humanos
 Configuración de jerarquía de informes, etc.

Proyecto de gestión
 Definición y configuración del alcance del proyecto
 Gestión de actividades de gestión de proyectos.
 Monitoreo de progreso y desempeño
 Análisis de riesgos en cada fase.
 Tome las medidas necesarias para evitar o salir de problemas.
 Actuar como portavoz del proyecto

Actividades de gestión de software

La gestión de proyectos de software consta de una serie de actividades, que
incluyen la planificación del proyecto, la determinación del alcance del
producto de software, la estimación del costo en varios términos, la
programación de tareas y eventos y la gestión de recursos. Las actividades de
gestión del proyecto pueden incluir:

 Planificación de proyectos
 Gestión del alcance
 Estimacion del proyecto

Planificación de proyectos
La planificación del proyecto de software es una tarea que se realiza antes de
que la producción del software realmente comience. Está allí para la
producción de software, pero no implica ninguna actividad concreta que tenga
ninguna conexión de dirección con la producción de software; más bien es un
conjunto de procesos múltiples, que facilita la producción de software. La
planificación del proyecto puede incluir lo siguiente:

Gestión del alcance

Define el alcance del proyecto; Esto incluye todas las actividades, el proceso
debe hacerse para hacer un producto de software entregable. La gestión del
alcance es esencial porque crea límites del proyecto al definir claramente lo
que se haría en el proyecto y lo que no se haría. Esto hace que el proyecto
contenga tareas limitadas y cuantificables, que pueden documentarse
fácilmente y, a su vez, evita la sobrecarga de costos y tiempo.
Durante la gestión del alcance del proyecto, es necesario:
  Definir el alcance
 Decidir su verificación y control
 Divida el proyecto en varias partes más pequeñas para facilitar la administración.
 Verificar el alcance
 Controle el alcance incorporando cambios al alcance

Estimacion del proyecto

Para una gestión efectiva es imprescindible una estimación precisa de varias
medidas. Con una estimación correcta, los gerentes pueden administrar y
controlar el proyecto de manera más eficiente y efectiva.
La estimación del proyecto puede incluir lo siguiente:

 Estimación del tamaño del software.

El tamaño del software puede estimarse en términos de KLOC (Kilo Line of Code)
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 varían según
los requisitos del usuario o del software.

 Estimación de esfuerzo
Los gerentes estiman los esfuerzos en términos de requisitos de personal y horas
hombre requeridas para producir el software. Para la estimación del esfuerzo, se
debe conocer el tamaño del software. Esto puede derivarse de la experiencia de
los gerentes, los datos históricos de la organización o el tamaño del software se
pueden convertir en esfuerzos mediante el uso de algunas fórmulas estándar.

 Estimación del tiempo

Una vez que se estiman el tamaño y los esfuerzos, se puede estimar el tiempo
requerido para producir el software. Los esfuerzos requeridos se segregan en
subcategorías según las especificaciones de requisitos y la interdependencia de
varios componentes de software. Las tareas de software se dividen en tareas,
actividades o eventos más pequeños por Work Breakthrough Structure
(WBS). Las tareas se programan día a día o en meses calendario.
La suma de tiempo requerida para completar todas las tareas en horas o días es
el tiempo total invertido para completar el proyecto.

 Estimación de costos
Esto podría considerarse como el más difícil de todos porque depende de más
elementos que cualquiera de los anteriores. Para estimar el costo del proyecto, se
requiere considerar:

o Tamaño del software

o Calidad del software
o Hardware
o Software o herramientas adicionales, licencias, etc.
o Personal calificado con habilidades específicas de la tarea.
o Viajes involucrados
o Comunicación
 o Entrenamiento y apoyo

Técnicas de estimación de proyectos

Discutimos varios parámetros relacionados con la estimación del proyecto,
como el tamaño, el esfuerzo, el tiempo y el costo.
El gerente de proyecto puede estimar los factores enumerados utilizando dos
técnicas ampliamente reconocidas:

Técnica de descomposición

Esta técnica asume el software como producto de varias composiciones.

Hay dos modelos principales:

 La estimación de la línea de código se realiza en nombre del número de líneas de

códigos en el producto de software.
 La estimación de puntos de función se realiza en nombre del número de puntos
de función en el producto de software.

Técnica de estimación empírica

Esta técnica utiliza fórmulas derivadas empíricamente para hacer

estimaciones. Estas fórmulas se basan en LOC o FP.

 Modelo de Putnam
Este modelo está hecho por Lawrence H. Putnam, que se basa en la distribución
de frecuencia de Norden (curva de Rayleigh). El modelo de Putnam asigna el
tiempo y los esfuerzos necesarios con el tamaño del software.

 COCOMO
COCOMO significa COnstructive COst MOdel, desarrollado por Barry W.
Boehm. Divide el producto de software en tres categorías de software: orgánico,
semi-separado e integrado.

Programación de proyectos
La programación del proyecto en un proyecto se refiere a la hoja de ruta de
todas las actividades que se realizarán con el orden especificado y dentro del
intervalo de tiempo asignado a cada actividad. Los gerentes de proyecto
tienden a definir varias tareas y a proyectar hitos y organizarlos teniendo en
cuenta varios factores. Buscan tareas que se encuentran en una ruta crítica en
el cronograma, que son necesarias para completar de manera específica
(debido a la interdependencia de la tarea) y estrictamente dentro del tiempo
asignado. La disposición de las tareas que se encuentra fuera de la ruta crítica
tiene menos probabilidades de impactar en todo el cronograma del proyecto.
Para programar un proyecto, es necesario:

 Divide las tareas del proyecto en una forma más pequeña y manejable
  Descubre varias tareas y correlacionalas
 Estimación del tiempo requerido para cada tarea
 Divida el tiempo en unidades de trabajo.
 Asigne un número adecuado de unidades de trabajo para cada tarea.
 Calcular el tiempo total requerido para el proyecto de principio a fin

Administracion de recursos
Todos los elementos utilizados para desarrollar un producto de software
pueden asumirse como recursos para ese proyecto. Esto puede incluir
recursos humanos, herramientas productivas y bibliotecas de software.
Los recursos están disponibles en cantidad limitada y permanecen en la
organización como un conjunto de activos. La escasez de recursos dificulta el
desarrollo del proyecto y puede retrasarse con respecto al cronograma. La
asignación de recursos adicionales aumenta el costo de desarrollo al final. Por
lo tanto, es necesario estimar y asignar recursos adecuados para el proyecto.
La gestión de recursos incluye:

 Definir el proyecto de organización adecuado creando un equipo de proyecto y

asignando responsabilidades a cada miembro del equipo
 Determinar los recursos requeridos en una etapa particular y su disponibilidad
 Administre los recursos generando solicitudes de recursos cuando sean necesarios
y desasignándolos cuando ya no sean necesarios.

Proyecto de Gestión de Riesgos

La gestión de riesgos implica todas las actividades relacionadas con la
identificación, el análisis y la provisión de riesgos predecibles y no predecibles
en el proyecto. El riesgo puede incluir lo siguiente:

 Personal experimentado que abandona el proyecto y que entra personal nuevo.

 Cambio en la gestión organizacional.
 Cambio de requisito o requisito de interpretación errónea.
 Subestimación del tiempo y los recursos requeridos.
 Cambios tecnológicos, cambios ambientales, competencia empresarial.

Proceso de gestión de riesgos

Existen las siguientes actividades involucradas en el proceso de gestión de
riesgos:

 Identificación: tome nota de todos los riesgos posibles que pueden ocurrir en el
proyecto.
 Categorizar: clasifique los riesgos conocidos en intensidad de riesgo alta, media y
baja según su posible impacto en el proyecto.
  Administrar: analiza la probabilidad de ocurrencia de riesgos en varias
fases. Haga un plan para evitar o enfrentar riesgos. Intenta minimizar sus efectos
secundarios.
 Supervisar: controle de cerca los riesgos potenciales y sus síntomas
iniciales. También controle los efectos de los pasos tomados para mitigarlos o
evitarlos.

Ejecución y Monitoreo de Proyectos

En esta fase, las tareas descritas en los planes del proyecto se ejecutan de
acuerdo con sus cronogramas.
La ejecución necesita monitoreo para verificar si todo va de acuerdo con el
plan. Monitorear es observar para verificar la probabilidad de riesgo y tomar
medidas para abordar el riesgo o informar el estado de varias tareas.
Estas medidas incluyen:

 Monitoreo de actividad: todas las actividades programadas dentro de alguna

tarea se pueden monitorear día a día. Cuando se completan todas las actividades
de una tarea, se considera completa.
 Informes de estado: los informes contienen el estado de las actividades y tareas
completadas dentro de un período de tiempo determinado, generalmente una
semana. El estado se puede marcar como terminado, pendiente o en progreso,
etc.
 Lista de verificación de hitos: cada proyecto se divide en múltiples fases en las
que se realizan tareas principales (hitos) según las fases de SDLC. Esta lista de
verificación de hitos se prepara una vez cada pocas semanas e informa el estado
de los hitos.

Gestión de comunicación de proyectos

La comunicación efectiva juega un papel vital en el éxito de un
proyecto. Cierra las brechas entre el cliente y la organización, entre los
miembros del equipo y otros interesados en el proyecto, como los proveedores
de hardware.
La comunicación puede ser oral o escrita. El proceso de gestión de la
comunicación puede tener los siguientes pasos:

 Planificación : este paso incluye las identificaciones de todos los interesados en el

proyecto y el modo de comunicación entre ellos. También considera si se requieren
medios de comunicación adicionales.
 Compartir : después de determinar varios aspectos de la planificación, el gerente
se enfoca en compartir la información correcta con la persona correcta en el
momento correcto. Esto mantiene a todos los involucrados en el proyecto
actualizados con el progreso del proyecto y su estado.
 Comentarios : los gerentes de proyectos utilizan diversas medidas y mecanismos
de comentarios y crean informes de estado y rendimiento. Este mecanismo
asegura que las aportaciones de varios interesados lleguen al gerente del proyecto
como su retroalimentación.
 Cierre : al final de cada evento importante, al final de una fase de SDLC o al final
del proyecto en sí, se anuncia formalmente el cierre administrativo para actualizar
 a todas las partes interesadas mediante el envío de un correo electrónico, la
distribución de una copia impresa del documento o por otro medio de
comunicación efectiva.
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 los
cambios en el software en términos de requisitos, diseño, funciones y
desarrollo del producto.
IEEE lo define como "el proceso de identificar y definir los elementos en el
sistema, controlar el cambio de estos elementos a lo largo de su ciclo de vida,
registrar e informar el estado de los elementos y las solicitudes de cambio, y
verificar la integridad y corrección de los elementos".
En general, una vez que se finaliza el SRS, hay menos posibilidades de que el
usuario requiera cambios. Si ocurren, los cambios se abordan solo con la
aprobación previa de la alta gerencia, ya que existe la posibilidad de que se
sobrepasen los costos y el tiempo.

Base

Se asume una fase de SDLC si está en línea de base, es decir, la línea de

base es una medida que define la integridad de una fase. Una fase se
establece como base cuando todas las actividades correspondientes están
terminadas y bien documentadas. Si no fuera la fase final, su salida se usaría
en la siguiente fase inmediata.
La gestión de la configuración es una disciplina de administración de la
organización, que se encarga de la ocurrencia de cualquier cambio (proceso,
requerimiento, tecnológico, estratégico, etc.) después de que se base una
fase. CM mantiene el control de cualquier cambio realizado en el software.

Cambio de control

El control de cambios es función de la gestión de la configuración, lo que

garantiza que todos los cambios realizados en el sistema de software sean
coherentes y se realicen de acuerdo con las normas y reglamentos de la
organización.
Un cambio en la configuración del producto pasa por los siguientes pasos:
 Identificación : una solicitud de cambio llega desde una fuente interna o
externa. Cuando la solicitud de cambio se identifica formalmente, se documenta
adecuadamente.
 Validación : se verifica la validez de la solicitud de cambio y se confirma su
procedimiento de manejo.
 Análisis : el impacto de la solicitud de cambio se analiza en términos de
cronograma, costo y esfuerzos requeridos. Se analiza el impacto general del
posible cambio en el sistema.
  Control : si el posible cambio afecta a demasiadas entidades en el sistema o es
inevitable, es obligatorio obtener la aprobación de las altas autoridades antes de
incorporar el cambio en el sistema. Se decide si vale la pena incorporar el cambio
o no. Si no es así, la solicitud de cambio se rechaza formalmente.
 Ejecución : si la fase anterior determina ejecutar la solicitud de cambio, esta fase
toma las medidas apropiadas para ejecutar el cambio, realiza una revisión
exhaustiva si es necesario.
 Cerrar solicitud : el cambio se verifica para una correcta implementación y fusión
con el resto del sistema. Este cambio recientemente incorporado en el software se
documenta adecuadamente y la solicitud se cierra formalmente.

Herramientas de gestión de proyectos

El riesgo y la incertidumbre se multiplican con respecto al tamaño del
proyecto, incluso cuando el proyecto se desarrolla de acuerdo con las
metodologías establecidas.
Hay herramientas disponibles, que ayudan a la gestión eficaz del
proyecto. Algunos se describen:

Gráfico de gantt

Los diagramas de Gantt fueron ideados por Henry Gantt (1917). Representa el
cronograma del proyecto con respecto a los períodos de tiempo. Es un gráfico
de barras horizontales con barras que representan actividades y tiempo
programado para las actividades del proyecto.

Gráfico PERT

El gráfico PERT (técnica de evaluación y revisión del programa) es una

herramienta que representa el proyecto como diagrama de red. Es capaz de
representar gráficamente los principales eventos del proyecto en forma
paralela y consecutiva. Los eventos, que ocurren uno tras otro, muestran
dependencia del evento posterior con respecto al anterior.
Los eventos se muestran como nodos numerados. Están conectados por
flechas etiquetadas que representan la secuencia de tareas en el proyecto.

Histograma de recursos

Esta es una herramienta gráfica que contiene barras o gráficos que

representan la cantidad de recursos (generalmente personal calificado)
necesarios a lo largo del tiempo para un evento (o fase) del proyecto. El
histograma de recursos es una herramienta eficaz para la planificación y
coordinación del personal.

Análisis de ruta crítica

Esta herramienta es útil para reconocer tareas interdependientes en el
proyecto. También ayuda a encontrar la ruta más corta o la ruta crítica para
completar el proyecto con éxito. Al igual que el diagrama PERT, a cada evento
se le asigna un marco de tiempo específico. Esta herramienta muestra la
dependencia del evento asumiendo que un evento puede pasar al siguiente
solo si se completa el anterior.
Los eventos se organizan de acuerdo con la hora de inicio más temprana
posible. La ruta entre el nodo inicial y el final es una ruta crítica que no se
puede reducir aún más y todos los eventos deben ejecutarse en el mismo
orden.

Requisitos de Software
Los requisitos de software son una descripción de las características y
funcionalidades del sistema de destino. Los requisitos transmiten las
expectativas de los usuarios del producto de software. Los requisitos pueden
ser obvios u ocultos, conocidos o desconocidos, esperados o inesperados
desde el punto de vista del cliente.

Ingeniería de requisitos
El proceso para reunir los requisitos de software del cliente, analizarlos y
documentarlos se conoce como ingeniería de requisitos.
El objetivo de la ingeniería de requisitos es desarrollar y mantener un
documento sofisticado y descriptivo de 'Especificación de requisitos del
sistema'.

Proceso de ingeniería de requisitos

Es un proceso de cuatro pasos, que incluye:

 Estudio de factibilidad
 Recopilación de requisitos
 Especificación de requisitos de software
 Validación de requisitos de software
Veamos el proceso brevemente:

Estudio de factibilidad

Cuando el cliente se acerca a la organización para desarrollar el producto

deseado, se le ocurre una idea aproximada sobre qué funciones debe realizar
el software y qué características se esperan del software.
En referencia a esta información, los analistas hacen un estudio detallado
sobre si el sistema deseado y su funcionalidad son factibles de desarrollar.
Este estudio de viabilidad está enfocado hacia el objetivo de la
organización. Este estudio analiza si el producto de software puede
materializarse prácticamente en términos de implementación, contribución del
proyecto a la organización, limitaciones de costos y según los valores y
objetivos de la organización. Explora aspectos técnicos del proyecto y el
producto, tales como usabilidad, mantenibilidad, productividad y capacidad de
integración.
El resultado de esta fase debe ser un informe de estudio de factibilidad que
debe contener comentarios y recomendaciones adecuadas para la
administración sobre si el proyecto debe llevarse a cabo o no.

Recopilación de requisitos

Si el informe de viabilidad es positivo para emprender el proyecto, la siguiente

fase comienza con la recopilación de los requisitos del usuario. Los analistas e
ingenieros se comunican con el cliente y los usuarios finales para conocer sus
ideas sobre qué debe proporcionar el software y qué características desean
que incluya el software.

Especificación de requisitos de software

SRS es un documento creado por el analista de sistemas después de que se

recopilan los requisitos de varias partes interesadas.
SRS define cómo el software previsto interactuará con el hardware, las
interfaces externas, la velocidad de operación, el tiempo de respuesta del
sistema, la portabilidad del software en varias plataformas, la capacidad de
mantenimiento, la velocidad de recuperación después de un bloqueo, la
seguridad, la calidad, las limitaciones, etc.
Los requisitos recibidos del cliente están escritos en lenguaje natural. Es
responsabilidad del analista de sistemas documentar los requisitos en
lenguaje técnico para que puedan ser comprendidos y útiles por el equipo de
desarrollo de software.
SRS debería tener las siguientes características:

 Los requisitos del usuario se expresan en lenguaje natural.

 Los requisitos técnicos se expresan en lenguaje estructurado, que se utiliza dentro
de la organización.
 La descripción del diseño debe escribirse en pseudocódigo.
 Formato de formularios e impresiones de pantalla GUI.
 Notaciones condicionales y matemáticas para DFD, etc.

Validación de requisitos de software

Después de desarrollar las especificaciones de requisitos, los requisitos

mencionados en este documento se validan. El usuario puede solicitar una
solución ilegal y poco práctica o los expertos pueden interpretar los requisitos
incorrectamente. Esto resulta en un gran aumento en el costo si no se corta de
raíz. Los requisitos pueden verificarse contra las siguientes condiciones:
  Si se pueden implementar prácticamente
 Si son válidos y según la funcionalidad y el dominio del software
 Si hay alguna ambigüedad
 Si están completos
 Si se pueden demostrar

Proceso de obtención de requisitos

El proceso de obtención de requisitos se puede representar utilizando el
siguiente diagrama:

 Recopilación de requisitos: los desarrolladores discuten con el cliente y los

usuarios finales y conocen sus expectativas del software.
 Requisitos de organización: los desarrolladores priorizan y organizan los
requisitos en orden de importancia, urgencia y conveniencia.
 Negociación y discusión: si los requisitos son ambiguos o existen algunos
conflictos en los requisitos de varias partes interesadas, si lo son, se negocia y
discute con las partes interesadas. Los requisitos pueden entonces ser
priorizados y razonablemente comprometidos.
Los requisitos provienen de varias partes interesadas. Para eliminar la
ambigüedad y los conflictos, se discuten para mayor claridad y corrección. Los
requisitos poco realistas se ven comprometidos razonablemente.

 Documentación: todos los requisitos formales e informales, funcionales y no

funcionales se documentan y se ponen a disposición para el procesamiento de la
próxima fase.

Técnicas de obtención de requisitos

La obtención de requisitos es el proceso para conocer los requisitos para un
sistema de software previsto mediante la comunicación con el cliente, los
usuarios finales, los usuarios del sistema y otras personas interesadas en el
desarrollo del sistema de software.
Hay varias formas de descubrir los requisitos.

Entrevistas

Las entrevistas son un medio fuerte para recopilar los requisitos. La

organización puede realizar varios tipos de entrevistas, tales como:

 Las entrevistas estructuradas (cerradas), donde cada información que se reúne se

decide de antemano, siguen firmemente el patrón y el tema de discusión.
 Entrevistas no estructuradas (abiertas), donde la información para recopilar no se
decide de antemano, es más flexible y menos sesgada.
 Entrevistas orales
  Entrevistas escritas
 Entrevistas individuales que se realizan entre dos personas al otro lado de la mesa.
 Entrevistas grupales que se realizan entre grupos de participantes. Ayudan a
descubrir cualquier requisito faltante ya que muchas personas están involucradas.

Encuestas

La organización puede realizar encuestas entre varias partes interesadas

mediante consultas sobre sus expectativas y requisitos del próximo sistema.

Cuestionarios

Se entrega a todas las partes interesadas un documento con un conjunto

predefinido de preguntas objetivas y opciones respectivas para que
respondan, que se recopilan y compilan.
Una deficiencia de esta técnica es que, si una opción para algún problema no
se menciona en el cuestionario, el problema podría dejarse desatendido.

Análisis de tareas

El equipo de ingenieros y desarrolladores puede analizar la operación para la

cual se requiere el nuevo sistema. Si el cliente ya tiene algún software para
realizar cierta operación, se estudia y se recopilan los requisitos del sistema
propuesto.

Análisis de dominio

Todo software pertenece a alguna categoría de dominio. Las personas

expertas en el dominio pueden ser de gran ayuda para analizar requisitos
generales y específicos.

Lluvia de ideas

Se lleva a cabo un debate informal entre las diversas partes interesadas y

todos sus aportes se registran para un análisis de requisitos adicional.

Prototipos

La creación de prototipos está construyendo una interfaz de usuario sin

agregar funcionalidad detallada para que el usuario interprete las
características del producto de software previsto. Ayuda a dar una mejor idea
de los requisitos. Si no hay un software instalado en el extremo del cliente
para referencia del desarrollador y el cliente no conoce sus propios requisitos,
el desarrollador crea un prototipo basado en los requisitos mencionados
inicialmente. El prototipo se muestra al cliente y se anota la
retroalimentación. La retroalimentación del cliente sirve como entrada para la
recopilación de requisitos.

Observación
Un equipo de expertos visita la organización o el lugar de trabajo del
cliente. Observan el funcionamiento real de los sistemas instalados
existentes. Observan el flujo de trabajo al final del cliente y cómo se tratan los
problemas de ejecución. El equipo mismo saca algunas conclusiones que
ayudan a formar los requisitos esperados del software.

Características de los requisitos de software

La recopilación de requisitos de software es la base de todo el proyecto de
desarrollo de software. Por lo tanto, deben ser claros, correctos y bien
definidos.
Las especificaciones de requisitos de software completas deben ser:

 Claro
 Correcto
 Consistente
 Coherente
 Comprensible
 Modificable
 Verifiable
 Priorizado
 Inequívoco
 Trazable
 Fuente creíble

Requisitos de Software
Deberíamos tratar de entender qué tipo de requisitos pueden surgir en la fase
de obtención de requisitos y qué tipos de requisitos se esperan del sistema de
software.
En términos generales, los requisitos de software deben clasificarse en dos
categorías:

Requerimientos funcionales

Los requisitos relacionados con el aspecto funcional del software entran en

esta categoría.
Definen funciones y funcionalidades dentro y desde el sistema de software.
Ejemplos -

 Opción de búsqueda dada al usuario para buscar desde varias facturas.

 El usuario debe poder enviar cualquier informe a la gerencia.
 Los usuarios pueden dividirse en grupos y los grupos pueden recibir derechos
separados.
 Debe cumplir con las normas comerciales y las funciones administrativas.
  El software se desarrolla manteniendo intacta la compatibilidad con versiones
anteriores.

Requerimientos no funcionales

Los requisitos, que no están relacionados con el aspecto funcional del

software, entran en esta categoría. Son características implícitas o esperadas
del software, que los usuarios suponen.
Los requisitos no funcionales incluyen:

 Seguridad
 Inicio sesión
 Almacenamiento
 Configuración
 Actuación
 Costo
 Interoperabilidad
 Flexibilidad
 Recuperación de desastres
 Accesibilidad
Los requisitos se clasifican lógicamente como

 Debe tener : El software no puede decirse operativo sin ellos.

 Debería : Mejorar la funcionalidad del software.
 Podría haber : El software todavía puede funcionar correctamente con estos
requisitos.
 Lista de deseos : estos requisitos no corresponden a ningún objetivo del software.
Mientras se desarrolla el software, 'Debe tener' debe implementarse, 'Debería
tener' es un tema de debate con las partes interesadas y la negación, mientras
que 'podría tener' y 'lista de deseos' pueden mantenerse para actualizaciones
de software.

Requisitos de interfaz de usuario

La interfaz de usuario es una parte importante de cualquier software o
hardware o sistema híbrido. Un software es ampliamente aceptado si es -

 fácil de operar
 respuesta rápida
 manejo efectivo de errores operacionales
 proporcionando una interfaz de usuario simple pero consistente
La aceptación del usuario depende en gran medida de cómo puede usar el
software. La IU es la única forma en que los usuarios perciben el sistema. Un
sistema de software que funcione bien también debe estar equipado con una
interfaz de usuario atractiva, clara, consistente y receptiva. De lo contrario, las
funcionalidades del sistema de software no se pueden utilizar de manera
conveniente. Se dice que un sistema es bueno si proporciona medios para
usarlo eficientemente. Los requisitos de la interfaz de usuario se mencionan
brevemente a continuación:

 Presentación del contenido

 Navegación fácil
 Interfaz simple
 Sensible
 Elementos de IU consistentes
 Mecanismo de retroalimentación
 Configuración por defecto
 Diseño intencionado
 Uso estratégico de color y textura.
 Proporcionar información de ayuda
 Enfoque centrado en el usuario
 Configuración de vista basada en grupos.

Analista de sistemas de software

El analista de sistemas en una organización de TI es una persona que analiza
los requisitos del sistema propuesto y garantiza que los requisitos se conciban
y documenten de manera correcta y correcta. El rol de un analista comienza
durante la Fase de Análisis de Software de SDLC. Es responsabilidad del
analista asegurarse de que el software desarrollado cumpla con los requisitos
del cliente.
Los analistas de sistemas tienen las siguientes responsabilidades:

 Análisis y comprensión de los requisitos del software previsto.

 Comprender cómo contribuirá el proyecto en los objetivos de la organización
 Identificar fuentes de requerimiento
 Validación de requerimiento
 Desarrollar e implementar un plan de gestión de requisitos.
 Documentación de los requisitos comerciales, técnicos, de proceso y de producto.
 Coordinación con los clientes para priorizar requisitos y eliminar y ambigüedad.
 Finalizar los criterios de aceptación con el cliente y otras partes interesadas.

Métricas y medidas de software

Las medidas de software pueden entenderse como un proceso de
cuantificación y simbolización de varios atributos y aspectos del software.
Las métricas de software proporcionan medidas para varios aspectos del
proceso de software y el producto de software.
Las medidas de software son requisitos fundamentales de la ingeniería de
software. No solo ayudan a controlar el proceso de desarrollo de software,
sino que también ayudan a mantener excelente la calidad del producto final.
Según Tom DeMarco, un (Ingeniero de software), "No puede controlar lo que
no puede medir". Por su dicho, está muy claro cuán importantes son las
medidas de software.
Veamos algunas métricas de software:
 Medidas del tamaño: LOC (líneas de código), calculadas principalmente en miles
de líneas de código fuente entregadas, denotadas como KLOC.
Function Point Count es una medida de la funcionalidad proporcionada por el
software. El recuento de puntos de función define el tamaño del aspecto funcional
del software.

 Métrica de complejidad: la complejidad ciclomática de McCabe cuantifica el límite

superior del número de rutas independientes en un programa, que se percibe como
la complejidad del programa o sus módulos. Se representa en términos de
conceptos de teoría de grafos mediante el uso de gráficos de flujo de control.
 Métricas de calidad: los defectos, sus tipos y causas, las consecuencias, la
intensidad de la gravedad 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 informados por el cliente después de que el producto se instala o entrega
al final del cliente, definen la calidad del producto.

 Métricas de proceso: en varias fases de SDLC, los métodos y herramientas

utilizados, los estándares de la compañía y el desempeño del desarrollo son
métricas de proceso de software.
 Métricas de recursos: el esfuerzo, el tiempo y los diversos recursos utilizados
representan métricas para la medición de recursos.

Conceptos básicos de diseño de software

El diseño de software es un proceso para transformar los requisitos del
usuario en una forma adecuada, que ayuda al programador en la codificación
e implementación del software.
Para evaluar los requisitos del usuario, se crea un documento SRS
(Especificación de requisitos de software), mientras que para la codificación y
la implementación, se necesitan requisitos más específicos y detallados en
términos de software. El resultado de este proceso se puede utilizar
directamente en la implementación en lenguajes de programación.
El diseño de software es el primer paso en SDLC (Software Design Life
Cycle), que mueve la concentración del dominio del problema al dominio de la
solución. Intenta especificar cómo cumplir los requisitos mencionados en SRS.

Niveles de diseño de software

El diseño de software produce tres niveles de resultados:

 Diseño arquitectónico: el diseño arquitectónico es la versión abstracta más alta del

sistema. Identifica el software como un sistema con muchos componentes que
interactúan entre sí. En este nivel, los diseñadores tienen la idea del dominio de la
solución propuesta.
  De alto nivel Design- Los de alto nivel se rompe diseño el 'solo componente
entidad de múltiples' concepto de diseño arquitectónico a la vista menos abstraído
de los subsistemas y módulos y representa su interacción entre sí. El diseño de
alto nivel se centra en cómo el sistema junto con todos sus componentes se
pueden implementar en forma de módulos. Reconoce la estructura modular de
cada subsistema y su relación e interacción entre sí.
 Detalla Diseño- ofertas de diseño detallado con la parte de implementación de lo
que se ve como un sistema y sus subsistemas en los dos diseños anteriores. Es
más detallado para los módulos y sus implementaciones. Define la estructura
lógica de cada módulo y sus interfaces para comunicarse con otros módulos.

Modularización
La modularización es una técnica para dividir un sistema de software en
múltiples módulos discretos e independientes, que se espera que sean
capaces de realizar tareas de forma independiente. Estos módulos pueden
funcionar como construcciones básicas para todo el software. Los diseñadores
tienden a diseñar módulos de manera que puedan ejecutarse y / o compilarse
por separado e independientemente.
El diseño modular sigue involuntariamente las reglas de la estrategia de
resolución de problemas 'divide y vencerás', esto se debe a que hay muchos
otros beneficios asociados con el diseño modular de un software.
Ventaja de modularización:

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

 El programa se puede dividir en función de aspectos funcionales.
 El nivel deseado de abstracción se puede traer al programa
 Los componentes con alta cohesión pueden reutilizarse nuevamente
 La ejecución concurrente puede ser posible
 Deseado desde el aspecto de seguridad

Concurrencia
En el pasado, todo el software debe ejecutarse secuencialmente. Por
ejecución secuencial queremos decir que la instrucción codificada se ejecutará
una tras otra, lo que implica que solo una parte del programa se activará en un
momento dado. Digamos que un software tiene múltiples módulos, entonces
solo uno de todos los módulos se puede encontrar activo en cualquier
momento de ejecución.
En el diseño de software, la concurrencia se implementa dividiendo el software
en múltiples unidades independientes de ejecución, como módulos, y
ejecutándolos en paralelo. En otras palabras, la concurrencia proporciona
capacidad al software para ejecutar más de una parte del código en paralelo
entre sí.
Es necesario que los programadores y diseñadores reconozcan esos módulos,
que pueden ejecutarse en paralelo.
Ejemplo

La función de corrección ortográfica en el procesador de textos es un módulo

de software que se ejecuta junto con el procesador de textos.

Acoplamiento y Cohesión
Cuando un programa de software se modulariza, sus tareas se dividen en
varios módulos en función de algunas características. Como sabemos, los
módulos son un conjunto de instrucciones juntas para lograr algunas
tareas. Sin embargo, se consideran como una entidad única, pero pueden
referirse entre sí para trabajar juntas. Existen medidas por las cuales se puede
medir la calidad de un diseño de módulos y su interacción entre ellos. Estas
medidas se llaman acoplamiento y cohesión.

Cohesión
La cohesión es una medida que define el grado de intradependencia dentro de
los elementos de un módulo. Cuanto mayor es la cohesión, mejor es el diseño
del programa.
Hay siete tipos de cohesión, a saber:

 Cohesión coincidente: es una cohesión no planificada y aleatoria, que podría ser

el resultado de dividir el programa en módulos más pequeños en aras de la
modularización. Debido a que no es planeado, puede causar confusión a los
programadores y generalmente no es aceptado.
 Cohesión lógica: cuando los elementos categorizados lógicamente se unen en un
módulo, se llama cohesión lógica.
 Cohesión emporal: cuando los elementos del módulo se organizan de manera
que se procesan en un punto similar en el tiempo, se denomina cohesión temporal.
 Cohesión de procedimiento: cuando los elementos del módulo se agrupan, que
se ejecutan secuencialmente para realizar una tarea, se denomina cohesión de
procedimiento.
 Cohesión comunicacional: cuando los elementos del módulo se agrupan, que se
ejecutan secuencialmente y funcionan en los mismos datos (información), se
denomina cohesión comunicacional.
 Cohesión secuencial: cuando los elementos del módulo se agrupan porque la
salida de un elemento sirve como entrada para otro y así sucesivamente, se
denomina cohesión secuencial.
 Cohesión funcional: se considera el mayor grado de cohesión, y es muy
esperado. Los elementos del módulo en cohesión funcional se agrupan porque
todos contribuyen a una única función bien definida. También se puede reutilizar.

Acoplamiento
El acoplamiento es una medida que define el nivel de interdependencia entre
los módulos de un programa. Indica a qué nivel los módulos interfieren e
interactúan entre sí. Cuanto más bajo sea el acoplamiento, mejor será el
programa.
Hay cinco niveles de acoplamiento, a saber:

 Acoplamiento de contenido: cuando un módulo puede acceder directamente o

modificar o hacer referencia al contenido de otro módulo, se denomina
acoplamiento de nivel de contenido.
 Acoplamiento común: cuando varios módulos tienen acceso de lectura y
escritura a algunos datos globales, se denomina acoplamiento común o global.
 Control de acoplamiento: dos módulos se denominan control acoplado si uno de
ellos decide la función del otro módulo o cambia su flujo de ejecución.
 Acoplamiento de sello: cuando varios módulos comparten una estructura de
datos común y trabajan en diferentes partes, se denomina acoplamiento de sello.
 Acoplamiento de datos: el acoplamiento de datos es cuando dos módulos
interactúan entre sí mediante el paso de datos (como parámetro). Si un módulo
pasa la estructura de datos como parámetro, el módulo receptor debe usar todos
sus componentes.
Idealmente, ningún acoplamiento se considera el mejor.

Verificación de diseño
La salida del proceso de diseño de software es documentación de diseño,
pseudocódigos, diagramas lógicos detallados, diagramas de proceso y una
descripción detallada de todos los requisitos funcionales o no funcionales.
La siguiente fase, que es la implementación del software, depende de todos
los resultados mencionados anteriormente.
Entonces es necesario verificar la salida antes de pasar a la siguiente
fase. Cuanto antes se detecte cualquier error, mejor será o podría no
detectarse hasta que se pruebe el producto. Si los resultados de la fase de
diseño están en forma de notación formal, entonces se deben usar sus
herramientas asociadas para la verificación; de lo contrario, se puede usar una
revisión exhaustiva del diseño para la verificación y validación.
Mediante el enfoque de verificación estructurada, los revisores pueden
detectar defectos que podrían ser causados por pasar por alto algunas
condiciones. Una buena revisión de diseño es importante para un buen diseño
de software, precisión y calidad.

Análisis de software y herramientas de

diseño
El análisis y diseño de software incluye todas las actividades, que ayudan a la
transformación de la especificación de requisitos en implementación. Las
especificaciones de requisitos especifican todas las expectativas funcionales y
no funcionales del software. Estas especificaciones de requisitos vienen en
forma de documentos legibles y comprensibles para el ser humano, para los
cuales una computadora no tiene nada que hacer.
El análisis y diseño de software es la etapa intermedia, que ayuda a
transformar los requisitos legibles por humanos en código real.
Veamos algunas herramientas de análisis y diseño utilizadas por los
diseñadores de software:

Diagrama de flujo de datos

El diagrama de flujo de datos es una representación gráfica del flujo de datos
en un sistema de información. Es capaz de representar el flujo de datos
entrantes, el flujo de datos salientes y los datos almacenados. El DFD no
menciona nada sobre cómo fluyen los datos a través del sistema.
Hay una diferencia prominente entre DFD y Diagrama de flujo. El diagrama de
flujo muestra el flujo de control en los módulos del programa. Los DFD
representan el flujo de datos en el sistema en varios niveles. DFD no contiene
ningún control o elementos de ramificación.

Tipos de DFD

Los diagramas de flujo de datos son lógicos o físicos.

 DFD lógico : este tipo de DFD se concentra en el proceso del sistema y el flujo de
datos en el sistema. Por ejemplo, en un sistema de software bancario, cómo se
mueven los datos entre diferentes entidades.
 DFD físico : este tipo de DFD muestra cómo se implementa realmente el flujo de
datos en el sistema. Es más específico y cercano a la implementación.

Componentes DFD

El DFD puede representar el origen, el destino, el almacenamiento y el flujo de

datos utilizando el siguiente conjunto de componentes:

 Entidades : las entidades son el origen y el destino de los datos de

información. Las entidades están representadas por rectángulos con sus
respectivos nombres.
 Proceso : las actividades y acciones tomadas en los datos están representadas
por rectángulos circulares o de bordes redondeados.
 Almacenamiento de datos : hay dos variantes de almacenamiento de datos:
puede representarse como un rectángulo con ausencia de ambos lados más
pequeños o como un rectángulo abierto con un solo lado faltante.
 Flujo de datos : el movimiento de los datos se muestra mediante flechas
puntiagudas. El movimiento de datos se muestra desde la base de la flecha como
su fuente hacia la punta de la flecha como destino.

Niveles de DFD

 Nivel 0 : el nivel más alto de abstracción DFD se conoce como Nivel 0 DFD, que
representa todo el sistema de información como un diagrama que oculta todos los
 detalles subyacentes. Los DFD de nivel 0 también se conocen como DFD de nivel
de contexto.

 Nivel 1 : el DFD de nivel 0 se desglosa en DFD de nivel 1 más específico. El Nivel

1 DFD representa los módulos básicos en el sistema y el flujo de datos entre varios
módulos. El Nivel 1 DFD también menciona procesos básicos y fuentes de
información.

 Nivel 2 : en este nivel, DFD muestra cómo fluyen los datos dentro de los módulos
mencionados en el Nivel 1.
Los DFD de nivel superior se pueden transformar en DFD de nivel inferior más
específicos con un nivel de comprensión más profundo a menos que se logre el
nivel de especificación deseado.

Gráficos de estructura
El gráfico de estructura es un gráfico derivado del diagrama de flujo de
datos. Representa el sistema con más detalle que DFD. Desglosa todo el
sistema en los módulos funcionales más bajos, describe las funciones y
subfunciones de cada módulo del sistema con mayor detalle que el DFD.
El diagrama de estructura representa la estructura jerárquica de los
módulos. En cada capa se realiza una tarea específica.
Aquí están los símbolos utilizados en la construcción de diagramas de
estructura:

 Módulo : representa el proceso, subrutina o tarea. Un módulo de control se bifurca

a más de un submódulo. Los módulos de biblioteca son reutilizables e invocables
desde cualquier módulo.

 Condición : está representado por un pequeño diamante en la base del

módulo. Representa que el módulo de control puede seleccionar cualquiera de las
subrutinas en función de alguna condición.

 Saltar : se muestra una flecha apuntando dentro del módulo para representar que

el control saltará en el medio del submódulo.

  Bucle : una flecha curva representa el bucle en el módulo. Todos los submódulos
cubiertos por bucle repiten la ejecución del módulo.

 Flujo de datos : una flecha dirigida con un círculo vacío al final representa el flujo

de datos.
 Flujo de control : una flecha dirigida con un círculo relleno al final representa el

flujo de control.

Diagrama HIPO
El diagrama HIPO (Hierarchical Input Process Output) es una combinación de
dos métodos organizados para analizar el sistema y proporcionar los medios
de documentación. El modelo HIPO fue desarrollado por IBM en el año 1970.
El diagrama HIPO representa la jerarquía de módulos en el sistema de
software. El analista utiliza el diagrama HIPO para obtener una vista de alto
nivel de las funciones del sistema. Descompone funciones en subfunciones de
manera jerárquica. Representa las funciones realizadas por el sistema.
Los diagramas HIPO son buenos para fines de documentación. Su
representación gráfica facilita a los diseñadores y gerentes obtener una idea
gráfica de la estructura del sistema.
A diferencia del diagrama IPO (Input Process Output), que representa el flujo
de control y datos en un módulo, HIPO no proporciona ninguna información
sobre el flujo de datos o el flujo de control.

Ejemplo

Ambas partes del diagrama HIPO, la presentación jerárquica y la tabla IPO se

utilizan para el diseño de la estructura del programa de software, así como la
documentación del mismo.

Inglés estructurado
La mayoría de los programadores desconocen el panorama general del
software, por lo que solo confían en lo que sus gerentes les dicen que
hagan. Es responsabilidad de la administración de software superior
proporcionar información precisa a los programadores para desarrollar un
código preciso pero rápido.
Otras formas de métodos, que utilizan gráficos o diagramas, a veces pueden
ser interpretados de manera diferente por diferentes personas.
Por lo tanto, los analistas y diseñadores del software presentan herramientas
como el inglés estructurado. No es más que la descripción de lo que se
requiere para codificar y cómo codificarlo. El inglés estructurado ayuda al
programador a escribir código libre de errores.
Otras formas de métodos, que utilizan gráficos o diagramas, a veces pueden
ser interpretados de manera diferente por diferentes personas. Aquí, tanto el
inglés estructurado como el pseudocódigo intentan mitigar esa brecha de
comprensión.
El inglés estructurado es el que utiliza palabras simples en inglés en el
paradigma de programación estructurada. No es el código definitivo, sino una
especie de descripción de lo que se requiere para codificar y cómo
codificarlo. Los siguientes son algunos tokens de programación estructurada.
IF-THEN-ELSE,
DO-WHILE-UNTIL

Analyst utiliza la misma variable y nombre de datos, que se almacenan en el

Diccionario de datos, lo que hace que sea mucho más sencillo escribir y
comprender el código.

Ejemplo

Tomamos el mismo ejemplo de autenticación de clientes en el entorno de

compras en línea. Este procedimiento para autenticar al cliente se puede
escribir en inglés estructurado 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 código escrito en inglés estructurado se parece más al inglés hablado día a
día. No se puede implementar directamente como un código de software. El
inglés estructurado es independiente del lenguaje de programación.

Pseudocódigo
El pseudocódigo se escribe más cerca del lenguaje de programación. Puede
considerarse como lenguaje de programación aumentado, lleno de
comentarios y descripciones.
El seudocódigo evita la declaración de variables, pero se escriben utilizando
algunas construcciones de lenguaje de programación real, como C, Fortran,
Pascal, etc.
El pseudocódigo contiene más detalles de programación que el inglés
estructurado. Proporciona un método para realizar la tarea, como si una
computadora estuviera ejecutando el código.
Ejemplo

Programa para imprimir Fibonacci hasta n números.

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 decisiones
Una tabla de decisiones representa las condiciones y las acciones respectivas
que deben tomarse para abordarlas, en un formato tabulado estructurado.
Es una herramienta poderosa para depurar y prevenir errores. Ayuda a
agrupar información similar en una sola tabla y, al combinar tablas, ofrece una
toma de decisiones fácil y conveniente.

Crear tabla de decisiones

Para crear la tabla de decisiones, el desarrollador debe seguir cuatro pasos

básicos:

 Identificar todas las condiciones posibles que se abordarán.

 Determinar acciones para todas las condiciones identificadas
 Crear máximas reglas posibles
 Definir acción para cada regla.
Los usuarios finales deben verificar las Tablas de decisión y últimamente
pueden simplificarse eliminando reglas y acciones duplicadas.

Ejemplo

Tomemos un ejemplo simple del problema diario con nuestra conectividad a

Internet. Comenzamos identificando todos los problemas que pueden surgir al
iniciar Internet y sus respectivas posibles soluciones.
Enumeramos todos los posibles problemas en condiciones de columna y las
acciones prospectivas en Acciones de columna.

Condiciones / acciones Reglas

Shows conectados norte norte norte norte Y Y YY

Condiciones Ping está funcionando norte norte Y Y norte norte Y Y

Abre el sitio web Y norte Y norte Y norte Y norte

Comprobar cable de red X

Comprobar enrutador de internet X X X X

Reiniciar el navegador web X

Comportamiento

Contactar con el proveedor de

X X X X X X
servicios

No hacer nada

Tabla: Tabla de decisiones - Solución de problemas internos de Internet

Modelo de entidad-relación
El modelo de entidad-relación es un tipo de modelo de base de datos basado
en la noción de entidades del mundo real y la relación entre ellas. Podemos
mapear el escenario del mundo real en el modelo de base de datos ER. El
modelo ER crea un conjunto de entidades con sus atributos, un conjunto de
restricciones y relación entre ellas.
El modelo ER se utiliza mejor para el diseño conceptual de la base de
datos. El modelo ER se puede representar de la siguiente manera:

 Entidad : una entidad en el modelo ER es un ser del mundo real, que tiene
algunas propiedades llamadas atributos . Cada atributo se define por su conjunto
de valores correspondiente, llamado dominio .
 Por ejemplo, considere una base de datos de la escuela. Aquí, un estudiante es
una entidad. El estudiante tiene varios atributos como nombre, identificación, edad
y clase, etc.
 Relación : la asociación lógica entre entidades se denomina relación . Las
relaciones se asignan con entidades de varias maneras. Las cardinalidades de
mapeo definen el número de asociaciones entre dos entidades.
Mapeo de cardinalidades:

o doce y cincuenta y nueve de la noche

o uno a muchos
o muchos a uno
o muchos a muchos

Diccionario de datos
El diccionario de datos es la recopilación centralizada de información sobre
datos. Almacena el significado y el origen de los datos, su relación con otros
datos, el formato de datos para su uso, etc. El diccionario de datos tiene
definiciones rigurosas de todos los nombres para facilitar a los usuarios y
diseñadores de software.
El diccionario de datos a menudo se hace referencia como repositorio de
metadatos (datos sobre datos). Se crea junto con el modelo DFD (Diagrama
de flujo de datos) del programa de software y se espera que se actualice cada
vez que se modifique o actualice DFD.

Requisito del diccionario de datos

Se hace referencia a los datos a través del diccionario de datos al diseñar e

implementar software. El diccionario de datos elimina cualquier posibilidad de
ambigüedad. Ayuda a mantener sincronizado el trabajo de los programadores
y diseñadores mientras se usa la misma referencia de objeto en todo el
programa.
El diccionario de datos proporciona una forma de documentación para el
sistema de base de datos completo en un solo lugar. La validación de DFD se
lleva a cabo utilizando el diccionario de datos.

Contenido

El diccionario de datos debe contener información sobre lo siguiente

 Flujo de datos
 Estructura de datos
 Elementos de datos
 Almacenes de datos
 Procesamiento de datos
El flujo de datos se describe mediante DFD como se estudió anteriormente y
se representa en forma algebraica como se describe.
= Compuesto de

{} Repetición

() Opcional

+ Y

[/] O

Ejemplo

Dirección = Casa No + (Calle / Área) + Ciudad + Estado

ID del curso = Número del curso + Nombre del curso + Nivel del curso +
Grados del curso

Elementos de datos

Los elementos de datos consisten en Nombre y descripciones de Datos y

Elementos de control, almacenes de datos internos o externos, etc. con los
siguientes detalles:

 Nombre primario
 Nombre secundario (alias)
 Caso de uso (Cómo y dónde usar)
 Descripción del contenido (notación, etc.)
 Información complementaria (valores preestablecidos, restricciones, etc.)

Almacén de datos

Almacena la información desde donde los datos ingresan al sistema y existen

fuera del sistema. El almacén de datos puede incluir:

 Archivos
o Interna al software.
o Externo al software pero en la misma máquina.
o Externo al software y al sistema, ubicado en diferentes máquinas.
 Mesas
o Convenio de denominación
o Propiedad de indexación

Procesamiento de datos

Hay dos tipos de procesamiento de datos:

 Lógico: como el usuario lo ve

  Físico: como lo ve el software

Estrategias de diseño de software

El diseño de software es un proceso para conceptualizar los requisitos de
software en la implementación de software. El diseño del software toma los
requisitos del usuario como desafíos e intenta encontrar una solución
óptima. Mientras se conceptualiza el software, se establece un plan para
encontrar el mejor diseño posible para implementar la solución deseada.
Existen múltiples variantes de diseño de software. Vamos a estudiarlos
brevemente:

Diseño estructurado
El diseño estructurado es una conceptualización del problema en varios
elementos de solución bien organizados. Básicamente se trata del diseño de
la solución. El beneficio del diseño estructurado es que brinda una mejor
comprensión de cómo se resuelve el problema. El diseño estructurado
también facilita que el diseñador se concentre en el problema con mayor
precisión.
El diseño estructurado se basa principalmente en la estrategia de "divide y
vencerás", donde un problema se divide en varios problemas pequeños y cada
problema pequeño se resuelve individualmente hasta que se resuelve todo el
problema.
Los pequeños problemas se resuelven mediante módulos de solución. El
diseño estructurado enfatiza que estos módulos estén bien organizados para
lograr una solución precisa.
Estos módulos están ordenados en jerarquía. Se comunican entre ellos. Un
buen diseño estructurado siempre sigue algunas reglas para la comunicación
entre múltiples módulos, a saber:
Cohesión : agrupación de todos los elementos relacionados funcionalmente.
Acoplamiento : comunicación entre diferentes módulos.
Un buen diseño estructurado tiene alta cohesión y bajos arreglos de
acoplamiento.

Diseño orientado a funciones

En el diseño orientado a funciones, el sistema se compone de muchos
subsistemas más pequeños conocidos como funciones. Estas funciones son
capaces de realizar tareas importantes en el sistema. El sistema se considera
como una vista superior de todas las funciones.
El diseño orientado a funciones hereda algunas propiedades del diseño
estructurado donde se utiliza la metodología de dividir y conquistar.
Este mecanismo de diseño divide todo el sistema en funciones más pequeñas,
que proporcionan medios de abstracción al ocultar la información y su
funcionamiento. Estos módulos funcionales pueden compartir información
entre ellos mediante el paso de información y el uso de información disponible
a nivel mundial.
Otra característica de las funciones es que cuando un programa llama a una
función, la función cambia el estado del programa, que a veces no es
aceptable por otros módulos. El diseño orientado a funciones funciona bien
donde el estado del sistema no importa y el programa / funciones funcionan en
la entrada en lugar de en un estado.

Proceso de diseño

 Se ve todo el sistema como el flujo de datos en el sistema por medio del diagrama
de flujo de datos.
 DFD muestra cómo las funciones cambian los datos y el estado de todo el sistema.
 El sistema completo se divide lógicamente en unidades más pequeñas conocidas
como funciones en función de su funcionamiento en el sistema.
 Cada función se describe en general.

Diseño orientado a objetos

El diseño orientado a objetos trabaja alrededor de las entidades y sus
características en lugar de las funciones involucradas en el sistema de
software. Estas estrategias de diseño se centran en las entidades y sus
características. Todo el concepto de solución de software gira en torno a las
entidades comprometidas.
Veamos los conceptos importantes del diseño orientado a objetos:

 Objetos: todas las entidades involucradas en el diseño de la solución se conocen

como objetos. Por ejemplo, persona, bancos, empresa y clientes son tratados
como objetos. Cada entidad tiene algunos atributos asociados y tiene algunos
métodos para realizar en los atributos.
 Clases: una clase es una descripción generalizada de un objeto. Un objeto es una
instancia de una clase. La clase define todos los atributos que puede tener un
objeto y los métodos que definen la funcionalidad del objeto.
En el diseño de la solución, los atributos se almacenan como variables y las
funcionalidades se definen mediante métodos o procedimientos.

 Encapsulación: en OOD, los atributos (variables de datos) y los métodos

(operación en los datos) se agrupan y se denomina encapsulación. La
encapsulación no solo agrupa información importante de un objeto, sino que
también restringe el acceso a los datos y métodos del mundo exterior. Esto se
llama ocultar información.
 Herencia: OOD permite que clases similares se acumulen de forma jerárquica
donde las clases inferiores o subclases pueden importar, implementar y reutilizar
variables y métodos permitidos desde sus superclases inmediatas. Esta propiedad
de OOD se conoce como herencia. Esto facilita la definición de clases específicas
y la creación de clases generalizadas a partir de clases específicas.
 Polimorfismo: los lenguajes OOD proporcionan un mecanismo en el que los
métodos que realizan tareas similares pero varían en argumentos pueden tener el
mismo nombre. Esto se llama polimorfismo, que permite que una sola interfaz
 realice tareas para diferentes tipos. Dependiendo de cómo se invoque la función,
se ejecuta la parte correspondiente del código.

Proceso de diseño

El proceso de diseño de software se puede percibir como una serie de pasos

bien definidos. Aunque varía según el enfoque de diseño (orientado a
funciones u orientado a objetos, puede tener los siguientes pasos
involucrados:

 Se crea un diseño de solución a partir de un sistema requerido o un diagrama de

secuencia del sistema utilizado anteriormente.
 Los objetos se identifican y agrupan en clases en nombre de la similitud en las
características de los atributos.
 Se define la jerarquía de clases y la relación entre ellas.
 El marco de la aplicación está definido.

Enfoques de diseño de software

Aquí hay dos enfoques genéricos para el diseño de software:

Diseño de arriba hacia abajo

Sabemos que un sistema está compuesto por más de un subsistema y

contiene varios componentes. Además, estos subsistemas y componentes
pueden tener su conjunto de subsistemas y componentes y crear una
estructura jerárquica en el sistema.
El diseño de arriba hacia abajo toma todo el sistema de software como una
entidad y luego lo descompone para lograr más de un subsistema o
componente basado en algunas características. Cada subsistema o
componente se trata como un sistema y se descompone aún más. Este
proceso continúa ejecutándose hasta que se alcanza el nivel más bajo del
sistema en la jerarquía de arriba hacia abajo.
El diseño de arriba hacia abajo comienza con un modelo generalizado de
sistema y sigue definiendo la parte más específica del mismo. Cuando todos
los componentes están compuestos, todo el sistema comienza a existir.
El diseño de arriba hacia abajo es más adecuado cuando la solución de
software debe diseñarse desde cero y se desconocen detalles específicos.

Diseño de abajo hacia arriba

El modelo de diseño ascendente comienza con los componentes más

específicos y básicos. Continúa con la composición de un nivel superior de
componentes mediante el uso de componentes básicos o de nivel
inferior. Sigue creando componentes de nivel superior hasta que el sistema
deseado no evoluciona como un solo componente. Con cada nivel superior,
aumenta la cantidad de abstracción.
La estrategia de abajo hacia arriba es más adecuada cuando se necesita crear
un sistema a partir de algún sistema existente, donde las primitivas básicas se
pueden usar en el sistema más nuevo.
Los enfoques de arriba hacia abajo y de abajo hacia arriba no son prácticos
individualmente. En cambio, se usa una buena combinación de ambos.

Diseño de interfaz de usuario de software

La interfaz de usuario es la vista de la aplicación front-end con la que el
usuario interactúa para usar el software. El usuario puede manipular y
controlar el software y el hardware mediante la interfaz de usuario. Hoy en día,
la interfaz de usuario se encuentra en casi todos los lugares donde existe
tecnología digital, desde computadoras, teléfonos móviles, automóviles,
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 que proporcione al usuario una visión del software. La interfaz de
usuario proporciona una plataforma fundamental para la interacción humano-
computadora.
La interfaz de usuario puede ser gráfica, basada en texto, basada en audio y
video, dependiendo de la combinación subyacente de hardware y software. La
interfaz de usuario puede ser hardware o software o una combinación de
ambos.
El software se vuelve más popular si su interfaz de usuario es:

 Atractivo
 Fácil de usar
 Sensible en poco tiempo
 Claro para entender
 Consistente en todas las pantallas de interfaz
La interfaz de usuario se divide en dos categorías:

 Interfaz de línea de comando

 Interfaz gráfica del usuario

Interfaz de línea de comando (CLI)

CLI ha sido una gran herramienta de interacción con las computadoras hasta
que surgieron los monitores de video. CLI es la primera opción de muchos
usuarios técnicos y programadores. CLI es la interfaz mínima que un software
puede proporcionar a sus usuarios.
La CLI proporciona un símbolo del sistema, el lugar donde el usuario escribe
el comando y lo alimenta al sistema. El usuario debe recordar la sintaxis del
comando y su uso. Las CLI anteriores no estaban programadas para manejar
los errores del usuario de manera efectiva.
Un comando es una referencia basada en texto para un conjunto de
instrucciones, que se espera que el sistema ejecute. Existen métodos como
macros, scripts que facilitan la operación del usuario.
La CLI usa menos cantidad de recursos informáticos en comparación con la
GUI.

Elementos CLI

Una interfaz de línea de comandos basada en texto puede tener los siguientes
elementos:
 Símbolo del sistema : es un notificador basado en texto que muestra
principalmente el contexto en el que trabaja el usuario. Es generado por el
sistema de software.
 Cursor : es una pequeña línea horizontal o una barra vertical de la altura de la
línea, para representar la posición del carácter mientras se escribe. El cursor se
encuentra principalmente en estado de parpadeo. Se mueve a medida que el
usuario escribe o elimina algo.
 Comando : un comando es una instrucción ejecutable. Puede tener uno o más
parámetros. La salida en la ejecución del comando se muestra en línea en la
pantalla. Cuando se produce la salida, se muestra el símbolo del sistema en la
siguiente línea.

Interfaz gráfica del usuario

La interfaz gráfica de usuario proporciona al usuario medios gráficos para
interactuar con el sistema. La GUI puede ser una combinación de hardware y
software. Usando GUI, el usuario interpreta el software.
Por lo general, la GUI consume más recursos que la de la CLI. Con tecnología
avanzada, los programadores y diseñadores crean diseños complejos de GUI
que funcionan con más eficiencia, precisión y velocidad.

Elementos GUI

GUI proporciona un conjunto de componentes para interactuar con software o

hardware.
Cada componente gráfico proporciona una forma de trabajar con el
sistema. Un sistema GUI tiene los siguientes elementos, tales como:

 Ventana : un área donde se muestran los contenidos de la aplicación. El

contenido de una ventana se puede mostrar en forma de iconos o listas, si la
ventana representa la estructura del archivo. Es más fácil para un usuario navegar
en el sistema de archivos en una ventana de exploración. Windows se puede
minimizar, redimensionar o maximizar al tamaño 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 secundaria.
 Pestañas : si una aplicación permite ejecutar varias instancias de sí misma,
aparecerán en la pantalla como ventanas separadas. La interfaz de documentos
con pestañas ha aparecido para abrir varios documentos en la misma
ventana. Esta interfaz también ayuda a visualizar el panel de preferencias en la
aplicación. Todos los navegadores web modernos usan esta función.
 Menú : el menú es una matriz de comandos estándar, agrupados y colocados en
un lugar visible (generalmente arriba) dentro de la ventana de la aplicación. El
menú puede programarse para aparecer u ocultarse con los clics del mouse.
 Icono : un icono es una imagen pequeña que representa una aplicación
asociada. Cuando se hace clic en estos iconos o se hace doble clic, se abre la
ventana de la aplicación. Icon muestra aplicaciones y programas instalados en un
sistema en forma de imágenes pequeñas.
 Cursor : los dispositivos que interactúan, como el mouse, el panel táctil y el lápiz
digital, se representan en la GUI como cursores. El cursor en pantalla sigue las
 instrucciones del hardware casi en tiempo real. Los cursores también se
denominan punteros en los sistemas GUI. Se utilizan para seleccionar menús,
ventanas y otras características de la aplicación.

Componentes de la GUI específicos de la aplicación

Una GUI de una aplicación contiene uno o más de los elementos de la GUI
enumerados:
 Ventana de aplicación : la mayoría de las ventanas de aplicación utilizan las
construcciones proporcionadas por los sistemas operativos, pero muchas usan
sus propias ventanas creadas por el cliente para contener el contenido de la
aplicación.
 Cuadro de diálogo : es una ventana secundaria que contiene mensajes para el
usuario y solicita que se tomen medidas. Por ejemplo: la aplicación genera un
diálogo para obtener la confirmación del usuario para eliminar un archivo.

 Cuadro de texto : proporciona un área para que el usuario escriba e ingrese

datos basados en texto.
 Botones : imitan los botones de la vida real y se utilizan para enviar entradas al
software.

 Botón de radio : muestra las opciones disponibles para la selección. Solo se

puede seleccionar uno entre todos los ofrecidos.
  Casilla de verificación : funciones similares a la casilla de lista. Cuando se
selecciona una opción, la casilla se marca como marcada. Se pueden seleccionar
varias opciones representadas por casillas de verificación.
 Cuadro de lista: proporciona una lista de elementos disponibles para la
selección. Se puede seleccionar más de un elemento.

Otros componentes impresionantes de la GUI son:

 Deslizadores
 Caja combo
 Cuadrícula de datos
 La lista desplegable

Actividades de diseño de interfaz de usuario

Hay una serie de actividades realizadas para diseñar la interfaz de usuario. El
proceso de diseño e implementación de la GUI es similar al SDLC. Cualquier
modelo se puede utilizar para la implementación de GUI entre Cascada,
Iterativo o Modelo Espiral.
Un modelo utilizado para el diseño y desarrollo de GUI debe cumplir con estos
pasos específicos de GUI.
  Recopilación de requisitos de GUI : a los diseñadores les gustaría tener una
lista de todos los requisitos funcionales y no funcionales de GUI. Esto se puede
tomar del usuario y su solución de software existente.
 Análisis del usuario : el diseñador estudia quién va a utilizar la GUI del
software. El público objetivo es importante a medida que los detalles del diseño
cambian de acuerdo con el nivel de conocimiento y competencia del usuario. Si el
usuario tiene conocimientos técnicos, se puede incorporar una GUI avanzada y
compleja. Para un usuario novato, se incluye más información sobre
procedimientos del software.
 Análisis de tareas : los diseñadores deben analizar qué tarea debe realizar la
solución de software. Aquí en GUI, no importa cómo se haga. Las tareas se
pueden representar de forma jerárquica tomando una tarea principal y
dividiéndola en subtareas más pequeñas. Las tareas proporcionan objetivos para
la presentación de la GUI. El flujo de información entre subtareas determina el
flujo de contenido de GUI en el software.
 Diseño e implementación de la GUI : los diseñadores, después de tener
información sobre los requisitos, las tareas y el entorno del usuario, diseñan la
GUI y la implementan en el código e incorporan la GUI con software de trabajo o
ficticio en segundo plano. Luego es probado por los desarrolladores.
 Pruebas : las pruebas de GUI se pueden realizar de varias maneras. La
organización puede tener una inspección interna, la participación directa de los
usuarios y el lanzamiento de la versión beta son algunos de ellos. Las pruebas
pueden incluir usabilidad, compatibilidad, aceptación del usuario, etc.

Herramientas de implementación de GUI

Hay varias herramientas disponibles con las que los diseñadores pueden crear
una GUI completa con un clic del mouse. Algunas herramientas pueden
integrarse en el entorno de software (IDE).
Las herramientas de implementación de GUI proporcionan una poderosa
variedad de controles de GUI. Para la personalización del software, los
diseñadores pueden cambiar el código en consecuencia.
Existen diferentes segmentos de herramientas GUI según su uso y plataforma
diferentes.

Ejemplo

GUI móvil, GUI de computadora, GUI de pantalla táctil, etc. Aquí hay una lista
de algunas herramientas que son útiles para construir GUI:

 FLUIDO
 AppInventor (Android)
 LucidChart
 Wavemaker
 Estudio visual

Interfaz de usuario Reglas de oro

Se menciona que las siguientes reglas son las reglas de oro para el diseño de
GUI, descritas por Shneiderman y Plaisant en su libro (Diseño de la interfaz de
usuario).
 Esfuércese por la coherencia : se deben requerir secuencias consistentes de
acciones en situaciones similares. Se debe utilizar una terminología idéntica en
las indicaciones, menús y pantallas de ayuda. Se deben emplear comandos
consistentes en todo momento.
 Permita que los usuarios frecuentes usen atajos : el deseo del usuario de
reducir la cantidad de interacciones aumenta con la frecuencia de uso. Las
abreviaturas, las teclas de función, los comandos ocultos y las funciones de
macro son muy útiles para un usuario experto.
 Ofrecer comentarios informativos : para cada acción del operador, debe haber
comentarios del sistema. Para acciones frecuentes y menores, la respuesta debe
ser modesta, mientras que para acciones poco frecuentes e importantes, la
respuesta debe ser más sustancial.
 Diálogo de diseño para producir el cierre : las secuencias de acciones deben
organizarse en grupos con un principio, un medio y un final. La retroalimentación
informativa al completar un grupo de acciones brinda a los operadores la
satisfacción del logro, una sensación de alivio, la señal de abandonar los planes
de contingencia y las opciones de sus mentes, y esto indica que el camino por
delante está claro para prepararse para el próximo grupo de acciones.
 Ofrezca un manejo simple de errores : en la medida de lo posible, diseñe el
sistema para que el usuario no cometa un error grave. Si se comete un error, el
sistema debería poder detectarlo y ofrecer mecanismos simples y comprensibles
para manejar el error.
 Permitir la reversión fácil de acciones : esta característica alivia la ansiedad, ya
que el usuario sabe que los errores se pueden deshacer. La reversión fácil de
acciones fomenta la exploración de opciones desconocidas. Las unidades de
reversibilidad pueden ser una sola acción, una entrada de datos o un grupo
completo de acciones.
  Apoye el locus de control interno : los operadores experimentados desean
sentir que están a cargo del sistema y que el sistema responde a sus
acciones. Diseñe el sistema para que los usuarios sean los iniciadores de
acciones en lugar de los que responden.
 Reduzca la carga de memoria a corto plazo : la limitación del procesamiento de
información humana en la memoria a corto plazo requiere que las pantallas se
mantengan simples, se consoliden varias pantallas de página, se reduzca la
frecuencia de movimiento de la ventana y se asigne suficiente tiempo de
entrenamiento para códigos, mnemotécnicos, y secuencias de acciones.

Complejidad del diseño de software

El término complejidad significa estado de eventos o cosas, que tienen
múltiples enlaces interconectados y estructuras altamente complicadas. En la
programación de software, a medida que se realiza el diseño del software, la
cantidad de elementos y sus interconexiones gradualmente emergen para ser
enormes, lo que se vuelve demasiado difícil de entender de inmediato.
La complejidad del diseño de software es difícil de evaluar sin utilizar métricas
y medidas de complejidad. Veamos tres medidas importantes de complejidad
de software.

Medidas de complejidad de Halstead

En 1977, el Sr. Maurice Howard Halstead introdujo métricas para medir la
complejidad del software. Las métricas de Halstead dependen de la
implementación real del programa y sus medidas, que se calculan
directamente desde los operadores y los operandos desde el código fuente, de
manera estática. Permite evaluar el tiempo de prueba, vocabulario, tamaño,
dificultad, errores y esfuerzos para el código fuente C / C ++ / Java.
Según Halstead, "Un programa de computadora es una implementación de un
algoritmo considerado como una colección de tokens que se pueden clasificar
como operadores u operandos". Las métricas de Halstead piensan que un
programa es una secuencia de operadores y sus operandos asociados.
Define varios indicadores para verificar la complejidad del módulo.

Parámetro Sentido

n1 Número de operadores únicos.

n2 Número de operandos únicos

N1 Número de ocurrencia total de operadores

N2 Número de ocurrencia total de operandos

Cuando seleccionamos el archivo fuente para ver sus detalles de complejidad

en Metric Viewer, el siguiente resultado se ve en Metric Report:
Métrico Sentido Representación matemática

norte Vocabulario n1 + n2

norte Talla N1 + N2

V Volumen Longitud * Vocabulario Log2

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

mi Esfuerzos Dificultad * Volumen

si Errores Volumen / 3000

T Tiempo de prueba Tiempo = Esfuerzos / S, donde S = 18 segundos.

Medidas de complejidad ciclomática

Cada programa abarca declaraciones para ejecutar con el fin de realizar
alguna tarea y otras declaraciones de toma de decisiones que deciden qué
declaraciones deben ejecutarse. Estas construcciones de toma de decisiones
cambian el flujo del programa.
Si comparamos dos programas del mismo tamaño, el que tenga más
declaraciones de toma de decisiones será más complejo ya que el control del
programa salta con frecuencia.
McCabe, en 1976, propuso la Medida de Complejidad Ciclomática para
cuantificar la complejidad de un software dado. Es un modelo basado en
gráficos que se basa en las construcciones de toma de decisiones del
programa, como las declaraciones if-else, do-while, repeat-until, switch-case y
goto.
Proceso para hacer un gráfico de control de flujo:

 Romper el programa en bloques más pequeños, delimitados por construcciones de

toma de decisiones.
 Cree nodos que representen cada uno de estos nodos.
 Conecte los nodos de la siguiente manera:
o Si el control puede ramificarse del bloque i al bloque j
Dibujar un arco
o Del nodo de salida al nodo de entrada
Dibuja un arco.
Para calcular la complejidad ciclomática de un módulo de programa, utilizamos
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 anterior 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

exceder 10.

Punto de función
Es ampliamente utilizado para medir el tamaño del software. Function Point se
concentra en la funcionalidad proporcionada por el sistema. Las
características y la funcionalidad del sistema se utilizan para medir la
complejidad del software.
El punto de función cuenta con cinco parámetros, denominados Entrada
externa, Salida externa, Archivos internos lógicos, Archivos de interfaz externa
y Consulta externa. Para considerar la complejidad del software, cada
parámetro se clasifica además como simple, promedio o complejo.
Veamos los parámetros del punto de función:

Entrada externa

Cada entrada única al sistema, desde el exterior, se considera como entrada

externa. Se mide la unicidad de la entrada, ya que no hay dos entradas que
tengan los mismos formatos. Estas entradas pueden ser datos o parámetros
de control.
 Simple : si el recuento de entrada es bajo y afecta menos archivos internos
 Complejo : si el recuento de entrada es alto y afecta a más archivos internos
 Promedio : entre simple y complejo.

Salida externa

Todos los tipos de salida proporcionados por el sistema se cuentan en esta

categoría. La salida se considera única si su formato de salida y / o
procesamiento son únicos.
 Simple : si el recuento de salida es bajo
 Complejo : si el recuento de salida es alto
 Promedio : entre simple y complejo.

Archivos internos lógicos

Cada sistema de software mantiene archivos internos para mantener su

información funcional y funcionar correctamente. 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 de registro es bajo
 Complejo : si el número de tipos de registro es alto
 Promedio : entre simple y complejo.

Archivos de interfaz externa

El sistema de software puede necesitar compartir sus archivos con algún

software externo o puede necesitar pasar el archivo para su procesamiento o
como parámetro a alguna función. Todos estos archivos se cuentan como
archivos de interfaz externos.
 Simple : si el número de tipos de registro en el archivo compartido es bajo
 Complejo : si el número de tipos de registro en el archivo compartido es alto
 Promedio : entre simple y complejo.

Consulta externa

Una consulta es una combinación de entrada y salida, donde el usuario envía

algunos datos para preguntar como entrada y el sistema responde al usuario
con la salida de la consulta procesada. La complejidad de una consulta es
más que Entrada externa y Salida externa. Se dice que la consulta es única si
su entrada y salida son únicas en términos de formato y datos.
 Simple : si la consulta necesita un procesamiento bajo y produce una pequeña
cantidad de datos de salida
 Complejo : si la consulta necesita un proceso alto y produce una gran cantidad de
datos de salida
 Promedio : entre simple y complejo.
A cada uno de estos parámetros en el sistema se le asigna un peso de
acuerdo con su clase y complejidad. La siguiente tabla menciona el peso dado
a cada parámetro:

Parámetro Sencillo Promedio Complejo

Entradas 3 44 66

Salidas 44 55 77

Investigación 3 44 66

Archivos 77 10 15

Interfaces 55 77 10

La tabla anterior arroja puntos de función sin procesar. Estos puntos de

función se ajustan según la complejidad del entorno. El sistema se describe
utilizando catorce características diferentes:
  Transmisión de datos
 Procesamiento distribuido
 Objetivos de rendimiento
 Carga de configuración de la operación
 Tasa de transacción
 Entrada de datos en línea,
 Eficiencia del usuario final
 Actualización en línea
 Lógica de procesamiento compleja
 Reutilización
 Facilidad de instalación
 Facilidad operacional
 Múltiples sitios
 Deseo de facilitar los cambios.
Estos factores de características se clasifican de 0 a 5, como se menciona a
continuación:

 Sin influencia
 Incidental
 Moderar
 Promedio
 Significativo
 Esencial
Todas las clasificaciones se resumen como N. El valor de N varía de 0 a 70
(14 tipos de características x 5 tipos de clasificaciones). Se usa para calcular
Factores de Ajuste de Complejidad (CAF), usando las siguientes fórmulas:
CAF = 0.65 + 0.01N
Luego,
Puntos de función entregados ( FP ) = CAF x FP sin procesar
Este FP se puede usar en varias métricas, como:
Costo = $ / FP
Calidad = Errores / FP
Productividad = FP / persona-mes

Implementación de software
En este capítulo, estudiaremos los métodos de programación, la
documentación y los desafíos en la implementación de software.

Programación estructurada
En el proceso de codificación, las líneas de código siguen multiplicándose, por
lo tanto, el tamaño del software aumenta. Gradualmente, se vuelve casi
imposible recordar el flujo del programa. Si uno olvida cómo se construyen el
software y sus programas, archivos y procedimientos subyacentes, se vuelve
muy difícil compartir, depurar y modificar el programa. La solución a esto es la
programación estructurada. Alienta al desarrollador a usar subrutinas y bucles
en lugar de usar saltos simples en el código, lo que aporta claridad en el
código y mejora su eficiencia. La programación estructurada también ayuda al
programador a reducir el tiempo de codificación y organizar el código
correctamente.
La programación estructurada indica cómo se codificará el programa. La
programación estructurada utiliza tres conceptos principales:
 Análisis de arriba hacia abajo : siempre se hace un software para realizar un
trabajo racional. Este trabajo racional se conoce como problema en el lenguaje
del software. Por lo tanto, es muy importante que comprendamos cómo resolver el
problema. Bajo el análisis de arriba hacia abajo, el problema se divide en
pequeños pedazos donde cada uno tiene algún significado. Cada problema se
resuelve individualmente y los pasos se indican claramente sobre cómo resolver
el problema.
 Programación modular : durante la programación, el código se divide en un
grupo más pequeño de instrucciones. Estos grupos se conocen como módulos,
subprogramas o subrutinas. Programación modular basada en la comprensión del
análisis de arriba hacia abajo. Desalienta los saltos usando declaraciones 'goto'
en el programa, lo que a menudo hace que el flujo del programa no sea
rastreable. Los saltos están prohibidos y se fomenta el formato modular en la
programación estructurada.
 Codificación estructurada : en referencia al análisis de arriba hacia abajo, la
codificación estructurada subdivide los módulos en unidades de código más
pequeñas en el orden de su ejecución. La programación estructurada usa una
estructura de control, que controla el flujo del programa, mientras que la
codificación estructurada usa una estructura de control para organizar sus
instrucciones en patrones definibles.

Programacion Funcional
La programación funcional es un estilo de lenguaje de programación, que
utiliza los conceptos de funciones matemáticas. Una función en matemáticas
siempre debe producir el mismo resultado al recibir el mismo argumento. En
lenguajes de procedimiento, el flujo del programa se ejecuta a través de
procedimientos, es decir, el control del programa se transfiere al procedimiento
llamado. Mientras el flujo de control se transfiere de un procedimiento a otro, el
programa cambia su estado.
En la programación de procedimientos, es posible que un procedimiento
produzca resultados diferentes cuando se llama con el mismo argumento, ya
que el programa en sí puede estar en un estado diferente mientras lo
llama. Esta es una propiedad, así como un inconveniente de la programación
de procedimientos, en la que la secuencia o el momento de la ejecución del
procedimiento se vuelve importante.
La programación funcional proporciona medios de cálculo como funciones
matemáticas, lo que produce resultados independientemente del estado del
programa. Esto hace posible predecir el comportamiento del programa.
La programación funcional utiliza los siguientes conceptos:
 Funciones de primera clase y de orden superior : estas funciones tienen la
capacidad de aceptar otra función como argumento o devuelven otras funciones
como resultados.
 Funciones puras : estas funciones no incluyen actualizaciones destructivas, es
decir, no afectan a ninguna E / S ni memoria y, si no están en uso, pueden
eliminarse fácilmente sin obstaculizar el resto del programa.
 Recursión : la recursión es una técnica de programación en la que una función se
llama a sí misma y repite el código del programa, a menos que coincida alguna
condición predefinida. La recursión es la forma de crear bucles en la
programación funcional.
 Evaluación estricta : es un método para evaluar la expresión pasada a una
función como argumento. La programación funcional tiene dos tipos de métodos
de evaluación, estrictos (ansiosos) o no estrictos (perezosos). La evaluación
estricta siempre evalúa la expresión antes de invocar la función. La evaluación no
estricta no evalúa la expresión a menos que sea necesaria.
 λ-calculus : la mayoría de los lenguajes de programación funcionales utilizan λ-
calculus como sus sistemas de tipos. Las expresiones λ se ejecutan al evaluarlas
a medida que ocurren.
Common Lisp, Scala, Haskell, Erlang y F # son algunos ejemplos de lenguajes
de programación funcionales.

Estilo de programación
El estilo de programación es un conjunto de reglas de codificación seguidas
por todos los programadores para escribir el código. Cuando varios
programadores trabajan en el mismo proyecto de software, con frecuencia
necesitan trabajar con el código del programa escrito por algún 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 nombres de funciones y
variables relevantes para la tarea prevista, el uso de sangría bien colocada, el
código de comentarios para la conveniencia del lector y la presentación
general del código. Esto hace que el código del programa sea legible y
comprensible para todos, lo que a su vez facilita la depuración y la resolución
de errores. Además, el estilo de codificación adecuado ayuda a facilitar la
documentación y la actualización.

Pautas de codificación

La práctica del estilo de codificación varía con las organizaciones, los sistemas
operativos y el lenguaje de codificación en sí.
Los siguientes elementos de codificación pueden definirse bajo las pautas de
codificación de una organización:
 Convenciones de nomenclatura : esta sección define cómo nombrar funciones,
variables, constantes y variables globales.
  Sangría : este es el espacio que queda al comienzo de la línea, generalmente 2-8
espacios en blanco o una sola pestaña.
 Espacio en blanco : generalmente se omite al final de la línea.
 Operadores : define las reglas de escritura de operadores matemáticos, de
asignación y lógicos. Por ejemplo, el operador de asignación '=' debe tener
espacio antes y después, como en "x = 2".
 Estructuras de control : las reglas de escribir if-then-else, case-switch, while-until
y para declaraciones de flujo de control únicamente y de forma anidada.
 Longitud de línea y ajuste : define cuántos caracteres deben estar allí en una
línea, principalmente una línea de 80 caracteres. El ajuste define cómo se debe
ajustar una línea, si es demasiado larga.
 Funciones : define cómo deben declararse e invocarse las funciones, con y sin
parámetros.
 Variables : menciona cómo se declaran y definen variables de diferentes tipos de
datos.
 Comentarios : este es uno de los componentes de codificación importantes, ya
que los comentarios incluidos en el código describen lo que realmente hace el
código y todas las demás descripciones asociadas. Esta sección también ayuda a
crear documentaciones de ayuda para otros desarrolladores.

Documentación de software
La documentación del software es una parte importante del proceso del
software. Un documento bien escrito proporciona una gran herramienta y un
medio de repositorio de información necesario para conocer el proceso del
software. La documentación del software también proporciona información
sobre cómo usar el producto.
Una documentación bien mantenida debe incluir los siguientes documentos:
 Documentación de requisitos : esta documentación funciona como una
herramienta clave para que el diseñador de software, el desarrollador y el equipo
de prueba realicen sus tareas respectivas. Este documento contiene toda la
descripción funcional, no funcional y de comportamiento del software previsto.
La fuente de este documento puede ser datos previamente almacenados sobre el
software, que ya están ejecutando software al final del cliente, la entrevista, los
cuestionarios y la investigación del cliente. En general, se almacena en forma de
hoja de cálculo o documento de procesamiento de texto con el equipo de gestión
de software de alta gama.
Esta documentación funciona como base para el desarrollo del software y se
utiliza principalmente en las fases de verificación y validación. La mayoría de los
casos de prueba se crean directamente a partir de la documentación de
requisitos.
 Documentación de diseño de software : estas documentaciones contienen toda
la información necesaria, necesaria para construir el
software. Contiene: (a) Arquitectura de software de alto nivel, (b) Detalles de
diseño de software, (c) Diagramas de flujo de datos, (d) Diseño de base de datos
Estos documentos funcionan como repositorio para que los desarrolladores
implementen el software. Aunque estos documentos no brindan detalles sobre
 cómo codificar el programa, brindan toda la información necesaria que se requiere
para la codificación y la implementación.
 Documentación técnica : los desarrolladores y los codificadores reales
mantienen estas documentaciones. Estos documentos, en su conjunto,
representan información sobre el código. Mientras escriben el código, los
programadores también mencionan el objetivo del código, quién lo escribió, dónde
será requerido, qué hace y cómo lo hace, qué otros recursos usa el código, etc.
La documentación técnica aumenta la comprensión entre varios programadores
que trabajan en el mismo código. Mejora la capacidad de reutilización del
código. Hace que la depuración sea fácil y rastreable.
Hay varias herramientas automatizadas disponibles y algunas vienen con el
lenguaje de programación en sí. Por ejemplo, Java viene con la herramienta
JavaDoc para generar documentación técnica de código.
 Documentación del usuario : esta documentación es diferente de todo lo
explicado anteriormente. Todas las documentaciones anteriores se mantienen
para proporcionar información sobre el software y su proceso de desarrollo. Pero
la documentación del usuario explica cómo debería funcionar el producto de
software y cómo debería utilizarse para obtener los resultados deseados.
Estas documentaciones pueden incluir procedimientos de instalación de software,
guías prácticas, guías de usuario, método de desinstalación y referencias
especiales para obtener más información, como actualización de licencias, etc.

Desafíos de implementación de software

El equipo de desarrollo enfrenta algunos desafíos al implementar el
software. Algunos de ellos se mencionan a continuación:
 Reutilización de código : las interfaces de programación de los lenguajes
actuales son muy sofisticadas y están equipadas con enormes funciones de
biblioteca. Aún así, para reducir el costo del producto final, la administración de la
organización prefiere reutilizar el código, que fue creado anteriormente para algún
otro software. Los programadores enfrentan grandes problemas para las
comprobaciones de compatibilidad y para decidir cuánto código reutilizar.
 Gestión de versiones : cada vez que se emite un nuevo software al cliente, los
desarrolladores deben mantener la documentación relacionada con la versión y la
configuración. Esta documentación debe ser muy precisa y estar disponible a
tiempo.
 Target-Host : el programa de software, que se está desarrollando en la
organización, debe diseñarse para máquinas host en el extremo del cliente. Pero
a veces, es imposible diseñar un software que funcione en las máquinas de
destino.

Descripción general de las pruebas de

software
La prueba de software es una evaluación del software con respecto a los
requisitos recopilados de los usuarios y las especificaciones del sistema. Las
pruebas se realizan a nivel de fase en el ciclo de vida de desarrollo de
software o a nivel de módulo en el código del programa. Las pruebas de
software se componen de Validación y Verificación.
Validación de software
La validación es el proceso de examinar si el software satisface o no los
requisitos del usuario. Se lleva a cabo al final del SDLC. Si el software cumple
con los requisitos para los que fue creado, se valida.

 La validación asegura que el producto en desarrollo cumple con los requisitos del
usuario.
 La validación responde a la pregunta: "¿Estamos desarrollando el producto que
intenta todo lo que el usuario necesita de este software?".
 La validación enfatiza los requisitos del usuario.

Verificación de software
La verificación es el proceso de confirmar si el software cumple con los
requisitos comerciales y se desarrolla siguiendo las especificaciones y
metodologías adecuadas.

 La verificación asegura que el producto que se está desarrollando cumple con las
especificaciones de diseño.
 La verificación responde a la pregunta: "¿Estamos desarrollando este producto
siguiendo firmemente todas las especificaciones de diseño?"
 Las verificaciones se concentran en el diseño y las especificaciones del sistema.
Los objetivos de la prueba son:
 Errores : estos son errores de codificación reales cometidos por los
desarrolladores. Además, hay una diferencia en la salida del software y la salida
deseada, se considera como un error.
 Falla : cuando existe un error, se produce una falla. Una falla, también conocida
como error, es el resultado de un error que puede causar fallas en el sistema.
 Falla : se dice que la falla es la incapacidad del sistema para realizar la tarea
deseada. La falla ocurre cuando existe una falla en el sistema.

Manual vs pruebas automatizadas

Las pruebas pueden realizarse manualmente o utilizando una herramienta de
prueba automatizada:
 Manual : esta prueba se realiza sin la ayuda de herramientas de prueba
automatizadas. El probador de software prepara casos de prueba para diferentes
secciones y niveles del código, ejecuta las pruebas e informa el resultado al
gerente.
Las pruebas manuales consumen mucho tiempo y recursos. El probador necesita
confirmar si se usan o no los casos de prueba correctos. La mayor parte de las
pruebas implica pruebas manuales.
 Automatizado Esta prueba es un procedimiento de prueba realizado con la ayuda
de herramientas de prueba automatizadas. Las limitaciones con las pruebas
manuales se pueden superar utilizando herramientas de prueba automatizadas.
Una prueba debe verificar si se puede abrir una página web en Internet
Explorer. Esto se puede hacer fácilmente con pruebas manuales. Pero para
verificar si el servidor web puede soportar la carga de 1 millón de usuarios, es
bastante imposible probarlo manualmente.
Existen herramientas de software y hardware que ayudan al probador a
realizar pruebas de carga, pruebas de estrés y pruebas de regresión.

Enfoques de prueba
Las pruebas se pueden realizar en base a dos enfoques:

 Prueba de funcionalidad
 Pruebas de implementación
Cuando se prueba la funcionalidad sin tener en cuenta 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 prueba la funcionalidad sino que también se
analiza la forma en que se implementa.
Las pruebas exhaustivas son el método más deseado para una prueba
perfecta. Se prueba cada valor posible en el rango de los valores de entrada y
salida. No es posible probar todos y cada uno de los valores en el escenario
del mundo real si el rango de valores es grande.

Prueba de caja negra

Se lleva a cabo para probar la funcionalidad del programa. También se llama

prueba de "comportamiento". El probador en este caso, tiene un conjunto de
valores de entrada y los resultados deseados respectivos. Al proporcionar la
entrada, si la salida coincide con los resultados deseados, el programa se
prueba 'bien', y de lo contrario es problemático.

En este método de prueba, el probador no conoce el diseño y la estructura del

código, y los ingenieros de prueba y los usuarios finales realizan esta prueba
en el software.
Técnicas de prueba de caja negra:
 Clase de equivalencia : la entrada se divide en clases similares. Si un elemento
de una clase pasa la prueba, se supone que se pasa toda la clase.
 Valores límite : la entrada se divide en valores finales superiores e inferiores. Si
estos valores pasan la prueba, se supone que todos los valores intermedios
también pueden pasar.
  Gráfico de causa-efecto : en ambos métodos anteriores, solo se prueba un valor
de entrada a la vez. Causa (entrada): el efecto (salida) es una técnica de prueba
en la que las combinaciones de valores de entrada se prueban de manera
sistemática.
 Prueba por pares : el comportamiento del software depende de múltiples
parámetros. En las pruebas por pares, los múltiples parámetros se prueban por
pares para sus diferentes valores.
 Pruebas basadas en estado: el sistema cambia de estado al proporcionar
entrada. Estos sistemas se prueban en función de sus estados y aportes.

Prueba de caja blanca

Se lleva a cabo para probar el programa y su implementación, con el fin de

mejorar la eficiencia o la estructura del código. También se conoce como
prueba 'estructural'.

En este método de prueba, el probador conoce el diseño y la estructura del

código. Los programadores del código realizan esta prueba en el código.
Las siguientes son algunas técnicas de prueba de caja blanca:
 Prueba de flujo de control : el propósito de la prueba de flujo de control para
configurar casos de prueba que cubran todas las declaraciones y condiciones de
ramificación. Las condiciones de la rama se prueban para que sean verdaderas y
falsas, de modo que se puedan cubrir todas las declaraciones.
 Prueba de flujo de datos : esta técnica de prueba hace hincapié en cubrir todas
las variables de datos incluidas en el programa. Comprueba dónde se declararon
y definieron las variables y dónde se usaron o cambiaron.

Niveles de prueba
Las pruebas en sí pueden definirse en varios niveles de SDLC. El proceso de
prueba se ejecuta en paralelo al desarrollo de software. Antes de saltar a la
siguiente etapa, se prueba, valida y verifica una etapa.
Las pruebas por separado se realizan solo para asegurarse de que no quedan
errores ocultos o problemas en el software. El software se prueba en varios
niveles:

Examen de la unidad

Mientras codifica, el programador realiza algunas pruebas en esa unidad de

programa para saber si está libre de errores. La prueba se realiza bajo un
enfoque de prueba de caja blanca. Las pruebas unitarias ayudan a los
desarrolladores a decidir que las unidades individuales del programa
funcionan según los requisitos y están libres de errores.

Pruebas de integración

Incluso si las unidades de software funcionan bien individualmente, es

necesario averiguar si las unidades integradas juntas también funcionarían sin
errores. Por ejemplo, pasar argumentos y actualizar datos, etc.

Prueba de sistema

El software se compila como producto y luego se prueba como un todo. Esto

se puede lograr usando una o más de las siguientes pruebas:
 Prueba de funcionalidad : prueba todas las funcionalidades del software según el
requisito.
 Pruebas de rendimiento : esta prueba demuestra la eficacia del software. Prueba
la efectividad y el tiempo promedio que tarda el software en realizar la tarea
deseada. Las pruebas de rendimiento se realizan mediante pruebas de carga y
pruebas de esfuerzo en las que el software se somete a una alta carga de
usuarios y datos en diversas condiciones ambientales.
 Seguridad y portabilidad : estas pruebas se realizan cuando el software está
diseñado para funcionar en varias plataformas y se accede por número de
personas.

Test de aceptación

Cuando el software está listo para entregar al cliente, tiene que pasar por la
última fase de prueba donde se prueba la interacción y respuesta del
usuario. Esto es importante porque incluso si el software cumple con todos los
requisitos del usuario y si al usuario no le gusta la forma en que aparece o
funciona, puede ser rechazado.
 Pruebas alfa : el propio equipo de desarrolladores realiza pruebas alfa utilizando
el sistema como si se estuviera utilizando en un entorno de trabajo. Intentan
descubrir cómo reaccionaría el usuario ante alguna acción en el software y cómo
el sistema debería responder a las entradas.
 Prueba beta : después de que el software se prueba internamente, se entrega a
los usuarios para que lo usen en su entorno de producción solo con fines de
prueba. Este todavía no es el producto entregado. Los desarrolladores esperan
que los usuarios en esta etapa traigan problemas diminutos, que se omitieron
para asistir.

Pruebas de regresión

Cada vez que un producto de software se actualiza con un nuevo código,

característica o funcionalidad, se prueba exhaustivamente para detectar si hay
algún impacto negativo del código agregado. Esto se conoce como prueba de
regresión.
Documentación de prueba
Los documentos de prueba se preparan en diferentes etapas:

Antes de la prueba

Las pruebas comienzan con la generación de casos de prueba. Los siguientes

documentos son necesarios para referencia:
 Documento SRS - Documento de requisitos funcionales
 Documento de política de prueba : describe hasta qué punto deben realizarse
las pruebas antes de lanzar el producto.
 Documento de estrategia de prueba : menciona aspectos detallados del equipo
de prueba, matriz de responsabilidad y derechos / responsabilidad del gerente de
prueba y el ingeniero de prueba.
 Documento de matriz de trazabilidad : este es un documento SDLC, que está
relacionado con el proceso de recopilación de requisitos. A medida que surgen
nuevos requisitos, se agregan a esta matriz. Estas matrices ayudan a los
evaluadores a conocer la fuente del requisito. Se pueden rastrear hacia adelante y
hacia atrás.

Mientras se prueba

Es posible que se requieran los siguientes documentos mientras se inicia y se

realiza la prueba:
 Documento de caso de prueba : este documento contiene una lista de las
pruebas que deben realizarse. Incluye plan de prueba de unidad, plan de prueba
de integración, plan de prueba del sistema y plan de prueba de aceptación.
 Descripción de la prueba : este documento es una descripción detallada de
todos los casos de prueba y procedimientos para ejecutarlos.
 Informe de caso de prueba : este documento contiene un informe de caso de
prueba como resultado de la prueba.
 Registros de prueba : este documento contiene registros de prueba para cada
informe de caso de prueba.

Después de la prueba

Los siguientes documentos pueden generarse después de la prueba:

 Resumen de prueba : este resumen de prueba es un análisis colectivo de todos
los informes y registros de prueba. Resume y concluye si el software está listo
para ser lanzado. El software se lanza bajo el sistema de control de versiones si
está listo para iniciarse.

Pruebas versus control de calidad, garantía de calidad

y auditoría
Necesitamos entender que las pruebas de software son diferentes del control
de calidad del software, el control de calidad del software y la auditoría del
software.
 Aseguramiento de la calidad del software : estos son medios de monitoreo del
proceso de desarrollo de software, mediante los cuales se garantiza que todas las
medidas se toman según los estándares de la organización. Esta supervisión se
realiza para garantizar que se siguieron los métodos de desarrollo de software
adecuados.
 Control de calidad del software : este es un sistema para mantener la calidad
del producto de software. Puede incluir aspectos funcionales y no funcionales del
producto de software, que mejoran la buena voluntad de la organización. Este
sistema se asegura de que el cliente reciba un producto de calidad para sus
requisitos y el producto certificado como "apto para su uso".
 Auditoría de software : esta es una revisión del procedimiento utilizado por la
organización para desarrollar el software. Un equipo de auditores, independiente
del equipo de desarrollo, examina el proceso, el procedimiento, los requisitos y
otros aspectos del software SDLC. El propósito de la auditoría de software es
verificar que el software y su proceso de desarrollo cumplan con los estándares,
reglas y regulaciones.

Descripción general del mantenimiento del

software
El mantenimiento de software es una parte ampliamente aceptada de SDLC
hoy en día. Representa todas las modificaciones y actualizaciones realizadas
después de la entrega del producto de software. Existen varias razones por las
cuales se requieren modificaciones, algunas de ellas se mencionan
brevemente a continuación:
 Condiciones del mercado : las políticas, que cambian con el tiempo, como los
impuestos y las restricciones introducidas recientemente, como la forma de
mantener la contabilidad, pueden provocar la necesidad de modificaciones.
 Requisitos del cliente : con el tiempo, el cliente puede solicitar nuevas
características o funciones en el software.
 Modificaciones de host : si cambia el hardware o la plataforma (como el sistema
operativo) del host de destino, se necesitan cambios de software para mantener la
adaptabilidad.
 Cambios en la organización : si hay algún cambio en el nivel comercial en el
extremo del cliente, como la reducción de la fortaleza de la organización, la
adquisición de otra compañía, la organización para incursionar en nuevos
negocios, puede surgir la necesidad de modificar el software original.

Tipos de mantenimiento
En la vida útil del software, el tipo de mantenimiento puede variar según su
naturaleza. Puede ser solo una tarea de mantenimiento de rutina como algún
error descubierto por algún usuario o puede ser un gran evento en sí mismo
según el tamaño o la naturaleza del mantenimiento. Los siguientes son
algunos tipos de mantenimiento basados en sus características:
  Mantenimiento correctivo : esto incluye modificaciones y actualizaciones
realizadas para corregir o corregir problemas, que son descubiertos por el usuario
o concluidos por los informes de error del usuario.
 Mantenimiento adaptativo : esto incluye modificaciones y actualizaciones
aplicadas para mantener el producto de software actualizado y en sintonía con el
mundo cambiante de la tecnología y el entorno empresarial.
 Mantenimiento perfecto : esto incluye modificaciones y actualizaciones
realizadas para mantener el software utilizable durante un largo período de
tiempo. Incluye nuevas características, nuevos requisitos de usuario para refinar
el software y mejorar su confiabilidad y rendimiento.
 Mantenimiento preventivo : esto incluye modificaciones y actualizaciones para
evitar futuros problemas del software. Su objetivo es atender los problemas, que
no son significativos en este momento pero que pueden causar serios problemas
en el futuro.

Costo de mantenimiento
Los informes sugieren que el costo de mantenimiento es alto. Un estudio
sobre la estimación del mantenimiento del software encontró que el costo de
mantenimiento es tan alto como el 67% del costo del ciclo completo del
proceso del software.

En promedio, el costo del mantenimiento del software es más del 50% de

todas las fases SDLC. Hay varios factores que provocan que el costo de
mantenimiento aumente, como:

Factores del mundo real que afectan el costo de mantenimiento

 La edad estándar de cualquier software se considera hasta 10 a 15 años.

  Los softwares más antiguos, que estaban destinados a funcionar en máquinas
lentas con menos memoria y capacidad de almacenamiento, no pueden
mantenerse desafiantes frente a los softwares mejorados que vienen
recientemente en el hardware moderno.
 A medida que avanza la tecnología, resulta costoso mantener el software antiguo.
 La mayoría de los ingenieros de mantenimiento son novatos y utilizan el método de
prueba y error para corregir el problema.
 A menudo, los cambios realizados pueden dañar fácilmente la estructura original
del software, lo que dificulta cualquier cambio posterior.
 Los cambios a menudo quedan sin documentar, lo que puede causar más
conflictos en el futuro.

Factores finales del software que afectan el costo de mantenimiento

 Estructura del programa de software
 Lenguaje de programación
 Dependencia del entorno externo.
 Fiabilidad y disponibilidad del personal.

Actividades de mantenimiento
IEEE proporciona un marco para actividades de proceso de mantenimiento
secuencial. Se puede usar de manera iterativa y se puede extender para que
se puedan incluir elementos y procesos personalizados.

Estas actividades van de la mano con cada una de las siguientes fases:
  Identificación y rastreo : implica actividades relacionadas con la identificación de
requisitos de modificación o mantenimiento. Es generado por el usuario o el
sistema mismo puede informar a través de registros o mensajes de error. Aquí, el
tipo de mantenimiento también se clasifica.
 Análisis : la modificación se analiza por su impacto en el sistema, incluidas las
implicaciones de seguridad y protección. Si el impacto probable es severo, se
busca una solución alternativa. Un conjunto de modificaciones requeridas se
materializa en especificaciones de requisitos. Se analiza el costo de modificación /
mantenimiento y se concluye la estimación.
 Diseño : los nuevos módulos, que deben reemplazarse o modificarse, están
diseñados según las especificaciones de requisitos establecidas en la etapa
anterior. Los casos de prueba se crean para validación y verificación.
 Implementación : los nuevos módulos se codifican con la ayuda del diseño
estructurado creado en el paso de diseño. Se espera que cada programador
realice pruebas unitarias en paralelo.
 Prueba del sistema: la prueba de integración se realiza entre los módulos recién
creados. Las pruebas de integración también se llevan a cabo entre los nuevos
módulos y el sistema. Finalmente, el sistema se prueba como un todo, siguiendo
procedimientos de prueba regresivos.
 Prueba de aceptación : después de probar el sistema internamente, se prueba su
aceptación con la ayuda de los usuarios. Si en este estado, el usuario se queja de
algunos problemas que se abordan o se señalan para abordar en la próxima
iteración.
 Entrega : después de la prueba de aceptación, el sistema se implementa en toda
la organización mediante un pequeño paquete de actualización o una instalación
nueva del sistema. La prueba final se lleva a cabo en el extremo del cliente
después de que se entrega el software.
Se proporciona un centro de capacitación si es necesario, además de la copia
impresa del manual del usuario.
 Gestión del mantenimiento: la gestión de la configuración es una parte esencial
del mantenimiento del sistema. Se ayuda con herramientas de control de
versiones para controlar versiones, semi-versiones o gestión de parches.

Reingeniería de software
Cuando necesitamos actualizar el software para mantenerlo en el mercado
actual, sin afectar su funcionalidad, se llama reingeniería de software. Es un
proceso minucioso donde se cambia el diseño del software y se reescriben los
programas.
El software heredado no puede seguir sintonizándose con la última tecnología
disponible en el mercado. A medida que el hardware se vuelve obsoleto, la
actualización del software se convierte en un dolor de cabeza. Incluso si el
software envejece con el tiempo, su funcionalidad no lo hace.
Por ejemplo, inicialmente Unix se desarrolló en lenguaje ensamblador. Cuando
surgió el lenguaje C, Unix fue rediseñado en C, porque trabajar en lenguaje
ensamblador era difícil.
Aparte de esto, a veces los programadores notan que pocas partes del
software necesitan más mantenimiento que otras y también necesitan
reingeniería.

Proceso de reingeniería
 Decide qué volver a diseñar. ¿Es todo el software o parte de él?
 Realice ingeniería inversa para obtener especificaciones del software existente.
 Reestructurar el programa si es necesario. Por ejemplo, cambiar programas
orientados a funciones en programas orientados a objetos.
 Reestructurar los datos según sea necesario.
 Aplique los conceptos de ingeniería avanzada para obtener un software
rediseñado.
Hay pocos términos importantes utilizados en la reingeniería de software

Ingeniería inversa

Es un proceso para lograr la especificación del sistema analizando a fondo y

entendiendo el sistema existente. Este proceso puede verse como un modelo
SDLC inverso, es decir, tratamos de obtener un nivel de abstracción más alto
analizando niveles de abstracción más bajos.
Un sistema existente es un diseño implementado previamente, del cual no
sabemos nada. Luego, los diseñadores realizan ingeniería inversa al mirar el
código e intentar obtener el diseño. Con el diseño en mano, intentan concluir
las especificaciones. Por lo tanto, ir en reversa del código a la especificación
del sistema.
Programa de reestructuración

Es un proceso para reestructurar y reconstruir el software existente. Se trata

de reorganizar el código fuente, ya sea en el mismo lenguaje de programación
o de un lenguaje de programación a uno diferente. La reestructuración puede
tener una reestructuración del código fuente y una reestructuración de datos o
ambas.
La reestructuración no afecta la funcionalidad del software, pero mejora la
confiabilidad y la facilidad de mantenimiento. Los componentes del programa,
que causan errores con mucha frecuencia, se pueden cambiar o actualizar con
la reestructuración.
La fiabilidad del software en una plataforma de hardware obsoleta se puede
eliminar mediante la reestructuración.

Ingeniería Adelante

La ingeniería avanzada es un proceso para obtener el software deseado a

partir de las especificaciones disponibles que se redujeron mediante ingeniería
inversa. Se supone que ya se realizó alguna ingeniería de software en el
pasado.
La ingeniería avanzada es igual que el proceso de ingeniería de software con
solo una diferencia: se lleva a cabo siempre después de la ingeniería inversa.

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

Ejemplo

Los procedimientos de inicio de sesión utilizados en la web pueden

considerarse como componentes, el sistema de impresión en el software
puede verse como un componente del software.
Los componentes tienen una alta cohesión de funcionalidad y una menor tasa
de acoplamiento, es decir, funcionan de forma independiente y pueden realizar
tareas sin depender de otros módulos.
En OOP, los objetos que se diseñan son muy específicos para su
preocupación y tienen menos posibilidades de ser utilizados en algún otro
software.
En la programación modular, los módulos están codificados para realizar
tareas específicas que se pueden utilizar en varios otros programas de
software.
Hay una vertical completamente nueva, que se basa en la reutilización de
componentes de software, y se conoce como Ingeniería de Software Basada
en Componentes (CBSE).

La reutilización se puede hacer en varios niveles.

 Nivel de aplicación : cuando se utiliza una aplicación completa como subsistema
de software nuevo.
 Nivel de componente : donde se utiliza el subsistema de una aplicación.
 Nivel de módulos : donde se reutilizan los módulos funcionales.
Los componentes de software proporcionan interfaces que se pueden utilizar para
establecer comunicación entre diferentes componentes.

Proceso de reutilización

Se pueden adoptar dos tipos de métodos: manteniendo los mismos requisitos

y ajustando los componentes o manteniendo los mismos componentes y
modificando los requisitos.
  Especificación de requisitos: se especifican los requisitos funcionales y no
funcionales, que un producto de software debe cumplir, con la ayuda del sistema
existente, la entrada del usuario o ambos.
 Diseño : este también es un paso estándar del proceso SDLC, donde los
requisitos se definen en términos de lenguaje de software. Se crea la arquitectura
básica del sistema en su conjunto y sus subsistemas.
 Especificar componentes : al estudiar el diseño del software, los diseñadores
segregan todo el sistema en componentes o subsistemas más pequeños. Un
diseño de software completo se convierte en una colección de un gran conjunto
de componentes que trabajan juntos.
 Buscar componentes adecuados : los diseñadores recomiendan el repositorio
de componentes de software para buscar el componente correspondiente, en
función de la funcionalidad y los requisitos de software previstos.
 Incorporar componentes : todos los componentes coincidentes se empaquetan
para darles forma de software completo.

Descripción general de las herramientas de

casos de software
CASO significa C omputer Un ided S oftware E ngineering. Significa,
desarrollo y mantenimiento de proyectos de software con la ayuda de varias
herramientas de software automatizadas.

Herramientas CASE
Las herramientas CASE son un conjunto de programas de aplicación de
software, que se utilizan para automatizar las actividades SDLC. Los
administradores de proyectos de software, analistas e ingenieros utilizan
herramientas CASE para desarrollar un sistema de software.
Hay varias herramientas CASE disponibles para simplificar varias etapas del
ciclo de vida del desarrollo de software, como herramientas de análisis,
herramientas de diseño, herramientas de gestión de proyectos, herramientas
de gestión de bases de datos, herramientas de documentación, por nombrar
algunas.
El uso de herramientas CASE acelera el desarrollo del proyecto para producir
el resultado deseado y ayuda a descubrir fallas antes de avanzar con la
siguiente etapa en el desarrollo de software.

Componentes de herramientas CASE

Las herramientas CASE se pueden dividir en términos generales en las
siguientes partes según su uso en una etapa SDLC particular:
 Repositorio central : las herramientas CASE requieren un repositorio central, que
puede servir como fuente de información común, integrada y coherente. El
repositorio central es un lugar central de almacenamiento donde se almacenan las
especificaciones del producto, los documentos de requisitos, los informes y
diagramas relacionados y otra información útil sobre la gestión. El repositorio
central también sirve como diccionario de datos.
  Herramientas de mayúsculas: las herramientas de mayúsculas y minúsculas se
utilizan en las etapas de planificación, análisis y diseño de SDLC.
 Herramientas de minúsculas: las herramientas de minúsculas se utilizan en la
implementación, prueba y mantenimiento.
 Herramientas integradas de casos: las herramientas integradas de CASE son
útiles en todas las etapas de SDLC, desde la recopilación de requisitos hasta las
pruebas y la documentación.
Las herramientas CASE se pueden agrupar si tienen una funcionalidad,
actividades de proceso y capacidad similares para integrarse con otras
herramientas.

Alcance de las herramientas de casos

El alcance de las herramientas CASE abarca todo el SDLC.

Tipos de herramientas de casos

Ahora revisamos brevemente varias herramientas CASE

Herramientas de diagrama

Estas herramientas se utilizan para representar los componentes del sistema,

los datos y el flujo de control entre varios componentes de software y la
estructura del sistema en forma gráfica. Por ejemplo, la herramienta Flow
Chart Maker para crear diagramas de flujo de última generación.

Herramientas de modelado de procesos

El modelado de procesos es un método para crear un modelo de proceso de

software, que se utiliza para desarrollar el software. Las herramientas de
modelado de procesos ayudan a los gerentes a elegir un modelo de proceso o
modificarlo según los requisitos del producto de software. Por ejemplo, EPF
Composer
Herramientas de gestión de proyectos

Estas herramientas se utilizan para la planificación de proyectos, la estimación

de costos y esfuerzos, la programación de proyectos y la planificación de
recursos. Los gerentes deben cumplir estrictamente la ejecución del proyecto
con cada paso mencionado en la gestión de proyectos de software. Las
herramientas de gestión de proyectos ayudan a almacenar y compartir
información del proyecto en tiempo real en toda la organización. Por ejemplo,
Creative Pro Office, Trac Project, Basecamp.

Herramientas de documentación

La documentación en un proyecto de software comienza antes del proceso del

software, abarca todas las fases del SDLC y después de la finalización del
proyecto.
Las herramientas de documentación generan documentos para usuarios
técnicos y usuarios finales. Los usuarios técnicos son en su mayoría
profesionales internos del equipo de desarrollo que se refieren al manual del
sistema, manual de referencia, manual de capacitación, manuales de
instalación, etc. Los documentos del usuario final describen el funcionamiento
y procedimientos del sistema, como el manual del usuario. Por ejemplo,
Doxygen, DrExplain, Adobe RoboHelp para documentación.

Herramientas de análisis

Estas herramientas ayudan a reunir los requisitos, comprueban

automáticamente cualquier inconsistencia, inexactitud en los diagramas,
redundancias de datos u omisiones erróneas. Por ejemplo, Accept 360,
Accompa, CaseComplete para análisis de requisitos, Visible Analyst para
análisis total.

Herramientas de diseño

Estas herramientas ayudan a los diseñadores de software a diseñar la

estructura de bloques del software, que puede desglosarse en módulos más
pequeños utilizando técnicas de refinamiento. Estas herramientas
proporcionan detalles de cada módulo e interconexiones entre módulos. Por
ejemplo, diseño de software animado

Herramientas de gestion de configuracion

Se lanza una instancia de software en una versión. Las herramientas de

gestión de configuración se ocupan de

 Gestión de versiones y revisiones.

 Gestión de configuración de línea de base
 Gestión de control de cambios
Las herramientas CASE ayudan en esto mediante el seguimiento automático,
la gestión de versiones y la gestión de versiones. Por ejemplo, Fossil, Git,
Accu REV.

Cambiar herramientas de control

Estas herramientas se consideran parte de las herramientas de administración

de configuración. Se ocupan de los cambios realizados en el software después
de que se fija su línea base o cuando se lanza el software por primera
vez. Las herramientas CASE automatizan el seguimiento de cambios, la
administración de archivos, la administración de códigos y más. También
ayuda a hacer cumplir la política de cambio de la organización.

Herramientas de programación

Estas herramientas consisten en entornos de programación como IDE

(Integrated Development Environment), biblioteca de módulos incorporados y
herramientas de simulación. Estas herramientas proporcionan una ayuda
integral en la creación de productos de software e incluyen características
para simulación y pruebas. Por ejemplo, Cscope para buscar código en C,
Eclipse.

Herramientas de prototipos

El prototipo de software es una versión simulada del producto de software

previsto. Prototype proporciona una apariencia inicial del producto y simula
pocos aspectos del producto real.
Las herramientas de creación de prototipos CASE vienen esencialmente con
bibliotecas gráficas. Pueden crear interfaces de usuario y diseño
independientes del hardware. Estas herramientas nos ayudan a construir
prototipos rápidos basados en la información existente. Además, proporcionan
simulación de prototipo de software. Por ejemplo, el compositor prototipo de
Serena, Mockup Builder.

Herramientas de desarrollo web

Estas herramientas ayudan a diseñar páginas web con todos los elementos
aliados como formularios, texto, guiones, gráficos, etc. Las herramientas web
también proporcionan una vista previa en vivo de lo que se está desarrollando
y cómo se verá una vez finalizado. Por ejemplo, Fontello, Adobe Edge Inspect,
Foundation 3, Brackets.

Herramientas de aseguramiento de calidad

El aseguramiento de la calidad en una organización de software es monitorear

el proceso de ingeniería y los métodos adoptados para desarrollar el producto
de software a fin de garantizar la conformidad de la calidad según los
estándares de la organización. Las herramientas de control de calidad
consisten en herramientas de configuración y control de cambios y
herramientas de prueba de software. Por ejemplo, SoapTest, AppsWatch,
JMeter.

Herramientas de mantenimiento

El mantenimiento del software incluye modificaciones en el producto de

software después de que se entrega. El registro automático y las técnicas de
informe de errores, la generación automática de tickets de error y el análisis de
causa raíz son pocas herramientas CASE, que ayudan a la organización del
software en la fase de mantenimiento de SDLC. Por ejemplo, Bugzilla para el
seguimiento de defectos, HP Quality Center.