SOFTWARE PROJECT DEVELOPMENT

METHODOLOGY

INTRODUCTION

A software development methodology is a framework that is used to

structure, plan, and control the process of developing an information system
- this includes the pre-definition of specific deliverables and artifacts that are
created and completed by a project team to develop or maintain an
application.

DIFFERENT TYPES OF METHODOLOGY WHICH

INCLUDES

 Waterfall Methodology

 Spiral Methodology
 Capability Maturity Model Integration (CMMI)
 Prototyping approach
 Incremental approach
 Rapid application development methodology
 SSADM
 JSP
 Object oriented system development methodology
 Disco specification method
Waterfall Methodology

All projects can be managed better when segmented into a hierarchy

of chunks such as phases, stages, activities, tasks and steps. In system
development projects, the simplest rendition of this is called the "waterfall"
methodology, as shown in the following figure:

Nevertheless, the graphic illustrates a few critical principles of a

good methodology:

• Work is done in stages,

• Content reviews are conducted between stages, and
• Reviews represent quality gates and decision points for continuing.

The waterfall provides an orderly sequence of development steps and

helps ensure the adequacy of documentation and design reviews to ensure
the quality, reliability, and maintainability of the developed software. While
almost everyone these days disparages the "waterfall methodology" as being
needlessly slow and cumbersome, it does illustrate a few sound principles of
life cycle development.

Spiral Methodology

The spiral methodologies reflect the relationship of tasks with rapid

prototyping, increased parallelism, and concurrency in design and build
activities. The spiral method should still be planned methodically, with tasks
and deliverables identified for each step in the spiral.

Software quality, reliability, and maintainability are enhanced by

having good documentation for requirements, architecture, interfaces,
detailed design, well-commented code, and good test procedures.
Requirements documentation practices should facilitate your customer's
understanding and review of the real requirements. Software project
planning should include estimating the time and resources to produce,
review, approve, and manage such documentation products.

Sample Software Documentation Work Products

Capability Maturity Model Integration (CMMI)

The Software Engineering Institute at Carnegie Mellon Institute in
Pittsburgh established standards and guidance for developing software
engineering disciplines and management. This was known as the Capability
Maturity Model (CMM), and its use has become widespread among mature
software development organizations, especially for that developing large
scale software in a competitive procurement environment. Government and
corporate software customers have increasingly required that proposals
include information about a software development organization's certified
level of maturity.

The CMM had recognized five steps towards organizational software

maturity:
 • Level 1 (Initial) - Processes are ad hoc and occasionally chaotic. Few
processes are defined, and success depends on individual effort and
heroics. (A Street-person with a laptop would be at Level 1.)
• Level 2 (Repeatable) - Basic project management processes are
established to track cost, schedule and functionality. A process
discipline is in place to repeat earlier successes on projects with
similar applications.
• Level 3 (Defined) - Management and engineering processes are
documented and integrated into a standard software process. Projects
use an approved, tailored version of the organization’s standard
software process.
• Level 4 (Managed) - Detailed measures of the software process and
product quality are collected. Processes and products are
quantitatively understood and controlled.

• Level 5 (Optimizing) - Continuous process improvement is

aided by quantitative feedback from the process and from piloting
innovative ideas and technologies.

Prototyping Approach
Software prototyping is the development approach of activities during
software development the creation of prototypes, i.e., incomplete versions of
the software program being developed.

Basic principles of the Prototyping Approach are

• Not a standalone, complete development methodology approach, but

rather an approach to handling selected portions of a larger, more
 traditional development methodology (i.e. Incremental, Spiral, or
Rapid Application Development (RAD)) approaches.
• Attempts to reduce inherent project risk by breaking a project into
smaller segments and providing more ease-of-change during the
development process.
• User is involved throughout the development 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.

Incremental Approach

Various methods are acceptable for combining linear and iterative

systems development methodology approaches, with the primary objective
of each being to reduce inherent project risk by breaking a project into
smaller segments and providing more ease-of-change during the
development process.

