En qué consiste la prueba de funcionalidad?
Se refiere a verificar y evaluar que el sistema este realizando los procesos, tareas y actividades adecuadamente y así obtener un resultado conveniente.
En qué consiste la prueba de compatibilidad?
Es la condición para verificar que un programa o sistema logre comprenderse correctamente en otra plataforma.
En qué consiste las pruebas de comunicaciones?
Se refiere a verificar que la cantidad de datos transferidos sea la adecuada
En qué consiste las pruebas de la caja blanca?
En programación, se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo.
En qué consiste las pruebas de la caja negra?
Se encuentran enfocadas a los requisitos funcionales del software y permiten al desarrollador centrarse en la coherencia de las entradas y salidas del sistema
Que es una prueba de robustez?
Su objetivo es comprobar la capacidad del sistema para soportar múltiples accesos concurrentes sin sufrir una merma considerable en su rendimiento.
Que es auditoria informática?
Es un examen crítico para evaluar y verificar los procesos y actividades dentro de una entidad así como verificar la eficacia y eficiencia de estos procesos.
Escribe 3 aspectos del porque es importante la auditoria informática.
Para evaluar los dispositivos de un centro de computo.
Para mejorar los procesos a través de recomendaciones.
Para tener una mejor perspectiva sobre nuestros centros de cómputo así como ventajas y desventajas.
En qué consiste la auditoria informática de producción o explotación?
En algunos casos también conocida como de Explotación u Operación, se ocupa de revisar todo lo que se refiere con producir resultados informáticos, listados impresos, ficheros soportados magnéticamente, ordenes automatizadas para lanzar o modificar procesos, etc.
En qué consiste la auditoria informática de desarrollo de proyectos?
La función de desarrollo es una evolución del llamado análisis y programación de sistemas, y abarca muchas áreas, como lo son: prerequisitos del usuario y del entorno, análisis funcional, diseño, análisis orgánico (preprogramación y programación), pruebas entrega a explotación o producción y alta para el proceso.
En qué consiste la auditoria informática de sistemas?
Se ocupa de analizar y revisar los controles y efectividad de la actividad que se conoce como técnicas de sistemas en todas sus facetas y se enfoca principalmente en el entorno general de sistemas, el cual incluye sistemas operativos, softwares básicos, aplicaciones, administración de base de datos, etc.
En qué consiste la auditoria informática de comunicaciones y redes?
Este tipo de revisión se enfoca en las redes, líneas, concentradores, multiplexores, etc. Así pues, la Auditoría Informática ha de analizar situaciones y hechos algunas veces alejados entre sí, y está condicionada a la participación de la empresa telefónica que presta el soporte. Para este tipo de auditoría se requiere un equipo de especialistas y expertos en comunicaciones y redes.
En qué consiste la auditoria de la seguridad informática?
La Auditoría de la seguridad en la informática abarca los conceptos de seguridad física y lógica. La seguridad física se refiere a la protección del hardware y los soportes de datos, así como la seguridad de los edificios e instalaciones que los albergan. El auditor informático debe contemplar situaciones de incendios, inundaciones, sabotajes, robos, catástrofes naturales, etc.
En qué consiste la auditoria informática para aplicaciones en internet?
En este tipo de revisiones, se enfoca principalmente en verificar los siguientes aspectos, los cuales no puede pasar por alto el auditor informático:
• Evaluación de los riesgos de internet (operativos, tecnológicos y financieros) y así como su probabilidad de ocurrencia.
• Evaluación de vulnerabilidades y la arquitectura de seguridad implementada.
• Verificar la confidencialidad de las aplicaciones y la publicidad negativa como consecuencia de ataques exitosos por parte de hackers.
Cuál es la metodología de trabajo de la Auditoria Informática?
El método de trabajo del auditor pasa por las siguientes etapas:
• Alcance y Objetivos de la Auditoría Informática.
• Estudio inicial del entorno auditable.
• Determinación de los recursos necesarios para realizar la auditoría.
• Elaboración del plan y de los Programas de Trabajo.
• Actividades propiamente dichas de la auditoría.
• Confección y redacción del Informe Final.
Definición de mantenimiento?
Medidas y acciones que se toman para mantener el funcionamiento de algo.
En qué consiste el mantenimiento preventivo?
Permite detectar fallos y anomalías que pueden ocurrir si no se tiene un mantenimiento frecuente.
En qué consiste el mantenimiento correctivo?
Es cuando el equipo está fallando y se debe detectar la causa o motivo del por cual fue el problema.
Menciona 3 dificultades del mantenimiento?
- Restricciones de tamaño y espacio de almacenamiento
- Herramientas desfasadas, sin métodos
- Una o varias migraciones a nuevas plataformas
- Múltiples modificaciones para adaptarlos o mejorarlos
- Desarrolladores no localizables
En qué consiste los costes del mantenimiento?
Los costes de mantenimiento son aquellos que generan un costo cuando se necesita realizar un reparación un cambio de dispositivo, etc o que se lleva a cabo un plan de mantenimiento para evitar fallos de los equipos.
jueves, 5 de agosto de 2010
jueves, 22 de julio de 2010
AUDITORÍA INFORMÁTICA.
AUDITORÌA Y SEGURIDAD INFORMÀTICA.
La auditoría es un examen crítico que evalúa la eficacia y eficiencia de los procesos de una empresa a través de las políticas y planes que se llevan acabo dentro de la entidad.
Esto con el fin de verificar que todos los procesos se llevan acabo basándose en los planes y objetivos de las áreas y a su vez entregar un dictamen final donde se darán recomendaciones así como las anomalías que hay dentro de la entidad para aplicarlas y mejorar el proceso.
La auditoria informática es un examen crítico que evalúa la eficacia y eficiencia de los procesos de un sistema para verificar que estos se llevan a cabo adecuadamente.
Tipos de Auditoría:
-Hardware.
-Software.
-Inventario
-Actualización.
-Bases de Datos.
-Integridad.
-Seguridad.
-Redundancias.
-Consistencia.
-Accesibilidad.
-Redes.
-Seguridad.
-Control de Accesos.
-Antivirus.
-Backups.
Principales objetivos de la Auditoría Informática.
- El control de la función informática,
- El análisis de la eficacia del Sistema Informático,
- La verificación de la implantación de la Normativa,
- La revisión de la gestión de los recursos informáticos
La auditoría es un examen crítico que evalúa la eficacia y eficiencia de los procesos de una empresa a través de las políticas y planes que se llevan acabo dentro de la entidad.
Esto con el fin de verificar que todos los procesos se llevan acabo basándose en los planes y objetivos de las áreas y a su vez entregar un dictamen final donde se darán recomendaciones así como las anomalías que hay dentro de la entidad para aplicarlas y mejorar el proceso.
La auditoria informática es un examen crítico que evalúa la eficacia y eficiencia de los procesos de un sistema para verificar que estos se llevan a cabo adecuadamente.
Tipos de Auditoría:
-Hardware.
-Software.
-Inventario
-Actualización.
-Bases de Datos.
-Integridad.
-Seguridad.
-Redundancias.
-Consistencia.
-Accesibilidad.
-Redes.
-Seguridad.
-Control de Accesos.
-Antivirus.
-Backups.
Principales objetivos de la Auditoría Informática.
- El control de la función informática,
- El análisis de la eficacia del Sistema Informático,
- La verificación de la implantación de la Normativa,
- La revisión de la gestión de los recursos informáticos
jueves, 24 de junio de 2010
CARACTERISTICAS PERT-CPM
MENCIONA LAS CARACTERISTICAS Y DIFERENCIAS DE PERT/CPM
DIAGRAMA PERT
DIAGRAMA CPM
DIAGRAMA PERT
DIAGRAMA CPM
MODELO DE PROTOTIPOS
El método de prototipo incluye el desarrollo interactivo o en continua evolución, donde el usuario participa de forma directa en el proceso.
-Este método contiene condiciones únicas de aplicación, en donde los encargados del desarrollo tienen poca experiencia o información, o donde los costos y riesgos de que se cometa un error pueden ser altos.
-Resulta útil para probar la facilidad del sistema e identificar los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación.
Pasos:
1.- Recolección de análisis de requerimientos: La determinación de los requerimientos de una aplicación es tan importante para el m‚todo de desarrollo de prototipos como lo es para el ciclo de desarrollo de sistemas o análisis estructurado. Por consiguiente, antes de crear un prototipo, los analistas y usuario deben de trabajar juntos para identificar los requerimientos conocidos que tienen que satisfacer.
2.- Desarrollo de un modelo de trabajo
Componentes:
a). El lenguaje para el dialogo o conversación entre el usuario y el sistema.
b). Pantallas y formatos para la entrada de datos.
c). Módulos esenciales de procesamiento.
d). Salida del sistema.
3.- Utilización del prototipo: Debe ser bajo condiciones del usuarios responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación. La experiencia del sistema bajo condiciones reales permite obtener la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, así como las características inadecuadas
4.- Revisión del prototipo: Durante la evaluación los analistas de sistemas desean capturar información sobre los que les gusta y lo que les desagrada a los usuarios.
Los cambios al prototipo son planificados con los usuarios antes de llevarlos a cabo, sin embargo es el analista responsable de tales modificaciones.
5.- Repetición del proceso las veces que sea necesarias: El proceso antes descrito se repite varias veces, el proceso finaliza cuando los usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias.
-Este método contiene condiciones únicas de aplicación, en donde los encargados del desarrollo tienen poca experiencia o información, o donde los costos y riesgos de que se cometa un error pueden ser altos.
-Resulta útil para probar la facilidad del sistema e identificar los requerimientos del usuario, evaluar el diseño de un sistema o examinar el uso de una aplicación.
Pasos:
1.- Recolección de análisis de requerimientos: La determinación de los requerimientos de una aplicación es tan importante para el m‚todo de desarrollo de prototipos como lo es para el ciclo de desarrollo de sistemas o análisis estructurado. Por consiguiente, antes de crear un prototipo, los analistas y usuario deben de trabajar juntos para identificar los requerimientos conocidos que tienen que satisfacer.
2.- Desarrollo de un modelo de trabajo
Componentes:
a). El lenguaje para el dialogo o conversación entre el usuario y el sistema.
b). Pantallas y formatos para la entrada de datos.
c). Módulos esenciales de procesamiento.
d). Salida del sistema.
3.- Utilización del prototipo: Debe ser bajo condiciones del usuarios responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación. La experiencia del sistema bajo condiciones reales permite obtener la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, así como las características inadecuadas
4.- Revisión del prototipo: Durante la evaluación los analistas de sistemas desean capturar información sobre los que les gusta y lo que les desagrada a los usuarios.
Los cambios al prototipo son planificados con los usuarios antes de llevarlos a cabo, sin embargo es el analista responsable de tales modificaciones.
5.- Repetición del proceso las veces que sea necesarias: El proceso antes descrito se repite varias veces, el proceso finaliza cuando los usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias.
Modelos Ciclo de Vida de los Sistemas.
1.1 Segmentación y modalidad
1.2 Criterios y elementos de conexión entre las partes
Ciclo de vida del software
“Una aproximación lógica a la adquisición, el suministro,
el desarrollo, la explotación y el mantenimiento del software”.
IEEE 1074
“Un marco de referencia que contiene los procesos, las actividades
y las tareas involucradas en el desarrollo, la explotación y el
mantenimiento de un producto de software, abarcando la vida del
sistema desde la definición de los requisitos hasta la finalización de
su uso”.
ISO 12207-1
De acuerdo a la definición anterior el ciclo de vida de un sistema es un enfoque por fases del análisis y diseño que sostiene que los sistemas sean desarrollados de mejor manera mediante el uso de un ciclo en especifico; determina el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Jaime APV.
Lista de modelos
1.-Modelo en cascada
2.-Modelo incremental
3.-Modelo en espiral
4.-Prototipado
5.- Concurrente
6.- Modelo de Prototipado de Requerimientos
7.- Modelo De Desarrollo Evolutivo
8.- La reutilización en el Ciclo de Vida
9.- Síntesis automática de Software
10. Comparación de Ciclos de Vida
11. Modelos para desarrollo de sistemas Orientados a
Objetos.
Modelo en cascada
-Flujo secuencial entre las fases.
-Cada etapa tiene un input y un output.
-Se supone que para comenzar con una
etapa deben haber finalizado las
anteriores.
Contribuciones:
-El proceso debe ser disciplinado, planeado
y gerenciado
-La implementación debe posponerse hasta
que los objetivos se hayan comprendido
Ingeniería de requerimientos
-Identificar y documentar los requerimientos
exactos del sistema según las necesidades de
los usuarios finales.
-Cualidades del sistema.
-Funcionales, no−funcionales, del proceso y del
mantenimiento
Diseño- Especificación
-Dividir el sistema en partes y establecer las
relaciones entre ellas.
-Arquitectura y diseño detallado.
-Establecer qué hará exactamente cada parte.
-En esta fase se crea un modelo funcional−
estructural de los requerimientos.
-El diseño debe permitir implementaciones que
verifiquen los requerimientos.
Críticas:
-No refleja realmente el proceso de desarrollo del software
-Se tarda mucho tiempo en pasar por todo el ciclo
-Perpetua el fracaso de la industria del software en su
comunicación con el usuario final
-El mantenimiento se realiza en el código fuente
-Las revisiones de proyectos de gran complejidad son muy
difíciles
-Impone una estructura de gestión de proyectos
Modelo Espiral
El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:
-Determinar qué quieres lograr.
-Determinar las rutas alternativas que puedes tomar para lograr estas metas.
-Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.
-Seguir la alternativa seleccionada en el paso 2.
-Establecer qué tienes terminado.
La dimensión radial en la figura refleja costos acumulativos incurridos en el proyecto.
Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situación y determinamos que los mayores riesgos son la interfaz del usuario. Después de un cuidadoso análisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificación de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de acción es construir un prototipo.
Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentación útil. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer sólo después de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximación es construir un incremento del sistema que satisfaga sólo los requerimientos mejor entendidos. Hagámoslo ya. Después del despliegue, el cliente nos provee de retroalimentación que dirá si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarán en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza.
El modelo espiral captura algunos principios básicos:
Decidir qué problema se quiere resolver antes de viajar a resolverlo.
Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatible.
Modelo Concurrente
Como el modelo espiral, el modelo concurrente provee una meta-descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del proceso de desarrollo de software. Discutamos un poco tales casos:
Los requerimientos son usualmente "líneas de base", cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados también). Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo.
Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en esos componentes estables. Similarmente, durante el diseño detallado, puede ser posible proceder con la codificación y quizás regular testeando en forma unitaria o realizando testeo de integración previo a llevar a cabo el diseño detallado de todos los componentes.
1.2 Criterios y elementos de conexión entre las partes
Ciclo de vida del software
“Una aproximación lógica a la adquisición, el suministro,
el desarrollo, la explotación y el mantenimiento del software”.
IEEE 1074
“Un marco de referencia que contiene los procesos, las actividades
y las tareas involucradas en el desarrollo, la explotación y el
mantenimiento de un producto de software, abarcando la vida del
sistema desde la definición de los requisitos hasta la finalización de
su uso”.
ISO 12207-1
De acuerdo a la definición anterior el ciclo de vida de un sistema es un enfoque por fases del análisis y diseño que sostiene que los sistemas sean desarrollados de mejor manera mediante el uso de un ciclo en especifico; determina el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Jaime APV.
Lista de modelos
1.-Modelo en cascada
2.-Modelo incremental
3.-Modelo en espiral
4.-Prototipado
5.- Concurrente
6.- Modelo de Prototipado de Requerimientos
7.- Modelo De Desarrollo Evolutivo
8.- La reutilización en el Ciclo de Vida
9.- Síntesis automática de Software
10. Comparación de Ciclos de Vida
11. Modelos para desarrollo de sistemas Orientados a
Objetos.
Modelo en cascada
-Flujo secuencial entre las fases.
-Cada etapa tiene un input y un output.
-Se supone que para comenzar con una
etapa deben haber finalizado las
anteriores.
Contribuciones:
-El proceso debe ser disciplinado, planeado
y gerenciado
-La implementación debe posponerse hasta
que los objetivos se hayan comprendido
Ingeniería de requerimientos
-Identificar y documentar los requerimientos
exactos del sistema según las necesidades de
los usuarios finales.
-Cualidades del sistema.
-Funcionales, no−funcionales, del proceso y del
mantenimiento
Diseño- Especificación
-Dividir el sistema en partes y establecer las
relaciones entre ellas.
-Arquitectura y diseño detallado.
-Establecer qué hará exactamente cada parte.
-En esta fase se crea un modelo funcional−
estructural de los requerimientos.
-El diseño debe permitir implementaciones que
verifiquen los requerimientos.
Críticas:
-No refleja realmente el proceso de desarrollo del software
-Se tarda mucho tiempo en pasar por todo el ciclo
-Perpetua el fracaso de la industria del software en su
comunicación con el usuario final
-El mantenimiento se realiza en el código fuente
-Las revisiones de proyectos de gran complejidad son muy
difíciles
-Impone una estructura de gestión de proyectos
Modelo Espiral
El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:
-Determinar qué quieres lograr.
-Determinar las rutas alternativas que puedes tomar para lograr estas metas.
-Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.
-Seguir la alternativa seleccionada en el paso 2.
-Establecer qué tienes terminado.
La dimensión radial en la figura refleja costos acumulativos incurridos en el proyecto.
Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situación y determinamos que los mayores riesgos son la interfaz del usuario. Después de un cuidadoso análisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificación de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de acción es construir un prototipo.
Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentación útil. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer sólo después de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximación es construir un incremento del sistema que satisfaga sólo los requerimientos mejor entendidos. Hagámoslo ya. Después del despliegue, el cliente nos provee de retroalimentación que dirá si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarán en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza.
El modelo espiral captura algunos principios básicos:
Decidir qué problema se quiere resolver antes de viajar a resolverlo.
Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatible.
Modelo Concurrente
Como el modelo espiral, el modelo concurrente provee una meta-descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del proceso de desarrollo de software. Discutamos un poco tales casos:
Los requerimientos son usualmente "líneas de base", cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados también). Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo.
Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en esos componentes estables. Similarmente, durante el diseño detallado, puede ser posible proceder con la codificación y quizás regular testeando en forma unitaria o realizando testeo de integración previo a llevar a cabo el diseño detallado de todos los componentes.
jueves, 3 de junio de 2010
Introducción y conceptos básicos
Ingeniería inversa (Reverse engineering):
La ingeniería inversa es el proceso de descubrir los principios tecnológicos de un dispositivo, objeto o sistema, a través de razonamiento abductivo de su estructura, función y operación.
La ingeniería inversa se trata de tomar algo (un dispositivo mecánico o electrónico, un software de computadora, etc.) para analizar su funcionamiento en detalle, generalmente para intentar crear un dispositivo o programa que haga la misma o similar tarea sin copiar la original.
Identifica los componentes de un sistema de información y la interrelación que existe entre ellos.
Reestructuración:
Es la transformación de una forma de representación de un sistema en otra distinta pero del mismo nivel de abstracción sin modificar el comportamiento externo del sistema.
Reingeniería:
Reingeniería en un concepto simple es el rediseño de un proceso en un negocio o un cambio drástico de un proceso. A pesar que este concepto resume la idea principal de la reingeniería esta frase no envuelve todo lo que implica la reingeniería.
Reingeniería es comenzar de cero, es un cambio de todo o nada, además ordena la empresa alrededor de los procesos. La reingeniería requiere que los procesos fundamentales de los negocios sean observados desde una perspectiva transfuncional y en base a la satisfacción del cliente.
Ingeniería hacia delante (Forward Engineering):
Reingeniería de empresas: (Bussiness Procese Reengineering):
¿Para qué se utiliza?
Acciones:
La ingeniería inversa es el proceso de descubrir los principios tecnológicos de un dispositivo, objeto o sistema, a través de razonamiento abductivo de su estructura, función y operación.
La ingeniería inversa se trata de tomar algo (un dispositivo mecánico o electrónico, un software de computadora, etc.) para analizar su funcionamiento en detalle, generalmente para intentar crear un dispositivo o programa que haga la misma o similar tarea sin copiar la original.
Identifica los componentes de un sistema de información y la interrelación que existe entre ellos.
Reestructuración:
Es la transformación de una forma de representación de un sistema en otra distinta pero del mismo nivel de abstracción sin modificar el comportamiento externo del sistema.
Reingeniería:
Reingeniería en un concepto simple es el rediseño de un proceso en un negocio o un cambio drástico de un proceso. A pesar que este concepto resume la idea principal de la reingeniería esta frase no envuelve todo lo que implica la reingeniería.
Reingeniería es comenzar de cero, es un cambio de todo o nada, además ordena la empresa alrededor de los procesos. La reingeniería requiere que los procesos fundamentales de los negocios sean observados desde una perspectiva transfuncional y en base a la satisfacción del cliente.
Ingeniería hacia delante (Forward Engineering):
Reingeniería de empresas: (Bussiness Procese Reengineering):
¿Para qué se utiliza?
Acciones:
Suscribirse a:
Entradas (Atom)
