Содержание:

Введение

Как без оформленного проекта вполне можно построить скворечник, но невозможно строительство высотного здания или комплекса космодрома со строительной индустрией, жилыми, стартовыми и производственными комплексами, так и без проекта можно реализовать лишь небольшую программу, но не автоматизированное рабочее место специалиста, а тем более автоматизированную систему управления большого предприятия.

Что же производят программисты? Программисты производят программный продукт. В терминах автоматизированных систем программисты создают программное обеспечение.

Программный продукт — программа, которую можно запускать, тестировать, исправлять и развивать. Такая программа должна быть написана в едином стиле, тщательно оттестирована до требуемого уровня надежности, сопровождена подробной документацией и подготовлена для тиражирования.

Программное изделие — программа на носителе данных, являющаяся продуктом промышленного производства. Термин утвержден Государственным стандартом.

Программное обеспечение автоматизированных систем — совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности автоматизированных систем.

Автоматизированная система (АС) — организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях, система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

Программа — очень сложный объект, содержащий до сотен тысяч и даже нескольких миллионов мыслей. Сложность программного продукта — отнюдь не случайное свойство, скорее необходимое. Его сложность определяется четырьмя основными причинами: сложностью задачи, сложностью управления процессом разработки, сложностью описания поведения отдельных подсистем, сложностью обеспечения гибкости конечного программного продукта.

Объект исследования – программное обеспечение.

Целью данной работы является изучение основ проектирования программ и этапов создания программного обеспечения.

Для достижения поставленной цели решались следующие задачи:

- рассмотрение основных технологий создания программного обеспечения;

- анализ этапов и стадий разработки программ;

- исследование стратегий тестирования программного обеспечения.

Работа состоит из введения, двух глав, заключения и списка использованных источников.

Глава 1. Основные технологии создания программного обеспечения

1.1 Стадии и этапы разработки программ

ГОСТ 19.102—77 регламентирует стадии и этапы программных разработок в течение всего жизненного цикла. Данный стандарт сформировался на основе анализа удачных и неудачных программных разработок и содержит основные рекомендации по проведению новых разработок. Стандарт уже пережил несколько технологий программирования. При этом, практически не изменяясь, он не являлся тормозом прогресса. Помимо наименований стадий и этапов проектирования ГОСТ 19.102—77 фактически содержит описание аналитико-синтетического эвроритма (алгоритма действий проектировщика с использованием методов анализа и синтеза) по временным этапам проекта^[1].

Стадия проекта — одна из частей процесса создания программы, установленная нормативными документами и заканчивающаяся выпуском проектной документации, содержащей описание полной, в рамках заданных требований, модели программы на заданном для данной стадии уровне, или изготовлением программ. По достижении окончания стадии заказчик имеет возможность рассмотреть состояние проекта и принять решение по дальнейшему продолжению проектных работ. Например, заказчик может принять решение о продолжении работ по одному из согласованных вариантов.

Этап проекта — обычно часть стадии проекта, выделенная по соображениям единства характера работ и (или) завершающего результата или специализации исполнителей. Иногда выделяют этапы (фазы), которые охватывают несколько стадий. Например, этап проектирования программы включает стадии ЭП и ТП. Описания этапов регламентируют порядок выполнения отдельных видов работ для достижения стадии. Одни и те же виды работ могут продолжаться ряд этапов.

Программный документ «Техническое задание» (ТЗ) помимо основных требований к программному изделию содержит проект порядка взаимодействия заказчика и исполнителя по окончании конкретных этапов, т. е. перечень необходимых стадий и этапов и требований к их выполнению. ТЗ может сразу не устанавливать всех требований, которые могут быть уточнены и согласованы с заказчиком на последующих стадиях. Однако сама возможность изменения требований должна закладываться в ТЗ. В ТЗ определяется стратегия выполнения проекта.

«Эскизный проект» (ЭП), как правило, необходим для разработки нескольких альтернативных вариантов реализации будущего изделия и уточнения требований на основе их анализа. Степень проработки при этом должна быть достаточной лишь для достижения возможности сравнения вариантов.

«Технический проект» (ТП) выполняется для получения однозначного описания конечного (оптимального) варианта построения программного изделия и порядка его реализации.

«Рабочий проект» (РП) необходим для реализации изделия в соответствии с ранее намеченным планом.

Стадия «Внедрение» необходима для размножения программной документации в нужном количестве, обучения пользователей, помощи в освоении программы, сопровождения программы.

Научно-исследовательская работа (НИР) может быть самостоятельным этапом. НИР в основном проводится для выявления последних научных достижений с целью их использования в проекте, проверки реализуемости изделия и уточнения отдельных его характеристик.

В соответствии с ГОСТ 19.102—77 допускается исключать стадию ЭП, а в технически обоснованных случаях — стадии ЭП и ТП. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком. Это позволяет разумно построить проект конкретной разработки (ход проекта также является объектом проектирования).

Пример 1. Разработка наукоемкой подпрограммы может вестись по следующим стадиям:

• ТЗ (ТЗ основное плюс ТЗ на отдельную НИР);

• ожидание результатов НИР, выполняемой в другой организации специалистами-математиками (срок от месяца до нескольких лет);

• РП (около месяца);

• внедрение.

