Bachelor of Computer Application (BCA) Semester 5 BC0054 Software project Management & Quality Assurance 4 Credits

Assignment Set 1 (60 Marks)

Ques1. Explain different roles of the software development. Ans. Job Roles in Software Development
The following are the roles based on the Microsoft Solutions Framework (MSF). Middle-Management Leadership

Manage people, resources, and budgets. Oversee and provide vision for several major projects simultaneously. Review employees in all other positions. Work with other MM leaders for interaction between projects. Team Leadership

Manage people, resources, and timelines for one major project or several minor projects. Act as the central point of contact on those projects. Involve or aware of virtually every issue or decision in project. Team Leader is responsible for all aspects of the project. Work with all other positions. Product Management

Work with clients to define requirements and resolve issues. Design and maintain functional specifications and other documentation. Often provide prototypes for user interfaces or design interface of services. Work with Team Leadership and Software Development. Logistics

Manage hardware/software requirements for development, testing, validation, and production environments. Perform or oversee installations. Own the installation process and any installation utilities. Work with resource teams to obtain servers/software and address issues within the environments. Work with Team Leader.

Software Development (Programming)

Design and code the software to match the specifications, prototypes, and other documentation. Define timelines. Work with Product Management to refine expectations and clarify requirements. Often interact with Team Leader, Tester, User Documentation, and User Education. Software Testing

Define testing procedures and certification process. Define timelines. Create and execute tests on software. Manage a bug-tracking procedure. Work with Team Leadership. Collaborate with Product Management to define areas and specifics of testing. Often interact with Software Developer. Work with Team Leader. User Documentation

Create and maintain user-centric documentation. Work with Product Management and Software Development to define and document functionality. Often provide training materials for User Education. Work with Team Leader. User Education

Create training procedures and policies. Design training materials. Execute training sessions. Work with Product Management and User Documentation. Work with Team Leader. Software Support

Define support procedures. Handle user issues. Provide resolutions or formulate work-around for software issues. Forward hardware/infrastructure issues to Logistics. Notify Software Testing and Development of software bugs. Work with Team Leader.

Ques2. Briefly explain various activities involved in project management. Ans. Project Management activities
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.

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.

Ques3. 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

Ques4. What is COCOMO? Write necessary steps for cost estimation. Ans. COCOMO (COnstructive COst MOdel) has been designed in 1981 by Barry Boehm to given an
estimate of the number of man-months it will take to develop a software product and it is referred as COCOMO 81 A new model called COCOMO II was designed in 1990 and the need for this model came up as software development technology moved from mainframe and overnight batch processing to desktop development, code re-usability and the use of off-the-shelf software components. COCOMO consists of a hierarchy of 3 increasingly detailed and accurate forms: 1) Basic COCOMO - is a static, single valued model that computes software development effort and cost as a function of program size expressed in estimated lines of code 2) Intermediate COCOMO - computes software development effort as function of program size and a set of "cost drivers" that include subjective assessment of product, hardware, personnel and project attributes 3) Detailed COCOMO - incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step in SDLC .

Steps for Estimation Step 1: Establish Objectives Key the estimating objectives to the needs for decision making information. Balance the estimating accuracy objectives for the various system components of the cost estimates.

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 orderto 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 modelimprovement feedback of any estimates-versus-actual differences are important. Software projects tend to be volatile: components are added, split up, rescoped, or combined in unforeseeable ways as the project progresses. The project manager needs to identify these changes and generate a more realistic update of the estimated upcoming costs. Software is an evolving field. Estimating techniques are all calibrated on previous projects, which may not have featured the future projects environment. It is important to sense differences due to these trends and incorporate them into improved project estimates and improved estimating techniques continuing to manage the project. Software estimating techniques are imperfect. For long-range improvements, we need to compare estimates to actual and use the results to improve the estimating techniques.

Ques5. Explain how to draw PERT chart with one example.

Ans. PERT is basically a method to analyze the tasks involved in completing a given project,
especially the time needed to complete each task, and identifying the minimum time needed to complete the total project. This model was invented by Booz Allen Hamilton, Inc. under contract to the United States Department of Defense's US Navy Special Projects Office in 1958 as part of the Polaris mobile submarine-launched ballistic missile project. PERT was developed in the 1950s, primarily to simplify the planning and scheduling of large and complex projects. It was able to incorporate uncertainty by making it possible to schedule a project not knowing precisely the details and durations of all the activities. It is more of an event-oriented technique rather than start- and completion-oriented The most famous part of PERT is the "PERT Networks", charts of timelines that interconnect. PERT is intended for very large-scale, one-time, complex, non-routine projects. The PERT chart provides a graphical display of Critical Path on a project. Most scheduling tools highlight the activities on the Critical Path. It is useful to include the following information in the activities on the PERT chart: Duration, Float Start date, End date, Resources Float The amount of surplus time and leeway allowed in scheduling tasks so that the network critical path is maintained on schedule. Example:

Figure. 5.

PERT network chart for a seven-month project with five milestones (10 through 50) and six activities (A through F). Conventions A PERT chart is a tool that facilitates decision making. The first draft of a PERT chart will number its events sequentially in 10s (10, 20, 30, etc.) to allow the later insertion of additional events. Two consecutive events in a PERT chart are linked by activities, which are conventionally represented as arrows in the diagram above. The events are presented in a logical sequence and no activity can commence until its immediately preceding event is completed. The planner decides which milestones should be PERT events and also decides their proper sequence. A PERT chart may have multiple pages with many sub-tasks. A PERT activity: is the actual performance of a task. It consumes time, it requires resources (such as labor, materials, space, machinery), and it can be understood as

representing the time, effort, and resources required to move from one event to another. A PERT activity cannot be completed until the event preceding it has occurred. PERT event: is a point that marks the start or completion of one or more tasks. It consumes no time, and uses no resources. It marks the completion of one or more tasks, and is not reached until all of the activities leading to that event have been completed. Critical Path: the longest possible continuous pathway taken from the initial event to the terminal event. It determines the total calendar time required for the project; and, therefore, any time delays along the critical path will delay the reaching of the terminal event by at least the same amount. A predecessor event: an event (or events) that immediately precedes some other event without any other events intervening. It may be the consequence of more than one activity. A successor event: an event (or events) that immediately follows some other event without any other events intervening. It may be the consequence of more than one activity. Slack: the slack of an event is a measure of the excess time and resources available in achieving this event. Positive slack (+) would indicate ahead of schedule; negative slack would indicate behind schedule; and zero slack would indicate on schedule.

Ques6. What is project scheduling? Explain different techniques for project scheduling.
Ans.

February 2011 Bachelor of Computer Application (BCA) Semester 5 BC0054 Software project Management & Quality Assurance 4 Credits
Assignment Set 2 (60 Marks)

Ques1. 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. Ques2. Explain in detail about risk management activities. Ans. In project management, risk management includes the following activities: Planning how risk management will be held in the particular project. Plan should include risk management tasks, responsibilities, activities and budget. Assigning a risk officer - a team member other than a project manager who is responsible for foreseeing potential project problems. Typical characteristic of risk officer is a healthy skepticism. Maintaining live project risk database. Each risk should have the following attributes: opening date, title, short description, probability and importance. Optionally a risk may have an assigned person responsible for its resolution and a date by which the risk must be resolved. Creating anonymous risk reporting channel. Each team member should have possibility to report risk that he foresees in the project. Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of the mitigation plan is to describe how this particular risk will be handled what, when, by who and how will it be done to avoid it or minimize consequences if it becomes a liability. Summarizing planned and faced risks, effectiveness of mitigation activities and effort spend for the risk management

Ques3. What are the issues that should be considered during software configuration process?

Ans. Software configuration management is an important element of software quality assurance. Its primary responsibility is the control of change. However, SCM is responsible for the identification of individual SCIs and various versions of the software, the auditing of the software configuration to ensure that it has been properly developed, and the reporting of all changes applied to the configuration. Any discussion of SCM introduces a set of complex questions: Software configuration management is an important element of software quality assurance. Its primary responsibility is the control of change. However, SCM is responsible for the identification of individual SCIs and various versions of the software, the auditing of the software configuration to ensure that it has been properly developed, and the reporting of all changes applied to the configuration. Any discussion of SCM introduces a set of complex questions: How does an organization identify and manage the many existing versions of a program (and its documentation) in a manner that will enable change to \ accommodated efficiently? How does an organization control changes before and after software is released to a customer? Who has responsibility for approving and ranking changes? How can we ensure that changes have been made properly? What mechanism is used to apprise others of changes that are made?

Ques4. Explain the following Team organizations: a. Centralized control team organization b. De-Centralized control team organization Ans. a) Centralized control team organization Centralized-control team organization is a standard management technique in well understood disciplines. In this mode of organization, several workers report to a supervisor who directly controls their tasks and is responsible for their performance. Centralized control is based on a hierarchical organizational structure in which number of supervisors report to a "second-level" manager and so on up the chain, to the president of the enterprise. In general, centralized control works well with tasks which are simple One way to centralize the control of person responsible for control is through chief-programmer team. In enough that the one a software development team of the project can this kind of organization, problem and its solution. chief programmer, is responsible for the design grasp the one engineer, known as the and all the technical details of the project. The chief programmer reports to a peer project manager who is responsible for the administrative aspects of the project. Other members of the team are a software librarian and programmers who report to the chief programmer and are added to the team on a temporary basis when needed. Specialists may be used as consultants to the team. The need for programmers and consultants, as well as what tasks they perform is determined by the chief programmer, who initiates and controls all decisions. The software library maintained by the librarian is the central repository for all the documentation, and decisions made by the team. Figure 4.0 is a graphical representation of the patterns of control and communication supported by this kind of organization...

