Оценка принципов разработки ПО

КУРСОВАЯ РАБОТА

Оценка принципов разработки ПО

Введение

программный алгоритм макетирование

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

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

Современный персональный компьютер теперь имеет производительность большой ЭВМ 80-х годов. Сняты практически все аппаратные ограничения на решение задач. Оставшиеся ограничения приходятся на долю ПО.

Чрезвычайно актуальными стали следующие проблемы:

аппаратная сложность опережает наше умение строить ПО, использующее потенциальные возможности аппаратуры;

наше умение строить новые программы отстает от требований к новым программам;

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

Ключом к решению этих проблем является грамотная организация процесса создания ПО, реализация технологических принципов промышленного конструирования программных систем (ПС).

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

Компьютерные науки вообще и программная инженерия в частности - очень популярные и стремительно развивающиеся области знаний. Обоснование простое: человеческое общество XXI века - информационное общество. Об этом говорят цифры: в ведущих странах занятость населения в информационной сфере составляет 60%, а в сфере материального производства - 40%. Именно поэтому специальности направления «Компьютерные науки и информационные технологии» гарантируют приобретение наиболее престижных, дефицитных и высокооплачиваемых профессий. Так считают во всех развитых странах мира. Ведь не зря утверждают: «Кто владеет информацией - тот владеет миром!»

Поэтому понятно то пристальное внимание, которое уделяет компьютерному образованию мировое сообщество, понятно стремление унифицировать и упорядочить знания, необходимые специалисту этого направления. Одними из результатов такой работы являются международный стандарт по компьютерному образованию Computing Curricula 2001 - Computer Science и международный стандарт по программной инженерии IEEE/ACM Software Engineering Body of Knowledge SWEBOK 2001.

 

Классический жизненный цикл

 

Старейшей парадигмой процесса разработки ПО является классический жизненный цикл (автор Уинстон Ройс, 1970) [1].

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

Охарактеризуем содержание основных этапов.

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

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

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

Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

 

Рис. 1. Классический жизненный цикл разработки ПО

 

Проектирование состоит в создании представлений:

архитектуры ПО;

модульной структуры ПО;

алгоритмической структуры ПО;

структуры данных;

входного и выходного интерфейса (входных и выходных форм данных).

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

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

Тестирование - выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение - это внесение изменений в эксплуатируемое ПО. Цели изменений:

исправление ошибок;

адаптация к изменениям внешней для ПО среды;

усовершенствование ПО по требованиям заказчика.

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

Как и любая инженерная схема, классический жизненный цикл имеет достоинства и недостатки.

Достоинства классического жизненного цикла: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования.

Недостатки классического жизненного цикла:

1) реальные проекты часто требуют отклонения от стандартной последовательности шагов;

2) цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);

3) результаты проекта доступны заказчику только в конце работы.

Макетирование

 

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

Основная цель макетирования - снять неопределенности в требованиях заказчика.

Макетирование (прототипирование) - это процесс создания модели (макета) требуемого программного продукта.

Модель может принимать одну из трех форм:

) бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог);

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

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

Как показано на рис. 2, макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик.

 

Рис. 2. Макетирование

 

Последовательность действий при макетировании представлена на рис. 3. Макетирование начинается со сбора и уточнения требований к создаваемому ПО Разработчик и заказчик встречаются и определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить.

Затем выполняется быстрое проектирование. В нем внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю.

Быстрое проектирование приводит к построению макета.

Макет оценивается заказчиком и используется для уточнения требований к ПО.

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

Достоинство макетирования: обеспечивает определение полных требований к ПО.

Недостатки макетирования:

- заказчик может принять макет за продукт;

разработчик может принять макет за продукт.

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

 

Рис. 3. Последовательность действий при макетировании

 

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

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

Программная инженерия

 

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

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

 

Средства разработки ПО

 

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

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

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

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

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

Один из самых важных вопросов, который нужно задать о новой системе, или даже о старой системе, с которой пришлось столкнуться, - какого вида эта система? Никто не станет даже пытаться расположить колонию хиппи вокруг плаца или военный лагерь в виде хаотически расположенных вигвамов, соединенных тропинками! Любая система может обладать более чем одним признаком из перечисленных ниже, хотя некоторые взаимно исключают друг друга. Эти, вероятно полезные, признаки - грубые категории, встречающиеся на практике. Они не выведены из какой-то лежащей в основе теории. Существуют следующие типы систем:

Монолитная;

Клиент-Сервер;

Интерактивная;

Пакетная;

Управляемая событиями;

Управляемая данными;

Оппортунистическая;

