첫 번째 개인 블로그 작업

계획	함유량
이 작품은 과정 속	봄 2020 컴퓨터 소프트웨어 공학 연구소 (로저 렌 지안)
어디에서 작업이 요구 사항	개인 블로그 작업
이 과정에서 내 목표는	팀 프로그래밍 능력을 향상 소프트웨어 공학의 기초를 마스터
작업 특정 측면이 나를 목표를 달성하는 데 도움이	은 "법의 건물"소프트웨어 공학의 개념과 사고의 예비 이해를 읽고

첫째, 독서 질문 후

두번째 테스트 유닛 (P22) 기술, 유닛 테스트 모듈에 어떻게 결합 장 2.1

단위 테스트 안정성 및 적절한 동작 모듈을 보장하는 것이다. 같은 점프 자료에 의존하는 데 필요한 기술의 일부로서 - 그러나 모듈 사이에서 커플 링은 점프 모듈과 기술을 모듈에 연결됩니다의 게임으로, 현실에 존재합니다. 이 경우 어떻게 단위 테스트를 설계?
두 개의 처리 방법을 종결 전체 테스트 주로 얻은 후 현재 (즉, 모든 테스트 모듈을 포함한다), 전체 예기치 않은 (즉, 연관 모듈 가정 올바른지). 내 사상은 큰 블록 설계 결합 유닛 테스트 후의 모듈의 다른 모듈들 사이의 관계에 기초하여 모듈 사이에 연결의 정확성을 검증 할 수있는 능력이다.

장 VI 6.2 (P117)이 여러 애자일 개발 경험의 경우의 문제와 거래를 언급에 대해, 다음 방법을 너무 오래 회의를 위해이 문제를 다루는

나는이 문제는 정기적으로 매일 엉덩이 회의를 포함한 다양한 기능 팀의 필요 엉덩이 작업에, 계획 층에서 특히 분명하다, 매일 회의는 개발 민첩 많은 시간을 차지 인턴 찾을 수 있습니다. 반면에 의사 결정 회의는 종종 효과적으로 회의는 항상 전체 이야기의 세부 사항의 일부를 토론하는 반 또는 한 시간 이상을 논의하는 것으로, 문제는 작은 팀 개발을 개발 대기업에 여전히 존재 여부, 결과를 논의 할 수 없습니다 따라서 효과적으로 진행을 촉진 할 수 없습니다. 그 중 두 종종 육시간 시간 두 세 시간 회의에 소요 극적 개발의 효율을 감소 작업 일의 결과, 그 문제는 계약이 민첩의 개발에서 발생하는 방법을 알고 싶어요 .

내가 혁신적인 소프트웨어는 또한 고려의 요구를 취할 필요가 있는지 여부의 요구를 생각 주로 사용자의 요구 및 기술 요구 사항을 구성하여 소프트웨어 요구 사항에서 언급 한 제 VIII 8.1 (P157) 소프트웨어 요구 사항,

예를 들어, 아이폰의 출시와 다른 스마트 폰과 모바일 게임 시장이 성장하고 있지만, 블리자드 입력 할이 PC 사용자의 손 여행 회사의 주요 사용자하지만 때문에이 회사의는 PC 게임의 장기적인 발전이다, 필요성의 부족의 관점에서 모바일 게임 경험은 이득 경험에 모바일 게임을 개발합니다. 혁신은 블리자드 (내 사용자 지정 요구) 모바일 게임을 필요로 할 때 충돌이있는이 때, 사용자의 요구는 한 번에, 블리자드의 새로운 PC 게임이다. 인터넷 기업으로서 확실히 긍정적 인 변화없이 규칙에 충실 할 수는 없지만이 충돌 요구 가고 계정에 소프트웨어 요구 사항을할지 여부를 고려하면 변화와 시도하고 회사를 설정하기 위해 필요한 혁신, 사용자의 요구의 모순을 축적하고 내부에, 우리는 어떻게이 모순 균형을해야합니까?

제 XV 15.1 (P330) 언급 여러 소프트웨어 게시자는 DDL 버그 처리 방법에 직면하지만, 지연 방출을 건너 뛰고, 나는 연기 선택할 때 알고 싶다

이 책은 연기 원본 릴리스에 다음과

일부의 비용으로 "완벽한"을 위해 세계적으로 유명한 회사를 포함 할 것이다 지연 게시 등 "영원히 공작이 충족"일부 애플 제품의 유명한 게임과 같은 예, 등등 ... 나는 질문 : 아이폰 첫 번째 버전 완벽한 무엇입니까? 심지어 / 복사 기능이없는 붙여 넣기,하지만 그는이 방출 됐습니다

그러나 사실,이 단어는 방법은 제품의 완벽하고 지연 방출이 해제 가능하지 아니지만, 소개 나중에 또 대처 상황의 곧 출시를 처리하는 방법으로 릴리스를 지연 할 수 없습니다, 그러나 실제로이 더 있음을 강조 할 수 없다 나는이 때 확장자를 알고 계획 릴리스로 선택할 때 선택 할 수 있도록 제품의 대부분은, 출시 날짜가 오기 전에 지연 선택합니다.

장 XVI 16.2 (P362)의 뛰어난 혁신은 대중에 의해 허용 될 수없는 산업보기의 일부를 만들기 위해 조기 지적, 생각 조기 의미있는 혁신이다

