Project Delivery 3

Alan Ricardo González Aguilar A01633872

Carlos Ernesto López Solano A01633683

Luis Eduardo Núñez Altamirano A01633894

Team: Beaver River

Project: Scheduling Management System (SMS) for the EIAD

Design based on the interviews and client requirements

As mentioned in the first delivery of our project, our goal is to improve for once and for all a very inefficient system used to do reservations of classrooms and/or equipment of one of the buildings of our campus. Therefore, from the start we had the goal of designing an efficient, reliable and friendly system of reservations that followed the next purpose: can be used by anyone anywhere on the campus at anytime they would want to do a reservation.

Due to the ease of use and flexibility of web technologies, it seemed that it could be a good idea to take advantage of this set of technologies to create a web app or web page and mount it on a server located inside the campus. We concluded that the best option would be to use HTML and CSS to bring structure and style to the tool and a JavaScript framework to develop the core functionality (we choose Vue.js because of its power and ease of use, as well as the clear documentation it includes).

We designed a simple and efficient user interface, with the power to automate many processes that could take a human a lot of time, and validate most of the inputs entered by the user. It should implement API’s for calendar use and a database implementation to manage the data of the reservations and the users.

For the calendar API we choose Google Calendar for the simple functionality and implementation, and for the database we choose Firebase based on the expected bandwidth use and the simple implementation process.

Based on the interviews and requirements of the client, we decided the tool should have 4 types of user, each with its own permits and displayable views in the app:

• Student
  • Regular student who wants to make a reservation, which could include seats of a classroom as well as equipment (on-site or storaged)
• Professor
  • Professor who wants to rent the whole classroom (and maybe all the equipment too) for a class, conference, crash course, etcetera.
• Security
  • Member of the security department who, at certain times,  needs to check who is inside of the classrooms, and to make sure the reservations are being respected
• Administrator
  • Administrator(s) of the classrooms and equipment of the building. Can add devices and classrooms, as well as remove them, and check the reservation forms made by other users in order to accept them or deny them

The permits and available functions for each user are shown in the Use case located later on this document.

The app manages the functionality of all the users while dividing into different “views” or sections. Some views are available for all users while other are only accessible with valid credentials.

Here are our designs for the different views the tool would have:

index.html

The main page of the application would include a view of the existing reservations in any of the classrooms of the building. The element would show the details of the classroom, the name and ID number of the person who did the reservation, and of the other team members (if necessary), the daytime of the reservation, the reserved equipment from the lab (static equipment such as PC’s or racks, or carry-on equipment such as cables or electronic devices), and the observations or comments about the reservation made by the person who reserved.

This page would be visible for the Student, Professor, Security and Administrator users.

newreservation.html

This view is generated from the index.html when a user wishes to do a new reservation.

The user should indicate all the information shown in screen, such as the desired classroom, name and email of the person who is reserving, the daytime of the reservation, which equipment is going to be used, observations or comments, and team members.

To finish the process of reservation, the user needs to send the form to the Administrator with the button at the bottom of the page. Later on, the Administrator would review the form and accept it or deny it. 

The notifications involving the requested reservation will reach the user and the Administrator by email.

login.html

The login page would be visible from the main page for the Student, Professor, Security and Administrator users, but only the Administrator user would have credentials so it would be the only user with the possibility to use and access the login interface. 

Through this page the Administrator would be able to access the Administrator dashboard of the application.

administrador.html

The application dashboard, as said earlier, would only be available for the Administrator and would need credentials in order to access it.

It would include three sections:

1. Reservations review

Here the Administrator can access and review the reservations made by other users in order to accept it or deny it. The Administrator can write observations and comments as well as restrict the use of some equipment.

Also, in this view the Administrator could check the accepted reservations to check for availability

2. Classrooms and equipment management

This section would be destined to manage the existent classrooms as well as the equipment stored in them. The Administrator would be able to:

3. Add equipment
4. Remove equipment

3. Add a classroom

3. Remove a classroom

Each operation would have a specific button to display the corresponding menu in the actual view. The Administrator would be able to return to the dashboard at anytime.

3. Manage users and classes

In this section, the Administrator could register another person as a new Administrator, and add or remove classes that could interfere with the schedule of the classrooms.

1. There is no limit for the number of existing Administrators, but for based on the requirements of the client we know for sure there won’t be a lot of them
2. The process starts in this section when an active Administrator generates a link where the new Administrator would register
3. The new Administrator has to enter a username as well as a password.
4. After the registration process, the new Administrator would be able to access the Administrator dashboard

