Category: Uncategorized

Task estimation for pert charts:

Task estimation for pert charts:

 

It is an analysis techniques can be used when the individual task times estimates are fairly uncertain. Instead of putting a point estimate for the duration estimate PERT uses three times estimates.

Optimistic

Most likely

Pessimistic

Formula example: (optimistic time+4X most likely time+ Pessimistic time)/6

(8 workdays+4*10work days+24 work days)/6 =12 Days

Where Optimistic time= 8 Days

Most likely time = 10 days

Pessimistic time = 24 days

So most likely time will be 12 days

Estimating duration this way allows managers to calculate a more realistic project schedule.

 

PERT charts are an excellent training tool for a project controls person to truly understand the underpinnings of a schedule,” says PMFocus’s Patterson.

 

PERT charts help project teams visualize the order of tasks, milestones and phases within a project. Illustrating the project schedule makes it easy to identify tasks as one of two types:

  • Dependent, or sequential tasks
  • Non-dependent, or concurrent tasks

This allows managers to coordinate work across teams and departments more effectively.

Downside of Agile

Downside of Agile

In case of some software deliverable, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.

There is lack of emphasis on necessary designing and documentation.

The project can easily get taken off track if the customer representative is not clear what final outcome that they want.

Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.

It’s a relatively new methodology, people not that much used that they are with waterfall

People are afraid of what they don’t know

Without a baseline different incomputable solutions could arise during each iterations.

Without communications different people may produce divergent solutions

People tend to get burned out as the end of iteration is approaching.

 

Planing for Contingencies

Planing for Contingencies

The goal of contingency plan are to establish a communication systems, create recovery/ respond threshold and define the roles and responsibilities of the employees in case of a disaster. We have all seen that unplanned events could occur  with little e or no warning and bring business operation to a halt as was recently the case with all the flights from and to to London recently

The key goal should be to make sure you can maintain the operation of your organization if the disaster were to occur.

It’s a good idea to have a formal policy spelling out the need for a contingency plan.

The plan should be simple overall. The language and directions in it should be understandable to future audiences. You never know who will have to implement it.

Figure out the specific trigger that will require you to use your contingency plan. Determine how you will measure success so that you can return to normal operations. Identify all operations that are critical to your business continuing.

Making sure your plan addresses each of these three questions will help you ensure you don’t miss anything.

What could happen?

What will we do in response?

What can we do in advance to prepare?

Here’s a brief case study in how a well prepared and executed disaster recovery plan can save a business.

Agile Estimations – How to?

Agile Estimations – How to?

Planning Poker or Scrum Poker.

Estimating a project, in terms of cost and time is always a difficult task for all project managers.  A project manager who have completed a similar project, the estimation would be much easier than a fresh project manager who doesn’t have e a  previous domain experience. In Agile the solution for the problem is doing a Planning Poker or Scrum Poker.

Procedure

At the estimation meeting, each estimator is given one deck of the cards. All decks have identical sets of cards in them.

The meeting proceeds as follows:

  • A Moderator, who will not play, chairs the meeting.
  • The Product Manager provides a short overview of one user story to be estimated. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks. A summary of the discussion is recorded by the Project Manager/Scum Master.
  • Each individual lays a card face down representing their estimate for the story. Units used vary – they can be days duration, ideal days or story points. During discussion, numbers must not be mentioned at all in relation to feature size to avoid anchoring.
  • Everyone calls their cards simultaneously by turning them over.
  • People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then discussion continues.
  • Repeat the estimation process until a consensus is reached. The developer who was likely to own the deliverable has a large portion of the “consensus vote”, although the Moderator can negotiate the consensus.
  • To ensure that discussion is structured; the Moderator or the Project Manager may at any point turn over the egg timer and when it runs out all discussion must cease and another round of poker is played. The structure in the conversation is re-introduced by the soap boxes.

Procedure source: Wikipidia

Contingency Planning and Management – I should have known better

Contingency Planning and Management – I should have known better

Contingency Planning in IT projects 

Unexpected and unforeseen issues do happen in all projects.  To manage the  negative impacts,  Project Managers plan a contingency arrangement to complete the project on time and within the budget.

Why do we need a contingency plan. 

  • To finish a project on schedule and within budget
  • To avoid unnecessary pressure on other team members

How do we plan to face an emergency situation in IT projects

The first step in contingency planning is identifying the constraints in advance.  The probable constraints include

 Vendor Supply

This issue do happen if we depends on a third party on hardware supply or support on both hardware and software.

How to plan?

*Constantly keep in touch with the vendor directly or indirectly how well they are on their promise on delivery and provide feed backs and manage projects slightly according to the delivery schedule.

*Plan and identify and make arrangements in advance for an alternate supplier and their conditions.

Key Personnel:

Whole project delivery commonly depends on few key people in the project team.  They are mostly domain experts or senior developer or someone who already have a wide knowledge about a similar project or same project.  These people normally have multitasking skills and  often members of other projects as well. A sudden disappearance of these people from the project would significantly effect the outcome of the project. Having a plan in place to substitute an expert by assigning tasks to suitable staff is always a better management policy.

How to plan and Manage this situation?

Always find backup domain experts for consultation before the beginning of project.  To replace these key people normally need more headcounts with individual skills.  From the time of project planning, project managers do assign( most of the time confidentially) a replacement for all key positions called Plan B and ask for extra 20% staff  as float.

 

 

Apple black Friday event 25/11/2016

Apple black Friday event 25/11/2016

hello everyone. Apple is having a massive sale on Friday.

If you are interested in apple product now is the time.

If you are a part of the cult of Apple mark the date 25/11/2016 on your calendar.

good luck to you all and may the odds ever be in your favor.

