Technical Writer: A proposal to improve quality and documentation in the agile methodology "Scrum"

Software development companies that choose to work with the agile Scrum methodology focus their efforts on frequent product delivery, neglecting the documentation itself of the processes involved in development. Scrum teams are made up of highly trained technicians in whom trust is placed for the development of a software solution. To support the Scrum team in documentation issues, we propose to incorporate a new actor called Technical Writer into the team, who will be in charge from the beginning of carrying the documentation that merits according to the phases of software development, which will contribute to the delivery of a final product with quality and with the respective documentation. We conclude that although the documentation is not the strength of the agile Scrum methodology, it is very necessary to deliver a quality product to its customers. Resumen. Las empresas  de  desarrollo  de  Software  que  optan  por  trabajar  con la metodología ágil como Scrum, centran sus esfuerzos en la entrega frecuente  y priorizada de productos, descuidando en gran medida la documentación que se genera en sí durante los procesos inmersos en el desarrollo de software. Normalmente, los equipos de Scrum están conformados por técnicos altamente capacitados que  se orientan completamente al desarrollo de una solución software. Para apoyar al equipo Scrum en temas de documentación y elaboración de artefactos de software, proponemos incorporar dentro del equipo a un nuevo actor que lo hemos denominado: “Technical Writer”, quien se encargará de llevar la documentación desde el principio del proceso Scrum y en las actividades donde se amerite en las fases del desarrollo del software. La propuesta apunta a que los técnicos del equipo Scrum aporten de mejor manera en la entrega de un producto final con calidad y con una adecuada documentación. Concluimos que a pesar de que la documentación no es el fuerte de la metodología ágil Scrum, es muy necesaria para entregar un producto de calidad a sus clientes

MEAC: An experience to keep the production line active in the software development process

Software development is not an easy process. Proof of this is the existence of numerous methodological proposals that have proven to be practical and efficient in a large number of projects. However, these methodologies have also presented problems in aspects of their application. To such an extent that they often need to be adapted to the realities of each project or company in order to improve the results obtained in their application. The aim of this article is to tell a real experience in a small development company in which several methodologies have been applied over the years, highlighting Scrum as the one that has brought better results. However, by applying it specifically to small projects, with few resources, limited times and changing requirements, the need to also adapt to this methodology for this type of project was born. We have called this adaptation MEAC, acronym that refers to an Empirical Method of Continuous Support whose purpose is to avoid time cuts in the generation and development of the software product, as well as to maintain the active production line of the software team active. Resumen: El desarrollo de software no es un proceso fácil. Prueba de ello, es la existencia de numerosas propuestas metodológicas que han demostrado ser prácticas y eficientes en un gran número de proyectos. No obstante, estas metodologías también han presentado problemas en aspectos de su aplicación. A tal punto que, muchas de las veces se necesitan adaptarlas a realidades propias de cada proyecto o empresa con el fin de mejorar los procesos de desarrollo de software y obtener un producto de calidad. El objetivo de este artículo es contar una experiencia real en una empresa pequeña de desarrollo en la cual se ha aplicado varias metodologías al largo de los años, destacándose Scrum como la que mejores resultados ha traído. Sin embargo, al aplicarla específicamente en proyectos pequeños, con pocos recursos, tiempos limitados y requisitos cambiantes, ha nacido la necesidad de también adaptar a esta metodología para este tipo de proyectos. A esta adaptación la hemos llamado MEAC, siglas que se refieren a un Método Empírico de Apoyo Continuo cuya finalidad es evitar cortes de tiempo en la generación y desarrollo del producto software, así como mantener activa la línea de producción activa del equipo de software

NoSQL vs. SQL in Big Data Management: An Empirical Study

When developing a software project, it is important to choose the database that best suits the needs of the project, whether it is relational or non-relational. This article compares the efficiency of two types of database in handling input and reading large amounts of data, using the SGDB MongoDB 3.2 and Microsoft SQL Server 2016. The study concludes that, in projects where the handling of a large amount of data and a rapid response are primary requirements, it is better to use a non-relational database. In contrast, if the project requires the use of relationships between entities, without giving greater importance to the response time, it is better to opt for a related database. Resumen: Al momento de desarrollar un proyecto software es importante escoger la base de datos que mejor se ajuste a las necesidades del proyecto. Las opciones de un técnico pueden estar entre una base de datos relacional o no relacional. El presente artículo compara la eficiencia de estos dos tipos de base de datos desde el punto de vista de la entrada y lectura de grandes cantidades de datos. Utilizamos a SGDB MongoDB 3.2 y Microsoft SQL Server 2016 para este estudio empírico. Concluimos que, en proyectos donde el manejo de una gran cantidad de datos y una respuesta rápida son requerimientos primordiales, y considerando estas variables, consideramos que podría ser idóneo el uso de una base de datos no relacional. En contraste, si el proyecto requiere el uso de relaciones entre entidades, sin dar mayor importancia al tiempo de respuesta, podría ser mejor optar por una base de datos relacional

The value of open-source clinical science in pandemic response: lessons from ISARIC

International audienc