Szoftver cég - Software company

A szoftvercég olyan vállalat, amelynek elsődleges termékei a szoftver különböző formái , szoftvertechnológia, forgalmazás és szoftverfejlesztés. Ők alkotják a szoftveripart .

Típusok

Számos különböző típusú szoftvercég létezik:

• Vannak olyan cégek, amelyek kereskedelmi forgalomban kapható (COTS) termékeket használnak, mint például a Microsoft Outlook, Word és Excel, az Adobe Systems Acrobat, Illustrator és más tervezőeszközei, vagy a Google-alkalmazások, például a Chrome.
• Sok vállalat nyújt szoftverfejlesztési szolgáltatásokat, és rendelkezik olyan struktúrával, amely egyedi szoftvereket fejleszt más vállalatok és vállalkozások számára.
• Speciális kereskedelmi szoftvereket gyártó cégek, például a Panorama , a Hyperion és a Siebel Systems
• A szoftvereket szolgáltatásként ( SaaS ) szolgáltató vállalatok , például a Google Gmail, Voice és Maps e -mail szolgáltatása, valamint a Salesforce és a Zendesk.
• Olyan technológia, amely mobilizálja a közösségi médiát, mint a Facebook , a LinkedIn , az Instagram , a Twitter és a Parler .
• Vannak más típusú SaaS -termékek is, olyan vállalatok, amelyek IT infrastrukturális szolgáltatásokat és felhőalapú számítástechnikai szolgáltatásokat nyújtanak, mint például az Amazon Web Services (AWS) , a Microsoft Azure Cloud Services és a GoDaddy hosting szolgáltatások.
• API, mint szolgáltatás, amely lehetővé teszi harmadik felek fejlesztőinek, hogy kölcsönhatásba lépjenek egy vállalati szoftverrel, például a Google Geo Location API -val, a Google Calendar API -val stb.
• Szoftverkomponenseket gyártó vállalatok , például Syncfusion , DevExpress, Telerik UI, Kendo UI és Dundas
• Alkalmazásszolgáltató, például a Salesforce
• Vállalatok, amelyek egyedi szoftvereket gyártanak vertikális iparágakhoz vagy bizonyos földrajzi régiókhoz
• Független szoftvergyártók (ISV), amelyek a végfelhasználók által fogyasztott fogyasztói vagy vállalati szoftvereket építenek, fejlesztenek és értékesítenek

Mindezek a következők egy vagy több kategóriájába sorolhatók:

• szerződéses - amikor a szoftvercéget arra szerződik, hogy bizonyos szoftvereket kívülről szállítson (szoftverek kiszervezése )
• termékfejlesztés - ha használatra kész, csomagolt szoftvert állít elő; Kereskedelmi polcon

Közös szerepek egy szoftvercégben

A szoftvercég szervezése egy nagyon speciális irányítási készség, ahol a tapasztalt személyek egyedülálló előnyökké tudják alakítani a szervezeti problémát. Például, ha az alcsoportok különböző időzónákban oszlanak meg, 24 órás vállalati munkanapot is engedélyezhet, ha a csapatok, rendszerek és eljárások jól fel vannak szerelve. Jó példa erre a 8 órával a fejlesztőcsapat előtt vagy mögött álló időzónában lévő tesztcsapat, akik kijavítják a tesztelők által talált szoftverhibákat .

Egy professzionális szoftvercég általában legalább három dedikált alcsoportból áll:

• Üzleti elemzők, akik meghatározzák a piac üzleti igényeit
• Szoftverfejlesztők, akik létrehozzák a műszaki leírást és megírják a szoftvert
• Szoftvertesztelők, akik felelősek a minőségirányítás teljes folyamatáért

A nagyobb szoftvercégeknél nagyobb szakosodást alkalmaznak, és gyakran előfordulnak:

• Műszaki írók, akik megírják az összes dokumentációt, például a felhasználói útmutatókat
• Engedje fel a szakembereket, akik felelősek a teljes termék és a szoftververzió kialakításáért
• Felhasználói élménytervezők , akik a tervezési architektúrát az üzleti követelmények, a felhasználói kutatások és a használhatóság szakértelme alapján hozzák létre
• Grafikusok, akik általában felelősek a grafikus felhasználói felület kialakításáért .
• Karbantartó mérnökök, akik két, három vagy több támogatási vonal mögött állnak
• A tanácsadók felelősek a megoldás működőképességéért, különösen akkor, ha bizonyos szakértelem szükséges. Példák erre: többdimenziós kockák építése az üzleti intelligencia szoftverben , integrálás a meglévő megoldásokkal, és üzleti forgatókönyvek megvalósítása az üzleti folyamatkezelő szoftverben.

Szerkezet

Egy szoftvercég vezetőjét általában Fejlesztési Vezetőnek (HOD) nevezik, és jelentést tesz az érdekelteknek . Ő vezeti az alcsoportokat közvetlenül vagy a vezetőkön/vezetőkön keresztül a szervezet méretétől függően . Általában legfeljebb 10 fős csapatok működnek a leginkább. Nagyobb szervezetekben általában két hierarchia -modell létezik:

Minden csapat teljesen független, és külön dolgoznak a különböző projekteken. A felépítés meglehetősen egyszerű, és az összes alkalmazott egy személynek számol be, ami egyértelművé teszi a helyzetet, de nem jó megoldás a tudáscsere és az emberi erőforrások optimális felhasználása szempontjából.

