Embed Size (px)
Citation preview
SYSTEM DEVELOPMENT LIFE CYCLE MODELS• Life cycle models come out in order to transfer systems from manual to
automated easily.
• Life cycle model emphasized on the need to follow some structured approach
towards building new or improved system.
•There were many models suggested. The Waterfall Model was among the very
first models that came into existence.
• Later on many other models like Prototyping Model, Object-Oriented Model,
and Dynamic System Development Model (DSDM) etc were also introduced.
9/30/2019CEN 421 - SAD 2
ACTIVITIES INVOLVED IN ANY LIFE CYCLE MODEL
•The following activities are the part of any life cycle model (not
necessarily in the same order):
1. Preliminary Investigation
2. Determination of System's Requirements: Analysis Phase
3. Design of System
4. Development of Software
5. System Testing
6. Implementation and Maintenance
9/30/2019CEN 421 - SAD 3
1. PRELIMINARY INVESTIGATION• The main aim of preliminary analysis is to identify the problem.
• First, need for the new or the enhanced system is established. If there is a need then
further analysis are done.
• Then "candidate systems" are chalked out.
• From these candidates best alternative is selected as the solution system, which is termed
as the "proposed system".
• The proposed system is then evaluated for its feasibility. Feasibility for a system means
whether it is practical and beneficial to build that system.
• The feasibility of the system is evaluated on technical, economical, legal and operational
issues.
9/30/2019CEN 421 - SAD 4
1. PRELIMINARY INVESTIGATION
Technical Feasibility:
Can the development of the proposed system be done with current
equipment, existing software technology, and available personnel?
Does it require new technology?
Economic feasibility:
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.
9/30/2019CEN 421 - SAD 5
1. PRELIMINARY INVESTIGATION
Legal Feasibility:
It checks if there are any legal hassle in developing the system.
Operational Feasibility:
Will the system be used if it is developed and implemented?
Will there be resistance from users that will undermine the possible
application benefits?
9/30/2019CEN 421 - SAD 6
1. PRELIMINARY INVESTIGATION
•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:
Statement of the problem
Details of findings
Findings and recommendations in concise form
•Once the feasibility study is done then the project is approved or
disapproved according to the results of the study.
9/30/2019CEN 421 - SAD 7
2. DETERMINATION OF SYSTEM'S REQUIREMENTS: ANALYSIS PHASE
•Analysis is a detailed study of:
the various operations performed by the system,
relationships among the various sub-systems or functional units,
the relationships outside the system.
•Study is conducted to find user's information requirements.
•Proper functioning of the current system is also studied.
•Many tools are used during analysis: Data flow diagrams, on-site observations,
and questionnaires are some examples.
9/30/2019CEN 421 - SAD 8
2. DETERMINATION OF SYSTEM'S REQUIREMENTS: ANALYSIS PHASE
•Major questions under consideration during analysis are:
1. What is being done?
2. How is it being done?
3. Does a problem exist?
4. If a problem exists, how severe is it?
5. How frequently does it occur?
6. What is the underlining cause for the problem?
•Once the analysis is completed, the analyst has a firm knowledge of what is to
be done.
9/30/2019CEN 421 - SAD 9
3. DESIGN OF SYSTEM• In design phase, the structure or design for the proposed system is finalized.
•Structure of files, databases, input, output, processes, and screens(interfaces)
are decided.
•After design is finalized, it is clearly documented in what is called Design
Document.
It contains various graphical representations of reports, user interaction
screens, etc.
It is referred by developers during development of system.
9/30/2019CEN 421 - SAD 10
3. DESIGN OF SYSTEM• Correct designing of the system is very crucial.
• If we have a wrong design we won't be able to get a correct desired system.
• Also cost of fixing errors is maximum for design phase.
• Cost of change increases when errors are discovered in later stages for system
development. Mostly design errors are discovered in development, testing, or
maintenance phase.
• So, the cost of change due to changes in design (which might happen due to some
error or improper design) is very high.
• Design process should be handled very carefully.
9/30/2019CEN 421 - SAD 11
4. DEVELOPMENT OF SOFTWARE• In this phase, the actual development of the system takes place.
•Design representations are translated into actual programs.
•Software developers may install (or modify and then install) purchased
software or they may write new, custom-designed programs.
•Programmers are also responsible for documenting the program, providing an
explanation of how procedures are coded.
•Documentation is essential to test the program and carry on maintenance
once the application has been installed.
• It is also helpful to user in knowing the system well.
9/30/2019CEN 421 - SAD 12
5. SYSTEM TESTING
• It is important to check if it fulfills the customer requirements after
development of the system.
•Various test cases are prepared for testing the system.
A test case is a certain made up situation on which system is exposed so as
to find the behavior of system in that type of real situation.
Test cases can be tested with real or artificial data.
Unit, integration, and acceptance testing are some of these.
9/30/2019CEN 421 - SAD 13
5. SYSTEM TESTING• In Unit Testing, the smallest units of software, the modules are tested one by
one.
• In Integration Testing, the modules are integrated and tested as a complete
system.
•This is done since testing individual module doesn't guarantee if the system will
work properly when these units are integrated.
•Acceptance Testing ensures that the system meets all the requirements. If it
fulfils the needs then the system is accepted by the customer and put into use.
9/30/2019CEN 421 - SAD 14
6. IMPLEMENTATION AND MAINTENANCE
• Implementation of system means putting up system on user's site.
• Like any system, there is an aging process. Therefore, the system requires
periodic maintenance.
•Maintenance can be for software or hardware.
•User priorities, changes in organizational requirements, or environmental factors
call for system enhancements.
•This is very crucial for the system's life.
9/30/2019CEN 421 - SAD 15
DIFFERENT LIFE CYCLE MODELS
•There are system development models, which follow these stages:
1. Waterfall Model (Traditional model)
2. Iterative Prototype Model
3. Dynamic Systems Development Model (DSDM)
4. Spiral Model, Incremental Model
5. Object-Oriented Model.
9/30/2019CEN 421 - SAD 16
WATERFALL MODEL•Waterfall model is a systematic
and sequential approach
towards software development.
• Follows all the stages and each
stage begins or originates only
after the previous stage has
finished.
• Every stage ends with a report
and if needed feedback is given.
9/30/2019CEN 421 - SAD 17
System
Engineering
Analysis
Design
Coding
Maintenance
Testing
•When to use Waterfall Model ?
In principle, the waterfall model should only be applied when
requirements are well understood and unlikely to change radically
during development as this model has a relatively rigid structure which
makes it relatively hard to accommodate change when the process is in
underway.
•The main advantage of this model is; it is easy to understand.
9/30/2019CEN 421 - SAD 18
WATERFALL MODEL
•Major limitations of the model:
Real projects rarely follow sequential flow. Iterations are required.
Requirements may not be clearly defined in the beginning itself.
Major errors may require going back to Design phase or even Feasibility
study phase.
Customer would have no idea of the working program until the end. Very
less interaction with the customer.
Major blunders may be noticed only after development.
Product delivery takes much time.
9/30/2019CEN 421 - SAD 19
WATERFALL MODEL
PROTOTYPING MODEL•Prototyping Model is an iterative approach.
•A prototype is a working system that is developed to test ideas about the new
system.
•Prototyping is a process of building a model of the system to be developed.
•This approach is used when it is difficult to know all the requirements in the
beginning of the project.
•Such situations arise in the following cases:
The user has not provided all the requirements.
No other system like the proposed system was built earlier.
9/30/2019CEN 421 - SAD 20
PROTOTYPING MODEL•This model can be also used in a situation
when the customer wants a quick
delivery. May be not the entire system
but a part of it.
•The complete system is based on an
iterative model where the customer
keeps specifying the requirements
according to the model made available
and the changes are incorporated to
build a better model.
9/30/2019CEN 421 - SAD 21
Requirements
Gathering
Quick
Design
Building
Protoype
Customer
Evaulation
Refining
Prototype
Final
Product
•The main disadvantage of this model is; because of quick design, there can be
compromise on quality.
•But on the other hand it has some advantages, too:
Reduces risk of uncertainty.
Allows early stoppage of unsuccessful projects.
User interaction and involvement is more.
Less chances of error during system design.
9/30/2019CEN 421 - SAD 22
PROTOTYPING MODEL
OBJECT-ORIENTED MODEL•Object-Oriented development requires that object-oriented techniques be used
during the analysis, and implementation of the system.
•This methodology asks the analyst to determine:
What are the objects of the system?
How they behave over time or in response to events?
What responsibilities and relationships an object has to other objects?
•Object-oriented analysis has the analyst look at all the objects in a system, their
commonalties, difference, and how the system needs to manipulate the objects.
9/30/2019CEN 421 - SAD 23
OBJECT-ORIENTED MODEL•Object-Oriented Model takes the objects as the basis.
• For this, first the system to be developed is observed and analyzed and the
requirements are defined as in any other method of system development.
•Once this is done, the objects in the required system are identified.
For example in case of a Banking System, a customer is an object, a chequebook is an object, and
even an account is an object.
• In simple terms, Object Modeling is based on identifying the objects in a system and
their interrelationships.
•Once this is done, the coding of the system is done.
9/30/2019CEN 421 - SAD 24
OBJECT-ORIENTED MODEL•Object Modeling is somewhat similar to the traditional approach of system
designing, in that it also follows a sequential process of system designing but
with a different approach.
•The basic steps of system designing using Object Modeling may be listed as:
1. System Analysis
2. System Design
3. Object Design
4. Implementation
9/30/2019CEN 421 - SAD 25
OBJECT-ORIENTED MODEL1. System Analysis:
• As in any other system development model, system analysis is the first phase of
development in case of Object Modeling, too.
• In this phase, the developer interacts with the user of the system to find out the
user requirements and analyses the system to understand the functioning.
• The analyst prepares a model of the desired system. This model is purely based on
what the system is required to do.
• The model of the system is prepared based on the idea that the system is made up
of a set of interacting objects.
9/30/2019CEN 421 - SAD 26
OBJECT-ORIENTED MODEL2. System Design:
• The overall architecture of the desired system is decided.
• Perceive the system as a set of interacting objects, a bigger system may also be
seen as a set of interacting smaller subsystems that in turn are composed of a set of
interacting objects.
•While designing the system, the stress lies on the objects comprising the system
and not on the processes being carried out in the system as in the case of
traditional Waterfall Model where the processes form the important part of the
system.
9/30/2019CEN 421 - SAD 27
OBJECT-ORIENTED MODEL3. Object Design
• In this phase, the details of the system analysis and system design are
implemented.
• The Objects identified in the system design phase are designed.
• Here the implementation of these objects is decided as the data structures get
defined and also the interrelationships between the objects are defined.
• In the Object Designing phase of the Development process, the designer decides
onto the classes in the system
• The designer also decides on whether the classes need to be created from scratch
or any existing classes can be used as it is or new classes can be inherited from
them.
9/30/2019CEN 421 - SAD 28
OBJECT-ORIENTED MODEL4. Implementation
• During this phase, the class objects and the interrelationships of these classes are
translated and actually coded using the programming language decided upon.
• The databases are made and the complete system is given a functional shape.
• As compared to the conventional system development techniques, OO modeling
provides many benefits like:
•Reusability
• Inheritance
•Data Hiding (Encapsulation)
9/30/2019CEN 421 - SAD 29
OBJECT-ORIENTED MODEL•The advantages of using Object-Oriented Model are;
OO Model closely represents the problem domain. Because of this, it is easier to
produce and understand designs.
The objects in the system are immune to requirement changes. Therefore, allows
changes more easily.
OO designs encourage more re-use. New applications can use the existing modules,
thereby reduces the development cost and cycle time.
OO approach is more natural. It provides nice structures for thinking and
abstracting and leads to modular design.
9/30/2019CEN 421 - SAD 30
DYNAMIC SYSTEM DEVELOPMENT MODEL (DSDM)
• DSDM develops the system dynamically. The DSDM development process is dynamic
as it is a Rapid Application Development method that uses incremental prototyping.
• This method is particularly useful for the systems to be developed in short time span
and where the requirements cannot be frozen at the start of the application building.
•Whatever requirements are known at a time, design for them is prepared and design is
developed and incorporated into system.
• In DSDM, analysis, design and development phase can overlap. Like at one time some
people will be working on some new requirements while some will be developing
something for the system. In DSDM, requirements evolve with time.
9/30/2019CEN 421 - SAD 31
DYNAMIC SYSTEM DEVELOPMENT MODEL (DSDM)
•The DSDM development process consists of 7 phases, of which some might be
omitted in a concrete project implementation.
9/30/2019CEN 421 - SAD 32
DYNAMIC SYSTEM DEVELOPMENT MODEL (DSDM)
• Pre-Project:
The pre-project phase is not strictly defined. It occurs before the project officially
begins. In this stage, the project is conceptualized, and the decision is made to start
the project.
• Feasibility Study:
In this phase, the team researches the question: Can it be done within the
constraints of time and resources? This phase is done as quickly as possible,
because DSDM is best used where time is short, and therefore the product needs
to be delivered quickly.
9/30/2019CEN 421 - SAD 33
DYNAMIC SYSTEM DEVELOPMENT MODEL (DSDM)
• Business Study:
In this phase, the team researches the business aspects of the project.
Does it make good business sense?
Who are the participants and interested parties?
What is the best work plan? What is needed to:
1. Build it
2. Test it
3. Deploy it
4. Support it
What technologies will we be using to build and deploy it?
9/30/2019CEN 421 - SAD 34
• Functional Model Iteration:
The main focus in this phase is on building the prototype iteratively and getting it
reviewed from the users to bring out the requirements of the desired system.
The prototype is improved through demonstration to the user, taking the feedback and
incorporating the changes.
The outcome of the functional model iteration is standard analysis model of the
software.
• Design and Built:
In this stage, the product is designed and developed in iterations. In each iteration a
design model is made of the area being developed, and then that area is coded and
reviewed.
9/30/2019CEN 421 - SAD 35
DYNAMIC SYSTEM DEVELOPMENT MODEL (DSDM)
• Implementation:
In the last phase, the product is wrapped up, documentation is written, and a review
document is drawn up, comparing the requirements with their fulfillments in the
product.
The users are trained in how to use the system, and the users give approval to the
system.
• Post-Project - Maintenance
After the product is created, maintenance will inevitably need to be performed. This
maintenance is generally done in a cycle similar to the one used to develop the
product.
9/30/2019CEN 421 - SAD 36
DYNAMIC SYSTEM DEVELOPMENT MODEL (DSDM)
•The main problem in this model is; it is a relatively new model so it is not very
common. In addition, it is a difficult model to understand.
•The advantages of the model:
Active user participation throughout the life of the project and iterative
nature of development improves quality of the product.
DSDM ensures rapid deliveries.
Both of the above factors result in reduced project costs.
9/30/2019CEN 421 - SAD 37
DYNAMIC SYSTEM DEVELOPMENT MODEL (DSDM)
SPIRAL MODEL• Spiral Model is a combination of a waterfall model
and iterative model.
• Each phase in spiral model begins with a design goal
and ends with the client reviewing the progress.
• The development team in Spiral model starts with a
small set of requirement and goes through each
development phase for those set of requirements.
• The software engineering team adds functionality for
the additional requirement in every-increasing spirals
until the application is ready for the production
phase.
9/30/2019CEN 421 - SAD 38
9/30/2019CEN 421 - SAD 39
•When to use Spiral Model?
When project is large
When releases are required to be frequent
When creation of a prototype is applicable
When risk and costs evaluation is important
For medium to high-risk projects
When requirements are unclear and complex
When changes may require at any time
When long term project commitment is not feasible due to changes in economic
priorities
SPIRAL MODEL
PROBLEM STATEMENT REPORTDUE DATE: 04.10.2019 FRIDAY
9/30/2019CEN 421 - SAD 40
• In general, a problem statement will outline the negative points of the current situation and explain why this
matters.
• The 5W2H questions can be used to spark the discussion about the problem:
• Who - Who does the problem affect? Specific groups, organizations, customers, etc.
• What - What is the problem that needs to be solved? What are the boundaries of the problem, e.g.
organizational, work flow, geographic, customer, segments, etc. - What is the issue? - What is the impact of the
issue? - What impact is the issue causing? - What will happen when it is fixed? - What would happen if we
didn’t solve the problem? - What impact does it have on the business or customer? - What impact does it have
on all stakeholders, e.g. employees, suppliers, customers, shareholders, etc.
• When - When does the issue occur? - When does it need to be fixed?
• Where - Where is the issue occurring? Only in certain locations, processes, products, etc.
• Why - Why is it important that we fix the problem?
• How - How is the problem observed? (symptoms)
• How often - How often is the problem observed? (error rate, magnitude, trend)
9/30/2019CEN 421 - SAD 41
• After describing the problem in the current situation, you will give a context diagram of the
system that will be planned for the future.
System Context Diagrams represent all external entities that may interact with a system.
Such a diagram pictures the system at the center, with no details of its interior structure,
surrounded by all its interacting systems, environments and activities. The objective of the
system context diagram is to focus attention on external factors and events that should be
considered in developing a complete set of systems requirements and constraints.
• Context diagrams can be developed with the use of two types of building blocks:
Entities (Actors): labeled boxes; one in the center representing the system, and around it
multiple boxes for each external actor
Relationships: labeled lines between the entities and system
9/30/2019CEN 421 - SAD 42
CONTEXT DIAGRAM EXAMPLE
9/30/2019CEN 421 - SAD 43
