Software Engineering-II

1. Software Engineering-II Software Project Management

2. Software Project Management!!! • IT Projects have a terrible track record • A 1995 Standish Group Study found that only 16.2% of IT projects were successful • Over 31% of It projects were cancelled before completion, costing over $81bn in the U.S. alone

3. What is Project? Project is a planned activity. Being planned it assumes that we can determine how we are going to carry out a task before we start. • Develop a web page within the next four days that provides information about the departmental time table to new incoming students Definition A project is a specific(non-routine), finite task to be accomplished. It carried out in several phases and the resources available are constrained. Any activity that results in a deliverable or a product. Projects always begin with a problem. The projects is to provide the solution to this problem. When a project is finished it must be evaluated to determine whether it satisfies the objectives and goals.

4. A project is temporary endeavor undertaken to accomplish a unique purpose. • Attributes of a project • Unique purpose (specified product is to be created) • Temporary (non-routine) • Planning is required • Require resources, often from various areas • Carried out in several phases • Involve uncertainty • Project is large or complex

5. Software Projects vs. Other Types of Projects • Invisibility with software progress is not immediately visible • Complexity per dollar software products contain more complexity • Conformity software developers have to conform to the requirements of clients. • Flexibility the ease with which software can accommodate changes.

6. Definition • SCOPE: what is the project trying to accomplish? what work must be done to satisfy the customer that deliverables meets the requirements. • TIME: How long should it take to complete the project? what is the project’s schedule? • COST: what should it cost to complete the project? The objective of any project is to complete the scope within the budget by a certain time to the customer’s satisfaction

7. What is Management? Management can be defined as all activities and tasks undertaken by one or more persons for the purpose of planning and controlling the activities of others in order to achieve objectives or complete an activity that could not be achieved by other acting independently. Management functions can be categorized as planning organizing staffing directing controlling

8. Management functions • Planning predetermining a course of action for accomplishing projects objectives • Organising arranging the relationship among work units for accomplishment of objectives and the granting of responsibility and authority to attain those objectives • Staffing selecting and training people for completing tasks • Directing creating an atmosphere that will assist and motivate people to achieve desired end result • Controlling establishing, measuring, and evaluating performance of activities towards planned objectives

9. Project Management!! Project management is a system of management procedures, practices, technologies, skills, and experience that are necessary to successfully manage a project.

10. Laws of Project Management • No major project is ever installed on time, within budget, with the same staff that started it. Yours will not be the first • Projects progress quickly until they become 90% complete, then they remain at 90% complete forever. • One advantage of fuzzy project objectives is that they let you avoid the embarrassment of estimating the corresponding costs. • When things are going well, something will go wrong. • When things just can’t get any worse, they will • When things appears to be going better you have overlooked something

11. Continue…. • If project content is allowed to change freely, the rate of change will exceed the rate of progress. • No system is ever completely debugged: attempts to debug a system inevitably introduce new bugs that even harder to find • A carelessly planned project will take three times longer to complete than expected, a planned project will take twice as long.

12. Project Management Advantages • Responsiveness to clients and the environment • Ability to make timely trade-off decisions • Central focus of decisions to insure overall project optimality • Better control, better customer relations, shorter development time, lower costs, higher quality and reliability, higher profit margins, sharper orientation towards results, better co-ordination, higher morale • Bosses, customers, and other stakeholders do not like surprises. Good project management provides assurance and reduce risk • Project management provides the tools and environment to plan, to monitor, to track, and to manage schedules, resources, cost, and quality

13. Project Management Disadvantages • Greater organizational complexity • More violations of company policy • Lower personnel utilization • More managerial conflicts

14. Management Spectrum Effective software project management focuses on the four P’s • People • Product • Process • Project

15. People Software process is populated by players who can be categorized into followings: • Senior Managers • Project Managers • Practitioners • Customers • End-users

16. The Project Team The Selection of team occurs early in the life cycle of a software development project. Common characteristics of effective team members • technically competent • Politically sensitive • Strong problem orientation • Strong goal orientation • High self –esteem

17. The project team development Some important tools and techniques for team development • Training • Team Building • Reward and Recognition Systems

18. Team Building A legendary sports manager once said “it’s easy to get the players. Getting them play together , that’s the hard part” Team building- developing a group of individuals to accomplish the project’s objectives- is an ongoing process. Team building helps to create an atmosphere of openness and trust. Members feel a sense of unity and a strong commitment to accomplish the project objectives

