본문 바로가기
728x90

전체 글240

[운영체제] 1장 Introduction 1장 요약 컴퓨터 시스템 요소 하드웨어 – CPU, memory, I/O devices 등 소프트웨어 - 한글, 윈도우, 오피스, 등등 프로그램 운영체제 – Operating System 4. 응용프로그램 – application programs(compilers, web browsers, development kits 등) => 운영체제 위에서 돌아감 5. 사용자 – user 운영체제 역할 – SSD, HD 저장된 게임을 메모리 위에 올려놓고 CPU와 같은 HW자원을 이용하여 게임과 같은 프로그램이 잘 돌아가게 해줌. 컴퓨터시스템, 운영체제 역사 학습함 운영체제의 정의 – 소프트웨어와 하드웨어(CPU, IO장치, 메모리 등) 간의 컴퓨터 자원을 효율적으로 관리를 해서 사용자에게 편안하고 편리한 작업환경.. 2021. 6. 29.
[소프트웨어공학] 25장 Configuration Management -> 소프트웨어의 버전을 관리하는 부분, change 요청을 관리하는 부분에서 언급됨. 주요의제 Version management(버전관리) System building(시스템 통합) Change management(개선점 변경관리) Release management(배포관리) Configuration Management ->소프트웨어 제품에 들어가는 다양한 소스코드, 자원에 대해서 유지관리 함 ->소스코드를 관리하며 변경이 된 내용을 관리하고 변경된 이력 역시 관리함 ->수정이 발생한다면 어떠한 파일이 언제 어떠한 이유로 바뀌었는지를 기록하고 관리함 ->각각의 릴리즈에 들어가는 소프트웨어는 무엇인지 컨트롤할 수 있어야함 CM activities >Version management – 버전을 관리해 주는.. 2021. 6. 29.
[소프트웨어공학] 24장 Quality Management -> 앞에서 다룬 개발을 통해 소프트웨어가 도달해야할 양적 질적 수준에 도착하였는가 판단하는 것 -> QA팀(개발이 잘 되었는지 판다하는 그룹) 주요주제 Software quality -> 소프트웨어 퀄리티 정의 Software standards -> 소프트웨어 품질 관리 표준 적립 Reviews and inspections -> 품질관리에서 코드를 리뷰하는 정적관리, 실행 시에 코드가 잘 동작하는지 보는 다이나믹 분석이 있음 Quality management and agile development -> 에이자일의 경우 품질관리가 어떻게 이루어지는지 확인 Software measurement -> 정량적으로 소프트웨어의 품질이 어떤지 측정하는 방법론 Software quality management ->.. 2021. 6. 29.
[소프트웨어공학] 23장 Project planning -> 누군가 만든 소프트웨어를 고객에게 돈을 받고 제공한다. -> 고객의 요구를 받아서 개발 후 그 소프트웨어를 고객에게 제공함. -> 원칙적으로 plan-based를 가정함 -> 에이자일과의 상관관계도 설명을 함 -> 소프트웨어를 납품하는 과정을 배움 -> 소프트웨어공학의 주된 내용 -> 경험과 노하우에 대해서 배우는 것 -> 23,24,25장은 소프트웨어를 돈을 받고 판매하려고 할 때 중요한 부분을 차지함 -> man-month가 나온 것처럼 기존의 제조업에서 발전한 소프트웨어 개발이 상당수 실패를 겪으면서 돈을 받고 제품을 만드는 것(시간, 성능을 주로 추구함)을 해온 사람들과의 거래에서 고려해 봐야하는 부분이기 때문에 충분히 고려해봐야 할 부분이다. -> 얼마를 받고 받을 건지, 고객에게 돈을 받.. 2021. 6. 29.
[소프트웨어공학] 22장 Project Management project의 plan을 세울 때 가장 중요한 것 -> 얼마만큼의 인원으로 얼마만큼의 비용을 들여서 얼마만큼의 시간을 들여서 수행할지 ex. IBM에서 데스크톱 컴퓨터를 만듦 -> CPU는 인텔, OS MS를 가져다 사용함 -> 하드웨어는 만들었지만 다른 애플과 MS의 OS가 큰 성공을 거두자 이에 따라 OS/2라는 운영체제를 만듦(윈도우즈와 유사) - 덩치가 너무 컸음 -> 기술적으로 많은 투자를 했지만 크게 실패한 사례임 -> 이전까지 배웠던 것처럼 개발되어온 소프트웨어가 무조건적으로 성공하는 것은 아님 ex. Multics -> multi user, performs, process(완전히 망함) -> 이것을 기반으로 unix운영체제가 만들어졌습니다. >>프로젝트가 수행되었다고 해서 무조건 성공하는.. 2021. 6. 29.
[소프트웨어공학] 9장 Software Evolution 소프트웨어공학의 기저에는 plan-based, top down, waterfall이 자리 잡고 있지만 에이자일 이나 plan drive 방법에 역시 적용이 가능함 주요의제 Evolution processes – 소프트웨어가 출시되고 끊임없이 발전/개선 됨 Legacy systems – 누군가 만들어 놓은 오래된 시스템이 아직도 사용되고 있는 것들이 있음 그런 것들에 대한 이해가 필요함 Software maintenance – 어떠한 작업들이 출시된 이후에 이루어지는지 알아봄 Software change >Software change is inevitable -> 소프트웨어가 출시가 되고 끝이 아님 -> 결국 우리가 놓쳤던 실수들이 들어오게 되거나 아니면 출시이후에 생긴 문제들이 생김 -> 비즈니스 환경의.. 2021. 6. 29.
[소프트웨어공학] 8장 Software Testing 실제 개발한 소프트웨어를 실험하고 검증하는 단계 주요의제 Development testing(개발에서 테스트가 무엇인지) Test-driven development(민감한 소프트웨어를 짤 때 많이 사용됨) Release testing(실제 사용자에게 내놓기 위한 테스트) User testing(사용자입장에서 테스트) Program testing >테스트를 할 때 우선적으로 확인해야할 것은 주어진 입력에 맞춰서 출력이 제대로 나오는 것에 대한 정상의 입력에 대해 정상의 출력이 나오는지 확인해야 한다. >어떠한 상황에서 프로그램이 잘못 동작하는 것에 대해 발견하고 그것에 대해 수정하거나 개선하거나 대응 할 수 있어야 한다. -테스트에 사용되는 데이터는 임의적으로 만들어지거나 아니면 이전 제품이 다루었던 내용.. 2021. 6. 29.
[소프트웨어공학] 7장 Design and Implementation 이전까지 요구사항을 정의를 하고 시스템의 아키텍처까지 정의를 했다. top-down 방식에서 설계자와 구현자가 다를 수 있다. 각각을 세분화해서 설계와 구현을 분리할 수도 있는 반면 에이자일과 같은 경우에는 설계와 구현이 밀 결합되어있다. 주요의제 Object-oriented design using the UML – 폭포수 기법이건 에이자일 기법이건 UML을 적용은 같지만 사용용도는 다를 수 있음 밑에 것들은 개발에 연관성이 더 높다 Design patterns Implementation issues Open source development 소프트웨어 상세설계와 구현을 통해서 결과로는 실행 가능한 시스템이 나온다. 상세설계와 구현하는 사람이 다르다면 서로 대화를 많이 해야 한다. 더불어 같다면 에이자일.. 2021. 6. 29.
[소프트웨어공학] 6장 Architectural Design requirement engineering에 의해 요구사항이 정리되고 추가로 모델링 부분까지 설명함 모델링은 설계단계에서 역시 사용이 가능하다. 지금까지 사용자가 원하는 요구사항을 만들고 그것을 설계가 용이하도록 그림 화하는 작업까지 해봄 이번 장에서 실제로 설계에 들어감 앞에서 배운 구조 모델링이 여기서 많이 쓰인다. 주요의제 Architectural design decisions – 설계를 위한 의사결정 Architectural views – 다양한 관점 Architectural patterns – 시스템의 형태를 골격화한 것 Application architectures – 어플리케이션 예제에 대해서 구조화 >Architectural design(소프트웨어 시스템 내부) - requirement e.. 2021. 6. 29.
728x90

티스토리툴바