Shin, SooJung Based on Ron’s book

Slides:



Advertisements
Similar presentations
2016 년도 1 학기 정보보호관리체계 (ISMS) 인증 이 강 신
Advertisements

Product Lifecycle Management © 2003 IBM Corporation PLM Definition Product Lifecycle Management.
설계사를 위한 Mobile 영업지원 System 설계사를 위한 Mobile 영업 지원 System 설계사를 위한 Mobile 영업 지원 System 1 Agenda Ⅰ. Mobile Project 추진 목적 Ⅱ. Mobile 환경 분석 Ⅲ.
소프트웨어 프로세스. 1 내용  소프트웨어 프로세스  생명주기의 의미  생명주기 모델 –Waterfall Model –prototyping model –Spiral Model –Iteration Model.
SW Testing Foundation 교육 1 일 기술 2G 배경호. Test in Life Cycle Request STATIC DYNAMIC Design Code Compo nent Integra tion System Accept ance.
Bring efficiency and empowerment to your business
목 차 ○ 변화의 필요성 – 기업생존 ○ 설비 보수 기술 선진화의 필요성 ○ 설비 보수 기술 선진화 추진방법.
멀티미디어의 개념 멀티미디어 CAI 교육용 멀티미디어 저작도구
목 차 Ⅰ. 병원경영의 환경분석 Ⅱ. 병원경영의 전략유형 Ⅲ. 병원경영의 최신기법 Ⅳ. 대응전략 1.
MrDataBld 2.x 제품 소개 2007.
품질개선활동 본 강의 자료는 2003학년도 교육인적자원부·한국교육학술정보원의 지원에 의하여 개발된 것임.
Capstone Design - Concept & Management
Value-driven commitment for CUSTOMER SUCCESS
Chapter 2 정보시스템 아키텍처 (IS Architecture)
생산정보화 시스템 개발 방법론(PSDM) 및 감리 수감시 고려 사항 소개 중소기업기술정보진흥원.
교육과정개발.
6σ 연계 TPM 추진 안내서 TPM컨설턴트/공학박사/품질기술사 권오운 6σ 연계 TPM 추진 안내서 전체편 6 σ T P M
하이닉스반도체「핵심인재 관리 시스템」 사례
ERP(Enterprise Resource Planning)
1. 활동 목적의 비교 Six Sigma의 목적은 산포를 줄여 제품 및 서비스의 결과가 완벽하게 고객의 요구에 부응하는 것임
원가절감을 위한 구매전략 July 구매기획팀.
전자정부 서비스 운영을 위한 SLA 적용 방안 남기찬 교수 서강대학교 아웃소싱연구센터 (
프로젝트 계획과 관리 1.
소프트웨어 공학 (Software Engineering)
교육평가 및 효과측정 시스템 POSCO 인재개발원 홍 성 근.
ISO / KS A 9001:2000 전환을 위한 지침.
1. 정보보호 관리체계(ISMS) 이해.
알기쉬운 DMAIC/DFSS Concept 6.
테 스 트 (Testing) - Software Engineering -.
12. 데이터베이스 설계.
소프트웨어 공학 (Software Engineering)
최 연식 ( ) EDMS를 활용한 EKP 구축 전략 2002년 09월 04일 성우시스템 주식회사 김 정훈 ( ) 최 연식 ( )
ISO 실무교육 교재.
Quality Management Construction Management
연구소의 R&D 관리 - 과제 선정/개발/상품화 -
우수제조시설 개론-GMP.
ISO 9001:2000 프로세스 접근방법의 이해와 적용 베스트경영컨설팅(BMC).
Program Management - Program and Project Definition -
S18/S49 The VISUAL Quality System
ISO/TS 품질경영시스템
BPR 추진전략 및 사례 1.
전사 기업관리 사이클 최적화를 통한 경영혁신과 전략적 수행방안
발표자 : 홍익대학교 소프트웨어 공학 연구실 변은영 지도교수 : 김영철
소프트웨어 소프트웨어란? 소프트웨어의 특성 프로그램과 프로그램의 개발, 운용, 유지보수에 필요한 관련 정보 일체
프로젝트 관리 Project Management
사내 직무교육체계개발 프로젝트 Kick-off(안)
목표원가 달성을 통한 기업 이익 창출 전략.
계 획 입력 제품 설계 및 개발 공정 설계 및 개발 제품 및 공정 유효성 확인 양 산 피드백 , 평가 및 시정조치
강의 소개, 자료구조의 개념, SW 개발과 자료구조
소프트웨어 공학 (Software Engineering)
ERP 시스템의 구축 ERP 시스템의 구축 기업이 ERP 시스템의 도입을 검토하는 단계에서부터 실제 업무에 적용하고 사후관리에 들어가는 단계에 이르기까지 시스템을 효과적으로 사용하기 위해 필요한 모든 활동.
생산운영관리 입문 CHAPTER01 (Introduction to Operations Management)
Cpt.4 제품과 서비스의 설계 Product and Service Design 생산운영관리.
ISO 9004 개 요.
Introduction to Computers
시스템 분석 및 설계 글로컬 IT 학과 김정기.
소프트웨어 형상관리: 목차 변경 및 형상관리의 기초 개념 형상항목 확인 및 버전관리 변경관리 감사 및 감사보고 99_11
13.1 정보시스템의 개요 13.2 정보시스템의 개발 13.3 시스템 검사 13.4 시스템 문서화
ISO 9004 개 요.
성공적인 웹사이트 구축 (2) 변화 발전하는 Site의 미래를 예측 반영해야 함.
Signature, Strong Typing
Signature, Strong Typing
Signature, Strong Typing
수익 극대화를 위한 전략적 원가경영2.
Life Cycle Cost Analysis Process 충북대학교 구조시스템공학과 시스템공학연구실
1. 데이터베이스 환경.
6장 정보분류 신수정.
목 표 관 리.
프로젝트 실행 오류와 해결.
우수제조시설 개론-GMP.
Presentation transcript:

Shin, SooJung Based on Ron’s book Information Systems Control & Audit(4) Shin, SooJung Based on Ron’s book

Programming Management Control Chapter 5 Programming Management Control

(1) The program development life cycle High-quality program function: perfectly & completely High quality UI Work efficiently Well-designed and documented Easy to maintain Robust under abnormal conditions (1) Feasibility study (2) Information analysis (1) Planning (2) Design Control (3) System design (4) Program development (3) Coding (5) Procedure &forms development (4) Testing (5) Operation & Maintenance (6) Acceptance testing (7) conversion (8) Operation & Maintenance

(1) The program development life cycle (1) Planning Major task: to estimate the amount of resources required for SW development, acquisition, and implementation Cost-estimation techniques Algorithm models Expert judgement Analogy Top-down estimation Bottom-up estimation Other decision Design approach Implementation approach Integration & testing approach Project Team Organization Auditor 계획의 본질과 정도가 개발 또는 구입될 여러 소프트웨어에 대해 적절한지 평가 계획작업이 얼마나 잘 이루어지는지 평가- 정확한 자원 요구 예측이 이루어지는지 등

(1) The program development life cycle (2) Control Purposes: 여러 생명주기 단계의 작업 진행이 계획대로 이루어지는가를 모니터 통제가 소프트웨어의 신뢰, 정확, 완전함을 보장할 수 있도록 수행되어야 함 Monitoring WBS(work breakdown structure): 세부 task정의, 각 task에 대한 자원할당 Gantt chart: 작업의 시작과 끝, 진도 PERT: 수행될 작업, 작업간의 연관성, 각 작업에 대한 자원할당 COntrol Review procedures: 각 단계별 마일스톤마다 수행 Access control: manual: 문서에 접근제한, 매너저의 허락없이 프로그래머는 프로그램문서에 접근제한됨 Automated: program library SW-접근과 변경에 대한 감사증적 Auditor control의 본질과 정도가 개발 또는 구입될 여러 소프트웨어에 대해 적절한지 평가 Control 절차가 신뢰성있게 동작하는지에 대한 증거확보

(1) The program development life cycle (3) Design Purposes: 시스템 개발의 정보처리 설계단계에서 모아진 요구사항들을 충족시키는 프로그램의 구조와 운영을 정의함. Auditor 어떤 형태의 설계의 시스템적인 접근방법을 사용했는가? 인터뷰, 관찰, 문서검토 등을 통해서 사용된 설계 실행의 증거를 확보함

(1) The program development life cycle (4) Coding Purposes: 설계를 implement하기 위해 source code를 작성함. (1) Modular implementation & integration strategy Top-down: 상위레벨이 먼저 coded, tested, integrated 됨. Bottom-up: 하위레벨이 먼저 coded, tested, integrated 됨. Threads: 중요한 function이 먼저 implemented됨 * 감사자는 어떠한 방식이 선택되었는지에 대해 인터뷰, 문서화 등을 통해 파악해야 함. (2) Coding strategy structured programming convention (SEQUENCE, IF-THEN-ELSE, DO-WHILE 메커니즘, 프로그램내의 각 모듈은 하나의 ENTRY와 하나의 EXIT를 가져야 함, 모듈의 길이는 50-100문장으로 한정) 감사자는 프로그래머가 구조화된 프로그래밍 convention을 따르는지, 프로그래밍을 위해 자동화된 tool을 활용하는지 파악해야 함. (3) Documentation strategy Provide Charts that show the overall makeup of the program in terms of its major components and the relationships among these components Use comment lines: program header, module comments, line comments Use names for variables, constants, types, paragraphs, modules, and sections that are meaningful to the readers of program source code Layout the source code Group related types of code together

(1) The program development life cycle (5) Testing Purposes: 개발되거나 획득된 프로그램이 정의된 요구사항을 성취하는지 평가됨. Testing steps Select the boundaries of the test Determine the goal of the test Choose the testing approach: ex) black-box, white-box Develop the test: test data, scenarios, expected result Conduct the test Evaluate the test results Document the test

