Основой проектирования программного обеспечения является системный подход. Системный подход – это методология исследования объекта любой природы как системы. Система – это совокупность взаимосвязанных частей, работающих совместно для достижения некоторого результата. Определяющий признак системы – поведение системы в целом не сводимо к совокупности поведения частей системы.
Программное обеспечение (ПО) – это система, включающая в себя: компьютерные программы; документацию; данные, необходимые для корректной работы программ.
Проектирование ПО – это процесс создания спецификаций ПО на основе исходных требований к нему. Проект – текущий или окончательный результат проектирования. Проект ПО включает в себя модели и проектную документацию, описывающие архитектуру, подсистемы, интерфейсы, программные компоненты, структуры данных и алгоритмы.
Особенности современных проектов ПО:
1 структурная, функциональная и информационная сложность объекта внедрения;
2 высокая техническая сложность, из-за наличия подсистем, обеспечивающих управление транзакциями, аналитическую обработку данных, безопасность;
Основные правила проектирования печатных плат. Учимся правильно разводить платы.
3 отсутствие полных аналогов и высокая доля вновь разрабатываемого ПО;
4 наличие унаследованного ПО и необходимость его интеграции с разрабатываемым ПО;
5 территориально распределенная и неоднородная среда функционирования;
6 большое количество участников проектирования, разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и опыту;
7 значительная длительность жизненного цикла ПО.
Лекция 1.3. Общие принципы проектирования систем. Модели программного обеспечения и их место в процессе проектирования
Одна из основных проблем при создании больших и сложных систем, в том числе ПО, – это проблема сложности. Подход к решению этой проблемы основан на принципе «разделяй и властвуй» (divide et impera). Сложная программная система должна быть разделена на небольшие подсистемы, каждую из которых можно разрабатывать независимо (в какой-то степени) от других. Декомпозиция является главным способом преодоления сложности разработки ПО. Принципы декомпозиции:
1 слабая связанность – low coupling (количество связей между отдельными подсистемами должно быть минимальным);
2 сильное сцепление – high cohesion (связность отдельных частей внутри каждой подсистемы должна быть максимальной).
Структура ПО должна удовлетворять следующим требованиям:
1 каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);
2 каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.
Два основных подхода к декомпозиции систем: функционально-модульный, основанный на функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и иерархии структур данных; объектно-ориентированный, использующий объектную декомпозицию, при которой структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Подходы имеют много общего. Достоинством второго подхода является то, что есть единая иерархия, и нет необходимости отслеживать соответствие между двумя иерархиями функционально-модульного подхода.
Металлоконструкции | расчет узлов | проектирование | сопромат
В рамках обоих подходов используются наглядные графические модели (схемы и диаграммы) для описания архитектуры ПО с различных точек зрения. Примеры: блок-схемы, диаграммы «сущность – связь», диаграммы классов. Модель ПО – это формализованное описание системы ПО на определенном уровне абстракции.
Каждая модель описывает конкретный аспект системы, использует набор диаграмм или формальных описаний и документов заданного формата, а также отражает точку зрения и является объектом деятельности различных людей с конкретными интересами, ролями или задачами. Модели служат полезным инструментом анализа проблем, обмена информацией между всеми заинтересованными сторонами, проектирования ПО. Моделирование способствует более полному усвоению требований, улучшению качества системы и повышению степени ее управляемости.
Визуальное моделирование – это способ восприятия проблем с помощью зримых абстракций, воспроизводящих понятия и объекты реального мира. Моделирование осуществляется при помощи языка моделирования, который включает в себя: элементы модели; нотацию (систему обозначений); руководство по использованию.
Моделирование не является целью разработки ПО. Диаграммы – это лишь наглядные изображения. Причины, побуждающие прибегать к их использованию:
1. Графические модели помогают получить общее представление о системе, сказать о том, какого рода абстракции существуют в системе и какие ее части нуждаются в дальнейшем уточнении.
2. Графические модели образуют внешнее представление системы и объясняют, что эта система будет делать, тем самым облегчают общение с заказчиком.
3. Графические модели облегчают изучение методов проектирования, в частности объектно-ориентированных методов.
В процессе создания ПО используются следующие виды моделей:
1 модели деятельности организации (или модели бизнес-процессов):
o модели «AS-IS» («как есть»), отражающие существующее положение;
o модели «AS-TO-BE» («как должно быть»), отражающие представление о новых процессах и технологиях работы организации;
2 модели проектируемого ПО, которые строятся на основе модели «AS-TO-BE», уточняются и детализируются до необходимого уровня.
Состав моделей, используемых в каждом конкретном проекте, и степень их детальности в общем случае зависят от следующих факторов: сложности проектируемой системы; необходимой полноты ее описания; знаний и навыков участников проекта; времени, отведенного на проектирование.
Для облегчения труда разработчиков и автоматизированного выполнения некоторых рутинных действий используются CASE-средства (Computer Aided Software Engineering). В настоящее время CASE-средства обеспечивают поддержку большинства процессов жизненного цикла ПО, что позволяет говорить о CASE-технологиях разработки ПО. CASE-технология – это совокупность методов проектирования ПО и инструментальных средств для моделирования предметной области, анализа моделей на всех стадиях ЖЦ ПО и разработки ПО.
Раздел 2. Язык UML.
Литература к лекции 2.1
1. Боггс У., Боггс М. UML и Rational Rose 2002: Пер. с англ. – М.: ЛОРИ, 2004.
2. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя.: Пер. с англ. – М.: ДМК, 2000. – Глава 2.
3. Вендров А. М., Малышко В. В. Объектно-ориентированный анализ и проектирование с использованием языка UML.: Методическое пособие – М.: Издательский отдел факультета ВМиК МГУ, 2002.
4. Фаулер М. UML. Основы. 3-е издание. Краткое руководство по стандартному языку объектного моделирования.: Пер. с англ. – СПб: Символ-Плюс, 2005.
Лекция 2.2. Варианты использования и диаграммы вариантов использования. Диаграммы взаимодействия
Вариант использования – это ответные действия ПО, являющиеся реакцией на событие, инициируемое извне. Вариант использования описывает типичное взаимодействие между пользователем и ПО. Он отражает представление о поведении системы с точки зрения пользователя. На диаграммах варианты использования представляются в виде овалов.
Действующее лицо – это роль, которую пользователь играет по отношению к системе. На диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок. Действующим лицом может быть пользователь-человек, внешняя программная система или время, если запуск каких-либо событий в системе зависит от времени.
Диаграммы вариантов использования показывают, какие действующие лица инициируют варианты использования (от них идет стрелка к варианту использования). Из диаграмм понятно, какие действующие лица получают данные в ходе выполнения варианта использования (к ним идет стрелка от варианта использования).
Правила построения диаграмм вариантов использования:
1. Не следует моделировать связи между действующими лицами, поскольку это не относится к системе.
2. Не следует соединять стрелкой два варианта использования.
3. Каждый вариант использования должен быть инициирован действующим лицом.
Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Детально функциональные требования описываются в документе, называемом «сценарий варианта использования» или «поток событий». Он подробно документирует процесса взаимодействия действующего лица с системой, реализуемого в рамках варианта использования.
Описание потока событий включает следующие разделы:
1) краткое описание;
3) основной поток событий;
4) альтернативные потоки событий;
6) расширения и подчиненные потоки.
Хорошо написанный поток событий должен легко читаться и состоять из предложений, написанных в единой грамматической форме. Правила составления описания потока событий:
1 следует использовать простые предложения;
2 нужно явно указывать в каждом пункте, кто выполняет действие – действующее лицо или система;
3 не следует включать в потоко событий слишком незначительные действия;
4 в описании основного потока не следует рассматривать ошибочные ситуации;
5 некорректные действия пользователя и внутренние ошибки следует описывать в альтернативных потоках.
В диаграммах вариантов использования может присутствовать несколько типов связей:
1 связи коммуникации (линия со стрелкой, обозначающая связь между вариантом использования и действующим лицом);
2 связи включения (пунктирная линия со стрелкой, обозначающая включение многократно используемой функциональности, представленной в виде абстрактного варианта использования);
3 связи расширения (пунктирная линия со стрелкой, указывающая на особый случай, описанный в абстрактном варианте использования);
4 связи обобщения (линия с треугольным концом, показывающая, что у нескольких действующих лиц имеются общие черты и различия).
Диаграммы взаимодействия описывают поведение взаимодействующих групп объектов в рамках потока событий. На диаграмме отображается ряд объектов и сообщения, которыми они обмениваются между собой. Сообщение – это средство, с помощью которого объект-отправитель запрашивает у объекта-получателя выполнение одной из его операций. Существует два вида диаграмм взаимодействия: диаграммы последовательности и коммуникационные диаграммы (ранее называемые кооперативными).
Диаграммы последовательности отражают временную последовательность событий, происходящих в рамках варианта использования. Все действующие лица и объекты системы изображаются в верхней части диаграммы. От каждого из них вниз проведена вертикальная черта – «линия жизни». Стрелки, соответствующие сообщениям, которые передаются между действующим лицом и объектом или между объектами, соединяют линии жизни отправителя и получателя сообщения. Порядок отправки сообщений соответствует их размещению на диаграмме сверху вниз.
Вторым видом диаграмм взаимодействия являются коммуникационные диаграммы. Как и диаграммы последовательности, они отображают поток событий варианта использования. На коммуникационных диаграммам внимание сконцентрировано на связях между объектами. Из них легче понять связи между объектами, однако, труднее уяснить последовательность событий.
Объекты и/или действующие лица, обменивающиеся сообщениями соединяются линиями, над которым в виде стрелок обозначаются сообщения. Нумерация сообщений указывает их последовательность во времени.
Литература к лекции 2.2
1. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя.: Пер. с англ. – М.: ДМК, 2000. – Главы 17, 18.
2. Вендров А. М., Малышко В. В. Объектно-ориентированный анализ и проектирование с использованием языка UML.: Методическое пособие – М.: Издательский отдел факультета ВМиК МГУ, 2002.
3. Фаулер М. UML. Основы. 3-е издание. Краткое руководство по стандартному языку объектного моделирования.: Пер. с англ. – СПб: Символ-Плюс, 2005. – Главы 4, 9, 12.
Литература к лекции 2.3
1. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя.: Пер. с англ. – М.: ДМК, 2000. – Главы 8, 12, 19, 24, 29, 30.
2. Вендров А. М., Малышко В. В. Объектно-ориентированный анализ и проектирование с использованием языка UML.: Методическое пособие – М.: Издательский отдел факультета ВМиК МГУ, 2002.
3. Леоненков В. А. Самоучитель UML. – СПб: BHV, 2001.
4. Фаулер М. UML. Основы. 3-е издание. Краткое руководство по стандартному языку объектного моделирования.: Пер. с англ. – СПб: Символ-Плюс, 2005. – Главы 3, 5, 7, 8, 10, 11, 14
Литература к лекции 2.4
1. Буч Г., Якобсон А., Рамбо Дж. UML. Серия «Классика CS». 2-е изд.: Пер. с англ. – СПб.: Питре, 2006. – Глава 12.
2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 2.
Литература к лекции 3.1
1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 3.
Лекция 3.2. Определение требований к системе. Варианты использования
Определение требований к ПО является составной частью процесса управления требованиями. Спецификация требований к ПО является основным документом, определяющим план разработки ПО. Все требования, определенные в спецификации, делятся на функциональные и нефункциональные. Функциональные требования определяют действия, которые должна выполнять система, без учета ограничений, связанных с ее реализацией. Нефункциональные требования не определяют поведение системы, но описывают ее атрибуты или атрибуты системного окружения (качество пользовательского интерфейса, производительность, средства реализации, надежность, безопасность).
Требования к ПО оформляются в виде ряда документов и моделей. Словарь предметной области (глоссарий) определяет общую терминологию для всех моделей и описаний требований к системе. Технические требования содержат описание нефункциональных требований. Функциональные требования к системе моделируются и документируются с помощью вариантов использования.
Литература к лекции 3.2
1. Коберн А. Современные методы описания функциональных требований к системам.: Пер. с англ. – М. Лори, 2002.
2. Кратчен Ф. Введение в Rational Unified Process. 2-е изд.: Пер. с англ. – М.: Вильямс, 2002. – Глава 9.
3. Соммервил И. Инженерия программного обеспечения. 6-е изд.: Пер. с англ. – М.: Вильямс, 2002. – Главы 5, 6.
4. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: Пер. с англ. – СПб.: Питер, 2002. – Главы 6, 7.
Литература к лекции 4.1
1. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Главы 11, 12.
2. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: Пер. с англ. – СПб.: Питер, 2002. – Глава 8.
Литература к лекции 4.2
1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 4.
2. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Глава 14.
3. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: Пер. с англ. – СПб.: Питер, 2002. – Глава 9.
Литература к лекции 4.3
1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 4.
2. Коналлен Дж. Разработка Web-приложений с использованием UML.: Пер. с англ. – М.: Вильямс, 2001. – Глава 10.
3. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Глава 14.
Литература к лекции 4.4
1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 4.
2. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Глава 19.
Литература к разделу 5
1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 5.
2. Кратчен Ф. Введение в Rational Unified Process. 2-е изд.: Пер. с англ. – М.: Вильямс, 2002.
3. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: Пер. с англ. – СПб.: Питер, 2002.
Раздел 1. Методические аспекты проектирования программного обеспечения
ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры.
Что вызывает тренды на фондовых и товарных рынках Объяснение теории грузового поезда Первые 17 лет моих рыночных исследований сводились к попыткам вычислить, когда этот.
ЧТО ТАКОЕ УВЕРЕННОЕ ПОВЕДЕНИЕ В МЕЖЛИЧНОСТНЫХ ОТНОШЕНИЯХ? Исторически существует три основных модели различий, существующих между.
Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем.
Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:
Источник: zdamsam.ru
Основные требования к методологии проектирования программного обеспечения
Технология – сложный комплекс, в основе которого лежит применение различных орудий, инструментов и аппаратов, использующий наработанные человечеством знания и умения. Первая информационная революция – письменность. Вторая – создание печатного станка.
Третья – разработка ЭВМ, компьютеров. (Новая) информационная технология – система методов и способов сбора, получения, накопления, хранения, обработки, анализа и передачи информации с использованием средств вычислительной техники. Мы будем работать именно с информационной технологией.
Методология – совокупность механизмов, применяемых при разработке программных систем и объединённых единым философским подходом. Что значит философский подход. Мы иногда «подход» называем парадигмой, т.е. это некое направление, в котором мы будем развивать наши идеи. Какие парадигмы мы знаем? ООП, Структурное, субъектно-ориентированное, функциональное, процессорное и т.д.
Подход выбирается от класса задач, которые требуется реализовать. Мы будем говорить о структурном и ООП. Метод – концептуальное описание правил построение моделей системы, представляющих разные взгляды на проект с использованием специальных графических нотаций, которая определяет изобразительные средства и состав документации по проекту.
Основные требования к методикам и методам проектирования ПО
1. Метод должен отражать специфику подхода (парадигму программирования) – структурный, ОО, ориентированный на процессе, субъектно-ориентированный. 2. Метод должен быть освоен всеми участниками проекта и должен быть наглядным с точки зрения полученных результатов. 3. Должны существовать формальные переходы от этапов анализа к этапу проектирования и обратно.
4. Должны существовать инструментальные средства, поддерживающие все эти методы. ISO/IEE 12207:1995 Information Technology – software life cycle processes (IT – процессы жизненного цикла). Этот стандарт описывает структуру жизненного цикла программного обеспечения и его процесс. Процесс жизненного цикла – совокупность взаимосвязанных действий, преобразующих некоторое входное в выходные. Каждый процесс характеризуется некоторыми задачами и методами их выполнения.
| Романова Т.Н. – Технология программирования [2011] by Melvin | Страница 3 |
Модели жизненного цикла 1. Каскадная (есть основные процессы). Состоит из последовательных шагов: Анализ предметной области Проектирование Кодирование Тестирование Внедрение И сопровождение. В ТЗ профиль стандартов должен быть прописан.
| Романова Т.Н. – Технология программирования [2011] by Melvin | Страница 4 |
Сложная система.
1. Такая система, которая разрабатывается не одним человеком, а группой разработчиков (более 5 человек). 2. Если количество строк исходного кода исчисляется сотнями тысяч или даже миллионами, то это тоже показатель сложной системы. 3. Если сложную задачу можно декомпозировать на более простые задачи (которые будут реализованы более мелкими подсистемами).
4. Если в требованиях встречаются взаимнопротиворечивые требования, то такая система будет однозначно сложной. Например, нужно обработать огромные информационные потоки, и время отклика должно быть кротчайшим. Следует найти компромисс. Это самые важные и самые общие требования, а остальные из них вытекают. Несколько слов об этапах жизненного цикла.
| Проектировка | Анализ предметной |
| области |
| Кодирование | Внедрение |
На каждом новом витке этой спирали могут добавляться новые наработки. Недостаток в том, что граница (напр., между Анализ и проектировка) очень расплывчата. В каскадной модели такого нет. На каждом этапе я должен выдать документацию. Каскадная модель работает при структурном подходе в программировании. Напр., при разработке крупных военных систем, где каждый этап регламентирован.
Но в бизнес-системах применяется спиралевидная. Её применяют для систем не критичных к ошибкам. В ООП.
Разработка технического задания.
Основные эксплуатационные требования к программным продуктам, а также выбор архитектуры. Техническое задание и ГОСТы, регламентирующие этапы разработки. ГОСТ 19.201-78: «Единая система программной документации», подраздел «техническое задание». ЕСПД.ТЗ: «Требования к содержанию и оформление». В соответствии с этим стандартом ТЗ содержит:
| Романова Т.Н. – Технология программирования [2011] by Melvin | Страница 5 |
1. Введение. Здесь следует писать краткую характеристику предметной области (медицина, торговля, промышленность). Можно даже нарисовать в виде картинки. Есть торговое предприятие. Есть поставщики и заказчики.
Тогда на введении, прямо на странице рисуют схематично всё это. Условно обозначаю, кто соучаствует в процессе. И, конечно, какая проблема стоит, какие решения есть (существующие разработки), какие у них недостатки. Напр., устарела и т.п. Т.е. почему возникла необходимость создания нового ПО, в самом общем виде – в том виде, в каком описывает заказчик.
Например «большая доля ручного труда, следует автоматизировать, чтобы снизить человеческий фактор ошибок и повысить производительность». 2. Основания для разработки. «На основании приказа такого-то по корпорации», или «на основании учебного плана кафедры ИУ7, разработать техническое задание и программное обеспечение в рамках учебного курса распределённые системы».
3. Назначение разработки. Необходимо веско аргументировать назначение программы.
Всё это обосновать детально. «Аналогичные разработки существуют, но они обладают рядом недостатков», «проанализировав предметную область, я выявил слабые места: 1. Ручной труд, 2. Неэффективно работает существующая система, 3. Избыточная функциональность существующей системы, 4. 5. 6. … другие недостатки, 7. Необходимо добавить конкретную функциональность в рамках сущ.системы». 4. Требования к программе (к программному изделию, комплексу).
4.1. Сначала высокоуровневые требования – это требования, которые касаются абсолютно всех подсистем, которые я интегрирую. Здесь можно сослаться на политические, юридические или финансовые документы, на основе которых ПО будет функционировать. Режим:. Напр., хочу разработать систему, которая должна будет работать круглый год 24 часа в сутки.
Пишут: «режим функционирования системы 24/7/365». Или «ежедневно», «ежечастно», «только по ночам» и т.д. 4.2. Функциональные требования. 4.2.1. Ф.Т с точки зрения пользователя. Требования будущих функций системы с точки зрения пользователя. Напр., «система должна предоставить возможность пользователю просмотреть список заказов», и т.п.
Короче, всё, что может сделать система для пользователя. 4.2.2. Ф.Т. с точки зрения администратора. У него полномочий больше. Администратор может не только читать, но и, в отличае от пользователя, но и изменять и т.п.
Перечисляем всё, что может сделать администратор в рамках системы. Админ и юзер – разные роли. Если есть другие роли (напр., менеджер) – то и его описываю. 4.3. Требования к функциональным характеристикам. Это «какие показатели» она будет выдавать с точки зрения реактивности системы – время реакции на запрос пользователя. Напр., «одновременно может работать NN клиентов.
Если количество клиентов больше, то время отклика увеличивается». 4.4. Надёжность. Следует указать уровень надёжности, который обязан быть у системы, и время восстановления системы после сбоя. Здесь следует описать, как производится
| Романова Т.Н. – Технология программирования [2011] by Melvin | Страница 6 |
контроль входной и выходной информации. Иногда этим занимается специальный блок контроля. Создание резервных копий. 4.5. Условия эксплуатации. «Температура, влажность» и т.п.
Напр., «система должна эксплуатироваться в нестандартных условиях (особые условия, экстремальные):». Т.е. это те технические характеристики, которые должна учитывать программа в своей работе. Этот пункт часто не пишут. Пишут его только в программно-техническом комплексе. 4.6.
К составу и параметрам технических средств. Здесь студенты часто делают ошибки. Мы отрабатываем программу на своём ПК (с его конфигурацией). А потом студенты заявляют что-то вроде «прога работает на всём!!», но ведь не факт! Она и медленнее работать будет.
Или не совместима с чем-то. Надо протестировать, и только протестировав, мы можем написать «система может работать под…. (и перечисляю всё то, под чем тестировал)».
Обычно пишут, указывая минимальные требования и рекомендуемые. «Минимальные требования к технической платформе и операционному окружению». «Техническая платформа: (прописываю всё детально)». «Операционное окружение: (какое ПО, какие платформы, какие версии и т.п.)». Рекомендуемые – это те требования, на которых будет выполняться время отклика и т.п., т.е. программа будет работать наилучшим образом.
4.7. Требования к информационной и программной совместимости. Предположим, что-то надо оптимизировать, и делаем это через Matlab. Тогда надо указать, что мы не сами модуль делали, а использовали «сторонний». Предполагаемые методы решения, язык и среду программирования, а также другие программные средства, которые должны взаимодействовать (и каким образом) с нашими программами.
С чем программа не может сосуществовать (конфликты), и т.д. ТЗ – это язык промежуточный между профессиональными программистами и заказчиками. Поэтому не должно быть никаких профессионально-жаргонных слов. «Осуществляем back-up» – не годится. Если их не избежать, то следует создать раздел «Глоссарий», в котором требуется описать слова и их определения.
Там следует указывать всю терминологию предметной области. По поводу протоколов. Если их диктует заказчик, то «основания протоколов передачи данных такие-то, по требованию заказчика». Если заказчик выдаёт сценарий работы системы, то пишу: «по требованию заказчика, сценарий работы следующий:».
А если я сам что-то определяю, то не пишу, т.к. это не исходные данные, а что-то то, чего разработать следует в ходе выполнения работы. В этом же разделе при необходимости указывают степень защиты. Т.е. нужно ли шифрование, или нет. Каким образом будет осуществляться шифрование. Весь ли трафик шифруется, или часть.
В конце привожу список стандартов, на основе которых осуществляется шифрование. А в самом начале писать: «Данное ТЗ разработано на основе ГОСТа (и полное название госта)». 4.8. Требования к программной документации. Документация бывает технологическая, научная, пользовательская и т.п.
Напр., разработали ПО, передаю её, коды и инструкцию. Пользователю передаётся только пользовательская документация, инструкцию по установке, инструкцию по использованию, и описание возможных сбоев с инструкциями по их устранению. Ещё инструкцию для администратора. Все остальные вещи – это моё know-how, передавать это не стоит, за исключением тех случаев, когда они сами хотят дорабатывать его и т.д.
| Романова Т.Н. – Технология программирования [2011] by Melvin | Страница 7 |
Источник: studfile.net
Лекция 9 Цели и принципы системного проектирования сложных программных средств
Цель управления проектом — рациональное использование и предупреждение потери ресурсов путем сбалансированного распределения их по частным работам на протяжении всего жизненного цикла объекта с заданным качеством.
Управление проектом — это особый вид деятельности, включающий постановку задач, подготовку решений, планирование, организацию и стимулирование специалистов, контроль хода работ и использования ресурсов при создании сложных систем.
Целевое управление проектами возникло из необходимости разрабатывать и реализовывать сложные системы с заданными функциями в максимально короткие сроки при ограниченных ресурсах. Критическим параметром планирования и управления проектами обычно является время.
Для интеграции усилий специалистов и эффективного использования ресурсов проекта должен выделяться лидер — менеджер, управляющий проектом.
Основная цель системного проектирования в программной инженерии — подготовить, обосновать и согласовать замыслы и решения заказчика (потребителя) и разработчика (поставщика) о необходимости, направлениях и концепции создания или модернизации существующего ПС и изменениях его качества.
Тщательное и полноценное системное проектирование выгодно с позиции ускорения разработок, предотвращения ошибок, обеспечения эффективности всего жизненного цикла и высокого качества сложных проектов комплексов программ в условиях ограниченных ресурсов.
Не предусмотренные при системном проектировании ситуации и возможные дефекты программ являются потенциальными источниками отказов и аварий при применении ряда систем. Массовая практика, когда заказчик не может сформулировать четкие требования к функциям и безопасности ПС, а разработчик не понимает, что нужно заказчику, приводит к длительному процессу разработки проектов с множеством дефектов и ошибок, на устранение которых расходуются большие ресурсы.
В результате многие системы не соответствовали исходному назначению и первоначальным спецификациям, не укладывались в графики и бюджет разработки.
Обширной практикой доказано, что обнаружение и устранение ошибок и дефектов в комплексах программ на начальных этапах системного проектирования в десятки и сотни раз быстрее и дешевле, чем в процессе завершения разработки и испытаний.
В последние десятилетия быстро возрастает сложность объектов и систем, создаваемых в различных областях индустрии. Для их разработки привлекаются специалисты разной квалификации и большие финансовые и материальные ресурсы. Использование этих ресурсов должно координироваться и объединяться комплексом мероприятий для достижения общей цели — создания соответствующего сложного объекта или системы с заданным качеством в условиях ограниченных ресурсов. Современные сложные системы и соответственно проекты, обеспечивающие их создание, имеют ряд важных особенностей:
— единую цель разработки и последующего функционирования всей системы для определенных пользователей;
— наличие совокупности нескольких, тесно взаимодействующих, компонентов
— подсистем, имеющих свои локальные задачи и цели функционирования;
— иерархическую структуру связей и взаимодействия компонентов, обеспечивающую концептуальное единство и устойчивость функционирования всей системы;
— иерархическую совокупность критериев качества функционирования компонентов и системы в целом, обеспечивающих достижение главных целей создания и последующего применение! системы пользователями.
Процессы системного проектирования программных средств
Системное проектирование в программной инженерии охватывает период жизненного цикла сложных комплексов программ, начиная от формулирования первичного замысла на создание или модернизацию системы и до начала детального проектирования и разработки ПС. В системном проекте должны быть обобщены и отражены следующие основные результаты выполненных системных исследований и разработок:
— обобщенный анализ проведенного обследования объекта информатизации, функций существующей информационной системы, качества ее основных программных компонентов и базы данных;
— совокупность предварительных исходных требований к функциям и характеристикам комплекса программ;
— оценки имеющихся и потенциально доступных ресурсов (финансовых, вычислительных средств, специалистов) для обеспечения всего жизненного цикла и требуемого качества проекта комплекса программ;
— результаты предварительного анализа возможной архитектуры комплекса программ на основе моделей и прототипов аналогичных систем, позволяющие наметить планы разработки и всего жизненного цикла проекта ПС;
— цели, задачи и функции предполагаемой новой или модернизированной системы, обобщенные в концепции создания соответствующего программного средства;
— проекты планов жизненного цикла, гарантирования требуемого качества ПС, защиты и обеспечения безопасности его функционирования;
— результаты технико-экономического обоснования целесообразности и основных направлений продолжения проектирования и всего ЖЦ ПС;
— результаты анализа существующей и возможной инструментальной среды разработки, а также системы обеспечения качества, перспективы их развития и совершенствования;
— предварительный план организации работ, требования к составу и квалификации специалистов для выполнения проекта и всего жизненного цикла ПС;
— проект формализованного технического задания и спецификации требований к ПС а также предложения по его финансированию и обеспечению ресурсами;
— системный проект, обобщающий проведенные исследования и разработки, позволяющий заключить контракт между разработчиком и заказчиком на финансирование и продолжение проектирования и/или на весь жизненный цикл ПС.
Разработка исходных требований для технического задания на проект ПС начинается с анализа результатов обследования объекта информатизации и оценки доступных ресурсов для реализации проекта. Эта деятельность требует специальной организации специалистов наивысшей квалификации и тесной совместной работы представителей заказчика и разработчика. Они должны подготовить исходные данные и документы, в которых содержатся предварительные требования и пожелания к функциональным и конструктивным характеристикам качества программного комплекса.
Далее ими должна проводиться сложная работа по предварительному упорядочению, селекции, обобщению и ранжированию приоритетов требований для их реализации в проекте. Наличие обычно ряда неформализованных, неструктурированных и противоречивых содержательных требований заказчика и разработчика требует их совместной обработки, согласования и корректировки.
Карпушева Ирина Александровна
Высшее образование, Нижегородский государственный педагогический университет им. Козьмы Минина. Пятнадцать лет педагогического стажа работы. Высшая квалификационная категория.
Источник: karpusheva.ru