Category Archives: Week 4

The Definition of Done (DoD)

How to write a Definition of Done

CS-348, CS@Worcester, Week-4

Source Article: https://www.atlassian.com/agile/project-management/definition-of-done

Recently, in doing a project in class, I had to write a Definition of Done (DoD) file for my portion of the project. I had a basic understanding of what needed to be conveyed, but not exactly how to convey it. I wanted to know more. I looked further into what the industry standard is, and that’s how I came across this post, which I used to help me figure out the one for my project.

I recall from the previous class activity that we looked at the Scrum Guide by Ken Schwaber and Jeff Sutherland, and the guide did give information on what the Definition of Done was and what it is meant to convey, but I wanted something more in-depth.

According to the article, the Definition of Done is a shared set of criteria that tells a Scrum team when a product increment is truly complete. The specifications contained are not created by one person but agreed upon by the entire team because there needs to be a shared understanding of what’s expected at the end of each sprint and for the project overall. This is needed to avoid miscommunication and make sure the team adheres to the pillars of Scrum: transparency, inspection, and adaptation. The developers of the team have the responsibility of parsing out what the DoD will be continuously as it will evolve and change as increments pass.

I knew that whatever was agreed upon needed to be something that is measurable and testable, otherwise there would never be a satisfying way to declare being done. But the article mentioned something about the DoD needing to also be “ready to ship”. This means that there can be no hidden work left after the spring, and there can’t be extra polishing stages.

The most helpful portions of the article were the examples that were provided of what can be included in a DoD. Here are some of them./

  • Increment Passes SonarCube checks with no Critical errors
  • Increment’s Code Coverage stays the same or gets higher
  • Increment meets agreed engineering standards
  • Acceptance Criteria for Increment pass
  • Acceptance Tests for Increment are Automated

Most of the examples include the project passing specific tests or meeting certain standards that would be either required by the client or the organization the team is working for, which is par for the course. The DoD is an important part of Scrum, and I need to understand how to think of a project in order to write one in future cases.

From the blog CS@Worcester – A Beginner's Journey Through Computer Science by Christiana Serwaah and used with permission of the author. All other rights reserved by the author.

Blog 4 – Software License

In our world, when you want to drive a car outside the public, you would need a driving license to do so. This is because you need the permission to use the road freely. Also, if you want to go fishing, you also need a fishing license, this gives you the permission to fish at any public lake or public fishing area. As we know, license provides you the authorization to access something that requires from someone’s permission. Same with software engineering, in software, we require license to access someone’s code or project. It grants right for you without transferring ownership from the author. However, there are multiple types of software licenses, each has their own function. I will explain everything in this blog based on what I read from https://finquery.com/blog/software-licenses-explained-examples-management/

What is a software license?

A software license is a legal agreement between the software creator/provider and the user (individual or organization) that defines how the software may be used. It doesn’t transfer ownership — it grants rights.

The license specifies things like how many devices you can install on, whether distribution or modification is allowed, and other restrictions (or freedoms) depending on the license type.

How licenses work & why they matter?

When you obtain software, what you actually pay for is the right to use that software under certain terms, not the software itself.

Licenses protect the intellectual property rights of developers, control distribution, and can also allow or forbid modification. That helps prevent piracy and misuse.

Before using software, users often must agree to an End User License Agreement (EULA) — a legally binding contract defining permitted and prohibited actions under that license.

Common Types of Software Licenses

  • Public domain license: No restrictions — software is effectively “free for all.” Anyone can use, modify, relicense, or commercially exploit it without needing to pay or give credit.
  • GNU Lesser General Public License (LGPL): Open-source license allowing developers to use/license the code in their own projects without having to release their own source code.
  • Permissive license: A flexible open-source license with minimal restrictions — typically just requiring attribution/copyright notice on redistribution. Common in open-source community
  • Copyleft license: More restrictive open-source license: if you modify and distribute the software, you must also make your version’s source code freely available under the same license
  • Proprietary license: Most restrictive — software remains proprietary, users get limited rights; typically no access to source code, and strict limits on copying, sharing, modification, or redistribution.

Software License Management

Because organizations often use many pieces of software (some licensed, some subscription-based), managing this properly is important. The article recommends:

  • Keeping a centralized inventory of all software licenses and subscriptions used within the organization.
  • Tracking license usage, renewals, and compliance — ideally via a dedicated license-management tool rather than manual spreadsheets.
  • Establishing reminders for renewals and conducting regular audits to avoid under- or over-licensing, penalties, or wasted spending

Conclusion

If you ever find an interested code, or project, that you want to install it in your computer or use it as references, make sure to keep an eye on its license. Identify its type, and follow the permission it allows. This keeps you avoid any legal risks, control costs, and efficiently manage software assets.

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

Week 4 – CS 343 Blog: What is front-end?

