Ratko Ćosić - lamentations of one programmer

srijeda, 07.05.2008.

Case Studies and what can we learn from it

This post is about another of my (ridiculous) toughts: Can we learn something from the case studies?

As I've mentioned once before, these case studies just tackles me in my heart because of its simplicity and good relaxing but on the same time exciting and thrilling feeling that they bring. Well, actually, it's poetic expression to say that you just can't rest your brain while you read it and you have to be patient with the studying it as with gardening your flowers (ok, probably you don't have any, and probably you don't have a garden at all, but never mind).



(gosh, I'd love to have this forensics set, at least for the kids)

Although you read it just to select the right answer and finally pass an exam, I think that they are usefull in everyday life because of some of the characteristics they have:
- case studies are, although idealistic, a try to present business environment to a young developer who merely knows anything about the companies and economics,
- case studies show which problems companies usually have, although the emphasis is on technology reasons rather that a people-ware, environment or politics,
- case studies have advantages to present the currect situation, problems, and potential solutions for just an hour, so a developer has the opportunity to quickly pass through life cycle of the development process, which he/she possibly doesn't see completelly at everyday work,
- case studies force you to pick the right answer within a stiffed time period, instead you stuck yourself into the problem you can't solve for days, maybe weeks,
- case studies lecture you to select balast facts from important ones, make you this way as a CSI detective, which usually has to discover a very tiny detail which can solve the case,
- finally, case studies force you to read and write - you just have to read this whole bunch of text, and possible you will be able to write some technical document more efficently because you now know the structure.

The list of the benefits of it could go more and more, but I guess the list of its weaknesses would also grow, so I stop here.

THE STRUCTURE OF CASE STUDY

Common table of contents:

1. BACKGROUND
1. 1. Company Overview
1. 2. Phyisical Locations
1. 3. Planned Changes
1. 4. Problem Statements
2. EXISTING ENVIRONMENT
2. 1. Existing Application Environment
2. 2. Existing Supporting Infrastructure
3. BUSINESS REQUIREMENTS
- General Requirements
- Views
- Business Processes
(also sometimes under TECHNICAL REQUIREMENTS)
- Performance
- Availability
- Security
- Maintainability
- Interoperability
- Scallability
- Recoverability
- Data / Storage of Information
- Multiple Language Support
- Reporting


Generally, a case study inside the exam consists of two or three main chapters. These are: background, existing environment and business requirements. In Background, there is usually a vision and mission statement, a short description of company's main occupations, organizational and geographic structure, planned changes and the statements about business problems. In Existing Environment section you can find a description of platform and dev tools on which the current solution is made and some of the othere related stuff as a network, protocols, internet, other participants in sharing the data. Finally, inside Business Requirements there are stuff like solution metrics (performance, security) or other special factors that are important for the task, as multiple languages or interoperability.

What is your task?

Your task, my friend, would be to read the study and to start using your underlining marker as much as you can. In other words, grasp the text and try to find something vital and indicating for the problem. As a guideline what is your goal, you shoud read Planned Changes section carefully. This is the spot where is mentioned what application is required or which existing functionality needs to change.
For example, if planned change includes to migrate all existing application to .NET framework 2.0, you should know that there is a possibility you'll get the question in which you should know the differences about a certain method call or approach between the two of the frameworks. And that would be the answer to your question.
Another example to that is, if a company plan to spread to different geo-areas instead of going local. This indicates you should revise all the methodologies currently used for connecting the components, number of layers, scallability issues, and so.
Also, Problem Statement is equally important. If users report that response time of the application or query in slow, you should review the sections about technical requirements and existing environment, especially existing supporting infrastructure.

Other questions will be direct or indirect implications of business and technical requirements of the study. That means that the answer would be just to read everything under certain requirement and try not to be in colision with some other requirement in the study.
For example, there are lots of questions like:
'You need to design (or create, modify, determine, etc) some task for this-and-that business process. Your solution must fullfill all business and technical requirements. What should you do?'
In that case, read the material and write down everything what might interfere with this task and with the requirements and, using selection, pick the right solution.

Also, there are questions in which you have, along with fullfilling all the requirements, support an additional requirement, for example, pick the solution which require minimum amount of development time, minimum number of changes, minimize additional network (or disk) usage, simplest or quickest solution, etc. But be warned, usually that is the trick that you omit other requirements mentioned in the case. You must satisfy all the requirements.

Happy hunting!

- 10:26 - Comments (0) - Print - #

<< Arhiva >>

Creative Commons License
Ovaj blog je ustupljen pod Creative Commons licencom Imenovanje-Nekomercijalno-Dijeli pod istim uvjetima.