17537992
Description
Flashcards by HardSoft Security, updated more than 1 year ago
|
Created by HardSoft Security
about 5 years ago
|
|
| Question | Answer |
| 1. Nube Legal. Fulgencio conocía a los miembros del órgano rector del colegio de abogados de Murcia y Alicante. Sugirió analizar la aplicación que tenían en funcionamiento. Actualización del software en producción a la nube, SaaS cloud. Por recelo de los datos, información sensible -> solución. | 2. Fases del proyecto. - Política de entrevistas. - Fase de entrevistas: entrevistas iniciales, entrevistas de desarrollo, entrevistas finales. |
| 2.1 Fases del proyecto. - En la fase de entrevistas iniciales, análisis actual del software en producción. - Enfoques: * Corregir el software: Actualizar a win10 todos los equipos y renovar licencias software. Análisis del software actual y reparación de errores (comenta errores y problema de seguridad de los datos). * Crear el proyecto desde cero: Modelado y adaptación de los datos + requisitos del sistema. | 3. Entrevista con el diagnóstico. - Comunicar al cliente los problemas: Problemas comentados en la anterior diapositiva. - Dar alternativas para solucionar los problemas: * Crear un proyecto desde cero, incluye aplicación y base de datos. * Modificar su software en producción (no, era software de pago). - Toma de una decisión: En este punto se le sugiere al cliente, que la mejor opción es iniciar un proyecto nuevo y migrar los datos. |
| 4. Solución propuesta. - Ventajas de hacer nueva la BD. * No habrá datos mal tipados. * Se aprovechará la potencia de las relaciones. * Se implementa métodos para que la propia base de datos funcione de casi autónoma. * Será modularizada para un mejor mantenimiento a largo plazo. | 4.1 Solución propuesta. - Requisitos funcionales * Se nos pidió cubrir todo lo que hacia la aplicación anterior. * También se nos pidió un módulo para la facturación. * Se nos pidió un módulo de agenda. - Planificación de entrevistas con el cliente. * Se plantea unas reuniones periódicas de cada 15 días para ir presentando resultados y avances. |
| 5. Objetivos de la solución. - Objetivos generales: * Diseñar una aplicación para facilitar la administración de un bufete de abogados. * Detectar y solucionar algunas carencias del software ya existente para este sector. * Desarrollar una interfaz minimalista e intuitiva. * Diseñar una base de datos para organizar y almacenar la información. * Desarrollar utilizando un lenguaje orientado a objetos como... | 5.1 Objetivos de la solución. - Objetivos específicos: * Poder trabajar de manera simultánea en la base de datos, la interfaz del usuario y el diseño de la interfaz. * Análisis de requisitos de la aplicación. (servidor) * Instalación y configuración de un servidor. (comentar los servicios.) * Utilizar lenguajes de programación más actuales y punteros. |
| 6. Herramientas utilizadas de la solución. - Mysql: Mucha comunidad, documentación, posibilidad de comprar una licencia. - PhpMyAmdin: Interfaz intuitiva, curva de aprendizaje rápida, editor para procedimientos y consultas. - Dia: solución liviana para hacer diagramas de todo tipo, exporta a una imagen vectorial. - Laravel: - Bootstrap: | 7. Análisis BBDD producción. - Atributos multivaluados: DNI, no se guardaba el numero y letra por separado, se guardaba más de uno por campo. - Atributos mal tipificados: Todo se guardaba como varchar. - Tablas mal estructuradas. - Duplicidad de los datos: Tablas duplicadas exactamente iguales, mismos datos. - Sin restricciones de clave ajena: Tablas sin relacionar, se controlaba en el software. * Conclusión: Base de datos incosistente. |
| 8. Desarrollo de la BBDD. - Ingeniería inversa (sacar la base de datos). - Reingeniería (volver a crear bien la BD). - Se dividió la nueva base de datos en módulos, así obtendremos: fácil mantenimiento, mejor integración para la inserción y consulta de datos. | 9. Base de datos antigua. - Cómo se almacenan los distintos tipos de clientes. - Se denota atributos mal tipados. - Se almacena más de un teléfono por tupla. - Se denota ambigüedad en el diseño. |
| 10. Trigger. Mantener la cuantía personal de la tabla expedientes de manera automática. Mantenemos la consistencia de la tabla de expedientes al mantener un atributo calculado automáticamente. | 11. Procedimiento. Realiza el vaciado de la tabla de JuzgadosOrganos, nos hizo falta debido a un error específico. |
| 12. Función. Esta función facilita la consulta de los NIE de los clientes. | 13. Migración de la base de datos. script python -> que generaba archivos CSV, para posteriormente procesarlos e insertarlos en la nueva base de datos. |
| 14. Seguridad - Desconfianza en la nube. | 15. Arquitectura. Arquitectura clásica de tres capas, persistencia (BBDD), modelo de negocio (Programación) y vista (interfaz). Facilidad de dividir el trabajo para el grupo de colaboradores, ventajas a la hora de mantenimiento, reemplazo y actualización de las mismas e incluso de la aplicación. |
| 16. Política de usuarios. - Administrador concede acceso a todo el sistema tanto de consulta como de modificación. - Abogado, no pueden acceder a la parte de administración, ni logs de control, pero tenían control total sobre todos los módulos relacionados con los expedientes. - Secretario, este tipo de usuario solo pueden acceder y consultar los expedientes de su abogado asignado y modificar aquellos a los que su abogado le ha concedido permisos. | 17. Interfaces de usuario. HTML5, CSS y el framework BOOTSTRAP. BOOTSTRAP -> Facilidad de hacerlo responsive. Se hicieron diferentes interfaces, móvil, tablets y para ordenadores. |
Want to create your own Flashcards for free with GoConqr? Learn more.