SDM Assignment 4

There was a legendary IT division (we call it BELL), which was in charge of developing and maintaining the software systems of a private organization (we call it FORGE). For ten years, BELL had developed software systems (varying from small-scale to large ones) for FORGE. Due to the prevalence of its IT services, FORGE had a substantial number of service points all over the country and offered diverse on-site and online services to its customers. Since FORGE was not the only organization and provider in its type, the quality and novelty of on-demand IT services was the only competitive edge, and the golden key to survival in the turbulent market environment. In addition to this, the criticality and vitality of the offered IT services had posed BELL as a decisive factor in the success of FORGE. On the other hand, ten years of working for FORGE, had given BELL the overall control of its software systems. Imagine the considerable benefits that were derived by this control! FORGE had to keep an ongoing relationship with BELL due to several reasons, such as: The operation and support of the existing software systems was a critical factor to FORGE which could only be provided by BELL; Offering new services by FORGE (in order to survive in the market) required the development of new software systems which were highly dependent on the existing systems (Therefore leaving BELL as the only solution).

However, BELL had deteriorated into a dilapidated ruin over the years: BELL managers had turned into nagging corncobs that could do nothing but negating, complaining and obstructing. Hence, no proper management activity such as project management, risk management and quality assurance was performed on the development activities (an antipattern called project mismanagement). This put a great deal of pressure and stress on all the poor programmers in charge of developing the software systems. No new idea could convince these corncobs other than tangible results which were delivered swiftly. There was no knowledge sharing mechanism between the developers and managers. Developers were kept isolated either from the users and contractors of the software systems (an antipattern called mushroom management), or the managers who were in charge of contracting with FORGE for the software projects. The burden of developing software systems were just upon the programmers. Hence, the success or failure of a project mainly depended on the skills and knowledge of the developers. This was while the developers of BELL just possessed expertise in some programming languages such C++ or Java, and having heard a little about RUP and UML. This had resulted into disparate development of software systems with no architecture, design, documentation, configuration management,; having one system implemented in X, while the other in Y. Only a few seasoned programmers had developed some ad-hoc architecture of which no documentation had remained (an antipattern called architecture by implication). Occasionally, some UML models were also produced for some systems.

The maximum number of developers working in a team on a software system was three. This was while due to the amount of stress and pressure which were upon these poor programmers, they quit their job quite often. Quitting the job was a frequent pattern in BELL ,posing developers and their knowledge of the systems as a bottleneck. Just imagine the chaotic situation created after the departure of each developer: on one hand a series of critical and vital systems in desperate need of operation and support, on the other hand no documents, no test and the developers which were quitting one after the other. Maintenance was a nightmare for BELL. Only a few programming heroines (heroes) could support the software pieces developed by their predecessors. However, the coming and going of these heroines (heroes) in addition to the ever-changing needs of the developed software systems had resulted into a master piece of dead codes (an antipattern called lava flow), and software systems with ad-hoc architectures (an antipattern called spaghetti code). Just imagine what stove-pipe services were offered by FORGE! Manipulating these systems and services was just like Walking through a mine-field.

This sad story continued until a heroine (hero) of Software Development Methodologies appeared. She (he) turned BELL from a bankrupt division into a flourishing IT company throughout the country (as you know this is a myth, therefore a little bit of exaggeration is quite natural.)

Problem Statement
Can you explain in details what this heroine (hero) did?

Answer Guidelines
To answer this question sum up your knowledge of Software Development Methodologies and solve the problem proposed. (The aim of the proposed question is to develop a bespoke software development methodology (or a family of methodologies) which fulfills the requirements of the situation at hand and removes its problems.) Software Methodologies are Software too! Regarding this point, the general activities of development lifecycle such as analysis, design and implementation should be performed in order to develop the target method. To resolve the proposed problem, the following steps should be performed:

S1: [Project Characterization] Study the case study thoroughly for several times and characterize the situation described. Project Characterization aims at identifying the features of the specific situation of the project at hand. In the proposed case study two points help with identifying the features: The general features of the target environment which directly help with the identification of a set of features, The antipatterns exemplified which identify the problems existing in the target environment and complement the set of features obtained in the previous steps.

S2: [Identification of the Methodology Requirements] In this activity the following steps should be followed: Translate the project characteristics specified in the previous steps into a set of methodology requirements.

Add the requirements which should be satisfied in a typical software develop methodology. [You are familiar with some of the methodology requirements: the criteria introduced in lecture 1.] S1 and S2 form the analysis phase of developing a soware method. S3: [Designing the target method] In this activity the following steps should be followed: Choose an appropriate method development strategy from among the following approaches: Ad-hoc, Assembly-based, Paradigm-based, Extension-based or Hybrid,

based on your current knowledge of the methodology engineering approaches and the variety of software development methodologies with which you are familiar. Use your overall knowledge of software development methods in order to design a method which satisfies the set of method requirements specified in the previous step.

S4: [Implementing the target method] In this activity the following steps should be performed:

Add the required details to the designed method to the level which it is implementable in the situation of the case study. [Use EPFC in the implementation step].

S5: [Validating and Verifying the developed method] In this activity the following steps should be performed: Provide a discussion about how the developed methodology tackles the problems introduced in the case study and resolves them. Does the developed methodology fulfill the requirement specified (Is it valid)? Is the developed method enactable in the situation of the case study (Is it correct [practical , practicable,])?

S1-S5: Form the software method development lifecycle. You could choose a methodology to perform these steps. [A methodology for methodology development] (This deserves bonus.)

Mahsa Sadi February 2011