Archive for the 'Software Engineering' Category

Object-Oriented Methods and Processes

July 24, 2006

Henderson-Sellers, B. 2000, “Object-oriented methods and processes,”Software Methods and Tools, 2000. SMT 2000. Proceedings. International Conference on, pp.7-12.

Quality of process can contribute to quality of product.

‘훌륭한 프로세스를 갖추고 있는 회사에서 개발된 소프트웨어는 우수한 품질을 가지고 있을 것이다’ 라고 우리는 당근 믿는다. 거기에 밑바탕을 두고 OO/CBD 프로세스를 하나의 메타모델에서 가져오는 게 OPEN 프레임워크다. 하지만 이걸 할려면 많은 자원이 필요한 것 같다. 훌륭한 인적 자원들, 시간, 비용등…
컴팩트한 프로세스를 찾기란 쉽지않다.

Design Phase Analysis of Software Qualities Using Aspect-Oriented

July 18, 2006

Park, D., Kang, S. and Lee, J. 2006, ‘Design Phase Analysis of Software Qualities Using Aspect-Oriented Programming’, Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, 2006. SNPD 2006. Seventh ACIS International Conference on, pp. 29-34, 19-20 June 2006.

In our method, quality aspects remain separate from functionality aspect in the design model and the implementation code for simulation is automatically obtained by injecting quality requirements into the skeleton code generated from the design level functionality model.

Even though they say their method reduce some implementation and maintenance cost, it seems to me it requires another workload such as knowledge of AspectJ.
However, the seperation of between Funtional aspect and quality aspect is interesting.

우연히 발견한 글이다. 한국에서 쓰여진 것만으로도 내겐 흥미로운 일이다… 나도 언젠가 내 글이 컨퍼런스에 발표될 날이 있겠지…

Is Software Quality Visible in the code?

July 18, 2006

Lauesen, S and Younessi, H, 1998, ‘Is Software Quality Visible in the Code?’, IEEE Software, vol. 14, no. 4, pp. 69-73.

many defects cannot be found through analysis because they reflect tacit or undesirable requirements or can be observed only when the product is being used. Detecting such defects is the purpose of good acceptance testing, and it cannot be replaced with code analysis, no matter how sophisticated.

Tools 1

July 6, 2006

CodeSurfer – a mainternance, understanding, and inspection tool.
코드를 서핑하는 툴… 아.. 서핑하고 싶어라..
Trial 프로그램 없음 T.T
코드inspection 툴이고 디펜던시 그래프등 많은 기능이 있음.
좋은 툴인 건 확실함.

참고.
Dependence Graphs and Program Slicing

Software Testing

July 5, 2006

Freeman, H., 2002, ‘Software Testing’, IEEE Instrumentation & Measurement Magazine, vol. 5, no. 3, pp. 48-50.

When a tester knows what type of testing is needed, it greatly improves the test results and ultimately decreases the number of defects.

Glass Box Testing(Structual testing, White/Clear Box testing)

It relies on the internal knowledge of the system as a method of testing

