Building Systems:

Software Development
Models

Management Information Systems

 Software and System Engineering

Systems System
Analysis testing

System
System
Integration
Design System Engineering Testing

Software Software
Software System
Requirements System
Engineering Testing
Analysis
Architectural Software
Software Integration
Design Testing

Software Engineering Detailed Software

Software Modular
Design Testing

Coding and
Unit Testing

Management Information Systems

 Generic software process models
 The waterfall model
 Separate and distinct phases of specification and
development.
 Evolutionary development
 Specification, development and validation are
interleaved.
 Component-based software engineering
 The system is assembled from existing components.
 There are many variants of these models e.g. formal
development where a waterfall-like process is used but
the specification is a formal specification that is refined
through several stages to an implementable design.
Systems Development Models
 Traditional Waterfall model,
 Prototype model,
 Object-Oriented Model,
 Spiral model
 Dynamic Systems Development Method
(DSDM)
 Agile Development
Systems Development Models
Problem solving in software consists of these activities:
 Understanding the problem- Requirement Analysis / Determination of
System's Requirements
 Deciding a plan for a solution-Design of system
 Coding the planned solution- Development (coding) of software
 Testing the actual program- System Testing

 In addition to the activities performed during software development, some

activities are performed after the main development is complete.
 installation (also called implementation) phase, which is concerned with
actually installing the system on the client's computer systems and then
testing it.
 software maintenance-an activity that commences after the software is
developed. Software needs to be maintained not because some of its
components "wear out" and need to be replaced, but because there are
often some residual errors remaining in the system which must be
removed later as they are discovered.
 Upgrade and enhancement to include more "features" and provide more
services. This also requires modification of the software,
Systems Development Life
Cycle (SDCL)
 Waterfall Traditional
Software System Development
Term
Project
Scope

Also called Waterfall model

Revision of Waterfall model
Requirements
definition

System and
software design

Implementa tion
and unit testing

Integration and
system testing

Operation and
maintenance
Software System Development
Traditional model - Advantages
 [Link] to explain to the user
 [Link] and activities are well defined
 [Link] to plan and schedule the project
 [Link] at each stage ensures early detection of
errors / misunderstanding
 Software System Development
Traditional model - Limitations
 Assumes that the requirements of a system can be frozen (i.e.
basedline) before the design begins. This is possible for systems designed
to automate an existing manual system. But for absolutely new system,
determining the requirements is difficult, as the user himself does not know
the requirements. Therefore, having unchanging (or changing only a few)
requirements is unrealistic for such project
 Freezing the requirements usually requires choosing the hardware (since
it forms a part of the requirement specification). A large project might take a
few years to complete. If the hardware is selected early, then due to the
speed at which hardware technology is changing, it is quite likely that the
final software will employ a hardware technology that is on the verge of
becoming obsolete.
 The waterfall model stipulates that the requirements should be
completely specified before the rest of the development can proceed. In
some situations it might be desirable to first develop a part of the system
completely, an then later enhance the system in phase. This is often done
for software products that are developed not necessarily for a client (where
the client plays an important role in requirement specification), but for
general marketing, in which the requirements are likely to be determined
largely by developers.
 Waterfall model problems-summary
 Inflexible partitioning of the project into distinct
stages makes it difficult to respond to changing
customer requirements.
 Therefore, this model is only appropriate when the
requirements are well-understood and changes
will be fairly limited during the design process.
 Few business systems have stable requirements.
 The waterfall model is mostly used for small
systems or large systems engineering projects
where a system is developed at several sites.
Evolutionary development
 Exploratory development
 Objective is to work with customers and to
evolve a final system from an initial outline
specification. Should start with well-
understood requirements and add new
features as proposed by the customer.
 Throw-away prototyping
 Objective is to understand the system
requirements. Should start with poorly
understood requirements to clarify what is
really needed.
 Evolutionary development
Concurrent
activities

Initial
Specification version

Outline Intermediate
description Development versions

Final
Validation version
Evolutionary development

 Problems
 Lack of process visibility;
 Systems are often poorly structured;
 Special skills (e.g. in languages for rapid
prototyping) may be required.
 Applicability
 For small or medium-size interactive systems;
 For parts of large systems (e.g. the user
interface);
 For short-life time systems.
Software System Development
- Prototyping
 Software System Development
Prototyping
 The goal of prototyping based development is to counter the
first two limitations of the waterfall model
 Instead of freezing the requirements before a design or coding
