분류 전체보기

유지보수 (Part2)

형상 관리 절차- 형상 식별   -> 형상 관리 대상을 구분, 베이스 라인의 기준을 정함   1) 형상 항목 선정   2) 형상 식별자 규칙 선정   3) 베이스라인 기준 선정       -> 베이스라인을 설정하지 않으면 어떤 파일이 최종적으로 사용되었는지 혼란 (작업의 기준)- 형상 통제   -> 형상변경요청을 승인하여 베이스라인에 반영될 수 있도록 통제   1) 변경 요청   2) 변경 심사   3) 변경 실시   4) 변경 확인        -> 새로운 버전 번호 부여, 새로운 베이스라인으로 수립- 형상 감사   -> 형상 항목의 변경이 계획에 따라 제대로 이루어졌는지 검토/승인- 형상 기록/보고   -> 소프트웨어 개발 상태에 대한 보고서를 제공   -> 관련된 사람들에게 보고 역공학이 필요한 이..

유지보수 (Part1)

레거시(Legacy) 시스템을 대체하지 못하는 이유- 높은 비용- 전문가, 사용자의 오랜 경험과 지식이 녹아 있음- 새로운 시스템이 더 좋다는 보장이 없음-> but 레거시 시스템을 계속 사용할 경우 유지보수가 점점 어려워짐 유지보수 유형- 수정형 유지보수   -> 테스트 단계에서 미처 찾지 못한 잠재적인 오류 발견- 적응형 유지보수   -> 프로그램 환경 변화에 적응하기 위함- 완전형 유지보수   -> 새로운 요구사항을 반영하기 위함   -> 유지보수 활동 중 가장 많은 자원 소모- 예방형 유지보수   -> 선재적 유지 보수 리먼(Lehman)의 소프트웨어 변화 법칙 (8가지)- 지속적인 변경의 원칙- 엔트로피, 복잡도 증가의 원칙   -> 시스템의 구조는 변경할수록 더 나빠짐   -> 변경될수록 구조..

테스팅 (Part2)

화이트박스 테스트 과정1) 소스코드를 통해 어플리케이스의 구조를 이해 (논리흐름도)2) 검증기준(커버리지)를 정함3) 각 경로에 대한 테스트 케이스를 준비, 결과 비교 커버리지- 테스트 데이터를 선택하기 위하여 테스트 실행 프로그램이 어떤 기준을 커버하는지 결정1) 문장 커버리지2) 분기 커버리지3) 조건 커버리지4) 조건/결정 커버리지5) 분기 커버리지   -> 모든 테스트 케이스를 조합하여 테스트를 수행하는 방법 통합테스트 모듈 결합 방법- 빅뱅 통합   장점 : 일정 관리가 편함, 테스트를 위해 스텁을 만들 필요가 없음   단점 : 오류의 위치와 원인을 찾기 어려움, 개발 진도를 예측하기가 어려움- 하향식   장점 : 중요한 모듈의 인터페이스를 초기에 테스트해볼 수 있음             오류의..

테스트(Part1)

테스팅이 왜 중요한가?1) 결함 예방2) 품질과 안정성 보장3) 소프트웨어의 신뢰성 향상 검증과 확인- 검증   -> 각 단계의 일들을 잘하고 있는가? (요구분석, 설계 등)- 확인   -> 결과가 요구사항에 맞게 잘 만들어졌는가? (요구와 최종 릴리스 사용) 테스트의 원리 (5가지)- 테스트는 오류를 찾기 위해서 하는 것   -> 잘 작동한다는 것을 보여주는 것이 아님- 완벽한 테스트는 있을 수 없음   -> 테스트를 통과한다고 해서 완벽한 프로그램이 아님   -> 효율적인 부분집합을 테스트해야함- 테스트는 창조적이며 어려운 일임- 테스트는 오류의 유입을 방지할 수 있음   -> 오류를 빠르게 알 수록 수정 비용이 적어짐- 테스트는 독립적인 팀에 의해서 이루어져야함   -> 객관적인 시선에서 보는 것이..

