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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 22.04.2023

Просмотров: 331

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Введение

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

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

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

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

На сегодняшний день, автоматизация различных процессов затронула все сферы человеческой деятельности. Проставленная курсовая работа направлена на создание электронного пособия «Построение и исследование вариационных рядов с помощью пакета анализа 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 % от совокупного объема работ.