Unit-I Conventional Software Management: The waterfall model, conventional software Management performance. Evolution of Software Economics: Software Economics, pragmatic software cost estimation. Improving Software Economics: Reducing Software product size, improving software processes, improving team effectiveness, improving automation, Achieving required quality, peer inspections. 10 Lectures Unit-II The old way and the new: The principles of conventional software Engineering, principles of modern software management, transitioning to an iterative process. Life cycle phases: Engineering and production stages, inception, Elaboration, construction, transition phases. Artifacts of the process: The artifact sets, Management artifacts, Engineering artifacts, programmatic artifacts. Model based software architectures: A Management perspective and technical perspective. 10 Lectures Unit-III Work Flows of the process: Software process workflows, Iteration workflows. Checkpoints of the process: Major mile stones, Minor Milestones, Periodic status assessments. Iterative Process Planning: Work breakdown structures, planning guidelines, cost and schedule estimating, Iteration planning process, Pragmatic planning. 10 Lectures Unit-IV Project Organizations and Responsibilities: Line-of-Business Organizations, Project Organizations, evolution of Organizations. Process Automation: Automation Building blocks, The Project Environment. 10 Lectures Unit-V Project Control and Process instrumentation: The seven core Metrics, Management indicators, quality indicators, life cycle expectations, pragmatic Software Metrics, Metrics automation. Tailoring the Process: Process discriminants. 10 Lectures Unit-VI Future Software Project Management: Modern Project Profiles, Next generation Software economics, modern process transitions. 10 Lectures

1. COURCES WE OFFER:
BSC(IT) FY,SY,TY
BSC(CS) FY,SY,TY
BSC(IT/CS) PROJECTS
MCA (ENTRANCE)
ENGG(IT/ELECTRONICS/EXTC)
ADDRESS: 302 PARANJPE UDYOG BHAVAN, NEAR KHANDELWAL SWEETS, THANE STATION,
THANE WEST.
TEL: 8097071144/55
STAY CONNECTED FOR MORE UPDATES AND STUDY NOTES
FACEBOOK : https://www.facebook.com/weittutorial
EMAIL: weit.tutorials@gmail.com
1
PHONE:8097071144/55

2. T.Y. B.SC.I.T.
PROJECT MANAGEMENT
UNIT I
2
WE-IT TUTORIALS ; PHNO:8097071144/55

3. THE WATERFALL MODEL
3
WE-IT TUTORIALS ;
PHNO:8097071144/55

4.  System requirements :- over all requirements, hardware
specifications, environment etc
 Software requirements :- functional requirements
 Analysis :- check whether it is feasible
 Design :- valid design which should be developed
 Coding :- development and monitoring
 Testing :- checking whether the software meets the requirements or not
 Operations :- includes implementation and maintenance
4
WE-IT TUTORIALS ;
PHNO:8097071144/55

5. CONVENTIONAL SOFTWARE MANAGEMENT
PERFORMANCE
SOFTWARE ECONOMICS
 SOFTWARE ECONOMICS can be abstracted into a function of five basic
parameters:
 size, process, personnel, environment, and required quality
1. The size of the end product (quantified in number of source instructions or
function points)
2. The process used to produce the end product
3. The capabilities of software engineering personnel
4. The environment, which is made up of the tools and techniques
5. The required quality of the product (its features, performance, reliability, and
adaptability)
 The relationships among these parameters and the estimated cost can be
written as follows:
Effort = (Personnel)(Environment)(Quality)(SizeProcess)
5
WE-IT TUTORIALS ;
PHNO:8097071144/55

6. PRAGMATIC SOFTWARE COST ESTIMATION
 Pragmatic (practical, realistic, sensible)
 A critical problem in software cost estimation is a lack of well-
documented case
 Some popular cost estimation model : COCOMO, CHECKPOINT,
ESTIMACS
 debates on software cost estimation models and tools:
1. Which cost estimation model to use
2. Whether to measure software size in source lines of code or
function points
3. What constitutes a good estimate
6
WE-IT TUTORIALS ;
PHNO:8097071144/55

7. IMPROVING SOFTWARE ECONOMICS
 Reducing the size or complexity of what needs to be developed
 Improving the development process
 Using more-skilled personnel and better teams (not necessarily the
same thing)
 Using better environments (tools to automate the process)
 Trading off or backing off on quality
7
WE-IT TUTORIALS ;
PHNO:8097071144/55

8. 8
WE-IT TUTORIALS ;
PHNO:8097071144/55

9. REDUCING SOFTWARE PRODUCT SIZE
 The most significant way to improve affordability and return on
investment
 Component-based development is introduced for reducing the "source"
language size
 Reuse (operating systems, dbms, networks etc)
 object-oriented technology (Unified Modeling Language, visual modeling
tools, architecture frameworks)
 automatic code production (CASE tools, visual modeling tools, GUI
builders)
 higher order programming languages are used (such as C++, Java,
Visual Basic and fourth generation languages)
9
WE-IT TUTORIALS ;
PHNO:8097071144/55

10. IMPROVING SOFTWARE PROCESSES
 Process is an overloaded term. For software-oriented organizations, there are
many processes and subprocesses. We use three distinct process perspectives.
 Metaprocess: an organization's policies, procedures and practices for pursuing
a software-intensive line of business. The focus of this process is on
organizational economics, long-term strategies and a software ROI.
 Macroprocess: a project's policies, procedures and practices for producing a
complete software product within certain cost, schedule and quality constraints.
The focus of the macroprocess is on creating an adequate instance of the
metaprocess for a specific set of constraints.
 Microprocess: a project team's policies, procedures and practices for achieving
an artifact of the software process. The focus of the microprocess is on
achieving an intermediate product baseline with adequate quality and adequate
functionality as economically and rapidly as practical.
10
WE-IT TUTORIALS ;
PHNO:8097071144/55

11. IMPROVING TEAM EFFECTIVENESS
Five staffing principles
1. The principle of top talent: Use better and fewer people
2. The principle of job matching: Fit the tasks to the skills and motivation
of the people available.
3. The principle of career progression: An organization does best in the
long run by helping its people to self-actualize.
4. The principle of team balance: Select people who will complement and
harmonize with one another.
5. The principle of phaseout: Keeping a misfit on the team doesn't
benefit anyone.
11
WE-IT TUTORIALS ;
PHNO:8097071144/55

12. IMPROVING AUTOMATION
 Related to The tools and environment used in the software process
 Planning tools, requirements management tools, visual modeling tools,
compilers, editors, debuggers, quality assurance analysis tools, test
tools, and user interfaces Generally allows improvements of 20% to
40% in effort
12
WE-IT TUTORIALS ;
PHNO:8097071144/55

13. ACHIEVING REQUIRED QUALITY
 Focusing on driving requirements and critical use cases early in the life
cycle, focusing on requirements completeness and traceability late in
the life cycle, and focusing throughout the life cycle on a balance
between requirements evolution, design evolution and plan evolution
 Using metrics and indicators to measure the progress and quality of an
architecture as it evolves from a high-level prototype into a fully
compliant product
 Providing integrated life-cycle environments that support early and
continuous configuration control, change management, rigorous design
methods, document automation and regression test automation
 Using visual modeling and higher level languages that support
architectural control, abstraction, reliable programming, reuse, and self-
documentation
 Early and continuous insight into performance issues through
demonstration-based evaluations
13
WE-IT TUTORIALS ;
PHNO:8097071144/55

14. PEER INSPECTIONS
 peer reviews are valuable as secondary mechanisms in certain cases
they provide a significant return.
 One value of inspections is in the professional development of a team.
 It is generally useful to have the products of junior team members
reviewed by senior mentors.
14
WE-IT TUTORIALS ;
PHNO:8097071144/55

15. UNIT II
The Old Way and the New Way
15
WE-IT TUTORIALS ;
PHNO:8097071144/55

16. THE OLD WAY AND THE NEW
16
WE-IT TUTORIALS ;
PHNO:8097071144/55

17. THE PRINCIPLES OF CONVENTIONAL SOFTWARE ENGINEERING
1. Make quality #1.
2. High-quality software is possible.
3. Give products to customers early.
4. Determine the problem before writing the requirements.
5. Evaluate design alternatives.
6. Use an appropriate process model.
7. Use different languages for different phases.
8. Minimize intellectual distance.
9. Put techniques before tools.
10. Get it right before you make it faster.
11. Inspect code.
12. Good management is more important than good technology.
13. People are the key to success.
14. Follow with care.
15. Take responsibility.
16. Understand the customer's priorities.
17. The more they see, the more they need.
18. Plan to throw one away.
19. Design for change.
20. Design without documentation is not design.
21. Use tools, but be realistic.
17
WE-IT TUTORIALS ;
PHNO:8097071144/55

18. THE PRINCIPLES OF MODERN SOFTWARE MANAGEMENT
 Base the process on an architecture-first approach.
 Establish an iterative life-cycle process that confronts risk early.
 Transition design methods to emphasize component-based
development.
 Establish a change management environment.
 Enhance change freedom through tools that support round-trip
engineering.
 Capture design artifacts in rigorous, model-based notation.
 Instrument the process for objective quality control and progress
assessment.
 Use a demonstration-based approach to assess intermediate artifacts.
 Plan intermediate releases in groups of usage scenarios with evolving
levels of detail.
 Establish a configurable process that is economically scalable.
18
WE-IT TUTORIALS ;
PHNO:8097071144/55

19. DIFFERENCE BETWEEN THE OLD WAY AND THE NEW WAY
19
WE-IT TUTORIALS ;
PHNO:8097071144/55

20. LIFE CYCLE PHASES
20
WE-IT TUTORIALS ;
PHNO:8097071144/55

21. ENGINEERING AND PRODUCTION STAGES
 The engineering stage, driven by less predictable but smaller teams doing
design and synthesis activities
 The production stage, driven by more predictable but larger teams doing
construction, test, and deployment activities
21
WE-IT TUTORIALS ;
PHNO:8097071144/55

22.  1. INCEPTION PHASE
 2. ELABORATION PHASE
 3. CONSTRUCTION PHASE
 4. TRANSITION PHASE
22
WE-IT TUTORIALS ;
PHNO:8097071144/55

23. INCEPTION PHASE
 The overriding goal is to achieve agreement among stakeholders on the
life-cycle objectives for the project.
 First phase
 Ad-hoc
 formalities
 Establishing the project's software scope
 Estimating the cost for the entire project
 Estimating the schedule for the entire project
 Estimating potential risks
23
WE-IT TUTORIALS ;
PHNO:8097071144/55

24. ELABORATION PHASE
 Considered as the most critical of the four phases
 At the end of this phase, the "engineering" is considered complete
 ensures that the architecture, requirements, and plans are stable
enough
 the risks sufficiently reduced
 the cost and schedule for the completion of the development can be
predicted within an acceptable range.
 executable architecture prototype is built
 Minimizing development costs by optimizing resources
 Achieving adequate quality as rapidly as practical
 Resource management, control, and process optimization
24
WE-IT TUTORIALS ;
PHNO:8097071144/55

25. CONSTRUCTION PHASE
 represents a production process
 emphasis is placed on managing resources and controlling operations
 Minimizing development costs by optimizing resources
 Achieving adequate quality as rapidly as practical
 Resource management, control and process optimization
25
WE-IT TUTORIALS ;
PHNO:8097071144/55

26. TRANSITION PHASE
 When project is to be deployed in the end user domain
 This phase could include any of the following activities:
1. Beta testing to validate the new system against user expectations
2. testing and parallel operation relative to a legacy system it is replacing
3. Conversion of operational databases
4. Training of users and maintainers
26
WE-IT TUTORIALS ;
PHNO:8097071144/55

27. MODEL BASED SOFTWARE
ARCHITECTURES
27
WE-IT TUTORIALS ;
PHNO:8097071144/55

28. MANAGEMENT PERSPECTIVE
 Describes the project from managements perspective
 From a management perspective, there are three different aspects of
an architecture:
 An architecture (design concept)
 An architecture baseline
 An architecture description
TECHNICAL PERSPECTIVE
 Software architecture encompasses the structure of software systems
 It displays the selection of elements and the composition of elements
into progressively larger subsystems
 their behavior (collaborations among elements)
28
WE-IT TUTORIALS ;
PHNO:8097071144/55

29. UNIT III
29
WE-IT TUTORIALS ;
PHNO:8097071144/55

30. WORKFLOWS OF THE
PROCESS
30
WE-IT TUTORIALS ;
PHNO:8097071144/55

31. SOFTWARE PROCESS WORKFLOW
31
WE-IT TUTORIALS ;
PHNO:8097071144/55

32. The term workflow is used to mean a thread of cohesive and mostly sequential
activities
 Management workflow: controlling the process and ensuring win
conditions for all stakeholders
 Environment workflow: automating the process and evolving the
maintenance environment
 Requirements workflow: analyzing the problem space and evolving the
requirements artifacts
 Design workflow: modeling the solution and evolving the architecture
and design artifacts
 Implementation workflow: programming the components and evolving
the implementation and deployment artifacts
 Assessment workflow: assessing the trends in process and product
quality
 Deployment workflow: transitioning the end products to the user
32
WE-IT TUTORIALS ;
PHNO:8097071144/55

33. 1. MANAGEMENT
 The workflow involves planning & controlling of the process so as to achieve
product & project’s goal.
 The purpose of the software project management is balancing the competing
objectives, managing risks & overcoming the constraints so as to deliver a
successful product which meets the needs of both customer & user.
 Active workers during this process:
 Project manager
 Project reviewer
33
WE-IT TUTORIALS ;
PHNO:8097071144/55

34. WORKS OF PROJECT MANAGER
 Initiate project
 Develop iteration plan
 Develop quality assurance plan
 Monitor project status
 Schedule & assign work
 Report status
 Handle exceptions & problems
34
WE-IT TUTORIALS ;
PHNO:8097071144/55

35. WORKS OF PROJECT REVIEWER
 Project approval review
 Project planning review
 Iteration plan review
 Iteration evaluation criteria review
35
WE-IT TUTORIALS ;
PHNO:8097071144/55

36. 2. DEVELOPMENT INFFRASTRUCTURE
 It defines the infrastructural requirements, installation platform &
change management.
 It provides the s/w development organization with the s/w development
environment – both process & tool – that are essential for the
development team.
 Active workers during this process:
 Process engineer
 s/w architect
 Tool specialist
36
WE-IT TUTORIALS ;
PHNO:8097071144/55

37. Works of Process Engineer:
 Development case
 Project specific templates
Works of S/W Architect:
 Design guidelines
 Programming guidelines
Works of Tool Specialist:
 Tool guidelines
 Tools
37
WE-IT TUTORIALS ;
PHNO:8097071144/55

38. 3. REQUIREMENTS (ANALYSIS)
 It involves analysis of the problem & determines the scope of the
project.
 It elicits the requirements for the project including their
identification, modeling & documentation.
 s/w requirement specification (SRS) describes what the system
should do & allows the developers & the customer to agree on
description.
 Goal:
 To determine risks
 Stability of the product & the expenses of the resource
 Active workers during this process:
 System analyst
 S/W architect
38
WE-IT TUTORIALS ;
PHNO:8097071144/55

39. Works of System Analyst:
 Elicit stakeholder’s request
 Develop requirement management plan
 find actors & use-cases
Works of S/W Architect:
 Prioritize use-cases
 Review requirements
39
WE-IT TUTORIALS ;
PHNO:8097071144/55

40. 4. DESIGN
 Purpose: To develop robust architecture for the system based
on the requirements, to transform the requirement into design & to
ensure that the implementation issues are reflected in design.
 Goal: To show how the system will be understood in the
implementation phase.
 Active workers during this process:
 Architect
 Designer
40
WE-IT TUTORIALS ;
PHNO:8097071144/55

41. Works of Designer:
 Use-case analysis
 Use-case design
 Class design
41
WE-IT TUTORIALS ;
PHNO:8097071144/55

42. 5. IMPLEMENTATION
 Purpose: To code & to test the system
 Goal: To develop ready to execute module independent of other
modules.
 Active workers during this process:
 Implementer
 Integrator
 Code reviewer
42
WE-IT TUTORIALS ;
PHNO:8097071144/55

43. Works of Implementer:
 Implement a module
 Fix a defect
 Perform unit testing
Works of Integrator:
 Plan system integration
 Plan subsystem integration
 Integrate subsystem
 Integrate system
Works of Code reviewer:
 Review code
43
WE-IT TUTORIALS ;
PHNO:8097071144/55

44. 6. EVALUATION
 It involves assessing costs, time, quality, communication,
deliverables.
 Purpose: To design test case procedures & other verification
methods.
 Goal: Design & execute test cases for the system in order to
eliminate defects.
 Active workers during this process:
 Test designer
 Tester
44
WE-IT TUTORIALS ;
PHNO:8097071144/55

45. Works of Test Designer:
 Plan test
 Design test
 Implement test
 Evaluate test
Works of Tester:
 Execute test
45
WE-IT TUTORIALS ;
PHNO:8097071144/55

46. 7. DEPLOYMENT
 Purpose: To install s/w at the end user.
 Goal: To deliver the system to the user.
 It involves issues of the marketing, packaging, installing, configuring,
supporting, making corrections.
 Active workers during this process:
 Deployment manager
 Technical writer
46
WE-IT TUTORIALS ;
PHNO:8097071144/55

47. Works of Deployment Manager:
 Deploy development plan
 Manage acceptance test
 Define bill of materials
Works of Technical Writer:
 Write release notes
 Develop support materials
47
WE-IT TUTORIALS ;
PHNO:8097071144/55

48. Workflows & life cycle phases
48
WE-IT TUTORIALS ;
PHNO:8097071144/55

49. 49
WE-IT TUTORIALS ;
PHNO:8097071144/55

50. ITERATION WORKFLOWS
50
WE-IT TUTORIALS ;
PHNO:8097071144/55

51. ITERATION OVERLAPS OVER PROJECT
DEVELOPMENT LIFE CYCLE
51
WE-IT TUTORIALS ;
PHNO:8097071144/55

52. INDIVIDUAL ITERATION WORKFLOWS 52
WE-IT TUTORIALS ;
PHNO:8097071144/55

53. CHARACTERISTICS OF ITERATION WORKFLOWS:
 The iterations include continuous assessment of risks & results that
describe:
 Requirement
 Design features & performance
 Reviews & any changes that may occur
 Iteration represent the state of overall system architecture & also the
progress status of complete deliverable system.
 Increment states the current work in progress that will be merged
with the previous iteration to form the next iteration.
53
WE-IT TUTORIALS ;
PHNO:8097071144/55

54. MILESTONES
 Measure of an activity.
 It measures an activity & its result with maximum certainty.
 It can be set of stakeholder's meetings to discuss plan & progress to
define the scope & to achieve the result.
 By setting milestones in stakeholder’s meetings, the project
manager:
 Co-ordinate developer, customer, user to achieves win-win
agreement on the requirement, the design & the plan.
 Identifies the risks, issues
 Conducts a global assessment for the whole life cycle process.
54
WE-IT TUTORIALS ;
PHNO:8097071144/55

55. MAJOR MILESTONES
 They are measured at the end of each phase.
 They are termed as system wide reviews since they are conducted at
the end of each of all 4 phases.
 It gives idea of overall system issues.
 It synchronizes & co-ordinates the project management &
engineering perspectives.
 It also verifies whether or not the aims of the phase are achieved.
 It use formal stakeholder’s approved evaluation criteria & releases
descriptions.
55
WE-IT TUTORIALS ;
PHNO:8097071144/55

56. MINOR MILESTONES
 Periodic events which provide management with frequent and
regular insight into the progress being made
 Management gets view of the current status of the events.
 Management reviews conducted at regular intervals.
 Ensure that the expectations of all stakeholders are synchronized and
consistent.
 Periodic project snapshots.
 Address progress and quality indicators .
56
WE-IT TUTORIALS ;
PHNO:8097071144/55

