Какой программный продукт разработать
Этапы разработки программного продукта
В настоящее время при разработке сложного программного обеспечения обычно используют одну из двух технологий: структурное программирование или обьектно-ориентированное программирование.
Первая технология для разработки сложных программ рекомендует разбивать (декомпозировать) программу на подпрограммы (процедуры), решающие отдельные подзадачи, т.е. базируется на процедурной декомпозиции.
Вторая технология использует более сложный подход, при котором в предметной области задачи выделяют отдельно функционирующие элементы.
Поведение этих объектов программно моделируется с использованием специальных средств, а затем, уже из готовых объектов, опять же специальным способом, собирается сложная программа. Таким образом, в основе второй технологии лежит объектная декомпозиция.
Современная методология разработки программного обеспечения предполагает разбиение проекта на этапы, на которых специалисты, играющие определенные роли в проекте, выполняют различные действия и производят составные части проекта.
Можно выделить следующие этапы:
— Постановка и анализ задачи, определение требований;
— Проектирование,
— Разработка, написание кода;
— тестирование, отладка
и оценка качества;
— документирование.
— внедрение и сопровождение.
Результатом обычно является документ, называемый в нашей стране техническим заданием (ГОСТ 19.201-78) и содержащий сведения о назначении продукта, набор требований к нему и описание границ проекта.
По результатам анализа условия задачи выбирают математические абстракции, адекватно, т.е. с требуемой точностью и полнотой, представляющие исходные данные и результаты, строят модель задачи и определяют метод преобразования исходных данных в результат (метод решения задачи).
Принято различать логическое и физическое проектирование.
Логическое проектирование не учитывает особенностей среды, в которой будет выполняться программа (технические и программные средства компьютера).
При выполнении физического проектирования все эти параметры должны быть учтены.
Логическое проектирование при процедурном подходе предполагает детальную проработку последовательности действий будущей программы.
Определяется структура программы (программ) и разрабатывается алгоритм.
Под Алгоритмом понимается точная конечная система предписаний, определяющая содержание и порядок действий исполнителя над некоторыми объектами (исходными и промежуточными данными) для получения (после конечного числа шагов) искомого результата.
Любой алгоритм существует не сам по себе, а предназначен для определенного исполнителя. Алгоритм описывается в командах исполнителя, который этот алгоритм будет выполнять. Объекты, над которыми исполнитель может совершать действия, образуют так называемую среду исполнителя. Исходные данные и результаты любого алгоритма всегда принадлежат среде того исполнителя, для которого предназначен алгоритм.
Дискретность. Выполнение алгоритма разбивается на последовательность законченных действий-шагов.
Детерминированность. Способ решения задачи однозначно определен в виде последовательности шагов.
Понятность. Алгоритм не должен содержать предписаний, смысл которых может восприниматься исполнителем неоднозначно
Результативность. Содержательная определенность результата каждого шага и алгоритма в целом.
Свойство результативности содержит в себе свойство конечности — завершение работы алгоритма за конечное число шагов.
Массовость. Алгоритм пригоден для решения любой задачи из некоторого класса задач.
При изучении алгоритмов важно разделять два понятия: запись алгоритма и выполнение алгоритма. В учебно-научной литературе термин «алгоритм» используется как в первом, так и во втором значении. Для более четкого изложения нужно конкретизировать употребление этого термина!
Различают последовательности действий
— линейной,
— разветвленной
— и циклической структуры.
Линейная структура процесса вычислений предполагает, что для получения результата необходимо выполнить некоторые операции в определенной последовательности.
Разветвленная структура процесса вычислений предполагает, что конкретная последовательность операций зависит от значений одного или нескольких
параметров.
Циклическая структура процесса вычислений предполагает, что для получения результата некоторые действия необходимо выполнить несколько раз.
Процессы вычислений циклической структуры в свою очередь можно разделить на три группы:
• циклические процессы, для которых количество повторений известно счетные циклы или циклы с заданным количеством повторений
• циклические процессы, завершающиеся по достижении или нарушении некоторых условий — итерационные циклы;
циклические процессы, из которых возможны два варианта выхода: выход по завершении процесса и досрочный выход по какому-либо дополнительному условию — поисковые циклы.
Способы задания:
— текстовая форма записи;
— запись в виде блок-схемы;
— запись алгоритма на каком-либо алгоритмическом языке;
— представление алгоритма в виде машины Тьюринга или машины Поста.
Вне зависимости от выбранной формы записи элементарные шаги алгоритма (команды) при укрупнении объединяются в алгоритмические конструкции: последовательные, ветвящиеся, циклические, рекурсивные.
В 1969 году Эдсгер В. Дейкстра в статье «Структуры данных и алгоритмы» доказал, что для записи любого алгоритма достаточно трех основных алгоритмических конструкций: последовательных, ветвящихся, циклических.
Блок-схема алгоритма(ГОСТ 19.701-90)
— Блок-схема алгоритма представляет собой диаграмму, на которой изображена последовательность действий, выполняемых программой.
Терминатор. Показывает начальную и конечную точки программы. Терминатор соединен с другими фигурами только одной линией: из начальной точки линия со стрелкой выходит, а в конечную — входит.
Ввод и вывод данных. Фрагмент программы, в котором пользователь вводит данные или программа выводит результаты на экран.
Обработка данных. Отображает любую операцию, выполняемую компьютером, например присвоение переменной какого-либо значения.
Структура принятия решения. Фрагмент программы, в котором принимается решение о направлении вычислительного процесса. В ромб всегда входит одна линия, а выходят две. Одна из выходящих линий отмечается словом «Да», а другая — «Нет».
Счетные циклы.
Предопределенный процесс. Эта фигура отображает группу операций, например вычисление факториала.
Соединитель. С помощью этой фигуры можно избежать перекрещивания линий и сделать блок-схему менее запутанной. Соединители всегда используются парами: в один соединитель линия входит, а из другого выходит, причем в каждый из соединителей данной пары заносится одно и то же число.
Линия. Соединяет две фигуры блок-схемы и показывает последовательность выполняемых программой операций.
— Базовые конструкции:
Перечисленные структуры были положены в основу структурного программирования
Псевдокод
Состоит из комбинации операторов языка высокого уровня и фраз на английском или русском языке. Стандартов на составление псевдокодов не существует.
— Алгоритм Евклида:
Алгоритмы простых программ разрабатывают, продумывая последовательность действий для решения некоторой задачи.
Для разработки алгоритмов более сложных программ целесообразно использовать метод пошаговой детализации
С использованием данного метода разработку алгоритмов
выполняют поэтапно.
На первом этапе описывают решение поставленной задачи, выделяя подзадачи и считая их решенными.
На следующем — аналогично описывают решение подзадач, формулируя уже подзадачи следующего уровня. Процесс продолжают до тех пор, пока не дойдут до подзадач, алгоритмы решения которых очевидны.
При этом, описывая решение каждой задачи, желательно использовать не более одной-двух конструкций, таких как цикл или ветвление, чтобы четче представлять структуру программы.
Физическое проектирование.
При выполнении физического проектирования осуществляют привязку разрабатываемого программного обеспечения к имеющемуся набору технических и программных средств.
— Разработанные алгоритмы реализуют, составляя по ним текст программы с использованием конкретного языка программирования.
— На этапе собственно разработки создается код приложения в соответствии с техническим проектом.
Вначале осуществляют ввод программы в компьютер. Для ввода используют специальную программу — текстовый редактор, с помощью которого создают файл, содержащий текст программы.
Программа преобразующая программу, записанную на одном из языков высокого уровня, в программу на машинном языке — транслятор.
Трансляторы реализуются в виде компиляторов или интерпретаторов.
— Интерпретатор (англ. interpreter — истолкователь, устный переводчик) переводит и выполняет программу строка за строкой.
— Компилятор (англ. compiler — составитель, собиратель) читает всю программу целиком, делает ее перевод и создает законченный вариант программы на машинном языке, который затем и выполняется.
При создании любого программного продукта всегда возникают две цели: «разработать правильный продукт» и «разрабатывать продукт правильно». Для того, чтобы итоговый продукт был успешным нужно всегда стремиться достичь обе указанные выше цели, а не сосредотачиваться только на одной из них, как это часто бывает. Иначе, если победит партия сейлзов, то в итоге быстро создается продукт, первая версия которого нравится клиентам, но при попытке выпустить вторую версию, процесс начинает буксовать, число багов только увеличиваться, а сроки релиза срываться. А если наоборот, безоговорочно побеждают технари, то в результате получается интересное с технической точки зрения решение, которое отлично работает, функционал которого может быть легко расширен, но вот сам продукт не востребован рынком и просто проедает деньги инвесторов.
Разработать правильный продукт
Для создания правильного продукта вы должны полностью понимать потребности ваших потенциальных клиентов. Поэтому первым делом надо начинать с исследования рынка. Необходимо ответить самому себе на следующие вопросы:
- Вы планируете выйти на существующий рынок, на котором еще есть незанятые ниши?
- Это потенциальный рынок, которые еще требуется создать?
- Если мы реализуем задумку, то сможем ли эффективно донести до клиентов выгоду от ее использования?
Если вы сможете ответить на эти вопросы и ответ внушает оптимизм, то можно начинать. Наихудшая из возможных ситуаций – это реализовать решение для некой гипотетической проблемы, а при попытке выйти на рынок убедиться, что проблемы в реальности не существует. Правильно сначала найти проблему, а затем придумать решение для нее. Итого: программный продукт должен соответствовать реальным потребностям клиентов, а не представлениям разработчиков о них.
После того, как потенциальный проект определен, вам нужно определить список требуемой функциональности. Для этого надо сделать аккуратный сбор и анализ требований. Далеко не всегда возможно сразу определить всю необходимую функциональность, но чем точнее вы очертите рамки будущего продукта, тем больше у вас шансы на успех.
Кроме собственно реализации определенной функциональности, вам будет необходимо создать подходящий интерфейс пользователя. Если планируется, что ваш продукт будет использоваться людьми со слабым знанием компьютера, то вы должны спроектировать простой и интуитивно понятный UI в соответствии с их навыками. И наоборот, если вы создаете софт для IT-профессионалов, то нужно делать UI который они смогут сами настроить под свои потребности. Кроме этого интерфейс должен соответствовать стандартам области использования, например, использовать общепринятую терминологию.
Надо выбрать правильные технологии для реализации программного продукта. Разработчики имеют тенденцию к использованию самых свежих технологий, которые только-только появились на рынке, но будет обидно если готовый продукт будет отвергнут рынком, так как требует софта или железа, которые еще не получили широкого распространения. Совместимость со стандартами часто более важна для клиента, чем производительность или богатая функциональность. Так как менять всю работающую инфраструктуру только ради одного решения никто не будет.
И последнее, на что требуется обратить внимание, при разработке – это экономическая составляющая проекта. Если у вас нет достаточного финансирования для завершения проекта, то будет лучше не тратить имеющиеся ресурсы на бесполезную затею. Более того, даже если в принципе возможно реализовать задуманный продукт, но цена для клиентов будет больше получаемой ими выгоды от использования вашего решения, то у вас также не получится продать продукт и получить прибыль. К слову сказать, все это верно и для шароварных проектов, разрабатываемых дома по вечерам.
Итого пять простых правил для выбора правильного продукта:
- Ориентируйтесь на требования клиентов.
- Реализуйте требуемую клиентам функциональность.
- Интерфейс пользователя должен быть рассчитан на целевую аудиторию.
- Используйте подходящие технологии.
- Прибыль от проекта должна быть больше, чем стоимость реализации.
Разрабатывайте продукт правильно
Правильная разработка программного продукта подразумевает использование правильных технологий и практик процесса разработки. Удивительно, но многие девелоперские команды используют принцип «главное, что все сделано, а как неважно». Если вы не контролируете процесс разработки, то вы никогда точно не знаете, что вы сделали и как вы это сделали, а успех проекта в большей или меньшей степени становится зависим от слепой удачи.
Правильные подходы к разработке программного кода обеспечат создание продукта, который не теряет данные, не имеет логических ошибок, утечек памяти и не крешется. Необходимо использовать практики на вроде «безопасного программирования», проверяя корректность значений переменных перед их использованием и анализируя коды возврата функций. Устаревший подход «мусор на вход, мусор на выход», нужно заменять на «мусор на вход, диагностика на выход». Эти дополнительные проверки немного замедляют скорость разработки и перформанс продукта, но в результате окупаются с лихвой.
Хороший код должен быть производительным. Он не должен создавать излишнюю нагрузку на процессор, память, жесткий диск или сеть. В связи с появлением дешевого производительного железа проблема перформанса сейчас стоит не так остро, как в прошлом, но она все еще актуальна. Разработчики часто недооценивают размер инфраструктуры пользователя. Продукт отлично работающий в тестовой лаборатории может безжалостно тормозить или выедать всю память в реальной инфраструктуре.
Любая команда разработки софта должна использовать coding style. Каждый программист имеет тенденцию к изобретению своего собственного, совершенного, стиля кодирования. Если попросить 10 программистов описать стандарт кодирования, то вы получите 10 разных стандартов, а если попытаетесь выбрать лучший из них, то можете разжечь религиозную войну. Поэтому coding style должен быть выбран в ультимативной форме менеджером или тимлидом.
Повторное использование кода – это еще один подход к повышению качества кода. Если вы реализовали и протестировали какой-нибудь функционал, то использование его повторно не только уменьшает время на разработку, но и увеличивает стабильность и поддерживаемость продукта. Главное не увлекаться, не нужно реюзать код только ради реюзанья.
Продукт должен быть поддерживаемым. Это означает, что код не только хорошо задокументирован, но и используемые алгоритмы, и их реализация должны быть легко понимаемы новыми программистами, присоединившимися к команде. Также необходимо создавать исходный код таким образом, чтобы его можно было легко менять с минимальными рисками разломать продукт. Избегайте в архитектуре продукта неочевидных взаимосвязей, когда изменения в одной части продукта могут привезти к багу в другой. Не забывайте о платформе, на которой будет работать ваше приложение. Будет ли ваш продукт продолжать работать, если изменится операционная система, железо и браузер?
Правильно разработанный продукт должен быть работоспособным на будущих версиях операционных систем, на которых он работает сейчас. Для этого продукт необходимо разрабатывать с учетом требований производителя операционки, а специфика конкретной версии должна влиять только на небольшие изолированные участки кода. Чаще всего, проблемы с переходом на новые версии OS связанны с ошибками дизайна, а не выбором языка программирования или фреймворка.
Тестирование, тестирование и еще раз тестирование. Необходимо тестировать продукт на всех стадиях процесса разработки, и чем раньше вы начнете это делать, тем лучше. Одна из распространенных ошибок программистов — сначала написать большой кусок кода, а затем пытаться протестировать его целиком. Результат будет гораздо лучше, если вы будете тестировать отдельно каждую функцию и каждый интерфейс, например, используя юнит тесты. Да, иногда для этого придется писать моки и другие вспомогательные вещи, но время, потраченное на тесты, в итоге будет меньше, чем отладка и тестирование уже целиком написанного продукта.
Как только код начал разрабатываться, необходимо сразу реализовать и протестировать процедуру сборки продукта. Новый билд продукта должен собираться каждый день, или даже каждый час. Постоянное использование стабильной билд процедуры позволяет сразу же находить ошибки, ломающие сборки. Гораздо проще пофиксить проблему сразу, пока еще все сделанные изменения сидят в голове, нежели найти проблему через неделю и мучительно вспоминать зачем так было сделано.
Кроме этого, необходимо как можно быстрей выделить отдельную машину для сборки билда, которая только для этого и будет использоваться. Машины разработчиков быстро обрастают всевозможным «мусором», разными версиями фреймворков, SDK, результатами экспериментов и т.п. Все это может приводить к неожиданным проблемам в релизном билде. Необходимо собирать «эталонный билд» и именно его отдавать на ручное тестирование и в релиз.
В заключении хочется отметить, что правильно разработанный продукт позволяет отслеживать все ваши изменения, а сам процесс и результат делает воспроизводимым. В дополнение к этому, правильно поставленные процессы разработки обеспечивают вам возможность постоянного улучшения процесса, ведь не существует такой организации процесса разработки, в которой было бы нечего улучшать.
Все новости сайта в телеграм канале:
@pmlife_ru
Основной нашей специализацией в EDISON является разработка сложного заказного программного обеспечения на платформах Windows, Linux, MacOS и мобильных Android, iOS, Windows Phone. За время своей работы мы выполнили свыше нескольких сотен крупных проектов на самом высоком уровне качества разработки и обслуживания клиентов. К сожалению, большая часть самых интересных проектов надёжно скрыты за NDA. Но каким бы ни было разрабатываемое программное обеспечение: системное, прикладное, веб-приложение или приложение для мобильных, — общая схема разработки и ее принципы одинаковы.
В прошлой статье мы рассказали о наших принципах проектирования ПО, в этом посте перейдём непосредственно к процессу разработки в Центре разработки EDISON.
Этапы разработки программного обеспечения
В зависимости от вида, масштабов и потребностей проекта определяется порядок разработки. Он будет несколько отличаться для разработки мобильных приложений, встроенного ПО, решений для автоматизации и БД, но общая последовательность действий для создания ПО универсальна:
Подробно про первый и второй этапы (подготовительный и проектирование программного обеспечения) можно перечитать в прошлой статье.
Перейдём к созиданию:
- Дизайн — вторая по важности составляющая продукта после технических характеристик, влияющая на эффективность и скорость взаимодействия пользователя с ним. Требования к дизайну определяются ТЗ — как правило, важны простота, интуитивность и минимальные затраты на совершения действия (достижение результата), а также красота и соответствие стилю компании и (или) продукта.
- Код — та часть работы, которая обычно ассоциируется с разработкой ПО как таковой. Важно, чтобы код был в достаточной мере оптимизированным, лаконичным и понятным. Назначаем на подобранные под специфику задания в ТЗ языки специализирующихся на их использовании программистов.
- Тестирование. Тестирование в EDISON проводится на каждом этапе разработки ПО, включает множество тестов по плану тестирования, кастомизируемому с учётом специфики проекта на этапе составления технического задания. Результаты тестирования документируются и доступны клиенту в режиме реального времени. Оплата за продукт производится только после прохождения всех видов тестов, в том числе клиентских.
- Документирование — процедура, фиксирующая план, процесс и результат разработки программного обеспечения. Включает в себя всю исходную информацию (ТЗ, макеты), планы работ, затрат, тестирования, список задач исполнителей в каждый момент времени, отчеты о работе и так далее. Документация необходима для быстрого и точного выявления ошибок, прозрачности совместной работы, как обязательная юридическая часть договора.
Схематично создание программного обеспечения выглядит так:
Принципы разработки программного обеспечения
Важный момент для компании, занимающейся разработкой ПО, — определиться с базовыми принципами работы. У каждого разработчика свой подход, свои ценности и приоритеты. Для компании EDISON такими принципами при разработке являются:
- Ориентация на качество. Мы прилагаем все усилия, чтобы это было не избитым маркетинговым клише, а объективной реальностью. Бесперебойность работы и удовлетворенность конечным результатом обеспечивают:
- следование ГОСТам, лучшим практикам и методологиям качественной разработки (RUP, Agile),
- лучшие спецы, четкое разделение труда и хорошая мотивация срок+качество,
- отлаженная и мощная система тестирования продуктов,
- качественное и прозрачное планирование и выполнение задач, система управления разработкой и обязательность грамотного технического задания,
- документирование процесса и результата,
- гарантии на разработанные продукты, техническая поддержка и обучение пользователей,
- понятная и удобная система оплаты за разработку ПО.
- Адаптивность и гибкость. В некоторых проектах нет возможности четкой формулировки требований на этапе составления ТЗ, а иногда у клиента уже на этапе разработки программного обеспечения появляется потребность в изменениях, — мы с пониманием относимся к таким ситуациям и заранее предусматриваем их вероятность и согласовываем с клиентом условия работы при прецеденте.
Примеры реализованных EDISON проектов
Программное обеспечение для микротомографа для изучения материалов, созданного учёными Томского Государственного Университета
Томограф с микроточностью распознает внешнее и внутреннее устройство органических и неорганических объектов размером до спичечного коробка. Программа сканирует предмет, строит 3D модель, выделяет цветом участки одинаковой плотности.
Электронная библиотечная система Vivaldi
Сервис, разработанный EDISON, совмещает в себе электронные библиотеки ВУЗов страны с доступом к базе Российской Государственной Библиотеки. С его помощью студенты и преподаватели из 126 городов России могут получить доступ к ценнейшим и редчайшим научным трудам. ЭБС Vivaldi сотрудничает с крупными библиотеками, научными центрами и периодическими печатными изданиями. Пользователи могут посещать специализированные читательские залы круглосуточно. В данном проекте реализован лёгкий поиск нужной литературы, возможность распечатки, доступ к архивам ВУЗов страны. Сервис легко внедряется в учебное заведение, экономя место и затраты на содержание библиотеки бумажных книг.
Сеть электронных бибилиотек Vivaldi (ЭБС) с аннотацией from EDISON Software Development Centre
Система для контроля и учета рабочего времени «Большой Брат»
Удобный сервис для компаний, особенно использующих гибкий график работы для сотрудников, позволяющий отслеживать и контролировать реальную занятость сотрудников на рабочем месте. Система не пропустит ни одного разгильдяя. Работодателю видно, когда сотрудник пришёл на рабочее место, когда покинул, отлучался, отслеживается бездействие за компьютером и время сверхурочных работ. Если есть сомнения, занимается ли человек работой, с любого компьютера можно получить скриншот рабочего стола. Сервис удобен и для сотрудников разных отделов: вы можете точно определить, кто из коллег сейчас доступен, а кто, например, ушёл на обед; вы можете легко сами контролировать свой свободный график, выбирая время обеда, начала и конца рабочего дня. Ну, а работодатель может сделать выводы насчёт каждого нанятого человека для повышения эффективности работы организации.
Есть замечания по нашей методологии или вы хотите поделиться своим опытом? Рады будем пообщаться в комментариях, в нашей группе в Фейсбуке или во Вконтакте.
О компании:
Проектирование программного обеспечения
Разработка программного обеспечения: этапы и принципы
Тестировщик в ответе за всё
Поддержка программного обеспечения
Как йога кодить и жить помогает: личный опыт
Обучаем сотрудников английскому: опыт Edison
Умственный труд и физическая культура