Вы находитесь на странице: 1из 17

|  


   
2 It initiates with a project request. First stage is the preliminary analysis. The main aim of
preliminary analysis is to identify the problem. First, need for the new or the enhanced
system is established. Only after the recognition of need, for the proposed system is
done then further analysis is possible. Suppose in an office all leave-applications are
processed manually. Now this company is recruiting many new people every year. So the
number of employee in the company has increased. So manual processing of leave
application is becoming very difficult. So the management is considering the option of
automating the leave processing system. If this is the case, then the system analyst
would need to investigate the existing system, find the limitations present, and finally
evaluate whether automating the system would help the organization.
2 Once the initial investigation is done and the need for new or improved system is
established, all possible alternate solutions are chalked out. All these systems are known
as "candidate systems". All the candidate systems are then weighed and the best
alternative of all these is selected as the solution system, which is termed as the
"proposed system". The proposed system is evaluated for its feasibility. Feasibility for a
system means whether it is practical and beneficial to build that system.
2 Feasibility is evaluated from developer and customer's point of view. Developer sees
whether they have the required technology or manpower to build the new system. Is
building the new system really going to benefit the customer. Does the customer have
the required money to build that type of a system? All these issues are covered in the
feasibility study of the system. The feasibility of the system is evaluated on the three
main issues: technical, economical, and operational. Another issue in this regard is the
legal feasibility of the project.
2 î
 : Can the development of the proposed system be
done with current equipment, existing software technology, and
available personnel? Does it require new technology?
2 £  
 : Are there sufficient benefits in creating the system
to make the costs acceptable? An important outcome of the economic
feasibility study is the cost benefit analysis.
2 º 
 : It checks if there are any legal hassle in developing the
system.
2 a    
 : Will the system be used if it is developed and
implemented? Will there be resistance from users that will undermine
the possible application benefits?
2 The result of the feasibility study is a formal document, a report
detailing the nature and scope of the proposed solution. It consists of
the following:
2 Statement of the problem
2 Details of findings
2 Findings and recommendations in concise form
2 Once the feasibility study is done then the project is approved or
disapproved according to the results of the study. If the project seems
feasible and desirable then the project is finally approved otherwise no
further work is done on it.
x
x   
 |
xº
2 The purpose of the design phase is to plan a solution of the problem specified
by the requirement document. This phase is the first step in moving from
problem domain to the solution domain. The design of a system is perhaps the
most critical factor affecting the quality of the software, and has a major impact
on the later phases, particularly testing and maintenance. The output of this
phase is the design document. This document is similar to a blue print or plan
for the solution, and is used later during implementation, testing and
maintenance. The design activity is often divided into two separate phase-
system design and detailed design. System design, which is sometimes also
called top-level design, aims to identify the modules that should be in the
system, the specifications of these modules, and how they interact with each
other to produce the desired results. At the end of system design all the major
data structures, file formats, output formats, as well as the major modules in
the system and their specifications are decided.
2 During detailed design the internal logic of each of the modules specified in
system design is decided. During this phase further details of the data
structures and algorithmic design of each of the modules is specified. The logic
of a module is usually specified in a high-level design description language,
which is independent of the target language in which the software will
eventually be implemented. In system design the focus is on identifying the
modules, whereas during detailed design the focus is on designing the logic for
each of the modules. In other words, in system design the attention is on what
components are needed, while in detailed design how the components can be
implemented in software is the issue.
2 During the design phase, often two separate documents are produced. One for
the system design and one for the detailed design. Together, these documents
completely specify the design of the system. That is they specify the different
modules in the system and internal logic of each of the modules.
2 A design methodology is a systematic approach to creating a design by
application of set of techniques and guidelines. Most methodologies focus on
system design. The two basic principles used in any design methodology are
problem partitioning and abstraction. A large system cannot be handled as a
whole, and so for design it is partitioned into smaller systems. Abstraction is a
concept related to problem partitioning. When partitioning is used during
design, the design activity focuses on one part of the system at a time. Since
the part being designed interacts with other parts of the system, a clear
understanding of the interaction is essential for properly designing the part. For
this, abstraction is used. An abstraction of a system or a part defines the overall
behavior of the system at an abstract level without giving the internal details.
2 While working with the part of a system, a designer needs to understand only
the abstractions of the other parts with which the part being designed
interacts. The use of abstraction allows the designer to practice the "divide and
conquer" technique effectively by focusing one part at a time, without worrying
about the details of other parts.
2 Like every other phase, the design phase ends with verification of the design. If
the design is not specified in some executable language, the verification has to
be done by evaluating the design documents. One way of doing this is thorough
reviews. Typically, at least two design reviews are held-one for the system
design and one for the detailed and one for the detailed design.
    x      x  |
