Unidad II - Documentación del software

488 visualizaciones

Publicado el

Presentacion de como documentar un Software

Publicado en: Software
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
488
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
14
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Unidad II - Documentación del software

  1. 1. EL CICLO DE VIDA DE UN SISTEMA DE INFORMACIÓN  El proceso de desarrollo de software  Modelos de ciclo de vida  El ciclo de vida de una base de datos  El proceso de diseño de bases de datos 1. Fase 1: Análisis de requerimientos 2. Fase 2: Diseño conceptual 3. Fase 3: Elección del SGBD 4. Fase 4: Diseño lógico 5. Fase 5: Diseño físico 6. Fase 6: Instalación y mantenimiento
  2. 2. LAS ETAPAS DEL PROCESO DE DESARROLLO DE SOFTWARE El ciclo de vida de un sistema de información comprende las siguientes etapas:  Planificación  Análisis  Diseño  Implementación  Pruebas  Instalación / Despliegue  Uso y mantenimiento
  3. 3. LAS ETAPAS DEL PROCESO DE DESARROLLO DE SOFTWARE Planificación  Ámbito del proyecto  Estudio de viabilidad  Análisis de riesgos  Estimación  Planificación temporal  Asignación de recursos.
  4. 4. LAS ETAPAS DEL PROCESO DE DESARROLLO DE SOFTWARE Análisis (¿qué?)  Elicitación de requerimientos:  Requerimientos funcionales  Requerimientos no funcionales  Modelado:  Modelado de datos  Modelado de procesos
  5. 5. LAS ETAPAS DEL PROCESO DE DESARROLLO DE SOFTWARE Diseño (¿cómo?) Estudio de alternativas y diseño arquitectónico  Diseño de la base de datos  Diseño de las aplicaciones
  6. 6. LAS ETAPAS DEL PROCESO DE DESARROLLO DE SOFTWARE Implementación  Adquisición de componentes.  Creación e integración de los recursos necesarios para que el sistema funcione.
  7. 7. LAS ETAPAS DEL PROCESO DE DESARROLLO DE SOFTWARE Pruebas  Pruebas de unidad.  Pruebas de integración.  Pruebas alfa.  Pruebas beta.  Test de aceptación.
  8. 8. LAS ETAPAS DEL PROCESO DE DESARROLLO DE SOFTWARE Instalación / despliegue Uso / mantenimiento  Mantenimiento adaptativo.  Mantenimiento correctivo.  Mantenimiento perfectivo.
  9. 9. MODELOS DE CICLO DE VIDA Modelo en cascada
  10. 10. MODELO EN CASCADA  El modelo en cascada (también conocido como “ciclo de vida clásico”) no es el único, ni tampoco el mejor en muchas situaciones.  No obstante, se adapta bien al desarrollo de las prácticas de una asignatura.
  11. 11. DESARROLLO DE PROTOTIPOS
  12. 12. CICLO DE VIDA DE UNA BD  Diseño conceptual: Descripción del esquema de la base de datos utilizando un modelo de datos conceptual.  Diseño lógico: Descripción de la base de datos con un modelo de datos implementable (p.ej. el modelo relacional).  Diseño físico: Descripción de la base de datos a nivel interno
  13. 13. MODELO EN ESPIRAL
  14. 14. CICLO DE VIDA DE UNA BD  Definición del sistema: Requerimientos de datos.  Diseño de la base de datos.  Implementación de la base de datos.  Carga o conversión de los datos.  Conversión de aplicaciones.  Prueba y validación.  Operación, supervisión y mantenimiento.
  15. 15. CICLO DE VIDA DE UNA BD Diseño de la base de datos:  Diseño conceptual: Descripción del esquema de la base de datos utilizando un modelo de datos conceptual.  Diseño lógico: Descripción de la base de datos con un modelo de datos implementable (p.ej. el modelo relacional).  Diseño físico: Descripción de la base de datos a nivel interno.
  16. 16. PROCESO DE DISEÑO DE BD Fases: 1. Análisis de requisitos. 2. Diseño conceptual. 3. Elección del sistema gestor de bases de datos. 4. Diseño lógico. 5. Diseño físico. 6. Instalación y mantenimiento.
  17. 17. DOCUMENTACIÓN DE SOFTWARE Como inventariar el hardware de cómputo. 1. El tipo de equipo, el número de modelo, el fabricante. 2. El estado de funcionamiento del equipo. 3. La edad estimada del equipo 4. La vida proyectada del equipo 5. La ubicación física del equipo 6. El departamento o la persona responsable del equipo.
  18. 18. ADQUISICIÓN DE HARDWARE DE COMPUTO Opción Ventajas Desventajas Compra - A la larga es mas barato que el arrendamiento -proporciona ventajas fiscales - El costo inicial es alto - Riesgo de quedarse con el equipo malo si la opción fue errónea Arrendamiento financiero -No se invierte ningún capital -los pagos son bajos -la compañía no tiene la propiedad del sistema Alquiler -Normalmente se incluyen el mantenimiento y el seguro -la compañía no es dueña de la computadora
  19. 19. EVALUACIÓN DEL SOFTWARE Al evaluar el software para los proyectos de sistemas de información, los analistas y las organizaciones se enfrentan cada vez mas con la disyuntiva de hacer, comprar o subcontratar. Existen 3 tipos: 1. Software personalizado: se debe crear cuando la organización busque una ventaja competitiva mediante el uso de sistemas de información reforzado como un despliegue estratégico
  20. 20. EVALUACIÓN DE SOFTWARE 2. Software Comercial: El software comercial incluye productos como Microsoft office, también se puede referir a componentes u objetos de software (llamados componentes básicos) que se puedan comprar para proporcionar una funcionalidad particularmente necesaria en un sistema.
  21. 21. EVALUACIÓN DE SOFTWARE 3. Proveedor de servicios de aplicaciones: las organizaciones podrían obtener algunos beneficios de tomar un enfoque totalmente diferente para adquirir software., esta opción es subcontratar algunas de las necesidades de las organizaciones que se especialice en las aplicaciones de Tecnologías.
  22. 22. EVALUACIÓN DE SOFTWARE Tipo Ventajas Desventajas Software a la medida -respuestas especificas -innovación -Personal interno disponible - Costo inicial elevado - -Necesidad de contratar o trabajar con un equipo Software Comercial - Refinado en el mundo comercial - -Otras empresas ya lo usan -Enfocado a la programación, no en los negocios, -personalización limitada ASP -No es necesario contratar, capacitar o retener a muchos empleados -Perdida de control de los datos -Preocupación sobre seguridad confidencialidad y privacidad.
  23. 23. TIPOS DE SOFTWARE • Por su estructura • Funcionales • Orientados a objetos • Orientados a listas • Orientados a componentes • Por su función • Programas o sistemas de usuario. • Interfaces Hombre – maquina • Herramientas de software • Librerías • BD • Sistemas basados en WEB
  24. 24. TIPOS DE SOFTWARE • Por su plataforma • Sistemas de cómputos distribuido • Sistemas de tiempo real • Sistemas de computo paralelos • Sistemas basados en chips
  25. 25. PROPUESTA DE SISTEMA Organización de las propuestas de sistemas. Una vez recopilado el material que se debe incluir en su propuesta de sistemas, necesita juntarlo en piezas de un a manera lógica y visualmente eficaz . La propuesta de sistemas debe llevar una carta de presentación para la dirección y la fuerza de tarea de Tecnología,
  26. 26. COMUNICACIÓN EFICAZ 1. Tablas 1.Tablas comparativas 2. Gráficos 1.Lineales 2.Columnas 3.Barras
  27. 27. REPRESENTACIÓN DE LA PROPUESTA DE SISTEMAS  Datos recopilados de la organización  Verificar el resumen ejecutivo  No se debe colocar el resumen de la propuesta
  28. 28. VISIBILIDAD DE PROCESOS Los sistemas de software son intangibles por lo que los administradores necesitan documentación para identificar el progreso en el desarrollo. RETOS • Sistemas Legados • Sistemas que deben ser mantenidos y mejorados • Heterogeneidad • Sistemas que incluyen una mezcla de software y hardware • Entrega • Entrega a tiempo de los productos de software • Formalidad • Exista demanda en el proceso de desarrollo
  29. 29. MANUAL TÉCNICO Documentación • Conservar la historia de un proyecto de software. • Establecer símbolos institucionales • Establecer las políticas de normalización para los estándares de documentación. Un manual técnico debe considerar 1. Estándares de programación 2. Listado de programas fuentes 3. Seguridad 4. Política de backups
  30. 30. MANUAL DE INSTALACIÓN Se deben desarrollar los pasos para la instalación del proyecto aplicativo MANUAL DE REFERENCIA Se describen detalladamente todos los mensajes y posibles errores con su solución
  31. 31. MANUAL DE USUARIO Maneja el alcance del aplicativo • Relación con otros aplicativos • Estándares de programación • Herramientas de desarrollo de software • Especificaciones del diseño • Listado de programas fuentes • Seguridad • Infraestructura
  32. 32. CONTROLES DE AUDITORIA DE SISTEMAS La auditoría de sistemas de información, auditoría informática o auditoría de sistemas es un tipo de auditoría consistente en el examen de los sistemas de información y de los centros de proceso de datos, instalaciones y unidades informáticas de las organizaciones, con objeto de facilitar la consecución de los objetivos que persiguen, tanto los del área informática como, primordialmente los del conjunto de la organización .
  33. 33. FACTORES QUE PROPICIAN LA AUDITORIA  Políticas internas de la empresa  Necesidad de controlar el eso de equipos computacionales.  Altos costos debido a errores  Perdida de información y de capacidades de procesamiento de datos, aumentando así la posibilidad de toma de decisiones.  Valor de hardware, software y personal
  34. 34. OBJETIVOS DE LA AUDITORIA • Conocer su propio sistema y su grado de adecuación a la norma. • Revisar el grado de implantación • Determinar la eficacia del sistema • Cumplir con los requisitos reglamentarios. • Detectar áreas de mejora.
  35. 35. FUNCIONES DE AUDITORIA  Velar por la eficacia y eficiencia del sistema informático  Verificar el cumplimiento de las normas y estándares vigentes en la organización  Supervisar el control interno ejercido sobre los sistemas de información conducente a la protección de los activos de información de información
  36. 36. TIPOS DE AUDITORIA Tipo Descripción Ventajas Desventajas Interna Aplicada con el personal que labora en la empresa. -Menos costosa -Omitir información - Encubrir deficiencias Externa Se contrata a una firma especializada para realizar la misma - Existe menor margen de error - No existe encubrimiento s - Que otras empresas conozcan su información
  37. 37. AUDITORIA APLICADA AL DESARROLLO DE APLICACIONES Auditoria de datos de entra Se analizará la captura de la información en soporte compatible con los Sistemas, el cumplimiento de plazos y calendarios de tratamientos y entrega de datos; la correcta transmisión de datos entre entornos diferentes.
  38. 38. AUDITORIA INFORMÁTICA DE SISTEMAS Se audita: Sistema Operativo: Verificar si la versión instalada permite el total funcionamiento del software que sobre ella se instala, si no es así determinar la causa Software de Aplicación: Determinar el uso de las aplicaciones instaladas. Comunicaciones: Verificar que el uso y el rendimiento de la red sea el más adecuado .
  39. 39. COPIAS DE SEGURIDAD Las copias pueden ser totales o parciales y la frecuencia varía dependiendo de la importancia de la información que se genere. Se recomienda tener como mínimo dos (2) respaldos de la información, uno dentro de la empresa y otro fuera de ésta (preferiblemente en un Banco en Caja Fuerte). Backup
  40. 40. NORMAS Las normas de auditoría son los requisitos mínimos de calidad relativos a la personalidad del auditor, al trabajo que desempeña ya la información que rinde como resultado de este trabajo. Las normas de auditoría se clasifican en: a. Normas personales. b. Normas de ejecución del trabajo. c. Normas de información.
  41. 41. NORMAS PERSONALES Son cualidades que el auditor debe tener para ejercer sin dolo una auditoría, basados en un sus conocimientos profesionales así como en un entrenamiento técnico, que le permita ser imparcial a la hora de dar sus sugerencias
  42. 42. NORMAS DE EJECUCIÓN DE TRABAJO Son la planificación de los métodos y procedimientos, tanto como papeles de trabajo a aplicar dentro de la auditoría. Normas de información Son el resultado que el auditor debe entregar a los interesados para que se den cuenta de su trabajo, también es conocido como informe o dictamen.
  43. 43. QUE PERMITEN LOS PROCEDIMIENTOS DE AUDITORIA .  Obtener conocimientos del control interno. Analizar las características del control interno. Verificar los resultados de control interno. Fundamentar conclusiones de la auditoría.
  44. 44. PELIGROS INFORMÁTICOS • Incendios • Inundaciones • Robos • Fraudes
  45. 45. RESPONSABILIDADES DE UN AUDITOR DE SISTEMAS 1. La redacción de los procedimientos de control en el área de seguridad lógica. 2. La aprobación de nuevos sistemas de gestión. 3. Evaluar los riesgos de los sistemas de información
  46. 46. EJEMPLO

×