This title is inspired by an IEEE paper 4+1 view model of software architecture.
The referred paper on software architecture suggests five views to organize description of software architecture. This helps to separation of concerns, with each view addressing concerns of a specific stakeholder role like programmer, designer, integrator, and system engineer with usage scenarios being central to all.
Similar approach helps to understand and manage game development. Note that I am referring to game development; not necessarily game architecture. It helps to look at game development from various perspective with gamer perspective being central to all.
These are not necessarily orthogonal; rather elements of one view are connected to elements of another just as in case of 4+1 view of software architecture. Each view helps define focus on specific stakeholder concerns, and in turn, roles, skill sets.
There have been many discussions in the past on whether software development is an art, craft, science or engineering. For convenience, I am listing below the major ones that had profound influence on my thoughts over years
1. Book Software Craftsmanship – The New Imperative
2. From Craft to Science Part 1 and Part 2
3. The great art and craft of software development
4. Software engineering and the Art of Design
5. The art, science and engineering of software development
6. Manifesto of software craftsmanship
7. The privilege and responsibility of software development
9. What is software design?
10. Software that lasts 200 years
My view is that software development is a combination of all of above. My view is also that software is a construction of human mind or rather minds; and should I say human brains. Yes, mind and brain. Emotion and intellect. What is important to me is this human creation has pervaded virtually every aspect of life and business by now, unlike any other human creation, and hence business critical.
It is an art, it is a craft… beyond all that business depends on it; life and career of many depends on it. Hence, it is important to bring in continually better control, better quality, better transparency and better predictability into software development. Taking recourse to engineering is to this end. Engineering is not an end in itself but a means to an end. Engineering as a manager’s tool to have better control, better quality, better transparency and better predictability. From that standpoint, we find that apparently conflicting perspectives are not truly conflicting; they are different dimensions of software development.
Every successful software development manager knows this and manages his/her business accordingly. These fits into my overall management-engineering framework; result of applying learning into practice, and continually refining my learning based on observation.
It feels great to selected to presented at IBM Rational Software Development Conference 2009. Unfortunately, due to personal priorities, I would not be able to make it to the conference.
Success (QM15: Effective Test Automation of SAP Implementations) would be presented by my manager Vipin Kumar (Managing Director and Software Engineering Evangelist, Astra Infotech Pvt Ltd), who has played a crucial role all through for the success of this project
Following are my comments on “What’s your opinion? Which is best? RUP, Scrum, or XP?” in Agile Alliance group in Linkedin
Why not RUP and …? RUP is a process framework/knowledge base and not a prescriptive process. You rather use RUP to derive a process instance
Great to see the active and healthy discussion and hope to see this progressing further.
In this context, I would like to reiterate and substantiate my statement that RUP is not a process but rather a knowledge base and process framework. Lists of activities, relative order in which they should be performed, which artifacts to create, and dependency between them are more of guidelines/reference, and not meant to be prescriptions. Interesting links to read in this line would be: http://www.agilealliance.org/system/article/file/941/file.pdf and http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jan03/StoryOfRUPManager_TheRationalEdge_Jan2003.pdf . There are many more but I hope these links clarifies
One does not adopt knowledge base and process framework. Rather, you pick and choose from it. I agree, “extract any element of RUP you think you need on a given project and add it to Scrum”, as pointed out by Richard, is the right way to use it. Meaning, in that case you are using RUP as a reference, and not as a textbook or bible. Again, you need not worry about size of encyclopedia if you know what you need from that
Again, I believe, good architecture and design is important for software development and role of architect, for me, is in war front (and therefor, hands on and continuous; again in sync with RUP), and not in the control room. Such architecturally-orientation is not in conflict with agile practices. In my understanding, what agile practices stand for is ‘right sized” architecture or design, rather than discounting their value.
Incidentally, I do not ask my customers to adopt RUP but I present to them as a knowledge base only. I also use it as a knowledge base, at the back of my mind, in my consulting service.
I would like to hear from you on your thoughts and on what you find in as conflicting
Rational Software Corporation was a company that I longed for, worked a couple of years there and still cherish my days there.
Going through my old records, I picked up my farewell note to Rational. It reads as below:
Farewell to ‘Rational’
Firm stands ‘today’, the moment of truth
Basking in the glory of the yesterday
Lo ! beckons the future, excitements set forth
It is time for me to move on, I say !
Shall stay with me, for ever and ever
Some ‘Rational’ thoughts, so fresh as ever
The joy of sharing, and caring for another
The fun of learning, and working together
It hurts to say ‘bye’, dear ‘Rational’
Oh! my friends, it pains to bid ‘farewell’
We shall meet again in the world, so small
We shall hold together, with a heart no small
Let me be gone now, for a while
To join our hands again, in a little while
For some purpose, quite worthwhile
To help our customers, with a sweet smile
I set forth to achieve certain tasks back in 2002, and on retrospection, I am glad to have
Often Software Factory and Model Driven Architecture as two orthogonal approaches.
For me, both are two different perspectives of software product engineering. Abstract and concrete modeling and transformation, and production at a software factory as dictated by production process dictated by architecture go hand-in-hand to make a successful product line
A great day indeed!
IBM publishes Astra Infotech‘s case study for test automation of SAP implementation. IBM’s FIRST IBM SAP Reference Case Study with Rational!.
Development of quality software requires a rigorous software architecting and design effort, and development strictly controlled by defined architecture and design. Astra Infotech‘s solution Astra Model Creator supporting model driven development is now ‘Ready for Rational Software’