Category Archives: CS-348

Scrum VS Kanban

The first step down my professional development path to become Agile involves understanding different Agile methodologies. The two most popular being Scrum and Kanban. Cassidy Knight does a great job comparing the two Agile methodologies in her blog, “3 Differences Between Scrum and Kanban You Need to Know.” (https://www.cprime.com/resources/blog/3-differences-between-scrum-and-kanban-you-need-to-know/) Knight starts the blog off with an easy to read table illustrating the three main differences are found in team roles, work boards, and the scheduling/cadence of the workflow.  She breaks down Scrum and Kanban individually for better understanding of how they are similar, before diving deeper into the three differences.  The blog finishes up with explaining that there is no clearly defined better methodology, but rather that they each have things that work better for different teams. 

Scrum

Scrum consists of breaking up large projects into small manageable tasks to be completed through several scheduled iterations called sprints.  During these sprints the Scrum Team, consisting of a Product Owner, Scrum Master, and Developer work together to design and build new features for a project.  Each new feature is broken into story points that are prioritized by the Product Owner in the project backlog.  The Scrum Master then selects what points will be moved to the sprint backlog to be worked on in the following sprint based on the priority and size of each point. 

Story points are tracked through the sprint on the Scrum board. The Scrum board breaks down workflow into columns, starting from the backlog, to work in progress, to completion. Each story point is given a limited amount of time to be worked on during the sprint. Scrum boards only show the work done for that sprint and are wiped clean after each sprint. Work produced by a Scrum team is evaluated at the end of the sprint and is found successful if all of the story points have reached the team’s definition of done.

Kanban

Kanban, unlike Scrum, does not work in scheduled iterations.  Instead, the workflow in a Kanban is limited by the amount of story points in each column of the work board.  Instead, each team may be made up of specialists that only handle work from the board that suits them.   The work board in a Kanban is like the one found in Scrum with the major difference of each column having limits to how many story points may be in each.  This means a “work in progress” point must be finished before a new one may be opened.

Using Scrum and Kanban Moving Forward

As I continue to learn how to work in agile environments, I will learn what parts form each of these methodologies that work well for me and my team.  Applying practices from many methodologies to create a hybrid methodology may be the best way to move forward. It all depends on the project and the team.

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

Licensing Software

Overview

In order to be able to use someone else’s software for your own software project, you must attain a software license. This license establishes the rights and limitations that you have when using the product owner’s software. Software licenses are attained by licensing agreements, where you sign a contract with the owner of the software to use the patented technology.In that contract contain the rights, responsibilities, and limitations you have as a user. I think if you develop some sort of software, it is crucial that you and your team are recognized as the owners of it, and that outside users don’t use it however they feel like. There are many types of software licenses that have different terms and conditions. An article that I read by Ben Lutkevich went more into depth of what a software license and agreement will usually look like, as well as the different types.

Attaining a License

You are about to sign the licensing agreement to officially be able to use someone else’s software. Here’s what to expect. On it will be basic information about both sides. Your name, your address, contact information, as well as the lending party’s. It will contain when the agreement officially goes into effect, and you are able to use the software. It will contain the duration of how long you are able to use the software. It will include how much you have to pay for the software, how many users are eligible. It will give a disclaimer of warranties, as well as maintenance, upgrades and support. Most importantly, it will include the permissions and limitations on distributing the software, user rights of copying and modifying the software. These licensing agreements may differ depending on the type of software license.

Types of Software Licenses

The most common software licenses you find are Proprietary and FOSS. A proprietary software license is commonly referred to as closed-source. Proprietary licenses do not allow users to freely alter the software. Whereas FOSS (Free and Open-Source Software) is the opposite, where the customer is allowed to use the source code and alter the software. FOSS is commonly referred to as open-source. This is the type of license that we will be using in class. Two other licenses that are familiar are Permissive and Copyleft. Permissive software licenses establish some requirements for distribution or modification of the software, and Copyleft notes that licensed code may be distributed or modified as part of a software application or project if all code involved is distributed under the same license. New products containing old code with a copyleft license have the same restrictions as the old code’s license.

Conclusion

If planning to create a software product, it is a smart idea to establish copyright for it, so you are credited for the work you put in. And if you are using someone else’s product for your own product or project, it is the smart decision to attain a licensing agreement, avoiding any potential lawsuits.

Article URL

https://www.techtarget.com/searchcio/definition/software-license#:~:text=A%20software%20license%20is%20a,the%20software%20without%20violating%20copyrights.

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

Week 8

Copyright and Licensing in the Time of COVID-19

The contents that I have been learning in this week is about the software license and copyright. I found this blog giving the general definition of these contents and in the time Covid-19.

For many instructors who just want to do what is right, the reality that copyright is complicated has been made worse by the significant transition to distant learning. The fact that over 900 individuals took time out of their days to watch the webinar is proof that copyright education is necessary.

Many publishers combined helpful content, offered free teaching aids, and canceled copyright costs for online learning during the pandemic. Many pieces of content were utilized without the copyright owners’ consent; some were used for legal “fair use,” others were used carelessly, and some were exploited for opportunistic purposes.

Five significant developments emerged in the licensing and reuse of protected information between March and June 2020:

  1. Print photocopying vastly increased as students lost access to materials in the classroom.
  2. Online learning platforms and other EdTech tools gained traction.
  3. Publishers created no-cost licenses to enable teaching under these new circumstances.
  4. More assessments moved online.
  5. Teachers taught using materials they copied or posted online, sometimes underpaid or free licenses, sometimes under fair use, and sometimes by committing infringements that rightsholders were willing to ignore.

Remote learning during COVID-19 resulted in an increasing number of queries about copyright, licensing, and practices for universities, schools, and academy centers as they seek to ensure better compliance.

A license is a permission given to use a property or to exercise rights belonging to another under agreed conditions. Copyright is the exclusive right of the creator of a work or her designees to make copies of that work. In order to reach a conclusion that a use was or was not a fair use, the judge has to analyze all the following factors:

  1. The purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes.
  2. The nature of copyrighted work.
  3. The amount and substantiality of the portion used in relation to the copyrighted work as a whole.
  4. The effect of the use upon the potential market for or value of the copyrighted work.

This blog provides educators with a deeper understanding of copyright, its relevance to remote learning, and strategies for managing copyright compliance while using published resources in this new paradigm.

From the blog CS@Worcester – Hong Huynh-CS348-WSU by hhuynh3 and used with permission of the author. All other rights reserved by the author.

Week 7

In this blog, we are going to learn about Scrum development framework and why its important. Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. The Scrum team consists of one scrum master, one product owner and developers and there are no sub-teams or hierarchies. The good thing about a scum team is that it is cross-functional meaning all the members have all the skills necessary to create value each sprint. Usually, the scrum team has 10 or fewer people and this helps teams communicate better and be more productive. The scrum team is responsible for all product related activities from stakeholder collaboration, verification, maintenance and more.

The blog I chose talks about the getting started as a scrum master and some of the steps to getting started. Some of the steps in the blog to getting started are getting to know your new team and this is important to understand who’s in the team and building healthy relationships. It is also important to understand your new team’s purpose and goals because sometimes action is confused with progress and it’s crucial to know what’s driving them. Mapping out the stakeholders is important because as a scrum master, you’re responsible for ensuring the team can run as efficiently as they can. When you’ve identified a tricky stakeholder, you can work with them to ensure they interface with the product owner rather than the team. Another important aspect as a scrum master is asking your team if the Agile framework like scrum is working for them. This is to make sure the team is aligned on different things like sprint planning. Looking after yourself and development as a scrum master is one of the most important steps when starting with a new team. This is because the role of a scrum master requires you to think differently a lot of the time which can be tiring therefore you need other people to get advice from or to bounce your ideas off.

I think this blog post gives an insight of the role of a scrum master in more detail. It explains some important aspects involved with being a scrum master and what the role looks like. The scrum team consists of other members like developers who keep the database working and product owner who is responsible for commuting the product goal and what it should do. This goes to show that this isn’t a one man’s job, and several people are required for completion of a successful task.

References.

5 Steps To Getting Started With A New Team As A Scrum Master

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

What it Means to be Agile

If you search online for Agile methodology blogs, you will find a lot of them mentioning what it means to be Agile by referencing the 4 main values and 12 principles from the Agile Manifesto. (https://www.agilealliance.org/agile101/the-agile-manifesto/).  While these core values and principles define what it means to be Agile, I was looking for more of a general definition. In my quest to discover what it means to be Agile in today’s software development world, I have come across a blog that, in my opinion, does a great job in explaining that. “What is Agile methodology? (+ how you’re already using it)” (https://www.lucidchart.com/blog/what-is-agile-methodology) starts off by giving a great, simple, explanation of Agile methodology: “Agile methodology breaks the developmental process into iterative steps and encourages flexibility, testing, and change throughout the life cycle of a project.”.  The simplicity of this definition really drives home how intuitively flexible this methodology is and how so many different frameworks are able to adopt Agile methods.

How To Adopt Agile Methods:

The blog has a great analogy for Agile methods being like a detailed to-do-list. Prioritizing must-have features to add to a project is the first step in being Agile. Step two involves estimating the time required for each feature and adjusting priorities as needed. Lastly, step 3, involves setting up a schedule for a sprint.

Importance of Iterations:

Sprints are typically two week periods where the team has prioritized features they are working on. The goal of each sprint is to have a working product that has been tested by the end. Having a working product at the end of each sprint allows the stakeholders to have input on the current development and the future plans. Further emphasizing the need for flexibility as a project can shift focus at any point in development. 

Agile Frameworks:

There are so many Agile frameworks already designed, such as Scrum, Kanban, and XP, just to name a few. With so many to choose from, where do you start? The beauty behind the flexibility of Agile methodologies is that no framework is rigid either. This means each team can adapt processes that work for them. 

Using Agile Methods Moving Forward:

As I will be working in Scrum teams, I hope to develop skills to maintain an agile environment for me and my team. Staying flexible to change while following the values and principles of the Agile manifesto will help me develop skills needed to work in a professional environment.

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

Copyright and licenses in Software creation.

In today’s technology-driven world, software development has become a cornerstone of innovation. Whether you’re a professional software engineer or just a hobbyist coder, understanding the legal aspects of software creation is crucial. This blog post explores copyright and licenses in the realm of software development, shedding light on how they affect developers and users alike.

  1. Copyright in Software

Copyright law plays a pivotal role in protecting the intellectual property of software creators. When you write code, you automatically gain copyright protection over it. This means that no one else can copy, distribute, or modify your code without your permission.

Key points about copyright in software:

  • Copyright protection is automatic: As soon as you create code, it’s protected under copyright law, without any need for registration.
  • Exclusive rights: Copyright grants you exclusive rights to control how your software is used, reproduced, distributed, and modified.
  • Duration: Copyright protection typically lasts for the lifetime of the author plus 70 years, or for a set period in the case of works created by corporations.
  1. Open Source and Licensing

While copyright protects software by default, developers often choose to use open-source licenses to specify how others can use their code. Open-source software is critical to the tech industry, fostering collaboration and innovation by allowing others to use, modify, and distribute the code.

Key points about open-source licensing:

  • Types of licenses: There are various open-source licenses, including the MIT License, GNU General Public License (GPL), Apache License, and more. Each has its own terms and conditions.
  • Permissive vs. copyleft licenses: Some licenses are permissive, allowing for wide usage, while others, like the GPL, enforce certain restrictions to ensure derivative works remain open source.
  • Attribution: Many open-source licenses require users to give credit to the original author when they use the code.
  1. Proprietary Software Licenses

Not all software is open source. Proprietary software is protected by strict licenses that limit how it can be used, modified, and distributed. These licenses may restrict users from viewing or modifying the source code.

Key points about proprietary software licenses:

  • Closed source: Proprietary software is typically closed source, meaning the source code is not freely available for inspection or modification.
  • End-user agreements: Users must agree to terms and conditions specified in end-user license agreements (EULAs) before using the software.
  • Restrictive vs. permissive licenses: Proprietary software licenses can vary widely in terms of the restrictions they impose on users.
  1. Dual Licensing

Some software developers choose to offer their software under both open-source and proprietary licenses. This approach allows them to provide a free, open-source version while also offering a commercial version with additional features and support.

Key points about dual licensing:

  • Monetization: Dual licensing provides a way for developers to generate revenue from their open-source projects.
  • Flexibility: Users can choose the license that best suits their needs, depending on whether they want a free, open-source version or a commercial one with extra features.
  1. Compliance and Enforcement

Both open-source and proprietary software licenses come with rules and conditions that must be followed. Non-compliance can lead to legal action and damages.

Key points about compliance and enforcement:

  • Legal consequences: Violating a software license can result in lawsuits, injunctions, and monetary damages.
  • Compliance tools: There are tools and services available to help developers and organizations track and ensure license compliance.

Conclusion

Understanding copyright and licenses in software creation is essential for developers and users. Whether you’re contributing to open source, building proprietary software, or using software created by others, awareness of these legal aspects is vital for fostering collaboration and innovation while respecting intellectual property rights. Always be sure to read and adhere to the terms and conditions specified in software licenses to avoid legal complications and contribute positively to the software development ecosystem.

From the blog cs@worcester – A Journey through CS by mgl1990 and used with permission of the author. All other rights reserved by the author.

Week 7: CS-348

Version Control

Version control is a software development process that tracks and manages every change made to a code base. Tracking changes allows developers to be able to see what changes were made, who made them, and when they were made. The history of these changes enables developers to revert changes back to previous versions in case of any irreparable damage.

Version control allows for multiple developers to work on a project concurrently. When multiple changes are made at once, conflicts can occur. Version control can identify those conflicts to allow development teams to quickly compare the changes and decide how to handle the conflict. Version control streamlines coordination, sharing, and collaboration.

Types of Version Control Systems

A version control system (VCS) is the system that tracks changes made to files. Common types of VCSs are distributed and centralized, the latter being most common.

Centralized VCS (CVCS)

In a centralized VCS, all files are stored in one central repository where developers work in. The central repository can be hosted on a server or on a local machine. CVCS is most commonly used in projects where teams need to share code and track changes.

Distributed VCS (DVCS)

Distributed VCS store files across multiple repositories, allowing developers access to files from multiple locations. DVCS is often used when developers need to work on projects from multiple machines or who collaborate with others remotely.

Lock-Based

Less commonly used, Lock-Based uses file locking to manage concurrent access to files and resources. File locking prevents more than one user to make changes to a file or resource at a time, eliminating conflict changes.

Optimistic

Optimistic VCS gives every developer their own private workspace. Once changes are made and are ready to be shared, a request is made to the server. Then the server looks at the changes and determines which can be safely merged together.

Popular Version Control Systems

Git

The most popular of version control systems. Git is an open-source distributed version control system that can be used with software projects of any size. This makes Git a popular choice for most, no matter the project.

Subversion (SVN)

Subversion is a centralized VCS; therefore, all project files are kept in one main repository. This makes branching impossible, allowing for easier scalability for large projects. A form of file locking is in place, allowing users to restrict access to subfolders.

Mercurial

Mercurial is another distributed version control system. Mercurial offers an intuitive command line interface that allows developers to use this system immediately.

Conclusion

I chose this resource because it clearly explains what version control is and why it’s important. Before reading this article, I was unaware of the different types of version control systems, and the popular choices that implement them such as Subversion. I also learned when each type of VCS might be more useful than another. This is only the beginning of my knowledge of version control systems. As my journey into software development continues, my understanding of VCSs will only broaden.

Resources:

https://about.gitlab.com/topics/version-control/

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

Agile & Scrum

The podcast episode, “Scrum vs Agile & Keys to Success with Mike Cohn,” discusses the ways to succeed using the Agile methodology and how to work with the Scrum Guide to create an efficient plan for your team. I selected this episode because I believe that one of the major aspects of creating an efficient team is the steps you take to complete your work. To do that, you must follow a methodology to create a plan to complete your goal. In class, we learned about Agile and the advantages it had over waterfall, so listening to a podcast about Agile was very intriguing. The episode emphasizes that you don’t have to adhere to the Scrum Guide as if it were a rule book, and that you have to work with your team to find out what aspects of the guide work best within the team to allow for maximum efficiency. This is a big mistake that many people make because they are scared of “breaking the rules.” However, this is something that one must be able to do if they want to elevate their work to the next level. From this, I thought the podcast was very interesting since we recently learned about these methods in class. In class, we discussed the steps of Agile and the benefits it has compared to the waterfall methodology that we learned about prior. In addition, we also learned about the Scrum Guide, where we were taught the aspects as well as the elements that the Scrum Guide highlights to help users understand Scrum. From our work, we were shown that you are allowed to deviate from the Scrum Guide; it is just a basic framework to help users put the steps in an effective order. After the episode, I believe that it gave valuable insights on how these methods work in real company settings, highlighting how you don’t have to follow the guide to a tee and you must find out what works best for your team to allow for the most efficient work. Plus, through the discussion of real-world examples, it promoted further thinking about what we learned in class as well as how to connect the ideas we were taught to work experiences. Once it comes time for me to apply this to my work, it will be helpful to understand that the Scrum Guide is not a rule book but a guide to take aspects from to assist in efficient teamwork.

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Exploring the Classical Waterfall Model in Software Development

In most respects the classical waterfall model serves as the foundational software development life cycle (SDLC) model, almost embodying a structured and sequential approach to project management and software development which can prove effective when doing a variety of coding projects. While it may not be as commonly employed today, its significance lies in being the basis upon which other SDLC models have evolved, the process often involving steps and details with which have been planned beforehand. This model finds its relevance in the realm of more large, complex projects, being a model characterized by its rigorous, phase-driven progression, making it suitable for scenarios where project requirements are well-defined, and project stakeholders seek a high level of confidence in the outcome.

The waterfall model, although now less prevalent in contemporary software development considering it’s lesser effectiveness compared to more agile methodologies , it remains a foundational framework for understanding software development life cycles. This model’s structured, sequential approach entails phases like requirements gathering and analysis, design, implementation, testing, deployment, and maintenance, each building upon the preceding one. It is a document-driven model, placing high importance on quality control and rigorous planning, thus ensuring that the project is well-defined and the team operates with clarity and precision.

it becomes pretty clear that the simplicity and linear progression that come with the waterfall technique offer advantages for specific project scenarios. This approach favors discipline, with a focus on defining requirements before design likewise with the design before coding. For smaller, well-understood projects, it can be effective in maintaining clarity and ensuring milestones are met.

At the same time though, the rigidity and limitations of the waterfall model become apparent in more complex, dynamic projects. Its lack of flexibility to accommodate changing requirements and late defect detection pose significant challenges. The sequential nature of the model restricts stakeholder involvement in later phases, potentially leading to misunderstandings and costly revisions.

in practice, project managers and development teams should carefully assess project requirements, size, complexity, and the degree of uncertainty to select the most appropriate SDLC model since the waterfall method might not always be effective, sometimes proving to be an unwieldy method for projects better suited to adaptability. Moreover, hybrid approaches, combining elements from multiple models, can offer the best of both worlds, allowing for structure and adaptability.

In conclusion, the classical waterfall model, while valuable for certain projects, is not a one-size-fits-all solution. Its use should be considered in situations where requirements are well-defined and change is unlikely, such as large-scale, safety-critical, or government projects considering these have a tendency to have big budgets and therefore need to be mapped out when taking into account the money spent on particular projects. In today’s rapidly evolving software landscape, more adaptive SDLC models have gained prominence, offering flexibility and responsiveness to changing needs.

https://www.geeksforgeeks.org/software-engineering-classical-waterfall-model/

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.

Software Licensing Compliance

The article I chose for this week’s blog post is “A PRIMER ON OPEN SOURCE LICENSE COMPLIANCE” by Dasha Gurova. This article discusses what Open Source Licensing is, what software licenses are, why you should implement an open source license compliance policy, some examples of semi-automated OSS compliance tools, and how to use OSS (open source software) compliance systems. I will be discussing the ways of implementing OSS compliance systems mentioned in the article, those being the manual and semi-automatic methods, and their strengths and weaknesses.

The methods the article mentions for maintaining OSS compliance are manual and semi-automatic. The manual process is a very time-intensive approach and an old-school approach. “A surprising number of companies are still using this approach. Basically, you create a spreadsheet and manually fill it out with components, versions, and licenses and analyze it against your policy.” The article also says that this method can be very effective on smaller projects if implemented early in the project’s development. This method would entail reviewing and logging the software’s license before implementing any components from the open-source software. However, if not implemented early, using this method can be very difficult to execute properly. This method also becomes much more challenging to maintain as your project uses more and more OSS components. Especially to make sure the licenses that you are using do not conflict with one another and are being adequately implemented. These issues can be made worse especially when this method is not being maintained properly, in addition to being used in a large project.

The other method mentioned in the article is the semi-automatic method. “This is a more reliable approach and is becoming more popular, as the importance of open source compliance practices grows along with the risks associated with ignoring these practices. There are many tools available, in a way that it gets overwhelming. Why semi-automated? Because there are always false positives if the license is not explicitly referenced in the header and you still have to read through some of them to discover special terms or conditions.” As mentioned in the article, this method is far more reliable but teams that use this method must be vigilant to see if the warnings that the tools give are false positives. If the team using this system just assumes all the warnings are completely accurate this could lead to a lot of headache trying to find other OSS that would comply even though you already had OSS that would work.

Article: https://www.zenko.io/blog/get-started-with-open-source-license-compliance/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.