大規模軟體開發問題,大規模軟體開發常見問題

發布 科技 2024-02-08
12個回答
  1. 匿名使用者2024-02-05

    設計方案的失敗將導致整個系統的故障,最終導致一切的損失。

    因此:1首先要設定開發目標,準確分析功能模組之間的邏輯關係,不能有邏輯錯誤。

    2.系統開發中非常重要的一步是要有乙個好的計畫,要畫出開發過程,把過程之間的聯絡、前期的準備和規劃都要設計好,設計要詳細。

    3.在大軟體中,一般編碼中的問題不是太嚴重,但是要選擇優化方法設計的主要部分,公共部分要寫成類或常用函式,這樣才能提高程式的可讀性和執行速度。

    4.做大型軟體,必須兼顧它的可維護性和可擴充套件性,這一點非常重要,後期維護在軟體開發中占有非常重要的地位,這是不容忽視的。

    5.還有安全方面,注意程式末尾關閉除錯的後門。

  2. 匿名使用者2024-02-04

    從軟體工程的角度來看,首先是你採用的設計開發模式,它決定了未來的開發流程、開發團隊、團隊成員角色等等,它很大程度上決定了軟體開發的時間和金錢成本以及相關資源的成本。 還有開發過程的文件問題,它決定了軟體的可維護性和可讀性。

    最重要的是,在大規模軟體開發的過程中,使用者需求必須非常準確,否則後續的所有工作都會費力一半,甚至導致整個軟體的失敗,因為很大程度上,從需求分析到開發測試再到最終軟體發布的過程是不可逆的, 所以一旦出現錯誤,後果就非常嚴重。最實際的問題是與客戶溝通不好,客戶不知道自己想要什麼,製作的軟體不是客戶需要的,或者客戶的需求在不斷變化等等,都會造成軟體的失敗,也就是說,大量的投資被浪費了, 資本丟失了。

    這似乎是乙個複雜的問題,所以我建議你找一本關於軟體工程的書,自己讀一讀。

  3. 匿名使用者2024-02-03

    1.簡化演算法。

    一般來說,當計算機解決乙個特定的問題時,首先需要尋求乙個合適的數學模型。 程式數量的增加並不意味著演算法的時間複雜度一定優越。 因此,在大型軟體的過程中,乙個獨立工作的程式程序往往被分解成幾個子程序,這個子程序可以與其他子程序協調。

    2.適應結構。

    乙個優秀的程式應該滿足演算法設計的要求,所以程式應該選擇自適應的資料結構和一些外部介面。

    EJ:在檢索資料的過程中,資料的初始狀態與排序演算法的漸進時間直接相關。 程式中的呼叫、轉賬和分支也與程式的執行過程有關,等等。

    3.效率高,儲存要求低。

    4.可維護性和可擴充套件性。

    5.安全設計。

  4. 匿名使用者2024-02-02

    問題相當多,在開發過程中會出現一些意想不到的問題,挺煩人的。 這取決於您擁有哪個行業的軟體。 第一步是真正了解軟體的一般流程和資料庫設計。 在開發之初。

  5. 匿名使用者2024-02-01

    看一看"軟體工程"酒吧

    什麼模組劃分,什麼自上而下,什麼物件導向,什麼演算法設計,有很多事情要遇到。

    總之,大型軟體的開發是乙個工程問題,涉及許多技術和工程問題。

  6. 匿名使用者2024-01-31

    如果這個問題可以是你的,那是乙個老程式設計師,這是乙個經驗問題,孩子。

  7. 匿名使用者2024-01-30

    1、缺乏面向公眾實現的技術方案細節和橫向平整機制。

    現在 deck 中有 3 個開發團隊,每個組都會涉及分布式事務、冪等等技術細節,以及每個組的通用業務邏輯,或者相互呼叫的介面。

    因此,缺乏跨組、統一組內技術規範(例如,分布式事務可以選擇服務編排和註解)和識別通用方法的橫向機制。 避免同一技術細節的多個版本的問題。

    2.質量跟蹤,走訪檢查缺失或不夠強。

    管道要求單元測試覆蓋率為 70%,單元測試通常是備份的,提交可以提交給 CI,而不會報告紅色。 單元測試的質量,以及缺乏演練或缺失或問題,都無法暴露。

    單元測試編碼規範和**規範缺乏標準,演練沒有標準,演練的重視度不夠,執行演練的人員不明確,各組的演練不同,所以問題可能暴露不出來。

    3. 在制定和實施層面缺乏對變化的風險識別、估計和反饋。

    在這個階段,經過幾輪迭代,卡組已經完成了管理交易的開發,形成了一定量的**。 在迭代過程中,出現“資料庫表結構發生重大變化”等情況,開發團隊無法識別或反饋“應用改造”導致的程式碼匹配工作負載,進而默示接受輸入到迭代中,這會影響到其他組和自己的組,導致當前迭代延遲交付的風險。

    4、技術基礎優先(推薦)。

    迭代輸入,面對版本交付的壓力,專注於業務介面,可能會忽略技術課題的提前研究儲備,然後將當前的業務介面和涉及的技術課題同時實現,進而技術課題延遲業務介面的進度。 可以提前識別和研究“引數工程”、“序列號生成器”、“單元分片和分片”、“冪等抗重複”、“流程表”、“7*24”、“會計日”等技術主題,進行演示。 輸出文件是使用者手冊。

    5、應留出合理的緩衝時間用於開發。

    目前的開發模型是迭代 3 周。

    第 1 周:講故事、大綱設計、漫遊設計。

    第 2 周:開發和交付測試。

    第 3 周:整合測試。

    在實際的開發過程中,沒有足夠的時間用於開發。 每個組的交付時間都有限制,或者由於其他外部問題而沒有足夠的時間來開發緩衝區。

    5、基於發行商現有的編碼水平和開發團隊的結構,探索如何最大限度地發揮開發者對使用者故事的理解和理解,提高PB策劃會議的效率,是乙個應該考慮的問題。

  8. 匿名使用者2024-01-29

    1.大規模軟體開發之所以困難,唯一的原因是開發難

    1.首先,前期投入大量資金,技術、銷售、科研等人員的素質和忠誠度要絕對可靠,保證發展成功能迅速占領市場份額,如果其中乙個環節出現問題,前期就可能導致大量資金流失, 而且即使你有一段成功的發展期,也要燒錢,在廣告領域投入推廣產品,最終要看宣傳的思路和操作方法是否合適,否則就是浪費。

    2.技術方面也比一般軟體難度大,首先,大型軟體的結構非常複雜,包括資料庫建設、穩定性、持續壓力測試、安全性也很重要等。 在開發過程中,要保證團隊和手指的和諧,隨時撤員也是很麻煩的。

    二、制定難點解決方案:

    1.這些困難來自於大系統的複雜性,其次是許多具有主動性的個人之間的組織和協調,這本身也帶來了很多困難,此外,各個應用領域之間的差異也導致了這些困難的加劇,而上次時間和變化的因素也給軟體開發工作帶來了許多困難。

    2.軟體流程定義了軟體開發的框架,並將自動化工具的軟體開發方法與質量管理緊密結合。 軟體過程構成了軟體專案管理控制的基礎,創造了乙個環境,便於採用技術方法、生成工作產品、建立里程碑、保證質量以及正確管理正常變化。

  9. 匿名使用者2024-01-28

    大規模軟體開發的難點和原因:首先,前期投入大量資金,技術、銷售、科研等人員的素質和忠誠度要絕對可靠,保證開發成功後能迅速占領市場份額,如果其中乙個環節出現問題, 前期可能會導致大量的資金投入,甚至在你成功開發了一段時間的燒錢之後,投資廣告領域來推廣你的產品,最終取決於你的宣傳思路和運營方式是否合適。否則,這是另一種浪費。

    首先,大型軟體的結構非常複雜,包括資料庫建設、穩定性、持續壓力測試、安全性也很重要等等。 在開發過程中,要保證團隊的和諧,隨時撤員也是很麻煩的。

  10. 匿名使用者2024-01-27

    1.軟體開發是乙個高風險、高投資的專案。

    2.開發時間長,成本高。

    3.無法證明其正確性。

    4.維護成本高。

    5.開發、維護難以衡量等等。

    6.極端觀點:任何軟體開發專案都無法按時完成。

  11. 匿名使用者2024-01-26

    原因一:企業管理基礎太薄弱。

    在沒有良好管理基礎的情況下實現軟體,就像在地基沒有建好的地方建摩天大樓一樣,總有倒塌的危險。 因此,實施辦公室管理制度的首要任務是為企業的管理奠定基礎。

    原因二:缺乏對規劃和培訓的關注。

    辦公室管理既是現代企業走向國際化的一種管理模式,也是一種基於現代資源管理的企業管理融合和新管理理論。 如果你沒有在人員培訓上投入足夠的資源,不改變你的業務流程,即使是最好的軟體也將是徒勞的。

    原因三:對辦公軟體的期望值太高。

    通過辦公軟體直接快速實現巨大收益,無疑是乙個不切實際的想法。 而有了這種實現辦公軟體的思維,最終失敗是不可避免的。

    原因四:只認可最好的,而忽略了可用性。

    如果企業忽視了辦公軟體解決方案提供商的實施、售後服務以及與自身企業的適用性,只看重其最佳因素,其結果將是難以想象的。

    理由五:認為辦公軟體一步到位,忽略了二次開發。

    仔細了解實施者是否具備專業的研發能力、豐富的實踐經驗、持續的服務以及較強的二次開發能力也很重要。 否則,最終受苦的將是企業本身。

    總之,辦公軟體總是作為管理工具來使用,是輔助決策的東西,不是靈丹妙藥。 但是,通過辦公軟體系統,可以及早做,監控更多,減少錯誤和不穩定的發生,但這並不意味著它不發生,你可以讓你的材料在使用辦公軟體後順利,但這並不意味著沒有問題。 有些事情需要定量考慮,但不是定量考慮,一刀切。

  12. 匿名使用者2024-01-25

    資金不到位,研發成果不豐。

相關回答