xº
2 Once the design is complete, most of the major decisions about
the system have been made. The goal of the coding phase is to
translate the design of the system into code in a given
programming language. For a given design, the aim of this
phase is to implement the design in the best possible manner.
The coding phase affects both testing and maintenance
profoundly. A well written code reduces the testing and
maintenance effort. Since the testing and maintenance cost of
software are much higher than the coding cost, the goal of
coding should be to reduce the testing and maintenance effort.
Hence, during coding the focus should be on developing
programs that are easy to write. Simplicity and clarity should be
strived for, during the coding phase. An important concept that
helps the understandability of programs is structured
programming. The goal of structured programming is to arrange
the control flow in the program. That is, program text should be
organized as a sequence of statements, and during execution,
the statements are executed in the sequence in the program.
2 For structured programming, a few single-entry-single-exit
constructs should be used. These constructs includes
selection (if-then-else), and iteration (while - do, repeat -
until etc). With these constructs it is possible to construct a
program as sequence of single - entry - single - exit
constructs. There are many methods available for verifying
the code. Some methods are static in nature that is, that is
they do not involve execution of the code. Examples of
such methods are data flow analysis, code reading, code
reviews, testing (a method that involves executing the
code, which is used very heavily). In the coding phase, the
entire system is not tested together. Rather, the different
modules are tested separately. This testing of modules is
called "unit testing". Consequently, this phase is often
referred to as "coding and unit testing". The output of this
phase is the verified and unit tested code of the different
modules.
x
î

Testing is the major quality control measure employed during software
development. Its basic function is to detect errors in the software. During
requirement analysis and design, the output is a document that is usually
textual and non-executable. After the coding phase, computer programs are
available that can be executed for testing phases. This implies that testing not
only has to uncover errors introduced during coding, but also errors introduced
during the previous phases. Thus, the goal of testing is to uncover requirement,
design or coding errors in the programs. Consequently, different levels of
testing are employed. The starting point of testing is unit testing. In this a
module is tested separately and is often performed by the coder himself
simultaneously with the coding of the module. The purpose is to execute the
different parts of the module code to detect coding errors. After this the
modules are gradually integrated into subsystem, which are then integrated
themselves eventually form the entire system. During integration of modules,
integration testing is performed. The goal of this testing is to detect design
errors, while focusing on testing the interconnection between modules. After
the system is put together, system testing is performed. Here the system is
tested against tech system requirements to see if all the requirements are met
and the system performs as specified by the requirements. Finally, acceptance
testing is performed to demonstrate to the client, on the real life data of the
client, the separation of the system.
2 For testing to be successful, proper selection of test cases is essential. There are
two different approaches to selecting test cases-functional testing and
structural testing. In functional testing the software for the module to be tested
is treated as black box, and then test cases are decided based on the
specifications of the system or module. For this reason, this form of testing is
also called "black box testing". The focus is on testing the external behavior of
the system. In structural testing the test cases are decided based on the logic of
the module to be tested. Structural testing is sometimes called "glass box
testing". Structural testing is used for lower levels of testing and functional
testing is used for higher levels.
2 Testing is an extremely critical and time-consuming activity. It requires proper
planning of the overall testing process. Frequently the testing process starts
with the test plan. This plan identifies all the testing related activities that must
be performed and specifies the schedule, allocates the resources, and specify
guidelines for testing. The test plan specifies manner in which the modules will
integrate together. Then for different test units, a test case specification
document is produced, which lists all the different test cases, together with the
expected outputs, that will be used for testing. During the testing of the unit,
the specified test cases are executed and actual result is compared with the
expected output. The final output of the testing phases is to the text report and
the error report, or set of such reports (one of each unit is tested). Each test
report contains the set of such test cases and the result of executing the code
with these test cases The error report describes the errors encountered and
action taken to remove those errors.
xº      x   º
2 Maintenance includes all the activity after the installation of software
that is performed to keep the system operational. As we have
mentioned earlier, software often has design faults. The two major
forms of maintenance activities are adaptive maintenance and
corrective maintenance. It is generally agreed that for large systems,
removing all the faults before delivery is extremely difficult and faults
will be discovered long after the system is installed. As these faults are
detected, they have to be removed. Maintenance activities related to
fixing of errors fall under corrective maintenance.
2 Removing errors is one of the activities of maintenance. Maintenance
also needed due to a change in the environment or the requirements of
the system. The introduction of a software system affects the work
environment. This change in environment often changes what is desired
from the system. Furthermore, often after the system is installed and
the users have had a chance to work with it for sometime, requirements
that are not identified during requirement analysis phase will be
uncovered. This occurs, since the experience with the software helps the
user to define the needs more precisely. There might also be changes in
the input data, the system environment and output formats. All these
require modification of the software. The maintenance activities related
to such modification fall under adaptive
2 maintenance.
2 Maintenance work is based on existing software, as compared to development
work, which creates new software. Consequently maintenance resolves around
understanding the existing software and spares most of their time trying to
understand the software that they have to modify. Understanding the software
involves not only understanding the code, but also the related documents.
During the modification of the software, the effects of the change have to be
clearly understood by the maintainer since introducing undesired side effects in
the system during modification is easier.
2 To test whether those aspects in the system that are not supposed to be
modified are operating as they were before modification, regression testing is
done. Regression testing involves executing old test cases to test that no new
errors have been introduced. Thus, maintenance involves understanding the
existing software (code and related documents), understanding the effects of
change, making the changes - both to the code and documents, testing the new
parts (changes), and resetting of the old parts that were not changed.
2 Since often during development, needs of the maintainers are not kept in mind,
little support documents are produced during development to aid the
maintainer. The complexity of the maintenance task is coupled with the neglect
of maintenance concerns during development which makes maintenance the
most cost effective activity in the life of a software product.
£ 
   |

