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.

This week in class we discussed the process of scrum. Scrum is an agile framework that can be applied to any project or product development effort. It promotes flexibility by encouraging openness, inspection, and adaptation. This loose framework allows teams to adopt it and make changes that benefit their team’s workflow. Unlike the waterfall development approach, where each step must be completed before moving to the next, a scrum team works in small increments over a smaller period. That period consist of the sprint, sprint planning, daily scrum, sprint review, and the sprint retrospective. The scrum event that piqued my interest after reviewing it in class was the daily scrum.

The blog, “Ten Tips for More Effective Daily Scrums” by Mike Cohn,  brought up some interesting and important points. The ten points that were mentioned were: (1) talk almost exclusively about the work of the current sprint, (2) limit discussion to what was and will be accomplished, (3) talk about impediments, not “blockers”, (4) give people something to say about their work not directed toward the sprint goal, (5) give team members a way to indicate when someone is rambling, (6) have people point to what they’re working on, (7) update the sprint backlog but don’t let numbers become the focus, (8) vary how the daily scrum is conducted, (9) keep everyone guessing as to who will speak next and (10) make it painful to ramble too long. 

During the summer, I had the chance to work on software for our university. It was my first time experiencing the scrum workflow. Our team implemented some of these tips during our daily meetings, mainly points 1, 2, 3, and 6 so it was interesting to hear the author’s perspective on what other methods make a daily standup more effective. The points that cater towards diminishing rambling were a fascinating read. While discussing methods to indicate when a member is rambling, examples of using buzzers, holding up rubber hats, and using dolls were mentioned. Although strange to me, those methods show that different teams use what’s best for them. Cohn’s ninth point about keeping everyone guessing as to who will speak next discussed more methods to make the meeting fun to help avoid tuning other members out while they are speaking. While working on software in the summer, I didn’t think about fun ways to improve daily scrum because it was all so new to me. It makes sense to implement something to make the meeting more engaging because, like he said, I did find myself zoning out at times. 

Because I have such little experience with a scrum team, I enjoyed reading about possible ways to improve a team’s process .It helped me realize just how different another team’s methods could be and what I could possibly implement in the future.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

In the dynamic world of software development, finding the right approach to tackle complex projects and manage uncertainties is an important task since we always need to figure out ways of maneuvering around problems or solving them if need be. One such approach having came across in my searches that has gained recognition for its adaptability and risk management capabilities is the Spiral Model. This Software Development Life Cycle (SDLC) model is something that provides a systematic and iterative method for building software, allowing developers to navigate through the challenges of large and intricate projects.

In the blog post, it delve deep into the intricacies of the Spiral Model, it tries exploring its phases, characteristics, advantages, and disadvantages.
By the end, you’ll have a comprehensive understanding of this powerful SDLC model and its potential applications, helping you make informed decisions about its use in your software development projects. from what i’ve uncovered as to why the Spiral Model is often referred to as a “Meta-Model” and discuss the scenarios where it shines, it’s most likely because of it’s nature to incorporate multiple approaches, being able to seamlessly integrate concepts from other SDLC models, utilizing a step wise approach almost similar to the classic Waterfall method- with every loop representing some kind of a step or phase that’s completed in the development process.

Following that, is usually the Prototyping model/technique; like the name implies we make a prototype model right in the beginning to have something of a baseline to draw on- the prototype is developed at each beginning phase, providing a tangible solution to resolve any risks that may crop up. the iterations in the spiral model can be thought of as evolutionary biology through which the complete systems we have are built.

The primary focus of the spiral model is usually risk aversion and management- by addressing risks at each and every phase- it makes sure that any risks or uncertainties software development cycle is usually kept at a minimum. last but not least is the adaptability of the spiral method- it’s iterative and incremental approach can be useful for any changing requirements or unexpected events that may crop up

I selected this resource because the Spiral Model is a fundamental concept in software engineering. Understanding different SDLC models, their advantages, and disadvantages is crucial in the software development field. The Spiral Model’s focus on risk management and adaptability piqued my interest as it aligns with the evolving nature of software projects.

https://www.geeksforgeeks.org/software-engineering-spiral-model/#

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

This week in our Software Process Management, we delved into the world of Scrum, an agile project management framework that’s been gaining a lot of attention in the software development industry. Scrum is all about fostering collaboration, flexibility, and adaptability in a project, and we explored the crucial roles that customers and developers play in planning and completing each sprint.

Let’s start with a quick overview of Scrum. It’s a framework that emphasizes incremental and iterative progress. Instead of a lengthy and rigid project plan, Scrum divides the work into smaller, manageable pieces called sprints. Each sprint typically lasts around two to four weeks, during which a specific set of features or tasks is tackled. This approach allows teams to be more responsive to changing requirements and deliver valuable software faster.

Now, onto the roles:

1. Product Owner: In Scrum, the customer’s voice is represented by the Product Owner. This role is pivotal in ensuring that the team is working on the right things. The Product Owner collaborates closely with stakeholders to define the product’s vision, prioritize features, and create a backlog of tasks. They act as the bridge between the customer and the development team, answering questions and providing feedback.
2. Scrum Master: The Scrum Master is like the team’s guide, facilitating the Scrum process. They ensure that everyone understands and follows the Scrum framework, including the roles, events, and artifacts. Scrum Masters remove any obstacles or distractions that might hinder the team’s progress.
3. Development Team: As a computer science student, this is where you come in. The Development Team consists of professionals who do the actual work of creating the product. This can include software developers, designers, and testers. The team is self-organizing and cross-functional, which means they work together to complete the tasks committed to during the sprint planning. They are responsible for delivering a potentially shippable product increment at the end of each sprint.

In Scrum, collaboration is key. Customers and developers regularly interact during various ceremonies like sprint planning, daily stand-up meetings, sprint review, and sprint retrospective. This close collaboration helps to ensure that the product being developed aligns with the customer’s needs and expectations.

The sprint planning meeting is where the Product Owner presents the prioritized backlog items, and the Development Team discusses what can be accomplished in the upcoming sprint. This collaboration ensures that the team commits to a realistic amount of work and that the customer’s priorities are respected.

During the sprint, the Development Team is focused on delivering high-quality work. The daily stand-up meetings keep everyone in sync, and any impediments are addressed quickly.

At the end of the sprint, the team and the customer come together for the sprint review to demonstrate the work done. This provides an opportunity for feedback and adjustments based on the customer’s input.

Finally, the sprint retrospective is where the team reflects on their processes and identifies areas for improvement, making each subsequent sprint better than the last.

In conclusion, Scrum is an exciting and collaborative approach to software development that empowers both customers and developers. It ensures that the product remains aligned with customer needs while fostering a dynamic and adaptable working environment. As computer science students, this framework equips us with valuable skills for future software development projects. So, embrace Scrum, work closely with your team, and be prepared for a dynamic and rewarding journey in the world of software development.

From the blog CS@Worcester – Dose Of Dev by msavice and used with permission of the author. All other rights reserved by the author.