(1) The program development life cycle (5) Testing Unit Testing - individual modules within a program Static Analysis tests: 코드의 직접적인 검사를 통한 모듈의 품질 평가 Dynamic Analysis tests: 모듈의 테스트가 기계에서 수행됨 Desk checking -프로그래머가 검토 Black-box test -모듈의 내부로직은 검사되지 않고, 테스트 케이스가 모듈의 요구스펙에 근거하여 설계됨 Structured walk-throughs -다른 독립적인 프로그래머들의 그룹이 검토 Test data based on Requirement spec. Output Design & code inspection -특수한 검토그룹이 검토, 공식적인 체크리스트를 사용하고 결과를 문서화함. 공식화검토 White-box test -테스트 케이스가 모듈의 내부로직이 검사된후 설계됨. 테스트 케이스가 프로그램내의 여러 실행 결로를 거침 Test data based on Internal working of program Output

a whole-of-program test -small to moderate-size system (1) The program development life cycle (5) Testing Integration Testing evaluate groups of program modules to determine - whether their interfaces are defective - overall, whether they fail to meet their requirements specs. Big-bag testing a whole-of-program test -small to moderate-size system Incremental testing -subset of modules are assembled iteratively and tested until the total program is finally in place Top-down test : top-level module을 먼저 테스트하고 lower-level module은 dummy module인 ‘stubs’를 통해 시뮬레이트함 Bottom-up test: bottom-level module을 먼저 테스트하고 higherr-level module은 dummy module인 ‘driver’를 통해 시뮬레이트함 Hybrid test: 혼합, sandwich testing

