tag:blogger.com,1999:blog-83389677044774047312024-02-22T21:38:02.741+05:30Software Product Development | Software Testing Tutorial | Software ProcessArticles, comments, queries about the processes of Software Product Development, Software Testing Tutorial, Software Processes .Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.comBlogger1821125tag:blogger.com,1999:blog-8338967704477404731.post-45825152758791929742019-12-04T00:21:00.000+05:302019-12-04T00:21:22.052+05:30Handling risk management as a part of Project Management
If you go through a course of how to be an effective Project Manager, there will be a number of points that would be made as critical processes. Risk management is one of the key points that the Project Manager needs to have a continuous focus on (in fact, some experts believe that once the project is on, Risk Management is the most important focus area of the Project /Program Manager). Like Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-60058648574487994852019-08-27T00:29:00.000+05:302019-08-27T00:29:16.395+05:30Effective project management: Controlling scope creep
We had a great Product Manager for our software project. The lady knew all her stuff, had a great rapport with the product support team and a direct contact with some of the larger customers for whom we did projects for. The design team liked how she was able to take the customer requirements and work with the design team to get the requirements into the required details that the High level Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-36331473034761323132019-08-20T22:42:00.001+05:302019-08-20T22:42:36.582+05:30Don't hard-code URL's into the software or documentation
This is something that we discovered during the initial versions. We had placed some URL's into the documentation which pointed to some external resources. Then an year later, we got a defect logged into the system, a defect logged by a customer. This was a low level defect, about some URL in a Help Page that was not working, giving a 404 error. However, when the defect got to review, it was theAshish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-61664450703259062732019-08-15T00:31:00.000+05:302019-08-15T00:31:12.373+05:30Keeping up with security fixes / patches and the like
Every other day, you hear about some major security flaw letting hackers steal credit card information, steal passwords, social security numbers or something equally serious. Such news can seem remote, but not for the organization that gets impacted by such news. In such an organization, the impact of such security lapses can be shocking and dramatic, including people getting laid off and stock Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-14738297329258925422019-08-13T01:04:00.000+05:302019-08-13T01:04:27.857+05:30Partnership with an external party - quick prototyping / solution
A couple of years back, a major disaster took place. We had tied up with an external mobile based organization, larger than us, for providing a customized version of our software which would act as an entry point to their software. Such deals and partnerships happen all the time; the schedule was aggressive, but which schedule is not. Deals such as these are the life blood of a growing Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-62605597633722049332019-08-09T00:21:00.000+05:302019-08-09T00:21:47.394+05:30The importance of code walkthrough and reviews
When one studies software engineering, the importance of review like activities are actively mentioned. However, during the pressure of actual project work, there is always pressure to reduce the amount of time spent on these activities; in many cases, this is something that the project manager might push. And there are a number of such review activities that happen during the course of the Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-57720884352333680572019-08-07T00:59:00.000+05:302019-08-07T00:59:30.708+05:30Coordination with external teams - regular meetings to track progress and status
Sometimes when I review some of the posts that I create, it seems like something that is so obvious, why would there be a need to even create such a post; everybody would already know this. And then, one comes across cases where it becomes clear that some people do not really know the contents of the post, that they get into problems which have been described in some of the posts. So the idea ofAshish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-16760334548721870062019-08-06T00:07:00.001+05:302019-08-06T00:07:58.964+05:30Giving time for the testing effort
The testing process is one of the most fundamental parts of a software project. Any software that is built (or modified) would have defects in it. Even the most confident of software developers and the most skilled would admit that there will be defects that creep in when they are writing their code (in fact, the best ones are a part of the testing effort, working closely with the testing team Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-84534205320125764762019-07-10T01:14:00.001+05:302019-07-10T01:14:52.044+05:30Interaction between product manager and usability expert
The product manager plays a role throughout the product development or the projectexecution cycle. The product manager delivers requirements, discusses them with the feature teams, collaborated and provides clarifications during the design phrase and also plays a key role during the development and testing cycles - defining what the flow for the feature should be case there is a lack of clarity Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-12077613786161591662019-07-04T01:08:00.002+05:302019-07-04T01:08:56.094+05:30Presentation - who should do the presentations ...
In previous posts, I have talked about the kind of data, graphs and slides one should use in a presentation, especially when the presentation is being made to people who are in a more senior position. One has to be careful about what to present, presenting a top level summary and not doing an overkill with data, and yet having backup data and graphs for the queries that might come (it always Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-91323402210288528242019-07-02T00:36:00.001+05:302019-07-02T00:36:55.092+05:30Focusing on the usability and ease of reading
Recently. I was driving past a gas station next to the highway, one that I had passed by earlier and this time saw a new board announcing some new eating options. Given the speed at which I was driving, I would normally be able to read the signs on the board, but the lettering was in a fancy script where I was not able to read it (or rather, it would have taken more time to read it than the timeAshish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-68077433324565317682019-06-11T23:15:00.000+05:302019-06-11T23:15:10.880+05:30Presentations - what data to present and how (contd..)
In the previous post (Data and graphs in a presentation), we talked about some of the data elements and graphs that would be shown in a presentation; such information is generated from a number of factors, the level to which these need to be shown as well as the detail depends on the audience of the presentation.
In this post, we talk about something that needs careful planning while making a Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-19003249933328587372019-06-06T01:08:00.000+05:302019-06-06T01:08:01.331+05:30Presentations - what data to present and how
This topic is actually a full book, since it depends on the type of presentation, the target audience, etc. For example, if you are presenting to senior management, you would try to keep bullet points and graphs of data along with conclusions (and keep all the detailed information on your fingertips since you would not know who could ask what question about which part of the presentation). If Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-41907060477765270682019-05-30T00:11:00.000+05:302019-05-30T00:11:36.328+05:30Ensuring you are kept in the loop for communication
Recently I got an email from another program manager, the lady was somewhat junior to me in the sense of actual title, but we were both doing the same role (and eventually that is what matters after all, not a title). She was in charge of a team that delivers some modules for a project that our team uses, and we have been working with her team in the past for several deliveries, and the Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-38771234424120381092019-04-24T23:19:00.000+05:302019-04-24T23:19:32.857+05:30Ensuring resources are allocated for the next version
The process of resource (in this post, we are talking about people) allocation during the process of product development is tricky, and because there are high costs associated with the same, it requires careful planning, and sometimes circumstances can throw such planning out of the window.
For projects, where people are assembled for a specific one-off project, the situation is slightly Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-47156239268694241182019-04-16T23:32:00.000+05:302019-04-16T23:32:41.039+05:30True status in the status report
The status report can be a very important document, or it can be just something that is created as a matter of routine. I remember 2 very differing usages in 2 different situations - in one case, the status report was reviewed by many members of management and they had queries on some of them, which reassured us that the status report was valued and was being viewed. However, it also brought on Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-34855589760949333922019-04-11T23:17:00.001+05:302019-04-11T23:17:51.140+05:30Ensuring the major features are delivered to testing early
Sometimes when I am writing these posts, and review the content once I have done the post; it seems like I am writing about the most obvious of topics. But you won't believe the number of projects where there has been discord between the team members with the QE team complaining about features being given late, those features which had a huge testing impact; and a significant number of end of Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-53661313542965767162019-04-10T23:50:00.000+05:302019-04-10T23:50:12.800+05:30Costs of taking last minute defect fixes
You know what I am talking about. I even hinted in the last couple of posts about the dangers and problems involved in this situation. It is like a Hobson's choice, no matter what you do, there is no clear right answer. Here are some cases for the same:
- You are a week away from the date when you cease the cycle of testing and fixing, when the product goes into the process of wrapping up the Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-20654313595827691962019-04-07T23:36:00.000+05:302019-04-07T23:36:15.825+05:30Avoiding ascribing blame for last minute defects without a review
As a software development team reaches the last stages of the development project, the tension levels in the team can suddenly change drastically, mostly increase. There is an anticipation that something may go wrong, something can change the milestones and deadlines. When the team reaches the days before the completion of the development and testing stage, every day of testing brings forth an Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-49970174768913531042019-04-06T22:53:00.001+05:302019-04-06T22:53:47.556+05:30Defining single point responsibilities for decision making during a software cycle
It seems like a simple management issue, having single point responsibilities for different functions, but you would amazed at the number of teams that stumble on this issue when at a critical point in their schedule. Consider the case where a team is coming to a point where they have to declare whether they are now clear of all major discovered defects (no team can find and fix all known Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-87093839265539479102019-04-06T00:00:00.001+05:302019-04-06T00:00:49.770+05:30Software product localization - there may be base product changes
For somebody (people or teams) who have experience in releasing software products in multiple languages, they would typically have gone through a lot of learning in terms of how the nuances of different languages can cause changes in the base language product (in our case, and in most cases, the base language product is in English, and the product can be released in many other languages, for Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-53595644048295058122019-04-03T23:47:00.002+05:302019-04-03T23:47:52.630+05:30Taking the time to define and design metrics
I recall my initial years in software products where there was less of a focus on metrics. In fact, in some projects, there was a question of accounting for defects and handling them, and the daily defect count was held on the whiteboard, but that was about the extent of it. Over a period of time, however, this has come to change. Software development organizations have come to realize that Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-80166593098282655932019-03-31T02:40:00.000+05:302019-03-31T02:40:54.160+05:30Regular sessions with Product Management and Customers
One of the most common experiences I had while interacting with people on product development teams, especially those who have been on 2-3 development cycles, from start to end is, that they seem to get a feeling for what the features in the product should be, how the workflow should happen and so on. It can get tricky when they have a strong feeling in this regard since they might incorporate Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-27982841440846475752019-03-24T23:45:00.000+05:302019-03-24T23:45:12.821+05:30Dedicated team for previous version releases
For software products that have had multiple releases over the years, there is a ticklish question about the resources that need to be dedicated for previous released product versions. This is even more critical for software products that have wide usage such as Microsoft Office, Photoshop, and Acrobat. Organizations have stated policies about providing support for previous versions, but there Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0tag:blogger.com,1999:blog-8338967704477404731.post-69097459659074966182019-03-20T22:25:00.000+05:302019-03-20T22:25:10.976+05:30Inter team - Pushing for your bug fixes
When you work in a slightly larger software development organization, you will find that there are numerous cases where teams have dependencies on external teams for getting defect fixes. A simple example can explain. Say, there are multiple teams that need a function for coding / decoding music - and there are so many different audio formats, some of which have free solutions, and others which Ashish Agarwalhttp://www.blogger.com/profile/17375418045330076026noreply@blogger.com0