ICTICT403 - Apply Software Development Methodologies: Project Management - 1

ICTICT403 - Apply
Software Development
Methodologies
Project Management - 1
Queensland International Business Academy V2018.1 1

Outline
• Traditional & Non Traditional Methodologies

 Application
 Strengths
 Weaknesses
• Task Types in Methodologies
• Control Structures
• Selection & Effectiveness of Methodologies
• Detailed Discussion of Two Methodologies

Introduction
What is a system?
• An interrelated set of business procedures used within one business
unit working together for a purpose
A system has a number of characteristics:

• Input and Output
• Components and Interrelated Components
• Interfaces
• Constraints
• Purpose
System

Introduction
• What is a method?
a regular and systematic way of accomplishing an objective
• What is a methodology?
the system of principles, practices, and procedures applied to a specific branch of
knowledge

Introduction
What is system development?

• Transition from an idea to a finished product
Then, what is a system development methodology?

• System development methodology in software engineering is a framework that is
used to structure, plan, and control the process of developing an information
system.
What is a life cycle?

• A Life cycle is the course of developmental changes through which a project passes
from its inception to the mature state. It is a progression through a series of
differing stages of development.

Methodologies
• Can be General or Detailed.
• Can be in-house or purchased.
• Can depend on the product type.
• Importantly, a methodology should exist and it should be followed.

Why?
 All necessary activities are accomplished in the correct or desired sequence.
 Documentation is consistent with other projects.
 Documentation has understandable information.

Methodologies, Techniques & Tools

Traditional & Non Traditional
• Traditional?
 Sequential
 Basic
 Structured
• Non-Traditional?
 Evolving
 Iterative
 Customized

Traditional & Non Traditional
• Traditional methods use PREDICTIVE approach:

 Requirements well-defined
 Project well-understood
 Low risk
• Non-traditional methods use ADAPTIVE approach:

 Uncertain requirements
 High risk

Methodologies
• There are similar steps in system creation, regardless of methodology
• All steps need to be considered
• At the MOST basic level, every variation of development methodology would have:
 Planning
 Analysis
 Design
 Implementation

Variations
• Development Methodologies vary based on:
 Phases
 Iteration
 Emphasis on people
 Speed of development

Planning
• Initiation – e.g. Request for Proposal
• Identify problems and opportunities
• Worth solving it?
• What are the benefits?

Analysis
• Feasibility Study
• Technical – can we build it?
• Economic – should we build it?
• Operational – if we build it, will it be used?
• Schedule – will it be ready in time?
• Requirements Definition
• Specification
• Project Plan

Analysis
• The first and most critical phase of the development cycle.
• In all cases, the results of the analysis phase determines

• if there is a problem to be addressed,
• if there is a feasible solution to the problem, and
• if developing a solution to the problem is cost beneficial to the user and to the firm as
a whole.

Discussion
• Surry Hills Pharmacy wants to have a system developed to manage its

inventory.
• The project was initiated and the project was concluded after the analysis
phase.
• Why?

Design
• Logical Design – the external view

• Physical Design – the internal view
• Programming
• Testing

Implementation
• Conversion – the actual use
• Training
• Installation
• Maintenance
• Post Implementation Audit

• Working as promised?
• Achieving Economic benefits?
• Additions needed?

SDLC

Stakeholders
• What are stakeholders?

• People who are interested in the system or project
• People who are benefiting
• Users
• Project Manager: Co-ordinates all resources for the project

• Human resources
• Equipment
• Travel

Stakeholders
• Business Analysts:
• Comprehensively investigates the business
• Documents the findings from that investigation
• Draw supportable conclusions from those findings
• Develop recommendations from those conclusions
• System Analysts:
• Sees the system as a whole
• Designs the system so that it fulfills the requirement
• Detects potential problems early on

Stakeholders
• Programmers
• Develops the system based on user requirements
• Technical Specialists: Hardware engineers, DB engineers, etc

Stakeholders

System Development Life Cycle
• is a traditional systems development technique that is time-tested and easy to

understand
• process-oriented
• uses a series of phases to plan, analyze, design, implement, and support an

information system
• relies on a set of process models to graphically depict the system