19. Five- stages in Team development Forming Storming Norming Performing Adjourning

20. level of functioning at various stages of team development

21. Project Manager Once the project is selected, the next step for the senior management is to choose a Project Manager OR When the team is formed, choose a leader It is the PM’s job to make sure that the project is properly planned, implemented and completed. It is the People - not the procedures and techniques - that are critical to accomplishing the project objectives.

22. Project Manager’s Role Facilitator (Virtual Project Manager) Many projects are international and team members may be geographically dispersed. Many projects may be carried out by different organizations at different location. Communicator PM is responsible to the project team, to senior management, to the client, to anyone else who may have a stake in the projects performance and outcome.

23. MOI model of leadership • Motivation • the ability to encourage technical ppl to produce to their best ability • Organization • the ability to mold existing processes that will enable the initial concept to be translated into a final product. • Ideas or innovation • the ability to encourage ppl to create and feel creative even when they must work with in bounds established for particular software product or application.

24. Project Manager’s - Responsibilities To the Organization • Conservation of resources • Timely and accurate communication of project’s progress • Competent project management To the Project Team • Competent human resource management To the Client • Acceptable delivery of project’s product • Timely and accurate communication of project’s progress

25. PM’s - Responsibilities (cont.) To the Project • acquisition of resources and personnel • dealing with obstacles arising during the course of the project • exercising the leadership needed to bring the project to a successful conclusion • trade-offs between budget, schedule, and specifications to ensure successful completion of the project

26. Project Manager’s Characteristics Technical skills § Supply of large and small technical solutions § Political sensitivity § Much of Project Management involves politics and power § Solution oriented § Goal oriented § Results rather than activity focused Openness through high self-esteem § No hiding errors, No witch hunts, No shooting the managers

27. Selecting a Project Manager The Best Project Manager is the one who can get the job done • In addition the individual should have & be perceived to have by stakeholders the following qualities • Credibility • Sensibility • Leadership • Stress-Resistance

28. Credibility Technical Credibility A Reasonable understanding of the base technologies the project requires The Aim is to • Interpret technical requirements of the client • Converse at a useful level with project team experts • To Be Able to Explain Technology to Senior Management Administrative credibility • A complete understanding of project management processes • Strong, consistent decision making based on mature, knowledgeable judgment

29. Sensitivity Political Sensitivity • External politics • Client, Senior Management, Functional Managers • Power base must be sufficient to get what you want • Internal politics • Detect and resolve conflicts between team members • Technical Sensitivity Detecting when technical experts are not telling everything • Covering up their own failures • Hiding doubts

30. Leadership Def: Interpersonal influence, exercised in situations and directed through the communication process, towards the attainment of a specified goal. • Leadership qualities • Personal charisma Enthusiasm, Optimism, Energy, Courage, Maturity • Ethical, Fair • Know • When to reward, when to punish • When to delegate , when to step in • When to communicate, when to remain silent • How to capitalize on people’s strengths and cover their weaknesses

31. Stress-Resistance • Causes (there are plenty of them) • Constant decision making • More responsibility than authority • Overwork • Failure to employ consistent project management processes – this is the PM’s fault • Constant change • Political hostility • Conflict • Satisfying several masters

32. Effective and Ineffective PMs

33. Project Manager vs Functional Manager • Project Manager • Generalist • Facilitator among specialists, indirect technical support • Employs holistic, systems approach • Decides how resources are obtained • What needs to be done and when it must be done • Functional Manager • Specialist in the area they manage • Direct technical supervisor, applies knowledge directly • Employs analytical approach • Decides how something will be done and who will do it • Decides what resources are required

34. Code of ethics for software engineer Software Engineers shall 1. act consistently with the public interest 2. act in a manner that is in the best interest of their client and employer 3. ensure that their products and related modifications meet the highest professional standards possible 4. maintain integrity and independence in their professional judgement 5. subscribe to and promote an ethical approach to the management of software development and maintenance 6. advance the integrity and reputation of the profession consistent with public interest 7. be fair and supportive of their colleagues 8. participate in lifelong learning regarding the practice of their profession

