Sciology = Science + Technology

Commonsense in Technology

Archive for the ‘Process’ Category

Proactive Maintenance is crucial in all industries !!!

Posted by sureshkrishna on June 7, 2009

During the start of my career as a Software Engineer, my first assignment was to maintain a COBOL system that used to transact approximately 5000 records per hour. It was very huge and challenging system with web and AS 400 system integration. During the start of the career, the general idea for me as a Computer Engineering student was to build software framework and systems with fancy programming languages and databases. Once i was thrown in to the COBOL maintenance, i was kind of dejected for initial few weeks. Luckily, my manager noticed this and made me understand why is it important to maintain software systems and what can one learn from it.

I am writing this article to remind all the developers and designers of the software/hardware systems in all industries about the maintenance of the critical systems. A problem, which everyone thinks small could become big or crucial or critical in certain circumstances. All the industries face the same problem that any system can not be tested with all the real time scenarios. The test data or test cases for any system are limited and time bound, So can not be trusted for 100% test coverage and safety of system.

Very often we encounter the “refactoring” dilemma in the software industry. The question that comes to everyone’s mind is should we refactor “NOW” or put it off for later “trigger” ? All projects are faced with the following challenges, which makes a project to decide if a “refactoring” is necessary at that time.

  • short time
  • limited budget
  • non-availability of resources
  • pressure from sales and marketing and
  • finally pressure to deliver

We always tend to postpone and procrastinate the code, design and architecture refactoring. Very often “shit happens” and the cost of refactoring is sky rocketing. Customer is angry, development team gets demotivated and project stakeholders are unhappy with the system performance. Some of these problems are addressed by the agile methodology (TDD, SCRUM, XP, RUP, etc…) and some are addressed by the timely act of “experienced” leaders in the industry. However good is a methodology or a process, finally everything depends on the people who implement it. So many times i get “upset” when big organizations talk about “people independant” process ???

Finally, i was moved by the recent incident of the Air France flight (Rio de Janeiro to Paris) havoc, which probably seems to be a problem with some failed hardware. The news seems to be that the hardware sensors had to be replaced some months back and for some reason they did not do it. Irrespective of whether this is a hardware failure, it calls for everyone to be more attentive, proactive  and creative when building the critical applications and systems. Following is an excerpt of the news from internet.

Air France issued a statement with details about the monitors hours after the French agency investigating the disaster of Flight 447 said the instruments were not replaced on that aircraft – an A330 – before it crashed last week into the Atlantic Ocean en route from Air France issued a statement with details about the monitors hours after the French agency investigating the disaster of Flight 447 said the instruments were not replaced on that aircraft – an A330 – before it crashed last week into the Atlantic Ocean en route from Rio de Janeiro to Paris.

Air France said it began replacing the monitors on the Airbus A330 model on April 27 after an improved version became available.

Pitot tubes, located on the exterior of the aircraft, are used to help measure aerodynamic speed.

Aviation officials have said the crash investigation is increasingly focused on whether external instruments may have iced over, confusing speed sensors and possibly leading computers to set the plane’s speed too fast or slow – a potentially deadly mistake in severe turbulence.

An Air France statement said that icing of the monitors at high altitude has led at times to loss of needed flying information.

However, the Air France statement stressed the recommendation to change the monitor “allows the operator full freedom to totally, partially or not at all apply it.” When safety is at issue the aircraft maker issues, rather than a recommendation, a mandatory service bulletin followed up by an airworthiness directive..

Air France said it began replacing the monitors on the Airbus A330 model on April 27 after an improved version became available.

Pitot tubes, located on the exterior of the aircraft, are used to help measure aerodynamic speed.

Aviation officials have said the crash investigation is increasingly focused on whether external instruments may have iced over, confusing speed sensors and possibly leading computers to set the plane’s speed too fast or slow – a potentially deadly mistake in severe turbulence.

