MODELO DE REQUISITOS

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que ofrecerá desde la perspectiva del usuario. Este modelo puede trabajar como un contrato entre el desarrollador y el cliente, o usuario del sistema, por lo que deberá proyectar lo que el cliente desea según la percepción del desarrollador. Por ello, es esencial que los clientes lo comprendan.

El modelo de requisitos es el primero en desarrollarse, y es la base para formar todos los demás modelos en el desarrollo de software. En general, cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias a este nivel que posteriormente. El modelo de requisitos que se desarrollará se basa en la metodología Objectory (Jacobson et al. 1992), que tiene su fundamento en el modelo de casos de uso. Actualmente esta metodología es parte del Proceso unificado racional (RUP) [Rational Unified Process].1 El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos.

► Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperación con otros modelos como se verá más adelante.

► Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, lo que lo hace un modelo lógico independiente del ambiente de implementación.

► Diseño: La funcionalidad de los casos de uso, ya estructurada por el análisis, la realiza el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más.

► Implementación: Los casos de uso se instrumentan mediante el código fuente en el modelo de implementación.

► Pruebas: Los casos de uso se comprueban a través de las pruebas de componentes y de integración.

► Documentación: El modelo de casos de uso se debe registrar a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, de administración, etcétera.

El propósito del modelo de requisitos es comprender en su totalidad el problema y sus implicaciones. Los demás modelos, análisis, diseño, implementación y pruebas dependen directa o indirectamente del modelo de requisitos. Asimismo, este modelo sirve de base para el desarrollo de las instrucciones operacionales y los manuales, ya que todo lo que el sistema deba hacer se describe aquí desde la perspectiva del usuario. El modelo de requisitos no es un proceso mecánico, el analista debe interactuar constantemente con el cliente para completar la información faltante, y así resolver ambigüedades e inconsistencias. También debe separar los requisitos verdaderos de las decisiones relacionadas con el diseño e implementación. Se deben indicar cuáles aspectos son obligatorios y cuáles opcionales para evitar que se limite la flexibilidad de la implementación. Durante el diseño, se debe extender el modelo de requisitos con las especificaciones de rendimiento y los protocolos de interacción para los sistemas externos, al igual que las provisiones sobre modularidad y futuras extensiones. Incluso, en ciertas ocasiones se pueden incluir aspectos de diseño, como el uso de lenguajes de programación particulares.

Gale Virtual Reference Library – Documento – Modelo de Requisitos Weitzenfeld, Alfredo. “Modelo de Requisitos.” Ingeniería de Software Orientada a Objetos con UML, Java e Internet, Cengage Learning, 2005, pp. [195]-197. Gale Virtual Reference Library, bibliotecavirtual.unad.edu.co:2081/ps/i.do?p=GVRL&sw=w&u=unad&v=2.1&it=r&id=GALE%7CCX3004300051&asid=959aa89a0acb01ba3c88b3e4069a7d13. Accessed 6 Mar. 2017.

COBIT Y LOS CONTROLES DE APLICACIÓN

Los controles de aplicación consisten de actividades manuales y/o automatizadas que aseguran que la información cumple con ciertos criterios, los que COBIT refiere como requerimientos de negocio para la información. Estos criterios son:

  • Efectividad
  • Eficiencia
  • Confidencialidad
  • Integridad
  • Disponibilidad
  • Cumplimiento
  • Confiabilidad

Los controles de aplicación se establecen para proporcionar una seguridad razonable de que los objetivos que la gerencia establece sobre las aplicaciones, se alcanzan. Estos objetivos se articulan típicamente a través de funciones específicas para la solución, la definición de las reglas de negocio para el procesamiento de la información y la definición de procedimientos manuales de soporte. Ejemplo de ello son:

  • Totalidad (Integridad)
  • Exactitud
  • Validez
  • Autorización
  • Segregación de funciones

Es necesario asegurarse de que existen suficientes controles para mitigar los riesgos y que están operando con la efectividad necesaria para proveer información confiable.

Durante el ciclo de vida de los sistemas, diversas partes de la organización realizan actividades, responsabilidades y roles asociados con los controles de aplicación.

