System testing

System testing of software or hardware is testing performed on a complete, integrated system to check and evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic. [1]
As a rule, system testing takes, as its input, all of the "integrated" software components that have successfully passed integration testing and also the software system itself integrated with any applicable hardware system(s). System testing is a more limiting type of testing; it seeks to detect defects both within the "inter-assemblages" and also within the system as a whole.
Testing the whole system
System testing is performed on the entire system in the context of a Functional Requirement Specification(s) (FRS) and/or a System Requirement Specification (SRS). System testing is an investigatory testing phase, where the focus is to have almost a destructive attitude and tests not only the design, but also the behavior and even the believed expectations of the customer. It is also intended to test up to and beyond the bounds defined in the software/hardware requirements specification(s). System testing includes the Load testing and Stress Testing. Once the Load testing and Stress testing is completed successfully, the next level of Alpha Testing or Beta Testing will go ahead.
Types of system testing
The following examples are different types of testing that should be considered during System testing:
• GUI software testing
• Usability testing
• Performance testing
• Compatibility testing
• Error handling testing
• Load testing
• Volume testing
• Stress testing
• User help testing
• Security testing
• Scalability testing
• Capacity testing
• Sanity testing
• Smoke testing
• Exploratory testing
• Ad hoc testing
• Regression testing
• Reliability testing
• Recovery testing
• Installation testing
• Idempotency testing
• Maintenance testing
• Accessibility testing
(Source: Wikipedia.com)

I have experience performing system testing. I must admit that the job is a laborious one considering the fact that you have to test every niche of the site. But in the end I find it fun and very interesting. Some would disregard system testing and even say "Why test at all?". Why indeed? If your site provides services like online transaction, online buy and sell, etc. then you definitely need a polished, almost perfect and error-free site. If you did not perform a thorough system testing, there is a huge possibility that people will always encounter bugs, problems, etc. And if there are many dissatisfied customers, then they will not patronize your services. And if they will not patronize your services or will not visit your site anymore, then it will be a big financial loss to you. So my advise is, DO NOT FORGET TO SYSTEM TEST YOUR ENTIRE WEBSITE, SOFTWARE OR SOFTWARE/HARDWARE.
plobrin@gmail.com
Website QA/Tester

PROJECT INTEGRATION MANAGEMENT – A Key to Overall Project Success

Let’s face it, it is indeed difficult to handle an IT project. So many matters to consider like schedule to meet, budget allocation, constant inquiries from stakeholders, team to manage, constant changes, etc. Due to the complexity of an IT project, many Project Managers (PM) tend to focus on the system to build rather than at the “big picture”.
One duty of a project manager is to coordinate all of the knowledge areas throughout a project’s life cycle. These knowledge areas are: Scope, Time, Cost, Quality, Human Resource, Communications, Risk and Procurement. I shall discuss individual knowledge areas in my succeeding articles. Project Integration Management cements all these knowledge areas in such a way that the project will be a complete success. Note that Project Integration Management is not the same thing as software integration management. The former is integration on the “big picture” (or entirety of the project) while the latter is integration on the software components only.
Project Integration Management includes the processes and methods required to ensure that the various elements of the project are properly organized. Example of which is making tradeoffs among competing objectives. Project Integration Management is divides into three parts: Project Plan Development, Project Plan Execution and Integrated Change Control.
Project Plan Development is where developers plan what they will do with their IT project. Apart from planning the entirety of the project, developers also consider other important aspects [of the project], like: Historical information, Organizational policies, and Constraints and Assumptions. The result of excellent planning is the creation of a Project (Development) Plan. This plan is used as a main document that serves as guide and blue print in project execution and project control. This document coordinates all project planning documents and assists the PM in leading the project team and assessing the project’s status. See Project Development Plan: the First Guide in Building an IT System.
Project Plan Execution is the primary process for carrying out the project plan and this is the area where the project’s budget and time is spent more. The application area or the project affects project execution because the products are produced during execution. The result of excellent planning – Project Plan – serves as input to Project Plan Execution. That is, Project Plan Execution is dependent on the result of excellent project planning, excellent creation of a project plan. Apart from this document, developers must also consider other important aspects at this stage like: Organized policies, Preventive action and Corrective action. The results of executing the Project Plan are Work Results and Change Requests. By executing the plan, results are recorded; however changes (proposed or brought about by the circumstances) cannot be avoided especially if these changes benefit the project. Here are a few samples of the tools and techniques used during project plan execution: (1) Work Authorization System – a method used to ensure that people do perform their tasks, (2) Status Review Meetings - regular and scheduled meetings where the project team discusses all things related to the project, and (3) Project Management Software - a software used in assisting a team in managing their projects.
Integrated Change Control is concerned with: (1) controlling factors that create changes to ensure that changes are agreed upon by all stakeholders, (2) determining that a change has indeed occurred, and (3) managing the actual changes when they occur. During Project Plan Execution, performance reports and change requests are gathered also. Change Request is a kind of document where all proposed changes affecting the system being built are listed and described. After the changes have been studied, corrective actions will be implemented and lessons are absorbed.
Change Control System is a process that describes how official project documents and work may be changed. The process describes the personnel who can make changes. Also, the process includes a change control board (CCB), configuration management, and a process for relaying the changes. The CCB is a group of people tasked to approve or reject changes on a project. They provide guidelines and documents for change requests, evaluate then and supervise how these changes are to be implemented.
Configuration management makes sure that all products (e.g. required documents) and their descriptions are correct and complete. Configuration management personnel identify and document configuration requirements, control changes, record and manage changes, and check the products to verify conformance to requirements.
P.Lobrin
plobrin@gmail.com