can proceed, a throwaway prototype is built to understand the
requirements.
 This prototype is developed based on the currently known
requirements.
 Development of the prototype obviously undergoes design,
coding and testing. But each of these phases is not done very
formally or thoroughly.
 By using this prototype, the client can get an "actual feel" of
the system, since the interactions with prototype can enable
the client to better understand the requirements of the desired
system.
 Software System Development
Prototyping
 Advantages of Prototyping
 [Link] are actively involved in the development
 [Link] provides a better system to users, as users have natural
tendency to change their mind in specifying requirements and this
method of developing systems supports this user tendency.
 [Link] in this methodology a working model of the system is
provided, the users get a better understanding of the system being
developed.
 [Link] can be detected much earlier as the system is mode side by
side.
 [Link] user feedback is available leading to better solutions.

 Disadvantages
 [Link] to implementing and then repairing way of building systems.
 [Link], this methodology may increase the complexity of the
system as scope of the system may expand beyond original plans
Component-based software
engineering
 Based on systematic reuse where systems
are integrated from existing components or
COTS (Commercial-off-the-shelf) systems.
 Process stages
 Component analysis;
 Requirements modification;
 System design with reuse;
 Development and integration.
 This approach is becoming increasingly used
as component standards have emerged.
 Reuse-oriented development

Requirements Component Requirements System design

specification analysis modification with reuse

Development System
and integ
ration validation
Process iteration
 System requirements ALWAYS evolve in the
course of a project so process iteration
where earlier stages are reworked is always
part of the process for large systems.
 Iteration can be applied to any of the generic
process models.
 Two (related) approaches
 Incremental delivery;
 Spiral development.
 Incremental delivery
 Rather than deliver the system as a single delivery, the
development and delivery is broken down into
increments with each increment delivering part of the
required functionality.
 User requirements are prioritised and the highest
priority requirements are included in early increments.
 Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.
 Incremental development

Define outline Assign requirements Design system

requirements to increments architectur
e

Develop system Validate Integrate Validate

increment increment increment system
Final
system
System incomplete
 Software System Development
The Spiral Life Cycle Model
 Four quadrants:
 Quadrant 1: Determine objectives, alternatives, and constraints.
 Quadrant 2: Evaluate alternatives, identify, resolve risks.
 Quadrant 3: Develop, verify, next-level product.
 Quadrant 4: Plan next phases.
 Activities in this model can be organized like a spiral. The spiral has many cycles.
 The radial dimension represents the cumulative cost incurred in accomplishing the steps
dome so far and the angular dimension represents the progress made in completing
each cycle of the spiral.
 Each cycle in the spiral begins with the identification of objectives for that cycle and the
different alternatives are possible for achieving the objectives and the imposed
constraints.
 Evaluate these different alternatives based on the objectives and constraints: identifying
uncertainties and risks
 Develop strategies that resolve the uncertainties and risks: activities such as
benchmarking, simulation and prototyping.
 Software is developed by keeping in mind the risks.
 Next step is determined by remaining risks. For example, its performance or user-interface
risks are considered more important than the program development risks. The next step
may be evolutionary development that involves developing a more detailed prototype for
resolving the risks.
 On the other hand, if the program development risks dominate and previous prototypes
have resolved all the user-interface and performance risks; the next step will follow the
basic waterfall approach.
Software System Development
The Spiral Life Cycle Model
Spiral development
 Process is represented as a spiral rather
than as a sequence of activities with
backtracking.
 Each loop in the spiral represents a phase in
the process.
 No fixed phases such as specification or
design - loops in the spiral are chosen
depending on what is required.
 Risks are explicitly assessed and resolved
throughout the process.
Spiral model sectors
 Objective setting
 Specific objectives for the phase are identified.
 Risk assessment and reduction
 Risks are assessed and activities put in place
to reduce the key risks.
 Development and validation
 A development model for the system is chosen
which can be any of the generic models.
 Planning
 The project is reviewed and the next phase of
the spiral is planned.
Software System Development
Iterative Enhancement Life Cycle Model
 counters the third limitation of the waterfall model and tries to combine the benefits of
both prototyping and the waterfall model.
 Software should be developed in increments, where each increment adds some
functional capability to the system until the full system is implemented.
 At each step extensions and design modifications can be made.
 a simple initial implementation is done for a subset of the overall problem. This subset is
the one that contains some of the key aspects of the problem which are easy to
understand and implement, and which forms a useful and usable system.
 A project control list is created which contains, in an order, all the tasks that must be