An Air France statement said that icing of the monitors at high altitude has led at times to loss of needed flying information.

However, the Air France statement stressed the recommendation to change the monitor “allows the operator full freedom to totally, partially or not at all apply it.” When safety is at issue the aircraft maker issues, rather than a recommendation, a mandatory service bulletin followed up by an airworthiness directive.

Posted in News, Process, Quality, Reviews, Technology | Tagged: , , , , , , | Leave a Comment »

Applications have mysterious processes !!!

Posted by sureshkrishna on December 13, 2008

Even after these many years of software development, there are some applications that still bother user with a lot of processes and memory consumption. I am not surprised if such applications are from the novice software vendors, but the matured technology companies like Google and Real Networks do develop some applications that annoy me.

googleupdate

realnetworks

As soon as i boot my windows machine, these process would start and sometimes i wonder how does my machine hit on the performance. Now, i go and kill both of the Google Updater, Real Networks processes in the process explorer.

kill_both

Recently Google has the Video plugin and it still sucks (:-(). There are so many times that i kill this process and i get the same process spawned multiple times. I cant kill this process for some reason and it always spawns a new process, each time i kill (Google might think it is a smart thing to do) . I was under the impression that Google does some magic by not using any dlls or exes but i was wrong. They do use the gooletalkplugin.exe directly attached to the browser.

googletalk

I am sure that a simple home user would not mind (to some extent) having all these *^$*^$ processes around, but as a programmer i do not feel this is a good practice and as a consumer, i feel cheated. e.g. Google could have just asked users to install the Google Talk and use it for the Video chat, instead of giving an impression that it runs right from the browser.

This is a good example for me how NOT to build products and how NOT to ignore what goes inside the processes and memory. I am sure many of the readers would have seen similar situations and sometimes even would have felt frustrated. Do you think such sort of things from software vendors is fair ? What are your experiences ?

Posted in Plug-ins, Process | Tagged: , , , | 3 Comments »

Is SEI-CMM L5 better than Agile Methodologies ?

Posted by sureshkrishna on September 15, 2007

I was working with a company which moved to CMM L5 and spent lot of $ on going for appraisal. I saw how the quality department and some of the (unlucky) project managers had to run around for the CMM L5 appraisal. Till that time I was more used to XP and Scrum for almost 3.5 years. Now as everyone would expect its very very difficult to get into the CMM mindset level from Agile methodologies. Of course in the end both processes are aiding us to achieve a good Software Product. As a project Lead i had the responsibility to implement a SW Development process. My manager was reasonable enough to listen to me and see the differences between CMM L5 and Agile practices.

In this article i want to explain how i convinced my management to adapt Agile Development for my project. I moved from CMM L5 to Agile Development. The comparison shows how i achieved each process area of CMM via Agile practices.

Some how in the industry there is a misconception that the Agile practices will lead to “Code-Test-Fix” cycles. Many fears that this process would lead to non-deliverable product , etc… In any case i had to convince few stakeholders in my organization to try these practices and see if it is better and makes sense. My Manager, QA Lead, QA Manager and customer are the main stakeholders who would be interested to see what the new process would be and what would it bring to them without disturbing any of the current Organization Level Metrics/Statistics. For me i had the advantage that the customer is working with the agile practices for a long time and there is no need to explain him what it was.

Let me explain the project that i was working for, so that you get the environment where i implemented this. This was a project with 10 team members in India and 5 team members in Germany. We had a time difference of 3 hours daily and we had full access to the Phones and Video Conferences. Everyone speaks english and the entire team knew each other. We have been developing a Eclipse based IDE for automobile systems and we were using CVS as configuration management system, JIRA for the Requirements, Work break up as issues, Bugs and Enhancements processing, Release management, estimations, tracking, we also linked JIRA and CVS via fisheye so that the traceability is not missed. Hummm….i definately have used a lot of JIRA, but trust me it worked perfectly (some say that i over used it). Every one is happy that they do not have to use any other Requirements Management tool (like Clear Quest), Bugs tracking tool (like Bugzilla), Project Management tool (MS Project), Team Tracking tools (PS7 and PC Team), etc… The important thing is that the developers and leads have to use only the Eclipse, CVS and JIRA; Thats all is the environment that makes your product development happy. We do have team members with varied experiences ranging from 12 years to 1 year.

In this article i am not going to explain the agile practices that we implemented but i will limit it to the differences that i found and we tackled with Agile Methodology. For Agile Methodology i have taken few practices from XP and practiced SCRUM. Following is a overview of the comparison that i had done. Of course i finally got the approval to go ahead with the Agile process that i proposed. But it was a lot of work to convince the management. I hope some of you who had done the same would agree with me 🙂 .

CMM and Agile.

Now its the time to look into each key process areas of the CMM and see how Agile Processes/Practices can help. Please make a note that i have mentioned Eclipse, CVS and JIRA in some of the process comparisons as tools that supports process implementation.

Project Planning & Integrated Project Management

  • Joint development with the customer
  • Life Cycle
    • No distinct phases, “Daily Development“, “Daily Integration”, “Daily Reviews”, “Daily Testing” and “Weekly Deliveries”
  • Estimation technique
    • Milestone (Sprint) planning is expected to be flexible. And customer has a knowledge of development on daily basis.
  • Tools recommended by customer
    • JIRA for planning, scheduling, tracking and OPL

Monitoring and Control

  • Team meetings, corrective actions, risk analysis is a daily ritual.
  • Agile methodology which is flexible, responsive, builds a self-managed teams
  • SVL, OTDQ have no importance. Sprints are flexible enough to accommodate various situations.

Quantitative Project Management

  • Flexibility is key. SVL (Schedule Variance) , OTDQ (Ontime Delivery Quotient) and RSI (Reqirement Stability Index) have no importance, sprints are flexible
  • JIRA will be used for scheduling, tracking and defect logging
  • DD/EPY (Delivered Defects per Person Year of effort), PYe(Productivity) , DFDQ (Defects per Delivery) will be calculated from the JIRA data

Requirements Development & Management

  • Frequent/Continuous meetings with stakeholder to get requirements – no concept of frozen Requirements. RSI has no significance.
  • JIRA is the RCMS for the project stakeholders (management, users and development team)
  • Due to the connection between the JIRA and the configuration management, code traceability is automatically maintained

Technical Solution

  • No distinct phases, “Daily Development” – Daily Integration, and weekly Deliveries
  • Not practical to check DIR (Defect Injection Rate) before each delivery
  • Impact analysis and Design is part of JIRA and is shared with Stakeholders

Product Integration

  • Due to Daily Integration and tool support, Integration is not a separate phase

Verification and Validation

  • No Distinct phase for reviews, testing. TDD – Test Driven Development.
  • Daily Reviews and Daily Tests; More efficient than a milestone based or task based reviews and testing.
  • Daily Development concept requires daily reviews and testing. Therefore no Test specification reviews.
  • No formal acceptance Test Specification, weekly Deliveries. As the customer is part of the deliveries (sprints), Acceptance test specification has no significance.

Configuration management

  • Latest code base from the development is taken and labeled.
  • Base lining is not done, as distinct phases does not exist.

Process & Product Quality Assurance

  • PDC (Pre Delivery Check) not done for Weekly deliveries. PDE is done for the major deliveries from the Customer to „End User“.

DAR & CAR

  • All major decisions taken could be documented in the JIRA tool.
    • This gives the flexibility that the entire team can view the decision basis.
  • All review & test defects are entered into the JIRA tool.
    • Informal CAR is done along with customer in the weekly reviews.

Risk Management

  • Daily meetings with the customer
  • Frequent meetings/demos to Stakeholders (also includes management, end users)

Organizational Innovation and Deployment

  • Promotes flexibility so more conducive for innovation

Hope this analysis helps you somehow. But in the end it takes a lot of time and effort to convince management who believes in the world of CMM fanatics.

Posted in Agile Methodology, CMM, CVS, Eclipse, estimation, incremental development, Process, scheduling, SEI, Uncategorized | 16 Comments »

Quality vs Process in Software Industry

Posted by sureshkrishna on December 12, 2006

I am trying to understand the difference between the Quality and Process, which we very often use in an interchangeable manner. After few years of my experience in different roles of Project Leader and Technical manager, now i am in a position to understand the REAL difference.

On a global perspective, the “Process Orientation” is the buzz word in the corporates. ISO 2000 certification, CMM Level2-Level5, Six Sigma, Agile Methodology and TSP/PSP are some of the well known processes in the implementation. Of course many corporates implement a subset of these processes also and might not really call with the real names.

Process is a sequence of steps to achieve a Task“, is the simplest definition i have. I strongly believe in this definition by my heart and sole 🙂 Now i have seen many guys who have really used Quality and Process as a single word. Some of the irritating dialogs i come across were….
#1 There is not quality in the software (They meant, Process implementation is bad)
#2 You have not implemented Process, Stop the delivery to the customer (They think, process non-conformance means LOW in quality)
#3 This month your Process Implementation index is 100% (some times this is because, there is no software delivered or developed)
#4 We produce a very high quality software (but at the customer’s site, the software bombs)
I am sure that all of us would have had a chance to hear this and then wonder, what the senior manager is talking about.

The real problem i see is the lack of awareness and education in the developers, middle managers and finally the senior managers. The people who pester us to implement the process, would have never implemented a single line of code nor the process. In my view a software practitioner is the best person to decide, which process is suitable for the project. He is the one who can say Why, When, Where, What and How. The Quality department just need to assist mainly in What and How.

We need to really distinguish between the Heavy processes and Lightweight processes. In my experience, i categorize ISO 9002, CMM as heavy weight processes; Agile Methodology and PSP/TSP as Lightweight processes. As a general convention, many Service Based Software industry follows ISO and CMM and Product Based software industry follows light weight processes (like Extreme Programming).

Coming to the Quality, i define it as the factor which determine closeness to the requirements, features and the customer/end user expectations. Of course this drills down to the different factors like
#1 How well do we understand the requirements
#2 Translation of the Customer Requirements to the System Requirements
#3 Analysis of the Market/Competition/TargetIndustry/TargetEndUsers, etc…
#4 Good Design Practices (specific to project)
#5 The right-passionate team to do the development
#6 Good coding practices
#7 Developer Documentation, End user Documentation
#8 Aesthetics of the Software (Not only limited to the UI)
#9 End user support
#10 Training

In my view Process is the one which assists to achieve a good quality software. It does not mean that Quality is not attained with out Process. This is a common conception amongst many of us. In small teams, the steps taken for a development project are pretty straight forward and simple. Get the requirements in any format you want (as long as its understood by many of us), design of the module is a very simple process (some times its in the developers brain), coding is done to meet the requirements, simple user documentation, deliver. I have seen all these phases as simple as i have written in some projects. And it works perfectly in some scenarios.

The same scenario, when transposed to a large organization with multiple projects, distributed and cross-functional teams, things gets complicated. This scenario requires a more formal way of managing the Contracts, Work Orders, Reporting Formats, Monthly Reports, Project Plans, Project Management Tools, Requirements, Design, Coding, Testing, Documentation, Delivery and User support, to mention a few. Now the challenging issue is to get all the teams to follow the same process and similar steps to achieve the goal of the organization.

Finally…. Quality is in People, The Software we write, Innovative Thinking and the Ability to Deliver the right things perceived by the customer.

Posted in Agile Methodology, Automobile, CMM, ISO 2000, Process, Quality, SEI, Six Sigma | 6 Comments »