LOVELY PROFESSIONAL UNIVERSITY

Assignment # 1
Software Project Management CSE412

Submitted To: Mr. Navneet Malik

Submitted By: Virender Kumar Section: A17B1 Roll No. 26

Part-A Q.1. As a programmer, you are offered a promotion to project management but you feel that you can make more effective contribution in technical rather than a managerial role. Discuss whether you should accept the promotion. Answer: If a programmer were to accept a project management position he would still be able to do some of the programming for the system but not as much as if he were in a technical role. The project management position would allow the programmer to oversee all the other programmers that are working on the system and would allow him to add changes to the system without having to do too much hard work because the other programmers would have done most of it for him which would still allow him to have input into the system but more of a backseat role. It would also be his responsibility to talk to the client about the system that they would want to create. The programmer may not have any previous experience of being in a management role which may hinder the project by inexperienced decisions. If the programmer stayed in the technical role he would be able to write more of the system and be more involved in the actual making of the system. He would not however have total control of what he would be making as he would have no contact with the client as that would be the role of the project manager. Since the programmer may have lots of experience as a programmer he will have a lot to offer to the project and he may also enjoy his role more. Q.2. The process of project planning is iterative and must be continually reviewed. Using example explain the major reasons and the causes for this. Answer: Iteration is defined as the process of repeating something as often as is necessary until a specific result is achieved. Iterative project planning is important because of the following reasons: 1. In software systems development, iterative project planning adds agility to the development process by allowing the developers as well as the users to learn from, and build upon former software development projects. 2. In particular, iterative development reduces development risks such as poorly defined user requirements; untenable architectures as well as untenable user interfaces. A project planning must be continually reviewed because of the following reasons: Project planning has to be continually reviewed to anticipate project late progress. It is necessary to determine what action to be performed next. Since a particular task may involve partial information, we have to continually update any information change to the particular task or the next task.

This type of activity will increase the possibility of delivering a successful project.

Example: This certainly holds true when defining the exact user requirements of a computerized software system before the design and development stages begin. It is often stated that if you can find an error or an oversight during the requirements definition stage, you can fix it with an eraser and a pencil. Finding the same mistake once the system has become operational can be costly in several ways. A project plan is analogous to a road map that not only shows you how to get from point A to point B; but also lists various milestones along the way. A project plan is similar to a road map with the exception that it also includes the "what" and the "when" with respect to certain project resource requirements as well as their critical paths. A project plan must be continuously monitored to as to determine, at any point in time during the project, if the planned progress of the project corresponds with the actual progress of the project. A discrepancy can be the result of poor planning and/or the introduction of one or more factors during the project that were unforeseen during the project planning phase. If such a discrepancy exists, it must be intercepted at the earliest point in time possible so that immediate corrective actions can be taken, thus minimizing the possibility that the project will not be completed on time and/or within the allocated budget. Q.3. If a software system is intangible, mention the different problems faced by the project management team due to the intangibility of the system. Also mention the reasons behind them. Answer: Software under development is considered and Intangible Asset and requires special accounting procedures. Since you cannot see it, touch it, stand on it or eat it, you have to rely on your team to produce timely and accurate documentation needed to track progress and productivity. The intangible nature of software causes problems for management in the following areas: y y y y Planning, Estimating, Scheduling and Budgeting for accounting purposes.

Ensuring that the software is delivered on scheduled and in accordance with the projects requirements. Project management is needed because software development is subject to problems in development, flexible budgets and schedule constraints. The software project managers job is to ensure that the software project meets these constraints on time and within projected investment calculations.

