Elements Of Research

Elements of Research Theoretical Framework A theoretical framework is a collection of interrelated concepts, like a theory but not necessarily so well worked-out. A theoretical framework guides your research, determining what things you will measure, and what statistical relationships you will look for. Theoretical frameworks are obviously critical in deductive, theory-testing sorts of studies (see Kinds of Research for more information). In those kinds of studies, the theoretical framework must be very specific and well-thought out. Surprisingly, theoretical frameworks are also important in exploratory studies, where you really don't know much about what is going on, and are trying to learn more. There are two reasons why theoretical frameworks are important here. First, no matter how little you think you know about a topic, and how unbiased you think you are, it is impossible for a human being not to have preconceived notions, even if they are of a very general nature. For example, some people fundamentally believe that people are basically lazy and untrustworthy, and you have keep your wits about you to avoid being conned. These fundamental beliefs about human nature affect how you look things when doing personnel research. In this sense, you are always being guided by a theoretical framework, but you don't know it. Not knowing what your real framework is can be a problem. The framework tends to guide what you notice in an organization, and what you don't notice. In other words, you don't even notice things that don't fit your framework! We can never completely get around this problem, but we can reduce the problem considerably by simply making our implicit framework explicit. Once it is explicit, we can deliberately consider other frameworks, and try to see the organizational situation through different lenses.

Cases and Variables Cases are objects whose behavior or characteristics we study. Usually, the cases are persons. But they can also be groups, departments, organizations, etc. They can also be more esoteric things like events (e.g., meetings), utterances, pairs of people, etc. Variables are characteristics of cases. They are attributes. Qualities of the cases that we measure or record. For example, if the cases are persons, the variables could be sex, age, height, weight, feeling of empowerment, math ability, etc. Variables are called what they are because it is assumed that the cases will vary in their scores on these attributes. For

example, if the variable is age, we obviously recognize that people can be different ages. Of course, sometimes, for a given sample of people, there might not be any variation on some attribute. For example, the variable 'number of children' might be zero for all members of this class. It's still a variable, though, because in principle it could have variation. In any particular study, variables can play different roles. Two key roles are independent variables and dependent variables. Usually there is only one dependent variable, and it is the outcome variable, the one you are trying to predict. Variation in the dependent variable is what you are trying to explain. For example, if we do a study to determine why some people are more satisfied in their jobs than others, job satisfaction is the dependent variable. The independent variables, also known as the predictor or explanatory variables, are the factors that you think explain variation in the dependent variable. In other words, these are the causes. For example, you may think that people are more satisfied with their jobs if they are given a lot of freedom to do what they want, and if they are well-paid. So 'job freedom' and 'salary' are the independent variables, and 'job satisfaction' is the dependent variable. This is diagrammed as follows:

(yes, I know. It looks like the Enterprise) There are actually two other kinds of variables, which are basically independent variables, but work a little differently. These are moderator and intervening variables. A moderator variable is one that modifies the relationship between two other variables. For example, suppose that the cases are whole organizations, and you believe that diversity in the organization can help make them more profitable (because diversity leads to fresh outlooks on old problems), but only if managers are specially trained in diversity management (otherwise all that diversity causes conflicts and miscommunication). Here, diversity is clearly an independent variable, and profitability is clearly a dependent variable. But what is diversity training? Its main function seems to be adjust the strength of relation between diversity and profitability For example, suppose you are studying job applications to various departments within a large organization. You believe that in overall, women applicants are more likely to get the job than men applicants, but that this varies by the number of women already in the department the person applied to. Specifically, departments that already have a lot of

women will favor female applicants, while departments with few women will favor male applicants. We can diagram this as follows:

Actually, if that model is true, then this one is as well, though it's harder to think about:

Whether sex of applicant is the independent and % women in dept is the moderator, or the other around, is not something we can ever decide. Another way to talk about moderating and independent variables is in terms of interaction. Interacting variables affect the dependent variable only when both are acting in concert. We could diagram that this way:

An intervening or intermediary variable is one that is affected by the independent variable and in turn affects the dependent variable. For example, we said that diversity is

good for profitability because diversity leads to innovation (fresh looks) which in turn leads to profitability. Here, innovation is an intervening variable. We diagram it this way:

Note that in the diagram, there is no arrow from diversity directly to profitability. This means that if we control for innovativeness, diversity is unrelated to profitability. To control for a variable means to hold its values constant. For example, suppose we measure the diversity, innovativeness and profitability of a several thousand companies. If we look at the relationship between diversity and profitability, we might find that the more diverse companies have, on average, higher profitability than the less diverse companies. But suppose we divide the sample into two groups: innovative companies and non-innovative. Now, within just the innovative group, we again look at the relationship between diversity and profitability. We might find that there is no relationship. Similarly, if we just look at the non-innovative group, we might find no relationship between diversity and profitability there either. That's because the only reason diversity affects profitability is because diversity tends to affect a company's innovativeness, and that in turn affects profitability. Here's another example. Consider the relationship between education and health. In general, the more a educated a person is, the healthier they are. Do diplomas have magic powers? Do the cells in educated people's bodies know how to fight cancer? I doubt it. It might be because educated people are more likely to eat nutritionally sensible food and this in turn contributes to their health. But of course, there are many reasons why you might eat nutritionally sensible food, even if you are not educated. So if we were to look at the relationship between education and health among only people who eat nutritionally sensible food, we might find no relationship. That would support the idea that nutrition is an intervening variable. It should be noted, however, if you control for a variable, and the relationship between two variables disappears, that doesn't necessarily mean that the variable you controlled for was an intervening variable. Here is an example. Look at the relationship between the amount of ice cream sold on a given day, and the number of drownings on those days. This is not hypothetical: this is real. There is a strong correlation: the more you sell, the more people drown. What's going on? Are people forgetting the 'no swimming within an hour of eating' rule? Ice cream screws up your coordination? No. There is a third variable that is causing both ice cream sales and drownings. The variable is temperature. On hot days, people are more likely to buy ice cream. They are also more likely to go to the beach, where a certain proportion will drown. If we control for temperature (i.e., we only consider days that are cold, or days that are warm), we find that there is no relationship between ice cream sales and drownings. But temperature is not an intervening variable, since it ice cream sales do not cause temperature changes. Nor is ice cream sales an intervening variable, since ice cream sales do not cause drownings. Theoretical Framework (What is the theoretical basis for your study?)

A good piece should be grounded in theory. What is a theory? Simply put, a theory is a statement explaining a phenomenon. Examples: •

Socio-economic status influences academic performance

•

Metacognitive ability influences performance in school subjects

•

Knowledge of story grammar enhances reading comprehension of narrative text

•

Discipline problems is more common among students with low selfesteem

•

Presenting information visually enhances recall and understanding

•

Inquiry learning methods improves understanding of material

Critically examine the literature in your field of study and you will come across the many different theories put forward. Some of these theories have been tested empirically while others remain theories yet to be tested. However, in education many of the theories tested remain inconclusive (with some studies supporting the theory while others providing contrary evidence). This is not surprising because the variables being studies in education is the human being, whether it be students, teachers/lecturers/ instructors, headmasters/principals, parents, etc. The variability of the human being and the difficulty of controlling factors impinging on human subjects explains why research in education tends to be inconclusive unlike the physical sciences or even the natural sciences where greater control can exercised in laboratory settings.

The agile method is a low-overhead method that minimizes risk by making sure that software engineers focus on smaller areas of work. It emphasises values and principles rather than processes. Agile methods work in cycles, typically of a week or a month, and at the end of each cycle, the priorities of the project are re-evaluated. This is similar to iterative methodologies which also re-evaluate at regular intervals. The four main principles of the agile methods as described by the Agile Alliance are to value: 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan (www.agilemanifesto.org) Poinsignon (2002) points out the main difference between Agile methods and classic methods, which he says is that "the paradigm is predictability for classic and adaptability for Agile." Agile methods try to keep overheads such as rationale, justification, documentation and meetings as low as possible. One of the key elements of reducing these overheads is ‘replacing before-the-fact permissions with after-the-fact forgiveness' (Thefreedictionary.com). As a result, agile methods are mainly seen to benefit small teams where the requirements are often changing, rather than larger projects. An example of the way that overheads are reduced might be that of AgileSoftwareDevelopment (http://c2.com/cgi/wiki?AgileSoftwareDevelopment) where only the edits that return the project to a testable state are performed, meaning that everything is tested that is relevant to a module after ‘the fewest possible edits' (The Real Definition of Agile). Alistair Cockburn sums agile methods up fairly neatly, by describing them as being "both light and sufficient, where lightness means maneuverability and sufficiency means facilitating future development" (The Real Definition of Agile). Cockburn then goes on to identify five "sweet spots" to characterize agility, relating to things such as team size and composition, frequency of feedback and other similar characteristics. Finally, to sum up this definition of agile, the words of Ken Schwaber at an eWorkshop in 2002: "...it is based on empirical methods rather than defined methods. Defined methods are when you plan what you want and then enforce it. Agile, you lightly plan what you want and then adapt to what you get." - First eWorkshop on Agile Methods An example of an Agile Method: Extreme Programming (XP)

