Wednesday, March 13, 2013

Software Engineering Body of Knowledge SWEBOK Reflection


The Software Engineering Body of Knowledge guide provides a detailed categorization of the software engineering discipline. The fact that it adopts the traditional waterfall model to begin the description of the knowledge areas in software engineering makes it easy to comprehend. An important feature of the guide is that concentrates on the software engineering process as a whole, instead of describing technologies. Thereby, it gives a thorough outlook of the functional components of the software engineering process. The organization of the document into knowledge areas, sub-areas and topics improves readability and understandability; so one can begin with the knowledge area of interest and then focus on a particular aspect.

Reading through each knowledge area and its topics refreshed my concepts of software engineering. Each knowledge area described in the guide provided great insight into the activities and processes involved in each phase of the software development life cycle. It introduced me to many new techniques, methodologies and concepts such as:
Ø  Emergent properties and FSM (Functional Size Measurement) in software requirements
Ø  Family pattern design, invention design, ADL (Architecture Description Language), and IDL (Interface Description Language) in software design
Ø  Extreme programming, scrum and static analysis in software construction
Ø  Oracle, mutation testing, fault seeding, and difference between fault and failure in software testing
Ø  Different types of maintenance categories in software maintenance
Ø  SCSA (Software Configuration Status Accounting) and SCSR (Software Configuration Status Reporting) in software configuration management
Ø  EF (Experience Factory), orthogonal defect classification and personal software process in software engineering process

An aspect of software engineering that I would like to have seen incorporated in the guide is Knowledge Management, which is gaining importance in organizations worldwide. Although KM is almost equivalent to the Experience Factory discussed in the software engineering process knowledge area, it also comprises of the knowledge and documents which are not part of the deliverables.

Since the guide is a dynamic document, it explains the evolving software engineering standards, best practices and processes and the inter-relationships between them and equips the software engineering professional with the necessary knowledge of what to do in a specified situation.

Wearable computing - Google Glass vs Iwatch

Wearable computing is an emerging technology that two of the biggest IT companies are vying to get their products out - Apple's Iwatch & Google's Glass. While both are significantly different, iwatch is a wrist watch computer whereas google's glass is a computerized spectacle, they are almost competing with the same smart phone application based features.

Here's a funny showdown of the two. Who wins in the end? Wait & Watch..

Tuesday, March 12, 2013

Project Management Death March Reflection

 
The book ‘Death March’ starts by introducing death march project concepts, exploring
various causes and explaining why people participate in such projects. After having
worked on one such project, I have experienced first-hand almost all of the causes and
effects of a death march project that the author mentions.

A study of over 7000 development projects cited in the 1997 edition of Computerworld,
stated that 55% were over budget (with cost overruns of more than 50%), 50% were late
(needing at least twice the estimated time), and 30% were incomplete (the product was
delivered with 50% or less of the planned functionality). These statistics were taken a
decade ago. So as I began reading the book, I thought that in the end, the author would
conclude that death march projects are likely to diminish because the industry is more
aware. But I was rather surprised that the author actually maintains throughout the book
that death march projects are the norm and will continue to be so, which was thought-
provoking.

The "politics" and "negotiations" chapters were engaging with ample lessons to be learnt.
I did not expect politics to be such an important factor in running a project smoothly.
What was interesting to read is the author’s description of death march projects from
differing perspectives of the key players namely the Owner, Customer, Shareholder,
Stakeholder, Champion. It made me realize the role and importance of a Champion.
Also, the negotiation games described were pragmatic. I understood how crucial
negotiations can be to a death march project and how they can be put to practice to
avoid projects from becoming death march projects such as the ‘Two out of three (cost,
schedule, quality)’ rule or the ‘10% change in project variable’ rule.

The thing I liked most about the book is that the author makes candid observations
about death march projects. The author mentions that some of the effects of a death
march project are lower self esteem, depression, and anxiety which I too have come
to witness while working on a death march project. Throughout the book the author
actually presents pragmatic ways of dealing with a death march project such as
not becoming too emotionally attached to the outcome of the project. I enjoyed
reading analogies that the author uses to compare death march projects such as
underground mining, cowboying, high rise window washing and the epitome –
spending a night in jail.

Almost everyone in the computer industry has noticed their workload increasing, while
at the same time the deadlines imposed by their supervisors are shortening. from a very
personal perspective of an individual member. In other words, a death march is just about
every project in these crazy days of compressed development cycles.

This book can be a very good tool to maintain a sense of perspective and help appreciate
the concerns of non- developers involved with the project.

The book then goes on to cover such significant topics as how a Death March project
team leader should negotiate with management for budget, working conditions, staffing,
etc.; how to handle the day-to-day issues of working on such a project, and, just as
importantly, when to know when it's time to get out.

I found this book to be remarkably refreshing in dealing with the true issues of working
in these sorts of environments, and it is far more practical than I had expected it would
be. The book has a Utilitarian approach. It is clearly written by someone who has "been
there" and has no use or time for trite answers. It would have been interesting to see some
of the examples in the book extended along these lines.

It is certain to occasion thousands of thoughtful debates all over the world. At the very
least, it will provide a great deal of practical advice for those "on the march" right now,
as well as at least some measure of relief by letting the participants know that they're not
alone.

In conclusion, I would say that the book adopts a very utilitarian perspective and
provides valuable guidance in identifying a death march project, understanding the
reasons behind it and the effects of it. The book also provides practical advice about
making an educated decision whether to get involved in a death march project or
not.

It hasn't stopped death march projects from taking place. And that death march projects
are likely to diminish. Death march projects are likely to be a common occurrence for
years to come. And that's the primary point of this chapter. You may not agree with any
of the rationales suggested here; you may not like any of the reasons for initiating such
projects or joining such projects—but they're real nonetheless. that such projects can be
an educational experience even if they fail

The books starts by exploring death march project concepts, introducing various causes
and reasons why people would join them. After looking at such projects from a very
personal perspective of an individual member, the author then presents several other

viewpoints - from the perspective of corporate politics and from the perspective of other
people involved in the death march team.

Although my personal experiences are different from one of the key ideas of the book,
that ‘death march projects are the norm, not the exception‘, I recognised several of my
projects in the descriptions of ‘mission impossible‘ and ‘ugly‘. Death March is quite a
thought-provoker, and it made me revisit my own dark experiences, thinking about what
we did and how we did it, why projects succeeded and failed, where we were wrong and
how not to do it again. Case studies in this book discuss problems common in software
development, so the proposed solutions are a good starting point for ideas that can be
applied to improve typical projects.