Software Development Life Cycle

Before, whenever a developer is tasked to perform programming or coding, he immediately would jump to it, start programming with or without full knowledge of what the system would look like, how the features are arranged, etc. It is probably okay only if you’re just building a very simple system. However, if you’re building a complex and sophisticated system, it will take a long time for you to finish. Worse, you start to suffer from “groping in the dark” syndrome since your full of ideas, you want to implement them all, but you tend to forget about them because other features need to be prioritized.
That was before. Now, whether an IT system is small, medium or large scale, it is important to have a proper software/system development plan from beginning to end. It saves time, features of the system are well documented and will not be forgotten regardless of priority, and above all, there is proper management and execution of plans.
System Development Life Cycle (SDLC) models help in the complete development of a system, right from the conceptual stage to the customer delivery stage. SDLC is very useful if one has a complicated system to build. SDLC is the overall process of developing information systems through a multi-step process, from investigation of initial requirements to analysis, design, implementation and maintenance.
To properly illustrate the SDLC models, I shall present them in bullet form.
1. Waterfall Model
• One of the older SDLC models
• Each single step in the process of system development is first written down in the form of specifications and reports. Only then are the actual phases initiated in practice
• The execution of a project appears as a sequence of stages in which the output of each stage becomes the input for the next
• The stages in Waterfall method are divided into the ff:
1. Project planning / feasibility study – commonly known as Requirements Stage. It is in this stage that developers/stakeholders determine the project goal
2. System analysis – refines project goals into defined functions and operations. It also analyses end-user information needs (Specification stage)
3. System design – describes desired features and operations in detail (Design stage)
4. Implementation / Coding (Implementation stage)
5. Integration and testing – brings all the individual system components into one, then testing it for errors, bugs, etc. (Integration stage)
6. Acceptance, Installation, Deployment – final stage of development where the software is put into production
7. Maintenance – this goes on apparently forever since changes, additions, etc are always essential, important and needed in a software application especially in the area that involves business and monetary transactions.
• Drawbacks
1. Works well on simplistic activities
2. Assumes that the only role of users is in specifying requirements and that all requirements can be specified in advance. Unfortunately, requirements grow and change
3. It is, thus, well suited to projects that has low risk in the areas of user interface and performance



