Software Engineering: A Practitioner's Approach, 6/e
-
Upload
basit-qamar -
Category
Documents
-
view
230 -
download
0
Transcript of Software Engineering: A Practitioner's Approach, 6/e
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
1/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005
Supplementary Slides forSupplementary Slides for
Software Engineering:Software Engineering:A Practitioner's Approach,A Practitioner's Approach,
6/e6/ePart 4Part 4copyright 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use OnlyMay be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's ApproachAny other reproduction or use is expressly prohibited.
This presentation, slides, or hardcopy may NOT be used forshort courses, industry seminars, or consulting purposes.
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
2/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005
Software Engineering: A Practitioners Approach,Software Engineering: A Practitioners Approach,
6/e6/e
Chapter 21Chapter 21
Project Management ConceptsProject Management Concepts
copyright 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.Any other reproduction or use is expressly prohibited.
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
3/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005
The 4 PsThe 4 Ps
PeoplePeople the most important element of a the most important element of asuccessful projectsuccessful project
ProductProduct the software to be built the software to be built ProcessProcess the set of framework activities and the set of framework activities and
software engineering tasks to get the job donesoftware engineering tasks to get the job done ProjectProject all work required to make the product a all work required to make the product a
realityreality
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
4/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005
StakeholdersStakeholders
Senior managersSenior managers who define the business issues that often have significant influence onwho define the business issues that often have significant influence onthe project.the project.
Project (technical) managersProject (technical) managerswho must plan, motivate, organize, and control thewho must plan, motivate, organize, and control thepractitioners who do software work.practitioners who do software work.
PractitionersPractitioners who deliver the technical skills that are necessary to engineer a productwho deliver the technical skills that are necessary to engineer a productor application.or application.
CustomersCustomers who specify the requirements for the software to be engineered and otherwho specify the requirements for the software to be engineered and otherstakeholders who have a peripheral interest in the outcome.stakeholders who have a peripheral interest in the outcome.
End-usersEnd-users who interact with the software once it is released for production use.who interact with the software once it is released for production use.
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
5/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005
Software TeamsSoftware Teams
How to lead?How to organize?
How to motivate?
How to collaborate?
How to create good ideas?
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
6/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005
Team LeaderTeam Leader
The MOI ModelThe MOI Model Motivation.Motivation. The ability to encourage (by push or pull)The ability to encourage (by push or pull)
technical people to produce to their best ability.technical people to produce to their best ability. Organization.Organization. The ability to mold existing processes (or inventThe ability to mold existing processes (or invent
new ones) that will enable the initial concept to be translatednew ones) that will enable the initial concept to be translatedinto a final product.into a final product.
Ideas or innovation.Ideas or innovation. The ability to encourage people to createThe ability to encourage people to createand feel creative even when they must work within boundsand feel creative even when they must work within boundsestablished for a particular software product or application.established for a particular software product or application.
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
7/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005
Software TeamsSoftware Teams
the difficulty of the problem to be solvedthe difficulty of the problem to be solved the size of the resultant program(s) in lines of code or function pointsthe size of the resultant program(s) in lines of code or function points the time that the team will stay together (team lifetime)the time that the team will stay together (team lifetime) the degree to which the problem can be modularizedthe degree to which the problem can be modularized
the required quality and reliability of the system to be builtthe required quality and reliability of the system to be built
the rigidity of the delivery datethe rigidity of the delivery date the degree of sociability (communication) required for the projectthe degree of sociability (communication) required for the project
The following factors must be considered when selecting aThe following factors must be considered when selecting asoftware project team structure ...software project team structure ...
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
8/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005
closed paradigmclosed paradigmstructures a team along a traditional hierarchy ofstructures a team along a traditional hierarchy ofauthorityauthority
random paradigmrandom paradigmstructures a team loosely and depends on individualstructures a team loosely and depends on individualinitiative of the team membersinitiative of the team members
open paradigmopen paradigmattempts to structure a team in a manner that achievesattempts to structure a team in a manner that achieves
some of the controls associated with the closed paradigm but also much ofsome of the controls associated with the closed paradigm but also much ofthe innovation that occurs when using the random paradigmthe innovation that occurs when using the random paradigm synchronous paradigmsynchronous paradigmrelies on the natural compartmentalization of arelies on the natural compartmentalization of a
problem and organizes team members to work on pieces of the problemproblem and organizes team members to work on pieces of the problemwith little active communication among themselveswith little active communication among themselves
Organizational ParadigmsOrganizational Paradigms
suggested by Constantine [CON93]
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
9/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005
Avoid Team ToxicityAvoid Team Toxicity
A frenzied work atmosphere in which team members waste energy and losefocus on the objectives of the work to be performed.
High frustration caused by personal, business, or technological factors thatcause friction among team members.
Fragmented or poorly coordinated procedures or a poorly defined orimproperly chosen process model that becomes a roadblock toaccomplishment.
Unclear definition of roles resulting in a lack of accountability and resultantfinger-pointing.
Continuous and repeated exposure to failure that leads to a loss ofconfidence and a lowering of morale.
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
10/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1
Agile TeamsAgile Teams
Team members must have trust in one another.Team members must have trust in one another. The distribution of skills must be appropriate to theThe distribution of skills must be appropriate to the
problem.problem. Mavericks may have to be excluded from the team, ifMavericks may have to be excluded from the team, if
team cohesiveness is to be maintained.team cohesiveness is to be maintained. Team is self-organizingTeam is self-organizing
An adaptive team structureAn adaptive team structure Uses elements of Constantines random, open, and synchronousUses elements of Constantines random, open, and synchronous
paradigmsparadigms Significant autonomySignificant autonomy
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
11/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1
Team Coordination & CommunicationTeam Coordination & Communication
Formal, impersonal approachesFormal, impersonal approaches include software engineering documents and workinclude software engineering documents and workproducts (including source code), technical memos, project milestones, schedules,products (including source code), technical memos, project milestones, schedules,and project control tools (Chapter 23), change requests and relatedand project control tools (Chapter 23), change requests and relateddocumentation, error tracking reports, and repository data (see Chapter 26).documentation, error tracking reports, and repository data (see Chapter 26).
Formal, interpersonal proceduresFormal, interpersonal procedures focus on quality assurance activities (Chapter 25)focus on quality assurance activities (Chapter 25)applied to software engineering work products. These include status reviewapplied to software engineering work products. These include status reviewmeetings and design and code inspections.meetings and design and code inspections.
Informal, interpersonal proceduresInformal, interpersonal procedures include group meetings for informationinclude group meetings for informationdissemination and problem solving and collocation of requirements anddissemination and problem solving and collocation of requirements anddevelopment staff.development staff.
Electronic communicationElectronic communication encompasses electronic mail, electronic bulletin boards,encompasses electronic mail, electronic bulletin boards,and by extension, video-based conferencing systems.and by extension, video-based conferencing systems.
Interpersonal networkingInterpersonal networking includes informal discussions with team members andincludes informal discussions with team members andthose outside the project who may have experience or insight that can assist teamthose outside the project who may have experience or insight that can assist team
members.members.
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
12/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1
The Product ScopeThe Product Scope
ScopeScope Context. How does the software to be built fit into a larger system,
product, or business context and what constraints are imposed as aresult of the context?
Information objectives. What customer-visible data objects
(Chapter 8) are produced as output from the software? What dataobjects are required for input?
Function and performance. What function does the softwareperform to transform input data into output? Are any specialperformance characteristics to be addressed?
Software project scope must be unambiguous andunderstandable at the management and technical levels.
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
13/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1
Problem DecompositionProblem Decomposition
Sometimes calledpartitioning orproblem elaboration Once scope is defined
It is decomposed into constituent functions It is decomposed into user-visible data objects
or It is decomposed into a set of problem classes
Decomposition process continues until all functions orproblem classes have been defined
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
14/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1
The Process
Once a process framework has been establishedOnce a process framework has been established Consider project characteristicsConsider project characteristics Determine the degree of rigor requiredDetermine the degree of rigor required Define a task set for each software engineering activityDefine a task set for each software engineering activity
Task set =Task set = Software engineering tasksSoftware engineering tasks Work productsWork products Quality assurance pointsQuality assurance points MilestonesMilestones
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
15/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1
Melding the Problem and the Process
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
16/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1
The Project
Projects get into trouble when Projects get into trouble when Software people dont understand their customers needs.Software people dont understand their customers needs. The product scope is poorly defined.The product scope is poorly defined. Changes are managed poorly.Changes are managed poorly. The chosen technology changes.The chosen technology changes. Business needs change [or are ill-defined].Business needs change [or are ill-defined]. Deadlines are unrealistic.Deadlines are unrealistic. Users are resistant.Users are resistant. Sponsorship is lost [or was never properly obtained].Sponsorship is lost [or was never properly obtained]. The project team lacks people with appropriate skills.The project team lacks people with appropriate skills. Managers [and practitioners] avoid best practices and lessons learned.Managers [and practitioners] avoid best practices and lessons learned.
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
17/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1
Common-Sense Approach to Projects
Start on the right foot.Start on the right foot. This is accomplished by working hard (very hard) toThis is accomplished by working hard (very hard) tounderstand the problem that is to be solved and then setting realisticunderstand the problem that is to be solved and then setting realisticobjectives and expectations.objectives and expectations.
Maintain momentum.Maintain momentum. TheThe project manager must provide incentives to keepproject manager must provide incentives to keepturnover of personnel to an absolute minimum, the team should emphasizeturnover of personnel to an absolute minimum, the team should emphasizequality in every task it performs, and senior management should doquality in every task it performs, and senior management should doeverything possible to stay out of the teams way.everything possible to stay out of the teams way.
Track progress.Track progress. For a software project, progress is tracked as work productsFor a software project, progress is tracked as work products(e.g., models, source code, sets of test cases) are produced and approved(e.g., models, source code, sets of test cases) are produced and approved(using formal technical reviews) as part of a quality assurance activity.(using formal technical reviews) as part of a quality assurance activity.
Make smart decisions.Make smart decisions. In essence, the decisions of the project manager andIn essence, the decisions of the project manager andthe software team should be to keep it simple.the software team should be to keep it simple.
Conduct a postmortem analysis.Conduct a postmortem analysis. Establish a consistent mechanism forEstablish a consistent mechanism forextracting lessons learned for each project.extracting lessons learned for each project.
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
18/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1
To Get to the Essence of a ProjectTo Get to the Essence of a Project
Why is the system being developed?Why is the system being developed? What will be done?What will be done? When will it be accomplished?When will it be accomplished? Who is responsible?Who is responsible? Where are they organizationally located?Where are they organizationally located? How will the job be done technically andHow will the job be done technically and
managerially?managerially? How much of each resource (e.g., people,How much of each resource (e.g., people,
software, tools, database) will be needed?software, tools, database) will be needed?
Barry Boehm
-
8/14/2019 SoftwareEngineering: APractitioner'sApproach, 6/e
19/19
These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e andare provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1
Critical PracticesCritical Practices
Formal risk managementFormal risk management Empirical cost and schedule estimationEmpirical cost and schedule estimation Metrics-based project managementMetrics-based project management Earned value trackingEarned value tracking
Defect tracking against quality targetsDefect tracking against quality targets
People aware project managementPeople aware project management