Management of projects on development of the software. Problems and ways of the decision

In clause(article) attempt to classify projects on development of the software is made, the review and the brief analysis of the cores metodology on manufacture of the software is made, the brief analysis of applicability of the cores metodology to types of projects on development of the software is made.

The introduction

Today there is enough plenty of standard processes and metodology, applying which the firm receives this or that model of manufacture ON. Most known of them are CMM (Capability Maturity Model) and a series of standards ISO 9000. As a rule, the organizations introduce these processes only for that will receive the certificate of conformity of the process to one of vysheupomyanutykh standards. However, as it is not paradoxical sounds, frequently attempts to introduce one of vysheupomyanutykh processes fatally affected stability of work of firm.

Last 3 years in the West there were fashionable terms « superficial process », « adaptive process », « uniform rational process » and « extreme programming ». What is such? And why sometimes the effect from introduction ISO9000 appears negative? What process to prefer and to be guided by what criteria at a choice of process? Other part of clause(article) is attempt to find answers to these and other questions.

Classification of projects

The model and parameters of process of manufacture ON appreciably depends on type of the project. Each command(team) has customers with whom there were those or other attitudes(relations).

The "" customer

Situation at which the command(team) of developers for a long time serves the unique customer. As a rule, the similar variant is characterized by magnificent attitudes(relations) between the customer and developers. Frequently, such commands(teams) settle down in territory of the customer. The basic characteristics of this type of the project:

• Availability of the customer at any time
• Steady representation about needs and needs(requirements) of the customer, generated for years of cooperation
• Low enough requirements to quality of the software
• Constant support of the products, their completion and perfection
• Steady financial mutual relations between the customer and developers
• Long-term plans on cooperation

  Product under the order

  The situation at which the command(team) of developers finds the foreign customer and agrees with it(him) about development of the software product, called to solve those or other problems of the customer. The basic characteristics of such type of the project:

• Availability of the customer can be characterized as "periodic"
• Representation about needs and needs(requirements) of the customer is formed on the basis of the made inspection
• In advance stipulated requirements to the software according to which acceptance of a ready product is made.
• The developer during in advance stipulated period of time supports(maintains) the put product.
• Financial attitudes(relations) are made out in the form of the single contract
• Plans on the further cooperation appreciably depend on quality and stability of a product, which developer has put the customer.

  Duplicated product

  The situation at which the command(team) of developers or at all has no concrete customers (« a box product »), or is enough significant amount of customers on the same product. The basic characteristics of such type of the project:

• The concrete customer forming the requirements to a product, does not exist
• Representation about needs and needs(requirements) of the present(true) and potential users are formed on the basis of the analysis of the market and contacts to typical representatives of users. The feedback with users of a product is carried out basically by means of e-mail.
• Quality of the software is supervised only by an internal department of quality + a feedback with users. üÑÔá-testing is widely used.
• The developer during in advance stipulated period of time supports(maintains) the put product.
• Financial attitudes(relations) exist in the form of the fixed price for a product
• Plans on development of a product are formed on the basis of the analysis of the market

  Outsourcing

  The youngest model of manufacture of the software. Has appeared because of high qualification and cheapness of work of the Russian programmers in comparison with their western colleagues. The essence of such model consists that between the western firm on manufacture of the software and the Russian firm the contract about subpodryade consists. The basic characteristics of such type of the project:

• The developer does not contact to the end user of production. The information turns out in the form of the technical project from the western party(side).
• Representation about needs and needs(requirements) of the customer are formed only on the basis of the information presented by the western party(side)
• The western party(side) gives the requirements to process of manufacture of the software and its(his) quality
• Support of a product is carried out, as a rule, by the western party(side)
• Financial attitudes(relations) exist in the form of individual contracts between members of a command(team) of the developer and the western customer. A variant is the conclusion of the contract between the western customer and the legal person(face) operating(working) on behalf of a command(team) of developers.

  Problems

  The organization of process

  The most typical in Russia can be characterized model of process of manufacture of the software as follows: « Each developer chooses this or that method or technics(technical equipment) for creation of programs according to own habits and predilections. Practically full absence of the precise responsibility for performance of those or other functions. Quality of the software is a random variable and directly depends on abilities of separate employees of the company. Practically all depends on the initiative and business qualities of several persons ». This formulation practically completely corresponds(meets) to 1 level CMM under the name "initial". On some source, 2 years ago, the share of firms-manufacturers of the software using this model, made over 70 %.

  Here what conclusions are done(made) by Martin Fowler [4], comparing process of manufacture of the software with classical types of construction and manufacture:

• During manufacture ON, the phase of direct programming (construction) is much cheaper than all other phases (designing, testing, etc.)
• During manufacture ON all the basic efforts go on designing. Process of designing demands, that the creative and presented people participated in it(him).
• Creative processes cannot be planned easily. Thus, predictability of similar processes can be the unattainable purpose.
• We should concern very cautiously to use of traditional metaphors by manufacture of the software. It is absolutely special kind of activity demanding especial process.

  Requirements and iterativnost

  Classical process of manufacture of the software which was used all over the world down to the middle of the ninetieth years and which practically is a symbol of an epoch of structural programming, consists of following steps: inspection, statement of a problem(task), designing, programming, testing and introduction. This process refers to "Falls". It(he) means, that requirements to the software product, collected during inspection and the problems(tasks) formalized during statement, are fixed(recorded) and do not vary during all production cycle. However modern business is very dynamical also change of requirements in it(him) – usual business.

  Fowler writes: « During manufacture of the software all depends on requirements. If you cannot achieve stability of requirements, you cannot create the predicted plan ». How to be? On the one hand requirements should be steady, and with another they will inevitably vary during the project. A key to all – iterative process of manufacture.

  Ways of the decision

  All ways of the decision vysheoboznachennykh problems are reduced to change of process of manufacture of the software so that process was predicted, steady and in time would provide performance of an overall objective – the ready software.

  Linear and iterative life cycles of creation ON

  Linear life cycle of creation of the software (also known as "Falls") provides consecutive passages of 6 stages: inspection, statement of a problem(task), designing, programming, testing and introduction. Such life cycle assumes an invariance of the requirements shown to ON, from the moment of statement of a problem(task) till the moment of signing of the adoption deed of the developed product, long the development cycle of the software would not be what.

  Such approach we shall apply, to classical disciplines, such, as construction of houses or manufacture of machine tools. The given approach we shall apply even in the industry of manufacture of the software if requirements to a product actually do not vary during all cycle of development. As one more condition the settled technology of development ON, without application any up to the end of not investigated(researched) technological novelties serves. As an example of projects of a similar sort the writing(spelling) of the program operating a rocket can serve, flying on the Moon (it is improbable, that on a course of a writing(spelling) of the program the mankind has learned(has found out) something cardinally new about the Moon) or creation of the calculator, the requirement to which already for a long time are known also long time do not vary. And how to be, if it is required to create, for example, electronic shop for the customer trading computers and accessories?

  Modern business is very dynamical, and requirements to electronic shop will change not one ten times during process of its(his) development. And each time it is necessary to copy a significant part of a code and to bring set of documents into accord with new circumstances. And it, as a rule, not planned losses of time, resources and efforts, that, as a result, pours out in failure of terms and manufacture of the software which is not satisfying (or not completely satisfying) to requirements of the customer. Where an output(exit)? An output(exit), in this case, one – use of an iterative cycle of creation ON. Such cycle represents a set of iterations, within the limits of each of which the project passes(takes place) through all 6 vysheupomyanutykh stages. The iterative cycle will allow to reveal serious problems at the earliest development cycles, to operate risks, earlier to begin testing etc. Such process becomes more dynamical and operated.

  Existing methodology

  In the world there are very many typical processes of manufacture of the software. ISO9001, ISO12207, ISO15504, CMM (Capability Maturity Model), MSF (Microsoft Solution Framework), RUP (Rational Unified Process), SCRUM, XP (eXtremal Programming), Crystal Clear, ASD (Adaptive Software Development), Lean Development – all this of a version of processes of manufacture of the software, family of processes and methodology. The methodology is understood as a set of methods, an expert, metricss and the rules used during manufacture ON. According to Alister Koburnu [1], the methodology is necessary that:

• To facilitate procedure of introduction of new people in a rate of process of manufacture
• To provide interchangeability of people
• To distribute(allocate) the responsibility
• To make impression upon the sponsor/customer
• To show visible transparent process
• To create educational base for the employees

  By Jim Khajsmita's definition [16] « the Present(True) purpose(assignment,destination) metodology is the increase in productivity providing the decisions for customers »

  The methodology can break conditionally into 3 categories – heavy, easy(light) and average. Uproshchenno, each of which, is intended for work in conditions, accordingly, greater(big), small and average projects. However, as we shall see in a consequence, it not absolutely so.

  According to Alister Koburnu [1]:

• The size of methodology is a quantity(an amount) of elements of the management including intermediate releases, standards, kinds of activity, a mark, the metrics of quality, etc.
• The density of methodology is a level of detail and the integrity, demanded for elements of methodology.
• The weight of the project is the size of methodology increased by its(her) density.
• The size of the project is a quantity(an amount) of the people involved in realization of the project.

  All the above-stated definitions have conceptual character as there are no quantitative metricss for the given sizes.

  The first category metodology was born before all and is an integral part of models of quality of the software. Heavy methodology differ that aspects of activity of the company making the software – from management of requirements and planning of process up to a regulation of mutual relations with subcontractors and descriptions of requirements to auxiliary processes cover all. All of methodology of the given category are intolerant of changes and consider(examine) people as a usual resource. Examples: CMM, ISO9000, SPICE.

  The second category metodology was born as some set of methods and an expert, developers applied by small commands(teams) in successful projects. Here huge value is given by mutual relations between people inside of a command(team), questions of tolerance and other psychological aspects are considered. All processes of the given category provide iterative life cycle of development ON. If to try to formulate the basic sense of lungs metodology the following will turn out: « Maintenance of the maximal speed and quality of development ON at a minimum of restrictions and reserves ». In particular, in all lungs metodologiyakh only necessary minimum of documents since the Documentation is given due to a principle « is is stipulated by not is understanding ». Essential difference of data metodology from metodology the first type is the attitude(relation) to planning. Is better an essence of this difference Jim Khajsmit has expressed: « In traditional planning a deviation(rejection) from the plan are mistakes(errors) which should be eliminated(erased,removed). However, in adaptive process, deviations(rejections) conduct us to the correct decision » [4]. Examples: SCRUM, XP (eXtremal Programming), Crystal Clear.

  In the third category metodology so-called "universal" processes get. The brightest and known representative of the given category is RUP. The basic characteristic of similar processes is scalability – i.e. process can be adjusted(set up) as for work in a small command(team) above the small project, and in the big command(team) above the greater(big) and serious project.

  The analysis of applicability of processes

  Alister Koburn, author Crystal, is one of the most known modern experts who have made with object of the researches of methodology. Result of its(his) researches in the given area is the book « Agile Software Development » [1] in which the author analyzes process of manufacture ON from the various points of view. Alister Koburn is the author of the concept « Development of the software is a joint game of the invention and interaction ». It(he) allocates 2 purposes at this game:

• The first purpose: to develop and introduce the working software.
• The second purpose: to provide all conditions for successful course of following game.

  Thus, the problem(task) is formulated minimaksovaya: to bring into the world ON (frequently for this purpose it is not required to create in general any documents) and to provide development of following versions of data ON (and here for this purpose it is necessary to create a number(line) of documents which are necessary, for example, in case one of the basic developers will leave(abandon) a command(team)). From the point of view of the given concept, project C3, during works above which methodology XP has been created, was unsuccessful game since after a command(team) the basic developers have left(abandoned) all, the software product could not be developed. As the reason for that that anybody from remained did not possess for this purpose necessary knowledge has served, and the detailed documentation under the project has not been made.

  During too time, easy(light) processes are inapplicable for work on greater(big) projects or above products, the degree of criticality of which correct work is very high.

  

  

  

  Figures 1-3 illustrate laws in use different metodology commands(teams) of developers of various number. In figure 1 dynamics(changes) of productivity of the command(team) consisting from several person and using different methodology is shown. The small command(team) successfully works using lungs of methodology. At weighting methodology, at a command(team) remains ever less than forces and time it is direct on development.

  Figure 2 reflects dynamics(changes) of productivity of the big command(team), using methodology of various weight. The easy(light) methodology does not provide due controllability to process, therefore in the beginning the schedule productivity of a command(team) is low. The command(team) reaches(achieves) the highest productivity, using methodology to which has enough for installation of operated and dynamical process, however at the further weighting methodology gradual recession in productivity is observed.

  Figure 3 reflects a ceiling of opportunities of a command(team) at use metodology different weight.

  Koburn has developed classification of [1] types of projects, being based on two parameters – the size of the project and its(his) degree of criticality. Following degrees of criticality differ:

• Loss of comfort (Loss of comfort). Loss of comfort means, that in case of a mistake(an error) in system, the life of people will a little become complicated, they should I shall do(make) more than manual work, or call each other, to fill the interrupted liaison channel. Programs of support of a corporate infrastructure usually lay in this area.
• Loss of essential quantity(amount) of money (Discretionary money). Means loss of a quantity of money or any other material equivalent, but only within the limits of discomfort. Usually, warehouse systems lay in the given area.
• Irreplaceable loss of money (Irreplaceable money, essential money). Means loss of money or their equivalent in volumes, sravnimykh with bankruptcy of the enterprise. The control system of national bank lays in this area.
• Loss of a life (Loss of life). Means, that in case of a mistake(an error) of such system there is a danger to human life. Control systems of nuclear station, a spacecraft and plane lay in the given area.
  

  Entering some amendments to an offered way of classification, it is possible to consider also a degree of distribution of the project (especially actually for autsorsingovykh projects), qualification of a command(team) and other nuances.

  Conclusions

  Now we shall return to our types of projects and we shall look, what types metodology are the most expedient for using otherwise.

  The customer

  The most favorable type of the project for introduction of lungs metodology as the customer is always accessible also special requirements to quality of the software are not shown. However, it is necessary to consider quantity(amount) of developers and a degree of their distribution. Necessities for certification, as a rule, at such commands(teams) do not happen, therefore, by and large, to pay attention on CMM and other heavy techniques as the cores, it is not necessary.

  Product under the order

  The most vulnerable type of the project. The firm entirely depends on quantity(amount) of the concluded contracts. Search of new customers is constantly made. In such conditions, certainly, presence of certificate ISO or CMM is very desirable, especially if it is a question of the western customers. However, introduction ISO9001, SPICE or CMM is enough labour-intensive process which not always justifies itself. Therefore, probably, it is expedient to begin introduction RUP, with a sight on the further certification.

  However, as shows the above-stated analysis, sertifitsirovanie small firms frequently simply perniciously for them. Therefore, to think of certification costs(stands) only at achievement of the certain number of the personnel which will be enough for introduction of one of heavy or average metodology. Otherwise, use of one of lungs metodology is the best output(exit). In particular, if at the company is prospects of growth it is possible to try to introduce Crystal Clear, with the subsequent transition to heavier of methodology of the given family.

  Duplicated product

  The steadiest, by definition, type of the project. Release of a duplicated product always is characterized by lower expenses for its(his) manufacture, in comparison with release of individual copies (it is similar – the conveyor and manual skills). In the given conditions, use of lungs metodology in the pure state, as a rule, is impossible, as there is no opportunity constantly to work with the customer. In this case all depends on a way of management of a command(team), the developed traditions, its(her) tactical and strategic purposes.

  Outsourcing

  The given kind of projects is characterized by the distributed(allocated) structure and primary preconditions to weighting process as dialogue with the customer occurs(happens) in the form of documents of the established(installed) sample. If the western party(side) gives to a command(team) the technological process at it(her), certainly, freedom of a choice does not remain. Otherwise it is necessary to stop the choice on a certain process of average weight which, on the one hand, would suffice for normal interaction with the customer, and on the other hand it(he) would be dynamical and steady.

  The conclusion

  In any case, all the above-stated conclusions are approximate as the situation in each concrete case is in own way unique and standard recipes for process of manufacture ON are not present and hardly ever will be. This sphere of activity of the person is still very young and sufficiently depends on the human factor. However, the author of clause(article) hopes, that the resulted(brought) review metodology and the brief analysis of their applicability will help(assist) you to understand an essence of a question and to make correct decisions. It is necessary to remember only, that « rather small increase in weight of used methodology conducts to rather big increase in cost of the project » [1].

   

  Derenchenko Andrey Gennadevich

  The bibliographic list:

  1. A. Cockburn. Agile Software Development, 2001, Addison Wesley

  2. A. Cockburn. Cristal Clear, 2002, Addison Wesley (prepares for printing)

  3. Mark C. Paulk. Extreme Programming from CMM perspective, Paper for XP Universe, Raleigh, NC, 2001

  4. Martin Fowler. The New Methodology (www.martinfowler.com/articles/newMethodology.html)

  5. A Guide to the Project Management Body of Knowledge, PMI, 2000

  6. Jim Highsmith. Agile Methodologies. Problems, Principlee and Practices, Cutter consortium, 2001 (www.surgeworks.com/resources/papers/AgileMethodologiesXP2001.pdf)

  7. Angelo Corsaro, eXtreme Programming Concepts, Department of computer science, Washington university, 2001

  8. Thomas Dudziak. eXtreme Programming. An Overview. Methoden und Werkzeuge der Softwareproduktion WS 1999/2000

  9. Spice. Consolidated product. Software Process Assessment (http: // www.sqi.gu.edu.au/spice)

  10. N.Saprykina, And Abarykov, A.Grigoriev. Certification of the Russian IT-companies, PCWeek, *41 (311)

  11. John Smitm. A Comparision of RUP and XP, Rational Software White Paper, 2000

  12. Gary Pollice. Using The Rational Unified Process For Small Projects: Expanding Upon eXtreme Programming, Rational Software White Paper, 2000

  13. McConnell. Software Project Survival Guide, Microsoft Press, 1998

  14. Philippe Kruchten. The Rational Unified Process, An Introduction, Second Edition, Addison-Wesley, Addison-Wesley, 2000

  15. Tom DeMarko, Cutter Trends Report on light methodologies, 2000

  16. Jim Highsmith, E-Project Management: Harnessing Innovation And Speed, Cutter consortium, 2001, VOL 1, No. 1

  17. Kent Beck, Mike Beedle etc, Manifesto for Agile Software Development (http: // agilealliance.org)

  18. Assessing the Rational Unified Process against ISO/IEC15504-5: Information Technology Software Process Assessment Part 5: An Assessment Model And Indicator Guidance. Rational Corporation Whitepaper, 2000

  19. Reaching CMM Levels 2 and 3 with the Rational Unified Process. Rational Corporation Whitepaper, 2000

  20. http: // www.objectmentor.com/resources/articles/RUPvsXP.pdf

  21. A. Cockburn. Surviving Object-Oriented Projects (The Agile Series for Software Developers), Addison Wesley 1998