Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Понятие «программное обеспечение»

Содержание:

ВВЕДЕНИЕ

Мир информационных технологий очень активно развивается. Одним из главных её строительных блоков является программирование.

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

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

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

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

В рамках работы необходимо решить следующие задачи:

  • раскрыть понятие «программное обеспечение»;
  • изучить основные принципы проектирования программного обеспечения;
  • проанализировать этапы создания программного продукта;
  • рассмотреть модели жизненного цикла;
  • изучить гибкие методологии.

Для решения поставленной задачи была изучена литературы в области проектирования и создания программных продуктов. Список литературы представлен в последнем разделе.

1. Анализ предметной области

1.1 Понятие «программное обеспечение»

Программное обеспечение — это общий термин для различных видов программ, используемых для работы с компьютерами и связанными устройствами. Термин аппаратное обеспечение описывает физические аспекты компьютеров и связанных с ними устройств. [4]

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

Утилитарные программы ("программы для себя") предназначены для удовлетворения нужд их разработчиков. Чаще всего утилитарные программы выполняют роль сервиса в технологии обработки данных либо являются программами решения функциональных задач, не предназначенных для широкого распространения. [2, 13]

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

Свободное программное обеспечение, несколько более новая и не связанная с этим концепция, — это программное обеспечение, которое можно свободно использовать, модифицировать и распространять только с одним ограничением: любая распространяемая версия программного обеспечения должна распространяться с оригинальными условиями бесплатного использования, модификации и распространения (известны как авторское право). В отличие от бесплатного программного обеспечения, бесплатное программное обеспечение может распространяться за плату. Бесплатное программное обеспечение может быть более ограниченным в возможностях, чем свободное программное обеспечение. [5, 11]

Условно-бесплатная программа — это программное обеспечение, которое распространяется бесплатно на пробной основе с пониманием того, что пользователь может нуждаться или захотеть заплатить за него позже. Некоторые разработчики программного обеспечения предлагают условно-бесплатную версию своей программы со встроенным сроком действия (по истечении 30 дней пользователь больше не может получить доступ к программе). Другое условно-бесплатное программное обеспечение предлагается с определенными возможностями. [13]

Условно-бесплатное программное обеспечение иногда путают с бесплатными. Как и с открытым исходным кодом, бесплатное программное обеспечение действительно бесплатно, но, как и условно-бесплатное программное обеспечение, код бесплатного программного обеспечения является проприетарным, и автор сохраняет за собой авторские права.

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

Дополнительной и трудно классифицируемой категорией программного обеспечения является утилита, которая представляет собой небольшую полезную программу с ограниченными возможностями. Некоторые утилиты поставляются с операционными системами. Как и приложения, утилиты, как правило, устанавливаются отдельно и могут использоваться независимо от остальной части операционной системы. Например, апплеты — это небольшие приложения, которые иногда поставляются с операционной системой как «аксессуары». Они также могут быть созданы независимо с использованием Java или других языков программирования. [10]

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

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

Некоторые общие виды прикладного программного обеспечения включают в себя:

  • программное обеспечение для повышения производительности, которое включает в себя текстовые процессоры, электронные таблицы и инструменты для использования большинством пользователей компьютеров;
  • программное обеспечение для презентаций;
  • графическое программное обеспечение для графических дизайнеров;
  • CAD/CAM программное обеспечение;
  • специализированные научные приложения;
  • рыночное или отраслевое программное обеспечение (например, для банковской, страховой, розничной и производственной сред). [2, 13]

1.2 Особенности технологии разработки ПО

Технологии (с греческого: ремесло и наука) — совокупность знаний о способах и средствах проведении производственных процессов.

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

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

Эти две взаимно противоположные ситуации характеризуются различной степенью формализации и проведении процесса разработки программных средств. [14]

Степень формализованности и проведения процесса разработки программного обеспечения напрямую зависит от целей его создания, его величины, численности группы разработчиков и других факторов. От того, насколько правильно и удачно с точки зрения технологии разработки программного обеспечения построено приложение, зависит качество и жизнеспособность конечного продукта. [5, 8]

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

Технология разработки программного обеспечения предс­тавляет собой инженерный подход к разработке программных средств ЭВМ, охватывающий методологию программирования, проблемы обеспечения надежности программ, оценки рабочих характеристик и качества проектов.

