Similar Tickets – How Can This Feature Help You In Supporting Your Customers?

February 20, 2012 by Leave a Comment

“…it would be great if it were possible to merge tickets that were similar, instead of just resolving as a duplicate or creating links between them; especially if the comments from the source ticket could be added to the target ticket, and any future requests for the source ticket redirecting to the merged ticket containing all the comments…”

“…I often get users creating new tickets to tell me more information about already existing ones. I have to copy/paste info into the existing ticket, and then close the new one. Would be nice to have a merge and close button…”

Sounds similar? Yes, these are a few common statements that developers post in discussion forums or help desks of the SDLC management tools or ALM tools that they use. BootStrapToday, which is also an SDLC Management tool, now offers Similar Tickets feature, which can solve such issues of similar tickets and save your time. Similar Tickets can accelerate your customer support quite a bit by addressing customers’ queries faster.

Many organizations today use third party chat clients like SnapEngage or GetSatisfaction or any other email/chat support tool to engage the visitors on their websites. You or your organization might be using one to ensure high customer conversion ratio from the organic traffic. Now, if you are a BootStrapToday user, every project in your account gets a unique email id. If you want to treat any project as support project, then you can configure your support project’s email id with any of the chat/email support tools that you are using on your website with the BootStrapToday email interface. Doing this will create tickets in your support project for all the requests from your customers.

This advantage extends into Similar Tickets feature of BootStrapToday to resolve the issue of following up separately with the tickets that are similar in nature (queries). Here is a snapshot of how it works:

  1. Similar Tickets is an intelligent feature which checks for more than 30% similarity of new tickets with the tickets already in the system.
  2. If a new ticket is 30% similar, then it gets the component of the most similar ticket.
  3. If the component exists, then it assigns the same component to the new ticket created into the system.
  4. Based on the component, the system automatically assigns the ticket to the component owner.
  5. If the component does not exist, then the new ticket is assigned to the project admin.
  6. The project admin can assign proper component to the ticket, which automatically gets assigned to component owner, and a notification email is sent to the assignee.

So, you see, all the queries can be intelligently managed and tracked inside BootStrapToday itself. This process automates lot of repetitive work for support team and leaves no chance of missing on valuable customer queries.

Every new ticket that is created from a customer query will most likely have a similar ticket associated with it already in the system. The new ticket will have links to the similar tickets associated with it, which can be used as a reference point by the user for generating comments. The support team can view the responses given to the customers earlier. This makes it easy for them to respond to the customers quickly based on similar responses.

An important point to note here is that if you see many similar tickets being generated, then you get an idea of some issues/problems early on and you may want to fix those issues quickly based on the customer comments.

What do you guys think?

Filed under Uncategorized Tagged with ,

7 Deadly Sins of Software Estimation in SDLC

February 15, 2012 by Leave a Comment

Steve McConnell in his book “Software Estimation – Demystifying the Black Art” points out that 20 – 30% of the software estimation errors come in by not estimating certain activities. This leads the team to be off target by 20-30% throughout their SDLC even before the project starts! And that is limited to 30% only if the estimation techniques are proper!

Software estimation is a very important step in any SDLC. It may include various estimation data such as cost estimation, effort & staffing data and project management data to arrive at the project schedule and delivery date. The proper estimate of efforts required leads to correct estimation of the project duration and the man-power requirement to deliver the quality that your customer expects. Though the word ‘estimation’ itself means that it cannot be a precise measure, but when we say software estimation it obviously means striving to minimize the standard deviation from what the customer actually wants at the end of the SDLC when the shippable product is ready.

So, what are those deadly sins of software estimation which can take your project way off the track? I am listing here the 7 most sinful of the many that exist.

1. Inappropriate Software Estimation Techniques

There are many kinds of software estimation techniques. If you choose the wrong one then the estimation will not be optimal for your project. For example, Basic COCOMO is suggested for organic projects with small and experienced team, and also for embedded projects with rigid requirements.

2. Using Only One Estimation Technique

Estimation is based on certain data points which are collected from various resources through various ways. Any estimation done using any statistical method has inherent biases which generally arise during the data collection stage and can influence the accuracy and reliability of the estimation. It is no different for software estimation. Different methods of data collection capture different types of biases. The best way to neutralise the biases in your data (and hence in the final inferences, which is estimation in your SDLC) is to use more than one estimation techniques. Some of the software cost estimation techniques suggested for the SDLCs are:

  • SLIM
  • COPMO
  • COCOMO II
  • Basic COCOMO

3. Choosing Wrong Data Collection Schemes

