Бесплатный фрагмент - Silver Bullets Toolkit

1. INTRODUCTION

“Well, — you will say after reading the headline of this book. — There is one more new profit appeared, one more impostor who tries to teach us how to live, how we should implement the software projects! We have already found the methodology that copes with all the problems. We adapted it for our needs and there is likely to be less problems.”

And you will be right… but not completely. In no way I consider myself some kind of a new Messiah who will finely tell everybody how to achieve a success.

But I am really interested in a method of effective software development (and as a result of this knowledge I am interested in extending the level of my professional skills as an informational system developer).

This book is not a written justification against a certain methodology. But before, on the forums of the special sites I permitted myself to express my rough point of view about different up-to-date development methodologies that were supported by their staunch defenders with a religious fanatic ardor.

You will not find here any arguments for a certain methodology, as can be supposed, taking into account that for a long period of time I was a faithful supporter of the RUP methodology, I learned it and took an active part in its introducing in activity of the company where I was working.

Moreover by that time I was in the firm belief that a strict divisions of the team members working over the project into separate roles and appropriate functions could make the process of development easily controlled and successful while their participants — satisfied with the work.

In this connection with my book I have the risk to incur just anger of defenders and supporters of the existing methodologies of software development or those that will appear in the future.

However, everybody has the right to express his own opinion and I will use this right.

I am sure that the truth about different methodologies is that they do not exist at all.

But now let help those who has fainted away to come around and confess to themselves what is the newest methodology of software development about which you have got to know from the latest marketing statement of a company.

Or what is the methodology that you use now in your day-to-day activity, where you have put many resources (learning materials, courses for key specialists with business trips in other city/country and finally the most important thing — time)?

You think that the methodology plays an organization role, that clearly prompts how you should work in order to achieve success in the field of informational technologies. And finally you hope to take a competitive priority “throwing dust in eyes” of the potential customers by the phrases difficult for understanding, such as “We are on the 6th level of CMM”, “Re-engineering of the business processes”, “Automation of the chaos by means of function separation in the alternative activities”, etc.

However, running the same methodology in different organizations and projects (frequently in development stages of the same project) shows for some reasons absolutely different results. Those things that perfectly work in particular cases and serve as motivation, in other cases, on the contrary, are obstacles.

What is the main reason, you could ask. I think that the project success depends on the following:

— Resources available (first of all it is the developers quality and the second — the time)

— Way of their interactions

If there are resources available and they collaborate with the maximum efficiency I think the project stands a better chance to result in something valuable.

As for methodologies, it seems to me that all of them describe the final collection of different efficient use methods of scarce resources.

My point of view consists in the fact that number of these methods (successful project solutions SPS) is infinite and you should not restrict yourself to the subset in the context of the methodology X. if we wish to advance in the field of successful program development we should gather these solutions (in a similar way as pattern) and learn to use them in a necessary situation.

This book is an effort to collect all the methods of successful development clear for me in a single place.

I wish you pleasant reading and good luck!

2. THE REASONS WHY THIS BOOK WAS WRITTEN

This book was written in order to collect in a single whole those things that I call “gold crumbs of knowledge”, dispersed in the great number of sources such as Internet, literature and some kind of folk arts.

Phrases like “Two heads are better than one” or principle “divide et impera”, known as early as in the Rome Empire, contributed in the development of program engineering more than both Microsoft and IBM.

After reading any book, article or message on the forum I was always interested in what useful I could get from this source exactly. Does it contain any useful thought unknown for me before? There were luckily to be new ideas in the most cases, but unfortunately they were diluted with secondary information that confused the issue.

Therefore after reading the next work I tried as far as possible to make up a summary with a list of the main ideas (unknown or not very obvious by that moment for me) that the author tried to express.

For example, here is the following result I have got after reading the book [3]:

1. The business-process description in text is much smaller than graphic format (it’s really truth — the greatest working problem with diagram was that the printer did not support A3 and A2 formats).