Пример 2. Требуется разработать программное изделие средней или большой сложности. При средней сложности изделия необходимо проведение ТП, а при большой сложности — и ЭП, и ТП. В отличие от примера 1 в данном случае ТЗ может не содержать законченных требований.

Пример 3. Требуется создать программные средства, автоматизирующие отдельные виды работ. Разработка такого проекта может проводиться по следующим стадиям:

• ТЗ;

• ЭП с НИР по исследованию существующих программных средств, автоматизирующих выполнение отдельных видов работ;

• РП по разработке только документации без реализации каких-либо программ, если НИР показала, что можно обойтись только существующими программными средствами;

• внедрение.

Пример 4. Разработка таких информационных систем, как САПР или АСУ должна осуществляться в соответствии с соответствующими стандартами. ТП САПР или АСУ может содержать технические задания на разработку отдельных программных изделий. Как правило, такие ТЗ очень конкретны. На этапе РП САПР или АСУ сначала ведется контроль над разработкой программных изделий по всем необходимым для этого стадиям разработки программных изделий, затем проводится совместная проверка всех разработанных программ.

Обычно основанием для заключения договора между заказчиком и исполнителем служит гарантийное письмо заказчика. На основании гарантийного письма составляется договор. Обязательным приложением к договору является ТЗ.

Некоторые отечественные и зарубежные источники предлагают выделять следующие этапы:

1) анализ требований, предъявляемых к системе (системный анализ). (Обычно проводится на основе первичного исследования потоков информации при традиционном проведении работ с фиксацией видов этих работ и их последовательности.);

2) определение целей, достигаемых разрабатываемыми программами;

3) выявление аналогов, обеспечивающих достижение подобных целей, их достоинств и недостатков;

4) постановка задачи на разработку новых программ, определение внешних спецификаций (т. е. описаний входной и выходной информации, а иногда и их форм) и способов (алгоритмов, методов) обработки информации;

5) оценка достижения целей разработки (Далее, при необходимости, этапы 1–5 могут быть итеративно повторены до достижения удовлетворительного облика изделия с описанием выполняемых им функций и некоторой ясностью реализации его функционирования.);

6) рассмотрение возможных вариантов структурного построения программного изделия: или в виде нескольких программ, или нескольких частей одной программы; результатом этой работы являются варианты архитектуры программной системы и (или) требования к структуре отдельных программных компонент; организация файлов для межпрограммного обмена данными;

7) разработка окончательного варианта архитектуры системы и разработка окончательной структуры программных компонент;

8) составление и проверка спецификаций модулей;

9) составление описаний логики модулей;

10) составление окончательного плана реализации программ;

11) кодирование и тестирование отдельных модулей и совокупности готовых модулей до получения готовой программы;

12) комплексное тестирование;

13) разработка эксплуатационной документации на программу;

14) проведение приемо-сдаточных и других испытаний;

15) корректировка программ по результатам испытаний;

16) окончательная сдача программного изделия заказчику;

17) тиражирование программного изделия;

18) сопровождение программы.

Современные технологии проектирования программного обеспечения (ПО) направлены на частичную автоматизацию этапов и на совмещение их во времени с целью сокращения сроков выполнения проектов.

В литературных источниках применяются наименования этапов, которые охватывают ряд приведенных этапов и по времени охватывают даже несколько стадий. Например, этап разработки программы.

1.2 Технология конструирования программного обеспечения

Компьютерные науки вообще и программная инженерия в частности — очень популярные и стремительно развивающиеся области знаний. Дать обоснование такому явлению несложно: человеческое общество XXI века — информационное общество. Этому свидетельствуют цифры: в ведущих странах занятость населения в информационной сфере составляет 60 %, а в сфере материального производства — 40 %. Вследствие этого компьютерного направления приобретение наиболее дефицитных и высокооплачиваемых считают во всех странах мира. утверждают: «Кто информацией — тот владеет Поэтому понятно то внимание, которое компьютерному образованию сообщество, понятно унифицировать и упорядочить необходимые специалисту направления^[2].

Известно, что основной первых трех компьютерной эры являлось аппаратных компьютерных было обусловлено стоимостью обработки и данных. В 80-е успехи микроэлектроники резкому увеличению компьютера при значительном стоимости. Основной задачей годов и начала XXI стало модернизация, совершенствование компьютерных приложений, которых целиком программным обеспечением В настоящее время персональный теперь имеет гораздо большую, чем ЭВМ 80-х Сняты практически все ограничения на решение Оставшиеся ограничения долю ПО. Чрезвычайно актуальными следующие положения, требующие разрешения: – аппаратная сложность наше умение использующее потенциальные аппаратуры; – наше умение новые программы требований к новым – нашим возможностям существующие программы низкое качество их ключом к решению проблем является организация процесса реализация технологических промышленного конструирования систем (ПС).

Технологии — совокупность способах и средствах производственных процессов. С одной стороны, в случае один осуществляет поэтапную программы со своего непринужденной обстановке. создает сравнительно программу, не требующую оценки.

С другой, в случае проектируется сложное программное предназначенное для функционирования в масштабе времени и трудозатрат объемам в человеко-часов^[3].