Штурманская (Dead reckoning);

Сходящаяся в одну точку (Convergent);

На гребне волны (Wavefront);

Ретроспективная (Retrospective).

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

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

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

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

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

CASE -системы

В последние годы на мировом рынке программных продуктов появилось много программных средств, называемых CASE-системами или CASE-средствами. Слово CASE представляет собой сокращение от Computer Aided Software Engineering. В русскоязычной литературе нет соответствующего общепринятого термина. С нашей точки зрения есть два наиболее соответствующих оригиналу и назначению CASE-систем перевода: ``Программная инженерия, поддерживаемая компьютером'' и менее буквальный, но более отвечающий сути перевод ``Средства разработки программ с помощью компьютера''. Теоретическое осмысливание этого явления и его места в технологии программирования находится на очень ранних стадиях.

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

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

Приведенная технология базируется в основном на стандартах IEEE [10,11] (IEEE - Institute of Electrical and Electronics Engineers - Институт инженеров по электротехнике и электронике). Термин «внедрение» используется в широком смысле и включает все действия от оценки первоначальных потребностей до полномасштабного использования CASE-средств в различных подразделениях организации-пользователя. Процесс внедрения CASE-средств состоит из следующих этапов:

    определение потребностей в CASE-средствах;

    оценка и выбор CASE-средств;

    выполнение пилотного проекта;

    практическое внедрение CASE-средств.

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

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

Приведем краткий обзор некоторых CASE-средств.

- Power Designer компании Sybase. В состав Power Designer входят следующие модули:Analyst - средство для функционального моделирования, поддерживает нотацию Йордона - ДеМарко, Гейна - Сарсона и несколько других.Analyst - инструмент для построения модели «сущность-связь» и автоматической генерации на ее основе реляционной структуры.Modeler - инструмент для автоматической генерации прототипов программ обработки данных на основе реляционных моделей, построенных в Data Analyst.

- Silverrun компании Silverrun Technologies Ltd. CASE-система Silverrun состоит из следующих инструментов:- построение DFD-диаграмм. Поддерживает нотации Йордона-ДеМарко, Гейна - Сарсона, Уорда-Меллора и многие другие. Данный инструмент позволяет автоматически проверить целостность построенной модели, причем список критериев проверки определяется пользователем (например: отсутствие имен у элементов модели, потоки данных типа «хранилище - хранилище» или «внешняя сущность - внешняя сущность» и т.д.)- построение диаграмм «сущность-связь». Поддерживаются не только бинарные связи, но и связи более высоких порядков, имеется возможность определения атрибутов у связей. Построенные ER-модели с помощью внешней утилиты могут быть сконвертированы в реляционный структуры (в той версии, с которой я работал, при этом, к сожалению, терялись атрибуты связей).- инструмент реляционного моделирования, позволяет генерировать SQL-скрипты для создания таблиц и индексов примерно для 25 целевых СУБД.

- BPWin и ERWin компании LogicWorks. LogickWorks выпускает два взаимнодополняющих инструмента проектирования информационных систем:- функциональное моделирование на основе методологии IDEF0. Допускается также использовние нотации IDEF3 и DFD в нотации Йордона - ДеМарко. Имеется возможность экспорта построенных моделей в системы функционально-стоимостного анализа (ABC - Activity Based Costing) и информационного моделирования ERWin.- средство информационного моделирования, используется нотация IDEF1X. Поддерживаются свыше 20 целевых СУБД, имеется возможность генерации прототипов прикладных программ для Visual Basic, Delphi и т.д.

- Designer/2000 компании Oracle. Данный продукт компании Oracle, возможно, наиболее полно поддерживает все этапы создания приложений обработки данных. Однако, следует оговориться, что, в отличие от других средств, он поддерживает практически одну целевую СУБД - Oracle Server (имеется еще возможность генерации скриптов на ANSI SQL). То же самое касается и средств создания пользовательсокго интерфейса. Хотя возможна генерация прототипов программ для языков Visual Basic, C, Java, полностью все возможности Designer/2000 реализуются только при использовании его вместе со средством разработки Oracle Developer/2000. В состав Oracle Designer/2000 включены модули: инструментарий анализа предметной области, генераторы структур, инструментарий проектирования приложения, генераторы данных и кода.

