Sunday, June 30, 2013
Explain the single and two level directory structures
Posted by Sunflower at 6/30/2013 12:30:00 PM 0 comments
Labels: Characters, device, Directory, File system, files, Individual, Limitations, Location, Logical, Operating System, Physical, Single-level, Standard, String, Structure, System, Two-level, Users
Subscribe by Email |
|
Dot / Patch release: Estimating the features where there is a change required
This post talks about actually doing an estimation of the changes required by working on the different features to see the overall impact of the change. Consider a case where a dot release has to be made for the application, with a change made in one of the features for a major defect. Now, the dot release has to be made in a couple of months, with the exact release date being decided based on the estimates for the different areas of the release (development effort, testing, localization, etc). One of the starting points for this estimation effort is figuring the effort needed for development, and for that, there needs to more detailed investigation of what areas need development effort.
How do you do this ? The first and most important starting point is to ensure that you have an experienced developer to do the investigation and estimate. The actual effort can be done by somebody in the development team, but the investigation should be done by a senior and experienced developer. How do you start:
- First, make sure that the developer has been given details of the change needed in terms of requirements
- Give the developer some time to discuss with other team members about the areas which are impacted.
If this is a core area, then the developer would need to go across the application to determine the impact. For example, there may be a need in the user security framework, and that would spin across all the application. If the change is localized to a specific area, then it is easier to make the effort estimate of the change. There is no great complexity in this area, as long as the developer does a thorough job.
- The senior developer should spend time with the actual developer who is going to work on the release and make sure that he has enough understanding of the changes required, and depending on the skill of the developer assigned, make sure that the correct estimate is given (which may included a required buffer).
- The developer also needs to ensure that he has spent time with people from the localization development team and the installer / release teams so that he has an idea of the amount of time needed from their side and can also include these in the effort estimate.
- The developer needs to spend a fair amount of time with the testing team so that they have a good understanding of all the changes that are going to happen in the release as well as the actual impact of the change including all the areas of the application that are impacted.
Posted by Ashish Agarwal at 6/30/2013 12:30:00 AM 0 comments
Labels: Development, Dot Release, Estimates, Estimation, Impacted areas, Installer, Patch, Release, Software Process, Testing of dot releases, Testing of patches
Subscribe by Email |
|
Saturday, June 29, 2013
What are the reasons for using layered protocols?
- Specialization and
- Abstraction
Posted by Sunflower at 6/29/2013 12:00:00 PM 0 comments
Labels: Abstraction, Application, Architecture, Data, Framework, Layered Protocols, Layering, Layers, Networking, Operating System, OSI, Protocols, Services, Software, Specialization, Standards, Tasks
Subscribe by Email |
|
Being able to estimate effort needed for smaller releases (patch / dot release)
- There could be a security issue for which an urgent patch needs to be released,
- There could be some new feature that is meant to be pushed through before the next release
- Because the release schedule is long, defects that are found during the next few months are collected and released in an interim release that is then released
- And this is one of the most interesting reasons for a release - I know several people who will not take a new version of a Microsoft until a service pack has been released, since that is when it would have stabilized - so this puts pressure on a company to do a release within a few months
With all this, who does these interim releases ? For products where there is already a definite schedule of interim releases, a small sub-team can be setup to take care of these releases. Such a team will soon gain expertise in doing these smaller releases, and can work on the main release if there are no interim releases ongoing. However, for teams where there is no definite schedule of release of these interim releases, it does not make sense for a team to put dedicated folks to work on the product. Even more, in my experience, when people are assigned to such interim releases, there is a need to rotate the people working on such releases, since these are seen as essential but maintenance, not with the excitement of working for something new.
Now, once people are assigned to do the project, there is a need to figure out the schedule for such a release. However, in most of these cases, the end date is already fixed - the Product Manager already has a date in mind about when these releases need to be released. But, the team still need to define the estimate and a probable schedule in mind:
- Whether this be a dot release or a patch (a patch is a small set of files that is downloaded and can be installed, a dot release is typically the full installer with a few changes in the files). The advantage of having a dot release is that it can replace the original installer
- Define the change that is happening (this typically means the files and features that are being changed, and the estimated impact of this change)
- The amount of time needed for the development team to make the required changes
- The amount of time needed for the testing team to test the area and surrounding areas (this would also include the installer created for the release)
- Typically most products have language versions, and those need to be created and tested when a dot release or a patch is made. So, the estimate for the amount of time needed for these activities also need to be incorporated into the schedule.
Together, all of these can be woven into a schedule for the interim release. If it turns out that the deadline given is less than the projected schedule end, then you need to push back. For a small release, it is next to impossible to meet the project with the required quality principles, unless sufficient time is given. We once had a situation where a particular variation in the installer made a small error in the registry, which then prevented those who installed from being able to install another update, and there was a lot of backlash over that - we had to release another patch for that one.
Read more about the estimation done by a senior member of the development team.
Posted by Ashish Agarwal at 6/29/2013 12:00:00 AM 0 comments
Labels: Dot Release, Estimates, Estimation, Installer, Patch, Release, Software Process, Testing of dot releases, Testing of patches
Subscribe by Email |
|
Friday, June 28, 2013
Give advantages of frame relay over a leased phone line?
Posted by Sunflower at 6/28/2013 12:00:00 PM 0 comments
Labels: Advantages, Communication, Connection, Data, Frame Relay, Frames, Layers, Leased phone line, Network, Process, Protocols, Route, Services, System, Techniques, Technology, Telecommunication, User
Subscribe by Email |
|
How to decide whether to add another language support to the software product
So, if you have an English only version of your product, what will happen is that you will sell it in the United States, Great Britain, Australia, (and other English speaking nations of the world), and to some extent, you will even sell the English language versions in some of the countries, selling it to those consumers who want the English language versions of the product. But, what about the Spanish speaking world, the Japanese speaking, the French speaking, and so on ? Well, in many of these regions, there will be also a reluctance to buy the product just because the company has not chosen to bring out a specific language release. So, it always makes more sense to release specific language versions of the product, and releasing with the same set of features as the English language version.
The process of creating multiple language versions of the software is much easier. What is basically required is to translate all the UI elements in the application (includes strings, error messages, text within images, and any other text that the user can see) The way that the software code is written makes it easy to extract all these UI elements, and send them off for translation. Once these are translated, these are then incorporated back into the software, and then tested to ensure that there is no functional issue, and no cases where the translation leads into text that is messy or otherwise not right.
If it is that easy, why not just translate the software into as many languages as required ? Well, the previous paragraph was an over-statement; the process is expensive both in terms of revenue and resources. The process is not so exact. It can happen (and this especially happens with Japanese, German and Russian) that the translated text is much larger than the English language version, and there needs to be effort spent to either increase the size where the text is to be fitted (and this would need to be done in all languages) or the text needs to be re-translated into something smaller. For large products, a complete translation, which also includes the thorough testing of the product, can run upto almost a million dollars.
So this why there needs to be thought about translation into a new language. Reasons for the same include:
- Marketing estimate of enhanced revenue
- Potential sales in that region over a period of time
- Negative image getting developed because of the lack of product in that language
- Need of a partner. In many cases, when doing deals with partners, the partner would want the product to be there in multiple languages, and if the language is not supported, the deal could be in danger
Posted by Ashish Agarwal at 6/28/2013 12:07:00 AM 0 comments
Labels: Cost benefit analysis, Costing, Language, Languages, Localization, Localize, Software Process, Translation, Translation into languages
Subscribe by Email |
|
Thursday, June 27, 2013
What is the difference between a passive star and an active repeater in fiber optic network?
Posted by Sunflower at 6/27/2013 11:30:00 AM 0 comments
Labels: Active, Active Repeater, Communication, Components, Coupler, device, Differences, Fiber, Fiber Optics, Input, Mode, Network, Optical, Output, Passive Star, Properties, Signals, Store, Telecommunications, Users
Subscribe by Email |
|
Wednesday, June 26, 2013
Encouraging a creative team member to assist in the UI designer duties
- Ask for and get more testers and/or developers, and take on this quantity of work
- Ask for and not get more testers and/or developers, and decline work beyond the amount that can be done with the team that you have
- The third one is the most problematic. The team does not get additional testers or developers, but there is a lot of pressure built to take on the additional work. One would not like to think of such a scenario, but it does happen, and eventually the team either gives up the additional work or takes on a lot of stress, and maybe even has a reduced quality in terms of their deliverable.
However, twice in the past 4 years, we have come across a situation which is not easily solvable, and for which we did not get any additional support. What was this case ? This was the case where the release we were doing had a number of features that required the support of a workflow designer / UI designer. In a typical release, we have a certain number of such resources assigned to the team, based on an expectation that the amount of workflow and UI required will be of a certain % (let us assume that 60% of the work being done by the team needs the support of the workflow / UI team - the reason for it being 60% is that the remaining 40% is where the team does some kind of tweaking / modification which does not require any workflow changes or UI changes).
However, this gets badly affected when there was a release where the estimation of the amount of work where the workflow / UI designer is needed was around 80%, and it was pretty clear that the team that was doing the workflow / UI design was not staffed for this extra work, and even if we had got allocation of budget for the extra work (which was not 100% certain by itself), it takes months to hire somebody with this skill set. Hence, there was no getting around the fact that we had a puzzle on our hands - we had estimated work for which we had enough developers and testers, we did not have enough designers. What to do ?
When we were discussing with the senior members of the team, we came across an interesting suggestion. Over the past, the team had noted that there were some members of the team who were more easily able to comprehend the designs put out by the designer team and understood the way that they were doing their reasoning. Given that we really did not have a choice, we went ahead with the open offer to team members who wanted to give open flow to their creative juices, and prepare the design, with rounds of review by the designer team (we found that this amount of effort could be accommodated), and then present to this team. One of the main persons we expected did not volunteer, but another person who was also seen a prospect volunteered, and we pulled her off her current responsibilities and got her temporarily assigned to the designer team. Over the next few weeks, we did a close watch on this arrangement, and while it was not as good as the design done by the designer team, our Product Manager was satisfied with this, and so was the design team, and we went with the design that she produced and the team accepted. Now, this was not a long term arrangement, but in the scenario described above, it seemed to work.
Posted by Ashish Agarwal at 6/26/2013 09:18:00 PM 0 comments
Labels: Design, Designer, Replacement, Shortage of resources, Team member, UI design, Workflow, Workflow design
Subscribe by Email |
|
What are advantages and disadvantages of having international standards for network protocols?
- Physical layer
- Data link layer
- Network layer
Posted by Sunflower at 6/26/2013 11:24:00 AM 0 comments
Labels: Addressing, Advantages, Communication, Data, Disadvantages, Inter-networking, International, Layers, Networking, Networks, Open System Interconnection, Packets, Protocols, Routing, Standards, Transmit
Subscribe by Email |
|
Tuesday, June 25, 2013
Working with people who are not so responsive as developers or testers ..
Who are these members of the extended team ? Well, let me lay out a few candidates (and this does not mean that every one of these roles will not follow the details of the schedule, but I do know many people who were in such roles with whom it was a challenge to get them to follow the schedule) - these are typically the more creative people of the team - in some cases, the Product Manager; in more cases, the UI Designer or the Experience Designer; and even in other cases, some of the more senior members of the development team.
Does this really happen ? Well, yes, it happens like this all the time. Let me layout some examples - during the course of a project schedule, there is an initial time period when the requirements need to be defined by the Product Manager (with a certain detail inherent in these requirements, a level of requirements that is enough for the workflow designer and the development team to do a certain level of estimation), and more often than not, unless I, as the Program Manager would do a lot of reminder to the Product Manager, there would always be some amount of delay, or the requirements that were available were not of enough detail. As a result, by a couple of cycles, we had actually started giving a buffer so that after all the urging, there would be time to do a couple of cycle of the requirements. Given that the Product Manager is also typically a senior person, we did not try any other method of ensuring that they finished their work by the scheduled time; instead we added a buffer of around a week in the overall schedule.
The bigger problem was when we were dealing with the experience designer / UI designer. The interaction with this person was on a regular basis, for more than 70% of features (given that most of the features needed some kind of UI work, or needing some kind of workflow optimization). Hence, it was not only the overall schedule, but also the schedule for each feature that needed dates and details for work supposed to be done by the UI designer. The work done by the designer followed in a logical order to the requirements and was needed for the development team to do their work, and hence any delays in this work would cause a ripple effect all down the schedule. However, in a clear case of Murphy's Law, the chances of there being a delay from the designer end was high (not always, but in most cases, there would be something pending).
How do you ensure that the work done by the designer was on time ? Well, there are no clear ways (atleast nothing that was 100% successful), but here are some steps:
- Layout a clear schedule for when the delivery from the designer is expected, including dates for interim deliveries, review times, and final deliveries.
- If the designer does not agree with the dates that you would have started out with, and considers them too aggressive, then you need to do a discussion. Don't try to force any dates on the designer from your end, make sure that dates are negotiated.
- Setup a weekly telecon with the designer, and make sure that you are reminding them of the dates that are due, and also find out from them whether they are on track or not. If wildly out of track, then you might need to modify your dates to some degree, and make sure that the team knows about.
- If there is a manager from the designer end who is looking at this, then make sure that they are also in the loop for the work done.
- Finally cross your fingers and hope that this is not the schedule where the designer is going to delay their deliveries.
Posted by Ashish Agarwal at 6/25/2013 11:00:00 PM 0 comments
Labels: Deliveries, Dependencies, Dependency, Meeting the schedule, Project Management, Project Manager, Risk, Risk Mitigation, Schedule, Software Process
Subscribe by Email |
|
Explain about demand paging and page replacements
- An
attempt is made for accessing the page.
- If
page is present in the memory the usual instructions are followed.
- If
page is not there i.e., is invalid then a page fault is generated.
- Memory
reference to a location in the virtual memory is checked if it is valid or
not. If it’s an illegal memory access then the process is terminated. If
not the requested page has to be paged in.
- The
disk operations are scheduled for reading the requested page in to the
physical memory.
- Restarting
the instruction that raised the page fault trap.
Posted by Sunflower at 6/25/2013 11:49:00 AM 0 comments
Labels: Algorithms, Data, Demand Paging, Logical, Management, Memory, Operating System, Page Replacement, Page table, pages, Paging, Physical, Process, Request, Strategy, Systems, Techniques, Virtual Memory
Subscribe by Email |
|