Эти две взаимно-противоположные характеризуются различной формализации и проведении разработки программных Степень формализованной и процесса разработки обеспечения напрямую целей его создания, его численности группы других обстоятельств. От правильного и удачного построения приложения с точки зрения разработки программного , качество и жизнеспособность продукта. Под технологией разработки обеспечения (ТРПО) понимается обобщенных и систематизированных наука об оптимальных (приемах) проведения разработки программного обеспечивающего в заданных получение программной предопределенными свойствами. Технология разработки обеспечения представляет инженерный подход к программных средств охватывающий методологию проблемы обеспечения программ, оценки характеристик и качества

Технология разработки ПО рассматривает управления проектированием ПО, а средства и стандарты программ. Любая технология базируется на некоторой методологией понимается принципов и способов процесса разработки Внедрение методов программ, обеспечивающих соответствующих характеристик качества являются целью методики разработки ПО. Технология разработки обеспечения определяет культуру специалистов (не только программистов), их профессионализм, обеспечивающий заданный производительности труда и качество, получаемое в результате, продукции. Технология разработки обеспечения охватывает разработки программного появления потребности в нем до его передачи пользователю, процессе эксплуатации и использования вследствие старения.

Существуют 2 основные процесса разработки обеспечения:

1.Каскадная waterfall) — стандартная модель Каскадная модель модель, при которой все разработки ведутся последующий этап после полного предыдущего.

Такая модель следующие этапы создания ПО:

Прежде всего определяются технические будущей программы, в утверждается список программному обеспечению. происходит переход к процессе которого документация, описывающая для план и способ требований. После полного проектирования программистами реализация (конструирование) стадии воплощения интеграция всех проекта. Только полного завершения стадий производится отладка готового.

Далее программный можно внедрять и внедрения осуществлять вносить новый ликвидировать ошибки. Так, все разработки программного при использовании модели выполняются последовательно. Не происходит предыдущей фазе или следующую, а также фаз. Основные достоинства разработки: – четкая документация процесса; – точное определение бюджета; – определение сроков проекта; – низкая степень человеческого фактора Минусы: – длительные сроки от старта предоставления первого – большой объем документов; – длительные согласования промежуточных документов; – невозможность внесения динамическом режиме.

2.Гибкая разработки программного (Agile software Ряд методологий программного обеспечения, совместную работу заказчика и разработчиков. В гибкого метода лежит итеративный динамическое формирование реализация короткими Результатом каждого этапа, включающего итераций, является малый программный проект,

Способов гибкой несколько, из наиболее Scrum, экстремальное DSDM.

Основные достоинства разработки: – минимизация рисков; – постепенное наращивание программного продукта; – небольшой объем документации; – запуск базовой программы в кратчайшие Недостатки: – невозможность точного бюджета проекта; – невозможность определения сроков готовности – не подходит для бюджетных организаций; – требует мотивации от представителей заказчика.

Положения гибкой методологии разработки: – удовлетворение клиента за быстрой и бесперебойной необходимого программного – приветствие изменений даже в конце (это может конкурентоспособность полученного – частая поставка программного обеспечения месяц или неделю или ещё – тесное, ежедневное заказчика с разработчиками на всего проекта; – проектом занимаются личности, которые нужными условиями поддержкой и доверием; – рекомендуемый метод информации — личный (лицом к лицу); – функционирующее программное лучший измеритель – спонсоры, разработчики и должны иметь поддерживать постоянный неопределённый срок; – непрерывное внимание технического мастерства и дизайну; простота — делать лишней – лучшие технические дизайн и архитектура само организованной – постоянная адаптация к обстоятельствам.

Глава 2. Стратегии тестирования программного обеспечения

2.1 Исследование стратегий тестирования программного обеспечения

Повышение качества программного обеспечения (ПО) является актуальной задачей при разработке технических систем. Для её решения создано множество методов и инструментов, применение которых стало возможным благодаря постоянно растущей мощности вычислительных средств. Сегодня высокое качество программного обеспечения воспринимается как обязательный компонент в сфере информационных технологий. Очень важно вовлечь средства и методы контроля качества в процесс планирования и реализации проектов с самого начала.

В настоящее время реальные программные продукты чаще всего разрабатываются в сжатые сроки и ограниченном бюджете. К сожалению, при таких условиях разработчики программного обеспечения часто игнорируют необходимость контроля и поддержки надлежащего качества разрабатываемого ими продукта, подвергая тем самым конечных пользователей неоправданному риску. Основным аспектом, доказывающим необходимость применения тестирования совместно с процессом разработки программного обеспечения (ПО), является минимизация затрат как для разработчика, так и для потребителя продукта^[4].

Такого рода затраты связаны с нарушением процесса разработки и применения программного продукта, вызванного необходимостью устранения найденных в программе ошибок или дефектов. Дефекты, обнаруженные и устраненные на ранней стадии разработки, обходятся разработчику и клиенту гораздо дешевле, чем такие же, но вскрывшиеся уже в период коммерческого использования программного продукта. Более того, тестирование позволяет вести аналитический сбор информации об уже совершенных в процессе разработки дефектах.

Своевременное обеспечение подобной информацией разработчиков и руководителей проектов существенно понижает риск повторения дефектов, что в конечном результате положительно сказывается на качестве программного продукта.

Тестирование программного обеспечения является процессом поиска ошибок в реализации программы. Очевидно, хотелось бы организовать тестирование таким образом, чтобы выявить все возможные ошибки и дефекты в программе. Для того чтобы утверждать, что программа полностью свободна от дефектов необходимо подготовить все возможные наборы входных данных (включая некорректные), выполнить программу на всех возможных перестановках и вариациях входных данных, проанализировать все выходные данные и установить, что каждый тестовый выходной набор соответствует правильному.

Для реализации идеального и полного тестирования потребовалось бы задействовать большой объем ресурсов. Не трудно понять, что даже для не больших программ количество тестовых случаев может исчисляться значительным количеством комбинаций. Это доказывает, что полное тестирование программного обеспечения, когда проверяется все возможные последовательности выполнения программы, невозможно, соответственно невозможно выявить все дефекты в реализации программы.

Интуитивный, построенный случайно процесс тестирования не принесет должного результата. Поэтому тестирование должно базироваться на некотором подмножестве всевозможных тестовых сценариев являющихся вынужденной необходимостью. Процесс тестирования должен делаться не спонтанно, а на основании конкретной стратегии, которой следует придерживаться при тестировании. Это говорит о том, что исследование современных методов тестирования, позволяющих проводить его системно, а не интуитивно, является актуальной проблемой.

Перед разработкой стратегии тестирования, необходимо собрать как можно больше информации о требованиях к тестируемому программному обеспечению (ПО) и оценить риски. Стратегия тестирования должна учитывать множество факторов и определять, что и когда должны выполнять разработчики и тестировщики. Цель стратегии по тестированию — минимизация рисков, принимая во внимание сроки, бюджет, лимит ресурсов и прочие нюансы разработки программного обеспечения. В настоящее время сформировались две противоположных друг другу парадигмы тестирования — функциональное (метод черного ящика) и структурное (метод белого ящика). Стратегия тестирования по методу «черного ящика» (Рис. 1) долгое время оставалась основным способом тестирования. В этом методе тестирования программе подаются некоторые данные на вход и проверятся результаты, в надежде найти несоответствия.

При этом как именно работает программа считается несущественным. Важно отметить, что при таком подходе обязательно необходимо иметь спецификацию программы для того, чтобы было с чем сравнивать полученные в результате тестирования результаты.

Рис. 1. Тестирование методом черного ящика

Методы функционального тестирования: 1) Эквивалентное разбиение — метод, когда по спецификации выделяются классы эквивалентности (множество тестов со сходными параметрами, протестировав один из них, можно считать, что протестированы и все остальные) входных данных и создаются тесты, моделирующие попадание данных в эти классы. 2) Анализ граничных условий — метод, при котором проверяются границы классов эквивалентности. Строятся тесты для границ классов, для минимальных и максимальных значений. 3) Метод функциональных диаграмм — метод, в котором функциональная диаграмма формально является текстом, в который транслируется спецификация.