Reasons behind the above written problems: From an accounting view which I see as the biggest obstacle, intangible assets have special guidelines for capitalization. Computer software is the most common type of an internally generated intangible asset. It can be purchased or licensed from a 3rd party and then modified it is still considered internally generated and reclassified as an intangible asset. The cost of internally generated intangibles, such as computer software, must be capitalized or expensed depending on three project stages: 1) Preliminary project stage -formulation and evaluation of alternatives, determining the existence of the needed technology. 2) Application development design includes coding, installation to hardware, testing, and parallel processing. 3) Post-implementation stage includes application training and software maintenance. Stages 1 and 3 are expensed, while stage 2 is capitalized. Generally, you have not reached stage 2 until you have executive management support for the project along with a commitment of funding and personnel. Determining what stage you are in can be difficult for large projects. Large projects might need to be broken down into multiple modules which are capitalized separately. The people involved in designing a software project are its greatest assets. They represent intellectual capital and its up to the software project manager to get best out of their investment in people. This is achieved when people are respected by their company and given a level of responsibility and reward that matches their skills. Software Project management is about regulating and managing phases of development done by others on a product that you can't see, smell, touch or eat and you can't even demonstrate it until it's almost finished. A close working relationship and constant communication with the people you are relying on to get the job completed are your greatest tools. Part-B Q.4. Why do we need to do feasibility study before starting the project and how can we say that a project is feasible or not? Answer: Feasibility Study: A Project Feasibility Study is an exercise that involves documenting each of the potential solutions to a particular business problem or opportunity. Feasibility Studies can be undertaken by any type of business, project or team and they are a critical part of the Project Life Cycle. When to use a Feasibility Study: The purpose of a Feasibility Study is to identify the likelihood of one or more solutions meeting the stated business requirements. In other words, if you are unsure whether your solution will deliver the outcome you want, then a Project Feasibility Study

will help gain that clarity. During the Feasibility Study, a variety of 'assessment' methods are undertaken. The outcome of the Feasibility Study is a confirmed solution for implementation. Why to do feasibility study: We need to do feasibility study to:
y y y y y y y

Research the business problem or opportunity Document the business requirements for a solution Identify all of the alternative solutions available Review each solution to determine its feasibility List any risks and issues with each solution Choose a preferred solution for implementation Document the results in a feasibility report

Is your project feasible or not: The best way to find out whether your project is feasible is to complete a Feasibility Study. This process helps you gain confidence that the solution you need to build can be implemented on time and under budget. So here's how to do it in 5 simple steps. Completing a Feasibility Study: A Feasibility Study needs to be completed as early in the Project Life Cycle as possible. The best time to complete it is when you have identified a range of different alternative solutions and you need to know which solution is the most feasible to implement. Here's how to do it. Step 1: Research the Business Drivers In most cases, your project is being driven by a problem in the business. These problems are called "business drivers" and you need to have a clear understanding of what they are, as part of your Feasibility Study. For instance, the business driver might be that an IT system is outdated and is causing customer complaints, or that two businesses need to merge because of an acquisition. Regardless of the business driver, you need to get to the bottom of it so you fully understand the reasons why the project has been kicked off. Find out why the business driver is important to the business, and why it's critical that the project delivers a solution to it within a specified timeframe. Then find out what the impact will be to the business, if the project slips. Step 2: Confirm the Alternative Solutions Now you have a clear understanding of the business problem that the project addresses, you need to understand the alternative solutions available. If it's an IT system that is outdated, then your alternative solutions might include redeveloping

the existing system, replacing it or merging it with another system. Only with a clear understanding of the alternative solutions to the business problem, can you progress with the Feasibility Study. Step 3: Determine the Feasibility You now need to identify the feasibility of each solution. The question to ask of each alternative solution is "can we deliver it on time and under budget?" To answer this question, you need to use a variety of methods to assess the feasibility of each solution. Here are some examples of ways you can assess feasibility:
y y y

Research: Perform online research to see if other companies have implemented the same solutions and how they got on. Prototyping: Identify the part of the solution that has the highest risk, and then build a sample of it to see if it's possible to create. Time-boxing: Complete some of the tasks in your project plan and measure how long it took vs. planned. If you delivered it on time, then you know that your planning is quite accurate.

