jueves, 5 de agosto de 2010
PREGUNTAS UNIDAD 8 A 12
En que consiste la prueba de funcionalidad?
Verifica que el ítem que se esta probando, cuando se dan las entradas apropiadas y produce los resultados esperados, acciones de usuarios.
En que consiste la prueba de compatibilidad?
Esta consiste en probar que el software pueda interactuar con los navegadores web y que no sufra alteraciones o errores durante su ejecución.
En que consiste las pruebas de comunicaciones?
Consiste en la cantidad de datos transmitidos durante determinado tiempo medido en bytes enviados y recibidos con cada petición al servidor
En que consisten las pruebas de la caja blanca?
Realiza pruebas del código línea por línea para verificar si este cumple con las condiciones especificas.
En que consisten las pruebas de la caja negra?
Las pruebas de caja negra consisten en verificar el código del software solo por fuera sin entrar en detalles de su funcionamiento interno, únicamente la parte de afuera que interactua el usuario.
Que es una prueba de robustez?
Este se verifican varios aspectos del mismo para verificar que este cumple con las condiciones para reaccionar frente a situaciones a priori imprevistas como el ingreso de múltiples accesos de usuarios ala vez.
Que es auditoria informática?
Consiste en determinar el grado de correspondencia informativo con evidencias que dieron origen, asi como determinar si dichos informes se han establecido con principios preestablecidos para dicho caso. Es en realidad una opinión profesional sobe si el objeto sometido a el análisis presenta alguna inconsistencia de la realidad que pretende eflejar y/o cumple con las condiciones que le han sido prescritas para operar adecuadamente. En caso de encontrar alguna inconsistencia el auditor tiene el deber de presentar recomendaciones a fin de poder mejorar el área que presenta problemas a fin de pode garantizar que se culan con los estatus y requerimientos minimos que marcan las políticas de la empresa, reglamentos, leyes o cualquier otro decreto que exija a la empresa ajustarse a dichas normas preestablecidas.
Escribe 3 aspectos del porqué es importante la auditoría informática?
En que consiste la auditoría informática de producción o explotación?
En que consiste la auditoria informática de desarrollo de proyectos?
En que consiste la auditoria informática de sistemas?
En que consiste la auditoria informática de comunicaciones y redes?
En que consiste la auditoria de la seguridad informática?
En que consiste la auditoria informática para aplicaciones en internet?
Cuál es la metodología de trabajo de la auditoria informática?
Definición de mantenimiento del equipo?
Este mantenimiento agrupa las acciones a realizar en el software (programas, bases de datos, documentación, etc.) ante un funcionamiento incorrecto, deficiente o incompleto que por su naturaleza no pueden planificarse en el tiempo.
Definición de mantenimiento preventivo y correctivo?
Menciona 3 dificultades del mantenimiento?.
En que consisten los costes del mantenimiento?
jueves, 22 de julio de 2010
AUDITORÍA INFORMÁTICA
Consiste en determinar el grado de correspondencia informativo con evidencias que dieron origen, asi como determinar si dichos informes se han establecido con principios preestablecidos para dicho caso. Es en realidad una opinión profesional sobe si el objeto sometido a el análisis presenta alguna inconsistencia de la realidad que pretende eflejar y/o cumple con las condiciones que le han sido prescritas para operar adecuadamente. En caso de encontrar alguna inconsistencia el auditor tiene el deber de presentar recomendaciones a fin de poder mejorar el área que presenta problemas a fin de pode garantizar que se culan con los estatus y requerimientos minimos que marcan las políticas de la empresa, reglamentos, leyes o cualquier otro decreto que exija a la empresa ajustarse a dichas normas preestablecidas.
Finalmente el auditor dara un dictamen final donde indicara los resultados que encontró de la empresa auditada a fin de poder entender claramente el empresario en donde se encuentran sus fallas y poder corregirlas para poder cumplir con los estándares de calidad que se requieren para poder certificarse y garantizar que sus procesos y servicios sean los adecuados.
TIPOS DE AUDITORÍA
Auditoría Informática de producción o Explotación
En algunos casos también conocida como de Explotación o 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.
Auditoría informática de desarrollo de proyectos.
La función de desarrollo es la evolución del llamado análisis y programación de sistemas lo cual abarca varias áreas, como control interno, satisfacción de usuario, seguridad de programas.
Finalmente el auditor dara un dictamen final donde indicara los resultados que encontró de la empresa auditada a fin de poder entender claramente el empresario en donde se encuentran sus fallas y poder corregirlas para poder cumplir con los estándares de calidad que se requieren para poder certificarse y garantizar que sus procesos y servicios sean los adecuados.
TIPOS DE AUDITORÍA
Auditoría Informática de producción o Explotación
En algunos casos también conocida como de Explotación o 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.
Auditoría informática de desarrollo de proyectos.
La función de desarrollo es la evolución del llamado análisis y programación de sistemas lo cual abarca varias áreas, como control interno, satisfacción de usuario, seguridad de programas.
jueves, 15 de julio de 2010
jueves, 24 de junio de 2010
PERT Y CPM
Elección entre PERT y CPM
La elección entre el enfoque de las tres estimaciones de PERTy el método de trueques entre el tiempo y el costo del CPM depende fundamentalmente del tipo de proyecto y de los objetivos gerenciales. El PERT es en particular apropiado cuando se maneja mucha incertidumbre al predecir los tiempos de las actividades y cuando es importante controlar de una manera efectiva la programación del proyecto; por ejemplo, la mayor parte de los proyectos de investigación y desarrollo caen dentro de esta categoría. Por otro lado, el CPM resulta muy apropiado cuando se pueden predecir bien los tiempos de las actividades(quizá con base en la experiencia) y cuando estos tiempos se pueden ajustar con facilidad (por ejemplo, si se cambian tamaños de brigadas), al igual que cuando es importante planear una combinación apropiada entre el tiempo y el costo del proyecto. Este último tipo lo representan muchos proyectos de construcción y mantenimiento.
En la actualidad, las diferencias entre las versiones actuales de PERT y CPM no son tan marcadas como se han descrito. Muchas versiones de PERT permiten emplear una sola estimación (la más probable) para cada actividad y omiten así la investigación probabilística. Una versión llamada PERT/Costo considera también combinaciones de tiempo y costo en forma parecida al CPM.
Diferencias Entre PERT y CPM
La diferencia entre PERT y CPM es la manera en que se realizan los estimados de tiempo. E1 PERT supone que el tiempo para realizar cada una de las actividades es una variable aleatoria descrita por una distribución de probabilidad. E1 CPM por otra parte, infiere que los tiempos de las actividades se conocen en forma determinísticas y se puede variar cambiando el nivel de recursos utilizados.
La distribución de tiempo que supone el PERT para una actividad es una distribución beta. La distribución para cualquier actividad se define por tres estimados:
1. el estimado de tiempo más probable, m;
2. el estimado de tiempo más optimista, a; y
3. el estimado de tiempo más pesimista, b.
La forma de la distribución se muestra en la siguiente Figura. E1 tiempo más probable es el tiempo requerido para completar la actividad bajo condiciones normales. Los tiempos optimistas y pesimistas proporcionan una medida de la incertidumbre inherente en la actividad, incluyendo desperfectos en el equipo, disponibilidad de mano de obra, retardo en los materiales y otros factores.
Con la distribución definida, la media (esperada) y la desviación estándar, respectivamente, del tiempo de la actividad para la actividad Z puede calcularse por medio de las fórmulas de aproximación.
El tiempo esperado de finalización de un proyecto es la suma de todos los tiempos esperados de las actividades sobre la ruta crítica. De modo similar, suponiendo que las distribuciones de los tiempos de las actividades son independientes (realísticamente, una suposición fuertemente cuestionable), la varianza del proyecto es la suma de las varianzas de las actividades en la ruta crítica. Estas propiedades se demostrarán posteriormente.
En CPM solamente se requiere un estimado de tiempo. Todos los cálculos se hacen con la suposición de que los tiempos de actividad se conocen. A medida que el proyecto avanza, estos estimados se utilizan para controlar y monitorear el progreso. Si ocurre algún retardo en el proyecto, se hacen esfuerzos por lograr que el proyecto quede de nuevo en programa cambiando la asignación de recursos.
CONCLUSIÓN: A manera de conclusión podemos decir que el PERT es mas utilizado cuando no se tiene suficiente experiencia en el ramo y se tiene un tiempo no estipulado por lo cual es mejor CPM cuando se tiene un tiempo determinado en el cual nos podamos bazar en base a la experiencia que se tiene.
PREGUNTA GENRADORA: Cual es el mejor metodo? No existe quizas uno mejor que otro mas bien se basa en las necesidades de cada uno y de lo que se requiera.
jueves, 17 de junio de 2010
MODELADO Y/O PROTOTIPO DE SISTEMAS SEGUN James Senn
MÉTODO DEL PROTOTIPO DE SISTEMAS
La construcción de prototipos representa una estrategiade desarrollo, cuando no es posible determinar todos los requerimientos del usuario. Es por ello que 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.
Así mismo este método 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. El método del prototipo de sistemas consta de 5 etapas:
1). Identificación de requerimientos conocidos: La determinación de los requerimientos de una aplicación es indispensable previo para crear un prototipo, trabajar juntos entre el usuario y el analista programador, es identificar los requerimientos conocidos que tienen que satisfacer.
2). Desarrollo de un modelo de trabajo: Es fácil comenzar el procesos de construcción del prototipo con el desarrollo de un plan general que permita a los usuarios conocer lo que se espera de ellas y del proceso de desarrollo, se debe hacer un cronograma para el inicio y el fin de la primera interacción. En el desarrollo del prototipo incluye los siguientes 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: Es responsabilidad del usuario trabajar con el prototipo y evaluar sus características, funciones y operación, identificando cualquier problema familiarizandose con el sistema, 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 completo las veces que sea necesarias: Repetir el proceso varias veces, finalizado el sistema. Si los usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias.
La construcción de prototipos representa una estrategiade desarrollo, cuando no es posible determinar todos los requerimientos del usuario. Es por ello que 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.
Así mismo este método 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. El método del prototipo de sistemas consta de 5 etapas:
1). Identificación de requerimientos conocidos: La determinación de los requerimientos de una aplicación es indispensable previo para crear un prototipo, trabajar juntos entre el usuario y el analista programador, es identificar los requerimientos conocidos que tienen que satisfacer.
2). Desarrollo de un modelo de trabajo: Es fácil comenzar el procesos de construcción del prototipo con el desarrollo de un plan general que permita a los usuarios conocer lo que se espera de ellas y del proceso de desarrollo, se debe hacer un cronograma para el inicio y el fin de la primera interacción. En el desarrollo del prototipo incluye los siguientes 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: Es responsabilidad del usuario trabajar con el prototipo y evaluar sus características, funciones y operación, identificando cualquier problema familiarizandose con el sistema, 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 completo las veces que sea necesarias: Repetir el proceso varias veces, finalizado el sistema. Si los usuarios y analistas están de acuerdo en que el sistema ha evolucionado lo suficiente como para incluir todas las características necesarias.
jueves, 10 de junio de 2010
CICLO DE VIDA DEL SOFTWARE
Conceptos (fuentes)
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Un modelo de ciclo de vida del software se describe a continuacion:
Describe las fases principales de desarrollo de software.
Define las fases primarias esperadas de ser ejecutadas durante esas fases.
Ayuda a administrar el progreso del desarrollo, y provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.
Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.
Mi Concepto
Se puede decir que el ciclo de vida del software nos sire para poder modelar cualquier softwarea a fin de poder, llevar un analisis detallado y estructurado de los fases dentro del proceso de desarrollo y pasos a seguir dentro del mismo.
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.
Lista de modelos
Existen diversos modelos como:
Modelo Cascada
Modelo De Desarrollo Incremental
Modelo De Desarrollo Evolutivo
Modelo de Prototipado de Requerimientos
Modelo Espiral
Modelo Concurrente
2 Modelos a elegir
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.
Ejemplo:
Un cliente nos pide un software con determinada interfaz de usuario. En el modelo 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 con la interfaz.
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. Se deben analizar las rutas alternativas, y decidimos que la mejor aproximación es construir un incremento del sistema que satisfaga sólo los requerimientos mejor entendidos. Después del despliegue, el cliente nos provee de retroalimentación que dirá si estamos correctos con esos requerimientos, sino regresamos y los corregimos y posteriormente empesamos el tercer viaje alrededor de la espiral.
Modelo Desarrollo Evolutivo
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.
Ejemplo:
Como en el ejemplo anterior el cliente en esta ocasión, no nos pide la interfaz sino un software que pueda realizar el envio de información por la red a otras sucursales de la empresa.
En la primera etapa el equipo de desarrollo realiza el programa piloto o de prueba para ser probado, una vez que lo terminan, aunque quizas no cuenta con todas las caracteristicas amigables de interfaz de usuario, es funcional en cuanto a lo que pide el cliente, que es el envio de información por la red a otras sucursales de la empresa.
Entregado el software al cliente, se le da el uso necesario y el cliente retroalimenta la funcionalidad de software y a partir de aqui se continua con su desarrollo del mismo para poder hacerle mejoras.
Bibliograf{ia
http://html.rincondelvago.com/el-ciclo-de-vida-del-software.html
http://www.monografias.com/trabajos29/ciclo-sistema/ciclo-sistema.shtml
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Un modelo de ciclo de vida del software se describe a continuacion:
Describe las fases principales de desarrollo de software.
Define las fases primarias esperadas de ser ejecutadas durante esas fases.
Ayuda a administrar el progreso del desarrollo, y provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.
Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.
Mi Concepto
Se puede decir que el ciclo de vida del software nos sire para poder modelar cualquier softwarea a fin de poder, llevar un analisis detallado y estructurado de los fases dentro del proceso de desarrollo y pasos a seguir dentro del mismo.
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.
Lista de modelos
Existen diversos modelos como:
Modelo Cascada
Modelo De Desarrollo Incremental
Modelo De Desarrollo Evolutivo
Modelo de Prototipado de Requerimientos
Modelo Espiral
Modelo Concurrente
2 Modelos a elegir
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.
Ejemplo:
Un cliente nos pide un software con determinada interfaz de usuario. En el modelo 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 con la interfaz.
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. Se deben analizar las rutas alternativas, y decidimos que la mejor aproximación es construir un incremento del sistema que satisfaga sólo los requerimientos mejor entendidos. Después del despliegue, el cliente nos provee de retroalimentación que dirá si estamos correctos con esos requerimientos, sino regresamos y los corregimos y posteriormente empesamos el tercer viaje alrededor de la espiral.
Modelo Desarrollo Evolutivo
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.
Ejemplo:
Como en el ejemplo anterior el cliente en esta ocasión, no nos pide la interfaz sino un software que pueda realizar el envio de información por la red a otras sucursales de la empresa.
En la primera etapa el equipo de desarrollo realiza el programa piloto o de prueba para ser probado, una vez que lo terminan, aunque quizas no cuenta con todas las caracteristicas amigables de interfaz de usuario, es funcional en cuanto a lo que pide el cliente, que es el envio de información por la red a otras sucursales de la empresa.
Entregado el software al cliente, se le da el uso necesario y el cliente retroalimenta la funcionalidad de software y a partir de aqui se continua con su desarrollo del mismo para poder hacerle mejoras.
Bibliograf{ia
http://html.rincondelvago.com/el-ciclo-de-vida-del-software.html
http://www.monografias.com/trabajos29/ciclo-sistema/ciclo-sistema.shtml
jueves, 3 de junio de 2010
Introducciòn y conceptos bàsicos
* Ingenierìa inversa.- Identificar los componentes que interactuan en el sistema de informaciòn, que proceso lleva el modulo y cual es la salida que va a darnos.
* 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.- .
* Ingenierìa hacia adelante (fordward engineering)
* Reingenierìa de empresas (bussiness procese reengineering)
* ¿Para que se utiliza?
* Acciones
* 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.- .
* Ingenierìa hacia adelante (fordward engineering)
* Reingenierìa de empresas (bussiness procese reengineering)
* ¿Para que se utiliza?
* Acciones
Suscribirse a:
Entradas (Atom)
