Good day everyone,

I have just posted this question on Stackoverflow: http://stackoverflow...mn-and-use-case . However, I want to post here to hear your opinions on software development process in general and the game industry in particular.

BPMN (Business Process Modeling Notations) is used for modeling business process by visualization, thus making intangible ideas become physically concrete through the expression of BPMN diagrams. The question is, how do I organize the process with the software development process.
Initially, I thought of two ways to organize use cases and business process diagram:

• 1 to many: By mapping each step (step here means each node in the BPMN digram) in the business process diagram with server use cases. Each use case is mapped with several class diagrams/component diagrams (I prefer this one, since you can encapsulate a set of classes into one component which has input and output), several sequence diagrams (optional). After you have class diagrams/sequence diagrams, code is written/generated based on the model.
  
• Many to one: By mapping several steps into one use case. The subsequence steps are the same.
  
• Many to many: For example, one step in the business process can be mapped with two or more use cases, and the same two or more use cases can be mapped with other steps.
  
  The above methods can be done by the modeling tool, and in my case, I use Enterprise Architect from Sparx System. I discover it recently and I am using its trial, but I will buy it in the future. I can organize many use case diagrams with one step of the BPMN diagram, and can click to view the necessary use cases. However, I don't if it supports many to many cases.
  After thinking my own method for organizing BPMN (which is aimed for business people) and Use Cases (which is more oriented to software engineers, even it's still at the high level point of view - the requirement view), I searched the Internet, and found two other papers, each suggest the following method:
  
  
  • Turn each use case into each step of BPMN diagrams: To visualize how use cases refined from engineering point of view play in the business process. However, this approach requires the use cases to be defined first, which makes it hard since business process should be modeled first to make everyone understands the process before turning into use cases, if the process is complicated enough. Or should this method be performed after business process and use cases are well defined to further verify and validate the concepts between two point of views (business and engineering)? Original presentation is here: Visualizing Use Case Sets as BPMN Processes
    
    
    
    
    
    • Each use case is exactly a business process: Each step in the use case is each step of the business process. Original paper is here: Describing Business Processes with Use Cases
      
      
      It seems to me that there's not standardized way of gluing these artifacts (BPMN and Use Cases and other digrams) together. Maybe it's a management problem and rely more on creative usage rather than follow a formal steps. What are your opinions/experience on the usage of these diagrams in software engineering process?
      
      I know methodology like XP which specifies its own practice in software development process. However, unlike Scrum where it focuses more on management aspects (which means you can still apply the BPMN/UML modeling into your work process), XP specifies software practices and requires you to follow, and eliminate the modeling process like BPMN/UML, and its practices if not apply properly will lead to issues like under documentation, incorporates insufficient software design....
      
      I prefer the model driven way more than XP. I guess it's up to the preference of companies and people. One of Agile goal is to "free developers from document works". Methodology like XP seems to easily lead to under documentation. I think to achieve that goal, the solution is to implement the tool to help developer reduce the workload on writing document, not by writing less documents, by gathering information from existing diagrams and automatically generate reports (in RTF, PDF, HTML in the case of Enterprise Architect of Sparx System). Another example is, people often complain about drawing diagrams consume their time. In my opinion, the solution is not to draw diagram, but the using the tool. Modeling tools today support round-trip engineering, where you can synchronize between your code and your diagrams, thus eliminates the extra effort to manually correct the diagrams if the code base changes (specifically, class diagram). What's your opinions/experience on this issue?

What's wrong with a good old-fashioned requirements specification, followed by a design document?

[sub](as you may guess, I have limited tolerance for enterprise-style 'process for the sake of process')[/sub]

What's wrong with a good old-fashioned requirements specification, followed by a design document?

[sub](as you may guess, I have limited tolerance for enterprise-style 'process for the sake of process')[/sub]

Of course the documents are necessary, and is aided by modelling tools where it helps retrieving relevant information to build up the document.The tool provides a way to manage documents throught out the development process (source code is a form of document as well). However, in practice like XP, documents such as what you specified are not encouraged to write, since it will cost more time.

BPMN is part of the requirement specification if it is applied. I think BPMN is a good tool to model the requirement and business process. So instead of writing pages of document, one diagram can summarize nicely and easier to read.