Extreme Programming is defined by its creators as a deliberate and disciplined approach to software development (extremeprogramming.org). It has its emphasis on teamwork and customer satisfaction, which is what has given XP its success in the software design field. There are four essential ways that the creators feel XP improves a software project: • • • •

Communication between customers and other team members; Simple, clean designs; Feedback as a result of beginning software testing on day one; Delivery to the customer as early as possible, and the implementation of suggested changes (extremeprogramming.org).

In essence, extreme programming is a bit like BBC Bitesize – by cutting down the big picture into smaller chunks, it is easier to digest and work out. The basis of this idea of simplicity is in the belief that those who say that software engineered to be simple and elegant is no longer valuable – are wrong. Extreme Programming is governed by a set of rules and practices listed on their website. These are broken down into planning, designing, coding and testing. To briefly sum up, however, the planning begins with a user story, written by the customer. The project is then divided up into iterations, and fixes carried out as necessary. The design is kept as simple as possible, using CRC cards for design sessions and reducing risks with spike solutions. Through the coding, the customer must always be available, and all production code (coded after the unit test) is pair programmed. Integration occurs as often as possible, only one pair at a time. During testing it is important that all code must have unit tests to pass before it is released, and when bugs are found then new tests are created. Fig. 2 A diagram of the Extreme Programming methodology (Source: http://extremeprogramming.org) In summary, XP is a software methodology that gains its success from an emphasis on simplicity, customer involvement and teamwork (extremeprogramming.org). Why an agile method would be more appropriate than a Waterfall method for the next C++ project There are reasons to support both waterfall and agile methods. However, after looking more closely at these it will be clear why an agile method is the more appropriate choice in this case. First, and most important: as mentioned earlier, once one stage of the waterfall method has been completed, going backwards is practically impossible. This of course makes most software designed and implemented under the waterfall method harder to change with the times and user needs. The common fix to this problem is to go back and design an entirely new system, which is both costly and inefficient. It must be noted here, however, that there is a view that says the waterfall method was in fact designed to be iterative (Presson on CMM) although this is a minority viewpoint. The agile methods, on the other hand do, as the word agile suggests, adapt to change. Their approach to software design and implementation is one which means that at the end of each stage you have a logical program, designed from the outset to cope and adapt with new ideas and to change easily. This may involve a modular approach

to the programming, so that if changes are necessary the whole program does not need to be rewritten, thus reducing the overheads. This is also useful when looking at upgrading programs. Another major advantage of agile methods is that not only do you have a launchable product after each stage, but the program is also tested at the end of each stage. This means that bugs are caught sooner in the development cycle, and as such can be eliminated and new tests brought in to double-check for them. This is very different to the waterfall method whereby the product is tested only at the end, and due to the nature of the waterfall method it is difficult to change the program when bugs are found in this test, as the program has been written by this stage. Due to its modular nature, therefore, object-orientated design and programming, such as C++, is much more suited to agile methodology. For example, you would be able to design a C++ project in terms of objects, and code these as separate modules, thus allowing you to test them before integration to reduce the number of bugs you have to deal with when testing the final project. As already discussed, when using agile methodology you will always have a working model that you can release, whereas with the waterfall method there will only be one main release. Therefore, if this main release has a problem delays will occur, which does not help customer satisfaction. When using agile methods, however, a working program can be released on time although it may not always fulfil the entire specification. This would therefore be useful for a C++ project as the manager would be able to be continually updated with progress. The agile method can always be changed to the end-user's liking. If the specification of the project is changed, therefore, this is allowed for in the adaptability of agile methodology, which means that customers are easily accommodated. This is not possible in the waterfall method, as already mentioned, where a change in the requirements would mean that the project would have to start all over again. Both methodologies allow for some sort of departmentalisation. In the case of waterfall, this can be done at each stage, while in the case of agile each module of coding can be delegated to separate groups. This means that both methods are fairly quick as several parts can be done at once, although it is used more effectively in agile methodologies than in waterfall methodologies which still require you to go through each stage in turn. On the plus side, waterfall has defined stages and elements of said stages and allows for thorough planning especially for deployment, so when you do get a product finished deploying can often be a matter of executing the agreed plan. To conclude, the adaptability of the agile methodology makes it the sound choice for the next C++ software development project to be carried out. Although the waterfall method does lend itself to a logical design, implementation and deployment, its lack of future proofing is also a major drawback. As a result, I would choose to use an agile methodology such as extreme programming.