Category Archives: CS-348

Writing Good Documentation

Sources: Ángel Cereijo and GeeksForGeeks

Writing documentation for your project can be tedious and boring. Say you just finished your project, you published it, and you’re excited to see people use it… but they don’t know how. You need documentation to explain your project. 

Software documentation is the writing that goes along with your project, ranging from what your program does, how you plan to build the program, or any notes you may have for your team. There are four types of documentation: requirement, architectural, technical, and end-user. Requirement documentation explains the requirements for the program and how it should perform. Architectural documentation explains how the program should be structured and how processes should work with each other. Technical documentation explains the technical parts of the program, like the API and algorithms. End-user documentation explains how the software works for the user. 

Good documentation should be created throughout the development process. Saving it all until the end will burn you out and set you back. To prevent this, progress the documentation as you build the project. Split your project into smaller pieces, like how it is done in an Agile setting, and improve the documentation as new features are developed. 

Documentation should explain the purpose of the project as well. It should set up a problem that your program solves and why it is useful to solve the problem. Communicate with your team on how the problem is going to be solved and a plan to get there. Then, split the project up into tasks and assign them to the team members. Explain in detail any information needed for each task. Having the research and plan in writing makes it so anyone can complete the task at any time. As tasks are completed, update the documentation to the project before calling it completed. 

Having explanatory documentation also ensures that tests can be written easily, even without the actual code that is being tested. Then, as you write the code for that task, the tests are already completed and you can move on. 

As your team progresses through the project, your initial plan and process will probably change. With new resources and findings, the initial documentation needs to be updated as well. 

Once your project is published, your documentation is there to help the users easily use your program. It needs to be written in simple language for any reader and avoid ambiguity/unneeded repetition. 

Writing documentation is necessary for every project, helping to communicate with your development team and to serve as a guide to the users. It is important to write good documentation and keep in mind how other people will use it. Having the basics down of writing good documentation will help me in the future and give me a step up as a new software developer. 

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.

Stay Educated

Let’s explore software process management through a domain that often gets overlooked in technical discussions (even though it’s unlikely in my opinion): education systems. To do this, the UNESCO article “Education Management Information Systems Progress Assessment Tool: A Methodological Guide for Educational Transformation.” The article explains how structured processes, data governance, and continuous improvement cycles help educational institutions operate more “effectively and equitably”.

The UNESCO guide introduces the Education Management Information Systems Progress Assessment Tool (EMIS‑PATT), a framework designed to help ministries of education evaluate and improve their data management processes. The article emphasizes that high‑quality education depends on high‑quality data — and achieving that requires clear processes for data collection, validation, analysis, and reporting. It outlines a structured methodology that educational organizations can use to strengthen institutional capacity, improve decision‑making, and support long‑term transformation efforts aligned with global education goals.

I chose this article because it highlights how process management principles extend far beyond software development. Education systems face many of the same challenges we discuss in SPM: inconsistent workflows, unclear responsibilities, poor documentation, and difficulty scaling processes across teams. Seeing these issues in a non‑technical domain helped me appreciate how universal process thinking really is. I was also drawn to this resource because it connects directly to real‑world impact — improving data processes in education can influence policy decisions, resource allocation, and ultimately student outcomes.

What struck me most is how closely EMIS‑PATT mirrors the software process models we study in class. For example, its emphasis on iterative assessment and continuous improvement parallels Agile’s sprint cycles. Its focus on standardizing workflows resembles the structured phases of Waterfall or the disciplined practices of DevOps. Even the idea of strengthening “institutional capacity” reminded me of how development teams invest in tooling, documentation, and onboarding to improve long‑term productivity.

This article also reinforced the importance of process transparency. In education, unclear data processes can lead to inaccurate reporting, inequitable resource distribution, or students being overlooked entirely. In software engineering, unclear processes can lead to bugs, delays, and misaligned expectations. In both cases, the solution is the same: define the process, measure it, and improve it continuously.

UNESCO made me reflect on my progression through taking this Software Product Management course. It was one of the most exhilarating experiences I have ever had in an educational environment. Throughout the various activities I’ve partaken, I not only gained new skills, but I learned my strengths and weaknesses. I see process management as a foundation skill & this resource has showcased the power of processes throughout entire systems, not just for software teams.

Source: https://www.unesco.org/en/articles/education-management-information-systems-progress-assessment-tool-methodological-guide-educational

From the blog CS@Worcester – theJCBlog by Jancarlos Ferreira and used with permission of the author. All other rights reserved by the author.

Blog Post for Quarter 4

Considering how the brief simulation of workflow was a recent assignment, I thought it’d be interesting to re-explore the waterfall workflow method. I found this article interesting due to the end. It emphasized potential benefits of aspects of the waterfall method. Instead of outright rejecting it, it highlighted some positives.