35. Past vs Future Management • Management in Past Future ManagementDirection Empower Manage Enable Bossing/dictatorship Coaching & apprising/collaboration Error hiding Error admitting To make profit To hold the customer giant steps Baby steps Worker supervision Mentoring and profit sharing

36. Management in Past Future Management Do it yourself Ask for help Play safe Take risk and initiative Crises management Prevention and contingency Planning Adhoc decisionPlanned decision Top downTop down & bottom up Management competitive Collaborative and cross functioning

37. Coordination and Communication issues Kraul and Streeter examine a collection of project coordination techniques that are categorize in following manner. • Formal, impersonal approaches • Formal, interpersonal procedures • Informal, interpersonal procedure • Electronic communication • Interpersonal networking

38. Product • Description • Composition • Format • Relevant standards • Quality criteria

39. What to produce!!!!! A product breakdown structure (PBS)

40. Project Ten signs that indicates that information system project is in jeopardy • Software people don’t understand their customer’s need • The product scope is poorly defined • Changes are managed poorly • The chosen technology changes • Business needs changes • Deadline are unrealistic • Users are resistant • Sponsorship is lost

41. The project team lacks people with appropriate skills • Managers avoid best practices and lessons learned Five-part commonsense approach to software projects: • Start on the right foot • Maintain Momentum • Track Progress • Make smart decisions • Conduct a postmortem analysis(*ASG)

42. The W5 HH principle Barry Boehm suggested w5HH principle • Why is the system being developed? • What will be done, by when? • Who is responsible for function? • Where are they organizationally located? • How will the job be done technically and managerially? • How much of each resource is needed?

43. Risk Management

44. Risk Management- Definition • Risk management is a process that is used extensively for various purposes • Recall earlier questions raised about safety, costs, etc. • According to “Webster’s Seventh New Collegiate Dictionary”, risk is defined as a: • “possibility of loss or injury” • “the chance of loss or the perils to the subject matter of an insurance contract” and • “the degree of probability of such loss.”(1)

45. Our Concern Risk Strategies • Reactive • Software team does nothing about risks until something goes wrong • “fire fighting mode” • At best, monitors the projects for likely risks • Proactive • Begins long before technical work is initiated • Identification of potential risks (studies of probability, impact and priorities) • Objective: AVOID RISK • Responds are in a controlled and effective manner

46. Risk Categories • Project Risks (budgetary, schedule, personnel, resource, customer) • Technical Risks (design, implementation, interfacing, verification) • Business Risks (market, strategic, management,budget) Software Risk • Charette: • Known risks • Predictable • Unpredictable

47. Risk Identification • Risk identification is a systematic attempt to specify threats to the project plan Generic Product-specific • Risk Item List Identify known and predictable risks • Product size • Business impact • Customer characteristics • Process definition • Development environment • Technology to be built • Staff size and experience What characteristics of this product may threaten our project plan?

48. Risk Identification • Product Size Risk : • Estimated size of the product in LOC or FP? • Percentage deviation in size of product from average for previous products? • Number of users/projected changes to the requirements for the product? • Amount of reused software? • Business Impact risks: • Effect of this product on the company revenue? • Visibility of this product to senior management? • Amount & quality of product documentation to be produced? • Governmental constraints on the construction of the product?

49. Risk Identification • Customer related risks: (needs, personalities, contradictions , associations) • Have you worked with the customer in the past? • Does the customer have a solid idea of what is required? • Will the customer agree to have meetings? • Is the customer technically sophisticated in the product area? • Does the customer understand the software process? • Technology Risks: • Is the technology to be built new to your organization? • Does the SW interface with new or unproven HW/SW? • Do requirements demand creation of new components ? • Do requirements impose excessive performance constraints?

50. Risk Identification • Are facilitated application specification techniques used to aid in communication between the • customer and developer ? • Are specific methods used for software analysis? • Do you use specific method for data and architectural design? • Are software tools used to support the software analysis and design? • Are tools used to create software prototypes? • Are quality/productivity metrics collected for all software projects? • Process Risks : (4) • Does senior management support a written policy statement that emphasizes a standard process for software development ? • Is there a written description of the software process to be used? • Is the software process used for other projects ? • Is configuration management used to maintain consistency among system/software requirements, design, code and test? • Is a procedure followed for tracking subcontractor performance? Process Issues: Tech- nical Issues: