Use Cases

--Originally published at Hackerman's house

Use cases is a methodology used to identify, clarify and organize system requirements. Use cases describe the step by step process a user goes to complete a goal using a software system, each use case has an specific goal and it has to consider the things that can go wrong, creating this way not only one path for the user but many paths.

Main characteristics of a use case:

Organizes functional requirements
Models the goal of the user
One main flow of events, and other possible ones (alternate courses of action)
Multi-level, this means one use case can use the functionality of another one

Photo by Bernard Goldbach

How to write a use case

You need to have a clear actor, and describe the scope of the use case.

Describe the set of steps the actors take to accomplish the goal of the use case. In case there are alternate flows you have to describe it as well. There is another type of flow, exception flows are the things that prevent the user from achieving their goal, this steps should also be in the use case. The alternate and exception flows must be marked as not part of the main path.

Photo by Kate Rusell

References:

Brandenburg, L (2018) How to write a use case. Bridging the gap. Retrieved from: https://www.bridging-the-gap.com/what-is-a-use-case/

Unified Software Process

--Originally published at Hackerman's house

The Unified Process is a iterative and incremental software development framework, from which a customized process can be defined. The most popular variation is the Rational Unified Process (RUP), there are others like the Open Unified Process (OpenUP).

There are some key characteristics in the Unified Process;

Iterative and incremental development framework
Architecture-centric
Risk focused
Highest risk factors should be adressed as early as possible
Use case and UML driven

Each cycle is broken into four different phases, this can have multiple iterations within the phase.

Inception Phase

In this phase you have to establish the goals of the project. The core requirements and features are defined here, as well as the main risks. This phase also includes the initial project plan and early use cases.

Photo by Mike Cohen

Elaboration Phase

The architecture foundation of the system is established. In this part is taken a more detailed analisys and planning. The architecture must consider the most important requirements and risks.

Construction Phase

This is the phase where the software is built, integrated and tested. The user manuals are created and details of the software are ready to be provided to the user.

Photo by Dan Simpson

Transition Phase

Is where the software is deployed to end users, it has a beta testing stage to ensure the software is ready for the user, retroalimentation from the user is really important in this phase.

References

David Olson (2014) Unified Process, recovered from: http://bawiki.com/wiki/concepts/sdlc-process-models/unified-process/

Life cycle

--Originally published at Hackerman's house

The Software Development Lyfe Cycle is a sequence of stages to develop a software product. Some of these stages are:

Planning
Analysis
Design
Building
Testing
Deployment
Maintenance

A diagram of the SDLC life cycle.

The main point of Life Cycle is to detect errors in software creation before they are discovered later in the development of the project, this way you can save time and money, this also can improve the quality of the software.

There are many different lifecycle methodologies with different approaches.

Agile

The agile model is relatively new, but in the present is one of the main methodologies used by many software organizations. The agile model is used to satisfy the rapidly changing demands of the clients, being flexible and delivering faster. The projects are divided into short manageable segments, with shorter deadlines and more basic requirements, each segment follows the basic stages managed in short sprints.

Resultado de imagen para agile lifecycle

Waterfall

The waterfall model is the oldest of the methodologies, it is very straightforward, you have a sequence of stages, when you finish one you move on to the next one, you don’t go back and every stage relies on what has been done before. This model is very rigid, which is why it has many cons, an early delay can carry huge loses, and the problems can’t be fixed until you get to the maintenance stage, this can be very expensive as one problem may have caused others in the way.

Other examples of SDLC methodologies

Lean
Spiral
Iterative
DevOps

References:

Arkasoftwares (w.d) Agile model software development lifecycle, Recovered from https://www.arkasoftwares.com/blog/agile-model-software-development-lifecycle/

Robert Half (2017) 6 basic sdlc methodologies: Which one is best?, Recovered from https://www.roberthalf.com/blog/salaries-and-skills/6-basic-sdlc-methodologies-which-one-is-best

Chapter 5 HFOOAD

--Originally published at Hackerman's house

This chapter talks about the importance of making software that is flexible that is prepared for change.

The abstract class defines behavior, and the subclasses implement that behavior

The first topic is the abstraction. We can use abstract classes as a mold for objects that share the same behavior, this is later implemented in the subclass following the precise requirements for that class, taking as a base the behavior of the abstract class. The subclass can implement or override what’s in the abstract class. The first step to create an abstract class is determining when objects share the same behavior.