В диаграмму включаются причины (входные условия) и следствия (выходные условия или преобразование системы). После чего функциональная диаграмма преобразуется в булевский граф, связывающий причины и следствия. Каждый узел графа может находиться в состоянии 0 (существует) или 1 (не существует). После чего диаграмма снабжается комментариями, которые задают ограничения на комбинации причин и следствий. И, наконец, диаграмма преобразуется в таблицу решений, выбирается следствие, которое устанавливается в 1, и находятся все комбинации причин, с учетом ограничений, которые устанавливают выбранное следствие в 1.

Выделяют следующие особенности методов функционального тестирования:

‒ Тестирование системы в целом, включая отдельные модули и интерфейсы между ними.

‒ Тестирование без знания исходного кода, что позволяет ускорить процесс тестирования и сделать его более беспристрастным.

‒ Тесты основаны на спецификации и не зависят от исходного кода.

‒ Удобство автоматизации и регрессионного тестирования на базе тестов, построенных на основе стратегии «черного ящика».

‒ Некоторые возникающие ситуации не будут проверены вследствие того, что тесты покрывают основную функциональность.

Метод тестирования «черного ящика» до сих пор является самым распространенным в повседневной практике, но у него есть некоторый ряд недостатков, например, невозможно найти взаимоуничтожающиеся ошибки и некоторые ошибки возникают достаточно редко (ошибки работы с памятью) и поэтому их трудно найти и воспроизвести.

Стратегия структурного (модульного) тестирования (Рис. 2) предполагает создание тестов на основе структуры системы и ее реализации. Такой подход иногда называют тестированием методом «белого ящика», чтобы отличать его от тестирования методом «черного ящика». Структурное тестирование так же называют тестированием путем покрытия логики.

Рис. 2. Структурное тестирование

Как правило, структурное тестирование применяется к относительно небольшим программным элементам, например, к подпрограммам или методам, ассоциированным с объектами. При таком подходе анализируется программный код и для получения тестовых данных используются знания о структуре компонента. Набор тестовых входных данных определяется исходя из структуры программы, наличия и взаимного расположения в коде определенных конструкций языка программирования — циклов, условных операторов. Основная цель такого тестового набора входных данных — обеспечить необходимое покрытие программного кода.

Основными методами структурного тестирования являются покрытие операторов программы, ветвей программы, условий. Критерии структурного тестирования: С0 — условие тестирования команд, заключается в выполнении каждого оператора хотя бы один раз. С1 — условие тестирование ветвей, требуется выполнение каждой ветви программы не менее 1 раза. C2 — критерий покрытия всех путей в управляющем графе программы. Кроме перечисленных выше критериев используют критерий покрытиях всех условий и критерия покрытия условий/решений, который совмещает C1 и критерий покрытия условий.