Two Approaches
• Traditional Approach - Processes

Waterfall Methodology
Framework Type: Linear
Basic Principles:
1. Project is divided into sequential phases, with some overlap acceptable between
phases.
2. Emphasis is on planning, time schedules, target dates, budgets and

implementation of an entire system at one time.

Tight control is maintained over the life of the project through the use of extensive
written documentation, as well as through formal reviews and approval/signoff by the
user and information technology management occurring at the end of most phases
before beginning the next phase.

INSTALLATION,
TESTING
Waterfall
Strengths:
• Ideal for supporting less experienced project teams and project managers, or project
teams whose composition fluctuates.
• The orderly sequence of development steps and strict controls for ensuring the adequacy
of documentation and design reviews helps ensure the quality, reliability, and
maintainability of the developed software.
• Progress of system development is measurable.
• Conserves resources.

Waterfall
Weaknesses:
• Inflexible, slow, costly and cumbersome due to significant structure and tight controls.
• Project progresses forward, with only slight movement backward.
• Little room for use of iteration, which can reduce manageability if used.
• Depends upon early identification and specification of requirements, yet users may not
be able to clearly define what they need early in the project.

Waterfall
Weaknesses:
• Requirements inconsistencies, missing system components, and unexpected

development needs are often discovered during design and coding.
• Problems are often not discovered until system testing.
• System performance cannot be tested until the system is almost fully coded, and
under-capacity may be difficult to correct.

Waterfall
Weaknesses
• Difficult to respond to changes. Changes that occur later in the life cycle are more costly and are thus
discouraged.
• Produces excessive documentation and keeping it updated as the project progresses is time-
consuming.
• Written specifications are often difficult for users to read and thoroughly appreciate.
• Promotes the gap between users and developers with clear division of responsibility.

Waterfall
Situations where least appropriate:

• Large projects where the requirements are not well understood or are changing for any reasons
such as external changes, changing expectations, budget changes or rapidly changing technology.
• Web Information Systems (WIS) primarily due to the pressure of implementing a WIS project
quickly; the continual evolution of the project requirements; the need for experienced, flexible
team members drawn from multiple disciplines; and the inability to make assumptions regarding
the users’ knowledge level.
• Real-time systems.
• Event-driven systems.
• Leading-edge applications.

Waterfall
Situations where most appropriate:
• Project is for transaction-oriented system.
• Project is large, expensive, and complicated.
• Project has clear objectives and solution.
• Pressure does not exist for immediate implementation.

Waterfall
• Project requirements can be stated unambiguously and comprehensively.
• Project requirements are stable or unchanging during the system development life
cycle.
• User community is fully knowledgeable in the business and application.
• Team members may be inexperienced.

Waterfall
• Team composition is unstable and expected to fluctuate.
• Project manager may not be fully experienced.
• Resources need to be conserved.
• Strict requirement exists for formal approvals at designated milestones.

Spiral Methodology
Framework Type: Combination Linear and Iterative
Basic Principles:
• Focus is on risk assessment and minimizing project risk by breaking it into smaller
segments and providing more ease of change during the development process, as well
as providing the opportunity to evaluate risks and weigh consideration of project
continuation throughout the life cycle.

Spiral
• “Each cycle involves a progression through the same sequence of steps, for each
portion of the product and for each of its levels of elaboration, from an overall
concept-of-operation document down to the coding of each individual program.”
(Boehm, 1986)
• Begin each cycle with an identification of stakeholders and their win conditions,
and end each cycle with review and commitment. (Boehm, 2000)
• Each trip around the spiral traverses four basic quadrants:
• Determine objectives, alternatives, and constraints of the iterations
• Evaluate Alternatives; identify and resolve risks
• develop and verify deliverables from the iteration; and
• plan the next iteration. (Boehm, 1986 and 1988)
Spiral

Spiral
Strengths
• Enhances risk avoidance.
• Useful in helping to select the best methodology to follow for development of a given
software iteration, based on project risk.

