Resumen mio.docx

INGENIERÍA DE SOFTWARE Proceso Conjunto estructurado de actividades para desarrollar un sistema de software. Estas actividades varían dependiendo de la organización y el tipo de sistema que debe desarrollarse. ¿Cómo se adapta un proceso de desarrollo a un proyecto real? Todo proyecto que se genera en el ámbito profesional responde a una situación particular, dada en un contexto y una realidad. Si el proyecto tiene como objetivo obtener un producto de software, entonces tiene asociado el proceso de desarrollo de software. Cada proyecto es único, aunque sea semejante a otro, siempre posee alguna característica o regla que lo diferencia de otro, no obstante, el proceso de desarrollo ya está definido y puede aplicarse a cualquier proyecto. Para ello tiene que permitir elegir cualquier metodología relacionada con los distintos ciclos de vida, por lo cual se basa en las actividades básicas definidas en el proceso. Actividades del proceso de desarrollo de software Las cuatro actividades o etapas básicas del proceso se organizan de forma distinta en diferentes procesos, estas actividades son:    

Especificación Desarrollo Validación y Evolución.

En el enfoque en cascada se organizan de forma secuencial, mientras que en el desarrollo evolutivo se entrelazan, esto depende del tipo de software, de las personas y de la estructura organizacional implicada, expresa Sommerville, (Ingeniería de Software, Pág. 84) Etapa de especificación del software Esta etapa, por ser la primera, es muy importante, es el proceso de comprensión del problema y definición de los servicios que requiere el sistema, como así también la identificación de las restricciones de funcionamiento y de desarrollo. En esta etapa no sólo se realiza la captura de los requerimientos, sino que también se realiza el análisis de los mismos. Los contenidos de esta etapa se profundizarán en el módulo 3. Existen 4 fases principales en el proceso de Ingeniería de requerimientos: 1. Estudio de viabilidad, se estima si las necesidades del cliente se pueden satisfacer. 2. Obtención y análisis de requerimientos, se utilizan distintas técnicas de recolección de datos e información, que luego es analizada. 3. Especificación de requerimientos, se describe la lista de requerimientos en un documento. 4. Validación del requerimiento, se comprueba si es correcta la lista de requerimientos con el cliente.

Titles you can't find anywhere else

Try Scribd FREE for 30 days to access over 125 million titles without ads or interruptions! Start Free Trial Cancel Anytime.













Etapa de diseño e implementación del software La etapa de implementación del software incluye a los procesos de diseño y construcción del software, ya que es el proceso de convertir una especificación del sistema en un sistema ejecutable. Esta etapa varía según el enfoque de ciclo de vida adoptado, por ejemplo, en un enfoque en cascada se implementará un ejecutable que contiene el total de las especificaciones diseñadas y programadas, mientras que en un enfoque evolutivo implicará un refinamiento de las especificaciones del software. Desarrollo La actividad de desarrollo sigue naturalmente a la etapa de diseño. El desarrollo del software es el proceso de codificación en un lenguaje de computación, de los requerimientos definidos, analizados y diseñados. Las herramientas CASE se pueden utilizar para generar un programa esqueleto a partir del diseño, esto incluye código para definir e implementar las interfaces, necesitando el programador solo agregar detalles de código. Etapa de Validación del software La validación del software es la etapa en la que se realizan comprobaciones. En general se conoce como V & V, verificación y validación, se utiliza para mostrar que el sistema se ajusta a su especificación y que cumple las l as expectativas del cliente.

Ingeniería de Requerimientos Los requerimientos para un sistema son las descripciones de los servicios o funciones proporcionados por el sistema y sus restricciones operativas. Los requerimientos reflejan las necesidades o deseos de los clientes, que ayuden a resolver problemas operativos o que brinden información para la toma de decisiones. El proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se denomina “Ingeniería de requerimientos”.

Los requerimientos se pueden clasificar de distintas formas, teniendo en cuenta sus características. En cuanto a las categorías, se pueden plantear dos:  

Orientado al mercado. Orientado al cliente y/o usuario.

