Work for users
When developing each project, it is important to remember one thing - what this project is done for. Represent the ultimate goal, that's what matters most.
We are writing a program, puzzling over a new algorithm or class interaction system, using technologies, new language features, spending time and energy on correct writing. And at the end - somewhere there sits a user, our client or client of our client, and uses our product. And he may not know anything about programming, in general. There are buttons, a screen, our application or site - and that's it. What is inside is not disturbed 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 is written on it, 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 is necessary to understand and accept as the fact that all these technologies are based on the consumption of end users. Those. they appeared not just like that. All that we do, what we learn - all this for users. We make their lives easier, they pay us money, we get the benefit and we live on it. E-mail, search engines, social networks, the Internet, CRM-systems, accounting software, 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 stands out two branches:
They are actually similar, the cascade 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 obtain a list of software requirements (functional specifications), and at the “Design” phase, a document describing methods and plans for implementing these requirements for programmers is created based on the list of requirements. Next, the program code is created and all program parts are integrated, which are tested and after successful testing, installation is performed on the customer’s system, and then we enter the “Support” phase, which includes user training, documentation, and heavy phone conversations with customer support.
')
Notice some discrepancy? I am yes. Let's do it again, only easier and taking into account the fact that we are still guided by the principle of “everything for the user”. Imagine a situation, user A. in January 2009 realized that he needed a program, justified the requirements to his superiors, the authorities accepted the reasonableness of the requirements and decided to allocate part of the budget to order the new program, and ordered it to us. Well, you understand that the reasonableness of the requirements from the point of view of the authorities - this is extra money. Well, that is ordering the entire program (+ legal documents, user training and user manual, and 13 percent VAT) costs less than the profit it is going to make from using our program.
User A. comes to us and explains that how much and what he wants. He formulates requirements for our product manager. In a language understandable to them, the product manager listens and writes down, this is the “Requirements Definition” phase. And of course, on the basis of this, the budget for writing the program and the deadlines are already laid. Here it is important to understand how much information is lost, the original goal is lost - to earn money using the program for a while more than the development of the program itself will cost. Second, how much does the product manager have the right to talk about timing and cost? Of course, a specific senior programmer is involved here, or Team Leader, who will estimate and tell you how much and how much time, but (!) Without taking into account legal documents, coffee expenses, rent and scheduled repairs of the company's premises and of course PROFIT. The senior programmer will announce the figure in person-days. Suppose 400 man-days (MD) or 20 man-months (did everyone read?). In general, they formed functional requirements, signed an agreement, letting user A. go back to the office and ask to come in 5-6 months after 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, makes a development plan in MS Project. Distributes tasks to each programmer when they start writing the program itself, gathering them together every hour, checking whether everything is moving according to plan.
Putting it all together in the phase of "Integration" checking the work of the architect. The architect is one of the key figures in the design, if he makes a mistake, it is revealed at a later stage of testing, the cost of each of his mistakes is very high, which will inevitably lead to an increase in time and cost, and will also affect the overall mood of the team. The failure of this phase takes us back to the “Design” phase and affects the budget.
If everything is good (it never happens), we go to the “Testing” phase, identifying small errors in a separate module leads to correction only inside this module, but identifying errors in the entire system throws us back into the “Design” phase and this is very expensive pleasure.
The “Installation” and “Support” phases are the same integration, only for end users. Here we are waiting for the most difficult problems. We meet again with User A. It has been 10 months, in November 2009, the court yard. During this time, many things can change, and our product during this time may become unclaimed.
Technically, when all signed requirements are fulfilled, after deducting all expenses for mistakes, we make a profit. But have we achieved the ultimate goal? The ultimate goal was to increase the efficiency of the company through the use of our program and, as a consequence, to obtain additional profit for the customer. If it is, it is not as big as we would like, too many risks are inherent in the cascade technology itself.
Next, an iterative development model should address these risks.
The project with this approach in each phase of development passes a repeating cycle:
Actually, the iterative approach itself speaks for itself. Starting the 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, a subset of requirements is highlighted, on the basis of which all further versions will be built in the future. The senior programmer and architect develops a plan for the implementation of only this iteration. The development team (or at the beginning it may be one) implements the requirements in the program and sends them for testing and re-analysis. These two phases can pass simultaneously. When errors are detected in the program, a patch is released (fixes in this version). And when errors are found in the architecture of the program, the next iteration adds a system redesign taking into account the reanalysis.
The iterations themselves are rather short, but at the very beginning we can identify and solve one of the most costly mistakes - the errors in architecture. In addition, for user A. after the first iteration, we can already show a prototype of the program, and get feedback, adjust the requirements and lay them out 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 it to a greater degree. Delivery of the product is not in 10 months, but in parts every 1-2 months. During this time, the personnel of the customer can study and get used to the new system, suggest and contribute their ideas and additions, thereby helping to create a more efficient solution.
But there are a lot of pitfalls here, because the relationship with the end user comes to the fore, and the user will be judged on the quality of work by the program and support service. In the development process we must pay special attention to testing and installing the product. About this in the following articles.
We are writing a program, puzzling over a new algorithm or class interaction system, using technologies, new language features, spending time and energy on correct writing. And at the end - somewhere there sits a user, our client or client of our client, and uses our product. And he may not know anything about programming, in general. There are buttons, a screen, our application or site - and that's it. What is inside is not disturbed 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 is written on it, 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 is necessary to understand and accept as the fact that all these technologies are based on the consumption of end users. Those. they appeared not just like that. All that we do, what we learn - all this for users. We make their lives easier, they pay us money, we get the benefit and we live on it. E-mail, search engines, social networks, the Internet, CRM-systems, accounting software, 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 stands out two branches:
- Cascade (or waterfall) model
- Iterative development model
Cascade model
They are actually similar, the cascade model is, let's say, a draft version of a flexible development model. Here are the phases of the cascade model:
- Determination of requirements
- Design
- Construction
- Integration
- Testing
- Installation
- Support
All phases go one after another strictly sequentially, i.e. at the “Requirements Definition” stage, we obtain a list of software requirements (functional specifications), and at the “Design” phase, a document describing methods and plans for implementing these requirements for programmers is created based on the list of requirements. Next, the program code is created and all program parts are integrated, which are tested and after successful testing, installation is performed on the customer’s system, and then we enter the “Support” phase, which includes user training, documentation, and heavy phone conversations with customer support.
')
Notice some discrepancy? I am yes. Let's do it again, only easier and taking into account the fact that we are still guided by the principle of “everything for the user”. Imagine a situation, user A. in January 2009 realized that he needed a program, justified the requirements to his superiors, the authorities accepted the reasonableness of the requirements and decided to allocate part of the budget to order the new program, and ordered it to us. Well, you understand that the reasonableness of the requirements from the point of view of the authorities - this is extra money. Well, that is ordering the entire program (+ legal documents, user training and user manual, and 13 percent VAT) costs less than the profit it is going to make from using our program.
User A. comes to us and explains that how much and what he wants. He formulates requirements for our product manager. In a language understandable to them, the product manager listens and writes down, this is the “Requirements Definition” phase. And of course, on the basis of this, the budget for writing the program and the deadlines are already laid. Here it is important to understand how much information is lost, the original goal is lost - to earn money using the program for a while more than the development of the program itself will cost. Second, how much does the product manager have the right to talk about timing and cost? Of course, a specific senior programmer is involved here, or Team Leader, who will estimate and tell you how much and how much time, but (!) Without taking into account legal documents, coffee expenses, rent and scheduled repairs of the company's premises and of course PROFIT. The senior programmer will announce the figure in person-days. Suppose 400 man-days (MD) or 20 man-months (did everyone read?). In general, they formed functional requirements, signed an agreement, letting user A. go back to the office and ask to come in 5-6 months after 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, makes a development plan in MS Project. Distributes tasks to each programmer when they start writing the program itself, gathering them together every hour, checking whether everything is moving according to plan.
Putting it all together in the phase of "Integration" checking the work of the architect. The architect is one of the key figures in the design, if he makes a mistake, it is revealed at a later stage of testing, the cost of each of his mistakes is very high, which will inevitably lead to an increase in time and cost, and will also affect the overall mood of the team. The failure of this phase takes us back to the “Design” phase and affects the budget.
If everything is good (it never happens), we go to the “Testing” phase, identifying small errors in a separate module leads to correction only inside this module, but identifying errors in the entire system throws us back into the “Design” phase and this is very expensive pleasure.
The “Installation” and “Support” phases are the same integration, only for end users. Here we are waiting for the most difficult problems. We meet again with User A. It has been 10 months, in November 2009, the court yard. During this time, many things can change, and our product during this time may become unclaimed.
Technically, when all signed requirements are fulfilled, after deducting all expenses for mistakes, we make a profit. But have we achieved the ultimate goal? The ultimate goal was to increase the efficiency of the company through the use of our program and, as a consequence, to obtain additional profit for the customer. If it is, it is not as big as we would like, too many risks are inherent in the cascade technology itself.
Next, an iterative development model should address these risks.
Iterative development model
The project with this approach in each phase of development passes a repeating cycle:
- Planning
- Implementation
- Check
- Evaluation
Actually, the iterative approach itself speaks for itself. Starting the 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, a subset of requirements is highlighted, on the basis of which all further versions will be built in the future. The senior programmer and architect develops a plan for the implementation of only this iteration. The development team (or at the beginning it may be one) implements the requirements in the program and sends them for testing and re-analysis. These two phases can pass simultaneously. When errors are detected in the program, a patch is released (fixes in this version). And when errors are found in the architecture of the program, the next iteration adds a system redesign taking into account the reanalysis.
The iterations themselves are rather short, but at the very beginning we can identify and solve one of the most costly mistakes - the errors in architecture. In addition, for user A. after the first iteration, we can already show a prototype of the program, and get feedback, adjust the requirements and lay them out 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 it to a greater degree. Delivery of the product is not in 10 months, but in parts every 1-2 months. During this time, the personnel of the customer can study and get used to the new system, suggest and contribute their ideas and additions, thereby helping to create a more efficient solution.
But there are a lot of pitfalls here, because the relationship with the end user comes to the fore, and the user will be judged on the quality of work by the program and support service. In the development process we must pay special attention to testing and installing the product. About this in the following articles.
Source: https://habr.com/ru/post/78122/
All Articles