Курсовая работа
Виды программного обеспечения. Общие требования к программным системам
Киев 2009
Содержание
1. Цели и задачи программной инженерии. Понятиепрограммного обеспечения
2. Шесть принципов эффективного использования программногообеспечения
3. Виды программного обеспечения:общесистемное, сетевое и прикладное
4. Типы программного обеспечения
5. Общие требования к программным системам
6. Принципы построения программногообеспечения
1. Цели и задачи программной инженерии. Понятиепрограммного обеспечения
Последнее десятилетие в областипрограммирования характеризуется становлением новой дисциплины — программнойинженерии (Software Engineering), что вызвановозросшими потребностями:
в создании различного видакомпьютерных систем;
необходимостью сокращения сроковразработки;
обеспечения качества ПО;
оптимизации используемыхресурсов (финансовых и трудовых).
В результате разработку ПО сталирассматривать как определенный вид человеческой деятельности, к которомуприменимы инженерные методы выполнения и организации работ, методы менеджментаи управления, экономические методы оценки эффективности и стоимости работ. Впоследние годы наблюдается повышенный интерес к вопросам формализации методованализа и спецификации требований к программному обеспечению. Необходимостьэтого обусловлена ростом требований к качеству программного обеспечения,изменениями в методологии его проектирования и разработки, в современнойорганизации проектных работ.
Программная инженерия — этонаучная дисциплина, которая изучает методы, способы и технологии разработки ПО,в результате которого реализуются возможности ЭВМ по выполнению различныхдействий, связанных с переработкой информации.
Программная инженерия — строгоеиспользование инженерных, научных и математических принципов, методов иинструментария для экономичного создания качественного программного обеспечения.
Программное обеспечение (ПО) — этосовокупность машинных программ, соответствующей качественной документации, базданных, а также технологических процедур по эксплуатации ПО.
Основа программной инженерии — стандарты,методы, методологии проектирования и управления процессом разработки ПО, атакже инструментально-технологические средства поддержки этого процесса (CASE — технологии), к которым относятся системы программирования и автоматизацииразных этапов проектирования и разработки ПО.
Верификация — это установлениесоответствия ПО его спецификации.
Подтверждение — установлениепригодности или соответствия ПО его назначению.
Структура целей программнойинженерииКачество ПО Эффективность процесса разработки ПО
Человеческие факторы Легкость использования Планируемость Удовлетворение потребностей пользователя Организованность команды разработчиков Следование модифицированному правилу Контролируемость хода работ
Управление ресурсами Эффективность Оценка затрат (стоимости проекта) Тестируемость Анализ эффективности Контроль сроков и бюджета
Программотехника Специфицированность Анализ требований к ПО Правильность Проектирование Адаптируемость Программирование модифицируемость Тестирование и контроль переносимость Верификация и подтверждение работоспособность в других системах Внедряемость и сопровождаемость Управляемость конфигурацией
2. Шесть принципов эффективного использованияпрограммного обеспечения
90-е годы — время интенсивногоразвития программной инженерии и новых информационных технологий. В то же времяпри внедрении и эксплуатации программных систем большинство компанийстолкнулись с еще более серьезными проблемами, чем раньше. Многие организацииобременены внедренными ранее дорогостоящими и неоправданно сложными системами. Удругих бизнес-подразделения и отдел информационных технологий не могут (или нехотят) найти общий язык. Третьи не могут понять, во что нужно вложить деньги,чтобы получить жизненно необходимые функциональные возможности.
Однако существует ряд компаний,которые смогли по-настоящему овладеть информационными технологиями и получают отних реальную пользу, т.к управляют своими программными системами примерно также, как и другими важными функциями и процессами в компании:
обеспечивая административнуюподдержку на самом высоком уровне,
прививая специалистам поинформационным технологиям знание бизнес-терминологии
ориентируя усилия сотрудниковтехнического отдела на достижение конкретных бизнес-целей.
В основе успеха внедрения ПОлежат шесть перечисленных ниже принципов:
Развитие в области внедренияпрограммных систем и информационных технологий обуславливается потребностямиосновной деятельности компании, а не технологическими новшествами.
Решения о финансировании вобласти программных систем и информационных технологий принимаются так же, каки во всех остальных сферах — исходя из соображений финансовой выгоды.
Программная система имеетпростую и гибкую структуру.
Любые разработки начинаютприносить пользу бизнесу практически с момента внедрения.
Проводятся планомерные ипостоянные улучшения производительности программной системы.
Отдел информационных технологийхорошо разбирается в бизнесе, а бизнес-подразделения — в программных системах иинформационных технологиях.
Очень важно применять все этипринципы одновременно: ни один из них не принесет успеха без пяти остальных.
Таблица 1. Контрольный списокдля реализации шести принциповРазвитие в области программного обеспечения обуславливается потребностями основной деятельности компании, а не технологическими новшествами Решения о финансировании в области программного обеспечения принимаются так же, как и во всех остальных сферах — исходя из соображений финансовой выгоды Программная система имеет простую и гибкую структуру
Управляйте программным обеспечением так же, как остальными бизнес-функциями компании.
Непосредственно свяжите ПО с важными для бизнеса стратегиями, основными стоимостными факторами и повседневными деловыми процессами.
Назначьте линейных руководителей ответственными за новые приложения:
Определение основных возможностей
Выбор проектов для внедрения
Руководство внедрением
Ответственность за результаты
Использование поддержки отдела информационных технологий
Поручите отделу информационных технологий создание и поддержку эффективной инфраструктуры для приложений.
Не относитесь к программной системе как к «черному ящику» — обязуйте технических специалистов применять деловую лексику.
Подходите к решениям о новых крупных инвестициях в ПО, как к остальным финансовым решениям:
Свяжите инвестиции с реальными задачами совершенствования бизнеса и производительности
Используйте при принятии решений анализ затрат и преимуществ, который обеспечит упорядоченность и систематичность.
Не используйте в качестве единственного критерия при разработке ПО снижение стоимости:
Распространите принятые в бизнесе подходы к менее определенным, менее поддающимся количественному учету и более стратегически важным решениям
Выходите за рамки отдельных проектов, учитывая при разработке приложений и инфраструктуры долговременные перспективы.
Оценивайте текущие расходы на программное обеспечение исходя из поставленных целей в области стоимости и обслуживания.
Избегайте крупных единовременных затрат на аппаратно-программное обеспечение; стремитесь к постоянному обновлению.
Устанавливайте стандарты архитектуры ПО и глубоко анализируйте плюсы и минусы использования иных стандартов.
Упрощайте систему:
Уменьшайте число используемых технологий и платформ.
Применяйте для приложений модульную архитектуру.
Используйте межплатформенные решения для повышения гибкости и простоты внедрения приложений и инфраструктуры.
Консервативно подходите к выбору технологий, исключение могут составлять только нововведения, способные принести огромные прибыли
Учитывайте коммерческие аспекты, такие как отраслевые стандарты и вероятность получения в будущем технической поддержки.
Условием выбора новейших технологий должна быть значительная бизнес-отдача.
Подходите к конфигурированию баз данных и приложений стратегически, стараясь обеспечить успешно работающую оптимальную структуру. Любые разработки начинают приносить пользу бизнесу практически с момента внедрения Проводятся планомерные и постоянные улучшения производительности системы Отдел информационных технологий хорошо разбирается в бизнесе, а бизнес-подразделения — в информационных технологиях
Осуществляйте постепенный переход, а не глобальную замену:
Разработку новых систем разбивайте на этапы.
Устанавливайте промежуточные цели (с интервалом, как правило, не больше 6 месяцев), которые обеспечивают реальное продвижение в бизнесе
Используйте по возможности стандартное проверенное ПО; сведите его модификацию к минимуму.
Сконцентрируйте усилия на тех 20 процентах функций, которые отвечают за 80 процентов деятельности компании и быстро добейтесь их полной реализации.
Если возможно, реализуйте тестовую модель проекта в небольших масштабах.
Для дисциплинирования сотрудников технического отдела и ускорения процесса внедрения обращайтесь к сторонним фирмам.
Постоянно сравнивайте развитие крупных проектов с эталонами и с запланированными результатами; при необходимости проводите коррекцию.
Регулярно проводите ревизию завершенных проектов и переоценку этапов разработки.
Относитесь к управлению эксплуатацией ПО, как к управлению заводом: определите стандарты производительности и конкретные задачи улучшения управления стоимостью, качества обслуживания и времени отклика.
Реорганизуйте работу ПО для получения максимально экономичной модели:
Централизуйте основные функции (такие как работа справочной службы, информационного центра и управление сетью).
Стандартизируйте конфигурацию настольных компьютеров и ограничьте возможность ее изменения.
Консолидируйте закупки в области программного обеспечения.
Строго контролируйте эффективность эксплуатации системы и передавайте обслуживание неэффективных функций сторонним организациям.
Разработайте эталонные тесты, чтобы можно было ставить конкретные цели в области поддержки и стоимости эксплуатации системы
Правильно распределите обязанности:
Генеральный директор активно участвует в принятии решений в области ПО, определяя верное направление.
Менеджер по информатизации, в первую очередь, является бизнес-руководителем и входит в состав высшего руководства
Обеспечьте руководство со стороны представителей бизнес-подразделений и их осведомленность в области ПО
Обучите специалистов по программному обеспечению основам бизнеса.
Выработайте совместную процедуру принятия обоснованных решений руководителями бизнес-отделов и руководителем информационно-технического отдела:
Стимулируйте исследование деловых возможностей.
Требуйте рассмотрения разных вариантов и всесторонних обсуждений при решении сложных вопросов.
Создайте условия для высокопроизводительной работы отдела информационных технологий:
Простая организационная структура.
Мало должностей.
Высокая квалификация специалистов.
Материальное стимулирование повышения производительности.
Развитие в области внедренияпрограммных систем и информационных технологий обуславливается потребностямиосновной деятельности компании, а не технологическими новшествами
В компаниях с более высокойпроизводительностью за программную систему отвечают руководителибизнес-отделов, а не технические руководители. Это означает, что руководителибизнеса отвечают за выбор, внедрение и оценку преимуществ новых приложений.
Отдел информационных технологийсотрудничает с основными отделами в разработке приложений и выступает в ролихозяина технологической инфраструктуры. Но если что-то не ладится, тоответственность ложится на бизнес-менеджера.
При таком подходе руководителиплатят за то, что им по-настоящему нужно, потому что это напрямую связано с ихбюджетом и кредитоспособностью. В результате, они значительно больше вниманияуделяют стоимости и гораздо менее склонны списывать свои неудачи за счетинформационных технологий. Такая ответственность способствует более четкомупониманию стоящих перед ними проблем и путей их решения. Кроме того,руководители начинают быстрее принимать решения, устанавливая более короткиесроки выполнения работ и разбивая процесс внедрения на этапы, чтобы как можноскорее получить конкретные результаты.
Назначение руководителейлинейных подразделений ответственными за программную систему означает, чтоотдел информационных технологий поддерживает новые разработки и отвечает заорганизацию экономичной инфраструктуры. Кроме того, появляется связь междурешениями, принятыми руководителями отдельных направлений, что обеспечиваетсогласованность отдельных решений.
Высшее руководство, со своейстороны, должно обладать достаточными знаниями, чтобы поддерживатьконструктивные диалоги со своим отделом по информатизации и задавать такие же прозорливыевопросы, как и в отношении других функций. Это означает, что сотрудникиинформационно-технического отдела должны использовать бизнес-терминологию, а нетехнический жаргон. Это также означает, что руководители других подразделенийдолжны владеть основами информационных технологий и не бояться задаватьразнообразные вопросы. Таким образом, руководители информационно-техническихгрупп и других отделов смогут оценивать эффективность друг друга и совместнопроводить необходимую корректировку в случае неудач.
Решения о финансировании вобласти программных систем и информационных технологий принимаются так же, каки во всех остальных сферах — исходя из соображений финансовой выгоды
В большинстве организацийразвитие информационных технологий определяется прошлогодними расходами ибюджетом текущего года. Некоторые компании применяют принцип финансирования отдостигнутого и сталкиваются с тем, что каждый проект оказывается важным, азатраты возрастают сверх меры. Другие компании с трудом могут сбалансироватьпотребности разных подразделений. Третьи нанимают специалиста по технологиям,ответственного за принятие решений по совершенствованию программной системы,только затем, чтобы уволить его и нанять другого с еще более высоким окладом втом случае, если инвестиции себя не оправдают. В таких компаниях недопонимаютзначение информационных технологий для развития бизнеса и основной упор делаютна возможности сокращения расходов.
Опросы показывают, что компании,успешно использующие информационные технологии, принимают решения о новыхкрупных инвестициях в информационные технологии так же, как и любые другиефинансовые решения — сочетая качественную оценку с точки зрения бизнеса сострогим анализом затрат и выгод, что обеспечивает упорядоченность исистематичность. Особенно важно то, что решения об инвестициях принимаются наоснове полноценного бизнес-анализа, что позволяет понять и оценить менееопределенные, меньше поддающиеся количественным оценкам и более стратегическиважные аспекты решений по инвестированию информационных технологий.
Если компании не удаетсявыработать тщательно продуманную систему оценки отдачи вложений, то, какправило, решения по развитию информационных технологий принимаются, исходя изпростого стремления снизить расходы.
Один из способов количественнойоценки крайне неопределенных, но стратегически многообещающих проектовзаключается в применении научно-исследовательского подхода и тестированиисистем в небольших масштабах. Для многих отделов информационных технологийтакой вариант окажется неприемлемым, потому что часть проектов неизбежнопровалится.
Кроме того, успешные компании,решая вопросы приобретения приложений и развития инфраструктуры, думают нетолько об отдельных проектах, но и учитывают долгосрочные перспективы. В такихкомпаниях при стратегическом планировании информационные технологии обязательнопринимаются во внимание, и отдел информатизации следит не только за текущимсостоянием реализуемых проектов, но и за стратегическими планами компании наближайшие три-пять лет. Оценивается, насколько с учетом поставленных в областиобслуживания и расходов целей, оправданы затраты на эксплуатацию информационнойсистемы. Информационный центр, сети и инфраструктура рассматриваются какпроизводство, к которому постоянно предъявляются требования повышенияпроизводительности.
И, наконец, компании, успешнорешающие связанные с информационными технологиями проблемы, избегают крупныхединовременных капиталовложений, предпочитая постоянно обновлять свои системы иежегодно инвестировать их совершенствование на регулярной основе. Это позволяетсохранять высокий технический уровень и надежно защищает от паденияэффективности работы, связанной с несбалансированной политикой.
Руководство компании должнопонимать, что решения в области информационных технологий, как и в другихсферах, следует принимать взвешенно. Единственный источник умения выбратьправильное решение — опыт. Те компании, которым не удается привлечь своихбизнес-менеджеров к обсуждению развития информационной системы и которые вместоэтого бесконечно сменяют руководителей информационно-технических отделов, нескоро достигнут необходимого уровня квалификации при принятии решений.
Программная система имеетпростую и гибкую структуру.
На словах многие компаниивыступают за стандартизацию, но лишь немногие из них реально придерживаютсястандартов. Большинство использует целый «ворох» приложений,разработанных самостоятельно или приобретенных у различных поставщиков. Иногдадля таких задач, как электронная почта или выписка счетов, используетсянесколько базовых систем. В результате возникают сложные и громоздкиеконгломераты приложений и пропадает гибкость инфраструктуры.
Компании, успешно использующиеинформационные технологии, обеспечивают простоту и гибкость своейтехнологической среды за счет жесткого определения стандартов архитектуры иглубокого анализа реальных плюсов и минусов в каждом конкретном случаеотклонения от этих стандартов. Им удается сохранить простоту системы, благодарясокращению числа используемых технологий и платформ, а также благодаряпостроению гибких и простых в реализации архитектур. При этом учитываютсякоммерческие аспекты, а именно: какие стандарты приняты в отрасли и насколькогарантированна поддержка данных технологий в будущем, так как поддержаниеморально устаревшей системы обходится чрезвычайно дорого.
Однако перевод организации наиспользование единых стандартов нередко встречает упорное сопротивление. Многиеотделы информационных технологий не имеют для этого необходимой власти.
Для некоторых, особо ценных приложенийдопустимы отклонения от принятых в организации стандартов архитектуры, нонаиболее предприимчивые компании сумели разработать эффективные способыуправления даже такими приложениями.
Такие компании прилагают многоусилий и для обеспечения модульности своих систем, упрощения и стандартизациивзаимодействия между ними. Такая стратегия позволяет им не только быстрееразрабатывать и интегрировать новые функциональные возможности и технологии, нои интегрировать разрозненные системы, приобретенные в результате слияния сдругими компаниями или реорганизации.
Повышение модульности и гибкостисистем неизбежно приводит к более продуманной стратегии разработки баз данных. Оченьважно определить, какая именно информация необходима компании. Для этого нужно,прежде всего, провести кропотливую, но чрезвычайно полезную работу по выделениюключевых данных, лежащих в основе бизнеса: например, какую информацию вывносите в заказы или как вы выставляете счета клиентам. Необходимо оценитьтребуемый объем информации: если информации будет слишком мало — вы не сможетепонять ключевые параметры вашего бизнеса, а слишком большие объемы данныхстановятся неуправляемыми.
Правильно организованный сборинформации, как правило, дает значительное преимущество в конкурентной борьбе. Например,многие успешно использующие информационные технологии компании могут наосновании этой информации составить сводку прибыльности по продуктам, клиентамили транзакциям и предпринять действия, повышающие их конкурентоспособность.
Отсюда следует вывод, нравитсявам это или нет, что руководителям необходимо принимать определенные решения вотношении стандартов, технологий и даже структур данных. Это не означает, чтоони должны вникать в детали, но они должны быть готовы к необходимости настоятьна соблюдении выбранных стандартов. Если эти решения затрагивают различныестраны и различные сферы бизнеса, то на руководителя ложатся обязанности повыработке компромиссов и принятию оптимальных решений.
Любые разработки начинаютприносить пользу бизнесу практически с момента внедрения.
Почти все компании приразработке приложений сталкиваются с проблемами управления проектом.
Компании, успешно использующиеинформационные технологии, применяют стратегию поэтапного ввода, чтобы избежатьединовременной замены всех устаревших информационных систем. При такойпошаговой организации процесса происходит постепенная модернизация всех систем.В хороших компаниях продолжительность каждого этапа обычно составляет 90 дней ипользователи быстро видят реальную отдачу.
Передовые компании используютвезде, где только возможно, стандартное программное обеспечение и вносятминимальные изменения в программы, предпочитая вместо этого рационализироватьсвои процессы. Если вы хотите добиться успеха, не следует приобретенные в прошломдурные привычки переносить на программное обеспечение будущего. «Золотое»правило: программное обеспечение стоит модифицировать только в том случае, еслив первый же год инвестиции в разработку окупятся в четырехкратном размере. Толькопри таком соотношении будут покрыты предстоящие расходы, связанные споддержанием нестандартных программ.
Если разработки по заказу нельзяизбежать или целью является наличие частной разработки, то «мудрые» компаниисосредотачивают свое внимание на тех 20 процентах функций, которые отвечают за80 процентов деятельности компании. Они ставят перед собой задачу быстроразработать все эти функции, используя такие приемы, как пробнаябизнес-реализация. При этом будущая система моделируется в небольших масштабах,чтобы специалисты по информационным технологиям могли внести необходимыепоправки и устранить проблемы, возникшие в ходе разработки, пока ситуация ещеуправляема. Первую серию изменений они проводят как можно более быстрымитемпами, оставляя менее существенные или требующие более долгих усилийизменения на более поздний этап.
В ходе разработки, правильнооценивающие роль информационных технологий, компании сопоставляют развитиекрупных проектов с реперными точками и с запланированными результатами и принеобходимости вносят изменения. Приоритетной задачей при этом является четкоесоблюдение сроков. Зачастую к работе привлекаются сторонние фирмы, чтобыпривнести в отдел информационных технологий диктуемую рыночными условиямидисциплину и ускорить процесс разработки.
После внедрения приложениякомпании в обязательном порядке проводят ревизию завершенного проекта и зановооценивают выполненную разработку. Полученный опыт учитывается в дальнейшейпрактике.
Для того чтобы такой подходзаработал, руководители должны в достаточной мере знать о функциональностипрограммного обеспечения для того, чтобы суметь проанализировать заявления отом, что стандартных функций недостаточно. Они должны суметь потребоватьреальные доказательства необходимости модификации стандартного программногообеспечения и понять, когда приводимые доказательства несостоятельны.
Проводятся планомерные ипостоянные улучшения производительности программной системы
Компании часто недооценивают,чего стоит просто поддерживать работу информационных систем. Во многих случаяхна приобретение новых приложений уходит менее одной трети от общих расходов наинформационные технологии, остальное поглощают затраты на эксплуатацию. Активноеуправление этой сферой деятельности поможет избежать стремительного ростатекущих расходов на эксплуатацию и поддержание системы.
Если разработку приложенийсравнить с производством продукции, то работа информационной системы можносравнить с работой завода. Как и на заводе, многие действия, связанные синформационной системой, выполняются круглосуточно и зачастую требуютмгновенной реакции: сюда относится обеспечение бесперебойного функционированияинформационного центра, сетей и прикладных программ, установка и демонтажоборудования, ответы на вопросы и администрирование.
Как и на хорошо работающемзаводе, производительность информационной системы оценивается по эталонам истандартам. Большинство компаний, достигших успеха в области информационныхтехнологий, оценивает производительность информационных центров и глобальныхсетей по эталонным тестам. Почти все консолидировали свои информационные центрыи переходят к консолидации серверов. Большинство либо централизует поддержкуинфраструктуры, либо поручает ее внешним организациям. И почти все из нихстремятся разработать хорошие эталонные тесты для своей распределенной среды.
Во многих отношениях управлениеИТ деятельностью требует больше административных, чем технических навыков.
Для того чтобы достичьсовершенства в эксплуатации системы, руководство должно научиться отделятьрасходы на поддержание системы от инвестиций в новое аппаратно-программноеобеспечение. Новые инвестиции следует оценивать как решения покапиталовложениям, а эксплуатацию — исходя из поставленных в областиобслуживания и затрат целей.
Отдел информационных технологийхорошо разбирается в бизнесе, а бизнес-подразделения — в программных системах иинформационных технологиях
Достаточно распространеннымявлением бывает наличие в организации руководящего комитета и специальныхпроцедур для интеграции информационных технологий с основными направлениямибизнеса. Но это не может заменить участие генерального директора и другихруководителей в стратегии развития информационной системы предприятия. Опытпоказывает, что высшее руководство процветающих компаний инициирует оживленныедискуссии об информационных технологиях среди руководителей основныхнаправлений деятельности и технических руководителей. Важным результатом такихдискуссий является привлечение к информационным технологиям интереса тех людей,которые могут устранить разрыв между технологиями и бизнесом. Привлечь такихлюдей нелегко, но еще труднее порой бывает их удержать.
В большинстве успешноиспользующих информационные технологии компаний менеджер по информатизации впервую очередь является бизнес-руководителем и только во вторую — техническимспециалистом. Возможно, кажется очевидным, что менеджер по информатизациидолжен входить в круг высшего руководства. Однако во многих компаниях онподчиняется руководителю финансового отдела; в результате увеличиваетсявероятность того, что к информационным технологиям будут относиться не более,чем как к затратам, которые необходимо контролировать.
В компаниях, успешноиспользующих информационные технологии, информационно-технический отдел тесноинтегрирован с остальными подразделениями. Его сотрудники размещаются бок о бокс остальным персоналом, и работа над всеми усовершенствованиями осуществляетсясовместно.
Основные отделы и отделинформационных технологий должны совместно работать над принятием решений вобласти информатизации, чтобы обеспечить их обоснованность, необходимую дляуспеха. Для этого сотрудники компании должны иметь базовые знания в областиинформационных технологий, а технические специалисты — знания об основнойдеятельности организации, однако большая часть такого обучения происходит входе совместной выработки решений. Поэтому ключевым моментом являетсяпривлечение основного персонала на стадии разработки и внедрения проекта.
В организациях, успешноиспользующих информационные технологии, структура технических отделов проста. Небольшоечисло сотрудников занимается поддержкой, а основной упор сделан напроизводительность. Эти организации понимают, что они не могут держатьспециалистов по всем направлениям, которые им могут понадобиться, и имеюттолько тех, потребность в которых особенно значительна или важна, а за другимиуслугами обращаются к внешним организациям. Они следят за тем, чтобыподдерживать у сотрудников навыки по ключевым бизнес-процессам.3. Виды программного обеспечения: общесистемное, сетевоеи прикладное
3.1 Общесистемное программноеобеспечение
Общесистемное ПО обеспечиваетуправление вычислительным процессом; вводом, выводом и обработкой данных икоманд пользователя. В его состав входят:
операционные системы
инструментально-технологическиесредства разработки и языковые процессоры
СУБД
CASE-системыи др.
3.2 Сетевое программноеобеспечение
Сетевое ПО обеспечиваетвзаимодействие локально или глобально распределенных компонентов компьютернойсистемы.
3.3 Прикладное программноеобеспечение
Прикладное ПО обеспечиваетрешение конкретных задач пользователей и включает:
3.3.1 Независимые программы
3.3.2 Библиотеки подпрограмм
3.3.3 Языковые процессоры длярешения общих прикладных задач
3.3.4 Многофункциональныепрограммы для решения ограниченного класса задач, различными алгоритмами
3.3.5 Пакеты прикладных программ
Обеспечивают:
решение класса задач
входной язык
информационная модель предметнойобласти
прикладные программ — модули
управление вычислительнымпроцессом
системная и функциональнаякомпоненты
ППП могут быть:
методо-ориентированные ППП
проблемно-ориентированные ППП
модельно-ориентированные ППП
объектно-ориентированные ППП
3.3.6. Программные системы (комплексы)4. Типы программного обеспечения
Тип ПО может бытьследующим:
Разрабатывающеесявновь;
Имеющееся вготовом виде;
Программно-аппаратное(встроенное);
Автономное.
Зновурозроблювальне. Таке ПЗ вступає в процес Розробки із самого початку і для ньогоповинні бути розглянуті усі вимоги цього процесу.
Наявне в готовомувигляді.
Готове ПЗ можевикористовуватися одним з наступних способів.
Використання ПЗточно в тому виді як воно є. Таке ПЗ вже спроектоване, закодоване і тестоване. Додатковетестування може знадобитися з урахуванням таких чинників як критичність іісторія використання. Це ПЗ входить у процес Розробки не пізнішекваліфікаційного тестування. Повний процес Розробки може виявитися зайвим. Повиннібути оцінені працездатність, документація, права власності і подальшоїпідтримки ПЗ.
Використанняготового ПЗ без модифікації, але зі зміною параметрів конфігурації додатка (наприклад,формату дати, валюти або розміру сторінки). Таке ПЗ входить у процес Розробки,коли компоненти ПЗ тестуються й інтегруються після відповідної зміни параметрів.Повний процес Розробки може виявитися зайвим. Повинні бути оціненіпрацездатність, документація, права власності і подальшої підтримки ПЗ.
Модифікаціяготового ПЗ (наприклад, зміна формату звітів або доробка документації). Упроцес Розробки входить на етапі кодування і тестування ПЗ. Повинні бутиоцінені працездатність, документація, права власності і подальшої підтримки ПЗ.
Вмонтоване ПЗ.
ПЗ абопрограмно-апаратні засоби вбудовуються в систему. Оскільки таке ПЗ є частиноювеликої системи, усі дії рівня системи в процесі Розробки повинні бутивраховані. Якщо ПЗ або програмно-апаратні засоби не вимагають подальшоїмодифікації, то треба старанно досліджувати питання про обсяг необхідноїдокументації.
Автономне ПЗ. Оскількитаке ПЗ не є частиною системи, усі дії рівня системи з процесу Розробки можутьбути виключені. Необхідно розглянути потреби в документації, особливо длясупроводу системи.
Великий проект, щовключає десятки або сотні людей, подає значні труднощі для керування Великийпроект або проект із багатьма субпідрядниками вимагає проведення ретельногоконтролю. Такий контроль досягається використанням процесів спільної оцінки,аудита, верифікації, валідації і забезпечення якості. Для невеликих проектівусі ці типи контролю можуть виявитися зайвими.
Чим більше системазалежить від того чи правильно працює ПЗ і чи закінчена його розробка вчасно,тим більше гласності і контролю необхідно. З іншої сторони надмірний контроль утих випадках коли в ньому ні необхідності, є неефективним.
Розробка ПЗ можебути сполучена з технічним ризиком. Якщо використовується незріла технологіярозробки, якщо розроблювальне ПЗ не має прецедентів або дуже складне, якщо доПЗ подаються специфічні вимоги по безпеці, захищеності, тоді потрібні дужеретельні специфікації, проектування, тестування й оцінка. У цьому випадкуможуть бути важливі незалежна верифікація і валідація.5. Общие требования к программным системам
5.1. Максимум удобствпользователя
общение на языке, близком кестественному
наглядное представление данных,возможность редактирования
быстрота ознакомления с работой,легкость осваивания
отсутствие жестких ограниченийна структуру и объем исходных данных
доступность общения
возможность адаптации ктребованиям пользователя
полнота и доступностьпрограммной документации
5.2. Адаптируемость ПО — приспособляемость к функционированию в различных условиях
5.3. Гибкость — возможностьлегко вводить изменения, дополнения и исправления в ПО
5.4. Мобильность — переносимостьна различные вычислительные платформы и операционные среды
5.5. Масштабируемость,расширяемость и модифицируемость
5.6. Эффективность работы6. Принципы построения программного обеспечения
6.1. Модульность ПО — проведениедекомпозиции алгоритмов и программ на модули с целью выделения общих типовыхфункций и компонентов.
6.2. Интеллектуальность ПО — наличие знаний о предметной области и умение использовать их при решении задач.
6.3. Черный ящик — ПО должноскрывать от пользователей сложный механизм организации и взаимодействияпрограмм.
6.4. Умолчание — умолчаниеоднажды заданных параметров, если они имеют смысл в других аналогичных задачах.
7. Критическиевопросы процесса разработки программного обеспечения
Качество
Людям свойственно ошибаться. Каждаяошибка, когда она найдена, является сюрпризом, исправление которого или дорогостоит, или выбивает из ритма разработки.
Если контроль качества ворганизации ослаблен, требуется запланировать в самом процессе разработки рядинспекций проектной документации и инспекций кодов, разрабатывая планыкачества, систему измерений, программу тестирования, т.е. более интенсивнуюработу по Подтверждению качества программного обеспечения (Software QualityAssurance).
Продуктивность технологии.
Очень часто при новыхразработках не ясно, как разработать алгоритм, достичь целей разработки илиограничить функциональность. Поскольку позднее «латание дырок» можетбыть безуспешным или трудоемким, или приводит к срывам темпов разработки,разумно в процессе предусмотреть заранее эксперименты для получения нужныхсведений. Последующая разработка будет развиваться более упорядоченным иэффективным образом.
Нестабильность (изменчивость) требований.
Для того, чтобы спроектировать,построить и оттестировать требуемую программу нужно, чтобы ее функции,интерфейсы и системный базис должны были стабильны. Поскольку возможныизменения во время разработки, эти изменения должны быть временно заморожены. Впланируемые периоды могут быть рассмотрены пакеты изменений и, соответственно,подработана программа. Если таким путем не управлять изменениями, процессразработки становится нестабильным.
Существуют три основных типаизменений требований.
Неизвестные требования. Пользовательдумает, что он знает, чего хочет, но во время начального использования открываетдля себя, что реальные потребности иные, нежели он думал. Это нормальноеявление при автоматизации человеческой деятельности. С ним можно бороться илиранним прототипированием или планированием множества релизов, которыепостепенно разрабатываются, используются, оцениваются и наращиваются до уровняследующего релиза.
Нестабильные требования. В товремя как общие требования известны, частности продолжают «плавать». Вбортовых системах, для которых hardware и software часто проектируетсяодновременно, изменения в hardware приводят к изменению требований кпрограммному обеспечению. Изменение hardware, диктуемое программнымиизменениями, является нонсенсом, аналогичным требованиям поменять фундамент припостройке здания. Тем не менее, с данным явлением можно бороться путемпредвидения нестабильностей и изоляции их.
Непонятные требования. Даже еслитребования известны и стабильны, разработчики часто не понимают их настолькодетально, чтобы сделать удовлетворительный программный продукт. Типичнымпримером является пользовательский интерфейс. Здесь полезно тестированиепользователем прототипов интерфейса или ранних версий пользовательскойдокументации.
Сложность.
Программы приложений часто легчеразработать, чем системы, поскольку их платформа и окружение более стабильны. Этоне означает, что разработка приложений требует меньшей квалификации. Этоозначает, что имеется меньше источников для одновременных изменений.
Например, во время разработкиновой операционной системы все ее элементы находятся в состоянии постоянныхизменений: управляющая программа, компиляторы, система управления данными и т.д.,в том числе и архитектура компьютера.
Для того, чтобы достичь хотя быкакого-то результата, требуется обеспечить хотя бы промежуточную стабильность. Обычностабильность достигается путем использования приемов модульногопрограммирования, в частности, выделения модулей и определения интерфейсов. Далееуправление изменениями позволяет для каждого модуля иметь осязаемые истабильные требования на определенном интервале между изменениями.