본문 바로가기
728x90

👨‍💻Computer Science73

[소프트웨어공학] 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.
[소프트웨어공학] 5장 시스템모델링(System Modeling) 앞에서 만든 요구사항(무엇을 해야 할지 정의)들을 토대로 동작시킬 시스템을 만들어야함 -> 요구사항을 반영해서 만든 소프트웨어를 모델링(그림을 많이 그림)함 우리가 무엇을 만들어야할지를 구체화하는 작업 대표주제 Context models – 우리의 시스템이 무엇인가 Interaction models – 다른 것들과 우리 시스템의 상호작용 or 내부 객체들 간의 상호작용 Structural models – 위와 같은 것들을 그림으로 모델링 하는 것 Behavioral models – 세부적으로 무엇을 기술할지를 정함 Model-driven engineering – 모델링을 잘하면 그것이 바로 시스템 코드로 나옴 -모델링에 대한 다양한 방법들을 제시를 할 것임 -그림(약속되어 있음, UML)으로 기호로 소프.. 2021. 6. 29.
[소프트웨어공학] 4장 Requirements Engineering *Plan based 기반으로 많이 설명함 Functional(소프트웨어 기능 관련, 구체적) and non-functional(추상적, 개발 전반에 영향을 미치는 요소) requirements Requirements engineering processes Requirements elicitation(요구사항 추출) Requirements specification(요구사항 명세화) Requirements validation(요구사항 검증) Requirements change(변화에 대한 발전사항) Requirements engineering 2가지 측면 -고객이 시스템에 대해 요구하는 것(이루어져야할 부분, 제한사항들을 파악) -구현해야할 기능적인 측면 요구사항 고객이 잘 모르는 부분은 모호함이 있을 수.. 2021. 6. 29.
[소프트웨어공학] 3장 에이자일소프트웨어개발 (Agile Software Development) 웹을 기반으로 하는 서버베이스에 많이 사용된다. 변화를 빠르게 받아드린다. 에이자일을 다루는 개발자 입장에서 폭포수 기법의 문제점을 알아봄 Plan based 기법을 주로 사용하는 서비스 -> c, c++를 통한 컴파일 언어가 주가 됨, 기계언어는 자체적인 해석이 안 되기 때문에 개발자만이 변경이 가능함 -MS windows & Office -한컴 한글 워드 프로세서 -패키지 게임 현대 에이자일을 다루는 서비스(유행이 민감한 서비스) -구글, 네이버 검색 서비스(실질적으로 소프트웨어를 팔지 않음 네이버와 같은 경우는 주 비즈니스 모델이 광고임 -> 대부분의 소프트웨어는 무료이고 이를 통한 서비스로 광고를 내보냄) -Free 게임(스마트폰 게임 -> 무료 다운이 가능하지만 속에서 아이템을 파는 것을 통해 .. 2021. 6. 29.
[소프트웨어공학] 2장 소프트웨어프로세스 소프트웨어 프로세스 모델 공정활동 변화에 대처하는 방법 공정개선 소프트웨어 프로세스 – 소프트웨어 시스템 개발에 필요한 구조화된 활동 집합 명세서(Specification) – 설계 및 구현(Design and implementation) – 검증(validation) - 진화(Evolution) 소프트웨어 프로세스 모델은 프로세스의 추상적인 표현이다. 일부 특정 관점에서 프로세스에 대한 설명을 제공합니다. 소프트웨어 프로세스 모델(Software process models) >폭포수 모형(The waterfall model) - 계획 중심 모델 사양 및 개발의 개별적이고 뚜렷한 단계. >점진적 발전(Incremental development) - 사양, 개발 및 검증이 서로 인접하지 않게 배열됩니다. .. 2021. 6. 29.
728x90