DISEÑO E IMPLANTACIÓN DE LOS CONTROLES DE APLICACIÓN

Una parte importante de esta etapa tanto para los sistemas nuevos como para los existentes, es identificar los objetivos de control, evaluar los riesgos y determinar la suficiencia de los controles de aplicación. Si no fue así, se deberán plantear las acciones correctivas necesarias.

1.PNG

OPERACIÓN Y MANTENIMIENTO DE LOS CONTROLES DE APLICACIÓN

El ambiente de proceso de TI en el cual operan los controles de aplicación, necesita ser controlado para asegurar la confiabilidad del proceso de los sistemas. Los cambios en los procesos y en los requerimientos de negocio, deben ser considerados para actualizar y/o mejorar los controles de aplicación.

2.PNG

DEPENDENCIA DE LOS CONTROLES GENERALES DE TI

Los controles generales de TI son aquellos que tienen que ver con el ambiente de proceso de TI en el cual operan los controles de aplicación. Entre los controles generales están, por ejemplo:

  • Control de cambios a programas
  • Controles de acceso físico
  • Controles de acceso lógico
  • Controles de continuidad operativa

El hecho de que los controles generales sean adecuados, no garantiza que los controles de aplicación serán adecuados.

Pero si los controles generales son deficientes, los controles de aplicación muy probablemente lo serán también.

MARCO DE TRABAJO GENERAL COBIT

Para proporcionar la información que la empresa necesita para lograr sus objetivos, es necesario administrar los recursos de TI a través de un conjunto estructurado de procesos de TI.

3.PNG

OBJETIVOS DE CONTROL DE APLICACIÓN IDENTIFICADOS EN COBIT

AC1 PREPARACIÓN Y AUTORIZACIÓN DE INFORMACIÓN FUENTE

Asegurar que los documentos fuente están preparados por personal autorizado y calificado siguiendo los procedimientos establecidos, teniendo en cuenta una adecuada segregación de funciones respecto al origen y aprobación de estos documentos. Detectar errores e irregularidades para que sean informados y corregidos.

AC2 RECOLECCIÓN Y ENTRADA DE INFORMACIÓN FUENTE

Establecer que la entrada de datos se realice en forma oportuna por personal calificado y autorizado. Las correcciones y reenvíos de los datos que fueron erróneamente ingresados se deben realizar, sin comprometer los niveles de autorización de las transacciones originales. En donde sea apropiado para la reconstrucción, retener los documentos fuente originales durante el tiempo necesario.

AC3 CHEQUEOS DE EXACTITUD, INTEGRIDAD Y AUTENTICIDAD

Asegurar que las transacciones son exactas, completas y válidas. Validar los datos ingresados, y editar o devolver para corregir, tan cerca del punto de origen como sea posible.

AC4 INTEGRIDAD Y VALIDEZ DEL PROCESAMIENTO

Mantener la integridad y validación de los datos a través del ciclo de procesamiento. Detectar transacciones erróneas y que no interrumpan el procesamiento de transacciones válidas.

AC5 REVISIÓN DE SALIDAS, RECONCILIACIÓN Y MANEJO DE ERRORES

Establecer procedimientos y responsabilidades asociadas para asegurar que la salida se maneja de una forma autorizada, entregada al destinatario apropiado, y protegida durante la transmisión; que se verifica, detecta y corrige la exactitud de la salida; y que se usa la información proporcionada en la salida.

AC6 AUTENTICACIÓN E INTEGRIDAD DE TRANSACCIONES

Antes de pasar datos de la transacción entre aplicaciones internas y funciones de negocio/operativas (dentro o fuera de la empresa), verificar el apropiado direccionamiento, autenticidad del origen e integridad del contenido. Mantener la autenticidad y la integridad durante la transmisión o el transporte.

TIPOS DE CONTROLES DE APLICACIÓN

CONTROLES DE APLICACIÓN MANUALES: Son controles ejecutados sin la asistencia de sistemas automatizados. Ejemplos:

  • Autorizaciones escritas, como firmas en cheques.
  • Reconciliación de órdenes de compra con los formatos de recepción de mercancías.