Spiral
• Weaknesses:
• Challenging to determine the exact composition of development
methodologies to use for each iteration around the Spiral.
• Highly customized to each project, and thus is quite complex
• An experienced project manager is required to apply it to any given situation.
• There are no established controls for moving from one cycle to another cycle.
Without controls, each cycle may generate more work for the next cycle
• There are no firm deadlines. Cycles continue with no clear termination
condition, and there is an inherent risk of not meeting budget or schedule.
• Possibility exists that it ends up following Waterfall method

Spiral
• Real-time or safety-critical systems.
• Risk avoidance is a high priority.
• Minimizing resource consumption is not an absolute priority.
• Project manager is highly skilled

Spiral
• Requirement exists for strong approval and document control.
• Project might benefit from a mix of other methodologies
• A high degree of accuracy is essential
• Implementation has priority over functionality, which can be added in later versions
Spiral
Situations where least appropriate:
• Risk avoidance is a low priority.
• A high degree of accuracy is not essential
• Functionality has priority over implementation.
• Minimizing resource consumption is an absolute priority

Prototyping
Framework Type: Iterative

Basic Principles
• Not a standalone, complete, development methodology, but rather an

approach to handling selected portions of a larger, more traditional
development methodology
• Attempts to reduce inherent project risk by breaking a project into

smaller segments and providing more ease-of-change during the
development process.

Prototyping
Basic Principles
• User is involved throughout the process, which increases the likelihood of user-acceptance of the final
implementation.
• Small-scale mock-ups of the system are developed following an iterative modification process until the
prototype evolves to meet the users’ requirements.
• While most prototypes are developed with the expectation that they will be discarded, it is possible in some
cases to evolve from prototype to working system.
• A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problem.

Prototyping

Prototyping

Prototyping
Strengths
• “Addresses the inability of users to specify their information needs, and the difficulty of
systems analysts to understand the user’s environment, by providing the user with a
tentative system for experimental purposes at the earliest possible time.” (Janson and
Smith, 1985)
• “Can be used to realistically model important aspects of a system during each phase of
the traditional life cycle.” (Huffaker, 1986)
• Improves both user participation in system development and communication among

project stakeholders

Prototyping
• Especially useful for resolving unclear objectives
• Potential exists for exploiting knowledge gained in an early iteration as later iterations are
developed.
• Helps to easily identify confusing or difficult functions and missing functionality.
• Encourages innovation and flexible designs.
• Provides quick implementation of an incomplete, but functional application

Prototyping
Weaknesses
• Approval process is not strict
• Incomplete problem analysis may occur where only the most obvious and superficial
needs will be addressed, resulting in current inefficient practices being easily built into the
new system.
• Requirements may frequently change significantly.
• Identification of non-functional elements is difficult to document

Prototyping
Weaknesses
• Designers may prototype too quickly, without sufficient user-analysis, resulting in an
inflexible design with narrow focus that limits future system potential
• Designers may neglect documentation, resulting in insufficient justification for the

final product and inadequate records for the future.
• Can lead to poorly designed systems.
• Unskilled designers may substitute prototyping for sound design

Prototyping
Weaknesses
• Can lead to false expectations, where the customer mistakenly
believes that the system is “finished” when in fact it is not
• Iterations add to project budgets and schedules, thus the added costs
must be weighed against the potential benefits.
• Prototype may not have sufficient checks and balances incorporated.

Incremental
• A series of mini-Waterfalls are performed, where all phases of the Waterfall

model are completed for a small part of the system OR
• Overall requirements are defined before proceeding to mini-Waterfall

strategy OR
• The initial software concept, requirements analysis, and design of

architecture defined using the Waterfall approach, followed by iterative
prototyping

Incremental
Strengths:
• Moderate control is maintained over the life of the project through the use of written documentation
• Stakeholders can be given concrete evidence of project status throughout the life cycle.
• Helps to mitigate integration and architectural risks earlier
• Allows delivery of a series of implementations that are gradually more complete and can go into
production more quickly as incremental releases.
• Gradual implementation provides the ability to monitor the effect of incremental changes and make
adjustments before the impact is negative

Incremental
Weaknesses
• Lack of overall consideration of the business when working on a small part of the system
using waterfall.
• Since some modules will be completed much earlier than others, well-defined interfaces
are required.
• Difficult problems tend to be pushed to the future to demonstrate success to management.

