Software Engineering Methods as Mental Models
You (as a developer, analyst, manager) can use Software Engineering methods in two ways: either you apply the method or you use it as a mental model. Let´s take the UML use case model as an example.
1.) Method as method: Software Engineering methods come along with templates, notations, rules, tools, etc. When you apply a method in your project, you most probably will have to motivate others to use the UML tool, keep to the UML notations and rules for Use Case specification. This is usually difficult to achieve. Especially if it is not your official task to initiate work process improvements. But even if it is, people do not like to be told to change their way of working.
2.) Method as mental model: Psychologists emphasize the importance of a mental model for systematic work and for communication with your colleagues, team members and all stakeholders. Such mental models can be the project plan, the software architecture, a workflow model etc.. Their function is to steer expectations and to make that the work of each individual fits together with the rest of the project. Therefore, it is important that everyone shares the same mental model. Software Engineering methods often provide such models. You can use them as the basis for structuring all your tasks, communication and documents. You go and ask the stakeholders for actors and use cases, and also for the dependencies among these use cases. You know what to ask and when you have asked enough. Your interview gets a structure by using a method. This looks more professional than saying: "Please, tell my anything I need to know about your requirements." or "Oops, sorry, I forgot to ask one question." You note down the results in a Use Case diagram which you later copy into the requirements specification, in presentation slides, meeting protocols and reports. Maybe, you want to structure requirements document and test cases according to which use case they belong to. This helps you to keep your documents consistent and provides an informal traceability link between them. You can use an UML tool for modeling the use case model, but you need not. If you want others to also edit the graphs, then you might want to use the drawing tool that is already used by your colleagues.
You see the difference? Alternative (1) demands a change in the way of working of your colleagues, while alternative (2) means that you do your normal work in a more structured way.
1.) Method as method: Software Engineering methods come along with templates, notations, rules, tools, etc. When you apply a method in your project, you most probably will have to motivate others to use the UML tool, keep to the UML notations and rules for Use Case specification. This is usually difficult to achieve. Especially if it is not your official task to initiate work process improvements. But even if it is, people do not like to be told to change their way of working.
2.) Method as mental model: Psychologists emphasize the importance of a mental model for systematic work and for communication with your colleagues, team members and all stakeholders. Such mental models can be the project plan, the software architecture, a workflow model etc.. Their function is to steer expectations and to make that the work of each individual fits together with the rest of the project. Therefore, it is important that everyone shares the same mental model. Software Engineering methods often provide such models. You can use them as the basis for structuring all your tasks, communication and documents. You go and ask the stakeholders for actors and use cases, and also for the dependencies among these use cases. You know what to ask and when you have asked enough. Your interview gets a structure by using a method. This looks more professional than saying: "Please, tell my anything I need to know about your requirements." or "Oops, sorry, I forgot to ask one question." You note down the results in a Use Case diagram which you later copy into the requirements specification, in presentation slides, meeting protocols and reports. Maybe, you want to structure requirements document and test cases according to which use case they belong to. This helps you to keep your documents consistent and provides an informal traceability link between them. You can use an UML tool for modeling the use case model, but you need not. If you want others to also edit the graphs, then you might want to use the drawing tool that is already used by your colleagues.
You see the difference? Alternative (1) demands a change in the way of working of your colleagues, while alternative (2) means that you do your normal work in a more structured way.
AndreaHerrmann - 26. Jul, 10:49
