miércoles, 17 de febrero de 2016

5 Preguntas practicas (taller3)


1.    ¿Qué beneficios proporciona un proceso?
Un proceso de software efectivo habilita a la organización a incrementar su productividad al desarrollar software:
• Permite estandarizar esfuerzos, promover reúso, repetición y consistencia entre proyectos.
• Provee la oportunidad de introducir mejores prácticas de la industria.
• Permite entender que las herramientas deben ser utilizadas para soportar un proceso.
• Establece la base para una mayor consistencia y mejoras futuras.

Un proceso de software mejora los esfuerzos de mantenimiento y soporte:
• Define cómo manejar los cambios y liberaciones a sistemas de software existentes.
• Define cómo lograr la transición del software a la operación, y cómo ejecutar los esfuerzos de operación y soporte.

2.    ¿De dónde provienen los proyectos?
Los proyectos surgen de as necesidades y de las proyecciones de innovación que poseen cada una de las empresas sin importar los campos de dichas empresa, ya que estos proyectos de soluciones tecnológicas llevan a la mejora a gran escala de la productividad y del mercado de la empresa en cada una de sus ramas, se puede decir que la Ingeniería de Software empleada en la empresa es una de las grandes innovaciones ya que esto conlleva a que la empresa este de frente al futuro y a los grandes mercados que se avecinan por el avance de la tecnología.

3.    ¿Cuál modelo elegir y porque?
Cuando se hace la pregunta de cuál modelo seguir o elegir para el proyecto que se quiere llevar acabo es tedioso, debido a que los modelos se aplican a los proyectos según el tema y según la problemática que se quiere solucionar, como también porque cada uno de los proyectos que se llevan acabo son diferentes y cada uno de ellos implican una manera diferente de solución y de aplicación con respecto al pasar del tiempo debido a que los proyectos se deben ejecutar teniendo en cuenta cada uno de las problemáticas que se pueden causar con su aplicación como también cada una de las mejoras y evolución que debe tener dicho proyectos. 

4.    En donde y cuando utilizar metodología de desarrollo y donde y cuando el método o modelo de ciclo de vida del software
a) Siempre es bueno utilizar las  numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Un ejemplo de ellas son las propuestas tradicionales centradas específicamente en el control del proceso. Estas han demostrado ser efectivas y necesarias en un gran número de proyectos, sobre todo aquellos proyectos de gran tamaño (respecto a tiempo y recursos).
Sin embargo el éxito del proyecto depende de la metodología que se elija, la experiencia ha demostrado que las metodologías tradicionales no ofrecen una buena solución para proyectos donde el entorno es volátil y donde los requisitos no se conocen con exactitud, porque no están pensadas para trabajar con incertidumbre.


Aplicar metodologías tradicionales nos obliga a forzar a nuestro cliente a que tome la mayoría de las decisiones al principio. Luego el coste de cambio de una decisión tomada puede llegar a ser muy elevado si aplicamos metodologías tradicionales.
Para proyectos a menor escala se recomienda Las metodologías ágiles que están revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologías tradicionales.
b) Siempre es bueno utilizar un modelo de ciclo de vida a menos que se vaya a realizar un denominado “hola mundo”, al igual que la metodología lo importante es saber cuál es el que más se adapta al tipo de proyecto, sin embargo hay flexibilidad  a la hora de escoger un modelo e incluso se pueden mezclar etapas de varios modelos si es un caso especial en donde se requiera.


5.    Mediante un ejemplo sencillo aplique una metodología y un modelo de ciclo de vida del software
Ejemplo metodología scrum
Requerimiento:
El cliente requiere los servicios para la creación de un sistema de información que administre la inmobiliaria del cual él es propietario.
El cliente se reúne con el director del proyecto para escuchar lo que el cliente quiere para el sistema de información.
Proceso:
1.    El cliente le informa los diferentes procesos que debe realizar el S.I, dándole una prioridad al sector de cobranza. El director del proyecto agrupa todos estos requerimientos y sugerencias del cliente y los organiza en una PILA DE PRIORIDAD para el proyecto.
2.    El director del proyecto SCRUM MANAGER se reúne con su equipo de trabajo para calcular el costo del proyecto. Usando la pila de prioridad de los módulos del S.I que diseño el SCRUM MANAGER.
3.    El cliente aprueba el presupuesto del proyecto y reordena la PILA DE PRIORIDAD del S.I según el interés del mismo que en este caso desea obtener como prioridad el módulo de cobranza.
4.    El equipo de trabajo comienza el trabajo desglosando la primera tarea a realizar o el primer módulo de desarrollo, dividiéndolo en subtareas menores para crear otra pila de actividades llamada PILA DE SPRINT

 