Los requerimientos orientados al mercado son mas generales. El cliente es en general no siempre bien identificado, es mas un sector de mercado. Los requerimientos específicos para un cliente atienden las necesidades de éste.

















Los requerimientos del usuario son declaraciones, normalmente en lenguaje natural y en diagramas, de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar. Los requerimientos del sistema establecen con detalle las funciones, servicios y restricciones operativas del sistema. El documento de requerimientos del sistema debe ser preciso, definiendo claramente y exactamente, lo que se va a implementar.

Concepto de Ingeniería de Requerimientos. “Es el proceso sistemático de desarrollar requerimientos a través de un proceso cooperativo e

iterativo de analizar el problema, documentar las observaciones resultantes en una variedad de formatos de representación y chequear la precisi ón de la comprensión obtenida”. Desde la perspectiva del software, los errores de los sistemas llevan a costos elevados en la corrección de los mismos, este es uno de los factores, si no es el mas importante, que da lugar a la Ingeniería de requerimientos, que es parte de la Ingeniería de Software.  

Los usuarios no saben lo que quieren. Los de sistemas quieren que les hagamos su trabajo.

¿Qué constituye un requerimiento? r equerimiento? El conocimiento convencional mas ampliamente compartido dice que “requerimiento constituye una sentencia completa acerca de qué hará el sistema, sin referirse a cómo lo hará”.

La importancia de los requerimientos se basa en que cuanto más tarde se detecta un error, más cuesta resolverlo. Son la fase inicial del proceso de desarrollo de software y de ella depende, en gran parte, el éxito del proyecto. Identificación de Requerimientos. Es descubrir los requerimientos para un sistema por parte de los clientes, usuarios, otros afectados. Es determinar cual es la necesidad, es un proceso de captura donde todo debe registrarse. Análisis de Requerimientos Es una actividad en la que tratamos de estructurar y comprender mejor el resultado de la identificación de requerimientos. Adquirir un nivel de abstracción que permita ver y entender de forma global el requerimiento, para luego entrar en los detalles. Tipos de requerimientos Funcionales: son las declaraciones de los servicios que debe proporcionar el sistema. Como debe reaccionar ante una entrada, procesos y controles. No funcionales: Están funcionales: Están relacionados con la performance, el tiempo de respuesta, interfases de usuario. Del dominio: Reflejan las características y restricciones de su dominio.













Es el proceso de adquirir todo el conocimiento relevante necesario para producir el modelo de los requerimientos del dominio del problema. El analista debe conocer la naturaleza del problema, entender del tema para poder interactuar con el cliente. Técnicas de Elicitación     

Entrevistas Torbellinos de ideas Análisis de documentación existente Observación Análisis de los objetivos

Especificación de requerimientos La especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. Completa significa que todos los servicios solicitados so licitados por el usuario deben estar definidos. Consistencia significa que los requerimientos no deben tener definiciones contradictorias. Una vez terminado el relevamiento y detectadas las necesidades del cliente, los distintos tipos de requerimientos, restricciones, reglas de negocio y dominio del problema, es necesario realizar la especificación y dejarlos en forma explícita en un documento. Este documento de requerimientos del software, denominado SRS o ERS, es la declaración oficial de qué deben implementar los desarrolladores del sistema. Se han definido estándares para el documento de requerimientos, el más conocido y utilizado es el de IEEE/ANSY 830-1998. Validación de requerimientos Trata de mostrar que los requerimientos realmente definen el sistema que el cliente desea. Es importante validarlos a tiempo, antes de que estén codificados. Las verificaciones pueden ser: 



 

Verificaciones de validez: durante el análisis pueden aparecer funciones adicionales o diferentes. Verificación de consistencia: los requerimientos no deben contradecirse o tener definiciones ambiguas. Verificación de completitud: deben definir todas las funcionalidades del sistema. Verificaciones de realismo: deben verificarse para asegurarse que se pueden implementar.

Las validaciones pueden realizarse mediante: La revisión sistemática de los requerimientos.