2. Customers will read the text, understand and sign it (admit or express their claims) faster than learn UML (for example, I spent a lot of time for explaining the include/extended link on usecase diagrams.

3. A new employee will easily learn how to write the text in the format of Cockburn’s usecases than make him use UML and the supporting product correctly (for example, Rational Rose — graphics editor that leaves much to be desired).

4. Good classification of aims — you should always work on the same goal level. The level comes up if you ask the question “Why?”, and comes down if you ask “How?” (this is the great art to be on the needed goal level — the diagrams become smaller and more general or too big and detailed).

5. An excellent, intuitive comprehensible pattern of use case description (main scenario from 10 steps without “if” + main scenario extending + additional information).

6. An excellent idea concerning methods of multivariate analysis of the requirements collected (for example, with the help of electronic worksheet) — use of sorting, grouping in different attributes (importance, term, module, role)

7. And finally, I consider that the most important thing is that the lower the goal standard is, the less useful and obvious diagrams are.

It follows from this the idea of dividing the task between different CASE-tools: for creating diagrams of higher level (business process scenario, schemes of traffic, diagram of main document mode, collaboration between program module) to use tools effectively applied for drawing diagrams, connections between them (Rational Rose, MS Visio), but for more detailed description to use Cockburn’s use cases.

I must confess that writing this book was a quite risky business: every time I can get a stab in the back from someone with 20 years of experience in development who devoted much time of his life for promoting the X methodology and can hear the phrase like “you should make as many projects as I did and then you would offer the solutions of yours”.

My general age does not exceed 24 (including only 3 years of commercial software development experience) and I have 5 embodied projects behind myself. According to “common standard” I should wait for my 40s and then express my thoughts in written.

But to hell with all these rules! You should live here and now and if you get the chance to do more than you can, do it immediately. There is little probability that you will lift a big iron case (see the movie One Flew over the Cuckoo’s Nest). But you will not ever succeed if you do not make at least an effort.

I am really interested in my profession and every day long I try to make my life (and professional activity) better and happier as more as possible. Of course, it is foolish to think that writing something like book, article or something like “advertisement to myself” will increase my or somebody else’s education (more details see in the article [2]). But nevertheless it has the sense.

Release of the book will enlarge my “virtual learning” (in other words what attitude the potential employers will have towards me). All of these things (meeting new persons, receiving new information) extend fair chances to increase my real education i.e. real benefits that I bring to the projects which I take part in. Enlarging real education incites me to publish new materials. And so on.

By this book I would like to prove (most of all to myself) that our world is much easier than it may seems for the first glace. It is possible to succeed in spite of those obstacles that can be encountered in our way.

There is a story about a millionaire who said: “I can tell you how I earned every million of mine, except the first one”. Indeed if you perceive the life success as a goal for climbing up the endless stairs, it is really difficult to make the first step. I tried to make this book as an exam for the right to climb up the first step.

And finally, it is a groove to write a book like to compose music, draw a picture or sculpture.

Actually the beauty will save the world, software projects and me.

When you see how fragments of thoughts and phrases after patient processing (with painful search of synonyms and making up participles) turn into a coherent text with a logical plot, you derive great incomparable enjoyment.

Programming gives this kind of pleasure as well. It is connected with the moment when disembodied data, requirements, orders, instructions, rumors and fantasies related to the system are like huge heavy stones suddenly become to form in your head a single sculpture. Every particle of a puzzle finds its own place and it remains only to bring them back to life. The stone statue wakes up and hand-made creature begins to take its first steps. This is the greatest pleasure of our profession.

3. ORIGINAL IDEA

Initially I had the following idea concerning this book (I had intention to release only paper variant of the book): firstly, to make an overview of up-to-date methodologies of software development, and secondary, to express the main idea that all of the methodologies use one of the successful project solutions. (See the fig. 1).

Figure 1. Successful project solutions area

Х — axis of software lifecycle stages;

Y — importance level of successful project solutions for a concrete stage

1..9 — Lifecycle (1-project base “Management”);

Circles — Successful project solutions known by this time;

Shadings — different methodologies of software development including the solutions in their postulate list.

In the middle of the book I planned to leave five blank sheets. Every sheet would be a form for entering a successful solution discovered by a reader (rather a writer) in the process of developing the next solution. The form would be standard: name,

code of lifecycle stage, effectiveness evaluation, description and additional information sources for solving the problem.

The concluding chapters would be “Table of Contents” and “Bibliography”. Of course, these chapters would be filled in manually. Everybody has his own “golden set” of books, WEB resources and phone numbers of neighboring pizzerias.

The idea lay in the fact that everybody would write his own book and even insert his initials in the cover.

But later I looked through my home library and found that the idea concerning book addition by a reader had been already made a reality. These are so-called “Notes”. I did not have notes at all. That is why I decided to refer to the creative work more professionally, and thus, the book gained the present form.

Also my plans included (in the case of positive evaluation of my book by qualified developers and free time available) further development of the theory about “general successful project solutions areas” and its release in the form of the Internet web-site. This site would be some kind of a portal for information exchange between software developers and supplement in databases of successful solutions. The main components of the site would be the following: developer Forum, divided into different themes (Lifecycle stages, Methodologies, Products, and etc.), Guest book, User Profiles and the most important thing — Database of successful project solutions, available for publicity. The site user would value every new solution (or changes in description of old one), and in case of the positive result it would be added to the database.

However, I’ve got the thing that I’ve got. As for book continuation, I think that it would be written in the moment when my professional experience would be brought to the qualitative new level. Maybe it would take 20 years (as in the case with F. Brooks) or less. By the way, as for Brooks: did you noticed differences between dedications of 1975 and 1995? In the first one the author mentioned his direct boss, while in the second — Nancy, God’s gift to him.

At last the family and all the things connected appear in the list of life values. But does “the core idea of the program engineering” lie in this?

4. GRATITUDE

Thus, here are the persons who influenced my growth much and whom I bless for this:

— My parents, they gave me birth; -) I prefer not to live in the times when the world terrorism is victorious, but there’s nothing to be done.