2. Spiral Model
• Most generic of the models. Most life cycle models can be derived as special cases of the spiral model
• Set of important requirements are selected for each prototype. Thus, developers can split the requirements and work first on those with high priority
• Employs a risk management approach to software development especially in the stages of Specification, Design, Implementation and Integration
• Emphasizes the need to reiterate earlier stages a number of time as the project progresses
• Actually a series of short waterfall cycles, each producing an early prototype, representing a part of the entire project. It’s like using the waterfall model as guide in doing one prototype only.
• If one prototype is finished (except perhaps the polishing of graphics), a developer can proceed to the next prototype. Build, test and integrate to the first prototype
• Helps demonstrate a proof of concept early in the cycle
• Incorporates prototyping and software quality objectives
• Gives early focus to reusable software
• Accommodates life cycle evolution, growth and requirement changes
• Focus on early detection and design (architecture) flaws
• Useful in hardware-software projects

3. Build and Fix Model
• Crudest of the models
• Implementation of system without specification nor design
• May work for small scale projects
• Code is written, then modified until client is happy
• VERY RISKY!
• I know of a developer who does just this kind of work strategy. He was given an assignment, but instead of planning properly, he will just code it immediately without specification or design. He improves it until his client is happy. If the client is dissatisfied, he doesn’t give a damn about it.

4. Rapid Prototyping Model
• Emphasis is on creating a prototype that looks and acts like the desired product in order to test its usefulness
• Develop a system with reduced capability
• Present to client for approval
• Once the prototype is approved, it is discarded and the “real” software is written.
• Develops specification with better understanding
• Exactly like the Spiral Model, where a prototype or only “shadow” of the real software is made, where the system (during implementation stage) is not that graphically perfect but features are functioning well for testing purposes
• Only difference is, in Rapid Prototyping, it requires client approval prior to the building of the “real” software



5. Incremental Model
• Divides the product into builds, where sections of the project are created and tested separately
• Each build contains an operational quality subsystem
• Each additional build, a new subsystem is integrated with the previous build
• You will notice that this model is very much like the Spiral Model except that instead of prototype, they’d rather call it builds. These builds, like prototypes, are tested separately first. Each build has a subsystem in Incremental Method, whereas in Spiral, subsystems may or may not be used
• Likely to find errors in user requirements quickly

6. Synchronize and Stabilize Model
• Type of Incremental Model
• Allows many teams to work efficiently in parallel
• A nightly compilation of builds of the entire project is made to piece together all current components
• An alpha release was done for internal testing, a couple of beta releases took care of a wider testing range outside the company. Finally, a release candidate leading to the final version, called a gold master, was released to manufacturing
• At some point before each release, specifications would be frozen and the remaining time spent on fixing bugs
• There is heavy emphasis in schedule management and perfection

7. Fountain Model
• Support Incremental Development
• Recognizes that some activities can’t stand before others, yet there’s a considerable overlap of activities throughout the development cycle
• Implies that you do some analysis, then some design, then some implementation
• Parallelism among various phases and iteration within phases
• Development of an object-oriented system that more likely to lead us to focus on sections of the whole known as clusters or subsystems
• Subsystems are collections of classes which work closely together
• Supports human learning and is recommended for most projects

SDLC is a systems approach to problem solving and is made up of several phases. A developer may or may not use or apply SDLC, but based on my experience, it is highly advantageous to use one. We did a system before where we didn’t plan much how we will execute, start and finish building a system. The result was a complete catastrophe! We suffered “groping in the dark” syndrome, regretted ever working with one another, and suffered too many expenses and too much time delay. Learning from the lesson, it is, thus, highly recommended to properly plan the flow of activities in building a system through SDLC as one of the tools in management.
plobrin@gmail.com

Project Development Plan: A Guide in Building an IT System

