A szoftverfejlesztésben a szoftverfejlesztési folyamat az a folyamat, ahol felosztjuk a szoftverfejlesztési munkát különböző fázisokra, hogy fejlesszük a tervezést, a termékmenedzsmentet és a projektmenedzsmentet. Ez szoftverfejlesztési életciklusként is ismert. A módszertan magában foglalhatja azon konkrét eredmények és előzetes elemek meghatározását, amelyeket egy projektcsapat készít egy alkalmazás kifejlesztése vagy karbantartása céljából.

A legtöbb modern fejlesztési folyamat leírható agilisnak. Egyéb módszerek: vízesés, prototípus-készítés, iteratív és inkrementális fejlesztés, spirálfejlesztés, gyors alkalmazásfejlesztés és extrém programozás.

Néhányan az életciklusos "modellt" általánosabb fogalomnak tekintik egy módszertankategória számára, a szoftverfejlesztési „folyamatot” pedig egy konkrétabb kifejezésnek, amely egy adott szervezet által kiválasztott adott folyamatra utal. Például számos olyan szoftverfejlesztési folyamat létezik, amelyek illeszkednek a spirális életciklus-modellhez. Ezt a területet gyakran a rendszerfejlesztési életciklus részhalmazának tekintik.

Történelem A szoftverfejlesztési módszertan kerete csak az 1960-as években alakult ki. Elliott (2004) szerint a rendszerfejlesztési életciklus tekinthető az információs rendszerek építésének legrégebbi formalizált módszertani keretének. Az SDLC fő gondolata az volt, hogy „az információs rendszerek fejlesztését egy nagyon megfontolt, strukturált és módszertani módon folytassák, megkövetelve az életciklus minden szakaszát – az ötlet kezdetétől a végső rendszer átadásáig – szigorúan és szekvenciálisan hajtják végre”Geoffrey Elliott (2004) Global Business Information Technology: an integrated systems approach. Pearson Education. p.87. az alkalmazott keretrendszerekkel összefüggésben. Ennek a módszertani keretnek az 1960-as években a fő célja a „nagy léptékű funkcionális üzleti rendszerek kifejlesztése volt a nagyszabású üzleti konglomerátumok korában. Az információs rendszerekkel kapcsolatos tevékenységek a nagy mennyiségű numerikus adatokat feldolgozó rutinok felé fordultak.”

A módszertan, a folyamatok és a keretek a specifikus kizárási lépésektől kezdődnek, amelyeket egy szervezet közvetlenül használhat a napi munka során, a rugalmas keretrendszerekig, amelyeket a szervezet egy adott projekt vagy csoport igényeihez igazított egyedi lépések készítéséhez használ. Egyes esetekben a „szponzor” vagy a "karbantartó" szervezet hivatalos dokumentumkészletet terjeszt, amely leírja a folyamatot. Különleges példák a következők:

1970

Strukturált programozás 1969 óta Cap Gemini SDM, az első angol fordítást kiadták 1974-ben.

1980-as évek

Strukturált rendszerelemzés és tervezési módszer (SSADM) 1980-tól kezdve Információs követelmények elemzése / puha rendszerek módszertana

1990-es évek

Objektumorientált programozás (OOP) az 1960-as évek elején alakult ki, és az 1990-es évek közepén vált domináns programozási megközelítéssé. Gyors alkalmazásfejlesztés (RAD), 1991 óta Dinamikus rendszerek fejlesztési módszere (DSDM), 1994 óta Scrum, 1995 óta Csapatszoftver-folyamat, 1998 óta Racionális egységes folyamat, amelyet az IBM 1998 óta tart fenn Extrém programozás, 1999 óta

2000-es évek

Agile Unified Process (AUP), 2005 óta karbantartja Scott Ambler Fegyelmezett agilis szállítás (DAD) felülírja az AUP-t

2010-es évek

Scaled Agile Framework (SAFe) Nagy léptékű Scrum (LeSS) DevOps

Figyelemre méltó, hogy a DSDM 1994 óta a fenti listán szereplő összes módszertan, a RUP kivételével, agilis módszer volt – mégis sok szervezet, különösen a kormányok továbbra is alkalmaznak agilis előzetes folyamatokat (gyakran vízesés vagy hasonló). A szoftver folyamata és a szoftver minősége szorosan kapcsolódnak egymáshoz; néhány váratlan aspektus és hatás megfigyelhető volt a gyakorlatban

A 2000-es évek eleje óta az agilis szállítási folyamatok méretezése a legnagyobb kihívássá vált az agilis folyamatokat használó csapatok számára.