x   
   º

2 A typical software product may take months to a few years for development, and is in
operation for five to twenty years before it is withdrawn. For software, the cost of
development is the incurred during requirement analysis, design, coding and testing.
Therefore, the development cost is the total cost incurred before the product delivery.
The cost of maintenance is the cost of modifying the software due to residual faults in
the software, for enhancing or for updating the software. This cost is spread over the
operational years of the software. Software engineers generally agree that the total cost
of maintenance is more than the cost of development of software. The ratio of
development to maintenance cost has been variously suggested as 40/60, 30/70 or even
lower. However, it is generally accepted that the cost of maintenance is likely to be
higher than the development cost, and are often not at all concerned with the
maintenance. Since maintenance depends critically on the software characteristics that
are decided during development, maintenance cost can be reduced if maintenance
concerns are kept in forefront during development. One of the reasons why this is often
not done is that the development cost is done by the developers while maintenance is
often done by the users. Hence, the developers do not have much incentive for
increasing the development effort in order to reduce the maintenance cost. However,
for reduction in overall cost of software, it is imperative that the software be developed
so the maintenance is easy.
2 The development cost, a typical distribution of effort with the different phases is
2 Requirement - 10%
Design - 20%
Coding - 20%
Testing - 50%
2 The exact number will differ with organization and the type of the project.
There are some observation we can make from the data given above. The first
is that the goal of design and coding should reduce the cost of design and
coding, but should be to reduce the cost of testing and maintenance, at the
expense of increasing design and coding cost. Both testing and maintenance
depend heavily in the design and coding of the software. And these costs can
be considerably reduced if the software is designed and coded to make testing
and maintenance easier. Therefore, during design and implementation, the
issues in our minds should be "can the design be easily tested", and "can it be
easily modified". These require alternate designs and may increase the cost of
the design and coding. But this additional costs pay dividends in the later
phases.
2 £ 
  
2 The notion that programming is the central of activity during software
development is largely because normally programming has been considered to
be difficult task and sometimes an "art". Another consequence of this kind of
thinking is the belief that errors largely occur during programming, as it is the
oldest activity in software development and offers many opportunities for
commiting errors. It is now realized that errors can occur at any stage during
development. A typical distribution of error occurrences by is
2 Requirement Analysis - 20%
Design - 30%
Coding - 50%
2 As we can see, errors occur throughout the development process.
However the cost of correcting different phases is not the same and
depends on when the error is detected and correceted. As one old
expect, the greater the delay in detecting an error after it occurs, the
more expensive it is to correct it. Error that occur during the
requirements phase, if corrected after coding is completed, can cost
many times more than correcting the error during the requirements
phase itself. The reason for this is fairly obvious. If there is an error in
the requirements, then the design and the code will get affected.
2 To correct the error, the coding that is done would require both the
design and the code to be changed there by increasing the correction.
So we should attempt to detect errors in the previous phase and should
not wait until testing to detect errors. This is not often practiced. In
reality, sometimes testing is the sole point where errors are detected.
Besides the cost factor, reliance on testing as the primary source for
error detection, due to the limitations of testing, will also result in
unreliable software. Error detection and correction should be a
continous proces that is done throughout software development. In
terms of the development phases what this means is that we should try
to validate each phase before starting with the next.