ICT consulting is a service provided by our top management consultants, who have a wide expertise of business processes in most industries in design and implementation of various types of business strategies. Our ICT consulting projects are focused on ICT infrastructure development study and organization that include the foundation of core ICT infrastructure, data integration or business intelligence.
DEVELOPMENT METHODOLOGY
We practice world’s renowned Agile Software Development and Implementation Methodology and also Waterfall Methodology in software development, implementation and integration which covers the entire life cycle of the software and related infrastructure system.
AGILE SOFTWARE DEVELOPMENT LIFE CYCLE AT THE OSOURCE
OSource follows iterative incremental process for software development based on agile software development model like SCRUM. Although This method intended to be for management of software projects, it can be used in running software maintenance teams, or as a program management approach.
AGILE PRIMER
Agile methods have worked out from grassroots movements based on proven practices of successful medium software teams. Popular Agile methods include Scrum, Crystal, Extreme Programming, and Agile Modeling. The term “method” as used here means a collection of techniques intended to work together. The term “technique” refers to a specific “how to” approach to implement some aspect of an Agile principle.
AGILE PRINCIPLES AND PRACTICES
Agile “principles” refers to the 12 principles behind the Agile Manifesto that was drafted by 17 methodologists in February 2001 to help address challenges faced by software developers. The Agile Manifesto also identifies four values:
- We value individuals and interactions over processes and
- We value working software over
- We value customer collaboration over contract
- We value responding to change over following a
It also states as a point of clarification with reference to the four values, “That is, while there is value in the items on the right, we value the items on the left more.”
KEY AGILE PRACTICES ARE PROVIDED IN TABLE BELOW:
Agile Practice | Brief Description |
Incremental and multigrain planning | “Coarse” and “fine” grain plans developed and used to guide work. |
Continual refinement of plan | Plans are continually refined as new information is acquired. |
Short iterative development cycles working closely with customer | To help ensure requirements are understood, work is done in short cycles using frequent customer feedback to aid course correction. |
Daily team standup meetings with current work kept visible to the full team | Ensures team is communicating and staying on the agreed-to course. |
Teams self-manage the work | Team members measure their own velocity/productivity and commit to work based on the team’s measured performance. |
Frequent delivery of working product to customer based on customer priorities | Helps team stay focused on customer high value items. |
Time-boxing work | Schedules are maintained by reducing delivered functionality, if necessary. |
Team retrospectives | Team periodically reflects on its processes, frequently making improvements the team agrees can help their performance. |
Rapid response to changing customer needs | By keeping the iterations short and continually communicating with the customer, the team is able to change priorities on shorter cycles, if required. |
AGILE METHODS INCLUDE:
- Scrum
- Extreme Programming
- Lean Software Development
- Feature-Driven Development
- Test-Driven Development
- and many others
AGILE PARADIGM
The following table contains Agile paradigms along multiple dimensions. This table provides a nice summary of concepts in a way that makes it easier to understand the viewpoints of Agile.
Dimension | Agile Paradigm |
Organizational focus of attention | The focus is on the project and team. Agile methods can isolate (i.e., insulate) the project/team from the organization and still be effective. |
Management | Management is a coaching function (as opposed to traditional command-and control) that helps to eliminate barriers to progress. This view of management may be expanding as Agile approaches are extended to address larger project contexts. |
Trust | Agile methods originated from the recognition that teams work best when they are composed of task-mature individuals operating in high trust groups. An Agile environment fosters high trust. |
Planning | In Agile methods, there are multiple levels of planning, including high-level product planning (including release planning) and at the beginning of each iteration, more detailed planning around the features to be addressed in that iteration. There is a strong emphasis on flexibility and re-planning as conditions change. Use of Gantt charts (that map tasks to calendar time) and graphs of task networks is discouraged because the requirements on which the tasks are based change frequently. |
Market/User Assumption | Agile methods have the most benefit in an emergent and not well- understood target/market. |
Design Presumptions | Projects are most successful when corporate standard architectures are adopted with flexibility applied as the project progresses. Some Agile methods downplay the importance of architectures on the general principle that such are often prematurely specified. |
Learning | Learning happens at project/iteration levels, typically bottom-up and just-in-time (i.e. comparable to Kaizen). |
Perspective | Agile takes, has, and assumes a short to medium-term view. |
Appraisals | The desire of Agile practitioners is that appraisals are made only by looking at results (i.e., customer satisfaction and other project outcomes). |
Human Development | Agile has a team and individual focus (i.e., people over process). There has been a tendency among many in the Agile community to advocate “just hire good people” with an implicit undercurrent of developing “hero developers” within a work-life balanced culture. |
Life-Cycle Emphasis | Agile methods employ concurrent development, test iterations, and informal peer reviews of work products as necessary. There is a tendency to see in Agile a “validate often and verify second approach” which may be a more correct reading. “Fail early, fail fast, and learn” are central to Agile methods. The trade-off is seen as favouring the development of a useable and testable product vs. developing and analysing requirements and product components. A low cost of delay or low cost of failure is assumed. There is an assumption of incremental delivery being viable. Burn out can arise from repeated time boxed iterations, so special provisions should be made for this eventuality (e.g., by revising the time-box duration based on experience feedback and by providing some slack around iterations). |
Predictability | Using time-boxed scope-limited iterations, evolving designs/solutions, driving out defects as early as possible and failing quickly leads toward a predictable development velocity. There is also an expectation of predictability of iteration delivery and scope of delivery. The anecdotal evidence suggests that Agile teams often struggle with predictability of iteration scope, often de-scoping iterations (or sprints) in the final few days. This de-scoping is rooted in a lack of statistical convergence of the velocity data combined with the analysis technique underlying the scope breakdown. |
Cost of Failure | Agile methods have flourished in a domain of low cost of failure or linear incremental cost of failure. Examples within this domain include Internet commerce, social networking, and games development. |
SCRUM PRIMER
Scrum is a pre-defined development lifecycle based on Agile principles. Agile methodologies promote a project-management process that encourages frequent inspection and adaptation, and a leadership philosophy using teamwork, self- organization and accountability.
Scrum is an iterative, incremental framework for projects and product or application development. It structures development in cycles of work called Sprints. These iterations are no more than one month each, and take place one after the other without pause. The Sprints are timeboxed – they end on a specific date whether the work has been completed or not, and are never extended. At the beginning of each Sprint, a cross-functional team selects items (customer requirements) from a prioritized list. The team commits to complete the items by the end of the Sprint. During the Sprint, the chosen items do not change. Every day the team gathers briefly to inspect its progress, and adjust the next steps needed to complete the work remaining. At the end of the Sprint, the team reviews the Sprint with stakeholders, and demonstrates what it has built.
People obtain feedback that can be incorporated in the next Sprint. Scrum emphasizes working product at the end of the Sprint that is really “done”; in the case of software, this means code that is integrated, fully tested and potentially shippable. Key roles, artifacts, and events are summarized in Figure 1.
A major theme in Scrum is “inspect and adapt.” Since development inevitably involves learning, innovation, and surprises, Scrum emphasizes taking a short step of development, inspecting both the resulting product and the efficacy of current practices, and then adapting the product goals and process practices. Repeat forever.
SCRUM’S ROLES AND RESPONSIBILITIES
Role | Responsibilities |
Product Owner | Represents the interests of everyone with a stake in the project and its resulting system. Maintains the Product Backlog, i.e., a rasterized |
| list of project requirements with estimated times to turn them into completed product functionality. |
Team | The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams have the following characteristics: · They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; · Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment; · Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule; · Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole; and, · Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis. |
Scrum Master | The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum |
| Team adheres to Scrum theory, practices, and rules. The Scrum |
| Master is a servant-leader for the Scrum Team. The Scrum Master |
| helps those outside the Scrum Team understand which of their |
| interactions with the Scrum Team are helpful and which aren’t. The |
| Scrum Master helps everyone change these interactions to |
| maximize the value created by the Scrum Team. |
SCRUM & Mapping with existing Process Areas of OSource
REQUIREMENTS MANAGEMENT:
The purpose of Requirements Management (REQM) is to manage the requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plans and work products.
- Develop an understanding with the requirements providers on the meaning of the requirements through review of Product Backlog (requirements) with Product owner and
- Release planning and Sprint planning sessions that seek team member
- Manage changes by adding requirements changes to the Product Backlog. Manage changes in the next Sprint planning meeting is left to
- Daily standup meeting to identify
- Release planning and Sprint planning sessions to address
- Sprint burn-down chart that tracks effort
- Release burn-down chart that tracks story points that have been This shows how much of the product functionality
PROJECT PLANNING
The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.
- A project planning document will be maintaining that will be progressively elaborate by each iteration (PMP)
- The standard tasks used in a Scrum process combined with specific project tasks (Scrum Backlog).
- Story points, used to estimate the difficulty (or relative size) of a Story (requirement).
- Project life-cycle phases will be planned as per the Scrum process
- Estimate project effort and cost for the work products and tasks based on estimation rationale using Scrum Ideal Time estimate (similar to billable hours or Full-time Equivalents).
- Establish and maintain the project’s budget and schedule by
- Scrum estimates (in Ideal Time)
- Estimates of what work will be in each
- Sprint
- Project Task-board.
- Plan for necessary resources to perform the
- Scrum estimates in Ideal Time
- Release plan, Sprint Backlog and
- Plan the involvement of identified
- Scrum process roles (including team, Scrum Master, Product Owner
- [Note: The stakeholders listed in Scrum might not be the complete list of stakeholders for the project, g., customers, other impacted teams.]
- Obtain commitment from relevant stakeholders responsible for performing and supporting plan
- Sprint planning
- Daily Scrum
- [Note: The stakeholders listed in Scrum might not be the complete list of stakeholders for the ]
PROJECT MONITORING AND CONTROL
The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.
- Monitor the actual values of the project planning parameters against the project plan
- Sprint burndown chart that tracks effort
- Release burndown chart that tracks completed story This shows how much of the product functionality is left to complete.
- Project Task Board used to track stories (requirements) that are done, in progress, or ones that need
- Monitor commitments against those identified in the project
- Discussions on team commitments at the:
- Daily Scrum
- Sprint review
- Sprint burndown chart that tracks effort
- Release burndown chart that tracks story points that have been This shows how much of the product functionality is left to complete.
- Discussions on team commitments at the:
- Periodically review the project’s progress, performance, and
- Daily Scrum
- Sprint review
- Take corrective action on identified
- Actions from the:
- Daily Scrum
- Sprint review
- Manage corrective actions to
- Tracking of actions from:
- Daily Scrum meeting
- Sprint review meeting
- Tracking of actions from:
- Actions from the:
CONFIGURATION MANAGEMENT (CM)
CM is not specifically called out in Scrum. However, in an Agile environment it is pretty easy to add a layer of CM to protect work product. Even for groups that like to use white boards, you can be creative and at least establish some basic protection by labeling items (e.g. “V1.1,” or “Story dated 1/2/YY”) and taking a photo. The CM Process Area does require more than just versioning, but versioning is an easy start..
PRODUCT AND PROCESS QUALITY ASSURANCE (PPQA)
Some basic PPQA activities are being done naturally when the Scrum Master checks that the Scrum process is being followed. Other PPQA activities are completed when a team performs code reviews, document reviews and testing. The Scrum Master also plays a role of removing process barriers and inefficiencies. Existing Quality Assurance Process and Internal Audit Process will be followed
RISK MANAGEMENT PLAN
Risk is characterized by the combination of the probability that a program or project will experience an undesired event (some examples include a cost overrun, schedule slippage, safety mishap, health problem, malicious activities, environmental impact, failure to achieve a needed scientific or technological breakthrough or mission success criteria) and the consequences, impact, or severity of the undesired event, were it to occur.
Risk Management (RM) is a process wherein the program/project team is responsible for identifying, analyzing, planning, tracking, controlling, and communicating effectively the risks (and the steps being taken to handle them) both within the team and with management and stakeholders. As depicted in the following figure, RM is a
continuous, iterative process to manage risk in order to achieve mission success. It should be a key element and an integral part of normal program/project management and engineering processes.
The Project Manager (PM) will be responsible for the following:
- Applying a continuous risk management process within the
- Documenting and approving that process within a Risk Management
- Documenting and managing risks throughout the project’s life
- Approving the formal acceptance of all project
- Providing program risk status, especially concerning primary
- Providing project risk status, especially concerning primary risks, to the project teams
- Evaluating the program/project’s risk status and ensuring that the formal acceptance/closure of program/project risks is consistent with
- Concurrence on the acceptance of all primary
CHANGE MANAGEMENT PLAN ROLES AND RESPONSIBILITIES:
The change process involves two or more customers who become partners to the change. The requestor of a feature/fix change which is sent to the other(s) is termed the Initiator. The recipients of the change request are termed Partners. A Change Management Coordinator should represent change process.
CHANGE CONTROL MANAGEMENT PROCESS:
Change Management Program (CMP), more commonly known as Change Control Process or Change Control Management Process, is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner .CMP should not be confused with Organizational Change Management (OCM), which manages the impacts of new business processes, including those stemming from system rollouts and IT initiatives, changes in organizational structure, or cultural changes within an enterprise. In short, OCM manages the people side of change.
The purpose of the CMP is to ensure that the negative impact of changes to a company’s Information Technology system is minimized by using a standardized process of governance. Some changes are not optional. If, for example, the bar code standard is changing, you must adapt; if a tax withholding structure changes, you must have a change. Nevertheless, all changes of this kind are still subject to governance.
It must never be the case that ad-hoc changes are made to the system or to procedures without some oversight. This idea must originate with senior management and be passed down, with no exceptions, to everyone in the company. Without backing at the highest level, the CMP is a useless waste of time and money. With proper backing, this program will save your company from some very costly errors.
We briefly describe the Change Control Management Process in below:
- Develop a Request for Change (RFC): This may come from Originator, Stakeholders, Technical Team, Project This may also originate from problem management where an issue, or a series of related issues, is identified and a mitigating change is necessary to prevent (or minimize) future effects. The RFC may also originate as a result of a business decision that
will require some modification (add, delete, change) to the supporting technology. An RFC may also be necessary due to outside influences (i.e. governmental regulations or changes made by business partners).
- Obtain Business Change Acceptance: The decision to make a change is typically a business decision where costs vs. benefits are weighed. Even in situations where the change is strictly infrastructure oriented (component or system failure) the decision to spend money resides with the business, not with the IT There are occasions when procedures are developed in advance to preauthorize changes such as emergency system maintenance, but regardless of the timing of the authorization, the decision still rests with the business management.
- Initiate the Development Project: Development of the change (including testing) is an IT-guided In the event of an emergency change (server is down) those functions are typically predetermined. When a new system is to be developed, there is a collaborative effort between the business users and the IT team. The systems are designed by IT, the design is approved by the business partners (users), developed by IT, tested by a combination of IT and the users, and the final product is approved by both. Careful attention must be given to ancillary effects the new change may have on existing systems.
- Pass the Change Management Gate: A Change Advisory Team (CAT) will be formed by combination of clients and consultant and reviews all changes before they can be put into production. Normally, the CAT will consist of a group of people with different perspectives, backgrounds and areas of Their function is to review the change from a process and governance standpoint to assure that all foreseeable risks have been identified and mitigated, and that compensatory techniques are in place for any elements of exposure (things that could go wrong). The development team and the change sponsor will present the change to the CAT. Evaluation of risk will be the focus. Implementation strategies, communication to affected stakeholders, back out plans and post-implementation monitoring are elements on which the CAT is required to focus. The CAT is not responsible for determining if the change is appropriate – that decision has already been made. The CAT is also not responsible for determining if the change is cost effective. Again, that is strictly a business decision.
- Implement the Change: If the Change Advisory Team does not approve the change, the reasons are listed (this is always because certain risks have not been mitigated or communications have not been planned) and the development team will be given time to fix those issues and reschedule a meeting before the CAT. If the change is approved, the implementation is It is not normally the case that the CAT is represented at implementation although it is possible that some members of the CAT have expertise that is necessary during the implementation, but they will not be present as official CAT representatives, but rather as subject matter experts (SME). How the change is implemented, the checklist and steps, are predefined and were presented to and approved by the CAT. The entire process must be thoroughly documented and the approved process must be precisely followed.
- Report the Results: Either the change was implemented successfully with no issues, the change was implemented with issues that were corrected during implementation, the change was implemented with issues that were deemed acceptable, issues arose that were unacceptable and the change was rolled back, or in the worst case the change was implemented with unacceptable issues and could not be rolled Whatever the result, that is documented and returned to the CAT. The CAT is then responsible for
distributing that information to the stakeholders and for storing and maintaining those results in the Change Management system (that may either be an automated database or a paper filing system, but the documents must be maintained for audit purposes).
- Link Problem Management to Changes: Issues that arise should be compared to the CAT documentation of changes so any unanticipated adverse effects of a change can be It is often the case that undesirable effects of a change are not noticed immediately, but are identified by the emergence of problems in ancillary systems. For example, the addition of several fields to a database might not have a direct negative effect on the users but could impact network performance that would be apparent to other users who are not directly involved with the modified system.
QUALITY ASSURANCE PLAN
We consist quality control team by computer and Information Technology specialist who will perform a variety of activities to support the project. In order to provide high quality products and services, each support team will adhere to processes, procedures and standards. Quality Assurance (QA) is a process used to monitor and evaluate the adherence to processes, procedures, and standards to determine potential product and service quality. It will involve reviewing and auditing the products and activities to verify that they comply with the applicable procedures and standards, and will assure the appropriate visibility for the results of the reviews and audits.
This policy supports
- Quality Assurance must be rational
- Continual improvement effort must be supported
- All quality control and quality measurement activities are documented
- A manager management team will be designated to be responsible for Quality
- Project Manager will review Quality Assurance activities
- The Quality Assurance Plan will be base lined and placed under Configuration
Management control
Quality Assurance will work to foster constructive communication, provide feedback to detect and prevent development problems, control risks, discuss alternative solutions, and ensure quality is built-in to products/and IT services to the customer.
Purpose
This Quality Assurance Plan(QAP) describes the standards, processes and procedures that will be used to support the consistent delivery of high-quality, professional products and services provided in the support of an automated environment. The quality assurance process will be concerned with establishing the authority of the QA function, quality assurance standards, procedures, policies, and monitoring, and evaluation processes to determine quality in relation to established standards. Quality assurance activities will concentrate on the prevention of problems through the continuous improvement of processes.
All required documents for the project would follow the appropriate standards concerning content and format. The project activities are to be implemented according to requirements. The required documentation that will required to ensure the project activities are planned, monitored and controlled and will be used to verify
the adequacy of the actual processes and procedures used to develop and/or deliver products/services. Required documentation, as applicable, includes:
Process Improvement:
The QA team is responsible for process improvement. Process improvement is successful when an effective process emerges or evolves that can be characterized as: practiced, documented, enforced, trained, measured, and improvable. A corrective action plan will be developed when a deficiency in the process will be detected. Corrective action should prevent the problem from recurring. Successive steps for implementing a process improvement approach are:
- Detection of quality-related problems
- Identification of responsibility
- Evaluation of importance
- Investigation of possible causes
- Analysis of problem
- Preventive action
- Process controls
- Disposition of nonconforming items
- Permanent changes
The QA team analyze the results of their findings in relation to the results of documented processes used to produce products or services. This comparison will be used to determine which process may need improvement and to determine the effectiveness of changes to the processes. This comparison will also be used to identify best practices that should be continued or implemented at other sites. Errors, defects, issues, deviations and noncompliance items identified in the project activities must be itemized, documented, tracked to closure, and reported by the QA team. The QA team must verify all problems were tracked to closure and must provide continuing feedback to management and the technical support team concerning the status of the problem.
TESTING PLAN
Our testing team will begin developing the detailtest plan after the initiation phase. But for now we will go through a brief test plan. Our testing team comprises three members headed by its test coordinator. The actual testing task will start with Unit Testing of the database codes simultaneously during the Development phase.
Features to be tested
- The following features will be tested as part of the acceptance test procedure:
- Hardware Functionality
- Software Functionality
- System Functionality
- System Performance
- Reliability
- Safety
TRAINING PLAN
Any Project will be concluded after the successful training of the users of this developed system. We usually train all the assigned technical people working in project. It should be noted unless trained properly; the users of the developed system
would not continue to use the solution because of technical complicacies. The training will be conducted with the following points into consideration.
IMPLEMENTATION/ DEPLOYMENT PLAN
Objectives: This will describes the deployment plan for the developed software system. The typical objectives of a deployment plan are to document in detail specific tasks and responsibilities as below:
Details given in the work plan
Customer representatives typically should have the following expertise:
- Knowledge of the application
- Knowledge of the application
- Knowledge of the project contract and statement of
PROGRESS REPORTING PLAN
Objective: The typical objectives of a status report are to report the:
- Current status of the endeavor
- Achievements that were made since the previous status report
- Planned achievements that were not made since the previous status
- Planned actual result.
- Identify Risk areas, priorities and bottlenecks and propagate to stakeholders for immediate escalation and