Основы проектирования программ. Этапы создания ПО

Содержание:

Введение

Актуальность овладения основами проектирования программного обеспечения обусловлена:

- во-первых, тем, что данная технология имеет широкую область применения для профессии программиста;

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

- в-третьих, проектные технологии обеспечивают конкурентоспособность специалиста на рынке труда.

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

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

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

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

2. Разработать структурную схему программного продукта;

3. Реализовать и провести тестирование программы.

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

1 Проектирование программ

1.1 Программирование как вид деятельности

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

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

1.2 Этапы разработки программ

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

Процесс создания программного продукта

Проанализируем традиционный процесс создания программного продукта.

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

Поскольку перечень требований к проекту в процессе работы над ним, как правило, изменяется, расширяется, а осуществление требований необходимо четко контролировать, используются специализированные программные инструменты для регулирования данных вопросов. Как правило, заказчик не может конкретно объяснить, что хочет получить в итоге, при этом основная функция экспертов по системной оценке — предоставить помощь в определении своих требований в форме, подходящей для формализации. По факту согласования перечня требований заключается соглашение на подготовку программного продукта. А значит в последующем всяческие отступления от установленных требований к проекту (и со стороны исполнителя, и со стороны клиента) оцениваются как нарушения соглашения. Реализация каждого этапа требует от клиента значительных инвестиций персональных трудозатрат, мобилизации высококвалифицированных экспертов, соответственно такой труд в обязательном порядке должен высоко оплачиваться — вряд ли кто-либо согласится реализовывать сложные проекты на бесплатной основе. И все же, несмотря на то, что первый этап – наиболее значимый, клиенты крайне редко осознают такую важность, не готовы тратить достаточно крупные бюджеты. Средний объем работ на такой стадии составляет 5 % от общего объема разрабатываемого продукта.

2. Выполняется предпроектное исследование объекта автоматизации. Посредством CASЕ-инструментов создается формальная модель работы программы, модель информационной базы, информационных потоков, объектов. На такой стадии, как правило, мобилизуются специалисты клиента, а также консультанты, которые отменно знают специфику предметной области, для которой формируется задача. Средний объем работ на второй стадии — порядка 10% от совокупного.

3. На базе формальной модели готовиться детальное техническое задание для разработчиков, определяются спецификации обособленных модулей, таблицы информационных баз, прочие сопроводительные документы. Составляется детальный рабочий календарный план, в котором отмечаются реализуемые объемы работ, ответственные исполнители, а также сроки (помесячно, понедельно). Так, для разработки рабочих планов можно использовать различные программные продукты, подходящие для немногочисленных команд разработчиков, либо для групп, состоящих из сотен специалистов, реализующих сотни-тысячи разнообразных задач в пределах единого плана. Средние объемы работ на третьей стадии — около 10 % от совокупного объема.

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

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

Весьма популярным считается подход итерационного проектирования, нацеленный на применение RAD-инструментов, систем автоматизированной генерации исходных текстов на базе разработанной модели формального типа. Данная методика хороша тем, что благодаря ей можно максимально быстро подготовить первый функционирующий образец программного продукта, до того момента, когда перечень требований к нему еще не в полном объеме детерминирован, и в последующем, на дальнейших итерациях (как правило, необходимо от 2-х до 5-ти), систематически уточнять, осуществлять определенные возможности, упущенные по некоторым причинам в ходе предшествующей итерации. Данный подход слегка отличается от нисходящей разработки тем, что используется, когда конечные требования до конца неизвестны, могут изменяться, а базовые работающие функции необходимы для заказчика максимально быстро (как правило, клиент хочет уже сегодня получить программу, готовую на 80%, нежели завтра – на 100% законченную). В случае нисходящей разработки главная структура задачи должна детерминироватся заблаговременно. Вынесение решения об окончательном выборе соответствующей методики — ответственный вопрос. Специалист, ответственный за принятие такого рода решение, прежде всего должен иметь значительный рабочий опыт, обширные познания в сфере разработки программных продуктов. Также многое обуславливается инфраструктурой клиента — какие ПК он использует, какие ОС, какие ресурсы есть в наличии. Согласно таким данным определяются рациональные инструменты проектирования. В некоторых ситуациях случается, что оптимальнее всего подходит к примеру, итерационный подход, и все же для ОС клиента нет хорошей RAD-среды, а значит рациональнее остановить свой выбор на менее продуктивном подходе.

