Если мы заметили ошибку на этапе написания требований, то исправить ее — дело 1 минуты, просто скорректировали предложение в тексте, и все.
Пока придумывают архитектуру будущего кода, стоимость уже дороже. Представьте, что архитектор уже придумал, как это будет выглядеть, а вы хотите изменить фундамент:
Но это еще реально. А вот если мы уже все построили (написали код), то некоторые изменения просто нельзя внести и приходится мириться с багом. А даже если можно, то стоить это будет сильно дороже:
— аналитику поправить ТЗ;
— архитектору придумать, как поправить минимальными усилиями;
— разработчикам внести правки.
Почему на картинке Lee Copeland есть еще Release с самой большой стоимостью?
 |
| Картинка из книги Lee Copeland |
Потому что пока мы на этапе тестирования нашли проблему, то да, придется исправлять много кода, но все же этот код написан в последний месяц (или сколько времени у нас занимает выпуск одной версии продукта).
А вот если мы выпустили версию и уже сделали другую, третью пятую, десятую… А потом нашли баг в самой первой, то на том коде уже столько всего понастроено, в том числе и костылей. Что исправить вашу хочу-шку будет особенно сложно.
Тем не менее такой подход до сих пор используют в больших организациях на сотни человек. Там с требованиями работает один отдел аналитики, потом передают дальше и так по каскаду все приходит в тестирование. С проблемами ошибки в требованиях приходится мириться…
Так что запоминаем: чем раньше найдена ошибка, тем проще ее исправить!
Поэтому тестировщики так важны. Чем раньше они заметят проблемы, тем проще будет их исправить!
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
1. Может ли в модели жизненного цикла отсутствовать стадия Анализа требований? Аргументируйте свою точку зрения.
Считаю, что стадия Анализа требований не может отсутствовать в модели жизненного цикла ПО.
Во-первых, на данной стадии аналитик просчитывает насколько экономически, социально и технологически является осуществимый проект.
Во-вторых, аналитик собирает все требования от стейкхолдеров.
В-третьих, на выходе должно быть четко описанное техническое задание, по которому в дальнейшем будет проектироваться и разрабатываться ПО
2. На каких этапах SDLC аналитик может работать над требованиями (выявлять, анализировать, документировать, изменять)?
Думаю, аналитик на всех этапах SDLC может работать над требованиями. В любой момент может что-то измениться, если заказчик этого захочет и оплатит
3. Какой этап SDLC может предварять этап Планирования в рамках жизни продукта?
Честно признаюсь, не сам пришел к такому выводу, прочитал такое мнение:
«Первым шагом, перед планированием и анализом, в рамках программы разработки программного обеспечения является выявление текущей проблемы. Задать вопрос «Что мы можем сделать?», «Что нужно клиенту?». Этот этап SDLC означает получение информации от всех заинтересованных сторон, таких как клиенты, сотрудники, программисты и т.д.»
Честно говоря, изначально из твоей лекции я так понял, что выявление проблемы у заказчика, вопросы «что мы можем?» и «что нужно клиенту?» относятся к планированию.
4. На каком этапе SDLC цена исправления ошибки ниже?
Думаю, что на этапе планирования и анализа требований цена исправления ошибки ниже всего.
Задачки на логику.
1. 0 или 360
2.Я бы посчитал сколько всего депо в Москве, т.к. все трамваи ночью живут в депо и как правило в одном и том же.
Определил бы восколько трамваи выходят на линию, а далее по каждому депо подсчитать сколько трамваев вышло на линию.
…
As we know during development of any software product the development teams follow the Software Development Life Cycle (SDLC) processes. But development process is not so easy and always runs smoothly. During the development process when product is being developed different types of defects or bugs arise with product. So these defects are identified and resolved throughout development process just to deliver a good quality software product at last. So in this article, we will discuss these bugs in software development process and how these are identified during software testing, and how these are resolved.
What is a Bug/Defect?
A defect is an error or bug in an application that is created during building or designing software and due to which software starts to show abnormal behaviors during its use. So it is one of important responsibilities of the tester to find as much as defect possible to ensure quality of product is not affected and end product is fulfilling all requirements perfectly for which it has been designed and provide required services to end-user. Because as much as defects will be identified and resolved then software will behave perfectly as per expectation.
Let’s first understand defect life cycle and after that, we will move to workflow and different states of defect.
Defect Life Cycle –
In Software Development process, Defect Life Cycle is life cycle of defect or bug from which it goes through covering the specific set of states in its entire life. Mainly bug life cycle refers to its entire states starting from a new defect is detected to closing of that defect by tester. Alternatively, it is also called a Bug Life Cycle.
The journey of Defect Cycle varies from organization to organization and also from project to project because development procedures and platforms as well as testing methods and testing tools differ depending upon organizations and projects. The number of states that defect goes through also varies depending upon the different tools used and process followed during testing of software.
Workflow of Defect/Bug Life Cycle –
The below diagram illustrates actual workflow of Defect Life Cycle.
The above diagram shows different states of Defect in Defect Life Cycle and these are as follows :
1. NEW –
When any new defect is identified by tester, it falls in ‘New’ state. It is first state of Bug Life Cycle. The tester provides a proper Defect document to Development team so that development team can refer to Defect Document and can fix bug accordingly.
2. ASSIGNED –
Defects which are in status of ‘New’ will be approved and that newly identified defect is assigned to the development team for working on defect and to resolve that. When the defect is assigned to developer team then status of bug changes to ‘Assigned’ state.
3. OPEN –
In this ‘Open’ state the defect is being addressed by developer team and developer team works on the defect for fixing the bug. Based on some specific reason if developer team feels that defect is not appropriate then it is transferred to either ‘Rejected’ or ‘Deferred’ state.
4. FIXED –
After necessary changes of codes or after fixing identified bug developer team marks state as ‘Fixed’.
5. PENDING RETEST –
During the fixing of defect is completed, developer team passes new code to testing team for retest. And the code/application is pending for retesting at Tester side so status is assigned as ‘Pending Retest’.
6. RETEST –
At this stage, tester starts work of retesting defect to check whether defect is fixed by developer or not, and the status is marked as ‘Retesting’.
7. REOPEN –
After ‘Retesting’ if tester team found that bug continues like previously even after developer team has fixed the bug, then status of bug is again changed to ‘Reopened’. Once again bug goes to ‘Open’ state and goes through life cycle again. This means it goes for Re-fixing by the developer team.
8. VERIFIED –
The tester re-tests bug after it got fixed by developer team and if tester does not find any kind of defect/bug then bug is fixed and status assigned is ‘Verified’.
9. CLOSED –
It is the final state of Defect Cycle, after fixing defect by developer team when testing found that the bug has been resolved and it does not persist then they mark defect as a ‘Closed’ state.
Few More States that also comes under this Defect Life Cycle –
1. REJECTED –
If the developer team rejects defect if they feel that defect is not considered as a genuine defect, and then they mark status as ‘Rejected’. The cause of rejection may be any of these three i.e Duplicate Defect, NOT a Defect, Non-Reproducible.
2. DEFERRED –
All defects have their bad impact on developed software and also they have a level based on his impact on software. If the developer team feels that defect that is identified is not a prime priority and it can get fixed in further updates or releases then developer team can mark status as ‘Deferred’. Means from current defect life cycle it will be terminated.
3. DUPLICATE –
Some times it may happen that defect is repeated twice or defect is same as any other defect then it is marked as ‘Duplicate’ state and then defect is ‘Rejected’.
4. NOT A DEFECT –
If the defect has no impact or effect on other functions of the software then it is marked as ‘NOT A DEFECT’ state and ‘Rejected’.
5. NON-REPRODUCIBLE –
If the defect is not reproduced due to platform mismatch, data mismatch, build mismatch, or any other reason then developer marks defect as in a ‘Non-Reproducible’ state.
6. CAN’T BE FIXED –
If the developer team fails to fix defect due to Technology support, Cost of fixing bug is more, lack of required skill or due to any other reasons then developer team marks defect as in ‘Can’t be fixed’ state.
7. NEED MORE INFORMATION –
This state is very close to ‘Non-reproducible’ state. But it is different from that. When the developer team fails to reproduce defect due to steps/document provided by tester is insufficient or Defect Document is not so clear to reproduce defect then developer team can change status as “Need more information’. When the Tester team provides a good defect document then developer team proceeds to fix the bug.
Advantages of following a Defect Life Cycle :
- Deliver High-Quality Product
- Improve Return on Investment (ROI) by Reducing the Cost of Development
- Better Communication, Teamwork and Connectivity
- Detect Issues Earlier and Understand Defect Trends
- Better Service and Customer Satisfaction
Difficulties in Defect Life Cycle :
- Variations of the Bug Life Cycle
- No Control on Test Environment
As we know during development of any software product the development teams follow the Software Development Life Cycle (SDLC) processes. But development process is not so easy and always runs smoothly. During the development process when product is being developed different types of defects or bugs arise with product. So these defects are identified and resolved throughout development process just to deliver a good quality software product at last. So in this article, we will discuss these bugs in software development process and how these are identified during software testing, and how these are resolved.
What is a Bug/Defect?
A defect is an error or bug in an application that is created during building or designing software and due to which software starts to show abnormal behaviors during its use. So it is one of important responsibilities of the tester to find as much as defect possible to ensure quality of product is not affected and end product is fulfilling all requirements perfectly for which it has been designed and provide required services to end-user. Because as much as defects will be identified and resolved then software will behave perfectly as per expectation.
Let’s first understand defect life cycle and after that, we will move to workflow and different states of defect.
Defect Life Cycle –
In Software Development process, Defect Life Cycle is life cycle of defect or bug from which it goes through covering the specific set of states in its entire life. Mainly bug life cycle refers to its entire states starting from a new defect is detected to closing of that defect by tester. Alternatively, it is also called a Bug Life Cycle.
The journey of Defect Cycle varies from organization to organization and also from project to project because development procedures and platforms as well as testing methods and testing tools differ depending upon organizations and projects. The number of states that defect goes through also varies depending upon the different tools used and process followed during testing of software.
Workflow of Defect/Bug Life Cycle –
The below diagram illustrates actual workflow of Defect Life Cycle.
The above diagram shows different states of Defect in Defect Life Cycle and these are as follows :
1. NEW –
When any new defect is identified by tester, it falls in ‘New’ state. It is first state of Bug Life Cycle. The tester provides a proper Defect document to Development team so that development team can refer to Defect Document and can fix bug accordingly.
2. ASSIGNED –
Defects which are in status of ‘New’ will be approved and that newly identified defect is assigned to the development team for working on defect and to resolve that. When the defect is assigned to developer team then status of bug changes to ‘Assigned’ state.
3. OPEN –
In this ‘Open’ state the defect is being addressed by developer team and developer team works on the defect for fixing the bug. Based on some specific reason if developer team feels that defect is not appropriate then it is transferred to either ‘Rejected’ or ‘Deferred’ state.
4. FIXED –
After necessary changes of codes or after fixing identified bug developer team marks state as ‘Fixed’.
5. PENDING RETEST –
During the fixing of defect is completed, developer team passes new code to testing team for retest. And the code/application is pending for retesting at Tester side so status is assigned as ‘Pending Retest’.
6. RETEST –
At this stage, tester starts work of retesting defect to check whether defect is fixed by developer or not, and the status is marked as ‘Retesting’.
7. REOPEN –
After ‘Retesting’ if tester team found that bug continues like previously even after developer team has fixed the bug, then status of bug is again changed to ‘Reopened’. Once again bug goes to ‘Open’ state and goes through life cycle again. This means it goes for Re-fixing by the developer team.
8. VERIFIED –
The tester re-tests bug after it got fixed by developer team and if tester does not find any kind of defect/bug then bug is fixed and status assigned is ‘Verified’.
9. CLOSED –
It is the final state of Defect Cycle, after fixing defect by developer team when testing found that the bug has been resolved and it does not persist then they mark defect as a ‘Closed’ state.
Few More States that also comes under this Defect Life Cycle –
1. REJECTED –
If the developer team rejects defect if they feel that defect is not considered as a genuine defect, and then they mark status as ‘Rejected’. The cause of rejection may be any of these three i.e Duplicate Defect, NOT a Defect, Non-Reproducible.
2. DEFERRED –
All defects have their bad impact on developed software and also they have a level based on his impact on software. If the developer team feels that defect that is identified is not a prime priority and it can get fixed in further updates or releases then developer team can mark status as ‘Deferred’. Means from current defect life cycle it will be terminated.
3. DUPLICATE –
Some times it may happen that defect is repeated twice or defect is same as any other defect then it is marked as ‘Duplicate’ state and then defect is ‘Rejected’.
4. NOT A DEFECT –
If the defect has no impact or effect on other functions of the software then it is marked as ‘NOT A DEFECT’ state and ‘Rejected’.
5. NON-REPRODUCIBLE –
If the defect is not reproduced due to platform mismatch, data mismatch, build mismatch, or any other reason then developer marks defect as in a ‘Non-Reproducible’ state.
6. CAN’T BE FIXED –
If the developer team fails to fix defect due to Technology support, Cost of fixing bug is more, lack of required skill or due to any other reasons then developer team marks defect as in ‘Can’t be fixed’ state.
7. NEED MORE INFORMATION –
This state is very close to ‘Non-reproducible’ state. But it is different from that. When the developer team fails to reproduce defect due to steps/document provided by tester is insufficient or Defect Document is not so clear to reproduce defect then developer team can change status as “Need more information’. When the Tester team provides a good defect document then developer team proceeds to fix the bug.
Advantages of following a Defect Life Cycle :
- Deliver High-Quality Product
- Improve Return on Investment (ROI) by Reducing the Cost of Development
- Better Communication, Teamwork and Connectivity
- Detect Issues Earlier and Understand Defect Trends
- Better Service and Customer Satisfaction
Difficulties in Defect Life Cycle :
- Variations of the Bug Life Cycle
- No Control on Test Environment
Жизненный цикл разработки ПО (англ. SDLC – Software development lifecycle) – это серия из шести фаз, через которые проходит любая программная система.
Абсолютно любое ПО проходит через 6 основных шагов, начиная от простой идеи и заканчивая использованием её конечным пользователем.
Но как это выглядит изнутри? С какими сложностями сталкивается команда разработчиков и как их решает на каждой фазе Жизненного Цикла ПО? Об этом расскажет Павел Гапонов, Project Manager компании-разработчика SolveIt.
Типичный жизненный цикл разработки состоит из следующих фаз:
1. Сбор и анализ требований (Planning and Requirement Analysis)
Это, пожалуй самый ответственный и важный из всех шагов к созданию успешной программной системы. Вся собранная информация используется для планирования базового проектного подхода.
Дополнительно идет планирование требований по обеспечению качества и выявления различных рисков, связанных с проектом. Результатом анализа является определение различных технических подходов, которые можно использовать для успешной реализации проекта с минимальными рисками. Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода ко второму этапу.
Проблема: Не соответствующие ожидания и часто изменяющиеся требования: заказчик и команда не понимают, какую реально пользу принесёт продукт.
Решение: Определить скоп работ, согласовать четкий, краткий документ с требованиями, создать прототипы (макеты) для подтверждения и уточнения окончательных требований.
2. Документирование требований (Defining Requirements)
Как только базовый анализ требований будет выполнен, следующим шагом будет четкое определение и документирование требований к продукту, утверждение со стороны клиента. Если одной из целей первого этапа является понимание и анализ требований, то на этом этапе все цели должны быть прописаны, это защита обеих сторон.
Важно четко определить и прописать, что требуется выполнить, это делается с помощью SRS (Software Requirement Specification). Документ содержит все требования к продукту, которые должны быть спроектированы и разработаны в течение жизненного цикла проекта.
Проблема: Большой многостраничный список требований
Решение: Выяснить высокоуровневые требования и, в ходе разработки и коммуникации с заказчиком, дописывать ТЗ. То есть разработка идет параллельно с Техническим заданием, а в процессе корректируется план.
В SolveIt мы всегда стараемся быть гибкими и подстраиваться под клиента. Работающий продукт важнее исчерпывающей документации.
Павел Гапонов, Project Manager, SolveIt
3. Дизайн (Design the Product Architecture)
SRS это ориентир для разработчиков, чтобы предложить лучшую архитектуру для продукта. Обычно предлагается несколько подходов к проектированию архитектуры продукта. Все предложенные подходы документируются в спецификации DDS (Design Document Specification) и выбирается наилучший подход к проектированию. Данный подход очень четко определяет все архитектурные модули продукта, а также его связь с внешними и сторонними модулями.
Проблема: Выбрали неправильную архитектуру.
Решение: Наличие в команде разработчиков опытных лидов, которые смогли бы предложить подходящую архитектуру, на основе своего успешного опыта в схожих проектах.
4. Разработка ПО (Building or Developing the Product)
Здесь начинается разработка и сборка продукта. Весь программный код, новые модули и фичи разрабатываются на основании DDS. Чем лучше написана эта документация, тем быстрее будет идти имплементация. На этом этапе подключается команда разработчиков. Написанный код должен покрываться Unit-тестами, а взаимодействие новых фич с другими модулями тестироваться с помощью интеграционных тестов. Эти активности выполняются именно командой разработчиков, а не QA специалистами.
Проблема №1: Слабая коммуникация между командой
Разработчик не интересуется прогрессом проекта, проблемами коллег.
Решение: Daily meetings, 100% вовлеченность, Скрам доска (интерактивность).
Проблема №2: Невыполнимые сроки
Заказчик хочет, чтобы его продукт был готов в ближайшее время. Менеджер проекта пытается объяснить клиенту к чему приведет такая спешка, но этого не достаточно. Клиент ставит невыполнимые дедлайны и не слушает возражения менеджера проекта. В результате, команда разработчиков сдается и пробует закрыть задачи в слишком короткие сроки. Как следствие – критические баги из-за спешки: команда не успевает, качество продукта снижается, клиент не доволен и решает, что виновата команда.
Решение: Менеджер проекта должен стоять на своём и аргументировать дедлайны. Клиент должен понять, что если команда разработчиков будет торопиться, то не реализует часть функционала. Если всё же такой срок реализации критичен для клиента, мы стараемся выявить какие задачи находятся у заказчика в приоритете.
Проблема №3: Добавление не оговоренных фич
99% заказчиков ошибаются именно в этом месте. В ходе разработки клиент отклоняется от оговоренного тз и хочет добавить ещё фич в продукт. В результате вместе с ростом скопа фич, увеличиваются сроки и бюджет на разработку, деньги заканчиваются, а готово только 50% продукта.
Решение: Менеджер проекта должен объяснить клиенту, к чему приведет добавление новых фич в проект, отстаивать свою позицию и держаться SRS. Поэтому так важна вторая фаза Жизненного цикла разработки ПО.
5. Тестирование (Testing the Product)
Именно тестирование, в основном, затрагивает все этапы жизненного цикла. Дефекты продукта регистрируются, отслеживаются, исправляются и повторно тестируются. Это происходит до тех пор, пока продукт не достигнет стандартов качества, которые прописаны в SRS. На данном этапе в процесс разработки подключается команда мануальных тестировщиков или автоматизаторы.
Проблема: Тратится слишком много времени на поиск причин багов. Попытки найти и исправить дефекты после завершения разработки – сложный процесс, который может привести к большому количеству исправлений.
Решение: Проводить тестирование параллельно задачам, сразу же по их завершению.
6. Внедрение и поддержка продукта (Deployment in the Market and Maintenance)
Как только продукт протестирован, он выходит в релиз. Иногда внедрение происходит поэтапно, в соответствии с бизнес-стратегией. Продукт сначала может быть выпущен в ограниченном сегменте и протестирован в реальной бизнес-среде, это UAT-тестирование (User Acceptance Testing). Затем, основываясь на отзывах, продукт может быть выпущен как есть, или с предлагаемыми улучшениями. После того, как продукт выпущен на рынок его обслуживание выполняется для существующей клиентской базы, и на этом этапе подключаются Support-команды.
Проблема №1: Отсутствие обратной связи, реальных отзывов потенциальных пользователей продукта.
Решение: Не ждать конца разработки, а как можно скорее запускать продукт, чтобы получить отзывы от реальных пользователей и на основе их предпочтений приоритезировать дальнейший функционал.
Проблема №2: Слабая инфраструктура проекта на стороне клиента.
Часть заказчиков предпочитают размещать сервера приложений не на Azure, AWS, Google и т.д, а в своей внутренней сети. Команда не может гарантировать стабильную работу, из-за сбоев, которые происходят на стороне клиента.
Решение: Предупредить клиента, о возможных проблемах, предложить решения для их устранения.
Это шесть основных стадий жизненного цикла разработки системы, и это повторяющийся процесс для каждого проекта. Важно отметить, что должен поддерживаться отличный уровень коммуникации с заказчиком. Для реализации требований очень важны и полезны прототипы. Строя систему короткими итерациями, можно гарантировать соответствие требованиям потребителя до того, как построить целую систему.
Если вам нужен качественный продукт, свяжитесь с нами и мы сделаем оценку вашего проекта!
Что такое Жизненный цикл разработки ПО (System/Software Development Life Cycle, SDLC)
Жизненный цикл разработки ПО это фреймворк, который определяет шаги включенные в процесс разработки ПО в каждой фазе. Он включает детальный план создания, развертывания и поддержки ПО.
Жизненный цикл разработки ПО определяет полный цикл разработки т.е. все задачи включенные в планирование, разработку, тестирование и развертывание программного продукта.
Что вы узнаете:
Процесс жизненного цикла разработки ПО
Циклы разработки ПО
Фазы разработки ПО
1) Сбор и анализ требований
2) Дизайн
3) Программирование и внедрение
4) Тестирование
5) Установка
6) Поддержка
Модели жизненного цикла разработки ПО
1) Водопадная модель
2) V-образная
3) Прототипная модель
4) Спиральная
5) Итеративно -инкрементальная модель
6) Модель большого взрыва
7) Agile модель
Выводы
Рекомендации
Процесс жизненного цикла разработки ПО
Жизненный цикл разработки ПО это процесс который определяет различные этапы включенные в разработку ПО для поставки высококачественного продукта. Этапы SDLC включают все этапы жизненного цикла ПО, т.е. от зарождения до вывода продукта из работы.
Соблюдение рекомендаций SDLC ведет к систематической и дисциплинированной разработке программного обеспечения.
Цель:
Основная цель SDLC поставка высококачественного продукта который соответствует требованиями заказчика.
SDLC определяет такие этапы как сбор требований, дизайн, программирование, тестирование и поддержка. Важно соблюдать порядок этапов для систематической разработки продукта.
Пример:
Необходимо разработать ПО, команда работает удаленно над продуктом и ей разрешено работать по собственному усмотрению. Один из разработчиков желает сначала заняться проектированием, второй начинает с программирования, третий с изучения документации.
Это приведет к провалу проекта так как необходимо члены команды должны обладать глубоким пониманием и знаниями, чтобы предоставить ожидаемый продукт.
Циклы разработки ПО
Этапы SDLC представляют собой процесс разработки ПО.
Внизу представлена диаграмма описывающая основные этапы SDLC
Этапы SDLC
Ниже представлены основные этапы разработки:
- Сбор и анализ требований
- Дизайн
- Программирование
- Тестирование
- Установка
- Поддержка
#1) Сбор и анализ требований
Во время данного этапа собирается вся необходимая информация у клиента для разработки продукта соответствующего его ожиданиями. Все двусмысленности должны быть устранены во время данного этапа.
Бизнес аналитик и Менеджер проекта назначают встречу с клиентом для сбора информации такой как — что клиент хочет получить в итоге, кто будет конечным пользователем, какая цель продукта. Перед созданием продукта очень важно понимание или знание продукта.
Пример, Клиент желает получить приложение которое включает перевод денег. В данном случае, требования должны содержать информацию о типе транзакции, каким образом совершать транзакцию, в какой валюте совершать перевод и другое.
Как только сбор требований завершен, аналитик проверяет требования на предмет реализуемости разработки. В случае выявления неточностей или двусмысленности, назначается повторная встреча с клиентом для обсуждения.
Как только требования ясно представлены и поняты создается SRS (Software Requirement Specification) или Спецификация требований программного обеспечения. Данный документ должен быть тщательно изучен и правильно понят разработчиками и самим клиентом.
#2) Дизайн
На данном этапе, требования зафиксированные в Спецификации используются как исходные данные для создания архитектуры, которая используется при разработке приложения.
#3) Программирование
Программирование начинается как только разработчик получил документ с архитектурой продукта. Дизайн ПО интерпретируется в код. На данном этапе создаются все компоненты ПО.
#4) Тестирование
Тестирование начинается как только завершено программирование и модули готовы для тестирования. На данном этапе, разработанное ПО тщательно тестируется и все найденные баги передаются команде разработчиков для исправления.
Повторное тестирование, регрессионное тестирование производится когда ПО полность соответствует ожиданиями заказчика. Тестировщики сверяют Спецификацию и созданный продукт, чтоб убедиться что ПО соответствует ожиданиям заказчика.
#4) Установка
Как только продукт протестирован, он устанавливается в рабочей среде заказчика для проведения приемочного тестирования заказчиком.
В случае приемочного тестирования заказчиком, создается копия рабочей среды (моделируются условия) и заказчик вместе с разработчиками проводит тестирование. Если заказчик по итогам тестирования принимает приложение как соответствующее спецификации, то подписываются документы на запуск приложения.
#4) Поддержка
После ввода ПО в эксплуатацию, осуществляется поддержка продукта т.е. если возникает какая-либо проблема, которую необходимо исправить, или необходимо внести какие-либо улучшения, разработчики займутся этим.
Модели жизненного цикла разработки ПО
Модели жизненного цикла разработки ПО это описательное представление процесса разработки ПО. SDLC (Software Development Life Cycle, SDLC) могут иметь различные подходы, но основные этапы и действия остаются одинаковыми для всех моделей.
#1) Водопадная модель
Водопадная модель первая модель из ряда SDLC. Ее также называют линейной последовательной моделью, каскадная моделью.
В данной модели, результат одного этапа является исходным (вводными данными) для следующего этапа. Разработка на следующем этапе начинается только тогда, когда завершены все работы на предыдущем этапе.
- Первое, сбор и анализ требований завершен. Когда требования утверждены, далее может начинаться создание системного Дизайна или Архитектуры приложения. Здесь создается SRS (Software Requirement Specification) или Спецификация требований программного обеспечения. То есть Спецификация является итогом сбора требований, и служит основой для создания системного Дизайна или Архитектуры приложения.
- На этапе системного Дизайна или Архитектуры приложения, создаются документы которые служат основной для следующего этапа — Программирования.
- На этапе Программирования команда разработки пишет код, создает компоненты приложения. Результат работы команды разработки служит для запуска следующего этапа — Тестирование.
- На этапе тестирования, полученный продукт тщательно тестируется на предмет наличия ошибок. Баги заносятся в системе баг-трекинга (Система отслеживания ошибок) и проходят повторное тестирование после исправления. Фиксирование багов, повторное тестирование, регрессионное тестирование проводится до тех пор, пока ПО не переходит в рабочее состояние, пока не начинает корректно работать.
- На этапе Установки, разработанное приложение запускается в эксплуатацию после одобрения заказчиком.
- Все проблемы возникающие в процессе эксплуатации решаются командой разработки в рамках Поддержки.
Преимущества Водопадной модели:
- Водопадная модель это простая модель которая может быть легко понята и она одна где все этапы выполняются пошагово.
- Поставка каждого этапа (результаты) хорошо определены и понятны, это делает проект легко управляемым и не сложным.
Недостатки Водопадной модели:
- Водопадная модель достаточно трудоемкая и не может быть использована в коротких по длительности проектах, так как в данной модели следующий этап не может быть начат пока не завершен текущий этап.
- Водопадная модель не может быть использована в проектах у которых неопределенные требования либо где требования изменяются так как данная модель предполагает четкие требования на этапе сбора и анализа требований и все изменения на поздних этапах приведут к увеличению стоимости так как изменения потребуются на каждом этапе.
#2) V-образная модель
V-образная также известна как Модель Верификации и Валидации. В данной модели Верификация и Валидация идут вместе т.е. разработка и тестирование идут параллельно. V-образная и Водопадная модель похожи за исключением что планирование тестирования и процесс тестирования начинается на ранних этапах в V-образной модели.
Этап Верификации:
- Сбор и анализ требований
На данном этапе, собирается вся необходимая информация собирается и анализируется. Верификация заключается в проверке, обзоре требований.
- Системный дизайн
Как только определены требования, начинается проектирования дизайна т.е. архитектура приложения, компоненты продукта. Создается документ с описанием дизайна продукта. - Высокоуровневый дизайн
Высокоуровневый дизайн определяет архитектуру/дизайн модулей. Он определяет взаимодействие (функциональность) между двумя модулями. - Низкоуровневый дизайн
Низкоуровневый дизайн определяет архитектуру/дизайн отдельных компонентов. - Программирование
На данном этапе осуществляется программирование.Этап Валидации:
1) Юнит — тестирование
Юнит — тестирование (Модульное тестирование) выполняется с использованием сценариев модульного тестирования, которые разработаны и выполняются на этапе низкоуровневого проектирования. Модульное тестирование выполняет сам разработчик. Он выполняется на отдельных компонентах, что приводит к раннему обнаружению дефектов.
2) Интеграционное тестирование
Интеграционное тестирование выполняется используя интеграционные тест кейсы на этапе разработки высокоуровневого дизайна. Интеграционное тестирование — это тестирование интегрированных модулей. Производится тестировщиками.
3) Системное тестирование
Системное тестирование выполняется на этапе разработки Системного дизайна. На данном этапе, вся система проходит тестирование, т.е. весь функционал приложения тестируется.
4) Приемочное тестирование
Приемочное тестирование связано с этапом Анализом требований и производится в рабочей среде заказчика.
Преимущества V-образной модели
- Простая и легкая для понимания модель
- Подход V-образная модели хорошо подходит для небольших проектов где требования определены и зафиксированы на ранних этапах
- Это системная и дисциплинированная модель результатом которой является высококачественный продукт.
Недостатки V-образной модели
- V-образная не подходит проектов в разработка (текущих проектов)
- Изменение требований на более позднем этапе приведут к повышению издержек.
#3) Прототипная модель разработки ПО
Прототипная модель это модель в которой прототип разрабатывается ранее самого приложения.
Модели-прототипы обладают ограниченными функциональными возможностями и неэффективной производительностью по сравнению с реальным программным обеспечением. Фиктивные функции используются для создания прототипов. Это ценный механизм для понимания потребностей клиентов.
Прототип ПО разрабатывается ранее самого ПО для получения значимой обратной связи от пользователя. Обратная связь учитывается разработчиками, дорабатывается прототип и снова обсуждается, рассматривается клиентом на предмет изменений и доработок. Данный процесс идет до тех пор, пока модель не будет принята пользователем.
Как только завершили процесс сбора требований, в скором времени создается первая версия прототипа которая предоставляется клиенту для оценки (билд).
Обратная связь клиента и новые, уточненные требования, замечания используются для усовершенствования прототипа и снова представляются заказчику для оценки. Как только клиент подтверждает прототип, он используется как набор требований для создания приложения. Далее ПО разрабатывается по подходам Водопадной модели.
Преимущества Прототипной модели
- Прототипная модель сокращает затраты и время на разработку так как баги выявляются на ранних этапах
- Отсутствие свойств и функционала или изменение в требованиях могут быть выявлены на стадии оценки клиентом и могут быть дополнены на стадии внесения дополнений.
- Вовлечение клиента с начальных этапов сокращает риск ошибок, двусмысленности в требованиях или понимания функционала.
Недостатки Прототипной модели
- С тех пор как клиент задействован на каждом этапе, им могут быть инициированы изменения в требованиях конечного продукта который повышают сложность работ и могут увеличить сроки разработки продукта.
#4) Спиральная модель
Спиральная модель включает итеративный и прототипный подходы.
Этапы спиральной модели следуют по итерациям. Петли данной модели представляют этапы SDLC (Software Development Life Cycle, Модели жизненного цикла разработки ПО) т.е. ключевой момент — сбор и анализ требований за которым следуют Планирование, Анализ рисков, разработка и оценка качества. Следующая петля это Разработка Дизайна и следующими за ней Разработка и тестирование.
У спиральной модели есть четыре этапа:
Планирование
Анализ рисков
Разработка
Оценка
Планирование:
Этап планирования включает в себя сбор требований где вся необходимая информация собирается у клиента и документируется. Спецификация требований к программному обеспечению создается на следующем этапе.
Анализ рисков:
На этом этапе выбирается лучшее решение с учетом имеющихся рисков и проводится анализ путем создания прототипа.
Пример: риск, связанный с доступом к данным из удаленной базы данных, может заключаться в том, что скорость доступа к данным может быть слишком низкой. Риск может быть устранен путем создания прототипа подсистемы доступа к данным.
Разработка:
Как только завершен анализ рисков, следует программирование и тестирование.
Оценка:
Клиент оценивает разработанную систему и планируется следующая итерация.
Преимущества Спиральной модели
- Широко применяется анализ рисков через использование прототипной модели.
- Добавление новых свойств и изменение функционала могут быть выполнены при следующей итерации.
Недостатки Спиральной модели
- Хорошо подходит только для больших проектов.
- Издержки могут быть высокими так как могут требовать большого количества итераций что может вести к высоким затратам времени для создания финального продукта.
#5) Итеративно инкрементальная модель
Итеративно инкрементальная модель предполагает декомпозицию продукта на небольшие задачи.
Пример: Определен и разработан функционал который будет реализован в рамках итерации. Каждая интеграция проходит этапы Анализ требований, Дизайн, Программирование и Тестирование. Детализированный план не требуется в итерации.
Как только завершена итерация, продукт проверяется и передается заказчику для оценки и обратной связи. Обратная связь клиента учитывается при следующей итерации с учетом добавления нового функционала.
Следовательно, продукт увеличивается с точки зрения функций, и после завершения итераций окончательная сборка содержит все функции продукта.
Этапы итеративно инкрементной модели:
- Начальный этап
- Этап разработки
- Этап Создания
- Переходный этап
Начальный этап
Начальный этап включает в себя сбор требований и определение рамок проекта
Этап разработки
Этап разработки включает в себя разработку рабочей архитектуры проекта которая включает риски определенные на начальном этапе и также учитываются и разрабатываются нефункциональные требования.
Этап Создания
На этапе создания архитектура заполняется кодом, готовым к развертыванию, и создается путем анализа, проектирования, реализации и тестирования функциональных требований.
Переходный этап
На переходном этапе продукт устанавливается в рабочем окружении клиента.
Преимущества итеративно инкрементной модели
- Любое изменение требования может быть легко выполнено и не требует затрат, поскольку есть возможность включить новое требование в следующую итерацию.
- В итерациях идентифицируется и анализируется риск
- Баги обнаруживаются на ранних этапах
- Так как продукт декомпозирован на мелкие задачи им легко управлять
Недостатки итеративно инкрементной модели
- Полные требования и понимание продукта необходимы для декомпозиции и разработки.
#6) Модель большого взрыва
Модель Большого взрыва не имеет определенного процесса. Деньги и усилия складываются вместе в качестве входных данных и на выходе мы получаем готовый продукт, который может либо не может соответствовать потребностям клиента.
Модель Большого взрыва не требует планирования и четкого расписания. Команда разработки проводит анализ требований, программирование, создает продукт таким каким они его поняли. Данная модель используется только для маленьких проектов. Здесь отсутствует команда тестировщиков и не проводится формального тестирования, и это может быть причиной провала проекта.
Преимущества модели Большого взрыва
- Очень простая модель.
- Не требуется планирования и определенного процесса.
- Команде разработки предоставлена свобода по созданию продукта как -будто для себя.
- Так как продукт декомпозирован на мелкие задачи им легко управлять
Недостатки модели Большого взрыва
- Не может быть использована для больших, действующих и комплексных проектов.
- Высокий риск и неопределенность.
#7) Agile модель
Agile модель это комбинация итеративной и инкрементальной модели разработки. Данная модель скорее сосредоточена на гибкости во время создания продукта, чем на требованиях.
В модели Agile продукт разбивается/декомпозируется на малые инкрементальные сборки (билды). Продукт не разрабатывается как сложная система за один подход. Каждая сборка увеличивается количество функций. Каждая последующая сборка строится на предыдущей функциональности.
В Agile итерации называются спринтами. Каждый спринт длится 2-4 недели. В конце каждого спринта владелец продукта проверяет продукт и после его подтверждения, продукт загружается для клиентов.
Обратная связь клиентов учитывается для улучшения продукта и обрабатывается в следующем спринте. Тестирование проводится в каждом спринте для минимизации риска и отказов.
Преимущества модели Agile
- Это позволяет более гибко адаптироваться к изменениям.
- Новую функцию можно легко добавить.
- Удовлетворенность клиентов, отзывы и предложения принимаются во внимание на каждом этапе.
Недостатки модели Agile
- Отсутствие документации.
- Для создания продукта нужны опытные и высококвалифицированные ресурсы.
- Если клиент не понимает, каким именно он хочет видеть продукт, проект провалится.
#Выводы.
Выбор подходящего жизненного цикла очень важно для успешного завершения Проекта. Это, в свою очередь, упрощает управление.
Различные модели жизненного цикла разработки программного обеспечения имеют свои плюсы и минусы. Лучшая модель для любого проекта может быть определена такими факторами, как требование (ясное или неясное), сложность системы, размер проекта, стоимость, ограниченные ресурсы и т. д.
Например, в случае неясного требования лучше всего использовать модели Spiral и Agile, поскольку требуемое изменение можно легко внести на любом этапе.
Водопадная модель является базовой моделью, и все остальные модели SDLC основаны только на ней.
Надеюсь, вы получили новые знания о SDLC.
Жизненный цикл разработки ПО (System/Software Development Life Cycle, SDLC) — процесс, состоящий из конкретных этапов, который начинается в момент принятия решения о необходимости создания ПО и заканчивается в момент прекращения поддержки ПО разработчиками.
Применение SDLC позволяет:
- Визуализировать сложный процесс разработки
- Управлять проектом
- Предсказывать и планировать доставку рабочих продуктов в ходе всего процесса разработки
- Управлять рисками выхода за рамки бюджета / превышения срока реализации
- Быстро определять, на каком этапе находится разработка в данный момент
В статье рассмотрим основные этапы жизненного цикла разработки ПО (SDLC) и их предназначение.
Этапы жизненного цикла разработки ПО
Всего выделяют 7 основных этапов разработки [1]:
- Идея
- Определение требований
- Дизайн (архитектура) системы
- Разработка
- Тестирование
- Развертывание
- Поддержка
Этап закрытия представлен на изображении, но он не является обязательным и зависит от проекта.
Этап 1: Идея
Разработка любой системы или ПО начинается с генерации идей для решения какой-то конкретной проблемы пользователя.
Этот процесс может быть формальным (например, brainstorming в компании) или не формальным (например, за барной стойкой с друзьями).
После генерации идей они анализируются, оцениваются и выбирается одна, которую будут «прорабатывать».
Этап 2: Определение требований
На этом этапе “идея” принимает более осмысленный и конкретный вид.
Для определения начальных требований к продукту привлекаются эксперты из разных областей: заказчики, клиенты, специалисты разных отделов (продаж, разработки, аналитики, тестирования и т.п.), эксперты по схожим продуктам.
Бизнес-аналитики (BA) прорабатывают полученную информацию, детализируют ее и преобразовывают в технические требования к системе. Эти требования называются Software Requirement Specification (SRS).
Кроме SRS на этом этапе:
- Определяются требования к качеству (SQA, Software Quality Attributes)
- Проводится анализ рисков (RA, Risk Analysis)
- Создаются планы валидации и верификации (V&V Plans, Test Plans)
- Определяются критерии приемки ПО (AC, Acceptance Criteria)
Этап 3: Дизайн (архитектура) системы
На этапе дизайна системы архитекторы ПО создают “скелет” проекта основываясь на требованиях. Они определяют используемые технологии, инструменты, рабочие процессы, взаимосвязи между разными частями проекта, структуры баз данных, потоки данных и т.п.
В итоге определяется спецификация по дизайну (Design Document Specification, DDS) с описанием что и как нужно делать с технической точки зрения.
DDS может состоять их двух частей — высокоуровневый дизайн (High-Level Design, HLD) и низкоуровневый дизайн (Low-Level Design, LLD).
Этап 4: Разработка
Разработчики получают требования (SRS), спецификацию по дизайну (DDS) и создают требуемое ПО.
Качество требований напрямую влияет на стоимость и продолжительность разработки. Чем хуже требования, тем больше ошибок нужно будет исправить, следовательно, увеличиваются незапланированные расходы.
Этап 5: Тестирование
Тестировщики, основываясь на требованиях (SQA, SRS, DDS) и готовом продукте производят проверку качества ПО (Quality Control).
Если находятся отклонения от требований / ошибки — они оформляются в виде отчетов о дефектах, исправляются и перепроверяются.
Процесс продолжается до тех пор, пока качество продукта не будет доведено до приемлемого уровня.
Этап 6: Развертывание
После успешного тестирования готовый продукт передается заказчику.
Кроме передачи может производится настройка рабочих окружений, установка, конфигурация и запуск продукта.
Этап 7: Поддержка
После запуска продукта он начинает развиваться, изменяться, дополняться новыми функциями.
Поддержку можно представить как повторяющуюся цепочку шагов “Определение новых требований” -> “Разработка” -> “Тестирование” -> “Развертывание”.
Эта часть жизненного цикла является самым длительным и важным этапом разработки ПО.
Без наличия процессов и стандартов разработки, рабочих процедур, порядка в документации, налаженной коммуникации и регрессионных тестов разработка очень быстро превращается в кошмар с микро-менеджментом, постоянно не закрывающимися задачами, кучей багов, огромным техническим долгом, развалом команды или проекта.
Именно на этом этапе умирает большинство стартапов.
Дополнительный этап: Закрытие
Закрытие — последний этап жизни ПО. На нем происходит вывод продукта из эксплуатации, его замена на современные аналоги, либо новые версии.
Как пример, можно вспомнить браузер Internet Explorer (был замен на Edge) или Windows XP (заменена на Windows 7).
Длительность разработки ПО
Для простых проектов разработка длится несколько месяцев (например, не “взлетевшие” стартапы, небольшие сайты, и т.п.).
Для сложных — более 15 лет (например, ПО для космических аппаратов).
Но, для большинства проектов, активная разработка продолжается на протяжении 6-8 лет. [2]
Учитывайте это, когда устраиваетесь на работу 🙂
Резюме
В статье мы разобрались, что такое жизненный цикл разработки ПО (SDLC), рассмотрели его этапы и их особенности.
Мы поняли, что создание программного обеспечения — это не только написание кода. В этот процесс входит много подготовительной (анализ, создание требований) и дополнительной работы (тестирования, разворачивание), а самым важным этапом является поддержка.
Далее, можем рассмотреть методологии разработки ПО которые реализуют этапы жизненного цикла ПО.
FAQ
Что такое SDLC?
Жизненный цикл разработки ПО (System/Software Development Life Cycle, SDLC) — процесс, состоящий из конкретных этапов, который начинается в момент принятия решения о необходимости создания программного продукта и заканчивается в момент прекращения поддержки ПО разработчиками.
Какие основные этапы SDLC?
Основными этапами SDLC являются:
1. Идея
2. Определение требований
3. Дизайн (архитектура) системы
4. Разработка
5. Тестирование
6. Развертывание
7. Поддержка (самый важный этап)
Жизненный цикл разработки ПО: основные этапы и модели
Содержание
Чтобы разработать программное обеспечение, нужно использовать специальный алгоритм. Его называют SDLC (Software Life Cycle Model), или жизненный цикл ПО. Это своеобразная основа, которая делает процесс разработки последовательным и упрощает техническую поддержку масштабных IT-проектов. В статье расскажем, что такое SDLC, перечислим его основные этапы и модели.
Оптимизируйте маркетинг и увеличивайте продажи вместе с Calltouch
Узнать подробнее
SDLC – это алгоритм создания IT-продукта, который состоит из 6 этапов и охватывает период с момента принятия решения о его разработке и заканчивается, когда ПО перестают использовать. Каждый этап опирается на результат предыдущего и дает пул необходимых указаний для выполнения последующего.
Его функции – регламентирование и формализация процесса разработки. Это важно при командной работе, когда задействуют десятки специалистов.
Модели жизненного цикла программного обеспечения
Есть 5 моделей жизненного цикла программного обеспечения. Чаще используют каскадную, инкрементную и спиральную. V-образная и итеративная пользуются меньшим спросом в силу своей «неуниверсальности».
Каскадная
Это цикл последовательно сменяющих друг друга уровней этапов, идущих в определенной последовательности, которую нельзя менять. Каскадная модель позволяет строить относительно простые ПО, четкий список требований к которым можно сформулировать изначально.
Ее преимущества:
- стабильность требований в течение всего жизненного цикла ПО;
- составление пакета проектной документации на каждой стадии;
- согласованность действий;
- логичность и понятность каждого шага;
- простой алгоритм реализации модели;
- прозрачные и прогнозируемые сроки прохождения каждой фазы;
- возможность точно планировать и грамотно распределять бюджет;
- оптимизация трудозатрат.
Например, такая модель подойдет, если нужно создать усовершенствованную версию проекта или перенести готовый продукт на новую платформу.
Недостатки:
- невозможность изменять и дополнять список требований на последующих этапах жизненного цикла;
- невозможность вернуться к предыдущим шагам, поскольку это ведет к удорожанию и увеличению сроков производства работ;
- отсутствие промежуточных результатов – продукт можно объективно оценить лишь после официального запуска;
- невозможность привлечения потенциальных пользователей на этапе разработки – продукт нельзя увидеть до запуска.
Каскадная модель жизненного цикла ПО подходит для выполнения проектов, в которых задействовано несколько крупных команд разработчиков. Линейная структура упрощает управление и формализует взаимодействие участников.
Инкрементная
Эта модель предполагает линейную последовательность действий, поэтапную обратную связь и контроль результатов. В процессе выполнения проекта создается несколько версий – инкрементов продукта.
Использование этой модели позволяет осуществлять последовательное финансирование дорогих проектов, находить дополнительные незапланированные ресурсы и внедрять продукт поэтапно, предлагая пользователям не готовую модель с массой неочевидных недостатков, а нечто вроде тестовых версий, которые можно постепенно усовершенствовать.
Недостатки модели:
- Динамику разработки нужно постоянно контролировать и своевременно реагировать на любой регресс.
- Структура модели, как и любой другой системы, негативно реагирует на постоянное добавление новых компонентов. Если вы выбрали инкрементную модель, предусмотрите в бюджете расходы на рефакторинг.
- Жизненный цикл ПО время от времени прерывается, и на то, чтобы заново собрать структуру воедино и продолжить разработку уходит много ресурсов.
Инкрементную модель используют для разработки многокомпонентных систем. Чтобы ее реализовать, заказчик должен четко понимать, как должен выглядеть желаемый результат.
Спиральная
Модель объединяет в себе два процесса – проектирование и поэтапное прототипирование ПО для проверки жизнеспособности сложных и нестандартных технических решений. Основная задача – уменьшить риски, которые влияют на организацию жизненного цикла.
Каждый условный «виток спирали» соответствует представлению очередной рабочей версии. Такая схема позволяет объективно оценить реальность выполнения отдельных задач и качество работы над проектом в целом, а также исключить серьезные баги и функциональные недочеты.
Достоинства модели:
- Возможность быстро показать пользователям готовый продукт и в процессе его доработки до итоговой версии устранить недочеты.
- Гибкость проектирования за счет сочетания преимуществ каскадной и инкрементной моделей, которые не исключают, а органично дополняют друг друга.
- Создание надежной и устойчивой системы за счет устранения слабых мест в ходе многочисленных доработок.
- Получение качественной обратной связи от пользователей.
Основные недостатки:
- Сложная громоздкая структура, из-за которой часто происходит рассинхронизация работы всех участников команды.
- Разработка по спиральной модели может дорого обойтись из-за огромного количества всевозможных доработок, целесообразность выполнения которых бывает сложно оценить адекватно.
- В основе планирования лежат профессиональный опыт фронтенд-разработчиков и объемная статистика, а не грамотное целеполагание.
Спиральная модель хорошо себя зарекомендовала при разработке инновационных систем или новой серии продукта. Он подходит для долгосрочные проектов, в ходе разработки которых возникает необходимость в представлении промежуточных версий или внесение изменений и новый требований в ТЗ.
V-образная
По сути, это та же каскадная модель, только более усовершенствованная. От прототипа она отличается тем, что тестирование проводят на каждом этапе. Это позволяет свести к минимуму количество ошибок в архитектуре программного обеспечения.
Основной минус – такой же, как и у классической каскадной модели – нет права на ошибку. Если на каком-то из этапов разработчики допустили недочет, его исправление окажется очень трудоемким и дорогим.
Применение V-модели оправдывает себя при разработке надежных и точных продуктов. Например, систем видеонаблюдения.
Итеративная
Преимущество этой модели в том, что она позволяет «ориентироваться на местности» – заранее определять закрытый список требований и составлять объемное техническое задание не нужно. Выявить актуальность и полезность продукта, а также возможные ошибки можно на этапе черновика.
Например, вы хотите создать планировщик задач для бизнеса. Вы схематично составляете список пожеланий к функционалу и интерфейсу продукта и ставите разработчикам задачу создать пробную версию, чтобы посмотреть, как это будет выглядеть.
Когда пробная версия готова, вы тестируете ее самостоятельно и предлагаете попробовать ее использовать друзьям, коллегам, партнерам – тем, чье мнение для вас авторитетно.
Допустим, что версия оправдала самые смелые ожидания – планировать дела на неделю в ней действительно удобно, все пользователи подтвердили, что с помощью вашего продукта стали работать эффективнее.
Вы понимаете, что продукт стоит того, чтобы его доработать, предложить более широкой аудитории и начать на нем зарабатывать деньги. И уже на этом этапе целесообразно писать подробное ТЗ для разработчиков, чтобы они устранили выявленные баги, добавили полезные функции, адаптировали продукт к требованиям рынка.
К недостаткам итеративной модели следует отнести сложности в использовании баз данных или серверов и невозможность спрогнозировать сроки и спланировать бюджет. Непонятно, как будет выглядеть готовый продукт и когда его можно будет запустить.
Такая разновидность жизненного цикла ПО подходит для разработки крупных эксклюзивных проектов с постоянно меняющимися требованиями.
Этапы разработки жизненного цикла ПО на примере каскадной модели
Выделяют 6 этапов реализации каскадной модели жизненного цикла ПО. Это основные шаги, которые применяют при планировании, разработке, тестировании и развертывании программного обеспечения.
Импровизировать и менять последовательность действий в данном алгоритме нельзя – это чревато последствиями: от неоправданного увеличения трудозатрат до серьезных сбоев в командной работе и финансовых потерь.
Согласованность и целесообразность всех действий в рамках разработки ПО обусловлена жесткой последовательностью этапов и их влиянием друг на друга.
Идея. Допустим, вы хотите открыть интернет-магазин одежды. Это и есть идея, для воплощения которой нужна команда специалистов: разработчик, дизайнер, оптимизатор, специалист по юзабилити, маркетолог, копирайтер.
Ограничиться тем, что вы соберете команду и сообщите ей, что вам нужен интернет-магазин, не получится. Сам замысел необходимо развернуть. Описать, что именно вы собираетесь продавать, для какой целевой аудитории, на какой территории; озвучить общие пожелания к дизайну, примерному количеству разделов.
Анализ и разработка требований. На этом этапе в процесс включаются тестировщики. Их основные задачи – собрать, проанализировать, систематизировать и задокументировать требования к создаваемому ПО. Тестировщики озвучивают свое видение продукта, корректируют процесс, выявляют возможные противоречия.
Если вы убеждены, что все участники команды правильно понимают задачи, и ясно представляете, как именно они будут реализовывать требования к ПО на практике (и что их точно можно реализовать), можно переходить к следующему этапу.
Проектирование. Этот этап нужен для того, чтобы ответить следующие вопросы:
- Как именно я и моя команда будем добиваться поставленных целей?
- Какие технологии будем использовать?
- Сколько времени займет выполнение пула поставленных задач?
- Как оптимизировать трудозатраты?
- Как добиться максимальной производительности команды, сделать ее работу слаженной и продуктивной?
- Какой бюджет потребуется?
После того, как будут сформулированы ответы, можно разрабатывать и предлагать конкретные проектные решения. Например, на этом этапе разрабатывается и утверждается дизайн сайта.
Чтобы сделать сайт привлекательным для пользователей и повысить конверсию, можно использовать виджеты Calltouch. Они позволят автоматизировать обработку обращений клиентов и облегчить работу менеджеров компании.
Виджеты Calltouch
- Увеличьте конверсию сайта на 30%
- Обратный звонок, промо-лендинги, формы захвата, мультикнопка, автопрозвон форм
Узнать подробнее
Программирование и разработка. К написанию кода можно приступать не ранее, чем будут утверждены требования к ПО и его дизайн. Круг задач четко очерчен и распределен – сисадмины работают над программным окружением, фронтенд-разработчики создают пользовательский интерфейс ресурса и формируют логику его взаимодействия с сервером.
Другие члены команды тем временем доводят до логического завершения дизайн, оптимизаторы составляют технические задания на тексты, копирайтеры готовят оптимизированный контент, контент-менеджер наполняет сайт товарами.
Тестирование. Тестирование – проверка готового к запуску сайта на всевозможные баги. Тестировщики досконально изучают ресурс, выявляют ошибки и передают информацию о них разработчикам в виде подробных отчетов. После устранения ошибок тестирование выполняется снова.
Этот цикл повторяется до тех пор, пока количество багов не станет минимальным или равным нулю. У каждого ресурса есть свой порог, после которого можно прекратить его тестировать.
Основная задача этапа – удостовериться, что продукт находится полностью в рабочем состоянии, и его можно запускать в работу.
Запуск, аналитика и сопровождение. Как только вы поймете, что в ПО не осталось серьезных дефектов и оно полностью готово к запуску, пришла пора официально выпустить готовый качественный программный продукт.
На данном этапе в процесс включается специалист по технической поддержке, который будет давать обратную связь пользователям, оказывать консультации, исправлять недочеты в соответствии с их пожеланиями и замечаниями.
Пользователи могут столкнуться с пострелизными багами и обратиться в техподдержку в нерабочее время. Чтобы не упустить ни одного обращения и показать клиентоориентированность компании, подключите обратный звонок Calltouch. Клиент оставит заявку, а система свяжет с ним специалиста, как только начнется рабочий день.
Виджет обратного звонка для сайта
- Повысьте конверсию сайта на 30%
- Новым клиентам 50 минут в подарок
Узнать подробнее
Другая важная функция отдела технической поддержки – сбор, анализ и систематизация различных метрик – показателей того, как работает продукт в реальных условиях. Это лучший способ понять, насколько он соответствует ожиданиям.
Закрытие. Это завершающий этап жизненного цикла ПО. Он наступает, когда вы понимаете, что достигли при помощи вашего продукта всех поставленных целей и готовы его закрыть и перейти на новый уровень.
Коротко о главном
При выборе модели жизненного цикла ПО ориентируйтесь на особенности продукта, который вы хотите получить, и потребности целевой аудитории. Для реализации сложных многоступенчатых систем, простых продуктов и их новых версий подходят разные модели SDLC. Грамотно выбрав вид алгоритма, вы запустите действительно успешный продукт, который будет востребован у пользователей, и потратите разумное количество времени и денег на воплощение идеи.
1. Может ли в модели жизненного цикла отсутствовать стадия Анализа требований? Аргументируйте свою точку зрения.
Считаю, что стадия Анализа требований не может отсутствовать в модели жизненного цикла ПО.
Во-первых, на данной стадии аналитик просчитывает насколько экономически, социально и технологически является осуществимый проект.
Во-вторых, аналитик собирает все требования от стейкхолдеров.
В-третьих, на выходе должно быть четко описанное техническое задание, по которому в дальнейшем будет проектироваться и разрабатываться ПО
2. На каких этапах SDLC аналитик может работать над требованиями (выявлять, анализировать, документировать, изменять)?
Думаю, аналитик на всех этапах SDLC может работать над требованиями. В любой момент может что-то измениться, если заказчик этого захочет и оплатит 
3. Какой этап SDLC может предварять этап Планирования в рамках жизни продукта?
Честно признаюсь, не сам пришел к такому выводу, прочитал такое мнение:
«Первым шагом, перед планированием и анализом, в рамках программы разработки программного обеспечения является выявление текущей проблемы. Задать вопрос «Что мы можем сделать?», «Что нужно клиенту?». Этот этап SDLC означает получение информации от всех заинтересованных сторон, таких как клиенты, сотрудники, программисты и т.д.»
Честно говоря, изначально из твоей лекции я так понял, что выявление проблемы у заказчика, вопросы «что мы можем?» и «что нужно клиенту?» относятся к планированию.
4. На каком этапе SDLC цена исправления ошибки ниже?
Думаю, что на этапе планирования и анализа требований цена исправления ошибки ниже всего.
Задачки на логику.
1. 0 или 360
2.Я бы посчитал сколько всего депо в Москве, т.к. все трамваи ночью живут в депо и как правило в одном и том же.
Определил бы восколько трамваи выходят на линию, а далее по каждому депо подсчитать сколько трамваев вышло на линию.
…
Если мы заметили ошибку на этапе написания требований, то исправить ее — дело 1 минуты, просто скорректировали предложение в тексте, и все.
Пока придумывают архитектуру будущего кода, стоимость уже дороже. Представьте, что архитектор уже придумал, как это будет выглядеть, а вы хотите изменить фундамент:
Но это еще реально. А вот если мы уже все построили (написали код), то некоторые изменения просто нельзя внести и приходится мириться с багом. А даже если можно, то стоить это будет сильно дороже:
— аналитику поправить ТЗ;
— архитектору придумать, как поправить минимальными усилиями;
— разработчикам внести правки.
Почему на картинке Lee Copeland есть еще Release с самой большой стоимостью?
|
| Картинка из книги Lee Copeland |
Потому что пока мы на этапе тестирования нашли проблему, то да, придется исправлять много кода, но все же этот код написан в последний месяц (или сколько времени у нас занимает выпуск одной версии продукта).
А вот если мы выпустили версию и уже сделали другую, третью пятую, десятую… А потом нашли баг в самой первой, то на том коде уже столько всего понастроено, в том числе и костылей. Что исправить вашу хочу-шку будет особенно сложно.
Тем не менее такой подход до сих пор используют в больших организациях на сотни человек. Там с требованиями работает один отдел аналитики, потом передают дальше и так по каскаду все приходит в тестирование. С проблемами ошибки в требованиях приходится мириться…
Так что запоминаем: чем раньше найдена ошибка, тем проще ее исправить!
Поэтому тестировщики так важны. Чем раньше они заметят проблемы, тем проще будет их исправить!
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Скачать PDF
1) Что такое SDLC?
SDLC — это аббревиатура от Software Development Life Cycle. SDLC — это последовательность шагов, которая предлагает определенную модель для разработки и управления жизненным циклом приложения.
2) Назовите пять моделей, используемых в SDLC.
- Модель водопада
- Модель быстрой разработки приложений (RAD)
- Гибкая модель
- Итерационная модель
- Спиральная модель
3) Объясните этапы модели водопада
Пять основных фаз модели водопада:
- Сбор требований
- Дизайн
- Разработка
- Тестирование
- Внедрение и обслуживание
4) Указывает на важность этапа проектирования?
Требования оформляются в виде документа. Затем он преобразуется в логическую структуру, которую необходимо реализовать на конкретном языке программирования. Этап проектирования также полезен для определения требований к оборудованию и системе. Это также позволяет определять полную архитектуру системы. Выходные данные предназначены для документирования, которые действуют как входные данные для всех последующих этапов SDLC.
5) Какие задачи выполняются на этапе кодирования?
На этапе кодирования проектный документ преобразуется в исполняемый язык программирования. Результатом этапа кодирования является исходный код, который может выступать в качестве входных данных для этапа тестирования и сопровождения.
6) Что такое технико-экономическое обоснование?
Осуществимость позволяет оценить, насколько жизнеспособна разработка программного проекта для любой организации. Аналитик программного обеспечения проводит полное исследование, чтобы понять операционную, экономическую и техническую осуществимость любого проекта.
7) Каковы уровни зрелости CMM?
Модель зрелости возможностей — это эталон для анализа зрелости процесса разработки программного обеспечения в организации. Это метод, который используется для совершенствования процесса разработки программного обеспечения в компании. Он используется для оценки любой компании по пятиуровневой шкале, основанной на их ключевых областях процесса. Он говорит о зрелости компании в зависимости от проекта, которым занимается компания, и клиентов.
Начальный, управляемый, определенный, количественно управляемый и оптимизация — это пять уровней, которые определяют уровни CMM любой компании.
Какие преимущества дает использование модели V?
- Легко и просто использовать.
- У каждой фазы есть свои
- Модель V более успешна из-за ранней разработки планов испытаний. Это снижает стоимость исправления ошибок.
- Наиболее эффективно работает с небольшими проектами, где требования невелики.
9) Каков «объем» проекта?
Объем проекта — это не что иное, как цели, задачи и ожидания от проекта. Объем программного обеспечения — это четко определенная граница, которая включает в себя все процессы, которые выполняются для разработки и доставки программного продукта. Объем программного обеспечения состоит из всех функций и артефактов, которые должны быть доставлены в систему программного обеспечения. Объем программного обеспечения также помогает определить, что система будет делать, а что нет.
10) По вашему мнению, когда следует обучать пользователей новой системе?
На этапе реализации
11) Назовите этап, на котором отслеживается производительность новой системы?
На этапах развития и обслуживания система постоянно контролируется.
12) Что такое компьютерная информационная система?
Это система, в которой компьютеры выполняют некоторые процедуры.
13) Объясните низкоуровневый или детальный дизайн относительно SDLC
В низкоуровневом дизайне высокоуровневый дизайн разбивается на модули и программы. Для каждой программы разрабатывается логический дизайн, который будет задокументирован в виде спецификаций программы.
14) Какая польза от сеанса JAD?
Сессия JAD (Joint Application Design) используется для получения данных и информации о системе.
15) Укажите разницу между SDLC и Stlc
SDLC включает в себя полную верификацию и валидацию проекта. Этап SDLC требует анализа бизнес-требований, проектирования, процесса разработки, процесса тестирования и сопровождения.
В то время как STLC включает только валидацию.
16) Кто задействован в фазах модели водопада?
Люди, вовлеченные в модель водопада, зависят от структуры организации. Вот профессионалы, которые обычно занимаются
- Бизнес-аналитик
- Технический менеджер или старшие разработчики
- Технический руководитель или системный архитектор на этапе проектирования
- Разработчики на этапе кодирования.
- Тестировщики на этапе тестирования.
- Менеджер проекта и группа обслуживания на этапе обслуживания
17) Что такое DFD уровня 0?
Самый высокий уровень абстракции называется DFD уровня 0 (диаграмма потока данных). Это также известно как DFD уровня контекста. Он дает спецификации всей информационной системы в виде одной диаграммы, которая содержит все подробности о системе.
18) Объясните команде Сбор требований относительно SDLC
Сбор требований — важный этап SDLC. На этом этапе собираются бизнес-требования. График и стоимость проекта также анализируются на этом этапе.
19) Кратко объясните этап тестирования
Используются различные методики тестирования для обнаружения ошибок программного обеспечения, которые возникают на предыдущих этапах. Сегодня существует множество типов инструментов тестирования и доступных методологий. Немногие новички также создают свои инструменты тестирования, которые изготавливаются на заказ в соответствии с потребностями или их организациями.
20) С какими проблемами сталкивается модель водопада?
Некоторые из распространенных проблем, с которыми сталкиваются модели водопада:
- Модель водопада не идеальна для сложных проектов, где требования не ясны.
- Для прохождения каждого этапа требуется много времени
- Есть определенные ошибки, которые никогда не исправлялись в этой модели.
21) Какое детальное изучение существующей системы называется?
Детальное изучение существующей системы называется Системным анализом.
22) Какова основная цель прототипирования?
Прототипирование предлагает мини-модель предлагаемой системы.
23) На каком этапе может быть выполнено досрочное завершение проекта SDLC?
В процессе SDLC прекращение проекта может быть выполнено на этапе технико-экономического обоснования.
24) Какая фаза жизненного цикла системы, по вашему мнению, является наиболее творческой и сложной?
Проектирование — один из самых сложных этапов жизненного цикла SDLC.
25) Назовите тип осуществимости, при котором экономия затрат и дополнительная прибыль превысят требуемые инвестиции.
Это известно как экономическая осуществимость.
26) Могут ли исправления ошибок включать обслуживание программного обеспечения?
Да, этап исправления ошибок также включает обслуживание программного обеспечения
27) На каком этапе жизненного цикла SDCL минимальная стоимость исправления ошибок?
Стоимость исправления ошибок на ранней стадии анализа требований намного ниже.
Время на прочтение
7 мин
Количество просмотров 192K
Цитируя автора книги Managing Information Technology Projects Джеймса Тейлора, «жизненный цикл проекта охватывает всю деятельность проекта». Задачей же разработки ПО является выполнение требований продукта. Если вы хотите научиться создавать и выпускать высококачественное ПО, вам придется следовать плану. Со слов Тейлора, вашей целью должен стать всесторонний анализ деятельности проекта и контроля каждого этапа его разработки. Вот только с чего именно начать?
Ответить можно так: направить ваш рабочий процесс в верном направлении поможет подходящий фреймворк. В наши дни довольно сильным и популярным фреймворком является SDLC – жизненный цикл программного обеспечения.
Принципы работы SDLC и почему им пользуются
На диаграмме ниже можно ознакомиться с шестью основными этапами SDLC.
В целом, SDLC это такой замкнутый цикл, в котором каждый этап влияет на действия в последующих и дает перспективные указания на будущее. Для получения ответов на конкретные вопросы и обеспечения согласованности вашего процесса разработки все шесть этапов стараются эффективно и последовательно друг на друга влиять.
Я постараюсь абстрагироваться от тонкостей и предоставить общие примеры, подходящие для студентов и разработчиков ПО. Например, если вы по аналогии с Zoomshift пробуете создать приложение, рассчитанное на работников с почасовой оплатой, или приложение для учета времени, начать вам нужно будет с этапа анализа требований.
На этом самом основном уровне вы сможете понять каковы должны быть требования к работникам в вопросах учета времени и труда, для чего полезно будет опросить как самих работников, так и их руководящих менеджеров. Так же для большего понимания проблем текущих приложений в области вы можете протестировать ваши решения на рынке, а создание диаграмм, графиков и в целом ведение записей поможет вам более глубоко понимать количественную и качественную обратную связь. Только после осознания этих критических особенностей вы будете готовы перейти к следующему этапу SDLC – планированию.
Фаза анализа требований может оказаться очень утомительной, но проходя через эти шаги, вы добиваетесь множества результатов: снижаете время выхода продукта на рынок, обеспечиваете большую его производительность, экономите бюджет и повышаете вероятность вхождения продукта на рынок.
Мыслите за пределами обычного приложения по отслеживанию времени — думайте о том, что вы хотите создать, чем вы хотите заниматься, а затем определите требования для решения связанных с этим проблем. Это и будет вашим началом.
Этапы SDLC и лучшие практики и методологии
В ходе разработки перед переходом от текущего этапа к следующему необходимо выполнить каждый его шаг, для чего их следует лучше понимать. В этом отношении первые три этапа стараются дать ответы на проверочные вопросы, а последние три оптимизированы для достижения фактических результатов.
- Анализ требований отвечает на вопрос «Какие проблемы требуют решений?»
- Планирование отвечает на вопрос «Что мы хотим сделать?»
- Проектирование и дизайн отвечает на вопрос «Как мы добьемся наших целей?»
- Разработка ПО регулирует процесс создания продукта.
- Тестирование регулирует обеспечение качественной работы продукта.
- Развертывание регулирует использование финального продукта.
Эти шесть этапов описывают уже наверняка применяемые вами при оценке, создании, тестировании и развертывании вашего ПО шаги. Тем не менее, SDLC стандартизирует и формализует рабочий процесс, что только в ваших же интересах: следуя конкретным шагам фреймворка, вы сможете легко понять в какой его части вы находитесь, и сообщить команде куда вы двигаетесь.
Давайте детальнее рассмотрим каждый этап и разберем проверочные вопросы и результаты, некоторые из которых вы можете захотеть оптимизировать под вашу конкретную ситуацию.
Этап #1: Анализ требований
На этом этапе SDLC вам необходимо получить обратную связь и поддержку от соответствующих внутренних и внешних заинтересованных сторон. Вспомните мой недавний пример с разработкой приложения по учету времени: вам нужно будет широко задуматься о том, кто станут вашими потенциальными пользователями. Некоторые идеи будут включать ваших клиентов, дизайнеров, вашего начальника или других технических специалистов команды. В целом вы хотите ответить на следующий вопрос: «Какие проблемы требуют решений?» Быть внимательным и делать заметки будет очень полезно на этом этапе.
Когда полученные ответы вас удовлетворят, вы сможете перейти к следующей фазе.
Этап #2: Планирование
На этом этапе вы ищете ответ на следующий вопрос: «Что вы хотите сделать?» Этот вопрос может вдохновить вас на понимание юнит-экономики вашего плана (затраты и выгоды), факторов снижения рисков и ожидаемых стоимостей. По аналогии с планированием отпуска, вам нужно будет разложить ваши вещи и подумать о том, что следует взять с собой.
Хороший пример:
Я много читал об истории Инстаграма, чей этап планирования занял невероятно много времени. Это совпало с бурным ростом социальных сетей, поэтому взаимодействие пользователей с продуктом во многом все еще было неизвестно. Разработчики знали, что сильный первичный опыт (съемка, редактирование и обмен фотографиями) обеспечит рост, успех и высокую конверсию, а корректное планирование упростит проектирование, поэтому планировали соответствующе и тратили на дизайн много времени. Они всегда смотрели на шаг вперед и думали о будущем социальных сетей и электронной коммерции.
Планируйте то, что вы можете контролировать, и помните о вещах, планировать которые вы не сможете. Это поможет вам получить прочную основу для перехода к третьему этапу.
Этап #3: Проектирование и дизайн
К этому этапу вы уже должны знать требования вашего продукта и в целом понимать чего вы вообще хотите, и прежде чем приступить к написанию кода, этого понимания должно быть достаточно для ответа на следующий вопрос: «Как мы добьемся наших целей?» Иначе говоря, вам необходимо понять, что именно вы оптимизируете и проектировать соответствующе.
Допустим, вы хотите создать безопасное, высокопроизводительное, эффективное и выдерживающее нагрузки приложение. Какой из этих четырех принципов наиболее для вас наиболее важен? Почему? Согласны ли с этим заинтересованные стороны из первого этапа? Важно обеспечить одобрение всех участников.
После фазы дизайна вы наконец-то сможете засесть за клавиатуры, и внесение изменений в отношении времени и потраченных ресурсов будет неуклонно расти, а также буду постепенно накапливаться всевозможные малые факторы. В этой фазе для принятия окончательных решений по вопросам дизайна я рекомендую учитывать несколько основных его элементов: операционное превосходство, безопасность, надежность, эффективность производительности, и оптимизация затрат.
Этап #4: Разработка ПО
На этапе разработки вы стремитесь не столько отвечать на вопросы, сколько произвести результаты, или, говоря точнее, вам необходимо склоняться к действиям и создать прототип или систему, испытать которую смогут другие. На этом этапе ваша задача – заручиться доверием заинтересованных сторон через воплощение образа мышления разработчика. Для соответствия результата ожиданиям критично при начале разработки следовать первым трем этапам.
Доставайте ваш компьютер, убедитесь, что окружение способствует рабочей атмосфере, хватайте ваш горячий кофе – и приступайте к делу.
Этап #5: Тестирование
Сотрудники в футболках с надписями вида «Разрабатывать круто, тестировать не очень» были для меня привычным зрелищем, но вы должны понимать, что не получится создать финальную версию продукта, пока вы на нем собаку не съедите. По завершению этого этапа вы должны будете в состоянии обеспечить рабочее состояние продукта. Отслеживайте ошибки и неточности, выслушивайте чужие точки зрения, и глубоко погружайтесь в вопрос с целью поиска тормозящих выход финального продукта ошибок. Вам просто необходимо обеспечить прочную основу.
Этап #6: Развертывание
Возьмите ваш продукт и пользуйтесь им. Предложите заинтересованным сторонам из первого этапа пользоваться вашим продуктом в естественных условиях, начните отслеживать вовлеченность в продажи. Снова и снова прислушивайтесь к пользователям, ведь благодаря обратной связи через опросы и рекомендации вы сможете вернуться к первой фазе и начать собирать новые требования. И не забудьте отпраздновать релиз.
Объединяя все вместе: подход SDLC
Фреймворк SDLC существует для помощи в сокращении времени вывода продукта на рынок, обеспечении более качественной производительности, экономии бюджета и повышения потенциальной пользы вашего продукта для заинтересованных сторон, о которых вы заботитесь. Особенно хорошо SDLC помогает при разработке ПО, поскольку он заставляет вас трудиться в строгих рамках. Другими словами, для обеспечения корректных действий в корректное время и по корректным причинам SDLC заставит вас следовать каждому необходимому шагу. Думайте о SDLC как о плане по достижению успеха: слепое ему следование ничего вам не гарантирует, но повышает вероятность что вы останетесь довольны результатами.
Разработка ПО, как все мы с вами знаем, это тема обширная, и она может затрагивать вопросы от инструментов веб-дизайна и онлайн форм до более надежного машинного обучения или систем бэкенда. Пишете ли вы код в браузере или занимаетесь более надежной разработкой, план действий вам необходим.
Разработка ПО может быть трудным, и в то же время полезным занятием.
SDLC это план по ведению технических работ, но если смотреть шире, то можно воспринимать его как руководство по жизни. Применять SDLC можно к множеству тем, например, создание контента в SaaS модели ведется по циклу SDLC. Перед написанием контента автор сначала определяет требования, планирует, что именно он будет писать, и лишь затем фактически прикладывает перо к бумаге. Также SDLC отлично подходит для технологических предпринимателей.
Мой друг хотел основать лучшее рекламное агентство для Facebook и обратился ко мне и другим специалистам за помощью. Несмотря на его большие амбиции, я посоветовал ему воспользоваться фреймворком SDLC чтобы сначала провести анализ требований. Я спросил его: «Какие проблемы ты хочешь решать? Чего хотят твои пользователи? И самое главное, как эта платформа поможет тебе достичь твоих целей?»
Сформулировав эти вопросы вокруг SDLC, он смог лучше отточить свой финальный продукт и предоставить нужные инструменты правильным пользователям. Он сузил свой кругозор до более строгого определения его проблемной области и смог выделить ресурсы на планирование еще до того как он начал делать что-либо еще.
Затем он перешел к созданию самого лучшего сервиса по росту на Instagram, но его интересы постоянно развиваются, и сейчас уже есть программы-планировщики деятельности в социальных сетях в любом масштабе. И в итоге ему придется вернуться к основам: анализу требований.
Принятие пользователями его технологий доказывает, что при правильном применении SDLC можно достичь основательных технологических и финансовых результатов. Однако, как и при развитии бизнеса, разработка ПО никогда не заканчивается.
Следовательно, цикл продолжается.
Вне зависимости от того что вы создаете, компанию ли, инструмент, сложную программу либо полностью новый продукт, чтобы обеспечить качество и сосредоточиться на пользователях, хорошим решением будет взять на вооружение SDLC.
Фраза «Создавать круто» должна стать вашей путеводной звездой, а SDLC – инструментом и помощником.