Rapid Application Development
• Objective is fast development and delivery of high quality system at low cost
• Reduces risk by breaking project into smaller chunks
• Uses iterative prototyping and active user involvement
• Emphasis on fulfilling business need and software engineering excellence is not considered
• Emphasis on meeting deadlines even if requirements need to be cut

Strengths
• Operational version available much earlier than other models
• Lower cost
• Clients gain sense of ownership and developers a sense of satisfaction due to client
interaction
• User viewpoint
• Ability to change requirements quickly
• Tighter fit between requirements and specifications

Weaknesses
• Quality affected by lower cost and faster speed
• May end up with more requirements than specified
• Gold plating
• Potential for inconsistent designs
• High cost of commitment from clients
• Formal reviews difficult

Control Structure - Reviews
Each phase of the life cycle, and in some cases each step within each phase should
result in a review of the completed products whether they are narratives, models,
or cost spreadsheet.
Reviews may be:

• formal or informal
• By management , peers or users
• by oral presentation, demonstration, formal document submission or a combination of all
three
• interim, checkpoint, milestone or decision point
• overview or in-depth

Reviews
• Reviews are an important part of the life cycle.
• Reviews are intended to catch flaws in logic, perception or design, and to

recommend appropriate corrective actions.
• What is meant by Review?

 To review is to study or examine again. To consider retrospectively. To examine with an
eye to correction or criticism To subject to formal inspection.

Reviews
• What is a Review?
 A review is a reexamination or reconsideration.. A retrospective view or survey. An
inspection or examination with the intention of evaluating
• All reviews should result in an approval of the finished or submitted

product. The approved product should form the basis for continued work

Review Characteristics
• The review should be facilitated, or lead, by a neutral party,

someone not involved in the project.
• Reviews should be attended by people who have been associated

with the project, but not necessarily with the development of the
product under review.
• The draft product(s) to be reviewed should be distributed to the

reviewers before the actual review session to allow to for them to
study the materials and formulate any questions.
• The goals of the review should be clearly stated and all reviewers should be
reminded that the goal of the review is to find any flaws or errors in the materials.
• Reviewers who make comments in their copy of the materials should return the
copy with the comments to the submitter.
• Each comment, criticism, and suggestion should be written on a review item form,
given an identifier and logged.
• Each comment, criticism and suggestion should be evaluated by the submitter and
the action (or non-action) taken should be noted on the written form. A reason
should given if a comment, criticism or suggestion is ignored.

• Each comment, criticism, and suggestion should be written on a review item form, given an identifier and logged.
• Each comment, criticism and suggestion should be evaluated by the submitter and the action (or non-action) taken
should be noted on the written form. A reason should given if a comment, criticism or suggestion is ignored.
• Each reviewer should be sent a copy of the final product with all changes noted and the completed review item
forms
• If the review was based on a demonstration the final product should be re-demonstrated for reviewers with any
changed identified.
• The final product review should be accompanied by an approval sheet which should be signed or initialed by the
reviewers indicating their approval or disapproval.
• The approved product, along with any reviewer notes and comments, all approval sheets, and all completed review
item forms , should be filed for reference as part of the project documentation

Reviews
• Although reviews are time consuming and take a great deal of effort to prepare
and conduct, each review will catch a certain number of product flaws.
• The earlier a flaw is caught the less damage it will cause to the project schedule.
• The longer a flaw remains undetected the greater the degree of effort it will take
to correct it.
• Flaws in the products of the project scope determination, requirements

identification, alternative approach identification and selection, project schedule
preparation, and staffing and resource allocation activities will have far-reaching
impact on the project.

Reviews
• The larger the project the greater the impact of an undetected flaw and the more
critical the early reviews become.
• Frequent reviews will prevent a project from deviating from its schedule, and from
losing sight of its goals. Many projects go off on tangents, follow divergent paths
misinterpret user requirements and management directives without realizing it.
• Reviews force the project team to focus on the goals, clarify their direction and
approach. Reviews provide the frequent project corrections needed to ensure a
successful completion of all activities. They also help to ensure that the user, and the
firm get what is needed in the way of a new system, or new business processes.
AGILE
• Agile software development refers to a group of based on iterative