Технология разработки программного обеспечения рассмат­ривает вопросы управления проектированием систем програм­много обеспечения, а также средства и стандарты разработки программ. [14]

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

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

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

  1. Необходима стандартизация языков проектирования программ, оформления и испытания программных модулей, а также гарантии их качества. Это позволит значительно сократить дублирующие разработки, внедрить сборочное программирование и вести накопление на предприятиях и в стране высококачественного программного продукта для его многократного использования в качестве типовых комплектующих изделий.
  2. Вести постоянный контроль и обеспечение качества программ.
  3. Программы не должны содержать непроверенных путей и ситуаций функционирования, которые приводят к неожиданным результатам.
  4. Пользователю или покупателю программ необходимо дать четкое представление о возможностях данной программы и технологических условиях эксплуатации, при которых гаран­тируются определенные функции и качества.
  5. Технология разработки программного обеспечения должна обеспечивать отделение программного изделия от его разработчика, т.е. человеческий фактор в программировании быть сведен к минимуму. [1, 11]
  6. Технология разработки программного обеспечения и средства ее поддержки (автоматизации) должны обеспечивать целенаправленную работу, прежде всего коллектива программистов, а не отдельных личностей. Она должна побуждать коллектив работать только правильно и слаженно; должна автоматически блокировать любые не санкционированные технологией действия.
  7. Необходимо вести аккуратное документирование всех этапов разработки. Документация должна также заноситься и храниться на магнитных носителях. Доступ к этой информации должен быть открытым, простым и автоматизированным.
  8. Работа пользователя должна обеспечиваться развитой информационно-справочной системой.
  9. Средства автоматизации технологии должны охватывать все этапы работы коллектива программистов.
  10. Технология разработки программного обеспечения должна быть простой в освоении, с автоматически включаемыми средствами подсказки.
  11. Технология разработки программного обеспечения должна иметь средства автоматической фиксации в хронологическом порядке всех действий, выполняемых в процессе коллективного изготовления программного изделия должны вестись и храниться в системе журналы (протоколы, дневники) разработки. Эти средства должны позволять восстанавливать любое состояние процесса разработки на любом интервале изготовления программного эксплуатации. [2, 14]

2. Проектирование программного обеспечения

2.1 Общие принципы проектирования систем

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

Понятие «правильная» по отношению к декомпозиции означает следующее:

  • количество связей между отдельными подсистемами должно быть минимальным (принцип «слабой связанности» — Low Coupling);
  • связность отдельных частей внутри каждой подсистемы должна быть максимальной (принцип «сильного сцепления» — High Cohesion).

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

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

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

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

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

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

С другой стороны, разработчики программного обеспечения исторически всегда стояли последними в ряду тех, кто использовал компьютерные технологии для повышения качества, надежности и производительности в своей собственной работе. [2, 4]

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

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

CASE-технология представляет собой совокупность методов проектирования ПО, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех стадиях разработки и сопровождения ПО и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методах структурного или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. [2]

2.2 Методы анализа и проектирования ПО

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

Таким образом, первым шагом упрощения сложной системы является ее

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

  • каждый «черный ящик» должен реализовывать единственную функцию

системы;

  • функция каждого «черного ящика» должна быть легко понимаема независимо от сложности ее реализации;
  • связь между «черными ящиками» должна вводиться только при наличии связи между соответствующими функциями системы (например, в бухгалтерии один «черный ящик» не обходим для расчета общей заработной платы служащего, а другой для расчета налогов — необходима связь между этими «черными ящиками»: размер заработной платы требуется для расчета налогов); [2]
  • связи между «черными ящиками» должны быть простыми, насколько это возможно, для обеспечения независимости между ними.

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

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

Структурным анализом принято называть метод исследования системы, начинающий с ее общего обзора, который затем детализируется, приобретая иерархическую структуру со все большим числом уровней. [2]

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

В структурном анализе и проектировании используются различные модели, описывающие:

  1. функциональную структуру системы;
  2. последовательность выполняемых действий;
  3. передачу информации между функциональными процессами;
  4. отношения между данными. [10]

