I am newly employed by a company. After a couple of weeks, I have heard lots of time that there is a huge project which most of the programmers are working on it. They call it something like Managing Everything Software. Then, somehow I got the document which they define what the MES will do. The document itself was 60 pages but contains only about what it does, not how it does.

The document simply describes properties of these softwares:

  • Enterprise Resource Planning (ERP),
  • Human Resources Management System (HRMS),
  • Content Management System (CMS),
  • Learning Content Management System (LCMS),
  • Enterprise Social Platform,
  • Document and Workflow Management System,
  • File Management System that can search on any file type like PDF, Word, etc.(like Elastic Search)
  • LDAP based authentication and authorization

Not only that, all these will be wired to each other.

It may seem those are different software projects but they are not. The project is, to make all of these with one big software:

Most of you already know the divide and conquer method to apply to software development. If it would be me, I would divide those tasks into small pieces. Then define database tables for each piece. Every piece would be responsible for their own data. No other part would have direct access to those tables which belong to other piece of program. If they need to access it, they would ask the responsible program to do it. This is pretty much an architecture of the SOA. But the way this big project is written, never mentions those pieces nor how connections between them will be. According to documentation, every part can see or change any table (if authorized).

Since people so involved in what the software will achieve, they pretty much seem in a position which they had narrowed vision. The project is reflected as silver bullet for all problems. I have to tell them we should slice the project into little ones and connect them like in SOA and this will make everything much more easier. But the problem is I don't know how to convince them that their approach is not the best way to do it. I have to provide solid evidence, sources, books, links and maybe videos to convince them that this is not gonna work.

I couldn't find any documents to support me(since my English is not so great to search this non technical stuff on internet). Can you please provide any information about why doing everything with one software project is wrong?

closed as too broad by Robert Harvey, user40980, gnat, durron597, Mason Wheeler Aug 17 '15 at 18:51

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    The project is, to make all of these with one and only one software -- Not sure what you mean by this. Every software system can be modularized, even if the requirements document describes it as a single system. If your problem is that there is no architecture, then create one, or work with someone in your organization who can help you create one. – Robert Harvey Aug 17 '15 at 14:56
  • 4
    Why do you think it can't be done? This is an odd belief since you don't have solid evidence on the contrary. Do you? At least from what you described it is just a big mountain of trivial things. – Mandrill Aug 17 '15 at 15:00
  • 2
    @RamazanPOLAT I worked on a project a while back... 60 pages was just the executive summary. We had, say, 20 pages per document, and we had a document per component. There were about 100 components. And then we had a spreadsheet describing the high-level (ie no details) requirements of several thousand lines. It sounds like this is an opportunity to learn how to manage and build very large and complex software systems. – gbjbaanb Aug 17 '15 at 15:33
  • 2
    As a manager of a company, before agreeing to develop such a monster, I would probably first evaluate if it is cheaper to buy something like SAP. That is a monster, too, but at least it is working (to some degree). Best advice I can give you is to get your managers a copy of dreamingincode.com and/or "Death March" by E. Yourdon. – Doc Brown Aug 17 '15 at 16:40
  • 2
    @RamazanPOLAT, you'd be surprised how complicated some of us can think, and have actually worked on. Is this more complicated than the combined control systems for a submarine? Been there, lot's of docs, lots of details, but all of the subsystems have to coexist. And the submarines worked :) – cdkMoose Aug 17 '15 at 19:45

I'm not sure what you mean by "one and only one software!" but I think you may be reading too much into this document. Since it talks about what not how, it sounds much more like a high level requirements document for a system and not a single application. This is actually a very important document for any large project. I'm sure that if you were to look at the equivalent documents for SAP or Oracle or MS Windows, they would be larger and more complex, but these were successful projects, so big doesn't mean wrong.

Let's look at the problem a different way. If all of this functionality is needed to help the company function efficiently, doesn't it make sense to have a document that lists all of these parts, so that they aren't all built separately and then don't work together?

It is up to your team to decompose the what into the how. You are on the right path if you believe these should not all be part of a single application executable. There is no reason to believe this can't be done based on the information we have so far. As long as people recognize the size of the effort and the resources required, looks like you'll have work (a job) for a while. Good Luck!

  • I edited the question and tried to elaborate the problem. – Ramazan Polat Aug 17 '15 at 18:34
  • 1
    I don't believe it matters whether you build it yourself or get a partner, a well designed solution can still be done. The biggest reason I see to be concerned about a partner is potentially giving up proprietary company information. I agree that this is an aggressive project, but your last two sentences show how to approach the solution and demonstrate what I mentioned about decomposing the what into the how. You're actually already on the way to solving this project. – cdkMoose Aug 17 '15 at 19:37

You are a bit confused with how software documentation is developed.

What you read is the requirements document. There are entire books written at length of how to engineer and document requirements, but all you need to know is that the requirements document specifies what the software is supposed to do. It makes no mention of how, since these documents are usually shared with management, who have little understanding (usually) of how software is constructed. There is very little to no technical jargon written into this document.

How to accomplish the requirements is up to you - the developer - to figure out. Usually before code is written for a large project, a Design Document is written that explains the how to the what. This is written for the development team so the project can be built and more importantly, maintained!. Here is where you put the fancy diagrams, the languages/technologies you will use, testing methods, etc. If you work for a good company, they will usually let the developers choose which technologies and languages are the best fit for the job.

Essentially, figuring out how code is supposed to meet the requirements is software engineering!

P.S. That being said, if you find the requirements to be impossible (my professors used to call this "wings on a car"), then it is your responsibility to bring it up to your Project Manager. They will then either work with the customer to change the requirements to make it more reasonable, or make you do it anyway. Unfortunately, it usually ends up being the latter.

  • 1
    Thank you for quick answer. The reason I said "60 pages document contains what it does, not how it does" is simply put emphasis on how much things asked from the software to be done. – Ramazan Polat Aug 17 '15 at 15:19
  • "Wings on a car"... nothing is impossible, just more expensive than you're willing to pay! – gbjbaanb Aug 17 '15 at 15:34
  • 1
    @RamazanPOLAT If this is a large project with a corosponding long time frame I dont see an issue. If they expect this to be done in a week then there will be issues. I have seen some truly massive software projects that had entire divisions assigned to them. Size just means more resources are needed to complete the project. – RubberChickenLeader Aug 17 '15 at 15:44

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