Se define así al flujo de trabajo a seguir para la consecución de una tarea o trabajo predeterminado. El flujo de trabajo determina como se estructuran las tareas, como se realizan, cual es su orden correlativo, como se sincronizan, como fluye la información que soporta. Su definición y control puede ser manual, informatizado o mixto. Su importancia consiste en buscar la máxima automatización de los procesos de trabajo y el control total de las diferentes etapas, donde los documentos, la información o las tareas pasan de un participante a otro. La principal limitación asociada a los Sistemas de Información tradicionales es que, no contemplan los procedimientos, organización y métodos de trabajo del sistema real. Objetivos:  

Reflejar, automatizar y mecanizar los métodos en el sistema de información. Establecer los mecanismos de control y seguimiento.

Dentro del Workflow se pueden distinguir tres tipos de actividades: 





Actividades colaborativas: colaborativas: Un conjunto de usuarios trabajan sobre un mismo repositorio de datos para obtener un resultado común. Actividades cooperativas: Un cooperativas: Un conjunto de usuarios trabajan sobre su propio conjunto particular, estableciendo los mecanismos de cooperación entre ellos. Actividades de coordinación: se coordinación: se establece cómo será el trabajo cooperativo entre los individuos.

Los flujos de trabajo como Workflow representan mejor la realidad de los procesos, dan una vista horizontal del mismo, con lo que el actor no es sólo responsable de su actividad, sino que es responsable del proceso, en cuanto que hay otro actor que depende de que su actividad esté resuelta satisfactoriamente. Elementos necesarios para implementar S.I. Workflow     

Procesos, conjunto de actividades organizadas Rutas, secuencia de actividades Reglas, de negocio como de procedimiento Roles, actores de una actividad Políticas, de seguridad o del tipo empresa

El proceso unificado racional El RUP es un modelo en fases que identifica cuatro fases diferentes en el proceso de software relacionadas con asuntos de negocio: 1- Inicio. Su objetivo es establecer un caso de negocio para el sistema, identificando todas las entidades externas que interactúan con el sistema. 2- Elaboración. Desarrollar un plan del proyecto e identificar los riesgos. Finalizadas esta fase se debe contar con un plan de proyecto, la especificación de requerimientos y los casos de uso.













Como no se cuenta con el 100% de los requerimientos, estas fases se presentan de forma iterativa e incremental. Las buenas prácticas que presenta RUP El RUP recomienda seis buenas prácticas de la Ingeniería de software en el desarrollo de sistemas: 1- Desarrolle el software de forma iterativa, planificando incrementos del sistema basado en las prioridades del usuario. 2- Gestione los requerimientos documentándolos debidamente. 3- Utilice arquitecturas basadas en componentes, identificando cuales pueden ser reusables. 4- Modele de forma visual el Software utilizando UML. 5- Verifique la calidad. 6- Controle los cambios. El proceso unificado presenta 3 aspectos a la hora de implementar su modelo:   

Dirigido por casos de uso Centrado en la arquitectura Iterativo e Incremental

Concepto de calidad Calidad se puede definir como “Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor”

De esta forma podríamos decir que la calidad de los productos puede medirse como una comparación de sus características y atributos. Calidad en los productos de Software Para el software también existen medidas que pueden hacerlo comparable, tales como puntos de función, líneas de código y otras. Para ello se debe tener en cuenta lo siguiente:  

Los productos de software son realizados por personas para personas. Los desarrolladores deben tener en cuenta que son otras personas las que utilizarán sus productos, los que pueden estar sujetos a fallos constantes.

La gestión de calidad se estructura en tres actividades principales:    

Garantía de la calidad, haciendo uso de tecnología eficiente. Planificación de la calidad, aplicando técnicas formales. Control de la calidad, controlando la documentación. Administración de la calidad, con un correcto mantenimiento y servicio post-venta.

















Confeccionar los informes necesarios del proceso.

Al finalizar el proceso de desarrollo se espera:      

La satisfacción del cliente. La comercialización y uso masivo. Que responda a los requerimientos. Buen rendimiento. Fácil de usar. Que se acompañe con la documentación necesaria.