5.    La PILA DE SPRING tiene como objetivo fraccionar el trabajo de un periodo de 15 días en tareas más pequeñas, que tardan como mucho dos días.
6.    El equipo comienza el sprint tomando las tareas priorizadas, una vez concluida una se toma la siguiente de la lista. Se convoca todos los días una reunión del equipo donde se informan las tareas realizadas el día anterior y cuales se van a realizar ese día.
7.    Una vez finalizado el SPRINT, el director del proyecto le muestra el resultado del trabajo realizado.
El cliente ya tiene su solicitud realizada y solucionada con el módulo de contabilidad completo y además podrá volver a priorizar la PILA del producto antes de que comience otro SPRINT.
8.    El equipo de trabajo se reúne para hacer una retrospectiva del buen trabajo realizado.

EJEMPLO CICLO DE VIDA EN CASCADA
Una empresa quiere implantar un sistema de control de acceso de usuarios previo al arranque del resto de aplicaciones que tiene instaladas. Cada usuario deberá indicar su nombre y password para poder tener acceso al resto del sistema.
El sistema de control de acceso permitirá un máximo de tres intentos antes de bloquear el terminal durante cinco minutos. El sistema detectar que tanto el nombre como el password han sido rellenadas y que dichos valores se corresponden con los que previamente han sido almacenados en la base de datos de control de accesos.
Bajo ningún concepto, el nombre de usuario y el password podrán quedar sin rellenar, en el caso de no poder realizar la identificación de los usuarios que quieren acceder al sistema, deberá mostrarse un mensaje de error que indique cual es la causa de fallo de identificación.


-SE ESQUEMATIZA LAS CAPAS DEL MODELO EN CASCADA
-ESPECIFICACION
-ANALISIS
-DISEÑO
-IMPLEMENTACION
-PRUEBAS
-INSTALACION

-MANTENIMIENTO

martes, 16 de febrero de 2016

Taller #2 Ingeniería de Software

 PRINCIPIOS DEL ANÁLISIS

Todos los métodos de análisis se relacionan a través del siguiente conjunto de principios operativos:
a. La representación y el entendimiento del dominio de información de un problema. Requiere el examen del dominio de la información. Este dominio contiene tres visiones diferentes de los datos y del control: (1) contenido de la información y relaciones, (2) flujo de la información y (3) estructura de la información. El contenido es definido por los atributos necesarios para crearlo. El flujo representa como cambian los datos y el control a medida que se mueven dentro de un sistema. La estructura representa la organización interna de los elementos de datos o de control.

b. La definición de funciones que debe realizar el software. Los modelos se crean para entender de mejor manera la entidad que se va construir como solución a un problema. Para transformar la información el software debe realizar al menos tres funciones genéricas: entrada, procesamiento y salida.

c. La representación del comportamiento del software. La característica estimulo respuesta forma la base del modelo de comportamiento. Un programa de computadora siempre está en un estado, en un modo de comportamiento observable exteriormente (imprimiendo, calculando, etc.).

d. La división de los modelos que representan información, función y comportamiento de manera que se puedan descubrir los detalles por capas, para que las partes puedan entenderse fácilmente y establecer luego las interacciones entre las mismas de manera que se pueda conseguir la función global.

