소프트웨어공학

소개글

소프트웨어공학에 대한 보고서 자료입니다.

목차

1.Critical System

2.Dependability
-Availability(Active/Stand by, Primary/ Back up)
-Reliability(신뢰성)
-Safety(안전성)
-Security(보안성)
위 주제들에 대한 자세한 설명과 예제

3.Software Process
-waterfall model
-Evolutionary development
-Spiral development

4.process activity

5.software design and implementation(설계,구현)
-Design process activities(설계활동)

6.software validation(소프트웨어 검증)
-Testing stage(시험프로세스)

7.Software management distinction
-Management Activities(관리활동)
-Project planning
-이정표(milestone)

8.Software requirement(소프트웨어 요구사항)
-Requirements engineering

9.Functional and non-Functional requirements

10.goal and requirements

11.Domain requirements
.
.
이외에도 많은내용..

본문내용

순한 개체일수도있고 밀접한 관련이 있는 개체들의 집합일수도 있다.
2.시스템시험: 컴포넌트가 시스템을 구성하기 위해통합됨, 예기치 않았던 상호작용과 컴포넌트의 인터페이스 문제로부터 생긴 오류 찾기, 기능적,비기능적 요구사항 만족하는지 검증, 새로운 시스템 특성 시험, 대형시스템일 경우 서브시스템이 최종적으로 통합전 독립적으로 시험된 서브시스템을 만들기 위해 컴포넌트 통합하는 다단계 과정 될수도
3.인수시험: 일상적 운영을 위해 인도되기 전 시험프로세스의 마지막, 고객이 제공한 데이터를 갖고 시험, 시스템 요구사항 정의에서 생략된것과 오류를 찾아냄, 사용자의 요구 충족못하거나 받아들일 수 없는 시스템의 성능과같은 요구사항 문제 드러냄=알파테스팅
*베타테스팅: 잠재적인 고객들이 하는 것
5과
Software management distinction
1.소프트웨어 제품은 형태가 없다(소프트웨어 제품관리자는 프로젝트 진척사랑을 점검할 수 있는 문서를 생성하는 사람에게 의존)
2.표준화된 프로세스가 없다(소프트웨어 프로세스는 조직에 따라 매우 가변적. 언제 개발문제를 야기할것인가를 신뢰할 정도로 예측할 수 없다)
3.대규모 소프트웨어 프로젝트는 종종 일회성(one-off) 프로젝트이다.(이전 프로젝트로부터 교훈은 새로운 프로젝트에 전달되지 않을 수 있다
Management Activities(관리활동)
*제안서작성(프로젝트의 목표와 수행할 방법, 비용과 일정추정치를 포함 왜 특정 조직이나 팀이 프로젝트 계약을 따내야 하는지 합리화)-프로젝트 계획 수립 및 일정관리(제품을 생성하기 위한 활동, 기준, 이정표, 프로젝트산출물들을 식별하는 것과 관계, 목표를 달성하기 위한 개발을 돕기 위해 계획이 수립)- 프로젝트비용산정- 프로젝트
감시 및 검토-인력선발 및 평가-보고서작성 및 발표
*관리자는 이상적인 팀보다 다소 미흡한 상태에서 팀을 구성한다. 그 이유는?
-프로젝트 예산 때문에 경험이 부족한 임금이 싼 직원을 채용해야 할 수도 있다.
-경험이 있는 직원을 조직내나 조직외부에서 채용이 불가능 할수 있음, 이미 다른 프로젝트에 참여 하고 있을수도 있다.
-조직은 직원의 기술을 발전시키길 원하기 때문에 경험을 얻게하기 위해서 채용할 수도 있다.
Project planning
*프로젝트계획-프로젝트에 이용가능한 자원을 설정, 업무를 나누고(work break down) 일을 수행하기 위한 일정계획을 세우는 것
*이정표(milestone): task의 결과물로 나올 수 있는 것, 이정표가 나왔는지 안나왔는지 중요, 프로젝트 계획할 때 일련의 이정표 설정해야하고 이것은 소프트웨어 프로세스 활동의 식별가능한 완료지점, 정형화된 출력물 제출해야함, 짧은 완료보고서, 산출물은 고객에게 전달해 주어야 할 프로젝트 결과로 보통 명세화 혹은 설계화 같은 주요 프로젝트 단계의 끝에 고객에게 전달, 산출물들을 이정표라고 함(폭포수모델은 단계마다 이정표 있음)
*프로젝트일정관리
-관리자는 요구되는 시간,자원을 예측하고 조직화
(문제의 어려움을 추정하고 따라서 솔루션을 개발 비용도 예측해야 한다)
-생산성 사람들 수는 작업의 양에 비례하지 않음
-늦게 프로젝트에 사람을 추가하는 것은 오히려 비용을 더 많이 들게함.
-예상치 못한 일이 생기기 때문에 항상 계획의 우연성을 따라야 함
-총 업무를 각 활동별로 분리하여 각 활동을 완료하는데 소요시간을 결정(task 별로 나누기)
-병행적인 업무를 조정해 인력이 최적으로 사용될 수 있도록 일을 구성
-보통 활동은 주단위로 작성,8주~10주 넘지않게
-필요한 자원의 계획 잘 세우기, 예측잘하기
-아무문제없는 것처럼 추정하고 예상문제 극복위해 추정치 증가시키는 방법, 문제를 해결하기 위해 우발적 요소도 추정치에 포함
-병행해서 수행할 수 있게 해야한다.
*Bar chart 와 activity networks
-Bar chart: 각 활동을 책임지는 사람이 내타내고 활동의 시작시간, 끝시간을 나타냄
-activity networks: 프로젝트를 구성하느 다른 활동들 사이의 관계표현
-Gantt chart: 캘린더와 활동들의 시작일과 종료일을 나타냄, 왼쪽에서 오른쪽으로 읽으면 활동의 시작일과 종료일이 분명히 나타남, 뒤의 음영바는 완료시간 내에 융동성이 있다는 것을 강조
Software requirement(소프트웨어 요구사항)
*Requirements engineering
시스템에 의해 제공되는 서비스+운영상의 제약에
관한 기술, 요구사항은 정보를 찾거나 주문을 하고 장치를 제어하는 것과 같은 문제를 해결하는데 도움을 주는 시스템에 대한 고객의 요구 반영
이러한 서비스와 제약조건을 찾아내고 분석, 문서화, 검사하는 프로세스
*requirement: 시스템이 제공해야 할 서비스와 시스템의 제약에 대한 고수준의 추상적 문장, 시스템 기능의 상세하고 정형화된 정의로 사용
*user requirement: 시스템이 제공해야 할 서비스와 시스템의 제약에 대한 고수준의 추상적 문제, 시스템기능의 상세, 정형화된 정의로 사용
*system requirement: 시스템의 기능, 서비스, 제약조건을 상세하게 설정, 문서는 정확해야함, 구현해야 될 것을 정확히 정의, 시스템 구매자와 소프트웨어 개발자 사이 계약의 일부분
*Functional and non-Functional requirements
소프트웨어 요구사항은 이렇게 3개로 나뉘어짐
-Functional requirements: 시스템이 제공해야 할 서비스, 시스템이 특정 입력에 대해 어떻게 반응하는지, 특정상황에서 어떻게 동작하는지에 대해, 하지말아야 할 것도 명시할 때도 있음
-non-Functional requirements: 시스템에서 제공되는 서비스나 기증에 대한 제약, 시간적, 개발 프로세스와 표준에서의 제약포함, 시스템에 적용되기도함, 개별시스템특징과 서비스엔 적용안됨
-Domain requirements: 시스템의 응용 도메인에 서 생긴 요구사항, 도메인의 제약과 특징 반영, 기능적이나 비기능적요구사항 일수도있음
*Functional requirements
시스템이 해야할일 기술, 사용자 요구사항으로
표현

키워드

소프트웨어공학,   노정규,   서경대,   서경대학교,   폭포수모델,   waterfall model,   active/stand by,   primary/backup