I recently read the article “Common SDLC Management Pitfalls (And How To Avoid Them)” published on Forbes.com. This insightful piece delves into prevalent challenges encountered during the Software Development Life Cycle (SDLC) and offers practical strategies to mitigate them.

I selected this article because, as someone striving to enhance my understanding of software process management, recognizing common pitfalls is crucial for effective project execution. The article’s focus on real-world issues and solutions provides valuable guidance for both current and future projects.

The article identifies several key pitfalls in SDLC management:

• Unclear Requirements: It emphasizes that ambiguous or incomplete requirements can lead to project delays and cost overruns. The recommendation is to engage stakeholders early and ensure thorough documentation to establish a clear project scope.
• Inadequate Communication: The piece highlights that poor communication among team members can result in misunderstandings and errors. Implementing regular meetings and utilizing collaborative tools are suggested to enhance information flow.
• Lack of Proper Testing: The article points out that insufficient testing can cause defects to reach production, affecting product quality. It advocates for integrating comprehensive testing phases within the development process to identify and address issues early.

Reflecting on these insights, I recognize the importance of establishing clear requirements from the outset. In past projects, I’ve experienced setbacks due to vague objectives, leading to scope creep and resource strain. Moving forward, I plan to prioritize stakeholder engagement to define precise and attainable goals.

The emphasis on communication resonates with my experiences in team settings. I’ve observed that regular check-ins and transparent discussions significantly reduce misunderstandings and align team efforts. I intend to advocate for consistent communication channels in future collaborations to maintain project coherence.

The article’s focus on testing underscores a critical aspect of software development. Previously, I underestimated the value of early and thorough testing, which led to last-minute defect discoveries. I now understand that incorporating iterative testing phases can enhance product quality and reduce time-to-market.

In conclusion, this article has deepened my understanding of common SDLC pitfalls and reinforced the necessity of proactive management strategies. By applying these lessons—clarifying requirements, fostering open communication, and committing to rigorous testing—I aim to contribute to more efficient and successful software development projects in the future.

For those interested in exploring this topic further, I recommend reading the full article: Common SDLC Management Pitfalls (And How To Avoid Them).

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Sweep The Floor

A common stereotype amongst movies and literature when an apprentice first begins their work, they are handed a menial task and told to perfect it. Often sweeping or “wax on, wax off” from the movie Karate Kid, the task being grueling and numbing in a sense. This task assigned to you wasn’t to demoralize you or just give you something to be distracted by, it was to get you ready and perfect a skill by practicing frequently.

As an apprentice you are nearly always going to be on the lower rung of experience and will find yourself doing work closer to your skill level. With programming the metaphorical broom might not be clear, or obvious. Instead of waiting for instruction you should take the initiative and volunteer for things. Take a task that you can complete or learn to complete and lighten the load of others.

This won’t necessarily seem like sweeping the floor but in a sense you are taking the tasks that will help yourself and the team you are aspiring to become an essential part of. I understand this aspect fairly well absorbing this concept through admittedly far more media than I should have, but I agree with this pattern pretty much wholeheartedly. Being apart of the group and not being as skilled as them is fairly demoralizing, but taking the lesser tasks can still make you a vital part of the process while you make the effort to become as skilled as your group members.

While learning and developing your skills you do have to step back and learn the basics. Focusing your skills and learning the essentials is integral and necessary. It’s also usually the tasks that most don’t want to work on. Mind numbing maintenance and formatting is one task that higher level workers dread maintaining. These tasks are necessary and vital to the projects success and someone needs to do it. You might as well put yourself into the problems you can solve and along the way you will learn things vital to improving the project and increasing your skills. To learn the basics is to master them. Sweep the broom before you place the first brick of the new structure. Stack bricks thousands of times before you can build a sturdy wall. This pattern is to take the mindset of the novice within your group and how as an apprentice you can learn while also helping out your group.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

As my final semester approaches here at Worcester State University, I figured a relatable blog topic would be the best practices you can learn as a Software Engineer. The article can be found here: http://www.excella.com/insights/best-software-engineering-practices

This article touches upon three different practices that the author thought highly enough to include. The three practices are S.O.L.I.D., Automated Unit Testing, and continuous integration.

S.O.L.I.D. –  an acronym for an object oriented design principle.

S –  Single Responsibility –  a class should have only a single responsibility.

O – Open/Closed Principle – Software should be open for extension, but closed for modification.

L- Liskov substitution principle – objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

I- Interface Segregation Principle – Many client-specific interfaces are better than one general-purpose interface.

D- Dependency inversion principle – One should depend upon abstractions, not concretions.

When you use all of these principle together, a developer can create code that is much easier to maintain and improve over time. The code is SOLID.

Automated Unit Testing

Automated unit testing is a software development and testing approach where you independently test units to ensure that they are operating correctly.  Unit testing can be done manually and it was in the past, but automation has taken over and everyone is thankful for that.

I use JUnit in eclipse to test java programs continuously. It makes it very easy to track where there is an error and what caused it to happen.

Developers become much more confident in their work when they don’t have to worry about wasting a bunch of time finding errors, instead we test immediately and fix the problem before it gets too clustered.

Continuous Integration

Continuous Integration quite literally means that you continuously ingrate the code and fixing issues before they are submitted to the actual project repository. In my classes we used Github or GitLab to manage repositories.

It works by a developer checking new code submissions in the repository. The integration process then builds and runs tests while analyzing the code. The CI detects any problems with the code and gives feedback to the developer. The developer fixes them and then approves the changes to the code. This way no code ever gets broken.

One of the benefits about using Continuous integration is that the version control system holds all current and changed code. You can easily go back to see what changed and how something may have broke.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.