Fases del Análisis y Diseño de Software

Esta fase consiste en elaborar el diseño arquitectónico del software. Primero, se analizan todos los datos disponibles (requerimientos) y, después, se elabora un diseño para recibir retroalimentación y pulirlo lo más posible.

Bases de Datos

Una **base de datos** es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso.

Componentes de una Base de Datos

• Campo: Dato, componente o variable asociado a un elemento (nombre, fecha, salario, etc.).
• Registro: Conjunto de campos asociados entre sí que definen una entidad o un elemento.
• Tabla: Conjunto de registros del mismo tipo.
• Actividades: Definición de los datos, mantenimiento de la integridad, seguridad y manipulación.
• Tipos de campos: Numérico, alfanumérico, fecha, lógico, memo, etc. Los campos pueden ser de entrada (fecha de nacimiento) o calculados (edad).

El dato es una representación simbólica (numérica, alfabética, algorítmica, etc.) de un atributo o variable cuantitativa.

Fases de la Construcción de Software

Definir los Componentes Físicos

Con componentes físicos nos referimos a hardware (pantallas, reportes y consultas). Lo importante de una pantalla es que contenga toda la información necesaria, debe tener todos los campos necesarios para determinado proceso, una secuencia lógica, una determinada estética y cumplir con todos los estándares de la empresa.

Desarrollo de Infraestructura

Durante esta fase, se desarrollará y organizará la infraestructura que permita cumplir las tareas de construcción de la forma más productiva posible.

Desarrollo de Unidades de Diseño Interactivas

Son procedimientos que se cumplen o se ejecutan a través de un diálogo usuario–sistema. Las actividades de esta sub-fase tienen como objetivo central:

• Especificar en detalle las tareas que debe cumplir la unidad de diseño.
• Desarrollar componentes.
• Realizar las pruebas unitarias y las pruebas de integración a nivel de la unidad de diseño.

Desarrollo de Unidades de Diseño Batch

Son procesos que se ejecutan sin la necesidad de que el usuario esté presente para alimentar datos o ejecutar comandos. Todo está escrito en un archivo que se ejecuta automáticamente.

Desarrollo de Unidades de Diseño Manuales

Esta sub-fase incluye las tareas que se ejecutan en forma manual que se incluyen dentro de los procedimientos administrativos.

Interfaz de Usuario (IU)

Es un conjunto de elementos hardware y software que presentan información al usuario y le permiten interactuar con el sistema. También se puede considerar parte de la IU la documentación (manuales, ayuda, referencia, tutoriales) que acompaña al hardware y al software.

Los archivos .Bat son archivos que ejecutan comandos batch, de ahí su nombre.

Cuando vamos a construir una interfaz, vamos a ver 3 perspectivas diferentes:

• Modelo del usuario: El usuario ve cómo quiere que el sistema funcione, careciendo de conocimientos técnicos, solo imagina cómo satisfacer sus necesidades y cómo debe hacerlo.
• Modelo del diseñador: Es el intermediario entre el usuario y el programador, transforma las necesidades en especificaciones.
• Modelo del programador: El programador tiene las herramientas y sabe cómo hacerlo, le dicen qué hacer y lo hace.

Herramientas para Realizar Pruebas de Software

Podemos encontrar herramientas Open Source (libres) o Comerciales (de pago). Estas herramientas podrán ser utilizadas para diferentes tipos de pruebas como: Herramientas de gestión de pruebas, Herramientas para pruebas funcionales, Herramientas para pruebas de carga y rendimiento, Herramientas Open Source, Herramientas de gestión de pruebas.

Tipos de Pruebas Según lo que Verifican

Pruebas Funcionales

Es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software (requisitos funcionales).

• Pruebas unitarias: Cuando uno mismo lo prueba.
• Pruebas de componentes: Este es el tipo de prueba que se hace sobre cada uno de los componentes del sistema de manera individual.
• Pruebas de integración: Validan que los distintos módulos del sistema interactúen correctamente entre sí.
• Pruebas de sistema: En este tipo de pruebas se verifica la funcionalidad del sistema completo, que lo haga con buena calidad y desempeño.
• Pruebas alpha: Son los mismos que los beta solo que enfocado a un cierto grupo determinado.
• Pruebas beta: Versión que suelta el fabricante para que lo utilicen, porque si se lanza a los usuarios es más barato en vez de contratar personal.
• Pruebas de aceptación: Son las pruebas que se hacen para medir, qué tanto el usuario considera que el sistema cumple con los requerimientos.
• Pruebas de humo: Son aquellas pruebas que pretenden evaluar la calidad de un producto de software previo a una recepción formal, ya sea al equipo de pruebas o al usuario final.
• Pruebas de regresión: Cualquier tipo de pruebas de software que intentan descubrir errores (bugs), carencias de funcionalidad.

Niveles de Prueba