Ezek között egy másik szoftverfejlesztési folyamat alakult ki nyílt forráskódban. Ezen ismert, bevált gyakorlatokat egy cég keretein belül belső forrásnak nevezik.

Prototípus A szoftver prototípusának meghatározása prototípusok létrehozását jelenti, azaz a fejlesztés alatt álló szoftver hiányos verzióit.

Az alapelvek a következők:

A prototípus-készítés nem önálló, komplett fejlesztési módszertan, hanem inkább megközelítés, amely a sajátos tulajdonságok kipróbálására szolgál egy teljes módszertan összefüggésében (például inkrementális, spirális vagy gyors alkalmazásfejlesztés (RAD)). Arra törekszik, hogy csökkentse a velejáró projektkockázatot azáltal, hogy egy projektet kisebb szegmensekre bont, és nagyobb változtathatóságot biztosít a fejlesztési folyamat során. Az ügyfelet bevonják a fejlesztési folyamatba, ami növeli annak valószínűségét, hogy az ügyfél elfogadja a végső megvalósítást. Míg néhány prototípust azzal a tudattal fejlesztenek ki, hogy el fogják távolítani, bizonyos esetekben lehetséges a prototípusról a működő rendszerre történő áttérés.

A helytelen problémák megoldásának elkerülése érdekében szükséges az alapvető üzleti probléma megértése, de ez igaz minden szoftver módszertanra.

Módszerek

Agilis fejlesztés Az "agilis szoftverfejlesztés" az iteratív fejlesztésen alapuló szoftverfejlesztési módszerek egy csoportjára vonatkozik, ahol a követelmények és megoldások az önszerveződő, többfunkciós csoportok közötti együttműködés révén alakulnak ki. A kifejezést 2001-ben alakították ki, amikor megfogalmazták az Agilis Manifestust.

Az agilis szoftverfejlesztés az iteratív fejlesztést veszi alapul, de a hagyományos megközelítéseknél könnyebb és emberközpontúbb nézőpont mellett áll. Az agilis folyamatok alapvetően magukban foglalják az iterációt és a folyamatos visszajelzést, amelyet a szoftverrendszer egymást követő finomítása és biztosítása érdekében nyújtanak.

Számos agilis módszertan létezik, köztük:

Dinamikus rendszerfejlesztési módszer (DSDM) Kanban Scrum

Folyamatos integráció A folyamatos integráció az a gyakorlat, ahol minden fejlesztői munkapéldányt naponta többször összevonnak egy megosztott fővonallal. Grady Booch először 1991-ben alkalmazott módszerével nevezte el és javasolta a Folyamatos integrációt, bár nem ösztönözte a napi többszöri integrációt. Az extrém programozás (XP) átvette ezt a fogalmat, és támogatja a napi egynél több integrációt – talán akár több tízszer is.

Inkrementális fejlesztés Különböző módszerek elfogadhatók a lineáris és az iteratív rendszerek fejlesztési módszertanának kombinálására, amelynek elsődleges célja az, hogy csökkentse a velejáró projektkockázatot a projekt kisebb szegmensekre bontásával és a változtatások egyszerűbbé tételével a fejlesztési folyamat során.

Az inkrementális fejlesztésnek három fő változata van:Centers for Medicare & Medicaid Services (CMS) Office of Information Service (2008). Selecting a development approach . Webarticle. United States Department of Health and Human Services (HHS). Re-validated: March 27, 2008. Retrieved 27 Oct 2008.

Minivízesések sorozatát hajtják végre, ahol a vízesés minden fázisa a rendszer egy kis részén befejeződik, mielőtt a következő lépésre lép Az általános követelményeket meghatározzák, mielőtt továbblépnének a rendszer egyes növekményeinek evolúciós, minivízeséses fejlesztésére A kezdeti szoftver koncepciót, a követelmények elemzését, valamint az architektúra és a rendszermag megtervezését a vízesés határozza meg, amelyet egy növekményes megvalósítás követ, ami pedig a végleges verziót eredményezi.

Gyors alkalmazásfejlesztés bélyegkép|Gyors alkalmazásfejlesztési (RAD) modell A gyors alkalmazásfejlesztés (RAD) egy szoftverfejlesztési módszertan, amely az iteratív fejlesztést és a prototípusok gyors felépítését támogatja a nagy mennyiségű előzetes tervezés helyett. A RAD segítségével kifejlesztett szoftverek „tervezését” magában foglalja a szoftver írása. A kiterjedt előzetes tervezés hiánya általában lehetővé teszi a szoftver sokkal gyorsabb írását, és megkönnyíti a követelmények megváltoztatását.

