Administración y sus objetivos

SOFTWARE PUNTO DE VENTA

El objetivo del software de punto de venta es registrar en 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 del control de las compras, de los inventarios y la capacidad de interactuar con otras cajas y con otras tiendas.

Software POS gratis

1.
Chromis POS

2.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.

3.FLOREANT POST

Técnicas DE Recolección DE REQUERIMIENTOS

Entrevistas frente a frente

La técnica más común para reunir requerimientos es sentarte con los clientes y preguntarles que es lo que necesitan.
2. Entrevistas grupales

Son similares a las entrevistas frente a frente excepto que hay más de una persona siendo entrevistada. Las entrevistas grupales requieren más preparación y más formalidad para obtener la información que quieres de todos los participantes.

3. Sesiones facilitadas

En una sesíón facilitada, reúnes a un grupo más grande por un propósito común. En este caso, intentas reunir un conjunto común de requerimientos del grupo de una manera más rápida que si entrevistaras a cada uno por separado.

4. Sesiones de desarrollo conjunto de aplicaciones

Las sesiones de desarrollo conjunto de aplicaciones (JAD) son similares a las sesiones facilitadas. Sin embargo, el grupo típicamente se queda en la sesíón hasta que se acuerda y documenta un conjunto de requerimientos.

5. Cuestionarios

Son buenas herramientas para reunir requerimientos de los interesados en locaciones remotas o de los que tendrán una muy pequeña participación en los requerimientos generales. Puede también ser la única manera práctica de reunir requerimientos de docenas, cientos o miles de personas.

6. Prototipos

Es una manera de construir una versión inicial de la solución – un prototipo. Se lo muestras al cliente, quien te da requerimientos adicionales.

7. Seguir a las personas

Esto es especialmente útil cuando reúnes información sobre procesos actuales. Quizá requieras ver a las personas desempeñar su trabajo antes de poder entender la idea general. En algunos casos quizá quieras también participar en el proceso real de rebajo para obtener una experiencia cercana de cómo funciona el negocio actualmente.


Conocer a tu audiencia te ayudará a determinar las técnicas adecuadas para satisfacer mejor sus necesidades. Debes seleccionar técnicas que te brinden la información más relevante y que sean las mejores para la audiencia.


REQUERIMIENTOS DE SOFTWARE

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. Siga leyendo para descubrir por qué los requerimientos son importantes para usted como ingeniero 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é carácterísticas estarán en el producto final, cuánto tiempo llevará desarrollar esas carácterí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 carácterí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 esté utilizando, ahorrando tiempo y dinero considerables más adelante. Al identificar los riesgos temprano, puede evitarlos por completo o establecer planes de contingencia para mitigar su impacto durante el desarrollo de software.

Algunos de los riesgos más comunes que puede 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 crear pruebas automatizadas
.
Estas pruebas pueden ejecutarse automáticamente cada vez que se cambia el código, proporcionando comentarios a los desarrolladores sobre si los cambios que realizaron rompieron 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. La dirección puede ayudar a evitar malentendidos sobre los objetivos del proyecto y evitar que se arrastren.

El requisito salvaguarda 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 en el desarrollo de aplicaciones.

Fomenta la comunicación y la colaboración entre los miembros 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.

Evite el costoso re-trabajo y las sorpresas de última hora

Si no reúne los requerimientos por adelantado, es probable que termine con un producto que no satisfaga las necesidades de sus usuarios. Esto puede resultar en un costoso retrabajo en el futuro, así como en sorpresas de último minuto que desvían su 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 en virtud de él incluyen:


Las carácterísticas y funcionalidad deseadas del producto


Plataformas para desarrollar aplicaciones, por ejemplo, iOS, Android y web


Especificaciones de diseño en términos de tema, colores y fuentes


Funcionalidad de back-end: integración APl y bases de datos


Plazos de finalización

Requerimientos no funcionales

Los requerimientos no funcionales describen carácterí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. Implica autenticación, autorización y cifrado.

Requerimientos de calidad

Especifica 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 de calidad: conformidad, usabilidad, confiabilidad y mantenibilidad.


Estándar IEEE 830-1998

Norma IEEE 830

¿Qué es?

El estándar IEEE 830-1998 para el SRS (en inglés) o ERS (Especificación de requerimientos de software) es un conjunto de recomendaciones para la especificación de los requerimiento o requisitos de software.

¿Para qué sirve?

El propósito principal de esta norma es ayudarnos a elaborar un documento muy útil: el ERS (Especificación de Requerimientos de Software) y este 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 la creo?

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 la usa o puede usar?

Un cliente/usuario que vaya a definir requerimientos (carácterí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 al usarla?

Facilita la comunicación entre clientes y desarrolladores.

Funciona como base para realizar las estimaciones del proyecto en costos, tiempo y magnitud.

Se reduzca el esfuerzo de análisis, diseño, y programación (evitando re-trabajos).

Se tenga una base o referencia para validar o probar el software solicitado.

Se facilite el traspaso del software a otros clientes/usuarios.

Se le puedan hacer mejoras (o innovaciones) a ese software.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.