H.CASE - METODOLOGIA (-PRUEBAS) Flashcards
HERRAMIENTAS CASE
Las herramientas CASE cuentan con un repositorios, el respositorio es una base de datos en la que se guardan metamodelos, guardamos de los digramas que estamos haciendo una parte semantica, que nos permite: hacer ingenieria inversa, directa, para hacer coherencia entre modelos.
Herramientas que nos ayudan al desarrollo de software. Fundamentemente en las fases de analisis y diseño (Futuro (construcción) ≡ MDA).
Clasificación de herramientas CASE:
- Upper U-CASE: Se ocupan de la fase de Analisis de requisitos y planificación.
- Middle M-CASE; Analisis y diseño. Diagramas de clase, paquetes…
- Lower L-CASE; Generación de código, deputación y pruebas (Orientadas a RAD “desarrollo rapido de aplicaciones”)
Entornos i-CASE (lenguaje XMI de XML)→ Varios CASE integrados que cubren todo el ciclo de desarrollo.
EJEMPLOS DE HERRAMIENTAS
- Modelo E/R → E/R studio, ERWin
- Modelado de Requisitos → DOORS, RequisitePro
- Modelo UML → Entreprise Architect, Rational Rose, ArgoUML, StrarUML, (Visio NO)
- Modelado DFD → Visible Analyst
- Visio no es una herramienta CASE por que no guarda nada de semantica, es una herramienta de dibujo.
CONTROL DE VERSIONES
Centralizados: Un servidor donde todos los desarrolladores trabajan contra un servidor centralizado.
Herramientas: CVS, Subversion (SVN) tiene un cliente que se llama TortoiseSVN, TFS (reeembrado a Azure DevOps Server)/SourceSafe. SourceSale
Distribuidos: En programación informática, el control de versiones distribuido permite a muchos desarrolladores de software trabajar en un proyecto común sin necesidad de compartir una misma red. Las revisiones son almacenadas en un sistema de control de versiones distribuido. Hay dos niveles de respositorio, uno local de cada desarrollador y uno centralizado.
Git, Mercurial (es una simplificación de las funcionalidades de Git), Bazaar, Dares, Bitkeeper.
GIT: Creado por Linus Torvalds para el desarrollo del kernel de Linux
- Distrubido: la mayor parte del trabajo se hace en local.
- Soporte avanzado de ramas y mezclas.
- Protocolos: Local, Compatible con HTTP(s) y SSH. Y el propio protocolo GIT
- Uso de criptografia (SHA-1 sobre object): HASH
- Tree
- Blob (≈ file). Es la manera de hacer un hash a los ficheros.
- Commit (Un commit apunta a un tree, y un tree apunta a otros tree o a un blob).
- Tag (un tag apunta a un commit)
FASES DE GIT:
Fase 1: “Working Directory”: Aquí es donde podemos hacer cualquier cambio y no afectar nuestro repositorio en lo absoluto. En cuanto modificamos algo de nuestro código, éste tiene status de modificado.
Fase 2: “Staging Area”: Aquí es donde le podemos dar nombre a nuestra nueva versión. Y crear una “copia” de cómo quedaría nuestro repositorio en producción.
Para pasar nuestro código de staging area al Git Repository (aun no se publica el código en Github), escribimos el siguiente comando: git commit -m “Nombre del la nueva versión”
Nota que cuando haces el commit el código pasa de estado preparado a confirmado.
Fase 3. “Git repository”: Una vez que el código esta confirmado ya esta listo para sincronizarse con el servidor de Git (github, bitbucket,etc). Para hacer esto, escribimos:
git push -u origin master
PLATAFORMAS COLABORATIVAS DEL SOFTWARE
-
Concepto de Forja (forge) → Concepto de Foss (Free and Open Source Soffware). Es basicamente repositorios donde ponde proyectos de forma publica.
- Source Forge
- GForge
- Github (Flujos colaborativos Fork y Pull Request)
Flujos colaborativos Fork y Pull Request: Son utilizados para proponer cambios al proyecto de alguien más ó usarlos como punto inicial para desarrollar nuestra propia idea.
Por ejemplo, si queremos desarrollar una nueva funcionalidad o corregir un bug, lo que hacemos es:
- Hacer un fork al repositorio principal (es decir, creamos una copia en la nube) - Trabajamos sobre nuestra copia de repositorio
Una vez listo nuestro fix o desarrollo, creamos un pull request desde nuestro fork al proyecto principal.
PLATAFORMAS COLABORATIVAS DEL SOFTWARE
- Source Forge
- GForge
- Github (Flujos colaborativos Fork y Pull Request)
- Gitlab
- Bitcucket
- Redmine
- Google Code
- forga (Se usa CTT en la administración) -> Para aquellas soluciones del CTT que desean construir una comunidad de desarrollo alrededor de su proyecto software libre, se ha creado la organization -ctt forge within a large public collaborative environment GITHUB
Herramientas de integración continua (CI/CD):
Integración Continua (CI, Continuous Integration): La integración Continua (CI) permite que los diferentes desarrolladores suban y fusionen los cambios del código en una misma rama del repositorio de forma frecuente. Una vez subido el código, se procede a su validación de forma automática mediante pruebas unitarias y de integración (tanto el código subido como del resto de componentes de la aplicación). En caso de que se produzca algún error, este se puede corregir de forma más sencilla.
Distribución Continua (CD, Continuous Delivery): El código nuevo introducido y que ha pasado el proceso de Integración continua se publica automáticamente en un entorno de producción (esta implementación puede requerir la aprobación manual).
Herramientas de integración continua (CI/CD):
- Jenkins
- Travis CI
- Circle CI
- TeamCity
- Code Ship
- Bamboo
PLATAFORMAS DE DESPLIEGUE:
- IaaS (Infrastructure as a Service)
- SaaS (Software as a Service)
- PaaS (Platform as a Service)
- FaaS (Functions as a Service)
- CaaS (Container as a Service)
PLATAFORMAS DE DESPLIEGUE:
IaaS (Infrastructure as a Service): IaaS es Infrastructure as a Service, la Infraestructura como Servicio.
SaaS (Software as a Service): Sin duda, es el servicio más utilizado por usuarios individuales. El SaaS, o Software as a Service, es también conocido como software bajo demanda, o software out-of-the-box.
PaaS (Platform as a Service): PaaS son las siglas de Plataforma como Servicio, que proporciona una plataforma y un entorno que permiten a los desarrolladores crear aplicaciones y servicios.
FaaS (Functions as a Service): FaaS, o Funciones como Servicio, se conoce como serverless architecture. Por serverless se entiende que los servidores se utilizan como un elemento más de la infraestructura gracias a las ventajas de la computación en la Nube —y no significa «sin servidor», como podría suponerse
CaaS (Container as a Service): El Contenedor como Servicio se encuentra en un punto intermedio entre el IaaS y el PaaS. Se trata de una forma de virtualización basada en contenedores en la que los motores de contenedores, la orquestación y los recursos informáticos subyacentes se entregan a los usuarios como un servicio de un proveedor en la Nube.
Plataformas de despliegue:
IaaS (Infraestructura)
- Digital Ocean
- OpenStack
- Azure
- Amazon Web Service (AWS)
- VCloud
PaaS (Plataforma)
- Heroku
- OpenShift
- Google App Engine
SaaS (Software)
- Office 365 Outlook
- Gmail, Skype
FaaS (Funciones)
CaaS (Contenedor)
- OpenStack Magnum
- Docker Universal Control Plane.
METODOLOGÍAS DE DESARROLLO
ESTRUCTURAS (ORIENTADAS A PROCESOS)
- SSADM
- MERISE
- METRICA3: Creada por la administración pública para homogeneizar. Se concibe como una metodología de planificación, desarrollo y mantenimiento de sistema de información. Metrica2 tecnologia estructurada, Metrica3 es una tecnología hibrida tiene una parte estructurada y una parte orientada a objetos.
ORIENTAS A OBJETOS: RUP (Iterativo Increm.)-> OPEN UP
- PROCESO UNIFICADO ABIERTO (OPEN UP): Proceso mínimo y suficiente. Tiene los componentes básicos que pueden servir de base a procesos especificios. Donado por la fundación Eclipse → Licencia libre.
- PROCESO UNIFICADO AGIL (AUP): V_ersión simplificada del Proceso Unificado de Rational (RUP)_. Describe de manera sencilla la forma de desarrollar aplicaciones con tecnologías ágiles.
METODOLOGÍAS AGILES: Permiten adaptar la forma de trabajo a las condiciones del proyecto. Flexibilidad e inmediated de respuesta.
- XP (Programación Extrema).
- SCRUM.
- FDD: Desarrollo basado en funcionalidades.
- TDD: Desarrollo orientado a pruebas.
- BDD: Desarrollo guiado por el comportamiento.
- KARBAN: Pizarra de tareas.
MANIFIESTO AGIL (12 Principios).
- Satisfacer al cliente → Entrega temprana y continua.
- Bienvenidos a los requisitos cambiantes.
- Entregar con frecuencia sw que funcione.
- Personas del negocio y desarrolladores deben trabajar juntos.
- Contrucción de proyectos entorno a invidividuos motivados.
- Conversación cara a cara: Forma mas eficiente de comunicación ida y vuelta.
- Sw que funcione es la primera medida del progreso.
- Los procesos agiles promueven el desarrollo sostenido. Patrocinadores, desarrolladores y usuarios deben mantener el ritmo contante de forma indefinica.
- Atención continua a la excelencia técnica.
- Simplicidad como arte de maximizar la cantidad de trabajo que se hace.
- Las mejores aquitecturas, requisitos y diseños vienen de equipos que se autorganizan.
- En intervalos reguares: Los equipos reflexionan sobre la forma de ser más eficientes.
METRICA V3: Metolologia para el desarrollo y mantenimiento de los sistemas de información.
Desarrollada por el MINISTERIO DE HACIENDA Y ADMINISTRACIONES PUBLICAS. De uso libre cuando se cite a la fuente de la propiedad.
OBJETIVOS:
- Dotar a la organización de productos sw.
- Mejorar productividad de los departamentos de sistemas y tecnologías de información y las comunicaciones.
- Facilitar la operación, mantenimiento y uso del sw.
FASES DE METRICA V3.
PLANIFICACIÓN DE SISTEMAS DE INFORMCIÓN.
DESARROLLO DEL SISTEMA DE INFORMACIÓN.
- ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS)
- ANALSIS DEL SISTEMA DE INFORMACIÓN (ASI).
- DISEÑO DE SISTEMAS DE INFORMACIÓN (DSI).
- CONSTRUCCIÓN DE SISTEMAS DE INFORMAC. (CSI)
- IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA (IAS).
MANTENIMIENTO DEL SISTEMA DE INFORMACIÓN
Métrica 3 incluye un conjunto de procesos que definen una serie de actividades de interfaz con otros procesos organizativos o de soporte.
- Gestión de proyectos:
- Seguridad.
- Gestión de configuración.
- Aseguramiento de la calidad.
PRUEBAS DE METRICA V3.:
ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI)
- Actividad ASI 10: Especificación del Plan de Pruebas
DISEÑO DEL SISTEMA DE INFORMACIÓN (DSI)
- Actividad DSI 10: Especificación Técnica del Plan de Pruebas
CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN (CSI)
- Actividad CSI 3: Ejecución de las Pruebas Unitarias
- Actividad CSI 4: Ejecución de las Pruebas de Integración
- Actividad CSI 5: Ejecución de las Pruebas del Sistema
IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA (IAS)
- Actividad IAS 5: Pruebas de Implantación del Sistema
- Actividad IAS 6: Pruebas de Aceptación del Sistema
SCRUM: Iterativo incremental
ROLES DE SCRUM
Cerdos:
- Product Owner: Representa la voz del cliente ≈ Director del proyecto
- Scrum master (O facilitador): Hace que SCRUM se cumpla
- Scrum Team (desarrolladores): [5-9] personas con habilidades transversales
Gallina: Stakeholder (interesados externos o internos) / Usuarios - Participan en las revisiones de los distintos Sprint (en los Sprint review).
EVENTOS EN SCRUM
SPRINT: Es un periodo de tiempo de un mes ± durante el cual se crea un incremento del producto “terminado utilizable y potencialmente desplegable. Los sprints contienen y consisten en:
- Plaificación del sprint → SPRINT PLANNING.
- Scrum diarios → DAILY SCRUM.
- Trabajo de desarrollo.
- Revisión del sprint → SPRINT REVIEW.
- Retrospectiva → SPRINT RETROSPECTIVE.
ARTEFACTOS DE SCRUM.
Cada artefacto contiene un compromiso para garantizar que proporcione información que mejore la transparencia y el enfoque frente al cual se puede medir el progreso.
- Para el producto Backlog → El objetivo del producto.
- Para el sprint backlog → El objetivo del sprint.
- Para el increment → La definición de terminado
BURN DOWN CHART: Grafica que mide la cantidad de requisitos en el backlog de proyecto pendiente al comienzo de cada sprint.
XP (Extreme Programming)
- Programación en parejas.
- Desarrollo iterativo incremental. Integración continua.
- Pruebas unitarias continuas. Se aconseja escribir el código de pruebas antes que la codificación ≈ TDD.
- Los técnicos estiman el esfuerzo del desarrollo y el cliete prioriza (se recomienda que un representante del cliente trabaje con el equipo de desarrollo). Clientes in-situ.
- Refactorización de código.
- Entregas pequeñas
- Propiedad de código compartida.
- 40 horas / semana.
XP (Extreme Programming). Roles:
Programador – Programmer: Es el programador considerado el más importante miembro del equipo ya que escribe las pruebas unitarias y el código del sistema.
Cliente – Customer: También llamado cliente es quien escribe las historias de usuario y las pruebas funcionales para validar su implementación. Asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar el mayor valor de negocio
Tester (Encargado de las pruebas): Ayuda al cliente a escribir las pruebas funcionales. Ejecuta pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.
Tracker (Es el encargado de seguimiento). Proporciona retroalimentación al equipo.
Entrenador - Coach: Es responsable del proceso global y se encarga de guiar a los miembros del equipo para seguir el proceso correctamente.
Consultor: Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto ayuda al equipo a resolver un problema específico y puede que no siempre haya un consultor como parte del equipo.
Manager (Gestor – Big Boss): Se encarga de agendar las reuniones, se asegura de que el proceso de juntas sea seguido, registra los resultados de las reuniones para futuros reportes para el Tracker. Asiste a las reuniones y trae información importante, mantiene al equipo feliz y productivo.
INTEGRACION CONTINUA
Practica de ingerieria del sw que consiste en hacer integraciones automáticas de un proyecto lo mas a menudo posible para así poder detectar los fallos cuento antes. Entendemos por integración la compilación y pruebas de todo un proyecto.
Persigue la automatización, pero ademas automatización coorporativa. Hay unas reglas de calidad y de desarrollo para todos los equipos igual. Cuanto antes hay que subir a producción.
En la empresa necesitamos un sw que orqueste esa automatización.
INTEGRACION CONTINUA.
HERRAMIENTAS:
- JAVA es JENKINS (maven)
- TRAVIS: Crea y probar proyecto de SW en Github y BitBucker.
- CIRCLE.
- TEAMCITY.
- BAMBOO.
- CODESHIP
La diferencia entre usar un producto CD (Entrega continua) y CI (Integración continua), es que en un producto de *integración continua* se hace solo hasta los test no se llega hacer el deploy, si se desplega estamos hablado de entrega continua.
METODOLOGIAS DE DESARROLLO – PRUEBAS
Existen varias clasificaciones. CLASIFICACIÓN A:
CAJA BLANCA: Solo conoce el detalle del algortimo.
- Pruebas de flujo de control.
- Pruebas de flujo de datos.
- Pruebas de bifurcación.
- Caminos basicos.
CAJA NEGRA: Solo nos interesan las entradas y salidas. Interface
- Enfocada en las entradas y salidas y no en el código fuente → Pruebo las distintas entradas y salidas.
METODOLOGIAS DE DESARROLLO – PRUEBAS
Existen varias clasificaciones. CLASIFICACIÓN B:
FUNCIONALES:
- Unitarias: De cada componente.
- Integración: Varios componentes trabajando juntos / Subsitemas.
- Aceptación: Orientadas al usuario desde punto de vista funcional. Simula que eres un usuario (pruenas funcionales). Ej: Que un usuario rellenara una factura.
- Regresión: Ante un cambio debemos volver a realizar las pruebas para ver que todo sigue funcionando.
- Alpha: Por el usuario con el desarrollador como observador, en entorno controlado.
- Beta: Por el usuario, en su entorno de trabajo sin observadores.
NO FUNCIONALES:
- Compatibilidad
- Rendimiento
- Seguridad
- Usabilidad
- …
HERRAMIENTAS - PRUEBAS:
Aceptación: Selenium, SOPA-UI, Watir (Ruby), WatuN(.Net)
Unitarias: Junit, Nunit, TEstNG, PHPUnit
- Mockito: Es una librería se usa alrededor de la pieza que quiero probar de forma aislada, si tengo toda la aplicación la capa de negocio usa la capa de datos, para engañar y poder probar la capa de negocio sin la de datos, utilizamos herramientas como Mockito (Utiliza los datos de prueba de forma que no usemos la capa de datos).
- Para hecer test de javascript: Mocha, Jasmine y Jest
Carga: JMeter, HPLoadRunner, LoadUI
Analisis Código estatico: PMD, Checkstyle y FindBugs
HERRAMIENTAS - PRUEBAS:
Aceptación: Selenium, SOPA-UI, Watir (Ruby), WatuN(.Net)
Unitarias: Junit, Nunit, TEstNG, PHPUnit
- Mockito: Es una librería que u__tiliza los datos de prueba de forma que no usemos la capa de datos).
- Para hecer test de javascript: Mocha, Jasmine y Jest
Carga: JMeter, HPLoadRunner, LoadUI
Analisis Código estatico: PMD, Checkstyle y FindBugs
PRUEBAS - METODOLOGÍA MÉTRICA3
Las pruebas son prácticas a realizar en diversos momentos de la vida del sistema de información para verificar:
- El correcto funcionamiento de los componentes del sistema.
- El correcto ensamblaje entre los distintos componentes.
- El funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica.
- El funcionamiento correcto del sistema integrado de hardware y software en el entorno de operación.
- Que el sistema cumple con el funcionamiento esperado y permite al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento.
- Que los cambios sobre un componente de un sistema de información, no introducen un comportamiento no deseado o errores adicionales en otros componentes no modificados.
PRUEBAS - METODOLOGÍA MÉTRICA3
Los tipos de pruebas que deben realizarse son:
- Pruebas Unitarias.
- Pruebas de Integración.
- Pruebas del Sistema.
- Pruebas de Implantación.
- Pruebas de Aceptación.
- Pruebas de Regresión.
PRUEBAS - METODOLOGÍA MÉTRICA3
PRUEBAS UNITARIAS: Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado.
Descripción: Las pruebas unitarias constituyen la prueba inicial de un sistema y las demás pruebas deben apoyarse sobre ellas.
Dos enfoques:
- Enfoque estructural o de caja blanca.
- Enfoque funcional o de caja negra
PRUEBAS - METODOLOGÍA MÉTRICA3
PRUEBAS DE INTEGRACIÓN: El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes.
Descripción: En las pruebas de integración se examinan las interfaces entre grupos de componentes o subsistemas para asegurar que son llamados cuando es necesario y que los datos o mensajes que se transmiten son los requeridos.
Se distinguen las siguientes estrategias de integración:
- De arriba abajo (top-down).
- De abajo arriba (bottom-up).
- Estrategias combinadas.
Integración no incremental.
PRUEBAS - METODOLOGÍA MÉTRICA3
PRUEBAS DEL SISTEMA
Descripción: Una vez que se han probado los componentes individuales y se han integrado, se prueba el sistema de forma global. En esta etapa pueden distinguirse los siguientes tipos de pruebas, cada uno con un objetivo claramente diferenciado:
- Pruebas funcionales. .
- Pruebas de comunicaciones.
- Pruebas de rendimiento.
- Pruebas de volumen.
- Pruebas de sobrecarga.
- Pruebas de disponibilidad de datos.
- Pruebas de facilidad de uso.
- Pruebas de operación.
- Pruebas de entorno.
- Pruebas de seguridad.
PRUEBAS - METODOLOGÍA MÉTRICA3
PRUEBAS DE IMPLANTACIÓN
Descripción: Una vez que hayan sido realizadas las pruebas del sistema en el entorno de desarrollo, se llevan a cabo las verificaciones necesarias para asegurar que el sistema funcionará correctamente en el entorno de operación. Debe comprobarse que responde satisfactoriamente a los requisitos de rendimiento, seguridad, operación y coexistencia con el resto de los sistemas de la instalación para conseguir la aceptación del usuario de operación.