Podemos considerar el proceso de pruebas funcionales como un proceso donde se va probando inicialmente de más bajo nivel y se van integrando y probando paulatinamente componentes hasta lograr un sistema completo totalmente probado.

Fase de Pruebas

Esta fase da inicio luego de que las diferentes unidades de diseño han sido desarrolladas y probadas por separado.

Niveles de Prueba

• De Sistema: Prueba desde el punto de vista de los niveles de calidad del sistema y de desempeño.
• De Integración: Capaz de integrarse con otros sistemas.
• De Aceptación Técnica: Desde 2 puntos de vista, del usuario y que lo pueda hacer.
• Funcional: Prueba desde el punto de vista de los requerimientos funcionales.

Si se cumplen estos niveles satisfactoriamente el sistema, se realiza la carga de los archivos, base de datos y tablas del nuevo sistema.

Para dar inicio al proceso de aceptación final, durante el cual, el sistema comenzará a funcionar bajo la responsabilidad del departamento de operaciones y del usuario, por un lapso determinado de tiempo llamado Periodo de Aceptación.

Las Pruebas de Software (software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada.

El objetivo de las pruebas es presentar información sobre la calidad del producto a las personas responsables de éste.

El objetivo de las pruebas es presentar información sobre la calidad del producto a las personas responsables de éste. Las pruebas de calidad presentan los siguientes objetivos:

• Encontrar defectos o bugs.
• Aumentar la confianza en el nivel de calidad.
• Facilitar información para la toma de decisiones.
• Evitar la aparición de defectos.

Tipos de Pruebas por su Ejecución

Pruebas Manuales

Son aquellas pruebas que se hacen sin utilizar software o programas para ayudarse.

Pruebas Automáticas

Se hacen a través de software.

• Pruebas Estáticas: Se realizan sin ejecutar el código de la aplicación.
• Pruebas Dinámicas: Se realizan ejecutando el sistema y verificando su comportamiento en tiempo real.

Enfoques de Pruebas

• Testing aleatorio (probar cualquier cosa que se nos ocurra).
• Pruebas de Caja blanca: Se revisa el código fuente y la lógica interna.
• Pruebas de Caja negra: Se evalúa el sistema sin conocer su estructura interna, centrado solo en las salidas para entradas específicas.

Pruebas de caja negra (enfoque en los resultados) vs caja blanca (enfoque en el proceso interno del sistema).

INFORMACIÓN: Son datos estructurados e interpretados (tienen que ser importantes para nosotros).

REGISTRO: Es un conjunto de campos.

TABLA: Un conjunto de registros del mismo tipo.

INDICE: Es una tabla que contiene claves de búsqueda y apuntadores.

UN ERP: Es un software que se dedica a manejar los procesos de la empresa. Es una serie de módulos en los cuales se cuentas, cuentas por pagar, pedidos, etc.

(El ERP más potente del mundo actual se llama «SAP»)

CRM (manejar clientes), MRP (manejar producción)

Principios para una Interfaz de Usuario

Principios que deben estar presentes en una interfaz de usuario:

1. ANTICIPACION: Es anticipar que el sistema se anticipe a lo que el usuario quiere.
2. AUTONOMÍA: El sistema le tiene que dar al usuario toda la autonomía posible, por ejemplo, en un procesador de texto que el usuario cambie la fuente, tamaño, color, etc. a la letra sin tener que pedírselo al programador. Que el usuario pueda configurar el sistema a sus necesidades.
3. CONTROL: Se necesita controlar al usuario, ya que la autonomía desmedida es perjudicial.
4. LA PERCEPCIÓN DEL COLOR: Nos sirve para transmitir mensajes, sentimientos, determinar acciones (utilizando estándares dentro de la aplicación), la legibilidad, estética.
5. VALORES PREDETERMINADOS: Debe de existir una opción que permita a los valores predeterminados/de fábrica.
6. CONSISTENCIA: Debemos de ser consistentes en nuestro sistema.
7. ESTRUCTURAS VISIBLES E INVISIBLES: Las VISIBLES son estructuras visibles que con un clic las alcanzas. Las INVISIBLES no se ven pero se pueden utilizar para realizar acciones, por ejemplo, el cómo agrandar una pantalla. Si por cuestiones del sistema no se debe de permitir, no se hace, pero en medida de lo posible se debe hacer.
8. USABILIDAD…
9. REDUCCION DE LATENCIA: …
10. AUDITORIA DE SISTEMAS: Es todo lo que sea una bitácora (una bitácora es un registro de todas las actividades). Es muy importante tener bitácoras (también se puede apagar), se necesita la bitácora para tener ATOMICIDAD.

    ATOMICIDAD: Es la capacidad de una computadora de regresar a un punto anterior si se realizó un proceso indeseado. (O se termina todo o no se hace nada, ese es el principio de ATOMICIDAD)

11. LEGIBILIDAD: Necesita ser legible en todo sentido (estética).

3 PRINCIPIOS PARA LA INTERFAZ: ESTÉTICA