Have you ever wondered everything you see on your phone’s screen in any of applications you clicked on, how do they work that makes you be able to interact with it? Of course, they’re programmed by the programmers, but in order to design the app and allow users to interact with the app, it’s not just about programming, it’s a whole process of implementing what is called “Front End”. So, what is front-end? Why does it matters in building an application or website?, who takes control of it? Everything will be explained in this blog based on what I read from https://airfocus.com/glossary/what-is-a-front-end/ by airfocus, “Front End (in website).

What is front end?

The front end refers to everything a user sees or interacts with when using a website or app. That includes layout, design, buttons, navigation menus, images — in short, the look and feel / user interface.

Technically, front-end work is implemented using web languages like HTML, CSS, and JavaScript.

In contrast, the back end handles behind-the-scenes functionality: data processing, business logic, server communications. The front end and back end together must work smoothly to deliver a good user experience.

Why Font End decisions matter?

According to airfocus, front-end design is critical for product success because:

  • User engagement & satisfaction: A well-designed front end makes it easier and more enjoyable for users to interact with the product — reducing friction, boosting clarity, building trust.
  • Ease of iteration and experimentation: Clean, intuitive front-end design allows product teams to iterate faster — experiment with UI/UX improvements, adjust features based on feedback, without overhauling the whole system.
  • Brand perception & consistency: A consistent, polished front end across platforms (web, mobile, etc.) strengthens brand identity and trust. A clunky or inconsistent UI risks undermining user perception of the brand

Roles & Collaboration: Who shapes the front-end — and how product leaders fit in

While front-end code is done by engineers / front-end developers, product managers (or product leaders) have a crucial role: they translate user needs and business goals into clear priorities for what the front end should deliver.

Product leaders don’t need to write code — but they should understand dependencies between front-end and back-end, and advocate for a user-centered design that balances business constraints, technical constraints, and user experience.

Effective front-end strategy means collaborating with design and engineering leads, making trade-offs transparent, and using structured planning tools (roadmaps, scoring, templates) to guide front-end work.

Conclusion

Overall, front-end developers is a very important position in building an app, or website. Specifically, front-end is like an appearance of what you can see and interact with within the app. If there is no front-end implementation, there is no app or website even exists.

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

API Security Practices

As we continue to study API implementation in my CS343 class, I find it important to continue to learn more about the subject. I came across this article that discusses 11 security practices for API implementation. A statistic I found interesting that is brought up at the beginning of the article is that APIs now account for more than 80% of internet traffic. The first practice listed is continuous API discovery. This means automating processes that catalog APIs across your infrastructure in real time. Doing this helps prevent the deployment of shadow APIs. The next practice is encrypting traffic in every direction. This one seems fairly obvious, but it is something that cannot be forgotten. The article also lists some key encryption requirements. Authentication and authorization are very important practices for API implementation as well. This allows for control over the usage of the APIs in the system, and it protects the user by keeping their primary credentials hidden to prevent theft and misuse. Using the Principle of Least Privilege is another good practice. Granting users the least amount of privilege necessary to use the system prevents damage from a malicious user. Documentation is also very important to help other developers maintain the system in a safe way. You must also validate your data to help protect against injection attacks. Make sure to limit data exposure as well. Data breaches are an issue that no one wants to deal with. The article lists a few more practices that are important for security in systems that use APIs.

This particular article stuck out to me because, as I said in the beginning, we are learning about API implementation in my CS343 class. Knowing the typical security practices for implementing APIs is imperative for creating a good system. It’s something that many may overlook, but cannot be omitted. I myself had failed to consider the potential security risks of implementing APIs. This article gave good insights on the security risks and how to prevent them. This was definitely worth the time it took to read and understand. It is always important that the data going through your system is protected to ensure that the users have a problem free experience. The problems that could possibly arise from a lack of security could result in huge losses for a company deploying these systems. As someone who has not had to deal with that kind of risk yet, I believe it is important I learn about these potential issues before it becomes too late.

https://www.wiz.io/academy/api-security-best-practices

From the blog CS@Worcester – Auger CS by Joseph Auger and used with permission of the author. All other rights reserved by the author.

Understanding GitHub

Quarter One Blog

The video I watched is a basic tutorial for GitHub. Corbin, the creator, explains that GitHub is essential for version control and organization, and how important it is when your code becomes more complex. He starts off by explaining what a repository is and how to make one in GitHub. Then, he shows one of his repositories for a project with a working program. He says if he wants to start making changes and adding to the code, he would create a branch to prevent the code from breaking and save a lot of time if he needed to backtrack and fix it. He shows how to make a branch, as well. He provides the basics for what we went over in class and in GitKit chapters and explains how to do it in a slightly different way than what was said in class. I chose this video because I find it useful when I have multiple ways to explain a topic and I can understand it better.

The process for creating a repository is not something that we went in depth on in class, so having Corbin explain how to go through that process was helpful. He touches on what the difference between public and private repositories are. In class and in FOSS applications, they would all be public repositories, but if you were just using GitHub to put your private code in the cloud and for your own version control, a private repository would be more useful.

