SDLC Processes

THE SOFTWARE PROCESS is a coherent set of activities for analyzing, designing, implementing and
testing software systems. A structured set of activities required to develop a software system. A
software process model is an abstract representation of a process. It presents a description of a
process from some particular perspective. There are four main processes ( Software Specifications,
Design, Validation and Evolution) which can also be broken down into the following:
> Analysis: determining what the software will do
> Design: how will the system accomplish it
> Implementation: writing code
> Validation: finding errors
> Evolution: modifying the software
THE NEED FOR A STRUCTURED SOFTWARE DEVELOPMENT PROCESS
1. Increased Dependence of many organizations on their computer system: In all industrialized

countries, and increasingly in developing countries, computer systems are economically critical.
More and more products incorporate computers in some form. Educational, administrative and
health care systems are dependent on computer systems. The software in these systems represents a
large and increasing proportion of the total system costs. The effective functioning of modern
economic and political systems therefore depends on the ability to produce software in a cost
effective way.
2. Crises in previous developments: A "large" software system is a system that contains more than
50,000 lines of high-level language code. With large software development projects, the work is
done in teams consisting of project managers, requirements analysts, software engineers,
documentation experts, and programmers. Conflicting requirements have always hindered the
software development process. For example, while users demand a large number of features,
customers generally want to minimize the amount they must pay for the software and the time
required for its development. The causes of the software crisis were linked to the overall complexity
of the software process and the relative immaturity of software engineering as a profession.
 Dissatisfaction of users and management with the quality and suitability of the software: Three
quarters of all large software products delivered to the customer are failures that are either not
used at all, or do not meet the customer’s real needs or requirements. This is so because software
development is often undertaken with only a vague notion of the customer’s requirements.
Many software efforts have failed because developers lack the essential formal and detailed
description on data, functionality, design constraint and validation criteria, which can be
accessed through frequent communication between developers and customers.
 Increasing length and complexity of the software: Another problem that still exists in software
development is the time taken to develop software. Software developers regularly underestimate
how long it takes to design, write and test their software. Mostly, this problem still exists
because developers are trying to produce massive software products with old tools, outdated
methods and inadequate management techniques. Sometimes, the assumptions made is that, if
the software is behind schedule, more programmers can be added and thus hasten the process.
Adding people to a late software project makes it later. Another contributing factor to the time
factor is that project requirements continually changes. The impact of change will vary
according to when it was introduced.
3. Requirements for standard interfaces:

 The structure principle. Your design should organize the user interface purposefully, in
meaningful and useful ways based on clear, consistent models that are apparent and recognizable
to users, putting related things together and separating unrelated things, differentiating dissimilar
things and making similar things resemble one another. The structure principle is concerned with
your overall user interface architecture.
 The simplicity principle. Your design should make simple, common tasks simple to do,
communicating clearly and simply in the user’s own language, and providing good shortcuts that
are meaningfully related to longer procedures.
 The visibility principle. Your design should keep all needed options and materials for a given
task visible without distracting the user with extraneous or redundant information. Good designs
don’t overwhelm users with too many alternatives or confuse them with unneeded information.
 The feedback principle. Your design should keep users informed of actions or interpretations,
changes of state or condition, and errors or exceptions that are relevant and of interest to the user
through clear, concise, and unambiguous language familiar to users.
 The tolerance principle. Your design should be flexible and tolerant, reducing the cost of
mistakes and misuse by allowing undoing and redoing, while also preventing errors wherever
possible by tolerating varied inputs and sequences and by interpreting all reasonable actions
reasonable.
 The reuse principle. Your design should reuse internal and external components and behaviors,
maintaining consistency with purpose rather than merely arbitrary consistency, thus reducing the
need for users to rethink and remember.
4. Need for Tighter Control of Management Processes:

 Different organizations use different processes to produce the same type of product. Different
types of product may be produced by an organization using different processes. However, some
processes are more suitable than others for some types of application. If the wrong process is
used, this will probably reduce the quality of or the usefulness of the software product to be
developed.
 Because there is a variety of different process models used, it is impossible to produce reliable
figures for cost distribution across these activities. However, modifying software usually takes
up more than 60% of total software costs. This percentage is increasing as more and more
software is produced and has to be maintained.
 Software processes are complex and involves a very large number of activities. These activities
need to be managed appropriately and efficiently.
Consider the following:
PROCESS CHARACTERISTICS
Characteristic Definition
Understandability To what extent is the process explicitly defined
and how easy is it to understand to process
definition?
Visibility Do the process activities culminate in clear

