Real-world software development methodologies?

As an answer to your first question, I think that my absolute favorite pattern catalog: Organizational Patterns of Agile Software Development by James O. Coplien could be a valuable resource. This book is not about software patterns, is about people, a catalog for creating successful teams.

A lot of stuff from the book is a case study of the successful Borland Quattro Pro for Windows development project This is a remarkably wise book, full of pragmatic advice drawn from real projects. Ultimately, software development is a human experience, and Jim and Neil have captured the essence of that experience in this work Grady Booch I didn't read it yet, but I guess Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software by Scott Rosenberg should deserve to be read also.

As an answer to your first question, I think that my absolute favorite pattern catalog: "Organizational Patterns of Agile Software Development" by James O. Coplien could be a valuable resource. This book is not about software patterns, is about people, a catalog for creating successful teams.

A lot of stuff from the book is a case study of the successful Borland Quattro Pro for Windows development project. "This is a remarkably wise book, full of pragmatic advice drawn from real projects. Ultimately, software development is a human experience, and Jim and Neil have captured the essence of that experience in this work." --Grady Booch I didn't read it yet, but I guess "Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software" by Scott Rosenberg should deserve to be read also.

Accepted for being one of the few answers that actually answered to the question. – Benno Feb 23 '10 at 14:45.

I thoroughly enjoyed the report Scrum and XP from the Trenches.

If you are skeptical and frustrated about how software engineering is taught, have a look at this paper: Twenty Dirty Tricks to Train Software Engineers Many employers find that graduates and sandwich students come to them poorly prepared for the every day problems encountered at the workplace. Although many university students undertake team projects at their institutions, an education environment has limitations that prevent the participants experiencing the full range of problems encountered in the real world. ... Another must have reading, really insightful: Bits of evidence: What we actually know about sw.

Development and why we think it's true I also enjoyed these two articles related to software engineering: Exploding Software-Engineering Myths Frequently Forgotten Fundamental Facts about Software Engineering Academia realized that the gap between theory and practice. Software engineering is nowadays seen more and more as a human-centric activity rather than a technology-centric activity. Most lectures slowly start to reflect this reality.It's however hard to teach the soft aspects of software engineering which relates to interaction between people, changing requirements, risk management, and external factors (financial crisis, product acquisition, etc. ) Software engineering is a broad topic.

It's not only about software design and coding, but also about requirement management, software architecture, human computer interaction and usability, design principle and best practices, software configuration management, product management (or even product line management), quality insurance and testing, risk management.It's now accepted that one of the biggest challenge in software engineering is to deal with unanticiapted changes. That is, we can not plan everything ahead -- goodbye waterfall! Hence the rise of agile approaches.

There are many such processes and methodologies out there, including Scrum, XP, Test driven, Domain Driven, and RUP and its flavours. I'm however doubtful how much success of a project can be related to the process itself. A good team produces good results no matter the process they use (and inversely).

The question is then whether success is reproducible. No Matter What They Tell You, It's a People Problem Is Good Design Replicable? I will conclude with UML.

UML is great, but the usage I've seen in practice stops too frequently to class diagram. That's just a tiny subset of what can be modeled. We should teach modeling, not UML I whish UML was removed from software engineering lectures and move into dedicated lectures, say, "software modeling".

The focus of such lecture would be entirely on software architecture and modeling, while the software engineering lecture would be about team collaboration, quality and process.

It also helps to have a process that is not based on the disproven notion that if one specifies enough detail ahead of time, that the project will be delivered on time, meeting all business requirements. – John Saunders Feb 21 '10 at 22:45.

Don't confuse a successful company with high quality product. And I'm not sure what 'impractical and unrealistic techniques' you are speaking of, but my guess is that they are being utilized to some degree or another by companies that do produce high quality code.

For example, it was suggested that one could use linguistic analysis to design an application. That is, write down a use case in prose, underline all substantives and turn them into classes, underline all adjectives and turn them into attributes and so on. This is done to create an exhaustive UML diagram which can then be turned into code almost automatically.

I would be pretty surprised if this would work in real life. – Benno Feb 21 '10 at 18:43 So you're looking for techniques to be used within a process, not a process itself? – brian Feb 21 '10 at 19:04 Well, I'm mainly looking for examples of real-world usage in large software projects, either of a particular technique or a whole process.

– Benno Feb 21 '10 at 19:21.

Most software development projects use the (outdated but still widely used) waterfall methodology, i.e. A predictive approach, and many of them are failure (they are late and over budget) because the nature of software development isn't like mass manufacturing, things aren't really predictive. Agile methodologies (which belong to the iterative and incremental approaches family) are an alternative to the traditional waterfall and are adaptive approaches, Scrum and XP being the most famous.

I haven't seen Waterfall used in years. – John Saunders Feb 21 '10 at 20:40 @John In France, Agile still didn't cross the chasm so, yes, most project are still using the waterfall (almost all fix bid project are waterfall projects actually). Are you saying that everyone is using an Agile approach in the US?

– Pascal Thivent Feb 21 '10 at 21:02 everyone I've worked with in the past five years have used something somewhat agile.At the very least, there's general understanding that Waterfall requires clairvoyance in order to succeed. – John Saunders Feb 21 '10 at 21:04 @John People are not happy with the waterfall but big companies don't know how to buy agile, they don't have the nuts for that and prefer the good old CYA waterfall contracts. PS: Somewhat agile sounds pretty vague (just doing TDD or pair programming doesn't mean being agile for me).

– Pascal Thivent Feb 21 '10 at 22:03 I guarantee you that I'm using the term "agile" instead of "Agile" because I'm not completely converted. However, "agile" instead of "rigid" or "unable to react to inevitable change" or "thinking that your plan will resemble reality because you produces do much paperwork documenting it", ... let's leave off here, I'm becoming unduly upset. – John Saunders Feb 21 '10 at 22:11.

In addition to what has been already said, I would like to recommend the following books: Code Complete 2 by Steve McConnell The Pragmatic Programmer: From Journeyman to Master Rapid Development: Taming Wild Software Schedules 97 Things Every Programmer Should Know Coders at Work Clean Code: A Handbook of Agile Software Craftsmanship Though not all the books deal directly with your question, they all will help you in your journey of becoming a better software developer. A great online resource that I would recommend is the Empirical Software Engineering and Measurement (ESM) Microsoft Research Group. The article titled Exploding Software-Engineering Myths is a good example of what you are trying to learn.

If you want to know how software is (or was) really produced at Microsoft, take a look at Show Stopper! Which is about the original development of NT. Frightening stuff.

And as a counterwieght to that, read Microsoft Secrets, which is all about their more recent development strategies - and after all, they are moderately successful at this.

Google for extreme programming, agile, waterfall and spiral model, RUP, RAD, software architecture, software development as a process, project management, software as design. You will also find many useful articles and books while doing so. Software engineering in real life is not exact, precise rocket science as taught in CS classes.It is a chaotic process with many possible approaches, that sometimes delivers.

And there is no silver bullet. (UML is a really nice way to visually represent some aspects of software design and the common way to start diving into something as useful as software engineering. But forget phrases like "which can then be turned into code almost automatically" which is marketing bullshit for tools or a placeholder in publications.

Albeit you will hear it many-many times from now...).

We created OPEN/Metis a few years ago in the context of my company Neco, and using research outcomes from my previous work at the University of Santiago de Compostela in Spain. It was successfully used in over 20 projects, and still used today.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.