57. PERIODIC STATUS ASSESSMENT
 It measures the process & its events.
 It also measures the completion of the goals.
 Assessments are conducted periodically so as to provide the
management with frequent & regular insights of the process.
57
WE-IT TUTORIALS ;
PHNO:8097071144/55

58. Iterative Process Planning
58
WE-IT TUTORIALS ;
PHNO:8097071144/55

59. WORK BREAKDOWN STRUCTURES
 It is a Scheduling technique.
 A good work breakdown structure is a critical factor in software
project success.
 development of a work breakdown structure is dependent on the
project management style, organizational culture, customer.
 provides the following information structure:
A description of all significant work
A clear task decomposition for assignment of responsibilities
A framework for scheduling, budgeting, and expenditure
tracking
59
WE-IT TUTORIALS ;
PHNO:8097071144/55

60. EVOLUTIONARY WORK
BREAKDOWN STRUCTURES
 Organizes the planning elements around the process framework
rather than the product framework.
 WBS is to organize the hierarchy as follows:
 First-level :WBS elements are the workflows (management, environment,
requirements, design, implementation, assessment, and deployment).
 Second-level: elements are defined for each phase of the life cycle.
 Third-level: elements are defined for the focus of activities that produce
the artifacts of each phase.
60
WE-IT TUTORIALS ;
PHNO:8097071144/55

61.  Scale
 Organization’s Structure
 Level of custom development
 Business context
 Previous experience
61
WE-IT TUTORIALS ;
PHNO:8097071144/55

62. PLANNING GUIDELINES
DEFAULT WEB BUDGETING: ROUGHLY ALLOCATE COSTS FOR THE
FIRST LEVEL WBS ELEMENTS.
62
WE-IT TUTORIALS ;
PHNO:8097071144/55

63. ALLOCATE THE EFFORTS & SCHEDULE ACROSS THE LIFECYCLE
PHASES.
63
WE-IT TUTORIALS ;
PHNO:8097071144/55

64. ADVANTAGES OF PLANNING GUIDELINES:
Using these 2 guidelines, it becomes easy to:
 Develop a staffing profile
 Allocate staff resources
 Schedule the project
 Develop a WBS with task budgets & schedules relatively
straightforward.
64
WE-IT TUTORIALS ;
PHNO:8097071144/55

65. THE COST AND SCHEDULE ESTIMATING PROCESS
Project plans need to be derived from two perspectives:
 forward-looking (top-down approach)
 backward-looking (bottom-up approach)
65
WE-IT TUTORIALS ;
PHNO:8097071144/55

66. FORWARD-LOOKING
 It starts with an understanding of the general requirements .
 Applied during the engineering stage.
 Derives a macro-level budget and schedule.
 Then decomposes these elements into lower level budgets and intermediate
milestones.
 Planning sequence:
 A characterization of the overall size, process, environment, people,
and quality required for the project is developed.
 A macro-level estimate of the total effort and schedule is developed
using a software cost estimation model.
 The estimate for the effort into a top-level WBS are partitioned. A
project level plan is developed.
 Subproject managers decompose each of the WBS elements into lower
levels.
66
WE-IT TUTORIALS ;
PHNO:8097071144/55

67. BACKWARD-LOOKING
 Applied during the production stage.
 Start with the end in mind.
 Analyze the micro-level budgets and schedules.
 Then sum all these elements into the higher level budgets and intermediate
milestones.
 This approach tends to define and populate the WBS from the lowest levels
upward.
 Planning sequence :
 The lowest level WBS elements are elaborated into detailed tasks.
 Estimates are combined and integrated into higher level budgets and
milestone.
 Comparisons are made with the top-down budgets and schedule
milestones.
67
WE-IT TUTORIALS ;
PHNO:8097071144/55

68. ITERATION PLANNING PROCESS
 Concerned with defining the actual sequence of intermediate results.
 The content and schedule of the major milestones and their intermediate
iterations are planned.
 Applied at each phase.
Inception iterations:
 Scope of the iteration.
 The early prototyping activities integrate the foundation components of a
candidate architecture and provide an executable framework for elaborating
the critical use cases of the system.
Elaboration iterations:
 These iterations result in an architecture, including a complete framework
and infrastructure for execution.
 Development of architecture baseline.
 architecture prototype is created. 68
WE-IT TUTORIALS ;
PHNO:8097071144/55

69. Construction iterations:
 Two major construction iterations: an alpha release & a beta release.
 An alpha release would include executable capability for all the critical
use cases. It usually represents only about 70% of the total product
breadth and performs at quality levels.
 A beta release typically provides 95% of the total product capability
breadth and achieves some of the important quality attributes.
Transition iterations:
 Product release.
 A beta release into the final product.
69
WE-IT TUTORIALS ;
PHNO:8097071144/55

70. PRAGMATIC PLANNING
 While executing iteration N of any phase, the software project manager
must be monitoring and controlling against a plan that was initiated in
iteration N - 1 and must be planning iteration N + 1.
 The art of good project management is to make trade-offs in the current
iteration plan and the next iteration plan based on objective results in the
current iteration and previous iterations.
 Success of every project is achieved only by good planning. Inadequate
planning is also one of the most common reason for project failure.
 A project plan defines how the requirements will be later transformed into a
product with constraints. And this project will be realistic, understandable
& easily usable.
 Plans are not only useful for the project managers – as more open is the
planning process & its results, more ownership will be attained among the
team members. That means, bad & closed plans cause destruction & good
and open plans encourages the teamwork.
70
WE-IT TUTORIALS ;
PHNO:8097071144/55

71. UNIT IV
71
WE-IT TUTORIALS ;
PHNO:8097071144/55

72. Project Organizations & Responsibilities
72
WE-IT TUTORIALS ;
PHNO:8097071144/55

73. Organization is an important part in the software Line - of - business as it
fulfils the basic needs necessary to support the software development.
Similarly, Project Organization is the large extend about the people involved
in software development - Various different types of people come together
and form a team for the project organization and these teams are
responsible for the work allocated to them.
In general, project organization binds some responsibilities to the team and
allocate some useful task towards that team members.
This ensures the large architecture and small - small components also to
complete whole project.
73
WE-IT TUTORIALS ;
PHNO:8097071144/55

74. LINE-OF-BUSINESS ORGANIZATIONS
74
WE-IT TUTORIALS ;
PHNO:8097071144/55

75. LINE-OF-BUSINESS
ORGANIZATIONS
The main features of the default organization are as follows:
 Responsibility for process definition and maintenance
 Responsibility for process automation
 Organizational roles may be fulfilled by a single individual or several
different teams, depending on the scale of the organization.
1. Organization Manager
 Leader
 Management Administrative
 Professional Working Task
75
WE-IT TUTORIALS ;
PHNO:8097071144/55

76. 2. Project Review Authority (PRA)
 PRA is the single individual responsible for ensuring that a software project
complies with all organizational and business unit software policies,
practices, and standards.
 A software project manager is responsible for meeting the requirements
of a contract or some other project compliance standard, and is also
accountable to the PRA.
 The PRA reviews both contractual obligations and the project's
organizational policy obligations
76
WE-IT TUTORIALS ;
PHNO:8097071144/55

77. 3. Software Engineering Process Authority (SEPA)
 The SEPA is a necessary role in any organization
 The SEPA could be a single individual, the general manager, or even a team
of representatives
 facilitates the exchange of information and process guidance both to and
from project practitioners
 the organization general manager is responsible for maintaining a current
assessment of the organization's process maturity and its plan for future
process improvements
 The SEPA must help initiate and periodically assess project processes
77
WE-IT TUTORIALS ;
PHNO:8097071144/55

78. 4. Software Engineering Environment Authority(SEEA)
Responsible for:
 automating the organization's process
 maintaining the organization's standard environment
 training projects to use the environment
 maintaining organization-wide reusable assets
78
WE-IT TUTORIALS ;
PHNO:8097071144/55

79. 5. Infrastructure
Components of the infrastructure:
 Project Administrative Work Infrastructure: time management system,
contract, pricing, rules & regulations, legal information related to
corporate world
 Engineering Skills Centered Infrastructure: tools warehouse &
maintenance department, independent R & D
 Professional Development: departmental training camp, hiring employees,
database maintenance skills, publish technical support books.
79
WE-IT TUTORIALS ;
PHNO:8097071144/55

80. PROJECT ORGANIZATIONS
80
WE-IT TUTORIALS ;
PHNO:8097071144/55

81. 1. Project Management Team
 is an active participant, responsible for producing as well as managing
 The software management team carries the burden of delivering win
conditions to all stakeholders
 The software management team is responsible for planning and adapting
the plan to changes in the requirements or the design
 the team takes ownership of resource management project scope, and sets
operational priorities across the project life cycle
 all aspects of quality
2. Project Architecture Team
 responsible for the integration of components .
 responsible for the architecture
 Responsible for all the engineering activities
 Involvement in the inception and elaboration phases
81
WE-IT TUTORIALS ;
PHNO:8097071144/55

82. 3. Project Development Team
 responsible for the development (construction)
 responsible for the development, testing, maintenance and quality of
individual components
 comprises several sub teams dedicated to groups of components that
require a common skill set.
 Skill sets: Commercial component, Database, Operating systems and
networking Domain applications
4. Project Assessment Team
 responsible for the testing
 Involvement in the construction and transition phases
82
WE-IT TUTORIALS ;
PHNO:8097071144/55

83. EVOLUTION OF ORGANIZATIONS
83
WE-IT TUTORIALS ;
PHNO:8097071144/55

84. The project organization represents the architecture of the team and
needs to evolve consistent with the project plan captured in the work
breakdown structure.
 Inception team: focused on planning
 Elaboration team: focused on Engineering activities
 Construction team: focuses on software development and software
assessment
 Transition team: focuses on the deployment activities
84
WE-IT TUTORIALS ;
PHNO:8097071144/55

85. PROCESS AUTOMATION
85
WE-IT TUTORIALS ;
PHNO:8097071144/55

86. A significant level of process automation is required for modern
software development projects to operate profitably.
 Saves time
 Less expertise required
 Cost efficient techniques
 Reliable
86
WE-IT TUTORIALS ;
PHNO:8097071144/55

87. ELEMENTS OF PROCESS AUTOMATION
 Environment
 Change Management Relation
 Round Trip Engineering
 Metric Automation
 Role of External Stakeholders
87
WE-IT TUTORIALS ;
PHNO:8097071144/55

88. Process Level: There are three levels of the process.
 Meta Process: This automation in the process is done at the Line of
business which we learn in the last chapter. The automation that
supports at the Meta level is called ‘infrastructure’.
 Macro Process: This automation in the process is done at project
development phase. The automation support at the macro level is
called an environment.
 Micro Process: This automation in the process is done at iteration
phase. The automation support at the micro process level for
generating artifacts is called as tool.
88
WE-IT TUTORIALS ;
PHNO:8097071144/55

89. AUTOMATION BUILDING BLOCKS
89
WE-IT TUTORIALS ;
PHNO:8097071144/55

90. Management:
 Workflow is the process which contains small task links together. The
automation in the tasks, resources and internal operations of the process is
called Workflow Automation.
Environment:
 Change management depends upon the new version of the product which
includes configuration management.
Requirements :
 The flow of the requirements finally reaches to smallest unit. System
requirements decompose into subsystem, sub - system requirements are
fulfilled by components while component requirements are generated by
smallest unit.
 Vision statement can be generated through the interaction amongst the
System development group.
 Vision statement is accessible by the buyer of the System.
90
WE-IT TUTORIALS ;
PHNO:8097071144/55

91. Design :
 The targeted tool for the design workflow is visual modeling.
 Generally this model is used to capture the design models which are further
used to present it in human understandable format and finally translate it
into source code.
Implementation :
 This workflow is based on the productive iteration, which is based upon the
programming environment include editing, compiling, debugging, linking,
running etc.
Assessment and Deployment:
 Assessment workflow depends upon testing the tool or system which is
finally generated. Defect finding is one of the important tasks of this
workflow.
91
WE-IT TUTORIALS ;
PHNO:8097071144/55

92. PROJECT ENVIORNMENT
92
WE-IT TUTORIALS ;
PHNO:8097071144/55

93. The project environment evolve through three states:
 the prototyping environment
 the development environment
 the maintenance environment
93
WE-IT TUTORIALS ;
PHNO:8097071144/55

94. The prototyping environment:
 Analyses the risks technically.
 Makes the feasibility study analysis for all the commercial products.
 Reconfiguration.
 Analyze the risks at the time of full system implementation.
 Make requirement analyses and generate testing scenario for that
etc.
94
WE-IT TUTORIALS ;
PHNO:8097071144/55

95. The Development Environment:
 The development environment should include a full suite of
development tools needed to support the various process workflows.
 to support round-trip engineering to the maximum extent possible.
 The maintenance environment.
 Related to maintenance of the project.
 The maintenance environment should typically coincide with a
mature version of the development environment.
95
WE-IT TUTORIALS ;
PHNO:8097071144/55

96. Maintenance Environment:
 It is the subset of the development environment. It includes
following major activities in-order to deliver the project’s end
product.
 In the environment aspect there are main four disciplines that are
essential for management context & it further finalizes the success
of a modern iterative development process.
 Round Trip Engineering
 Change Management
 Infrastructure
 Stakeholder Environment
96
WE-IT TUTORIALS ;
PHNO:8097071144/55

97. T.Y. B.SC.I.T.
UNIT V
97
WE-IT TUTORIALS ; PHNO:8097071144/55

98. THE SEVEN CORE METRICS
MANAGEMENT INDICATORS
• Work and progress (work performed over time)
• Budgeted cost and expenditures (cost incurred over time)
• Staffing and team dynamics (personnel changes over time)
QUALITY INDICATORS
• Change traffic and stability (change traffic over time)
• Breakage and modularity (average breakage per change over time)
• Rework and adaptability (average rework per change over time)
• Mean time between failures (MTBF) and maturity (defect rate over time)
WE-IT TUTORIALS ;
PHNO:8097071144/55
98

99. OVERVIEW OF THE SEVEN CORE METRICS
METRIC PURPOSE
Work and progress
Iteration planning, plan vs. actuals,
management indicator
Budgeted cost and expenditures
Financial insight, plan vs. actuals,
management indicator
Staffing and team dynamics
Resource plan vs. actuals, hiring rate,
attrition rate
Change traffic and stability
Iteration planning, management
indicator of schedule convergence
Breakage and modularity
Convergence, software scrap, quality
indicator
Rework and adaptability
Convergence, software rework, quality
indicator
MTBF and maturity
Test coverage/adequacy, robustness
for use, quality indicator
WE-IT TUTORIALS ;
PHNO:8097071144/55
99

100.  MANAGEMENT INDICATORS
 WORK AND PROGRESS
 architecture ,development ,assessment ,management
 BUDGETED COST AND EXPENDITURES
 Expenditure plan, Actual progress, Actual cost, Cost variance, Schedule variance
 STAFFING AND TEAM DYNAMICS
 Inception(5%),elaboration(20%),construction(65%),transition(10%)
 QUALITY INDICATORS
 CHANGE TRAFFIC AND STABILITY
 Overall change,change orders,Stability
 BREAKAGE AND MODULARITY
 average extent of change
 REWORK AND ADAPTABILITY
 average cost of change
 MTBF AND MATURITY
 average usage time between software faults
WE-IT TUTORIALS ;
PHNO:8097071144/55
100

101. LIFE-CYCLE EXPECTATIONS
 provide insight
 standard measurement perspective
 recognize the inherently dynamic nature of an iterative
development process
 concentrate on the trends or changes with respect to time
 combination of insight from the current value and the current
trend
WE-IT TUTORIALS ;
PHNO:8097071144/55
101

102. PRAGMATIC SOFTWARE METRICS
 provides data to help them ask-the right questions, understand
the context, and make objective decisions.
 measures must be available at any time, tailorable to various
subsets of the evolving product
WE-IT TUTORIALS ;
PHNO:8097071144/55
102

103. BASIC CHARACTERISTICS OF A GOOD METRIC
 It is considered meaningful by the customer, manager, and
performer
 It demonstrates quantifiable correlation between process
easiness and business performance
 It is objective and unambiguously defined
 It displays trends
 It is a natural by-product of the process
 It is supported by automation
WE-IT TUTORIALS ;
PHNO:8097071144/55
103

104. TAILORING THE PROCESS
 Tailoring the process involves the in-built activities required for
the development task.
 Depending upon the project specific characteristics, the project
framework is decided.
WE-IT TUTORIALS ;
PHNO:8097071144/55
104

105. PROCESS DISCRIMINATION
 Two different dimensions of the project Discrimination
1. Technical Dimensions
2. Management Dimensions
WE-IT TUTORIALS ;
PHNO:8097071144/55
105

106. SCALE
 process tailoring, the scale is measured by the total
number of the people involved in the process as a
team.
 1 individual Trivial
 5 member’s team -> Small
 25 member’s team -> Moderate
 125 member’s team -> Large
 625 member’s team -> huge
WE-IT TUTORIALS ;
PHNO:8097071144/55
106

107. T.Y. B.SC.I.T.
UNIT VI
107
WE-IT TUTORIALS ; PHNO:8097071144/55

108. FUTURE SOFTWARE PROJECT MANAGEMENT
 Continuous Integration
 At the design phase architecture first approach forces integration which includes
the demonstration construction level. This beginning work gives fast track for the
future work. Design breakage covered in the engineering phase.
 Early Risk Resolution
 resolution had done in the engineering stage of the life cycle which is means
inception and elaboration stage.
 That indicates production phase free for the resource commitment.
 Evolutionary Requirements
 Components requirements fulfillment for the sub system and finally sub system
requirements finishes the system requirements.
 Teamwork among Stakeholders
 Good and healthy relationship between stakeholders makes various strong
activities for software project.
WE-IT TUTORIALS ;
PHNO:8097071144/55
108

109. TOP - TEN MANAGEMENT PRINCIPLES
1. Architecture first is the primary base of the process.
2. Earlier risk finding is good strategy for process which is the part of the
iterative life cycle.
3. Component based development requires the transition design.
4. Generate change management profile projects.
5. In case of the round trip engineering improve change freedom activity.
6. In the model design notations draw the designs artifacts.
7. Process instrumentation is necessary for the quality control objectives and
assessment of progress in the project.
8. Demonstration based approach is useful for assessing middleware artifacts.
9. Detailing regarding each level is at releasing time.
10. Generate configuration process which is economic scalable.
WE-IT TUTORIALS ;
PHNO:8097071144/55
109

110. NEXT GENERATION SOFTWARE ECONOMICS
 This returns the return policy against investment. We can say
that this is the mature organization indication.
 Next Generation Cost Models
 Old C++ verses GUI based Java
 Function oriented verses code of source lines
 Quality against productivity measure
 Procedure oriented verses object oriented
 Modern Software Economics
 Fix problems earlier in the design phase
 Schedule should be reduced(25%)
 Client side maintenance
WE-IT TUTORIALS ;
PHNO:8097071144/55
110

111. MODERN PROCESS TRANSITION
 Culture Shifts (adjustments)
 Performers are major indicators which are lower and middle level
managers.
 Customer given requirements and its design should be change and
tangible.
 Motivated demonstrations are encouraged.
 Performance of the project which is either bad or good should be clear
earlier in the life cycle.
 Uses of artifacts are more in later stage than early stage.
 Whatever problems arises that are faced and solved step by step
WE-IT TUTORIALS ;
PHNO:8097071144/55
111

112. END OF PROJECT MANAGEMENT
ADMISSION FOR
TYBSC(IT/CS) STARTS
FROM DECEMBER
WITH COMPLIMENTRY
SUBJECTS.
OFFERS GROUP
DISCOUNT, AND
SPECIAL DISCOUNTS
FOR SCHOLARS.
WE-IT TUTORIALS ; PHNO:8097071144/55
112