Corbin provides a visual and explanation for what branches and forks do, but it is not as clear as what was shown in class. Having the different explanations of both is helpful for a deeper understanding. He goes over having a completed branch, how to merge it back to main, and explains what the version control deletions and additions look like. 

Outside of the Software Process Management class, understanding GitHub is super useful in the real world. Other classes, like the Software Development Capstone, will require the understanding of GitHub to complete the final project. A lot of companies use Git for version control and collaboration, and look for those skills on applicants’ resumes. I feel confident and comfortable that I can navigate and use GitHub in my life going forward. 

Last year, I took Software Testing before understanding Git. While I was able to figure it out and get through the class, having the knowledge I do now with the actual process and reasonings of it, I feel like I would’ve spent less time troubleshooting silly issues.

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

Learning the Basics of Software Copyrighting and Licensing

When I first started studying how code and software is protected by law, I was lost. I’d never explored the realm of who owns what, or when one can utilize another’s code. I decided to delve further into these concepts after I was inspired to by a software development course.

I came across two fantastic pages on TechTarget, one on software licenses, and the other on copyright (1,2), that covered many topics of software law, including what licenses and copyrights are, do, and where they come from. Through reading these pages, I developed a better understanding of the these legal topics.

Licenses

Licenses are contracts between the people who developed or own the software, and the people or organizations who want to use the software. They cover how the software can be used, what the rights of the owners are, and what the users are allowed to do with the software. They can also include how the software is paid for, how many copies can be downloaded, or what level of access to the source code users can have.

This image from TechTarget gives an overview of strictness of different types of software licenses. To apply a license to software, the legal text of the license must be included with the software when shipped. This can be accomplished by including a file called “License” that contains the legal text alongside your software.

Obtaining a license from the software owner generally involves paying the owner to use the software. An example of this exchange is when someone purchases a video game. The person pays the price of the game, accepts the end-user license agreement upon loading the game up, and can then use the software forever.

This concept of payment for license is essentially the same when scaled up for business applications. One company can pay a software company for the license to utilize their software. This will likely cost more money than purchasing a video game, and can potentially involve other stipulations depending on license choice.

Copyrights

Copyright prevents others from copying or otherwise exploiting your creations, but works differently than licensing. For one, copyrighting in most countries, including the USA, is automatic. When software is written, the developer, or company the developer works for, automatically gains copyright over that work. This prevents others from stealing, reusing, or altering the work without permission. The copyright holder can also formally apply for a copyright with their country’s relevant organizations.

Interestingly, copyright can have a time limit in terms of years, with some companies, such as Disney, fighting to lengthen or alter the laws to allow them to protect their original mouse design for as many years as possible.

One huge difference with copyrighting is that someone else can use parts of your work legally without specifically asking you or your company. This is called “Fair-Use” by the non-owner, and includes uses such as for criticism and comment, parody, education, public good, and non-commercial activities.

From the blog CS@Worcester – KeepOnComputing by CoffeeLegend and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.

Design Patterns, and other such oddities

 This week we discussed design smells (which I find endlessly amusing from a name standpoint), as well as the concept of design patterns. As a whole, design patterns are something that I had never thought of before now, though it makes perfect sense in retrospect. Programmers often run into the same kinds of problems or requirements for a project, so it makes perfect sense that we would have a set of designs that help to alleviate some of the problems surrounding them. I’ve always been one to writer code from scratch, or look up how to set something up in a basic sense, but these more abstract concepts aren’t something I had put much thought or research into. The article I’ve chosen to read for this week is “The Problem with Patterns” from A List Apart ,which is a
blog that specializes in having many writers from the Computer Science
industry comment on various issues and topics. I figured that it would be a good idea to look at some of the problems with patterns, so maybe I could learn to avoid them, while using them for the first time.

   The article talks about the problems with using design patterns, mostly from the perspective of the prospective user. Design patterns are good from the perspective of getting software completed and modular for the future, but most commonly used patterns focus more on just that, getting code done, rather than focusing on making it as usable as possible. This is compounded by the fact that since many designs are so readily available, it encourages programmers to use them without maybe understanding how they fully work, or the ramifications of using them in the first place. A design might look like it works for a specific purpose that suits your needs, but it most likely cannot be used for everything, so it requires more thought than just implementing them and being done with it. 

   We’ve mainly focused on one design pattern in class, the strategy pattern, but we’ve also been very good about mentioning some of the potential downsides of using it (Additional objects, more required knowledge, etc). After reading this article, I hope we remain this informed about any other patterns we might talk about. I can see that it would be incredibly easy to not think about the needs of your users and therefor make it much worse to use by not paying attention to the patterns I use, so overall, I think I’m just going to be more mindful of my programming overall. Patterns are great, but there’s always a place for time to be spent on the designs of my code.

 

ARTICLE LINK: https://alistapart.com/article/problem-with-patterns/ 

From the blog Camille's Cluttered Closet by Camille and used with permission of the author. All other rights reserved by the author.