Oosad Chapter 1
Oosad Chapter 1
Oosad Chapter 1
INTRODUCTION
Software development is dynamic and always undergoing major change. Today a vast
number of tools and methodologies are available for system development.
System development refers to all activities that go into producing information system
solution. System development activities consist of system analysis, modelling, design,
implementation, testing and maintenance. A software development methodology is
series of processes that, if followed, can lead to the development of an application. The
original goal based on the system requirements.
Software Process
Here, the project has been divided into different phases, each phase building on the
previous one and with a running release of software produced at the end of each phase
Advantages
1. The development team will work on all the stages
The team are able to work on the entire lifecycle (Analysis, Design, Code, Test)
rather than spending years on a single activity
2. Early feedback can be obtained
We can receive early and regular feedback from the customer, and spot potential
problems before going too far with development
3. Risks can easily be solved
We can attack risks up-front. Particularly risky iterations (for example, an
iteration requiring the implementation of new and untested technology) can be
developed first
4. The scale and complexity of work can be discovered earlier
5. New requirements and technological change can easily be integrated
Changes in technology can be incorporated more easily
6. It boosts the morale of the user and developer
A regular release of software improves morale
7. The status of the project (e.g.- how much of the system is complete.) can be assessed
more accurately
8. Mostly used for complex system
Disadvantages
1. It is accompanied by RAD
The process is commonly associated with Rapid Application Development, so the
user must know RAD to give good feedback.
2. The process is much more difficult to manage.
The Waterfall Model fits in closely with classic project management techniques
such as Gantt charts, but spiral processes require a different approach.
A. Inception
The inception phase is concerned with establishing the scope of the project and
generally defining a vision for the project. For a small project, this phase could be a
simple chat over coffee and an agreement to proceed; on larger projects, a more
thorough inception is necessary.
Possible deliverables/Artifacts from this phase are:
A Vision Document
An initial exploration of the customer’s requirements
A first-cut project glossary
A Business Case (including success criteria and a financial forecast, estimates of
the Return on Investment, etc)
An initial risk assessment
A project plan
B. Elaboration
The purpose of elaboration is to analyze the problem, develop the project plan further,
and eliminate the riskier areas of the project. By the end of the elaboration phase, we
aim to have a general understanding of the entire project, even if it is not necessarily a
deep understanding (that comes later, and in small, manageable chunks).
At the end of as many iterations as possible, we will aim to have a running system
(albeit, of course, a very limited system in the early stages). These iterations are called
Increments, hence the name of the framework!
D. Transition
The final phase is concerned with moving the final product across to the customers.
Typical activities in this phase include:
Beta-releases for testing by the user community
Factory testing, or running the product in parallel with the legacy system that the
product is replacing
Data take on (i.e. converting existing databases across to new formats, importing
data, etc.)
Training the new users
Marketing, Distribution and Sales
The Transition phase should not be confused with the traditional test phase at the end
of the waterfall model. At the start of Transition, a full, tested and running product
should be available for the users. As listed above, some projects may require a beta test
stage, but the product should be pretty much complete before this phase happens.
Complexity of Software
System: Systems are constructed by interconnecting components (Boundaries,
Environments, Characters, Emergent Properties), which may well be systems in their
own right. The larger the number of these components and relationships between them,
higher will be the complexity of the overall system.
3. Separation of Concerns
Hierarchic systems decomposable because they can be divided into identifiable parts;
he calls them nearly decomposable because their parts are not completely independent.
This leads to another attribute common to all complex systems:
Intra-component linkages are generally stronger than inter-component linkages. This
fact has the involving the high frequency dynamics of the components-involving the
internal structure of the components – from the low frequency dynamic involving
interaction among components.
4. Common Patterns
Hierarchic systems are usually composed of only a few different kinds of subsystems in
various combinations and arrangements. In other words, complex systems have
common patterns.
These patterns may involve the reuse of small components such as the cells found in
both plants and animals, or of larger structures, such as vascular systems, also found
in both plants and animals.
5. Stable intermediate Forms
A complex system that works is invariably bound to have evolved from a simple system
that worked. A complex system designed from scratch never works and can't be patched
up to make it work. You have to start over, beginning with a working simple system.
Structured Approach vs. Object-Oriented Approach
The following table explains how the object-oriented approach differs from the
traditional structured approach:
1. Increased reusability
2. Increased extensibility
3. Improved quality
4. Increased chance of project success
5. Reduced maintenance burden
6. Managed complexity
7. Financial benefits (allow the above advantages contribute to financial benefits)