2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Особенности разработки и выпуска

Особенности разработки и выпуска

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

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

Разработке ПО присущ ряд специфических особенностей.

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

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

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

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

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

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

Анализ надежности элементов (конкретно для ИС) показывает, что примерно

40 — 45% всех отказов возникает из-за ошибок на этапе проектирования,

30 % — от неправильной эксплуатации,

25-30 % – от всех остальных причин (ошибок, допущенных при производстве, отестественного старения).

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

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

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

Основные задачи теории надежности сложных ПС

Учитывая особенности разработки ПО, из теории надежности технических систем выделилось направление – надежность программных средств. К основным задачам этого направления можно отнести:

1) формулирование основных понятий, используемых при исследовании и применении показателей надежности программных средств (ПС);

2) выявление и исследование основных факторов, определяющих характеристики сложных программных комплексов;

3) выбор и обоснование критериев надежности для комплексов программ различного типа и назначения;

4) исследование дефектов и ошибок, динамики их изменения при отладке и сопровождении, а также влияния на показатели надежности ПС;

5)исследование методов и средств контроля и защитыпутем использования различных видов избыточности;

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

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

Модели разработки программного обеспечения

Предисловие

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

Эта статья — начало большого цикла статей о разработке ПО, который включит в себя:

  • популярные модели;
  • популярные методики;
  • подробней об «Agile» и фреймворках гибкой разработки.

Общая информация о разработке ПО

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

  • Э. Деминг — американский учёный, статистик и консультант по менеджменту. Больше всего известен благодаря усовершенствованному циклу Шухарта, после этого названному циклом Деминга;
  • Дж. Джуран — американский специалист в области качества, академик Международной академии качества (МАК). Автор множества книг по менеджменту и теории качества. Дж. Джуран первым обосновал переход от контроля качества к управлению качеством;
  • Ф. Кросби — бизнесмен и автор нескольких книг по теории качества, который внес вклад в теорию менеджмента и практики менеджмента качества. В 1979 году Кросби основал консалтинговую компанию по управлению финансами Philip Crosby Associates, Inc.

Благодаря этим известным личностям, были разработаны методы построения качества и менеджмента на производствах. С течением времени теория качества вышла за пределы производств, повлияв на многие сферы. Одной из них является разработка программного обеспечения.

К ключевым процессам разработки ПО относятся:

  1. Анализ — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей и документирование;
  2. Проектирование — процесс создания проекта программного обеспечения (ПО);
  3. Программирование — процесс создания компьютерных программ;
  4. Документирование — печатные руководства пользователя, диалоговая (оперативная) документация и справочный текст, описывающие, как пользоваться программным продуктом;
  5. Тестирование —- процесс исследования, испытания программного продукта, цель которого — проверка соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определенным образом.

К основным типам рисков разработки ПО относятся:

  1. Непродуманные сроки и нереалистичный бюджет;
  2. Отсутствие квалифицированных разработчиков;
  3. «Плавающие» требования;
  4. Трата большого количества ресурсов на оптимизацию;
  5. Слабая производительность системы;
  6. Разная классификация специалистов из разных отделов.

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

Итеративный метод

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

Итеративная модель используется при построении «гибких» (Agile) методов в разработке ПО.

Преимущества итеративного подхода:

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

Недостатки итеративного подхода:

  • при отсутствии четких требований к проекту, возможны проблемы при разработке архитектуры проекта;
  • требуется постоянное вовлечение в процесс заказчика;
  • отсутствие устойчивых сроков и бюджета.
  • Итерационная модель достаточно универсальна и может использоваться в большинстве проектов, командами разной квалификации, но, при этом, желательно создать «внутренние правила» для работы с данной моделью.
Читать еще:  Для чего производится обкатка

Каскадная модель (waterfall model)

Процесс разработки в модели расположен последовательно и включает в себя:

  • анализ;
  • проектирование;
  • реализацию;
  • тестирование;
  • интеграцию;
  • поддержку.

Первым описание модели считают статью, опубликованную У. У. Ройсом в 1970 году.

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

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

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

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

Преимущества каскадной модели:

  • Подробное документирование всех этапов;
  • возможность определить четкие сроки и бюджет;
  • прозрачность разработки для всех участников.

Недостатки каскадной модели:

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

Каскадную модель желательно использовать в проектах, где четко определены требования и не предвидятся какие-либо изменения в процессе разработки. Также команда разработки может использовать каскадную модель, если часть разработки ПО отдана на аутсорсинг — например, тестированием будет заниматься сторонняя команда или компания.