When my team had an IT project to do during our college days, we used a very important document to help us get started during the initial stages of the project. We used a document called Project Development Plan (PDP) as guide. It is adapted from the IEEE standards for Software Project Management Plans. This document is very useful because all succeeding documents (i.e. Test Plan) follow the initial guidelines stated in the PDP document and the general details and strategies for testing and quality assurance are also stated in this document.
Apart from minor (but pertinent) details, the PDP is divided into four major parts, namely: Project Organization, Managerial Process Plans, Technical Process Plans, and Supporting Process Plans. The Project Organization part of the PDP document describes and illustrates the organizational hierarchy of the developing team. The Managerial Process Plan section of the PDP describes how the developing should start and how it will close. Apart from which, this section also tackles the general and specific details of managing resources, budget, staff and schedule. The Technical Process Plan part of the PDP is where the process, methods, tools and techniques in building the system, as well as maintenance and release, are stated. And, the Supporting Process Plan section of the PDP provides general details about configuration management, testing, standards and quality assurance, reviews, issue management, subcontract management and improvement plan. This part is essential because many documents particularly the Test Plan and the Quality Assurance documents base its initial plans, standards and processes.
The first part of the Project Development Plan document details the purpose, scope and objectives of the project. Of course, the developers of the system must know what they are building, and the limitations and extent of the finished product. The initial section of the PDP also enumerates the list of deliverables of the project like documents and the finished system itself.
The first major part of the PDP document is the Project Organization. This is where the internal and external organizations are identified, together with their roles and responsibilities. Improper or poorly defined position in the organization causes confusion amongst the members of the developing team regarding each one’s roles and responsibilities; causes some members of the team to slacken around and do nothing, while some have more than enough in their hands; and some members tend to assume the responsibility supposed to be assigned to another team member. Thus, poor staffing or poor Human Resources management might contribute heavily to the project’s total failure.
The second major part of the PDP document is the Managerial Process Plans. This is where the specific and general management process for the project appears. While doing this part of the PDP before, I find the contents of this section repetitive especially in the areas of schedule, budget, staffing and resources management. There are certain developers who don’t have to worry about estimating schedule, budget, staffing and resources because the company where they are employed provides them with all the things that they need. However, there are developers who must do all the estimating and budgeting. Thus, the Start-up Plan (under the Managerial Process Plans) is where all the initial plans of the developers are found. Usually, this plan came about during the pre-Requirements stage. The opposite of the Start-up plan is the Close-out Plan that discusses how the project should end. Work Plan section (under the Managerial Process Plans) is where the specific details of budget, schedule, staffing and resources are found. Also, we can have an early glimpse of the Work Breakdown Structure and the specific work activities. Risk Management Plan (under the Managerial Process Plans) describes the mechanisms used to identify, analyze, build mitigation and contingency plans; and manages the risks possibly found in the project.
The Technical Process Plans describe the processes used for developing the product or IT services. The activities in the Work Breakdown Structure follow a guideline in the form of a Software Development Life Cycle Model (i.e. Waterfall Method). If a Life Cycle Model is not determined, sometimes it is difficult to prioritize the activities in the project.
Lastly, the Supporting Process Plans of the PDP discusses the supporting processes of the project, namely: configuration management, testing, documentation, quality assurance, reviews, issue management (which I find somewhat similar with Risk Management), subcontract management and improvement plan. Configuration management has something to do with the configuration items identified in the project. These configuration items are already named as early as pre-Requirements stage but they are visible for every phase-end or if an item is already declared original and final version. Samples of configuration items are documents. Once changes are made in these items (which normally happens during project-end), a control board analyzes changes prior to acceptance or rejection. The analysis of the control board is one of several activities under Configuration Management. The general guidelines for the Test Plan and the Quality Assurance Plan documents are first planned and described in the Supporting Process Plans of the PDP. Without the initial guidelines, there is a huge possibility that testing and quality assurance activities are taken for granted.
The Project Development Plan document is very important and essential especially if you’re into software development. Without this document as guide, an IT developer might experience “groping in the dark” in the middle of the project, NO FORMAL GUIDELINES AND STANDARDS established, and there is poor management in areas of budget, staffing, schedule and resources.
P. Lobrin
plobrin@gmail.com

IT Project Management and Systems Management