performed to obtain the final implementation. This project control list gives an idea of how
far the project is at any given step from the final system
 Each step consists of removing the next step from the list.
 Designing the implementation for the selected task, coding and testing the implementation,
and performing an analysis of the partial system obtained after this step and updating the
list as a result of the analysis.
 These three phases are called the design phase, implementation phase and analysis
phase. The process is iterated until the project control list is empty, at the time the final
implementation of the system will be available.
 Advantages
 it can result in better testing, since testing each increment is likely to be easier than testing
entire system like in the waterfall model.
 As in prototyping, the increments provides feedback to the client which is useful for
determining the final requirements of the system.
 Software System Development

You already
know or
You can guess
Term
Project
Scope
Software System Development
Object Oriented Methodology Life Cycle
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 the objects of the system are,
 how they behave over time or in response to events,
 what responsibilities and relationships an object has to other objects.
 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.
 System Analysis
 System Design
 Object Design
 Implementation
 The Object Oriented Methodology of Building Systems takes the objects as
the basis.
 the system to be developed is observed and analyzed and the requirements
are defined as in any other method of system development.
 the objects in the required system and their interrelationships. are identified.
( Banking System, a customer is an object, a chequebook is an object, and
even an account is an object.)
 coding is done.
Software System Development
Object Oriented Methodology Life Cycle
Model
 System Analysis
 The implementation details are not taken care of. Only the model of
the system is prepared based on the idea that the system is made up
of a set of interacting objects. The important elements of the system
are emphasized.
 System Design
 the overall architecture of the desired system is decided. The system
is organized as a set of sub systems interacting with each other.
While designing the system as a set of interacting subsystems, the
analyst takes care of specifications as observed in system analysis
as well as what is required out of the new system by the end user.
 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.
 Software System Development
Object Oriented Methodology Life Cycle

Model
Object Design
 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.
 The process-based structural programming is not used; objects are
created using data structures.
 The complete OO methodology revolves around the objects identified
in the system. When observed closely, every object exhibits some
characteristics and behavior. The objects recognize and respond to
certain events. For example, considering a Window on the screen as
an object, the size of the window gets changed when resize button of
the window is clicked.
 Here the clicking of the button is an event to which the window
responds by changing its state from the old size to the new size. While
developing systems based on this approach, the analyst makes use of
certain models to analyze and depict these objects.
Software System Development
Object Oriented Methodology Life Cycle
Model
 Class: A class is a collection of similar objects. It is a template where certain
basic characteristics of a set of objects are defined. The class defines the basic
attributes and the operations of the objects of that type. Defining a class does
not define any object, but it only creates a template. For objects to be actually
created instances of the class are created as per the requirement of the case.
 Abstraction: Classes are built on the basis of abstraction, where a set of
similar objects are observed and their common characteristics are listed. Of all
these, the characteristics of concern to the system under observation are
picked up and the class definition is made. The attributes of no concern to the
system are left out. This is known as abstraction.
 The abstraction of an object varies according to its application. For instance,
while defining a pen class for a stationery shop, the attributes of concern might
be the pen color, ink color, pen type etc., whereas a pen class for a
manufacturing firm would be containing the other dimensions of the pen like its
diameter, its shape and size etc.
 Inheritance: Inheritance is another important concept in this regard. This
concept is used to apply the idea of reusability of the objects. A new type of
class can be defined using a similar existing class with a few new features. For
instance, a class vehicle can be defined with the basic functionality of any
vehicle and a new class called car can be derived out of it with a few
modifications. This would save the developers time and effort as the classes
already existing are reused without much change.
Software System Development
Object Oriented Methodology Life Cycle
Model
 Implementation
 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.
Software System Development
Object Oriented Methodology Life Cycle
Model
The methodology supports and uses three basic Models:
 Object Model - This model describes the objects in a system
and their interrelationships. This model observes all the
objects as static and does not pay any attention to their
dynamic nature.
 Dynamic Model - This model depicts the dynamic aspects of
the system. It portrays the changes occurring in the states of
various objects with the events that might occur in the system.
 Functional Model - This model basically describes the data
transformations of the system. This describes the flow of data
and the changes that occur to the data throughout the system.

 While the Object Model is most important of all as it describes

the basic element of the system, the objects, all the three
models together describe the complete functional system
 Software System Development