— My sister for support.

— Technical University of Moldova — for higher technical education not to be very good, but better among others in the Republic. In the book [15] the author says that you should set yourself an object, get the education as good as it is possible, and then for God’s sake do something!

— Stratan Victor for excellent explanation of theory and help in practice of design patterns, OOP and etc. Thanks to him for the first version of Rational Rose 98.

— Serdtsev Vitaly — after watching his “magic” with assembly programs, С++, low-level programming, I took a great interest in my own profession and have not been regretting still. I recall the words of our department manager V. Beshliu: “You came here in the University with different aims, but in the case of graduation you will be fervent patriots of your profession”.

— Smolov Alexander — when the balance between joys and sorrows of a profession moves in favor of the last (idea from the book [6]), I sit down to my computer and struggle against aliens in my old kind XCOM (see website [15]), whom Alexander brought me on 3 diskettes with little elephants. Thanks to it all sad thoughts disappear, but you keep dreaming about little green men for a long time.; -)

— Dragoner V.V. — my thesis tutor. I set a pride aim to create an analogue of Rational Rose. I wrote a compiler of incoming C++ texts, Serdtsev — graphics for browser of objects and diagrams, Smolov — Russian sounds for insonification analysis results of texts through MSTextToSpeech. This project happily failed (by the thesis presentation only 50% of requirements were fulfilled), but sometimes misfortunes are more fruitful than success. I gained an experience in working with Rose, read a lot of materials concerning Rose and s. o.

— Paprotskii I.B. and Starashuk A.I. — my work in government enterprise Registru (see the article [1]) under their direction had a great impact on my professional activity and career growth.

— Zolotuhina E.B. for brilliant course of system analysis and information system development.

— Edward Durleshteanu (BitGenerator Company) — it was difficult but quite interesting to work together. I regret that difficulty outweighed interest.

And finally, Igor Toporet, by the present my direct boss and a real professional in his field. Many of my aims I could achieve faster thanks to him. I also hope that I helped him to achieve his aims.

5. SOFTWARE DEVELOPMENT METHODOLOGIES

5.1. RUP — Rational Unified Process

RUP was created in 1996 by the Rational Corporation with the assistance of Grady Booch, Jim Rumbaugh, Ivar Jackobson. It is truly fundamental work describing successful methodologies of software development. Software lifecycles, workflows, roles, activities, artifacts, and products supporting most of the lifecycle stages. This methodology is called “heavy”. It supports the UML. According to the general volume and significance, RUP as an independent knowledge base can be compared to MSDN.

The main idea of RUP is to assign the work of each team member. To my opinion, the greatest problem in this case is that it is quite difficult or even absolutely impossible to find people who will do only things they are asked to do. How much time they need to be tired of monotonous working? The sense of responsibility (as well as satisfaction with results) for the work completed in the framework of fixed working conditions is lost, isn’t it? Does the availability of coordinated interfaces serve as a quality assurance and effectiveness of work?

First of all, the products supporting this methodology are the products of the Rational Company: the basic product Rose (used almost in all development stages), SoDA (Software Documentation Automation), RequisitePro (Requirements Management), ClearQuest (Change Request), ClearCase (Configurion Management), Administrator (Project Repository Management), WorkBrench (Project Management), Quantify (Profiling Function Performance), Purify (Detecting Memory Errors and Leaks), PureCoverage (Monitor code coverage), Robot (Executing Test Suites), SiteLoad (Load Testing), SiteCheck (Dead Links Check). The RUP product called Rational XDE integrated in the Microfost.NET environment is now available.

5.2. XP — Extreme Programming

As regarded, this discipline of software development appeared, in other words its official registration took place in 2001, when in USA, Utah State, 17 supporters of agile methodologies worked out a manifesto with the main postulates. Kent Beck, Ward Cunningham and Ron Jeffries can be considered to be the ideologists of this method.

The main principles are the following: close communication, continuous testing, minimal documentation, maximal flexibility. Nevertheless it is better to present a text of this manifesto (see the book [4]):

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

— Individuals and interactions over processes and tools

— Working software over comprehensive documentation

— Customer collaboration over contract negotiation

— Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more”.

These are brief and clear explanations that make the proposed ideas available for broad masses.

At first XP suggested some revolutionary new principles of development. “It will not be necessary for you”, “You should find the simplest solution that may work”, “The Customer can change his requirements at any time”, “Either of the developers sitting next to each other can change whatever they like in the system”, and so on.

However I have just expressed my criticism concerning XP before. Many claims raised to XP will be withdrawn after more detailed acquaintance with it. The last projects in which I used to take part, was regarded to develop in the manner of XP.

There is the following criticism left:

— The idea of presence a customer and programmers side by side in one room is a fantastic wish, as to my opinion. Nobody argues that collaboration with a customer is a vitally important matter. But solving the problem lies as far in the sphere of the documents standard forms development on the collaborating level, and, on the other hand, in the faster integration (it is necessary to help a customer to define the requirements and correct his system view).

— Denial of “big prior design” stage is accepted only in the process of trivial system development (easy sites with emphasis on design, not programming, elementary one-user programs with minimum business-logic, etc.). At this point I’d like to quote from one of the authors: “Here I consider the decisions useful for development of complicate systems. If the application is found to be easy, why I should spend my time on it?” In a complex and interesting project it would be a criminal negligence not to create a framework of the system and the core principles of its functioning from the very beginning. Of course, real XP supporters would perceive with courage the information that in the center of the project development there is the use case appeared that makes to change the most part of code (or even worse to remove it). But I “m inclined to think that it is not acceptable.

— Dozens of user stories (sheets of paper with a few sentences characterized the use case), remained after the project completion cannot be regarded as a reliable documentation. It turns out that XP focuses only on the agile software development, but not on its maintenance. In the book [4] I came across the example of a failed project 3C implemented with the help of XP (salary accounting for Chrysler, I confirm that salary, in spite of its seeming simplicity, is one of the most complex branches of book-keeping where no a single team of programmer has been lost). The author says that when quite many collaborators left the service, unwritten project data and team memory were lost. As far as I can judge, apologists were over-diligent with minimization of documentation. Serious developers cannot trust the things that are considered by students attractive.

I would like to share my impressions of the work in the manner of XP. In comparison with RUP (or any other methodology with fixing stage results with the help of a requirements specification or design project, etc.), XP gives you the sense of uncertainty and anarchy in the beginning of the project. Business requirements and architecture change so quickly that after sitting a couple of days at home you may not recognize the structure of the basic classes (even if you have created them by yourself). At once you begin to be aware of the XP postulate concerning 40-hour workweek without overtime work. What for you should toil at a module up to 10 p.m. that you will not need tomorrow?

In the middle the architecture becomes stabilize and the end of the project is characterized by the confidence. No requirements change of a customer seems to be terrible. During continuous modifying architecture has to be processed accordingly all the changes to be implemented with the maximum simplicity. Programmers take a role of users working with a program design created by them. If they detect a flaw it is difficult to make changes in the system in the process of development and he may suffer some troubles. As a result, the design improves forcedly, and the system undergoes any change in business requirements.