Во время проектирования важно:

- постоянно отслеживать ход осуществления работ согласно составленному плану, в случае отступлений от него прибегать к мерам экстренного характера;

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

Средний объем описанных работ — порядка 10% от совокупного объема задачи.

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

Средний объем данных работ — около 10 % от совокупного объема.

6. Если клиенту подходит качество спроектированной программы, наступает черед внедрения продукта — подготовка к заключительному запуску в эксплуатацию. В случае, если программа многопользовательская, как правило, необходимо дополнительно выбрать, отстроить локальную сеть, определить серверы, установить дополнительные программные продукты. Достаточно много проблем может возникнуть в случае перехода со старого ПО (к примеру, работа с кадрами, калькуляции зарплаты, бухгалтерский учет и прочее), которое проектировалось различными работниками, приобреталось в разных компаниях (своеобразная лоскутная автоматизация), к обновленной системе интегрированного типа. При этом доведется откорректировать, перенести либо ввести огромные массивы важных данных: информацию о хранимой технике, оснащении, финансовые и бухгалтерские отчеты, многие прочие сведения. Данная стадия – наиболее монотонная и трудоемкая, в среднем занимает порядка 90% времени от всего проектирования проекта. Тогда как для систем автоматизации крупных организаций такой этап составляет несколько лет.

7. Определив, что разработанная система готова к функционированию, необходимо обучить работников предприятия клиента принципам работы с новоиспеченной системой, поскольку методических пособий по ней – нет, кроме того, в спроектированной системе, внедренной в определенной компании, присутствует огромное количество нюансов, тесно связанных с особенностями работы. Средние объемы трудозатрат на этап обучение — около 5 % от совокупного объема работ.

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 не предусматривает определенную модель ЖЦ или методы создания ПО. Все его регламенты имеют общий характер и нацелены на самые разные модели ЖЦ, технологии и методологии разработки. Этот стандарт описывает общую структуру процессов ЖЦ ПО, однако детали реализации либо выполнения действий и тех задач, которые входят в данные процессы, упускает.

Модель ЖЦ представляет собой структуру, устанавливающую последовательность реализации и взаимосвязи между разными процессами, задачами и действиями в течение всего ЖЦ. Кроме того, модель ЖЦ во многом зависит от особенностей ИС и тех условий, в которых происходит создание и функционирование системы. На сегодня самыми популярными стали две модели жизненного цикла:

- каскадная модель (с 1970 по 1985 гг.),

- спиральная модель (с 1986 по 1990 гг.).

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

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

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

Рисунок 2 - Каскадная схема разработки ПО

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

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

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

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

- лучше справляется с разными сложностями и оптимально проявляет себя в достаточно понятных, но трудно разрешимых проектах;

- отличается доступностью для понимания, ведь в этом случае преследуется лишь одна цель – осуществить все необходимые действия;

- выделяется удобством и простотой использования, так как разработка выполняется поэтапно;

- обладает простой структурой, которой может руководствоваться даже неопытный и недостаточно технически подготовленный персонал;

- характеризуется постоянством требований;

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

- лучше всего подходит в тех случаях, когда запросы к качеству преобладают над требованиями к графику выполнения и затратам по проекту;

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

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

- в случае правильного использования позволяет обнаруживать дефекты на ранних этапах (тогда их устранение не требует больших затрат);

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

