Author Archives: Allana Richardson

CS348-01: Quarter Two Blog

Software Process Management – Quarter Two Blog

SCRUM was something that I had never heard of until we did the activity in class, so I wanted to learn more about it to get a better understanding. We went through the “Scrum Values of Courage, Focus, Commitment, Respect, and Openness.” We learned that there was a product owner, a SCRUM master, and developers. We learned that there was transparency, inspection, and adaptation as pillars in this framework.

We learned how “Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” How it requires the Scrum Master “to foster an environment where a product owner orders the work for a complex problem into a Product Backlog, the SCRUM team turns a selection of the work into an Increment of value during a Sprint, the Scrum Team and its stakeholders inspect the results and adjust for the next Sprint, and repeats.”

We learned how “the fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.” And with this team, each has a role and a responsibility that can transfer into the other’s, creating a way for them to collaborate efficiently.

When researching, I found out that SCRUM is not an acronym like DRY or YAGNI. “It  is actually inspired by a scrum in the sport of rugby. In rugby, the team comes together in what they call a scrum to work together to move the ball forward. In this context, Scrum is where the team comes together to move the product forward.”

I also found out that while there is SCRUM, there’s also professional SCRUM. At times, teams fall into a habit of going through the motions. So, professional SCRUM has requirements where the “mindset changes for ways of working and thinking, and an environment that supports it including trust. It also requires you to embrace the Scrum Values in your work.”

With the activity we worked on for this topic, I can see why it’s an agile framework since SCRUM gives just enough of a sense of structure to the people and teams to come together on how they work while giving them ways to add the right processes to “optimize for their specific needs.”

Source: https://www.scrum.org/resources/what-scrum-module and https://scrumguides.org/scrum-guide.html 

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

CS343-01: Week (Quarter) Two

Software Constr – Blog Two

In class, we learned two acronyms. DRY which was Don’t Repeat Yourself and YAGNI which meant You Ain’t Gonna Need It. So, I was curious as to what others we had and why we had them in the first place.

When researching on why acronyms like DRY and YAGNI are important, I came across that “in the ever-evolving world of software development, clean, maintainable code isn’t a luxury — it’s a survival skill. As systems grow and teams scale, codebases can quickly become tangled, brittle, and expensive to change.” The acronyms are principles that help us write code that are sustainable and that even though they’re easy to understand, they’re powerful when applied.

Alongside DRY and YAGNI, there’s also KISS (Keep It Simple, Stupid). The KISS principle “encourages developers to avoid unnecessary complexity. Whether you’re writing a function or designing an entire system, simplicity is often the best strategy.” This is important since if there’s a lot involved in the project, then there’s a lot more risk of bugs when can result in the needless complexity, rigidity, etc. that we learned in class.

This principle was actually created by a systems engineer named Kelly Johnson who was working for Lockheed Skunk Works which was the team that developed the SR-71 Blackbird (“a retired long-range, high-altitude, Mach 3+ strategic reconnaissance aircraft,” according to Wikipedia). “His idea was simple: systems should be so straightforward that even someone with basic training could repair them under stressful conditions — like in combat. This philosophy translated beautifully into software, where complexity is often the enemy of reliability.”

I learned that DRY “was introduced by Andy Hunt and Dave Thomas in their 1999 book The Pragmatic Programmer. Their definition was concise but profound: ‘Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.’” It helps reduce redundancy and speed up development in a project.

I learned that YAGNI worked as “a reminder to avoid building features or abstractions that aren’t immediately required” because of the encouragement it gives to “developers to resist the urge to ‘future-proof’ code based on assumptions about needs that may never materialize.” I also learned that YAGNI came from a thing called Extreme Programming (XP) and was popularized by Ron Jeffries, one of the original Agile Manifesto signatories. It became a core tenet of XP: ‘Always implement things when you actually need them, never when you just foresee that you need them.’” It helped prevent overthinking in engineering and keep the development focused on solving the problems of today rather than in the future.

Source: https://levelup.gitconnected.com/software-architecture-explaining-kiss-dry-yagni-with-practical-examples-in-typescript-9bf23c484816 

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

CS348-01: First Blog

The First Blog

Software process models are definitely something that I feel like as a student taking CS348: Software Process Management should have an idea or an understanding of. They are frameworks that define the sequence of events like activities, tasks, and the deliverables that are required to develop software. “These models act as a roadmap, providing a step-by-step guide for software development teams.”

And there are quite a few key components to software process models that are essential for successful software development. Requirements gathering and analysis, design and architecture, coding and implementation, testing and quality assurance, and finally, deployment and maintenance are these essential components.

“Design and architecture focus on creating a blueprint for the software. It involves designing the overall structure, defining the modules and components, and establishing their relationships. This phase lays the groundwork for the coding and implementation phase. Coding and implementation are where the actual development takes place. Developers write the code based on the design specifications, bringing the software to life. This phase requires attention to detail and adherence to coding standards to ensure a high-quality end product. Testing and quality assurance are crucial to ensure that the software meets the desired quality standards. This phase involves various testing techniques, such as unit testing, integration testing, and system testing, to identify and fix any bugs or issues. Deployment and maintenance involve releasing the software to the end-users and providing ongoing support. This phase includes activities like installation, configuration, and user training.”

In simple words: design and architecture is the planning stage where it draws up blueprints to figure out the big picture before the actual building. Coding and implementation is the building stage where the developers write the code using the plan made as a guide, to make it neat and make sure the code is correct for a good final product. Testing and quality assurance is the checking stage, they run many different tests to ensure that code is working from individual parts to groups of parts and then the whole system. And finally, deployment and maintenance is the launch and support stage where the team can get the finished product out to the users and keep it running well.
And these stages are used in many different types of models. The waterfall model– which is a linear, sequential approach– to the agile model where it has flexibility and adaptability when it comes to planning– and to the iterative model that focuses on incremental development.

Source: https://www.institutedata.com/us/blog/understand-software-process-models/ 

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

CS343-01: Week One Blog

Software Constr – Week One

For week one’s blog, I read the article I first found, Software Architecture Recommendations By Mark Richards. I wanted to start off with something I’ve found first before potentially either diving into more research for videos and articles or maybe even going through what my classmates have found for inspiration.

In Software Architecture Recommendations By Mark Richards, it features a software architect named Mark Richards who covers his definition of software architecture along with the key soft skills and responsibilities of an architect. There are two aspects of software architecture in his vision, as structure and as process. “Within the structural aspect of software architecture there are 4 dimensions: architecture characteristics, architecture components, architecture styles, and architecture decisions.” He mentions how there are soft skills and techniques which include negotiation, facilitation, and leadership when it comes to the process aspect he sees in software architecture.

He says that negotiation is a required skill since “almost every decision you make as an architect will be challenged. Your decisions will be challenged by other architects who think they have a better approach than you do; your decisions will be challenged by business stakeholders because they think your decision takes too long to implement or is too expensive or is not aligned with the business goals; and finally, your decisions will be challenged by development teams who believe they have a better solution.” Which makes sense since if you want to do your job, people will think what they have to say is better, more efficient, etc. So you do have to understand the political climate– as the article says– and how to navigate it to get the views and decisions you made both approved and accepted.

Facilitation is another “soft skill” that Mark Richards thought of where the architects don’t only collaborate with development teams. He says that they should also collaborate with various business stakeholders to understand a number of things such as “business drivers, explain important architecture characteristics, describe architectural solutions, and so on.” Upon further research, I found that facilitation is a shift in the architect’s role from a central decision-maker to a facilitator who empowers the development team to make architectural decisions collaboratively, so it’s a tool to have to keep things on track.

And then there’s leadership. The architect in Mark Richards’ mind is responsible for leading and guiding the development team through implementations. “They are there as a guide, mentor, coach, and facilitator to make sure the team is on track and is running as smooth as a well-oiled machine, and to be there when the team needs clarification or has questions and concerns about the architecture.”

Reading this from his perspective and his opinions are an interesting way of learning his job as a software architect since he has the experience and he has learned from the mistakes he’s made. It’s an important thing to know that even though it’s his job, he’s always learning about ways to improve and for him to share this knowledge is something that’s valuable since you can take the advice and knowledge given and apply it to your own job.

Source: https://apiumhub.com/tech-blog-barcelona/software-architecture-recommendations-mark-richards/

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

CS348-01: Software Process Management

The Beginning

This is the beginning of my documentation in my class CS-348 and phase two, part one, I suppose, for CS@Worcester with the work that I was able to accomplish, had trouble with, and solutions I found.

It’s kind of like my last blog, except new class equals new puzzles I’ll experience!

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.

CS343-01: Software Constr, Des & Archit

Software Constr – First Steps

This is the beginning of my documentation in my class CS-343 and phase two, part two, I suppose, for CS@Worcester with the work that I was able to accomplish, had trouble with, and solutions I found.It’s kind of like my last and now current blog, except new class equals new puzzles I’ll experience! I really hope to do well, even with quizzes or exams as a sort of weak spot for me.But hopefully, with enough reading and practicing, I’ll do well. I want to do well. I’m aiming to do well.

From the blog CS@Worcester – The Progress of Allana R by Allana Richardson and used with permission of the author. All other rights reserved by the author.