Prueba en el proceso unificado La prueba es el proceso de ejercitar un programa con la intención específica de encontrar errores previos a la entrega al usuario final. Las dos actividades fundamentales de pruebas son: 



La prueba de componentes, es probar las partes del sistema, tratando de descubrir defectos en los componentes. La prueba del sistema, probar el sistema integralmente, como un todo, que satisface los requerimientos funcionales, los no funcionales y que no se comporta de forma inesperada.

El proceso de pruebas tiene dos objetivos: 1- Demostrar al desarrollador y al cliente que el software satisface sus requerimientos. 2- Descubrir defectos, comportamientos incorrectos o que no cumple su especificación. Tipos de pruebas 

 

Deberían probarse todas las funciones del sistema que se accedan a través de menúes. Prueba funcional. Deben probarse todas las combinaciones de funciones, como los ingresos de datos. El ingreso de datos debe hacerse con datos correctos e incorrectos.

Pruebas del sistema Se plantean dos fases de pruebas distintas: 

Pruebas de integración, en la que el equipo de pruebas tiene acceso al código fuente del













Los resultados de un proyecto de software se miden según las siguientes variables:    

Alcance – (funcionalidad) Tiempo – (calendario) Esfuerzo – (Presupuesto, costo) Calidad – (criterios de aceptación)

La Garantía de la calidad o Aseguramiento A seguramiento de la calidad es el proceso que define como lograr la calidad del software y cómo la organización de desarrollo conoce el nivel de calidad requerido en el software. Se pueden definir dos estándares como parte del proceso de garantía de calidad: 1- Estándares de producto, se aplican sobre el producto software que se comienza a desarrollar, incluyen estándares de documentación y estándares de codificación. 2- Estándares de proceso, definen los procesos que deben seguirse durante el desarrollo del software y de la documentación que debe acompañarlo. ISO 9001:2000   

Es un instrumento de adhesión voluntaria. Es un texto aplicable a cualquier tipo de organización Es un texto que exige compromisos

Modelo de calidad CMM CMM, es un esquema que representa un camino de mejoramientos, permite determinar la madurez y evaluar las capacidades de las organizaciones que desarrollan software, recomendado para las organizaciones que quieren incrementar la capacidad de su proceso de desarrollo. El Modelo de Capacidad y Madurez o CMM, es un modelo de evaluación de los procesos y del nivel de maduración de una organización. CMM, es un esquema que representa un camino de mejoramientos, permite determinar la madurez y evaluar las capacidades de las organizaciones que desarrollan software. CMM como modelo es Descriptivo, Normativo y No prescriptivo. Estas Áreas de Proceso se agrupan en cinco "niveles de madurez", madurez" , de modo que una organización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus



















Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinación entre grupos, formación del personal, técnicas de ingeniería más detalladas y un nivel más avanzado de métricas en los procesos. Se implementan técnicas de revisión por pares (peer reviews). Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de métricas significativas de calidad y productividad, que se usan de modo sistemático para la toma de decisiones y la gestión de riesgos. El software resultante es de alta calidad. Optimizado. La organización completa está volcada en la mejora continua de los procesos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.

Certificación: La certificación es la forma de Validación que una entidad externa realiza a la organización para aprobar o desaprobar estándares de calidad utilizados en los procesos. Las características que presentan las organizaciones organizaciones maduras son: Comunicación y coordinación entre los diferentes grupos de trabajo de la organización y externos. Todos los trabajos son realizados de acuerdo a un plan. Posee la habilidad para administrar los procesos de desarrollo y mantenimiento del software. Las prácticas son consistentes con los procesos y los procesos son debidamente comunicados y compartidos por todos. Los administradores monitorean monitorean los procesos, la calidad del producto y la satisfacción del cliente. Los procesos son actualizados cuando son necesarios Los roles y responsabilidades responsabilidades están bien definidos La planificación y los presupuestos son realistas y basados en la performance histórica de otros proyectos. Los resultados esperados pueden alcanzarse en costos, tiempo y calidad del producto. La gerencia formalmente se compromete. Se sigue un proceso disciplinado, todos los participantes entienden el valor de hacerlo y existe la infraestructura necesaria necesaria para darle soporte. 

 





  

 

