1. 종목명: 엠파스 (066270)
2. 분석일: 2007.04.20
3. 의견: 금일(04.20) 일부 매수 완료 / 적정예상가: 35,000
4. 차트 참고 (귀찮아서 편집 생략)

소개: 인터넷 포털 서비스 업체  (코스닥 - 중형)
본사: 서울 강남구 논현2동 82-18 벤처캐슬빌딩 3층
홈피: www.empascorp.com
설립: 1996. 9.21  (구: (주)지식발전소, 계열: SK)
대표이사: 박석봉
주식담당: 02-546-4615
보통주: 10,610,710 주
주거래: 하나은행(서초)
원자재: 컨텐트, 컨텐츠, 유틸리티
주매출: Premium Service(56.2%), Solution 및 기타(주)(21.7%), Marketing Service(12.5%)
수출비중: 23.9 %

- 열린검색 효과가 미미하고 현저히 낮은 광고효과로 인해 광고주 유입효과가 낮아 외형적 성장이 제한적인 것으로 예상됨.
- 2006년 3분기 웹메일시스템 구축 사업으로 매출이 일시적으로 증가할 것으로 보이나 SI 사업 특성상 큰 폭의 수익성 개선 가능성은 낮음.
- 풍부한 유동성을 바탕으로 현금흐름상의 위험은 낮아보이며 양호한 재무안정성 유지할 듯.
- 2006.10. 0 - 최대주주변경 (에스케이커뮤니케이션즈 주식회사)

- 재무구조 개선 예상
- SK컴즈, 검색 강화
- 싸이월드+웹2.0 응용 가능성 (미래)

* 호재: 드러난 호재 없음
* 악재: 드러난 악재 없음

1. 종목명: 현대제철 (004020)
2. 분석일: 2007.04.18
3. 의견: 금일(04.18) 일부 매수 완료 / 1차 적정예상가: 47,000 ~ 49,000
4. 차트 참고 (3가지 경우의 수 가능)

소개: 국내 1위의 봉형강 업체  (KOSPI 200)
본사: 인천 동구 송현3동 1
홈피: www.hyundai-steel.com
설립: 1964. 9. 1  (구: INI스틸(주))
대표이사: 이용도
주식담당: 02-2112-9597
보통주: 84,897,919 주
우선주:     416,556 주
주거래: 신한은행(영업2부)
원자재: 철스크랩, STS HR
주매출: 봉강,형강(70.5%), 주강,sts(13.3%), 열연(10.2%)
수출비중: 23.6 %

- 건설경기 착공면적 증가 및 안전시공에 따른 철근 실질소비량 증가 등으로 상반기 매출 증가. (2006.8월 자료임)
- 국제 철강가격 인상 및 국내 실수요 증가로 3차례에 걸친 가격 인상이 단행되었으며, 생산성 향상 등으로 10%대의 영업이익률 기록.
- 호주 석탄 및 동광산 개발에 참여하는 등 해외 자원개발 사업에 참여, 대한생명, 한화건설 등의 우량 자회사 지분 소유로 자산가치 상승

- 정부의 건설경기 부양 및 태풍피해 복구, 건설사들의 착공면적 증가 등으로 봉형강류의 수요 증가에 따른 외형 성장세 전망.
- 중국의 H형강 수입으로 과열경쟁 예상되나, 미니밀 열연코일의 생산확대 및 당진공장의 B열연의 생산여건 개선으로 수익성 상승.
- 철근업체들의 M&A 구조조정에 따라 전후방 산업에 대한 가격 협상력이 증대되었으며, 철스크랩 가격이 낮아져 고수익성 전망됨.

- 세계 최초 ‘밀폐형 제철원료 처리시설’
- 친환경 / 꿈의‘그린(Green) 제철소’
- 폴워스사와 핵심설비 계약:  폴워스사는 철광석과 코크스 등 제철원료를 고로 안에 균등하게 넣어주는 설비인 노정장입장치와 고로에 불어넣을 공기를 섭씨 1100∼1200도로 가열하는 열풍로 등을 제작 공급하게 된다.
- 현재 건설업종의 호조 --> 자재 수요 증가 예상

* 호재: 드러난 호재 없음
* 악재: 드러난 악재 없음

1. 문제점의 수명주기

* 사용자 -> 제작사 문제점 보고
* 문제점 재현
* 문제 상황 격리
* 코드에서 결함을 찾고 교정
* 교정 결과물을 사용자에게 돌려줌

