December 13, 2009 at 14:46Work for users
When developing each project, it is important to remember one thing - what this project is for. Presenting the ultimate goal is the most important thing.
We write a program, puzzle over a new algorithm or system of class interaction, use technologies, new features of the language, spend time and effort on the correct spelling. And in the end - somewhere there the user sits, our client or the client of our client, and uses our product. And he may be unaware of programming, in general. There are buttons, a screen, our application or website - and that’s it. What is inside does not bother him at all. It is true, the user is completely indifferent to what you used in the program: for or foreach. The most annoying thing is that they are completely indifferent to what it is written on, be it Delphi, VB or C #. And they have no idea about version control systems, frameworks, development through testing, and design patterns.
But without users we would not exist. It must be understood and accepted as a fact that all these technologies are based on the consumption of end users. Those. they appeared for a reason. All we do, what we learn - all this for users. We make their life easier, they pay us money, we benefit and live on it. E-mail, search engines, social networks, the Internet, CRM systems, accounting programs, project management systems - all for the consumption of users.
Here is a good example of how far you can go trying to satisfy users: http://lenta.ru/news/2007/04/09/butty/
From technology development programs there are two branches:
They are actually similar, a cascading model is, let's say, a draft version of a flexible development model. Here are the phases of the cascade model:
All phases go one after another strictly sequentially, i.e. at the “Requirements Definition” stage, we get a list of software requirements (functional specifications), at the “Design” phase, on the basis of the requirements list, a document is created that describes for programmers ways and plans for implementing these requirements. Next, the program code is created and all parts of the program are integrated that are tested and after successful testing, the installation is performed on the customer’s system, and then we enter the “Support” phase, which includes user training, documentation, languid telephone calls with customer support.
Have you noticed some discrepancy? I am. Let's do it again, only easier and given the fact that we are still guided by the principle of "everything for the user." Imagine the situation, user A. in January 2009 realized that he needed a program, justified the requirements for the authorities, the authorities accepted the reasonableness of the requirements and decided to allocate part of the budget to order a new program, and ordered it for us. Well, you understand that the reasonableness of requirements from the point of view of superiors is extra money. Well i.e. ordering the entire program (+ legal documents, user training and user guidance, and 13 percent VAT) costs less than the profit that he is going to get from using our program.
User A. comes to us and explains what, how much, and what he wants. He formulates the requirements for our product manager. In a language that they understand, the product manager listens and writes down; this is the “Requirement Definition” phase. And of course, based on this, the budget for writing the program and the deadlines are already being laid. It is important to understand how much information is lost, the original goal is lost - to earn money on using the program for some time more than the development of the program will cost. Second, how much is a product manager entitled to talk about timing and cost? Of course, a specific senior programmer, or Team Leader, is involved here, who will estimate and tell you how much and how much time, but (!) Without taking into account legal documents, coffee costs, renting and planned repairs of the company premises and of course PROFIT. The senior programmer will announce the number in man-days. Let's say 400 person-days (MD) or 20 person-months (all read?). In general, we formed functional requirements, signed a contract, let go of user A., he works back in the office, and we ask you to come back after 5-6 months when the product is ready for installation.
We take the specifications, go to the architect, the architect conjures the system and together with the senior programmer bring the technical requirements to mind. The senior programmer takes them, draws up a development plan in MS Project. It distributes tasks to each programmer when they start writing the program itself, gathering them together hour by hour, checking whether everything is moving according to plan.
Putting it all together on the “Integration” phase, checking the work of the architect. An architect is one of the key figures in development, if he makes a mistake, it is detected at a later stage of verification, the cost of each of his mistakes is very high, which will inevitably lead to an increase in both time and cost, and also affect the general mood of the team. The failure of this phase brings us back to the Design phase and affects the budget.
If everything is fine (it never happens), we proceed to the “Testing” phase, identifying small errors in a separate module leads to correction only inside this module, but detecting errors in the entire system throws us back to the “Design” phase and this is very expensive pleasure.
The “Installation” and “Support” phases are the same integration, only for end users. Here the most difficult problems await us. We meet again with User A. 10 months have passed, in the courtyard of November 2009. A lot of things can change during this time, and our product during this time may become unclaimed.
Technically, when all the signed requirements are met, after deducting all the expenses for errors, we make a profit. But have we reached the ultimate goal? The ultimate goal was to increase the efficiency of the company through the use of our program and, as a result, receive additional profit by the customer. If it does, then it’s not as big as we would like, too many risks are inherent in the most cascading development technology.
The next is an iterative development model that should address these risks.
The project with this approach in each phase of development goes through a repeating cycle:
Actually, the iterative approach itself speaks for itself. Starting development, we focus on the main functions of the program and analyze the task. User A. with the product manager again compiles a list of requirements, but at this stage, that subset of the requirements is highlighted, on the basis of which all further versions will be built in the future. A senior programmer and architect develops a plan for implementing only this iteration. The development team (or at the beginning it may be one) implements the requirements in the program and transfers it for testing and reanalysis. These two phases can take place simultaneously. If errors are detected in the program, a patch is released (corrections in this version). And when errors are detected in the program architecture, a system redesign is added to the next iteration, taking into account reanalysis.
Iterations themselves are a short process, but at the very beginning we can identify and solve some of the most expensive errors - errors in architecture. In addition, for user A., after the first iteration, we can already show the prototype of the program, and get feedback, adjust the requirements and lay them on for implementation in the future.
And so, step by step, iteration by iteration, we gradually implement all the necessary functionality. Using this method of creating a software product, we often interact with the end user, and thereby create a product that will satisfy him more. Product delivery does not take place after 10 months, but in parts every 1-2 months. During this time, the customer’s staff can study and get used to the new system, suggest and make their ideas and additions, thereby helping to create a more effective solution.
But here there are a lot of pitfalls, since relationships with the end user come to the fore, and the user will judge the quality of work by the program and support service, then in the development process we should pay special attention to testing and installing the product. About it in the following articles.
We write a program, puzzle over a new algorithm or system of class interaction, use technologies, new features of the language, spend time and effort on the correct spelling. And in the end - somewhere there the user sits, our client or the client of our client, and uses our product. And he may be unaware of programming, in general. There are buttons, a screen, our application or website - and that’s it. What is inside does not bother him at all. It is true, the user is completely indifferent to what you used in the program: for or foreach. The most annoying thing is that they are completely indifferent to what it is written on, be it Delphi, VB or C #. And they have no idea about version control systems, frameworks, development through testing, and design patterns.
But without users we would not exist. It must be understood and accepted as a fact that all these technologies are based on the consumption of end users. Those. they appeared for a reason. All we do, what we learn - all this for users. We make their life easier, they pay us money, we benefit and live on it. E-mail, search engines, social networks, the Internet, CRM systems, accounting programs, project management systems - all for the consumption of users.
Here is a good example of how far you can go trying to satisfy users: http://lenta.ru/news/2007/04/09/butty/
Software Development Technologies.
From technology development programs there are two branches:
- Cascading (or waterfall) model
- Iterative Development Model
Cascade model
They are actually similar, a cascading model is, let's say, a draft version of a flexible development model. Here are the phases of the cascade model:
- Definition of requirements
- Design
- Construction
- Integration
- Testing
- Installation
- Support
All phases go one after another strictly sequentially, i.e. at the “Requirements Definition” stage, we get a list of software requirements (functional specifications), at the “Design” phase, on the basis of the requirements list, a document is created that describes for programmers ways and plans for implementing these requirements. Next, the program code is created and all parts of the program are integrated that are tested and after successful testing, the installation is performed on the customer’s system, and then we enter the “Support” phase, which includes user training, documentation, languid telephone calls with customer support.
Have you noticed some discrepancy? I am. Let's do it again, only easier and given the fact that we are still guided by the principle of "everything for the user." Imagine the situation, user A. in January 2009 realized that he needed a program, justified the requirements for the authorities, the authorities accepted the reasonableness of the requirements and decided to allocate part of the budget to order a new program, and ordered it for us. Well, you understand that the reasonableness of requirements from the point of view of superiors is extra money. Well i.e. ordering the entire program (+ legal documents, user training and user guidance, and 13 percent VAT) costs less than the profit that he is going to get from using our program.
User A. comes to us and explains what, how much, and what he wants. He formulates the requirements for our product manager. In a language that they understand, the product manager listens and writes down; this is the “Requirement Definition” phase. And of course, based on this, the budget for writing the program and the deadlines are already being laid. It is important to understand how much information is lost, the original goal is lost - to earn money on using the program for some time more than the development of the program will cost. Second, how much is a product manager entitled to talk about timing and cost? Of course, a specific senior programmer, or Team Leader, is involved here, who will estimate and tell you how much and how much time, but (!) Without taking into account legal documents, coffee costs, renting and planned repairs of the company premises and of course PROFIT. The senior programmer will announce the number in man-days. Let's say 400 person-days (MD) or 20 person-months (all read?). In general, we formed functional requirements, signed a contract, let go of user A., he works back in the office, and we ask you to come back after 5-6 months when the product is ready for installation.
We take the specifications, go to the architect, the architect conjures the system and together with the senior programmer bring the technical requirements to mind. The senior programmer takes them, draws up a development plan in MS Project. It distributes tasks to each programmer when they start writing the program itself, gathering them together hour by hour, checking whether everything is moving according to plan.
Putting it all together on the “Integration” phase, checking the work of the architect. An architect is one of the key figures in development, if he makes a mistake, it is detected at a later stage of verification, the cost of each of his mistakes is very high, which will inevitably lead to an increase in both time and cost, and also affect the general mood of the team. The failure of this phase brings us back to the Design phase and affects the budget.
If everything is fine (it never happens), we proceed to the “Testing” phase, identifying small errors in a separate module leads to correction only inside this module, but detecting errors in the entire system throws us back to the “Design” phase and this is very expensive pleasure.
The “Installation” and “Support” phases are the same integration, only for end users. Here the most difficult problems await us. We meet again with User A. 10 months have passed, in the courtyard of November 2009. A lot of things can change during this time, and our product during this time may become unclaimed.
Technically, when all the signed requirements are met, after deducting all the expenses for errors, we make a profit. But have we reached the ultimate goal? The ultimate goal was to increase the efficiency of the company through the use of our program and, as a result, receive additional profit by the customer. If it does, then it’s not as big as we would like, too many risks are inherent in the most cascading development technology.
The next is an iterative development model that should address these risks.
Iterative Development Model
The project with this approach in each phase of development goes through a repeating cycle:
- Planning
- Implementation
- Check
- Rating
Actually, the iterative approach itself speaks for itself. Starting development, we focus on the main functions of the program and analyze the task. User A. with the product manager again compiles a list of requirements, but at this stage, that subset of the requirements is highlighted, on the basis of which all further versions will be built in the future. A senior programmer and architect develops a plan for implementing only this iteration. The development team (or at the beginning it may be one) implements the requirements in the program and transfers it for testing and reanalysis. These two phases can take place simultaneously. If errors are detected in the program, a patch is released (corrections in this version). And when errors are detected in the program architecture, a system redesign is added to the next iteration, taking into account reanalysis.
Iterations themselves are a short process, but at the very beginning we can identify and solve some of the most expensive errors - errors in architecture. In addition, for user A., after the first iteration, we can already show the prototype of the program, and get feedback, adjust the requirements and lay them on for implementation in the future.
And so, step by step, iteration by iteration, we gradually implement all the necessary functionality. Using this method of creating a software product, we often interact with the end user, and thereby create a product that will satisfy him more. Product delivery does not take place after 10 months, but in parts every 1-2 months. During this time, the customer’s staff can study and get used to the new system, suggest and make their ideas and additions, thereby helping to create a more effective solution.
But here there are a lot of pitfalls, since relationships with the end user come to the fore, and the user will judge the quality of work by the program and support service, then in the development process we should pay special attention to testing and installing the product. About it in the following articles.