Las organizaciones inmaduras presentan características características bien definidas, como son: Proceso improvisado durante el proyecto de desarrollo de software Procesos aprobados son ignorados a la hora de desarrollar el software Reactivas, no pro-activas, esperan a que pase algo para implementar el proceso Presupuestos y planificaciones no realistas Calidad del producto sacrificada en pos de la entrega, el tiempo siempre es un determinante que hace que se sacrifique la calidad del producto y que no se cumpla     

















Hacer predicciones generales acerca del sistema, midiendo las características de los componentes del sistema y reuniéndolas, pudiendo derivar en una estimación general de alguno de los atributos atr ibutos del sistema, como puede el número de fallos detectados. Identificar componentes anómalos, implica encontrar componentes que tengan un comportamiento fuera de lo normal, normalmente se establece como prioridad la medición de los componentes de mayor complejidad y criticidad, que se supone pueden tener mayor cantidad de errores en un funcionamiento.

Si bien todos los estándares de calidad definen la necesidad de hacer mediciones, sólo indican qué se deben realizar, pero no establecen cómo, cuáles ni dónde aplicarlas, esta es una tarea que se determina en los lineamientos estratégicos de la organización, quien con la ayuda de los ingenieros y líderes de proyecto tienen en cuenta las metas de la organización y los objetivos de las áreas para establecerlas. Una métrica de software es cualquier tipo de medida relacionada con un sistema, proceso o documentación de software. Como se ha expresado anteriormente, es necesario medir para lograr una mejora en el proceso y en el producto. Las mediciones del mundo físico pueden englobarse en dos categorías: medidas directas y medidas indirectas. Medidas Directas. En Directas. En el proceso de ingeniería se encuentran los valores que identifican el costo, y el esfuerzo aplicado, las líneas de código producidas, velocidad de ejecución, el tamaño de memoria y los defectos observados en un determinado período de tiempo. Medidas Indirectas. Se Indirectas. Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento, entre otras. La gestión de la calidad del software permite señalar si éste tiene escaso número de defectos y si alcanza los estándares requeridos de mantenibilidad, fiabilidad y portabilidad. No existen métricas de software estandarizadas ni de uso universal. La calidad de productos software está dada por los procesos que lo desarrollan y no por el producto mismo. Las métricas del software también se pueden clasificar teniendo en cuenta lo que miden y cómo lo miden, citemos algunas de ellas:













Métricas orientadas a la función . Son medidas indirectas del software y del proceso, se centran

en la funcionalidad o utilidad del programa.

Los puntos de función, miden lo que el software hace y no como lo hace.















AUDITORÍA DE SISTEMAS Auditoría La auditoría puede definirse como un proceso sistemático s istemático de revisión y evaluación objetiva, realizada sobre las actividades de una organización con el objetivo de verificar su cumplimento a las normas y condiciones preestablecidas. Debe ser efectuada por un auditor calificado e independiente, el cual recolecta evidencias y emite una opinión profesional para determinar el grado de fiabilidad del objeto analizado. El contenido de una auditoría será una opinión comunicada en un informe y elevada a las personas interesadas. La condición de una auditoría es que sea de carácter profesional, es decir, realizada por una persona que posea los conocimientos y las habilidades técnicas necesarias para la actividad. Cuando hablamos de objetividad, nos referimos que el auditor interno debe tener una actitud imparcial y neutral, y debe evitar los conflictos de intereses. Clases de Auditoría     

Auditoría Financiera (contable) Auditoría de Seguridad (identificar vulnerabilidades) v ulnerabilidades) Auditoría de Calidad (cumplimiento del sistema de calidad) Auditoría Política Auditoría Informática (evalúa los sistemas de información para verificar la i ntegridad de los datos que administra). Se aplican procedimientos para auditar el uso y el













adecuadas, los procedimientos serán incorrectos y se fallará en el resultado final del trabajo de auditoría.

