I think we (the software engineering industry) can all speak from experience that it can be hard to explain some of our own ideas to other people. We’ve all had that killer app idea that had the potential to become as big as Facebook or Google, yet we find ourselves at a crossroads when trying to explain the functionality of it to our peers and friends. Yet, in 1992, our good pal, Ivar Jacobson, introduced the idea of use cases to help everybody explain what the heck is going on in any system.

Use cases can be used for many different fields, yet it is widely used in the software industry, and it was one of the main components of the Unified Software Process. When describing the definition of a use case, we need to understand the different parts that can interact with each other in our diagram. The first one, and I believe the easiest to understand, is the system part. A system can be a lot of things, it could be a web app, a mobile app, a business process, a logistics solution, etc.

The next part of a use case, is the actor. Actors don’t have to be human, they just have to use the system in our diagram. This can be a little tricky, because it’s not always clear who interacts with the system and who doesn’t, so it’s key to have that established to avoid errors. An actor can be labeled as primary or secondary, the difference lies within how the actor “acts”. A primary actor will initiate the system, so for example, any user that uses an app is considered primary. Secondary actors react to what the primary actor is doing, and in our diagram, they are shown to the right of the system, while primary actors go to the start, or left part.

The third part of use cases is, well, they’re called use cases, which is a little redundant, but they are basically actions that our system makes to solve any given task. So for example, a weather app gives you the ability to check the weather depending on any given city. That is considered to be a use case. They’re the functionality within our system that makes our system useful to the user. You want to be very especific with your use cases, and want to place them in the logical order that one would typically follow.

Finally, we have relationships, which, as one might guess, define who interacts with who within our system. This final part is very important, as it gives sense to our system, and will make our idea very clear. Relationships usually go from an actor to a use case and vice versa.

So there you have it. Use cases are a very cool concept, and a very useful one when developing any system. They provide clarity when it can be hard to explain using just words, and defines the boundaries of a project and the relation it has within itself. I wanted to mention that I made this blog based on Lucidchart’s video on Youtube about use cases, which was very clean and easy to understand, so I will leave that link in here.

Main Image by Bethany Drouin from Pixabay

You can check out some of my latest work on my website: grupoargon.co

Peace!

Let’s simply start with the fact that this blog was supposed to be made about 3 weeks ago, yet my procrastination was too big and now here I am, on partial’s week, blogging about what Unified Software Process (I’ll now refer to it as USP) is.

Last blog, I talked about some of the different methodologies used for developing software projects and how it could literally mean the difference between a good process and just having a really bad time. So we’ve already established that having a good framework is important, now we’re going to talk about USP and it’s iterative ways.

Everything started back in 1999 when the trio of Grady Booch, Ivar Jacobson and James Rumbaugh published a book called “The Unified Software Development” in which described the process that we know as USP today. Just for clarification, this process was owned by Rational Software, so people just started using the USP name to avoid conflict with what Rational called RUP, or Rational Unified Process, but they’re mostly the same concepts. Anyhow, this process has many different interesting aspects, but the one’s that I found more interesting were the fact that it is an iterative process, and it has many different layers, which overlay between each other. The model has 4 differents stages, which are Inception, Elaboration, Construction and Transition. Unlike some of the methodologies discussed before, USP is risk-focused in a way that it relies on the development team addressing the most critical risks early on.

USP is tied closely to UML, this makes sense since that’s the language that was developed by the people we just talked about. Many people consider USP to be the most reliable and trusted process for the development of a project, but you’re not here for that, you’re here for my opinion. To me, USP looks like an awesome way of developing a project. It is very organized and very clean, yet I think that the biggest flaw it has is it’s made by people in the software industry, for people in the software industry. This is cool and makes sense, but a development team is not always compromised by software engineers, it can have many parts to it. Designers, for example, can be a big part of a development team, and I don’t think this makes much sense if you’re not accustomed to this kind of methodology. However, if you can make it work and get other parts of your team up to speed and not struggle with the many different parts of USP, I do believe it is a very strong framework, one that can lead to the development of a great project.

I used a bunch of resources to try and learn about USP and I had some trouble getting the gist of it, so I’ll link my favorite video about it right here.

You can check out some of my latest work on my website: grupoargon.co

Peace!

