Silver Bullets Toolkit
Konstantin Berlinskii
The wars between IT-methodologies do not calm down. Every several years we receive absolutely new, quick, simple, and effective methodology. It finely should solve the main problem – the creation of the qualitative software on term.I think that the single truth concerning methodologies is that they do not exist at all.There are only successful project solutions (SPS). That can work (or not) in a particular situation. The goal of this book is to offer IT-community to find and classify them.
Silver Bullets Toolkit
Konstantin Berlinskii
© Konstantin Berlinskii, 2022
ISBNВ 978-5-0056-9705-9
Created with Ridero smart publishing system
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 6
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.