- устанавливает процедуры, необходимые для контроля качества и позволяет все полученные сведения подвергнуть надлежащему обзору (данная процедура применяется разработчиками для проверки качества системы);

- отличается достаточно понятными и точно определенными стадиями.

2.2 Выбор технологии, языка и среды программирования

На исходном этапе проектирования удалось принять комплекс фундаментальных решений:

- определена архитектура ПО (в такой ситуации в рассматриваемом электронном пособии была применена однопользовательская архитектура, в соответствии с которой ПО предусмотрено для одного пользователя, который работает за ПК);

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

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

- определены среда и язык программирования. Так, для проектирования своего программного продукта мною был избран именно Delphi. Во время выбора рабочей среды я, прежде всего, опирался на такие параметры:

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

2. В соответствии со сложившимся мнением версия Object Pascal, которая применяется в среде Delphi, сопровождается специализированными классовыми библиотеками, адаптирующими ведение масштабных разработок, включая те, которые требуют применения информационных баз. Благодаря данным фактам Delphi является достаточно эффективной средой для проектирования программ Windows;

3. У компании-разработчика имеется лицензионная версия Delphi XE 8;

4. Применение хорошо известного языка.

1.2 Анализ и уточнение требований к программному продукту

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

Рисунок 1 - Классификация моделей разрабатываемого ПО используемых на этапе определения спецификаций

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

2.3 Анализ процесса обработки информации и выбор структур данных для ее хранения

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

- терминологичный словарь;

- спецификация функционирования программного продукта;

- определение операций, как правило, представляется в форме псевдокодов, алгоритмов, схематических изображений, лаконичного текстового описания;

- диаграммы переходов состояний, которые описывают поведение системы в процессе функционирования;

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

Следовательно, был выбран именно такой подход, поскольку это самое рациональное решение для нашего программного средства. Наше проектируемое ПО - не большое, а значит – для нас нет необходимости в использовании диаграмм, описанных в объектном подходе, к примеру: диаграммы вариантов применения; диаграммы классов. Тогда как третья модель, «Не зависящая от подхода к разработке», - общая, слабо раскрывает особенности программного продукта.

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

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

Рисунок 2- Диаграмма переходов состояний

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

Терминологический словарь:

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

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

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

Чтобы представить диаграммы информационных потоков, как правило, применяются такие типы нотаций:

- нотации Гейна – Сарсона;

- нотации Йордана.

Так, в своей диаграмме, представленной ниже, буду основываться на нотациях Гейна - Сарсона.

Рисунок 3 - Детализирующая диаграмма потоков данных

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

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

Ниже представлена спецификация процесса работы программы.

Рисунок 4 - Спецификация процесса работы программы

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

2.4 Выбор методов и разработка основных алгоритмов решения задач

Подход к разрешению задач.

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

Базовые алгоритмы:

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

3 Разработка программы

3.1 Разработка структурной схемы программного продукта

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

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

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

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

Определяем структуру управляющей программы.

Программа

Инициализировать глобальные значения

Вывести главную форму

Выполнять

Если нажата кнопка «Средние величины»

То Открыть форму «Средние велечины»

Если Построение вариационного ряда

То Открыть дочернюю форму «Построение вариационного ряда»

Если нажата кнопка «Пример»

То Открыть дочернюю форму «пример 1»

Если нажата кнопка «на главную»

То Открыть дочернюю форму «Пример»

До команда = выход

Конец.

Сумев все детализировать, приходим к построению структурной схемы нашего программного продукта.

Рисунок 5 - Структурная схема ПП

3.2 Проектирование интерфейса пользователя

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

Варианты интерфейса пользователя, стадии их проектирования

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

Разновидности интерфейсов пользователя

Рисунок 6 - Типы пользовательских интерфейсов

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

На сегодняшний день объектно-ориентированные интерфейсы представлены исключительно клиентским интерфейсом прямого манипулирования. Данный вариант интерфейса подразумевает следующее – взаимосвязь между пользователем и ПО реализуется через подбор, перемещение пиктограмм, которые соответствуют объектам материальной сферы. Чтобы спроектировать данные интерфейсы могут применяться объектно-ориентированные библиотеки, а также событийное программирование.