Object Oriented Methodology Life Cycle
Model
Benefits:
 Reusability - The classes once defined can easily be used by other applications. This is
achieved by defining classes and putting them into a library of classes where all the
classes are maintained for future use. Whenever a new class is needed the programmer
looks into the library of classes and if it is available, it can be picked up directly from
there.
 Inheritance - The concept of inheritance helps the programmer use the existing code in
another way, where making small additions to the existing classes can quickly create new
classes. Programmer has to spend less time and effort and can concentrate on other
aspects of the system due to the reusability feature of the methodology.
 Data Hiding - Encapsulation is a technique that allows the programmer to hide the
internal functioning of the objects from the users of the objects. Encapsulation separates
the internal functioning of the object from the external functioning thus providing the user
flexibility to change the external behaviour of the object making the programmer code
safe against the changes made by the user.

Advantages of Object Oriented Methodology

 Object Oriented Methodology 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.
 Object Oriented Methodology designs encourage more re-use. New applications can use
the existing modules, thereby reduces the development cost and cycle time.
 Object Oriented Methodology approach is more natural. It provides nice structures for
thinking and abstracting and leads to modular design.
Dynamic Software Development
 DSDM is a proven and robust agile project framework that provides best
practice guidance for on time, in budget delivery of projects in any business
sector
 Microsoft Solutions Framework (MSF)
 Rational Unified Process (RUP) (IBM)
 SCRUM is also an agile development method, which concentrates
particularly on how to manage tasks within a team-based development
environment.
 XP (eXtreme Programming) is a more radical agile methodology,
focusing on the software development process and addressing the
analysis, development and test phases with novel approaches aimed
at making a substantial difference to the quality of the end product.

 In reality, there is no magic bullet for software development. The real

trick is to know lots of techniques from various waterfall and agile
development methods, and to select a mixture of the best approaches
that are most appropriate for any given situation. To do this reliably
with any degree of success really requires a lot of experience and
skill.
 Agile Software Development
 Agile teams.
 The processes we describe as Agile are environments for a team to learn how to be Agile. The
way a team works together is far more important than any process. While a new process can
easily improve team productivity by a fraction, enabling team to work effectively as a cohesive
unit can improve productivity by several times.
 Customer as a team player:
 customer, the one who funds the software development, is a valuable and essential team
member. When the dead line gets close a traditional approach to reducing scope is to let the
developers decide what will work properly and what won't. Instead let the customer make scope
decisions a little at a time throughout the project. When customer, or domain expert works
directly with the development team everyone learns something new about the problem. True
domain expertise and experience is essential to finding a simple, elegant, correct solution. A
document can have plenty of information, but real knowledge is hard to put on paper. Left alone
programmers must assume they know everything they need. When asking questions is difficult
or slow the knowledge gap grows. The system will get built, but it won't solve the problem like
one guided by an expert on a daily basis.
 Requirements Change:
 Perhaps the biggest problem with software development is changing requirements. Agile
processes accept the reality of change versus the hunt for complete, rigid specifications. There
are domains where requirements can't change, but most projects have changing requirements.
For most projects readily accepting changes can actually cost less than ensuring requirements
will never [Link] can learn so much more about the project requirements in the context of a
working system. The changes we get this way are usually the most important to implement.
 Project Management:
 Agile also means a fundamental change in how to manage projects. If working software is what
you will deliver then measure your progress by how much you have right now. Management
style is based on getting working software done a little at a time. The documents used to create
as project milestones may still be useful, just not as a measure of progress.
Agile Software Development
Changes in development
 Evolved from DSDM
 process where team empowerment and collaboration thrive to
reach full potential
 Instead of managing activities and waiting till the project ends for
software, manage requirements and demonstrate each new
version to the customer.
 There are various methodologies and standards that address various
aspects of software development, for instance PRINCE2 for Project
Management, Use Cases/UML for Analysis and Design, ISEB for Testing.
Although these are typically applied to Waterfall development projects,
elements of these methods can also be applied in an agile development
approach.
10 Principles
 1. Active user involvement is imperative
 2. The team must be empowered to make decisions
 3. Requirements evolve but the timescale is fixed
 4. Capture requirements at a high level; lightweight & visual
 5. Develop small, incremental releases and iterate
 6. Focus on frequent delivery of products
 7. Complete each feature before moving on to the next
 8. Apply the 80/20 rule
 9. Testing is integrated throughout the project lifecycle – test
early and often
 10. A collaborative & cooperative approach between all
stakeholders is essential