Original Project Ideas
Angel Adrian Galeano Ortiz
At the begging of the intro to software design. It was discussed that our homework would be based on a potential project Idea. This seems useful since it gets students involved in a topic they would actually enjoy. Instead of the same topic for everyone. However, finding and choosing one idea can get difficult. The processes me and my partner Gabriel Marengo used. Was to use the one that seems simple to implement. We thought of a time manager app, a habit tracker and a simple chat app. We eventual decided on the chat application since the concept was simple enough so we decided to see if we could implement a peer to peer chat app. This was discussed since we saw how centralized the internet has become and how powerful social media has become. That a decentralized chat would be a good idea to solve some of the issues centralized systems have. So this is the origin of our project topic for the semester.
Time Management
Time, the most valuable asset one can ever have. However it is so easy to just lose track or even wast this precious resource. That is why many of us try to use time management techniques to keep track of our time. One new technique to me presented by the professor, was to use a time logger. Just record everything you do and see how many minutes of the day you dedicate your time to that task. Since you are tracking your time. You now know what you spend most of you time in. A person can normally tell what they spend most time on since that is what you are mainly doing. However, knowing exactly how much of it can give you an idea and feedback on how to improve. With this you do try to keep goals in mind and tend to accomplish important task sooner. All of this just due to the fact that you are more aware. The only problem is actually getting into the habit of tracking your time. Since you don't normally just put a timer on things you do. You just do them its automatic and you need to develop a habit if you want to do this method. Personally, when I need to accomplish a task. I implement the pomadoro technique. Here you allocate 20 minutes focused on one task. Then take a 5 minute break and continue. After 4 pomadoros, you can take a half hour brake. This is useful since you are pre-allocating time and you are aware of the time or pomadoros needed to complete a task. This helps your mind stay focused and aware of what you truly need to do.
What is Software Engineering
One of the first questions brought up by the professor of Intro to Software Engineering was "What is Software engineering, and to that extent what is engineering?" These basic question help put in perspective what exactly we are going to be doing in our careers for the most part. We all give ideas and say that engineering is the application of math and science to solve problems. This was the first and most simple definition we gave in class. The next question arose was then how do we apply that to software? The simple answer could be the same as before but with the application of software techniques. The definition given in class was the following. "Software engineering is the establishment and use of sound methods for the efficient construction of efficient, correct, timely and pleasing software that solves the problems such as users identify them." As well as the development of systems complex enough that it requires a team of engineers. However then we were put in perspective on how relatively young software engineering is compared to other engineering which has existed for thousands of years. This truly intrigued me since when one codes. Typically we do simple planning on what we need then just code. However, this is where lots of bugs come alive since there is little consideration on how each component behaves independently and then with each other. This leads us to be trapped in the debugger to discover how each component is behaving. This is were we are introduced to domain engineering, requirements and software design.
Project Domain
For the first homework we needed to discover and understand what is our project domain. Since the topic me and my team mate decided upon was that of a decentralized chat. Our domain revolves mostly on the user interactions with the app. This lets us see what are the main entities we use for the system. These included the main user. Which is composed of a sender and a receiver of the message. Another entity was the actual message itself. Then some data and the block chain infrastructure that the app is going to run on. Later on we need to know what are the most basic functions that the app will need to interact with in the domain of the project. The three most basic ones used where a send, receive, and verify function. Now one must think about what triggers these functions. These would be the basic events that occur when using the app. Then if we go even further and think on how these events work together. We can derive behaviors that the app must be able to perform. Once we have these basic concepts on how the app must be able to perform. We can now see what requirements we need. Like the interface requirements. In our case we need a section to log the messages. A section to write the text, to send and receive text and a way to create groups when messaging other users. Since we know what interface we need, we can see the actual hardware capabilities are required to implement such a task. These initial steps in developing the domain of a project help create a foundation for the project to not get so easily lost when developing the project. As well as seeing what other requirements are needed to continue developing the project.
Formalization and Informal Descriptions
When developing complex ideas, it is always a good idea express them and write them down. With formal and informal descriptions ideas can be more fleshed out and understandable. When formalizing using tools like TLA+ help by providing a more mathematical description of each process. This allows you to know exactly what happens in particular module. Modules can help provide a layer of abstraction when looking at how modules interact with each other. Then provide more detail when you look at the components of each module. However, no matter how precise a formal description may be. Others may not be able to grasp the ideas properly since it is such a mathematical approach. This is where informal descriptions help complement the forma description by providing explanations on what is going on in the system. The informal description since it easier to understand may still leave ambiguities. These must never actually conflict with the formal description. Once you know that both descriptions properly complement each other. One can say they know what and how the system works. For this reason it is always a good idea to do both and write ideas out when you can do so.
Petri Nets and UML
One interesting way of formalizing and describing how a system will work is with the implementation of petri nets and UML charts. With these diagrams you can clearly see how each component of the system interacts with each other. In the case of petri nets. You can see each state as a circle. With each corresponding transition with bar. This gives a clear idea of how one state transitions to the next. However you can use tokens to show the requirements of a state before it transitions to the next.
UML diagrams can provide other perspectives on how the system would work. Such is the case of the sequence diagram. Here we have a basic actor and components all lined up in a timeline. With this format one can see the proper order of events when each component interacts with each other. With this perspective it is easier to provide order to the operations f the system. Then there are the class diagram. With this approach one can see the more technical side of the application. One can see the functions and entities that each class contains. However you can also see how these classes interact or inherit from each other with a parent child like structure. Finaly a Case diagram can provide more detail on how a particular use case scenario may be. By having actors outside the system then visualizing how the system behaves internally depending on the user action. All of these types of diagrams help provide a visual aid when developing a system.
Risk Assesments
Risks are always present in every decision we make. Therefor,when developing systems we need to assert all the risks and how severe are the consequences. To start the analysis process we must understand where we are looking at. This can be done by getting input from different departments and think about the most common occurrences and how they can become a potential problem. Afterwards we can start identifying what type of risk they are. All be it structural, hardware, software, user safety, etc. Once the risks are identified we can start seeing the actual probability of these events occurring. This helps give a sense of urgency on fixing or reducing the risks. We can also see what consequences might occur if the risk happens. This helps give a sense of severity each risk may bring. Once this is done, we can start developing ideas on how to address these risks. Sometimes risks are inevitable and will eventually occur. In these cases it is recommended to develop a plan to reduce the consequences of the risk and mitigate the damage. Other cases, risks can be simply avoided if asserted properly. However, one must then be aware if this approach introduces a different risk. Then there are cases where transferring where the risk occurs may be the correct approach. Then other times the risk will occur yet we can change the consequences of the actual risk. All of these are valid approaches depending on the risk at hand. Yet when solving these risk we need to take priority on which risk to asses. A way to see which risk to asses first is to develop a risk severity vs probability table. where you would try to asses a risk with sever consequences and high probability first and a low probability and low damaging consequence last. Finally when all of this analysis is done. One must sill monitor the situation in case a new or unexpected events occurs. Then we repeat this process but with the new data gathered.
Procrastination
Procrastination, the ban of every person with tasks to complete. This is a phenomena that is difficult to overcome. With no real benefits in any way. Therefore, what is procrastination, what causes one to do it, and how can we overcome it. Since procrastination has existed since humanity we can trace one definition to the Greek philosopher Aristotle. With his definition "Akrasia is the state of acting against your better judgment when you know you should be doing something else." I like to think of it as delaying a task with the illusion of time available. so, what causes this behavior? There are several factors that cause one to procrastination. One is simply the lack of self discipline and previous habits that conflict with the task at hand. Another cause is the simple fact that we have many things to do in a day and we no longer know what is the most important task to accomplish at a certain time. A final one is the act of self sabotage. This is when you procrastinate in a difficult situation. Giving you a fake excuse in case you don't accomplish the task. This form of procrastination is extremely dangerous, since it involves you sabotaging your future self while you are not even realizing it. Now realizing what procrastination is and some of the causes. How does one stop or reduce procrastination? One technique is to start developing a habit for the task at hand. This helps it become more instinctual and eventually require less effort to accomplish. Yet now the problem is how do we start the habit? To start one can try to associate the task with visual queue or event to remind you to do the actual task at hand. This method helps develop discipline and reduce the amount of effort to find motivation to accomplish the task.