1. Жизненный цикл Информационной Системы icon

1. Жизненный цикл Информационной Системы

Смотрите также:
Спецкурс (9 семестр) Специальность «Экономическая кибернетика» из Лекция Внедрение кис...
План Жизненный цикл и дисбаланс предприятия как эконо­ мической системы...
План Жизненный цикл и дисбаланс предприятия как эконо­ мической системы...
Тематический план лекций Тема Информационная система. Определение информационной системы...
Программа дисциплины «Бизнес технологии в управлении человеческими ресурсами. Оценка персонала.»...
Савельев О. О. Науч руководитель к т. н доц. Береговых Ю. В...
Тема Загальні відомості про розробку програм...
Программа дисциплины Технологии управления человеческими ресурсами...
1Жизненный цикл товара и управление ассортиментом и номенклатурой в рамках товарной стратегии...
Исследование существующей информационной системы...
Программа дисциплины Технологии управления человеческими ресурсами: о бучение и развитие...
Программа дисциплины Технологии управления человеческими ресурсами: обучение и развитие...



скачать







Лекция 1:
Методологии Разработки Программного Обеспечения.


Contents


Лекция 1:
Методологии Разработки Программного Обеспечения. 1


1. Жизненный цикл Информационной Системы. 3

2. Методологии разработки. 5


1.Жизненный цикл Информационной Системы.


Информационная система – это совокупность систем баз данных, СУБД и прикладных программ, предназначенная для того чтобы обеспечить надлежащих людей надлежащей информацией.

^ ЖЦ ИС — это непрерывный процесс, начинающийся с принятием решения о необходимости создания ИС и заканчивающийся, как правило, полным изъятием ИС из эксплуатации. ЖЦ включает более мелкие процессы, которые делятся на 3 группы: основные, вспомогательные и организационные. К организационным относится, кстати, прежде всего, управление проектами, которым мы будем заниматься в середине семестра.


Основные этапы ЖЦ ИС – это:

1. Анализ бизнес-процессов, которых касается система

1.1. Создание исходной модели бизнес-процессов (“as is”)

1.2. Создание нормативной модели бизнес-процессов (“to be”)

1.3. Определение пользователей ИС и их бизнес-требований

2. Формулировка «технических» требований к ИС

3. Анализ и проектирование

3.1. Разработка архитектуры системы

3.2. Проектирование базы данных (структуры данных, логика БД)

3.3. Проектирование приложений (распределение между клиентом и сервером, структура и функции модулей, проектирование графического интерфейса, запросов и т.п.)

4. Реализация (программирование, а также UI-дизайн, ввод данных, интеграция)

5. Тестирование (самой ИС, ее взаимодействия с другим ПО, ее производительности)

6. Внедрение

6.1. Инсталляция ИС в нужной комплектации

6.2. Настройка ИС (администрирование)

6.3. Обучение персонала

7. Эксплуатация и сопровождение


Многие из основных этапов ЖЦ буду подробнее рассмотрены на последующих лекциях.


Вспомогательные процессы включают:

  1. документирование,

  2. создание общей среды работы над ИС,

  3. конфигурационное управление

  4. оценку, аттестацию ИС,

  5. рекламу, «раскрутку» ИС, если она предназначена для продажи



^

1.1.Жизненный Цикл ИС: подход IBM/Rational
(Rational Unified Process)


См. Слайд 2

Inseption->Elaboration->Construction->Transition

1.2.Жизненный Цикл ИС: подход NetCracker
(NetCracker Implementation Methodology)


См. Слайд 3

Kick-Off->Discovery->Analisys->Design->Build->Test->Deployment->Maintanence
^

2.Методологии разработки.


См. Слайд 4

Методология разработки – Software Development Method – это набор методик и правил, которые могут быть использованы для многократного повторения процесса построения software. На слайде – извечная «палка о двух концах»: Адаптивность vs. Предсказуемость.

Опишем эту проблему, проведя аналогию software development с инженерными дисциплинами (например, гражданское строительство и машиностроение).


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


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


Предположим, в молодой компании, на первых порах практикующей методологию Cowboy Programming («просто программирование», «мы пишем код и правим баги», «правь баги везде где видишь, все свободное время»), происходит переосмысление процесса разработки. Первая же идея которая может возникнуть при оптимизации процесса – отделить этап проектирования от этапа конструирования полностью, по аналогии с гражданским машиностроением и строительством (см. выше). Таким образом строятся так называемые каскадные («водопадные») методологии разработки информационных систем:

^

2.1.От хаоса к предсказуемости: каскадные методологии
(waterfall methods)


