Процесс разработки ПО

Как уже упоминалось выше, что при создании моего программного продукта, я использовал спиральную модель разработки программного обеспечения. Так почему же была выбрана именно спиральная модель? Спиральное модель — это улучшенная водопадная модель. Чем же она лучше вышесказанной модели? А лучше она тем, что в ней учтены недостатки водопадной модели. А одним из главных недостатков водопадной модели является «слабое» управление рисками. Интеграция всех результатов обработки в водопадной модели происходит лишь в конце. А это влечет за собой позднее выявление проблем и ошибок, которые могли возникнуть во время разработки программного продукта. В спиральной модели этот недостаток учтен. Интеграция результатов происходит несколько раз, в течение создания проекта. То есть создателями выделяются некие рамки и точки в периоде создания программного продукта, во время которых идет полный анализ уже проделанной работы и выявление недостатков или ошибок.

Сфера покупок и продаж очень динамичная среда, в которой позднее выявление недостатков того или иного звена системы может повлечь за собой огромные убытки. Очень редко покупатель закрывает глаза на неудобный интерфейс, на неправильные списки товаров, на все то, что может принести ему неудобство и дискомфорт во время процесса выбора и покупки товара. Поэтому я просто не мог рисковать, создавая разово проект и запуская его на реализацию.

Первым этапом создания моего программного продукта являлась реализация Администраторской части программы. Почему я начал именно с этого звена, а не с покупателя? Потому что при отсутствии полного управления, вся система может «развалиться на глазах». При создании этого блока программы учитывались интересы заказчика данного продукта. А именно полный контроль. Как же его осуществить? Администратор должен видеть все. Он должен видеть заказы, которые поступают в его фирму, что бы была возможность контроля количества оставшегося товара на складе, мог определить примерные сроки доставки и знать, когда нужно пополнение товара. Он должен видеть весь список складов, которые принадлежат фирме. Что бы опять же иметь четкое представление, когда и сколько ему нужно товара от производства. Но лишь видеть полную информацию для администратора — это слишком мало. Администратор должен иметь возможность самостоятельно добавлять приходы и информацию о них.

Для чего это нужно? Что бы сотрудники складского помещения отчетливо знали, когда и в каком количестве им приедет партии товара, что бы принять отгрузку и распределить товар на территории склада. Приобретая новое помещение, под склад, фирма может с помощью администратора внести в свою программу данные о новом складском помещении. Когда фирма заключает новые договора по поставке нового продукта, в этих сделках сотрудники складов не участвуют. А значит администратор, как никто другой лучше знает всю информацию о новом товаре. Поэтому было принято решение, добавить в административный блок программного продукта возможность администратору самостоятельно пополнять список продаваемой продукции.

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

Следующим этапом в создании моего проекта являлась разработка программной части для сотрудников склада. Было четко решено, что никаким добавление информации, кроме фактической, сотрудники склада заниматься не будут. Но что же такое фактическая информация. А фактическая информация — это на склад приехал приход груза или продукции. Менеджер принял этот товар, установил его в отведенное место на складе и занес в программу, сколько и какого товара по факту он получил. И не более того. Так в чем же заключается основная задача менеджеров?

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

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