software development methodologies development, where requirements
and solutions evolve through collaboration between self-organizing cross-
functional teams.
• Started in 2001

AGILE
• Agile methods generally promote a project management process that

encourages frequent inspection and adaptation, a leadership philosophy
that encourages teamwork, self-organization and accountability, a set of
engineering best practices that allow for rapid delivery of high-quality
software, and a business approach that aligns development with customer
needs and company goals.

Agile
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile
• Each iteration is worked on by a team through a full software development

cycle, including planning, requirements analysis, design, coding, unit
testing, and acceptance testing when a working product is demonstrated to
stakeholders.
• This helps minimize overall risk, and lets the project adapt to changes
quickly.
• Stakeholders produce documentation as required.
• An iteration may not add enough functionality to warrant a market release,
but the goal is to have an available release (with minimal bugs) at the end of
each iteration
Agile
• Agile methods emphasize face-to-face communication over written documents when the
team is all in the same location
• No matter what development disciplines are required, each agile team will contain a
customer representative. This person is appointed by stakeholders to act on their behalf and
makes a personal commitment to being available for developers to answer mid-iteration
problem-domain questions.
• Agile emphasizes working software as the primary measure of progress.
• Lightweight
Agile

Extreme Programming
• One of the approaches in AGILE
• Rules of Engagement
 Similar to those of AGILE in general
• Rules of Play
 Continuous Testing
 Clearness of code
 Common Vocabulary
 Authority for everybody

ICTICT403 - Apply Software Development Methodologies: Project Management - 1

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ICTICT403 - Apply Software Development Methodologies: Project Management - 1

Caricato da

Copyright:

Formati disponibili

ICTICT403 - Apply

Queensland International Business Academy V2018.1 1

• Traditional & Non Traditional Methodologies

• Task Types in Methodologies

• Selection & Effectiveness of Methodologies

• Detailed Discussion of Two Methodologies

A system has a number of characteristics:

Queensland International Business Academy V2018.1 4

Queensland International Business Academy V2018.1 5

What is system development?

Then, what is a system development methodology?

What is a life cycle?

Queensland International Business Academy V2018.1 6

• Can be General or Detailed.

• Can be in-house or purchased.

• Can depend on the product type.

• Importantly, a methodology should exist and it should be followed.

Queensland International Business Academy V2018.1 7

Queensland International Business Academy V2018.1 8

Queensland International Business Academy V2018.1 9

• Traditional methods use PREDICTIVE approach:

• Non-traditional methods use ADAPTIVE approach:

Queensland International Business Academy V2018.1 10

• There are similar steps in system creation, regardless of methodology

• All steps need to be considered

Queensland International Business Academy V2018.1 11

• Development Methodologies vary based on:

Queensland International Business Academy V2018.1 12

• Initiation – e.g. Request for Proposal

• Identify problems and opportunities

• Worth solving it?

• What are the benefits?

Queensland International Business Academy V2018.1 14

• The first and most critical phase of the development cycle.

• In all cases, the results of the analysis phase determines

Queensland International Business Academy V2018.1 15

• Surry Hills Pharmacy wants to have a system developed to manage its

Queensland International Business Academy V2018.1 16

• Logical Design – the external view

Queensland International Business Academy V2018.1 17

• Conversion – the actual use

• Post Implementation Audit

Queensland International Business Academy V2018.1 18

Queensland International Business Academy V2018.1 19

• What are stakeholders?

• Project Manager: Co-ordinates all resources for the project

Queensland International Business Academy V2018.1 20

Queensland International Business Academy V2018.1 21

• Technical Specialists: Hardware engineers, DB engineers, etc

Queensland International Business Academy V2018.1 22

Queensland International Business Academy V2018.1 23

• is a traditional systems development technique that is time-tested and easy to

• uses a series of phases to plan, analyze, design, implement, and support an

• relies on a set of process models to graphically depict the system

Queensland International Business Academy V2018.1 24

• Traditional Approach - Processes

Queensland International Business Academy V2018.1 25

Framework Type: Linear

2. Emphasis is on planning, time schedules, target dates, budgets and

Queensland International Business Academy V2018.1 26

Queensland International Business Academy V2018.1 27

• Progress of system development is measurable.