Once upon a time, someone, somewhere, had an issue. This someone was trying to develop a software project, but they were having some issues regarding the steps they should follow to create the best quality of project possible. That story takes place way back in the year 1960, but that was then, now is now, and what I want to discuss today is the different software development life cycles that are most popular in the community today.

You probably already know what a SDLC is, so I will skip that definition to go directly into (most of them anyway) the different cycles that are used to develop complex software systems, and I will also include my direct opinion on them.

The Waterfall Model

This model is the pioneer model used to develop software. The waterfall model is called like this because progress in the project is described to be going in a downward manner, just like a waterfall. One of the better characteristics of the waterfall is that it is very straightforward: Finish any stage, move on to the next. This means that there is no real overlapping between the different stages, and there is no going back after finishing a stage. However, the waterfall model isn’t really that great, because it doesn’t give us any flexibility at all. Anyone who has worked with a client on a software projects knows that, more often than not, the requirements and nature of the project can change on the run, and the rigidity of this model makes it very difficult for both the developers and the client to get to where they want. I believe we mostly study the waterfall model because it was the first one used for software development, but it is very outdated now, and mostly unused in the community.

V-Shaped model

Also known as the validation and verification model, the v-shaped model is the basic successor of the waterfall model. Just like the waterfall model, it’s biggest flaw is that it is still very rigid and has no sort of adaptation to it. Coding is done in the implementation stage, which leaves us without early prototypes, which can raise some issues with the stakeholders. I guess you could use it for some small to medium problems that have very well defined requirements, which is kind of hard! I’m not saying that this methodology is bad, it just isn’t something I would use with the types of clients that you are most likely to encounter.

Spiral model

In the Pokemon universe, “Ditto” is a shapeshifting Pokemon that transforms into anything that it sees fit. The spiral model is the equivalent of Ditto for SLDC’s, as this model lets you adopt elements from the other SLDC’s based on what happens in every spiral. This is very different from what we’ve seen so far from the other model’s, as the spiral model gives us the flexibility to choose the best approach on the run. I believe this approach to be riskier, yet more rewarding. However, as much as I do enjoy my flexibility for development projects, the Spiral model has some very big flaws, starting with the fact that you don’t really have an end date, you don’t really have a way to quantify progress, and it can be very difficult to manage. So, not as straightforward as the other two, but way more flexible, so it’s more suitable for big projects.

Agile

This model has been around for about a decade now and is a major force in the community in the present. It has become so popular, that some companies are using it in non-tech projects. On a side note, Agile is the only methodology that I’ve used on the projects that I’ve been a part of, so I can speak from experience when I say that things can go either very well or very poorly when a team decides to use the Agile model. The cycle works kind of like a for loop or a while loop, where the team is working in an iterative manner, making small progress in each cycle, and correcting small errors before they become bigger ones down the road. It is a good approach when both the development team and the client have a very good understanding what they are getting into. Communication is the biggest key here, yet sometimes is missing, and can lead to a very poor process. In conclusion, I like Agile, but it requires a lot for it to work, so you have to have that in mind when you choose agile.

SLDC’s are a very important aspect of any software project, and the selection of one or the other can be a life or dead situation. Some are more popular than others, some are newer, some are older, but it is a fact that you have to know the pros and cons for each one to be able to make a good decision and develop a great project.

You can check out some of my latest work on my website: grupoargon.co

Peace!

I will start my blogging journey right here, right now. This is the first of many blogs to come down the road, most of which will be talking about the Analysis and Modeling of Software Systems, also known as my Wednesday 10 p.m. class. The teacher, Ken Bauer, asked us to create a blog and use it as a resource to relay our ideas to the public, and I believe that I’m going to enjoy this quite a bit.

I haven’t blogged in about 4 years, and I’ve never really blogged about software, so bare with me for a moment, I promise to give it my best shot. The blog’s UI is kind of dull right now, but I’ll try to improve it during the semester and hopefully I will have a bunch of interesting posts for you to read. I’ve also created my Hypothes.is account, as we are expected to be using it later in the semester for some activities.

Finally, I just wanted to talk a little bit about this new (at least for me) programming language called SmallTalk. It seems to be really different from pretty much every programming language I’ve ever used, so I’m excited to look at code through a different point of view. In SmallTalk, everything is an object, even the program itself, so that’s going to be something cool to work with. After all, I’m all for a fresh experience in software.

You can find some of my latest work on my website: grupoargon.co

Peace!