Спиральная модель

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

Преимущества спиральной модели:

  • подробный анализ рисков;
  • подробная документация процесса разработки ПО;
  • возможность вносить изменения на каждом этапе разработки;
  • быстрое создание MVP(Минимально готовый продукт).

Недостатки спиральной модели:

  • может быть ресурсозатратной;
  • требует высококвалифицированных специалистов;
  • реализация очень сильно зависит от анализа рисков.

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

V-Model

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

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

Преимущества V-модели:

  • строгое разделение на этапы;
  • тестирование начинается уже на ранних этапах;
  • экономия времени за счет параллельного тестирования;
  • тестирование каждого этапа.

Недостатки V-модели похожи на недостатки каскадной модели, к ним можно отнести:

  • отсутствие гибкости;
  • недостаточный анализ рисков;
  • невозможность внести изменение на текущем этапе и продолжить дальше разработку.

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

Резюме

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

Для более подробного изучения моделей можно изучить данную литературу:

  1. Richard W. Selby. Software Engineering: Barry W. Boehm’s Lifetime Contributions to Software Development, Management, and Research.
  2. Эрик Брауде. Технология разработки программного обеспечения
  3. Мартин Фаулер.Рефакторинг.
  4. Стив Макконнелл. Совершенный код

Поделиться

Для авторов

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

Программирование на C, C# и Java

Уроки программирования, алгоритмы, статьи, исходники, примеры программ и полезные советы

ОСТОРОЖНО МОШЕННИКИ! В последнее время в социальных сетях участились случаи предложения помощи в написании программ от лиц, прикрывающихся сайтом vscode.ru. Мы никогда не пишем первыми и не размещаем никакие материалы в посторонних группах ВК. Для связи с нами используйте исключительно эти контакты: vscoderu@yandex.ru, https://vk.com/vscode

Технология разработки программного обеспечения

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

Технология разработки программного обеспечения (ПО) – это комплекс мер по созданию программных продуктов (ПП). Данная деятельность включает в себя несколько этапов, с которыми так или иначе придётся столкнуться при разработке достаточно крупного ПО.

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

Жизненный цикл программы

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

  • Процесс приобретения. Данный процесс представляет собой действия заказчика разработки ПО, и обычно включает в себя такие мероприятия, как: формирование требований и ограничений к программному продукту (ограничения могут быть связаны с выбором программной архитектуры, а также с приемлемым быстродействием системы и т.д.); заключение договора на разработку; анализ и аудит работы исполнителя. В конце данного процесса заказчик осуществляет приёмку готового программного продукта.
  • Процесс поставки включает в себя мероприятия, проводимые исполнителем по поставке ПО. Исполнитель анализирует требования заказчика, выполняет проектирование и анализ работ, решает, как будет происходить процесс конструирования (программирования): своими силами, либо же с привлечением сторонних команд разработки (подрядчика), также осуществляет оценку и контроль качества готового программного продукта и выполняет непосредственно поставку продукта и сопутствующие завершающие мероприятия.
  • Процесс разработки. Его мы подробно рассмотрим в разделе “Этапы создания программных продуктов”.
  • Процесс эксплуатации. После того, как программное обеспечение будет готово, начинается процесс его эксплуатации организацией-заказчиком и её операторами.
  • Процесс сопровождения. Фирма-разработчик осуществляет поддержку пользователей программного продукта в случае возникновения у них каких-либо вопросов или проблем. Если в процессе эксплуатации будет обнаружена ошибка в ПП, разработчики должны её устранить. Процесс эксплуатации и процесс сопровождения идут параллельно.

