Файл: Программа, комплекс программ, программное средство, программное обеспечение, программный продукт. Концепция программного изделия непосредственная производительная сила,.doc
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 07.11.2023
Просмотров: 308
Скачиваний: 3
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Если выбран интерфейс со свободной навигацией или прямого
манипулирования, то, как указывалось выше, это практически однозначно предполагает
использование событийного программирования и объектного подхода, так как современные среды
визуального программирования, такие как Visual C++, Delphi, Builder C++ и им подобные,
предоставляют интерфейсные компоненты именно в виде объектов библиотечных классов. При
этом в зависимости от сложности предметной области программное обеспечение может
реализовываться как с использованием объектов и, соответственно, классов, так и чисто
процедурно. Исключение составляют случаи использования специализированных языков
разработки Интернет-приложений, таких как Perl, построенных по совершенно другому принципу.
Примитивный интерфейс и интерфейс типа меню совместимы как со структурным, так и с
объектным подходами к разработке. Поэтому выбор подхода осуществляют с использованием
дополнительной информации.
Практика показывает, что объектный подход эффективен для разработки очень больших
программных систем (более 100000 операторов универсального языка программирования) и в тех
случаях, когда объектная структура предметной области ярко выражена.
Следует также учитывать, что необходимо осторожно использовать объектный подход при
жестких ограничениях на эффективность разрабатываемого программного обеспечения, например,
при разработке систем резального времени.
Во всех прочих случаях выбор подхода остается за разработчиком.
Выбор языка программирования.
Язык может быть определен:
• организацией, ведущей разработку;
• программистом, который по возможности всегда будет использовать хорошо знакомый язык;
• устоявшимся мнением:
Если же все-таки выбор языка реально возможен, то нужно иметь в виду, что все существующие языки программирования можно разделить на следующие группы:
• универсальные языки высокого уровня;
• специализированные языки разработчика программного обеспечения(языки баз данных; языки создания сетевых приложений; языки создания систем искусственного интеллекта и т. д.)
• специализированные языки пользователя (обычно являются частью профессиональных сред пользователя, характеризуются узкой направленностью и разработчиками ПО не используются.)
• языки низкого уровня. (позволяют осуществлять программирование практически на уровне машинных команд)
Выбор среды программирования. Средой программирования называют программный
комплекс, который включает специализированный текстовый редактор, встроенные компилятор,
компоновщик, отладчик, справочную систему и другие программы, использование которых
упрощает процесс написания и отладки программ. (Delphi, C++ Builder и Visual C).
Выбор или формирование стандартов разработки. Реальное применение любой технологии
проектирования требует формирования или выбора ряда стандартов, которые должны
соблюдаться всеми участниками проекта:
• стандарт проектирования;
• стандарт оформления проектной документации;
• стандарт интерфейса пользователя.
Стандарт проектированиядолжен определять:
• набор необходимых моделей (схем, диаграмм) на каждой стадии проектирования и степень
их детализации;
• правила фиксации проектных решений на диаграммах, в том числе правила именования
объектов и соглашения по терминологии, набор атрибутов для всех объектов и правила их
заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и
размерам объектов;
• требования к конфигурации рабочих мест разработчиков, включая настройки операционной
системы и используемых CASE-средств;
• механизм обеспечения совместной работы над проектом, в том числе и правила интеграции
подсистем проекта и анализа проектных решений на непротиворечивость.
Стандарт оформления проектной документациидолжен регламентировать:
• комплектность, состав и структуру документации на каждой стадии;
• требования к ее содержанию и оформлению;
• правила подготовки, рассмотрения, согласования и утверждения документов.
Стандарт интерфейса пользователядолжен определять:
• правила оформления экранов (шрифты и цветовую палитру), состав и расположение окон и
элементов управления;
• правила пользования клавиатурой и мышью;
• правила оформления текстов помощи;
• перечень стандартных сообщений;
• правила обработки реакции пользователя.
Основная цель календарного планирования - выдача информации для подготовки производства на планируемый период.
Календарное планирование проекта, которое состоит в определении календарных дат выполнения всех работ, ставит цель координацию деятельности привлеченных к проекту исполнителей для обеспечения его успешного завершения.
В календарных графиках (способу вывода данных ) отмечается возможная гибкость в дате начала работы без осложнения выполнения всего проекта (т.е. запас времени по некритическим роботам).
Цели календарного графика:
- обеспечить своевременное поступление финансирования;
- координировать поступление ресурсов;
- своевременно обеспечить нужны ресурсы;
-предусмотреть в разные моменты уровень нужных финансовых затрат и ресурсов и рациональное распределение их между проектами;
-обеспечить своевременное выполнение проекта.
4.2. Функции программного обеспечения для календарного планирования
Как правило, система календарного планирования, обеспечивает основной набор функциональных возможностей, которые включают в себя:
- средства визуального проектирования структуры работ проекта,
- средства планирования по методу критического пути,
- средства ресурсного планирования (описание, назначение и оптимизация загрузки ресурсов),
- некоторые возможности стоимостного анализа,
- средства контроля за ходом исполнения проекта,
- средства создания отчетов и графических диаграмм,
4.3. Виды календарного планирования (календарные графики, диаграммы Гантта)
Существует два приемлемых пути представления календарного графика:
- табличный — с перечнем работ с указанием продолжительности их выполнение;
- диаграммный (балочные диаграммы, или диаграммы Гантта).
диаграмма Гантта является наглядным источником такой проектной информации:
- какие работы являются критическими, а какие - некритическими;
- вывод и использование затрат проекта и т.д.
Диаграммы Гантта:
-легко строится и прочитывается;
- разрешает наглядно подать ход выполнения работ за проектом;
- дает возможность легче понять идею запаса времени и его использование;
- является предпосылкой календарного планирования нужд в ресурсах;
- является условием определения денежных потоков;
- является прекрасным средством планирования и контроля;
- является ключевым документом в процессе принятия решений.
Прежде чем строить диаграмму Гантта, нужно определить:
- логическую связь между работами;
-продолжительность работ в зависимости от ресурсов, которые используются;
- распределение ресурсов между роботами в зависимости от их наличия.
Поэтому календарное планирование нуждается в не только определении сроков выполнения работ, но и согласование их с состоянием обеспечения необходимыми ресурсами и возможностью финансирования.
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
Спецификации представляют собой полное и точное описание функций и ограничений разрабатываемого ПО. При этом одна часть спецификаций (функциональные) описывает функции разрабатываемого программного обеспечения, а другая часть (эксплуатационные) определяет требования к техническим средствам, надежности, информационной безопасности и т. д.
Определение отражает главные требования к спецификациям. Применительно к
функциональным спецификациям подразумевается, что:
• требование полноты означает, что спецификации должны содержать всю существенную
информацию, где ничего важного не было бы упущено, и отсутствует несущественная информация, например детали реализации, чтобы не препятствовать разработчику в выборе
манипулирования, то, как указывалось выше, это практически однозначно предполагает
использование событийного программирования и объектного подхода, так как современные среды
визуального программирования, такие как Visual C++, Delphi, Builder C++ и им подобные,
предоставляют интерфейсные компоненты именно в виде объектов библиотечных классов. При
этом в зависимости от сложности предметной области программное обеспечение может
реализовываться как с использованием объектов и, соответственно, классов, так и чисто
процедурно. Исключение составляют случаи использования специализированных языков
разработки Интернет-приложений, таких как Perl, построенных по совершенно другому принципу.
Примитивный интерфейс и интерфейс типа меню совместимы как со структурным, так и с
объектным подходами к разработке. Поэтому выбор подхода осуществляют с использованием
дополнительной информации.
Практика показывает, что объектный подход эффективен для разработки очень больших
программных систем (более 100000 операторов универсального языка программирования) и в тех
случаях, когда объектная структура предметной области ярко выражена.
Следует также учитывать, что необходимо осторожно использовать объектный подход при
жестких ограничениях на эффективность разрабатываемого программного обеспечения, например,
при разработке систем резального времени.
Во всех прочих случаях выбор подхода остается за разработчиком.
Выбор языка программирования.
Язык может быть определен:
• организацией, ведущей разработку;
• программистом, который по возможности всегда будет использовать хорошо знакомый язык;
• устоявшимся мнением:
Если же все-таки выбор языка реально возможен, то нужно иметь в виду, что все существующие языки программирования можно разделить на следующие группы:
• универсальные языки высокого уровня;
• специализированные языки разработчика программного обеспечения(языки баз данных; языки создания сетевых приложений; языки создания систем искусственного интеллекта и т. д.)
• специализированные языки пользователя (обычно являются частью профессиональных сред пользователя, характеризуются узкой направленностью и разработчиками ПО не используются.)
• языки низкого уровня. (позволяют осуществлять программирование практически на уровне машинных команд)
Выбор среды программирования. Средой программирования называют программный
комплекс, который включает специализированный текстовый редактор, встроенные компилятор,
компоновщик, отладчик, справочную систему и другие программы, использование которых
упрощает процесс написания и отладки программ. (Delphi, C++ Builder и Visual C).
Выбор или формирование стандартов разработки. Реальное применение любой технологии
проектирования требует формирования или выбора ряда стандартов, которые должны
соблюдаться всеми участниками проекта:
• стандарт проектирования;
• стандарт оформления проектной документации;
• стандарт интерфейса пользователя.
Стандарт проектированиядолжен определять:
• набор необходимых моделей (схем, диаграмм) на каждой стадии проектирования и степень
их детализации;
• правила фиксации проектных решений на диаграммах, в том числе правила именования
объектов и соглашения по терминологии, набор атрибутов для всех объектов и правила их
заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и
размерам объектов;
• требования к конфигурации рабочих мест разработчиков, включая настройки операционной
системы и используемых CASE-средств;
• механизм обеспечения совместной работы над проектом, в том числе и правила интеграции
подсистем проекта и анализа проектных решений на непротиворечивость.
Стандарт оформления проектной документациидолжен регламентировать:
• комплектность, состав и структуру документации на каждой стадии;
• требования к ее содержанию и оформлению;
• правила подготовки, рассмотрения, согласования и утверждения документов.
Стандарт интерфейса пользователядолжен определять:
• правила оформления экранов (шрифты и цветовую палитру), состав и расположение окон и
элементов управления;
• правила пользования клавиатурой и мышью;
• правила оформления текстов помощи;
• перечень стандартных сообщений;
• правила обработки реакции пользователя.
-
Планирование процесса проектирования, виды планов: календарный, индивидуальный, сетевой график разработки и проектирования программного обеспечения.
Основная цель календарного планирования - выдача информации для подготовки производства на планируемый период.
Календарное планирование проекта, которое состоит в определении календарных дат выполнения всех работ, ставит цель координацию деятельности привлеченных к проекту исполнителей для обеспечения его успешного завершения.
В календарных графиках (способу вывода данных ) отмечается возможная гибкость в дате начала работы без осложнения выполнения всего проекта (т.е. запас времени по некритическим роботам).
Цели календарного графика:
- обеспечить своевременное поступление финансирования;
- координировать поступление ресурсов;
- своевременно обеспечить нужны ресурсы;
-предусмотреть в разные моменты уровень нужных финансовых затрат и ресурсов и рациональное распределение их между проектами;
-обеспечить своевременное выполнение проекта.
4.2. Функции программного обеспечения для календарного планирования
Как правило, система календарного планирования, обеспечивает основной набор функциональных возможностей, которые включают в себя:
- средства визуального проектирования структуры работ проекта,
- средства планирования по методу критического пути,
- средства ресурсного планирования (описание, назначение и оптимизация загрузки ресурсов),
- некоторые возможности стоимостного анализа,
- средства контроля за ходом исполнения проекта,
- средства создания отчетов и графических диаграмм,
-
средства организации групповой работы.
4.3. Виды календарного планирования (календарные графики, диаграммы Гантта)
Существует два приемлемых пути представления календарного графика:
- табличный — с перечнем работ с указанием продолжительности их выполнение;
- диаграммный (балочные диаграммы, или диаграммы Гантта).
диаграмма Гантта является наглядным источником такой проектной информации:
- какие работы являются критическими, а какие - некритическими;
- вывод и использование затрат проекта и т.д.
Диаграммы Гантта:
-легко строится и прочитывается;
- разрешает наглядно подать ход выполнения работ за проектом;
- дает возможность легче понять идею запаса времени и его использование;
- является предпосылкой календарного планирования нужд в ресурсах;
- является условием определения денежных потоков;
- является прекрасным средством планирования и контроля;
- является ключевым документом в процессе принятия решений.
Прежде чем строить диаграмму Гантта, нужно определить:
- логическую связь между работами;
-продолжительность работ в зависимости от ресурсов, которые используются;
- распределение ресурсов между роботами в зависимости от их наличия.
Поэтому календарное планирование нуждается в не только определении сроков выполнения работ, но и согласование их с состоянием обеспечения необходимыми ресурсами и возможностью финансирования.
-
Структурный подход к проектированию программного обеспечения: основные принципы, лежащие в основе структурного подхода, средства описания функциональной структуры, средства описания отношения между данными, применение средств на стадиях жизненного цикла программного обеспечения.
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:
-
принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; -
принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
-
принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных; -
принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы; -
принцип непротиворечивости - заключается в обоснованности и согласованности элементов; -
принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
-
SADT модели и соответствующие функциональные диаграммы; -
DFD диаграммы потоков данных; -
ERD диаграммы "сущность-связь".
-
Спецификации ПО при структурном подходе: формальные модели, зависящие от подхода к разработке и не зависящие от подхода – диаграммы переходов состояний, математические модели предметной области.
Спецификации представляют собой полное и точное описание функций и ограничений разрабатываемого ПО. При этом одна часть спецификаций (функциональные) описывает функции разрабатываемого программного обеспечения, а другая часть (эксплуатационные) определяет требования к техническим средствам, надежности, информационной безопасности и т. д.
Определение отражает главные требования к спецификациям. Применительно к
функциональным спецификациям подразумевается, что:
• требование полноты означает, что спецификации должны содержать всю существенную
информацию, где ничего важного не было бы упущено, и отсутствует несущественная информация, например детали реализации, чтобы не препятствовать разработчику в выборе