Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a 5장
Semelhante a 5장 (20)
Mais de 홍준 김
5장
- 1. HARD CODE 5 , . kingkkkk@hanmail.net
- 2. 5 , . • ? • ? • , • •
- 3. ? • • . • , , . •
- 4. ? • • . • . • STRIDE • API • X =
- 5. ? • • • • (MS) •
- 6. ? • , , • V " . ." •
- 7. ? • . • • •
- 8. ? • • • • •
- 9. ? • • •
- 10. ? • • • •
- 11. ? • • •
- 12. ? • • •
- 13. ? • • •
- 14. ? • ? • ? • , , • • • !
- 15. , • , • • • • ,
- 16. , • • , , , , . • , , . • • • • ,
- 17. , • • • , ,
- 18. , • ? • • •
- 19. , • • • • •
- 20. , • , • • , ,
- 21. , • • , , PREfast , , • . •
- 22. • FOCKED • • •
- 23. • • • ' ' • •
- 24. • ? • • • ? • • •
- 25. • ? • • •
- 26. • • • •
- 27. • • • • •
- 28. • • 2~3 • 3~5 , 200~400 • • • / • / •
- 29. • • • • •
- 30. • ? • •
- 31. • • main branch • • •
- 32. • • 90% , , , • • • , , • ?
- 33. • ? • • • •
- 34. • • • •
- 35. • • • •
Notas do Editor
- 보안은 진짜 개떡같은 문제 수백만 줄 코드에서 단 두줄을 간신히 악용 했다는 이유로 언론의 똥파리들이 광분
- STRIDE 스푸핑 spoofing 변조 tampering 부인 repudiation 정보 공개 information disclosure 서비스 거부 denial fo service 권한 상승 elevation of privilege DREAD 예상 피해(Damage potential) 재현 확율(Reproducibility) 공격 용의성(Exploitability) 영향을 받는 사용자(Affected users) 발견 용이성(Discoverability)
- 팀이 협의하여 심각도와 발생 가능성 등급을 정함 등급 1~10 심각도 10은 매우 심각 발생가능성 1 매우 희박
- 일괄수주 제품을 요구 열쇠만 돌리면 곧바로 돌아가는 제품 - 쉬운 프로그램 소비자 제품 시장 경쟁업체-작고 단순한 제품, 실패 확율은 낮음, 복구도 쉬움 MS-기능이 훨씬 풍부하고 복잡함, 실패율은 높음 기업 제품 시장 경젱업체는 제품 지원과 컨설팅을 가장 큰 사업분야로 꼽음 실패가 잦아지면 오히려 돈 저렴한 제품을 대량으로 판매하고 최소한의 지원 실패율이 낮아야 함 실패해도 신속하게 고치거나 복원
- 두가지 측면에서 부정적 고객이 다음 버전을 구매 하지 않는다. 제품을 모방한 제품이 마구 쏟아진다.
- 품질을 얻으려면 희생이 따름 고차원적인 관점 변수는 품질, 일정, 기능 고정된 일정 품질 강요 기능 줄어듬 고정된 기능 품질 강요 일정 늘어남 빌 게이츠 왈 : 과거 우리는 새 기능을 추가하고 플랫폼을 확장하는 방법으로 우리 소프트웨어와 서비스를에 경쟁력을 더했습니다. 이제까지 멋진 성과를 거뒀지만, 고객이 우리 소프트웨어를 신뢰하지 못한다면 아무리 우수한 기능을 제공해도 소용이 없습니다. 품질을 높이려면 설계와 코드 개선 보조 코드 삽입(instrumentation)과 테스트 개선 고객지원과 복구 속력 개선
- 설게를 토론하고 코드를 검토 단순성 올바른 팩토링 TDD 는 구현 설계 과정에서 위 두가지 효과를 제공 팀원을 짝지어서 기능 구현 기능에 투자하는 시간 2배 설계와 코드를 검토 백업 개발자가 있어서 진행에 유용 팀을 자율적으로 일하도록 명세서에 완료 날짜 정함 백업 개발자도 품질에 책임 체크인 품질을 추적
- 단위 테스트 긍정적인 단위 테스트는 의도대로 코드를 실행해서 결과를 검증 부정적인 단위 테스트는 고의적으로 코드를 잘못 사용해서 안정성과 오류를 처리 상태를 확인 스트레스 테스트는 코드를 한계까지 밀어 붙여 미묘한 자원, 성능, 재진입 오류를 찾아냄 오류 삽입 테스트는 코더가 비정 상적인 상황을 일관성 있게 처리하는지 확인
- ex: IIS 서버 컴포넌트가 죽으면 즉시 서버 프로세스를 자동으로 다시 시작 ex2: 오피스 죽으면 자동 저장 다시 시작
- 제품을 컴포넌트로 분해한 후 각 컴포넌트마다 품질 점검 보조 코드 삽입 테스트 지원 복구 구조적인 공학 기법 적용 제품을 단순화 애초에 설계한 목적만 정확하게 수행 하도록 기능을 단순화 쓸때 없는 옵션 넣지 마라
- 개발자는 무엇이냐 우리는 공학자가 아니라 개발자다 용역꾼은 일단 부딪히고 본다 행동이 먼저 생각은 나중 누가 뭐라 해야 마지 못해 뒤처리 공예가는 미리 연구,계획,가장 적합한 기법과 도구를 사용,자기 결과물에 자부심을 가진다. 우수한 소프트웨어 개발자가 여기에 속함 공예는 확실성과 예측성이 부족, 결과를 알기 보다는 예측하는 수준
- 창의성이나 혁신정신이 부족 하다는 뜻은 아님
- 개발과정에서 수집할 측정값 각 점검 기간에 투자한 작업시간(설계,구현) 이미 정검한 작업을 다시 하느라 걸린 시간과 재작업 양(설계변경,버그) 추가하거나 삭제하거나 변경한 코드 행 수
- 이 자료를 토대로 버그를 통제에 나섯던 팀들은 코드당 1000줄당 40~100개에서 100만줄당 20~60개로 줄였다. 통합과정에서 발생하던 버그도 줄어듬
- FOCKED 병 검토회의에 멍 때리는 걸린이유 아이디어와 해결책 찾아내기 진행중인 작업에 대한 피드백 받기 완료한 작업의 품질을 진단하고 문제 찾기 고치는 방법 목표를 파악 목표 달성을 위한 효율적인 방법 선택 브레인 스토밍 비공식 검토 검사
- 최종 해결책 퓨의 개념 선택 기법 독립적인 요구사항과 각 해결책을 대비해 표를 만듬 해당 해결책이 해당 요구 사항을 만족하는 정도를 판단 각 칸에 양수,음수,0을 기입 해결책 별로 값을 합산해서 점수가 가장 높은 해결책 선택 최종 해결책을 선정하지 않는 편이 낫다 모든 설계 아이디어를 후보로 고려,모든 요구사항을 최적으로 만족하는 해결책 하나가 남음 도요타 집합 기반 설계
- 완벽하게 구현된 기능이라도 아이디어가 자체가 틀렸다면 고객에게는 무용지물