См. Слайд 5

Общая идея каскадных методологий разработки: "measure twice; cut once".

Плюсы каскадных моделей:

  • процесс разработки предсказуем;

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

  • подходит для больших команд ;

  • подходит для распределенных команд (географически распределенных).



Минусы каскадных моделей:

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

  • стоимость - любое изменение в начальных требованиях оборачивается дорогостоящим запуском каскада заново – отсутствие адаптивности к изменяющимся требованиям,

  • отсутствие обратной связи (feedback) с последующей фазы проекта часто сильно затрудняет текущую фазу (например, не имея некоторых пробных прототипов системы, трудно провести детальное проектирование User Interface)


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

^

2.2.От предсказуемости к адаптивности: итеративные методологии
(iterative methods)


См. Слайд 6

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


При строительстве моста на работы по проектированию уходит около 10% от всей стоимости работ. Остальное - затраты на конструирование. В программных разработках время, которое тратится на кодирование намного меньше (В большом проекте на кодирование и написание тестового кода приходится всего 15%, то есть цифра, с точностью до наоборот повторяющая соотношение планирования и конструирования при постройке моста. Даже если считать тестирование частью конструирования, то все равно проектирование займет не менее 50% работ.) А на оценку, анализ, проектирование, детальный дизайн и т.п., соответственно, затрачивается не менее половины ресурсов проекта. Отсюда вопрос о сущности проектирования при разработке программных продуктов и его отличиях от проектирования в других областях инженерной деятельности.


Предлагается итеративный процесс построения системы: … -> Initialization -> Iteration -> Production -> … Необходима мощная вспомогательная система отслеживания Change Requests, назовем её условно “Change Control list”. И необходима также некая организация которая будет принимать решение о критичности каждого Change Request – назовём её “Change Control board”


Итеративные методы разработки – это пока лишь «оболочка», идея без её реализации, слишком абстрактная для того чтобы породить большое количество конкретных технологий, но достаточно продуктивная для того чтобы породить несколько новых методологий.

^

2.3.От адаптивности к гибкости: гибкие методологии
(agile methods)


См. Слайд 7-8

Под Agile Methods или Agile Development подразумевается большое семейство итеративных гибких (старый термин – “light-weighted”, «легковесных») методологий разработки, объединённых под одним общим «Манифестом Гибкости» (2001 год, лыжный курорт Snowbird штата Utah, 17 ведущих специалистов по 17 гибким технологиям разработки).


  • Individuals and Interactions over Processes and Tools

  • Working Software over Comprehensive Documentation

  • Customer Collaboration over Contract Negotiation

  • Responding to Change over Following a Plan


Итеративные методологии разработки, подчиняющиеся agile manifesto:

  • XP (Extreme Programming)

  • Crystal

  • Open Source (как методология)

  • ASD

  • SCRUM

  • Feature Driven Development

  • DSDM (Dynamic System Development Method)

  • наверняка, список можно продолжать…



^

2.4.Что выбрать?


См. Слайд 9

На слайде собраны воедино плюсы и минусы как Waterfall Models так и Agile Models.

2.5.Что такое RUP?


Всякий раз при обсуждении методов разработки ПО в сфере объектно-ориентированных технологий, разговор неизбежно заходит о роли Rational Unified Process (RUP). Унифицированный Процесс был разработан Филиппом Крачтеном (Philippe Kruchten), Иваром Якобсоном (Ivar Jacobson) и другими сотрудниками компании "Rational Software" в качестве дополнения к языку моделирования UML. RUP представляет собой каркас для процессов, и таким образом, включает в себя огромное их количество. Именно эта черта RUP вызывает основную критику - поскольку он может быть чем угодно, его нельзя считать ничем определенным. В частности, Фаулер ([1]) указывает на возможность построения в точности «по RUP» как методологии Extreme Programming (яркий представитель Agile Methods), так и некоторой методологии типа Waterfall  То есть, складывается ощущение что авторы RUP сами не определились, на стороне каких методологий разработки им выступать.

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

2.6.Полезные материалы


[1] Мартин Фаулер, «Новые Методологии Программирования»
http://www.martinfowler.com/articles/newMethodology.html (eng)
http://www.maxkir.com/sd/newmethRUS.html (rus)

[2] WIKIPedia, “Agile Software Development”
http://en.wikipedia.org/wiki/Agile_programming

[3] Agile Manifesto
http://www.agilemanifesto.org/


База данных защищена авторским правом © kursovaya-referat.ru 2017
При копировании материала укажите ссылку