Зачёт исис. зачет исис. Перечислите стадии жц по. Опишите, что на входе и выходе каждой стадии. 1 Первой стадией является
 Скачать 2.03 Mb.
|
|
Перечислите стадии ЖЦ ПО. Опишите, что на входе и выходе каждой стадии. 1)Первой стадией является анализ требований. На входе: - встреча разработчиков и заказчика - достижение общего понимания задачи для решения которой будет разработано по - выявление и обсуждение требований и ограничений заказчика к по. На выходе: -форматизированное описание требований - список требований(документ) 2)подготовка проектных спецификаций. -Она происходит на основе описания требований. - готовится руководителем проекта Содержит: -описание всей функциональности проекта - выбранную модель разработки по - состав проектной команды -оценку сроков проекта - оценку стоимости проекта - общий план проекта 3) детальное проектирование - производится на основе проектных спецификаций -выполняется разработчиком Содержит: - модель предметной области как есть и как будет - описание бизнес-процессов На выходе дает документы, которые описывают все программные модули корпоративного комплекса. 4)Реализация - производится разработчиком на основе документов детального проектирования с учетом общего плана проекта, В результате мы получаем отдельные программные модули, каждый из которых является уже реализованным и протестированным прежде всего самим разработчиком на внутреннюю корректность и на соответствие проектным спецификациям по отдельности. 5)интеграция(Сборка) - сборка модулей в общую архитектурную схему, которая была оговорена на этапе архитектурного проектирования. - тестирование проводят разработчик и заказчик Если все приемочные тесты, которые производятся заказчиком, успешны, то происходит передача программного продукта вместе с документацией заказчику и наступает фаза эксплуатации. 6) сопровождение – самый затратный этап ЖЦ. Задачами сопровождения программного продукта являются ликвидация ошибок, которые остались в программном продукте, коррекция проектных спецификаций, улучшение производительности и учет особенностей новой программной и аппаратной среды заказчика, если таковые имеются. Сопровождение позволяет выстроить долговременные отношения с заказчиком. 7) вывод из эксплуатации. Вывод из эксплуатации возможен только на основе взвешенного решения, которое включает оценку стоимости. Стоимость замены ПО включает целый ряд факторов: стоимость смены технологий (стоимость нового ПО, стоимость лицензий), стоимость разработки и поддержки приложений на основе нового ПО, затраты на обучение персонала, потеря производительности труда персонала в переходный период, поскольку с новым ПО всегда достаточно сложно работать. В ряде случаев вывод из эксплуатации осуществляется вынужденно (например, при обнаружении существенной несовместимости). Вклад фаз ЖЦ в сроки и стоимость проекта. Цена ошибки в программном проекте. Каждая фаза ЖЦ ПО включает три важных составляющих – процессы, методы и средства. Под процессами понимают задачи, которые необходимо реализовать, они отличаются и, по сути, не зависят друг от друга. Методы – это относительно формальное описание каждой задачи процесса. Средства – автоматический инструментарий типа CASE-средств для поддержки процессов и методов. Основные затраты выделяются на сопровождение. Особенно это важно для корпоративных проектов, которые являются долгосрочными и включают большое количество компонентов, которые нужно объединять, интегрировать и поддерживать совместно, что вызывает дополнительные сложности. Кроме того, программные средства, которые увеличивают расширяемость применения ПО, более эффективны, чем все попытки рефакторинга улучшения кода. Обрамляющие стадии (тестирование и коррекция спецификаций) обеспечивают существенное улучшение качества ПО и его соответствие требованиям. Нужно сказать, что правильная постановка обрамляющих стадий очень важна и ускоряет кодирование. Большая часть серьезных ошибок, которые выявляются в программных проектах, происходит на стадиях проектирования и построения спецификаций. Поэтому эти ошибки очень дорогостоящи, поскольку приходится переделывать и код, и документацию, и нужны формальные методы их анализа (это и ревизия проекта, и более формальные логические технологии проверки корректности). Цена ошибки растет примерно экспоненциально по мере продвижения проекта по жизненному циклу. Если ошибка обнаруживается на стадии анализа требований, то ее исправление достаточно дешево. Если же она обнаружена на более поздних стадиях, особенно на стадии сопровождения, то ее цена во много раз выше, потому что приходится изменять всю версию ПО, документацию, диаграммы и целый ряд других программных продуктов. К счастью, есть специальные средства для поиска, выявления и устранения ошибок. Понятие модели жизненного цикла (ЖЦ) ИС. Модель Build-and-Fix Модель ЖЦ ИС – комбинация последовательности этапов жизненного цикла и переходов между ними, необходимых для гарантированного достижения поставленной для реализации проекта цели. Модель Build-and-fix – «кодируй и фиксируй», по сути, она близка к модели проб и ошибок. Модель Build-and-fix (модель неполного жизненного цикла, рис. 3.1), которая в силу своей простоты не пригодна для больших и сложных проектов, имеющих размеры более 1000 программных строк. Дело в том, что при разработке программного обеспечения в рамках данной модели, первичным условием является разработка детальных спецификаций, и реализация программного продукта без : Ø существенной концептуальной проработки решения Ø архитектурного проектирования, Ø первичного проектирования. То есть нам нужно повторить полный цикл разработки до тех пор, пока не будет получен тот продукт, который нужен заказчику. Существенная сложность и проблема данного подхода — полный цикл разработки — это достаточно дорогостоящее мероприятие, может получиться так, что те затраты, которые мы понесем в итоге, не окупятся за счет той экономии на первичных стадиях, анализ, первичное проектирование, архитектурное проектирование, которое нам придется из этого жизненного цикла в данном случае выбросить.  Каскадная модель ЖЦ. Перечислите особенности модели. Приведите примеры проектов, где целесообразно применение этой модели. Каскадная модель, является в полной мере применимой для корпоративных информационных систем. Она требует дисциплины и организованности, хорошего знания CASE-средств, так как нужно быстро и организованно создавать диаграммы, проводить сетевые совещания, конференции, достаточно быстро вести тестирование различными методами. Кроме того, нужно производить документацию в соответствии со стандартами, которые приняты по договоренности с заказчиком внутри компании как руководство к действию, как шаблоны для реализации документации, которая тоже является важной частью продукта. Документация критически важна для каскадной модели, потому что, проверяя ее на адекватность и сопоставляя с ТЗ или другим вариантом требований к продукту, которые согласованы с заказчиком и утверждены как юридический документ, разработчики отчитываются по продукту и закрывают каждую стадию жизненного цикла. Каскадную модель лучше применять в следующих случаях: - при разработке проектов с четкими неизменными в течении жц требованиями, понятными техническими методиками. - при разработке проектов, связанного с созданием и выпуском новой версии уже существующего проекта или системы.  Инкрементальная модель ЖЦ. Перечислите особенности модели. Приведите примеры проектов, где целесообразно применение этой модели. Инкрементная модель жизненного цикла представляет собой пример итеративного подхода к разработке программного обеспечения, который предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включающий все фазы жизненного цикла в применении к созданию отдельных версий системы, обладающих меньшей функциональностью по сравнению с проектом, в целом. Каждый релиз включает в себя требования к предыдущему релизу, т. е. функциональность нарастает плавно и таким образом, что следующий релиз в смысле функциональности поглощает предыдущий, добавляя к нему новые возможности. Кроме того, каждый этап наращиваемой разработки продукта, производства нового релиза включает в себя все стадии жизненного цикла программного продукта. Эта модель популярна при разработке веб-приложений и среди продуктовых компаний. Кроме того, модель может быть использована, когда есть необходимость доставить товар на рынок раньше срока.  Особенности инкрементальной модели: В ходе построения плана проект ПО претерпевает разбивку на последовательные релизы. Весь жизненный цикл, связанный с производством до передачи в сопровождение, подразумевает производство последовательных релизов – циклов разработки, каждый из которых дает уже работоспособный продукт. Таким образом, в ряде случаев, особенно когда продукт не требует революционной перестройки от релиза к релизу заказчику передается в сопровождение уже работоспособный продукт, пусть и с ограниченной функциональностью. Таким образом, на каждой стадии происходит создание необходимой документации и тестирование, и продукт получается работоспособным, но реализует не всю функциональность, а каждый релиз уже дает продукт, который может применяться. Таким образом, в итоге каждого шага разработки, тестирования и интеграции имеется работающий продукт, который может устроить заказчика. В технических требованиях можно заранее оговорить, в какой последовательности и в какие сроки в плане проекта вводить ту или иную функциональность у заказчика, и далее вести последовательные релизы в соответствии с используемыми технологиями и функциональными ограничениями. Спиральная модель ЖЦ. Перечислите особенности модели. Приведите примеры проектов, где целесообразно применение этой модели. Пример ИТ-инсорсинговой компании России. Суть спиральной модели состоит в возможности прохождения всех этапов жизненного цикла системы в несколько итераций, каждый раз создавая новый прототип и проверяя актуальность требований, по которым он создавался, внося технические доработки в интерфейс и функциональность. Подобная гибкость позволяет использовать модель на предприятиях любого масштаба. Каждый виток состоит из четырех фаз: 1) определить цели – продукт, деловые цели, понять ограничения, предложить альтернативы; 2) оценить альтернативы – анализ риска, прототипирование; 3) разработать продукт – детальный проект, код, unit test, интеграция; 4) спланировать следующий цикл – оценка клиентом, планирование проектирования, поставка клиенту, внедрение Эта модель предназначена для проектов с существенными рисками. Лучше всего подходит для проектов: со средним или высоким уровнем вероятных рисков; когда требования к продукту слишком сложные или заказчик не может их четко сформулировать; когда есть вероятность, что нужны будут серьезные изменения в продукте в процессе разработки.  Гибкие модели ЖЦ. Пример гибкой модели ЖЦ. Объясните суть основных компромиссов данных моделей: компромисс между ценностями знания и ценностями для клиента; делать правильные фичи, делать фичи правильно или делать фичи быстро. Гибкие методологии, такие как Agile , Scrum , eXtreme Programming. Следует отметить, что направление этих подходов ортогонально моделям жизненного цикла. Они, в отличие от IBM Rational и MSF, применимы к проектам с большими неопределенностями, возможно, большими рисками, но меньшего масштаба, чем корпоративные информационные системы. С другой стороны, методологии – это параллельное направление проектирования систем, которое связано скорее с задачей проектного менеджмента, чем с задачей построения системной архитектуры. Причины появления интегрированных среды поддержки проектов (IPSE). Условия появления таких сред - инструментальная среда 70 - 80х гг Интегрированная среда (integrated development environment - IDE) - набор инструментов для разработки и отладки программ, имеющий общую интерактивную графическую оболочку, поддерживающую выполнение всех основных функций жизненного цикла разработки программы - набор и редактирование исходного текста (кода), компиляцию (сборку), исполнение, отладку, профилирование и др. Использование интегрированной среды - один из возможных подходов к разработке программ. Альтернативой ему является более ранний, традиционный подход системы UNIX, основанный на использовании набора инструментов (toolkit, toolbox), родственных по тематике и функциональности, но не объединенных в одну интегрированную интерактивную среду и подчас (в ранних версиях системы UNIX) вызываемых врежиме командной строки (command line interface). Разумеется, использовать интегрированную среду гораздо удобнее для разработчика, чем и объясняется бурное развитие и разнообразие интегрированных сред, начиная с 1980-х годов. Одной из первых интегрированных сред стала среда Turbo Pascal [1] фирмы Borland, руководителем разработки которой в середине 1980-х гг. стал Филипп Кан, ученик Никлауса Вирта. Цель системы Requirement Management (RM). Критерии выбора инструментов управления требованиями. Пример RM системы. Системы управления требованиями (СУТ, англ. Requirements Management Systems, RMS) помогают аналитикам, проектировщикам и руководителям проводить сбор, фиксирование требований, их систематизацию, приоритизацию, построение взаимосвязей. Такие программные продукты применяются на протяжении всего жизненного цикла процесса, продукта, услуги. Критерии выбора инструментов: Декомпозиция требований, Типизация и шаблонизация требований, Классификация требований, Трассировка требований друг на друга, Графическое моделирование требований, Определение и причина возникновения CASE – средств. Назначение CASE-инструментов. Примеры типичных/распространенных CASE-средств CASE - средства CASE (англ. Computer-Aided Software Engineering ) – автоматизированная разработка программного обеспечения. CASE-средства – это набор инструментов и методов программной инженерии, предназначеный для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов. Ручная разработка обычно порождала следующие проблемы: неадекватная спецификация требований; неспособность обнаруживать ошибки в проектных решениях; низкое качество документации, снижающее эксплуатационные качества; затяжной цикл и неудовлетворительные результаты тестирования. Перечисленные факторы способствовали появлению программно-технологических средств специального класса - CASE-средств. CASE-средством считается программное средство, которое автоматизирует определенную совокупность процессов жизненного цикла программного обеспечения и обладает рядом таких характеристик как: объединение определенных компонентов CASE-средств, которое дает возможность управляемость процессом разработки информационных систем; репозитория; наличие графических средств, с помощью которых можно описывать и документировать информационные системы, которые предоставят удобный интерфейс с разработчиком; Основные компоненты CASE – систем. Критерии выбора CASE-систем. Примеры типичных/распространенных CASE-средств. четыре основных компонента: Средства централизованного хранения всей информации о проектируемом ПО в течение всего ЖЦ Графические среды анализа и проектирования, обеспечивающие создание и редактирование иерархических связанных диаграмм. Средства разработки приложений 4)Средства документирования управления проектом и реинжиринга Критерии выбра: - простота или сложность средста -степень согласованности с существующими бизнес процессами - требуемая степень интеграции с другими программными средствами - опыт и квалификация пользвателей  Определение и причина возникновения IDE. Назначение IDE сред. IDE (Integrated Development Environment) – это интегрированная, единая среда разработки, которая используется разработчиками для создания различного программного обеспечения. IDE представляет собой комплекс из нескольких инструментов, а именно: текстового редактора, компилятора либо интерпретатора, средств автоматизации сборки и отладчика. Помимо этого, IDE может содержать инструменты для интеграции с системами управления версиями и другие полезные утилиты. Есть IDE, которые предназначены для работы только с одним языком программирования, однако большинство современных IDE позволяет работать сразу с несколькими. Обычно среда разработки включает в себя: текстовыйредактор компилятор и/или интерпретатор средства автоматизации сборки отладчик. Первые IDE были созданы для работы через консоль или терминал, которые сами по себе были новинкой: до того программы создавались на бумаге, вводились в машину с помощью предварительно подготовленных бумажных носителей (перфокарт, перфолент) и т. д. IDE очень часто представляет из себя единственную программу, в которой проводилась вся разработка. Она содержит много функций для: · создания · изменения · компилирования · развертывания · отладки программного обеспечения Цель среды разработки заключается в абстрагировании конфигурации, необходимой, чтобы объединить утилиты командной строки в одном модуле, который позволит уменьшить время, чтобы изучить язык, и повысить производительность разработчика. Назовите главное принципиальное отличие от дискретных инструментов разработки кода каждой из компонент IDE: текстовый редактор; отладчик; системы контроля версий (VCS); графический интерфейса пользователя. Приведите примеры типичных/распространенных IDE.   Раскройте суть понятия «изменение». Причины появления систем контроля версий (VCS).Назовите главные компоненты общей модели «запрос и анализ». Н  азовите главные компоненты общей модели «подтверждение и реализация». Назовите главные компоненты общей модели «проверка и закрытие реализации».   О  пишите основной цикл разработчика при работе в системе SVN. 17. Дайте характеристику системы GIT. Отличие этой системы от SVN. Git — это система контроля версий файлов с исходным кодом программы. Написав полный код или его часть, Git сохраняет текущее состояние файла. Далее разработчик продолжает работу над кодом и понимает, что сделал ошибку или не оптимизировал код. Чтобы вернуться в предыдущее сохраненное состояние, не требуется удалять участки некорректного кода, пересматривая его полностью. Достаточно ввести специальную команду в Git, и система вернет разработчика к предыдущему состоянию файла. С точки зрения программного обеспечения Git бывает трех видов: Консольная утилита, требующая знания текстовых команд для управления репозиторием. Графическое приложение для ПК. Онлайн-версия, которая называется GitHub — именно здесь хранятся репозитории большинства разработчиков, которые делятся своим детищем со всеми пользователями интернета. Git использует гораздо больше программ чем svn. Git используется как для командной разработки, так и одним программистом. Каждый разработчик команды создает доверенную ему часть проекта. Опытное лицо просматривает все версии файлов, выполненных младшими разработчиками, делает правки и осуществляет сборку проекта из частей. Отличия: Основное отличие Git распространяется, а Svn не распространяется Git хранит контент как метаданные, в то время как SVN хранит его как файлы Git не имеет глобального номера версии, в то время как SVN имеет: пока это самая большая функция, которой Git не хватает по сравнению с SVN. Целостность содержимого Git лучше, чем SVN После загрузки Git все журналы можно увидеть в состоянии OffLine, а SVN – нет Характеристики SVN просты, но это нормально, когда вам нужно место для размещения кода. Функции контроля версий Git могут делать что угодно, не полагаясь на сеть, и имеют лучшую поддержку для ветвления и слияния (конечно, это то, что больше всего беспокоит разработчиков), но если вы можете использовать его лучше, вам нужно потратить некоторое время на его опробование. 13) 4)Отладчик (дебаггер, англ. debugger) — компьютерная программа, предназначенная для поиска ошибок в других программах, ядрах операционных систем, SQL-запросах и других видах кода. Отладчик позволяет выполнять трассировку, отслеживать, устанавливать или изменять значения переменных в процессе выполнения кода, устанавливать и удалять контрольные точки или условия остановки и т.д. 1)Текстовый редактор — самостоятельная компьютерная программа или компонент программного комплекса (например, редактор исходного кода интегрированной среды разработки или окно ввода в браузере), предназначенная для создания и изменения текстовых данных в общем и текстовых файлов в частности. |