Basic principles of the incremental development approach are

 • A series of mini-Waterfalls are performed, where all phases of the
Waterfall development approach are completed for a small part of the
systems, before proceeding to the next incremental.
• Overall requirements are defined before proceeding to evolutionary,
mini-Waterfall development approaches of individual increments of
the system.
• The initial software concept, requirements analysis, and design of
architecture and system core are defined using the Waterfall approach,
followed by iterative Prototyping approach, which culminates in
installation of the final prototype (i.e., working system).

Rapid Application Development (RAD) Approach

Rapid Application Development (RAD) is a software development

methodology approach, which involves iterative development and the
construction of prototypes. Rapid application development is a term
originally used to describe a software development process introduced by
James Martin in 1991.

Basic principles:

• Key objective is for fast development and delivery of a high quality

system at a relatively low investment cost.
• Attempts to reduce inherent project risk by breaking a project into
smaller segments and providing more ease-of-change during the
development process.
• Aims to produce high quality systems quickly, primarily through the
use of iterative Prototyping (at any stage of development), active user
 involvement, and computerized development tools. These tools may
include Graphical User Interface (GUI) builders, Computer Aided
Software Engineering (CASE) tools, Database Management Systems
(DBMS), fourth-generation programming languages, code generators,
and object-oriented techniques.
• Key emphasis is on fulfilling the business need, while technological
or engineering excellence is of lesser importance.
• Project control involves prioritizing development and defining
delivery deadlines or “time boxes”. If the project starts to slip,
emphasis is on reducing requirements to fit the time box, not in
increasing the deadline.
• Generally includes Joint Application Development (JAD), where
users are intensely involved in system design, either through
consensus building in structured workshops, or through electronically
facilitated interaction.
• Active user involvement is imperative.
• Iteratively produces production software, as opposed to a throwaway
prototype.
• Produces documentation necessary to facilitate future development
and maintenance.
• Standard systems analysis and design techniques can be fitted into this
framework.

Structured Systems Analysis and Design Methodology (SSADM)

Structured Systems Analysis and Design Methodology (SSADM) is a

systems approach to the analysis and design of information systems.
 System design methods are a discipline within the software
development industry which seeks to provide a framework for activity and
the capture, storage, transformation and dissemination of information so as
to enable the economic development of computer systems that are fit for
purpose.
Objective of SSADM
SSADM was developed with the following objectives
• Ensure that projects can successfully continue should a loss of staff occur
without a damaging effect on the project
• Develop overall better quality systems
• Improve the way in which projects are controlled and managed
• Allow more effective use of experienced and inexperienced staff and their
development
• Make it possible for projects to be supported by computer based tools e.g.
computer-aided software engineering systems
• Improve communication between participants in a project so an effective
framework is in place
Benefits of SSADM
• Timelines
• Usability
• Respond to changes in the business environment
• Effective use of skills
• Better quality
• Improvement of productivity
Disadvantages of SSADM
SSADM puts special emphasis on the analysis of the system and its
documentation. This causes the danger of over-analyzing, which can be very
time and cost consuming. Due to various types of description methods,
checks of consistence cannot be carried out.
Especially with large systems, the outline diagram can become very
unclear, because all relevant data flows have to be included.
SSADM techniques
Logical Data Modeling
Data Flow Modeling
Entity Behavior Modeling
Steps used in SSADM
1. Feasibility study
2. Requirements
3. Requirements Specification
4. Logical System Specification
5. Physical design

Object oriented system development methodology

The development of a software system is usually just a part of finding

a solution to a larger problem. The larger problem may entail the
development of an overall system involving software, hardware,
procedures, and organizations.
Here are some of the benefits of the object-oriented approach:

Reduced Maintenance: The primary goal of object-oriented development

is the assurance that the system will enjoy a longer life while having far
smaller maintenance costs. Because most of the processes within the system
are encapsulated, the behaviors may be reused and incorporated into new
behaviors.

Real-World Modeling: Object-oriented system tends to model the real

