A blog on content management and digital experiences
Okay so the title is a bit troll-ish. This really isn't about waterfall versus agile, just my misunderstanding of the term "methodology." Apparently I've been using it wrong; a method is the correct term to describe a way of developing systems, whereas a methodology is the study of such methods.
I guess we can continue to debate if the "S" in SDLC stands for systems or software?
It is very tempting to jump at a technical solution right away, especially for those that love solving problems.
Given a new project that two teams in separate buildings need to work on, how can you get them to work together? This question came up in one of my project management classes and answers from IT students included Web-based software and networking the buildings.
The instructor wanted the class to consider low-tech solutions. Maybe the teams could be consolidated into one building, for example.
As a non-academic example, I'm working with a team dealing with missing data in a text-based data file that's preventing them from connecting two systems. The temptation is to "solve" the problem with a script or batch job. I'm glad the team considered this but has a preference for a more robust and "supportable" solution.
In context, the specific software connects multiple systems involving five or more parties including telecom, database and server administration, a support partner, the software vendor, and a hardware vendor. The team doesn't want to introduce a customization that could slip between the parties when it's time to troubleshoot issues.
The business concern for supportable interfaces trumps an "easy" fix. From a project-perspective the quick, clever, or brilliant technical solution doesn't always meet the business needs.
After 2 years in a BS IT program with an emphasis in business systems analysis, we finally get into the nitty gritty of UML (Unified Modeling Language) diagrams. The light bulb finally went in my interaction-related use case and sequence (or swim) diagrams.
We start with class diagrams as blueprints that describe objects as well as their attributes and operations. It's all about behavior and data.
We can consider state and activity diagrams to see how these object exist through time.
To better understand how the parts come together (as well as roles and security concerns) we can add use case diagrams (and their text-based use case descriptions) as well as sequence diagrams. How do the objects and users interact with each other?
Each diagram would be appropriate to different audiences and contexts, but together you get a nifty toolkit that can be used in a variety of scenarios.