my question is related to social network analysis. I am starting my research work on the citations network analysis of 3 universities. my question is that how can i easily collect data for my citation network? or Is there any intelligent software which can identify references link of citations automatically? Or can I do it through simple programming?
Thanks in advance.
You could try something like this:
http://www.vosviewer.com/Home
But I guess if you want to write your own custom-made software, it would work better, because you'd be able to fine-tune it exactly for your needs.
Which package to recommend depends on the languages you know. I think most of the existing modules for this sort of stuff are written in Python, so if you're familiar with it, go ahead and google some citation extractors.
Alternatively, you could program it yourself, shouldn't be that hard. Consider using a graph database, like Neo4J for it.
Interesting that you asked this question on the day Nature published the Leiden Manifesto
#Dmitry Paranyushkin turned me to VOSViewer
Watch this video and learn how to collect/import data into VOSviewer
Your institution will have to has access to Web of Science to collect the publication data.
For you specific purpose you may find CitNetExplorer more useful.
Also, check out the parent organization Centre for Science and Technology Studies at Leiden University.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm trying to think of a simple (and agile in nature) way to visualize a large department's work and bottlenecks, with the idea of gradually improving the process once we have the necessary data.
The problem is that we have multiple groups of developers working on multiple projects. Some developers are cross-project and some projects are cross-team. Developers are very set in their ways (we don't want to force C# or Java developers to learn Delphi 6 during pair programming).
Another issue is that a very small QA team is shared between all developers/projects.
I need ideas for how to organize a Kanban (or similar) taskboard so that stories are categorized by project (or team?) but that the WIP limits are still applied across the board.
Also, how would the standup meetings go? Including everyone in a single meeting would take up too much time and result in information overload, but splitting the meeting makes us lose out on a lot of the transparency that agile enforces.
So, any ideas related to taskboards and standup meetings are welcome.
Also, alternatives to Kanban with the same level of prescription as Kanban (in other words not much) are very welcome.
Eylean Board could be a solution in this situation. Eylean board offers data slicing in visual level and in data level. Arrange by rows, columns, categories, assignments. It supports task grouping into categories which can work as different projects and may be placed into different rows of the task board. Any of these options leaves ability to apply WIP limits across the board. The app itself was built to suite kanban so you should find helpful.
Corey Ladas over at Lean Software Engineering has a few articles on how to design a Kanban board for various workflows. I also highly recommend the kanbandev mailing list - the community is pretty mature, but searching through the archives should prove useful.
For standup meetings, keep in mind that Kanban does not prescribe the standard Scrum-style standup (What did you do yesterday, what did you do today, any blockages?). These can still be useful to do with smaller groups, but with a larger team (you never mention how large - 20? 200?) you can just focus on the blockages. What people are currently working on is visible for all on the board, and the next priority (i.e. What will I do next?) should be in some sort of "Ready" queue, which is pulled from according to your different classes of service.
I believe it is impossible to have a physical or (any other) board that shows projects, teams and development flow simultaneously. Moreover, there is no software that provides good team-level visibility, almost all project management tools built on top of Project concept, and little use Team concept.
I've been thinking about this problem for 2 years and came up with a solution that we are going to implement in TargetProcess, but we are not there yet. The basic idea is to allow to filter and group work flexibly by teams or by projects to provide bird-eye view and zoom in to see details for particular project or particular team. I can't imagine how it can be done on physical kanban board.
Here are some ideas.
In Agile projects, it's a common practice to visualize and share project status using charts or diagrams on boards. While no single document delivers all of the ammunition agile teams need to get the rhythm, this set of visual materials offers an easy framework to help guide software development teams through the various agile cycles.
A variation of the Kanban, an easy way to represent these cards, with some enhancements to this representation and a synchronized use of the concept, ArabiaGIS introduced the Sync Kanban concept.
The Sync Kanban is composed of a board for each project where the team leader or the responsible developer will try to represent the project status and the features progress with pies.
for complete description: http://www.jaftalks.com/Home/Show/Sync-Kanban-Agile-Project-Management
I'm trying to think of a simple (and agile in nature) way to visualize a large department's work and bottlenecks, with the idea of gradually improving the process once we have the necessary data.
Maybe not the expected answer but this is exactly what value stream mapping is for:
(source: killen.org)
And this is where you should start.
Have a look at Mary Poppendieck material on this subject (e.g. this presentation, this one, or her books).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Are there any programming methodologies that take into account the concept that the first round of written code is likely to be not what you want to use? The most common thing I hear at the end of a project from a developer is 'If I could do that again, I'd do it so differently.' This is almost an exact mirror of the process a writer goes through after writing a first draft. The difference seems to be that writers then rewrite and rewrite again until they're ready to move into the editing stage, whereas developers seem to write and then refine their first draft with testing and refactoring.
I'm certainly no fan of trying to use alternative analogies to define the development process, but I do think there's value in recognising that your first draft is just to get ideas down, you need further rewrites in order to produce something worthwhile. I just don't think I've ever encountered a programming process or project methodology that recognises that, so I was hoping that the vast collective concious of Stackoverflow might have an idea of where I might start exploring this possibility?
Prototyping seems to address the problem in some way. The wikipedia article on Prototyping names an approach called 'Throwaway prototyping' which seems inline with your way of thinking.
What you are describing is called throwaway prototyping. The idea is that as soon as you have your preliminary requirements, you create a basic model of the system to show the user and/or customer what the final system might look like and how it might function (although there's no real functionality). The user provides feedback on this prototype.
If you wanted to utilize throwaway prototyping, my first suggestion would be to start looking at the spiral process model. However, I'm not familiar with very many methodologies that explicitly utilize throwaway prototyping. The more "agile" methodologies favor evolutionary prototyping or incremental prototyping. The only time I've ever personally used throwaway prototyping was to only prototype the user interface, as the underlying system was already under development and I used whiteboards and pen and paper for the prototypes.
Besides, this is one of Brooks's ideas which he himself found not the most effective after some revision: you've probably heard of "throwing away two systems after planning to throw away just one". Fortunately many such troubles can be overcome nowadays thanks to agile methodologies.
This is exactly the argument that Bruce Eckel is making here.
I would argue that the best thing to do is modularize very well. For example, if you're writing a kernel, the "Get the next available free memory frame" function should reside in its own function. That way, when you figure out that it's written in a really crappy way, you simple erase (of course you're using version control) and start from scratch. That way, your existing modules exist as a way to test your new code.
Going from start to finish and then start to finish again is an awesome way of going through a large percentage of the same bugs again.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I spent a couple of hours to find any up-to-date figures regarding the share of software development methodologies such as Waterfall, RUP or Scrum but could not find any useful information. Is there anybody who knows about such surveys? The corresponding document does not need to be freely available, but as a matter of course I would appreciate it.
Thank you very much!
Seb
Couple of the documents I have on hand to help you on your research.
THE INFLUENCE OF ORGANIZATIONAL STRUCTURE ON SOFTWARE QUALITY: AN EMPIRICAL CASE STUDY
Nachiappan Nagappan
Microsoft Research
Redmond, WA, USA
nachin at microsoft.com
Brendan Murphy
Microsoft Research
Cambridge, UK
bmurphy at microsoft.com
Victor R. Basili
University of Maryland
College Park, MD, USA
basili at cs.umd.edu
In Proceedings, International Conference on Software Engineering, 1999, Los Angeles, CA, pp. 85-95
Splitting the Organization and Integrating the Code:
Conway's Law Revisited
Debugging the Development Process
Managing Humans - Biting and Humorous Tales of a Software Engineering Manager
I believe you will find most software developed for business systems follows iterative development cycles with a rough methodology similar to SCRUM even though most wouldn't have realized it.
The only times you will ever see a static methodology such as Waterfall would be in most likely a large government project that requires every single technical and business design document to be completed and approved before any type of software development begins.
Since you are willing to spend money, you could turn to a professional analyst firm like Gartner Research. They generate tons of reports and you might find something in their archives. Major corporations often cite studies by Gartner.
If that does not yield any results, you should do a search in research papers. Google Scholar might help you there.
If all else fails, and you have enough time on your hands, you could perform a small study yourself: Pick random companies and tell them you are doing research and that you would like to ask them a few questions.
If such a thing existed...
There would be standards based on the results. If anywhere close to 50% of shops actually used Scrum or RUP or anything, there would be an applicable standards organization pounding out the details.
We'd all be told specifically what to do based on the results. Our lawyers and accountants would ask why we're using a methodology only used by 15% and not a methodology used by 28%. We'd have to contend with armchair generals quoting the results at us.
There would be products for sale based on the results. "Supporting the most popular methodology." "One of the most popular methodologies." "Trouble-tickets for the fastest growing methodology."
You'd see advertising that quoted the results and claiming specific quantitative benefits. "28% of organizations use our version of Scrum with improved on-time delivery."
Ever see any advertising or standards based on adoption of a methodology? Anything?
Such quantitative studies probably don't exist.
Also, a precondition for counting is definition. Can you define Scrum in a way that it's somehow different from XP? I doubt it.
I think this kind of data cannot possibly exist. It requires far more formality and standardization than are even remotely possible for something so complex as software development.
I don't think you will find reliable data on what you're looking for. I've been looking for that kind of figures for a few years and I haven't found them.
First of all, very few organisations tell you what method they are using. Some just don't use any. Some other don't know what they use, or what to call it. And some know what to call it, but won't disclose it for whatever reasons. Of the organisations that will tell you, which are (in my experience) a minority, there's a big assymetry in how they characterise what they tell you. The way in which your own question is worded illustrates this: most industry people (and many academics) today, when asked to list methodologies, think of waterfall, RUP, Scrum, XP, and a few other "trademarked" agile approaches. It is interesting, but they are perfectly capable of citing a number of agile approaches, the differences between which are usually much smaller than the differences between (almost forgotten) methods that are bunched together under "waterfall". Agile approaches are so heavily marketed and hyped that, like Coca-Cola or McDonald's, are so present in our daily lives.
Methodologies are often presented as either waterfall or agile. That is a terrible fallacy, fostered by the agile community. There are successful methodologies that do not qualify as waterfall and predate (and do not qualify as) agile. However, they seem to be ignored, and they rarely surface on surveys such as the one you demand in your question. Very rarely I find people in industry reporting to use methods such as Catalysis, OPEN/Metis or Fusion.
(Note: Don't misunderstand me; I appreciate the value and contributions of the agile movement. But I am no raving fan; I am a researcher who tries to make an objective assessment.)
In summary, I don't think you'll find a study with data that answers your question. But, in your search, I suggest you take into account these comments.
Good luck. :-)
maybe not sound helpfull, but don't give to much to buzzwords. good programmer/software engineers with an sense/instinct what needs to be done you need. most of these proceses where invented because fearfull programmer sticked to closely to one of these pradigmes and the car went against the wall and some guy rightfully pointed out what they missed. but that can happen with most strategies if you don't see you situation in which you developing as a whole.
the more recently hyped methods like XP i don't see in you list. they work well even in smaller teams. :)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Do you use a formal event to get people talking in your IT department? Like a monthly meetup in a social place, a internal wiki/chat space or just a regular "information market" with some presentations about technology or projects made by your staff for your staff? Do you invite Sales people to participate or is it a closed event for programmers only?
How do you get people to participate in these events? Do you allow them to spent work time on knowledge transfer? Or do you understand it as an integral part of the work time?
I wonder how to monitor the progress of knowledge transfer itself. How do you spot critical one-person spots of failure in your projects? There are several methods to avoid it, like staff swapping or the "fifo" attempt on bug fixing.
Note: Ok, this is a very very noisy question and I hope to fix it after a few comments. Sorry for the mixup.
edit: My personal experience is that there is a very high barrier for people to start contributing. It looks like they won't put in the (minimal) extra time to edit our wiki, or spend the hour in the afternoon to talk about technology topics with the developing staff. It's like people don't like our wiki, our document management system or the meeting. Maybe it's because it's all free-to-use and not forced by the management. But I don't like to force people into it - but is it the right way?
One example: Our wiki holds pages about projects, telling who worked on it to get a first contact in case of questions. But nobody besides a colleague and me is creating this pages...
Knowledge Transfer and Knowledge Management have one drawback. They seem to cost an aweful lot: if everybody knows what I know, am I still needed? All the time I use to bring others up to speed, what do I gain from it?
The best way to go about this is to be an example. Share your knowledge; in a wiki, blog about it, talk about it, make it easily accessible, and talk about the benefits you have from that: less people come to interupt and ask you stuff, as they can get an answer easily without even getting up. And show them that you are still there.
This with all the other things mentioned will actually win out. One more thing: one of my employers kept on paying me 1/3 of my salary for another year after I left (on my own initiative), just to keep my knowledge-base up and running. Did he have to? No, it was his property anyway. But it motivated people still working for him to share their knowledge.
I think all of the above. But you're forgetting the most important way.
The most efficient way to transfer knowledge is to have people work together. You might think about doing 1 on 1 code reviews or even pair programming and make knowledge transfer an intergral part of the work.
I think it depends on the knowledge you are trying to transfer. I've found the following:
Technical Knowledge: "How to guide" with screenshots and a short demo - similar to the way you will see new features at a conference. The added benefit of this is what you have got is documented for when you leave the company.
Problem solving: informal discussions, short internal projects, lessons learned and an internal FAQ system which EVERYONE is responsible for updating.
Soft Skills (people skills): social meetings/outings/informal events etc.
Measuring that is going to be difficult though, as no matter how you transfer your knowledge there will always be varying degrees of uptake, after all, just because I do something one way doesnt mean its correct. Another developer/designer/manager may have a different way of doing the same thing with the same end result.
Mauro
At my workplace we use a wiki. The workplace is small enough (~20 people) so that you can always ask the person who was most involved in a particular project, however it is expected that you have searched on the wiki before you ask "the expert". If you cannot find your answer in the wiki, then you should add it after you have discussed it with your co-worker.
One word: Lunch
You should encourage people about things that you want them to do. You should "feed the animal". Look at stackoverflow; what do you think about badges? Why do you think this wonderful things exist? Thanks to ego, there is nothing you can't get it done. Give them badges, real badges, wearable badges. They will wear with happiness, they will do with happiness.
Btw, yes, I am a boss :)
Although i am still a student, when i did work experience 12 months ago, the all IT departments from within the corporation (I was 'working' for large corporation which own several mines in the area) would have a daily telephone conference, where each employee would say what they had been doing etc, and then talk about something new they had discovered and any other interesting tid-bits.
Couple ways I have seen so far:
Wiki is suitable for internal knowledge, for example environment, project specific topics.
Open doors policy
Encourage asking questions.
Voluntary presentations. Find out who have special knowledge and make it easy and attractive to set up a short presentation about it.
Project post mortem documents. A wrap up meeting moderated by someone outside project team held after project is finished or terminated.
Compulsory presentations.
Project presentation when they go live. Technologies used etc.
In case someone is sent to conference, he should have a presentation about new technology he saw.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
So basically I am looking for good templates for writing both technical and functional specs on a project or work request.
What do you use? How deep do you get while writing the specs? Any additional general tips you could provide would be appreciated.
My company needs these badly. I work for a contractor and right now we do not use these documents at all.
EDIT: I have read Joel's take about Painless Specification, I really liked it, but are there any other opinions :)
On general tips;
We are implementing a process of
1) Business Requirements Statement (BRS)
2) Functional Specification
3) Technical specification
The BRS covers what the business problems are, and what the requirements are around solutions, testing, security, reliability and delivery. This defines what would make a successful solution.
The functional spec details what is needed, how it should look, how long fields should be, etc.
The technical spec details where the data comes from, any tricky code that may need to be considered.
The customer owns the requirements. The developers own the tech specs, and the functional spec is a middle ground. Testing is done against the tech specs (usually unit testing) then against the functional specs (usually system testing) and then against the requirements (UAT).
The important part of this (and we are struggling with) is that the developers still need to deliver to the functional spec, and the original business requirements. In reality the functional and tech specs are just there for clarity.
In short, my main tip is to first work out the process you wish to implement. Then seek agreement from all parties involved in your proposed process, then work on the templates to fit. The templates themselves are only are a small part of the change you want to make.
Not a template, but Joel has written a couple of articles on writing a functional spec. He also has sample here.
You can buy templates from ieee and other places, but I have always ended up making my own.
For a technical spec, "Code Complete" by Steve McDonnell has a good checklist, you can draw some info from that. At my last job, I just made a template out of his section headers, and tweaked it from there.
As far as a functional spec, the important thing is to define all the interfaces:
UI (screen mockups)
Software interfaces (plugins, etc.)
Hardware interfaces (if appropriate)
Communications interfaces (Services, email, messaging, etc.)
There should also be a section for business rules, things that are important functionally that are not covered in any interface definition.
If you want to purchase a book, Software Requirements by Karl Wiegers has templates for a few documents as an appendix. Unfortunately, I'm at work and that particular book is at home. If someone has it handy, they might be able to confirm that.
I happen to like this one, among others: ReadySet.
He sells a pro version too.
This is the best one I have found: http://www.jiludwig.com/templates/FRDTemplate.doc
Start off simple, and work your way from there. Since this is your first experience working with this, use a word document with bullet points. Write it, re-read it and provide enough detail that it makes sense. For technical specifications, you may want to lead the developer toward a solution, but for functional specifications the "how" should be completely missing.
I would suggest to have a look at the Roberston's Volere template here. They are part of the Atlantic Systems Guild, together with people like Tom DeMarco and Timothy Lister of "Peopleware" fame.
As the template is copyrighted, I will not reproduce it here, but give you some of the main headers:
The Purpose of the Project
The Stakeholders
Mandated Constraints
Naming Conventions and Terminology
Relevant Facts and Assumptions
The Scope of the Work
Business Data Model and Data Dictionary
The Scope of the Product
Functional Requirements
Look and Feels Requirements
...
There are many more, but this should give you an idea. The most interesting part of the template is the requirements shell that lists functional requirements on a kind of cue card. Again copyrighted, but truly valuable.
Look here in chapter 9.