I think this is particularly interesting as it highlights the benefits and suggests pulling certain aspects out by suggesting hybrid styles. This also relates back to class by directly referring to agile methodologies. When referring to hybrid styles, they mention combining waterfall and agile together. I found this interesting in how there a likely many different places that use different workflow practices as well. This is also mentioned in the article as it does refer to companies choosing certain styles of workflow.

For example, it used waterfall’s extensive documentation and planning as a positive in some situations. It could be used to keep the agile method in a rough plan and sequence things more effectively. This was described to help maintain a long-term goal more concretely. By stating how the extensive early planning is, it tells of how it may be used in tandem with another style. This can lead to moments where the goal is still clear even if many short-term ones were met. In addition, it can have some flexibility by using agile’s dynamic and constant feedback to make adjustments. This could mitigate the huge commitment of waterfall.

I found this also interesting since I remember concepts of technical debt and clean code as well. Where clean code wants to reduce technical debt by taking more time to make code cleaner and more efficient to modify. I found this interesting in how both waterfall and agile could technically use it. Either by planning on certain things to build from the beginning, or opting for the modularity of relying on numerous functions. Alternatively, documentation could exist to inform on how code should be written, so long term projects are made more consistent. After all, changing too many things may lead to a lot of backtracking, so there has to be a purpose to cleaning up code in a certain way.

This is something that I should keep in mind for the future as I may need to adapt to different workflow styles depending on the company. This is also for personal use to see what flows I prefer in my work. The highlight of pros and cons also tells me I should look out for advantages and disadvantages for other styles as well. It makes things more situational and informs me to be more flexible and open-minded.

https://ones.com/blog/waterfall-lifecycle-computer-science-pros-cons/

From the blog CS@Worcester – Ryan's Blog Maybe. by Ryan N and used with permission of the author. All other rights reserved by the author.

The public and software

Link to article: https://github.blog/open-source/social-impact/software-as-a-public-good/

This article goes into detail on the relationships between the public good services and open source software and its importance. As recently many open-source software proponents went to the United Nations office in New York City to discuss the importance of open-source software for the world at large for non-profits and the private sectors of society to further society as a whole. One of the most important points that was made is the underfunding of open-source projects either due to technology not being updated or vulnerabilities being found in said software causing further security issues for public good repositories. They also stress that both private sectors and public sectors must work together to further as 80% of public good software lives on GitHub whether its properly funded or not. One of these project that the article touches upon as a public good is the PRISM project which help gathers data about geological disasters and events to better inform local governments about risks and how to best deal with a situation. The largest takeaway from the ending of the article is that proper maintenance and contributing financial or through additions to public repositories is extremely important for both public and private sectors as both rely on help from governments and individuals to maintain for long periods of time.

I chose this article due to myself supporting open-source software as a public service, Due to my use of many tools and helpful resources that come from GitHub and open-source repositories and I also the believe government should further support the trend of open-source having more funding for better projects and better legal protections. This blog post also taught me the importance of open-source software for the public good that benefits all members of society due to its ease of access and its advantages to be built off of and how the private sector also benefits from the funding of open-source projects as often times a benefit to the public good also benefits private interests

Based off of this blog post I will take further actions to support legislation and political pundits that also share the same support for open-source funding for public good systems and as well as try to further contribute to publicly available public good repositories to help with the overall lack of funding to these projects that provide a overall positive impact on society as whole.

From the blog CS@Worcester – Aidan's Cybersection by Aidan Novia and used with permission of the author. All other rights reserved by the author.

The Power of Linters

For my final self-directed blog of the semester, I decided to dive deeper into linters and their function. In class, we had briefly gone over linters, specifically their use to correct non-inclusive or problematic language. This is useful when creating any form of documentation because we want it to be as neutral and non-problematic as possible. I found a blog post from Codacy regarding information about linters, their benefits and drawbacks, and some popular linters for different programming languages.

The article starts by detailing the history of linters, they were created by computer scientist Stephen C. Johnson in 1978 as a tool used to find errors within written code. The name was a reference to the lint trap in a dryer, which was designed to catch the unwanted lint in the machine during the drying process. The linter is a useful tool for static code analysis, which is the process of examining errors in code before executing the code. According to the article, linters can help find “coding errors, stylistic inconsistencies, bugs, violations of coding standards, and potential security vulnerabilities.” It does this by checking your code against a predefined set of rules.

The benefits of linting are that it will reduce the number of errors written into code, it creates a consistent standard for coding practices, and can help improve the objectivity of code. Some argue that the downsides of linting include too many false positives and can negatively affect the performance of programmers in the early stages of development. However, it is generally accepted that linting is a useful tool and is adopted by many development teams.