Наиболее распространенными моделями первых трех групп являются:

  • функциональная модель SADT (Structured Analysis and Design Technique);
  • модель IDEF3;
  • DFD (Data Flow Diagrams) — диаграммы потоков данных. Модель «сущность — связь» (ERM — Entity-Relationship Model), описывающая отношения между данными, традиционно используется в структурном анализе и проектировании, однако, по существу, представляет собой подмножество объектной модели предметной области. [2]

В этом разделе были рассмотрены общие вопросы проектирования систем. Жизненный цикл ПО и непосредственно сами этапы будут изучены в следующем разделе.

3. Этапы создания программных продуктов

3.1 Этапы создания

Модели жизненного цикла программного обеспечения описывают фазы программного цикла и порядок их выполнения. Каждый этап дает результаты, необходимые для следующего этапа жизненного цикла. Требования переведены в дизайн. Код создается в соответствии с дизайном, который называется фазой разработки. После кодирования и разработки тестирование проверяет соответствие этапа реализации требованиям. Команда тестирования следует жизненному циклу тестирования программного обеспечения (STLC), который подобен циклу разработки, который следует за командой разработчиков. [9, 10]

В каждой модели жизненного цикла разработки ПО есть шесть следующих этапов:

  • сбор и анализ требований;
  • проектирование;
  • реализация или кодирование;
  • тестирование;
  • развертывание;
  • техническое обслуживание.

1. Сбор и анализ требований: бизнес-требования собираются на этом этапе. Этот этап является основным направлением работы руководителей проектов и заинтересованных сторон. Встречи с менеджерами, заинтересованными сторонами и пользователями проводятся с целью определения таких требований.

  1. Кто будет использовать систему?
  2. Как они будут использовать систему?
  3. Какие данные должны быть введены в систему?
  4. Какие данные должны выводиться системой?

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

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

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

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

3. Внедрение или кодирование: при получении проектной документации системы работа разделяется на модули или блоки и начинается фактическое кодирование. Так как на этом этапе код создается, поэтому он является основным направлением для разработчика. Это самая длинная фаза жизненного цикла разработки программного обеспечения.

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

5. Развертывание: после успешного тестирования продукт доставляется/развертывается заказчику для его использования.

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

6. Техническое обслуживание. Когда клиенты начинают использовать разработанную систему, возникают реальные проблемы, которые время от времени требуют решения. Этот процесс, где заботятся о разработанном продукте, известен как техническое обслуживание. [11]

3.2 Жизненный цикл программного продукта

Модель водопада — это линейный последовательный поток. В которых прогресс рассматривается как непрерывно нисходящий (как водопад) через фазы реализации программного обеспечения. Это означает, что любая фаза в процессе разработки начинается, только если предыдущая фаза завершена. Водопадный подход не определяет процесс возврата к предыдущему этапу для обработки изменений в требованиях. Водопадный подход — самый ранний и наиболее широко известный подход, который использовался для разработки программного обеспечения. [2, 5, 9]

Преимущества:

  1. Легко объяснить пользователям.
  2. Структурный подход.
  3. Этапы и мероприятия четко определены.
  4. Помогает планировать и планировать проект.
  5. Проверка на каждом этапе обеспечивает раннее обнаружение ошибок и недоразумений.
  6. Каждый этап имеет конкретные результаты.

Недостатки:

  1. Предполагается, что требования системы могут быть заморожены.
  2. Очень сложно вернуться на какой-либо этап после его завершения.
  3. Немного гибкости и настройки объема сложно и дорого.
  4. Дорого и требует больше времени, помимо подробного плана.

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

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

Преимущества:

  1. Простой и удобный в использовании
  2. Каждый этап имеет конкретные результаты.
  3. Более высокие шансы на успех по модели водопада из-за разработки планов испытаний в начале жизненного цикла.
  4. Хорошо работает там, где требования легко понять.
  5. Проверка и валидация продукта на ранних этапах разработки продукта.

Недостатки:

  1. Очень негибкий, как модель водопада.
  2. Регулировка объема сложна и дорога. [8, 11]
  3. Программное обеспечение разрабатывается на этапе реализации, поэтому ранние прототипы программного обеспечения не производятся.
  4. Модель не дает четкого пути для проблем, обнаруженных на этапах тестирования.
  5. Дорого и требует больше времени, в дополнение к детальному плану.

Модель прототипирования — это относится к деятельности по созданию прототипов программных приложений, например, неполных версий разрабатываемой программы. Это действие, которое может происходить при разработке программного обеспечения, и оно используется для визуализации некоторого компонента программного обеспечения, чтобы ограничить разрыв в неправильном понимании требований заказчика командой разработчиков. Это также уменьшит количество итераций, которые могут возникнуть в подходе с водопадом, и его трудно реализовать из-за негибкости подхода с водопадом. Таким образом, при разработке окончательного прототипа требование считается замороженным. [2]

Он имеет несколько типов, таких как:

  1. Быстрое прототипирование: прототипы, которые в конечном итоге отбрасываются, а не становятся частью окончательно поставляемого программного обеспечения
  2. Одноразовое прототипирование
  3. Эволюционное прототипирование: прототипы, которые эволюционируют в конечную систему благодаря итеративному включению отзывов пользователей.
  4. Эволюционное прототипирование
  5. Инкрементальное прототипирование: конечный продукт создается как отдельные прототипы. В итоге отдельные прототипы объединяются в общий дизайн.

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

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

Преимущества:

  1. Сокращение времени и затрат, но это может быть недостатком, если разработчик теряет время на разработку прототипов.
  2. Улучшено и увеличено участие пользователей.

Недостатки:

  1. Недостаточный анализ. Путаница пользователя с прототипом и готовой системой.
  2. Недопонимание разработчиком целей пользователя.
  3. Избыточное время разработки прототипа.
  4. Это дорого для реализации прототипов

Спиральная модель — он объединяет элементы как проектирования, так и поэтапного создания прототипа, стремясь объединить преимущества концепций сверху вниз и снизу-вверх. Эта модель развития сочетает в себе особенности модели прототипа и модели водопада. Спиральная модель предпочтительна для больших, дорогих и сложных проектов. Эта модель использует многие из тех же этапов, что и модель водопада, в основном в том же порядке, разделенных планированием, оценкой риска и созданием прототипов и симуляций. [5]

Он используется в больших приложениях и системах, которые встроены в небольшие фазы или сегменты.

3.3 Использование гибких методологий при разработке ПО

История Agile начинается с публикации в 2001 году «Манифеста гибкой разработки ПО», состоящего из 12 принципов. Конечно, отдельные положения Agile-подхода появились появлялись и до этого, но только этот документ систематизировал и изложил их в достаточной для использования мере. Каждый год под манифестом подписываются новые компании, IT-специалисты и проектные менеджеры. Появляются новые методы и модификации гибкой системы разработки. [3, 9, 15]

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

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

12 принципов, которые составляют Agile Methodology, можно поделить на 4 главные идеи:

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

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

Метод успешно применяют такие компании как Microsoft, Yahoo, Siemens Healthcare, а проектный менеджер в Amazon даже описал кейс внедрения Scrum на основе полученного опыта.

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

Джефф Сазерленд, автор книги «Scrum. Революционный метод управления проектами» выделил 8 шагов по использованию методики:

  1. Выберите владельца продукта — он знает о цели проекта и ожидаемом результате.
  2. Соберите команду — до 10 человек с необходимыми для создания работоспособного продукта навыками.
  3. Найдите скрам-мастера — он следит за ходом проекта, помогает проектной команде бороться с трудностями.
  4. Составьте бэклог продукта — на Agile-доске расставьте приоритеты по каждому требованию к продукту. В этом большую роль играет владелец продукта, который собирает пожелания к продукту для оценки командой бэклога.
  5. Запланируйте спринты (итерации) — отрезки времени на выполнение определенного ряда задач.
  6. Организовывайте ежедневные пятнадцатиминутные «мит-апы» — задавайте по 3 вопроса каждому из команды: что делал вчера, что будет сегодня, что мешает выполнить задачу.
  7. Делайте обзоры рабочих частей продукта — с вовлечением в просмотр и обсуждение стейкхолдеров.
  8. Проводите ретроспективу — обсуждение проблемы и поиск решения после каждого спринта. Полученный план изменения внедряете на следующем спринте.

В скрам есть 4 ключевых элемента:

  1. Product Backlog — список требований по проекту
  2. Sprint Backlog — список требований, которые нужно выполнить в ближайший спринт
  3. Sprint Goal — цель спринта
  4. Sprint Burndown Chart — диаграмма, которая обновляется по мере завершения задач. По ней легко понять динамику и уровень продвижения команды в проекте. [5]

Разработчик методики, Кент Бек, создал метод экстремального программирования, цель которого — справиться с постоянно меняющимися требованиями к программному продукту и повысить качество разработки.

Он применим исключительно в сфере разработки ПО, и строится вокруг 4 процессов:

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

Малоизвестное на отечественных просторах проектного менеджмента семейство методологий, разработанное Алистером Кокберном, одним из автором «Манифеста гибкой разработки ПО». Классификацию Кокберн предлагает проводить по цветам за критерием количества человек в команде: от 2 (Crystal Clear) до 100 (Crystal Red). Под более масштабные проекты выделены цвета Maroon, Blue и Violet. [15]

Crystal-проекты должны соответствовать 3 основным показателям:

  • быстрая доставка рабочего кода — развитие идеи итеративной модели разработки Agile.
  • совершенство через рефлексию — новая версия ПО улучшается на основе данных о предыдущей.
  • «осмотическое» взаимодействие — нововведение Алистера, метафора коммуникации и обмена информацией между разработчиками ПО в одной комнате.

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

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

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

DSDM делится на версии, которые обновляются по мере развития технологий, появления новых требований к разработке ПО. Последняя на сегодня — DSDM Atern, выпущенная в 2007 году, хотя предыдущая (2003 года) еще в строю.

В начале команда изучает реальность разработки приложения и область применения. Дальше работа делится на три взаимосвязанных цикла:

  • цикл функциональной модели — создание аналитической документации и прототипов. [15]
  • цикл проектирования и конструирования — приведение системы в рабочее состояние.
  • цикл реализации — развертывание системы.

FDD тоже применяется итерационная модель разработки, от Agile она отличается в следующем:

  • больше внимания предварительному моделированию
  • повышенная (по сравнению с Agile) важность построения отчётности и графиков
  • нацелено на корпоративную разработку.

Feature Driven Development состоит из таких цикличных этапов:

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

Lean Software Development — скорее не методология, а набор принципов бережливого производства, который направлен на повышение эффективности процесса разработки, минимизацию затрат. [15]

В набор входят следующие 7 принципов:

  1. избавление от потерь — всё, что не прибавляет ценности продукту для конечного потребителя.
  2. постоянное обучение — непрерывное развитие команды увеличивает возможности эффективного выполнения задач.
  3. принятие решения так поздно, как только можно — приоритет не спонтанным решениям, а продуманным, разработанным на основе полученных знаний.
  4. быстрая доставка — по сути основа итеративной модели.
  5. усиление команды — один из принципов «Манифеста...» гласит, что люди и взаимодействие важнее процессов и инструментов. Проектная команда — основа успешного завершения задач.
  6. целостность и качество — нужно изначально делать качественный продукт, чтобы не тратить время и ресурсы на дальнейшее тестирование и избавление от багов.
  7. видение цельной картины — разбиение проекта на отдельные части невозможно без понимания текущего статуса разработки, целей, концепции и стратегии разрабатываемого ПО.

Agile Modeling — набор ценностей, принципов и практик для моделирования программного обеспечения.

AM используют как составляющую полноценной методики разработки ПО — например, экстремального программирования или Rapid Application Development.

Принципы Agile Modeling таковы:

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

AUP — упрощённая версия другой методологии разработки ПО — Rational Unified Process (RUP). С 2012 года её заменили на Disciplined Agile Delivery (DAD), но кое-где AUP еще встречается.

Автор методики, Скотт Амблер, выделил следующие ключевые позиции Agile Unified Process:

  1. Команда знает, что делает;
  2. Простота превыше всего.
  3. Соответствие принципам гибкой методологии разработки.
  4. Сфокусированность на ценных для проекта активностях.
  5. Независимость в выборе инструментов.
  6. Индивидуальная настройка AUP под нужды конкретного проекта.

ADM — набор итеративных методик гибкой разработки программного обеспечения, которые делают упор на формирование требования и решений по проекту через сотрудничество отдельных команд. Как и AUP, это не самоценная методика. [15]

Суть Agile Data Method определяется шестью положениями:

Данные — основа создания любого приложения.

  1. Проблемы с проектом — их можно обнаружить только при чётком понимании цели и концепции проекта.
  2. Рабочие группы — помимо непосредственной команды разработчиков есть enterprise groups, которые поддерживают другие рабочие группы.
  3. Уникальность — нет идеальной методики, под каждый проект нужно комбинировать инструменты с разных методологий.
  4. Работа в команде — совместная работа гораздо эффективнее, чем поодиночке.
  5. «Сладкое пятно» — поиск оптимального решения проблемы («сладкого пятна»), избегая крайностей.

Essential Unified Process (EssUP) — это разработка шведского учёного Ивара Якобсона, созданная для улучшения Rational Unified Process.

EssUP оперирует понятием практики, в которые входят:

  • сценарий использования — описание поведения системы.
  • итерационная разработка — создание рабочих кусков кода короткими циклами в несколько недель.
  • командные практики — направленные на сплочение команды и повышение её эффективности.
  • процессуальные практики — например, «Думай глобально, начинай с малого» или «Вовлекайте стейкхолдеров в бизнес-процессы».

Все практики в том или ином виде встречаются в методологиях RUP, CMMI и гибкой методике разработки.

Getting Real (GR) — эффективная для стартапов и начинающих команд методология, которая предлагает по максимуму использовать особенности небольших проектов и компаний: мобильность, гибкость, поиск новых решений, отсутствие жёсткой запутанной иерархии и т.д. Джейсон Фрид и Давид Ханссон, основатели компании 37signals (теперь — Basecamp), определили Getting Real как систему для решения реальных задач: максимально простую, понятную и функциональную. [15]

GR — сборная группа из десятка инструментов гибкой разработки, которые используются для минимизации:

  • возможностей;
  • опций и настроек;
  • структуры компании;
  • встреч;
  • обещаний.

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

OpenUP (OUP) — независимая от инструментов методология разработки ПО без жесткой структуры, которая содержит такие практики:

  • измерение скорости работы команды;
  • проведение ежедневных встреч и ретроспектив по завершению итераций;
  • концепция микрошагов и раннего тестирования с использованием чеклистов;
  • методика гибкого моделирования (AMDD).

Практики реализуются на основе четырех принципов:

  • согласование интересов и достижение общего видения во время совместной работы
  • непрерывное совершенствование через постоянную обратную связь
  • фокусирование на архитектуре приложения на ранних стадиях для минимизации рисков
  • максимизация ценности для конечного потребителя.
  • непрерывное совершенствование через постоянную обратную связь. [15]

Учитывая разнообразие инструментов, практик, методов и методологий в Agile, нужно выбрать инструмент, который поможет определить эффективность каждого из них. Таким инструментом выступают метрики. [9]

Для большинства проектов хватит 4 направлений метрик:

  1. Производительность — сюда относятся Velocity и WIP. Первая подойдёт не для всех проектов, так как идет измеряются количество выполненных задач в итерацию, а они неравнозначны. Метрика Work-in-Progress определяет лимит задач на разных стадиях: и чем он выше, тем хуже;
  2. Прогнозирование — метрика capacity: определение количества идеальных часов, доступных в следующем спринте. Соответственно, можно понять, сколько времени есть на работу, насколько эффективно выполнение задач и как спланировать количество задач для спринта;
  3. Качество — например, индекс стабильности требований, который рассчитывается по формуле = (Общее количество оригинальных бизнес-требований + Число требований, которые поменялись к этому времени + Число добавленных требований + Число убранных требований) / (общее число оригинальных требований). С помощью метрики определяется количество времени, затраченное на переделывание задач;
  4. Ценности — в каждом случае просчитывается индивидуально, зависимо от формата проекта. Например, стартап AirBnb в качестве метрики, определяющую конечную ценность продукта для пользователей, выбрала количество загруженных фотографий высокого качества. С их увеличением пропорционально росло и количество потребителей.

К метрикам применимы те же правила, что и к другим Agile-инструментам. [15]

Нет единственно верной или нужной проекту метрики. Их нужно постоянно пересматривать, отбрасывать устаревшие и добавлять новые по мере необходимости. Она должна быть понятна и доступна всей всей команде, не превращаться в самоцель. Метрика ради метрики — плохое решение.

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

