HFOOAD Chapter 7

--Originally published at Hackerman's house

This chapter is about how sometimes you don’t know where to start a project or how to approach it. This is something that made I felt identified to; it is usual that at the beginning of a project I spend more time looking at the screen and thinking without any idea of how to start, so I think it was useful to read this chapter.

The things in your application that are really important are architecturally significant, and you should focus on them FIRST.

One of the first advices I found useful was that before you start designing the relations between the parts of the systems you need to have these parts or at least the basics. Architecture isn’t just about the relationships; it’s is also about deciding which parts are more important to create them first. This is where the three Q’s of architecture get into the scene; they help you determine which modules are more important.
Q

Photo by Bill Dickinson

Is it part of the essence of the system?

The essence is the most basic idea of what a system does. The easiest way to determine if a part is essential to the system is imagining the system withouth that feature, if you can’t, the feature is most probably essential.

What the heck does it mean?

This idea was somewhat new to me, because I usually start with the part that I can understand easily. In this case the suggestion is start with the features we don’t completely understand. This allows you to avoid risks around this feature. Understanding it from the beginning can mean that you won’t have problems when you are designing the relation with other parts.

Confused

Photo by Thomas Hawk

How the heck do I do it?

This idea is really similar to the one Continue reading "HFOOAD Chapter 7"

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 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

Pug
Continue reading "Chapter 4 HFOOAD"

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.

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.