brak podjęcia tych początkowych działań może utrudnić prawidłowe rozdzielenie kosztów między te, które powinny być kapitalizowane i te, które powinny być wydatkowane. Może to prowadzić do błędów w stosowaniu ogólnie przyjętych zasad rachunkowości, a także błędów w wysokości sprawozdania jednostek osiągających przychody lub straty netto., Ten artykuł ma na celu pomóc czytelnikom w odpowiedzi na to pytanie: które koszty oprogramowania powinny być kapitalizowane, a które powinny być wydatkowane, gdy jednostka tworzy oprogramowanie do użytku zewnętrznego przy użyciu zwinnego środowiska programistycznego?
tendencja do zwinnego rozwoju
metoda tworzenia oprogramowania znana jako agile stała się popularna w branży oprogramowania w ostatnich latach., Ponieważ podejście zwinne (patrz wykres „podejście zwinne”) jest powszechnie postrzegane jako szybsze i bardziej reagujące na szybko zmieniające się wymagania, wiele firm stosuje je obecnie jako preferowaną alternatywę dla tradycyjnego podejścia do rozwoju wodospadu.
konwencjonalne podejście do rozwoju wodospadu obejmuje organizowanie projektu w szereg tradycyjnych faz, takich jak koncepcja, inicjacja, analiza, projektowanie, budowa, testowanie, produkcja i wdrożenie oraz utrzymanie., Fazy te są naznaczone działaniami, które wytyczne wykorzystują jako ramy do wyciągania wniosków na temat tego, kiedy osiągnięta jest wykonalność Technologiczna i można wykorzystać koszty projektu rozwoju oprogramowania.
w modelu zwinnym, z drugiej strony, projekt jest zorganizowany w osobne moduły, a prace rozwojowe i testowe na tych modułach są wykonywane w krótkich sprintach., Określenie, kiedy występują tradycyjne działania podejścia wodospadu, wymaga znaczącej analizy i oceny w zwinnym rozwoju, co może utrudnić stosowanie wytycznych GAAP do kapitalizacji wydatków.
ostatecznie, zarówno modele zwinne, jak i waterfall mogą stworzyć udany projekt; jednak określenie punktu w procesie tworzenia oprogramowania, aby rozpocząć i zakończyć koszty kapitalizacji, może być trudniejsze z modelem zwinnym.,
2 zestawy zasad kapitalizacji oprogramowania
jako punkt wyjścia do odpowiedniej kapitalizacji kosztów rozwoju oprogramowania, ważne jest określenie odpowiednich wytycznych. Zgodnie z amerykańskimi zasadami GAAP, przy określaniu, czy koszty rozwoju oprogramowania powinny być kapitalizowane, czy wydatkowane, mogą mieć zastosowanie dwa potencjalne zestawy głównych zasad.
jeden zbiór zasad (FASB Accounting Standards Codisation (ASC) temat 985, oprogramowanie) przeznaczony jest dla kosztów oprogramowania, które jednostka zamierza sprzedać lub wydzierżawić., Zasady te, powszechnie określane jako reguły kapitalizacji oprogramowania dla oprogramowania do użytku zewnętrznego, są głównym tematem tego artykułu. Drugi zbiór zasad (temat ASC 350, Wartości niematerialne i prawne — wartość firmy i inne) reguluje oprogramowanie, którego jednostka nie zamierza sprzedać ani wydzierżawić. Reguły te są powszechnie określane jako reguły kapitalizacji oprogramowania dla oprogramowania wewnętrznego.
należy pamiętać, że próg kapitalizacji jest niższy dla oprogramowania wewnętrznego., Zgodnie z wewnętrznymi zasadami oprogramowania koszty rozwoju mogą być kapitalizowane po zakończeniu wstępnego etapu projektu. Próg kosztów rozwoju oprogramowania dla zewnętrznej sprzedaży lub licencjonowania — w centrum uwagi tego artykułu-jest bardziej rygorystyczny, co oznacza, że wymagana jest większa analiza w celu określenia, które koszty rozwoju powinny zostać skapitalizowane.
gdzie GAAP i agile nie zgadzają się
w temacie 985, krytyczny problem przy określaniu, czy koszty rozwoju oprogramowania do użytku zewnętrznego powinny być kapitalizowane, dotyczy terminu „wykonalność technologiczna.,”Wszelkie koszty rozwoju oprogramowania, które zostały poniesione przed punktem, w którym projekt wykazał wykonalność technologiczną, powinny być wydatkowane w miarę ich ponoszenia.
Po ustaleniu wykonalności technologicznej większość (ale nie wszystkie) kosztów rozwoju może zostać skapitalizowana. Wreszcie, po zakończeniu rozwoju i udostępnieniu oprogramowania klientom, kapitalizacja nie jest już odpowiednia, ponieważ wszelkie pozostałe koszty są uważane za bieżącą konserwację i wsparcie. Koszty te zawsze muszą być wydatkowane w miarę ich ponoszenia.,
definicja „wykonalności technologicznej” jest zatem kluczowym czynnikiem przy określaniu, kiedy firma powinna rozpocząć kapitalizację kosztów rozwoju. Temat 985 mówi: „wykonalność technologiczna oprogramowania komputerowego jest ustalana, gdy jednostka ukończyła wszystkie działania związane z planowaniem, projektowaniem, kodowaniem i testowaniem, które są niezbędne do ustalenia, że produkt może być produkowany w celu spełnienia jego specyfikacji projektowych, w tym funkcji, cech i wymagań technicznych.,”Ważne jest również, aby pamiętać, że koszty rozwoju oprogramowania podlegają tym zasadom niezależnie od tego, czy koszty zostały wygenerowane wewnętrznie (np. czas pracownika) czy zewnętrznie (np. opłaty sprzedawcy).
w konwencjonalnych projektach programistycznych z dobrze zdefiniowanymi, kolejnymi fazami, wykonalność technologiczna jest zazwyczaj wykazywana poprzez szczegółowy projekt programu lub, gdy szczegółowy projekt programu jest nieobecny, model roboczy, który jest gotowy do testowania przez Klienta. Są to znane kamienie milowe dla projektów wykorzystujących podejście do wodospadu.,
w zwinnym środowisku projektowym, jednak poszczególne funkcje i funkcje są rozwijane oddzielnie w serii sprintów. Każdy sprint lub moduł jest przewidywany, planowany, finansowany, opracowywany i testowany indywidualnie, aby być włączonym do ogólnego projektu, gdy będzie gotowy.
w takim środowisku kompleksowe projekty programów lub działające modele często są niepraktyczne lub nieistotne., Firmy stosujące zwinne podejście do tworzenia oprogramowania mogą wnioskować niewłaściwie, że wykonalność technologiczna nie została znacznie spełniona przed udostępnieniem ulepszenia oprogramowania klientom, co powoduje, że koszty są wydatkowane jako poniesione, a nie kapitalizowane. Jeżeli znaczne koszty będą rosły między momentem faktycznego osiągnięcia wykonalności technologicznej a momentem, w którym oprogramowanie jest dostępne dla klientów, wynikająca z tego Rachunkowość może być niezgodna z ogólnie przyjętymi zasadami rachunkowości.,
stosowanie GAAP w środowisku zwinnym
chociaż obecne wytyczne GAAP dla oprogramowania do użytku zewnętrznego nie są dostosowane do środowiska zwinnego, nie oznacza to, że koszty zwinnego rozwoju nie mogą być w ogóle kapitalizowane. Są przecież różne poziomy zwinności. Podczas gdy czysty zwinny projekt może zaczynać się tylko od pomysłu i stosunkowo niewielkiej pracy projektowej, niektóre zwinne projekty mają szczegółowe projekty programów z dogłębnym storyboardingiem, badaniami akceptacji rynku i innymi dokumentami prac projektowych zebranymi przed faktycznym rozpoczęciem rozwoju., Takie dokumenty mogłyby być wykorzystane do oceny wykonalności technologicznej.
krytycznym punktem, o którym należy pamiętać, jest to, że aby ocenić koszty, które powinny być kapitalizowane, konieczne jest wystarczające planowanie projektu, aby wykazać, że kryteria „szczegółowego projektu programu” zostały spełnione. Istnieje ryzyko, że zespoły projektowe mogą nie wykonać wystarczająco dużo planowania front-end Lub zachować odpowiednią dokumentację, aby wykazać, że osiągnęły ten próg., Wykazanie wykonalności technologicznej może wymagać od zespołu projektowego więcej planowania i kompilacji dokumentacji niż jest to typowe dla większości projektów zwinnych.
Inne ważne kwestie przy określaniu wykonalności technologicznej odnoszą się do cech rozwoju wysokiego ryzyka. Na przykład, czy projekt jest zupełnie nową platformą oprogramowania, czy może jest to ulepszenie lub odtworzenie czegoś, co zostało zrobione wcześniej? Czy firma tworzy oprogramowanie od podstaw, czy też składa ze sobą różne komponenty oprogramowania, które już istnieją?, Cechy rozwojowe wysokiego ryzyka mogą wymagać dodatkowej analizy, kiedy osiągnięta zostanie wykonalność technologiczna, a w niektórych przypadkach wydatkowanie wcześniej skapitalizowanych kosztów.
ulepszenia produktu, które nie są uważane za czynności konserwacyjne, czasami mogą łatwiej osiągnąć próg wykonalności technologicznej, ponieważ programiści dodają funkcje do już udanego produktu. Decydujące czynniki w takich przypadkach obejmują rodzaj oprogramowania, poziom wymaganej modyfikacji i poziom prac projektowych, które zostały zakończone przed rozpoczęciem rozwoju.,
nawet jeśli zostanie ustalona wykonalność technologiczna, nie wszystkie zwinne koszty rozwoju mogą zostać skapitalizowane. W większości przypadków tylko niektóre koszty w każdym sprincie można kapitalizować. Koszty, które nie powinny być kapitalizowane obejmują wstępną analizę, zdobywanie wiedzy, wstępne planowanie projektu, prototypowanie i porównywalne prace projektowe, które należy wykonać, aby osiągnąć zrozumienie pożądanych cech produktu i wykonalności.
ale duża część kosztów poniesionych na opracowanie i przetestowanie takich funkcji często powinna być kapitalizowana, jeśli zostanie osiągnięta wykonalność technologiczna., Koszty te obejmują rzeczywiste kodowanie, Testowanie i powiązane koszty pracy.
należy jednak pamiętać, że wszelkie koszty związane z konserwacją lub korekcją błędów, które są ponoszone podczas sprintu, mogą być wydatkowane, a nie pisane wielką literą, ponieważ wiele działań podczas sprintu może nie być kodowaniem i testowaniem, ale mogą być działaniami takimi jak rozwiązywanie problemów i wykrywanie. Co więcej, kapitalizacja kończy się po zakończeniu projektu, a oprogramowanie jest gotowe do użycia.,
rozróżnianie kosztów, które mogą być pisane wielkimi literami, a te, które nie mogą być pisane wielkimi literami, może nieco skomplikować etapy księgowania projektu, raportowania i dokumentacji w ramach każdego sprintu. Ale dodatkowa praca administracyjna nie musi być uciążliwa. W większości przypadków różne zadania i rezultaty w ramach każdego sprintu można podzielić na szerokie kategorie, dzięki czemu wszystkie koszty związane z tym zadaniem mogą być wydatkowane lub kapitalizowane.,
przygotowanie i komunikacja: kluczowe kroki
decydowanie, które koszty rozwoju oprogramowania do użytku zewnętrznego można wykorzystać w zwinnym środowisku projektowym, wymaga pewnej oceny. W wielu przypadkach konkretne fakty i okoliczności związane z rodzajem tworzonego oprogramowania będą prowadzić do traktowania kosztów. Staranne planowanie może pomóc w analizie, które koszty kapitalizować w porównaniu z wydatkami.,
z tego powodu zwykle zaleca się omówienie sposobu rozliczania z zespołem zarządzającym projektem i ekspertami tematycznymi przed rozpoczęciem jakiegokolwiek dużego projektu deweloperskiego. Ważne jest również, aby od samego początku projektu zrozumieć poziom wsparcia i Dokumentacji, które będą potrzebne do podjęcia odpowiednich decyzji dotyczących kapitalizacji kosztów. Ponadto wymagane jest jasne zrozumienie poziomu dokumentacji, który będzie musiał zostać utrzymany, aby audytorzy mogli ocenić i potwierdzić decyzje dotyczące kapitalizacji i wydatków.,
na przykład zespół projektowy powinien dokładnie udokumentować rolę każdej osoby w projekcie, aby księgowość mogła rozróżnić te osoby, których czas i działania mogą potencjalnie podlegać kapitalizacji, a te, których działania nigdy nie należą do tej kategorii. Ważne jest również utrzymanie dodatkowych kontroli wewnętrznych, takich jak comiesięczne przeglądy działań, kapitalizowane i wydatkowane kwoty oraz szablony komunikacji, które kierownicy projektów mogą wypełnić, aby sprawdzić, czy czas pracownika jest poprawnie zakodowany.,
mimo, że doszło do pewnych dyskusji branżowych na temat aktualizacji odpowiednich standardów w celu ich lepszego zastosowania do zwinnych RAM, takie aktualizacje Zwykle pociągają za sobą kilkuletnie planowanie, dyskusje, propozycje i opinie branżowe. Oznacza to, że w dającej się przewidzieć przyszłości firmy, które wykorzystują zwinny model do opracowywania oprogramowania do sprzedaży zewnętrznej lub licencjonowania, będą musiały nadal ściśle koordynować swoje zespoły księgowe, aby zastosować istniejące wytyczne GAAP i odpowiednio skapitalizować koszty rozwoju.
Dodaj komentarz