In a project, there are so many factors to consider like cost, time, quality product, etc. But, the top three ever-present factors in a project that need to be considered are Cost, Scope and Time. These three are also the constraints in Project Management.
In cost, a team usually ponders about the likely expenses to be incurred while building a product. In scope, a team tries to determine what the project is trying to accomplish. And, in time, a team has to finish the product with what time allotment given to them. These discussions are about Project Management, but what about managing the actual building of the system? There’s a different kind of approach used in an analytical way to handle problem-solving and management issues, and that is Systems Management. Sounds new right? But actually, it’s been used since the 50’s.
Systems Management is divided into three parts: (1) systems philosophy – views things as systems, (2) systems analysis – problem solving approach, and (3) systems management – address business, organizational and technical issues.
There are two major phases in a project. These are project feasibility and project acquisition. The former determines the concept and the initial development plans of a project. While the latter executes and implements the plans a team has created while also considering potential risks.
I had an experience before where in my team didn’t fully discuss the concept of the project we are trying to build. We suffered a lot because in a way we realized, in the middle of the building process, that the IT product we are trying to build is not feasible at all considering what resources, time, etc. my team has. Probably, if we have done a thorough study of the system we are trying to build, we probably detected as early as Project Feasibility stage that the system is not feasible at all.
Systems Development Life Cycle (SDLC) is one very useful method or guide in systems management. Developers use it to help them as they go along in building a system/IT product. SDLC is a useful tool because it describes the phases involved in developing systems. The most popular phases (common in many Life Cycle models) are: planning, analysis, design, implementation and maintenance. Samples of SDLC models are: waterfall, spiral, incremental release, RAD, and prototyping. Using SDLC is important because there is a smooth transition from one phase to another, there is a smooth execution of plans, there is a detailed description and set of activities for every stage, and it serves as guide. Thus, eliminating “groping in the dark” and confusion about what to do next.
P. Lobrin
plobrin@gmail.com

What You Should Know About IT Project Management

Why do we have to plan and manage IT projects? Why bother at all considering the fact that many clients eventually accept whatever the resulting software may be? Why bother at all since time is precious in building the systems rather than planning systems? These are the usual answers of independent or freelance software developers who are excited in tackling or building software projects immediately without the need to sit around and plan first. If you will bother to read my article, you will see the importance of IT Project Management.
I have an experience before in my last year in college where in we have an IT project to do. Since we are excited in building – or finishing? – the product without planning properly, my team suffered a lot in the near end of the project-building time. We failed in building one prototype after another. We also exceeded the time allotment given to us, thus, we suffered financially since we incurred extra expenses, lost the interest of other team members and caused dissatisfaction from out teacher. Learning from my mistakes and applying Project Management in other areas of my life, I would like to share the importance and advantages of IT Project Management to others as well.
Project Management is “the application of knowledge, skills, tools and techniques to project activities in order to meet project requirements” (PMI, Project Management Body of Knowledge (PMBOK Guide), 2000, p.6). These project requirements are like the goals of a project that once met or achieved signifies the completion of a project as well as customer satisfaction. The application of knowledge requires careful sifting, planning, specification and design of these requirements. Through Project Management, software developers will be able to identify, coordinate and monitor tasks, activities and resources to meet the project requirements.
The outcome of Project Management is: scope of work is defined, project feasibility is evaluated (thus, a team can early detect if they are capable of doing a project while considering their skills and resources), tasks and resources are estimated, plans for execution of tasks are developed (through documentation that serves as blueprint also), and progress is monitored.
The advantages of Project Management are: shorter development period, less expenses, quality software products, control in activities and resources, client interaction (since they too are informed of the project’s progress), early detection of risks and potential problems, good documentation (serves as blueprint and reference), and project members are learning and applying teamwork.
Though it usually takes time in planning, in the end software developers are assured of smooth work in developing their IT projects since they already have plans and blueprints in the form of documentations and reports. All that they have to do is implement it in the actual building of their products. Take for instance a carpenter building a small house. Once he has the plan, blueprint, tools, workers and other resources, he can build the house in a jiffy and his construction work will run smoothly. Technorati Profile
P. Lobrin
plobrin@gmail.com