As described earlier in this document, the tool would be mounted on a local server on the campus. This would make it easier for the students and professors to make or check reservations of the many classrooms in the building.

What did you learn about the process of design in this course/project?

We discover that it is very important to have a design process before starting to code. Usually when someone asks us to create a new project, the first thing we think about is code. There are many tools that help us to design everything that we need, the diagrams,  the cycles of life, design patterns, etc. It is very important to have a previous planning, and this will help us to create a better software and a successful project.  

Use cases

Class Diagrams

Link to video: https://www.loom.com/share/9220445c0520411f9fa0f9fe7d081762

Vídeo: https://www.loom.com/share/e3265afdfd3643a7a692c29575575e6f (Son 10 minutos así que recomiendo mucho ponerlo en x1.5)

Sabemos que es testing y OO pero y si los juntamos?

Solo por si alguien no llega tener una idea al 100% de testing o que significa OO es sencillo:

• Testing, como su traducción dice, es el hacer pruebas en tu software producto, de modo que intentemos romper todo lo que podamos al punto que el programa simplemente deje de funcionar. No es solo a lo loco experimentar si no que también debemos llevar ciertas metodologías, las cuales ya hable un poco de ellas en blogs pasados.
• OO (Object Oriented) es la programación que se orienta a objetos, es un paradigma extremadamente popular al punto que varios de los lenguajes de programación mas usados son siguen este paradigma, del que creo no he hablado con anterioridad pero lo haré próximamente.

The 10 most popular programming languages

Entonces cambia o no la cosa?

Para mi gran sorpresa las metodologías si cambian, la principal razón de sus cambios son por el paradigma, recordemos que la programación orientada a objetos genera instancias de clases y sumado con la herencia esto puede generar muchos mas problemas que sin el uso de OO. Esto hace que las pruebas deban tener unas ciertas características:

• Siempre se debe especificar la clase que se probara, SIEMPRE.
• El propósito del test jamas debe ser omitido para evitar confusiones en herencias.
• Las condiciones externas a los casos deben ser bien descritas para tomarlas a consideración.
• Siempre los estados de los objetos deben ser especificados ya que muchas veces los estados cambian de un objeto por ende también su comportamiento.
• Deben haber instrucciones para conducir correctamente las pruebas en cada caso.

También hay diferentes escenarios para el testeo como por error o por escenario, pero como nunca he testeado de manera profesional creo lo mas recomendable es revisar esta pagina lo describe de una manera muy profesional y comprensible.

Los niveles de testeo

Para cerrar quisiera hablar de los tres niveles de testing existentes:

• Clase: Es el testeo por unidad, cada clase se prueba en búsqueda de bugs, sirve para asegurarse que los atributos de las clases se implementaron acorde al diseño y especificaciones.
• Inter-Clase: Es un testeo de integración, revisa si el funcionamiento de varias clases a la vez es correcto.
• System: Se prueba todo el sistema o software, de esta manera se asemeja mas al uso real y se pueden encontrar bugs de una manera mas cercana a la experiencia de usuario.

Para un poco mas de información entra a esta página.

Finalmente si te gustaría estudia un poco mas encontré estos slides que son muy buenos para estudiar si tienes un examen de este tema.

Project Delivery 2

Luis Eduardo Núñez Altamirano A01633894

Carlos Ernesto López Solano A01633683

Alan Ricardo González Aguilar A01633872

Team: Beaver River

Project: Scheduling Management System (SMS) for the EIAD

• What did you learn about the project with these interviews?

We learn the requirements of the project. In the interviews we discuss with Diego and Alejandro about what is exactly what they want, and they explained to us the way you can schedule the laboratories, and why it’s not efficient. 

• What did you learn about the process of interviewing?

To ask the right questions. Sometimes as we interview we tend to focus on the bigger things or the abstract necessities of the stakeholders, but we forget about the little details (that matter the most) and the specifications that the stakeholders may have forgotten to take in account. Also, we as developers need to take in consideration that the stakeholders may not know (which is the usual) the whole process of creating the final product and what it could take to achieve it (in terms of difficulty, complexity, resources, among others), and hence they won’t get too technical with the details leaving too much room for error and ambiguity. In other words, they might as well tell us (the developers) “I want to have X on my project” but won’t know how much work, resources and time is needed to accomplish it.