Step 4: Choose a Preferred Solution With the feasibility of each alternative solution known, the next step is to select a preferred solution to be delivered by your project. Choose the solution that; is most feasible to implement, has the lowest risk, and you have the highest confidence of delivering. You've now chosen a solution to a known business problem, and you have a high degree of confidence that you can deliver that solution on time and under budget, as part of the project. Step 5: Reassess at a lower level It's now time to take your chosen solution and reassess its feasibility at a lower level. List all of the tasks that are needed to complete the solution. Then run those tasks by your team to see how long they think it will take to complete them. Add all of the tasks and timeframes to a project plan to see if you can do it all within the project deadline. Then ask your team to identify the highest risk tasks and get them to investigate them further to check that they are achievable. Use the techniques in Step 3 to give you a very high degree of confidence that it's practically achievable. Then document all of the results in a Feasibility Study report. After completing these 5 steps, get your Feasibility Study approved by your manager so that everyone in the project team has a high degree of confidence that the project can deliver successfully. These five steps will determine whether the project is feasible or not.

Q.5.What is the importance of a manager in a project and what are the responsibilities of project managers. Answer: Skilled project manager professionals (PMPs) are important to businesses when implementing complex, project-based processes executed by teams. These skills are increasingly important in a variety of industries. Even in a down economy PMPs are in demand. Project Managers have their importance in the following areas: Business The PMP's role varies from assignment to assignment and across industries, but at the core, project management requires balancing a timeframe, budget and scope as the team works to meet its objectives. Project managers oversee the individual tasks that move a project toward completion, so the ultimate success or failure depends, in large part, on the PMP's competency. In companies where jobs are frequently late, over budget or fail to meet their objectives, hiring a skilled PMP can improve productivity and morale - and can often lead to greater profitability. Role of Project Manager: Generally, a PMP's responsibilities focus on maintaining the goals. This can include working with a variety of people, from C-level executives to hourly support staff, understanding the basics of several software options and being aware of the challenges that may arise. A project manager must define goals. After defining the goals, resources must be accounted for and a timeline must be created. Next, the PMP assigns teams to perform the tasks. Project managers provide much-needed direction to ensure that at every phase of the project, each contributor knows what's expected. Project managers communicate with upper management, outside vendors and clients, as needed. Proactive communication is one of the most important functions. Definition Defining the job is crucial to its success. Before launch, the PMP communicates these definitions and goals to stakeholders to obtain agreement and support. All resources, risks and benefits are identified, and contingency plans are outlined. The plan, budget and schedule are based on available resources, deliverables, and company or client priorities. PMPs typically use professional software packages in the complex planning and monitoring stages. Network diagrams illustrate the job's critical paths to completion.

PMPs monitor each stage, analyzing progress and communicating to upper management and others involved, including sub-contractors in external organizations. As goals change or unexpected risks arise, the plan is amended to reflect scheduling, budget and other modifications. Motivation Good managers provide the motivation team members need to help bring a job to successful completion. Leadership Teams need strong leaders. The most successful leaders are decisive, inspiring, and personable. When these essential skills are lacking, morale and productivity can drop, along with sales and profits. Few companies can fulfill sales and profit goals, efficiency and productivity objectives, and shareholder expectations without skilled managers. Excellent leadership can result in higher morale, a greater sense of ownership and professionalism among team members, and increased productivity and profitability. Advantages to have a Project Manager for any project: * Good managers use established processes to proactively deal with the surprises and challenges as they arise. * Poor management can create stress among project contributors and lead to higher turnover. * Most people are happier working on productive teams with good communication and clearlydefined goals. When team members see a competent leader handling each crisis, it can be inspiring and motivating. Workers who know that clear direction and communication will be part of their job every day more likely to perform at their best. Responsibilities of project managers: * The Project Manager is the person responsible for managing the project. * The Project Manager is the person responsible for accomplishing the project objectives within the constraints of the project. He is responsible for the outcome (success or failure) of the project. * The Project Manager is involved with the planning, controlling and monitoring, and also managing and directing the assigned project resources to best meet project objectives.