e. El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación. Una visión esencial de los requisitos del software presenta las funciones a conseguir y la información a procesar sin tener en cuenta los detalles de la implementación. La visión de implementación de los requisitos del software introduce la manifestación en el mundo real de las funciones de procesamiento y las estructuras de la información.
PRINCIPIOS DEL DISEÑO
El principio de segregación de interfaces
Este principio, conocido por ISP (Interface segregation principle), dice que el una clase que implementa una interfaz no debe depender de métodos que no utiliza. Esto como norma general implica que nuestras interfaces deben ser sencillas y tener pocos métodos. Es preferible tener varias interfaces pequeñas, a tener una interfaz grande. Así no obligamos a los clientes a depender de métodos que no necesitan implementar.
El principio de inversión de dependencias
En inglés DIP (Dependency Inversion Principle), que viene a decir que las clases de alto nivel, no deben depender de clases de bajo nivel. Ambos deben depender de abstracciones. Además las abstracciones no deben depender de los detalles, si no que los detalles deben depender de las abstracciones. En definitiva, lo que tenemos que hacer es invertir las dependencias.
Por ejemplo, imaginemos una clase Saludo que tiene un método que imprime un mensaje dependiendo de la hora del día. Si es antes de las 12 de la mañana, escribe "Buenos días". Si es más tarde escribe "Buenas tardes". En este caso el componente de alto nivel es la clase Saludo, mientras que el componente de bajo nivel, es una clase Date. El método Saludar instancia un objeto de la clase Datepara comprobar la hora del día y realizar el saludo que corresponda. En este caso tan simple, la clase Saludo depende de una clase de bajo nivel Date. Esto hace que, entre otras cosas, la clase Saludo sea más difícil de probar.
Si invertimos las dependencias, lo que podemos hacer es pasar un objeto Datecomo parámetro a la hora de instanciar la clase Saludo. Cuándo se llame al método Saludar se utilizará dicho objeto. En este caso estamos inyectando la dependencia a través del constructor de la clase Saludo.
Separa los asuntos
Principio SoC (separation of concerns). Los asuntos, son los diferentes aspectos de la funcionalidad de nuestra aplicación. Por ejemplo la capa de negocio, la capa de datos etc. Un buen ejemplo de separación es el patrón MVC.
PRINCIPIO DE CONSTRUCCION DEL SOFTWARE
Los principios fundamentales de la construcción de software son:
·         Minimizar la Complejidad
·         Anticipar los Cambios
·         Pensar en la Verificación posterior
·         Aplicar Estándares

ü  Minimizar la Complejidad
·         Escribiendo código sencillo y fácil de leer
·         Utilizando estándares
·         Técnicas de codificación
·         Técnicas de aseguramiento de calidad

ü  Anticipar los Cambios
·         El software se ve afectado por los cambios en su entorno y está destinado a cambiar a lo largo del tiempo
·         Aplicación de técnicas específicas

ü  Pensar en la Verificación posterior
·         Construir de forma que los fallos puedan ser encontrados lo antes posible (al codificar, hacer pruebas u operar el sistema)
·         Técnicas:
Ø  Seguir estándares de codificación
Ø  Hacer pruebas unitarias
Ø  Organizar el código para soportar pruebas automatizadas
Ø  Restringir el uso de técnicas complejas

