In case you didn’t get the title of the post: this is a reflection of The First Partial.
It’s been a whole month since the semester started and, so far, four topics have been considered for the course. I’d like to summarize the important stuff that I’ve learned along the course about each of them, as well as the things I’ve grasped as the course went on.
I finally learned how to correctly include images in my blog posts. I know! What a shocker. But jokes aside, originally I hadn’t included any kind of picture in any of my previous posts mainly because I was too worried about not correctly crediting the original author. Fortunately, mister Alan Levine (not to be confused with Maroon 5’s singer, Adam Levine, as Google suggested) has written this script that can be used in some web browsers to help with Creative Commons License; it provides a way to automatically credit Flickr pictures, so thanks to him and also thanks to my teacher, Ken Bauer, for providing me with this tool. You can click on their names to check out their respective blogs.
Now, back to the topics themselves, I would like to synthesize the most important aspects for each of them. As I’ve said in practically every single one of my entries, I feel like analogies are the best way of understanding new concepts, or at least their importance in certain fields. That’s why I want to start by listing all comparisons I’ve already used, followed by their proper explanation regarding the topic of the corresponding week.
The scientific method is a strict procedure followed by many. It functions as a guide that tells you what to do before, during and after an experiment; it encourages you to have some background on the problem you are tackling; it helps you figure out what to expect during your testing and it provides options on what to do whether the experiment is successful or not.
SDLC are also procedures, but they support the software development process (duh). They’re practically alternative versions of the scientific method when we take a look at the features listed in the last paragraph. SDLC do consider stages before (definition of requirements), during (coding) and after (testing, deploying, updating) the development of software. More specifically, they encourage research as to what will be needed for a project and define its requirements with the help of the clients prior to the implementation; they help figure out what the expected outcome for certain test/case/version is to then compare it with actual results and, at last, have plans for maintaining, updating, fixing and/or reviewing the application depending on how successful certain test was.
As the name suggests, SDLC involve cycles and, therefore, a sequence of steps. The number of steps and each of their names change from one variant to the other, but the global idea is pretty much the same. Many types of SDLC exist, some are simple, some are repetitive, some are intuitive. Their main differences rely on how often you test or deploy your application, how much time you spend on each phase and whether you can go back to previous steps or not. Each variant may serve for different kind of projects, so it’s useful to know a thing or two about them.
Burgers! Who doesn’t like burgers? Even vegans have found ways to have burgers themselves. This popular dish has, of course, many different versions. Multiple recipes for burgers exist, and alongside different cooks, different tastes and different ingredients, it’s very unlikely for two burgers to taste the same, even for the same recipe. But in the end, whoever eats it will have enjoyed a nice burger, that’s for sure.
I think the Unified Software Process (USP) is similar, not only to burgers, but to most dishes. The basic structure or idea is the same for all variants, USP divides itself into four blocks: Inception, Elaboration, Construction and Transition; and the last three are also subdivided into iterations. This could be seen as the idea of the dish. You probably will include some kind of pasta and meat if you plan on cooking spaghetti and meatballs, for instance.
A USP has to consider disciplines to cover all aspects of the development process. They are then distributed across the four mentioned blocks to indicate how much relevance each of them will have in every stage of the procedure. Disciplines have to be well defined. I like to think of disciplines like if they were the ingredients for a recipe: you choose what to use, how much of it and in what stage of the preparation.
The key difference between SDLC and USP is that, just like recipes, USP serve as reference and not necessarily as a strict guide. Many refinements of the process exist, each with different disciplines, distributions and goals. Some tweaks may be made in order to better fit a project, just like you can add/remove an ingredient from a recipe to meet your preferences. Adaptation also allows USP to work on smaller projects, its versatility is what makes me prefer it over SDLC.
Burgers! But just the patties, yay! Wouldn’t you agree that a single patty could change a burger’s flavor completely? It doesn’t matter how good the rest of the burger is, if the “base” is bad the whole thing would turn out worse than it could’ve.
Just like patties and burgers, requirements are the base of any software development process/life cycle. Your requirements define what’s important, what has priority over what, what’s completely necessary and what could be postponed.
Use cases are a term used to describe how every kind of user accomplishes different goals by using the application. These goals should cover all possible scenarios so, when listed, the developers can figure out how those goals could be achieved through their software, and could go from as simple as logging in to find a very specific section to do a very specific action.
Just to clarify, by users I don’t mean each individual using the application, but rather the roles they can take. Roles define what you are able to do and what you are allowed to see/change. For example, a student and a teacher don’t have the same kind of privileges; teachers should be allowed to change students’ grades, but the students themselves should only be able to consult them.
Thinking of situations like this help you come up with new use cases, the example above could be reinterpreted to define a new user requirement for both student and teacher roles. The best way of thinking of new situations, in my opinion, would be to find an actual representative of the role and ask about what they usually want to do, what they usually have to do and how their role functions, basically.
Use cases are an easy way of visualizing user requirements.
Communication is vital for people. Whether you’re reading something like this entry or seeing a picture like the one below, you’re probably getting a message. People can accurately get these messages only if they know the language they originate from. The more people understand a language, the better it is to use it since it requires less effort.
Modeling languages intend to formalize the way of representing multiple types of information so more people can let others know what is needed in, for instance, each software development process stage. The goal is to set a standard that everyone understands so representations are interpreted as quick as possible.
Diagrams and other graphical representations are popular ways of defining modeling languages, since shapes and colors are more easily recognizable and do not depend on languages to be understood. In fact, the most popular modeling language, UML, is mostly graphical.
UML diagrams are standard ways of depicting different tools and procedures in a more universal manner, and they cover practically every process related to software. From OOP class diagrams to representation of use cases, UML has defined structures, relations, symbols and many more things to express everything needed in each of them.
Modeling languages are a powerful tool that break language barriers and allow for better teamwork and more efficient communication.
Outside of the topics of the masteries, I’ve learned a few things related to OOP during the last couple classes and I now realize that most languages I had been told are object-oriented aren’t completely. We’ve been working with SmallTalk, a programming language where absolutely everything is treated as an object, because everything is, indeed, an object of some sort.
The way SmallTalk works is pretty distinct to what I’m used to, so I’ve been a little confused as to how efficiently/correctly make use of SmallTalk, but I think that’s something I’ll eventually figure out.
Also, I like that I’ve finally had the opportunity to practice my English once again after like a whole year of not really needing it. I think it’s cool.
For now, I hope that the next topics make me think of analogies as hard as these last four have. I think that’s a fun challenge and help both me and whoever might end up reading these entries to better understand all of these different concepts. And not only that, but the ones we’ve already gone through are quite useful, even if we don’t get to make use of them yet the fact that we are now conscious about their existence and how they roughly work is useful enough.
TL; DR: I hope to keep doing as well as I think I have.