- •3.Основные признаки пр-та.
- •4.Одноуровневая Арх-ра ис.
- •5.Двухуровневая Арх-ра ис.
- •6.Трехуровневая Арх-ра ис.
- •7.Четырехуровневая Арх-ра ис.
- •8.Легкие методологии создания по.
- •9.Тяжелые методологии создания по.
- •12.Модель жц по: code-and-fix,stagewise model
- •10.Конус неопределенности пр-та.
- •11.Системная модель пр-та ф.Бегьюли
- •13.Модель жц по:evolutionary model
- •14.Модель жц по: водопад
- •15.Модель жц по: содержание работ ветви проектирования
- •16.V модель жц по: содержание работ ветви конструирования.
- •17.Содержание видов испытаний:валидация,верификация,тест-е.
- •19.Внешняя среда программного пр-та
- •20.Внутренняя среда программного пр-та
10.Конус неопределенности пр-та.
Степень неопределенности оценок затрат на выполнение пр-та изменяется в зависимости от этапа пр-та,на кот-м такая оценка производится,и возможная величина погрешности сильно варьируется в зависимости от предметной области.Для проектов внедрения ИС можно воспользоваться "конусом неопределенности",предложенный Барри Бемом в 1981г и заново введенный Стивом МакКоннеллом в 1997г.Исслед-ли обнаружили,что оценкам проектов на разных стадиях присущи прогнозируемые уровни неопред-сти.КН показывает,что оценки становятся более точными по мере продвижения работы над проектом.По горизонтальной оси отложены основные ключевые этапы пр-та:исходная концепция,согласованное определение прод-та,завершение требований,завершение проектир-я польз-го интер-са,завершение детального проект-я,готовый ППрод.По вертикальной оси:Неопредел-ть в оценке пр-та.Отсчитывается относительная величина ошибки в пр-тах,создаваемых опытными оценщиками на разных стадиях раб над пр-ом.Оценка может относиться к затратам или объему раб на реализацию определенного набора функций,кол-ву функций для заданного объема раб или срока и т.д.Как видно из графика,оценки,созданные на очень ранней стадии пр-та,подвержены высокой степени ошибок.
11.Системная модель пр-та ф.Бегьюли
Сущность каждого пр-та заключается в деят-ти.Но для того чтобы он был успешным,необходимо продуманное управление им,направленность на достиж-е общей конечной цели.Необходимы четко сформулир-е задачи,д.б налажена сист связи,участники пр-та должны работать согласованно.Успешные пр-ы преследуют реальные цели и ставят перед собой поддающиеся решению задачи.Они строятся на достижении промежуточных резул-ов,позволяющих развить успех и добиться желаемого.Основное внимание уделяется текущим результ-ам,где возможные проблемы выявляются заранее.Схема реализации пр-та.:Управление,Планир-е,Действия,Контроль,Проверка-> Результат проекта.
Действия составляют самую сущность реализации пр-та,все его процессы взаимос-ны и не явл-я чем-то изолированным,поскольку подкреплены управлением,планир-м,проверкой и контролем.В основе успешного реш задач в 1ю очередь лежит эффективное упр-е пр-м.рис:Проведение политики,Планир-е,Координация,Действия
12.Модель жц по: code-and-fix,stagewise model
МодельЖЦ-возможные стратегии реализации ПО.Подход "кодирование-исправление"(code and fix)упрощенно м.б описан так.Разработчик начинает кодир-е сист с самого первого дня.Все ошибки обнаруживаются к концу кодир-я и требуют исправления через повторное кодир-е.При использовании данного подхода затрачивается время лишь на кодир-е.Этот подход м.б рекомендован к использованию в 2х случаях.-Для очень мал-х пр-в,кот-е должны завершиться разработкой демонстрационного прототипа;-Для доказ-ва некоторой прогр-й концепции.
Code and fix( Кодир-е и фиксирование)Основная идея:Прозрачная задача,затем код.Метод использовался в 50гг.(слабые ЭВМ,ненадежные,реле,электро-вакуумные приборы)- трудность модифик-и и развития ППрод;-высокая вероятность того,что функциональность ППрод не будет совпадать с потребностями польз-я;-сложность тест-я ППрод.Stagewise model(Постадийная модель)1.Планир-е разработки;2.Разработка спецификации(Привлечь людей,поставить задачу в четком виде);3.Кодир-е;4.Параметрическое тест-е модулей(Во время тест-я отдельных модулей ошибку легче найти);5.Тест-е сборки;6.Опытная эксплуатация(Разработчиком);7.Оценка сист польз-м.
Нисходящее программ-е,т.е задачу делят на куски,разбивают на части.Разработка спецификации-процесс созд-я док-та,в кот-м однозначно описано то,что должна делать прог-а,а также ее хар-тики,треб-я к ней и т.д.