CONTROLES DE APLICACIÓN AUTOMATIZADOS: Son controles que han sido programados e integrados en una aplicación computacional. Ejemplos:

  • Validaciones de edición y contenido de datos de entrada.
  • Dígitos verificadores para validar números de cuenta.

CONTROLES DE APLICACIÓN HÍBRIDOS O DEPENDIENTES DE CONTROLES DE APLICACIÓN AUTOMATIZADOS: Son controles que consisten de una combinación de actividades manuales y automatizadas. Ejemplo:

El proceso de llenado de órdenes de embarque puede incluir un control donde el gerente de embarques revisa un reporte de órdenes no embarcadas.

Para que este control sea efectivo, la actividad automatizada (generación de un reporte completo y seguro de órdenes no embarcadas) así como la actividad manual (revisión y seguimiento por el gerente), son necesarias para que el control sea efectivo.

CONTROLES DE APLICACIÓN CONFIGURABLES: Son controles automatizados que están basados y por lo tanto son dependientes de la configuración de parámetros dentro de la aplicación. Ejemplo:

Un control en un sistema de compras automatizado, que permite órdenes hasta un límite de autorización, es dependiente de controles sobre los cambios en los límites preconfigurados de autorización.

En muchos casos, las aplicaciones comerciales o desarrolladas en casa, son altamente dependientes de la configuración de varias tablas de parámetros.

Es apropiado considerar el diseño del control sobre las tablas como un elemento separado.

ATRIBUTOS DE LOS CONTROLES

  • Frecuencia del Control: Esta característica se relaciona con que tan frecuentemente es aplicado un control (diaria, semanal, mensual, etc.). Esta necesita ser considerada en el contexto de riesgo. Tal vez la frecuencia anual de revisión de la nómina no sea suficiente y por otro lado, una revisión de un balance diario, pueda dar lugar a errores y debe hacerse mensualmente.
  • Proximidad del Control al evento de Riesgo: Esta característica considera dónde, dentro del proceso, se aplica la actividad de control. Si la entrada de datos es una preocupación, entonces la actividad de control debe ser más efectiva entre más cerca esté de dicho evento dentro del proceso.
  • Ejecución de la actividad de Control: Saber quién ejecuta el control es una característica relevante, sobre todo en los controles manuales, ya que ello implica roles y responsabilidades por las decisiones y aprobaciones relacionadas con el control. Esta característica considera si las responsabilidades han sido apropiadamente segregadas de otras responsabilidades incompatibles.

SAAS, IAAS Y PAAS

SOFTWARE COMO UN SERVICIO (SAAS)

El software como un servicio es un concepto que lleva vigente en la industria de la tecnología desde hace mucho tiempo. Desde que los ingenieros se dieron cuenta que era más barato correr aplicaciones en un centro de datos y distribuirlas a las terminales clientes, el software se convirtió en un servicio. Sin embargo, fue a comienzo del siglo XXI cuando SaaS realmente se convirtió en un término importante para las empresas un poco más pequeñas.

¿Qué es exactamente el SaaS? La explicación más sencilla se puede ver en el modelo de distribución. El software tradicional simplemente se vendía y quedaba alojado en los equipos del comprador. El cambio de modelo enfocado en un servicio implica que el software queda guardado en un servidor remoto y es administrado por la empresa que lo ofrece.

Gartner define SaaS como: “software que es propiedad, es entregado y es administrado por algún proveedor”

El enfoque en el modelo de distribución es clave porque cambia totalmente la forma de usar la tecnología. Anteriormente, las empresas tenían que desarrollar o comprar una aplicación que se ajustara a sus necesidades puntuales. Hasta ahí, todo normal. Los problemas venían cuando el aplicativo se dañaba, necesitaba servicio o se iba quedando obsoleto.

En el pasado, lo más lógico era comprar un software que permitiera hacer esto eficientemente, instalarlo en sus propios servidores y empezar a trabajar. Ahora, con el SaaS, lo más lógico es dejar que otra empresa especializada en tecnología haga la aplicación, la administre y la asegure. Este modelo tiene dos principales ventajas: el costo y el valor estratégico.

Cuando el software se empezó a vender como un servicio, el cambio se realizó principalmente para ahorrar costos. La ecuación es relativamente sencilla. ¿Por qué me voy a gastar miles de dólares en un software que puede quedar obsoleto en unos años cuándo simplemente puedo arrendar uno que siempre está actualizado? Además, de esta manera se puede convertir una inversión en capital en un gasto operativo de la organización.

INFRAESTRUCTURA COMO UN SERVICIO (IAAS)

La infraestructura como servicio también se comporta de manera similar a la SaaS. La gran diferencia es que, en lugar de vender programas y licencias, los proveedores de este servicio arriendan sus servidores para que otras empresas puedan usarlos como quieran.

Gartner define IaaS como: “una oferta automatizada y estandarizada, donde recursos de computo, complementados con opciones de almacenamiento y capacidades de red, son propiedad del proveedor y son ofrecidos al consumidor para que los consuma cuando quiera”

La IaaS es un servicio más enfocado en las empresas que trabajan con tecnología, ya que permite desarrollar y ajustar las máquinas virtuales a las necesidades del equipo. Para que un servicio sea considerado dentro de la categoría de IaaS, se deben cumplir una serie de características. Según Microsoft, el servicio debe ser ‘on-demand’: el consumidor debe tener la posibilidad de usar los recursos de computación sin tener que acudir a un humano. La solución también debe tener banda ancha. Una aplicación de misión crítica no puede depender de la conexión. Se tiene que garantizar una red amplia, segura y confiable.

Sin embargo, lo más importante y valioso es la posibilidad de ajustar los recursos a la carga del cliente. Los proveedores de infraestructura deben permitir que sus clientes puedan aumentar o disminuir los recursos de cómputo y almacenamiento a medida que cambian los requerimientos. Si una página web, por ejemplo, sabe que va a tener un día extraordinariamente pesado de tráfico, puede aumentar su máquina virtual para garantizar el servicio.

Lo mismo debe ocurrir hacia abajo. El cliente puede disminuir los recursos, lo que debería bajar el costo de la solución. Con esta flexibilidad, los gerentes de TI pueden ser más cuidadosos con sus gastos y más eficientes en su trabajo y su inversión.

Otra de las grandes ventajas es que no hay que comprar servidores. Una compañía que no tiene su foco en tecnología puede hacer inversiones de capital en lugares más estratégicos y optar por un modelo de servicio para suplir las necesidades de infraestructura de TI. Además, como es un servicio contratado, no tendrá que preocuparse por gastos de mantenimiento y seguridad. Y como el servidor está en un centro de datos, siempre estará actualizado con la más reciente tecnología. El cliente no se tiene que preocupar por eso y, si tiene un problema, simplemente cambia de proveedor.

PLATAFORMA COMO UN SERVICIO (PAAS)

La combinación de los dos servicios mencionados anteriormente se puede catalogar como una plataforma como servicio. La integración del software con la infraestructura permite crear una plataforma que puede ser aprovechada por los clientes para crear soluciones de valor agregado que ahorran costos y usan la más reciente tecnología.

Al integrar el software como servicio, así como la infraestructura como servicio, se crea una plataforma que aprovecha los beneficios de las dos modalidades: menores costos, manejo financiero más flexible y eficiente y valor agregado.

http://www.enter.co/guias/tecnoguias-para-empresas/saas-iaas-y-paas-que-son-como-usarlos-y-para-que/

 

POLÍTICA DE SEGURIDAD INFORMÁTICA

El establecimiento de una política de seguridad informática es una necesidad para las empresas que utilizan las redes como una forma de mejora en procesos y de poder competir en un mundo globalizado.

Las políticas vienen a representar una forma consensuada de hacer y manejar todos los aspectos tecnológicos de la organización ya que de no hacerlo así podrían ocasionar serios problemas a la organización.

Las políticas de seguridad deberán ser definidas tomando en cuenta riesgos y vulnerabilidades y sobre todo deberán estar actualizándose constantemente ya que al estar relacionadas con aspectos tecnológicos sus consideraciones cambian con gran rapidez.

Las políticas de seguridad informáticas deben ser definidas tomando en cuenta lo que se debe proteger y por qué se debe proteger y por supuesto, deben tomar en cuenta al personal que hace uso de esa información o de los recursos y redactarlas en un lenguaje que sea comprensible para ellos

La seguridad informática tiene un dicho: “lo que no está permitido debe estar prohibido” pero esto no se logra fácil. Es necesario establecer una política de seguridad siguiendo un procedimiento en donde se analizan los riesgos a los cuales está expuesta la información y los recursos tecnológicos con los que cuenta la empresa.

El establecimiento de dichas políticas debe ser de arriba hacia abajo en la organización ya que requiere de un apoyo económico, pero también de dirección muy importante para hacer que esto tenga éxito y no sea considerado como algo superficial que no tiene impacto en la empresa.

El error de muchas empresas es pensar que a sus sistemas y a sus recursos informáticos nunca les pasará nada, es por eso que nos encontramos con frases como las siguientes:

  1. Mi sistema no es importante para un hacker. Por lo tanto no le pongo passwords. Un hacker y un Virus entran a donde puede así que si le dejas la puerta abierta entrará y ya estando ahí tomará lo que se le antoje.
  2. Estoy protegido pues no abro archivos que no conozco. Los sistemas realizan acciones sin necesidad que el usuario lo supervise o autorice a veces los usuarios desconocen y aceptan algunas operaciones que pueden resultar peligrosas para el sistema.
  3. Como tengo antivirus estoy protegido. No basta con esto, es necesario estar actualizando el antivirus y en ocasiones ni esto es suficiente dado que se genera el virus y después el antivirus.
  4. Como dispongo de un firewall no me contagio. El contagio puede realizarse por usuarios con altos privilegios a los cuales el sistema de firewall puede estar permitiendo accesos autorizados por supuesto.

NORMA ISO/IEC 14598 EVALUACIÓN DEL PRODUCTO DE SOFTWARE

Para aplicar pruebas al software, existen diferentes modelos, dentro de estos modelos surge la norma ISO/IEC 14598. En sus diferentes etapas, establece un marco de trabajo para evaluar la calidad de los productos de software proporcionando, además, métricas y requisitos para los procesos de evaluación de los mismos. En particular, es utilizada para aplicar los conceptos descritos en la norma ISO / IEC 9126. Se definen y describen las actividades necesarias para analizar los requisitos de evaluación, para especificar, diseñar y realizar acciones de evaluación y para concluir la evaluación de cualquier tipo de producto de software.

PARTES:

2.png

NORMA ISO/IEC 25000 REQUISITOS Y EVALUACIÓN DE LA CALIDAD DE LOS PRODUCTOS DE SOFTWARE

La familia ISO/IEC 25000 es el resultado de la evolución de otras normas, especialmente de las normas ISO/IEC 9126, que describe las particularidades de un modelo de calidad del producto software, e ISO/IEC 14598, que abordaba el proceso de evaluación de productos software.

DIVISIONES:

1.png

La norma establece tres vistas para determinar en el estudio la calidad del producto. Primero se realiza una vista interna que se ocupa de examinar las propiedades del software. En segundo lugar se realiza una vista externa que analiza el comportamiento que tiene el software en productividad. En tercer y último lugar se hace la vista en uso que mide la efectividad del software.

Una vez realizado estos pasos se establece las características de calidad del producto en función de la eficiencia, usabilidad, fiabilidad, funcionabilidad, portabilidad y mantenimiento.

NORMA ISO/IEC 9126 CALIDAD DEL PRODUCTO DE SOFTWARE

Esta norma Internacional fue publicada en 1992, es usada para la evaluación de la calidad de software. Se publicó bajo el nombre de “Information technology Software product evaluation: Quality characteristics and guidelines for their use”, y en ella se establecen las características de calidad para productos de software. La norma ISO/IEC 9126 establece que cualquier componente de la calidad del software puede ser descrito en términos de una o más de seis características básicas, cada una de estas se detalla a través de un conjunto de subcaracterísticas que permiten profundizar en la evaluación de la calidad de productos de software.

