Проблемы при разработке программ

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

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

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

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

• необходимость интеграции существующих и вновь разрабатываемых приложений;

• функционирование в неоднородной среде на нескольких аппаратных платформах;

Проблемы при разработке KPI в Digital!

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

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

Как отмечает Фредерик Брукс, руководитель проекта разработки операционной системы OS/360, самым существенным и неотъемлемым свойством программных систем является их сложность. Благодаря уникальности и несхожести своих составных частей программные системы принципиально отличаются от технических систем (например, компьютеров), в которых преобладают повторяющиеся элементы.

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

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

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

Уничтожаю C++

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

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Источник: studopedia.ru

Лекции (часть 1) / 1. WCF / Проблемы разработки ПО

ПРОБЛЕМЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Денисов В.В., Хирьянов А.А. Филиал ГОУ ВПО «Московский государственный университет приборостроения и информатики» в г.Ставрополе Хорошо известно при разработке программного обеспечения часто срываются графики работ и наблюдается превышение установленного бюджета.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

решает данную проблему. От части тут может помочь подробнейшим образом составленная инструкция пользователя и служба поддержки. Список использованной литературы: 1. BPwin и ERwin. CASE-средства разработки информационных систем. Маклаков С.В.

М: Диалог-МИФИ 2001. 2. Быстрая и качественная разработка программного обеспечения Кармайкл Э., Хейвуд Д. — М.: Издательский дом Вильямс, 2003.

Источник: studfile.net

VI Международная студенческая научная конференция Студенческий научный форум — 2014

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

Для адекватного анализа проблем визуализации данных в процессе разработки ПС рассмотрим наиболее известные и активно используемые в настоящее время процессы. Одной из таких моделей можно по праву считать водопадную (или каскадную) модель, предложенную в 1970 году Уинстоном Ройсом, американским ученым, директором технического цента Lockheed Software, расположенном в штате Техас. Основная мысль модели довольно проста: весь процесс разделен на определенные, четко ограниченные по смыслу и деятельности, фазы, которые выполняются в строгой последовательности. Главным положительным моментом использования каскадной модели можно считать уменьшение количества долгоживущих ошибок.

Другой довольно известной моделью считается модель разработки– Rational Unified Process (RUP),созданная в 1990 х годах. Основным отличием данной модели является обязательное формирование прецедентов использования ПС для описания требований к разрабатываемой ПС. Каждый прецедент (вариант) использования – это описание сценария взаимодействия пользователя с системой, полностью выполняющего конкретную пользовательскую задачу. И наиболее эффективным способом документирования таких сценариев является графическая визуализация прецедентов и связей между ними с помощью различных case-средств.

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

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

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

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

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

Рассмотренные модели процессов разработки ПС можно отнести к классическим, в то время как в течение 1990-х годов становилось все больше разработчиков ПО, которые пытались найти альтернативу традиционным моделям. К 2000 году было предложено целое множество так называемых легковесных процессов. И в 2001 году группой создателей и экспертов по различным легковесным процессам был проведен семинар, на котором было определено новое понятие для легковесных процессов – гибкая разработка, а так же сформулированы основные принципы гибкой разработки программного обеспечения, так называемый Agile Manifesto.

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

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

Лекции (часть 1) / 1. WCF / Проблемы разработки ПО

VI Международная студенческая научная конференция Студенческий научный форум — 2014

Напиши программу которая в последовательности натуральных чисел определяет количество чисел кратных

Составьте блок схему и программу вычисления значения функции вариант 3

Как записать музыку на сд диск в формате сд программа

Какая нужна программа на телефон чтобы скачивать музыку на телефон

Если не хватает места на диске с для установки программы

Задачи по ознакомлению с формой и геометрическими фигурами в программе радуга

Как расширение имени файла связано с форматом файла и программой обработки

Что программа 12111 переводит число 50 в число 20 определите значение b