Software Engineering-II
description
Transcript of Software Engineering-II
Software Engineering-II
Software Project Management
1
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
2
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
DefinitionA 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.
3
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
4
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.
Flexibilitythe ease with which software can accommodate
changes.
5
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
6
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 organizingstaffing directingcontrolling
7
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
Staffingselecting 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
8
Project Management!!Project management is a system of
management procedures, practices, technologies, skills, and experience that are necessary to successfully manage a project.
9
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
10
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.
11
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
12
Project Management Disadvantages Greater organizational complexity More violations of company policy Lower personnel utilization More managerial conflicts
13
Management Spectrum Effective software project management
focuses on the four P’s
People Product Process Project
14
People Software process is populated by players
who can be categorized into followings:
1. Senior Managers2. Project Managers3. Practitioners 4. Customers 5. End-users
15
The Project TeamThe 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
16
The project team developmentSome important tools and techniques for
team development
Training Team Building Reward and Recognition Systems
17
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
18
Five- stages in Team development
19
Forming
Storming
Norming
Performing
Adjourning
level of functioning at various stages of team development
20
Project ManagerOnce the project is selected, the next step for the
senior management is to choose a Project Manager
ORWhen 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.
21
Project Manager’s RoleFacilitator (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.
CommunicatorPM 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.
22
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.
23
Project Manager’s - Responsibilities
To the Organization Conservation of resources• Timely and accurate communication of project’s
progress• Competent project managementTo the Project Team• Competent human resource managementTo the Client• Acceptable delivery of project’s product• Timely and accurate communication of project’s
progress
24
PM’s - Responsibilities (cont.)To the Project• acquisition of resources and personnel• dealing with obstacles arising during the courseof the project• exercising the leadership needed to bring theproject to a successful conclusion• trade-offs between budget, schedule, andspecifications to ensure successful completion ofthe project
25
Project Manager’s CharacteristicsTechnical skillsSupply of large and small technical solutionsPolitical sensitivityMuch of Project Management involves politics
and power
Solution orientedGoal orientedResults rather than activity focusedOpenness through high self-esteemNo hiding errors, No witch hunts, No shooting
the managers
26
Selecting a Project ManagerThe 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
27
CredibilityTechnical CredibilityA Reasonable understanding of the base technologies theproject requiresThe 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
ManagementAdministrative credibility A complete understanding of project management processes Strong, consistent decision making based on mature,
knowledgeable judgment
28
SensitivityPolitical 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 SensitivityDetecting when technical experts are not telling everything• Covering up their own failures• Hiding doubts
29
LeadershipDef: Interpersonal influence, exercised in situations anddirected through the communication process, towards
the attainment of a specified goal. Leadership qualities
Personal charismaEnthusiasm, 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
30
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
31
Effective and Ineffective PMs
32
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
33
Code of ethics for software engineerSoftware Engineers shall1. act consistently with the public interest2. act in a manner that is in the best interest of their client and
employer3. ensure that their products and related modifications meet the
highestprofessional standards possible4. maintain integrity and independence in their professional judgement5. subscribe to and promote an ethical approach to the management
ofsoftware development and maintenance6. advance the integrity and reputation of the profession consistent
withpublic interest7. be fair and supportive of their colleagues8. participate in lifelong learning regarding the practice of their
profession
34
Past vs Future Management
Management in Past Future Management Direction 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
35
Management in Past Future Management
Do it yourself Ask for help Play safe Take risk and
initiativeCrises management Prevention and
contingency Planning Adhoc decision Planned decision Top down Top down & bottom
upManagement competitive Collaborative and
cross functioning
36
Coordination and Communication issuesKraul 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
37
Product Description Composition Format Relevant standards Quality criteria
38
What to produce!!!!!A product breakdown structure (PBS)
39
ProjectTen 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
40
The project team lacks people with appropriate skills
Managers avoid best practices and lessons learned
Five-part commonsense approach to software projects:
1. Start on the right foot2. Maintain Momentum3. Track Progress4. Make smart decisions 5. Conduct a postmortem analysis(*ASG)
41
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?
42
Risk Management
43
45
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)
Risk Management- Definition
48
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
Our Concern
49
Risk Categories
Software Risk
• Project Risks (budgetary, schedule, personnel, resource, customer)
• Technical Risks (design, implementation, interfacing, verification)
• Business Risks (market, strategic, management,budget)
Charette: • Known risks • Predictable• Unpredictable
50
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?
51
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?
52
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?
53
Risk Identification
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?
ProcessIssues:
Tech- nical Issues:
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?
54
Risk Identification Development Environment Risks: Is a software project/process management tool available? Are tools for analysis and design available?? Are testing tools available and appropriate for the
product? Are all SW tools integrated with one another? Have members of the project team received training in
each of the tools? Risk Associated with Staff Size and Experience:
Are the best people available? Do the people have the right combination of skills? Are staff committed for entire duration of the project? Do staff have the right expectations about the job at hand? Will turnover among staff be low enough to allow continuity?
55
Risk Identification Risk Components and Drivers (U.S. Air Force guidelines)
Performance risk: the degree of uncertainty that the product will meet its requirements and be fit for its intended use
Cost risk: the degree of uncertainty that the project budget will be maintained
Support risk:the degree of uncertainty that the software will be easy to correct, adapt, and enhance
Schedule risk: the degree of uncertainty that the project schedule will be maintained
57
Risk Projection Also called risk estimation, attempts to rate each risk in two ways: Likelihood (probability) Consequences
Develop a risk table: A risk table provides a project manager with a simple technique for risk projection
For each identified risk, list likelihood, consequence and impact
Risk Assessment: Examine the accuracy of the estimates that were made during risk projection. A risk referent level must be defined and the referent point or break point should be established
58
Risk ProjectionRisks Category Probability Impact RMMMSize estimate may be significantly low PS 60% 2Larger number of users than planned PS 30% 3Less reuse than planned PS 70% 2End users resist system BU 40% 3Delivery deadline will be tightened BU 50% 2Funding will be lost CU 40% 1Customer will change requirements PS 80% 2Technology will not meet expectations TE 30% 1Lack of training on tools DE 80% 2Staff inexperienced ST 30% 2Staff turnover will be high ST 60% 2...
59
Risk Matrix
Consequences1 2 3 4 5
LIkelIhood
5
4
3
2
1
60Risk Mitigation, Monitoring, and Management An effective strategy must consider three issues:
risk avoidance, risk monitoring, and risk management and contingency planning.
A proactive approach to risk avoidance is the best strategy. Develop a plan for risk mitigation. For example: assume that high staff turnover is noted as a project risk r1, some of the possible steps to be taken are these: meet with current staff to determine causes for turnover assume turnover will occur and develop techniques to ensure
continuity when people leave. define a backup staff member for every critical technologies.
61
Risk Mitigation, Monitoring, and Management
As the project proceeds, the following factors can be monitored: general attitude of team members based on project
pressures, the degree to which the team has jelled, interpersonal relationship among team members, availability of jobs within the company and outside it
In addition of these factors, the project manager should monitor the effectiveness of risk mitigation steps.
Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become reality.
62
Safety Risks and Hazards Software safety and hazard analysis are software quality
assurance activities that focus on the identification and assessment of potential hazard that may impact software negatively and cause an entire system to fail.
If hazards can be identified early in the software engineering process, software design features can be specified that will either eliminate or control potential hazards.
66
SEI Software Development Risk
67
Summary Risk analysis is an important part of most software projects.
Risk analysis requires a significant amount of project planning effort.
Understanding risk helps you know where to commit your resources.
If you don’t actively attack the risks, they will actively attack you.
Major projects should all have a risk management plan..
Questions
68