Для каких целей необходимо программное обеспечение для разработки
Обновлено: 09.05.2024
В настоящее время существует огромное количество программных продуктов, позволяющих в сжатые сроки эффективно и качественно разработать программный комплекс для различных предметных областей.
К ним относятся такие программные средства, как Delphi, Visual C++, С Builder, Visual Basic, Java Builder;
Использование средств этого типа оправдано, когда необходимо в сжатые сроки создать приложение с удобным и понятным графическим интерфейсом.
Приняв во внимание вышеперечисленные аргументы, для разрабатываемого программно-методического комплекса целесообразно использовать средства типа RAD.
Для функционирования программного комплекса, необходима также некоторая программная среда, в простейшем случае представленная операционной системой. В более сложных случаях, когда система работает с большим количеством данных, которые необходимо поддерживать в актуальном состоянии, должна присутствовать некоторая СУБД.
Для правильного и обоснованного выбора RAD-средства необходима оценка продуктов по определенным критериям экспертами. Получить оценку продуктов можно из специальных источников. Но эта оценка дается, учитывая специфику разработки приложения. Более или менее рациональный выбор средства разработки приложения можно сделать только в контексте конкретного проекта или конкретной организации, ведущей разработку.
Поэтому для правильной оценки средств разработки приложения нужна оценка экспертов, ознакомленных со спецификой разрабатываемого приложения, с вопросами его дальнейшей модификации и сопровождения. Ввиду невозможности получить такую оценку от признанных экспертов и не достаточной серьезности разрабатываемого приложения, решил в качестве экспертов принять студентов группы и других лиц, занимающихся разработкой программ.
Во внимание принимались различные критерии для оценки качества программного продукта, в частности такие, которые учитывают аспекты разрабатываемого программного продукта:
- доступность программных средств разработки и реализации;
- cоответствие выбираемых программных средств уровню подготовленности программиста;
- возможности программных средств для разработки профессиональных приложений и сложных программных систем;
- оценка качества средств с точки зрения надежности, производительности, удобства работы и трудоемкости их эксплуатации;
- перспективность и жизнеспособность фирм изготовителей программных средств, возможность обновления и наличия новых версий продуктов при модернизации программно-технической среды;
- возможность перехода от однопользовательского варианта (для отладки и локального применения) к сетевому, для средств разработки и средств эксплуатации, а также его сложность;
- стыковка с широким спектром других СУБД и возможности переноса БД для данного программного средства на другие СУБД;
- возможность подключения к корпоративным сетям и Интернет/Интранет, поддержка постоянно развивающихся WEB технологий;
- модульный принцип построения, степень ее универсальности.
- наличие документации на русском языке, справочных систем, документации в печатном и электронном исполнении, возможности консультаций;
- простота языка программирования;
- скорость работы приложения;
- скорость компиляции приложения;
- наличие интегрированного отладчика;
- обработка исключительных ситуаций;
Методика определения подходящего программного продукта заключается в следующем.
Сначала выбирается несколько доступных и известных программных продуктов. Мною для рассмотрения были выбраны Delphi 5.0, Visual C++ 6.0 и Visual Basic. Каждому критерию назначил вес, исходя из целей проектирования таким образом, что сумма весов всех критериев равнялась 1.
Потом по каждому из параметров критерия давалась оценка программному продукту по десятибалльной шкале, и считалась интегральная оценка по каждому программному продукту по формуле 1.1.
Вычисления по формуле (1.1) сведены в таблицу 1.2.
Как видно из таблицы 1.2 наиболее подходящим средством для разработки программного комплекса является Delphi 5.0.
Таблица 1.2 - Сравнение программных продуктов
1.4 Техническое задание 1.4.1 Введение
Программный комплекс предназначен для создания курса обучения дисциплине и для обучения дисциплине.
1.4.2 Основания для разработки
Разработка программного комплекса ведется на основании задания на дипломную работу, утвержденное приказом ректора Донбасской машиностроительной академии по ГОСТ 19.101-77.
1.4.3 Назначение разработки
Программный комплекс предназначен для создания большого числа обучающих дисков по разным дисциплинам. Включает интерфейс для создания курса обучения и оболочку для обучения.
1.4.4 Требования к программному изделию 1.4.4.1 Требования к функциональным характеристикам
Программный комплекс должен выполнять следующие функции:
- предоставлять возможность ввода лекций и другого учебного материала с рисунками, видео и звуковым сопровождением;
- предоставлять возможность изменения курса;
- предоставлять возможность проходить курс(обучаться);
- предоставлять возможность контролировать полученные знания;
- содержать гипертекстовые ссылки для быстрого перехода на соответствующую ссылку;
- предоставлять возможность поиска по всему курсу.
1.4.4.2 Требования к надежности
Программный комплекс должен устойчиво функционировать и не приводить к зависанию операционной системы в аварийных ситуациях.
Контроль формируемого учебного материала возложен на пользователя, который создает учебный курс.
1.4.4.3 Условия эксплуатации
Температура окружающего воздуха, влажность и другие параметры микроклимата должны соответствовать требованиям к помещениям, оборудованным персональными ЭВМ.
Для создания учебного курса необходим человек – преподаватель или пользователь, который будет заводить материал. Человек должен обладать навыками работы с персональной ЭВМ, оснащенной операционной системой Windows.
1.4.4.4 Требования к составу и параметрам технических средств
Для нормального функционирования программного комплекса необходима персональная ЭВМ со следующими характеристиками:
- объем оперативной памяти не менее 32 мегабайт;
- процессор не ниже Pentium 166, мышь, клавиатура;
- наличие свободного места на жестком диске в размере не менее 5 мегабайт;
1.5.4.5 Требования к информационной и программной совместимости
Программа должна функционировать под операционной системой Windows. Должна быть установлена программа BDE Administrator для работы с базами. Исходные коды программы должны быть написаны на языке Object Pascal в среде разработки Delphi 5.0. Информация должна вводиться непосредственно через GUI. Результат визуализации информации должен быть представлен в хорошо воспринимаемом виде.
1.4.4.6 Требования к программной документации
Предварительный состав программной документации установлен в соответствии с ГОСТ 19.101-77. Ниже перечислен список программных документов и их содержание.
Текст программы – запись программы с необходимыми пояснениями и комментариями.
Описание программы – сведения о логической структуре и функционировании программы.
Программа и методика испытаний – требования, подлежащие проверке при испытании программы, также порядок и методы контроля.
Техническое задание – настоящий документ.
Пояснительная записка – результаты исследования структур представления информации, общее описание функционирования программы, а также обоснование принятых технических и технико-экономических решений.
1.4.5 Стадии и этапы разработки
Стадии и этапы разработки должны соответствовать ГОСТ 19.101-77 и состоять из следующих пунктов.
1 Техническое задание – черновое определение требований к программному комплексу и программной документации.
2 Эскизный проект – разработка структур представления информации в программном комплексе, разработка структуры классов, необходимых для реализации поставленного алгоритма. Формулировка методов реализации вложенности в программном комплексе, разработка структуры программы.
3 Технический проект – уточнение структуры классов и методов представления информации. Детальное уточнение метода реализации вложенности. Разработка структуры программы.
4 Рабочий проект – разработка программы, разработка программной документации, испытание программы.
1.4.6 Порядок контроля и приемки
Разработанное программное обеспечение должно соответствовать требованиям заказчика и отвечать всем поставленным функциональным требованиям. Программа должна быть протестирована на возможность возникновения исключительных ситуаций и должна быть сделана соответствующая рецензия.
1.5 Разработка математической модели
Очень важным этапом при создании электронного учебника является выбор материалов для обучения и стрктура представления этих материалов.
Предлагаются следующие шаги для составления курса обучения:
- Методическая разработка темы обучающей программы.
- Анализом результатов специальных модельных экспериментов разработать модель главы для профильного учебника.
- Определить требования к программному продукту, с помощью которого можно педагогам образовательных учреждений создавать электронные учебники для профильной школы с учетом уровня подготовки педагогов к использованию компьютера.
- Разработать пакет программных средств , предназначенный для разработки электронных средств учебного назначения: информационных и экспертных систем, электронных учебников, специальных средств для изучения учащихся.
- Предложить технологию разработки электронных учебников для профильного обучения с помощью пакета.
- Разработать ряд учебников и провести эксперименты по их проверке с учащимися и педагогами.
На основе анализа электронных средств, созданных педагогами и специальных исследований разработать новый проект программных средств для создания электронных учебников.
При разработке учебника необходимо учитывать: интересы учащихся, их психологически особенности, отношение к предмету и педагогу, возможности учащихся выполнить творческие задания и ориентация на него, затруднения школьников в изучении предмета и виды помощи, которые они предпочитают.
Этапы разработки электронного учебника можно представить в виде схемы, изображенной на рисунке 1.2.
- В учебнике требуется уделить специальное внимание мотивации обучающихся к изучению каждой темы. Общими моментами в данной плоскости являются: возможности применения математики в соответствующей предметной области, необходимость сдачи экзаменов.
- Возможность накопить опыт творческой деятельности в разных предметных областях, знакомство с интересными применениями ЭВМ.
- Учебник должен обеспечить возможность ученику выбрать не только уровень, на котором будет изучать учебный материал темы, но и разный способ изучения темы (не менее двух способов). При этом ученик должен осознать, что он и только он отвечает за свой выбор уровня изучения темы.
Рисунок 1.2 - Этапы разработки ЭУ
- Учебник призван защитить обучаемых от перегрузки. В частности, этому служит раздел домашних заданий по новому материалу (в нем представлены минимальное число задания, которые будут предложены на дом и при выполнении которых студенту вновь предстоит выбирать уровень сложности).
- В учебнике должен быть специальный тренажер, обращаясь к которому по своей инициативе ученик может не только отработать алгоритмы решения основных типов задач, но и учиться: отказываться от известного метода решения задач и находить другие методы, составлять задачи, искать и исправлять ошибки в решении задач, проводить анализ ситуаций разными способами и др.
- В учебнике должен быть раздел личного мониторинга, предназначенный для учащихся, которые до проведения контрольной работы хотят оценить результаты своей работы над темой и своевременно внести необходимые коррективы, хотят узнать прогноз результата выполнения контрольной и получить указание от компьютера, каким образом можно его улучшить.
- Предусмотрены различные виды помощи ученикам. Особенно важным является включение специальной экспертной системы, которая предназначена не только для оказания помощи ученикам в решении конкретных задач на уроке или дома, но и ориентирована на передачу опыта автора учебника с разными элементами учебника.
- Раздел творческих заданий, в котором предлагаются возможные проекты для нужд учебного заведения и для участия в конференциях и конкурсах, проводимых как внутри учебного заведения , так и вне его.
- Важно, чтобы учебник можно было существенно изменять и дополнять на основе не только разработок автора учебника, учителя, который его использует, но и учащимися вместе с учителем на основе проектов, выполненных учениками и с учетом особенностей образовательного учреждения и профиля класса. Вот одна иллюстрация: учебник по математике для гуманитарных классов может быть переведен учащимися на те иностранные языки, которые изучают учащиеся. В этом случае новые ученики, использующие дополненный вариант электронного учебника, получают новый возможный вариант изучения темы – изучать тему на иностранном языке.
- Существенно, чтобы обучающиеся знакомились с опытом выполнения каких-то работ, которые являются важными для профиля класса, которые вызывают известные затруднения учащихся и которые выполнены их сверстниками. Это достигается за счет включения в учебник разделов, в которых представлены разные варианты выполнения одних и тех же заданий учениками, изучавшими материал с помощью электронного учебника (к примеру, на рефлексию или систематизацию, на составление задач и др.) и анализ выполнения, выполненные учениками и автором электронного учебника.
Исходя из вышеперечисленного предлагается структура материалов, приведенная на рисунке 1.3.
1.6 Разработка компонентов программного комплекса 1.6.1 Разработка логической модели программного комплекса
Одним из способов при описании логической модели программного комплекса является структурный анализ.
Сущность структурного подхода заключается в декомпозиции (разбиении) системы на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов [45]. В качестве двух базовых принципов используются следующие:
- принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
- принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из
них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:
- принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
Рискнок 1.3- Структура материалов
- принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
- принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
- принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
- SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы ;
- DFD (Data Flow Diagrams) диаграммы потоков данных ;
- ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь";
- STD (State Transition diagrams) диаграммы переходов состояний.
На стадии проектирования модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения.
Перечисленные модели в совокупности дают полное описание системы независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
1.6.1.1 Функциональная модель программного комплекса
Разработка функциональной модели программного комплекса сводится к разработке:
- общего алгоритма работы;
Рассмотрим вышеперечисленные элементы более подробно.
Раздел: Информатика, программирование
Количество знаков с пробелами: 149070
Количество таблиц: 17
Количество изображений: 18
“Мы подготовили для вас перевод статьи о методологиях разработки, которая в сжатой форме описывает наиболее популярные из тех, что используются сегодня. Хотя эти методологии в большей степени относятся именно к разработке программного обеспечения, мы SMART business также очень широко используем их для внедрения систем по управлению бизнесом.
В этих внедрениях главной частью является не разработка программного обеспечения, а конфигурирование и поднастройка к существующим в компании бизнес-процессам, путем использования того набора инструментов и функциональности, который уже создан поставщиками таких решений. С каждой версией эти инструменты совершенствуются, и трудно не заметить фокус на абсолютно новую аудиторию – Citizen Developers. Наверное, вы все видите, какую популярность набирают no-code и low-code подходы, роботизация процессов (RPA), и самое интересное то, что новые инструменты требуют новых подходов.
Хотим поделиться с вами последними обновлениями методологии Microsoft, получившей название Success by Design, и очень рекомендуем всем, кто интересуется этим вопросом, ознакомиться с бесплатным курсом, поскольку он, по нашему мнению, относится не только к Microsoft Dynamics 365 и Power Platform, но и очень структурировано описывает подход к решению бизнес-задач с цифровизации компаний.”
Кирилл Руднев управляющий партнер SMART business
Сегодня мы живем в мире, где весь контроль – под рукой. Технологии развиваются за гранью воображения. И все благодаря индустрии разработки программного обеспечения!
Методология, предназначенная для жизненного цикла разработки ПО, фактически является структурой, используемой для планирования и управления процедурой создания специализированной информационной системы для достижения желаемых целей.
Эти инновационные методы подчеркивают процесс создания программного обеспечения на каждом этапе разработки. Фактически, это постепенное развитие больше связано с управлением проектами и как таковое не предполагает каких-либо технических нюансов.
Это скорее касается правильного планирования и включает в себя любые итерации, необходимые для создания высокомасштабируемого программного обеспечения.
Простота и надежность этих принципов заключается в том, чтобы предлагать индивидуальную разработку ПО в соответствии с требованиями, и это то, что должна принять каждая команда разработчиков ПО.
Каскадная модель (“Waterfall”)
Если вы работаете в компании по разработке программного обеспечения, в какой-то момент вы непременно сталкиваетесь с каскадной моделью ведения проекта по разработке продукта.
Рассматриваемый как традиционный метод разработки ПО в программной инженерии, каскадный метод позволяет представить процесс в виде линейного потока с заданной последовательностью, чтобы пользователи понимали, что следующий этап наступает по завершении предыдущего. Более того, согласно этой методологии, вернуться к исправлению изменений невозможно.
Плюсы:
- Легкая для понимания и функциональная.
- Достаточно проста в обращении благодаря зафиксированной структуре.
- Экономит много времени.
- Позволяет легко тестировать и анализировать.
Минусы:
- Соответствует только конкретным потребностям.
- Не применима к проектам технического обслуживания.
- Нет возможности узнать возможный результат проекта.
- Не подходит для длительных и бессрочных проектов.
Прототипирование
Это специализированный принцип разработки программного обеспечения, согласно которому разработчики создают только образец решения, чтобы подтвердить его функциональную суть для клиентов и провести существенную итерацию перед созданием конечного продукта и финальным тестированием качества.
Лучшее в этой методологии то, что она обычно помогает решить ряд разнообразных проблем, возникающих при использовании каскадного метода.
Плюсы:
- Дает четкое представление о функциональном процессе программного обеспечения.
- Снижает риск сбоя в работе программного обеспечения.
- Хорошо помогает при сборе требований и общем анализе.
Минусы:
- Вероятность увеличения управленческих расходов.
- Чрезмерное участие клиента может повлиять на работу.
- Слишком много изменений, влияющих на рабочий процесс по разработке программного обеспечения.
Методология гибкой разработки ПО (“Agile”)
Как инновационный подход и одна из ведущих моделей разработки ПО, методология гибкой разработки программного обеспечения используется для формулирования хорошо организованной процедуры управления проектами, допускающей периодические изменения.
Безусловно, методология Agile-разработки – это теоретический план для реализации нескольких программных продуктов и проектов.
Плюсы:
- Agile-подход адаптивен и благоприятно реагирует на изменения.
- Позволяет прямое общение для поддержания прозрачности.
- Постоянное улучшение качества за счет быстрого обнаружения и устранения дефектов и раннего выявления несоответствий ожиданиям.
Минусы:
- Методология сосредоточена на работе с программным обеспечением, а не на эффективном документировании.
- Есть шансы сбиться с пути, поскольку исход не ясен.
Быстрая разработка приложений
(RAD – Rapid Application Development)
Быстрая разработка приложений, нацеленная на получение быстрых результатов, представляет собой модель разработки программного обеспечения, которая может помочь создать превосходные процессы с помощью других подходов к разработке ПО.
Подход создан, чтобы максимально использовать преимущества ПО для разработки.
Он предназначен для увеличения работоспособности всего проекта по разработке ПО и акцентирует участие активного пользователя.
Найм сотрудников для таких проектов непрост, потому что необходимо учитывать множество факторов. В этой статье Collectiveray речь идет о нескольких способах поиска разработчиков приложений для таких проектов.
Плюсы:
- Упрощает весь процесс разработки.
- Помогает клиенту совершать быстрые проверки.
- Поощряет обратную связь от клиентов для улучшения.
Минусы:
- Производительность зависит от команды.
- Работает на модульной системе, ограниченной этой методологией.
- Требуется высококвалифицированный персонал для решения сложных задач.
- Не применим для проектов с небольшим бюджетом.
Метод разработки динамических систем
(DSDM – Dynamic System Development Model)
Аутентично сформулированный и созданный на основе методологии быстрой разработки приложений, этот итеративный и поэтапный подход ориентирован на участие пользователя.
Задача этой методологии – обеспечить рабочий процесс разработки ПО в рамках конкретных сроков и выделенного бюджета.
Именно поэтому он достаточно востребован в мире разработки программного обеспечения.
Плюсы:
- Пользователи получают контроль над процессом разработки ПО.
- Функциональность разрабатывается быстро.
- Легкий доступ разработчиков к конечным пользователям.
Минусы:
- Внедрение этой методологии требует больших затрат.
- Не подходит для небольших организаций.
Спиральная модель
Имея сложную структуру, этот подход призван снизить ранние риски в проекте.
Что касается процесса разработки ПО, разработчики начинают на низких уровнях и исследуют присущие ему риски.
Далее разработчики создают план итераций по спирали. Реализация любой модели жизненного цикла спирали основывается на последовательном, внимательном и грамотном управлении проектом.
Плюсы:
- Факторы риска значительно снижены.
- Отлично подходит для больших и сложных проектов.
- Позволяет создавать дополнительные функции позже.
- Подходит для очень рискованных проектов с различными бизнес-потребностями.
Минусы:
- Дорогостоящая модель в разработке ПО.
- Сбой на этапе анализа рисков может нанести ущерб всему проекту.
- Не подходит для проектов с низким уровнем риска.
- Может затянуться и никогда не закончиться
Экстремальное программирование (XP)
Экстремальное программирование определяется тем фактом, что вовлеченность клиентов в процесс создания ПО невероятно высока.
Как методология гибкой разработки ПО, методология экстремального программирования в настоящее время известна как методология XP.
Он в основном используется для создания ПО в очень несбалансированной атмосфере.
Это обеспечивает большую управляемость в рамках процедуры моделирования.
Основная цель модели XP – снизить стоимость необходимого программного обеспечения.
Однако в рамках модели XP цена изменения требований на последующих этапах проекта может быть огромной.
Плюсы:
- Основное внимание уделяется вовлечению клиентов.
- Устанавливает рациональные планы и графики.
- Разработчики очень преданны проекту.
- Использование современных методов качественного программного обеспечения.
Минусы:
- Эффективность зависит от вовлеченных людей.
- Требуются частые встречи по разработке, что увеличивает общие затраты.
- Необходимость чрезмерных изменений в разработке.
- Будущие возможности и результаты точно не известны.
Рассмотрим некоторые дополнительные преимущества, которые вы можете получить при использовании XP:
Коммуникация
В XP процесс коммуникации прост, надежен и довольно прозрачен. Каждый из членов команды зависит друг от друга и делится знаниями внутри команды, что означает, что все знают об обязанностях друг друга.
Простота
Поскольку сам этап коммуникации начинается с простого и прозрачного подхода, простота гарантируется на всех остальных этапах. Более того, в этом контексте простота относится к реализации подхода, при котором вы сокращаете всё неважное и включаете только необходимую информацию.
Обратная связь
Благодаря обратной связи легче отследить области, которые можно улучшить наряду с модификацией применяемых в ней процессов, чтобы обеспечить качество продукции.
Мотивация
Смелость – это не что иное, как набор действий, которые в случае их реализации могут нанести вред команде и бизнес-требованиям. С мотивацией вы можете работать над выявлением серьезных факторов, которые могут повлиять на ваши услуги.
В команду, работающую по методологии Экстремального программирования, входит 5 человек: клиент, координатор, программист, специалист по контролю качества и трекер.
Разработка, управляемая функциональностью
(FDD – Feature-driven development)
Являясь итеративной методологией разработки программного обеспечения, она нацелена на обслуживание большого количества команд, работающих над проектом на основе объектно-ориентированной технологии. Такая модель подходит для компаний, которые переходят от поэтапного метода к итерационному.
Она известна как методология FDD и достаточно функциональна и креативна, чтобы справляться с различными сложностями.
Плюсы:
Минусы:
- Не подходит для небольших проектов и одного разработчика – всегда требуется огромная команда, а это означает, что невозможно гарантировать быстрый релиз в срок.
- Высокая степень зависимости от ведущих разработчиков, что требует полной структуры – процесс необходимо контролировать на каждом этапе, поскольку даже незначительный недостаток может создать хаос в системе.
Совместная разработка приложений
(JAD – Joint Application Development)
Методология совместной разработки приложений – это подход к классификации требований и расширению пользовательского интерфейса, который требует от конечных пользователей, клиентов и разработчиков присутствия на крупной удаленной конференции, где они могут расставить акценты и согласовать программную систему.
Эта методология служит для включения клиента в разработку и расширение приложения.
Подход реализуется с помощью серии согласованных семинаров, известных как JAD-сессии.
Он, как правило, ставит во главу угла сложности бизнеса, а не методические детали.
Плюсы:
- Позволяет одновременно собирать и объединять большие объёмы информации.
- Генерирует огромное количество ценной информации за короткий период.
- Позволяет немедленно решать разногласия с соответствующей помощью.
- Предоставляет форум для рассмотрения разных вопросов.
Минусы:
- Планирование и составление расписания отнимает много времени.
- Требует значительных затрат времени и усилий.
- Требует высококвалифицированных специалистов, которых сложно найти.
Бережливая разработка ПО (Lean Development)
Как следствие технического прогресса, модель бережливой разработки делает упор на создание легко управляемого программного обеспечения.
Эта тонко разработанная методология более продумана, чем любая другая форма гибкой методологии.
Цель этой процедуры – улучшить ПО в три раза быстрее, при очень ограниченном бюджете и минимальном объеме необходимого рабочего процесса.
Плюсы:
- Меньше требований к бюджету и времени.
- Позволяет предоставить продукт раньше срока.
Минусы:
- Работоспособность команды определяет успех процесса разработки ПО.
- Неподходящий бизнес-аналитик может стать причиной серьезных проблем.
- Излишняя гибкость приводит к тому, что разработчик теряет фокус.
Rational Unified Process (RUP)
Методология Rational Unified Process, получившая название RUP, обеспечивает разработку программного обеспечения с использованием Rational Tools.
Эта методология разделяет процесс расширения на четыре различных этапа, каждый из которых включает бизнес-моделирование, проверку и проектирование, внедрение, тестирование и утилизацию.
Это объектно-ориентированная методология развития программ в режиме онлайн.
Модель помогает разработчикам программного обеспечения в формулировании руководящих принципов, шаблонов и образцов для всех функций и этапов разработки программного обеспечения.
Плюсы:
- Особое внимание уделяется точной документации.
- Устраняет риски, связанные с меняющимися потребностями клиентов.
- Мало требований по интеграции.
Минусы:
- Требуется очень опытный разработчик ПО.
- Сложная процедура разработки методологии.
- Интеграция может вызвать путаницу.
- Очень сложна для понимания.
Scrum
SCRUM – это наиболее предпочтительный подход к гибкой разработке для большинства команд разработчиков ПО, который фактически является гибкой средой. (Аналогично, KANBAN – это процесс, который помогает командам сотрудничать и эффективно работать.) По сути, эта методология подходит для программных проектов, которые постоянно меняются или имеют чрезвычайно высокие требования к масштабированию.
Модель разработки программного обеспечения Scrum начинается с непродолжительного планирования, конференции и завершается заключительным обзором.
Эта методология используется для создания ПО и включает в себя серию итераций для создания необходимого программного обеспечения.
Это идеальный подход, потому что он без особых усилий приводит в движение прогрессирующие проекты.
Плюсы:
- Принятие решений находится в руках команды.
- Документ бизнес-требований считается несущественным.
- Малоконтролируемый метод, предполагающий постоянные обновления.
Минусы:
- Нестабильная стоимость.
- Не подходит для крупных проектов.
- Требуется высококвалифицированная команда, в которой нет места новичкам.
Технологии проложили путь ко многим радикальным изменениям в разработке программного обеспечения, которые даже изменили подходы к программированию.
Главное – то, что они решают самые разные сложности, требующие квалифицированного подхода.
Для разработки ПО существуют методологии, которые работают на определенных платформах, что дает им свободу действий.
Это требует высокого качества работы под руководством профессионалов, имеющих многолетний опыт эффективного решения технических проблем.
Благодаря различным формам методологий, применимых к разному набору проектов разработки программного обеспечения, у разработчиков есть множество вариантов для создания превосходно работающего ПО.
Сегодня все смотрят именно в сторону технологий, и постоянные изменения привели к разработке различных программных продуктов. И именно методологии создания полезного программного обеспечения улучшают бизнес-процедуры и предоставляют возможности для создания технических методологий.
Существенным фактором разработки качественного программного обеспечения является то, что оно упрощает сложную процедуру, но требует комплексного подхода к техническим деталям и экспертных знаний.
Именно гибкие команды и эксперты помогают каждому программному продукту работать эффективно; в противном случае весь процесс может быть испорчен.
Средства разработки программного обеспечения – совокупность приемов, методов, методик, а также набор инструментальных программ (компиляторы, прикладные/системные библиотеки и т.д.), используемых разработчиком для создания программного кода, отвечающего заданным требованиям.
Разработка программ – сложный процесс, основной целью которого является создание, сопровождение программного кода, обеспечивающего необходимый уровень надежности и качества. Для достижения основной цели разработки программ используются средства разработки программного обеспечения.
Основные средства, используемые на разных этапах разработки программ
При анализе возможностей средств разработки программного обеспечения в качестве критериев оценки могут применяться такие критерии как:
- скорость выполнения разработанного программного обеспечения,
- кроссплатформенность разработанного программного обеспечения,
- поддержка работы с сетью при помощи API функций сокетов,
- возможность реализации объектно-ориентированных методов программирования,
- возможность запуска программ в виде службы операционной системы Windows,
- наличие развитой системы помощи,
- поддержка стандартных библиотек и компонентов,
- сложность разработки интерфейса в данной среде,
- условия распространения данной среды разработки программного обеспечения (платно или бесплатно) и т.п.
В зависимости от предметной области и задач, поставленных перед разработчиками, разработка программ может представлять собой достаточно сложный, поэтапный процесс, в котором задействовано большое количество участников и разнообразных средств. Для того, чтобы определить, когда и в каких случаях какие средства применяются, выделим основные этапы разработки программного обеспечения. Наибольший интерес для проблематики рассматриваемого вопроса представляют следующие этапы разработки:
- Проектирование приложения.
- Реализация программного кода приложения.
- Тестирование приложения.
Здесь сознательно опущены этапы, связанные с написанием технического задания, планирования сроков, бюджета и т.д. Причина этого заключается в том, что на данных этапах, за редким исключением, практически не используются специфические средства разработки.
Средства проектирования приложений
На этапе проектирования приложения в зависимости от сложности разрабатываемого программного продукта, напрямую зависящего от предъявляемых требований, выполняются следующие задачи проектирования:
- Анализ требований.
- Разработка архитектуры будущего программного обеспечения.
- Разработка устройств основных компонент программного обеспечения.
- Разработка макетов Пользовательских интерфейсов.
- BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer).
- Блок-схемы (Vision 2003 и многие другие).
- ER-диаграмы (Visio 2003, ERWin, Sybase Power Designer и многие другие).
- UML-диаграмы (Sybase Power Designer, Rational Rose и многие другие).
- макеты, мат-модели и т.д.
Иногда, когда разрабатываемый программный продукт предназначен для автоматизации какой-либо сложной деятельности задача Анализа (Моделирования) выполняется до составления технических требований к будущему продукту. Результаты анализа позволяют сформировать обоснованные требования к той или иной функциональности разрабатываемой программы и просчитать реальную выгоду от внедрения разрабатываемого продукта. Более того, иного получается так, что по результатам анализа первоначальные цели и задачи автоматизации кардинально меняются или по результатам оценки эффективности разработки и внедрения принимается решение продукт не разрабатывать.
Целью второй и третьей задачи из приведенного списка задач является разработка модели (описания) будущей системы, понятной для кодировщика – человека, который пишет код программы. Здесь огромное значение имеет то, какую парадигму программирования (парадигму программирования также необходимо рассматривать как средство разработки) необходимо использовать при написании программы. В качестве примера основных парадигм необходимо привести следующее:
- Функциональное программирование;
- Структурное программирование;
- Императивное программирование;
- Логическое программирование;
- Объектно-ориентированное программирование (прототипирование; использование классов; субъективно-ориентированное программирование ).
Выбор её во многом зависит от сложившихся привычек, опыта, традиций, инструментальных средств, которыми располагает коллектив разработчиков. Иногда разрабатываемый программный продукт настолько сложен, что для решения ряда задач в разных компонентах системы используются разные парадигмы. Необходимо отметить, что выбор того или иного подхода накладывает ограничения на средства, которые будут применены на этапе реализации программного кода. Результатом решения данной задачи в зависимости от подхода могут быть (в скобках приведены программные средства, которые могут быть использованы для их получения):
- диаграмма классов и т.д (Ration Rose, Sybase PowerDisigner и многие другие).
- описание модулей структур и их программного интерфейса (например, Sybase PowerDisigner и многие другие).
Разработка макетов пользовательских интерфейсов подразумевает создание наглядного представления того, как будут выглядеть те или иные видеоформы, окна в разрабатываемом приложении. Решение данной задачи основывается на применение средств дизайнера, которые в данной статье рассматриваться не будут.
Средства реализации программного кода
На этапе реализации программного кода выполняется кодирование отдельных компонент программы в соответствии с разработанным техническим проектом. Средства, которые могут быть применены, в значительной степени зависит от того, какие подходы были использованы во время проектирования и, кроме этого, от степени проработанности технического проекта. Тем не менее, среди средств разработки программного кода необходимо выделить следующие основные виды средств (в скобках приведено примеры средств):
Средства тестирования программ
Основными задачами тестирования является проверка соответствия функциональности разработанной программы первоначальным требованиям, а также выявление ошибок, которые в явном или неявном виде проявляются во время работы программы. Среди основных работ по тестированию можно выделить следующее:
- Тестирование на отказ и восстановление.
- Функциональное тестирование.
- Тестирование безопасности.
- Тестирование взаимодействия.
- Тестирование процесса установки.
- Тестирование удобства пользования.
- Конфигурационное тестирование.
- Нагрузочное тестирование.
Среди основных видов средств, которые могут быть применены для выполнения поставленных работ можно привести следующие:
- средства анализа кода, профилирования (Code Wizard – ParaSoft, Purify – Rational Softawre. Test Coverage – Semantic и т.д.);
- средства для тестирования функциональности (TEST – Parasoft, QACenter – Compuware, Borland SilkTest и т.д.);
- средства для тестирования производительности (QACenter Performance – Compuware и т.д).
Процесс разработки программ является сложным процессом и то, какие средства необходимо применять во многом зависит от задач, поставленным перед разработчиками. В независимости от задач разработки средства нельзя ограничивать лишь набором каких-то инструментальных средств, также необходимо включать методы, методики, подходы и все-то, что применяется для создания программы, отвечающей заданным требованиям.
Выделены и охарактеризованы основные этапы разработки программного обеспечения. Для каждого этапа приведены и описаны средства, которые могут быть применены для достижения целей этапа.
Терминология
Средства разработки программного обеспечения – совокупность приемов, методов, методик, а также набор инструментальных программ (компиляторы, прикладные/системные библиотеки и т.д.), используемых разработчиком для создания программного кода Программы, отвечающего заданным требованиям.
Разработка программ – сложный процесс, основной целью которого является создание, сопровождение программного кода, обеспечивающего необходимый уровень надежности и качества. Для достижения основной цели разработки программ используются средства разработки программного обеспечения.
Основные средства, используемые на разных этапах разработки программ
В зависимости от предметной области и задач, поставленных перед разработчиками, разработка программ может представлять собой достаточно сложный, поэтапный процесс, в котором задействовано большое количество участников и разнообразных средств. Для того, чтобы определить, когда и в каких случаях какие средства применяются, выделим основные этапы разработки программного обеспечения. Наибольший интерес для проблематики рассматриваемого вопроса представляют следующие этапы разработки:
1. Проектирование приложения.
2. Реализация программного кода приложения.
3. Тестирование приложения.
Здесь сознательно опущены этапы, связанные с написанием технического задания, планирования сроков, бюджета и т.д. Причина этого заключается в том, что на данных этапах, за редким исключением, практически не используются специфические средства разработки.
Средства проектирования приложений
На этапе проектирования приложения в зависимости от сложности разрабатываемого программного продукта, напрямую зависящего от предъявляемых требований, выполняются следующие задачи проектирования:
1. Анализ требований.
2. Разработка архитектуры будущего программного обеспечения.
3. Разработка устройств основных компонент программного обеспечения.
4. Разработка макетов Пользовательских интерфейсов.
- BPMN (Vision 2003 + BPMN, AcuaLogic BPMN, Eclipse, Sybase Power Designer).
- Блок-схемы (Vision 2003 и многие другие).
- ER-диаграмы (Visio 2003, ERWin, Sybase Power Designer и многие другие).
- UML-диаграмы (Sybase Power Designer, Rational Rose и многие другие).
- макеты, мат-модели и т.д.
Иногда, когда разрабатываемый программный продукт предназначен для автоматизации какой-либо сложной деятельности задача Анализа (Моделирования) выполняется до составления технических требований к будущему продукту. Результаты анализа позволяют сформировать обоснованные требования к той или иной функциональности разрабатываемой программы и просчитать реальную выгоду от внедрения разрабатываемого продукта. Более того, иного получается так, что по результатам анализа первоначальные цели и задачи автоматизации кардинально меняются или по результатам оценки эффективности разработки и внедрения принимается решение продукт не разрабатывать.
Целью второй и третьей задачи из приведенного списка задач является разработка модели (описания) будущей системы, понятной для кодировщика – человека, который пишет код программы. Здесь огромное значение имеет то, какую парадигму программирования (парадигму программирования также необходимо рассматривать как средство разработки) необходимо использовать при написании программы. В качестве примера основных парадигм необходимо привести следующее:
- Функциональное программирование;
- Структурное программирование;
- Императивное программирование;
- Логическое программирование;
- Объектно-ориентированное программирование (прототипирование; использование классов; субъективно-ориентированное программирование ).
Выбор её во многом зависит от сложившихся привычек, опыта, традиций, инструментальных средств, которыми располагает коллектив разработчиков. Иногда разрабатываемый программный продукт настолько сложен, что для решения ряда задач в разных компонентах системы используются разные парадигмы. Необходимо отметить, что выбор того или иного подхода накладывает ограничения на средства, которые будут применены на этапе реализации программного кода. Результатом решения данной задачи в зависимости от подхода могут быть (в скобках приведены программные средства, которые могут быть использованы для их получения):
- диаграмма классов и т.д (Ration Rose, Sybase PowerDisigner и многие другие).
- описание модулей структур и их программного интерфейса (например, Sybase PowerDisigner и многие другие).
Разработка макетов пользовательских интерфейсов подразумевает создание наглядного представления того, как будут выглядеть те или иные видеоформы, окна в разрабатываемом приложении. Решение данной задачи основывается на применение средств дизайнера, которые в данной статье рассматриваться не будут.
Читайте также: