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.

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.

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.

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.

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.

Learning the differences between Waterfall and Agile and choosing the methodologies best suited for the next project!

For this week I have decided to write about 2 different methodology, Waterfall and Agile. Which one is the best and when can we use each of them? I read a blog about both these methodologies and I am going to explain which one is the best to use on different cases.

In the world of project management, two prominent methodologies, Waterfall and Agile, offer distinct approaches to achieving project success. Imagine making a ham sandwich to grasp the fundamental differences between these methodologies. In Waterfall, you follow a linear process, just as you would follow a recipe step by step. Each stage, from gathering requirements to maintenance, proceeds in a clear sequence. However, like making changes to your sandwich after it’s complete, altering anything in Waterfall can be challenging. This approach demands a clear vision from the start and is ideal for projects with well-defined requirements and minimal changes expected, such as building a bridge.

On the other hand, Agile is akin to a group of friends embarking on a road trip with flexibility in mind. Instead of a fixed plan, Agile projects are divided into short sprints, typically lasting two to four weeks. After each sprint, the team evaluates their progress, incorporates feedback, and adjusts their course. Agile’s adaptability is perfect for projects with evolving requirements, quick adaptability, and a need for continuous feedback, as seen in software development.

Both Waterfall and Agile have their advantages and disadvantages. Waterfall offers well-defined project phases, clear documentation, and straightforward cost estimation. However, it struggles with making changes and may not suit projects with uncertain requirements. There’s also a risk of a mismatch between the initial design and user needs.

Agile, on the other hand, excels in accommodating changes, iterative improvements, team collaboration, and dynamic resource allocation. It is, however, susceptible to chaos without proper management and might lack comprehensive documentation. Setting a fixed price or timeline can be challenging, and there’s a risk of scope creep.

Choosing between Waterfall and Agile depends on your project’s nature. Waterfall is best for projects with clear requirements, usability tied to the entire deliverable, strict phase dependencies, and linear progress. Agile shines in situations where requirements may evolve, quick adaptation is essential, continuous feedback is necessary, and flexibility is key.

Selecting the right approach is not about determining which method is superior but rather about choosing the one that aligns with your project’s unique requirements. To excel in either Waterfall or Agile, consider using project management tools like Motion, which offers features that cater to both methodologies. Motion’s intelligent calendar and task manager assist with scheduling and prioritizing tasks, while its flexibility makes it adaptable for Waterfall’s structured phases or Agile’s iterative workflows.

In conclusion, project management is not a one-size-fits-all endeavor. Waterfall and Agile are two distinctive methodologies, each with its strengths and weaknesses. The key to success lies in understanding your project’s needs and selecting the approach that best aligns with those requirements. With the right tools and a clear understanding of these methodologies, you can navigate your project to success, just like choosing the right footwear for your journey – be it hiking boots or running shoes, tailored to the path you plan to tread.

Resources: https://www.usemotion.com/blog/waterfall-methodology-vs-agile

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