results so that the progress of the process is
externally visible?
Supportability To what extent can the process activities be

supported by CASE tools?
Acceptability Is the defined process acceptable to and usable

by the engineers responsible for producing the
software product?
Reliability Is the process designed in such a way that

process errors are avoided or trapped before
they result in product errors?
Robustness Can the process continue in spite of

unexpected problems?
Maintainability Can the process evolve to reflect changing

organizational requirements or identified
process improvements?
Rapidity How fast can the process of delivering a

system form a given specification be
completed?
NEED FOR VISIBILITY
Because of the intangible nature of software systems, software process managers need
documents, reports and reviews to keep track of what is going on. Each activity must end with
the production of some document. These documents make the software process visible.
However, regular document production has some drawbacks:
1. Management needs regular deliverables to assess project progress: The timing of management
requirements may not correspond with the time needed to complete an activity. Extra documents
may have to be produced adding to the cost of the process.
2. The need to approve document constrains process iterations: The cost of going back and adapting a
complete deliverable are high. If the problems are discovered during the process, inelegant
solutions are sometimes adopted to avoid the need to change ‘accepted’ project deliverables.
3. The time required to review and approve a document is significant: is rarely a smooth transition
from one phase of the process to the next. Development may continue before the previous phase
document has been completed.
NEED FOR RISK MANAGEMENT
Risk is a concept that is difficult to define precisely. Informally, it is simply something which can
go wrong. For example, if the intention is to use a new programming language, a risk is that the
available compilers are unreliable or do not produce sufficiently efficient object code. Risks are a
consequence of inadequate information.
They are resolved by initiating some actions which discover information that reduces uncertainty.
In the above example, the risk would be resolved by a market survey to find out which compilers
are available and how good are they. If no suitable system was discovered, the decision to use a
new language must be changed.
Risk Management is a method for dealing with project risks, by identifying and handling them
appropriately. This method is on-going and is used throughout the life of the project.
BASIC APPROACH
Analysis of project, so that you can identify risks involved. For each risk identified, the following
steps are taken:
 Impact and Probability Analysis (the nature of the risk),
 Avoidance Plan ( How to minimize risks), and
 Contingency Plan (What to do if it occurs).

RISK REDUCTION CONTINGENCY PLANNING
 Avoiding Risk  Some risks cannot be reduced
o Modifying project requirements  Plan for risk occurrence
 Transferring the Risk  Why?
o By allocation to other systems o Reduces “Crisis” atmosphere
o Buying Insurance to cover financial loses o Reduces chance of mistakes
 Mitigating the Risk o Reduces time to correct
o Pre-Event Actions to:
 Reduce Likelihood of Occurrence
and/or
 Minimize Impact
MONITORING AND CONTINUOUS REASSESSMENT

 Periodic Review of Risk Status
o Changes in Probabilities or Impacts
o Changes in Avoidance/Mitigation/Contingency
Plans
 Periodic Review of Project to Identify New Risks
 Implementation of Risk Avoidance or Mitigation Plans
 Keep Management and Customers Informed!!!
o Frequent Risk Reviews

SDLC Processes

Uploaded by

Copyright:

Available Formats

SDLC Processes

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SDLC Processes

Uploaded by

Copyright:

Available Formats

THE SOFTWARE PROCESS is a coherent set of activities for analyzing, designing, implementing and

> Analysis: determining what the software will do

> Design: how will the system accomplish it

> Implementation: writing code

> Validation: finding errors

> Evolution: modifying the software

THE NEED FOR A STRUCTURED SOFTWARE DEVELOPMENT PROCESS

1. Increased Dependence of many organizations on their computer system: In all industrialized

3. Requirements for standard interfaces:

4. Need for Tighter Control of Management Processes:

Consider the following:

Visibility Do the process activities culminate in clear

Supportability To what extent can the process activities be

Acceptability Is the defined process acceptable to and usable

Reliability Is the process designed in such a way that

Robustness Can the process continue in spite of

Maintainability Can the process evolve to reflect changing

Rapidity How fast can the process of delivering a

However, regular document production has some drawbacks:

NEED FOR RISK MANAGEMENT

 Impact and Probability Analysis (the nature of the risk),

 Avoidance Plan ( How to minimize risks), and

 Contingency Plan (What to do if it occurs).

MONITORING AND CONTINUOUS REASSESSMENT

You might also like