Fig. 4.0: chief programmar team On the negative side, a chief programmer team has a "single point of failure." Since all communication must go through, and all decisions must be made by, the chief programmer, he or she may become overloaded or, indeed, saturated. The choice of chief programmer is the most important determinant of success of the team. ERROR! The success of the chief-programmer team clearly depends on the skill ability of the chief programmer, the size and complexity of the problem. b) Decentralized-Control Team Organization In a decentralized-control team organization, decisions are made by consensus, and all work is considered group work. Team members review each other's work and are responsible as a group for what every member produces. Figure 4.1 shows the patterns of control and communication among team members in a decentralized-control organization. The ringlike management structure is intended to show the lack of a hierarchy and that all team members are at the same level. Such a "democratic" organization leads to higher morale and job satisfaction and, therefore, to less turnover. The engineers feel more ownership of the project and responsibility for the problem, resulting in higher quality in their work. A decentralized-control organization is more suited for long-term projects, because the amount of intragroup communication that it encourages leads to a longer development time, presumably accompanied by lower life cycle costs. The proponents of this kind of team organization claim that it is more appropriate for less understood and more complicated problems, since a group can invent better solutions than a single individual can. Such an organization is based on a technique referred to as "egoless programming," because it encourages programmers to share and review one another's work. On the negative side, decentralized-control team organization is not appropriate for large teams, where the communication overhead can overwhelm all the engineers, reducing their individual productivity.

Fig 4.1: (a) management structure.

Fig. 4.1: (b) patterns of communication

Ques5. What is Software Quality Assurance plan? Will it have impact on the quality of the software to be developed? Ans. The SQA Plan provides a road map for instituting software quality assurance. Developed by the SQA group, the plan serves as a template for SQA activities that are instituted for each software project. The purpose of creating a software assurance plan is to document/specifies the conduct of the activities that will comprise software assurance for a specific project. A standard for SQA plans has been recommended by the IEEE [IEE94], Initial sections describe the purpose and scope of the document and indicate those software process activities that are covered by quality assurance. All documents noted in the SQA Plan are listed and all applicable standards are noted. The management section of the plan describes SQA's place in the organizational structure, SQA tasks and activities and their placement throughout the software process, and the organizational roles and responsibilities relative to product quality. Effective assurance programs require planning and follow through. The plan identifies, Evaluations to be performed Audits and reviews to be performed Standards those are applicable to the project. Procedures for error reporting and tracking

Documents to be produced by SQA group The SQA plan also identifies the tools and methods support SQA activities and tasks. It cannot simply evolve along with the project. Adequate assurance planning ensures that the assurance activities are focused on the quality requirements and risks associated with the specific project. Ques6. Explain the role of project closure analysis with a diagram. Ans. The Role of Closure Analysis The objective of a postmortem or closure analysis is "to determine what went right, what went wrong, what worked, what did not, and how it could be made better the next time. "Relevant information must be collected from the project, primarily for use by future projects. That is, the purpose of having an identified completion analysis activity, rather than simply saying, "The project is done," is not to help this project but rather to improve the organization by leveraging the lessons learned. This type of learning can be supported effectively by analysis of data from completed projects. This analysis is also needed to understand the performance of the process on this project, which in turn is needed to determine the process capability. As noted earlier, the data obtained during the closure analysis are used to populate the process database (PDB). The data from the PDB can be used directly by subsequent projects for planning purposes. This information is also used in computing the process capability, which is used by projects in planning and for analyzing trends. Figure 6. illustrates the role of closure analysis. Earlier chapters discuss the types of data generally collected in a project and describe the collection methods. The amount of raw data collected in a project can be quite large. For example, a project involving five people and lasting for 25 weeks will have 125 entries for weekly effort, data for about 250 defects (assuming about 0.05 defects injected per person-hour), data on many change requests,

various outputs, and so on. Clearly, these data will be of limited use unless they are analyzed and presented within a proper framework and at a suitable level of abstraction. Closure analysis aims to accomplish this goal. After data analysis and extraction of all lessons learned from the analyses, the results should be packaged so that they can be used by others (packaging is the last step in the quality improvement paradigm6). Furthermore, to leverage this information, project processes must be constructed so that their execution requires the effective use of data. It can be argued, however, that even if others do not learn from the packaged information, the project personnel will have consolidated their experience and will carry the lessons learned from the analysis into future projects. In other words, a closure analysis is useful even if others do not directly gain from it.

Figure 6 : The role of closure analysis