Curso de revisi贸n CISA Cap铆tulo 6
Desarrollo, adquisici贸n, implementaci贸n y mantenimiento de Aplicaciones de negocio
Contenido del capítulo • Desarrollo de aplicaciones de negocio • Método tradicional Ciclo de vida de desarrollo de sistemas (SDLC) • Estrategias alternativas de desarrollo de sistemas • Prácticas de mantenimiento de sistemas de información • Herramientas y técnicas de administración de proyectos • Herramientas y métricas de desempeño del desarrollo de sistemas • Mejores prácticas del proceso de desarrollo de software • Auditando el desarrollo, adquisición y mantenimiento de sistemas de información
Objetivo del capítulo El objetivo de esta área es “Asegurar que el auditor es capaz de evaluar la metodología y el proceso por el cual son desarrollados, adquiridos, implementados y mantenidos los sistemas aplicativos de negocio para asegurar que estos cumplen con los objetivos de negocio de la organización.
Sumario del capítulo
De acuerdo cuadro de certificación, el contenido de este capítulo representa aproximadamente el 16% de el total del examen CISA (aproximadamente 32 preguntas)
Desarrollo de aplicaciones de negocio Una aplicación individual o un proyecto es iniciado por: • Una nueva oportunidad que involucra a un nuevo o ya existente proceso de negocio • Un problema que involucra a un existente proceso de negocio • Una nueva oportunidad que permitirá a la organización tomar ciertas ventajas tecnológicas • Un problema con la tecnología actual
Método tradicional del ciclo de vida de desarrollo de sistemas Definición de requerimientos Estudio de Factibilidad Diseño
Adquisción de Sw
Desarrollo
Parametrización Pruebas Implementación
Desarrollo de aplicaciones de negocio Roles y responsabilidades de grupos e individuos
• ALTA GERENCIA
• GERENCIA DEL PROYECTO
• GERENCIA USUARIA
• EQUIPO DE DESARROLLO
• COMITÉ SEGUIMEINTO PROYECTO
• EQUIPO DE USUARIOS
• PATROCINADOR PROYECTO
• OFICIAL DE SEGURIDAD
• GERENCIA DESARROLLO
• ASEGURAMIENTO DE CALIDAD
Desarrollo de aplicaciones de negocio Funciones y Responsabilidades de los Grupos y Personas
ALTA GERENCIA
• Se compromete c/proyecto • Aprueba recursos • Su compromiso ayuda a asegurar la participación de personas/áreas necesarias.
Desarrollo de aplicaciones de negocio Funciones y Responsabilidades de los Grupos y Personas GERENCIA USUARIA
• Asume propiedad del proyecto y producto • Asigna representantes calificados • Participa en definición requerimientos, pruebas aceptación, entrenamiento • Revisa y aprueba fases/etapas del sistema • ¿Cumple el Software con la funcionalidad requerida?
Desarrollo de aplicaciones de negocio Funciones y Responsabilidades de los Grupos y Personas COMITÉ SEGUIMIENTO DEL PROYECTO
• Ejerce dirección total • Asegura representación apropiada de áreas involucradas • Responsable de costos y planes de trabajo • Conformado por un representante de cada parte afectada, los cuales estarán autorizados para tomar decisiones p/su parte • Gerente del Proyecto puede ser integrante y actuar como presidente
Desarrollo de aplicaciones de negocio Funciones y Responsabilidades de los Grupos y Personas COMITÉ SEGUIMIENTO DEL PROYECTO
• Funciones: – Revisa regularmente avances y celebra reuniones de emergencia – Coordina y asesora, responde preguntas y toma decisiones sobre usuarios y diseño – Emprende acciones correctivas (cambios personal, presupuestos, cronogramas, objetivos, rediseño, etc.). Decide interrupción del proyecto
Desarrollo de aplicaciones de negocio Funciones y Responsabilidades de los Grupos y Personas PATROCINADOR PROYECTO • Alto directivo a cargo de función principal de negocio + beneficiada • Financia proyecto • Trabaja con GTE. PROYECTO p/definir parámetros medición éxito (términos mensurables y cuantificables) • Se le asigna propiedad de datos y aplicación
Desarrollo de aplicaciones de negocio Funciones y Responsabilidades de los Grupos y Personas GERENCIA DESARROLLO • Apoyo técnico de HW y SW • Desarrollando, instalando y operando el sistema solicitado • Garantiza compatibilidad de aplicación con entorno informático y plan estratégico organizacional • Asume apoyo y mantenimiento después de liberación
Desarrollo de aplicaciones de negocio Funciones y Responsabilidades de los Grupos y Personas GERENCIA DEL PROYECTO • Dirección general • Administración cotidiana, asegurando alineación con dirección gral. • Asegura representación apropiada de áreas involucradas • Asegura ajuste a normas locales • Asegura calidad sw • Resuelve conflictos • Monitorea y controla costos y plan trabajo • Puede ser miembro de Usuarios o Sistemas
Desarrollo de aplicaciones de negocio Funciones y Responsabilidades de los Grupos y Personas EQUIPO DESARROLLO • Ejecuta tareas de programación • Respeta normas/estándares • Mantiene comunicación con usuarios, involucrándose activamente • Informa sobre ajustes necesarios al GTE. PROYECTO
Desarrollo de aplicaciones de negocio Funciones y Responsabilidades de los Grupos y Personas EQUIPO USUARIOS • Realiza tareas asignadas • Mantiene comunicación con Sistemas, involucrándose activamente • Informa al GTE. PROYECTO desviaciones reales y previsibles
Desarrollo de aplicaciones de negocio Funciones y Responsabilidades de los Grupos y Personas OFICIAL SEGURIDAD • Asegura el cumplimiento a las políticas de seguridad institucional • Asesora sobre medidas de seguridad que deben incorporarse • Revisa planes y reportes de las pruebas de seguridad antes de implementación • Periódicamente revisa efectividad de la seguridad del sistema durante su vida operativa
Desarrollo de aplicaciones de negocio Funciones y Responsabilidades de los Grupos y Personas ASEGURAMIENTO DE CALIDAD • Revisa resultados y productos de c/fase y confirma al final de cada una, si requerimientos fueron cubiertos • Los puntos en donde se hacen estas revisiones dependen de la metodología usada, de la estructura y magnitud del sistema y del impacto de las desviaciones • Crucial para completar un proyecto dentro de lo programado y presupuesto, y para alcanzar madurez del software
Desarrollo de aplicaciones de negocio Funciones y Responsabilidades de los Grupos y Personas
Desarrollo de aplicaciones de negocio Riesgos asociados con Desarrollo de Software Al utilizar una pobre metodología de se incurre frecuentemente en: •Expectativas no cumplidas •Se excedan los límites de recursos financieros •Se excedan los tiempos de desarrollo
Desarrollo de aplicaciones de negocio Riesgos asociados con Desarrollo de Software Proveedores externos •Comunicar claramente los requerimientos •Establecer claramente los entregables •Costos y tiempos esperados •Calidad esperada El hecho de contar con una metodología no asegura el éxito de un proyecto de desarrollo
Uso de Técnicas de Análisis Estructurado, Diseño y Desarrollo •
Desarrollar diagramas de contexto de sistemas
•
Realizar descomposición de flujo de datos jerárquica/ flujo de control
•
Desarrollar mini-especificaciones
•
Desarrollar diccionario de datos
•
Definir todos los eventos externos.- entradas desde ambientes externos
•
Definir diagramas de transformaciones individuales de flujo de datos de cada evento externo
Método Tradicional de Ciclo de vida de Desarrollo de Sistemas (SDLC) Definición de requerimientos •
Identificar y consultar a los accionistas para determinar sus expectativas
•
Analizar los requerimientos para detectar y corregir conflictos y determinar prioridades
•
Identificar alcance y como el sistema debe interactuar con otros sistemas
•
Convertir los requerimientos de usuarios en requerimientos de sistemas
•
Registrar los requerimientos en un formato estructurado
•
Verificar que los requerimientos están completos, consistentes, no ambiguos, verificables, modificables, probables
•
Resolver conflictos entre accionistas
•
Resolver conflictos entre el conjunto de requerimientos y los recursos disponibles
Método Tradicional de Ciclo de vida de Desarrollo de Sistemas (SDLC) Estudio de Factibilidad •Definir un marco de tiempo de la solución •Determinar si se requieren recursos de información o es la solución óptima para las necesidades del negocio •Determinar si un sistema existente puede corregir la situación sin modificaciones. •Determinar si un producto del mercado ofrece una solución •Determinar el costo/beneficio aproximado •Determinar si la solución encaja la estrategia de negocio
Método Tradicional de Ciclo de vida de Desarrollo de Sistemas (SDLC) Adquisición de Software Contenido de la Propuesta de requerimientos (RFP) •Producto frente a requerimientos del sistema •Referencias de clientes •Viabilidad y estabilidad financiera del vendedor •Disponibilidad de documentación completa y exacta •Soporte del vendedor •Disponibilidad del código fuente •Tiempo de experiencia en el producto •Lista de actualizaciones, anteriores y previstas
Método Tradicional de Ciclo de vida de Desarrollo de Sistemas (SDLC) Adquisición de Software •Puntos de discusión con los usuarios acerca de los proveedores •Contenido contractual
Método Tradicional de Ciclo de vida de Desarrollo de Sistemas (SDLC) Sistemas de administración de recursos integrados (ERP) • Alineación con la operación y administración • Adecuada parametrización • Pruebas de usuario
Método Tradicional de Ciclo de vida de Desarrollo de Sistemas (SDLC) Diseño 9Participación de usuarios 9Desarrollo de diagramas de flujo 9Describir entradas y salidas 9Diseño de Bases de datos Participación del Auditor de TI
Método Tradicional de Ciclo de vida de Desarrollo de Sistemas (SDLC) • Desarrollo 9Codificación y desarrollo de programas 9Depuración y prueba de programas 9Conversión de datos de sistemas viejos 9Entrenamiento de usuarios 9Documentación de cambios 9Métodos y técnicas de programación 9Facilidades de programación en línea (IDF) 9Lenguajes de programación
Método Tradicional de Ciclo de vida de Desarrollo de Sistemas (SDLC)
Pruebas •Piloto
•Función/validación
•Unitarias
•Regresión
•De interface
•Paralelas
•De sistema
•Sociabilidad
Método Tradicional de Ciclo de vida de Desarrollo de Sistemas (SDLC)
Pruebas del sistema 9Pruebas de recuperación 9Pruebas de seguridad 9Pruebas de volumen/stress 9Pruebas de desempeño
Método Tradicional de Ciclo de vida de Desarrollo de Sistemas (SDLC) Implementación •Planeación y asignación de responsabilidades •Conversión de datos •Fecha de migración •Procedimiento de vuelta atrás •Pruebas en ambiente real Revisión post implementación
Metodologías alternativas de desarrollo Prototipos •Creación de sistemas a través de procedimientos controlados de prueba y error •Modelo del sistema en un corto período de tiempo •Modelo como mecanismo de diseño •El desarrollo se centra en informes y pantallas
Metodologías alternativas de desarrollo Desarrollo de aplicaciones basadas en WEB •Protocolos basados en XML (Extensible Markup Language) –SOAP, WSDL, UDDI
•Integración de diversas plataformas •Actualización de datos •Internet, extranet, intranet
Metodologías alternativas de desarrollo Desarrollo rápido de aplicaciones (RAD) •Equipos de desarrollo pequeños y bien entrenados •Herramientas de diseño •Creación de prototipos •Reutilización de componentes •Límites rigidos de tiempo Etapas •Definición de conceptos •Diseño funcional •Desarrollo •Implantación
Metodologías alternativas de desarrollo Desarrollo Agil •Subproyectos •Replanificación del proyecto en cada interacción •Conocimiento tácito •Equipos pequeños •Codificación en pareja •Rol del gerente •Rol de miembros del equipo
Metodologías alternativas de desarrollo •Desarrollo de sistemas Orientados a datos •Desarrollo basado en objetos •Desarrollo basado en componentes •Reingeniería o rediseño •Ingeniería inversa o en reversa
Prácticas de mantenimiento de sistemas de información Administración del cambio •Cambios de emergencia •Aprobación •Documentación •Pruebas de cambios de programas •Proceso de migración de programas
Prácticas de mantenimiento de sistemas de información •Software de control de bibliotecas (librerías) •Integridad del código fuente y ejecutable •Comparación del código fuente
Técnicas de administración de proyectos
•Administración del proyecto general (Planeación y monitoreo de programa) •Estimación del costo del Software •Administración de configuración del Sw •Documentación •Automatización de oficinas
Técnicas de administración de proyectos •Timebox managment •Presupuestos y cronogramas •CPM (metodología de ruta crítica) •Diagramas de Gantt •PERT (Técnica de evaluación y revisión de programas)
Herramientas de desarrollo de sistemas y ayudas de productividad •Generadores de código –Ingeniería de Software asistida por computadora (CASE)
•Lenguajes de cuarta generación •Análisis de punto de función
Prácticas mejoradas del proceso de Desarrollo de Software ISO 9126 ISO 9126 provee la definición de las características y proceso de evaluación de calidad asociado para ser usado cuando se especifican los requerimientos y se evalúa la calidad de los productos del Software a través de su ciclo de vida.
Prácticas mejoradas del proceso de Desarrollo de Software Software Capability Maturity Model (CMM)
•Inicial •Repetible •Definido •Administrado •Optimizando
Auditando el desarrollo, Adquisción y mantenimiento de sistemas • Determinar los principales componentes, objetivos y requerimientos de usuarios • Determinar y clasificar los principales riesgos • Identificar controles para mitigar riesgos • Informar al equipo del proyecto en lo referente al diseño del sistema e implementación de controles • Monitorear el proceso de desarrollo de sistemas • Participar en las revisiones post-implementación
Auditando el desarrollo, Adquisción y mantenimiento de sistemas
•Administración de proyecto •Estudio de factibilidad
Auditando el desarrollo, Adquisción y mantenimiento de sistemas
•Definición de requerimientos •Proceso de adquisición del software
Auditando el desarrollo, Adquisción y mantenimiento de sistemas •Fase de diseño detallado y programación •Fase de pruebas •Fase de implementación •Revisión post-implementación
Auditando el desarrollo, Adquisción y mantenimiento de sistemas Procedimientos de cambios de sistemas y procesos de migración de programas
•
Evaluar lo apropiado de los procedimientos de la organización
•
Identificar cambios del sistema
•
Revisar la documentación
PREGUNTAS
El uso del diagrama de GANTT puede:
A. Asistir en el control del proyecto.
B. Resaltar los checkpoints del proyecto. C. Asegurar documentaci贸n est谩ndar. D. Dirigir la post-implementaci贸n
Cual de los siguientes NO es un rol de un patrocinador de proyecto quien estĂĄ involucrado en un proyecto de desarrollo de sistemas: A. Proveer fondos al proyecto B. Responsable de la propiedad de los datos y la aplicaciĂłn C. Monitorear y controlar los costos y tiempos del proyecto D. Trabajar con el project manager para definir parametros de ĂŠxito
La responsabilidad de asegurar que el SDLC se adhiere a las pol铆ticas de seguridad corporativas y probar la seguridad antes de la implementaci贸n es de: A. Security Officer B. Project manager C. Quality assurance D. Project steering commitee
Cual de los siguientes puntos es MENOS probable de incluir en un estudio de Factibilidad A. Requerimientos legales B. Requerimientos de Sistema Operativo C. Especificaciones de control y AuditorĂa D. Consideraciones de capacidad de Hardware
Cuando se implementa un software que es una aplicación empaquetada, cual de los siguientes representa el MAYOR riesgo: A. Varias versiones de software sin control B. Programas fuente que no estén sincronizados con código objeto C. Parametrización incorrecta del Sw D. Errores de programación
Durnte cual de las siguientes fases del desarrollo de sistemas deben ser preparadas normalmente las pruebas de aceptación de usuario: A. Estudio de factibilidad B. Definición de requerimientos C. Planeación de implementación D. Revisión post-implementación
Idealmente, las pruebas de stress deben de efectuarse en: A. Ambiente de prueba, usando datos de prueba B. Ambiente de producci贸n, usando cargas de trabajo reales C. Ambiente de pruebas, usando cargas de trabajo reales D. Ambiente de producci贸n usando datos de prueba
Una revisi贸n post-implementaci贸n de un sistema nuevo o modificado, debe de realizarlo: A. Usuario final y un auditor de IS B. Auditor de IS y equipo de desarrollo C. Comit茅 de direcci贸n y equipo de desarrollo D. Equipo de desarrollo y usuarios finales
Cual de las siguientes debe ser considerada como la MAS seria desventaja del desarrollo de sistemas por prototipo? A. El software de prototipo es caro B. El prototipo demanda excesivo uso de la computadora C. El usuario puede percibir que el desarrollo ya estรก completo D. La necesidades del usuario pueden no ser correctamente establecidas.
Cual de las siguientes debe ser considerada como el control MAS efectivo para controlar el mantenimiento de aplicaciones? A. Informar a los usurios del status de los cambios B. Establecer prioridades sobre cambios de programas C. Obtener aprobaci贸n de usuario sobre cambios de programas D. Requerir la documentaci贸n de especificaci贸n de los usuarios sobre los cambios
Cuando se está pensando en mover un programa del ambiente de pruebas al ambiente de producción, el MEJOR control esta dado por: A. Los programadores copian el programa fuente y compilan el programa objeto a las librerias de producción. B. El programador copia el programa fuente a las librerias de producción y ahí el Grupo de Control de producción compila el programa C. El Grupo de control de producción copia el programa fuente y compila el programa objeto a las librerias de producción. D. El Grupo de control de producción copia el programa fuente a librerias de producción y entonces compila el programa
Cual de las siguientes NO debe de ser una raz贸n para que un auditor de IS se involucre en las negociaciones contractuales de sistemas de informaci贸n? A. En ocasiones el Hardware no interfaza de manera aceptable B. Muchos proyectos de sistemas de informaci贸n incurren en mayores costos de los planeados C. El proveedor puede salir del mercado y dejar de dar servicio de soporte del producto D. Solo el auditor de IS puede determinar si los controles en el sistema son adecuados
Cuando se audita el propósito de la adquisición de un nuevo sistema computacional, el auditor de IS debe PRIMERAMENTE establecer que: A. Claramente un caso de negocio está siendo aprobado por la gerencia B. Estándares de seguridad corporativa serán alcanzados C. Los usuarios serán involucrados en el plan de implementación D. El nuevo sistema alcanczará toda la funcionalidad requerida por los usuarios
Cual de las siguientes debe estar establecida para proteger al comprador de una aplicación empaquetada, en caso de que el vendedor cese el trato? A. El código fuente permanezca en retención de garantía B. El código objeto lo mantenga un tercero confiable C. Obligación contractual para el mantenimiento del software D. Adecuado entrenamiento para el equipo de programación interno
En cual de las siguientes fases del SDLC de un nuevo sistema es MAS importante que el auditor de IS participe?
A. Dise帽o B. Pruebas C. Programaci贸n D. Implementaci贸n
1. El análisis de riesgo es MAS útil cuando se aplica durante qué fase del proceso del SDLC ? A. Iniciación del proyecto B. Construcción C. Pruebas de aceptación D. Implementación
2.
¿Cuál de los siguientes tipos de pruebas determinarían si los cambios a un programa han introducido errores que no existían antes? A. Pruebas de integración B. Pruebas unitarias C. Pruebas del sistema D. Pruebas de regresión
3.
La persona MAS apropiada para encabezar el comité de dirección para un proyecto de desarrollo de sistemas con impacto significativo en el área de negocios sería: A. Analista de negocio B. Director de Sistemas de Información (CIO) C. Líder de proyecto D. Directivo nivel ejecutivo
4.
El PRINCIPAL prop贸sito de una corrida en paralelo de un sistema nuevo es: A. Verificar que el sistema provee la funcionalidad de negocio requerida. B. Validar la operaci贸n del nuevo sistema comparada con el anterior. C. Resolver cualquier error en el programa y archivos interfaces. D. Verificar que el sistema puede procesar la carga de producci贸n
5.
Cuál de los siguientes proveerían los estándares de codificación? A. Convenciones de nombramiento de campos. B. Diagramas de flujo de datos. C. Tablas de control de accesos D. Documentación del programa
6.
Cuál de los siguientes MAS probablemente aseguraría que el proyecto de desarrollo de sistemas alcanza los objetivos del negocio? A. Mantenimiento de las bitácoras de cambios del programa. B. Desarrollo de un plan de proyecto indentificando todas las actividades de desarrollo. C. Liberación de cambios en la aplicación en periodos específicos del año. D. Involucramiento del usuario en las especificaciones y aceptación del sistema
7.
¿Cual de los siguientes es una medida del tamaño de un sistema de información basado en el número y complejidad de entradas, salidas y archivos del sistema? A. Function point (FP) B. PERT. C. Diseño rápido de aplicaciones (RAD) D. Método de ruta crítica (CPM)
8.
Cuando se audita la fase de requerimientos de una adquisici贸n de software, el auditor IS debe: A. Establecer la factibilidad de la tabla de tiempos del proyecto B. Establecer los procesos de calidad propuestos por el proveedor C. Asegurar que el mejor paquete de software es adquirido D. Revisar la completez de las especificaciones
9.
El prop贸sito de hacer debug a los programas es: A. Generar datos random que pueden ser usados para probar programas antes de implementarlos. B. Proteger durante la fase de programaci贸n, de que los cambios v谩lidos sean sobreescritos por otros cambios. C. Definir los costos de desarrollo y mantenimiento del programa para incluirlos en el estudio de factibilidad. D. Asegurarse que las terminaciones anormales del programa y errores sean detectados y corregidos.
10. Cuál de los siguientes enunciados es MAS válido con respecto a la estandarización de la documentación del software?: A. Debe ser escrita desde la perspectiva de quien lo escribe. B. Debe ser escrita en un estilo de lenguaje natural que sea fácil de leer. C. Se debe usar una organización estándar D. El escritor como autoridad primaria tiene la última palabra. .
La solicitud de propuesta (RFP) para la adquisición de un sistema de aplicación es MÁS probable que sea aprobada por el: A.
Comité de seguimiento del proyecto (project steering committee.)
B.
Patrocinador de proyecto.
C.
Gerente de proyecto.
D.
Equipo de proyecto de usuario.
11. Cual de los siguientes procedimientos NO realizaría un Auditor de IS durante la fase de diseño de un proyecto de sistema? A. Ayudar al desarrollo de un diseño funcional para las rutinas incrustadas de auditoría B. Evaluar la adecuación del sistema C. Infomar al analista en lo referente a las rutinas de control D. Examinar el diseño con respecto a la adherencia a las polítias institucionales
12. Cuando un auditor está revisando un proyecto de desarrollo de sistemas, debe de estar MAS preocupado sobre: A. Los objetivos de negocio son alcanzados B. Adecuación de los procedimientos de control y seguridad C. El sistema es acorde a la Infraestructura tecnológica D. El desarrollo cumple con los estándares de calidad de la compañía
13. Cual de los siguientes debe ser incluido en un estudio de factibilidad de un proyecto para instalar EDI? A. El formato de los algoritmos de encripci贸n B. Detalle de los procedimientos de control interno C. Los protocolos de comunicaci贸n requeridos D. Acuerdos de confianza de terceras partes
14. Cual de los siguientes son objetivos de usar la Metodología de Ciclo de Vida de Desarrollo de Sistemas A. Asegurar que el equipo de trabajo está completo y provee metodos para controlar costos y tiempos B. Provee un metodo de controlar costos y tiempos, asegurando comunicación entre usuarios, auditores de SI, gerencia y personal de TI C. Provee metodos de controlar costos y tiempos, y medios efectivos de auditar el proyecto de desarrollo D. Asegura la comunicación entre usuarios, auditores de IS, gerencia y personal de TI, asegurando que los equipos de trabajo estén completos.
15. Cual de los siguientes mecanismos es mas probable que ocurra cuando un proyecto de Desarrollo est谩 a la mitad de su etapa de contrucci贸n? A. Pruebas unitarias B. Pruebas de stress C. Pruebas de regresi贸n D. Pruebas de aceptaci贸n
16. Los siguientes son controles de mantenimiento de aplicaciones que son responsabilidad del equipo de usuarios, Excepto A. Iniciar requerimientos dentro de su alcance de autoridad B. Actualizar la documentaci贸n que refleje los cambios del sistema C. Aprobar cambios antes de su implementaci贸n basado en los resultados de prueba D. Aprobar cambios antes de su implementaci贸n basado en la revisi贸n cambios en el manual de procedimientos
17. Utilizar software de Auditoría para realizar comparación de código de programas de producción es una técnica de pruebas: A. Lógicas B. Cambios C. Eficiencia D. Computacionales
18. Cuando un nuevo sistema es implementado dentro de un marco de tiempo corto, es MAS importante: A. Concluir los manuales de usuario B. Realizar pruebas de aceptaci贸n del usuario C. A帽adir mejoras de 煤ltimo minuto a la funcionalidad D. Asegurar que el c贸digo ha sido bien documentado y revisado
19. Si la decisión ha sido adquirir un software empaquetado en lugar de desarrollo interno, esta decisión se toma en la etapa de: A. Definición de requerimientos B. Estudio de factibilidad C. Diseño detallado D. Fase de programación
20. Una compañía ha contratado a un consultor externo para desarrollar un sistema que remplace a uno que actualmente está en produccción. En la revisión, el auditor de IS debe estar mas preocupado por: A. Las pruebas de aceptación son manejadas por los usuarios B. No está estipulado un plan de calidad con el proveedor C. No todas las funcionalidades de negocio estarán disponibles en la primera implementación del sistema D. Se están usando prototipos para confirmar que se alcancen los requerimientos de negocio