Software Punto de Venta (POS)
El objetivo del software de punto de venta (POS) es registrar en el sistema las ventas efectuadas en la tienda y la administración del dinero recibido, ya sea efectivo, cheques, tarjetas de crédito, vales, etc. Además, permite el control de las compras, de los inventarios y la capacidad de interactuar con otras cajas y con otras tiendas.
Opciones de Software POS Gratuito
Chromis POS
eHopper
Entre sus desventajas, cabe destacar que la versión gratuita solo se integra con un procesador de tarjetas de crédito (A1 Charge), la asistencia es limitada y no existe la posibilidad de integración con QuickBooks. Además, está restringido a una única caja registradora y no permite usar las funciones de medición de tiempo para los empleados.
Floreant POS
Técnicas de Recolección de Requerimientos
Entrevistas Frente a Frente
La técnica más común para reunir requerimientos es sentarse con los clientes y preguntarles qué es lo que necesitan.
Entrevistas Grupales
Son similares a las entrevistas frente a frente, excepto que se entrevista a más de una persona. Las entrevistas grupales requieren más preparación y más formalidad para obtener la información deseada de todos los participantes.
Sesiones Facilitadas
En una sesión facilitada, se reúne a un grupo más grande con un propósito común. En este caso, se intenta reunir un conjunto común de requerimientos del grupo de una manera más rápida que si se entrevistara a cada uno por separado.
Sesiones de Desarrollo Conjunto de Aplicaciones (JAD)
Las sesiones de Desarrollo Conjunto de Aplicaciones (JAD) son similares a las sesiones facilitadas. Sin embargo, el grupo típicamente se queda en la sesión hasta que se acuerda y documenta un conjunto de requerimientos.
Cuestionarios
Son buenas herramientas para reunir requerimientos de los interesados en ubicaciones remotas o de aquellos que tendrán una participación muy pequeña en los requerimientos generales. Puede también ser la única manera práctica de reunir requerimientos de docenas, cientos o miles de personas.
Prototipos
Es una manera de construir una versión inicial de la solución: un prototipo. Se lo muestra al cliente, quien proporciona requerimientos adicionales.
Observación de Procesos (Seguir a las Personas)
Esto es especialmente útil cuando se reúne información sobre procesos actuales. Quizá se requiera ver a las personas desempeñar su trabajo antes de poder entender la idea general. En algunos casos, quizá se desee también participar en el proceso real de trabajo para obtener una experiencia cercana de cómo funciona el negocio actualmente.
Conocer a la audiencia ayudará a determinar las técnicas adecuadas para satisfacer mejor sus necesidades. Se deben seleccionar técnicas que brinden la información más relevante y que sean las mejores para la audiencia.
Requerimientos de Software
Los requerimientos de software son simplemente una descripción de lo que un programa de software en particular debe hacer. Actúan como pautas para que los desarrolladores creen un producto funcional que satisfaga las necesidades de los usuarios. Continúe leyendo para descubrir por qué los requerimientos son importantes para un ingeniero de software.
Importancia de los Requerimientos de Software
Definir el Alcance de un Proyecto
Los requerimientos son esenciales para el alcance de un proyecto. Los requerimientos de software ayudan a determinar qué características estarán en el producto final, cuánto tiempo llevará desarrollar esas características y cuánto costará. Si el alcance de un proyecto no está bien definido, puede conducir a un deslizamiento del alcance. El deslizamiento del alcance ocurre cuando el alcance de un proyecto comienza a expandirse más allá del acuerdo inicial. Puede suceder porque las partes interesadas comienzan a incluir una nueva característica o porque el equipo del proyecto no hizo un excelente trabajo al definir el alcance en primer lugar.
Identificar Riesgos Potenciales
Los requerimientos también ayudan a identificar los riesgos al principio del proceso de desarrollo y, dependiendo de la metodología que se esté utilizando, ahorran tiempo y dinero considerables más adelante. Al identificar los riesgos temprano, se pueden evitar por completo o establecer planes de contingencia para mitigar su impacto durante el desarrollo de software.
Algunos de los riesgos más comunes que se pueden identificar a través de la recopilación de requerimientos incluyen:
- Objetivos indefinidos o contradictorios
- Falta de comprensión de las necesidades del usuario
- Falta de recursos
- Plazos poco realistas
Proporcionar una Base para las Pruebas
Los requerimientos de software proporcionan la base para las pruebas prácticas. Al tener un conjunto completo y bien documentado de requerimientos, los ingenieros de software pueden crear casos de prueba que cubren todos los aspectos del software que están desarrollando. Las pruebas ayudan a garantizar que el producto final cumpla con todas las expectativas del cliente. Además, los requerimientos pueden permitir la creación de pruebas automatizadas. Estas pruebas pueden ejecutarse automáticamente cada vez que se cambia el código, proporcionando retroalimentación a los desarrolladores sobre si los cambios que realizaron afectaron o no alguna funcionalidad existente.
Dar Dirección a los Desarrolladores
Los requerimientos también proporcionan una hoja de ruta para el proceso de desarrollo. Pueden ayudar a los desarrolladores a comprender cómo encajan las diferentes piezas del software y qué necesidades deben satisfacer primero. Además, los requerimientos bien escritos pueden ahorrar tiempo a los desarrolladores al proporcionar instrucciones claras y concisas. Esta dirección puede ayudar a evitar malentendidos sobre los objetivos del proyecto y evitar que se prolonguen.
Salvaguardar la Experiencia del Usuario Final
Los requerimientos de software ayudan a salvaguardar la experiencia del usuario final en el desarrollo de software. Al tener una comprensión completa y precisa de lo que los usuarios necesitan, quieren y esperan de una aplicación de software, los desarrolladores pueden crear productos que tienen más probabilidades de satisfacer las necesidades del usuario. La consideración del usuario final es crucial en aplicaciones de misión crítica, donde la satisfacción del usuario es esencial.
Fomentar la Comunicación y Colaboración del Equipo
El desarrollo de software y aplicaciones es un proceso técnico que involucra a muchas personas diferentes con varios conjuntos de habilidades. Los requerimientos actúan como un lenguaje común entre los miembros del equipo, mejorando la comunicación y la colaboración. El proceso proporciona un marco para la comunicación entre los miembros del equipo que trabajan en un proyecto de desarrollo de software. Con una comprensión compartida de las metas y objetivos del proyecto, los miembros del equipo pueden colaborar más fácilmente para producir el resultado deseado.
Evitar Retrabajos Costosos y Sorpresas Inesperadas
Si no se reúnen los requerimientos por adelantado, es probable que se termine con un producto que no satisfaga las necesidades de los usuarios. Esto puede resultar en un costoso retrabajo en el futuro, así como en sorpresas de último minuto que desvíen el cronograma de desarrollo.
Tipos de Requerimientos de Software
Generalmente, hay dos tipos de requerimientos en el desarrollo de software y aplicaciones: funcionales y no funcionales. Los requerimientos funcionales especifican lo que debe hacer un sistema, mientras que los requerimientos no funcionales especifican cómo debe comportarse el sistema.
Requerimientos Funcionales
En general, los requerimientos funcionales describen acciones específicas que el ingeniero de software debe ser capaz de realizar durante el desarrollo de software. Los requerimientos funcionales a menudo se dividen en reglas de negocio y casos de uso. Las reglas de negocio son declaraciones de alto nivel que definen lo que un sistema debe hacer, mientras que los casos de uso son descripciones más detalladas de cómo debe funcionar el sistema.
Algunos de los requerimientos más comunes bajo esta categoría incluyen:
- Las características y funcionalidad deseadas del producto
- Plataformas para desarrollar aplicaciones (por ejemplo, iOS, Android y web)
- Especificaciones de diseño (tema, colores y fuentes)
- Funcionalidad de back-end: integración API y bases de datos
- Plazos de finalización
Requerimientos No Funcionales
Los requerimientos no funcionales describen características específicas que el software debe poseer durante el desarrollo de la aplicación. Por lo general, se dividen en tres categorías: rendimiento, seguridad y calidad.
Requerimientos de Rendimiento
Los requerimientos de rendimiento suelen dividirse en dos categorías: tiempo de respuesta y rendimiento. El tiempo de respuesta es el tiempo que tarda un sistema en responder a la solicitud de un usuario, mientras que el rendimiento es el número de solicitudes que un sistema puede manejar. Son más críticos para los sistemas interactivos, como las aplicaciones de escritorio y los sitios web, donde los usuarios esperan respuestas inmediatas a sus acciones.
Requerimientos de Seguridad
Los requerimientos de seguridad especifican las medidas que un sistema debe tomar para proteger los datos del acceso no autorizado. En algunos casos, los requerimientos de seguridad también pueden especificar el nivel de protección requerido (como confidencial o de alto secreto). Implican autenticación, autorización y cifrado.
Requerimientos de Calidad
Especifican el nivel de calidad que debe cumplir un sistema. En algunos casos, los requerimientos de calidad también pueden especificar los métodos utilizados para medir la calidad (como la densidad de defectos o la satisfacción del cliente). Los requerimientos de calidad son generalmente cuatro medidas: conformidad, usabilidad, confiabilidad y mantenibilidad.
Estándar IEEE 830-1998 para la Especificación de Requerimientos de Software (ERS)
¿Qué es el Estándar IEEE 830-1998?
El estándar IEEE 830-1998 para el SRS (Software Requirements Specification en inglés) o ERS (Especificación de Requerimientos de Software) es un conjunto de recomendaciones para la especificación de los requerimientos o requisitos de software.
¿Para qué sirve el Estándar IEEE 830-1998?
El propósito principal de esta norma es ayudar a elaborar un documento muy útil: la ERS (Especificación de Requerimientos de Software). Esta, a su vez, tiene como finalidad la documentación de los acuerdos entre el cliente y el grupo de desarrollo para así cumplir con la totalidad de exigencias estipuladas.
¿Quién creó el Estándar IEEE 830-1998?
El estándar 830-1998 fue generado por el Software Engineering Standards Committee (Comité de Normas de Ingeniería de Software) del IEEE.
¿Quién usa o puede usar el Estándar IEEE 830-1998?
- Un cliente/usuario que vaya a definir requerimientos (características) de un software que necesite.
- Un desarrollador (interno/externo) que haga software ‘a la medida’ mediante proyecto.
- Un desarrollador que haga software ‘de paquete’ que se venda masivamente.
Ventajas de usar el Estándar IEEE 830-1998
- Facilita la comunicación entre clientes y desarrolladores.
- Funciona como base para realizar las estimaciones del proyecto en términos de costos, tiempo y magnitud.
- Se reduce el esfuerzo de diseño y programación (evitando retrabajos).
- Se tiene una base o referencia para validar o probar el software solicitado.
- Se facilita el traspaso del software a otros clientes/usuarios.
- Se le pueden hacer mejoras (o innovaciones) a ese software.