Вспомогательные процессы

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

  • Процесс документирования. В процессе разработки и далее исполнитель пишет документацию и руководства пользователя к разрабатываемому программному продукту. Данные документы помогут разработчикам [вспомнить/разобраться] структуру и код ПО (ибо со временем всё забывается, особенно в больших проектах), а пользователям освоить работу с программой.
  • Процесс управления конфигурацией. Данный процесс включается в себя работы по управлению наборами разрабатываемых компонентов ПО и по управлению версиями ПП.
  • Процесс обеспечения качества. Он отвечает за то, чтобы разрабатываемый программный продукт соответствовал предварительным требованиям к разработке, а также стандартам организаций исполнителя и заказчика.
  • Процесс верификации. Нужен для того, чтобы выявить ошибки внесённые в ПО во время конструирования, а также выявить несоответствия разрабатываемого ПО выработанной архитектуре.
  • Процесс аттестации. Процесс направлен на подтверждение соответствия получаемых величин эталонным. То есть, выходные данные должны иметь погрешность, удовлетворяющую требованиям и установленным стандартам.
  • Процесс совместной оценки. Нужен для контроля и проверки состояния персонала и разрабатываемого программного продукта. Выполняется обеими сторонами (заказчиком и исполнителем) на протяжении времени всех работ по проекту.
  • Процесс аудита. Аудит направлен на независимую оценку текущих положений, состояния проекта, документации и отчетов. При аудите выполняется сравнение с договором и документами, определяющими стандарты. Может выполняться также обеими сторонами.
  • Процесс разрешения проблем. Реализует устранение недочётов, выявленных во время всех процессов связанных к контролем и оценкой.
Читать еще:  Технические характеристики дэт 250

Организационные процессы жизненного цикла программного продукта

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

Организационные процессы жизненного цикла программного обеспечения включают:

  • Процесс управления, который направлен на грамотное и эффективное управлением персоналом компании-исполнителя. За это отвечают люди, находящиеся на руководящих постах, а также специальный отдел в фирме.
  • Процесс создания инфраструктуры. Разработка программных продуктов требует наличия огромного количества инфраструктурных компонентов: компьютеров, серверов, специальных программ для разработки и т.д. Кроме того, готовый продукт требует наличия определённых единиц для его работы. Данный процесс необходим для подготовки оборудования и ПО для разработчиков, а также для успешного функционирования готового ПП у заказчика.
  • Процесс усовершенствования. Направлен на усовершенствование всех остальных процессов жизненного цикла программного обеспечения. Усовершенствование может повысить производительность разработчиков и добиться большей выгоды от выполнения заказа на производство программы.
  • Процесс обучения. Постоянное обучение сотрудников и повышение их квалификации – это залог производства качественных продуктов и программ. Процесс обучения направлен на организацию мероприятий для повышения уровня и получения новых навыков сотрудниками компании-разработчика.

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

Приведём все основные этапы создания программного продукта. Всего их пять. Они так или иначе характерны для любой методологии разработки ПО: будь то классическая водопадная, либо современные гибкие методологии (Agile software development) – во всех из них разработчики проходят через следующие этапы создания программного обеспечения:

  1. Составление требований заказчика. На данном эта производится работа с заказчиком и документирование его видения и его требований к программе. В подавляющем большинстве случаев данный этап проходит трудно. Поскольку, слабо разбираясь в особенностях разработки ПО, заказчик плохо представляет себе, что нужно знать разработчикам и (самое главное!), что им нужно сообщить о продукте.
    Выработка требований чрезвычайно важное мероприятие. Убедитесь, что все требования полностью понятны вам и вашей команде.
  2. Проектирование программного продукта. Разобравшись в предметной области, разработчики приступают к проектированию. На данном этапе создания программного продукта разрабатывается архитектура компонентов ПО, выбираются нужные шаблоны проектирования (паттерны) и составляется схема информационной базы данных системы.
  3. Разработка. Когда требования сформулированы и архитектура готова – команда начинает разработку ПП. На этапе разработки также выполняется документирование системы.
  4. Тестирование. После разработки необходимо произвести тестирование системы в целом, тем самым подтвердить её соответствие требованиям заказчика.
    Здесь стоит сказать, что модульные тесты (unit-тесты; т.е. тесты отдельных частей программы) обычно выполняются на этапе разработки программистом, разрабатывавшем конкретный модуль.
    Когда все тесты пройдены, программное обеспечение готово к выпуску.
  5. Сопровождение ПП. После выпуска фирма-разработчик отвечает за поддержку программного продукта и выпуска новых версий, которые исправляют ошибки и привносят новый функционал. Также необходимо осуществлять поддержку пользователей разработанного ПО.

Примечание 1: Следует как можно тщательнее подходить к формированию предварительных требований и проектированию, поскольку стоимость исправления ошибок после выпуска ПО, допущенных на этих этапах, обычно в 2-10 (!) раз выше, чем стоимость исправления ошибок сделанных на этапе программирования (Стив Макконнелл “Совершенный код”).

