Collaborating with other disciplines

Starting from the essential bibliography for this research, there are some elemental concepts that the readings from Frederick Brooks (1995), Peter Harris  (2008) and Brian Wilson (2001).  The methodological process to undertake this project will be very important.  The interdisciplinary quality will bring big challenges in the managerial aspect of the project. At this early stage, I believe the project being an intrinsic part of Web Science will invite collaborative work from Computer Science, Museology, Business Management and Visual Communication among others.

Developing Software?

I will argue that the project will contain a product similar to a computer software product.  This product I believe will be develop similar to software, by this I mean a “collection of programs and the algorithms they represent” (Brookshear, 2010).

The complexity within the development of any kind of software of application requires an understanding of the methodology and the environment in which these products are created. It is also important to learn how to communicate with the team and how to make the team communicate with each other as a managerial task (Brooks, 1995). In the development of software, Brooks (1995) defines some essential tasks:

• Planning
• Coding
• Component test and early system test
• System test, all components in hand

Its about time!

It is important to know how to calculate the time needed for the development of the project and the time needed for each one of the tasks, not only for the implementation of these digital tools, but also for all the research tasks of the project.  If there are some ‘hold backs’ within the project, Brooks (1995) explains that bringing more man work will not only be the solutions due to the tasks required for the development of software.  Therefore it is important to analyse and understand all the different solutions applied within the Computer Science discipline and all the other disciplines involved.

It is recommended to use as little people as possible for the construction of a ‘soft system’. This is due to the managerial problems that big teams create. But sometimes small teams won’t be able to cope with the workload. Based on this, I will argue that it is also important to plan correctly the size of the teams in order for the research project to flow smoothly and with minimum communicative problems.

Assembling the team

It is my perception that is important to understand how a big system team is built in order to continue or to blend the methodological process into that work structure.

Although there are other organizational proposals, the one that seems more traditional is where we find a chief programmer defining the original program and codes and even testing the software. Followed by a co-pilot working as a second hand. There are other team members like the administrator, the editor, secretaries, program clerk, toolsmith, language lawyer and the tester (Brooks, 1995).

Problem solving

The main objective of a program or software is to solve a problem (Brooks, 1995; Wilson, 2001; Harris, 2008).  For this it is essential to define the problem.  What is this set of tools or applications going to solve. Wilson (2001), defines two types of problems: hard problems and soft problems. “The design of a piece of software to meet a given specification is a hard problem (as long as the specification is ‘a given’) whereas the specification of information requirements to meet business needs is a soft problem…”.  The perception of what is a problems is also important.  Being a multidisciplinary project means that what seems to be a problem, it could not mean anything to the person working in the museum or the audience or even the cultural heritage manager.  To solve this, Wilson (2001) suggest that instead of trying to solve a problem, it would be more helpful to try to solve the situation that is creating the problem. For this he proposes the next methodology.

1. Define the situation that is problematic
2. Express the situation (top mapping, rich picture, etc.)
3. Select concepts that may be relevant
4. Assemble concepts into an intellectual structure
5. Use this structure to explore the situation
6. Define changes to the situation (i.e problems to be tackled)
7. Implement change processes

Its all about the good manners.

Both Wilson (2001) and Brooks (1995) express the importance of the way to communicate with other team members.  The ‘hierarchical’ level of communication. During the production of this research project (and any other), which I completely agree is to break the ‘tree’ system in which one person is the boss and the people below are reporting or working for this person.  The responsibilities have been already defined and in the communicative structure, everybody is allowed to participate and to provide solutions to the situation problem solving.

Bibliography.

Brooks, F. P. (1995). The mythical man-month essays on software engineering (Anniversar., p. 322). Reading, Mass ;: Addison-Wesley Publishing
Harris, P. (Peter R. ). (2008). Designing and reporting experiments in psychology (3rd ed., p. 284). Maidenhead :: Open University Press
Wilson, B. (Brian). (2001). Soft systems methodology conceptual model building and its contribution (p. 260). Chichester ;: Wiley