Because of this, we need to excel in the design and planning stages to be aware of the technical details required to accomplish the feats of the project, and to ask the stakeholders if it’s possible to designate such resources to the process.

• If you did more than one interview, how did you change for the other interview(s)?

At the moment, we have not do any more interviews. Mainly because the first one gave us all the information that we need for the moment, and also because we have a lot of freedom with the design, limits and validation of the project, hence we think we can ask the needed questions as we work.

• If you did another interview now, what would you change about the process?

We would focus more to the software limitations and validation requirements, because that is the most time consuming part of the interview and the most important part of the whole project

• What do your use cases look like now? Did you have to remove some, change some, add some?

At the moment, they didn’t have to change at all. 

If you have any work on class diagrams or database ER diagrams, include those as well.

At the moment, we do not have any.

Según mi amigo Wikipedia: La verificación y validación son procesos independientes usados para, en conjunto, revisar si un producto, servicio o sistema tiene los requerimientos y especificaciones para asegurarse que logra su objetivo.

Verificación y validación

Lo mas sencillo para poder entender que es uno y el otro es listar lo que cada uno hace, esta lista es tomada de la siguiente pagina, comenzando con la verificación:

• Revisar documentos, diseño, código y programar.
• Nunca haces una ejecución de código.
• Utiliza métodos de verificación, revisiones, inspecciones, chequeo rápido, etc.
• Revisa si el código esta hecho según sus especificaciones
• Encuentra bugs en la parte temprana del ciclo de desarrollo.
• El objetivo siempre es la arquitectura, diseño, alto nivel, etc.
• Un equipo se dedica completamente a asegurarse de los requerimientos del software.
• Viene antes de la validación.

La validación:

• Es dinámico ya que se basa en pruebas y validación del producto actual.
• Siempre debe ejecutar código.
• Usa múltiples métodos de pruebas.
• Revisa si cumple con todos los requerimientos.
• Encuentra bugs que el procedimiento de verificación no encuentra.
• Su objetivo es el producto actual.
• El equipo de testeo esta en la mayoría del proceso.
• Viene después de la verificación.

Ya sabes que hace, a lo que sigue

Realmente si entiendes lo anterior tienes una gran idea de la parte de teórica de estos procesos, ahora bien para el uso de verificación y validación depende en si mucho de cada empresa. Hay empresas que hacen mucho énfasis en la verificación pero por lo general el mayor énfasis es en la validación, es mas sencillo es encontrar bugs una vez esta terminado o en proceso el producto a antes de crearlo ya que esto requeriría de mucha experiencia o una comprensión completa sobre el proyecto, el problema viene a que es mas costoso arreglar bugs después de que salieron. Lo mas inteligente es conocer las buenas metodologías para la parte de validación que es la creación y chequeo de tu “plan” de trabajo, para esto te recomiendo las siguientes fuentes de información:

• Más acerca de verificación y validación: What is Verification And Validation In Software Testing
• Pasar diseño a código: De mi diseño al código
• Revisión de código: Revisión de código, de vuelta a las calificaciones

Project Delivery 1

Luis Eduardo Núñez Altamirano A01633894

Carlos Ernesto López Solano A01633683

Alan Ricardo González Aguilar A01633872

Team: Beaver River

Project: Scheduling Management System (SMS) for the EIAD

Stakeholders:

• Diego Ávalos de la Torre
• Alejandro Gallegos

Use cases first attempt.

A general description of the problem that this system will attempt to solve.

When a student has projects or activities which need a laboratory or room, or the equipment in it, the process to book the laboratories and/or the equipment is very complicated. It is a real problem to fill the form and print it correctly because of the many mistakes one can make, and if you did something wrong you have to repeat the process from scratch.

Once you have the form filled correctly, the next step is to go find the person in charge (Diego or Alejandro Gallegos) and give them the printed form, but most of the time they are busy in class or with other activities, so it’s difficult and time wasting for the student to find them and for the administrators to give authorization to all the forms at all times. This is a stressful and very inefficient system, and we must improve it.

The idea of our project is to simplify the process by using a management software which will validate the entries of the user and help the administrator authorize them in a quicker manner. It will work with four different users:

• Administrator
• Guard
• Administrative
• Student