world in a more complete fashion than do traditional methods. Objects are
organized into classes of objects, and objects are associated with behaviors.
The model is based on objects, rather than on data and processing.

Improved Reliability and Flexibility: Object-oriented system promise to

be far more reliable than traditional systems, primarily because new
behaviors can be "built" from existing objects. Because objects can be
dynamically called and accessed, new objects may be created at any time.
The new objects may inherit data attributes from one, or many other
objects. Behaviors may be inherited from super-classes, and novel
behaviors may be added without effecting existing systems functions.

High Code Reusability: When a new object is created, it will automatically

inherit the data attributes and characteristics of the class from which it was
spawned. The new object will also inherit the data and behaviors from all
super classes in which it participates. When a user creates a new type of a
widget, the new object behaves "weighty", while having new behaviors
which are defined to the system.
The downside of the Object Technology

There are several major misconceptions which must be addressed when

considering the use of an object-oriented method:

Object-oriented Development is not a panacea - Object-oriented

Development is best suited for dynamic, interactive environments, as
evidenced by its widespread acceptance in CAD/CAM and engineering
design systems. Wide-scale object-oriented corporate systems are still
unproved, and many bread-and-butter information systems applications (i.e.
payroll, accounting), may not benefit from the object-oriented approach.

Object-oriented Development is not a technology - Although many

advocates are religious in their fervor for object-oriented systems, remember
that all the "HOOPLA" is directed at the object-oriented approach to
problem solving, and not to any specific technology.

Object-oriented Development is not yet completely accepted by major

vendors - Object-oriented Development has gained some market
respectability, and vendors have gone from catering to a "lunatic fringe" to a
respected market. Still, there are major reservations as to whether Object-
oriented development will become a major force, or fade into history, as in
the 1980's when Decision Support Systems made great promises, only to
fade into obscurity.
Disco specification method

A central part of the methodology is the DisCo specification language.

There are two major versions of the language. When the version matters in
the documentation, we refer to the different versions as DisCo92 and
DisCo98, respectively. The DisCo Toolset distribution (see below) includes
a language specification document of the version supported by the
accompanying compiler.

DisCo in a Nutshell
DisCo (Distributed Co-operation) is a formal specification method for
reactive systems. It incorporates a specification language, a methodology for
developing specifications using the language, and tool support for the
methodology. Currently the support tools include an animation facility for
executing specifications, a tool for visualizing execution histories as
scenarios, and a link to a mechanical theorem proved for verification.

The method has a solid formal basis but the specification language
uses concepts and notations familiar to people with a conventional software
engineering background. To get a taste of DisCo see the distributed sort and
other examples.

DisCo focuses on early verification and validation of behavioral

properties. Emphasis is on collective behavior, rather than on behavior of
individual objects. The joint action model of execution enables modeling of
behavior at a high level of abstraction. In particular, collective behavior can
be specified without fixing the interfaces of objects and without indicating
which objects initiate communication.
Examples of DisCo Specifications

Distributed sort with termination detection (DisCo92). This example

includes a Java applet that illustrates animation of DisCo specifications.

• Distributed sort (DisCo98).

• Taxi cabs.
• Seat reservation system.
• Mobile robot case study.
• Verifying a real-time DisCo specification using Kronos.
• Distributed water tanks.

Jackson Structured Programming (JSP)

Jackson Structured Programming (JSP) was the first software

development method that Jackson developed. It is a program design method,
and was described in his book Principles of Program Design. JSP covers the
design of individual programs, but not systems.

The Jackson System Development (JSD) was the second software

development method that Jackson developed. JSD is a system development
method not just for individual programs, but for entire systems. JSD is most
readily applicable to information systems, but it can easily be extended to
the development of real-time embedded systems.

The strength of Jackson Program Design lies in its description of what a

program is to do. Its basic characteristics that give it advantages in its
systematic approach include:
 • Rational- based on reasonable principles, well developed and well
defined: structured programming (iteration, selection, sequence).

• Teachable- it has a well set of defined steps, it is possible to explain and

