ASSIGNMENT SET – 1

1. Explain the difference between light-weighted matrix organization and heavy-weighted matrix organization.

Ans: Lightweight and heavyweight processes refer the mechanics of a multi-processing system.

In a lightweight process, threads are used to divvy up the workload. Here you would see one process executing in the OS (for this application or service.) This process would posess 1 or more threads. Each of the threads in this process shares the same address space. Because threads share their address space, communication between the threads is simple and efficient. Each thread could be compared to a process in a heavyweight scenario.

In a heavyweight process, new processes are created to perform the work in parallel. Here (for the same application or service), you would see multiple processes running. Each heavyweight process contains its own address space. Communication between these processes would involve additional communications mechanisms such as sockets or pipes.

The benefits of a lightweight process come from the conservation of resources. Since threads use the same code section, data section and OS resources, less overall resources are used. The drawback is now you have to ensure your system is thread-safe. You have to make sure the threads don't step on each other. Fortunately, Java provides the necessary tools to allow you to do this.

2. What is project management? Explain various activities involved in project management.

Ans: Project management is a systematic method of defining and achieving targets with optimized use of resources such as time, money, manpower, material, energy, and space.

Project Management is composed of several different types of activities such as: 1. Planning the work or objectives: A manager must decide what objectives are to be achieved, what resources are required to achieve the objectives, how and when the resources are to be acquired and how the objectives are achieved. 2. Assessing and controlling risk (or Risk Management): Risk is associated with several issues. It can be technical risk, methodology risk and financial risk etc. Manager need to plan from the starting of the project, to handle unexpected or sudden occurrence of risks. 3. Estimating resources: Resource estimation is another crucial task to the project manager. A resource can be software, hardware, human personnel, capital etc. Resource estimation involves the planning of required resources for the given tasks in the given period of time. Optimum utilization of these resources is the ultimate goal of manager. 4. Allocation of resources and assigning tasks: This involves identification of task and allocation of required resources to fulfill the given task. For example, identification of skilled personal to solve the given task. 5. Organizing the work: Organizing involves clear lines of authority and responsibility for groups of activities that achieve the goals of the enterprise.

6. Acquiring human resources (staffing): Staffing deals with hiring personnel, which involves recruiting, compensating, developing and promoting employees. 7. Directing activities: Directing involves leading subordinates. The goal of directing is to guide the subordinates and to understand and identify the organizational structure and goals of the enterprise. 8. Controlling project execution: Controlling consists of measuring and correcting activities to ensure the goals are achieved. Controlling requires the measurement against plans and taking corrective action when development occurs. 9. Tracking and reporting progress: After assigning the tasks to the team members, it is essential to track and monitor the work progress. The work progress is documented at regular intervals. 10. Forecasting future trends in the project: The project must be designed to facilitate extensibility of new features in the forth coming days. This is very crucial task of manager or designer. Designers have to keep this point in mind, while designing architecture for the system. 11. Quality Management: Satisfying the customer requirements is called quality. Quality reflects in many ways. It can be through functionality, performance and external factors like portability etc. So the project manager needs to implement different quality management techniques from the analysis phase itself. 12. Issues solving: An issue can be a conflict among the team members, sudden increase in the attrition rate of employees, sudden drop in rupee value etc. Based on the issues, proper corrective action need to be taken to ensure the smooth working of the system. 13. Defect prevention: A defect is a flaw in the system. It is more serious than an error. A defect occurs because of improper design, poor quality etc. A thorough testing is needed before and after implementation of the product, to avoid the defects. 14. Project Closure meet: Project closure describes the overall project details. The details can be conveyed through closure reports. Ex. Performance reports, testing reports and project completion reports. Controlling: Controlling consists of measuring and correcting activities to ensure the goals are achieved. Controlling requires the measurement against plans and taking corrective action when development occurs.

3. Explain in detail about software project development stages.

Ans: Regardless of the methodology used, the project development process will have the same major stages: Initiation, Planning and design, project implementation and closing/maintenance.

Initiation

The initiation stage determines the nature and scope of the development. If this stage is not performed well, it is unlikely that the project will be successful in meeting the business’s needs. The key project controls needed here is an understanding of the business environment and making sure that all necessary controls are incorporated into the project. Any deficiencies should be reported and a recommendation should be made to fix them.

The initiation stage should include a cohesive plan that encompasses the following areas:

· Study analyzing the business needs in measurable goals. · Review of the current operations. · Conceptual design of the operation of the final product. · Equipment requirement. · Financial analysis of the costs and benefits including the budget. · Select stake holders, including users, and support personnel for the project. · Project charter including costs, tasks, deliverables, and schedule. This phase can also be called initiation phase, where in people has to identify the following, · Information to be processed. · Functions required. · Performance required. · System behavior should be determined · No of interfaces required should be estimated. This may be difficult to do. But tentatively allowed. Some times project can be dropped during at this phase. Planning and Design

After the initiation stage, the system is designed. Occasionally, a small prototype of the final product is built and tested. Testing is generally performed by a combination of testers and end users, and can occur after the prototype is built or concurrently. Controls should be in place that ensures that the final product will meet the specifications of the project charter. The results of the design stage should include a product design that:

· Satisfies the project sponsor, end user, and business requirements. · Functions as it was intended. · Can be produced within quality standards. · Can be produced within time and budget constraints. During this phase the following issues are addressed, · How design should be converted into code? · Testing strategy should be planned · Strategy for module integration. · Architectural issues are evaluated · Interfaces are characterized. Etc Project Implementation

Against the project plan and project organization structure defined in the previous stage, the project activities are executed, tracked and measured. The project implementation stage not only includes the completion of planned activities, but also the evaluation of the success and contribution of this effort and the continual review and reflection of project status and outstanding issues against the original project business case.

The implementation is basically concerned with the development of code and deploying the code. There should be synchronization between the code and design. Tools are available to synchronize both code and design.

(Ex: UML – Visual Paradigm, Rational Rose etc).Once implementation is over, proper testing is required. Testing can be unit testing, performance testing, load testing, integration testing and system testing.

Closing and Maintenance

One of the key success criteria for continuous process improvement involves defining a formal process for ending a project. This includes evaluating the successful aspects of the project as well as identifying opportunities for improvement, identification of project "best practices" that can be leveraged in future projects, and evaluating the performance of project team members. Closing includes the formal acceptance of the project and the ending thereof. Administrative activities include the archiving of the files and documenting lessons learned.

Maintenance is an ongoing process, and it includes: · Continuing support of end users · Correction of errors · Upgradation of software and hardware etc. · Documentation preparation (user manuals). 4. Explain different project planning methods. Ans: Every project starts with initiation. In which project scope, pros and cons are discussed. Once the project initiation phase is completed, the project team, usually the project manager and the analysts in the early stages, must determine the scope of the effort necessary to accomplish the necessary tasks. There are many methods available for accomplishing this planning process; many of them use graphics of varying types, but all require the same basic information. 1. Project start date 2. Project completion date 3. Selection of the project methodology or project life cycle to be used. 4. Scope of the project in terms of the phases of the selected project methodology or project life cycle. 5. Identification or selection of the project review methods to be used 6. Identification of any predetermined interim milestone or other critical dates which must be met. 7. A list of tasks, by project phase in the order in which they must be accomplished 8. An estimate of the personnel necessary to accomplish each task 9. An estimate of the personnel available to accomplish each task 10. Skill level necessary to perform each task 11. Task dependencies 12. Which tasks can be performed in parallel? 13. Which tasks require the completion of other tasks before they can start? 14. Project control, or review points 15. Project cost estimation and cost-benefit analysis

5. What is cost estimation? Explain different cost Estimation methods. Ans: Cost Estimating is a critical component of a Project Management Process or methodology. Estimates are used for budgeting, planning, forecasting, resource planning, and staffing. Customers also use estimates to make decisions for changing their business and systems. Cost estimates are quantitative assessments of the likely costs of the resources required to complete project activities. They may be presented in summary or in detail. Costs must be estimated for all resources that will be charged to the project. This includes, but is not limited to, labor, materials, supplies, and special categories such as an inflation allowance or cost reserve. Steps for Estimation Step 1: Establish Objectives (i) Key the estimating objectives to the needs for decision making information. (ii) Balance the estimating accuracy objectives for the various system components of the cost estimates. (iii) Re-examine estimating objectives as the process proceeds, and modify them where appropriate.   Step 2: Plans for Required Data and Resources If we consider the software cost-estimation activity as a mini project, then we automatically cover this problem by generating a project plan at an early stage. The mini plan includes an early set of notes on the why, what, when, who, where, how, how much, and whereas of your estimating activity. Step 3: Pin Down Software Requirements It is important to have a set of software specifications that are as unambiguous as possible (subject to qualifications with respect to our estimating objectives). The best way to determine to what extent a software specification is cost table is to determine to what extent it is testable. A specification is testable to the extent that one can define a clear pass/fail test for determining whether or not the developed software will satisfy the specification. In order to be testable, specifications must be specific, unambiguous, and quantitative wherever possible. Step 4: Work out as Much Detail as Feasible "As feasible" here means "as is consistent with our cost-estimating objectives". In general, the more detail to which we carry out our estimating activities, the more accurate our estimates will be, for three main reasons: a) the more detail we explore, the better we understand the technical aspects of the software to be developed; b) the more pieces of software we estimate, the more we get the law of large numbers working for us to reduce the variance of the estimate; c) the more we think through all the functions the software must perform, the less likely we are to miss the costs of some of the more unobtrusive components of the software Step 5: Use Several Independent Techniques and Sources None of the alternative techniques for software cost estimation is better than the others from all aspects, their strengths and weaknesses are complementary. It is important to use a combination

of techniques, in order to avoid the weakness of any single method and to capitalize on their joint strengths. Step 6: Compare and Iterate Estimates The most valuable aspect of using several independent cost-estimation techniques is the opportunity to investigate why they give different estimates. An iteration of the estimates after finding why they give different estimates may converge to a more realistic estimate. Step 7: Follow-up Once a software project is started, it is essential to gather data on its actual costs and progress and compare these to the estimates because of: Software estimating inputs are imperfect (sizing estimates, cost driver ratings). It is important to update the cost estimate with the new knowledge of the cost drivers by comparing the estimates to actual, providing a more realistic basis for some projects does not exactly fit the estimating model. Both near-term project-management feedback and long-term model-improvement feedback of any estimates-versus-actual differences are important. 6. What is budgeting? Write any three budgeting techniques.. Ans: Budgeting in a business sense is the planned allocation of available funds to each department within a company. Budgeting allows executives to control overspending in less productive areas and put more company assets into areas which generate significant income or good public relations. Budgeting is usually handled during meetings with accountants, financial experts and representatives from each department affected by the budgeting. Software budgeting is also the same. The three budgeting techniques are :-

(i) Capital budgeting (or investment appraisal) is the planning process used to determine a firm's long term investments such as new machinery, replacement machinery, new plants, new products, and research and development projects.(EX: IT projects ) Many formal methods are used in capital budgeting, including the techniques such as · Net present value · Profitability index · Internal rate of return · Modified Internal Rate of Return, and · Equivalent annuity. These methods use the incremental cash flows from each potential investment, or project. Techniques based on accounting earnings and accounting rules are sometimes used - though economists consider this to be improper – such as the accounting rate of return, and "return on investment." Simplified and hybrid methods are used as well, such as payback period and discounted payback period. (ii) ROI is also known as rate of profit. Return can also refer to the monetary amount of gain or loss. ROI is the return on a past or current investment, or the estimated return on a future investment. ROI is usually given as a percent rather than decimal value.

ROI does not indicate how long an investment is held. However, ROI is most often stated as an annual or annualized rate of return, and it is most often stated for a calendar or fiscal year. In this article, “ROI” indicates an annual or annualized rate of return, unless otherwise noted.

ROI is used to compare returns on investments where the money gained or lost – or the money invested – are not easily compared using monetary values. For instance, a $1,000 investment that earns $50 in interest obviously generates more cash than a $100 investment that earns $20 in interest, but the $100 investment earns a higher return on investment. · $50/$1,000 = 5% ROI · $20/$100 = 20% ROI Since rates of return are percentages, negative rates cannot be averaged with positive rates for purposes of calculating monetary returns. However, it is common practice in finance to estimate monetary returns by averaging periodic rates of return; these estimations are most useful when the averaged periodic returns are all positive, all negative, or have low variances.

(iii) Payback time, or payback period, is the time it will take to recoup, in the form of cash inflows from operations, the initial dollars invested in a project.

P= I ÷ O

Payback Model Example

Assume that $12,000 is spent for a machine with an estimated useful life of 8 years.

Annual savings of $4,000 in cash outflows are expected from operations.

What is the payback period?

P = I ÷ O = $12,000 ÷ $4,000 = 3 years

ASSIGNMENT SET – 2 1. Explain the software configuration management process in detail. Ans: The output of the software process is information that may be divided into three broad categories: (1) computer programs (both source level and executable forms); (2) documents that describe the computer programs (targeted at both technical practitioners and users), and (3) data (contained within the program or external to it). The items that comprise all information produced as part of the software process are collectively called a software configuration. As the software process progresses, the number of software configuration items (SCIs) grows rapidly. A System Specification spawns a Software Project Plan and the software Requirements Specification (as well as hardware related documents). These in turn spawn other documents to create a hierarchy of information. Change may occur at any time, for any reason. In (the First Law of System Engineering [BER80] states: "No matter where you are in system life cycle, the system will change, and the desire to change it will pen throughout the life cycle." There are four fundamental sources of change. � New business or market conditions dictate changes in product requirements or business rules.

� New customer needs demand modification of data produced by informal systems,

� Functionality delivered by products. � Reorganization or business growth/downsizing causes changes in project priorities

� Changes in software engineering team structure.

� Budgetary or scheduling constraints cause a redefinition of the system or product. Software configuration management is a set of activities that have been developed to manage change throughout the life cycle of computer software. SCM can be viewed as a software quality assurance activity that is applied throughout the software process. In the sections that follow, we examine major SCM tasks and important concepts that help us to manage change.

2. What is software risk? Explain various factors for risks. Ans: Risk is the possibility of loss. It is a function of both the probability of an adverse event occurring and its impact; the impact manifests itself in a combination of financial loss, time delay, and loss of performance. A risk is the precursor to a problem; the probability that, at any given point in the software life cycle, the predicted goals cannot be achieved within available resources. Risk can not be eliminated from a software project, but it can be managed. Risk management is critical to the success of any software effort and is a strategic aspect of all software projects. Software risks can be caused by defects inherent in the software, such as errors, ambiguities, oversights, wrong assumptions, misinterpretation of re-quirements or specifications, malfunctioning of third-party tools, inadequate verification and validation, and incorrect or

unexpected usage. Different types of software faults can cause reliability problems, as discussed in the following sections. Software Design Faults 1) Architecture deficiencies 2) Exception handling issues 3) Traceability issues of specifications or requirements 4) Misinterpretation of specifications or requirements 5) Use of third-party tools without adequately testing them 6) Wrong assumptions regarding the end users or the target platform 7) Inadequate verification and validation of designs 8) Inadequate field size, such as the Y2K issue 9) Environmental changes, such as euro conversion Coding or Construction Faults 1) Oversight 2) Missed steps 3) Errors of omission and commission 4) Inefficient code 5)Ambiguous code 6)Improper interpretation of comparisons due to wrong algorithmsfor data comparisons 7)Numeric precision issues Data Failures 1)Master data errors 2)Ambiguous master data 3)Data precision problems 4)Data corruption 5)Data integrity and consistency problems.

3. What is risk prioritization? Explain risk prioritization techniques.

Ans: The identified risks for a project merely give the possible events that can hinder it from meeting the goal. The consequences of various risks, however, may differ. So before we proceed with management risks, project mangers prioritize them so that management energies can be focused on high risks.

Prioritizatation requires analyzing the possible side effects of the risk event in case it actually occurs. Based on the possible consequences and the probability of the risks event occurring, you can compute the risk exposure, which you can then use for prioritizing risks.

The objective of Risk Prioritization is to prioritize the identified risks for mitigation. Both qualitative and quantitative methods can be used to categorize the risks as to their relative severity and potential impact on the project. To effectively compare identified risks, and to provide a proactive perspective, the risk prioritization method should consider the following factors:

1. the probability of the risk occurring,

2. the consequence of the risk, and

3. the cost and resources required to mitigate the risk.

The Risk Factor Product prioritization methodology consists of identifying project risks, assessing the probability of each risk's occurrence and the consequence of each risk's occurrence, and prioritization of the identified risks by calculating the Risk Factor (RF) Product for each risk, and mitigation of the highest risks to resolution.

4. What are issues involved in software quality assurance?

Ans: QUALITY ASSURANCE PROBLEMS

1) Inadequate software verification

2) Inadequate software validation

3) Not using specialist software testers

4) Not verifying the test results

5) Not measuring the quality of the software product

6) Not having a QA department

It is true that QA activities cannot build quality into a product directly, but they certainly provide an environment that is conducive to producing high-quality software that is free of defects. The QA activities that are critical, in addition to verification and validation, are software process definition and improvement, software quality measurement, analysis and improvement, and definition of standards and guidelines for software engineering activities and their regular improvement.

Many organizations look at the QA department as a cost center and do not provide the funding, resources, and tools necessary for it to function effectively.Apart from this, senior management also does not allocate adequate time for QA activities. It is the norm for senior management to side with the development team in any conflict between the QA department and the development department. How to maintain an organization that is conducive to excellence in quality is discussed in detail in Chapter 4.

5. What is SQA plan? Briefly explain it.

Ans: The software quality assurance plan is one of the most important plans thatshould be prepared before embarking on a software development project. It isthe project’s charter for achieving quality in the project deliverables.The following details are recorded in the software quality assurance plan:

1.Standards—Include coding guidelines, design guidelines, testingguidelines, etc. selected for use in the project. These standards ensurea minimum level of quality in software development as well as uni-formity of output from the project resources.

2.Quality control activities—Proposed activities for the project includecode walkthrough, requirements and design review, and tests (unittesting, integration testing, functional testing, negative testing, end-to-end testing, system testing, acceptance testing, etc.). Quality con-trol activities ensure the necessary conformance to quality require-ments in the project, especially to the three dimensions of quality:specifications (requirements), software design, and construction.

3.Software metrics—Metrics collected for the project define the de-sired level of quality for the artifacts developed for the project.

4.Procedures and events that trigger causal analysis—Include fail-ures, defects, and successes.

5.Audits—To analyze the exceptions in the project so that necessarycorrective and preventive actions are taken to ensure the exceptionsdo not recur in the project.

6.Institute of Electrical and Electronics Engineers Standard 730—Givesdetails on how to prepare a quality assurance plan, including a sug-gested template. 6. What is version control? Explain how it helps to reduce too many changes . Ans: Version Control combines procedures and tools to manage different versions of c figu-ration objects that are created during the software process. Clam [CL describes version con-trol in the context of SCM: Configuration management allows a user to specify alternative configurations of the software system through the selection of appropriate versions. This is supported by associating at-tributes with each software version, and then allowing a configuration to be specified [and constructed] by describing the set of desired attributes. These "attributes" mentioned can be as simple as a specific version number the attached to each object or as complex as a string of Boolean variables (switches) indicate specific types of functional changes that have been applied to the system.

One representation of the different versions of a system is the evolution graph. Each node on the graph is an aggregate object, that is, a complete version of the software. Each version of the software may be composed of different variants. To construct the appropriate variant of a given version of a program, each entity can be as-signed an "attribute-tuple" a list of features that will define whether the entity should be used when a particular variant of a software version is to be constructed. One or more attributes is assigned for each variant. For example, a color attribute could be used to define which entity should be included when color displays are to be supported. Another way to conceptualize the relationship between entities, variants and versions (revi-sions) is to represent 'them as an object pool [REI89]. The relationship between configuration objects and entities, variants and versions can be represented in a three-dimensional space. An entity is composed of a collection of objects at the same revision level. A variant is a differ-ent collection of objects at the same revision level and therefore coexists in parallel with other variants. A new version is defined when major changes are made to one or more objects. A number of different automated approaches to version control have been proposed over the past decade. The primary difference in approaches is the sophistication of the attributes that are used to construct specific versions and variants of a system and the mechanics of the process for construction.