With this new tool, the student or administrative will be able to select the time that (s)he wants to book the laboratory and if it’s available, as well as the equipment to use, and the form will be automatically send to the administrator who will authorize or denegate the request. Also, the guard will be able to check the bookings and see full log of who has used the lab and who should be able to use in the future.

En mi opinión y experiencia la revisión de código es la parte mas importante de un proyecto y es por eso que solo ciertas personas deberían hacerlo.

¿Qué es y porque es importante?

Según la buena Wikipedia es un examen sistemático para mejorar la calidad de código y evitar todos los bugs posibles. Si leíste la oración anterior ya sabes porque es importante, no he tenido ni un proyecto “formal” donde esto no se haga, y con formal me refiero a un trabajo para un cliente. La revisión de código es de las partes mas importantes en el código final ya que un compañero puede tuyo puede cambiar tu código a una linea y de la misma manera tu puedes hacerlo, si pensaste que tu no podías hacerlo tienes el síndrome del impostor del cual ya hablare después.

Formas de hacerlo

Encontraras varios lugares que te dirán varias formas de hacerlo pero la pagina Smartbear considero los acomoda en tipos de manera muy correcta, seria los siguientes:

• Correo: Se envía un correo cuando tu código esta listo y varios colegas lo revisan, el gran problema es que tendrás múltiples opiniones y puedes quedar mal con algún colega.
• Programación en pares: Funcionan muy bien en metodologías extremas, dos personas trabajan en el mismo código. El problema que he encontrado es que es necesario tener una buena sinergia con tu compañero o si no las cosas se pondrán feas.
• Over-the-shoulder (Sobre el hombro): Aquí es cuando literalmente te están criticando a tus espaldas, te juntas con uno o varios compañeros para que revisen tu código mientras les explicas el porque lo hiciste de esta manera. En mi opinión es el mas cómodo aunque también puede hacer que pasen discusiones.
• Asistido por herramientas: Es el favorito de muchos y el único que nunca he probado, básicamente utilizas software para eficientar la revisión de código. Aquí hay una lista de los mejores softwares.

En mi experiencia

Mi mejor experiencia de revisión de código fue al usar GitHub y crear mí pull request (que se agregue tu código al proyecto) mi coordinador del proyecto que era una persona con varios años de trabajo lo revisaba y le daba el sí o no. La experiencia anterior también fue una de las peores porque también mis compañeros de trabajo podían revisarlo, yo nunca subía el código hasta que mi coordinador lo revisaba porque suceden cosas malas. Una compañera creo un código muy simple que mejoraba parte de la aplicación y dos compañeros míos le dieron el sí, y después se agrego su código mi trabajo de una semana se perdió ya que su código de algún modo neutralizaba el mio, el suyo mejoraba el como se veía el texto y el mio permitía subir imágenes, por esto tuve que juntar el trabajo de tres semanas con el debuggeo de una semana de trabajo. El código nunca lo arregle tuvo que ayudarme mi coordinador ya que ni el ni yo sabíamos que el código de mi compañera se subió y eso fue lo que desato el problema, esto no fue culpa de nadie era muy difícil saber que esto sucedería ya que era un problema de la librería que uso mi compañera, al final no paso nada y el problema se arreglo pero eso hizo que mi eficiencia bajara considerablemente. Es por esto que al principio del blog lo escribí y lo repito “La revisión de código debe ser hecha por personas con mas experiencia que tu”.

Suena sencillo… y de hecho lo es

Digamos que estuviste un buen tiempo preparando el diseñado de tu software, lo hiciste en UML y finalmente llegaste al punto de empezar a “codear” entonces viene la parte en la que veras si hiciste un buen diseño o no. El momento de empezar a escribir el código es de los mas delicados ya que un pequeño problema en el diseño hará que pierdas muchas horas laborales, si por alguna razón aun no sabes mucho de UML o el diseñado tengo varios blogs de eso así que te recomendaría que los vieras. Sí pudiste tener un diseño correcto entonces podrás pasar a código tu diseño de manera muy sencilla. Veamos un ejemplo:

Si vemos este modelo es fácil entender que requiere nuestra clase, primero se llamara Cliente, tendrá dos atributos nombre y dirección, y un método llamado pago.

Si lo vemos de esta manera el pasar a cualquier lenguaje de programación es sencillo incluso a los no orientados a objetos. Pero estarás pensando que el comentario anterior no es valido ya que si no usaras un lenguaje orientado a objetos no lo diseñas de esa manera y estas en lo correcto, pero que pasa si hay algún inconveniente de algún tipo y requieres el cambio? Realmente el pasar de código a diseño es sencillo como ya lo dije la cosa es hacer un buen diseño, si quieres profundizar en el pasar de diseño a código te recomiendo esta pagina la cual se basa en un capitulo de un libro muy recomendable de ingeniería de software o si no conoces el diseño de software pero no te interesa indagar mucho esta pagina lo resume muy bien, pero no te recomendaría que te quedaras solo con eso.

De orientado a objetos a NO orientado a objetos. (Demasiadas a’s en la oración)

Primero que clase de Java es un lenguaje no orientado a objetos? Como dice su nombre su base no se centra en crear código que siga este paradigma si no otros paradigmas, un lenguaje del que seguro has escuchado que no es orientado a objetos es C, si quieres mas información de esto puedes ver esta pregunta en Quora.

En lo personal no he trabajado lo suficiente para poder dar los mejores consejos para estos cambios, pero lo que pude encontrar en foros y otros blogs es que el diseño se trata de respetar, y lo que después haces es utilizar diferentes tácticas para hacer una imitación de algo que se use en POO. En StackOverflow se da un muy buen ejemplo. Aunque me gustaría agregar mas información de estos cambios no hay mucha es muy poco común que esto llegue a suceder así que si deseas mas información tu mejor opción sera hacer un post en StackOverflow o algún foro en Reddit.

El titulo es la reacción que tuve cuando en mi clase de bases de datos me explicaron que esto era posible.

Diagramas de clase

Un diagrama de clase es la representación de clases en un diagrama, por lo general en UML, que se hace al momento del diseño y planeo de software. De manera muy sencilla la clase se representa en un rectángulo, en la parte superior de este se encuentra el nombre de la clase, debajo seguido del símbolo “-“ se escriben el nombre de los atributos de la clase, y finalmente con un símbolo “+” escribimos los métodos de la clase. Hay mas cosas como el usar flechas para mostrar herencias entre clases o usar diamantes para mostrar relaciones pero no me adentrare mucho ya que seria salirme del tema. Si deseas saber mas de UML te invito revisar mis blogs anteriores: “Porque usamos UML?” y “Un poco más de UML”.

Tablas en una base de datos y las clases

Si alguna vez has trabajado con SQL (digo SQL porque nunca he trabajado con algo mas que SQL o Firebase para bases de datos así que si hay más espero me disculpen los más expertos) sabrás que tu base de datos utiliza tablas para el manejo de datos, si nunca has usado algo parecido es muy sencillo. Digamos que creamos una tabla llamada “Autos” y luego esa tabla almacenara tipos de datos al estilo C o Java ya sean integers, chars o varchars entonces esta información pertenece a esta tabla, ahora que nuestra tabla esta creada agregamos campos para que se llenen con la información, digamos que el modelo del auto sera un varchar (un string), el año un integer al igual que su precio, y por ultimo otro varchar para el nombre de su comprador, entonces una vez con esto podemos empezar a llenar nuestra tabla. El uso de tablas no llega a solo almacenarlos si no también podemos crear funciones y limitaciones, podemos hacer que si se agrega un modelo de auto sea necesario agregar todos los demás datos, y si necesitamos buscar información podemos usar una función para que se use un querie y este haga una búsqueda.

Y seguro ya te diste cuenta

Si llevas tiempo que aprendiste programación orientada a objetos mientra leías la parte de arriba te habrás dado cuenta el porque requeríamos de los diagramas, la descripción de la tabla es básicamente una clase que usa POO (Programación Orientada a Objetos), entonces para esto es que buscamos usar los diagramas para tener bien definido todo y simplemente pasarlo a las tablas. Ahora no todo es hermoso y sencillo hay varios casos en las que las tablas almacenan información dependiente de otra tabla, esto hace que se genere una jerarquía y la solución es tomar el diagrama original, el que ya por si solo tiene herencias y relaciones, y transformarlo para que tome en cuenta las jerarquías. La mayoría de veces sera necesario cambiar el diagrama original dependiendo el acomodo de la base de datos. Si requieres de más información o algo mas preciso puedes ir a las siguientes páginas:

• Diseñar una base de datos con UML
• Modelado de clases y objetos con UML
• Mapeando objetos a bases de datos relacionales (Este es el mas pesado de leer de los tres pero el mas completo)