Выделяют следующие особенности структурного тестирования^[5]:

‒ Минимальная стоимость устранения ошибки, благодаря локализации ошибки внутри программного модуля.

‒ Тесты, построенные на базе исходного кода, обеспечат его полное покрытие.

‒ Тесты зависят от программного кода и тестировщик вынужден актуализировать состояние тестов следуя изменениям в программе.

‒ Специалист по тестированию должен разбираться в проверяемом коде.

‒ Сложность тестирования в целом Тестирование в реальных условиях, как правило выполняется на месте использование программного продукта пользователями или совместно с заказчиком.

Среди особенностей тестирования в реальных условиях выделяются:

‒ Возможность проверки разработанного программного продукта в условиях реальной эксплуатации.

‒ Высокая стоимость устранения ошибки. ‒ Необходимость поддержки тестирование в виде консультаций специалистов по поддержке программных продуктов.

В результате исследования современных методов тестирования программного обеспечения (ПО) было установлено, что не существует универсального средства для избавления программного обеспечения от ошибок. Каждый из рассмотренных методов ориентирован на выявление определенных классов дефектов. Поэтому для достижения определенного качества программного продукта будет разумно применять комбинацию рассмотренных методов.

На этапе разработки наиболее эффективно представляется стратегия структурного тестирования. Тестирование «белого ящика» рассматривается как часть программирования. Программисту следует отдельно тестировать каждый модуль программы после его написания, поскольку он лучше других разбирается в собственном коде. На этапе интеграции отдельных модулей в единую систему целесообразно использовать стратегию функционального тестирования. Такое тестирование ни в коем случае не должно выполняться программистами, а специалистами по тестированию. Это эффективно потому что они не знают, как работает программа, они лишь только знают, как она должна работать в соответствии со спецификацией и могут полностью сконцентрироваться на поиске ошибок несоответствии требованиям. В конце концов только успешно пройдя все тесты, программный продукт может быть подвергнут тестированию в реальных условиях.

Исчерпывающее тестирование невозможно в следствии большого сочетаний всевозможных входных данных. Чтобы добиться наилучшего качества и выявить максимальное число ошибок, тестирование необходимо проводить, опираясь на существующие методы. Для обеспечения высокого уровня качества программного обеспечения (ПО) целесообразно применять комплексные подходы к тестированию.

2.2 Бережливая разработка программного обеспечения

Идея названия этой статьи позаимствована из книги «Бережливое производство программного обеспечения»^[6], в ней авторы Мэри и Toм Поппендик сделали попытку перенести концепцию производственной системы Toyota (Toyota Production System — TPS) в область программных разработок. Тайити Оно (один из ее главных создателей) сформулировал семь видов потерь^[7]: потери из-за перепроизводства; потери времени из-за ожидания; потери при ненужной транспортировке; потери из-за лишних этапов обработки; потери из-за лишних запасов; потери из-за ненужных перемещений; потери из-за выпуска дефектной продукции. Суть TPS заключается в сокращении, ликвидации этих потерь. Программная разработка все же отличается от производства, поэтому Мэри и Toм Поппендик, опираясь на идеи Тайити Оно, Сигаэо Синго и др. специалистов в области бережливого производства, предложили свою концепцию.

Своего рода проекцию TPS на программные разработки. Проекцию, несомненно, полезную, но все же имеющие некоторые недостатки и неудобства в плане применения. Прежде всего, это касается излишней привязке к оригинальной TPS. Перечисленные выше затраты сложно найти в прямом их смысле в области программных разработок. Попытки это сделать носят несколько искусственный характер, т. е. подогнать их можно, но смысла в этом нет. Куда проще и естественнее оперировать устоявшимися концепциями программной разработки, имея в виду идею бережливости, чем адаптировать TPS к существующим реалиям. Исходя из этого соображения и построено дальнейшее изложение.

Вместе с тем отметим несомненную пользу озвученных в книге Поппендик идей и примеров, которые послужили основой для данного исследования. Ключевая идея бережливости заключается в сокращении потерь, коими можно считать любые затраты, которые не участвуют в создании ценности продукта. Рассмотрим главные из них.

1. Лишние функциональные возможности «Только около 20 % функциональных возможностей в типичном пользовательском программном обеспечении используется регулярно, и около двух третей возможностей используется редко» (Джим Джонсон, председатель Standish Group)^[8]. Наверное, каждый, кто пользовался программными пакетами типа Microsoft Office, согласится с вышеозвученным утверждением. Для примера читатель может оценить используемый лично им функционал, например, в текстовом редакторе Word. В лучшем случае это будут те самые 20 % от всех его возможностей. Если брать операционную систему Windows и все ее возможности по части настроек и оптимизации, то процент будет, скорее всего, меньше.

Основные причины появления лишнего функционала:

1)      Конкуренция между производителями программного обеспечения. Принято считать, что дополнительные функции — это конкурентное преимущество. Программа, обладающая богатым функционалом, может быть привлекательна для потребителя. По крайне мере, это используется в  маркетинговом продвижении. Но в реальности обширным функционалом будет пользоваться только небольшой процент профессиональных пользователей, для остальных же — это дополнительная сложность при освоении базовых возможностей программы.