В свою очередь, процедурно-ориентированные интерфейсы представлены в таких разновидностях:

- графические интерфейсы пользователей (со свободной навигацией) – способны поддерживать концепцию интерактивной взаимосвязи с ПО, реализуя визуальное об­ратное взаимодействие с пользователем, возможность непосредственного управления объектами, данными на мониторе;

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

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

Базовые типы диалога:

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

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

Существуют следующие формы диалога:

- табличная – подразумевает, что пользователь будет выбирать ответ из тех альтернатив, которые предлагает программа;

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

- фразовая форма – подразумевает «коммуникацию» с пользователем посредством естественного языка либо его подмножества.

Проектирование диалогов

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

- детерминирование множества требуемых диалогов, их базовых сообщений, вероятных сценариев – разработка диалогов абстрактного типа;

- определение формы, типа диалогов, синтаксиса, а также семантики применяемых языков – разработка конкретных диалогов;

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

3.3 Построение графа - диалога

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

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

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

Главная форма

Рисунок 7 - Граф-диалог для электронного пособия

3.4 Разработка форм ввода/вывода информации

Опираясь на граф - диалог, разработанный в пункте 2.3 курсовой работы, предполагается, что необходимо разработать такие формы:

1) на основной форме необходимо подобрать нужный пункт для исследования;

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

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

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

Для оформления дизайна формы применялись графические файлы, имеющие расширение «.jpg». Они хранятся в текущем программном каталоге.

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

3.5 Выбор стратегии тестирования и разработка тестов

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

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

Необходимо тщательно протестировать все формы.

Кроме того, тестируется осуществление операции TButton1Click (определение функциональности кнопки «Построение вариационного ряда») на Form1 (форма 1). По факту проверки должна открываться Form2 (форма 2).

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

Тестируем функцию «возврата» из формы 2 (Form2) в форму 1 (Form1): выполняем процедуру TBitBtn1Click (нажимаем на кнопку «На главную» на форме 3 (Form3)). Процедура работает верно, если форма 2 (Form2) закрывается, а на экране остается только форма 1 (Form1). Аналогично тестируем функцию «На главную» из формы 4 (Form4) в форму 1 (Form1).

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

3.6 Руководство пользователя

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

Описание установки:

Копирование данной программы в любой каталог жесткого диска и затем уже ее запуск из корневой папки.

Описание запуска:

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

Инструкции по работе:

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

Рисунок 8 – Главное окно программы

При нажатии на «средние величины» изложен материал (Рис. 9).

Рисунок 9 - Материал

При нажатии на кнопку «Построение вариационного ряда» отображается форма с теоретическими сведениями (Рис. 10).

Рисунок 10 – Теоретические данные

После нажатия на кнопку «Пример» появляется форма, где отображается пример (Рис. 11).

Рисунок 11 – Описание примера

После изучения материала пользователь либо переходит на главную форму, либо продолжает изучение (рис.12).

Рисунок 12 – Описание примера

Последний этап изучения представлен на рис.13

Рисунок 13 – Описание примера

Заключение

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

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

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