Proceso de Auditoría ETAPAS DEL PROCESO DE AUDITORÍA 





Planificación: Visita previa, revisión de documentación, creación plan de auditorías, redacción de cuestionarios, elaboración del programa de auditorías. Ejecución: aplicación de los procedimientos de auditoría, comunicación constante con la dirección. Conclusión: Reporte de auditoría con hallazgos y recomendaciones.

METODOLOGÍA DE CONTROL INTERNO

El control interno se encarga de monitorear diariamente las actividades de los sistemas de información, su función es verificar que se cumplan los procedimientos, las normas y los estándares definidos por la organización. o rganización. Las metodologías indican un conjunto de pasos exactos a seguir, así como las fases y los momentos oportunos para ejecutarlos. El propósito de las metodologías es llegar a un resultado a través de una secuencia de pasos lógicos y ordenados. Contramedidas: las medidas y acciones existentes para proteger la integridad de la información de la organización. La organización se encarga de definir y llevar a cabo contramedidas para mitigar el impacto y evitar la ocurrencia de los mismos, y la auditoría informática verifica la calidad y eficacia de estas contramedidas, identificando sus puntos débiles y dando sugerencias de cómo mejorarlas. CONTROL INTERNO INFORMÁTICO













Sistema de Evaluación: Además, Evaluación: Además, los distintos aspectos que evalúa. Nivel de exposición: Es exposición: Es un número del 1 al 10 que define la fecha de cuando será la próxima auditoría. Seguimiento de acciones correctivas: sugerencias correctivas: sugerencias de corrección del auditor. Plan de trabajo: Calendario de actividades y los recursos asignados. INFORME DE AUDITORÍA Normas: En 1996 la Unión U nión Europea publicó el Libro Verde de la Auditoría con normas IFAC Irregularidades: Irregularidades: Son los fraudes y errores. La responsabilidad del auditor se centra en planificar, llevar a cabo y evaluar su trabajo para obtener una expectativa razonable de su detección. Documentación: El informe de auditoría debe estar basado en la documentación o papeles de trabajo. Los papeles de trabajo pueden llegar a tener valor en los Tribunales de Justicia. Preparación, contenido y estructura general Es el momento adecuado de separar lo significativo de lo no significativo, debidamente evaluados por su importancia y vinculación. No existe un formato vinculante, si esquemas con requisitos mínimos aconsejables. El informe deberá ser claro, adecuado, suficiente y comprensible. Una utilización apropiada del lenguaje informático resulta recomendable. Puntos esenciales del informe de auditoría:













El Hábeas Data es un derecho que poseen las personas efectuar un amparo para conocer los datos referidos a ellos, almacenados en bancos de datos públicos o privados. Este derecho también permite exigir la supresión, s upresión, rectificación, actualización y confidencialidad de los mismos si fueran falsos o discriminatorios. Como consecuencia de la ley 25.326 es posible declarar que el uso de información de las personas con un propósito distinto al ingresado al banco de datos, y en especial la falta de veracidad de la misma, constituye una violación a la protección de datos personales. Ejemplo de esto son correos electrónicos con propagandas, las promociones telefónicas, o la difusión de datos entre e ntre entidades privadas cuando las direcciones de mail, el número de teléfono u otros datos extraído de las bases no tuvieron el consentimiento del titular. Para proteger jurídicamente al hardware se lo incluía en la categoría de “patentabilidad” o “inventos patentables”, dado que se lo consideraba como un elemento material o un

artefacto. Sin embargo, no es tan sencillo clasificar al software dentro de un marco jurídico por su carácter de elemento inmaterial, incorporal, intelectual, moral y económico. El Derecho ha adoptado, de manera generalizada internacionalmente, al régimen de derecho de autor para incluir a los programas de software. En nuestro país la Dirección Nacional de Propiedad Industrial rechazó patentar al software debido a que el artículo 4 de la ley 111 veda la protección jurídica a los inventos completamente teóricos sin aplicación industrial indicada. No obstante, el decreto del Poder Ejecutivo 165/94 incluyó al software dentro de la ley Propiedad Intelectual 11.723, con lo que le brinda protección jurídica y posibilita su registro en la Dirección Nacional de Derecho de Autor.