2)      Слабое понимание того, что действительно нужно потребителю, что будет востребовано, а что нет. Вводя обширный функционал мы, по сути, пытаемся попасть в мишень потребительской ценности, стреляя длинными очередями. Мы пытаемся угадать ключевые потребности. Понятно, что во многом это проблема маркетинга, но для некоторых типов проектов, например, стартапов это скорее норма. Если не сработала первоначальная идея, инициатор проекта пытается уточнить ее, переиграть, найти что-то еще, что вызовет отклик у потребителя. Но даже в этом случае не стоит оставлять в системе неиспользуемый или малополезный функционал, разработанный на ранних стадиях развития проекта. Почему не стоит, мы обсудим чуть позже.

3)      Разработка по waterfall (каскадная модель). Для каскадной модели характерны следующие фазы^[9]:

1.                 Определение требований

2.                 Проектирование

3.                 Конструирование (также «реализация» либо «кодирование»)

4.                 Воплощение

5.                 Тестирование и отладка (также «верификация»)

6.                 Инсталляция

7.                 Поддержка Как правило, эта модель отражает существующую в компании схему взаимодействия с заказчиком и схема эта способствует появлению лишних требований. Вот ироничное описание распространенной ситуации в waterfall: «Будьте так любезны, драгоценный заказчик, предоставьте нам список того, что программное обеспечение должно делать. И будьте добры расписаться внизу. После этого, если потребуется что-либо изменить или добавить, вам придется пройти через запутанный процесс, называемый “управление изменениями”, чтобы добиться одобрения каждого изменения. Поэтому, если вы хотите получить хорошее программное обеспечение, постарайтесь все предусмотреть заранее, поскольку нам нужно знать обо всем этом до начала процесса разработки. Не удивительно, что наши заказчики включают в этот список все, что только можно. И очень часто меры, призванные ограничивать масштабы создаваемого программного обеспечения, дают противоположные результаты»^[10].

Пути решения проблемы:

1)      Начать с малого. Как отмечают Мэри и Toм Поппендик «целесообразно сначала полностью разработать 20 % программного кода, которые обеспечивали бы 80 % потребностей заказчика, и только после этого переходить к разработке следующих наиболее необходимых функциональных возможностей». Полный список всех возможностей, которые теоритически могут понадобиться, не имеет особого смысла. Его можно проговорить, чтобы разработчик понимал, в каком направлении будет развиваться проект, но фиксировать его не стоит. Вполне может так оказаться, что какие-то возможности окажутся лишними или появятся новые, в свете более глубокой проработки концепции проекта. Особенно это актуально при быстром выпуске прототипа, который может подтвердить или опровергнуть бизнес-гипотезы на реальных потребителях.

2)      Убрать лишнее. Если стало очевидно, что лишние функции все же попали в систему, то от них нужно избавиться, и желательно не затягивать с  этим. Это может быть сложно с психологической точки зрения. На написанный код уже потрачено время и силы, возможно, что кому-то когда-нибудь он все же пригодится. Выкидывать его просто жалко. Но при этом мы забываем, что его нужно поддерживать, его нужно учитывать при внесении изменений, он усложняет понимание программной системы. Поэтому если данные функциональные возможности необходимы условным 5 % пользователей, то от них можно и нужно избавляться, они «не делают погоду». Финансовый выигрыш, который мы можем получить от пользователей, готовых приобрести систему из-за наличия определенных (маловостребованных другими пользователями) функций, перекрывается время затратами на поддержание этого кода. Конечно, 5 % — это некая абстрактная, условная величина.

В реальном проекте нужно тщательно взвесить финансовый вклад этих пользователей в доход от проекта, а также оценить сложность кода и трудоемкость его поддержания.

3)      Перейти на гибкую схему разработки. Мы уже говорили выше, что избыточный функционал — это зачастую следствие выбора неудачной схемы взаимодействия с заказчиком. Ее можно и нужно менять на более гибкие варианты, например, переход на Agile-методики (Scrum, Extreme programming и др.). Основные идеи (взяты из Agile-манифеста^[11]):

-        люди и взаимодействие важнее процессов и инструментов;

-        работающий продукт важнее исчерпывающей документации;

-        сотрудничество с заказчиком важнее согласования условий контракта;

-        готовность к изменениям важнее следования первоначальному плану.

Однако нужно учитывать особенности организационной культуры заказчика, его готовность к насыщенному сотрудничеству с исполнителями. Также проблемой может быть неготовность заказчика отказаться от фиксированного бюджета и сроков проекта (для Agile характерна модель оплаты «Time & Materials»). В этом случае может помочь т. н. FFF-подход: Fix Time and Budget, Flex Scope — фиксированное время и бюджет, гибкие возможности.

2. Overengineering (избыточное проектирование) Overengineering — излишне сложное проектное решение. Такое решение, которое обеспечивает избыточную гибкость системы. Обычно это выражается в программном коде, который пытается предусмотреть все, не только текущие, но и будущие потребности. «Избыточное проектирование заключается в том, что вы делаете код более гибким или сложным, чем он должен быть. Некоторые программисты делают это, поскольку полагают, что им известно, какие требования к разрабатываемой системе могут появиться в будущем. Поэтому они считают, что лучше сделать более гибкий и сложный проект уже сегодня, чтобы он без изменений соответствовал завтрашним нуждам. Это звучит разумно, если, конечно, вы обладает даром предвидеть будущее»^[12].

