The Cathedral and the bazaar

--Originally published at Hackerman's house

Molavi Bazaar

Photo by Kamyar Adl

The Cathedral and the Bazaar is an essay about the open source software, written by Eric Raymond in 1997. It starts comparing the Cathedral that is a vertical model where there are less developers focused on the product, it is more organized and carefully crafted, in this case the beta was released until the product had achieved certain goals and the product was decent enough. On the other part was Linus Torvalds’s style of development, where everyone can contribute to the software. This style is compared to the bazaar, everyone has different approaches and agendas, the problem of this could be that with so many contributors the production of a stable system might be difficult, but this wasn’t the case; the bazaar style seemed to work well.

Release early and often, delegate everything you can, be open to the point of promiscuity

tux_to_valdisere_05

Photo by Tao Mai

The success of Linux and Open source was thanks to many factors. One that I find very important is that the developers get involved because of their own interests. The case that is presented is that the existing software doesn’t serve them well enough, so they contribute to make it better, this way they can use it in their everyday life.

Every good work of software starts by scratching a developer’s personal itch

One key in the bazaar style is taking advantage of the existing software. Software can be improved and working with others and taking their contributions make your work easier and better. If you want to have contributions it is important to do constant releases, this way your contributors and clients can give you constant ideas and feedback to improve your software. Another thing that caught my attention was that every contributor has their own ideas and their Continue reading "The Cathedral and the bazaar"

Modeling Languages and Tools

--Originally published at Hackerman's house

A modeling language is a graphical or textual computer language that is used to design models of new software or system.

Graphical modeling

Graphical modeling languages use diagrams, symbols and arrows to represent relations, real life concepts or even steps.

The most popular is the Unified Modeling Language (UML) this is also the most popular modeling language in general. Thanks to its popularity there is a lot of software that supports this language.

Another one is the flowchart, is a diagram used to represent an algorithm, workflow or process.

Both of these languages are supported by https://www.draw.io/ 

Textual modeling

The textual modeling languages are formalized natural languages. TMLs have the ability to describe whole software. The language has to be readable, this is really important because is common that the programmer needs feedback from the user, the model needs to be easy to understand. It is also important that it is unambiguous.

Some examples of these languages are, PlantUML that is an adaptation of UML into a text only format. TextUML does not suppose the user knos UML concepts, it requieres a large amount of information about classes and relations. Umple is model-oriented programming, it is integrated in Eclipse IDE.

Writing

Photo by Chris Campbell

References:

Martin, M; Macek, O (2012) On General-purpose Textual Modeling Languages, recovered from: http://ceur-ws.org/Vol-837/paper10.pdf

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

21 Steps to Success

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.
Path less travelled

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

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.
Day 2 | "The Claw" | 20 December 2007

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.

Warmup

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

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.

 

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.

Need

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.

Userstory

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"