hello and welcome to lessen 3.4 d sdm, the dynamic system development model. I'm your instructor cane,
and we're going to be going over this particular flavor of agile, which actually was also developed in the 19 nineties.
But it waas Maura response to some of the shortcomings at the time with rapid application development. So, in essence, once we got into the middle, late nineties were moving away from green screens and on to more of the power builder graphical user interface type of thing.
that was where rapid application development
began to become more popular and a lot of the blue chip companies. These are the large companies that
were complaining about the speed of
the normal traditional waterfall. Project management got together and created a D SDM consortium that came up with this D sdm framework. And again,
the this particular flavor of agile can be leveraged with other types of agile frameworks and its tool independent so it doesn't necessarily subscribe to a particular
software tool, whether it's combine boards or marks project or any of those it ISS software independent. In addition,
it's often sold as one of the most viable, agile methodologies for non I T projects, and I think you'll start to see why here as we go through today's lesson.
So the big thing about D SDM is of course, it's business need focused, It's incremental, and it uses the same basic, agile premises as the other flavors.
But this really is kind of the first inclination of what we would call sort of a hybrid methodology.
Wow. Agile is sometimes used, which is the combination of waterfall and agile, and it uses
a the idea of building incrementally from firm foundation so it requires has a level of governance in a level of oversight
appealing to your bigger government projects and some of those entrenched blue chip type companies, because
we have a dedicated planning and requirements development process that is being
progressively elaborated and progressively refined. But your stakeholders, your executives, have a lot more governance structure on this type of an agile methodology than they do in some others, and that tends to make them a little bit more comfortable with this particular flavor of agile.
So we're still doing our continuous improvement
we're doing Our iterations were what they call a time boxed method, which most most agile, really
is a time box, meaning that your of your triple constraints the schedule constraint
is the driver. So it's locked down and the other two are allowed to fluctuate. So your performance and your effort throughout the life cycle of the particular project
one of the interesting things about D sdm that make it easier in some cases to visualize is there a proponent of was called the Moscow method.
And when you're developing requirements because remember, D SDF has a requirements development phase
that's a little bit more formalized, and some of the other flavors of agile ah, the Moscow method is used to basically say must have, should have, could have and won't have will not have. And that's what makes the acronym Moscow. But the idea is, as you're building your requirements,
the business owners and the stakeholders
can have a few me could have a say in
what is definitely in scope, what is out of scope and what those gold plating nice toe have, um,
things are and give you some s essence of
ah, priority structure that's a little bit more formalized with the business community outside of just the scrum team, getting together every two weeks and talking about what the system should be doing and what the new features are.
it's a little bit more of a
clearly communicated effort. We have this requirements matrix, which gives a warm and fuzzy to some of those folks that arm or tied into the waterfall methodology. Or this may be their first time trying something with agile.
And it allows for the requirements in the planning phase to be a little bit more water fully and structured,
which also makes contract management a little bit easier for those of you that are working for the government or large organizations. As we've gone through this course, some of you with a lot of contract management experience might be shaking your head and basically saying that there's no way.
But our organization conduce this because we can't get a contract written that would be approved by legal
with some of these other agile methodologies. And that is a concern for you, quite frankly, a lot of of larger organizations that still want to develop
and produce production ready software at a at a faster pace.
so what you start to look at. It is sort of that
requirements gathering piece, and then we go into prototyping. So that's what makes it a little bit more iterative versus some of the others. You'll see a little screenshot here talks about some different project phases. So you've got your fuse ability,
your foundation, your R a y, your business case. All of these things that develop
sort of a warm and fuzzy for
the individual business owners that maybe aren't all on board with a full agile project.
Then we go into this exploration prototyping. Start looking at you know how we can implement the things that we've developed in the feasibility study, and if it the looking at those Moscow work items, then you go into your engineering and then you start doing your deployments and things like that, so it gives you a little bit different. Look,
there's Ah, there's 1/3 of a waterfall essence on Ben. When you get into the narrative development, as those Moscow work
more like a feature or a product backlog, and you've done some of those additional pieces of discovery about them, then you start getting into that water, not the part fall of the agile methodology. And you start really focusing on building that quality program or that quality feature doing your testing
and making sure that you are able to deliver on time. And that may again makes the business community feel a little bit
more comfortable that this is not a never ending
project, which is really one of the
I guess you can say one of the negative
stereotypes with agile I don't think is necessarily true. But a lot of companies are unable to implement agile correctly, and what you end up with is basically a never ending project that we're always throwing money at it. There's always things in the backlog, um, and so they don't get that sense of completeness
that they might otherwise have gotten with waterfalls, uh,
type of project, so that building on firm foundations is really a key element here to de sdm.
So that was popularized in the late nineties came about again because rapid application development at the time had a lot of the same complaints that agile now has again of the old saying goes, What's old is new again is that we're kind of at that phase in an agile
that is one of the areas that D. Sdm is trying to address.
So in today's video, we discussed the dynamic system development model and talked about some of their ways that it might be more appealing to implement in a structured and more formalized organization, Thank you very much, and I will see you in the next video.