Delito informático:













El objetivo de la seguridad física es el garantizar la integridad de los activos físicos de la TI. Se puede entender por activos físicos a las personas, los equipamientos y las comunicaciones AUDITORÍA OFIMATICA La ofimática es un sistema informatizado que genera, procesa, almacena, recupera, comunica y presenta datos relacionados con el funcionamiento de la oficina. (Planillas de cálculo, procesadores de texto, agendas electrónicas, correo electrónico etc.) Existe falta de control centralizado en cuanto a la compra e implementación de estas herramientas en forma homogénea en toda la empresa. El auditor debe verificar que el inventario ofimático refleje con exactitud los equipos y las aplicaciones existentes en la organización. El auditor evalúa el procedimiento de adquisiciones de equipos, programas y aplicaciones. el auditor debe prestar especial atención a las necesidades que motivaron el pedido de equipos y la integración de estos con el sistema existente. Se debe evaluar si los usuarios cuentan con la suficiente formación y la documentación de apoyo necesaria para el desarrollo de sus tareas de un modo eficaz y eficiente. Se debe determinar si el procedimiento de respaldo es fiable y si se garantiza la recuperación de la información en caso de necesidad. Un punto para analizar es el grado de exposición ante la posibilidad de intrusión de virus informáticos.















AUDITORÍA DE LA SEGURIDAD. La función de la seguridad es asegurarse que los sistemas de información sean accedidos y modificados solo por el personal autorizado, quienes solo deben actúan dentro de los límites de su autorización.

La seguridad en el área de los sistemas s istemas de información tiene los siguientes objetivos:    

La protección de la integridad, la exactitud y la confidencialidad de la información. La protección de los activos ante amenazas de vandalismo. La protección de los activos ante desastres naturales. Contar con planes y políticas de contingencia para la recuperación de los sistemas.

AUDITORÍA DE REDES Aquí es donde se verifican los mecanismos de cifrado para las comunicaciones, para comprobar la eficiencia de los sistemas existentes y elevar recomendaciones de mejora si fuere necesario.

Al mismo tiempo, los usuarios deben tener restricciones de acceso por dominios de red, y solo pueden instalar los aplicativos señalados para sus puestos













Proyecto

Proceso

Muere al finalizar Objetivo particular, ejecutados por única vez Tiempo determinado, acotado.

No muere, no termina Repetitivos, secuenciales, ordinarios

Revolucionarios (cambios importantes) Equipos variables Los recursos entran y salen en la medida que son requeridos Mucha incertidumbre, más riesgos

El tiempo no está acotado, existe para perdurar en el tiempo. Evolutivo (mejora continua) Equipos relativamente estables Los recursos están disponibles por más tiempo Todo está mayormente definido, menos riesgos

La administración de proyectos es el conjunto de actividades que deberá llevar adelante el Gerente del Proyecto para conseguir los objetivos planteados. El director del proyecto es la persona responsable de alcanzar los objetivos del proyecto. La dirección de un proyecto incluye:













  

Comunicaciones. Elaboración de informes. Riesgos. Identificar Riesgos. Identificar los factores de riesgo. Adquisiciones. Compras, Adquisiciones. Compras, proveedores y contrataciones.

ALCANCE DEL PROYECTO ALCANCE: son todos los trabajos, y solo los trabajos necesarios para completar el producto del proyecto.

Mientras el grado de cumplimiento del Alcance del producto se mide contra las especificaciones, el grado de cumplimiento de Alcance del Proyecto se mide contra el Plan. A efectos de Definir el Alcance, será necesario generar la “Declaración del Alcance”, estamos

