5

I am taking a module called "Requirements Analysis & Design" in a local university. Common module, I'd say (on software development life cycle (SDLC) and UML). But there is a lot of things I wonder if they are actually (strictly) practiced in the industry.

For example, will a domain class diagram, an not anything extra (from design class), be strictly the output from Analysis or Discovery phase? I'm sure many times you will think a bit about the technical implementation too? Else you might end up with a design class diagram later that is very different from the original domain class diagram?

I also find it hard to remember what diagrams are from Initiation, Discovery, Design etc etc. Plus these phases vary from SDLC to SDLC, I believe? So I usually will create a diagram when I think will be useful. Is it the wrong way?

Improve this question
1
  • 1
    The answer Péter Török provided below describes it well. Every place has its own process, its own types of documentation and diagrams, and its own variation of the traditional SDLC. University is trying to prepare you by teaching a strictly formal and overbearing process so that when you get into the world you will have been exposed to all of this already and hopefully be able to adapt more quickly.
    – maple_shaft ♦
    Nov 16, 2011 at 12:15

3 Answers 3

Reset to default
9

Practices and SDLC within the industry vary wildly from company to company (or even from team to team within the same company). From your description it sounds like the SDLC as taught in your university is a more formal, heavyweight, non-agile process. There are lots of projects following such processes (using differing terminology, tools and artifacts, e.g. some produce long Word documents as the outcome of analysis, containing pure text, others use some UML diagrams, yet others diagrams in a completely different notation system...). There are also lots with close to zero level of formalized processes. And anything in between these two extremes.

So the bottom line is, there surely is no single Right Way to do this. Once you start working in a concrete project team, you will get to learn and adhere to their local conventions and processes anyway (which, chances are, will be quite different from what you were taught at the university).

But if you have the chance to choose/shape your SDLC, I suggest you be pragmatic. Use what works for you(r team), regularly reflect on the problems/issues you see, and adapt your process/tools accordingly. As a starting point, I recommend investigating some of the low-ceremony, developer-oriented Agile methods.

In these, the various phases aren't strictly separated: it is acknowledged that one can't create the perfect requirements/design up front. As you mention, in practice you will think about the possible design(s) for your domain model, and the possible implementation(s) of your design in advance, and you may even create a quick prototype to verify some assumptions early on. Also, during design you will get new questions and insights into the requirements, and during implementation you will get new realizations which will change and refine your design.

Improve this answer
2
  • 1
    Industries that are less agile tend to have similar SDLC. Take the automotive industry as an example, many of the suppliers follow a very similar SDLC, including similar documentation. Usually these SDLC are mandated by regulations. I would imagine medical or aerospace would have an even less agile SDLC, and the SDLCs would almost be uniform across the various companies.
    – tehnyit
    Nov 16, 2011 at 13:34
  • 1
    +1 for Long Word documents as the outcome of analysis, containing pure text and I wish to give another +1 although I cant for "It is acknowledged that one can't create the perfect requirements/design up front."
    – Karthik Sreenivasan
    Jan 20, 2012 at 5:45
5

These are just my experiences: I've never worked for a company that strictly followed an SDLC. I've worked for many companies that had an SDLC, but never one that followed it even remotely.

IT groups tend to grow organically with the business, releasing software quickly and responding to customer demand. Eventually IT grows 'big enough' to have multiple layers of management and a CTO (IT is 'important' now).

Then something goes wrong - under pressure from customers, IT ship a buggy version of an important application, and the bottom line is impacted. The wider business reacts: "How could you allow that to happen?"

After fixing the issue, IT need to be seen as responding to make sure it never happens again. So they introduce policies and bureaucracies, and SDLC's are documented. The SDLC isn't actually intended to improve IT's ability to deliver quality software on-time, but to placate the CXO's at the next board meeting. So it's full of bluster and pomp designed to impress the CFO and CMO and any external analysts that anyone decides to bring in. Everyone involved knows it's a pretentious waste of time and won't be followed, but they go along with it like bogans testing the wine at a restaurant ("mm... it's red!").