Чаще всего такие «предсказания» несостоятельны, а заложенная в систему гибкость оборачивается ненужной тратой времени и сил. Более того, выбранное архитектурное решение приходится поддерживать в дальнейшем, затрачивая на это дополнительные ресурсы, отвлекая их от действительно нужного функционала. Усложненная кодовая база затрудняет чтение программы, а также мешает вносить в нее изменения.

Overengineering — это своеобразное «горе от ума», специалист обладает, например, теоритическими знаниями по паттернам проектирования и пытается их применить, но при отсутствии практического опыта или его недостатке такие попытки зачастую приводят к неоправданному усложнению кода. В основе избыточного проектирования может быть психологическая особенность, связанная с нежеланием переделывать, программист хочет сделать «заранее», сделать так, чтобы потом не переделывать или свести переделку к минимуму. Это ошибочное ожидание, в реальности требования могут меняться, могут возникать новые запросы, связанные с лучшим понимаем клиентов и их потребностей.

3. Поиск и исправление ошибок Ошибки неизбежны, как и неизбежны затраты на их поиск и исправление. Однако можно устранить причины появления ошибок, т. е. создать такие условия, при которых ошибки не возникают или их возникает меньше. Помимо этого необходимо сократить время устранения ошибок, желательно это делать сразу же, как только они обнаружены.

Их накопление, откладывание исправлений — не допустимо. Трудоемкость исправлений и затрачиваемое на это время — сложно прогнозируемые величины. При накоплении ошибок, мы накапливаем неопределённость, связанную с временем завершения проекта или завершения отдельного его этапа. Кроме того, некоторые исправления могут повлечь за собой серьезные архитектурные изменения, которые также могут повлиять на время разработки.

Основные причины ошибок:

1)      Нарушение технологии: принципов ООП, принципов написания чистого кода. Примеры: большие классы (антипаттерн «God object»), большие методы, отсутствие единого подхода к именованию переменных и др. Все это естественным образом приводит к созданию хрупкого, запутанного, сложного кода, который, во-первых, способствует появлению ошибок, а во-вторых, затрудняет их поиск. Если речь идет об опытном, квалифицированном специалисте, то чаще всего нарушение технологии связано со спешкой.

2)      Низкая квалификация работника, низкая культура кодирования. Здесь возможны два пути: либо развивать программиста, либо изначально набирать в команду высококвалифицированных специалистов.

3)      Неудачно выбранный инструментарий, технологическая платформа. Можно привести пример с сильно и слабо типизированными языками, динамическая типизация — потенциальный источник ошибок, особенно для малоопытного программиста. Если есть выбор, то предпочтительнее язык с сильной типизацией.

Также проверка ошибок на этапе компиляции предпочтительнее, чем их проверка в процессе исполнения. Если язык не компилируемый (типа PHP) желательно использовать IDE с поверкой кода во время его редактирования, например, PhpStorm. Заключение. Вышеперечисленные потери — это далеко не все, что можно и нужно рассмотреть в рамках данной темы. Есть масса вопросов, связанных с организацией процесса, коммуникацией внутри и вне команды, выбором архитектурных решений, тестированием и др. Все это — потенциальные источники оптимизации трудозатрат и они также нуждаются в детальном рассмотрении.

Заключение

Проектирование — высокоинтеллектуальный процесс. Для понятия теории проектирования необходимо оперировать множеством терминов и определений, такими как проектная ситуация, технология, оптимизация программных разработок. Все это говорит о необходимости тщательно подходить к изучению словарного аппарата теории проектирования.

Программы в основном представляют собой сложные системы из миллионов машинных инструкций. Сложность определяется четырьмя основными причинами: сложностью задачи; сложностью управления процессом разработки; сложностью описания поведения отдельных подсистем; сложностью обеспечения гибкости конечного программного продукта.

При разработке программного обеспечения следует использовать следующие общие принципы: частотный; модульности; функциональной избирательности; генерируемости; функциональной избыточности; «по умолчанию».

Одной из важнейших составляющих успешного проектирования является системный подход, предусматривающий всестороннее исследование сложного объекта.

При создании и развитии ПО рекомендуется применять следующие общесистемные принципы: включения; системного единства; развития; комплексности; информационного единства; совместимости; инвариантности.

В программировании существуют различные парадигмы, приводящие к разным подходам при написании программ: процедурно-ориентированный; объектно-ориентированный; логически-ориентированный; ориентированный на правила; ориентированный на ограничения; параллельное программирование, а также многие другие.

Необходимо помнить, что проектирование неотъемлемо от различных стандартов (ГОСТ, ANSI, проекта) и их следует соблюдать как при оформлении документации, так и для унификации вашего проекта.

Программы создаются, эксплуатируются и развиваются во времени, проходя свой жизненный цикл. Характерная особенность жизненного цикла ПО — отсутствие этапа утилизации.

В процессе выполнения проекта предусматриваются отдельные моменты времени, которые характеризуются законченным оформлением результатов всех работ, выполненных разработчиками до данного момента. Согласно ГОСТ возможны следующие стадии разработки: ТЗ; ЭП; ТП; РП; внедрение. Возможны также и нестандартные этапы и стадии. Набор этапов и стадий отражает результаты проектирования самого процесса проектирования.