As I said earlier, reliability and accuracy of your software estimation will be a direct function of the quality of the data collected. Hence, depending upon the nature of your project and other factors such as product (project) objectives, organizational assets (people, development tools, etc.) and processes and policies, you should set-up your data collection procedure. For example, If you want to collect effort data, then you could collect the data from timesheets or the employee status reports. But you must sift that data to find out the actual hours spent on work.

4. Not Knowing the Software Requirements

Some projects may depend on fluid requirements and may require that the project SDLC incorporates scope to implement new requirements throughout the SDLC. In such cases, it is impossible to know all the software requirements at the beginning. So, if you come out with an estimation based on regular methods, you are definitely going to be doomed. This sin can be avoided if you consider using Agile SDLC. It is altogether a different matter, but do not provide estimation if you do not know what the actual software is.

5. Building Estimate on Past Projects

This sin is closely related to the sin #4. Sometimes you might not want to re-invent the wheel, and would want to base your estimation on past projects. This maybe a bad thing to do, simply because by doing this you are directly including the deviations and errors of the past projects, along with few inevitable variations which will anyhow occur in any software estimation due to human factor.

6. Overlooking Non-technical Reasons

While doing the effort estimation, it is highly sinful if you overlook certain non-technical reasons just out of oversight. Reasons such as paternity/maternity leave, employee attrition, lead-time to hire a new recruit etc., are easily overlooked whereas these are extremely important to consider during project effort estimation. A good approach would be to provide weightage based on probability of such patterns occurring in your industry.

7. Not Using Estimation Tools

A human is liable to err. The best thing to avoid errors in your software estimation is to use estimation tools.

Why don’t you point out more sins of software estimation, which you think are responsible for substantial deviations in SDLC?

Filed under Uncategorized Tagged with ,

10 Advantages Of Agile SDLC

February 9, 2012 by 1 Comment

Long since software development has come into mainstream it has primarily followed sequential development techniques through the development lifecycle. To be very specific, the SDLC (or software development life cycle) has followed waterfall approach most, where each phase of SDLC is completed before the next stage begins. For example, before any coding begins, the requirements gathering and the architecture design are completed. Though this ‘assembly line’ approach to software development was advantageous in early days of software industry it seems to be getting obsolete for the current generation of software development needs.

In today’s world, traditional SDLC models such as waterfall model, pose a lot of challenges and limitations. It limits the teams from revisiting the stages of SDLC as the traditional approach allows the teams to finish every stage before beginning the next stage. The teams do not revisit the previous stages. The fast paced technological changes in our markets, the increased use of embedded software in devices and the ever increasing uncertainty in the market place makes it impossible for the customers to provide all the requirements at the beginning of the SDLC. By the time the software is estimated to be ready, if developed via waterfall SDLC, it is quite likely that the feature/functional requirements of the software become irrelevant for the customer by the time the software is released.

Agile SDLC evolved out of these experiences in the real-time project development by some of the software development protagonists. Agile methodologies propose to develop software through iterative approach. The entire SDLC is followed in incremental way by dividing the SDLC into cadences of work. At the end of each cadence or iteration the teams deliver a shippable piece of incremental work to the customer. This process leaves enough scope to keep requirements gathering a continuous process and helps the stakeholders determine the course of the software being developed. Unlike the traditional software development approach, in Agile the teams revisit the complete SDLC as a result of providing iterative incremental work that is shippable at the end of every iterative piece.

Together the advantages of Agile SDLC can be listed as under:

  1. Agile helps to speed up the SDLC phases and bypasses process steps that add little value to the project.
  2. Usually Agile methodologies promote less formal culture and encourage collaborative team approach.
  3. Agile facilitates smooth flow of knowledge sharing.
  4. Engages the stakeholders continuously so that the new requirements are gathered faster and there is no scope for guess work by the teams.
  5. It incorporates frequent and rapid changes into the SDLC for product functionality and features.
  6. Saves cost, time and efforts by following iterative incremental work delivery and thereby identifying deviations early.
  7. Redistributes leadership at various levels within the teams.
  8. Increases cohesion between the teams to deliver on time.
  9. Follows crisp and flexible documentation policies which save time.
  10. Provides the end result of higher quality of the software delivered and a highly satisfied customer.

Looking at all the advantages and the limitations (of the traditional SDLCs) that Agile overcomes for today’s development landscape, it is understood that most of the Web 2.0 e-commerce and web applications are being developed using Agile SDLC. According to an article on PR Web, industry leaders such as Xerox and Microsoft have switched over to Agile methods simply because it saves them cost and also produces better products. If your company is still following traditional models such as Waterfall model, then the inefficiencies in your development processes will be obvious and you may not be able to meet the customers need precisely.