구현

로드맵- 코딩 표준- 메소드 구현   -> 메소드 내부의 내용 구현 (설계에서는 진행 X)- 클래스 인스펙션   -> 구현 결과를 눈으로 확인 (눈코딩)- 유닛 테스트   -> 클래스의 메서드를 시험- 릴리즈 코딩 오류- 메모리 누수   -> 메모리가 free 되지않고 계속 할당됨 (메모리 고갈)- 중복된 free 선언   -> 메모리를 free하고 중복으로 다시 free하는 경우   -> 프로그램이 중단되는 critical한 오류임- 하나 차이에 의한 오류   -> 범위 양 끝지점에서 일어나는 오류- 배열 인덱스 오류   -> 범위 안에 있지 않거나 범위를 벗어나는 인덱스를 호출하는 경우- 수식 예외 오류   -> 0으로 나누는 경우- 스트링 처리 오류   -> 매개변수가 NULL일 때, 스트링이 NU..

설계 (Part 9) : UI 설계

UI가 중요한 이유- 사용자 경험 개선- 생산성 향상- 오류 감소- 유지보수 용이성-> 시장경쟁력 강화 UI 설계 요소- 버튼- 툴바   -> 공통 작업일 경우- 메뉴- 라디오 버튼   -> 여러 항목중 하나만 선택할 경우- 체크 박스   -> 다른 항목과 관련없이 한 항목에 대한 True/False가 필요한 경우- 텍스트   -> 내용을 입력해야 되는 경우   -> 오류가 들어올 가능성을 전제로 두고 구현- 리스트   -> 여러 선택항목을 모두 보여주고 그 중 선택하는 경우- 콤보 박스   -> 선택항목이 너무 많아 한 화면에 보여주는 것이 힘들 때(화면의 제약) 스크롤을 사용- 탭   -> 탭으로 구분을 잘 하면 모듈화가 잘 된 느낌을 준다   -> 너무 많은 탭을 만들면 사용자의 실수를 유발할 수 ..

설계 (Part 8) : 아키텍처 설계

아키텍처의 4+1 관점[ 문제 영역의 1개 관점 ]   - 시나리오 관점 : 시스템이 사용자에게 제공하는 기능에 주목 -> 유스케이스 관점이라 함[ 해법 영역의 4개 관점 ]   - 논리적 관점 : 시스템의 내부를 들여다봄, 클래스나 컴포넌트 및 이들의 관계에 초점   - 프로세스 관점 : 비기능적인 속성에 관심을 가지는 것, 자원의 효율적인 사용이나 이벤트 처리 등을 표현                              동적인 개념이 들어감   - 개발 관점 : 서브시스템의 모듈이 어떤 관계를 갖고 상호작용하는지에 주목   - 물리적 관점 : 물리적인 배치에 주목, 분산 및 배치 상태 아키텍처 스타일-> 개발할 시스템의 타입에 따라 아키텍처 스타일을 결정1) MVC 구조 스타일2) 저장소 구조 스타..

설계(Part 7) : 모듈화

7가지 바람직한 설계 목표- 느슨한 결합 (모듈끼리의 결합) - 강한 응집력- 복잡성 최소- 유연성- 확장성- 유지보수성- 재사용성 모듈화- 모듈(Module) : 시스템의 각 기능- 소프트웨어의 성능을 향상시키기 위해서 기능 단위로 분해한 것- 모듈의 독립성은 1) 결합도를 약하게 2) 응집도를 강하게 3) 모듈의 크기가 작을 때 높아짐    1) 모듈끼리의 영향 최소화   2) 모듈 안에서의 기능은 최대한 같은 기능   3) 너무 크면 모듈안의 기능들이 달라질 수 밖에 없음결합도의 종류- 자료 결합도   -> 가장 낮은 결합도   -> 단순히 파라미터 등을 통해 데이터를 주고 받음    -> 한 모듈의 내용을 변경해도 다른 모듈에는 전혀 영향을 미치지 않음- 스탬프 결합도   -> 두 모듈이 동일한 ..