By looking at the Visual Studio solution (not to be confused with a SharePoint solution WSP), you can easily tell what you have:
In the Visual Studio project (from the Solution Explorer of VS), if you see a "Features" folder with one or more sub-folders in it: you have a SharePoint project that builds into a SharePoint WSP package. That package contains one or more features. Steps to deploy it (avoid using "F5") are: add the WSP (from PowerShell), install the WSP (from CA or PowerShell) and then activate the feature (from Web UI, go to Site Settings). You can find these steps for instance here (they're missing the very first step, witch is to create the package from VS, i.e. clicking "Package" -aka "Publish" from VS2012).
Note that from VS you can also see what components (elements) your features embed: from the "Features" folder, double-click on each sub-folder (one sub-folder is a feature). This will bring you to a feature designer page, where, in the right pane, you can consult what elements (Web parts, custom actions, workflows...) are included.
Also, note that SharePoint solutions do not really use code: they're just a package (a .cab file: you can even rename a .wsp to .cab to get all the contents). That package contains generally a DLL (the actual code written by the developer) and features. Features are made of declarative XML elements. Some elements (like Web parts) use code from the DLL.
From the comments, I understood your solution is actually a sandbox solution, not a farm solution. It mean you don't deploy it farm-wide from PowerShell/CA/any admin tool, but by uploading the WSP to the solution galery of each site collection. And then, you activate it from the ribbon.