Виды программного обеспечения. Общие требования к программным системам

Виды программного обеспечения. Общие требования к программным системам Курсовая работа Виды программного обеспечения. Общие требования к программным системам Киев 2009 Содержание 1. Цели и задачи программной инженерии. Понятие программного обеспечения 2. Шесть принципов эффективного использования программного обеспечения 4. Типы программного обеспечения 5. Общие требования к программным системам 6. Принципы построения программного обеспечения 1. Цели и задачи программной инженерии. Понятие программного обеспечения Последнее десятилетие в области программирования характеризуется становлением новой дисциплины - программной инженерии (Software Engineering), что вызвано возросшими потребностями: в создании различного вида компьютерных систем; обеспечения качества ПО; В результате разработку ПО стали рассматривать как определенный вид человеческой деятельности, к которому применимы инженерные методы выполнения и организации работ, методы менеджмента и управления, экономические методы оценки эффективности и стоимости работ. В последние годы наблюдается повышенный интерес к вопросам формализации методов анализа и спецификации требований к программному обеспечению. Необходимость этого обусловлена ростом требований к качеству программного обеспечения, изменениями в методологии его проектирования и разработки, в современной организации проектных работ. Программная инженерия - это научная дисциплина, которая изучает методы, способы и технологии разработки ПО, в результате которого реализуются возможности ЭВМ по выполнению различных действий, связанных с переработкой информации. Программная инженерия - строгое использование инженерных, научных и математических принципов, методов и инструментария для экономичного создания качественного программного обеспечения. Программное обеспечение (ПО) - это совокупность машинных программ, соответствующей качественной документации, баз данных, а также технологических процедур по эксплуатации ПО. Основа программной инженерии - стандарты, методы, методологии проектирования и управления процессом разработки ПО, а также инструментально-технологические средства поддержки этого процесса (CASE - технологии), к которым относятся системы программирования и автоматизации разных этапов проектирования и разработки ПО. Верификация - это установление соответствия ПО его спецификации. Подтверждение - установление пригодности или соответствия ПО его назначению. Качество ПО Человеческие факторы Легкость использования Планируемость Удовлетворение потребностей пользователя Организованность команды разработчиков Следование модифицированному правилу Контролируемость хода работ Управление ресурсами Эффективность Тестируемость Анализ эффективности Контроль сроков и бюджета Специфицированность Анализ требований к ПО Правильность Проектирование Адаптируемость Программирование модифицируемость Тестирование и контроль переносимость Верификация и подтверждение работоспособность в других системах Внедряемость и сопровождаемость Управляемость конфигурацией 2. Шесть принципов эффективного использования программного обеспечения серьезными проблемами, чем раньше. Многие организации обременены внедренными ранее дорогостоящими и неоправданно сложными системами. У других бизнес-подразделения и отдел информационных технологий не могут (или не хотят) найти общий язык. Третьи не могут понять, во что нужно вложить деньги, чтобы получить жизненно необходимые функциональные возможности. Однако существует ряд компаний, которые смогли по-настоящему овладеть информационными технологиями и получают от них реальную пользу, т. к управляют своими программными системами примерно так же, как и другими важными функциями и процессами в компании: обеспечивая административную поддержку на самом высоком уровне, прививая специалистам по информационным технологиям знание бизнес-терминологии ориентируя усилия сотрудников технического отдела на достижение конкретных бизнес-целей. В основе успеха внедрения ПО лежат шесть перечисленных ниже принципов: Развитие в области внедрения программных систем и информационных технологий обуславливается потребностями основной деятельности компании, а не технологическими новшествами. Решения о финансировании в области программных систем и информационных технологий принимаются так же, как и во всех остальных сферах - исходя из соображений финансовой выгоды. Программная система имеет простую и гибкую структуру. Любые разработки начинают приносить пользу бизнесу практически с момента внедрения. Проводятся планомерные и постоянные улучшения производительности программной системы. Отдел информационных технологий хорошо разбирается в бизнесе, а бизнес-подразделения - в программных системах и информационных технологиях. Очень важно применять все эти принципы одновременно: ни один из них не принесет успеха без пяти остальных. Таблица 1. Контрольный список для реализации шести принципов Развитие в области программного обеспечения обуславливается потребностями основной деятельности компании, а не технологическими новшествами Решения о финансировании в области программного обеспечения принимаются так же, как и во всех остальных сферах - исходя из соображений финансовой выгоды Программная система имеет простую и гибкую структуру Управляйте программным обеспечением так же, как остальными бизнес-функциями компании. Непосредственно свяжите ПО с важными для бизнеса стратегиями, основными стоимостными факторами и повседневными деловыми процессами. Назначьте линейных руководителей ответственными за новые приложения: Выбор проектов для внедрения Руководство внедрением Ответственность за результаты Использование поддержки отдела информационных технологий Поручите отделу информационных технологий создание и поддержку эффективной инфраструктуры для приложений. "черному ящику" - обязуйте технических специалистов применять деловую лексику. Свяжите инвестиции с реальными задачами совершенствования бизнеса и производительности Используйте при принятии решений анализ затрат и преимуществ, который обеспечит упорядоченность и систематичность. Распространите принятые в бизнесе подходы к менее определенным, менее поддающимся количественному учету и более стратегически важным решениям Оценивайте текущие расходы на программное обеспечение исходя из поставленных целей в области стоимости и обслуживания. Избегайте крупных единовременных затрат на аппаратно-программное обеспечение; стремитесь к постоянному обновлению. Устанавливайте стандарты архитектуры ПО и глубоко анализируйте плюсы и минусы использования иных стандартов. Упрощайте систему: Уменьшайте число используемых технологий и платформ. Применяйте для приложений модульную архитектуру. Используйте межплатформенные решения для повышения гибкости и простоты внедрения приложений и инфраструктуры. Консервативно подходите к выбору технологий, исключение могут составлять только нововведения, способные принести огромные прибыли Учитывайте коммерческие аспекты, такие как отраслевые стандарты и вероятность получения в будущем технической поддержки. Условием выбора новейших технологий должна быть значительная бизнес-отдача. Подходите к конфигурированию баз данных и приложений стратегически, стараясь обеспечить успешно работающую оптимальную структуру. Проводятся планомерные и постоянные улучшения производительности системы Отдел информационных технологий хорошо разбирается в бизнесе, а бизнес-подразделения - в информационных технологиях Осуществляйте постепенный переход, а не глобальную замену: Устанавливайте промежуточные цели (с интервалом, как правило, не больше 6 месяцев), которые обеспечивают реальное продвижение в бизнесе Если возможно, реализуйте тестовую модель проекта в небольших масштабах. Постоянно сравнивайте развитие крупных проектов с эталонами и с запланированными результатами; при необходимости проводите коррекцию. Регулярно проводите ревизию завершенных проектов и переоценку этапов разработки. Относитесь к управлению эксплуатацией ПО, как к управлению заводом: определите стандарты производительности и конкретные задачи улучшения управления стоимостью, качества обслуживания и времени отклика. Реорганизуйте работу ПО для получения максимально экономичной модели: Стандартизируйте конфигурацию настольных компьютеров и ограничьте возможность ее изменения. Разработайте эталонные тесты, чтобы можно было ставить конкретные цели в области поддержки и стоимости эксплуатации системы Правильно распределите обязанности: Генеральный директор активно участвует в принятии решений в области ПО, определяя верное направление. Менеджер по информатизации, в первую очередь, является бизнес-руководителем и входит в состав высшего руководства Обеспечьте руководство со стороны представителей бизнес-подразделений и их осведомленность в области ПО Обучите специалистов по программному обеспечению основам бизнеса. Выработайте совместную процедуру принятия обоснованных решений руководителями бизнес-отделов и руководителем информационно-технического отдела: Стимулируйте исследование деловых возможностей. Требуйте рассмотрения разных вариантов и всесторонних обсуждений при решении сложных вопросов. Создайте условия для высокопроизводительной работы отдела информационных технологий: Простая организационная структура. Мало должностей. Высокая квалификация специалистов. Развитие в области внедрения программных систем и информационных технологий обуславливается потребностями основной деятельности компании, а не технологическими новшествами В компаниях с более высокой производительностью за программную систему отвечают руководители бизнес-отделов, а не технические руководители. Это означает, что руководители бизнеса отвечают за выбор, внедрение и оценку преимуществ новых приложений. Отдел информационных технологий сотрудничает с основными отделами в разработке приложений и выступает в роли хозяина технологической инфраструктуры. Но если что-то не ладится, то ответственность ложится на бизнес-менеджера. При таком подходе руководители платят за то, что им по-настоящему нужно, потому что это напрямую связано с их бюджетом и кредитоспособностью. В результате, они значительно больше внимания уделяют стоимости и гораздо менее склонны списывать свои неудачи за счет информационных технологий. Такая ответственность способствует более четкому пониманию стоящих перед ними проблем и путей их решения. Кроме того, руководители начинают быстрее принимать решения, устанавливая более короткие сроки выполнения работ и разбивая процесс внедрения на этапы, чтобы как можно скорее получить конкретные результаты. Назначение руководителей линейных подразделений ответственными за программную систему означает, что отдел информационных технологий поддерживает новые разработки и отвечает за организацию экономичной инфраструктуры. Кроме того, появляется связь между решениями, принятыми руководителями отдельных направлений, что обеспечивает согласованность отдельных решений. Высшее руководство, со своей стороны, должно обладать достаточными знаниями, чтобы поддерживать конструктивные диалоги со своим отделом по информатизации и задавать такие же прозорливые вопросы, как и в отношении других функций. Это означает, что сотрудники информационно-технического отдела должны использовать бизнес-терминологию, а не технический жаргон. Это также означает, что руководители других подразделений должны владеть основами информационных технологий и не бояться задавать разнообразные вопросы. Таким образом, руководители информационно-технических групп и других отделов смогут оценивать эффективность друг друга и совместно проводить необходимую корректировку в случае неудач. Решения о финансировании в области программных систем и информационных технологий принимаются так же, как и во всех остальных сферах - исходя из соображений финансовой выгоды с тем, что каждый проект оказывается важным, а затраты возрастают сверх меры. Другие компании с трудом могут сбалансировать потребности разных подразделений. Третьи нанимают специалиста по технологиям, ответственного за принятие решений по совершенствованию программной системы, только затем, чтобы уволить его и нанять другого с еще более высоким окладом в том случае, если инвестиции себя не оправдают. В таких компаниях недопонимают значение информационных технологий для развития бизнеса и основной упор делают на возможности сокращения расходов. Опросы показывают, что компании, успешно использующие информационные технологии, принимают решения о новых крупных инвестициях в информационные технологии так же, как и любые другие финансовые решения - сочетая качественную оценку с точки зрения бизнеса со строгим анализом затрат и выгод, что обеспечивает упорядоченность и систематичность. Особенно важно то, что решения об инвестициях принимаются на основе полноценного бизнес-анализа, что позволяет понять и оценить менее определенные, меньше поддающиеся количественным оценкам и более стратегически важные аспекты решений по инвестированию информационных технологий. Если компании не удается выработать тщательно продуманную систему оценки отдачи вложений, то, как правило, решения по развитию информационных технологий принимаются, исходя из простого стремления снизить расходы. Для многих отделов информационных технологий такой вариант окажется неприемлемым, потому что часть проектов неизбежно провалится. планировании информационные технологии обязательно принимаются во внимание, и отдел информатизации следит не только за текущим состоянием реализуемых проектов, но и за стратегическими планами компании на ближайшие три-пять лет. Оценивается, насколько с учетом поставленных в области обслуживания и расходов целей, оправданы затраты на эксплуатацию информационной системы. Информационный центр, сети и инфраструктура рассматриваются как производство, к которому постоянно предъявляются требования повышения производительности. И, наконец, компании, успешно решающие связанные с информационными технологиями проблемы, избегают крупных единовременных капиталовложений, предпочитая постоянно обновлять свои системы и ежегодно инвестировать их совершенствование на регулярной основе. Это позволяет сохранять высокий технический уровень и надежно защищает от падения эффективности работы, связанной с несбалансированной политикой. Руководство компании должно понимать, что решения в области информационных технологий, как и в других сферах, следует принимать взвешенно. Единственный источник умения выбрать правильное решение - опыт. Те компании, которым не удается привлечь своих бизнес-менеджеров к обсуждению развития информационной системы и которые вместо этого бесконечно сменяют руководителей информационно-технических отделов, не скоро достигнут необходимого уровня квалификации при принятии решений. Программная система имеет простую и гибкую структуру. "ворох" приложений, разработанных самостоятельно или приобретенных у различных поставщиков. Иногда для таких задач, как электронная почта или выписка счетов, используется несколько базовых систем. В результате возникают сложные и громоздкие конгломераты приложений и пропадает гибкость инфраструктуры. Компании, успешно использующие информационные технологии, обеспечивают простоту и гибкость своей технологической среды за счет жесткого определения стандартов архитектуры и глубокого анализа реальных плюсов и минусов в каждом конкретном случае отклонения от этих стандартов. Им удается сохранить простоту системы, благодаря сокращению числа используемых технологий и платформ, а также благодаря построению гибких и простых в реализации архитектур. При этом учитываются коммерческие аспекты, а именно: какие стандарты приняты в отрасли и насколько гарантированна поддержка данных технологий в будущем, так как поддержание морально устаревшей системы обходится чрезвычайно дорого. Для некоторых, особо ценных приложений допустимы отклонения от принятых в организации стандартов архитектуры, но наиболее предприимчивые компании сумели разработать эффективные способы управления даже такими приложениями. новые функциональные возможности и технологии, но и интегрировать разрозненные системы, приобретенные в результате слияния с другими компаниями или реорганизации. Повышение модульности и гибкости систем неизбежно приводит к более продуманной стратегии разработки баз данных. Очень важно определить, какая именно информация необходима компании. Для этого нужно, прежде всего, провести кропотливую, но чрезвычайно полезную работу по выделению ключевых данных, лежащих в основе бизнеса: например, какую информацию вы вносите в заказы или как вы выставляете счета клиентам. Необходимо оценить требуемый объем информации: если информации будет слишком мало - вы не сможете понять ключевые параметры вашего бизнеса, а слишком большие объемы данных становятся неуправляемыми. Правильно организованный сбор информации, как правило, дает значительное преимущество в конкурентной борьбе. Например, многие успешно использующие информационные технологии компании могут на основании этой информации составить сводку прибыльности по продуктам, клиентам или транзакциям и предпринять действия, повышающие их конкурентоспособность. Отсюда следует вывод, нравится вам это или нет, что руководителям необходимо принимать определенные решения в отношении стандартов, технологий и даже структур данных. Это не означает, что они должны вникать в детали, но они должны быть готовы к необходимости настоять на соблюдении выбранных стандартов. Если эти решения затрагивают различные страны и различные сферы бизнеса, то на руководителя ложатся обязанности по выработке компромиссов и принятию оптимальных решений. Почти все компании при разработке приложений сталкиваются с проблемами управления проектом. Компании, успешно использующие информационные технологии, применяют стратегию поэтапного ввода, чтобы избежать единовременной замены всех устаревших информационных систем. При такой пошаговой организации процесса происходит постепенная модернизация всех систем. В хороших компаниях продолжительность каждого этапа обычно составляет 90 дней и пользователи быстро видят реальную отдачу. Передовые компании используют везде, где только возможно, стандартное программное обеспечение и вносят минимальные изменения в программы, предпочитая вместо этого рационализировать свои процессы. Если вы хотите добиться успеха, не следует приобретенные в прошлом дурные привычки переносить на программное обеспечение будущего. "Золотое" правило: программное обеспечение стоит модифицировать только в том случае, если в первый же год инвестиции в разработку окупятся в четырехкратном размере. Только при таком соотношении будут покрыты предстоящие расходы, связанные с поддержанием нестандартных программ. Если разработки по заказу нельзя избежать или целью является наличие частной разработки, то "мудрые" компании сосредотачивают свое внимание на тех 20 процентах функций, которые отвечают за 80 процентов деятельности компании. Они ставят перед собой задачу быстро разработать все эти функции, используя такие приемы, как пробная бизнес-реализация. При этом будущая система моделируется в небольших масштабах, чтобы специалисты по информационным технологиям могли внести необходимые поправки и устранить проблемы, возникшие в ходе разработки, пока ситуация еще управляема. Первую серию изменений они проводят как можно более быстрыми темпами, оставляя менее существенные или требующие более долгих усилий изменения на более поздний этап. В ходе разработки, правильно оценивающие роль информационных технологий, компании сопоставляют развитие крупных проектов с реперными точками и с запланированными результатами и при необходимости вносят изменения. Приоритетной задачей при этом является четкое соблюдение сроков. Зачастую к работе привлекаются сторонние фирмы, чтобы привнести в отдел информационных технологий диктуемую рыночными условиями дисциплину и ускорить процесс разработки. После внедрения приложения компании в обязательном порядке проводят ревизию завершенного проекта и заново оценивают выполненную разработку. Полученный опыт учитывается в дальнейшей практике. Для того чтобы такой подход заработал, руководители должны в достаточной мере знать о функциональности программного обеспечения для того, чтобы суметь проанализировать заявления о том, что стандартных функций недостаточно. Они должны суметь потребовать реальные доказательства необходимости модификации стандартного программного обеспечения и понять, когда приводимые доказательства несостоятельны. Проводятся планомерные и постоянные улучшения производительности программной системы Компании часто недооценивают, чего стоит просто поддерживать работу информационных систем. Во многих случаях на приобретение новых приложений уходит менее одной трети от общих расходов на информационные технологии, остальное поглощают затраты на эксплуатацию. Активное управление этой сферой деятельности поможет избежать стремительного роста текущих расходов на эксплуатацию и поддержание системы. Если разработку приложений сравнить с производством продукции, то работа информационной системы можно сравнить с работой завода. Как и на заводе, многие действия, связанные с информационной системой, выполняются круглосуточно и зачастую требуют мгновенной реакции: сюда относится обеспечение бесперебойного функционирования информационного центра, сетей и прикладных программ, установка и демонтаж оборудования, ответы на вопросы и администрирование. Как и на хорошо работающем заводе, производительность информационной системы оценивается по эталонам и стандартам. Большинство компаний, достигших успеха в области информационных технологий, оценивает производительность информационных центров и глобальных сетей по эталонным тестам. Почти все консолидировали свои информационные центры и переходят к консолидации серверов. Большинство либо централизует поддержку инфраструктуры, либо поручает ее внешним организациям. И почти все из них стремятся разработать хорошие эталонные тесты для своей распределенной среды. Во многих отношениях управление ИТ деятельностью требует больше административных, чем технических навыков. Для того чтобы достичь совершенства в эксплуатации системы, руководство должно научиться отделять расходы на поддержание системы от инвестиций в новое аппаратно-программное обеспечение. Новые инвестиции следует оценивать как решения по капиталовложениям, а эксплуатацию - исходя из поставленных в области обслуживания и затрат целей. Достаточно распространенным явлением бывает наличие в организации руководящего комитета и специальных процедур для интеграции информационных технологий с основными направлениями бизнеса. Но это не может заменить участие генерального директора и других руководителей в стратегии развития информационной системы предприятия. Опыт показывает, что высшее руководство процветающих компаний инициирует оживленные дискуссии об информационных технологиях среди руководителей основных направлений деятельности и технических руководителей. Важным результатом таких дискуссий является привлечение к информационным технологиям интереса тех людей, которые могут устранить разрыв между технологиями и бизнесом. Привлечь таких людей нелегко, но еще труднее порой бывает их удержать. В большинстве успешно использующих информационные технологии компаний менеджер по информатизации в первую очередь является бизнес-руководителем и только во вторую - техническим специалистом. Возможно, кажется очевидным, что менеджер по информатизации должен входить в круг высшего руководства. Однако во многих компаниях он подчиняется руководителю финансового отдела; в результате увеличивается вероятность того, что к информационным технологиям будут относиться не более, чем как к затратам, которые необходимо контролировать. и работа над всеми усовершенствованиями осуществляется совместно. Основные отделы и отдел информационных технологий должны совместно работать над принятием решений в области информатизации, чтобы обеспечить их обоснованность, необходимую для успеха. Для этого сотрудники компании должны иметь базовые знания в области информационных технологий, а технические специалисты - знания об основной деятельности организации, однако большая часть такого обучения происходит в ходе совместной выработки решений. Поэтому ключевым моментом является привлечение основного персонала на стадии разработки и внедрения проекта. организации понимают, что они не могут держать специалистов по всем направлениям, которые им могут понадобиться, и имеют только тех, потребность в которых особенно значительна или важна, а за другими услугами обращаются к внешним организациям. Они следят за тем, чтобы поддерживать у сотрудников навыки по ключевым бизнес-процессам. 3. Виды программного обеспечения: общесистемное, сетевое и прикладное 3. 1 Общесистемное программное обеспечение Общесистемное ПО обеспечивает управление вычислительным процессом; вводом, выводом и обработкой данных и команд пользователя. В его состав входят: операционные системы инструментально-технологические средства разработки и языковые процессоры СУБД CASE-системы и др. 3. 2 Сетевое программное обеспечение 3. 3 Прикладное программное обеспечение 3. 3. 2 Библиотеки подпрограмм 3. 3. 3 Языковые процессоры для решения общих прикладных задач 3. 3. 5 Пакеты прикладных программ Обеспечивают: решение класса задач информационная модель предметной области прикладные программ - модули управление вычислительным процессом системная и функциональная компоненты методо-ориентированные ППП проблемно-ориентированные ППП модельно-ориентированные ППП объектно-ориентированные ППП 4. Типы программного обеспечения Автономное. Знову розроблювальне. Таке ПЗ вступає в процес Розробки iз самого початку i для нього повиннi бути розглянутi усi вимоги цього процесу. Наявне в готовому виглядi. Готове ПЗ може використовуватися одним з наступних способiв. Використання ПЗ точно в тому видi як воно є. Таке ПЗ вже спроектоване, закодоване i тестоване. Додаткове тестування може знадобитися з урахуванням таких чинникiв як критичнiсть i iсторiя використання. Це ПЗ входить у процес Розробки не пiзнiше квалiфiкацiйного тестування. Повний процес Розробки може виявитися зайвим. Повиннi бути оцiненi працездатнiсть, документацiя, права власностi i подальшої пiдтримки ПЗ. Використання готового ПЗ без модифiкацiї, але зi змiною параметрiв конфiгурацiї додатка (наприклад, формату дати, валюти або розмiру сторiнки). Таке ПЗ входить у процес Розробки, коли компоненти ПЗ тестуються й iнтегруються пiсля вiдповiдної змiни параметрiв. Повний процес Розробки може виявитися зайвим. Повиннi бути оцiненi працездатнiсть, документацiя, права власностi i подальшої пiдтримки ПЗ. власностi i подальшої пiдтримки ПЗ. Вмонтоване ПЗ. ПЗ або програмно-апаратнi засоби вбудовуються в систему. Оскiльки таке ПЗ є частиною великої системи, усi дiї рiвня системи в процесi Розробки повиннi бути врахованi. Якщо ПЗ або програмно-апаратнi засоби не вимагають подальшої модифiкацiї, то треба старанно дослiджувати питання про обсяг необхiдної документацiї. Автономне ПЗ. Оскiльки таке ПЗ не є частиною системи, усi дiї рiвня системи з процесу Розробки можуть бути виключенi. Необхiдно розглянути потреби в документацiї, особливо для супроводу системи. Великий проект, що включає десятки або сотнi людей, подає значнi труднощi для керування Великий проект або проект iз багатьма субпiдрядниками вимагає проведення ретельного контролю. Такий контроль досягається використанням процесiв спiльної оцiнки, аудита, верифiкацiї, валiдацiї i забезпечення якостi. Для невеликих проектiв усi цi типи контролю можуть виявитися зайвими. Чим бiльше система залежить вiд того чи правильно працює ПЗ i чи закiнчена його розробка вчасно, тим бiльше гласностi i контролю необхiдно. З iншої сторони надмiрний контроль у тих випадках коли в ньому нi необхiдностi, є неефективним. по безпецi, захищеностi, тодi потрiбнi дуже ретельнi специфiкацiї, проектування, тестування й оцiнка. У цьому випадку можуть бути важливi незалежна верифiкацiя i валiдацiя. 5. Общие требования к программным системам общение на языке, близком к естественному наглядное представление данных, возможность редактирования быстрота ознакомления с работой, легкость осваивания отсутствие жестких ограничений на структуру и объем исходных данных доступность общения возможность адаптации к требованиям пользователя полнота и доступность программной документации 5. 2. Адаптируемость ПО - приспособляемость к функционированию в различных условиях 5. 3. Гибкость - возможность легко вводить изменения, дополнения и исправления в ПО 5. 4. Мобильность - переносимость на различные вычислительные платформы и операционные среды 5. 5. Масштабируемость, расширяемость и модифицируемость 5. 6. Эффективность работы 6. Принципы построения программного обеспечения 6. 1. Модульность ПО - проведение декомпозиции алгоритмов и программ на модули с целью выделения общих типовых функций и компонентов. 6. 2. Интеллектуальность ПО - наличие знаний о предметной области и умение использовать их при решении задач. 6. 4. Умолчание - умолчание однажды заданных параметров, если они имеют смысл в других аналогичных задачах. Качество Людям свойственно ошибаться. Каждая ошибка, когда она найдена, является сюрпризом, исправление которого или дорого стоит, или выбивает из ритма разработки. Если контроль качества в организации ослаблен, требуется запланировать в самом процессе разработки ряд инспекций проектной документации и инспекций кодов, разрабатывая планы качества, систему измерений, программу тестирования, т. е. более интенсивную работу по Подтверждению качества программного обеспечения (Software Quality Assurance). Продуктивность технологии. Очень часто при новых разработках не ясно, как разработать алгоритм, достичь целей разработки или ограничить функциональность. Поскольку позднее "латание дырок" может быть безуспешным или трудоемким, или приводит к срывам темпов разработки, разумно в процессе предусмотреть заранее эксперименты для получения нужных сведений. Последующая разработка будет развиваться более упорядоченным и эффективным образом. эти изменения должны быть временно заморожены. В планируемые периоды могут быть рассмотрены пакеты изменений и, соответственно, подработана программа. Если таким путем не управлять изменениями, процесс разработки становится нестабильным. Существуют три основных типа изменений требований. Неизвестные требования. Пользователь думает, что он знает, чего хочет, но во время начального использования открывает для себя, что реальные потребности иные, нежели он думал. Это нормальное явление при автоматизации человеческой деятельности. С ним можно бороться или ранним прототипированием или планированием множества релизов, которые постепенно разрабатываются, используются, оцениваются и наращиваются до уровня следующего релиза. Нестабильные требования. В то время как общие требования известны, частности продолжают "плавать". В бортовых системах, для которых hardware и software часто проектируется одновременно, изменения в hardware приводят к изменению требований к программному обеспечению. Изменение hardware, диктуемое программными изменениями, является нонсенсом, аналогичным требованиям поменять фундамент при постройке здания. Тем не менее, с данным явлением можно бороться путем предвидения нестабильностей и изоляции их. Непонятные требования. Даже если требования известны и стабильны, разработчики часто не понимают их настолько детально, чтобы сделать удовлетворительный программный продукт. Типичным примером является пользовательский интерфейс. Здесь полезно тестирование пользователем прототипов интерфейса или ранних версий пользовательской документации. Программы приложений часто легче разработать, чем системы, поскольку их платформа и окружение более стабильны. Это не означает, что разработка приложений требует меньшей квалификации. Это означает, что имеется меньше источников для одновременных изменений. Например, во время разработки новой операционной системы все ее элементы находятся в состоянии постоянных изменений: управляющая программа, компиляторы, система управления данными и т. д., в том числе и архитектура компьютера. Для того, чтобы достичь хотя бы какого-то результата, требуется обеспечить хотя бы промежуточную стабильность. Обычно стабильность достигается путем использования приемов модульного программирования, в частности, выделения модулей и определения интерфейсов. Далее управление изменениями позволяет для каждого модуля иметь осязаемые и стабильные требования на определенном интервале между изменениями.