Модели играют важнейшую роль в проектировании программ. При построении моделей используется абстрагирование и декомпозиция.

Каждая стадия проекта завершается утверждением программных документов. Документы включают описания (спецификации). Спецификации являются моделями. Спецификации делятся на внешние и внутренние.

Рациональный выбор стандартных элементов («кубиков») имеет два аспекта: удобство при повторном использовании и возможность осуществления синтеза из малых элементов более общих элементов.

Имена, используемые в программах, должны соответствовать назначению, обладать узнаваемостью, обеспечивать запоминаемость, быть краткими, обладать уникальностью.

Список использованных источников

1. Артемьев. А. работаем на ноутбуке в Windows7. Самоучитель [Текст] / Артемьев. А. – СПб., 2014.
2. Граничин,о.Н. Информационные технологии в управлении / [Текст]. – М.: Бином, 2014.
3. Додд, А.З. Мир телекоммуникаций.обзор технологий иотрасли [Текст] / А.З. Додд. – М.:Олимп-Бизнес, 2015. – 400 с.
4. Ковтанюк Ю.С. Библия пользователя ПК. — М.: «Диалектика», 2016.
5. Кузнецов Е. Ю.,осман В. М. Персональные компьютеры и программируемые микрокалькуляторы: Учеб. пособие для ВТУЗов - М.: Высш. шк. -2014.
6. Ляхович В. Ф., Крамаров С.о.основы информатики: учебник. – М., 2015.
7. Мелехин, В.Ф. Вычислительные машины, системы и сети [Текст] / В.Ф. Мелехин, Е.Г. Павловский. – М.: Академия, 2016. – 557 с.
8. Семененко В.А. Айдидын В.М., Липова А.Д. Электронные вычислительные машины. – М.: Высшая школа, 2014.
9. Сапков, В.В. Информационные технологии и компьютеризация делопроизводства / [Текст]. – М.: Академия, 2013. – 288 с.
10. Скотт М. Модернизация и ремонт ПК. — 17-е изд. — М.: «Вильямс», 2015.
11. Степаненкоо.С. Персональный компьютер, учебный курс, 2-е издание. – СПб.: Компьютерное изд-во «Диалектика», 2014. – с. 195.
12. Современный компьютер: Сб. науч.-попул. статей; Пер. с англ./Под ред. В. М. Курочкина; Предисл. Л. Н. Королева. — М.: Мир, 2015. – с. 10.
13. Трофимов, В. Информационные системы и технологии в экономике и управлении / [Текст]. – М.: Юрайт, 2012. – 528 с.
14. Уинн Л. Рош. Библия по модернизации персонального компьютера. - Мн.: ИПП «Тивали-Стиль», 2014.
15. Фигурнов В. Э. «IBM PC для пользователя», 4-е издание, переработанное и дополненое, M., 2013.
16. Фролов А., Фролов Г. Аппаратноеобеспечение IBM PC. М.:Диалог-МИФИ, 2012. – с. 102.
17. Хомоненко А.Д.основы современных компьютерных технологий: Учебник / Под ред. проф., – СПб.: КОРОНА принт, 2015. – 223 с.
18. Шафрин Ю.А. IBM PC.Учебник. – М., 2012.
19. Яковенко Е.А. Компьютерные курсы. Учебник пользователя. – М.: АСП Сталкер, 2015.

1. Сапков, В.В. Информационные технологии и компьютеризация делопроизводства / [Текст]. – М.: Академия, 2013. – 288 с. ↑

2. Хомоненко А.Д.основы современных компьютерных технологий: Учебник / Под ред. проф., – СПб.: КОРОНА принт, 2015. – 223 с. ↑

3. Сапков, В.В. Информационные технологии и компьютеризация делопроизводства / [Текст]. – М.: Академия, 2013. – 288 с. ↑

4. Трофимов, В. Информационные системы и технологии в экономике и управлении / [Текст]. – М.: Юрайт, 2012. – 528 с ↑

5. Трофимов, В. Информационные системы и технологии в экономике и управлении / [Текст]. – М.: Юрайт, 2012. – 528 с ↑

6. Поппендик, М., Бережливое производство программного обеспечения: от идеи до прибыли [Текст]: пер. с англ. / М. Поппендик, Т. Поппендик — М.: Вильямс, 2010. ↑

7. Бережливое производство [Электронный ресурс]. — Режим доступа: https://ru.wikipedia.org/

   wiki/ Бережливое_производство ↑

8. Поппендик, М., Бережливое производство программного обеспечения: от идеи до прибыли [Текст]: пер. с англ. / М. Поппендик, Т. Поппендик — М.: Вильямс, 2010. ↑

9. Каскадная модель [Электронный ресурс]. — Режим доступа: https://ru.wikipedia.org/ wiki/ Каскадная_модель ↑

10. Яковенко Е.А. Компьютерные курсы. Учебник пользователя. – М.: АСП Сталкер, 2015. ↑

11. Agile-манифест [Электронный ресурс]. — Режим доступа: http://agilemanifesto.org ↑

12. Кериевски, Д., Рефакторинг с использованием шаблонов [Текст]: пер. с англ. / Д. Кериевски — М.: Вильямс, 2014. ↑