Please share us your thoughts on whether Agile SDLC should be followed by all type of organizations in the industry.

Filed under Uncategorized Tagged with , ,

SDLC for Cloud Computing – How Is It Different From The Traditional SDLC?

February 6, 2012 by 2 Comments

SDLC (Systems Development Life Cycle or Software Development Life Cycle) is a framework that defines tasks to be performed at each step in the software development process. It is a set of processes to be followed by developers for each step of the SDLC such as Planning, Development, Documentation, Testing, Deployment and Maintenance. That is the traditional SDLC as we know of. But will traditional SDLC frameworks be suitable completely for the cloud SDLC? Logically speaking – no. Next question that arises is – how is traditional SDLC different from Cloud SDLC?

To answer this question it is best to first understand the crux of the matter – the root cause of why SDLC methodologies have evolved, the fundamentals of cloud computing and why cloud computing has become the de-facto computing and application environment.

Cloud computing is a paradigm shift in the computing world and brings more scalable, flexible and yet robust environment for developing web applications. It provides almost instant access to the software and development environments, by providing multi-tenancy of the virtualized servers and other IT infrastructure. Specifically, PaaS (Platform-as-a-Service), the development platform environment in the cloud, encourages use of Agile methodologies. Agile and PaaS together add great value to the SDLC processes. They help to reduce costs for enterprises in the long run and help in increasing developer productivity at the same time.

SDLC is management of development stages while using different kinds of methodologies which best suit the needs of different projects. An article on Testdog.com explains SDLC wonderfully by calling it a management roadmap. (Also read 2 key differences between SDLC Management and ALM). According to the roadmap analogy, you can say that SDLC gives you route options that you can take to reach your destination and also provides options for the mode of travel. In software development scenario, SDLC frameworks (roadmap) present you with methodologies (route options) that you can choose depending upon the requirements of your project.

In today’s fast changing technological world, the need for faster development processes, higher developer productivity and adaptation to certain technological trends, makes it even more important for the development teams to have the flexibility and robustness of cloud as well as maturity in SDLC framework which can be accommodated in the cloud computing environments.

Keeping these crucial factors in mind, SDLC for Cloud Computing will be different than the traditional SDLC in following ways:

Inclination towards Agile Methodologies:

Cloud SDLC can utilize methodologies such as Agile SDLC (using SCRUM or IBM Rational Unified Process). These are designed for iterative approach to development and fast deployment lifecycles. To bring operations on the same table, use of DevOps should be specified in cloud SDLC frameworks.

Customizable SDLC framework for different stages:

Cloud computing SDLC must have the capabilities to be customized according to the requirements of the project due to change in the effort levels and implementation speeds. In other words the elasticity and robustness of cloud computing environment (to be able to scale-up and scale-down on-demand) can best be utilized if the SDLCs for cloud are customizable in the integrated IDEs and ALMs in the cloud.

Installation and configuration guidelines

SDLC for cloud must provide implementation approach and guidelines for installation and configuration of the cloud environment that is being erected, depending upon its size. The guidelines must ensure that installation and configuration of infrastructure and application environment is completed appropriately for different stages of SDLC including operations and maintenance. These guidelines are the key to differentiating SDLC for cloud from traditional SDLC. This is so because the infrastructure set-up for computing environments and other application environments in the cloud are very different from the traditional on-premise IT stacks, as cloud is based on distributed network and virtualized environment allowing multi-tenancy.

What is your take?

 

Filed under Uncategorized Tagged with , ,

2 Key Differences Between SDLC Management and ALM

February 2, 2012 by 3 Comments

People often get confused between the terms Software Development Life-cycle (SDLC) Management and Application Life-cycle Management (ALM). It is very common that the two are used interchangeably when they should not be. This is because the difference between the two acronyms (both associated closely with the life-cycle of software engineering projects) never gets highlighted well.

Wikipedia defines the two as follows:

Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.

The systems development life cycle (SDLC), or software development life cycle in systems engineering, information systems and software engineering, is a process of creating or altering information systems, and the models and methodologies that people use to develop these systems. In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system: the software development process.

According to these definitions, ALM is a process which clubs business management with software engineering and hence manages the entire life-cycle, whereas, SDLC is a process that creates information systems and hence manages the development stage only. In SDLC the business aspect is not integrated in the process. SDLC itself needs management on case basis. The differences can be brought out more clearly in two ways.

Basic difference

At the outset, ALM is considered as a superset, one that should include one or more SDLCs for any system development or software application development. ALM is a process that starts from the very beginning – from definition of the application, till implementation, maintenance and application retirement. To elaborate this, let me draw an example from warehouse management for a company who provides digitalization service for all your important documents, accessible on-demand. At the back-end, this company will need a sophisticated physical warehouse storage system for safely keeping all the documents in files and folders.

