201671030119唐は、強力な実験的な14コースの概要をカバー

プロジェクト コンテンツ
この作品は、コースに属し 2016コンピュータサイエンスとエンジニアリングソフトウェアエンジニアリング(西北師範大学)
どこの仕事でこの要件 実験14プロジェクトレビューチーム&コース概要
ジョブの学習目標 1.マスター・ソフトウェア・プロジェクトは、プロセスを評価されます。
2.反射がコースの内容を要約したものです。

1学期のコースの内容は、質問に答えると明確にしようとする、あなたが言及したタスク5(与えられた質問ブログのリンク)「実験ソフトウェア工学を準備する」対比をはっきり方法を学ぶ/練習によって議論/明確にして、学習が新たな問題を作成するかどうか?その場合は、お問い合わせください。

- 问题1:在构建之法书本第17页中提出了这样两个问题,“软件工程为什么要发布一些不完美的软件?为什么不等到软件完美后再发布?”而后书中提到,软件工程就是要在时间、成本等多种约束条件下决定一个软件在什么时候“足够好”,可以发布。那么我有了疑问,当软件的质量和软件的预计时间与成本有了极大的冲突时,一个优秀的软件开发团队应该更倾向于哪一方?
  解答 :一个优秀的软件开发团队,不会出现预计时间、成本与软件质量之间的冲突,因为优秀的开发团队会在需求调研过程中将得到很完整的用户需求,之后按照用户需求和自己团队的能力进行时间、成本的估计也就是可行性分析,这样就不会发生问题中这种冲突。
- 问题2:在构建之法中第135页也就是第七章实战中的软件工程中有这样一个标题:保持敏捷,预期和适应变化。这里向我们表明,软件工程是时刻在变化的,所以在软件开发的过程中我们要时刻跟进用户的需求,这里就要用到“敏捷流程”。敏捷流程是应对快速变化的需求的一种开发方式,可以使开发团队应对经常变化的需求。在现如今技术快速的发展背景下,是不是代表形式化的开发方法(有极高的可靠性和质量)已经跟不上软件需求变化的脚步了?那我们是不是应该放弃以往的形式化开发方法?
  解答 :经过一学期的学习,我发觉敏捷流程是一种很强大的开发方法,但不代表着以往形式化的开发方法就应该被放弃,虽然如今技术发展的很快速,但是当软件需求出现变化不是很大,不需要团队进行时时刻刻的变化时候,这种形式化的开发方法可以极高的提升冉软件的质量,所以我们不应该放弃这种方法。
- 问题3:在构建之法书中第十二章提到了用户体验,这一章节强调了用户体验的重要性,软件服务是紧贴着用户的选择。书中提到了很多软件被长期使用之后,软件会越发难用。当一个软件在交付给用户以后,用户经过长期使用,对软件产生了厌倦,使得用户丢弃了软件,那么在这种情况下,是用户还是软件开发团队的错误使得软件被弃用呢?
  解答 :在这种情况下,用户可以跟开发团队进行交流,让开发团队在后期进行软件的优化和维护。问题中提到用户经过长时间使用后对软件产生厌倦,那么说明在软件交付时,软件是符合用户的要求的,而长期使用后,厌倦了软件,这种时候应该去和开发团队交流,而不是去抛弃软件,所以两者都有错误。

「質問の建設は法律を読んで」--Guthubリンク

2.プロジェクトの実現可能性の彼の分析を総括/分析/ソフトウェアの設計/実装/テスト/プロジェクトの承認を必要とする/何を学んだ「知識を。」

- 可行性分析
    1.数据流图(DFD)的使用;
    2.任务分解技术;
    3.NABCD方法的使用。
- 需求分析
与用户交流获取需求的方法:
    1.访谈;
    2.调查问卷;
    3.原型需求分析。
- 软件设计
    1.层次图和结构图的使用;
    2.软件结构设计中遵循发模块独立原理。
- 实现
    java web的学习。
- 测试
    1.白盒测试技术、黑盒测试技术;
    2.Alpha测试和Beta测试。
