Maybe I’m not into the whole stuff, but Apple came to Ireland and made a deal. No matter if this was legal or not, it was a deal, so now I don’t think Apple should pay anything…
The one that should pay is Ireland, as with this agreement Ireland was tricking the other EU governments. If we want Europe, the taxation system should be the same everywhere otherwise there is no Europe. Obviously Ireland can always do the same as England (Irexit) and then they would be able to have Apple for free, but then they should pay all the consequences..
Packet analysis can discover issues in your network, but if there is a load balancer in the mix, you’ll want to follow these best practices.
Sorgente: Network Troubleshooting: Consider The Load Balancer – Network Computing
taken from http://www.lifehack.org/articles/productivity/50-things-highly-productive-people-differently.html
Simple and effective
taken from http://uk.businessinsider.com/famous-business-book-summaries-2014-5
This is just a short note on a new NIST publication: Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations
Here’s the link
I recently had to review some of the security standards in order to get consistency in the framework I have been defining.
For this reason I had to get some order and to grasp as much as possible from each standard “on the market”.
As a result from this work I was able to made a simple list to be used as reference in case you need to go trough the definition of security framework.
The simple explanation I’m giving is just for reference and doesn’t aim to give any insight. I will eventually update the article with more references as I will use them. Possibly for each of the standard a new article will follow.
The first and most important standard I have been following is the family of ISO 27000 (Information Security Management).The ones I used most are:
- ISO 27001:2013 which gives in detail the requirements for implementing an Information Security Management System. This standard is one of the best to follow in order to assess the security compliance of your organization.
- ISO 27002:2013 which highlights the best practices to set up a system of security controls
- ISO 27005:2011 which gives the basis to set up a serious IT Risk Framework in your organization
To get deep understanding of the ISO27K the NIST (National Institute of Standards and Technology) standards are the most valuable ones. Just to note that NIST is an american agency that basically defines a series of strong standard in the system security area.
Together with NIST I strongly suggest to take a look at the The Standard of Good Practice for Information Security that give a full coverage on standard and control practices that can be fully and straightforward applied to any environment.
I got good insights from the the Payment Card Industry (PCI) Data Security Standard (DSS) that was developed by some of the major credit card companies and consists in a series of core requirements to be developed in order to achieve data security in credit cards payments
Most of the times, in order to get the big picture, I had to refer to the famous Control Objective for Information and related Technology (COBIT) or to the ITIL (Information Technology Infrastructure Library) frameworks. COBIT is basically a control framework that enables the management and right governance of an ICT system, while ITIL is not directly linked to security but is again a series of good practices in managing and operating IT systems. As a matter of fact most of the practices have a direct impact on the security of the systems (e.g patch management and incident management).
The ones up are in my opinion the basics, while additional ideas can be obtained from
- HIPAA (Health Insurance Portability and Accountability Act) that is a standard which aims directly to protect the confidentiality and security of healthcare information
- The Federal Information Security Management Act (FISMA) that is an american legislation that define a framework to protect government information, operations and assets against natural or man-made threats.
- FIPS (Federal Information Processing Standards) which represents a series of publications of the NIST that represents guidelines and standards and in general minimal security requirements that US federal agencies must follow.
- The ISO/EIC 15408 well known also as common criteria helps to evaluate, validate and certify the security assurance of a technology product against a certain number of factors. Hardware and software are generally validated against this standard
where possible I put some links in my link page.
A constraint is anything that restricts the project manager’s options. Constraints are requirements, confines, or, if you’re a glass-is-half-empty kind of person, prison walls.
Constraints can include:
- Schedule. You and the project team must create the software deliverable by such-and-such date — or else. Schedule constraints can also be crunched by the availability of project resources, vendors’ ability to deliver, and even access to testing facilities, server rooms, and networks.
- Budget. Of course, you’ve got a budget, but is it enough? In software project management, the bulk of your budget is tied to labor. The longer your programmers take to create accurate code, the more expensive your project deliverable becomes. You must find a balance between the cost of work and the required quality. Additionally your budget consists of not human resources, as material, space rent, machine rent … usually however this part is know with a better detail at the beginning of a project.
- Resources. You probably have your favorite workers that you’d like to work with on every project because simply they guarantee the result. But they can’t do everything, they’re in high-demand, and chances are, because of their skill sets, they’ll cost your project more. And even if you don’t play favorites, which I bet you do, you may still face resource challenges. Most organizations don’t dedicate their people to just one project at a time — so which project has priority for the resources you need? You’ll have to bargain, beg, and plead (sometimes) to get the resources you need and want.
- Technology. In every project this is a strong boundary. When it comes to software project management, you have to deal with surprises, like programming in COBOL, Visual Basic, PHP on a new platform, and more. And sometimes the technology you have to interface with is so old you’ll be consulting with Leonardo da Vinci just to be backward compatible. On the other side, sometimes technology is so advanced that probably we would need doctor Spock to deal with it. All this to give the message that technology can be a huge constraint.
- Competence. No one likes to admit to not knowing something. But if your project team doesn’t know how to solve problems, how to perform day-to-day activities, or even the functional characteristics of the product they are developing, then you’re in big trouble. You need to have an approach to skill assessment. You need to create an environment where workers are encouraged to ask for help when they need it. It’s better to train, offer materials, or hire experts to help the project than to let your team wallow in denial and produce a crappy product.
- Management. this is the most dangerous as it sums up all the others. Have you ever said: “We don’t have enough time!”, “We don’t have enough cash!”?
Management is often setting unrealistic expectations, even if we should admit that sometimes we have to determine who’s really to blame. Usually the project managers are correct. Usually. But sometimes the project managers are so out of tune of the project management processes that they don’t know how to plan or attack the project objectives.
Other times, management has no concept of what the characteristics of the project (e.g. software development) are. Management may throw a schedule and budget together and dump them on the project manager’s desk. In these instances the project manager must communicate the problem. If the project manager does nothing other than rant in private, things won’t change and the project will likely fail.
The key here is to document the problem as a risk, share the risk assessment with management, and then document the results. If you’re faced with unrealistic expectations from management, your job is not to fail and then tell the managers, “I told you so.” (That will not earn you a promotion) It’s to say, “Here’s a problem: unrealistic expectations. How will we fix it?”
Here are the basic principles of TOC that find there application in the critical chain management:
- Eliminate Safeties from Each Task
- Management Must Not Insist on Each Task Starting & Finishing “On Time”
- Stagger Tasks in the Schedule Using Finish to Start Constraints
- Start Right Jobs at Right Time Using Prioritized Task List
- Focus on Meeting Milestone Dates, Not Task Dates
- Single Integrated Schedule
- Update Official Schedules Daily with Actual Starts, Remaining Duration, & Actual Finishes
- Predict Milestones Based on Buffer Penetration
- Focus on Task Throughput, NOT on Task Costs
- Counter Parkinson’s Law
- Conserve Available Float/Slack on Each Task, Reduce Time Available
- Counter Student Syndrome
- Start Each Task As Early As Possible
- Claim Early Finishes Immediately
- When Problems Occur, Solve the Problem vice Starting New Task
- Decrease Frequency & Duration of Meetings
- Resolve Conflicts Immediately at the Jobsite
- Eliminate Bad Multi-tasking
- Resources Focus on One Job at a Time, Work to Completion
- Keep WIP Low!
- Request Only Resources Necessary to Accommodate Priority Work
- Request Only Overtime Necessary to Recover Buffer on Priority Work
- Move Resources When Work is Done to Next Priority Work Quickly
- Work Right Jobs instead of Easy Jobs
- Plan for New Work & Scope Changes vice Complaining About it