ASSIGNMENT

REPORT ON ANALYSIS OF A SOFTWARE COMPANY NEXT BRIDGE

PRESENTED TO : SIR TOUSEEF TAHIR
DEPT OF COMPUTER SCIENCES LAHORE

PREPARED BY :
MUHAMMAD BILAL BABER SP10-BCS-057 MUHAMMAD SALMAN AZIZ SP10-BCS-065 ADNAN MAQBOOL SP10-BCS-005

IQBAL AHMAD BCS-035 TANSEEF FAHAD SP10-BCS-097 DATED : 2ND APRIL , 2012 INTRODUCTION :

SP10-

The report is about the analysis of a software house Next Bridge located in Lahore , Pakistan . it has a number of branches all over the country and this report explains an interview taken from one of its team leaders . This report is prepared collectively by our group and it is assured that no part of this is taken from any source other than the one mentioned above . The report explains about the development lifecycle the company is using and its various techniques regarding the collection

of requirements , developing , deploying , testing and maintenance along with our analysis and comments on how it can be a better developing company . Our analysis of the answers that the interview presents are stated along with the questions and a final conclusion is also provided for assessment of this report.
Why spend all this time finding, fixing and fighting when you could have prevented the problem in the first place? -- Philip Crosby

Company information :

NextBridge Pvt Ltd Located in Gulberg,Lahore No certifications Designing projects for companies worldwide , mainly based on Dotnet & oracle

America, Pakistan, and others virtual teams are working togather Some projects take too much time for example we are working for 12 years on a project it depends in the project nature There are 7 branches in lhr, Islamabad, Peshawar 400 people are working in these branches only one ceo

Company stakeholder mapping

A narrow mapping of a company's stakeholders might identify the following stakeholders:

Employees Communities Shareholders Creditors Investors Government Customers

Person interviewed :
Furqan Lodhi

Qualifications: BSCS (Hons) , MSCS. Skills :

Programing Java, dot net Current Position : Team leader

Experience : 6 years & 6 months .

Requirement engineering processes

requirement elicitation

Companies use Agile practices , they do not follow the traditional methods of documenting the requirements and specifications. They practice minimum documentation where ever necessary and utilize that time in developing products.

Stakeholder management

Companys stakeholders are its valued customers who use online products, various financial institutions, global & regional financial and business standards. Company use formal modes of communication like emails and phones. And also communicate with its stakeholders through Official business meetings addressing business requirements and changes in standard business

procedures.

Requirement prioritization
One characteristic of excellent requirements is that they are explicitly prioritized. When customer expectations are high, timelines are short, and resources are limited, you want to make sure the product contains the most essential functions. Establishing each chunk of functionalitys relative importance lets you sequence construction to provide the greatest product value at the lowest cost. Customers and developers must collaborate on requirements prioritization. Developers do not always know which requirements are most important to the customers, and customers cannot judge the cost and technical difficulty associated with specific requirements. A project manager has to balance the project scope against the constraints of schedule, budget, staff resources, and quality goals. One balancing strategy is to drop or defer low priority requirements to a later release when you accept new, higher priority requirements or other project conditions change. If customers dont differentiate their requirements by importance and urgency, the project manager must make these trade-off decisions. Because customers may not agree with the project managers decisions, they must indicate which requirements are critical and which can wait. Establish priorities early in the project, while you have more options available for achieving a successful project outcome.

i. how this is used for release planning The prioritization process leads the release planning as it helps recognizing the timelines and efforts required to take the deliverable into production.

 Implementation

 Key To Success
There are three very important considerations to keep in mind if we want our implementation of a process/tool to be successful. These considerations are PROCESS, PEOPLE and TECHNOLOGY.

Our goal is to be effective and efficient not only in the process/tool we are implementing, but in the way we go about this implementation. A basic but driving insight is that PROCESS and PEOPLE make an effort effective, and TECHNOLOGY at best can make an effort efficient. With this in mind, we need to do all three because if we focus on:

Just TECHNOLOGY.............we become very efficient about being ineffective! Just PROCESS-PEOPLE.......we become very effective about being inefficient!

Software Design and Architecture

Identify Architecture Objectives

Architecture objectives are the goals and constraints that shape your architecture and design process, scope the exercise, and help you determine when you are finished. Consider the following key points as you identify your architecture objectives:

Identify your architecture goals at the start. The amount of time you spend in each phase of architecture and design will depend on these goals. For example, are

you building a prototype, testing potential paths, or embarking on a long-running architectural process for a new application? Identify who will consume your architecture. Determine if your design will be used by other architects, or made available to developers and testers, operations staff, and management. Consider the needs and experience of your audience to make your resulting design more accessible to them. Identify your constraints. Understand your technology options and constraints, usage constraints, and deployment constraints. Understand your constraints at the start so that you do not waste time or encounter surprises later in your application development process.

Scope and Time Based on the high-level goals for your architecture, you can scope the amount of time to spend on each of your design activities. For example, a prototype might only require a few days to design, while a complete and fully detailed architecture for a complex application could potentially take months to completeand may involve architecture and design over many iterations. Use your understanding of the objectives to determine how much time and energy to spend on each step, to gain an understanding of what the outcome will look like, and to define clearly the purpose and priorities of your architecture. Possible purposes might include:

Creating a complete application design. Building a prototype. Identifying key technical risks. Testing potential options. Building shared models to gain an understanding of the system.

Each of these will result in a different emphasis on design, and a varying time commitment. For example, if you want to identify key risks in your authentication architecture, you will spend much of your time and energy identifying authentication scenarios, constraints on your authentication architecture, and possible authentication technology choices. However, if you are in the early stages of considering the overall architecture for an application, authentication will be only one of many other concerns for which you address and document solutions. Some examples of architecture activities are building a prototype to get feedback on the order-processing UI for a Web application, testing different ways to map location data to search results, building a customer order-

tracking application, and designing the authentication and authorization architecture for an application in order to perform a security review.

Key Scenarios
In the context of architecture and design, a use case is a description of a set of interactions between the system and one or more actors (either a user or another system). A scenario is a broader and more encompassing description of a user's interaction with the system, rather than a path through a use case. When thinking about the architecture of your system, the goal should be to identify several key scenarios that will help you to make decisions about your architecture. The goal is to achieve a balance between the user, business, and system goals (as shown in Figure 1 of Chapter 1 "What is Software Architecture?"). Key scenarios are those that are considered the most important scenarios for the success of your application. Key scenarios can be defined as any scenario that meets one or more of the following criteria:

It represents an issuea significant unknown area or an area of significant risk. It refers to an architecturally significant use case (described in the following section). It represents the intersection of quality attributes with functionality. It represents a tradeoff between quality attributes.

For example, your scenarios covering user authentication may be key scenarios because they are an intersection of a quality attribute (security) with important functionality (how a user logs into your system). Another example would be a scenario that centered on an unfamiliar or new technology. Architecturally Significant Use Cases Architecturally significant use cases have an impact on many aspects of your design. These use cases are especially important in shaping the success of your application. They are important for the acceptance of the deployed application, and they must exercise enough of the design to be useful in evaluating the architecture. Architecturally significant use cases are:

Business Critical. The use case has a high usage level or is particularly important to users or other stakeholders when compared to other features, or it implies high risk. High Impact. The use case intersects with both functionality and quality attributes, or represents a crosscutting concern that has an end-to-end impact across the layer and tiers of your application. An example might be a Create, Read, Update, Delete (CRUD) operation that is security-sensitive.

After you have determined the architecturally significant use cases for your application, you can use them as a way to evaluate the success or failure of candidate architectures. If the candidate architecture addresses more use cases, or addresses existing use cases more effectively, it will help usually indicate that this candidate architecture is an improvement over the baseline architecture.

A good use case will intersect the user view, the system view, and the business view of the architecture. Use these scenarios and use cases to test your design and determine where any issues may be. Consider the following when thinking about your use cases and scenarios:

Early in the project, reduce risk by creating a candidate architecture that supports architecturally significant end-to-end scenarios that exercise all layers of the architecture. Using your architecture model as a guide, make changes to your architecture, design, and code to meet your scenarios, functional requirements, technological requirements, quality attributes, and constraints. Create an architecture model based on what you know at the time, and define a list of questions that must be addressed in subsequent stories and iterations. After you make sufficient significant changes to the architecture and design, consider creating a use case that reflects and exercises these changes.

Application Overview
Create an overview of what your application will look like when it is complete. This overview serves to make your architecture more tangible, connecting it to real-world constraints and decisions. An application overview consists of the following activities:

1. Determine your application type. First, determine what type of application you

are building. Is it a mobile application, a rich client, a rich Internet application, a service, a Web application, or some combination of these types? For more details of the common application archetypes, see Chapter 20 "Choosing an Application Type." 2. Identify your deployment constraints. When you design your application architecture, you must take into account corporate policies and procedures, together with the infrastructure on which you plan to deploy your application. If the target environment is fixed or inflexible, your application design must reflect restrictions that exist in that environment. Your application design must also take into account Quality-of-Service (QoS) attributes such as security and reliability. Sometimes you must make design tradeoffs due to protocol restrictions and network topologies. By identifying the requirements and constraints that exist between the application architecture and infrastructure architecture early in the design process, you can choose an appropriate deployment topology and resolve conflicts between the application and the target infrastructure. For more information about deployment scenarios, see Chapter 19 "Physical Tiers and Deployment." 3. Identify important architecture design styles. Determine which architecture styles you will be using in your design. An architecture style is a set of principles. You can think of it as a coarse-grained pattern that provides an abstract framework for a family of systems. Each style defines a set of rules that specify the kinds of components you can use to assemble a system, the kinds of relationships used in their assembly, constraints on the way they are assembled, and assumptions about the meaning of how you put them together. An architecture style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems. Common architectural styles are Service Oriented Architecture (SOA), client/server, layered, message-bus, and domain-driven design. Applications will often use a combination of styles. For more information about the architectural styles in common use today, see Chapter 3 "Architectural Patterns and Styles." 4. Determine relevant technologies. Finally, identify the relevant technology choices based on your application type and other constraints, and determine which technologies you will use in your design. Key factors to consider are the type of application you are developing, and your preferred options for application deployment topology and architectural styles. The choice of technologies will also be governed by organization policies, infrastructure limitations, resource skills, and so on. The following section describes some of the common Microsoft technologies for each type of application.

Software Quality Assurance

A definition of Software Quality should emphasize three important points: 1.) Software requirements are the foundation from which Software Quality is measured. 2.) Specified standards define a set of development criteria that guide the manner in which software is engineered. 3.) There is a set of implicit requirements that often goes unmentioned. Inspections A Software Inspection is a formal review of a work product by the work product owner and a team of peers looking for errors, omissions, inconsistencies, and areas of confusion in the work product. A formal inspection is performed according to established procedures and schedules. A typical inspection includes the following stages: Planning, Overview Meeting (Kickoff), Preparation, Inspection Meeting, Rework, and Follow-up. A formal inspection has well-defined roles for participants, such as moderator, recorder, reader, author, Root Cause Analysis Root cause analysis (RCA) is a class of problem solving methods aimed at identifying the root causes of problems or events. The practice of RCA is predicated on the belief that problems are best solved by attempting to correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, it is hoped that the likelihood of problem recurrence will be minimized. However, it is recognized that complete prevention of recurrence by a single intervention is not always possible. Thus, RCA is often considered to be an iterative process, and is frequently viewed as a tool of continuous improvement.

Software Reliability Software Reliability is the application of statistical techniques to data collected during system development and operation to specify, predict, estimate, and assess the reliability of software-based systems. "Software Reliability Engineering (SRE) is a standard, proven best practice that makes testing more reliable, faster, and cheaper. It can be applied to any system using software and to frequently-used members of software component libraries." Statistical Process Control (SPC) SPC is about using control charts to manage software development efforts, in order to effect software process improvement. The practitioner of SPC tracks the variability of the process to be controlled. When that variability exceeds the range to be expected from natural causes, one then identifies and corrects assignable causes. Verification and Validation (V&V) is a series of technical and managerial activities performed by someone other than the developer of a system to improve the quality and reliability of the system and assure the developed product satisfies the user's operational needs. Verification is the assurance that the products of a particular development phase are consistent with the requirements of that phase and preceding phase(s), while validation is the assurance that the final product meets system requirements. V&V can be performed by an outside agency, which is referred to as Independent V&V, or IV&V, or by a group within the organization but not the developer, referred to as Internal V&V. Use of V&V often accompanies testing, can improve quality assurance, and can reduce risk.

Analysis
General understanding and description of overall process

The requests are presented to the review board, which is responsible to make assessments and make course of actions.

PRB takes decisions on the requests by doing cost and complexity analysis. Requests are than prioritized in separate queues based on their urgencies, market competition and the complexity of the tasks. Releases are planned based on the defined prioritized items in the queue. Products are deployed into production for over 60000 customers. Support and maintenance requested are served 24/7, throughout year. Change request based on surveys and normal feedbacks are again logged into the same system, which goes through same priority and planning phases.

Answers to the questions asked :

1.What is your name? Furqan lodhi 2. Would you like to describe your academic and professional background? Bscs(hons), mscs 3. What is your core field of specialization? Programing Java, dot net , 4. Would you like to describe your current position at organization? Team leader

A Team Leaders exact responsibilities vary from company to company, but in general he or she is responsible for the underlying architecture for the software program, as well as for overseeing the work being done by any other software engineers working on the project

5. How much time you are related to this particular field? If you like to inform your experience in years? 6 years and 6 months 6. How many employees working under your supervision? It depends on the projects currently I am directing 6 or 7 people 7. Do you have any kind of experience of CMMI-related activities? No

It is important to note that CMMi defines what processes and activities need to be done and not how these processes and activities are done. The goal of CMMi is process improvement and CMMi can be thought of as a Software Process Improvement, SPI, framework.

8. What type of activities you are currently performing in the organization? I am leader of the team , coding, management of the team some portion of the testing

Organization related Question

1. Would you like to provide some general information about your software organization? Our organization is globalized different virtual mangers are handling the branches .different teams are managed to handle the different projects, different departments like quality assurance and testing department is also available to give the better products to our client.
The software industry includes businesses for development, maintenance and publication of software that are using any business model. The industry also includes software services, such as training, documentation, and consulting.

2. When your organization established? Organization was established in 1997 3. How many employees are currently working there? Approximately 400 workers are working in7 branches of Pakistan.

4. How many countries containing different branches of your organization? Mostly branches are in Pakistan but some departments are also in America.

5. How are you targeting your customers regarding to (bespoke or market-driven) products? It depends that what the clients wants like if he wants some business sites then we direct him but if he want some software like map creator and other then product will always according to the client requirements.
Custom software (also known as bespoke software) is software that is specially developed for some specific organization or other user. As such, it can be contrasted with the use of software packages developed for the mass market, such as commercial off-the-shelf (COTS) software, or existing free software.

6. Which SDLC being followed in your organization? It depends on the projects in some we use basic water fall method but mostly we use RAD(rapid application development) to develop a product.

The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance.

7. What are your main Organizational goals? How your organization align them and what type of activities are performed?

The Market share to generate revenue by giving quality products .give better main goals are services and earn money. Innovation. Productivity. Physical and financial resources. Profitability. Management performance and development. Employees performance and attitude goals. Social responsibility.

8. Why your organization wants to attain the higher maturity level? That it becomes best org to provide good products.

Measurement Perspective Questions

1. What type of services your Organization is providing? Our organization is providing networks , applications and security solutions to our clients all over the Globe and are looking to increase our scope.

2. What kind of Project/Products is developed by your company? Would you like to explain it briefly? Mostly web based application ,CMS(content management system) enterprises, ecommerce based, mobile phone based applications.

A content management system (CMS) allows publishing, editing, and modifying content as well as site maintenance from a central page. It provides a collection of procedures used to manage work flow in a collaborative environment. These procedures can be manual or computer-based.

3. What are your main business goals for any project/product development? The main goal of project is to provide a product to the customer according to his requirements with his limitations and provide it in time and quality thing.

4.Does your organization have a special department for measurement? As such no separate department is there for measurement cost is decided by the higher management and roughly estimation of the project has developed for the working.

4. How are you performing measurements for your project/products in the organization and which process is used? As such no measure are collected like number of errors per ,lines of code but time duration is affected and varies in different project ,actually we do estimation according to the project when any project has given the team related to this project and customer meetings are arrange to understand the project here time ,cost is discussed .it is our duty to give the better quality to our customer

5. How does the organization collect measures from the projects? Mostly measures are not collected in a proper form, some project take to much time to complete, some requires lot of budget, quality increases according to requirement and the budget.

6. Is there any measurement training provided? How is it? Is it only for measurement department or for all departments? Which and how people are selected for it? No

7. How is the co-ordination between measurement department and other departments? Actually the team that handling the project estimates the things with his experience. 8. What type of measurement data will be collected on regular basis that is required by project managers? Actually a team leader handles it he assigns the work to the others and have a check on them and a team leader reports to the manager about his team work.

11. What are the types of indicators that focused during project/product development? Would you like to specify the name of some leading indicators, such as cost? Any example for explanation? Mostly the cost indicators are managed , we are not using any special metrics but the main indicators during our development are time and cost .

12. How did software measurements widely used for management and development decisions making? I think the measurements have a vital role in deciding what to do in a project as it would be helping in time as well as cost assessment in our projects.

13. How do you decide which project measurements should be collected? We take this help from our past experiences and it helps us deciding what should be best in project measurement

14. How are you software measurements used to improve your organization performance?

That is an answer only an analyst can give completely , the performance is not dependent on measurements only , it requires dedication alongside it .

15. Which type of the software measurement activities are performed in the organization? It involves a scheme that partitions the domain of software production by considering the entities that are amenable to measurement.

16. What are the basic software measures are collected in the organization? Number of lines of code Most of thelines of customer requirements difficulties in choosing Number of software organizations face the measures time Program executionto collect since there is no universal set of measures for Program load time all types of organizations and projects. Experience shows that measurement can be more successful if Program size (binary)

the measures are collected based on the goals of the organization or the project which it will serve. However, one of the major constraints for the organizations is the associated cost for the resources needed when collecting the measures. Therefore, based on their goals, the software organizations require collecting not only as few measures from a large number of possible measures as possible but an optimum set of measures as well. In this paper, we propose a model, called Optimum Measures Set Decision (OMSD) Model, which is an extension of the well-known Goal Question Metric (GQM) paradigm using a heuristics approach. We performed a survey by distributing a structured questionnaire to a number of people from the industry in order evaluate and get feedback on these factors. We evaluated the rules of the model by means of some sample cases we created. In this paper, we discuss OMSD as well as the empirical studies we conducted in order to develop it.

17. Did your organization use any measurement tool or framework? If yes then please specify the name? And what type of results gathered from them?

No such tool is being used as it is sometimes a very expensive practice. 18. How you characterized the involvement of different stakeholders in deciding goals and measurement? I believe that the goal of a disciplined agile delivery project team should be to provide their stakeholders with a solution which fulfills their current understanding of the intent of their stakeholders as effectively as possible

19. What are the main problems in the software measurement process that you are practicing? It sometimes becomes complex and quite difficult and consumes a lot of time . 22. How you characterize are classified that these measures are better for specific project? On which basis you select them? Is all stakeholders are involved in it? All stakeholders are certainly involved ,yes its better to measure a software in a project as it would help in attaining better results in future projects.

23. How is your organization analyzing the software measurements? We have hired analysts in USA that do the job for us

24. It is valuable or only wastage of time for your organization. On what basis? It will be helpful for future but it take lots of time and I think it is mostly for evaluation purposes not for estimation every project has its own characteristics.

25. Do you think automated software measurement tool will support your measurement process?

I think It will work but we are not dealing so much measurements.

26. How do you provide quality based products to the customer and what is your main motivation? Our main motivation is to provide good service and earn more.

Project Based
1. Would you like to briefly explain about any project/product that was developed recently? Now a days I am working on a project inertia related to the constructions process it can provide to generate maps, designing of the whole construction. we also making its mobile application.

2. Does the project follow a written organizational policy for managing the system measurement process? No

3. Which goal was more critical in this project development? Which were most important goals to achieve for this project? The most important achievement would be designing this map generator and making its mobile prototype , it will be the first of its kind .

4. How much human resources were used in project development? 7 people are handling This project

5. How much time was consumed for project? We are working from last three years and going on. 6. What were the main goals for this project development?

The main requirements are to give designs and making maps.

Conclusion :
It can be concluded from the above research and interviewed questions that no company can be ideal and there are always some problems which cause failures at different times . the company we interviewed was a simple yet a good one and we have gained quite some information along with experience from that interview . The software companies and their working environments are entirely different from what we experience in our daily routine , it evolves around the project and the stakeholders , some work for money and some for pleasure but all the same , the ultimate goal is to achieve what is assigned to them , it was a good experience and we have concluded that most of the practices that are read are not followed and the company and is working is optimized according to requirements and working conditions rather than following strict rules and following general standards of work as in other departments .