In this case building a warehouse is the application and when this company decides to build the storage warehouse, the ALM process sets-in. Next, every type of document filing will need certain parameters for storage depending upon their utility and level of criticality. Each of these file storage systems can be seen as separate projects, requiring different models of SDLCs, depending on their specific deployment needs. These file storage systems together will form the complete functionality of the warehouse.

ALM engulfs all the smaller parts which come together to make the application work, and which need their own SDLC frameworks to be developed and deployed. Each SDLC (which by itself is a process and can be seen as components of the larger whole – the application) needs separate management. ALM oversees this entire process to deliver the end user value.

In short, the gamut of the ALM is the entirety of the application right from inception of its idea till its seamless functioning to deliver the end user value. SDLC Management is management of separate SDLCs. Hence ALM and SDLC Management can be defined more appropriately as follows:

ALM is a superset which wraps together the fragmented SDLC Management as processes, and integrates them ensuring delivery of end user value and maintaining the same.

SDLC Management is the management of the processes during the development stages only for different modules/components of the application.

Difference in phases

The second way of highlighting the difference can be by pointing out to the phases where ALM and SDLC Management play their roles. ALM is associated with the management of the entire life-cycle of an application which includes development phase (and therefore, SDLC Management also) along with other phases of application’s existence, such as maintenance and retirement. SDLC Management is associated with the management of the life-cycle of the development phase only of the application. Even if there is only single development project that has to be completed to develop any application, it will entail ALM as well as SDLC Management in its life-cycle.

Do you agree? Please share your opinions here and share.

Filed under Uncategorized Tagged with ,

Key Practices for Agile ALM for Improving Productivity

January 27, 2012 by Leave a Comment

We have been talking about Agile ALM for quite some time now. Of course we believe that the Agile ALM will become a requisite for accelerated application delivery coupled with superior software development quality. In fact, the future of application development or software engineering holds a strong case for hosted Agile ALM.

The few crucial technology trends have changed the needs of the businesses. It is a pressing need for the businesses to be able to adapt to the market changes and deliver faster to stay ahead of competition. Hence they need to build a capacity to switch to new software and place processes at a faster pace. This creates a demand for developers of the vendors or in-house teams to be more productive. This increased developer productivity can be achieved only when it is supported by appropriate processes and tools.

All these reasons not only make it necessary to use ALM by all types of businesses, it requires vendors to integrate Agile methodologies in the ALM tools and adopt some key practices to implement Agile ALM which support people and processes for improving productivity.

Traditional ALM has always enforced pre-defined standardized processes through tools and people had to adopt software development based around the processes and tools. The end result of software delivery would never be what the customer has been looking for. Though the pre-defined processes would concentrate on maintaining certain levels of quality, often it would lead to delayed production and sub-optimal delivery of software to the end-user. But the traditional method of using ALM will not work in the wake of new trends. Organizations which focus on supporting people and processes through Agile ALM will improve productivity and therefore beat the competition.

“]

A Scrum in Rugby union [Image Courtesy: www.en.wikipedia.org

More agility and impromptu strategies to evolve project specific processes is required in software development lifecycle. It is almost similar to the experiences originating from field sports.  The word Scrum (part of Agile methodologies) has actually been derived from Rugby.

Agile methodologies focus on developing processes and supporting people through tools. They focus on continuous delivery of the software so that the end-user feedback is received at early stages and the changes can be incorporated faster. It is important that Agile is combined with ALM to achieve increased developer productivity. A successful roll-out of Agile ALM requires its vendors to equip organizations by incorporating scope for following suggested vital practices. These practices are based on few of our observations and are congregated from the whitepaper – Redefining ALM with five key practices – published by ThoughtWorks Studios:

Evolve Processes

Agile ALM recognizes that the processes for two different software engineering projects cannot be same. Hence Agile ALM tools must be such that they enable the teams to discover and build their processes progressively. The Agile ALM tools must enable the teams to construct possible roll-ups for reviewing and governance which gives them a chance to reflect and improve upon their processes and also incorporate changes at short intervals that may be suggested by the stakeholders. This flexibility for continuous improvement is essential in Agile ALM tools so that the true benefits of Agile ALM are derived by the organizations implementing it.

Incorporate Heterogeneity

The second good thing about Agile ALM is that it appreciates presence of heterogeneity in different projects. For example, if an organization from Life-sciences industry wants to launch a new SaaS CRM product, then development work may happen based on loosely defined requirements. In this case, the team will need to come out with a prototype, only to improve it based on continuous feedback from a focus-group. On the other hand, if the same organization wants a feature enhancement in an existing product, then the team will have to work on very strict defined processes. Therefore, heterogeneity of situations makes it necessary that the Agile ALM tools also embrace heterogeneity so as to let different teams evaluate and build their own processes.

Collaborative Approach to Management

Flexibility to evolve processes under heterogeneous projects also facilitates collaboration among the team members and stakeholders at every stage of the software lifecycle. The collaborative approach of Agile ALM ensures continuous delivery of features weekly or even daily. It makes sure that the end product does not deviate from the requirements laid down by the end-users. Agile ALM tools should facilitate orchestrating of the entire development lifecycle, instead of stiffening the teams with pre-defined processes that come with traditional ALM tools.

What do you think should be a part of best practices for rolling-out Agile ALM in organizations? Please share your thoughts.

Filed under Uncategorized Tagged with , ,

Cloud ALM – An Enterprise Market Disruption Strategy for SMEs?

January 19, 2012 by Leave a Comment

The biggest problem that SMEs face today is that the playing field is not leveled for them. SMEs typically take a beat from the large enterprises at the technology and the scalability front. Due to lack of up-to-date technology and constraints for scaling up rapidly, SMEs always find expanding their business as the real challenge.

The high upfront cost of buying licenses for owning the IT or getting customized software application developed does not permit the small players to automate processes completely and competitively. Yet the ALM as a process is necessary requirement even for the SMEs to be competitive in the future. This argument will be understood in much stronger way if you refer to the following two articles:

  1. Application Lifecycle Management through Cloud and Agile – A Case for Hosted Agile ALM
  2. Rise of Developer Platforms – A Paradigm Shift

Historically, software development has grown more complex and the tasks involved have developed the need to automate the complete software development cycle. Early on, the automation started with development of tools to control and manage source code versions, based on the Source Code Control System (SCCS). Software development needs further evolved and gave shape to Integrated Development Environments (IDEs). All these efforts were to automate and integrate the features of the SDLC and thereby maximize the productivity of developers.

Moving on, the software development has further felt the need to integrate other stages outside the core of software development but which are closely involved in shaping an application. These are requirements gathering, architecture designing, deployment and management, and these together form the basis for Application Lifecycle Management (ALM).

ALM does not happen as a single step in a single instance, but it happens at various stages engulfing the traditional SDLC and reaching beyond. In order to automate the processes SMEs usually invest in buying tools that fit best in their overall ALM strategy and then try to integrate them. But wouldn’t it be better if the ALM functionalities required for automation were built in a single platform and that was also available in cloud?

So, can ALM Platforms in the cloud bring the change that the SMEs are looking for? Yes, certainly it can. It can level the playing field for the SMEs. Since cloud computing provides reduced cost of using technology, it can be the answer to the prayers of many SMEs. Here are some benefits why I think Cloud ALM will be the business disruption strategy for SMEs:

Low Capital Investment

Utilizing IT services on pay-per-use reduces the upfront capital investment drastically as utilizing IT in the cloud comes at a fraction of the cost of buying on-premise IT infrastructure. It releases much of your budget for other business functions. This gives plenty of scope for the SMEs to become more competitive vis-à-vis the larger enterprises.

Improved Productivity

ALM tools, which integrate the complete application lifecycle and make application development a more managed business process, enable SMEs to improve the developer productivity. The developers can focus more on business requirements and programming than on mode switching due to use of disconnected tools for various processes in the entire application lifecycle. As explained in the earlier point, the ALM tools in the cloud can further add to the appeal – improve operational efficiencies of the SMEs – to make it a tool of top choice.

Robust Scalability

Most of the time SMEs are not able to scale up and hence they lose business to larger enterprises. Since business is variable and uncertain, SMEs would not want to invest further if there is no certainty of long-term ROI. With hosted ALM tools it becomes easy to scale-up because cloud gives you the option of scaling up or down as per your business requirements with just a click of a button. So you need not invest heavily just for scaling up for one of your customers by opting for traditional way of owning IT.

Our team at BootStrapToday has done immense research on software development and, coupled with our own programming experiences, have integrated features like Version Control, Tracking System, Milestones, Git & Subversion Hosting, and Knowledge Repository, and have weaved intelligence in our ALM Platform. We are developing an Integrated and Intelligent ALM platform for complete project management, and which is already available as SaaS and has an option for in house set-up also.

What is your take? How do you think ALM will chart the future of software development? Share your thoughts here.

Filed under Uncategorized Tagged with , , , ,

Follow

Get every new post delivered to your Inbox.

Join 41 other followers