(1) The program development life cycle (5) Testing Whole-of-program Testing focus on the program, in total, to determine - whether it meets its requirement * 감사자는 이 테스트가 모든 중요한 프로그램에 대해 잘 수행되었는지, 이러한 테스트가 잘 설계되고 실행되었는지를 검토해야 함. 단위나 통합테스트는 항상 수행되지 않을 수 있지만, 이 테스트는 반드시 수행되어야 함. Function Test Performance Test 통합된 프로그램이 어떤 성능조건을 만족시키는지 결정하는데 사용됨 예) fault tolerance, reliability under load, maintenance of security, response time adequacy, throughput rate adequacy -프로그래머에 의한 테스트 통합된 프로그램이 그 요구조건을 만족시키는지 결정하는데 사용됨 -프로그래머에 의한 테스트 Acceptance Test Installation Test 프로그램의 사용자에 의해 이루어지는 테스트 프로그램이 요구조건과 일반적인 성능요구사항을 만족시키는지 결정하는데 사용됨 다른 테스트는 테스트 환경에서 이루어지지만 설치테스트는 운영환경에서 수행됨

(6) Operation & Maintenance (1) The program development life cycle (6) Operation & Maintenance 운영: 감사의 관점에서 프로그램의 성능이 적절하게 모니터 되고 있는지 확인 유지보수:감사의 관점에서 유지보수의 절차가 중요함. 유지보수에 적절한 통제가 없으면 부정확한, 허가되지 않은, 완성되지 않은 코드가 프러덕션 프로그램에 들어갈 수 있음. 그러므로 프로덕션 프로그램에 대한 변경이 공식적으로 승인될 수 있는 것을 보장하는 통제가 존재해야 함. In Configuration management system: maintenance requests must be documented formally and approved by a change control group. Maintenance process가 추적되고 변경기록이 유지됨.

