소프트웨어공학 컨퍼런스 일정 지도
Upcoming Software Engineering Conference Map
가보고 싶은 도시를 지도에서 볼수도 있고,
지도에 빨간색으로 표시된 것은 논문제출 기한이 자닌 것을 표시합니다.
지도에 초록색은 제출기한이 남은 곳입니다.
또 기본적으로 submit 기한과 위치, 날짜등을 보실 수 있습니다.
가끔 참고 하실만 합니다~ ^^
'Software Engneering.....' 카테고리의 다른 글
ISO 9126 Standard - 이식성 (0) | 2009.06.04 |
---|---|
모바일 소프트웨어의 성능 평가 (0) | 2009.04.17 |
꼭 읽어보야 할 위키피디아 - ISO 9126 (0) | 2009.04.09 |
프로그래머의 심금을 울리는 Let's it be?
Let's li be를 개사하여 만든 영상인데...
왠지 마음이 짠해지네여....
가사를 좀 찾아봤더니...
When I find my code in tons of trouble
friends and colleagues come to me,
speaking words of wisdom..
.."Write in C"..
내가 나의 코드에서 엄청난 오류를 찾았을때
친구들과 대학동기들이 나에게 와서 속삭여~
"C 로 짜~"
And as the deadline fast approaches,
and bugs are all that I can see
Somewhere someone whispers:
"Write in C"
마감시간이 미친드시 다가오고 있고,
버그들이 미친드시 생기면~
어디에선가 누군가가 속삭여~
"C 로 짜~"
Write in C, Write in C~
Write in C, oh~ Write in C~
LOGO's dead and burried,
Write in C~
C 로 짜, C 로 짜~
C 로 짜, 오~ C 로 짜~~
로고는 이미 죽었고, 묻혔어~
C 로 짜~~
I used to write a lot of FORTRAN
For science it worked flawlessly~
Try using it for Graphics!
Write in C!
나는 '포트란'을 완전많이 쓰곤했어~
그건 과학에선 흠잡을데가 없었어~
그것을 그래픽을 만들때 쓰도록 해봐!
C 로 짜!
And if you've just spent nearly 30 hours
debugging some assembly~
Soon you will be glad to
write in C~
그리고 만약 니가 어셈블리 디버깅을
거의 30시간을 써버렸다면~
그걸 C 로 짠다면 너는 곧 즐거워질꺼야~
Write in C, Write in C~
Write in C~ oh~ Write in C~
BASIC's not the answer,
Write in C~
C 로 짜, C 로 짜~
C 로 짜~ 오~~ C 로짜~
'베이직'은 답이 아냐,
C 로 짜~
Write in C, Write in C~
Write in C~ oh~ Write in C~
PASCAL won't quite cut it,
Write in C!!~~
C 로 짜, C 로 짜~
C 로 짜, 오~ C 로 짜~
'파스칼'은그걸 완전히 없앨수 없어~
C 로 짜!!~~
'일상.......' 카테고리의 다른 글
블로그에 PPT파일 보이게 만들기... (0) | 2009.04.17 |
---|---|
090406 놀러와의 김재동의 말.... (0) | 2009.04.09 |
구글 애드센스 (0) | 2009.04.02 |
티스토리 사이드바에 위젯달기~ ㅋㅋㅋ (0) | 2009.04.01 |
10,000시간 법칙에 대한 오해를 보고... (0) | 2009.03.31 |
꼭 읽어보야 할 위키피디아 - ISO 9126
연구실에 들어와 소프트웨어 공학을 공부한지 얼마 되진 않았지만...
그래도 너무 심했네요... ㅠㅠ
꼭 한번은 읽어봐야 할것 같아서... 위키피디아에서 퍼왔습니다.
ISO 9126 is an international standard for the evaluation of software quality. The fundamental objective of this standard is to address some of the well known human biases that can adversely effect the delivery and perception of a software development project. These biases include changing priorities after the start of a project or not having any clear definitions of "success". By clarifying, then agreeing on the project priorities and subsequently converting abstract priorities (compliance) to measurable values (output data can be validated against schema X with zero intervention), ISO 9126 tries to develop a common understanding of the project's objectives and goals.
The standard is divided into four parts:
- quality model
- external metrics
- internal metrics
- quality in use metrics.
Contents[hide] |
[edit] Quality Model
The quality model established in the first part of the standard, ISO 9126-1, classifies software quality in a structured set of characteristics and sub-characteristics as follows:
- Functionality - A set of attributes that bear on the
existence of a set of functions and their specified properties. The
functions are those that satisfy stated or implied needs.
- Suitability
- Accuracy
- Interoperability
- Compliance
- Security
- Reliability - A
set of attributes that bear on the capability of software to maintain
its level of performance under stated conditions for a stated period of
time.
- Maturity
- Recoverability
- Fault Tolerance
- Usability - A
set of attributes that bear on the effort needed for use, and on the
individual assessment of such use, by a stated or implied set of users.
- Learnability
- Understandability
- Operability
- Efficiency - A
set of attributes that bear on the relationship between the level of
performance of the software and the amount of resources used, under
stated conditions.
- Time Behaviour
- Resource Behaviour
- Maintainability - A set of attributes that bear on the effort needed to make specified modifications.
- Stability
- Analyzability
- Changeability
- Testability
- Portability - A set of attributes that bear on the ability of software to be transferred from one environment to another.
- Installability
- Replaceability
- Adaptability
- Conformance (similar to compliance, above, but here related specifically to portability, e.g. conformance to a particular database standard)
Each quality sub-characteristic (e.g. adaptability) is further divided into attributes. An attribute is an entity which can be verified or measured in the software product. Attributes are not defined in the standard, as they vary between different software products.
Software product is defined in a broad sense: it encompasses executables, source code, architecture descriptions, and so on. As a result, the notion of user extends to operators as well as to programmers, which are users of components as software libraries.
The standard provides a framework for organizations to define a quality model for a software product. On doing so, however, it leaves up to each organization the task of specifying precisely its own model. This may be done, for example, by specifying target values for quality metrics which evaluates the degree of presence of quality attributes.
[edit] Internal Metrics
Internal metrics are those which do not rely on software execution (static measures).
[edit] External Metrics
External metrics are applicable to running software.
[edit] Quality in Use Metrics
Quality in use metrics are only available when the final product is used in real conditions.
Ideally, the internal quality determines the external quality and external quality determines quality in use.
This standard stems from the model established in 1977 by McCall and his colleagues, who proposed a model to specify software quality. The McCall quality model is organized around three types of Quality Characteristics:
- Factors (To specify): They describe the external view of the software, as viewed by the users.
- Criteria (To build): They describe the internal view of the software, as seen by the developer.
- Metrics (To control): They are defined and used to provide a scale and method for measurement.
ISO 9126 distinguishes between a defect and a nonconformity, a defect being The nonfulfilment of intended usage requirements, whereas a nonconformity is The nonfulfilment of specified requirements. A similar distinction is made between validation and verification, known as V&V in the testing trade.
[edit] Used By
SQuaRE which is a tailored view for COTS software.
[edit] See also
'Software Engneering.....' 카테고리의 다른 글
ISO 9126 Standard - 이식성 (0) | 2009.06.04 |
---|---|
모바일 소프트웨어의 성능 평가 (0) | 2009.04.17 |
소프트웨어공학 컨퍼런스 일정 지도 (0) | 2009.04.11 |