Static techniques

  • Statement coverage testing
  • Branch coverage testing
  • Path coverage testing
  • All definition use path coverage testing
  • 히든 코드에 있는 모든 에러를 다 발견 할 수 있는 장점이 있지만, 비용이 비싼 단점이 있다.

    Black Box Testing(Behavioral, functional, closed/opaque box testing)
    이 테스트는 시스템 기능에 중점을 두고 기능 요구사항을 테스트 한다. 코드에 대한 지식보다 요구사항에 대한 지식이 요구된다.

    System Testing
    이 테스트는 모든 시스템 요구사항을 만족하는지 테스트 한다. verification process . acceptance testing is a kind of verification testing performed by end users. Regression, load, and stress testing are performed.

    Test Team
    Experienced Tester, Analyst, User, System Designer, Configuration Management Analyst

    Developing Scientific Applications Using Eclipse

    July 4, 2006

    Watson, G.R. and DeBardeleben, N.A., 2006, ‘Developing Scientific Applications Using Eclipse’, Computing in Science & Engineering, vol. 8, no. 4, pp. 50-61.

    윈도우에서 이클립스를 사용할려면 우선 이클립스를 설치한 후에, 따로 컴파일러(MinGW, MSYS)를 설치해 줘야 한다. 설치한 후에 환경변수에도 패스를 걸어줘야 하고…그러고 나서 이 PTP 플러그인을 설치하면 병렬컴퓨팅을 개발할 수 있다. 디버거도 포함되어 있다. 좋은 플러그인같은데 설치만 간단하면 이것도 물론 윈도우 버전은 지원하지 않는다. 자바툴이랑 오픈 소스 툴들은 리눅스 친화적이다. 지금 윈도우 비스타 쓰고 있는데, 여기서 과연 오픈 소스 툴들이 돌아갈 지 궁금하다. 리눅스에서 한번 설치해 봐야 할 것 같다…

    참고.
    Parallel Tools Platform
    MinGW

    The Past, Present, and Future of Software Architecture

    July 3, 2006

    Kruchten, P., Obbink, H. and Stafford, J., 2006, ‘The Past, Present, and Future of Software Architecture’, IEEE Software, vol. 23, no. 2, pp. 22-30.

    Software architecture captures and preserves designers’intentions about system structure and behavior, thereby providing a defense against design decay as a system ages.
    we’re far from having a consensus on a satisfying, short, crisp answer to this simple question—no widely accepted definition exists.

    아직 정의도 내려지지 않았는데, 벌써 architect 라고 하는 사람들도 있구, 그 과정을 가르치는 곳도 있다.
    Koala, UML 정도가 현재 …
    UML 로 시스템 아키텍쳐를? Is it enough?
    Some papers are good.

    Software architecture will be recognized as a key foundation to agile software development, despite the fact that it’s ignored or even despised by the most ardent “agilistas,” who have nicknamed it BUFD (big up-front design)

    결국 애자일도 Software Architecture 를 그리게 될 것이다. 이게 Documenting 이랑 관계가 있지 싶다.

    참고.
    SEI’s architecture practice

    Eclipse Becomes the Dominant Java IDE

    July 2, 2006

    Geer, D., 2005, ‘Eclipse Becomes the Dominant Java IDE’, IEEE Computer, vol. 38, no. 7, pp. 16-18

    “Anyone cna write plug-ins for Eclipse and have them work directly with any other plug-ins for the platform

    Eclipse 가 대세로군. 플러그인을 개발자가 스스로 만들어서 쓸 수 있다는 건데…
    현재까지는 잘 나가고 있는 것 같은데. 벤더들도 support 하는 것 같구…
    다른 툴들하고 호환성도 가져가는 것 같구…
    언제까지 갈련가… 누가 하나 Visual studio 같은 자바 툴 만들면 그쪽으로 넘어가지 않을까??
    if MS 처럼 Support를 한다면…

    참고.
    Eclipse Foundation

    Working with Unix Tools

    June 29, 2006

    Spinellis, D., 2005, ‘Working with Unix Tools’, IEEE Software, vol. 22, no. 6, pp. 9-11

    find src -name ‘*.java’ -print |
    xargs fgrep -c .substring |
    sort -t: -rn -k2 |
    head -10

    Command line tools do magic.

    What Is Software Testing? And Why Is It So Hard?

    June 29, 2006

    Whittaker, J.A., 2000, ‘What Is Software Testing? And Why Is It So Hard?’, IEEE Software, vol. 17, no. 1, pp. 70-79

    For example, to check for structural completeness, testers might ask these questions:
    Have I tested for common programming errors?
    Have I exercised all of the source code?
    Have I forced all the internal data to be initialized and used?
    Have I found all seeded errors?

    To check for functional completeness, testers might ask these questions:
    Have I thought through the ways in which the software can fail and selected tests that show it doesn’t?
    Have I applied all the inputs?
    Have I completely explored the state space of the software?
    Have I run all the scenarios that I expect a user to execute?

    프로그램 소스코드를 testable 하게 개발하는 것도 쉽지는 않겠지??

    참고.
    Roland Untch’s Storm Site
    Bret Pettichord’s Software Testing Hotlist
    Brian Marick’s Testing Foundations