1. Product vision (shared across all stakeholders of the project)
2. Product development plan (including risk identification, anticipation and mitigation)
3. Business case (justification: financial, market and technical)
4. Product architecture
5. Quality assurance and control
6. Maintain conceptual and structural integrity, and traceability, across all work products
7. Flexible but repeatable process
8. Pre-sales support plan (must include getting people in, getting them up to speed and retention of key resources)
9. Post-implementation support plan (must include getting people in, getting them up to speed, retention of key resources and knowledge persistence)
10. Product champion and a core team of code warriors of at least 3-4 years of experience
11. Infrastructure (including hardware, software and network)
12. Maintenance and change management plan
Have you been looking at your crystal ball to see where IT is headed? Read Gartner Highlights: Key Predictions for IT Organizations and Users in 2010 and Beyond .
Particularly interesting, looking at it from India, is the prediction that ‘India-centric IT services companies will represent 20 percent of the leading cloud aggregators in the market by 2012’ is interesting.
Prediction that ‘mobile phones will overtake PCs as the most common Web access device worldwide by 2013’ indicates a changing landscape of computing. Computing was once a terrain for techno-geeks; it is now an irreplaceable aspect for everyday life, tool for business and platform for collaboration. Is it not yet time we get serious about it?
Pardon me if my statement “software engineering is hard” sounds like a cliche. Lest it sound like I am parroting what Grady Booch has already stated “software development has been, is, and will remain a fundamentally hard profession” , let me elaborate. Here, my reference is not about software development being hard due to inherent complexities and invisible changes. It is rather about doing business in a changing world. What does that mean?
If one were to hibernate for about five years, world of software that you see would be quite a lot different. Changes may not be fundamental but there are significant changes. Well, as always, devil is in the details.
Let me elaborate going a little more specific now. Let us look at from two perspectives.
i) Analysis and design: Object Oriented Analysis and Design was quite in the hype early 1990s. I too joined the bandwagon, going around with the hammer looking for nails. Books on object orientation from those days talked at length about finding abstractions (identifying nouns etc) from requirements but these provided no scope for working with technical solutions. This was largely left to the discretion of individual practitioners. Experience of these practitioners were absorbed into standard Object Oriented Analysis and Design methodology taking it to its present bloated form. This happened in a span of 5-10 years
ii) Software Testing and Software Test Automation: Way back in 1990s, when popular testing tools like IBM Rational Robot (then called SQA Robot) and HP (Mercury) WinRunner came into being, popular success of web could hardly be envisaged. What was started off as tool to testing Windows GUI application had to extend itself into test web based application. These challenges continue as web 2.0, SoA, SaaS and mobile applications emerge. Point here is, when projects are undertaken in respective technologies, necessary tool support is not yet in place often. It is left to the individual teams to create custom solutions, which subsequently get into available tool sets.
These details are rarely look into, at decision making levels. Management of software development business are still desperately looking for mythical silver bullet solutions. Tool vendors still continue to promise magic wand solutions without looking into details before making such promises; well, it is again business! Developers are caught between …
I am not proposing a miracle solution. No such solution exists. My effort all along my consulting practice has been, and will be, to get business into sufficient level of details in decision making and helping them implement the same. With the scope for factoring in “Success Critical Stakeholders”, I find Value Based Software Engineering to hold potential as framework for such a deliberation.
Are you looking for a good book on Architecture? Then, Microsoft Application Architecture Guide, 2nd Edition is a ‘must-read’. Though it is tuned to working with Microsoft technologies, much of topics covered have larger relevance. What I like about this book, compared to other books on software architecture, is practical relevance and ease of application
Hats off to Microsoft for bringing architecture from the elite glass house to developers’ workspace!
As software permeates every aspect of daily life and as we depend more and more on software in all walks of life, quality of software gets to be of utmost importance.
World has come a long way from the early perceptions of quality as a natural consequence of following a good process. Agile community has asserted umpteen times, reflecting in manifesto of software craftsmanship and agile manifesto, quality of software that add value to users in their context is far more importance than religious, and often dogmatic, adherence to process.
People, process and automation are three different, orthogonal but often inseparably interrelated, factors of what goes into making of a quality software. These form different dimensions that call for attention of a manager of software development project, and not conflicting goals as they are sometime made out to be. Managing software development project is not progressing on one dimension at the cost of another but working with a dynamic balancing of these dimensions through the course of project
It is interesting to note, in this context, emergence of a consortium focused on software quality. It is a step in the right direction. I hope that this would help in making life better for its users and customers
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.
When I look at game development, as a software engineer, is a striking similarity to what we have gone through in software development.
Most critical milestone was awareness of software crisis and decision to adopt an engineering approach to software development. That essentially meant applying principles and practice of engineering into software development.
Is it a right thing to do? There are pros and cons to the argument. Can we development software with a predefined process? Is software development process prescriptive or adaptive? It is very project specific question. There are software development projects which are very mundane and There are ones which are highly complex, and exploratory. There are simple ones where one could go very light and instinctive; small team, developers with good skills, great motivation, and synergy. In a well managed projects, even the latter ones tend to get predictable and prescriptive over a period of time. It is always a project specific judicious mix.
Where we successful? Yes, to some extent. Sure, there were many stumbling blocks. I value the initial commitment to engineering irrespective of whether one agrees to engineering approach to software development or not. Even such a discussion can take place only in the context of related learning from the practical adoption.
I am tempted to explore possibilities of engineering game development, on similar lines and learning from the mistakes of past.
Following are my comments on “Why do you want to adopt both CMMI and Agile ?” in Agile CMMI for Software Professionals group in Linkedin
CMMI is about measured capability maturity, primary beneficiary being the organization/project itself, and marketing advantage being a by-product.
I have worked with customers on their way up the CMMI levels. For some of them, I am sure, primary motivation for going on with CMMI was not marketing but rather demonstrated/proven capability maturity.
Agile approach is about effectively doing software development, being open and honest with all stakeholders across the board; focus being brought back from documentation (at times, misinterpreted to mean process) to customers, milestones, deliverables and team.
Fundamentally, being agile is a statement by yourself, about yourself, to yourself. You are not agile because someone wants you to but you believe you are doing the right things by adopting agile practices and you follow them for their benefit
I consider both as two sides of the same coin (software engineering), rather than conflicting interests