TÉCNICAS DE RECOLECCIÓN DE DATOS

CUESTIONARIO

1 ¿tiene computador en casa?

2 ¿sabe usar la computadora?

3 ¿usa la computadora?

4 ¿usa el internet?

5 ¿cuanto tiempo?

a) menos de una hora b) una hora c) mas de una hora (por dia)

6 ¿que programas utiliza?

7 ¿cuales son sus preferencias al navegar (si lo hace)?

8 ¿en que utiliza la computadora?

opciones: a) diversion b) tareas escolares c)trabajo

9 ¿a utilizado el internet para comunicarse con amigos y familiares (facebook)?

10 ¿que opina de las TIC?

ENCUESTA

*Como ejemplo tenemos la encuesta de una tienda que vende sofware y hardware de la computadora:

La encuesta tiene como objetivo reunir opiniones de los clientes para asi poder mejorar nuestra atencion y nuestros productos

1.-¿Que opinion tiene sobre nuestros productos?

2.-¿Que opina de la atencion afrecida por el vendedor?

3.-¿Que opinion da sobre los precios de nuestros productos?

4.-¿El ambiente de nuestra tienda le parecio agradable?

5.-¿Al momento de comprar algun producto. el vendedor le entrega ls instrucciones del producto?

6.-Considera a nuestros productos...

              *Buenos           *Regulares            *Malos

7.-Le gusto la actitud de los vendedores...

               *Si                   *No

8.-El servicio de entrega del producto fue ...

               *Rapido            *Lento                  *Regular

9.-Los precios se le icieron...

                *Caros           *Muy caros          *Normales          *Baratos

10.-Recomendaria a demas personas esta tienda...

                *Si                 *No

ENTREVISTA

 *Como ejemplo tenemos la entrevista a una persona para que pueda entrar a una empresa como diseñador grafico:

1.-Ha laborado en alguna otra empresa

              *Si              *No

2.-¿Cuales fueron sus trabajos anteriores?

3.-¿Como fue su desempeño en su anterior trabajo?

 4.-¿De que manera obtuvo el puesto en su anterior trabajo?

5.-¿Como fue su desempeño?

6.-Que actividades desarrollaba?

7.-¿Que estudios tiene cursados?

             *Primaria            *Secundaria          *Estudios superiores

8.-¿Defina sus defectos?

9.-¿Defina sus virtudes?

10.-¿Cual es su interes en este trabajo?

TIPOS DE DIAGRAMAS UML

DIAGRAMAS DE CASOS DE USO


Los Casos de Uso no forma parte de la llamada Fase de Diseño, sino parte de la fase de Análisis, respondiendo el interrogante ¿Qué?. De forma que al ser parte del análisis ayuda a describir que es lo que el sistema debe hacer.

Estos diagramas muestran operaciones que se esperan de una aplicación o sistema y como se relaciona con su entorno, es por ello que se ve desde el punto de vista del usuario. Describen un uso del sistema y como éste interactúa con el usuario.

Los casos de usos se representan en el diagrama por una elipses la cual denota un requerimiento solucionado por el sistema.
El conjunto de casos de usos representa la totalidad de operaciones que va a desarrollar el sistema. Por último a estos elipses lo acompaña un nombre significativo de manera de rótulo.











Otro elemento fundamental de estos diagramas son los actores la cual representa a un usuario del sistema, que necesita o interactúa con algún caso de uso, la que también es acompañado por un nombre.Por último tenemos los flujos de eventos quecorresponde a la ejecución normal y exitosa del caso de uso.




DIAGRAMA DE CLASES



En UML el diagrama de clases es uno de los tipos de diagramas o símbolo estático y tiene como fin describir la estructura de un sistema mostrando sus clases, atributos y relaciones entre ellos.




Estos diagramas son utilizados durante el proceso de análisis y diseño de los sistemas informáticos, en donde se intentan conformar el diagrama conceptual de la información que se manejará en el sistema.






Como ya sabemos UML es un modelado de sistema Orientados a Objetos, por ende los conceptos de este paradigma se incorporan a este lenguaje de modelado.




























Los diagramas de clases tiene las siguientes características:
Las clases define el ámbito de definición de un conjunto de objetos.
Cada objeto pertenece a una clase.
Los objetos se crean por instanciación de las clases.






DIAGRAMA DE OBJETOS



Forma parte de la vista estática del sistema. En este diagrama se modelan las instancias de la clases del Diagrama de Clases. Este diagrama cabe aclarar que cuenta con objetos y enlaces. En estos diagramas también es posible encontrar las clases para tomar como referencia su instanciación.











En otras palabras el Diagrama de Objetos muestra un conjunto de objetos y sus relaciones en un momento concreto.Los Diagramas de Objetos son realmente útiles para modelar estructuras de datos complejas