show how this system is applied and how it works.

• CONSISTENT- given a single problem for analysis, different

programmers or analysts will come up with more or less the same
program design.

• SIMPLE- the method does not involve overly complex rules,

cumbersome procedures or difficult notations to remember.

• UNIVERSAL- specifications are produced that can be implemented in

the language the developer desires.

Implementation of JSP
Jackson Workbench is a CASE tool for implementing Jackson design
methods. It contains an intuitive JSP Structure Editor for implementing the
Jackson Structured Programming (JSP) method and a JSD Network Editor
for implementing the Jackson System Development (JSD) method. In this
illustrate JSP using the Jackson Structure Editor.
The JSP Structure Editor is well documented in the Help provided as well as
in examples that show how to generate Java code using the overall header,
header, and trailer features. One of the main strengths of the Structure Editor
is its “smart” editing feature. Use of Jackson Workbench to design the
following simple program is illustrated in the following pages:
Multiplication Problem Statement:
The basic design method can be illustrated by the following example: The
lower- left triangle of a multiplication table is to be generated and printed.
The required output is:
1
24
369
4 8 12 16
5 10 15 20 25
6 12 18 24 30 36
7 14 21 28 35 42 49
8 16 24 32 40 48 56 64
9 18 27 36 45 54 63 72 81
10 20 30 40 50 60 70 80 90 100
Step 1 Draw system diagram. (This step is omitted since it is obvious.)
Step 2 Draw data structures for program input(s) and output(s). In our
example, we only have the output to consider. First, we open a new JSP file
and name it The JSP Structure Editor produces the initial structure shown in
Figure.

Initial structure produced by Jackson Workbench

Double-clicking on the box labeled Dummy causes the label to be

surrounded by a white rectangle, indicating that the text can be selected and
over-written. Replacing Dummy with row as the label, and preparing to
change type to iteration: dragging the mouse to the upper right-hand corner
causes “Change box type” to appear. Clicking the mouse will cause the
symbol for an iterated component to appear in the upper-right corner of the
box.
Moving the mouse to bottom of box labeled “row” in order to add a
sub-tree causes a "hotspot" image to appear just below, indicating that a new
sub-tree can be added by positioning the mouse over the “hotspot" and left-
clicking. A new sub-tree is added after clicking the small rectangle centered
below the iterated row component row. We complete the data structure for
multiplication table by labeling the new sub-tree with “element” and
changing the box type to an iterated component.
Step 3 Form program structure based on the data structures from the
previous step by adding verbs to each component to make them actions.
Step 4 List and allocate operations we list the elementary operations needed
to perform the task, and answer for each operation, "How often is it
executed?" and "In what program component(s) does it belong?" The
operations must be elementary statements of some programming language;
we have chosen Java.
# OPERATION HOW WHERE
OFTEN
1 MAX=10; Once at start
2 row=1; Once at start
3 Col=1 once per in component that
row produces a table row, at
start of component
4 row++; 9 times in component that
produces a table row, at
end of component
5 Col ++; 55 times in component that
produces a table element,
at end of
 component
6 element = once per in component that
row*col;
element produces a table element
7 System.out.print( 55 times in component that
element); produces a table element