혁신은 사용자에 의해 허용하지만, 할 수없는 동안은 특별한 의미와 좋은 영감 대응, 될 수있다. 1999 년 예를 들어 그 해에 매우 실력을 판매 있었지만, 세가는 게임 '쉔무 "을 발표하지만, 자주 오늘날에 사용되는 혁신 영화 서술 방법과 QTE 시스템에서 게임은 다음 주류 게임 모두에 의해 만들어 . 혁신적인 게임 사용자의 수용에 관해서는,이 게임은 완벽합니다. 사용자 경험은 다른 게임 회사들은 이러한 혁신의 가치와 '쉔무'게임 모드는 시대의 감각이라고 실천, 궁극적 인 증거를 볼 그래서. 혁신의 일부는 상업적으로 성공하지뿐만 아니라 산업의 발전을 촉진하기 위해 가치를 가지고, 또한 가치를 실현해야 조기 혁신 (앞서 동료의 혁신은) 비록이라고 할 수 있습니다.

둘째, "소프트웨어"및 "소프트웨어 공학"이 단어가 표시되는 방식인가?

단어의 소스 "소프트웨어"는 "소프트웨어"에 위키 백과에 설명

오늘날 우리가 알고있는 컴퓨터의 창조 이전에 소프트웨어에 대한 최초의 이론은 Entscheidungsproblem (의사 결정 문제)에 대한 응용 프로그램과 함께 그의 1935 에세이 계산 가능한 수에 앨런 튜링 (Alan Turing)에 의해 제안되었다

즉, 처음과 "를 Entscheidungsproblem에 응용 프로그램과 함께 계산 가능한 숫자"튜링의 1935 기사라는 제목의 단어 "소프트웨어"및 관련 이론을 설명 글

그리고 "소프트웨어 공학"만든 아폴로 프로그램 기간 동안 1968 마가렛 해밀턴 발명에서 용어 "법을 구축"에 따라

셋째, 당신이 재미있는 퀴즈와 이야기를 찾아 어떤 소프트웨어 엔지니어링 개발 과정

감소 플래시 잡스하기로 결정
벡터 그래픽 무료, 편리한 설치 매우 정교한 매우 인기가 있습니다 시간에 제공하는 매우 작은 양 (몇 백킬로바이트 ~ MB)를 형성 할 수있는 능력 덕분에 한 번 깜박에서 발견된다 거의 모든 페이지에 걸쳐. 그러나, 빠른 플래시 하락하지만 가장 화려한.
천둥 Masamori 플래시 불어 애플이 막 시작했다는 사실이었다. 스티브 잡스가 플래시 기술의 소유자로,이 결정을 인정하지 않았다 모든 관련 제품 거의 모두, 플래시를 지원하지 않을 것이라고 결정 후 애플은 어도비는 애플의 움직임은 "반 경쟁"과 반응 후자 말했다 소위 "플래시의 성능과 보안에 대한 악몽을 가져올 것"이라고 말했다. 스티브 잡스가 2010 년 4 월이라는 제목의 희귀 기사 발행 후 "플래시 설명 정보를"1500 워드 문서를 어도비는 아이폰이 플래시를 지원하지 않습니다 이유를 설명 인수를 반박. 스티브 잡스가 강한 플래시에 거절 진짜 이유에 관해서는, 어도비 애플의 형식적인 태도는 이전에주고 실패의 플래시에 대한 질문입니다 그것은 플래시 보안 자격 증명의 문제를 해결할 수 설득가. 스티브 잡스는 아이폰의 궁극적 인 성공을 발표 Adobe는이 논쟁을 수상했다. 앤드류스 빠르게, 웹에서 모바일 단말을 입력하는 것은 더 이상 가능 플래시 호황을 누리고 있기 때문에, 지원 플래시를 떨어 없습니다.

주요 보안 결함의 버스트 플래시가 낙타의 등을 부러 마지막 밀짚 낳은 후에, 크롬, 파이어 폭스와 다른 브라우저는 플래시를 포기해야, 심지어 HTML5를 사용하는 대신 시작 트위터 페이스 북으로 시작 플래시 소프트웨어에 의존하는 사람들이 빠르게 깜박 시대의 눈물이된다.

넷째, 소스 코드 버전 관리 소프트웨어 및 프로젝트 관리 소프트웨어

힘내
- 장점 : 많은 오픈 소스와 사용자의 수는 오픈 소스 프로젝트는 무료 호스팅 GitHub의에서, 사용자는 쉽게 오픈 소스 코드의 방대한 양을 찾을 수 있습니다. 분산 버전 관리 시스템으로 편리하고 유연한 버전 관리 및 수정, 편집 된 버전보다 효과적인 지원이 될 수 있습니다.
- 단점 : 어려움의 특정 정도가 시작하는 것입니다
수은제
- 장점 : 초보자 비교적 완벽하고 쉬운에 대한 의욕 파일은 사용하기 쉬운, 읽을 수 있습니다. 의욕이 개발 Windows에서 원활하게 구현하기 위해 파이썬을 사용하는 것입니다. 데이터베이스 유지 관리가 간편.
- 缺点：与Git相比功能性有所不足
Trac
- 优点：有良好的扩充性，权限体系设计比较完备
- 缺点：不支持多项目，需求和缺陷没有分离，中文本地化做的不好
Bugzilla
- 优点：免费且中文支持良好
- 缺点：只能管理缺陷