Developers of course go back to working in agile ways, building things users ask for and short-cutting the red-tape where possible. Some parts of the SDLC are followed - release sign-offs for example - but most of it is done simply because that's The Policy and questioning it is too politically sensitive.

Developers do tend to draw diagrams and design object models, but they happen very organically and where necessary, not strictly as part of a Phase, unless that's The Policy in which case it's usually rushed just to get it out of the way so real work can begin.

Improve this answer
2

Below is my own view of things. It is based on my experience as someone who worked in a company that had a successful SDLC long time ago. Funny, I left another large company, because their miss-use of SDLC! I can't say that all what is here is currently valid in today's methodologies and techniques though.

Conceptually SDLC is a set of consistent and integrated processes to deliver a product. The primary goals of a methodology are to:

1 - Define work phases and deliverable so that project management becomes possible.

2 - Define a conceptual platform that the organization could enhance as it grows up using industry best practices.

3 - Stop the organization from re-inventing the wheel with every project by identifying inputs and outputs of each task/stage

4 - Minimize the state of chaos in the development process minimize the dependency on a single or a specific set of people in the organization to know everything - This is achieved by good documentation and involving different levels in the process

5 - Enhances the communication among the product development, management and other parties in the organization by establishing a set of agreed terms, KPIs and tools of communication.

The SDLC achieves its goals by utilizing the best suitable practices and tools at each of its processes.

Setting up/choosing an SDLC is not trivial and performing SDLC tasks is valuable.

UML is not SDLC and vice versa. UML is one of the tools that may be adopted by a given SDLC for producing software products but then again it might not. You will not find too many Mainframe CICS developers using UML for example.

as per your point:

Blockquote For example, will a domain class diagram, an not anything extra (from design class), be strictly the output from Analysis or Discovery phase? I'm sure many times you will think a bit about the technical implementation too? Else you might end up with a design class diagram later that is very different from the original domain class diagram? Blockquote

You are correct in some of this. A domain mdoel is not necessarily a design model. The difference between the two is that a domain model (called different things depending on the methodology you use) is supposed to collect important facts and rules for business during the business analysis stage. The concept of an object in analysis is very wide. The objective of such a model would be to store the collected information in a form that can be used by the designers. It is usually built by analysts so if the two class diagrams look similar, then either the subject is trivial, or has one solution only. The objectives of the technical model is different. It inherits the rules, data and business objectives from the analysis model but shapes it toward code generation, specific database requirements, and performance. It is completed by software engineers and not analysts. As a result it is different. For example a Customer Number may be a good key for Customer Enitty in analysis, but in the database it ends to be implemented as a column with unique index and a sequence number is used instead. It is also not uncommon to see the customer class converted to an abstract class and different types of customers get their own classes (or vice versa)!

Regarding your question:

I also find it hard to remember what diagrams are from Initiation, Discovery, Design etc etc. Plus these phases vary from SDLC to SDLC, I believe? So I usually will create a diagram when I think will be useful. Is it the wrong way?

The methodology should define the stages of the development process and which diagrams should be produced by which professionals and which tools to be used for doing this.

For example, should analysis sessions include prototyped web pages? A prototyped web page is definitely not a UML diagram! In general, you need to define and refine your:

Use Case Diagrams

Class Diagrams

Activity Diagrams

State-Machine Diagrams

Each of the above diagrams have a purpose. If you study the purposes well, it will be clear to you when to use it.

and don't forget your Data Model diagram (ERD) - But ERD is not part of UML. Again, UML is not enough, at least, almost always it is not enough. You need integrated tools and a methodology and above all people to get the work done right.

So, you create a diagram when it is useful, that is OK but if you are working in a team with a methodology you need to follow that and don't forget to allocate time for it in a project plan too.

At the end of all this, please distinguish between SDLC, UML, Project Management - They are different things (at least to me!).

Good luck.

Improve this answer
1
  • +1 - Thanks for the explanation. It was clear and very detailed description.
    – Karthik Sreenivasan
    Jan 20, 2012 at 6:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.