Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Software Engineering Process...

Options
  • 23-08-2017 4:13pm
    #1
    Pelvis
    Closed Accounts Posts: 1,758 ✭✭✭


    I was just wondering, having had to study this stuff, are the various techniques available to develop software actually utilized in the work place? As in structural/behavioural modelling, use cases/class diagrams/sequence and state charts etc?

    I'm not involved in dev with my current employer, but using our systems, and knowing the workload they have, I would be surprised if this kind of planning is done.

    Just curious if this stuff I'm learning will be put to use. As it seems like the right approach!


Comments

  • Options
    #2
    Idleater
    Registered Users Posts: 6,236 ✭✭✭Idleater


    I've used it (UML/modelling) mostly during interviews when asked model XyZ questions. In real life haphazard lowest common denominator whiteboard pictures were most prevalent for me. In my case explaining use cases involved discussing with non technical (or people that should know possibly?????) so there ended up being a lot of "arrows on the whiteboard between boxes"

    That said, now I've moved to a bit more front end and have "wireframes" that show a theoretical (oh sorry customer ideal) flow between pages that ignores business logic or reason.

    Planning wise, I've really only done "Agile" including quotes, so have been shielded from pure waterfall, probably through denial.

    When actually developing, modelling is definitely used, and behavioural/structural etc patterns are pretty important.


  • Options
    #3
    ginger_hammer
    Registered Users Posts: 147 ✭✭ginger_hammer


    In my experience it depends on the company, if its a large place with 10+ software people then maybe yes you have a more structured approach but never on the level that I learnt back at college. Working in smaller places where there is only you or 1 or 2 others on the IT side then no, just make it as quick as possible with as few bugs as possible. You won't be revisiting it to improve efficiency/speed as you move onto the next project. Sometimes you are very lucky to even get a requirements document, any formal testing, sign off, etc. It just depends on the size and function of the company you work for.


  • Options
    #4
    s7ryf3925pivug
    Closed Accounts Posts: 4,007 ✭✭✭s7ryf3925pivug


    I use UML to sketch aspects of software and to reason about it. I use the philosophy in UML Distilled by Roger Fowler, which is an excellent book that suggests UML is more valuable if used loosely in this manner rather than strictly to rigorously define systems. I would use it more than anyone else in my company afaik. (I'm a senior dev in software development company where agile development is the norm).

    Sketching things on paper is really useful for reasoning about things. Got to say I'm liking using my new surface to do the same thing, but then have digital file of same thing afterwards, can replace my ****ty handwriting with typing and put it on a wiki.

    I would definitely recommend UML as a tool for reasoning and communicating about a system above it being used for strictly formulating it, and above not using it. I would definitely recommend UML Distilled.


Advertisement