(2) Organizing the programming team Level of uncertainty Level of complexity Size of task Time constraints Chief programmer team Low-moderate Low-moderate moderate Tight Moderate-high Moderate-high Moderate Loose Adaptive team Controlled decentralized team Large Moderate Moderate-high Moderate-high

(1) Chief programmer Team (2) Organizing the programming team (1) Chief programmer Team Designed to reduce the need for information processing among the team members and to increase their capacities to process information Chief programmer Responsible for the system. Designing, coding, testing.. Assigning work Support programmer Support programmer Librarian Backup programmer A senior Programmer for full supporting chief Provide specialist support Assist in coding and testing lower-level modules Maintain the Program library

(2) Organizing the programming team (2) Adaptive Team 권위, 계층이 없음 작업은 팀 단위로 할당됨 공식적인 라이브라리안이 없음 중앙집중팀에 비해서 많은 의사소통이 필요함: 시간이 짧은 프로젝트에는 불리 실패가 팀 전체에 전파될 수 있음 서로의 일치성으로 인해 혁신적인 프로그래밍을 방해할 수도 있음 Programmer (temporary leader) Programmer Programmer Programmer Programmer

(3) Controlled-decentralized Team (2) Organizing the programming team (3) Controlled-decentralized Team 프로그램 작업이 대형이고 어려울 경우 사용 프로그램 작업이 잘 할당되지 않으면 작동하지 않음 Tight한 기한을 맞추어야 하는 프로젝트에 적합하지 않음. PL Senior Programmer Senior Programmer Senior Programmer Junior Programmer Junior Programmer Junior Programmer Junior Programmer Junior Programmer Junior Programmer

(3) Managing the system programming group Application programmer: develop & maintain application System programmer: develop & maintain system SW- OS, DBMS, 통신프로그램 등 Control problem 시스템 소프트웨어의 에러는 그것을 사용하는 모든 응용시스템에 영향을 줌 시스템 소프트웨어는 특권권한으로 수행되어 표준적인 control을 돌아가는 경우가 많음 이러한 특권권한은 남용될 가능성이 있음 시스템 프로그래머를 통제하는 것은 어려움 위기상황에서 작동할 수 있는 작업은 기존에 수립된 통제절차를 무시할 수 있음 Control measures 높은 품질의 SP를 고용함. 최대한 임무의 분리를 수행함(예) 시스템프로그램의 설계,코딩 과 테스트의 분리) 방법론과 성능 표준을 개발하고 문서화함. :자신의 방법을 개발하지 않도록 함. SP의 권한을 제한함: 프로덕션 시간동안 tinker가 되도록 허가받아서는 안됨, 특수한 테스트 기간동안에만 특권권한으로 수행되는 시스템 소프트웨어를 개발하고 테스트 해야함. 프로덕션 기간동안은 SP와 AP는 동일한 권한유지 SP활동에 대한 수동,자동로그 유지: 독립적인 로그가 유지되어야 하며 검토되어야 함 SP작업을 평가하기 위해 외부 컨설턴트를 고용함 AP로 하여금 주기적으로 SP를 평가하도록 함