1. Agile подойдет для всех проектов.

Самое упорное заблуждение. Ни один метод Agile не добавит сам по себе ценности продукту и не смотивирует команду.

2. Agile против документации.

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

3. Agile и планирование несовместимы.

Опровержением этого мифа служат дневные планирования с 10-минутными стэндапами, итерационное планирование каждые две недели, спринт-встречи и т.д.

4. Agile требует много переделывания (re-work).

В гибкой методологии разработки ПО переделывание проявляется в двух формах: переделывание требований (пользователи понимают, что им действительно нужно) и программного обеспечения (команды разработчиков находят улучшенные способы написать и спроектировать приложение). Но с этим приходится сталкиваться и в других методиках! Более того, для уменьшения негативного влияния rework и нужна итерационная модель, которая является особенностью Agile. [15]

Плюсы использования Agile следующие:

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

Минусы:

  • повышенные требования к команде и клиентам — без тесного взаимодействия между проектной командой и пользователями невозможно добиться выхода качественного продукта с высокой ценностью. А обилие инструментов и методов в Agile для внедрения требует опытную команду.
  • не подходит для аутсорса и проектов, где участники взаимодействуют друг с другом только онлайн.
  • риск никогда не выпустить финальную версию ПО — этот минус, как ни странно, выплывает из итеративной разработки и непрерывного совершенствования продукта — плюсов Agile.
  • не работает без четкого видения бизнес-целей проекта — так как Agile-команда ориентируется на стейкхолдеров, то без выработки целей и концепции продукта разработка невозможна. [15]

В этом разделе были изучены этапы создания ПО, жизненный цикл, а также рассмотрены гибкие методологии разработки.

ЗАКЛЮЧЕНИЕ

В рамках работы решены следующие задачи:

  • раскрыто понятие «программное обеспечение»;
  • изучены основные принципы проектирования программного обеспечения;
  • проанализированы этапы создания программного продукта;
  • рассмотрены модели жизненного цикла;
  • изучены гибкие методологии.

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

  1. Богданов В. Управление проектами. Корпоративная система – шаг за шагом. — Манн, Иванов и Фербер (МИФ), 2012. — 241 с.
  2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. — Финансы и статистика, 2005. — 544 с.
  3. Вольфсон Б. Гибкое управление проектами и продуктами. — Питер, 2016. — 160 с.
  4. Джефф Паттон Пользовательские истории. Искусство гибкой разработки ПО. — Питер, 2014. — 400 с.
  5. Джефф Сазерленд Scrum. Революционный метод управления проектами. — Манн, Иванов и Фербер (МИФ), 2014. — 320 с.
  6. Дженнифер Дэвис, Кэтрин Дэниелс Философия DevOps. Искусство управления IT. — Питер, 2016. — 610 с.
  7. Мартин Клеппман Высоконагруженные приложения. Программирование, масштабирование, поддержка. — Питер, 2017. — 640 с.
  8. Эндрю Стеллман, Дженнифер Грин Постигая Agile. — Манн, Иванов и Фербер (МИФ), 2015. — 650 с.
  9. Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong, Richard Turner The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software. — Addison-Wesley Professional, 2014. — 336 p.
  10. Chris Sims, Hillary Louise Johnson Scrum: a Breathtakingly Brief and Agile Introduction. — Dymaxicon, 2012. — 54 p.
  11. John Ousterhout A Philosophy of Software Design. — Yaknyam Press, 2018. — 190 p.
  12. Joyce Farrell Programming Logic & Design, Comprehensive. — Cengage Learning, 2017. — 656 p.
  13. Life-Prog [Электронный ресурс] Основные понятия. Программный продукт Режим доступа: https://life-prog.ru/2_13687_osnovnie-ponyatiya-programmniy-produkt.html Дата обращения (19.01.2019)
  14. Технология программирования [Электронный ресурс] Технология разработки программного обеспечения. Режим доступа: http://www.tehprog.ru/index.php_page=lecture12.html Дата обращения (19.01.2019)
  15. WorkSection [Электронный ресурс] Методология Agile. Матерь драконов или всех гибких методологий. Режим доступа: https://worksection.com/blog/agile.html Дата обращения (19.01.2019)