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 6 years ago.
Improve this question
I have two question for labview users. I'm quite new to this language, I would like to know if design like in the picture attached (extensive use of disable diagram structure) are:
a good practice to separate part of code (I like the structure input/computation/output)
does not imply extra computation time
labview disable structure
Thanks in advance!
PS: sorry I had to hide some code not my will...(licensed)
No, the code is compiled and disable structures are ignored. But the best practise is to use subVIs (with proper connector pane and icon) to structure input/computation/output.
Everything that is connected to the left of your subVI connector pane is input.
What you have in subVI is computation.
Everything that is connected to the right of your subVI connector pane is output.
Please have a look below:
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 7 years ago.
Improve this question
So, I working on a problem at my workplace, that is a big company with a serious CNC shopfloor. Here I thought I could make the life much easier with a little software. I have the conception, I put a lot of work in it together with my helpful friends and here is the point, when I suppose to explain it to my leaders.
The problem is, I've never made anything like this before. So I don't know the way. I should use UML-diagrams and use cases, class diagrams etc? Or which is a preferred way?
Out of the management perspective you could explain why your programm is efficient and required to optimise the workflow. Creating a presentation could help you make the idea of the application clear and bring it in a form which is understandable.
If I were you I will go in priorities for activities diagram. You create an activity diagram of the old flow and another with the new flow. You show both to your manager and you compare them. Normally your program will minimise steps inside the new flow. Then you can say that with less steps to manage there will be more money to earn for your manager and you at the end :)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I need to prepare a Software Requirements Specification Document for a small enhancement within an JAVA application.
I have tried goggling for the same but found the samples for whole application whereas I am preparing SRS for a small enhancement within an application.
Can anybody suggest the links or suggestions for preparing the SRS.
As you realized by yourself what you're asked isn't a Requirements Specification, which usually covers the whole set of requirements for a software.
What you've been asked is a Change Request, and it must be merged in the existing SRS. However something tells me that there's no SRS for the software you're dealing with, as your management doesn't know the difference between both...
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 5 years ago.
Improve this question
I am trying to make a flowchart of my program (yes I know it is the wrong order to do it:) )
and I made a desicion symbol to represent the actionsheet I display in the iPhone application. It prompts the user "Yes, No, Cancel", so it is three options. However on all the templates/tutorials I have seen they only use "Yes" and "No" over the arrows which lead out from the desicion symbol. So could I use "Cancel" as well? If not how could I have done it otherwise?
You can do whatever you want with it, as long as it simplifies the meaning for your program. Decision making isn't restricted to 'yes' and 'no'.
Most of the time, flow charts are used to explain program logic to non-programmers. Your goal is to get them to understand what you program. We often use visual tools for this. You want to put all relevant information on there. If the cancel button is important to your program, put it on there. In my opinion there is no strict rule about what a flowchart should look like. Over time some basic form of flowchart has grown but you can add or remove whatever you want if it allows you to make more comprehensible charts.
Wikipedia suggests that decisions can have more than 2 choices, but should maybe be broken down. I see two options using a Google Docs drawing:
https://docs.google.com/drawings/d/11AhEIUOr9SdhXB1REculUy0NF9c628qaxfYVacUGfzU/edit?hl=en_US
I agree with the previous answer that the simpler it looks the better... whatever makes it most understandable. I think it's simpler to have 3 choices out of the 1 decision.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have various documents some are large some are small, we have to draw up some form of model that would describe how a user interacts with each document when following them for a build. For example, a user might.
Follow Document 1 to Section 10 then be pointed to Document 2 to complete then return back to Section 10 in document 1 etc.
Has anyone ever drawn up some sort of chart to demonstrate this kind of thing for documentation, it is fairly standard for systems but i have never done it regarding documentation and I am just wondering if there is a formal method of doing this for documentation and is there any examples or standard guides to follow.
I think I would use an Activity diagram with Swimlanes for each document.
An alternative would be an IDEF0 diagram(may be appropriate if there are instructions for completing each document, and/or different roles for different steps)
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 5 years ago.
Improve this question
In software developement project..
While preparing a gantt chart, which things we should take care?
A very vague question, kind of like "What is the meaning of life?".
Things that occur to me:
Knowing what you will build
the order in which things have to be build,
resources required,
when things have to be finished,
who will have to check the build items,
when are people and resources available.
The WBS 100% rule (see this)
Where relevant, use abstract time units in the chart and scale to meet a fixed release date.
Don't overuse. Use it for what it's good for. For example, avoid showing too many dependencies: Draw out a separate dependency tree
If you have several tasks which are proving difficult to estimate then try to have them run in parallel. That way you reduce the overall risk should one or more of them overrun.