ü  Aplicar Estándares
·         Directamente a la construcción del software:
Ø  Formatos de comunicación (documentos, contenidos).
Ø  Versiones estándares de lenguajes de programación (Java, C++, C#,…).
Ø  Reglas de codificación (nombres de variables comentarios )
Ø  Notaciones de diagramas (UML,…).
Ø  Intercambio entre herramientas (XLM,…).
·         En un proyecto:
Ø  Externos: propuestos por organismos de estandarización (ISO, ANSI, AENOR), consorcios industriales (OMG), asociaciones profesionales (IEEE, ACM).
Ø  Internos: creados por la propia organización.

PRINCIPIOS DE CODIFICACION DEL SOFTWARE
La escritura del código fuente es el principal esfuerzo de construcción de software
·         Aplicar técnicas para crear código fuente comprensible (reglas de asignación de nombres y de formato del código, clases, tipos enumerados, constantes, etiquetadas,…)
·         Manejar condiciones de error (errores previstos e imprevistos, excepciones)
·         Prevenir brechas de seguridad a nivel de código (llenado de buffers, overflow de índices de vectores, …)
·         Uso eficiente de recursos escasos (hilos, bloqueos en bases de datos, …)
·         Organizar el código fuente (sentencias, rutinas, clases, paquetes, …)
·         Documentar el código
PRINCIPIO DE VALIDACION DEL SOFTWARE
La validación también es una evaluación del sistema o de componentes, solo que es en el transcurso o al final del proceso del desarrollo, donde se determina si cumple con lo especificado.
Aspectos en la validación:
·         Construir el sistema correcto.
·         Evaluar la conformidad con la especificación de requisitos.
Principales Principios:
·         Especificación de los requisitos.
·         Prevención de defectos.
·         Tiempo y Esfuerzo.
·         Ciclo de vida del software.
·         Planificación.
·         Procedimientos.
·         Validación del software.
·         Alcance de la validación.
·         Independencia de la validación.
·         Flexibilidad y Responsabilidad.
PRINCIPIO DE PRUEBA DEL SOFTWARE
Las pruebas revelan la presencia de bugs, no la ausencia de ellos
Probar reduce la probabilidad de que existan bugs pero nunca se puede asegurar que no quede ninguno oculto.
Además, cada tipo de pruebas que realicemos (de sistema, de integración, añadir auditorías de código…) son más efectivas para detectar un tipo de bug.
Es imposible probarlo todo
El flujo de control de un sistema software no trivial como los que acostumbramos a utilizar en el día a día contiene miles de decisiones.
Estas decisiones se pueden combinar entre ellas para dar lugar a una infinidad de posibles caminos. De entrada, probar todos los caminos es un problema inabordable.
Y eso si no tenemos en cuenta la prueba de requisitos no funcionales, como el rendimiento de un sistema ante una exigente carga de usuarios, o requisitos específicos de seguridad (por ejemplo, en un sistema bancario) para protegerse de usuarios malintencionados.
Todo esto hace necesaria una estrategia de pruebas (un plan) y priorizar a partir de una gestión de riesgos de calidad y de proyecto, y como reza el siguiente principio…
Cuanto antes se comience a probar…mejor
Corregir un bug con una revisión en la fase de captura de requisitos o en una prueba unitaria tiene un coste mucho menor a lo que costará corregir este bug cuando se detecte en una prueba de sistema, o peor aún, en una prueba de aceptación por el cliente.
En demasiadas ocasiones existe una confianza excesiva en las pruebas de sistema, y todo el plan de pruebas (cuando existe) se reduce a estas. Se confía en que todos los componentes que no se probaron con una estrategia de pruebas unitarias y de integración se puedan entender bien a unos días del hito de entrega (cuando corregir un bug ya es demasiado caro, en lo que se denomina una prueba de integración “big-bang”).
Curiosamente estas malas prácticas se realizan para ahorrar costes, y finalmente el coste de la no calidad cambia las tornas: siempre se acaba pagando en unos costes de mantenimiento excesivos (con caídas de la productividad del 50% según Capers Jones).
La aglomeración de defectos. ¡Los bugs siempre van en pandilla!
Entender esto es muy importante para plantear una buena estrategia de pruebas: los bugs suelen ir en grupo. Se concentran en determinados puntos de un sistema software, no manteniendo una distribución uniforme a lo largo del mismo.
Conclusión: si encuentras un bug en un componente, es muy probable que haya más. Con lo que una posible estrategia sería centrarse en mejorar las pruebas de aquellos componentes para los que se han reportado un número mayor de bugs, para ser más eficaces a la hora de cazarlos en fases tempranas.
La paradoja del pesticida
O la necesidad de ajustar continuamente tu plan de pruebas… porque según este principio un plan de pruebas va perdiendo efectividad conforme se ejecuta sucesivas veces. Con lo que cada vez tenderá a encontrar menos bugs… ¡lo que no significa que no haya! (vuelve a leer el primer principio). Se habla de paradoja del pesticida ya que estos matabichos usualmente sirven para un tipo de bichos, pero una vez no queda ninguno del tipo específico que mata el pesticida… ¡nadie te dice que no haya otros bichos campando a sus anchas!
Las pruebas se deben adaptar a necesidades específicas
Esto viene a enlazar con lo que he comentado antes. Si tu producto se centra en el ámbito de la seguridad deberás adaptar tus casos de prueba para intentar forzar situaciones o posibles escenarios no amistosos. Si quieres probar una intranet donde los servicios más vitales son los de imputación de horas y el de vacaciones, es lógico centrarse en estos servicios y no invertir tiempo en otros componentes infrautilizados.  Además, hay que tener en cuenta que los recursos en los proyectos son siempre escasos, con lo que en el inicio del proyecto hay que preguntarse… qué estrategia debemos seguir para encontrar y corregir lo antes posible los bugs en las funcionalidades de mayor valor para nuestros usuarios.
La falacia de la ausencia de errores
Para terminar, nos encontramos con la satisfacción del usuario y con el hecho de que los usuarios elijan tu software para resolver sus necesidades. Que hayas corregido muchos bugs no significa que finalmente tu software sea un éxito. En ocasiones hay que primar un buen time to market, para luego corregir los problemas de calidad que quedaron por el camino. Y esto si se hace de manera consciente y con una buena estrategia, a priori, no debe ser un problema.
PRINCIPIO DE DESPLIEGUE DEL SOFTWARE
·         Se deben administrar las expectativas que el cliente tiene del software.
·         Se debe ensamblar y probar un paquete de entrega completo.
·         Se debe establecer un régimen de soporte antes de entregar el software.
·         Se debe proporcionar material instructivo apropiado  los usuarios finales.

·         El Software con errores se debe arreglar primero y entregar después.

QUE ES UN EQUIPO DE ALTO RENDIMIENTO?

Los equipos de alto rendimiento se caracterizan por que todos sus miembros se sienten bien integrados, se mantienen enfocados en los objetivos y trabajan de forma casi autónoma, sin que el jefe tenga que decirles exactamente lo que tienen que hacer.

¿CÓMO PODRÍA FORMAR UN EQUIPO DE ALTO RENDIMIENTO EN SU EMPRESA?

 los equipos de alto rendimiento están liderados por personas con una clara visión del futuro de la empresa, capaces de trazar una ruta de acción y crear empatía y energía creativa entre el grupo.


Los líderes de equipos de alto rendimiento tienen un estilo de liderazgo integrador, no autoritario, que se preocupa por entender la manera de trabajar de cada uno de sus miembros y sus necesidades particulares (pues hay personas que trabajan de forma más analítica y otras que se preocupan más por las relaciones interpersonales).
Además de tener un líder con estas características los equipos de alto rendimientos deberían:

1. Establecer metas claras y priorizarlas. Todos los miembros deben entender bien cuáles son las metas, la importancia de cumplirlas y sentir un fuerte compromiso hacia su logro. Mantener al equipo informado del progreso ayuda a mantener el equipo motivado o anuente a reaccionar rápidamente.

2. Estar conformados por personas talentosas con habilidades complementarias. La selección de los miembros del equipo es una de las bases del éxito. Es importante tener a personas con habilidades diversas para poder desarrollar tareas diferentes.

3. Contar con normas y una estructura definida. Las normas sobre cómo debe funcionar el equipo, cuáles son los roles y responsabilidades de cada uno de los miembros ayudará a evitar conflictos.

4. Hablar y escuchar. Es importante mantener una comunicación abierta entre las personas que conforman el equipo. A través de la comunicación, se genera más confianza, sinergia, aparte que se pueden resolver conflictos. Los equipos de alto rendimiento están conformados por personas que no temen hablar de las cosas difíciles, encuentran maneras para hacerlo asertivamente y sin atacar a los demás.

5. Tener autonomía. Para que los equipos de alto rendimiento trabajen de manera casi autónoma, deben sentirse en capacidad de tomar decisiones y fijar la manera en que trabajarán. No sólo deben ser capaces de tomar sus propias decisiones, sino sentirse responsables por las decisiones que toman y asumir el riesgo que ellas conlleven.

6. Reconocer y recompensar los resultados. La mayoría de los equipos de alto rendimiento trabaja por objetivos y al cumplirlos deberían ser reconocidos y recompensados. La compensación no sólo debería ser a nivel individual sino para todo el equipo.

¿POR QUÉ FALLAN MUCHOS EQUIPOS?

1. Algunos directores de equipo tienden a rodearse de colaboradores demasiado parecidos a ellos mismos.
2. a resultas de lo cual, muchos equipos están descompensados, con demasiados componentes coincidiendo en algunas funciones mientras en otras hay carencias importantes.
3. En muchas ocasiones la falta de conocimiento de los perfiles profesionales motiva una asignación incorrecta de tareas y responsabilidades.
 4. Los profesionales que trabajan en equipos descompensados suelen sentir que sus talentos y habilidades personales no son aprovechados al máximo con la consiguiente frustración y desmotivación.
El resultado siempre es el mismo: un grupo de personas que se afana en trabajar y produce unos resultados insuficientes.


La función del directivo es repartir de forma óptima el trabajo que es preciso realizar, en base a las capacidades y habilidades de los miembros del equipo.

martes, 9 de febrero de 2016

INTRODUCCIÓN ALA INGENIERA DEL SOFTWARE

Introducción

Este término fue introducido a finales de los 60 a raíz de la crisis del software.
Esta crisis fue el resultado de la introducción de la tercera generación del hardware.
El hardware dejo de ser un impedimento para el desarrollo de la informática; redujo los costos y mejoro la calidad y eficiencia en el software producido
La crisis se caracterizó por los siguientes problemas:
Imprecisión en la planificación del proyecto y estimación de los costos.
Baja calidad del software.
Dificultad de mantenimiento de programas con un diseño poco estructurado, etc.
Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en la compra.
También se requiere una serie de características como fiabilidad, facilidad de mantenimiento y de uso, eficiencia, etc.

Objetivos de la ingeniería de software

En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la ingeniería de software.
Mejorar la calidad de los productos de software
Aumentar la productividad y trabajo de los ingenieros del software.
Facilitar el control del proceso de desarrollo de software.
Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.
Definir una disciplina que garantice la producción y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.
Objetivos de los proyectos de sistemas
Para que los objetivos se cumplan las empresas emprenden proyectos por las siguientes razones: "Las cinco C”

Capacidad

Las actividades de la organización están influenciadas por la capacidad de ésta para procesar transacciones con rapidez y eficiencia.
Los sistemas de información mejoran esta capacidad en tres formas.
* Aumentan la velocidad de procesamiento:
Los sistemas basados en computadora pueden ser de ayuda para eliminar la necesidad de cálculos tediosos y comparaciones repetitivas.
Un sistema automatizado puede ser de gran utilidad si lo que se necesita es un procesamiento acelerado.
*Aumento en el volumen:
La incapacidad para mantener el ritmo de procesamiento no significa el abandono de los procedimientos existentes. Quizá éstos resulten inadecuados para satisfacer las demandas actuales. En estas situaciones el analista de sistemas considera el impacto que tiene la introducción de procesamiento computarizado, si el sistema existente es manual. Es poco probable que únicamente el aumento de la velocidad sea la respuesta. El tiempo de procesamiento por transacción aumenta si se considera la cantidad de actividades comerciales de la empresa junto con su patrón de crecimiento.
* Recuperación más rápida de la información:
Las organizaciones almacenan grandes cantidades de datos, por eso, debe tenerse en cuenta donde almacenarlos y como recuperarlos cuando se los necesita.
Cuando un sistema se desarrolla en forma apropiada, se puede recuperar en forma rápida la información.

Costo

* Vigilancia de los costos:
Para determinar si la compañía evoluciona en la forma esperada, de acuerdo con lo presupuestado, se debe llevar a cabo el seguimiento de los costos de mano de obra, bienes y gastos generales.
La creciente competitividad del mercado crea la necesidad de mejores métodos para seguir los costos y relacionarlos con la productividad individual y organizacional.
* Reducción de costos:
Los diseños de sistemas ayudan a disminuir los costos, ya que toma ventaja de las capacidades de cálculo automático y de recuperación de datos que están incluidos en procedimientos de programas en computadora. Muchas tareas son realizadas por programas de cómputo, lo cual deja un número muy reducido de éstas para su ejecución manual, disminuyendo al personal.

Control

*Mayor seguridad de información:
Algunas veces el hecho de que los datos puedan ser guardados en una forma adecuada para su lectura por medio de una máquina, es una seguridad difícil de alcanzar en un medio ambiente donde no existen computadoras.
Para aumentar la seguridad, generalmente se desarrollan sistemas de información automatizados. El acceso a la información puede estar controlado por un complejo sistemas de contraseñas, limitado a ciertas áreas o personal, si está bien protegido, es difícil de acceder.
*Menor margen de error: (mejora de la exactitud y la consistencia)
Esto se puede lograr por medio del uso de procedimientos de control por lotes, tratando de que siempre se siga el mismo procedimiento. Cada paso se lleva a cabo de la misma manera, consistencia y con exactitud: por otra parte se efectúan todos los pasos para cada lote de transacciones. A diferencia del ser humano, el sistema no se distrae con llamadas telefónicas, ni olvidos e interrupciones que sufre el ser humano. Si no se omiten etapas, es probable que no se produzcan errores.

Comunicación

La falta de comunicación es una fuente común de dificultades que afectan tanto a cliente como a empleados. Sin embargo, los sistemas de información bien desarrollados amplían la comunicación y facilitan la integración de funciones individuales.
* Interconexión: (aumento en la comunicación)
Muchas empresas aumentan sus vías de comunicación por medio del desarrollo de redes para este fin, dichas vías abarcan todo el país y les permiten acelerar el flujo de información dentro de sus oficinas y otras instalaciones que no se encuentran en la misma localidad.
Una de las características más importantes de los sistemas de información para oficinas es la transmisión electrónica de información, como por ejemplo, los mensajes y los documentos.
* Integración de áreas en las empresas:
Con frecuencia las actividades de las empresas abarcan varias áreas de la organización, la información que surge en un área se necesita en otra área, por ejemplo.
Los sistemas de información ayudan a comunicar los detalles del diseño a los diferentes grupos, mantienen las especificaciones esenciales en un sitio de fácil acceso y calculan factores tales como el estrés y el nivel de costos a partir de detalles proporcionados por otros grupos.