- Rational Rose. Это CASE-система для визуального моделирования объектно-ориентированных программных продуктов. Визуальное моделирование - процесс графического описания разрабатываемого программного обеспечения. В его составе выделяют шесть элементов: строку инструментов, панель «инструменты диаграммы», окно диаграммы, браузер, окно спецификации, окно документации. В процессе генерации Rational Rose отображает логическое описание класса в каркас программного кода - в коде появляются языковые описания имени класса, свойств класса и заголовки методов. Кроме того, для описания тела каждого метода формируется программная заготовка. Появляются и программные связи классов. Автоматическая генерация была задана настройкой среды - свойствами генерации. Система обеспечивает настройку параметров генерации для уровней класса, роли, свойства (атрибута) и проекта в целом.

 

Заключение

 

Современная программная инженерия (Software Engineering) - молодая и быстро развивающаяся область знаний и практики. Она ориентирована на комплексное решение задач, связанных с разработкой особой разновидности сложных систем - программных систем.

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

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

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

1. Уважительные отношения с клиентами и пользователями программ, выполнение взятых на себя обязательств качественно и в срок.

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

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

.   Разработка должна быть дружественной пользователю. Она должна быть для пользователя, а не пользователь для нее. Из этого следует несколько выводов:

    Программа не должна по возможности задавать вопросы пользователю, наоборот она должна отвечать на них.

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

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

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

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

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

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

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

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

Базис современной программной инженерии образуют следующие составляющие:

процессы конструирования ПО;

метрический аппарат, обеспечивающий измерения процессов и продуктов;

аппарат формирования исходных требований к разработкам;

аппарат анализа и проектирования ПО;

аппарат визуального моделирования ПО;

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

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

Хотелось бы обратить внимание на новейшие постобъектные методологии - аспектно-ориентированное и многомерное проектирование и программирование. Они представляют собой новую высоту в стремительном полете в компьютерный космос. Но это - тема другой отдельной работы.

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

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

 

Список литературы

 

1. Технологии разработки программного обеспечения. 2002. Орлов С А

2. Материалы сайта www.intel.com/software/products/

3. Приемы объектно-ориентированного проектирования. Паттерны проектирования. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Д. 2003.

.   Экстремальное программирование. Бек К. 2004.

.   Язык программирования C++. Страуструп Б. 1996.

.   Рефакторинг: улучшение существующего кода. Фаулер М., Бек К., Брант Д., Робертс Д., Апдайк У. 1999.

.   Автоматизированные библиотечно-информационные системы России: состояние, выбор, внедрение, развитие. Шрайберг Я.Л., Воройский Ф.С. - М.: Либерея, 1996

.   Проектирование баз данных информационных систем. 2-ое изд. - М.: Финансы и статистика, Бойко В.В., Савинков В.М. 1989.

.   Введение в АСУ. Глушков В.М., 1974.

10. IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of CASE Tools.

.   IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools.

12. Один из подходов к выбору средств проектирования баз данных и приложений. Вендров А.М. 1995.

.   Бизнес-реинжиниринг и технологии системного проектирования. Зиндер Е.З. 1996

.   CASE. Структурный системный анализ (автоматизация и применение). Калянов Г.Н. 1996.

.   Методология структурного анализа и проектирования. Марка Д.А., МакГоуэн К. 1993.

КУРСОВАЯ РАБОТА

Оценка принципов разработки ПО

Введение

программный алгоритм макетирование

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

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

Современный персональный компьютер теперь имеет производительность большой ЭВМ 80-х годов. Сняты практически все аппаратные ограничения на решение задач. Оставшиеся ограничения приходятся на долю ПО.

Чрезвычайно актуальными стали следующие проблемы:

аппаратная сложность опережает наше умение строить ПО, использующее потенциальные возможности аппаратуры;

наше умение строить новые программы отстает от требований к новым программам;

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

Ключом к решению этих проблем является грамотная организация процесса создания ПО, реализация технологических принципов промышленного конструирования программных систем (ПС).

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

Компьютерные науки вообще и программная инженерия в частности - очень популярные и стремительно развивающиеся области знаний. Обоснование простое: человеческое общество XXI века - информационное общество. Об этом говорят цифры: в ведущих странах занятость населения в информационной сфере составляет 60%, а в сфере материального производства - 40%. Именно поэтому специальности направления «Компьютерные науки и информационные технологии» гарантируют приобретение наиболее престижных, дефицитных и высокооплачиваемых профессий. Так считают во всех развитых странах мира. Ведь не зря утверждают: «Кто владеет информацией - тот владеет миром!»

Поэтому понятно то пристальное внимание, которое уделяет компьютерному образованию мировое сообщество, понятно стремление унифицировать и упорядочить знания, необходимые специалисту этого направления. Одними из результатов такой работы являются международный стандарт по компьютерному образованию Computing Curricula 2001 - Computer Science и международный стандарт по программной инженерии IEEE/ACM Software Engineering Body of Knowledge SWEBOK 2001.