MDLC

During the last two years, I kept on reading what Haitham and Dr.Mervat had written concerning their MSc, sharing their experiences, their thoughts, their feelings and many times they shared also scientific information as well… while I was reading, I wondered if there would be a day when I’d write about my MSc, will I have something to write about other than an annoying conflict with my supervisor, a negative feeling to expose…

I didn’t expect to have an entry labeled “master hassle” soon, but I was surprised as my first discussion about my research point with some Dr.s in the faculty came out with the beginning of the series… I’d try not to be totally sarcastic; rather I’d try to present even a single useful piece of information through each episode…

This methodology was derived from an example suggested by one of the Dr.s in the committee discussed my proposed research point today… ok let me tell the story from the beginning;

Macaroni Development Life Cycle (MDLC):

I was proposing my suggested research point which is based on the incorporation of a new family of development methodologies called ADM (Agile Development Methodologies) & a new thinking based on the development of the system as a set of services which are loose coupled called SOA (Service Oriented Architecture)…

From the business opinion, both approaches gained a mass range of audience through the past six years, or let me say, from the first moment they exist large organizations are trying to adapt their resources to accommodate even one from the two approaches out of their realization of the welfare those approaches may bring to their businesses; from the academic point of view, both approaches gain the same clamor celebrating their existence and many researches had been done to explore the two new worlds, either separately or mutually…

From Mansoura_fcian point of view, no one have the comprehensive mind to adopt a new concept that may replace the traditional techniques of software development, neglecting the vast number of benefits that can be gained by quitting adoption of traditional minds and bypassing any voice calling for change, on the other hand; they are totally bursting forth the migration from the traditional object orientation to the new mind of service orientation.

At first let me admit that the only distinguishing criterion that distinguishes most of CMU_mans staff is the intuition only – if found- and their opinions and thoughts in most cases not based on practical experiences or readings or researches… there is no space to consider specialization, because unfortunately, the slogan of most of CMU_mans staff is “5aleeeha 3ala Allah”…

Back to the main topic; I was trying to convince the committee about the viability of this research point based on the various strengths of both of the two approaches, and usage of the strength points of each of them to vanquish the weak points of the other… but I found myself stuck on justifying only the feasibility of the ADMs, the topic I wasn’t preferring to get into that time, for three important reasons: first, I hadn’t gained yet enough background about this part to the extent that makes me debate about it and be certain that I shall be able to convince the audience of my point of view; second, the committee hadn’t even one specialized member to debate logically based on any criterion rather than intuition and appeal, they don’t believe on the severe viability of analysis and design, instead they believe on the perceived sides of development such as colors, interfaces…finally; it is not my responsibility to justify either approaches my research relies on, I took them both for granted and my part is to justify the viability of their mixture…

The Dr. who insisted on the debate doesn’t know but SOA and thinks that the whole of the world can be abstracted in this approach which can be the silver bullet of any development project…

To describe and justify the proposed methodology, I’d begin with the example the Dr. himself had given:

“If we considered macaroni cooking, shall we consider the process as a whole in the beginning or we shall take it as a separated set of steps with no knowledge in advance about what the result shall be, and without planning the produced dish??”… He said

“but, if I was told that the chief Osama El-Saied is on a TV show now proposing a new trend in cooking macaroni, if I’m following a traditional mind I won’t have the space for flexibility in considering new receipts and the new trend, while if I’m following an agile methodology I can guarantee to have this flexibility”… I replied

In both cases, I know in advance that I’m going to have in the end macaroni, and adopting either of the two minds would guarantee that the process would begin with boiling the macaroni in the beginning and having the dish hot and salty in the end…

Following a traditional methodology would restrict the mind of “plan it when you are going to accomplish it”, instead you must be ready with your full plan in advance because you must have decided each step with its milestones precisely before even boiling the water; leaving no space for sudden circumstances or, sometimes, for upcoming risks; while you cannot prevent them from affecting you; and you may have at the end unsatisfied eaters who may take the meal for granted; which won’t be the case if you are developing a critical system or a software system that the organization was planning to have it as a competitive advantage…

So, to summarize the benefits we shall gain by adopting an agile methodology:

1-The ability to react, to respond quickly and effectively to both anticipated and unanticipated changes in the business environment.

2-And more than reaction to change is its ability to create change which requires innovation which is the ability to create new knowledge that provides business value.

3-Agile development is focused on delivering business value immediately as the project starts, thus reducing the risks of non-fulfillment regarding the contract.

4-Close collaboration between the development team and the customer to reduce the risk of a project since the correct interpretation of the customer needs is verified at every step.

5-I liked a statement I’d read about the development phase (the game phase) in Scrum: “expecting the unexpected”…

That’s what I’ve tried to tell him during the debate that lasted for about 30 minutes and resulted in:

1-More insistence from my side on what I’ve decided long ago

2-More realization of what I’m going to face for the coming journey

3-A supervisor who finally decided to interfere to put an end to the debate; not out of conviction of the concept, but out of boredom and to hasten leaving

4- The Dr. who was debating with me hadn’t been persuaded, but he praised me for being the only one of my colleagues who had proposed a real research point

5-A Dr. whom declared finally that he didn’t understand what we were debating about for the past 30 minutes!!!

By the end of this episode, I shall liken Software development process to the process of constructing a building; the real process is based on having the architect planning the scheme, designing and making the estimations of the cost, measurements and all related stuff; then we would have all the deliverables are handed- out to the civil engineer to implement them in real world with the aid of the builders… the debate comes actually from how each one of us shall consider this process; a few persons whom consider it as it occurs in reality; larger sector of perceivers would assume that the civil engineer is the only responsible in the whole process and he seeks the help of the builders to have it done that way; but unfortunately; mass amount of perceivers consider it the builders whom had built the building!!!