From analysis to application

Question

Which learning path would you recommend to be able to create complete application from requirement analysis, design (with various diagrams) to coding and testing?

It's not easy to get this knowledge when man does not work for a software company. Is there on the internet some example of this process from requirements to complete application?

It won't need to be very complex, something for a beginner who knows UML, database design and a few programming languages (intermediate level). I prefer the resulting application in Python or C (but in C there aren't classes, so maybe here will be less design). I don't like C++ much. Java is acceptable too.

This is rather easier example of what I'm looking for. The emphasis should be more on design, there don't need to be complex algorithms but show rather putting some working system (e.g. information system with 3 layer architecture) together.

Answer 1

For a nicely described and explained walkthrough of a reasonably productive development process, consider studying POS system case study in Larman's book Applying UML and Patterns...

• As far as I can tell it fits almost perfectly to what you describe as creating complete application from requirement analysis, design (with various diagrams) to coding and testing.

Per my recollection, "testing" part of the walkthrough felt somewhat er weaker than the rest so if you feel the need to dig deeper in that direction, look for other sources. You can probably get better suggestions about that if you ask at http://sqa.stackexchange.com

Answer 2

You might want to start off by reading up on the general software development process on Wikipedia or other sources on the internet. If you require sources in form of dead trees, you may be interested in Ian Sommerville's Software Engineering, which provides you with all the information you need to get a good overview about requirements, design & architecture as well as other topic like change management and project management methods.

To get you started, I would recommend the following: Start off by reading up on user stories and record your requirements in that a way. This will not only save you time in the beginning but also teach you some Scrum / XP basics.

In the next step, define a domain model. You can use UML in this step or choose a simple boxes-and-lines diagram. The main purpose is to establish a vocabulary and to provide a brief overview over the required entities. Now you may want to choose an architecture, i.e. what programming language are you going to choose, which platforms do you want to support, design patterns, libraries & frameworks... You may choose to do this in a formal way, but based on your questions I would say that thinking about it and textual descriptions should be enough for the moment. Always remember though that there should be a reason for an architectural decision in form of a requirement (functional or non-functional) or a decision force (e.g. you are experienced with X or you would like to learn Y). This should help you reduce accidental complexity (quite common a problem when you are starting with software development - don't over-engineer).

If you reached this point, you can decide whether you want to follow an iterative or waterfall development model. Assuming you want to follow an iterative model (recommended), you may choose to use Scrum (or any other iterative process). Follow the Scrum guidelines and you should have a good alternation between design, implementation and testing. You will find more details about Scrum on the internet, just google it.

Of course you may add various additional steps to this process. Please only consider it as a simplified example. For instance you may want to define a relational model or create a UML class diagram.

Answer 3

You are referring to a Software Development Life Cycle, aka SDLC.

In my experience, development is inherently iterative. If you want to formalize it, that's up to your or your management, but you can't escape the existence of flaws and new realizations that cause change. You also can't iterate at scale, you have to iterate in the components.

Depending on the domain, more or less up-front design will be needed. If you want to do heavy OO modelling of the solution, that will take up-front time.

The language you choose is almost orthogonal to the SDLC. However, compiled languages like things defined up-front.

Answer 4

Figure out a minimum viable application which is a small subset of what you want to build. Design the data, use-cases, process model, user interfaces quickly, and the build it and deploy it, and get people to use it.

From that you will learn a lot. From what you have learned, build another subset of your dream application. Incorporate your learnings from the first one. And repeat.

After you have done it a few times, you will learn which parts of the SDLC theory of choice are really useful, and which are marginally useful.

The key here is to move quickly to something that works, and then get feedback to grow your knowledge, and improve your application.

Answer 5

I would recommend reading up on CMMI For Development Level 3, especially the Engineering process Areas. the SEI has some very good free books one the subject.

After you are clear on the theory, follow through the SDLC on any product you want.

For example, pick an idea, develop the requirements, design the app, develop it, test it and deploy it. All while adhering to the concepts laid down in CMMI. You don't have to be as robust as a full CMMI implementation, but choose what applies to your case and follow it. For instance, if new requirements come up, update the necessary documents and so on...

I know CMMI sounds a bit overkill, but if you manage it well, its the best way to fully understand the right way to go from conception to implementation.

CMMI applies to any development methodology you want to use, whether waterfall or Agile, and defining the specifics of development technologies, platforms and infrastructure belong to the CMMI process.

Answer 6

As Paul Nathan has already discussed, you are in learning more about the SDLC. Perhaps the most thorough online resource for that is the IEEE's Software Engineering Body of Knowledge (SWEBOK).

The SWEBOK is essentially an engineering textbook covering the entire SDLC and includes a chapter on software requirements and one on design. It's not a terribly dense read, but neither is it interactive. You'll probably want to also take a look at some other sources to get your hands dirty with some hands-on examples.