Prior to this course and the activity we completed in class, I was not aware of linters or what they could do. Most of my code errors over the years would get cleaned up by the debugger in my IDE or by any error messages that came up upon execution. I was not aware of this as a tool that I could use in my development. Though I do not program often, or plan on pursuing it as a career path, I enjoy learning about all aspects of the field. The next time I have to do any kind of programming project, I will be adding a linter to my IDE so I can have a more consistent program with less errors. I enjoy learning more about all aspects of the field to become a more well-rounded academic and professional.

, ,

Source Article: https://blog.codacy.com/what-is-a-linter

From the blog CS@Worcester – zach goddard by Zach Goddard and used with permission of the author. All other rights reserved by the author.

Writing Clean Code

Clean code is about writing software that humans can easily read, understand, and change. Not just about making something that compiles and runs. The main idea is that code should communicate clearly to other developers so the intent of each part is obvious without needing to dig through the entire project or guess what the … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

Blog 4 Code Review

I am Dipesh Bhatta, and I am writing this blog entry for CS-348 Software Process Management for Blog Quarter 4. I chose to write about code review and how it connects to software process management. My chosen resource is an article titled “What is a Code Review?” from Atlassian (https://www.atlassian.com/agile/software-development/code-reviews). This passage explains what code review is, why it matters in software development, and how teams use it to maintain quality, consistency, and shared understanding across a project.

The passage defines code review as the practice of examining another developer’s work before it becomes part of the main codebase. It emphasizes that code review is more than a bug-finding activity. It helps improve readability, structure, naming, and overall maintainability. One important idea from the article is that code review serves as a communication channel. When developers submit changes for review, they are also sharing their reasoning and thought process with the team. This allows everyone to stay aligned and ensures that the project follows a predictable and well-managed workflow. These ideas directly connect to the concepts of structured processes and shared ownership that we learn in CS-348.

I chose this resource because code review is a key part of modern software process management. Throughout the semester, we used Git, branches, merge requests, and clean code practices. Code review brings all of these together into a single process that supports collaboration and project organization. Understanding how professional teams use code review helped me see the purpose behind good habits such as writing meaningful commit messages, keeping changes small, and separating different tasks into separate branches. These practices make reviews easier and prevent confusion later.

Another valuable point from the article is how code review helps reduce technical debt early. Small issues, such as unclear variable names or overly complex functions, may not break the program right away, but they make the code harder to maintain. Code review allows teams to fix these problems before they grow. This is especially important in long-term projects, where small mistakes can become costly if left unchecked.

The article also highlights the importance of giving feedback respectfully. Suggestions like “Could we simplify this part?” or “What do you think about renaming this variable?” create a more positive and productive review environment. I experienced this in class as well. The way feedback is written affects how teammates respond and how smoothly the discussion goes. Good communication makes the whole team stronger.

In short, code review is an essential part of software process management. It supports collaboration, improves quality, and keeps the codebase organized. Through Blog Quarter 4, I strengthened my understanding of reviews, communication, and clean coding practices that will benefit me in future projects and my career.

From the blog CS@Worcester – dipeshbhattaprofile by Dipesh Bhatta and used with permission of the author. All other rights reserved by the author.

Understanding Software Licensing

Software licensing is a crucial part of the software development process. It is vital to establish a license to set the legal precedent for the work that can be enforced. This blog post from “Click Up” focused on different types of licensing and monetization models.

Software licensing outlines the terms under which a program can be used, shared, modified, or accessed. Different licences can have more restrictions or more freedoms than others.

Types of Licenses from the blog

Propriety: Commercial-based, normally only gives access to use the software and does not allow any further rights. An example is Microsoft Office.

Open Source: Gives large rights for modification, sharing, adaptation, and selling of further forms of software. Some examples are GNU GPL and MIT.

Free and shareware: Freeware can be used for free but may have limited features. Shareware is software that has a free trial version to push the user into buying the full version to either access all the content or continue allowing usage. An example of this is the Adobe suite.

The blog also outlines potential terms of monetization for software and the main forms being used. The types are

Perpetual: One payment with complete ownership of the software. Maintenance may be a separate plan

Subscription: Lower upfront and user-decided cost, but recurring cost with less control and no complete ownership for the user

Usage-Based: Monitor consumption and charge based on usage. Requires metering

Pay-for-overage: User pays base fee and more if they exceed a threshold of usage. Often used in conjunction with usage-based or subscription

Device: Restricts to one or a certain paid for number of paid-for devices

Concurrent/Floating: After paying, you have a set number of uses for the software

I chose this topic due to the coverage in class on licensing topics. While we mainly covered why licensing is important and what the main types are, I wanted to learn more and look into what the other forms of application are. It was good to be able to learn more about how people work to monetize their programs and work through their licenses. One of the biggest things that I learned from the blog and to consider in my future works is in terms of licensing. While I would normally favor open-source for my own projects, in a work environment, I know that the revenue stream from the software must be considered. I now have a greater understanding of potential licenses to consider with software and what the user will be getting when they pay. I found perpetual licenses to be most appealing, and then pushing updated forms to the users or simply selling new yearly versions, as was done in the past with software before switching to a subscription-based model. This is due to my desire to have the user still owning the software while not needing a constant internet connection.

Works Cited:

Team, E. (2024, September 28). Types of Software Licenses and Models Explained | ClickUp. ClickUp. https://clickup.com/blog/types-of-software-licenses/

From the blog CS@Worcester – Dan's Blog by Daniel Fung-A-Fat and used with permission of the author. All other rights reserved by the author.

Software Licensing

For this blog entry, I chose to review the blog “Software Licensing – Terms and Licenses Explained” by CrystalLabs because software licensing connects to what we’ve been learning and working with in class. The blog explains what software licensing is, how it works, and why choosing the right license is essential for developers and organizations. It also covers the differences between proprietary software, open-source software, and other license types that decide whether people can modify or redistribute code. This ties directly into our course discussions on ownership, copyright law, and the responsibility developers have when sharing their work.

The blog begins by defining a software license as a legal agreement that outlines how software can be used, shared, or changed. Proprietary software licenses are restrictive, stopping users from seeing source code or redistributing the program. Most commercial software uses this model. The blog then explains that open-source software gives users more freedom, but the level of freedom depends on the specific license. Permissive licenses like MIT or BSD allow people to reuse the code in pretty much any way they want, including in commercial applications. Copyleft licenses like GPL require that any modified version remains open-source under the same license, protecting long-term openness. The blog also briefly touches on public-domain software, where the creator essentially gives up all rights.

I selected this resource because software licensing is something that is extremely important but I didn’t fully understand. Since we are studying software licensing in class, learning how and when I can use someone else’s code is crucial. It isn’t just about making software work, developers must consider legal compliance and respect for the original author’s intentions.

What stood out to me was how much power a license has over the future of a project. One document can determine whether software becomes a community project or remains locked behind a licensing wall. Now I understand that licenses shape the project itself, being an essential part of the start of any work. This made me more aware for future software that I work on later down the line, I will need to purposely choose a license that matches my goals.

Overall, this resource helped me better understand software licensing as something tied to ethics, law, and user rights. I’m definitely more prepared to navigate licensing in my future work, the software I use and create will be properly licensed with this knowledge in mind.

https://crystallabs.io/software-licensing

From the blog CS@Worcester – Coding with Tai by Tai Nguyen and used with permission of the author. All other rights reserved by the author.

Licensing Your Projects

Sources: Codecademy, TLDR Legal, and Choose A License

Choosing a License

All projects should have a license, but choosing a license for your project can seem daunting. By breaking it down into simple goals you want to achieve, the process can be much easier! 

First, choose how you want your users to interact with your project. Do you want to preserve your original code in future versions or do you want users to be free in how they modify it? There are two main kinds of licenses to choose from, permissive and copyleft. 

Permissive licenses do not restrict the user from modifying the code or using it how they like. Some popular examples are the MIT license and Apache license. Both of these licenses state the user can modify, distribute, and sublicense the code how they want, and do not require future versions to use the same license. 

Copyleft licenses preserve the original code and protect the creators and users. Some examples of a copyleft license are General Public license (GPL) and Lesser General Public license (LGPL). Both of these licenses allow the users to modify and distribute the code how they like, but require the same license to be used on all future versions and require user protections like install instructions and a change log. 

One license is not better than another, all that matters is that your project has a license and it’s what is best for you. If you are still unsure of which one to choose, try looking at the licenses of similar projects or projects from people like you. 

Why Do You Need a License

Licenses state the rights of you as a creator and of all the people that interact with your code. Without a license, users do not know where you stand on using, modifying, and sharing your work. Attaching a license allows you to have peace of mind your code is being used how you want it to and allows people using your code to have it clearly laid out what they can and cannot do with your work. 

Choosing a License For Your Code’s Documentation

Now that you have a project with a license, you need to apply a license to your documentation as well. Most of the time, it will use the same license you chose for the code by default, but in the case you do not want it to, you can choose any license that you feel applies.

From the blog ALIDA NORDQUIST by alidanordquist and used with permission of the author. All other rights reserved by the author.