In order for you to succeed in being an effective project manager you have to define the target and the goal of the project. You need to know where this project is going and what it is trying to achieve. For instance, if your boss asks you to organize a blood donation campaign from the employees. You have to know the scope of the project. You have to know if this project is aiming to donate as much blood as it can to the blood bank or is it another reason such as elevating the community profile of the company. Knowing the real reason and target of a certain project would help you exceed and manage it well. This is why knowing the real scope and aim of a project is one of the bases of successful project management.
As the head of the project management staff you also have to know all of the activities involved. For instance, will the company provide transportation for the employees from and to the blood bank or will they be asked to drive themselves. Knowing the activities will help with the organization and planning as it will have a great effect on the work scope that will have to be done throughout the project. You also need to acknowledge the stakeholders because you will have to ask for their help. You need to understand and know what they are expecting by the end of the project as this will help you plan and manage your project more efficiently.
The next step in your project management crusade is to understand and define the expected outcome of the project. You need to know what are the products, things or services that are expected to be delivered when the project is over. For instance, if you are the project manager of an advertising campaign then the client expects a piece of art work or an advert in the newspaper. Understanding the deliverables will help you plan and manage your project much easier.
Another vital step in project management is to make sure that there is communication between the different team. Each team has to know what is asked from it and what is it expected to deliver. All the teams need to have a good level of communication with each other as well. If there is no communication between you and the teams and between the teams themselves then the project will be deemed to fail.
Monday, July 9, 2012
Sunday, July 8, 2012
What you need to know about Software architecture
At the end of the 60s, the programmers came out with a philosophy that is related to developing software. The concept stated that if the data structures are correct and stable and by applying effort, the development of the program will go very smoothly without any problems. Back in the 60s is was only an intuition and a philosophical concept but in the 1970s it was transformed from just a concept into a theory. The transformation of this concept to a real theory included the grasping and understanding of several points.
These points included the structure of the architecture software and the specifications. These specifications were expressed through math as algebraic axioms or abstract models. The understanding of language problems was also vital. It included user-defined types, scope and modules. Another major point that had to be understood is the protection of the information. This includes all kinds of information and not only the ones that are a part of the specifications. This is very essential as the protection of this information is vital to the success of any software development.
The target of this transformation was to enhance the quality of the architecture design of several parts of the software. This included the enhancing of abstract data types in order to surpass the level of the programming language or statements. In order to achieve that, the understanding of the above mentioned points were accompanied by integrating specifications, representations, functional interfaces and algorithms in uniform methods. In order for the architecture design to succeed, the programming language had to be used but the abstract data type paradigm gave some pieces of the system the ability to be developed using a vocabulary of data types that is not included in the programming language’s vocabulary.
The same ways programmers recognized the usage of strong and correct data structure back in the 60s, now experienced software developers recognize strong system organizations. Although many organizations and architecture software designers depend on abstract data types but this is not the only available method to organize a software system. This is due to the fact that other designers and developers have developed various organizations over the course of time. These organizations have become a solid part of the vocabulary of the language that software designers use. So as a software developer you have the choice to either choose these new organizations or the usual abstract data types.
These points included the structure of the architecture software and the specifications. These specifications were expressed through math as algebraic axioms or abstract models. The understanding of language problems was also vital. It included user-defined types, scope and modules. Another major point that had to be understood is the protection of the information. This includes all kinds of information and not only the ones that are a part of the specifications. This is very essential as the protection of this information is vital to the success of any software development.
The target of this transformation was to enhance the quality of the architecture design of several parts of the software. This included the enhancing of abstract data types in order to surpass the level of the programming language or statements. In order to achieve that, the understanding of the above mentioned points were accompanied by integrating specifications, representations, functional interfaces and algorithms in uniform methods. In order for the architecture design to succeed, the programming language had to be used but the abstract data type paradigm gave some pieces of the system the ability to be developed using a vocabulary of data types that is not included in the programming language’s vocabulary.
The same ways programmers recognized the usage of strong and correct data structure back in the 60s, now experienced software developers recognize strong system organizations. Although many organizations and architecture software designers depend on abstract data types but this is not the only available method to organize a software system. This is due to the fact that other designers and developers have developed various organizations over the course of time. These organizations have become a solid part of the vocabulary of the language that software designers use. So as a software developer you have the choice to either choose these new organizations or the usual abstract data types.
Saturday, July 7, 2012
Architecture principles for different businesses
If you are in a position where you have to architect enterprises and different business applications where you have to use different COTS products & come out with architecture solutions around these products. Then you should follow these easy and simple principles that would help you architect different solutions for your business. The first rule is to keep everything stupid and simple. You should not use complex and complicated words or terms that would make the readers scratch their heads. Some people think that the more complicated the more professional which is terribly wrong because if the readers do not understand it then it is of no use. So make sure to keep everything clear and a simple for the stakeholders whether its IT, Infra Team or Business.
The second principal is communication. Maintaining a strong network of communication of architecture to the whole team is essential and vital to the success of your solutions. This includes both external & internal stakeholder’s teams. Your side includes the development, deployment, testing and PMO teams. As for the other side, the client’s side it includes IT, security and business. Connecting all of the above teams together is one of the ingredients of success.
The third principal is the flexibility in the requirements. You have to be prepared and ready to accept changes that might occur. This is essential because as much as we would like for everything to stay the same but things change. For instance the requirements that always change include HTML appearance, the layout of the content and so on. On the other hand there are requirements that never change such as auditing, messaging and logging. This is why in order for your architecture solutions to work, it has to be flexible and for you to accept changes. Not only to accept them but to be prepared for them and to expect them.
Lastly, in any given architecture project and design, decisions will have to be made. People tend not to take decisions in order to avoid the risk of being wrong. The best thing to do is to take a look at the data and information available and to take decisions according to them for the project to move along. Even if you are wrong, the project and the design will move on. Plus, you gave your best decision according to the available data. So you did the best you can with what you had.
Visit http://www.tlconsulting.com.au/testing-services/architecture-design to know more about architecture
The second principal is communication. Maintaining a strong network of communication of architecture to the whole team is essential and vital to the success of your solutions. This includes both external & internal stakeholder’s teams. Your side includes the development, deployment, testing and PMO teams. As for the other side, the client’s side it includes IT, security and business. Connecting all of the above teams together is one of the ingredients of success.
The third principal is the flexibility in the requirements. You have to be prepared and ready to accept changes that might occur. This is essential because as much as we would like for everything to stay the same but things change. For instance the requirements that always change include HTML appearance, the layout of the content and so on. On the other hand there are requirements that never change such as auditing, messaging and logging. This is why in order for your architecture solutions to work, it has to be flexible and for you to accept changes. Not only to accept them but to be prepared for them and to expect them.
Lastly, in any given architecture project and design, decisions will have to be made. People tend not to take decisions in order to avoid the risk of being wrong. The best thing to do is to take a look at the data and information available and to take decisions according to them for the project to move along. Even if you are wrong, the project and the design will move on. Plus, you gave your best decision according to the available data. So you did the best you can with what you had.
Visit http://www.tlconsulting.com.au/testing-services/architecture-design to know more about architecture
The difference between architecture & engineering
The question that has kept all the art historians and philosophers wondering and yet failed to find a clear and a specific answer, “what is architecture?” Not only them, as many of us find themselves wondering the same thing. It can be explained as any piece of work that has some sort of substance that has acquired a physical state. Any work that has the mentioned characteristics would pass as being architecture.
Whenever an architect starts his project, his main goal is to capture and realize a dream that he has in his mind. Every architectural design is aiming to achieve a concept or a goal that is set by the architect himself. This dream or goal can be a form, a function or a philosophy. An architect uses all of his past experiences and collective knowledge to achieve all of that, the end result of it all is what architecture means.
Some people mix between architecture and engineering. They think that they are the same because they both result in buildings and construction. They cannot be any more wrong. There is a very thin line between architecture and engineering. Engineering is the act of eliminating any kind of emotions or feelings while designing, this result in an emotionless design that is very objective and has the function as its first and only priority. On the other hand architecture is the absolute opposite of that as it is all based around the emotions, feelings and dreams of the designer and architect. The end result of a design made by an architect would be the result of all of his emotions and feelings. This is why the design is not revolved around the objectivity which is the function but rather around the emotions and dreams.
To sum it up, the difference between engineering & architecture lies in the emotional force and philosophical concept of the architect that is embedded into the design. For instance, reading a script of an opera and reading it objectivity from the paper differs completely from hearing it and seeing it being performed on stage. You will certainly feel a rush of emotions and feelings when watching it and you will not get that feeling if you are just reading the notes and the script objectively from the paper. This is why architecture is looked upon as a piece of art and as any piece of art, it has to be filled with emotions and as far as it can be from subjectivity.
Whenever an architect starts his project, his main goal is to capture and realize a dream that he has in his mind. Every architectural design is aiming to achieve a concept or a goal that is set by the architect himself. This dream or goal can be a form, a function or a philosophy. An architect uses all of his past experiences and collective knowledge to achieve all of that, the end result of it all is what architecture means.
Some people mix between architecture and engineering. They think that they are the same because they both result in buildings and construction. They cannot be any more wrong. There is a very thin line between architecture and engineering. Engineering is the act of eliminating any kind of emotions or feelings while designing, this result in an emotionless design that is very objective and has the function as its first and only priority. On the other hand architecture is the absolute opposite of that as it is all based around the emotions, feelings and dreams of the designer and architect. The end result of a design made by an architect would be the result of all of his emotions and feelings. This is why the design is not revolved around the objectivity which is the function but rather around the emotions and dreams.
To sum it up, the difference between engineering & architecture lies in the emotional force and philosophical concept of the architect that is embedded into the design. For instance, reading a script of an opera and reading it objectivity from the paper differs completely from hearing it and seeing it being performed on stage. You will certainly feel a rush of emotions and feelings when watching it and you will not get that feeling if you are just reading the notes and the script objectively from the paper. This is why architecture is looked upon as a piece of art and as any piece of art, it has to be filled with emotions and as far as it can be from subjectivity.
Friday, June 1, 2012
Practical Security Infrastructure Testing
When building and deploying new security infrastructure, the moment eventually arrives where you have to connect your new system to the Internet. This is the moment of truth, where you expose your carefully crafted infrastructure to hackers, crackers, phishers and script kiddies who are always to exploit someone else’ mistakes.
Before you get to this point, you want to have tested the security of you deployment very carefully, and this often gets overlooked in project planning. Many a project has stalled because the business would not approve connecting an untested build to the Internet, and it was not possible to perform effective testing without having the infrastructure connected to the Internet. Consideration should be given to security testing as early as possible in the design phase of the project: who will do the testing, and what sort of access and connectivity will they need? How can that access and connectivity be provisioned without exposing the new deployment to the Internet at large?
TL Consulting (www.tlconsulting.com.au) recommends that the first phase of security testing be conducted in house, using static testing techniques to ensure that the design and configuration of the new infrastructure complies with the organisation’s security policy, and to establish a working baseline. This work can be started very early in the project, and should ideally be commenced before the detailed design is signed off and before equipment is purchased. Regular review phases will ensure that there is no unapproved “drift” from the baseline.
TL Consulting also recommends that the second phase of security infrastructure testing should be white box style internal testing, conducted from within the network where the new infrastructure resides. In this phase the testers should be given access to the systems either as trusted users, or as attackers who have already breached the defences. The goal in this phase is to uncover vulnerabilities that could be exploited, and to understand the extent of the damage that a successful attack could cause.
External testing should initially be mimicked using a harness to emulate access from the Internet. This type of harness can often be provisioned using a low-end router to provide connectivity for the testers to the “outside” of the infrastructure. Testing in this phase should include a mix of positive and negative testing, to ensure that traffic and transactions that should pass and succeed do so, and that all other traffic is blocked, and that appropriate logging is in place.
Formal penetration testing should always be performed by a third party. A third party is more likely to spot deficiencies that the people who have worked on building the infrastructure. If a third party is engaged to perform internal testing, that work should be completed and the results analysed – and any defects remediated – before external testing proceeds. Both internal and external testing should be re-executed on a regular basis, in line with the organisation’s security policy.
Learn more about Test Data Management.
Before you get to this point, you want to have tested the security of you deployment very carefully, and this often gets overlooked in project planning. Many a project has stalled because the business would not approve connecting an untested build to the Internet, and it was not possible to perform effective testing without having the infrastructure connected to the Internet. Consideration should be given to security testing as early as possible in the design phase of the project: who will do the testing, and what sort of access and connectivity will they need? How can that access and connectivity be provisioned without exposing the new deployment to the Internet at large?
TL Consulting (www.tlconsulting.com.au) recommends that the first phase of security testing be conducted in house, using static testing techniques to ensure that the design and configuration of the new infrastructure complies with the organisation’s security policy, and to establish a working baseline. This work can be started very early in the project, and should ideally be commenced before the detailed design is signed off and before equipment is purchased. Regular review phases will ensure that there is no unapproved “drift” from the baseline.
TL Consulting also recommends that the second phase of security infrastructure testing should be white box style internal testing, conducted from within the network where the new infrastructure resides. In this phase the testers should be given access to the systems either as trusted users, or as attackers who have already breached the defences. The goal in this phase is to uncover vulnerabilities that could be exploited, and to understand the extent of the damage that a successful attack could cause.
External testing should initially be mimicked using a harness to emulate access from the Internet. This type of harness can often be provisioned using a low-end router to provide connectivity for the testers to the “outside” of the infrastructure. Testing in this phase should include a mix of positive and negative testing, to ensure that traffic and transactions that should pass and succeed do so, and that all other traffic is blocked, and that appropriate logging is in place.
Formal penetration testing should always be performed by a third party. A third party is more likely to spot deficiencies that the people who have worked on building the infrastructure. If a third party is engaged to perform internal testing, that work should be completed and the results analysed – and any defects remediated – before external testing proceeds. Both internal and external testing should be re-executed on a regular basis, in line with the organisation’s security policy.
Learn more about Test Data Management.
How to Use Web Testing Scorecard
Web testing scorecards will concentrate mainly on the GUI (Graphic user interface), GUI is used by websites to enable the users to browse easily within the pages of website. The website’s GUI functionality has great impact on the amount of traffic generated by a website.
GUI is created to provide effective control to the users on computers. In this case, control means the flexibility with which the Graphical User Interface reacts to the commands of users. Developing the website’s GUI quality will be the first thing that a web test scorecard will attempt to achieve. Logically the goal will be to give users the required graphic interface functionality by making use of the most appropriate web technology that is available.
The homepage will get the initial attention naturally, while testing a design of the website. The questions that you may ask here are: how the homepage is found by a visitor? Is easy navigation with the pages of website is allowed by the homepage menus? Does the design of the homepage and building inspire more visitors? Being biased, owner of a website or developer will tend to provide desired answers but there is a good and more precise way of measuring the functionality of homepage and that is, to ask the users about their opinion.
A web testing will decide the efficiency of GUI by measuring the flexibility and speed with which users browse from the homepage to other pages of website and back and to link with important links. A good GUI pattern will often give obviously located navigation points in every page and graphic buttons that give graphic recognition, which informs searchers they are still within the domain of a website.
The creation of the site should give straight forward links to embedded pages within the website. A well planned GUI will not fall short of links that will make the searchers to come back to the homepage, otherwise, they will be clenched in the page and will not have any opportunity to come to other pages of the site. Every page should have links to other sections and pages, which is even better.
Interface speed is another web testing that is good for measuring the functionality of website. Users are believed to give only 10 seconds of waiting time to enter websites before going somewhere else. This means, website interface should be assembled with access speed of majority users. Searchers on internet usually use dial-up connections. So it has to be aligned by considering that speed.
GUI is created to provide effective control to the users on computers. In this case, control means the flexibility with which the Graphical User Interface reacts to the commands of users. Developing the website’s GUI quality will be the first thing that a web test scorecard will attempt to achieve. Logically the goal will be to give users the required graphic interface functionality by making use of the most appropriate web technology that is available.
The homepage will get the initial attention naturally, while testing a design of the website. The questions that you may ask here are: how the homepage is found by a visitor? Is easy navigation with the pages of website is allowed by the homepage menus? Does the design of the homepage and building inspire more visitors? Being biased, owner of a website or developer will tend to provide desired answers but there is a good and more precise way of measuring the functionality of homepage and that is, to ask the users about their opinion.
A web testing will decide the efficiency of GUI by measuring the flexibility and speed with which users browse from the homepage to other pages of website and back and to link with important links. A good GUI pattern will often give obviously located navigation points in every page and graphic buttons that give graphic recognition, which informs searchers they are still within the domain of a website.
The creation of the site should give straight forward links to embedded pages within the website. A well planned GUI will not fall short of links that will make the searchers to come back to the homepage, otherwise, they will be clenched in the page and will not have any opportunity to come to other pages of the site. Every page should have links to other sections and pages, which is even better.
Interface speed is another web testing that is good for measuring the functionality of website. Users are believed to give only 10 seconds of waiting time to enter websites before going somewhere else. This means, website interface should be assembled with access speed of majority users. Searchers on internet usually use dial-up connections. So it has to be aligned by considering that speed.
Perspective - Investment in Performance Testing
Ideally in a real world Project or Testing Lifecycle, it is essential that Performance Testing is considered an Investment priority, this is valuable from a business and IT perspective. Preferably to ensure the Application, System or Environment under test is:
1. Fit for purpose – Meets agreed business SLA’s/Performance level requirements.
2. Responsive – Performance responsiveness is crucial under various user/load scenarios.
3. Scalable – Meets current and future capacity requirements to scale up or scale out.
4. Stable – Meets Performance level requirements under load.
5. Confidence – Business and IT Stakeholders need to be confident the system will perform to expected requirements and SLA’s.
Further to the above, another critical success factor in ascertaining whether you should invest in performance testing is evaluating your Return on Investment (ROI). Some of the elements that can provide justification for this include:
1. Application Tuning – Find and fix architectural defects and Performance Bottlenecks.
2. Environment/Infrastructure Tuning – Improved efficiency of existing hardware.
3. Capacity Planning – Identifying the size and scale for future capacity requirements.
All of the above principles and concepts are considered ‘best practice’ and are advised to be applied in a traditional Performance Testing Model. Clearly time and budget are constraints, but if the investment is available it is certainly worth the while to ensure stability and sustainability to IT Projects longer term.
From our experience, there are a number of areas within a Performance Testing practice or function we can provide a significant value proposition, these include:
1. Senior Management Expertise – Strong Non-Functional Test Strategy & Management
2. NFT SME Capability – Providing resources that enhance delivery and provide subject matter expertise (SME) in Performance Testing and tooling.
3. Performance Engineering – Optimised approach towards Architectural test analysis, Performance tuning with a focus on customer experience.
4. Static Testing of Non Functional Requirements
5. Non-functional requirements analysis and traceability
Read more about Test Environment Management by visiting one of the best Australian based IT Professional company http://www.tlconsulting.com.au/
1. Fit for purpose – Meets agreed business SLA’s/Performance level requirements.
2. Responsive – Performance responsiveness is crucial under various user/load scenarios.
3. Scalable – Meets current and future capacity requirements to scale up or scale out.
4. Stable – Meets Performance level requirements under load.
5. Confidence – Business and IT Stakeholders need to be confident the system will perform to expected requirements and SLA’s.
Further to the above, another critical success factor in ascertaining whether you should invest in performance testing is evaluating your Return on Investment (ROI). Some of the elements that can provide justification for this include:
1. Application Tuning – Find and fix architectural defects and Performance Bottlenecks.
2. Environment/Infrastructure Tuning – Improved efficiency of existing hardware.
3. Capacity Planning – Identifying the size and scale for future capacity requirements.
All of the above principles and concepts are considered ‘best practice’ and are advised to be applied in a traditional Performance Testing Model. Clearly time and budget are constraints, but if the investment is available it is certainly worth the while to ensure stability and sustainability to IT Projects longer term.
From our experience, there are a number of areas within a Performance Testing practice or function we can provide a significant value proposition, these include:
1. Senior Management Expertise – Strong Non-Functional Test Strategy & Management
2. NFT SME Capability – Providing resources that enhance delivery and provide subject matter expertise (SME) in Performance Testing and tooling.
3. Performance Engineering – Optimised approach towards Architectural test analysis, Performance tuning with a focus on customer experience.
4. Static Testing of Non Functional Requirements
5. Non-functional requirements analysis and traceability
Read more about Test Environment Management by visiting one of the best Australian based IT Professional company http://www.tlconsulting.com.au/
Subscribe to:
Posts (Atom)