DIAGRAMAS DE COMPORTAMIENTOS





Diagrama de Estados


Un estado es una condición durante la vida de un objeto, de forma que cuando dicha condición se satisface se lleva a cabo alguna acción o se espera por un evento.


El estado de un objeto se puede caracterizar por el valor de uno o varios de los atributos de su clase, además, el estado de un objeto también se puede caracterizar por la existencia de un enlace con otro objeto.






El diagrama de estados engloba todos los mensajes que un objeto puede enviar o recibir, en otras palabras es un escenario que representa un camino dentro de un diagrama.

Como característica de estos diagramas siempre cuentan con dos estados especiales, el inicial y el final, con la particularidad que este diagrama puede tener solo un estado inicial pero varios estados finales.

Una transición entre estados representa un cambio de un estado origen a un estado sucesor destino que podría ser el mismo que el estado origen, dicho cambio de estado puede estar aparejado con alguna acción. Además las acciones se asocian a las transiciones y se consideran que ocurre de forma rápida e ininterrumpible.











Los elementos que componen estos diagramas son:



Círculo lleno, apuntando el estado inicial.
Círculo hueco que contiene un círculo lleno más pequeño en el interior, indicando el estado final.
Rectángulo redondeado dividido por una línea horizontal, indicado los estados, en la parte de arriba se encuentra el nombre del estado y abajo se indica la actividad que realiza.
Flecha, la cual denota la transición, el nombre del evento que causa esta transición etiqueta el cuerpo de la flecha.






Diagrama de actividad


Un Diagrama de Actividades representa un flujo de trabajo paso a paso de negocio y operacionales de los componentes en un sistema.

En UML 1, un diagrama de actividades es una variación del Diagrama de Estados UML donde los estados representan operaciones y las transiciones representan las actividades que ocurren cuando la operación es completa.

En la actualidad, el diagrama de actividades en UML 2.0 es similar al aspecto del diagrama en UML 1, solo que ahora la semántica esta basada en lo que se conoce como Redes de Petri. En UML 2.0, el diagrama general de interacción está basado en el diagrama de Actividad.

Componentes:
Inicio: el inicio de un diagrama de actividades es representado por un círculo de color negro sólido.
Actividad: Una actividad representa la acción que será realizada por el sistema la cual representa dentro de un óvalo.
Transición: Una transición ocurre cuando se lleva acabo el cambio de una actividad a otra, la transición es representada simplemente por una línea con una flecha en su terminación para indicar su dirección.

















DIAGRAMA DE INTERACCION




Diagrama de Secuencia




Un Diagrama de Secuencias muestra una interacción ordenada según la secuencia temporal de eventos y el intercambio de mensajes. Los diagramas diagramas de secuencia ponen especial énfasis en el orden y el momento en el que se envían los mensajes a los objetos.

















En los diagramas de Secuencias los elementos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta.

Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamadohasta que el método finalize, o asíncronos donde se devuelve el control directamente al objeto que realiza la llamada.

Los mensajes síncronos tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control del programa.






Diagrama de Colaboración

Un diagrama de colaboración, se puede decir que es una forma alternativa al diagrama de secuencias a la hora de mostrar un escenario.
Este tipo de diagrama muestra las interacciones que ocurren entre los objetos que participan en una situación determinada.
A diferencia del diagrama de secuencia, el diagrama de colaboración se enfoca en la relación entre los objetos y su topología de comunicación.

En estos diagramas los mensajes enviados de un objeto a otro se representa mediante flechas, acompañado del nombre del mensaje, los parámetros y la secuencia del mensaje.

Estos diagramas están indicados para mostrar una situación o flujo de programa específico y son considerados uno de los mejores diagramas para mostrar o explicar rápidamente un proceso dentro de la lógica del programa












DIAGRAMA DE IMPLEMENTACION




Diagrama de componentes




Lo que distingue el Diagrama de Componentes de otro tipo de diagramas es sin duda su contenido. Normalmente contiene componentes, interfaces y relaciones entre ellos.Los componentes perteneces a un mundo físico, es decir, representan a un bloque de construcción al modelar aspectos físicos de un sistema.


Cada componente debe tener un nombre que lo distinga de los demás. Al igual que las clases los componentes pueden enriquecerse con compartimientos adicionales que muestran sus detalles.








Diagrama de Despliegue




Básicamente este tipo de diagrama se utiliza para modelar el Hardware utilizado en la implementación del sistema y la relaciones entre sus componentes.


Los elementos usados por este tipo de diagrama son nodos, componentes y asociaciones. En el UML 2.0 los componentes ya no están dentro de nodos, en cambio puede haber artefactos (archivo, un programa, una biblioteca o Base de datos) u otros nodos dentro de nodos.

















