ENGR Engineering Project Management 1.

(1)

ENGR 301 -2021

Engineering Project

Management 1.

Project Lifecycles 1 and Methodologies

(2)

ENGR 301 IP Project Agreement

• Complete Project Agreement:

• Deadline:

12 March 2021

• Current status:

• Submitted: 85

• Not submitted: 28

• Students who have contacted me with concerns: 4

https://ecs.wgtn.ac.nz/Courses/ENGR301_2021T1/ProjectAgreement

2

(3)

Mattermost

(4)

Project Storage

• All project documents to be stored in GitLab.

• No GitHub, Google Drive, etc.

• GitLab repositories for all projects have been set up

https://gitlab.ecs.vuw.ac.nz/course-work/ENGR300/2021/Group-01/

4

(5)

(6)

The Relationship Between Project Management

and Project Management Methodology

• Project management provides the framework. It informs what

needs to be done at a high-level. BOKs are frameworks.

• A project management methodology describes how things should

be done.

• One definition of a methodology:

…a strictly defined combination of logically related practices,

methods and processes that determine how best to plan,

develop, control and deliver a project throughout the continuous

implementation process until successful completion and

termination. It is a

scientifically-proven

, systematic and

disciplined approach to project design, execution and

completion.

Project Management Framework

Methodology

Project stages (life cycle stages)

Processes

Tasks and Activities

6

(7)

,..

DoDSTD-2167

4 JUNE

1%

SUPERSEDING

