For my third blog, I will explore software maintenance and its important role in the SDLC process. Maintenance is typically the last step because these updates and tweaks are made after the finished product. We have touched on the SDLC process and scrum during our in-class activities and examined both their differences and similarities. I found this source that goes into more detail about software maintenance while explaining the different types of maintenance.
For the most part, maintenance in our in-class discussions for the SDLC process was a period of bug fixing or adding new features the customer wanted in the software. The blog lists two more reasons why maintenance should be altered, whenever a policy changes or if there is a business-level change, like an acquisition of another company. In our in-class discussion, we mainly went over two types of maintenance, corrective maintenance, which consists of updates correcting problems found by an end user, and adaptive maintenance, which consists of keeping the program up to date. A new type of maintenance I haven’t thought of but the source pointed out was preventive maintenance, updates that aim to prevent future problems of the software. Some examples of preventive maintenance can be regular cleaning of code or replacing outdated sections and updating them with newer code.

The source then goes on to talk about the costs of each software process cycle, and this section caught me by surprise. It goes on by stating a study found that maintenance can be as high as 67% of the cost of the total software process cycle. I always thought that designing or testing would have a bigger slice of the cost rather than maintaining, but the source again highlights that on average the cost of software maintenance is more than 50% of all SDLC phases. It then goes on to give some context or some reasoning why this phase can be so expensive, the standard age of software can be up to 10 to 15 years which creates a commitment to pay to upkeep them, the structure of the program, the language used in the programming, and changes that are made are often undocumented which leads to problems in the future.

This source did a good job of going in-depth with the maintenance stage of the SDLC process we learned in various in-class activities. It gave me a new sense of where most of the budget goes during the SDLC stages while explaining that each type of maintenance is varied by its nature and characteristics. If you would like to know more about the most costly phase during the SDLC then I would recommend reading.

Source: https://www.tutorialspoint.com/software_engineering/software_maintenance_overview.htm

From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.

For my second blog post, I will explore Software Licensing. I chose this topic because we have learned in class about the different types of licensing and what you can or can’t do with specific ones. There are multiple options to choose from when selecting a license for a program or software, and these differences can sometimes be confusing. I decided to dive deeper into this topic and found a blog titled “Understanding Software Licensing” by Fernando Galano.

The blog is divided into five sections: What is a software license? How does it work? Why does it matter? What are the types of software licenses? How do you find the perfect license for your software? The blog does a good job highlighting the importance of a license and the complexities of the legalities that come with terms and conditions. As we learned in class, a license is a type of legal contract between the creator(s) and the users interacting with the software. This interaction for the users can include the installation, modification, copying, or distribution of the software. It’s ultimately up to the creator(s) to select the license they want, which then defines what rights the users possess with the software.

In our class discussions about software licenses in model two, we discuss the different types of licenses and which is the best. The blog also does a good job explaining the differences between them while giving examples of companies that use certain licenses. Some examples of licenses for software are copyleft, public domain, permissive, and open source. Each of these licenses has its benefits and limitations, and it is up to the creator to line up the values they want their software to use. For example, a public domain has no restrictions on how the software can be used, but in comparison, a copyleft license forces derived work to have the same conditions.

The blog ends by explaining why licenses even matter and how to choose which best describes your situation. It explains that licenses have benefits for the user and the creator and these benefits help both parties understand the terms and conditions for its use while avoiding confusion. The author highlights the benefits for the user as an aid to managing tools and resources, clarifying how you can use them, and preventing unnecessary costs for tools the user may not need. The benefits for the creator include preventing unauthorized copying and distribution, limiting liability, and giving the creator control over the usage of their product. What I wish the blog talked about is the similar topic of copyright. We learned about this important topic in part one of software licenses by answering questions like, “You have a new idea for a program, can you copyright that idea?” or “You created a new program based on that idea, is that software copyright-able?”.

This blog did a great job explaining how licenses protect the user and creator while going in-depth on the different types to choose from.

Source: https://www.bairesdev.com/blog/understanding-software-licensing/

From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.

For my first real blog entry, I would like to talk about Code Review. I chose this topic because we are doing in-person activities based on clean code, in my Software Process Management class. When discussing how to make code cleaner and more readable, I looked more into the topic for more information. Code Review is a process performed by a person or more to examine and improve the code. I found this blog titled “How to Review Code – Tips and Best Practices” by ‘AK DevCraft’ and noticed that some of the points and practices are the same as we learned in class.

The blog highlights three important tips to be aware of when reviewing code, the first tip being Intention. This tip explained what the dos and don’ts are when reviewing code. When you review someone’s work, it’s pivotal to be positive and respectable. Giving constructive criticism, and explaining precisely what changes need to be made to improve the code. The blog also made sure to emphasize not to leave comments where you didn’t need one. Adding multiple comments to code is unnecessary and makes the code harder to read. The summary of the first tip was to be respectful to the ones who wrote the code and make it a collaboration when reviewing the code.

The second tip the author said was important was Standards. When reviewing code, making the code easy to read while making it easy to understand is what coding is all about. This can be done by sticking to a consistent format, which can be having meaningful whitespace, removing unnecessary gaps, or breaking larger functions into smaller ones. Understanding the standards of variables by creating clear and concise names for every variable. By knowing to avoid abbreviations and add values to variables such as “gallon” or “mL” to make the variable clear on what unit it is. A good practice we learned in class is to avoid duplication, duplication of code can lead to unnecessary code or more confusing messes like bugs or error messages.

The last tip the author highlighted was to review. When finishing the code review, keeping the big picture in mind can verify if your changes were necessary. GitHub is a platform we are using in class for our in-class discussions the platform has a review system to look over the source code and can help you double-check the code.

The blog shined a light on tips I believe are important when reviewing code, when my group did discussions on reviewing code, we used the same tips listed in this blog in our discussion. The blog gave me information on taking reviewing code to the next level, informing me of the GitHub feature to review the source code and always keeping a strict format in mind when reviewing code. I would recommend this blog to someone who is new to reviewing code or just wants a different approach when reviewing code with another person.

Source: https://dev.to/akdevcraft/how-to-review-code-2gam

From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.