El estándar está dividido en cuatro partes las cuales dirigen, realidad, métricas externas, métricas internas y calidad en las métricas de uso y expendido. El modelo de calidad establecido en la primera parte del estándar, ISO 9126-1, clasifica la calidad del software en un conjunto estructurado de características y subcaracterísticas de la siguiente manera:

CARACTERÍSTICAS SUBCARACTERÍSTICAS
Funcionalidad – Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades específicas. Las funciones son aquellas que satisfacen las necesidades implícitas o explícitas. Adecuación – Atributos del software relacionados con la presencia y aptitud de un conjunto de funciones para tareas especificadas.
Exactitud – Atributos del software relacionados con la disposición de resultados o efectos correctos o acordados.
Interoperabilidad – Atributos del software que se relacionan con su habilidad para la interacción con sistemas especificados.
Seguridad – Atributos del software relacionados con su habilidad para prevenir acceso no autorizado ya sea accidental o deliberado, a programas y datos.
Cumplimiento funcional.
Fiabilidad – Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestación bajo condiciones establecidas durante un período establecido. Madurez – Atributos del software que se relacionan con la frecuencia de falla por fallas en el software.
Recuperabilidad – Atributos del software que se relacionan con la capacidad para restablecer su nivel de desempeño y recuperar los datos directamente afectos en caso de falla y en el tiempo y esfuerzo relacionado para ello.
Tolerancia a fallos – Atributos del software que se relacionan con su habilidad para mantener un nivel especificado de desempeño en casos de fallas de software o de una infracción a su interfaz especificada.
Cumplimiento de Fiabilidad – La capacidad del producto software para adherirse a normas, convenciones o legislación relacionadas con la fiabilidad.
Usabilidad – Un conjunto de atributos relacionados con el esfuerzo necesario para su uso, y en la valoración individual de tal uso, por un establecido o implicado conjunto de usuarios. Aprendizaje- Atributos del software que se relacionan al esfuerzo de los usuarios para reconocer el concepto lógico y sus aplicaciones.
Comprensión – Atributos del software que se relacionan al esfuerzo de los usuarios para reconocer el concepto lógico y sus aplicaciones.
Operatividad – Atributos del software que se relacionan con el esfuerzo de los usuarios para la operación y control del software.
Atractividad
Eficiencia – Conjunto de atributos relacionados con la relación entre el nivel de desempeño del software y la cantidad de recursos necesitados bajo condiciones establecidas. Comportamiento en el tiempo – Atributos del software que se relacionan con los tiempos de respuesta y procesamiento y en las tasas de rendimientos en desempeñar su función.
Comportamiento de recursos – Usar las cantidades y tipos de recursos adecuados cuando el software lleva a cabo su función bajo condiciones determinadas.
Mantenibilidad – Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema software. Estabilidad – Atributos del software relacionados con el riesgo de efectos inesperados por modificaciones.
Facilidad de análisis – Atributos del software relacionados con el esfuerzo necesario para el diagnóstico de deficiencias o causas de fallos, o identificaciones de partes a modificar.
Facilidad de cambio – Atributos del software relacionados con el esfuerzo necesario para la modificación, corrección de falla, o cambio de ambiente
Facilidad de pruebas – Atributos del software relacionados con el esfuerzo necesario para validar el software modificado.
Portabilidad – Conjunto de atributos relacionados con la capacidad de un sistema de software para ser transferido y adaptado desde una plataforma a otra. Capacidad de instalación – Atributos del software relacionados con el esfuerzo necesario para instalar el software en un ambiente especificado.
Capacidad de reemplazamiento – Atributos del software relacionados con la oportunidad y esfuerzo de usar el software en lugar de otro software especificado en el ambiente de dicho software especificado.
Calidad en uso – Conjunto de atributos relacionados con la aceptación por parte del usuario final y Seguridad. Eficacia – Atributos relacionados con la eficacia del software cuando el usuario final realiza los procesos.
Productividad – Atributos relacionados con el rendimiento en las tareas cotidiana realizadas por el usuario final.
Seguridad – Atributos para medir los niveles de riesgo.
Satisfacción – Atributos relacionados con la satisfacción de uso del software.