hablando de un documento que permita declarar con claridad lo que Si está incluido en el proyecto dejando muy claro lo que No incluye. Una buena declaración del Alcance (conocida también por su nombre en inglés, (Scope Statement), se escribe en términos de sus Entregables, es decir los productos o subproductos que se generan a lo largo del proyecto.













Control de Cambios del alcance Es el proceso de asegurar que los cambios ocurren de manera ordenada y beneficiosa. Prestemos atención a que no se dice que los cambios no ocurran, sino que estén bajo control. GESTIÓN DEL TIEMPO DEL PROYECTO Para poder llevar adelante una adecuada gestión de tiempos del proyecto será necesario hacer un correcto plan de tareas. Para ello deberemos, en primer lugar, hacer una clara y completa definición de actividades. Este proceso consiste en identificar y documentar las actividades específicas que deben ser efectuadas para producir los entregables identificados en la Estructura de Descomposición del Trabajo (EDT). Estimación Lo primero es lograr una predicción de cuál será la cantidad de jornadas laborales que insumirá cada actividad del proyecto. Inicialmente se calculará el esfuerzo. El esfuerzo es una medida de la carga de trabajo requerida para la actividad.













Mediciones de Valor Ganado: Para poder trabajar con Valor Ganado, es necesario contar con: 







La estructura de tareas (WBS): una lista de todas las tareas y paquetes de trabajo del proyecto, estructurados de forma jerárquica. Una serie de reglas para determinar objetivamente el grado de avance de c ada tarea en términos de los productos logrados. El cronograma de ejecución: un Diagrama de Gantt con el orden en el que se desarrollarán las tareas. Una línea base del proyecto en términos de costos, o lo que es lo mismo, el presupuesto acumulado a lo largo del tiempo o Curva S.

Las medidas centrales del Valor ganado son: 



BCWS (Budgeted Cost of Work Scheduled) o PV (Planed Value). Avance físico planeado a su valor presupuestado. o Suma de los costos estimados para las actividades cronogramadas hasta cierto o momento. BCWP (Budgeted Cost of Work Performed) o EV (Earned Value).

















Tiempo estimado originalmente en que se va a concluir el proyecto, medido en días, meses, años, etc.

Nos permite entre otras cosas, comparar el total de trabajo realizado hasta una fecha con el total de trabajo planificado para esa fecha. Estos análisis de valor ganado nos permitirán evaluar el estado del proyecto y si es necesario realizar ajustes. Es un tema que suele generar bastantes dudas, especialmente entre los aspirantes a PMP, que en su proceso de preparación para la certificación, suelen tener dificultades para entender













    

Formación Tormenta Normalización Rendimiento Despedida

GESTIÓN DE LAS COMUNICACIONES

La planificación de las comunicaciones implica comunicaciones implica determinar las necesidades de información y comunicaciones de los stakeholders del proyecto. Esto incluye determinar lo que necesita ser comunicado, a quien, cuando, con que método y cuan frecuentemente.













o bien en una escala cualitativa del tipo: alta, media, baja, entre otras posibilidades. La identificación de riesgos es el proceso sistemático de descubrir anticipadamente las amenazas sobre los objetivos del proyecto.

Gestión de abastecimiento del proyecto. La Gestión del abastecimiento o adquisiciones del proyecto se refiere a los procesos













Un contrato es un acuerdo vinculante para las partes en virtud del cual una de ellas se compromete a proveer productos, servicios o resultados especificados, mientras la otra parte asume el compromiso compromiso de retribuir con con dinero u otra contraprestación contraprestación válida y acordada.

Un contrato: • Obliga legalmente a las partes. • Describe derechos y obligaciones • Documenta un acuerdo

Un contrato se compondrá de un conjunto de Términos y Condiciones.















▪ Organizaciones matriciales. Representan un híbrido entre las dos estructuras

anteriores ya que ambas se superponen para dar lugar a una tercera en la que cada individuo depende de dos superiores: el director del proyecto en el que participa y el director del departamento (área funcional) en el que se encuentra. Si la dependencia del primero es mayor se habla de estructura matricial fuerte y en e n caso contrario de estructura matricial débil.

ISO 9000

















Establece los requisitos de la documentación, que son:













organizaciones organizacio nes los siguientes pasos para implementar y certificar un Sistema de

Resumen mio.docx

Recommend Documents