Наша предыдущая лекция целиком была посвящена знакомству с терминологией и введению в предмет. Сформулируем кратко некоторые выводы:
Причина 1. Нереалистичные временные рамки.
Причина 2. Недостаток количества исполнителей.
Причина 3. Размытые границы проекта.
Причина 4. Недостаток средств.
Причина 5. Нехватка квалифицированных кадров.
При написании данной лекции активно использовались материалы Иана Соммервилля (Ian Sommerville) - одного из наиболее уважаемых авторов в данной области.
Источник (на английском языке):
Источник (на русском языке):
В предыдущей лекции мы познакомились с базовыми понятиями и обсудили ряд проблем, которые возникают при разработке программного обеспечения. В данной лекции мы кратко рассмотрим основные понятия
Говоря о
За ответом обратимся к Большой Советской Энциклопедии:
Инженер (франц. ingenieur, от лат. ingenium - способность, изобретательность), специалист с высшим техническим образованием. Первоначально - название лиц, управлявших военными машинами [2.5].
Понятие гражданский инженер появилось в 16 в. в Голландии применительно к строителям мостов и дорог, затем в Англии и др. странах. Первые учебные заведения для подготовки инженеров были созданы в 17 в. в Дании, в 18 в. - в Великобритании, Франции, Германии, Австрии и др. В России первая инженерная школа основана Петром I в 1712 в Москве. В Петербурге были открыты Горное училище, приравненное к академиям (1773), Институт инженеров путей сообщения (1809), Училище гражданских инженеров (1832, с 1882 - Институт гражданских инженеров), Инженерная академия (1855). С 19 в. за рубежом стали различать инженеров-практиков, или профессиональных инженеров (по существу специалистов, имевших квалификацию техника), и дипломированных инженеров, получивших высшее техническое образование (Civil Engineer) [2.5].
Итак, инженер - дипломированный специалист, имеющий высшее техническое образование. Нетрудно догадаться, что программный инженер - инженер в области разработки программного обеспечения.
Теперь попробуем ответить на вопрос, что такое
Как было выяснено ранее, программное обеспечение представляет собой собственно программы плюс вся сопутствующая документация. На протяжении последних десятилетий стоимость разработки ПО неуклонно растет, в результате чего эта стоимость становится весьма высокой.
В западной литературе часто используются термины:
Итак,
Всем этим занимается
Целями
Разберем по очереди эти вопросы.
Если вы создали продукт, который не нужен конечным пользователям, вы не сможете его продать и не только не получите прибыль, но и не окупите затраты на его создание.
ПО должно допускать развитие в связи с изменением
Возможные неполадки в работе не должны нанести существенный, тем более невосполнимый, ущерб. Если ваша программа рассчитывает орбиту полета спутника, вам придется потратить уйму времени на то, чтобы убедиться, что она работает правильно.
ПО должно эффективно использовать имеющиеся ресурсы. Вряд ли клиент согласится полностью поменять свою аппаратную базу без должного обоснования. Вот в этот момент и придется задуматься об алгоритмической оптимизации, оптимизации кода…
ПО должно приниматься пользователями "на ура", работа должна быть удобной и естественной. Помните, что персонал, которому предстоит работать с программой, скорее всего не придет в восторг от ее появления. Постарайтесь сделать процесс обучения как можно более простым.
Если вы не укладываетесь в бюджет, вам придется просить дополнительные деньги на разработку. Иногда вам пойдут на встречу, иногда нет. В любом случае, ваша репутация пострадает. Посмотрим, из чего чаще всего состоят расходы на создание ПО:
Думая о том, сколько денег потратить разработку, не забывайте, что последующие этапы отнимут не меньше средств.
Расходы на развитие иногда могут превысить расходы на создание, впрочем, многое тут зависит от того, как вы выполнили проектирование. Детали зависят от специфики предметной области, требований к ПО, используемых подходов к организации разработки.
Залог успеха - строгое соблюдение следующих принципов:
Взаимодействие с научной средой - один из способов повышения эффективности деятельности. Возможная выгода от сотрудничества с учеными:
Помощь ученых жизненно необходима в по крайней мере в двух ситуациях:
Этот подход широко применяется современными IT-компаниями: Intel, Microsoft, IBM и другими.
Сразу оговоримся, что по данному разделу написано немало литературы. Существуют многостраничные книги, ГОСТ-ы, стандарты... На сегодняшний день мы можем смело утверждать, что при некотором общем теоретическом (философском) и практическом понимании того, что происходит в отрасли, и что нужно делать для лучшей организации при создании программного обеспечения, терминология в данной области абсолютно не устоялась. Мы в данном курсе ориентируемся на вариант И. Соммервилля. При этом рекомендуем ознакомиться и с другими книгами и материалами. Каждая новая книга предложит вам новую терминологию. Не пугайтесь этого. Пройдет время, и терминология устоится. Общий смысл изложения во многих книгах по
Процесс создания программного обеспечения - совокупность мероприятий, целью которых является создание или модернизация программного обеспечения [2.1, 2.2, 2.3].
Выделяют 4 основных мероприятия (стадии) процесса:
Спецификация: формулирование спецификаций определяет основные требования к ПО (что должна делать система).
Разработка: создание ПО в соответствии со спецификациями.
Аттестация: проверка ПО на соответствие потребностям заказчика.
Модернизация: развитие ПО в соответствии с изменившимися потребностями заказчика.
Все стадии основаны на специальных технологиях. Например, рассмотренные кратко в предыдущей лекции модульное, структурное, объектно-ориентированное,
Каждая организация может организовать процесс создания программного обеспечения так, как ей это представляется разумным. Этот процесс может иметь разную степень формализации. Так, создание продукта может идти по принципу "вечером обсудили и договорились", но этот принцип работает только для команд из 2-3 человек в достаточно простых проектах. Возможна другая крайность - каждое действие жестко определено и прописано в описании процесса. В этом случае возникает необходимость длительного предварительного обучения сотрудников работе в рамках этого, безусловно, сложного описания. Подобный подход, конечно, порождает и другие накладные расходы. Например, то, что вполне могло бы быть решено в частной беседе, теперь приходится долго и нудно "проводить" через соответствующий
Несмотря на естественные отличия в описаниях процессов, как правило, в нем присутствуют рассмотренные стадии. Они могут иначе называться, детализироваться, но от них никуда не уйти.
Существуют известные, хорошо проработанные процессы:
Эти процессы (ко второму в большей степени применим термин методология) имеют свои разновидности и могут применяться как для малых и средних компаний и проектов, так и для больших.
Итак, некий "каркас" процесса обычно выглядит так:
Сам этот "каркас" можно приводить в жизнь по-разному. Существуют общие
Рассмотрим некоторые устоявшиеся
Суть
Достоинства
Суть эволюционной модели состоит в том, что многие стадии повторяются неоднократно. Так, после
Недостатки
Часто подходы, перечисленные ранее, используются в совокупности. В том смысле, что на некоторых стадиях при их детализации можно пользоваться как каскадной, так и эволюционной моделью. Полезность этого обусловлена реальными условиями, в которых, в частности, требования почти всегда меняются в ходе разработки. Соответственно, необходимо иметь возможность адекватно реагировать, а именно, выполнять новую итерацию, заново проходя все или почти все этапы с целью создания того, что будет удовлетворять пожеланиям пользователя.
Рассмотрим две популярные гибридные модели, использующих различные особенности перечисленных выше моделей, и основанные на итерациях.
Модель пошаговой разработки (Миллс) состоит в выполнении стандартных шагов. В итоге каждого шага - работающий прототип. Требования фиксированы во время шага. Для шага можно применять каскадную или эволюционную модель.
Особенность состоит в том, что наиболее важные для заказчика компоненты разрабатываются в самом начале, в результате чего он может оценить, насколько конечный продукт будет соответствовать его потребностям, и при необходимости внести коррективы.
Одно из ответвлений -
Каждый виток разбит на 4 сектора: определение
На каждом витке спирали могут применяться разные
Главное отличие от других моделей состоит в акценте на анализ и преодоление рисков (об этом мы еще будем говорить более подробно в 3 разделе нашего курса).
Тема следующей лекции -
Основы
Наша предыдущая лекция целиком была посвящена знакомству с терминологией и введению в предмет. Сформулируем кратко некоторые выводы:
Причина 1. Нереалистичные временные рамки.
Причина 2. Недостаток количества исполнителей.
Причина 3. Размытые границы проекта.
Причина 4. Недостаток средств.
Причина 5. Нехватка квалифицированных кадров.
При написании данной лекции активно использовались материалы Иана Соммервилля (Ian Sommerville) - одного из наиболее уважаемых авторов в данной области.
Источник (на английском языке):
Источник (на русском языке):
В предыдущей лекции мы познакомились с базовыми понятиями и обсудили ряд проблем, которые возникают при разработке программного обеспечения. В данной лекции мы кратко рассмотрим основные понятия
Говоря о
За ответом обратимся к Большой Советской Энциклопедии:
Инженер (франц. ingenieur, от лат. ingenium - способность, изобретательность), специалист с высшим техническим образованием. Первоначально - название лиц, управлявших военными машинами [2.5].
Понятие гражданский инженер появилось в 16 в. в Голландии применительно к строителям мостов и дорог, затем в Англии и др. странах. Первые учебные заведения для подготовки инженеров были созданы в 17 в. в Дании, в 18 в. - в Великобритании, Франции, Германии, Австрии и др. В России первая инженерная школа основана Петром I в 1712 в Москве. В Петербурге были открыты Горное училище, приравненное к академиям (1773), Институт инженеров путей сообщения (1809), Училище гражданских инженеров (1832, с 1882 - Институт гражданских инженеров), Инженерная академия (1855). С 19 в. за рубежом стали различать инженеров-практиков, или профессиональных инженеров (по существу специалистов, имевших квалификацию техника), и дипломированных инженеров, получивших высшее техническое образование (Civil Engineer) [2.5].
Итак, инженер - дипломированный специалист, имеющий высшее техническое образование. Нетрудно догадаться, что программный инженер - инженер в области разработки программного обеспечения.
Теперь попробуем ответить на вопрос, что такое
Как было выяснено ранее, программное обеспечение представляет собой собственно программы плюс вся сопутствующая документация. На протяжении последних десятилетий стоимость разработки ПО неуклонно растет, в результате чего эта стоимость становится весьма высокой.
В западной литературе часто используются термины:
Итак,
Всем этим занимается
Целями
Разберем по очереди эти вопросы.
Если вы создали продукт, который не нужен конечным пользователям, вы не сможете его продать и не только не получите прибыль, но и не окупите затраты на его создание.
ПО должно допускать развитие в связи с изменением
Возможные неполадки в работе не должны нанести существенный, тем более невосполнимый, ущерб. Если ваша программа рассчитывает орбиту полета спутника, вам придется потратить уйму времени на то, чтобы убедиться, что она работает правильно.
ПО должно эффективно использовать имеющиеся ресурсы. Вряд ли клиент согласится полностью поменять свою аппаратную базу без должного обоснования. Вот в этот момент и придется задуматься об алгоритмической оптимизации, оптимизации кода…
ПО должно приниматься пользователями "на ура", работа должна быть удобной и естественной. Помните, что персонал, которому предстоит работать с программой, скорее всего не придет в восторг от ее появления. Постарайтесь сделать процесс обучения как можно более простым.
Если вы не укладываетесь в бюджет, вам придется просить дополнительные деньги на разработку. Иногда вам пойдут на встречу, иногда нет. В любом случае, ваша репутация пострадает. Посмотрим, из чего чаще всего состоят расходы на создание ПО:
Думая о том, сколько денег потратить разработку, не забывайте, что последующие этапы отнимут не меньше средств.
Расходы на развитие иногда могут превысить расходы на создание, впрочем, многое тут зависит от того, как вы выполнили проектирование. Детали зависят от специфики предметной области, требований к ПО, используемых подходов к организации разработки.
Залог успеха - строгое соблюдение следующих принципов:
Взаимодействие с научной средой - один из способов повышения эффективности деятельности. Возможная выгода от сотрудничества с учеными:
Помощь ученых жизненно необходима в по крайней мере в двух ситуациях:
Этот подход широко применяется современными IT-компаниями: Intel, Microsoft, IBM и другими.
Сразу оговоримся, что по данному разделу написано немало литературы. Существуют многостраничные книги, ГОСТ-ы, стандарты... На сегодняшний день мы можем смело утверждать, что при некотором общем теоретическом (философском) и практическом понимании того, что происходит в отрасли, и что нужно делать для лучшей организации при создании программного обеспечения, терминология в данной области абсолютно не устоялась. Мы в данном курсе ориентируемся на вариант И. Соммервилля. При этом рекомендуем ознакомиться и с другими книгами и материалами. Каждая новая книга предложит вам новую терминологию. Не пугайтесь этого. Пройдет время, и терминология устоится. Общий смысл изложения во многих книгах по
Процесс создания программного обеспечения - совокупность мероприятий, целью которых является создание или модернизация программного обеспечения [2.1, 2.2, 2.3].
Выделяют 4 основных мероприятия (стадии) процесса:
Спецификация: формулирование спецификаций определяет основные требования к ПО (что должна делать система).
Разработка: создание ПО в соответствии со спецификациями.
Аттестация: проверка ПО на соответствие потребностям заказчика.
Модернизация: развитие ПО в соответствии с изменившимися потребностями заказчика.
Все стадии основаны на специальных технологиях. Например, рассмотренные кратко в предыдущей лекции модульное, структурное, объектно-ориентированное,
Каждая организация может организовать процесс создания программного обеспечения так, как ей это представляется разумным. Этот процесс может иметь разную степень формализации. Так, создание продукта может идти по принципу "вечером обсудили и договорились", но этот принцип работает только для команд из 2-3 человек в достаточно простых проектах. Возможна другая крайность - каждое действие жестко определено и прописано в описании процесса. В этом случае возникает необходимость длительного предварительного обучения сотрудников работе в рамках этого, безусловно, сложного описания. Подобный подход, конечно, порождает и другие накладные расходы. Например, то, что вполне могло бы быть решено в частной беседе, теперь приходится долго и нудно "проводить" через соответствующий
Несмотря на естественные отличия в описаниях процессов, как правило, в нем присутствуют рассмотренные стадии. Они могут иначе называться, детализироваться, но от них никуда не уйти.
Существуют известные, хорошо проработанные процессы:
Эти процессы (ко второму в большей степени применим термин методология) имеют свои разновидности и могут применяться как для малых и средних компаний и проектов, так и для больших.
Итак, некий "каркас" процесса обычно выглядит так:
Сам этот "каркас" можно приводить в жизнь по-разному. Существуют общие
Рассмотрим некоторые устоявшиеся
Суть
Достоинства
Суть эволюционной модели состоит в том, что многие стадии повторяются неоднократно. Так, после
Недостатки
Часто подходы, перечисленные ранее, используются в совокупности. В том смысле, что на некоторых стадиях при их детализации можно пользоваться как каскадной, так и эволюционной моделью. Полезность этого обусловлена реальными условиями, в которых, в частности, требования почти всегда меняются в ходе разработки. Соответственно, необходимо иметь возможность адекватно реагировать, а именно, выполнять новую итерацию, заново проходя все или почти все этапы с целью создания того, что будет удовлетворять пожеланиям пользователя.
Рассмотрим две популярные гибридные модели, использующих различные особенности перечисленных выше моделей, и основанные на итерациях.
Модель пошаговой разработки (Миллс) состоит в выполнении стандартных шагов. В итоге каждого шага - работающий прототип. Требования фиксированы во время шага. Для шага можно применять каскадную или эволюционную модель.
Особенность состоит в том, что наиболее важные для заказчика компоненты разрабатываются в самом начале, в результате чего он может оценить, насколько конечный продукт будет соответствовать его потребностям, и при необходимости внести коррективы.
Одно из ответвлений -
Каждый виток разбит на 4 сектора: определение
На каждом витке спирали могут применяться разные
Главное отличие от других моделей состоит в акценте на анализ и преодоление рисков (об этом мы еще будем говорить более подробно в 3 разделе нашего курса).
Тема следующей лекции -
Основы
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.