But if we are ready to go to the market,
if we are ready to deploy our product, then we can
move to the transition phase, which has mainly to do
with deployment and maintainence of a system. So what are the
main activities in the transition phase? As we discussed in
our initial lessons, in most real world cases, there are issues
that manifest themselves after deployment, when we release our software and
actual users interact with the
software. Specifically, users might report failures
that they experienced while using the system. So, what we call
bug reports. Or they might report improvements they might want to see
in the software. So typically these will be new feature requests. And
in addition, there might be issues that don't come necessarily from the
users but that are related to the fact that our system
has to operate, has to work in a new execution environment. For
example, the new version of an operating system, or the new version
of a set of libraries. When this happens, we have to address
these issues by performing maintenance. Specifically, corrective maintenance
for bug reports, perfective maintenance, for feature requests, and
adaptive maintenance, for environment changes. And the result of
this is that we will have a new release
of the software. Other activities that are performed in
this phase include training, customer service, and providing help-line
assistance. Finally, if you remember what we saw when
we were looking at the banking IT system example,
the cycles within a development are not necessarily completely dis-joined, but
they might overlap a little bit. So something else that might
happen in the transition phase is that a new cycle may
start. So there might be some activities that are related to
the fact that we're starting to think about the new cycle.
So now let's see what kind of outcome these activities will
produce. The first one is a complete project with all the
artifacts that we mentioned before. Another outcome is that the product will
be actually in use. So the product will be in the
hands of the users and the users will start using it, will
start interacting with it, for real, not just in a beta testing
setting. Another outcome will be a lesson learnt. What worked. What didn't
work. What should we do different in the next cycle or in
the next development? And this is a very important part of the
whole process, because it;s what provides
feedback between cycles, and between projects.
And as we said before, in case we have a next released
planned or a next cycle coming up, we might want to
start planning for the next release. So another outcome will be
the plan for the next release. So similar to the other
phases, also for the transition phase, we have a milestone, which
is the fourth milestone in this case. And therefore we
have evaluation criteria for the transition phase that will define whether
we've reached the milestone or not. And in this case, one
important assessment is whether the user is satisfied. So users are
actually using our product now, so we can get feedback
from them, we can see whether the product makes them
happy or not. And we continue assessing whether our expenditures
are fine with respect to our estimates. And in this case,
problems with this milestone might lead to further maintenance of
the system. So for example, we might need to produce
a new release to address some of the issues that
the users identified, as we discussed a couple of minutes ago.