Примечание 2: Очень часто случается, что заказчик уже после составления требований к ПО (т.е. во время проектирования и разработки) объявляется и радостно сообщает исполнителю свои новые идеи или рассказывает о какой-нибудь “классной” функции, которую нужно добавить в приложение… Бывают случаи, когда это труднореализуемо и сопряжено с пересмотром архитектуры. В данной ситуации можно посоветовать сказать разработчику примерно следующее: “Отлично придумано! Мне нравится! Тогда я пересмотрю свою смету и сроки работы и потом сообщу Вам!”. Практически всегда это срабатывает и гасит пыл заказчика, и он отказывается от новых идей и изменений в проекте.

Модели жизненного цикла

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

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

Каскадная (водопадная) модель

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

V-образная модель разработки

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

Модель прототипирования

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

Модель быстрой разработки (RAD-модель)

RAD-модель (rapid application development — быстрая разработка приложений) ориентирована в первую очередь на быстроту и удобство программирования. Команда делает акцент именно на разработке, а большая часть работы по составлению требований и описанию пользователей возлагается на заказчика.

Итерационная модель

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

Спиральная модель

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

Гибкие методологии

Гибкие методологии (Agile) олицетворяют современные подходы к разработке ПО. Они используются обычно в небольших командах разработчиков. Среди них такие модели жизненного цикла программного продукта, как Scrum, DSDM, XP, FDD и другие. Вы можете посмотреть видео про одну из гибких методологий: экстремальное программирование.

Вот мы и рассмотрели тему, связанную с технологией разработки программного обеспечения. Если есть вопросы – задавайте их в комментариях. Спасибо за прочтение статьи!

ОСОБЕННОСТИ РАЗРАБОТКИ ОПЕРАТИВНО-КАЛЕНДАРНЫХ ПЛАНОВ

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

Оперативное планирование осуществляется каждым производственным цехом на основе собственных производственных программ. Задания участкам, бригадам формируются с учетом возможности их выполнения на каждом рабочем месте. Разрабатываются оперативно-календарные планы запуска — выпуска изделий и сменно-суточные задания.

Читать еще:  Технология укладки холодного асфальта

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

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

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

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

Число запусков каждой партии деталей может быть различным. Если запусков больше одного, то в ОКП выпуск каждой партии деталей следует чередовать с соответственно рассчитанной периодичностью запуска — выпуска, добиваясь равных промежутков времени между выпусками партий деталей одного наименования. В серийном производстве определяется периодичность запусков в обработку или число запусков для каждой партии деталей. Затраты времени на переналадку оборудования при переходе от обработки одной партии деталей к другой должны быть минимальными. Это достигается строгим закреплением деталей за одними и теми же станками. Иногда для сокращения простоя станка устанавливают определенную последовательность подачи деталей на обработку, заменяя наладку подналадкой.

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

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

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

Уточним некоторые определения.

Деталь — предмет, который не может быть разделен на части без разрушения его.

Сборочная единица (узел) — разъемное или неразъемное соединение нескольких деталей.

Комплект — соединение нескольких сборочных единиц и деталей.

Партия — количество одинаковых предметов, обрабатываемых или собираемых на операции непрерывно.

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

Очередность запуска может быть выражена рядом чисел, каждое из которых показывает, на сколько дней процесс сборки изделия обеспечен данной деталью к моменту выхода из обработки очередной партии. Эти числа отражают очередность запуска партии деталей в обработку. Определение показателей очередности является одним из основных элементов разработки ОКП [7, с. 49].

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

Оперативно-календарные планы могут разрабатываться с разной степенью детализации: укрупненно — применительно к партии деталей в соответствии с расчетными циклами обработки и периодичностью запуска; дифференцированно, т.е. применительно к каждой операции для каждой партии деталей.

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

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

Элементарные приоритеты можно сформулировать так:

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

Сложные приоритеты — это вариантные приоритеты (рис 3.3).

Рис. 3.3. Вариантные приоритеты запуска деталей в обработку

Комплексный приоритет определяется по формуле

где Jj — комплексный приоритет г-й детали;

Kj — весовые коэффициенты значимости элементарных приоритетов; Fj: — значение j-го элементарного приоритета по ;-й детали.

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

где 7’„j OCT — остаточный цикл обработки, дни;

И’ — обеспеченность сборки деталями, дни.

Показатель очередности по каждой из партий деталей может принимать три значения:

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

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

При организации обработки деталей поточными методами можно использовать последовательный и параллельно-последовательный вид движения.

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

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

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

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector