1.2 Постановка задачі розробки інтернет магазину з продажу мообільних телефонів

У наш час людська праця стала не тільки приємною, а ще й легкою. Багато роботи за людей виконують їх вироби, тобто машини. У зв’язку з появою портотивних комп’ютерів та всесвітньої мережі Інтернет у людини виникла ідея «Інтернет магазину». Але саме зараз продаж товарів через всесвітню мережу Інтернет набув таких масштабів, що можна говорити про їх актуальність.

Саме зараз дуже популярними Інтернет магазинами стали магазини мобільних телефонів, так як у наш час мобільний телефон це дуже велика користь та поміч людству. Перевагами онлайн – покупок мобільних телефонів є: великий різновид товарів, можливість ознайомлення з описом товару для вибору найбільш підходящого, та найголовніше - економія грошей. Товари у Інтернет магазині не потребують витрат на аренду приміщень, найму робітників – консультантів, продавців, охоронців та інш. Обирати товари через мережу інтернет дуже зручно, адже можна детально вивчити інформацію щодо нього та зробити покупку не виходячи з дому. Також на покупця ніхто не давить, тому можна вільно роздивлятися усі товари, що є на складі.

Кожен покупець при замовленні мобільного телефону протягом невеликого проміжку часу 100% отримує своє замовлення.

Створений Інтернет магазин допоможе власнику вести облік свого товару та бачити тенденції продажів. Користувачі ж завжди будуть у курсі, які товари існують на ринку мобільних телефонів, та матимуть змогу слідкувати за виходами до продажу нових моделей. Створений електронний магазин допоможе замовнику проводити реалізацію свого товару через мережу Інтернет. Він матиме усі можливості для ведення свого бізнесу та отримуватиме прибуток. В свою чергу користувачі будуть забезпечені зручними умовами для створення покупок, витрачаючи при цьому менше грошей. Таким чином створення даного ресурсу принесе користь обом сторонам відносин «продавець-покупець».

2 Проектування програмного продукту web-вузла інтернет-магазину з продажу мобильних телефонів

2.1 Визначення моделі процесу розробки пп

Розглянемо модель водоспаду.

Модель водоспаду (waterfall model або послідовна розробка) - напевно, найвідоміший, історично з'явився одним з перших процес розробки. Він був описаний у статті Ройса (WWRoyce) в 1970 році (насправді, Ройс критикував цей процес, пропонуючи як альтернативу ітеративну розробку). Основна ідея полягає в тому, що процес розробки ділиться на чітко визначені фази, що виконуються строго послідовно.

Окремі завдання, з яких складається будь-який проект (не обов'язково виконується за моделлю водоспаду), можна розділити між декількома процесними областями. Класична водоспадна модель включає наступні області [4]:

• розробка вимог (requirements): збір бізнес-вимог замовника і їх перетворення в функціональні вимоги до програмного продукту;

• аналіз і дизайн (analysis and design): розробка моделі предметної області (domain model), проектування схеми бази даних, об'єктної моделі, користувальницького інтерфейсу і т.п.;

• реалізація (implementation): створення продукту по специфікаціям, розробленим на попередньому етапі;

• тестування (testing): включає перевірку відповідності функціональності програмного продукту потребам користувачів (validation), а також пошук дефектів в реалізації;

• розгортання (deployment): навчання користувачів, інсталяція системи, переклад в промислову експлуатацію.

У моделі водоспаду кожна з процесних областей являє собою окрему фазу проекту. Фази виконуються строго послідовно, тобто аналіз і дизайн починаються після завершення розробки вимог, початку реалізації передує завершення дизайну і т.д.

Основні міркування для використання такої моделі розробки цілком очевидні. Як відомо, вартість виправлення помилок, зроблених в ході виконання проекту залежить від того, наскільки швидко ці помилки виявляються і виправляються. Помилку у вимогах досить просто виправити на етапі розробки вимог, але якщо про неї стає відомо після завершення розгортання, наслідки можуть бути катастрофічними. Модель водоспаду прагне зменшити, наскільки це можливо, число таких довгоживучих помилок. Для цього розробка дизайну не повинна починатися, поки вимоги не будуть визначені з достатньою якістю, кодування не починається до появи повної дизайну системи і т.д.

Такий підхід добре працює в проектах, де вимоги можуть бути чітко визначені і зафіксовані. В таких проектах модель водоспаду дозволяє забезпечити заданий рівень якості (який може бути досить високим) і дотримуватися бюджетні та часові обмеження. Завдяки цьому вона часто використовується у великих організаціях при суворих вимогах до надійності створюваного ПЗ.

Однак практика показала наступні недоліки цього процессу.

1. Процес погано працює в проектах з нечіткими вимогами. Навіть якщо проектна команда вважає, що повністю пропрацювала і документувала функціональний дизайн системи, він може значно відрізнятися від очікувань користувачів. З великою ймовірністю ця розбіжність буде виявлено не на етапі рецензування функціональної специфікації (рідкісний замовник здатний представити поведінку реальної системи, читаючи документ з описом її функціональності), а під час впровадження продукту.

2. Процес украй неефективний при постійних змінах вимог (що як правило трапляється в проектах, що тривають більше одного-двох місяців). Кожна зміна змушує повертатися до фази визначення вимог і повторювати весь процес з початку.

3. Складно управляти ризиками деяких типів (таких, як ризики, пов'язані з використанням нових технологій або ризики некоректного визначення вимог). Подібні ризики можуть проявити себе тільки на етапі реалізації (якщо не тестування), коли число можливих шляхів виправлення ситуації набагато менше, ніж на початку проекту.

4. Вельми обмежені можливості оцінки і коректування важливих атрибутів проекту - швидкості розробки, якості продукту, обгрунтованості прийнятих архітектурних рішень. Адекватно оцінити ці атрибути стає можливим тільки на пізніх етапах проекту.

Модель водоспаду є розумним вибором для типових, стандартних проектів або при наявності жорстких вимог до якості. Тим не менше, її недоліки дуже серйозні, і для розробки комерційного ПЗ, як правило, існують значно більш ефективні альтернативи.

Розглянемо ітеративну модель розробки.

Процес ітеративної (або інкрементальной) розробки став еволюційним розвитком моделі водоспаду. Процес складається з серії повторюваних ітерацій (їх число залежить від конкретного проекту), кожна з яких фактично є повноцінним міні-проектом з фазами визначення вимог, аналізу, дизайну і т.д. У результаті чергової ітерації продукт набуває нову функціональність або поліпшення в існуючій функціональності. Повний набір вимог, зафіксований межами проекту, виявляється реалізованим після завершення фінальної ітерації.

Грунтуючись на специфіці проекту та вимоги замовника, розробники можуть вибирати, що вони хочуть отримати в результаті чергової ітерації:

• повноцінну систему з обмеженою функціональністю, готову для промислової експлуатації;

• функціональні та архітектурні прототипи, непридатні для промислової експлуатації, але дозволяють оцінити функціональний дизайн, користувальницький інтерфейс, продуктивність і т.д.

Ітеративна розробка має ряд переваг у порівнянні з послідовною (водоспадною) моделлю.

1. Реалізація найбільш важливих функцій може бути завершена в ході декількох перших ітерацій. Після їх завершення (тобто набагато раніше закінчення всього проекту) замовник зможе почати використання системи.

2. Вже на початку проекту користувачі отримують можливість оцінити фунціональном системи та її відповідність своїм потребам. Необхідні зміни і доповнення можуть бути зроблені протягом наступних ітерацій.

3. Основні проектні ризики можуть (і повинні) бути дозволені на перших ітераціях. Наприклад, архітектурне рішення, що приводить до неприйнятною продуктивності може бути виявлено і виправлено вже в першій ітерації.

Важливо розуміти, що всі ці переваги проявляються тільки при ретельному плануванні ітерацій, в іншому випадку легко отримати погіршений варіант моделі водоспаду. Ітеративна модель використовується в багатьох процесах розробки, включаючи RUP і гнучкіметодології.

Розлянемо спіральну модель розробки.

Спіральна модель була розроблена з більшою ретельністю, ніж інші методики, в розробці за принципом спіралі особливу увагу приділено оцінці альтернативних варіантів і оцінки ризиків. Критичний аналіз, який здійснюється в кінці кожної фази, забезпечує перехід до наступної фази або в разі необхідності визначає потребу в повторному виконанні кожної фази.

Переваги спіральної моделі:

• спіральна модель дозволяє користувачам "побачити" систему на ранніх етапах, що забезпечується за допомогою використання прискореного прототипування в життєвому циклі розробки ПЗ;

• забезпечується визначення непереборних ризиків без особливих додаткових витрат;

• ця модель дозволяє користувачам активно приймати участь при плануванні, аналізі ризиків, розробці, а також при виконанні оцінних дій;

• вона забезпечує розбиття великого потенційного обсягу роботи з розробки продукту на невеликі частини, в яких спочатку реалізуються вирішальні функції з високим ступенем ризику, що дозволяють усунути необхідність продовження роботи над проектом (таким чином, у разі необхідності стає можливим припинити роботу над проектом, і зменшуються витрати);

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

• реалізовані переваги інкрементной моделі, а саме випуск інкрементом, скорочення графіка допомогою перекривання інкремент, розсортованих за версіями, і незмінність ресурсів при поступовому зростанні системи;

• тут не ставиться мета виконати неможливе - довести конструкцію до досконалості;

• зворотний зв'язок у напрямку від користувачів до розробників виконується з високою частотою і на ранніх етапах моделі, що забезпечує створення потрібного продукту високої якості;

• відбувається удосконалення адміністративного управління над процесом забезпечення якості, правильністю виконання процесу розробки, витратами, дотриманням графіка і кадровим забезпеченням, що досягається шляхом виконання огляду в кінці кожної ітерації;

• підвищується продуктивність завдяки використанню придатних для повторного використання властивостей;

• підвищується ймовірність передбачуваного поведінки системи за допомогою уточнення поставлених цілей;

• при використанні спіральної моделі не потрібно розподіляти заздалегідь усі необхідні для виконання проекту фінансові ресурси;

• можна виконувати часту оцінку сукупних витрат, а зменшення ризиків пов'язане з витратами.

Недоліки спіральної моделі:

• якщо проект має низький ступінь ризику або невеликі розміри, модель може виявитися дорогою, бо оцінка ризиків після проходження кожної спіралі пов'язана з великими витратами;

• модель має ускладнену структуру, тому може бути складно її застосування розробниками, менеджерами та замовниками;

• серйозна потреба у високопрофесійних знаннях для оцінки ризиків;

• спіраль може тривати до нескінченності, оскільки кожна відповідна реакція замовника на створену версію може породжувати новий цикл, що віддаляє закінчення роботи над проектом (прийняття спільного рішення про припинення процесу розробки);

• велика кількість проміжних стадій може привести до необхідності в обробці внутрішньої додаткової і зовнішньої документації;

• використання моделі може виявитися дорогим і навіть неприпустимим за коштами, так як час, витрачений на планування, повторне визначення цілей, виконання аналізу ризиків та прототипування,може бути надмірним;

• при виконанні дій на етапі поза процесом розробки виникає необхідність в перепризначенні розробників;

• можуть виникнути труднощі при визначенні цілей і стадій, які вказують на готовність продовжувати процес розробки на наступній ітерації;

• відсутність хорошого засобу або методу прототипування може зробити користування моделі незручним;

• у виробництві використання спіральної моделі ще не отримало такого широкого масштабу, як застосування інших моделей.

Спіральна модель втілює в собі переваги каскадної моделі. При цьому в неї також включені аналіз ризиків, управління ними, а також процеси підтримки та менеджменту. Тут також передбачено розробку програмного продукту при використанні методу прототипування або швидкої розробки додатків за допомогою застосування мов програмування і засобів розробки четвертого покоління (і вище). Модель відображає базову концепцію, яка полягає в тому, що кожен цикл являє собою набір операцій, якому відповідає така ж кількість стадій, як і в моделі каскадного процесу. Причому береться до уваги кожна складова частина продукту, і кожен рівень складності, починаючи із загального формулювання потреб і закінчуючи кодуванням кожної окремої програми.

Порівнявши усі моделі, їх переваги і недоліки, була обрана модель ітеративної розробки для даного ПП.