object oriented software engineering - project management concept

8/6/2019 Object Oriented Software Engineering - Project Management Concept

1/19

Project Management Concept

Chapter Two

1


2/19

Project Management Conceptsy Project management involves the planning, monitoring, and control of people,

process, and events that occur during software development.

y Everyone manages, but the scope of each person's management activities varies

according his or her role in the project.

y Software needs to be managed because it is a complex undertaking with a longduration time.

y Managers must focus on the fours P's to be successful : (People product, process,and project).

y

A project plan is a document that defines the four P's in such a way as to ensurea cost effective, high quality software product.

y The only way to be sure that a project plan worked correctly is by observing

that a high quality product was delivered on time and under budget.

2


3/19

Management Spectrum Software project management is aimed to ensure that the software is

delivered on time, within budget and schedule constraints, and

satisfies the requirements of the client

Effective software project management focuses on the four Ps:

1. People : the most important element of a successful project

2. Product : the software to be built

3. Process : the set of framework activities and software

engineering tasks to get the job done

4. Project : all work required to make the product a reality

3


4/19

The People Most important factor in success of software project.

Companies That sensibly manage their investment in people willprosper in the long run .

Cultivation of motivated and highly skilled software people has alwaysbeen important for software organizations.

The people-factor is so important that SEI has developed People

Management Capability Maturity Model (PM-CMM).

4


5/19


6/19

The Product Before a project can be planned:

y Product objectives and scope should be established

y Alternative solutions should be considered

y Technical and management constraints should be identified

Without above information ,Estimates of cost, effective assessment of risk,realistic breakdown of project tasks, or manageable project schedule is hardto define.

Customer and developer define the product objectives and scope

Objectives identify the overall goals for the product

Scope Identifies the primary data, functions and behaviors thatcharacterize the product and attempt to bound these characteristics ina quantitative manner(eg no. of simultaneous users, max response time).

Alternative solutions are then considered. Among them, the best one ischosen by the developer based on given constraints imposed by delivery

deadlines, budgetary restrictions, personnel availability etc.


7/19

The Process

A software process provides the framework for which a

comprehensive plan for software development can be established.

Task sets tasks, milestones, work products, and quality assurance

points Umbrella activities software quality assurance, software

configuration management, and measurement


8/19

The Project

To manage complexity

To avoid project failure

To develop a common sense approach for planning, monitoring,

and controlling the project.


9/19

The People

The Players

Team Leaders

The Software Team Coordination and Communication Issues

9


10/19

The Players They can be categorized into one of the following five categories

y Senior Managers

y They define business issues that often have significant influence onbusiness

y

Project (technical) managersy They must plan, motivate, organize and control the practitioners who do

software work

y Practitioners

y They deliver the technical skills necessary to engineer a product or

applicationy Customers

y They specify the requirements for the software to be engineered

y End Users

y They interact with the software after it is released for production use

10


11/19

Team Leader Competent Practitioners often make poor team leaders as they lack the

right mix of skills In his excellent book of technical leadership,Jerry Weinberg suggests

a MOI model of leadership MOI Model of Leadership

y Motivationy Ability to encourage technical people (by push or pull ) to produce

y Organizationy Ability to mold existing process (or invent new ones) that will enables

the initial concept to be translated into a final product.

y Ideas or Innovationy Ability to encourage to make people feel creative or be creative even in

the boundary of software product constraints.

11


12/19

Team Leader Characteristics of a effective project managers:

y Problem Solvingy Diagnostic ( about technical and organizational issues )y Skill to solvey Ability to design solution

y Managerial Identityy Control the project

y Achievementy Reward Initiativey Encourage Controlled risk taking

y Influence and team buildingy Influence the teamy Read peoples mind and respond according to their needsy Be controlled in stress situations

12


13/19

The Software Team N individuals vs. m tasks

Team organizationsy Democratic decentralized (DD):

y no permanent leader

y rather task coordinator

y

decision made by group consensusy Communication is horizontal

y Controlled decentralized (CD):y has defined leader

y decision remains group activity

y works partitioned

y Communication is horizontal

y Controlled centralized (CC):y Defined team leader

y Top-level problem solving

y internal coordination

y communication and management by team leader

y Communication is vertical

13


14/19

The Software Teamy Team Structures: Seven Factors that should be considered while

planning the structure of software engineering team:

1. Difficulty of task

2. Size of resultant code (no. of lines)

3. Time that team will stay together

4. Degree of modularization

5. Required quality and reliability of the system being built

6. Rigidity of delivery date (schedule)

7. Degree of communication

14


15/19

Organizational Paradigm

15

Constantine suggest four organization paradigm

1. Closed Paradigm :structures a team along a traditional hierarchy of

authority (similar to a CC team)

2. Random Paradigm : structures a team loosely and depends on individual

initiative of the team members3. Open Paradigm: attempts to structure a team in a manner that achieves

some of the controls associated with the closed paradigm but also much of

the innovation that occurs when using the random paradigm

4. Synchronous Paradigm :relies on the natural compartmentalization of a

problem and organizes team members to work on pieces of the problem with

little active communication among themselves


16/19

Communication & coordination Issues Many reasons that software projects get into trouble:

Scale

Uncertainty

Interoperability

Therefore, must establish methods for coordinating the people.

Hence, establish formal and informal communication among team members:

1. Formal, impersonal approaches: SE docs and deliverables, tech memo.

2. Formal, interpersonal procedures: QA activities, status review meetingsand design

3. Informal, interpersonal procedures: group meeting

4. Electronic communication: email, e-bbs

5. Interpersonal networking: interpersonal discussion with outsiders.

16


17/19

The Product The product and the problem that is intended to solve must be

examined at very beginning of the software project.

The scope of product must be established and bounded.y Bounded scope means

y establishing quantitative data like no. of simultaneous users, max.allowable response time. etc.

y Constraints and limitations

The problem that the product is addressing must be decomposed

17


18/19

The Product

18

y Scope is defined by

y Context (1st step in scope determination)

y Functional location of the software product into a large system, product

or business context

y Constraints involved

y Information Objectives (2nd step)

y What data objects are required as i/p or o/p

y Function and Performance (3rd step)

yWhat function does the software system perform on i/p to produce o/p

y Are any special performance characteristic to be addressed?


19/19

Problem Decomposition

19

Also called Partitioning ORProblem Elaboration This activity is at core of requirements analysis

Divide and conquer policy for complex problemsy Decompose problem in tasksy Decomposition in 2 major areas

y Functionality that must be deliveredy Process that will be used to deliver product

A complex problem is partitioned into smaller problems that aremore manageable.

Decomposition make planning easier. Software functions, defined in scope, are evaluated and refined to

provide more detail before estimation (part of planning) begins.

object oriented software engineering - project management concept

Documents