Además los Diagramas de Despliegue muestran la configuración en funcionamiento del sistema incluyendo su software y su hardware. Para cada componente de un diagrama es necesario que se deba documentar las características técnicas requeridas, el trafico de red, el tiempo de respuesta, etc.

UML (LENGUAJE UNIFICADO DE MODELADO UML)

 

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

 Antes de UML 1.x

Después de que la Rational Software Corporation contratara a James Rumbaugh de General Electric en 1994, la compañía se convirtió en la fuente de los dos esquemas de modelado orientado a objetos más populares de la época: el OMT (Object-modeling technique) de Rumbaugh, que era mejor para análisis orientado a objetos, y el Método Booch de Grady Booch, que era mejor para el diseño orientado a objetos. Poco después se les unió Ivar Jacobson, el creador del método de ingenieríá de software orientado a objetos. Jacobson se unió a Rational en 1995, después de que su compañía Objectory AB fuera comprada por Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se sabia de sus constantes argumentos sobre las prácticas metodológicas.

En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la adopción de la tecnología de objetos, y para orientarse hacia un método unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de Modelado abierto. Se consultó con representantes de compañías competidoras en el área de la tecnología de objetos durante la OOPSLA '96; eligieron cajas para representar clases en lugar de la notación de Booch que utilizaba símbolos de nubes.

Bajo la dirección técnica de los Tres Amigos fue organizado un consorcio internacional llamado UML Partners en 1996 para completar las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo como una respuesta al OMG RFP. El borrador de la especificación UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para finalizar las semánticas de la especificación y para integrarla con otros esfuerzos de estandarización. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.

UML 1.x

Como notación de modelado, la influencia de la OMT domina UML (por ejemplo el uso de rectángulos para clases y objetos). Aunque se quitó la notación de "nubes" de Booch, si se adoptó la capacidad de Booch para especificar detalles de diseño en los niveles inferiores. La notación de Casos de Uso del Objectory y la notación de componentes de Booch fueron integrados al resto de la notación, pero la integración semántica era relativamente débil en UML 1.1, y no se arregló realmente hasta la revisión mayor de UML 2.0.

Conceptos de muchos otros métodos OO fueron integrados superficialmente en UML con el propósito de hacerlo compatible con todos los métodos OO. Además el grupo tomó en cuenta muchos otros métodos de la época, con el objetivo de asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en una variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones de un sólo usuario a sistemas concurrentes y distribuidos.

MODELOS DE CICLO DE VIDA

En los años 70 se impuso un nuevo enfoque de desarrollo del software, introducido por Royce en 1970, a través de un ciclo de vida en “cascada” (así denominado por la disposición de las distintas fases de desarrollo, en las que los resultados de una fase parecen caer en cascada hacia la siguiente fase, tal como se muestra en la Figura 1). El método ideado por Royce constituye uno de los primeros modelos de ciclo de vida publicados, por lo que también recibe el nombre de modelo de ciclo de vida clásico. Este método modela el ciclo convencional de la Ingeniería del Software, aplicando un enfoque sistemático y secuencial de desarrollo que comienza con la ingeniería del sistema y progresa a través del análisis, diseño, codificación, pruebas y mantenimiento.

Ventajas:

• Es un modelo sencillo y disciplinado
• Es fácil aprender a utilizarlo y comprender su funcionamiento
• Está dirigido por los tipos de documentos y resultados que deben obtenerse al final de cada etapa
• Ha sido muy usado y, por tanto, está ampliamente contrastado
• Ayuda a detectar errores en las primeras etapas a bajo costo
• Ayuda a minimizar los gastos de planificación, pues se realiza sin problemas

Desventajas:

• Los proyectos raramente siguen el proceso lineal tal como se definía originalmente el ciclo de vida
• Es difícil que el cliente exponga explícitamente todos los requisitos al principio
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• No refleja exactamente cómo se programa realmente el sistema, en el que suele haber un gran componente iterativo
• Puede resultar complicado regresar a etapas anteriores (ya acabadas) para realizar correcciones
• El producto final obtenido puede que no refleje todos los requisitos del usuario

 

El modelo en V es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño. Como se muestra en la Figura 3, la codificación forma el vértice de la V, con el análisis y el diseño a la izquierda y las pruebas y el mantenimiento a la derecha.

Figura 3 Modelo de Ciclo de Vida en V
La unión mediante líneas discontinuas entre las fases de la parte izquierda y las pruebas de la derecha representa una doble información. Por un lado sirve para indicar en qué fase de desarrollo se deben definir las pruebas correspondientes. Por otro sirve para saber a qué fase de desarrollo hay que volver si se encuentran fallos en las pruebas correspondientes.
Por lo tanto el modelo en V hace más explícita parte de las iteraciones y repeticiones de trabajo que están ocultas en el modelo en cascada. Mientras el foco del modelo en cascada se sitúa en los documentos y productos desarrollados, el modelo en V se centra en las actividades y la corrección.
Ventajas y desventajas  del Modelo en “V”

Ventajas:
• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

Desventajas:

• Es difícil que el cliente exponga explícitamente todos los requisitos
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario

INGENIERIA DE SISTEMAS

La ingeniería de sistemas es la aplicación de las ciencias matemáticas y físicas para desarrollar sistemas que utilicen económicamente los materiales y fuerzas de la naturaleza para el beneficio de la humanidad.

Una definición especialmente completa -y que data de 1974- nos la ofrece un estándar militar de las fuerzas aéreas estadounidenses sobre gestión de la ingeniería (MIL-STD-499B Systems Engineering).

Ingeniería de sistemas es la aplicación de esfuerzos científicos y de ingeniería para:

• transformar una necesidad de operación en una descripción de parámetros de rendimiento del sistema y una configuración del sistema a través del uso de un proceso interactivo de definición, síntesis, análisis, diseño, prueba y evaluación;

• integrar parámetros técnicos relacionados para asegurar la compatibilidad de todas las interfaces de programa y funcionales de manera que optimice la definición y diseño del sistema total

•  integrarse factores de fiabilidad, mantenibilidad, seguridad, supervivencia, humanos y otros en el esfuerzo de ingeniería total a fin de cumplir los objetivos de coste, planificación y rendimiento técnico.                                                                                                                                                                                               

Historia  

Esta área comenzó a desarrollarse en la segunda parte del siglo XX con el veloz avance de la ciencia de sistemas. Las empresas comenzaron a tener una creciente aceptación de que la ingeniería de sistemas podía gestionar el comportamiento impredecible y la aparición de características imprevistas de los sistemas (propiedades emergentes). Las decisiones tomadas al comienzo de un proyecto, cuyas consecuencias pueden no haber sido entendidas claramente, tienen una enorme implicación más adelante en la vida del sistema. Un ingeniero de sistemas debe explorar estas cuestiones y tomar decisiones críticas. No hay métodos que garanticen que las decisiones tomadas hoy serán válidas cuando el sistema entre en servicio años o décadas después de ser concebido, pero hay metodologías que ayudan al proceso de toma de decisiones. Ejemplos como la metodología de sistemas blandos (Soft Systems Methodology), la dinámica de sistemas, modelo de sistemas viables (Viable System Model), teoría del Caos, teoría de la complejidad, y otros que también están siendo explorados, evaluados y desarrollados para apoyar al ingeniero en el proceso de toma de decisiones que se puede llegar a ser por medio del CENAL.   

CICLO DE VIDA DE UN SISTEMA DE INFORMACION

El ciclo de vida de un sistema de información es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista y del usuario.

Según James Senn, existen tres estrategias para el desarrollo de sistemas: el método clásico del ciclo de vida de desarrollo de sistemas, el método de desarrollo por análisis estructurado y el método de construcción de prototipos de sistemas. Cada una de estas estrategias tienen un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada. 

En la actualidad para muchas organizaciones, los sistemas de información basados en computadoras son el corazón de las actividades cotidianas y objeto de gran consideración en la toma de decisiones, las empresas consideran con mucho cuidados las capacidades de sus sistemas de información cuando deciden ingresar o no en nuevos mercados o cuando planean la respuesta que darán a la competencia.

Al establecer los sistemas de información basados en computadoras deben tener la certeza de que se logren dos objetivos principales: que sea un sistema correcto y que este correcto el sistema. Ningún sistema que deje satisfacer ambos objetivos será completamente útil para la gerencia u organización.

Si los dispositivos de un sistema de información no se adaptan a su población de clientes, no lograra sus objetivos potenciales. A mismo tiempo, aun cuando se identifiquen precisamente las necesidades del usuario, un sistema de información va tener un valor único si funciona en forma adecuada.

Los informes y las salidas producidas por el sistema deben ser precisos, confiables y completos. La función del Análisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios.

Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre.

Aunque la estimación, es más un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena Ingeniería Sistemas y Software.

Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones.

A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software. La disponibilidad de información Histórica es otro elemento que determina el riesgo de la estimación.

CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS

 El método de ciclo de vida para el desarrollo de sistemas es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:

1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.

2). Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:

¿Qué es lo que hace?

¿Cómo se hace?

¿Con que frecuencia se presenta?

¿Qué tan grande es el volumen de transacciones o decisiones?

¿Cuál es el grado de eficiencia con el que se efectúan las tareas?

¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?

3). Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.

4). Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.

Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.

5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.

Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.

6). Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.

Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

*Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.

*Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.

*Opinión de loa administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.

*Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.