* The Project Manager Controls and monitors triple constraintsproject scope, time and cost (quality also)in managing competing project requirements. * The Project Manager examines the organizational culture and determines whether project management is recognized as a valid role with accountability and authority for managing the project. * The Project Manager collects metrics data (such as baseline, actual values for costs, schedule, work in progress, and work completed) & reports on project progress and other project specific information to stakeholders. * The Project Manager is responsible for identifying, monitoring, and responding to risk. * The Project Manager is responsible to the project stakeholders for delivering a projects objectives within scope, schedule, cost, and quality. * The reporting structure of Project Manager Changes depends on organizational structure. He may reports to a Functional Manager or to a Program Manager. In a bit exaggerating terms, Project Manager is the God of his project and he is the one who decides the success of the project. Q 6.Using examples discuss why it is important for a software project management to produce an overall description of system architecture at an early stage in the system specification. Answer: When building a house, the architect, the general contractor, the electrician, the plumber, the interior designer, and the landscaper all have different views of the structure. Although these views are pictured differently, all are inherently related: together, they describe the buildings architecture. The same is true with software architecture. Architectural design basically establishes the overall structure of a software system. The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design. The output of this design process is a description of the software architecture. Importance for a software project management to produce an overall description of system architecture at an early stage in the system specification: There are three reasons for this: 1. Mutual communication. Software architecture represents a common high-level abstraction of the system that most, if not all, of the systems stakeholders can use as a

basis for creating mutual understanding, forming consensus, and communicating with each other. 2. Each stakeholder of a software system (customer, user, project manager, coder, tester, and so on) is concerned with different characteristics of the system that are affected by its architecture. Architecture provides a common language in which different concerns can be expressed, negotiated, and resolved at a level that is intellectually manageable, even for large, complex systems. Without such language, it is difficult to understand large systems sufficiently to make the early decisions that influence both quality and usefulness. 3. Early design decisions. Software architecture represents the embodiment of the earliest set of design decisions about a system, and these early bindings carry weight far out of proportion to their individual gravity with respect to the systems remaining development, its service in deployment, and its maintenance life. It is also the earliest point at which the system to be built can be analyzed. An implementation exhibits architecture if it conforms to the structural design decisions described by the architecture. This means that the implementation must be divided into the prescribed components, the components must interact with each other in the prescribed fashion, and each component must fulfill its responsibility to the other components dictated by the architecture. Resource allocation decisions also constrain implementation. These decisions may be invisible to implementers working on individual components. The constraints permit a separation of concerns that allows management decisions that make best use of personnel and computational capacity. Component builders must be fluent in the specification of their individual components but not in architectural trade-offs. Conversely, the architects need not be experts in all aspects of algorithm design or the intricacies of the programming language, but they are the ones responsible for architectural trade-offs. Not only does architecture prescribe the structure of the system being developed, but it also engraves that structure on the structure of the development project. The normal method of dividing up the labor in a large system is to assign different portions of the system to different groups to construct. This is called the work breakdown structure of a system. Because the system architecture includes the highest level decomposition of the system, it is typically used as the basis for the work breakdown structure. Specifically, the module structure is most often the basis for work assignments. The work breakdown structure, in turn, dictates units of planning, scheduling, and budget, as well as inter-team communications channels, configuration control and file system organization, integration and test plans and procedures. Teams communicate with each other in terms of the interface specifications to the major components. The maintenance activity, when launched, will also reflect the software structure, with teams formed to maintain specific structural components.

A side effect of establishing the work breakdown structure is to effectively freeze the software architecture, at least at the level reflected in the work breakdown. A group that is responsible for one of the subsystems will resist having its responsibilities distributed across other groups. If these responsibilities have been formalized in a contractual relationship, changing responsibilities could become expensive. Tracking progress on a collection of tasks that is being distributed would also become much more difficult. Thus, once the architectures module structure has been agreed on, it becomes almost impossible for managerial and business reasons to modify it. This is one argument (among many) for carrying out extensive analysis before freezing the software architecture for a large system.