Note: Although Jackson Workbench is not used in this step, we include the
table of operations in order to make subsequent steps intelligible.
Step 5 Create the elaborated program structure with operations and
conditions added to the basic program structure. After having created a table
containing a list of operations needed together with the number of times
each occurs and in what component each appears, we are ready to create the
elaborated program structure from the basic program structure. We click the
Bars on the menu bar, and click Add Operation.
The Operations status box (lower right) adds the 1st operation, and a
space opens up under Add Operations to add the 1st operation. We type
MAX=10. At this point, we must insert a new level into the structure
diagram. We wish to allocate the 1st operation at the start as the leftmost leaf
of the root node. But, since the root is iteration, we must convert it first into
a sequence consisting of our 1st operation and a component, Generate rows,
iteration with one component, Generate row. (Otherwise, we would have
under the root our 1st operation followed by a component that repeats – and
the root would be neither a sequence nor an iteration - it would be a badly-
formed component. We first position the mouse just under the root, and
when a small box appears, click on it to create a new box under the root. We
then slide the mouse on the arc connecting the root to the new box, and
move it left: a small box will appear and, if we click on it, we create the box
as a left sibling of the new box under the root.
After we click on the empty box, we allocate the 1st operation to the
leftmost box, by dragging the 1 from the Operation box (lower right) into the
leftmost leaf of our root. Then, we add a label to the new box to its right.
Next, we will add a condition to our program structure. The condition
for continuing the iteration, Generate rows, is that row is less than equal to
MAX (we model iteration using a while construction here).
We click Add Condition, and a space opens up under the Add
Condition menu bar on the left, and a 1 appears in the Condition bar (lower
right). We add the condition, row <= MAX. Then, we drag the 1 to the
Generate row box. We complete the elaborated program structure by adding
other operations and conditions.

Elaborated program structure

To generate a Java program, we need to add the class header as the

overall header, the header for main as the header together with primitive
type declarations, and a trailer consisting of a right curly brace, }.
 The Java program together with its output generated from the
elaborated program structure is shown below

Generated Java code

Our best hope for producing better software is to enforce a software

engineering discipline that focuses on problem analysis and design. In this
illustrated the use of Jackson Workbench and JSP to inculcate students from
the outset with a software engineering approach to designing programs.

A subsequent part of this pedagogy continues with the design of

information systems using Jackson System Development (JSD) – it is
object-based and uses the design techniques of JSP – in conjunction with the
Network Editor of Jackson Workbench. Jackson Workbench and Jackson
methodology (JSP and JSD) could form a promising introductory software
engineering curriculum.

THE BRITISH STANDARDS FOR

QUALITY MANAGEMENT SYSTEMS

A company or organization that has been independently audited and

certified to be in conformance with ISO 9001 may publicly state that it is
"ISO 9001 certified" or "ISO 9001 registered". Certification to an ISO 9001
standard does not guarantee any quality of end products and services; rather,
it certifies that formalized business processes are being applied.

Versions

ISO 9000:1994 emphasized quality assurance via preventive actions, instead

of just checking final product, and continued to require evidence of
compliance with documented procedures.

ISO 9000:1987 had the same structure as the UK Standard BS 5750, with
three 'models' for quality management systems, the selection of which was
based on the scope of activities of the organization:

ISO 9001:1987 Model for quality assurance in design, development,

production, installation, and servicing was for companies and organizations
whose activities included the creation of new products.

ISO 9002:1987 Model for quality assurance in production, installation, and

servicing had basically the same material as ISO 9001 but without covering
the creation of new products.
ISO 9003:1987 Model for quality assurance in final inspection and test
covered only the final inspection of finished product, with no concern for
how the product was produced.

ISO 9001:2000 combines the three standards 9001, 9002, and 9003 into one,
called 9001. Design and development procedures are required only if a
company does in fact engage in the creation of new products.

ISO 9001:2008 only introduces clarifications to the existing requirements of

ISO 9001:2000 and some changes intended to improve consistency with ISO
14001:2004. There are no new requirements. Explanation of changes in ISO
9001:2008 a quality management system being upgraded just needs to be
checked to see if it is following the clarifications introduced in the amended
version.

References:

http://en.wikipedia.org/wiki/ISO_9001#Contents_of_ISO_9001

http://www.hyperthot.com/pm_sdm.htm

http://www.itmweb.com/methodology/

http://en.wikipedia.org/wiki/Software_development_methodology
 ASSIGNMENT

ON

SOFTWARE PROJECT

MANAGEMENT

BY
P.ISWARYA
II MSC CS)
 CONTENTS

♦ INTRODUCTION
♦ TYPES OF METHODOLOGY
♦ IMPLEMENTATION OF JSP
♦ BS IN QUALITY MANAGEMENT
♦ REFERENCES