1. Jesse R.H., Delphi (язык программирования) [Текст] / R.H. Jesse - М.: VSD, 2012. – 114 с.
2. Акимов А. Г. Автоматизированная система электронного контроля // Молодой ученый. - 2013. - №11. - С. 39-40.
3. Архангельский А.Н., Delphi 2006. Справочное пособие: Язык Delphi, классы, функции Win32 и NET [Текст] / А.Н. Архангельский - М.: Бином. Лаборатория знаний, 2015. 1152 с.
4. Архангельский А.Н., Приемы программирования в Delphi на основе VCL [Текст] / А.Н. Архангельский - М.:Бином. Лаборатория знаний, 2013. - 944 с.
5. Баженова И.Ю., Основы проектирования приложений баз данных [Текст] / И.Ю. Баженова - М.:Интернет-Университет Информационных Технологий (ИНТУИТ), 2016. – 261 с.
6. Виснадул Б.Д., Технология разработки программного обеспечения [Текст] / Б.Д. Виснадул - М.:Форум, 2016. – 400 с.
7. Голицына О.Л., Основы проектирования баз данных. [Текст]: Учебное пособие /О.Л. Голицына - М.: Форум, 2016. – 416 с.
8. Грекул В.И., Управление внедрением информационных систем [Текст] / В.И. Грекул - М.: Интернет-Университет Информационных Технологий (ИНТУИТ), 2014. – 224 с.
9. Григорьев М.В. Проектирование информационных систем: учебное пособие для вузов [Текст] / М.В. Григорьев, И.И. Григорьева. - М.: Издательство Юрайт, 2016. - 318 с.
10. Джесси Р., Проектирование баз данных [Текст] / Р. Джесси - М.: VSD, 2013. – 100 с.
11. Заботина Н., Проектирование информационных систем [Текст] / Н. Заботина - М.: Инфра-М, 2016. – 331 с.
12. Илюшечкин В.М., Основы использования и проектирования баз данных. Учебник для академического бакалавриата [Текст] / В.М. Илюшечкин - М.: Юрайт, 2015. – 213 с.
13. Информационные системы в экономике: учебник для академического бакалавриата [Текст] / В.Н. Волкова, В.Н. Юрьев, С.В. Широкова, А.В. Логинова; под ред. В.Н. Волковой, В.Н. Юрьева. - М.: Издательство Юрайт, 2016. - 402 с.
14. Информационные системы и технологии в экономике и управлении: учебник для академического бакалавриата [Текст] / В.В. Трофимов [и др.]; под ред. В.В. Трофимова. - 4-е изд., перераб. и доп. - М.: Издательство Юрайт, 2016. - 542 с.
15. Исаев Г.Н., Проектирование информационных систем [Текст]: учебное пособие / Г.Н. Исаев - М.: Омега-Л, 2013. – 424 с.
16. Карминский А.М., Методология создания информационных систем [Текст] / А.М. Карминский - М.: Инфра-М, 2016. – 320 с.
17. Коберн А., Быстрая разработка программного обеспечения [Текст] / А. Коберн - М.: Лори, 2014. – 314 с.
18. Коваленко В.И., Проектирование информационных систем [Текст] / В.И. Коваленко - М.: Форум, 2015. – 320 с.
19. Кон М., Scrum: гибкая разработка ПО. Описание процесса успешной гибкой разработки программного обеспечения [Текст] / М. Кон - М.: Вильямс Диалектика, 2016. – 576 с.
20. Кон М., Пользовательские истории: гибкая разработка программного обеспечения [Текст] / М. Кон - М.: Вильямс Диалектика, 2012. – 256 с.

Приложение А

Фрагмент программного кода

unit Primer1;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, StdCtrls, ExtCtrls;

type

TForm3 = class(TForm)

GroupBox1: TGroupBox;

Label1: TLabel;

Memo1: TMemo;

Label2: TLabel;

Label3: TLabel;

Memo2: TMemo;

Image1: TImage;

Button1: TButton;

Button2: TButton;

procedure Button2Click(Sender: TObject);

procedure FormClose(Sender: TObject; var Action: TCloseAction);

procedure Button1Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form3: TForm3;

implementation

uses Main, Primer1_1;

{$R *.dfm}

procedure TForm3.Button2Click(Sender: TObject);

begin

Form3.Close;

Form1.Show;

end;

procedure TForm3.FormClose(Sender: TObject; var Action: TCloseAction);

begin

Form1.Show;

end;

procedure TForm3.Button1Click(Sender: TObject);

begin

Form3.Close;

Form4.Show;

end;

end.