Why should we use dummy data instead of live data?

Why should we use dummy data instead of live data?

Dummy data is benign information that does not contain any useful data, but serves to reserve space where real data is nominally present. It can be used as a placeholder for both testing and operational purposes.

Dummy data must be rigorously evaluated and documented to ensure that it does not cause unintended effects.

There are obvious pro’s and con’s when using dummy data for testing.

Pro’s:

  • Easy to create a dummy set of data for testing as and when needed.
  • There is no need to obfuscate live data.
  • Testers can create the data they need without depending upon other teams.
  • A smaller data set can be created to test against where the testers know exactly what data exists (controlled sample).

Con’s:

  • Dummy data cannot fully replicate every single type of data that exists in production, thus defects could be missed.
  • Using a smaller data set means that load test results may not reflect the size of production data (web page/web service response times).
  • Processing times on a smaller dataset will not accurately reflect what will happen in production (e.g. on an Oracle Financials database).

Most organizations are still using live data in test and development environments because of a lack of awareness around data security, and they don’t know they can easily mask or de-identify sensitive data using off-the-shelf technologies without changing applications or testing processes.

Even when the awareness is there, organizations still tend to rely on real data for its speed and ease of use.

Using live, cloned data is generally regarded as a shortcut when there isn’t enough time or resources to create test data, or a secure test data strategy isn’t in place.

But these are not excuses for a practice that can put customer data in great jeopardy. It is true that in general these test systems are not Internet-accessible, but even if you have absolute trust in all your employees — never a good starting point — that doesn’t remove the risk, as many organizations will outsource parts of development and hire contractors, consultants, and the like.  And if the media has taught us anything over the last decade about carelessness, it’s that people often store this type of data on laptops and removable media devices, and those assets can get lost or stolen.

Beyond the insider threat, there’s also the very real possibility that malicious external hackers can eventually work their way deep enough into the network after a blended attack and get their hands on test applications and live data.

The biggest change in recent years is the legislation requiring live data to be obfuscated on pre-live environments.  The challenge is to replicate live issues on non-live environments, and to test on live-like data prior to releasing code to production. Failure to do so can lead to defects being uncovered in production, just due to a deficiency in the actual data or the volume of the data used on a test environment.

It’s a challenge but one that cannot be ignored. Either you use hand-crafted dummy data, or obfuscated live data – either way, you cannot just take live data and test it unchanged!

 

Under what circumstances will you hold your TFN

Under what circumstances will you hold your TFN

Tax file numbers are unique numbers issued by the Australian Taxation Office (ATO) to identify individuals, corporations and others who lodge income tax returns with the ATO.

Once you get a tax file number (TFN), you need to keep it safe. Your TFN is how we identify you for tax and super. It’s yours for life, so don’t let anyone else use it – not even friends or family.

If someone else uses your TFN, it can cause serious problems because they could use your name illegally and you could be convicted of a crime.

Your TFN information must only be used or disclosed by TFN recipients for:

  • a purpose authorised by taxation law, personal assistance law or superannuation law
  • the purpose of giving you TFN information that they hold about you.
  • lodge a tax return
  • apply for income assistance or support payments, such as pensions or benefits from DHS (which administers the Centrelink, Child Support and Medicare Programs) or DVA
  • start a new job or change jobs
  • have savings accounts or investments that earn income (eg interest or dividends)
  • receive a payment under the Higher Education Loan Program
  • join a superannuation fund.

TFNs may not be used by a financial institution to confirm your identity.  You must make sure you keep your TFN information in a safe place.  It should be properly destroy any TFN information that you no longer need. This will help prevent other people stealing your identity. You should report a lost or stolen TFN, or unauthorised access of your TFN information to the ATO.

The Privacy (Tax File Number) Rule 2015 (TFN Rule) outlines how your TFN information should be collected, stored, used, disclosed and kept safe. All people, agencies, organisations and other entities that are allowed to ask for your TFN information must follow the TFN Rule.

The people, agencies, organisations and other entities that are allowed to ask for your TFN information must not record, collect, use or pass on your TFN unless this is permitted under taxation, personal assistance or superannuation law.

There is no law in Australia that says you must give an authorised person, agency, organisation or other entity your TFN if they ask for it. However, sometimes there may be financial consequences if you don’t give your TFN to someone who is allowed by law to ask you for it.

 Examples

  • If you are claiming or receiving a personal assistance payment from DHS (such as a pension, benefit or allowance) they may ask for your TFN to check your information with the ATO and other agencies that make payments.
  • If you do not give DHS your TFN, certain personal assistance payments may not be paid to you. Providing your TFN is a condition of receiving most Australian Government personal assistance payments.
  • If you don’t give your employer, bank, other financial institution or superannuation fund your TFN, it may affect how much tax you pay and could result in tax being deducted from your income or your interest payments at the highest marginal rate.
  • Your superannuation fund may ask for your TFN to facilitate the location and combination of your superannuation accounts. If you decide not to quote your TFN, the fund may not be able to find any additional accounts that you may have.

When an authorised person, agency, organisation or other entity asks you for your TFN, they must tell you:

  • why they are collecting it (including the name of the law or laws that allow them to collect your TFN and the purpose for which they are collecting it)
  • that it is not an offence if you do not give them your TFN
  • what will happen if you do not give them your TFN.

This information must be included in any forms that ask you for your TFN. The description of the purposes for collection can be reasonably general as long as it adequately informs you of what the law authorises the person, agency, organisation or other entity to do with your TFN.

If you consider someone has not handled your TFN information properly, you can make a complaint to the OAIC. And before you can make a complaint to the OAIC, you must first make your complaint to the person, agency, organisation or other entity you consider has mishandled your TFN information.