- 项目验收
    掌握了软件项目评审流程。

3.個々のプロジェクト/双晶個々のプログラム/プロジェクトチームの経験の組み合わせが経験について話をします。

    个人项目到结对编程再到团队项目,这个过程让我真正认识到了什么是团队。从刚开始的个人项目,一个人做着一个小项目,很小很小的那种,只是这样也有着很多错误,到后来的结对编程,发觉结对编程可以极快的加速编程速度,而且错误也变的很少了,这个项目后,已经感觉到了一个人力量的薄弱。再到后来,开始了团队项目,它让我找到了做真正项目的感觉,也明白了为什么好的软件都是由软件团队制作而成,因为一个人的力量是有限的,而众人的力量是无限的。

4.コースの実践の概要と、以下を含む、あなたをもたらすためにアップグレードします。

(1):あなたが完了しているどのように多くのコードの行統計ソフトウェアエンジニアリングの実践、

约2000行代码。 

(2):あなたはどのくらいの時間ごとの宿題ソフトウェアエンジニアリングの実践でしたか?(リストを作成します)

実験 (分)を使用する場合
準備する実験的ソフトウェア工学 60
ソフトウェア工学実験2つの個々のイベント 180
3回の操作でのピアレビューの改善 60
実験4つのソフトウェアエンジニアリングツイニング・プロジェクト 270
実験5ソフトウェアのR&Dのチームビルディング 60
実験6つのチームプロジェクトのトピック 50
実験7チームのプロトタイピングおよび開発プロジェクト 90
実験研究と分析は、8つのプロトタイプベースのチームプロジェクトを必要とします 150
実験9つのチームプロジェクトを改善し、システム設計を必要とします 180
システムを改善するための実験的な10件のプロジェクトチームと詳細設計 270
実験的な11のプロジェクトチームをうまく設計とコーディング 180
もしソフトウェアのテストやテストアルファスプリント 450
ベータテスト13チームスプリントとプロジェクトの受け入れ 450

(3):どちらの仕事はほとんどあなた作るには?なぜ?

    最让我印象深刻的一次作业就是团队作业7:团队项目设计完善&编码,这次是软件真正开始编写的时候,因为我们的编码能力有限,在这个过程中发生了很多问题,差点导致项目不能正常提交,我们团队,花费了很多时间去解决它。所以这是我印象最深刻的一次作业。

(4):ソフトウェア工学の実践に費やした時間の累積数?週あたりの時間の平均数は、使用済み?

    共累计54小时用在软件工程实践上,平均每周用时3小时。

(5):あなたは新しい言語、新しいプラットフォームを学び、習得。

    语言:Java web
    平台:GitHub、博客园

(6):下記のフォームに記入し、あなたが学ぶかを使用研究の学期、ソフトウェアエンジニアリング開発ツール、開発手法とモデリング手法をまとめました。

ソフトウェア開発ツール、プロジェクト管理ツール ソフトウェア開発手法 モデリングソフトウェア
Visioの、ブレード、mockplus、GitHubの プロトタイプメソッド、オブジェクト指向のアプローチ、構造化されたアプローチ UMLモデリング、オブジェクト指向モデリング

(7):その他の利益またはアップグレードします。

    在整个软件工程课程的学习过程中,我的博客撰写能力、基于java语言以及数据库sql语言的程序编写能力都有了很大的提升,而且,经过多次团队作业,我的团队协作能力也有了极大的提升。

5.どのような問題は、現在のカリキュラムを思い、あなたは任意のより良い提案を持っています。

    我认为软件工程就是一门需要手动、脑动的课程,老师布置的作业可以很好的帮助我们。唯一的缺点可能就是时间的问题,因为大三学生的任务还是很繁重的,软件工程的作业是每周一次,为了保质保量,必然会花费很多的时间,所以,我希望老师可以增加一些时间给每一个项目,让学生可以更好的完成它。

おすすめ

転載: www.cnblogs.com/tanggq/p/11109284.html