By coding to an interface your code will work with all of the interface’s subclasses-even ones that haven’t been created yet

The interfaces have been a common topic since I began studying this career, the classes inherit common behavior from this interface, interfaces make software easier to extend, this is important as it adds flexibility to the software.

In this chapter I noticed that I usually see encapsulation just as a way to avoid repeated code but it is more than that, encapsulation can prevent unnecesary changes in the classes. A good practice is to separate behaviors of an app that can change a lot from those behaviors that won’t.

Finally one of the things that impacted me the most in this chapter was that you have to analyze your own code and recognize when you have made a mistake, design is iterative and you have to change your own design in case it’s needed.

Photo by Mr. Nixter

Finally I want to talk a little about my project. We have decided our project and it’s main requirements but we need to define better what the reach of the project is going to be, the design until now is very Continue reading "Chapter 5 HFOOAD" →

Chapter 4 HFOOAD

--Originally published at Hackerman's house

This chapter is really interesting, as it talks about how your project will not be in the perfect situation when you release it in the real world, so you have to take into consideration all the bad things that could happen and the external factors and situations that may arise in the environment where your software is. In the case that your system only works on the perfect scenario you will have a lot of problems with your customer, because the external factors may cause the software to become useless.

This chapter talks about two more things, first, in relation with the use cases we have been working on for a couple of chapters, it talks about how important is to detect the nouns and verbs in this use cases, this can be useful to determine which classes we are going to need to develop our system, it is important to notice that not all the nouns are going to become classes as some of these are external agents and the software doesn’t have the need to include them. The verbs help us define the methods that we’ll use.

Resultado de imagen para class diagram

Example of class diagram by TutorialsPoint

At last, this chapter introduces UML diagrams, to visually represent the system and how their parts relate to each other. This can be used after the analysis and can help us to have a nice transition between this stage and the development or code stage. This UML is used when you already have the vision of how the software should work.

Now I want to talk a little bit about the project, we have finally decided what we are going to do, the Robodoggo is a robot that will help the people take care of their dogs. I really like my team, I’ve known Max

Continue reading →

Chapter 3 HFOOAD

--Originally published at Hackerman's house

Chapter 3 of the book was shorter than the first two, and I think it didn’t cover as much information. It talks about change, this is something you can always count on when you are developing software. This sometimes happen in the middle of the project, when the requirements need to evolve to satisfy the customer, in other occasions the software is already complete, but the customer realizes that his product can improve or even change its goal.

Change is constant, and your system should always improve every time you work on it.

The system must evolve to handle the new requirements, the use cases must be redesigned to assure that the customer’s goal is accomplished. As we already learned in the chapter 2, the use cases help us code, if the initial code and the original use cases are well designed, the changes in the requirements can be easily handled. A good encapsulation, where the objects and their methods are correctly related may avoid duplicated code, thus facilitating the process of change.

Photo by Martin Deutsch.

In this chapter I realized how important is a good design, as this not only affects the way your customer will receive its product, but it affects the programmer when change is needed.

Chapter 2 HFOOAD

--Originally published at Hackerman's house

This chapter of the Head First Object-Oriented Analysis and Design talks about the importance of gathering the adequate requirements for the costumer, this process is all about making sure you satisfy your costumer by making sure you deliver them exactly what they need even though they may not know all they need.

This part of the design to talk with your client so you can understand what are their needs, this way you can define way better how to design your software, then you can verify if your software is fulfilling all the requirements that you set at the beginning of the project, this way you have a viable way to measure how well your project is being made, this can be used to show the customer or your boss the advances in the project.

Most of the times, listen to the costumer won’t assure that your requirement list is complete, that’s why you got to see beyond what they told you, and imagine specific cases where external variables may affect the way the system works, in any case the system should be able to respond to these specific cases and take an alternate path to accomplish what it is made for.

In this book they use a requirement list to gather all the requirements for the system, a year ago I learned something called user stories these are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system, is an agile methodology which is really useful to define the requirements, and something I personally like to do when designing software.

When you already have the list of requirements you may write Use cases to define how to accomplish the requirements previously stablished, this Continue reading "Chapter 2 HFOOAD" →

Chapter 1 HFOOAD

--Originally published at Hackerman's house

