Shin, SooJung Based on Ron’s book

Presentation on theme: "Shin, SooJung Based on Ron’s book"— Presentation transcript:

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

2 Programming Management Control
Chapter 5 Programming Management Control

3 (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

4 (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 계획의 본질과 정도가 개발 또는 구입될 여러 소프트웨어에 대해 적절한지 평가 계획작업이 얼마나 잘 이루어지는지 평가- 정확한 자원 요구 예측이 이루어지는지 등

5 (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 절차가 신뢰성있게 동작하는지에 대한 증거확보

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

7 (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를 가져야 함, 모듈의 길이는 문장으로 한정) 감사자는 프로그래머가 구조화된 프로그래밍 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

8 (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

9 (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

10 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

11 (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 프로그램의 사용자에 의해 이루어지는 테스트 프로그램이 요구조건과 일반적인 성능요구사항을 만족시키는지 결정하는데 사용됨 다른 테스트는 테스트 환경에서 이루어지지만 설치테스트는 운영환경에서 수행됨

12 (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가 추적되고 변경기록이 유지됨.

13 (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

14 (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

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

16 (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

17 (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를 평가하도록 함