Добавлен: 22.04.2023
Просмотров: 328
Скачиваний: 2
СОДЕРЖАНИЕ
1.1 Программирование как вид деятельности
2 Выбор технологии разработки, анализ требований
2.1 Обоснование выбора стандарта методики организации жизненного цикла (ISO/IEC 12207: 1995-08-01)
1.2 Анализ и уточнение требований к программному продукту
2.3 Анализ процесса обработки информации и выбор структур данных для ее хранения
2.4 Выбор методов и разработка основных алгоритмов решения задач
3.1 Разработка структурной схемы программного продукта
3.2 Проектирование интерфейса пользователя
3.3 Построение графа - диалога
3.4 Разработка форм ввода/вывода информации
8. Проект можно считать реализованным после того как клиент подписал акт приемки, и все же связь с исполнителем не должна разрываться. В особенности на первых порах у пользователей системы регулярно будет появляться огромное количество вопросов. Также непременно будут появляться первые ошибки, которые нужно оперативно ликвидировать. Более того, разработчик может создавать обновленные версии системы, соответственно старую систему доведется регулярно обновлять. Сопровождение – это непосредственная коммуникация с клиентом по вопросам обслуживания системы. Эта услуга бесплатна на установленный гарантийный срок (к примеру, на год). В действительности объемы программирования, тестирования (отладки) в совокупном цикле проектирования - минимальны. Данный этап составляет от 10-ти до 20-ти % от совокупного объема проекта.
1.3 Контроль качества
Чем масштабнее проект, тем больше в нем вероятных ошибок. В таком случае не рекомендуется излишне затягивать процесс отладки — возрастает недовольство заказчика, срываются сроки контракта, как результат - на рынок поступает недоработанная система с огромным количеством ошибок, которые ликвидируются в ходе использования разработкой бесчисленных «заплаток».
Инновационные технологии проектирования надежных программ предполагают регулярный сквозной контроль качества создаваемых проектов на всех стадиях жизненного цикла — начиная от оценки перечня требований, заканчивая внедрением, сопровождением, тестированием. В результате качество плановых работ формализуется числовыми показателями посредством специализированных подходов, и все же их можно контролировать, рациональным образом организовав рабочий процесс многочисленной команды разработчиков и аналитиков. Чтобы это сделать необходимо иметь возможность анализировать все поправки, вносимые в программу — корректировка требований, сопроводительных документов, формализованных моделей, вариантов исходных текстов, алгоритма реализации календарного плана по проектированию, отладке, внедрению, сопровождению, кроме того управлять и контролировать данные стадии процесса разработки ПО. Для таких целей используются системы конфигуративного управления — дорогостоящие, сложные продукты (цена варьируется в пределах десятков - сотен тысяч долл.), и все же без них масштабный проект вероятнее всего обречен на фиаско.
К примеру, системы упрощенного конфигурационного управления, которые охватывают процедуры контроля вариантов исходных текстов, комплекс прочих вопросов функционирования группы разработчиков, встроены в системы Visual и Delphi.
1.4 Стандарты качества ПО
Организации могут организовать максимально эффективную процедуру проектирования программного продукта, в свою очередь клиенты весьма закономерно далеко не всегда готовы до конца поверить в его действенность. На сегодняшний день существует международная система сертификации предприятий по стандарту качества ISO 9000, она гарантирует следующее – фирма высококачественно реализует программные проекты, в установленные сроки. Процедура сертификации достаточно непростая, требует предварительной подготовки на протяжении 2-3-х лет. Кроме того, сертификация по стандарту ISO 9000 может осуществляться предприятиями, которые имеют соответствующее право, или на конкретной территории (к примеру, Восточная Европа), или же по всему миру. Так, до 1999-го организация, обладающая правом на международную сертификацию, на территории РФ смогла выдать единственный стандарт качества ISO 9000.
Тогда как пару лет назад в США удалось разработать специфическую методологию Capability Maturity Model for Software (СММ), благодаря которой можно сертифицировать фирмы по одному из пяти уровней «развитости» процесса разработки программы. В соответствии с итогами двадцатилетних исследований Американского Министерства обороны, основная причина распространенных проблем во время проектирования масштабных информационных проектов - неспособность управленческих кадров руководить процессом разработки качественного продукта.
По сравнению со стандартом ISO 9000, который всего лишь удостоверяет качество работы фирмы на основе обобщенных критериев, методика СММ нацелена непосредственно на качество управления процедурой проектирования, обладает огромным количеством практичных советов, директив по методикам организации всех стадий разработки программы. На сегодняшний день в США нет возможности получить крупный военный либо государственный заказ на разработку ПО стоимостью свыше 2-х миллионов долл., в том случае, если предприятие не сертифицировано по крайней мере по 3-му уровню СММ. Тогда как по 5-му уровню сертифицировано не больше 10-ти компаний во всем мире.
2 Выбор технологии разработки, анализ требований
2.1 Обоснование выбора стандарта методики организации жизненного цикла (ISO/IEC 12207: 1995-08-01)
Жизненный цикл программного обеспечения (сокращенно – ЖЦ ПО) – это одно из основных понятий в методологии проектирования различных программных средств. Под ЖЦ ПО подразумевается процесс, начинающийся с решения выполнить разработку ПО и заканчивающийся его изъятием из эксплуатации.
Главным нормативным документом, который регламентирует ЖЦ ПО, выступает международный стандарт ISO/IEC 12207, выдаваемый Международной организацией по стандартизации – International Organization of Standardization (ISO) и Международной комиссией по электротехнике – International Electrotechnical Commission (IEC). Указанный стандарт назначает структуру ЖЦ, в которой содержатся действия, процессы и задачи, выполняемые в ходе создания ПО. Согласно стандарту ISO/IEC 12207 обычная структура ЖЦ ПО базируется на трех основных группах процессов:
Ключевые процессы ЖЦ ПО – подразумевают покупку, поставку, создание, сопровождение и последующую эксплуатацию программного обеспечения.
Вспомогательные процессы – гарантируют выполнение всех главных процессов. В эту группу входят следующие действия: управление конфигурацией, документирование, достижение качества, аттестация, верификация, аудит, оценка и решение всевозможных проблем.
Организационные процессы – предполагают формирование инфраструктуры проекта, осуществление управления различными проектами, оценивание, определение и улучшение ЖЦ, процесс обучения.
В разработку включаются работы по подготовке ПО и его составляющих (аналитическая работа, проектирование, программирование) согласно установленным требованиям. Сюда же входит составление проектных и эксплуатационных документов, всех материалов, которые необходимы для проверки качества и работоспособности программных продуктов, а также материалов, требующихся для обучения персонала.
В процесс эксплуатации стандартно включаются:
- работы по внедрению разных компонентов ПО, включая конфигурирование рабочих мест пользователей и базы данных, подготовку эксплуатационной документации, обучение сотрудников и др.;
- сама эксплуатация, предполагающая локализацию тех или иных проблем, борьбу с причинами их появления, модификацию ПО в соответствии с установленным регламентом, разработку предложений по развитию, совершенствованию и модернизации системы.
Далее отметим, что управление проектом тесно связано с планированием и организацией работ, образованием целых коллективов разработчиков, а также с контролем качества и сроков выполнения работ. Организационное и техническое обеспечение каждого проекта предусматривает подбор инструментальных средств и методов для выполнения проекта, установление оптимальных методов описания состояний разработки промежуточного характера, разработку средств и методов испытаний ПО, реализацию обучения сотрудников и т.д.
Гарантирование должного качества проекта связано с необходимостью верификации, проверки и дальнейшего тестирования ПО. Под верификацией подразумевается процесс установления соответствия текущего состояния разработки требованиям того этапа, на котором она находится. С помощью проверки можно дать оценку соответствию параметров разработки исходным требованиям. Частично проверка совпадает с процессом тестирования, связанным с идентификацией отличий между ожидаемыми и действительными результатами, а также с оценкой корреспонденции характеристик ПО первоначальным требованиям. В ходе осуществления проекта особое место отводится вопросам описания, идентификации и контроля конфигурационных запросов к отдельным элементам и, в целом, ко всей системе.
Управление конфигурацией – это один из процессов вспомогательного характера, который поддерживает главные процессы ЖЦ ПО (в первую очередь процессы разработки и последующего сопровождения ПО). При подготовке проектов сложных ИС, которые состоят из большого количества элементов, и каждый из них может дополнительно иметь версии или разновидности, необходимо вести учет их функций и связей, а также сформировать унифицированную структуру и достичь развития системы. Посредством управления конфигурацией можно организовать, регулярно учитывать и контролировать все изменения, внесенные в ПО, на каждой из стадий его ЖЦ. Принципы и рекомендации по планированию, ведению конфигурационного учета и управлению конфигурациями ПО представлены в проекте такого стандарта как ISO/IEC 12207-2.
Отметим, что всякий процесс отличается конкретными задачи и различными методами их решения, первоначальными данными, которые были получены на предшествующем этапе, и конечными итогами. Так, результатами анализа выступают информационные и функциональные модели, а также соответствующие им диаграммы. При этом ЖЦ ПО отличается итерационным характером: итоги очередного этапа зачастую провоцируют изменения в тех проектных решениях, которые были подготовлены на предыдущих этапах.
В целом, жизненный цикл состоит из таких ключевых этапов:
Системный анализ – в ходе его выполнения устанавливается необходимость в ПС, а также его предназначение и функциональные характеристики. Кроме того, на данном этапе выполняется оценка затрат и определяется вероятная эффективность использования подобного комплекса программ.
Проектирование ПС – предполагает разработку структуры всего комплекса и отдельных его составляющих. Также выполняется программирование модулей и несколько этапов отладки, проводится испытание, после чего следует введение в эксплуатацию полностью выполненной версии КП.
Эксплуатация ПС – предусматривает исполнение и применение программ на ЭВМ для обработки данных и получения необходимых результатов, которые изначально были целью разработки ПС, а также достижение надежности и достоверности предоставляемых сведений.
Сопровождение ПС – предполагает эксплуатационный сервис, совершенствование функциональных возможностей, улучшение эксплуатационных характеристик ПС, а также тиражирование КП и его перенос на разнообразные типы вычислительных средств.
Этап системного анализа является самым трудно формализуемым, специфичным и тесно связанным с предназначением ПС. На данном этапе определяется назначение и главные показатели качества разрабатываемых программ. Предметную область системного анализа почти полностью определяют решаемые задачи. По этой причине на указанном этапе тяжело обобщать все критерии качества и технологические процессы, необходимые для создания разных типов программ.
Подчеркнем, что этапы проектирования, сопровождения и эксплуатации существенно различаются между собой целями и задачами, а также средствами и методами. Далее показатели качества ПС, а также методы их установления систематизируются по названным трем этапам. Соответственно, программное средство рассматривается в качестве объекта разработки либо как функционирующий продукт, объект модификации и контроля.
Важно отметить специфику взаимодействия этапа сопровождения с двумя другими этапами – проектирования и эксплуатации, ведь сопровождение выступает в качестве необходимой обратной связи между ними (Рисунок 1).
При функционировании программ вероятно обнаружение в них ошибок, вследствие чего возникает необходимость в расширении их функций и модификации. Подобные доработки обычно реализуются параллельно с эксплуатацией действующей версии ПС. Когда подготовленные корректировки проходят проверку на одном экземпляре программ, тогда следующая версия заменяет более ранние или только некоторые из них. Вместе с тем, процесс эксплуатации может почти не перерываться, ведь замена версий отличается кратковременностью. Указанные обстоятельства ведут к тому, что эксплуатация той или иной версии ПС реализуется параллельно и, как правило, не зависит от этапа сопровождения.
Рисунок 1 - Модели жизненного цикла программного обеспечения.
Упомянутый ранее стандарт ISO/IEC 12207 не предусматривает определенную модель ЖЦ или методы создания ПО. Все его регламенты имеют общий характер и нацелены на самые разные модели ЖЦ, технологии и методологии разработки. Этот стандарт описывает общую структуру процессов ЖЦ ПО, однако детали реализации либо выполнения действий и тех задач, которые входят в данные процессы, упускает.