20177301005-範白金真実験一ソフトウェアエンジニアリング準備-ソフトウェアエンジニアリングの基本操作を学び、考える
3546 ワード
プロジェクト
内容
クラスのブログリンク
https://www.cnblogs.com/nwnu-daizh/
ジョブ要求リンク
https://www.cnblogs.com/nwnu-daizh/p/12369881.html
学習目標
(1)ブログ園のソフトウェア開発者がコミュニティの使用技術と経験を学ぶことを学ぶ.(2)Githubの基本操作を理解する.
この宿題から何を学びましたか.
Markdownのレイアウトをマスターします.ソフトウェアエンジニアリングという学科を知っています.
参考文献
鄒欣構築の方法——現代ソフトウェアエンジニアリング:現代ソフトウェアエンジニアリング[M].人民郵便出版社、2014
鄒欣先生の「構築の法--現代ソフトウェア工学」という本を読んで、この本の主な分析と研究のどのような問題について大まかな理解があった.第1章では、鄒欣先生が生き生きとした例で多くの概念を導入し、これらの概念も本書が研究と討論に重点を置く内容である.私自身がこれらの概念について考えた上で、私は自分の3つの問題をまとめました. 1.プログラマー一人一人の思想は異なり、同じ問題に対して、千人のプログラマーには千種類の解決方法がある.プログラマー一人一人にこの千の方法を理解させることはできません.では、プログラムの後期メンテナンスと改善は、実装をどのように管理すべきか. **思考の起因:**最初の問題も鄒欣先生の本の中で言及した問題である:
私は出勤してから、以前同僚が書いたプログラムが本当にゴミで、全然読めなくて、メンテナンスできません.書き直すぞ!その後、あるベテラン社員がにこにこして私に教えてくれました.私たちが今見ているプログラムは、去年の新入社員が怒って書き直した構造を覆し、以前のバージョンがまだ使えないことを反映しています.--『構築の法——現代ソフトウェアエンジニアリング』から引用
私にとって、プログラムを書くのは注釈を書くのが好きではありません.だからこそ、私自身のプログラムは、かなり簡単なアルゴリズムでも、しばらくしてから見ると、自分がアルゴリズムを書いたときの考えを理解できるとは限りません.内容の多いアルゴリズムであれば、読み返すより書き直すほうが時間がかかるかもしれません.他人のプログラムを見るのはもっと同じだ.时には自分で書くよりも読むのが難しいことがあります.これにより、ソフトウェアエンジニアリング上の問題が発生し、プログラムはユーザーが使用するにつれて、コンテンツを追加、削除、または変更する必要があります.最初にこのプログラムを書いたプログラマーがいつまでも自分の以前のプロジェクトを修正できることは保証できません.これがソフトウェアのメンテナンスの問題です.
1つのチームにとって、分業をどのように処理し、手配すれば、このような問題を回避し、プロジェクトの維持と改善による一連の問題を減らすことができます. 2.ユーザーはソフトウェアの機能に対する想像が需要に基づいていることが多い.しかし、需要分析の過程で、各種類の需要をどのように処理すれば、できるだけユーザー体験を高めることができるのか. 思考の起因:同じく「構築の法--現代ソフトウェアエンジニアリング」で引き起こされた問題:
ソフトウェアやサービスを買う人がいれば、お客様を見つけなければなりません.お客様にはいろいろなニーズがあり、頼りになる人もいれば、頼りにならない人もいます.簡単にできるものもあれば、難しいものもあります.--『構築の法——現代ソフトウェアエンジニアリング』から引用
ユーザーは1つのソフトウェアに対して、このような需要が合理的であるかどうかにかかわらず、組み合わせが適切であるかどうかにかかわらず、このように実現することを望んでいます.しかし、時にはこのような考え方で作られた道具は、使い心地の良い道具ではありません.このようなニーズに対して、私たちはどのように手配すれば、機能を完成し、ユーザーの使用感に合致することができます.また,ユーザのソフトウェアの使用は長時間継続しているが,使用習慣はしばらくの間変更することは困難である.場合によっては、1つの問題に対する改善であるのに、従来の使用感に反するため、ユーザがこのような改善の利点を発見できるとは限らない.むしろ改善すべきではないと思うかもしれません.このような場合、これらのニーズをどのように処理すれば、ユーザー体験をできるだけ向上させることができます.
ソフトウェアプロジェクトの設計は需要分析に基づいて、つまりすべての需要を分析しなければならない.この需要は合理的かどうか.適切ですか?これらの問題に基づいて解決策を講じてこそ、次の仕事を展開することができる.ユーザーがこのソフトウェアで本当に必要とするものを明確にしなければならない. 3.ソフトウェアエンジニアリングで最も重要な問題に対して、チームが協力して、どのようにチームを管理してソフトウェアをよりよく開発することができますか? 思考の起因:『構築の法--現代ソフトウェアエンジニアリング』では、チームと非チームを区別して問題を解決している.また、ソフトウェアチームをいくつかのモデルに細分化しました.例えば、直感的に形成された蜂のパターン、「一人の学生が仕事をし、他の学生が醤油を打つ」という主治医のパターン、個人的な役割が際立って他のメンバーがチームの端を泳いでいるスターのパターン、誰もが自分の興味のあるプロジェクトに参加するコミュニティのパターン、中央指揮(監督)に従うアマチュア劇団のパターン、秘密チーム、スパイチーム、交響楽のパターン、ジャズのパターン、機能チームモデルや官僚モデルなど10種類の特色の異なるチームモデル. 私の疑問:どのモデルにも自分の長所と欠点があるが、チームモデルが最初は適切に選択することが難しく、チームの男女の割合、仕事の能力、性格の違いなどの影響要素が、チームの発展モデルに影響を与えることが多い.ソフトウェアエンジニアリングという授業を学ぶ前に、グループとチームが共同でカリキュラム設計などの内容を完成する過程もあります.チーム全体の前進方向を制御することが難しい場合があります.どのようにして、メンバー一人一人の役割を最大化することができますか?どのようにして1つのプロジェクトをチームの能力を最善にすることができますか?すべて重要な問題です. 私の考え:『構築の法--現代ソフトウェアエンジニアリング』で述べた10種類のチームモデルの中で、私が一番好きなのは機能チームモデルです.誰もが機能に基づいて自分の理解を話し、みんなで一つの問題を解決するために相談しています.問題が簡単でも困難でも、みんなで討論して、この問題を解決してから次の問題を解決し続けます.ソフトウェア機能を究極の目標とする.管理と管理の関係がないというパターンは、必ずみんなで力を合わせて、目標のために一緒に努力しなければなりません.
今回の実験を通じて、ブログ園とgithubの使用について理解し、熟知しました.これはソフトウェアエンジニアリングを学ぶ授業の基礎です.鄒欣先生の「構築の法--現代ソフトウェアエンジニアリング」という本を読んで、ソフトウェアエンジニアリングがどのような学科なのかを全体的に理解した.以前のソフトウェア学習の過程で出会った問題に対して、私はこの授業で勉強した後に解決することを望んでいます.理解の中でもっと深くソフトウェアエンジニアリングという授業の意義を把握します.
内容
クラスのブログリンク
https://www.cnblogs.com/nwnu-daizh/
ジョブ要求リンク
https://www.cnblogs.com/nwnu-daizh/p/12369881.html
学習目標
(1)ブログ園のソフトウェア開発者がコミュニティの使用技術と経験を学ぶことを学ぶ.(2)Githubの基本操作を理解する.
この宿題から何を学びましたか.
Markdownのレイアウトをマスターします.ソフトウェアエンジニアリングという学科を知っています.
参考文献
鄒欣構築の方法——現代ソフトウェアエンジニアリング:現代ソフトウェアエンジニアリング[M].人民郵便出版社、2014
『構築の法——現代ソフトウェアエンジニアリング』を読む
鄒欣先生の「構築の法--現代ソフトウェア工学」という本を読んで、この本の主な分析と研究のどのような問題について大まかな理解があった.第1章では、鄒欣先生が生き生きとした例で多くの概念を導入し、これらの概念も本書が研究と討論に重点を置く内容である.私自身がこれらの概念について考えた上で、私は自分の3つの問題をまとめました.
私は出勤してから、以前同僚が書いたプログラムが本当にゴミで、全然読めなくて、メンテナンスできません.書き直すぞ!その後、あるベテラン社員がにこにこして私に教えてくれました.私たちが今見ているプログラムは、去年の新入社員が怒って書き直した構造を覆し、以前のバージョンがまだ使えないことを反映しています.--『構築の法——現代ソフトウェアエンジニアリング』から引用
- ** ：**
私にとって、プログラムを書くのは注釈を書くのが好きではありません.だからこそ、私自身のプログラムは、かなり簡単なアルゴリズムでも、しばらくしてから見ると、自分がアルゴリズムを書いたときの考えを理解できるとは限りません.内容の多いアルゴリズムであれば、読み返すより書き直すほうが時間がかかるかもしれません.他人のプログラムを見るのはもっと同じだ.时には自分で書くよりも読むのが難しいことがあります.これにより、ソフトウェアエンジニアリング上の問題が発生し、プログラムはユーザーが使用するにつれて、コンテンツを追加、削除、または変更する必要があります.最初にこのプログラムを書いたプログラマーがいつまでも自分の以前のプロジェクトを修正できることは保証できません.これがソフトウェアのメンテナンスの問題です.
- ** ：**
1つのチームにとって、分業をどのように処理し、手配すれば、このような問題を回避し、プロジェクトの維持と改善による一連の問題を減らすことができます.
ソフトウェアやサービスを買う人がいれば、お客様を見つけなければなりません.お客様にはいろいろなニーズがあり、頼りになる人もいれば、頼りにならない人もいます.簡単にできるものもあれば、難しいものもあります.--『構築の法——現代ソフトウェアエンジニアリング』から引用
- ** ：**
ユーザーは1つのソフトウェアに対して、このような需要が合理的であるかどうかにかかわらず、組み合わせが適切であるかどうかにかかわらず、このように実現することを望んでいます.しかし、時にはこのような考え方で作られた道具は、使い心地の良い道具ではありません.このようなニーズに対して、私たちはどのように手配すれば、機能を完成し、ユーザーの使用感に合致することができます.また,ユーザのソフトウェアの使用は長時間継続しているが,使用習慣はしばらくの間変更することは困難である.場合によっては、1つの問題に対する改善であるのに、従来の使用感に反するため、ユーザがこのような改善の利点を発見できるとは限らない.むしろ改善すべきではないと思うかもしれません.このような場合、これらのニーズをどのように処理すれば、ユーザー体験をできるだけ向上させることができます.
- ** ：**
ソフトウェアプロジェクトの設計は需要分析に基づいて、つまりすべての需要を分析しなければならない.この需要は合理的かどうか.適切ですか?これらの問題に基づいて解決策を講じてこそ、次の仕事を展開することができる.ユーザーがこのソフトウェアで本当に必要とするものを明確にしなければならない.
実験のまとめ
今回の実験を通じて、ブログ園とgithubの使用について理解し、熟知しました.これはソフトウェアエンジニアリングを学ぶ授業の基礎です.鄒欣先生の「構築の法--現代ソフトウェアエンジニアリング」という本を読んで、ソフトウェアエンジニアリングがどのような学科なのかを全体的に理解した.以前のソフトウェア学習の過程で出会った問題に対して、私はこの授業で勉強した後に解決することを望んでいます.理解の中でもっと深くソフトウェアエンジニアリングという授業の意義を把握します.