The $\parallel$ notation means concatenation. In this case, take the message $m$ (it's a sequence of bits), encode the value $r$ as a sequence of bits, and hash the sequence of bits that consists in $m$ followed by the encoded $r$.
In the step 4, you have a sequence of bits (hash output) that you must somehow convert back to an integer. This is again a question of encoding, but in the decoding direction this time. The underlying theme here is that you must have some convention that lets you encode integers into bits, and decode bits into integers. From a security point of view, the choice of convention is more or less open, but of course it is part of the algorithm specification: signer and verifier must agree on these details, otherwise the verifier won't accept as valid the signatures produced by the signer.
By the way, this is not DSA. DSA is specified by FIPS 186-4. What you describe is known as Schnorr signatures (there are several variants, e.g. on the order of $m$ and $r$ in the concatenation, or whether $s = \alpha h + k$ or $s = \alpha h - k$; all these variants procure more-or-less equivalent security). Historically, the distinction was important: DSA was defined at a time when Schnorr had patented his scheme, and the definition of DSA was carefully made to avoid that patent. Cryptographically, the difference also matters: the "security picture" of Schnorr signatures is better (we can make security proofs on Schnorr signatures, but we don't know how to do that with DSA; and DSA signatures are malleable, a property which is usually harmless but has allowed replay attacks in Bitcoin in the past).
