Scientific meth. (part4)
12 sept. 201212. september 2012 - lecture #4 (Computer science and engineering)
The topic for this lecture is computer science, computer engineering and how to do research in these fields. It was held by a different professor with more knowledge specific of "true" science. 5 papers were a part of today's preparations from which two of them are part of the course literature. Our main teacher will send us a mail Thursday 13th with more information about the group assignment that will take place in a few weeks. There were still students without a group.
Two important papers
- Design Research in Information Systems
- Design Science in Information Systems Research
Computing disciplines
- Computer science: Fundamental of computing.
- Software engineering: Apply fundamentals to practical problems, building complex systems.
- Information systems: People and business aspects of computing.
Is computer science really a science?
According to the first paper "Is Computer Science Science?" by Peter J. Denning, he argues that it is a science of the artificial, which means "man made" objects designed to meet certain goals. One could compare it with the social science which is studying human or animal behavior. The question depends on what you understand science itself to be. Science is a body of knowledge and a process of increasing this knowledge base. The goal of this information gathering is to get a better understanding of the world we live in by describing it and doing experiments. Computer science is not actually about computers[1]. Computers are the tools we use, but the goal is to describe processes and procedures necessary to describe how to solve problems. Wikipedia [2] gives this explanation:
"theoretical foundations of information and computation, together with practical techniques for the implementation and application of these foundations"
One "problem" of the field computer science is the lack of theories.
What is software engineering and is it engineering?
Engineering is creating cost-effective solutions to practical problems by applying scientific knowledge, often by building things (in the service of human kind).
The second paper "Prospects for an Engineering Discipline of Software" by Mary Shaw tries to compare it with engineering in different fields like civil and chemical engineering to point out there is a fundamental evolution of engineering. The conclusion is that "it is not yet a true engineering discipline but has the potential to become one"
One of the main arguments is the lack of general scientific theories and the tendency of everyone "starting from scratch" because of little sharing of "how to do things". Typically seen early in the fields history. In time, this will hopefully change. This is illustrated by the interaction between science and engineering
Interaction between science and engineering
- A new problem is discovered
- Many ad hoc solutions are generated (engineering)
- The best solutions is included in the "folklore" and believed to be the best way to solve this kind of problem
- The best solutions are documented, analysed, tested in many different scenarios
- Models and theories are developed and added to the body of knowledge of the field, "best practices". (science)
- ..back to new problems
Computing discipline methods
The most commonly used method (for thesis) is the proof-of-concept implementation. Show it is possible to solve the problem. The goal of this slide (#5) is to inform us there are many other approaches. The slide is a copy of page 16 (table 1c) of the third paper "A Unified Classification System for Research in the Computing Disciplines" by Iris Vessey.
- Experimentation in field or lab doing simulations on how the prototype behaves (technically)
- Observational case, survey or field studies (human aspect)
- Theory building, trying to compare different solutions, find patterns and describe them in terms of frameworks or mathematical models.
When trying to determine what method to use for your own mater thesis, look at what other researchers tend to choose in your field.
Good research
A repetition from the first lecture:
- Based on others work (build on the body of knowledge, do not start from scratch)
- Can be tested by others (get the same results you did, requires detailed explanation of what was done)
- Can be generalized from (if it only applied to one specific problem, no one else could benefit from it)
- Logical and theory-based (logical yes, theory-based when applicable)
- Generates new questions (where to go from here)
Design Science
The information systems (third computing discipline) research framework is presented: "Design Science in Information Systems Research" by Alan R. Hevner. The environment (people, organizations and technology) have business needs the research has to find answers to, using the knowledge base (foundations and methodology). A process of development is performed, and by evaluating (analytically, study, simulation) refining the artifact in development. The result of evaluating gives addition to new knowledge and the environment more technology when a good enough solution is found. It is an iterative process starting with awareness of a problem, suggesting solutions, develop prototypes, test prototypes and at any stage go back if result is not satisfying. It is important to distinguish between routine design and design research. Routine design is all about utilizing best practices to build solutions for known problems, while design research is about finding solutions to unsolved problems.
7 guidelines
- Innovative purposeful artifact
- A specified important and relevant problem domain
- Thoroughly evaluated and has "style"
- Novelty: Solving either an unsolved problem or solving a known one more efficiently
- Rigorously defined and consistent, why does it work
- The process: Iterative search process generating alternative designs, testing them and getting closer to an optimal solution (and expanding the understanding of the problem domain)
- Communicated efficiently to technical and management-oriented audiences
Outcome of research
The goal is more understanding, and the artifact (like a prototype) is only valuable if it can support a more general method or theory for understanding that same artifact. Do not use to much resources implementing a fully functional commercial product in your thesis (80% of the work going prototype to fully functioning program).
It is important to also describe solutions that did not work out, and the language/format is important to communicate your work so that others can build on it
[1] MIT Introduction to LISP (1986)
[2] Computer Science