1) Общие сведения. (Указывается общие сведения о создаваемой системе)
 Скачать 60 Kb.
|
|
Техническое задание. ТЗ на ИС является основным документом, определяющим требования и порядок создания ИС в соответствии с которым производится разработка ИС и ее приемка при вводе в эксплуатацию. ТЗ включает в себя системное описание расширенных требований к разрабатываемому программному продукту, который может функционировать либо самостоятельно, либо в составе другой системы. В состав ТЗ принято включать следующие разделы. 1) Общие сведения. (Указывается общие сведения о создаваемой системе) 2) Назначение и цели создания (развития) ИС. 3) характеристика объектов автоматизации - в данной части приводятся описания деятельности или схемы тех объектов, для которых создается ИС. 4) требования к системе. 5) состав и содержание работ по созданию системы. 6) порядок контроля и приемки системы. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие: 1) требования к документированию. 2) источники разработки (материалы, передаваемые заказчику) Это то что содержится в тех задании согласно госту 34-602. Согласно стандарту IEEE-830 в практике ведущих компаний принято создавать спецификацию требований к программному обеспечению. В рамках данного стандарта принято выделять след разделы 1) введение - состоит из 4 подразделов: а) цель ( в данном подразделе отражается цель документа, а не цель ИС) б) область примирения ( в данном подразделе указываются отдельные аспекты программного продукта, которые содержатся в данном документе) в) определения, термины и сокращения г) ссылки ( в данном подразделе указываются ссылки на документы, которые буду использоваться при создании ИС) д) Обзор. 2) общие описания - дается представление проектируемой системы с точки зрения ее назначения в целом. Это описание необходимо сделать достаточно общим, чтобы оно несущественно изменялось в будущих версиях, кроме того здесь перечисляются Общесистемные и отраслевые требования к системам заданного класса. 3) детальные требования - 4) дополнительная информация в подразделе 2.1 указываются перспективы программного продукта и дается представление о сравнении проектируемой ИС с аналогичными программными продуктами. В рамках данного подраздела могут использоваться различные инструменты, дающие представления о концепции создаваемой системы ( DFD-диаграммы, UseCase и т.д.). Так же могут приводится проекты пользовательских интерфейсов и других особенностях создаваемого программного продукта. В разделе 2.2 содержится сводка сведений об основных функциях разрабатываемого приложения. Здесь рекомендуется приводить особенности реализации функции продукта посредством диаграмм языка УМЛ (ДВИ, Диаграмма Последовательностей, Диаграмма Классов, Диаграмма деятельности или взаимодействия. В пункте 2.3 указываются пользовательские характеристики. Иными словами указываются особенности пользователей создаваемого продукта. Это необходимо для того, чтобы разработчики имели представление об уровне владения компьютером бедующих пользователей и учитывали эти знания при создании ИС. В разделе 2.4 указываются всевозможные ограничения на процесс проектирования и разработки ИС, а так же описываются границы и условия того, как приложение задумано и как оно должно работать, здесь, например, могут указываться ограничения на используемые языки программирования, на возможность изменения пользователям функционала, совместимости и т.д. В пункте 2.5 предполагают указания предположений и зависимостей. В данном разделе Заказчик указывает возможные допущения (отступления) которые возможны в программном продукте. Пункт 2.6 содержит требования, ориентированные на заказчиков и на исполнителей. В 3 разделе, посвященным детальному описанию требований приводится полный список конкретных свойств и функциональности, которую должна иметь программа. Каждое детальное требование должно быть пронумеровано и отслеживаться его реализация в процессе разработки. Чаще всего в данном разделе проводятся сопоставления так называемых С-требований ( требований заказчика ) и D-требований ( требований исполнителей ). Эти 2 вида требований должны быть согласованы. Требования, которые согласовать не удалось либо подлежат исправлению, либо удаляются. В данном разделе принято выделять следующие подразделы. 3.1) требования к внешнему интерфейсу 3.2) описание детальных требований 3.3) требования к производительности. 3.4) ограничения проектирования 3.5) атрибуты программной системы 3.6) дополнительные требования. В 4 разделе содержится вся дополнительная информация. Управление проектом по созданию ИС. Оценка трудоемкости создаваемого ПО. Модели и методы оценки трудоемкости используются для решения следующих Важениных задач процесса управления программным проектом: 1) Разработка бюджета проекта. 2) Анализ степени риска и выбор компромиссного решения. 3) Планирование и управление проектом. 4) Анализ затрат на улучшение качества ПО. Недооценка стоимости, времени и ресурсов, требуемых для создания ПО, влечёт за собой недостаточную численность проектной команды, чрезмерно сжатые сроки и, как следствие, нарушение доверия заказчика. С другой стороны, переоценка требуемых ресурсов может значительно снизить экономическую эффективность разрабатываемого проекта. Замечание** Практика свидетельствует о том, что большинство проектов требуют большего объема ресурсов, чем запланировано. ** Для оценки трудоемкости проектов существует несколько групп методов. Алгоритмические методы, экспертные оценки, оценка по аналогии, Эластические закономерности. Рассмотрим методику оценки трудоёмкости разработки ПО на основе так называемых функциональных точек. Определение числа функциональных точек является методом количественной оценки ПО применяемым для измерения функциональных характеристик процессов его разработки и сопровождением независимо от технологии, использованных для его реализации. Согласно рассматриваемой методике трудоемкость вычисляется на основе функциональности разрабатываемой системы, которая в свою очередь определяется на основе выявления функциональных типов - логических групп взаимосвязанных данных, используемых и поддерживаемых приложением, а так же элементарных процессов, связанных с выводом и вводом информации. Порядок расчета трудоемкости разработки ПО следующий: 1) Определение количества и сложности функциональных типов приложения 2) Определение количества связано с каждым функциональным типов элементарных данных, элементарных записей и элементарных файлов типа ссылок. 3) Определение сложности в зависимости от выделенных функциональных типов. 4) Подсчет количества функциональных точек приложения. 5) Подсчет количества функциональных точек с учетом общих характеристик системы. 6) оценка трудоемкости разработки с использованием различных статистических данных. В состав функциональных типов включаются следующие элементы приложений разрабатываемой системы: 1) Внутренний логический файл (ILF) - идентифицируемая совокупность логически-взаимосвязанных записей данных, поддерживаемая внутри приложения посредством элементарного процесса. 2) Внешний интерфейсный файл (EIF) - Идентифицируемая совокупность логически-взаимосвязанных записей данных, передаваемых другому приложению или получаемых от него и поддерживаемых вне данного приложения. 3) Входной элемент приложения (EI) - элементарный процесс, связанный с обработкой входной информации приложения (входного документа или экранной формы). 4) Выходной элемент приложения (EO) - элементарный процесс, связанный с обработкой выходной информации приложения (выходного отчета, документа и т.д.). 5) Внешний запрос (EQ) - элементарный процесс, состоящий из комбинации Запрос-Ответ, не связанный с вычислением производных данных или обновлением базы данных Количество функциональных типов по данным определяется на основе диаграммы классов. Если объекты класса находятся внутри приложения, то это соответствует внутреннему логическому файлу ILT. Если объекты класса не существуют в системе, а получаются в результате обработки запросов в базе данных, то это внешний интерфейсный файл EIF. Далее для каждого функционального типа определяется его сложность (высокая, средняя, низкая). Она зависит от количества связанных с рассматриваемым функциональным типом элементарных данных (DET) и элементарных записей (RET). Один дет соответствует одному атрибуту или связи класса. Замечание** Количеству ДЕТ не зависит от количества объектов класса. *** Одна РЕТ соответствует либо абстрактному классу в связи обобщения, либо классу части Целое в композиции, либо классу Родитель-потомок (т.е. связь типа Агрегация). После того, как подсчитаны все ДЕТ и РЕТ по специальным таблицам определяется сложность функционального типа, далее для каждого функционального типа так же по специальным таблицам оценивается количество входящих в его состав функциональных точек. В результате суммирования функциональных точек по всем функциональным типам определяется общее количество функциональных точек. И далее по специальным формулам определяется общее количество функциональных точек приложения. Существуют так же теоритические модели, предполагающие аналитическую связь между трудоемкостью и какими-либо факторами влияющими на трудоемкость. На практике получили распространение так называемые нелинейные модели. Они имеют следующий общий вид: Трудоёмкость=А*(размер ПО)^b, где А - совокупность факторов влияющих на трудоемкость, В - масштабный коэффициент. По-видимому наиболее известной из алгоритмических моделей является модель COCOMO2. В рамках данной модели используются следующие допущения: 1) Исходный код конечного продукта включает в себя все строки за исключением комментария. 2) начало цикла разработки совпадает с началом разработки продукта, а окончание совпадает с окончанием приемочного тестирования. 3) Виды деятельности включают в себя только непосредственно направленные на выполнение проекта работы. 4) Человеко-месяц состоит из 152 часов. 5) В ходе выполнения проекта требования не меняются. Уравнения СОСОМО2 для оценки номинальных значений трудоемкости и времени имеют следующий вид: DM(NS)=A*(size)^E*П(i=1,N)(EM(i)), где b=В+0,01*сумма(поJ=1,5)(SF(j)) (трудоемкость в человеко-часах), а календарное время TDEN=S*(PM(NS))^F, где F=D+0,002*сумма(поj=1,5)(SF(j)). Здесь ЕМ(i) - мультипликативный коэффициент трудоемкости, определяемый по специальной таблице. SF(j) - экспоненциальный коэффициенты масштаба, так же определяемые по таблице. Size - Размер ПО, выраженные в тысячах строках исходного кода. А=2,94; В=0,91; С=3,67; D=0,28. В заключение рассмотрим методику оценки трудоемкости разработки ПО на основе вариантов использования. Все действующие лица подразделяются на 3 группы: 1) Простые - представляет собой внешнюю систему с четкоопределенных программным интерфейсом. 2) Средние - представляет собой либо внешнюю систему, взаимодействующую с данной посредством какого-либо протокола, либо личность, пользующуюся текстовым интерфейсом. 3) Сложные - представляет личность, пользующуюся графическом интерфейсом, подсчитанное кол-во действующих лиц умножается на соответствующий весовой коэффициент, а затем, путем сложения, определяется общий весовой показатель. Аналогичным образом рассчитывается сложность технического проекта, уровень квалификации и, в результате, получается итоговая оценка в человеко-часах на один вариант использования. Практика показывает, что в среднем на простой вариант использования уходит 150 часов, на сложный - 350 часов. Замечание** В литературе принято следующее соотношение времени и объема работ
*** Управление проектом по созданию ИС. Замечание** для того чтобы получить общее представление о менеджменте в сфере управления проектами по созданию ИС рекомендуется ознакомиться с профессиональным стандартом <менеджер программных проектов>, а так же с ГОСТом 54800-69 - требования к управлению проектом. ** Практика создания программных проектов определила ряд требований которыми должен удовлетворять кандидат на должность менеджера по управлению проектом. 1) процессы оценивания (Признание кандидатом критериев которые могут быть использованы при осуществлении обзора программных решений) 2) знание стандартов процесса 3) определение продукта (идентификация предметной области и требований предъявляемых к создаваемому продукту) 4) оценка альтернативных подходов (выбор той или иной методологии создания проекта). замечание** для небольших типичных проектов рекомендуется использовать методологию быстрой разработки ПО.** 5) управление требованиями (мониторинг изменений требований) 6) управление субподрядчиками (планирование, управление и осуществление контроля за деятельностью лиц которая не являются непосредственными участниками проекта и выполняют какие-либо работы по договору) 7) выполнение начальной оценки (оценка степени трудности создаваемого ПО, рисков, затрат и создание графика работ) 8) отбор методов и инструментов 9) подгонка процессов (модификация стандартных процессов с целью удовлетворения требований, выдвигаемых в рамках проекта) 10) отслеживание качества продукта (контроль качества в процессе разработки ис) 11) понимание действий по разработке ИС 12) оценка производительности (оценка текущей производительности команды и разработка иер по ещё повышению) 13) вопросы интеллектуальной собственности 14) организация эффективных встреч 15) взаимодействие и общение (взаимодействие с разработчиками, высшим руководством и другими командованиями) 16) лидерство (обучение проектных команд для получения оптимальных результатов) 17) управление изменениями (обеспечение эффективного управления изменениями как внутри проекта так и вне его) 18) успешное ведение переговоров (в данном случае понимается успешное разрешение конфликтов между заинтересованными лицами) 19) планирование карьерного роста (создание условий для карьерного роста всех участников команды, стимулирование) 20) эффективное представление проекта (умение делать презентации) 21) набор персонала 22) отбор команды 23) создание команды 24) оценка стоимости 25) оценка трудозатрат 26) выбор метрических показателей 27) отбор инструментов применяемых для управления 28) составление календарного графика выполнения работ 29) составление временного графика выполнения работ 30) составление стоимостного графика выполнения работ Замечание** современная практика предполагает использование диаграммы Гантта** 31) документирование 32) обратная связь с заказчиком 33) умение продвигать программный продукт 34) оценка результатов проекта Структура отчёта итогового отчета по лабораторным. 1) структурное моделирование объекта автоматизации (структурное моделирование предметной области) замечание** все графические объекты должны быть прокомментированы в необходимом читателю объёме. ** 2) анализ требований к системе (дви + спецификация) 3) проектирование нотации uml 4) технические задание (гост34602 или ЕЕЕ) |