--> 수명주기의 조직화 필요

1. 문제점이 드러나 있는지 (소프트웨어에 결함이 존재)
2. 가장 심각한 문제점은 무엇인지 (심각도 순서대로 교정 필요)
3. 과거 문제점 사례발생 여부 (기존의 해결책 이용 가능성)

[ 대규모 디버깅 공정을 어떻게 조직화할 것인가? ]

2. 문제점 보고

* 문제점 보고 (Problem Report) == 변경요청 == 버그리포트
* 문제점 보고에 쓸데없지 않은 것만 포함시켜야 함
  --> 그러기 위해서 '유관사실'만을 판별하고, 구체적 항목으로 목록화

* 문제점 보고에 포함시켜야 할 내용 (기본원칙)

3. 문제점 관리

* 한번에 오직 한 사람만 문제점 문서를 다루어야 한다.
    - 버전 관리 시스템에서는 분리 병합
* 이전의(교정된) 문제점에 대한 내력이 사라진다.
    - 버전 관리 시스템에서는 변경 내력 유지 가능
* 규모 가변성이 없다.
    - 하나의 통합된 문서 형태로 관리가 가능해야 함.
       ---> 그러기위해서, 문제점 데이터베이스에 모든 문제점 보고들을 저장
              ex) BugZilla

4. 문제점 분류

# 각 애트리뷰트별로 문제점을 분류

* 심각도 (Severity) - '차단, 치명, 주요, 보통, 부차, 사소' 레벨이 부여
* 우선순위 (Priority) - 개발/문제해결 공정을 조절하는 핵심 기준
* 식별자 (identifier) - 특정 문제점 지칭용
* 주석 (comment) - 문제환경 정보 기입 / 해결책 논의
* 통지
   - 문제점보고시 이메일주소 첨부 --> 문제점보고 변경시 자동통지 받음

# 이상적인 제품은 심각한 문제점을 모두 고친 후에 출시 되어야 함.

5. 문제점 처리

* Unconfirmed (아직 누구도 재현해 보지 않은 상태)
* New (문제점 보고가 있어야 유효함 , 유관 사실이 포함되어 있어야 함)
* Assigned (개발자에 배정됨)
* Resolved (해소됨)
* 처리결과
    - fixed
    - Invalid (문제점이 아니거나 유관 정보가 없음)
    - Duplicate
    - WONTFIX (교정 불가)
    - WorksForme(재현 불가)
    - VERIFIED (교정 후 검증 성공)
    - Close (제품의 새 릴리즈가 만들어짐)
    - Reopen (동일 문제 발생시는, new가 아닌 reopen)

6. '문제점 추적' 관리

* 문제점 정리/보관자는?
* 문제점 보고 분류자는?
* 우선순위 설정자는?
    - 문제점 발생 가능성
    - 영향을 받는 사용자수
    - 피해 가능성
* 문제점 처리자는?
* 문제점 종결자는?
* 문제점 수명주기는?

7. '문제점 == 요구사항'

* 문제점은 개발 과정에서 사용 가능
* 요구사항이 주요 문제점
* 요구사항에 따른 중요도 선정
* 계통구조를 지원 해야 함 (세분화 지원)

8. 중복의 관리

* 최대한 많은 사실을 포함
* 중복을 찾기 위해서는 최대한 적은 사실들이 바람직
* 교정의지 없는 문제점: 개발자가 더이상 지원의사 없음 (BugZilla: Won't Fix)
    - 오래된 딱 한번 발생한 문제점
    - 오직 내부에서만 발생한 문제점

9. 문제점과 교정의 연계

* 개발자가 버전별 소스/도구를 사용가능 해야함
  --> 그래야만 개발자 PC에서 재현 가능
* 임의의 구성(형상)을 언제라도 재현할 수 있어야 함
* 소프트웨어 형상관리는 버전 관리 시스템을 이용

10. 문제점과 테스트의 연계

* 실패한 테스트와 문제점을 어떻게 동기화할 것인가?
* 테스트 결과와 문제점 보고를 분리하도록 권장
    - 테스트 결과는 자주 생성됨.
    - 테스트는 결과를 굳이 어딘가에 저장할 필요가 없음
    - 테스트 실패 시 만일 즉시 교정 가능하면 기록의 필요가 없음.
* 테스트 케이스들은 문제점 보고를 퇴물로 만든다.
* 문제점 발생시 재현 가능한 테스트 케이스를 작성