A gyors fejlesztési folyamat előzetes adatmodellek és üzleti folyamatmodellek fejlesztésével kezdődik, strukturált technikák felhasználásával. A következő szakaszban a követelményeket prototípus-formálással ellenőrzik, az adatok és a folyamatmodellek finomítása érdekében. Ezeket a szakaszokat iteratívan megismételjük; A további fejlesztés eredményeként "kombinált üzleti követelmények és műszaki tervezési nyilatkozat kerül felhasználásra az új rendszerek építéséhez".

A kifejezést először James Martin által 1991-ben bevezetett szoftverfejlesztési folyamat leírására használták. Whitten (2003) szerint ez különféle strukturált technikák, különösen az adatközpontú információtechnológiai tervezés és a prototípus-technikák egyesítése a szoftverrendszerek fejlesztésének felgyorsítása érdekében.

A gyors alkalmazásfejlesztés alapelvei a következők:

A fő cél a magas színvonalú rendszer gyors fejlesztése és szállítása viszonylag alacsony beruházási költségek mellett. Arra törekszik, hogy csökkentse a velejáró projektkockázatot azáltal, hogy egy projektet kisebb szegmensekre bont, és nagyobb változtathatóságot biztosít a fejlesztési folyamat során. Célja, hogy gyorsan kiváló minőségű rendszereket állítson elő, elsősorban iteratív prototípus-készítéssel (a fejlesztés bármely szakaszában), aktív felhasználói bevonással és számítógépes fejlesztési eszközökkel. Ezek az eszközök tartalmazhatnak grafikus felhasználói felület (GUI) készítőket, számítógépes szoftverfejlesztési (CASE) eszközöket, adatbázis-kezelő rendszereket (DBMS), negyedik generációs programozási nyelveket, kódgenerátorokat és objektumorientált technikákat. A legfontosabb hangsúly az üzleti igény kielégítésén áll, míg a technológiai vagy a mérnöki kiválóság kevésbé fontos. A projekt ellenőrzése magában foglalja a fejlesztés prioritását és a kézbesítési határidők vagy „idődobozok” meghatározását. Ha a projekt elcsúszik, akkor a hangsúly a követelmények csökkentésére kell hogy fókuszáljon, azért, hogy illeszkedjen az idődobozba, és nem pedig a határidő növelésére. Általában magában foglalja a közös alkalmazástervezést (JAD), ahol a felhasználók intenzíven részt vesznek a rendszertervezésben, konszenzus kialakításával akár strukturált műhelyekben, akár elektronikusan megkönnyített interakción keresztül. Az aktív felhasználói részvétel nélkülözhetetlen. Iteratív módon készít sorozatszoftvert, szemben az eldobható prototípussal. A jövőbeli fejlesztés és karbantartás megkönnyítéséhez szükséges dokumentációt állít elő. A szokásos rendszerelemzési és tervezési módszerek illeszthetők ebbe a keretbe.

Spirális fejlesztés bélyegkép|400x400px| Spirálmodell (Boehm, 1988) 1988-ban Barry Boehm kiadott egy hivatalos szoftverrendszer-fejlesztési „spirálmodellt”, amely egyesíti a vízesésmodell néhány kulcsfontosságú aspektusát és a gyors prototípus-készítési módszertanokat annak érdekében, hogy ötvözzék a felülről lefelé és az alulról felfelé építkező koncepciók előnyeit. Fontos hangsúlyt fektet egy kulcsfontosságú területre, amelyet sok más módszer elhanyagol: szándékos iteratív kockázatelemzés, különösen a nagyszabású komplex rendszerek számára.

Az alapelvek a következők:

A hangsúly a kockázatértékelésre és a projekt kockázatának minimalizálására irányul. A projektet kisebb szegmensekre bontja és nagyobb változtathatóságot biztosít a fejlesztési folyamat során, valamint lehetőséget kínál a kockázatok felmérésére és a projekt folytatásának mérlegelésére az életciklus során. "Minden ciklus a termék minden egyes részén és minden kidolgozási szintjén ugyanazon lépések sorozatával halad előre, a működési koncepció átfogó dokumentumától kezdve az egyes programok kódolásáig."Barry Boehm (1996)., "A Spiral Model of Software Development and Enhancement". In: ACM SIGSOFT Software Engineering Notes (ACM) 11(4):14-24, August 1986