Introduction
This paper looks at the typical software development methodology and attempts to gain insights from its practical approach to solving any problem. Purusharth or effort making on the part of the spiritual aspirant can gain much from this approach. This method is tried and tested and works very well in the software domain. It is earnestly hoped that the approach would also be of tremendous help in Liberation Management of the Spiritual Kind – Objective Oriented Purusharth.
Cautioning note: This paper uses the Masculine gender to describe the spiritual aspirant. This is merely for convenience. Gender is of no relevance in the quest for perfection.
Stages in Product Development
The stages in the development of any product is as follows:
1) Idea about the Product - Conception
2) Market Survey for finding out the demand for the product – Concept Evaluation
3) Doing a cost benefit analysis - Analysis
4) Developing the product in a quality conscious way - Development
5) Customizing the product to meet customer requirements – Sales & Marketing
6) Keeping the customer happy while making a good profit – Customer Satisfaction
Product Development on the spiritual front
On the spiritual domain, these points can be thought of as follows:
1) The product (or objective in mind) is attaining perfection.
2) Indeed in the current day world, there is a tremendous requirement for souls who
reach perfection in terms of self-development and of character. The customer here is the common man who is usually in a stage of constant struggle for peace, love and happiness and seeks it in different means such as money, power, adventures and so on.
3) The Quest for perfection has the cost that it takes away the mundane day to day life of the aspirant. This is because, the end product is the successfully transformed aspirant himself. The greatest benefit is of course derived by the aspirant because he lives the greatest, the happiest and the indeed the ultimate form of lifestyle ever conceivable.
4) Product Development – or how to achieve this transformation - is the focus of this paper.
5) It is not enough that the aspirant enjoys an elevated state of spiritual lifestyle. The benefits must reach the customer who requires it. The customer in today’s world is confused by the plethora of options he has in front and is often unable to take the right choice. Also, each customer has his own peculiar choices. The successful aspirant should be able to perceive these widely varying and often confused demands of the customer and offer his services in an appealing and beneficial way. Often, the customer needs to be educated for this purpose through proper counselling.
6) The ultimate proof of product quality is customer satisfaction. Unless the aspirant is able to help solve the fundamental requirements of the common man, he has not reached the required quality and would not be worthy of being show-cased as the ideal product.
The Nuts and Bolts of Product Implementation
Now we analyse the core issue of getting the actual product ready.
The basic stages of the software development cycle can be termed as follows:
New Feature Requirements - Analysis – Design – Implementation – Integration Testing – System Testing-Trouble Shooting or Maintenance.
These can be further subdivided into a number of questions or points that enable us to understand the meaning behind these terms.
1) Breakdown the list of features into a set of work-packages. What should be the final product like?
a) Bare minimal features – the essentialsWhat qualities does the man of perfection have? Minimally what virtues and powers does he possess? Does he maintain his state of equanimity and happiness? Is he self- reliant?
b) Extensions – useful features
c) Extras – which make the product a great joy to use
Additionally is he able to grasp others problem situations and give simple and direct solutions? Is he able to impart self confidence in others? Can he transmit his joys to others and help others experience the sublime feelings that he experiences?
Enumerate a comprehensive list of features(or functional behaviour) that are required in the final product and group a small set of related features together. These form work-packages on which individual attention needs to be given.
2) Make a rough estimate of the amount of time required to implement each work-package. For this base it on a evaluation study of the current capabilities of the product
Each aspirant has his own unique stage. This needs to be evaluated with respect to the requirements in the final perfect stage. Estimate how much time each work-package would take if given individual focus and full-time effort.
3) Schedule the features in the order of priority
4) Is parallel activity possible for some features?
5) Write down a functional specification for each work-package. Note down assumptions, open issues, use cases for each piece of functionality ( What are the pre-conditions for use, a step by step description of usage, post conditions which are guaranteed)
The idea of this phase is to get an in-depth understanding of each feature or functional behaviour. What exactly should happen – this needs to be understood. Give a detailed description of each feature. How must the man of perfection behave in any given situation. Are there any pre-conditions (For example, an aspirant may require a quiet environment for being able to transmit peace to others, while the perfect one would radiate peace in any environment)? How can the common man gain benefits from the perfect ones? Some gain by hearing a discourse, others by merely looking on, some others by visualising from afar, yet others through visions…
6) Design the method of fulfilling the requirements. Model the real world interactions that would be required between the product and the user. Draw the scenario. Look at various design patterns, implementations of other products. See if anything is re-usable. Define the external and internal interfaces. Define the various classes of roles that are required. These form the blueprint for action. Inherit from the abstract base class which demonstrates ideal behaviour.
Override the functions to adapt to local requirements. Define the architecture (Client/Server – how can any requirement within be fulfilled? Who as the server, can help in the fulfillment of any requirement?) to be followed. Check out if there are any differences from requirements or from the functional specifications. Write down in plain language how each piece of functionality will be implemented.
This phase is extremely important. Study the real world situations and see various approaches which are being used to achieve product quality. See seniors, others who have been effective in implementing a particular feature and see if the same approach is possible. What should be the minimal external interfaces? (“Come what may, I shall remain cheerful and friendly to others”).
Similarly, the internal interfaces (“ I shall not think negative about anybody”) – how to implement these? See the classes of roles that are required (a friend to all, a father to a few, a student of God, an enemy of none …) but in all respects, the focus is on how to fulfill all the roles without disturbing any feature of another role. This requires various powers – to have a sense of discrimination, to adjust, to withdraw, to listen, to judge, to co-operate and so on. In all matters define a role model – how would this model behave in such a circumstance? If there are no local requirements of the customer, the default behaviour is to do what the role model would do. The role model is an abstract base class (something which does not actually exist at present but determines the basic functionality).
Cross check the design with others. Does it look OK? Let them give review comments. Incorporate these immediately in the design.
7) Implement the feature. Borrow extensively from the idioms of implementation already in use. Use the existing library of functions as much as possible. Do not re-invent the wheel. Follow the given implementation guidelines as closely as possible. Make alterations or deviations from the guideline only if absolutely necessary and with due documentation. Review extensively. Incorporate review comments methodically. Document this. This step requires total compliance to the set design. If the design is strong, then this stage is almost mechanical and fast to complete. If problems are encountered in implementation, go over the design and implementation procedure again and again till you spot the fault. Use the remedy specified in the design and overcome the problem. If problem persists, either the implementation has been improper or the design needs to re-evaluated.
8) Do white box testing of internals. Given a particular set of inputs (inside or outside the expected range.) Check what happens within. Check for abnormal behaviour. Catch exceptions if any. In white box testing, every particular action is analysed to see if correct behaviour is seen. Its like testing going on in a box in which the contents can be observed from outside. Spiritually, this means that examination of every thought which comes across during a problem situation should be checked it is as per the design.
9) Do black box testing. Given a set of inputs – normal, abnormal, repeated normal, repeated and abnormal, wildly abnormal conditions – check out the outputs. Do they match specifications? Check Fault Tolerance. The common man is usually unconcerned about how the aspirant thinks. The aspirant is a black box, only the end result matters. Given a situation ( good or bad), how good is the aspirant?
10) Integration Testing – when all attributes or functionality is simultaneously required does one suffer when another is used. Does all the functionality integrate well together in a cohesive and balanced manner? This is to check if the variety of roles and demands that are set upon the aspirant can all be fulfilled by him in a balanced and integrated manner. For example, it is to be ensured that the aspirant is a great student put not at the cost of being poor as a friend of others.
11) System Testing – How does the product when handled by a lay user? Expert user? Malicious user? Is the product stable in all conditions, providing either correct responses or appropriate helpful error messages? Does the product work well in extreme environments? This test puts the aspirant into real world environment. All sorts of problem situations are posed in front. Is the aspirant really qualified to be call ed a perfect product? Does he pass the stringent quality standards that will certify him? Is the product free of Bugs (problems) and ready to serve the customers fully? Any problems that are found need to be repeatedly corrected until the desired stage is reached.
12) Is the product liked well by the developer, the company (the boss), the customers? Does it attract new customers?
Conclusion
The software approach to problem solving is very effective. This is because, its done iteratively till the zero-defect standard for the product is reached. The same is the goal for the spiritual aspirant. Large goals or objectives are broken down into more easily understandable and tangible features and they are evaluated, understood, and solved in a systematic manner. Testing if the desired objective is met, peer reviews and incorporation of corrective feedback needs to be done in every phase. This approach is very robust and practical. It is hoped that these ideas will be incorporated into the daily lives of the purusharthis so that they gain the benefits of Objective Oriented Purusharth.
Further thoughts on the topic can be had: A proper feedback mechanism for realising potential bugs (problems) and incorporating changes to counter these. An evaluation and appraisal scheme for checking. An accounting set up to see the number of man-hours spent on any given task. Training camps to learn help and improve in any given area of functionality and so on.
No comments:
Post a Comment