DOD-STD-1B7BA (NAVY

Z? OCTOBER

19S2

MILSD-1644B (TDl

2 MARCH

19S4

MILITARY

STANDARD

DEFENSE SYSTEM

SOFIVVARE DEVELOPMENT

(

~

i

AMSC

NO. N3SOB

AREA

MCCR

,..

DoDSTD-2167

4 JUNE

1%

SUPERSEDING

DOD-STD-1B7BA (NAVY

Z? OCTOBER

19S2

MILSD-1644B (TDl

2 MARCH

19S4

MILITARY

STANDARD

DEFENSE SYSTEM

SOFIVVARE DEVELOPMENT

(

~

i

AMSC

NO. N3SOB

AREA

MCCR

DISTRIBUTION STATEMENT

A. Approved forpublicreleaaa;

distribution

isunlimitd’.

(8)

,..

DoDSTD-2167

4 JUNE

1%

SUPERSEDING

DOD-STD-1B7BA (NAVY

Z? OCTOBER

19S2

MILSD-1644B (TDl

2 MARCH

19S4

MILITARY

STANDARD

DEFENSE SYSTEM

SOFIVVARE DEVELOPMENT

(

~ i

AMSC

NO. N3SOB

AREA

MCCR

DISTRIBUTION STATEMENT

A. Approved forpublicreleaaa;

distribution

isunlimitd’.

(9)

(10)

Classic Waterfall

Managing the development of large software systems

Winston W Royce

Proceedings of IEEE WESCON 26

Figures from Ian Somerville, Software Engineering, 10th ed, 2014.

http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf

10

(11)

I

SYSTE M

I

ANALYSIS

PROGRAM

DESIGN

I

c o o , . o

TESTING

I OPERATIONS

Figure 2. Implementation steps to develop a large computer program for delivery to a customer.

I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.

One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software without these steps, but generally these phases are managed with relative ease and have little impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbit mechanics, spacecraft attitude determination, mathematical optimization of payload activity and so forth, but when these departments have completed their difficult and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their difficult and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.

However, I believe the illustrated approach to be fundamentally sound. The remainder of this discussion presents five additional features that must be added to this basic approach to eliminate most of the development risks.

Managing the development of large software systems

Winston W Royce

Proceedings of IEEE WESCON 26

(12)

I SYSTEM !

REQUIREMENTSIBI~

~"'i so,w.,~ I

ANALYSIS

~1111~

I I pRI~OGRAM

~lll I

CODING Ii

TESTING

OPERATIONS

Figure 3. Hopefully, the ~terat=ve interact=on between the various phases is confined to successive steps.

I

.~oo,.~-,..Sl.,~

SYSTEM "1

I so,w..~ !.

I ANALYSIS

PROGRAM

DESIGN

I

coo,.G I,~

!

TESTING I

I

O .ATO.S !

Figure 4. Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps.

330 Managing the development of large software systems

Winston W Royce

Proceedings of IEEE WESCON 26

(13)

I SYSTEM !

REQUIREMENTSIBI~

~"'i so,w.,~ I

ANALYSIS

~1111~

I I pRI~OGRAM

~lll I

CODING Ii

TESTING

OPERATIONS

Figure 3. Hopefully, the ~terat=ve interact=on between the various phases is confined to successive steps.

I

.~oo,.~-,..Sl.,~

SYSTEM "1

I so,w..~ !.

I ANALYSIS

PROGRAM DESIGN

I

coo,.G I,~

!

TESTING I

I

O .ATO.S !

Figure 4. Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps.

Managing the development of large software systems

Winston W Royce

(14)

STEP 1: PROGRAM DESIGN COMES FIRST

The first step towards a fix is illustrated in Figure 5. A preliminary program design phase has been inserted between the software requirements generation phase and the analysis phase. This procedure can be criticized on the basis that the program designer is forced to design in the relative vacuum of initial software requirements without any existing analysis..As a result, his preliminary design may be substantially in error as compared to his design if he were to wait until the analysis was complete. This criticism is correct but it misses the point. By this technique the program designer assures that the software will not fail because of storage, timing, and data flux reasons. As the analysis proceeds in the succeeding phase the program designer must impose on the analyst the storage, timing, and operational constraints in such a way that he senses the consequences. When he justifiably requires more of this kind of resource in order to implement his equations it must be simultaneously snatched from his analyst compatriots. In this way all the analysts and all the program designers will contribute to a meaningful design process which will culminate in the proper allocation of execution time and storage resources. If the total resources to be applied are insufficient or if the embryo operational design is wrong it will be recognized at this earlier stage and the iteration with requhements and preliminary design can be redone before final design, coding and test commences.

How is this procedure implemented? The following steps are required.

1) Begin the design process with program designers, not analysts or programmers.

2) Design, define and allocate the data processing modes even at the risk of being wrong. Allocate processing, functions, design the data base, define data base processing, allocate execution time, define interfaces and processing modes with the operating system, describe input and output processing, and define preliminary operating procedures.

3) Write an overview document that is understandable, informative and current. Each and every worker must have an elemental understanding of the system. At least one person must have a deep understanding of the system which comes partially from having had to write an overview document.

/ ALLOCATE ~ A DESCRIBE

/ sO..oOO,,. /

c

%

I

Figure 5. Step 1 : Insure that a preliminary program design is complete before analysis begins.

331

Managing the development of large software systems

Winston W Royce

Proceedings of IEEE WESCON 26

(15)

I | I ' I I

:i]

.

~

'

l l e ~$ ~ ~ i n |~ ~ u 8( I I .. I s""

O0

0@'

0 O°

~

d

p@@@@@@~S.

I w

R

I.L.

338 Managing the development of large

software systems

Winston W Royce

Proceedings of IEEE WESCON 26

(16)

I

|

I

'

I

:i]

.

~

'

l

e

~$

~

i

n

|~

~

u

8(

I

..

I

s""

O0

0@'

0 O°

~

d

p@@@@@@~S.

I

w

R

I.L.

338 Managing the development of large software systems

Winston W Royce

Proceedings of IEEE WESCON 26

16

(17)

V Model

Figures from Ian Somerville, Software Engineering, 10th ed, 2014.

Validation can be

expressed by the

query "Are you

building the right

thing?"

(18)

Requirements

Figures from Ian Somerville, Software Engineering, 10th ed, 2014.

(19)

(20)

ISO/IEC/IEEE

12207 (agile)

Figure 4 —Software life cycle processes 5.6.2 Agreement processes

Organizations are producers and users of software systems. One organization (acting as an acquirer) can task another (acting as a supplier) for products or services. This is achieved using agreements. Agreements allow both acquirers and suppliers to realize value and support business strategies for their organizations.

The Agreement processes are organizational processes that apply outside of the span of a project’s life, as well as for a project’s lifespan. Generally, organizations act simultaneously or successively as both acquirers and suppliers of software systems. The Agreement processes can be used with less formality when the acquirer and the supplier are in the same organization. Similarly, they can be used within the organization to agree on the respective

Information Management Process (Clause 6.3.2) Project Processes Human Resource Project Portfolio Infrastructure (Clause 6.2.1) Project - Enabling

Software Life Cycle Processes

Information Management Process (Clause 6.3.2) Project Processes Project Portfolio (Clause 6.2.3) Infrastructure Life Cycle Model

Technical Processes

Measurement Process (6.3.7) Information Management Process

(6.3.6) Configuration Management

Process (6.3.5) Risk Management Process (6.3.4)

Decision Management Process (6.3.3)

Project Assessment and Control Process (6.3.2) Project Planning Process (6.3.1) Technical Management

Processes

Quality Management Process (6.2.5) Human Resource Management

Process (6.2.4) Portfolio Management Process

(6.2.3) Life Cycle Model Management

Process (6.2.1) Infrastructure Management Process (6.2.2) Organizational Project-Enabling Processes Supply Process (6.1.2) Agreement Processes

Knowledge Management Process (6.2.6)

Quality Assurance Process (6.3.8)

Architecture Definition Process (6.4.4)

Design Definition Process (6.4.5) Stakeholder Needs and Requirements Definition Process

(6.4.2) Maintenance Process (6.4.13) Operation Process (6.4.12) Validation Process (6.4.11) Transition Process (6.4.10) Verification Process (6.4.9) Integration Process (6.4.8) Implementation Process (6.4.7) System Analysis Process (6.4.6)

Disposal Process (6.4.14) Business or Mission Analysis

Process (6.4.1) Acquisition Process (6.1.1)

Systems/Software Requirements Definition Process (6.4.3)

Authorized licensed use limited to: Victoria University of Wellington. Downloaded on March 19,2018 at 09:22:47 UTC from IEEE Xplore. Restrictions apply.

(21)

By U.S. House of Representatives

(Systems Development Life-Cycle

Policy p.13) [Public domain], via

Wikimedia Commons

(22)

Planning

Figures from Ian Somerville, Software Engineering, 10th ed, 2014.

(23)

Estimation

(24)

Estimation – Constructive Cost Model

(COCOMO)

Figures from Ian Somerville, Software Engineering, 10th ed, 2014.

(25)

Risk Management

(26)

Cost of Change

Barry Boehm

Software Engineering Economics, 1981

(27)

Change Control

(28)

Incremental

Figures from Ian Somerville, Software Engineering, 10th ed, 2014.

(29)

Iterative

(30)

Incremental vs Iterative

Incremental

Iterative

(31)

Taxonomy of Methodologies

• PRINCE2

• Critical path method (CPM)

• Lean manufacturing

• Lean Software

Development

• Six Sigma

• Critical Chain Project

Management (CCPM)

• Scrum

• Extreme Programming (XP)

• Unified Software Development Process

(USDP)

• Rational Unified Process (RUP)

• Dynamic Systems Development Method

(DSDM)

• Capability Maturity Model Integration

(CMMI)

• Feature Driven Development (FDD)

(32)

PRINCE2

PRINCE2: Projects IN Controlled Environments (1990’s)

• Very popular.

• Generic, adaptable.

• Defines 45 separate sub-processes organized into 8 groups:

1. Starting up a project.

2. Planning

3. Initiating a project.

4. Directing a project.

5. Controlling a stage.

6. Managing product delivery.

7. Managing stage boundaries.

8. Closing a project.

32

(33)

R

ational

U

nified

P

rocess (RUP)

Iterative software development

process that focuses on team

productivity and delivers software

best practices to all team members.

(34)

Six Sigma

Used to improve quality and processes. Six Sigma’s target for

perfection is the achievement of no more than 3.4 defects, errors, or

mistakes per million “opportunities”. Two main strains: DMAIC (Define,

Measure, Analyze, Improve and Control) and DMADV (Define,

Measure, Analyze, Design and Verify).

34

(35)

Capability Maturity Model

cmmiinstitute.com

Software Engineering Institute

Carnegie Mellon University

Figures from Ian Somerville, Software Engineering, 10th ed, 2014.

(36)

The Engineering Design Process

What is the Engineering Design Process?

(37)

The Engineering Design Process

What is the Engineering Design Process?

In it’s simplest form:

Think it

Plan it

Build it

Forbidden Planet (1956) - IMDb

(38)

The Engineering Design Process

There are, obviously, a few more

details in practice!

You can encounter many

expressions of the process, but

they all share the common ideas of:

• Requirements

• Product concept

• Solution concept

• Embodiment design

• Detailed design

38

(39)

Engineering Design Cycle

The process is often iterative or

cyclic.

• This is particularly true of

software engineering.

• Electronics engineering will also

often follow an iterative

process.

(40)

Engineering Design Levels

We can recognize different kinds (“levels”) of design, which depend on

the task:

• Adaptive design

o highly constrained/refined existing design;

o Minimal freedom to develop or change.

o Requires minimal specialist expertise.

X

None of our projects.

40

(41)

Engineering Design Levels

We can recognize different kinds (“levels”) of design, which depend on

the task:

• Development design

o Starting with an existing design.

o Final design/product can be significantly different from the initial design.

o Requires specialist technical expertise and a little design expertise. Past projects:

üProject 1 – Riverwatch mobile phone apps, hardware and website.

üProject 6 – DIY 3D printer.

(42)

Engineering Design Levels

We can recognize different kinds (“levels”) of design, which depend on

the task:

• New design

o No existing design.

o Most exciting but, typically only a minority of projects you will encounter.

o Requires the greatest specialist expertise, both design and technical.

üProject 3 – Integrated electronics platform.

üProject 7 – DIY laser cutter.

üProject 12 – Rocket avionics system.

42

(43)

Projects and the Engineering Design Process

• The engineering design process informs and shapes the engineering project

life-cycle models

• The question (or even problem) to be solved is:

How to integrate an iterative engineering design process into a project which

operates within human, technological and time constraints.

(44)

Project Life Cycles

• Why “model” a project with a life cycle?

• Just natural due to transient nature of projects. They have:

• A beginning

• A period of growth and development.

• An end.

• For an engineering project, the middle period implements the

engineering design cycle.

• The life cycle provides a necessary framework within which the

design cycle operates.

44

(45)

Your Project Life Cycle is Like a

Beautiful Butterfly

(46)

Then there are some projects…

(47)

Linear Project Life Cycle

• This figure from the APM Body of

Knowledge is a typical linear life

cycle model.

• Great for projects which are:

• Conceptually well-establishable.

• Sequential by nature.

• Are less likely to be subject to

changes in requirements or

environment.

What are some examples of projects

with linear life cycles?

(48)

Examples of Linear Projects

• Construction projects:

o Building a residential house

or commercial building.

o Building a road.

o Infrastructure.

• Manufacturing projects:

o Motor vehicle

manufacturing.

o Aircraft manufacturing.

o Electronic device hardware:

CPUs, phones; tablets;

laptops; desktops.

• Service projects:

o Weddings.

o Conferences.

o Concerts.

o Marketing or advertising.

• Software:

o None I can think of.

• Science:

o Surely you’re joking…

48

(49)

The Linear Life Cycle as a Waterfall

• This is the much-maligned

traditional/classical model.

• Many, many diagrams. This is one.

• Life cycle stages, once completed, are

rarely revisited. Broadly:

o Analysis.

o Design.

o Implementation.

o Maintenance.

• Is best for some projects.

(50)

The Spiral Model: Iterating the Waterfall

• Waterfall was never intended

to be completely rigid…

although many projects

benefit from that rigidity.

• Iteration of a linear cycle has

become known as the spiral

life cycle.

• Introduces flexibility and

adaptability to the project.

• Still contains rigid cycle

stages.

50

(51)

Project Life Cycles

• At the most abstract level, there are only the two:

• Linear.

• Iterative.

• At a less abstract level, we enter the realm of implementations of Project

Management Methodologies.

(52)

Project Initiation to Project Planning

We now move from the initiation phase to the planning phase of our

projects.

• Initiation processes – project charter, kick-off meeting, stakeholder analysis –