This is a new semester in my life, this means I will be using this blog to share insights about my Software Analisis class.

This time I will be sharing my thoughts and things I learned about the first chapter of the famous book Head First Object-Oriented Analysis and Design written by Brett D. McLaughlin, Gary Pollice and David West.

Reading this chapter I realized about the importance of planning when you are developing any project. It’s is important to consider not only the present of the project and its functionality but the future, how robust it is and many other factors that should be taken in account in the production of good software.

While you are developing software you have to have priorities, usually the most important thing is that it is useful for the customer, then you can try some other things to make your software flexible and reusable, both of them properties of good software.

I really liked this chapter, specially the way the authors try to explain the topics in such a didactic way, using examples of code as well as UML diagrams or simply using texts or characters to explain what is going on.

Semestre I, Parte Técnica

--Originally published at Hackerman's house

En este semestre I teníamos la tarea de proponer un modelo de luminaria pública inteligente, en el cual se solucionarán problemas relacionados al municipio de Zapopan, como la contaminación, el bajo índice de luminarias funcionales, las altas tasas de criminalidad ocasionados por la luminaria deficiente.

La propuesta implementada por la mayoría de los equipos en este semestre I fue utilizar 2 fotorresistencias, 1 sirve para medir la luz solar que llega a la posición de la lampara y con esto implementar la automatización de la lampara, la segunda fotorresistencia tiene la función de medir la luz que esta emitiendo la lampara. Los resultados de estas 2 variables se pueden comparar para así determinar si la lampara está comportándose de la manera adecuada ante la luz natural presente, en caso de que esta no haga lo adecuado, la base de datos se actualiza para que los administradores estén al tanto de las fallas en el sistema, de esta manera pueden ejecutar su mantenimiento de mejor manera.

Para realizar este proyecto requerimos desarrollar competencias referentes a bases de datos, principalmente referentes al diseño de tablas y las relaciones entre ellas, esto lo aprendimos en el salón de clases, mientras que el manejo de estas mediante la utilización de un lenguaje de programación lo realizamos por nuestra cuenta, con un manejo bastante básico de los datos mediante la utilización de PHP.

Por otra parte, la competencia más complicada de aprender, en parte porque soy Ingeniero Computacional y la materia es de electrónica, fue microcontroladores, requerimos de esta para la implementación de las fotorresistencias, además de para enviar datos coherentes mediante la utilización de un módulo wi-fi. Parte de la funcionalidad del microcontrolador es permitir la automatización de la lampara. Este sistema funciona gracias a la utilización de interrupciones que permiten que se hagan

Continue reading →

Semestre I, gran idea de ejecución mediocre

--Originally published at Hackerman's house

En este blog hablaré de mis opiniones y recepción al semestre I que estoy cursando actualmente. Primero que nada, el semestre I es un nuevo programa de enseñanza que se está llevando a cabo desde hace un par de años en mi universidad, el Tecnológico de Monterrey, este busca desarrollar competencias que les serán útiles a los estudiantes a lo largo de su carrera profesional. Todas las materias acreditadas a lo largo del semestre están enfocadas a un solo proyecto a realizar, este modelo crea equipos que se mantienen juntos a lo largo de todo el semestre y en todas las materias. En mi opinión personal este modelo tiene bastante futuro, ya que se experimentan cosas mas reales que en el semestre regular no experimentas.

Este semestre tuvo sus problemas incluso antes de comenzar, no se nos comunicó que participaríamos en el semestre I, los alumnos nos dimos cuenta debido a lo poco común que eran nuestros horarios, además de que es poco usual que muchos alumnos lleven exactamente las mismas materias en este semestre, especialmente en nuestro caso en el que alumnos de 2 carreras diferentes tenían las mismas materias. Después de que varios alumnos presentaron su inconformidad en relación a la situación que se estaba dando, se logro que hubiera una junta informativa, en esta nos pintaron el semestre I como una maravilla donde tendríamos una libertad de horario que nunca habíamos experimentado, después nos daríamos cuenta que esto no sería así, además nos mencionaron que el socio formador (el cual nos debe de ayudar a desarrollar estas competencias) todavía no había sido confirmado, esto a escasas semanas del inicio del semestre.

El comienzo del semestre se dio de manera muy similar a un semestre regular, cada clase veíamos temas que también se ven en el plan regular,

Continue reading →