Ebben a modellben minden fő szakterületen elkötelezett menedzserek/vezetők vannak, akik "bérbe adják" embereiket bizonyos projektekhez, amelyeket termék-/projektmenedzserek vezetnek, akik hivatalosan vagy informálisan megvásárolják az embereket és fizetnek az idejükért. Ez azt eredményezi, hogy minden magán alkalmazottnak két főnöke van - a termék-/projektmenedzser és a speciális "erőforrás -menedzser". Egyrészt optimalizálja az emberi erőforrások felhasználását, másrészt konfliktusokat idézhet elő azzal kapcsolatban, hogy az egyik vezetőnek mi a prioritása a struktúrában.

Ezeknek a struktúráknak is számos változata létezik, és számos szervezetnél ez a struktúra elterjedt és megosztott a különböző osztályokon és egységeken belül.

Módszerek

A szoftvergyártók számos különböző módszert alkalmazhatnak a kód előállításához. Ezek a következők lehetnek:

• a vízesés modellje , beleértve a projektmenedzsment módszereket, mint a PRINCE2 vagy a PMBoK
• agilis szoftverfejlesztés , például Extreme Programming és SCRUM

Vannak olyan módszerek is, amelyek mindkettőt kombinálják, például a spirálmodell , a Rational Unified Process (RUP) vagy az MSF .

Termék életciklus

Az alkalmazott módszertől függetlenül a termék életciklusa legalább három szakaszból áll:

• Tervezés - beleértve mind az üzleti, mind a műszaki előírásokat
• Kódolás - maga a fejlesztés
• Tesztelés - a minőségirányítás

Ideális esetben minden szakasz a teljes idő 30% -át veszi igénybe, a fennmaradó 10% pedig tartalék.

A csoportok közötti interakció UML szekvenciadiagramja így nézhet ki:

Minden szakaszban más -más csoport játszik kulcsfontosságú szerepet, de minden típusú szerepet be kell vonni a teljes fejlesztési folyamatba:

• Az elemzők az üzleti specifikáció befejezése után kezelik a változó üzleti helyzetet, hogy minimálisra csökkentsék a változás lehetőségét az idő múlásával. A programozókat és a tesztelőket is támogatják a teljes fejlesztési folyamat során annak biztosítása érdekében, hogy a végtermék megfeleljen az elején meghatározott üzleti igényeknek. A folyamat ideális esetben az üzleti elemzőket tekinti a kulcsszereplőknek a megoldás végső szállításakor az ügyfélnek, mivel ők vannak a legjobb helyzetben a legjobb üzleti réteg biztosításához.
• A programozók a tervezési fázisban elvégzik a műszaki előírásokat, ezért hívják őket programozóknak/tervezőknek, és a tesztelés során javítják a hibákat.
• A tesztelők a tervezési fázisban befejezik a teszt forgatókönyveket, és a kódolási fázisban értékelik azokat

Rendszerek és eljárások

A szoftvercégek különböző rendszerekkel és eljárásokkal rendelkeznek, amelyek minden alcsoporton belül belsőleg működnek. Ezek tartalmazzák:

Üzleti elemzők

• Modellező eszközök, például a Sparx Systems Enterprise Architect vagy az IBM Rational Rose

Programozók

• Version Control Systems és szoftver verziókezelési eljárások
• Kód elemző eszközök és kódolási szabványok , validált manuálisan vagy automatikusan
• Telepítési mechanizmusok

Tesztelők

• Hibakövető rendszerek
• Tesztelje az automatizálási eszközöket
• Teljesítmény- és stresszteszt eszközök

Projekt-/termékmenedzserek

• Vállalati projektmenedzsment (EPM) rendszerek és eljárások
• Termékportfólió -kezelés (PPM)
• Változáskezelési rendszerek és eljárások

Létezik az Alkalmazás -életciklus -kezelés (ALM) is, amely ezeknek a funkcióknak egy részét egy csomagba ágyazza, és a csoportokban használják. Különböző gyártóktól szállítják őket, mint például a Borland , az ECM vagy a Compuware .

Hatékonysági auditok

A jól bevált szoftvercégek általában valamilyen módon mérik saját hatékonyságukat. Ez általában a legfontosabb teljesítménymutatók (KPI) meghatározásával történik, mint pl

• A fejlesztő által az időegységenként vagy forráskódjaiban elkövetett hibák átlagos száma
• A tesztelő által talált hibák száma tesztciklusonként
• A tesztciklusok átlagos száma Zero Bug Bounce -ig (ZBB)
• A tesztciklus átlagos ideje
• A feladat becsült ideje a feladat valós idejéhez képest (tervezés pontossága)
• Az alapvonal korrekcióinak száma

Számos szervezet a képesség lejárati modell (CMM) optimális szintjének elérésére összpontosít , ahol az "optimális" nem feltétlenül jelenti a legmagasabbat. Vannak még más rendszerek, mint a Carnegie-Mellon University „s SEMA vagy bizonyos ISO szabványoknak. A kis szoftvercégek néha kevésbé formális megközelítéseket alkalmaznak. Minden szervezet kidolgozza a saját stílusát, amely valahol a teljes technokrácia (ahol mindent számok határozzák meg) és a teljes anarchia (ahol nincsenek számok) között helyezkedik el. Bármilyen irányba is megy a szervezet, fontolóra veszik a piramist, amely leírja a költségeket és kockázatokat, amelyek a változások bevezetésének a már megkezdett fejlesztési folyamatokban történnek:

Lásd még

• A legnagyobb szoftvercégek listája

Hivatkozások