タグ

関連タグで絞り込む (43)

タグの絞り込みを解除

見積に関するmonochrome-tvのブックマーク (6)

  • https://app.shufti.jp/

  • スマホ案件の見積もりについて - ku-sukeのブログ

    Android案件の見積り ｜ クラスメソッド開発ブログ　を読んで、業界人らしき人のブコメが、「この程度でホッテントリか」という感じで、僕もややそっちよりの意見だったので、ざっくり補足できそうな点について書いて見ました。もう転職して受託の立場ではなくなったので。やや発注側の視点も含まれています。 責任のないリスクについてコスト負担範囲を決める すべてにおいて最重要項目です。変化の激しいスマホ業界においては、互いのリスクテイクについての認識をあわせておく必要があります。例としてはこんなものがあります。 開発期間中に突如OSのメジャーバージョンアップがあった。 顧客「あ、新しいのでましたね。対応できますよね＾＾」 世論に応じて機能の根幹部分が突然リジェクト対象になる。 りんご「今日から電話番号認証禁止ね＾＾直さないと削除しちゃうよ＾＾」 過去を顧みない方針転換がなされる ぐぐる「メニューボタン

    スマホ案件の見積もりについて - ku-sukeのブログ

  • Android案件の見積り | DevelopersIO

    Android案件を何件か担当して見積り前に確認しておいた方がいいと思うことや決めておくこと、 事前に説明しておくべきことがいくつかあったのでまとめます。 ①ハードウェアの選定 ・どの端末をサポートしますか？ 動作確認を行う端末を決めてもらいます。 複数の端末をサポートする場合、テストも複数の端末で行うため工数もそれに応じて増やす必要があります。 ・サポートするAndroidのバージョンは？ 端末を決めた時点でほぼ決まってしまいますが"Android 2.2以上"のようにサポートする最小のバージョンを決めます。 特にお客様にご要望がない場合はアプリのリリース時期と端末、OSのシェアなどを考慮して提案しています。 ・タブレットでの使用は想定していますか？ これはスマートフォン用に開発している案件で後からタブレットでも使用したい、 というご要望を受けることがあるためです。 ・マルチデバイス対応

  • (株)オー・エム・エス　三森支太郎

    見積/納品/請求の各明細書,合計請求書,領収証,その他帳票を作成するソフトです。 ・明細書の書式は固定で1枚に最大15or20件 (複数枚に及ぶ物は作成不可) ・合計請求書はｵﾘｼﾞﾅﾙ,HISAGO GB1123,GB1147,GB1164の用紙に対応 ・見積依頼書/物品受領書/注文書/発注書/領収証の印刷も可能 ・品名や単位をリストに登録し、登録リストから選択入力 (設定しておけば品名を選択入力すると単位と単価も自動入力) ・複数の見積データを集計して合計請求データを作成可能 ・自社情報は２カ所登録でき、印刷時に切り替えて印刷 ・社名ロゴ/会社印/担当者印の画像ファイルを所定位置にカラー印刷可能 ・源泉税に対応（計算機能と帳票印刷）

  • システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

    先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出

    システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

  • 工数見積もりで陥りやすい罠 - プログラマの思索

    「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い

    工数見積もりで陥りやすい罠 - プログラマの思索
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.