Software Engineering is an engineering approach for software
development.The basic principle of software engineering is to use structured,
formal and disciplined methods for building and using systems.The outcome of software
engineering is an efficient and reliable software product.
Without using software engineering principles it would be difficult to develop large programs. In industry it is usually needed to develop large programs to accommodate multiple functions. A problem with developing such large commercial programs is that the complexity and difficulty levels of the programs increase exponentially with their sizes. Software engineering helps to reduce this programming complexity. Software engineering principles use two important techniques to reduce problem complexity: abstraction and decomposition. The principle of abstraction implies that a problem can be simplified by omitting irrelevant details. In other words, the main purpose of abstraction is to consider only those aspects of the problem that are relevant for certain purpose and suppress other aspects that are not relevant for the given purpose. Once the simpler problem is solved, then the omitted details can be taken into consideration to solve the next lower level abstraction, and so on. Abstraction is a powerful way of reducing the complexity of the problem.
The other approach to tackle problem complexity is decomposition. In this technique, a complex problem is divided into several smaller problems and then the smaller problems are solved one by one. However, in this technique any random decomposition of a problem into smaller parts will not help. The problem has to be decomposed such that each component of the decomposed problem can be solved independently and then the solution of the different components can be combined to get the full solution. A good decomposition of a problem should minimize interactions among various components.
System Requirement Specification(SRS):
It is obtained after excessive discussions with the users.Software requirement specification (SRS) is a document that completely describes what the proposed software should do without describing how software will do it.SRS is important and difficult task of a System Analyst.
Characteristics of SRS:
- Correct
- Complete and Unambiguous
- Verifiable
- Consistent
- Traceable
- Modifiable
Software
Life Cycle Models:
A software
life cycle model (also called process
model) is a descriptive and
diagrammatic representation of the software life cycle. A life cycle
model represents all the activities required to make a
software product transit through its life
cycle phases. It also captures the
order in which these activities are to be undertaken. In other
words, a life cycle model maps the different activities performed on a
software product from its inception to retirement. Different life
cycle models may map the basic development activities to phases in
different ways. Thus, no matter which life cycle model
is followed, the basic activities are
included in all life cycle
models though the activities may be carried out in different orders
in different life cycle models. During any life cycle phase, more than one
activity may also be carried out. A software life cycle model is a particular
abstraction representing a software life cycle.Such a model may be:
Activity-centered----Focusing
on the activities of software development
Entity-centered----Focusing
on the work products created by these activities
A
software life cycle model is often referred to as a Software Development Life
Cycle(SDLC).ISO/IEC 12207 is an international standard for software life-cycle
processes. It aims to be the standard that defines all the tasks required for
developing and maintaining software.
Waterfall Model:
The
Waterfall Model was first Process Model to be introduced.
The
waterfall Model is a linear sequential flow. In which progress is seen as
flowing steadily downwards (like a waterfall) through the phases of software
implementation. This means that any phase in the development process begins
only if the previous phase is complete. The waterfall approach does not define
the process to go back to the previous phase to handle changes in requirement.
The waterfall approach is the earliest approach that was used for software
development.
Requirement Gathering and Analysis
|
Capture all the possible requirement of the system to
be developed and documented in a software requirement.
|
System Design
|
Helps in specifying hardware and
system requirements and also helps in defining overall system architecture.
|
Implementation
|
With inputs from system design, the
system is first developed in small programs called units, which are
integrated in the next phase. Each unit is developed and tested for its
functionality which is referred to as Unit Testing.
|
Integration and Testing
|
All the units developed in the
implementation phase are integrated into a system after testing of each unit.
During this phase, each module is unit tested to determine the correct
working of all the individual modules. It involves testing each module in
isolation as this is the most efficient way to debug the errors identified at
this stage.
|
Integration and System Testing
|
During the integration and
system testing phase, the modules are
integrated in a planned manner. The different modules making up a software
product are almost never integrated in one shot. Integration is normally
carried out incrementally over a number ofsteps. During
each integration step, the partially
integrated system is tested and a
set of previously planned modules are added to it. Finally, when all
the modules have been successfully integrated and tested, system
testing is carried out. The goal of system testing is to ensure that
the developed system conforms to its requirements laid out in the SRS
document. System testing
usually consists of three different kinds of testing
activities:
α – testing: It is the system testing performed by the
development team.
β –testing: It is the system testing performed by a
friendly set of customers.
Acceptance testing: It is the system testing performed
by the customer himself after the product delivery to determine whether to
accept or reject the delivered product.
|
Deployment of System
|
Once the functional and non functional
testing is done, the product is deployed in the customer environment or
released into the market.
|
Maintenance
|
Maintenance of a typical software product requires much
more than the effort necessary to develop the
product itself. Many studies carried out
in the past confirm this and indicate that the
relative effort of development of a typical software product to its
maintenance effort is roughly in the 40:60 ratios. Maintenance involves
performing any one or more of the following three kinds of activities:
Correcting errors that were not discovered during the
product development phase. This is called corrective maintenance.
Improving the implementation of
the system, and enhancing the
functionalities of the system according to the customer’s
requirements. This is called perfective maintenance.
Porting the software to
work in a new environment. For
example, porting may be required to get the software to
work on a new computer platform or with a new operating system. This is
called adaptive maintenance.
|
Advantages of waterfall model:
- This model is simple and easy to understand and use.
- It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
- In this model phases are processed and completed one at a time. Phases do not overlap.
- Waterfall model works well for smaller projects where requirements are very well understood.
Disadvantages of
waterfall model:
- Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.
- No working software is produced until late during the life cycle.
- High amounts of risk and uncertainty.
- Not a good model for complex and object-oriented projects.
- Poor model for long and ongoing projects.
- Not suitable for the projects where requirements are at a moderate to high risk of changing.
When to use the
waterfall model:
- This model is used only when the requirements are very well known, clear and fixed.
- Product definition is stable.
- Technology is understood.
- There are no ambiguous requirements
- Ample resources with required expertise are available freely
- The project is short.
Very less customer enter
action is involved during the development of the product. Once the product is
ready then only it can be demoed to the end users. Once the product is
developed and if any failure occurs then the cost of fixing such issues are
very high, because we need to update everywhere from document till the logic.
All the contents you mentioned in is too good and can be very useful. I will keep it in mind, thanks for sharing the information keep updating, looking forward for more posts.Thanks Salt Lake City custom software development
ReplyDelete