eșecul acestei acțiuni inițiale ar putea face dificilă separarea corectă a costurilor între cele care ar trebui capitalizate și cele care ar trebui cheltuite. Acest lucru ar putea duce la erori în aplicarea GAAP, precum și la erori în valoarea raportului entităților de venit sau pierdere netă., Acest articol este conceput pentru a ajuta cititorii să răspundă la această întrebare: ce costuri software ar trebui valorificate și ce costuri ar trebui să fie cheltuite atunci când o entitate construiește software de uz extern folosind un mediu de dezvoltare agil?
tendința spre dezvoltarea agilă
metoda de dezvoltare software cunoscută sub numele de agile a devenit populară în industria software în ultimii ani., Deoarece abordarea agilă (a se vedea graficul „abordare agilă”) este percepută pe scară largă ca fiind mai rapidă și mai receptivă la cerințele în schimbare rapidă, multe companii o folosesc acum ca o alternativă preferată la abordarea tradițională de dezvoltare a cascadelor.abordarea convențională de dezvoltare a cascadelor implică organizarea unui proiect într-o serie de faze tradiționale, cum ar fi concepția, inițierea, analiza, proiectarea, construcția, testarea, producția și implementarea și întreținerea., Aceste faze sunt marcate de activități, pe care ghidul le folosește ca cadru pentru a face o concluzie cu privire la momentul în care se realizează fezabilitatea tehnologică și costurile proiectului de dezvoltare software pot fi valorificate.sub un model agil, pe de altă parte, un proiect este organizat în module separate, iar lucrările de dezvoltare și testare pe aceste module se fac în sprinturi scurte., Identificarea momentului în care au loc activitățile tradiționale ale abordării cascadei necesită o analiză și o judecată semnificativă în dezvoltarea agilă, ceea ce poate face mai dificilă aplicarea orientărilor GAAP pentru valorificarea cheltuielilor.
în cele din Urmă, atât de agil și cascada modele pot produce un proiect de succes; cu toate acestea, determinarea punctelor în procesul de dezvoltare software pentru a începe și a termina valorificarea costurile pot fi mai provocatoare cu agile model.,
2 seturi de reguli de capitalizare software
ca punct de plecare pentru a valorifica în mod corespunzător costurile de dezvoltare software, este important să se determine îndrumarea adecvată. În conformitate cu GAAP din SUA, se pot aplica două seturi potențiale de reguli majore atunci când se stabilește dacă costurile de dezvoltare software ar trebui capitalizate sau cheltuite.un set de reguli (FASB Accounting Standards Codification (ASC) Topic 985, Software) este conceput pentru costurile software pe care entitatea intenționează să le vândă sau să le închirieze., Aceste reguli, denumite în mod obișnuit regulile de capitalizare a software-ului pentru software-ul de uz extern, sunt accentul principal al acestui articol. Celălalt set de reguli (ASC Topic 350, intangibile — Goodwill și altele) reglementează software-ul pe care entitatea nu intenționează să-l vândă sau să-l închirieze. Aceste reguli sunt denumite în mod obișnuit regulile de capitalizare a software-ului pentru software-ul de uz intern.este important să rețineți că pragul de capitalizare este mai mic pentru software-ul de uz intern., În conformitate cu regulile software-ului de uz intern, costurile de dezvoltare pot fi, în general, valorificate după încheierea etapei preliminare a proiectului. Pragul pentru costurile de dezvoltare software pentru vânzarea sau licențierea externă — punctul central al acestui articol-este mai strict, ceea ce înseamnă că este necesară o analiză mai mare pentru a determina ce costuri de dezvoltare ar trebui valorificate.
în cazul în care GAAP și agile nu se aliniază
Sub Tema 985, problema critică în determinarea dacă costurile de dezvoltare a software-ului de uz extern ar trebui să fie capitalizate se învârte în jurul termenului „fezabilitate tehnologică.,”Orice costuri de dezvoltare software care sunt suportate înainte de punctul în care proiectul a demonstrat fezabilitatea tehnologică ar trebui să fie cheltuite pe măsură ce sunt suportate.odată ce fezabilitatea tehnologică a fost stabilită, majoritatea (dar nu toate) costurile de dezvoltare pot fi valorificate. În cele din urmă, odată ce dezvoltarea este completă și software-ul este pus la dispoziția clienților pentru lansare, capitalizarea nu mai este adecvată, deoarece orice costuri rămase sunt considerate întreținere și asistență continuă. Aceste costuri trebuie întotdeauna să fie cheltuite pe măsură ce sunt suportate.,definiția „fezabilității tehnologice” este, prin urmare, factorul critic în determinarea momentului în care o companie ar trebui să înceapă să-și valorifice costurile de dezvoltare. Topic 985 spune: „fezabilitatea tehnologică a unui produs software de calculator este stabilită atunci când entitatea a finalizat toate activitățile de planificare, proiectare, codificare și testare care sunt necesare pentru a stabili că produsul poate fi produs pentru a îndeplini specificațiile sale de proiectare, inclusiv funcții, caracteristici și cerințe tehnice de performanță.,”De asemenea, este important să rețineți că costurile de dezvoltare a software-ului sunt supuse acestor reguli, indiferent dacă costurile au fost generate intern (cum ar fi timpul angajaților) sau extern (cum ar fi taxele de furnizor).în proiectele convenționale de dezvoltare de software cu faze consecutive bine definite, fezabilitatea tehnologică este demonstrată, în general, fie printr-un design detaliat al programului, fie, atunci când lipsește un design detaliat al programului, un model de lucru pregătit pentru testarea clienților. Acestea sunt repere familiare pentru proiectele care utilizează abordarea cascadei.,cu toate acestea, într-un mediu de proiect agil, funcțiile și caracteristicile individuale sunt dezvoltate separat într-o serie de sprinturi. Fiecare sprint sau modul este conceput, planificat, finanțat, dezvoltat și testat individual pentru a fi încorporat în proiectul general atunci când este gata.într-un astfel de mediu, proiectele cuprinzătoare de programe sau modelele de lucru sunt adesea impracticabile sau irelevante., Companiile care folosesc o abordare agilă pentru a dezvolta software-ul ar putea concluziona în mod necorespunzător că fezabilitatea tehnologică nu a fost îndeplinită în mod semnificativ înainte ca îmbunătățirea software-ului să fie disponibilă clienților, ceea ce duce la cheltuieli ca suportate, mai degrabă decât să fie capitalizate. Dacă se acumulează costuri semnificative între momentul în care a fost atinsă fezabilitatea tehnologică și momentul în care software-ul este disponibil clienților, contabilitatea rezultată ar putea fi incompatibilă cu GAAP.,deși orientările actuale GAAP pentru software-ul de uz extern nu sunt adaptate mediului agil, aceasta nu înseamnă că costurile de dezvoltare agile nu pot fi capitalizate deloc. Există, la urma urmei, diferite niveluri de agilitate. În timp ce un proiect agil pur ar putea începe doar cu o idee și o muncă de proiectare relativ mică, unele proiecte agile au proiecte detaliate de programe cu storyboarding aprofundat, studii de acceptare a pieței și alte documente de lucru de proiectare puse împreună înainte de începerea dezvoltării reale., Astfel de documente ar putea fi folosite pentru a evalua fezabilitatea tehnologică.punctul critic de reținut este că, pentru a evalua costurile care ar trebui valorificate, trebuie să existe o planificare suficientă a proiectului pentru a demonstra că au fost îndeplinite criteriile pentru un „design detaliat al programului”. Riscul este ca echipele de proiect să nu facă suficientă planificare front-end sau să păstreze documentația adecvată pentru a demonstra că au atins acest prag., Demonstrarea fezabilității tehnologice este probabil să necesite echipei de proiect să facă mai multă planificare și să compileze mai multă documentație decât este tipic în majoritatea proiectelor agile.alte considerente importante la determinarea fezabilității tehnologice se referă la caracteristicile de dezvoltare cu risc ridicat. De exemplu, proiectul este o platformă software complet nouă sau este o îmbunătățire sau re-creare a ceva care a fost făcut înainte? Compania dezvoltă software de la zero sau combină diverse componente software care există deja?, Caracteristicile de dezvoltare cu risc ridicat pot necesita o analiză suplimentară a momentului în care se atinge fezabilitatea tehnologică și, în unele cazuri, cheltuieli ale costurilor capitalizate anterior.îmbunătățirile produselor care nu sunt considerate activități de întreținere pot atinge uneori mai ușor pragul de fezabilitate tehnologică, deoarece dezvoltatorii adaugă funcții unui produs deja de succes. Factorii decizionali în astfel de cazuri includ tipul de software, nivelul de modificare necesar și nivelul lucrărilor de proiectare finalizate înainte de începerea dezvoltării.,chiar și atunci când se stabilește fezabilitatea tehnologică, nu toate costurile de dezvoltare agile pot fi valorificate. În cele mai multe cazuri, doar o parte din costurile din fiecare sprint pot fi valorificate. Costurile care nu trebuie valorificate includ analiza inițială, achiziția de cunoștințe, planificarea inițială a proiectului, prototiparea și lucrările de proiectare comparabile care trebuie făcute pentru a înțelege caracteristicile și fezabilitatea dorite ale produsului.dar porțiuni mari din costurile suportate pentru dezvoltarea și testarea unor astfel de caracteristici ar trebui adesea valorificate dacă se obține fezabilitatea tehnologică., Aceste costuri includ codificarea reală, testarea și costurile forței de muncă asociate.
rețineți, totuși, că orice costuri legate de întreținere sau de Corectarea erorilor care sunt suportate în timpul sprintului ar putea fi mai degrabă cheltuite decât capitalizate, deoarece multe activități în timpul sprintului nu pot fi codificate și testate, ci pot fi activități precum depanarea și descoperirea. Mai mult, capitalizarea se încheie odată ce proiectul este finalizat și software-ul este gata de utilizare.,distincția între costurile care pot fi capitalizate și cele care nu pot fi capitalizate poate complica oarecum etapele de contabilitate, raportare și Documentare a proiectului în cadrul fiecărui sprint. Dar munca administrativă suplimentară nu trebuie să fie oneroasă. În cele mai multe cazuri, diferitele sarcini și rezultate din fiecare sprint pot fi segmentate în categorii largi, astfel încât toate costurile asociate cu acea sarcină pot fi fie cheltuite, fie capitalizate.,
pregătirea și comunicarea: pașii critici
a decide care costuri de dezvoltare software de uz extern pot fi valorificate într-un mediu de proiect agil implică o anumită judecată. În multe cazuri, faptele și circumstanțele specifice legate de tipul de software dezvoltat vor conduce la tratarea costurilor. Planificarea atentă poate ajuta la analiza costurilor de valorificare față de cheltuieli.,din acest motiv ,de obicei este recomandabil să discutați tratamentul contabil cu echipa de management de proiect și experții în materie înainte de a începe orice proiect de dezvoltare mare. De asemenea, este important să înțelegem încă de la începutul unui proiect nivelul de suport și documentație care va fi necesar pentru a permite deciziile adecvate privind capitalizarea costurilor. În plus, este necesară o înțelegere clară a nivelului de documentare care va trebui menținut pentru ca auditorii să evalueze și să afirme capitalizarea și deciziile de cheltuieli.,de exemplu, Echipa de proiect ar trebui să documenteze în detaliu rolul fiecărei persoane în proiect, astfel încât contabilitatea să poată distinge între acele persoane ale căror timp și activități ar putea fi supuse capitalizării și cele ale căror activități nu ar intra niciodată în această categorie. De asemenea, este important să se mențină controale interne suplimentare, cum ar fi revizuirile lunare ale activităților, sumele capitalizate și cheltuite și șabloanele de comunicare pe care managerii de proiect le pot completa pentru a verifica dacă timpul angajaților este codificat corect.,deși au avut loc unele discuții din industrie privind actualizarea standardelor relevante pentru a le face mai aplicabile cadrului agile, astfel de actualizări implică de obicei mai mulți ani de planificare, discuții, propuneri și feedback din industrie. Aceasta înseamnă că, în viitorul previzibil, companiile care utilizează un model agil pentru a dezvolta software pentru vânzare sau licențiere externă vor trebui să continue să se coordoneze îndeaproape cu echipele lor de contabilitate pentru a aplica orientările GAAP existente și pentru a valorifica costurile de dezvoltare în mod corespunzător.
Lasă un răspuns