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.
There