Event-Driven Programming Ch-1 Introduction 2012 E.C.

Table of Contents
Chapter One: Introduction ............................................................................................................................ 2
1.1. Introduction to Software Development........................................................................................ 2
1.2. Software Development Approaches ............................................................................................. 2
1.2.1. The Waterfall Model ............................................................................................................. 2
1.2.2. Agile Methods ....................................................................................................................... 2
1.2.3. The Rational Unified Process (RUP) ...................................................................................... 4
1.2.4. Rapid Application Development ........................................................................................... 4
1.2.5. Extreme Programming .......................................................................................................... 5
1.3. Rapid Application Development ................................................................................................... 6
1.4. Software Development Principles................................................................................................. 9

Bantamlak Dejene; Semera University Department of Information 1

Technology
 Event-Driven Programming Ch-1 Introduction 2012 E.C.

Chapter One: Introduction

1.1. Introduction to Software Development
Software development is a complicated process. It requires careful planning and execution to
meet the goals. Sometimes a developer must react quickly and aggressively to meet ever
changing market demands. Maintaining software quality hinders fast-paced software
development, as many testing cycles are necessary to ensure quality products.
A commercial software product is usually derived from market demands. Sales and marketing
people have first-hand knowledge of their customers’ requirements. Based upon these market
requirements, senior software developers create architecture for the products along with
functional and design specifications. Then the development process starts. After the initial
development phase, software testing begins, and many times it is done in parallel with the
development process. Documentation is also part of the development process because a product
cannot be brought to market without manuals. Once development and testing are done, the
software is released and the support cycle begins. This phase may include bug fixes and new
releases.
1.2. Software Development Approaches
1.2.1. The Waterfall Model
The waterfall model particularly expresses the interaction between subsequent phases. Testing
software is not an activity which strictly follows the implementation phase. In each phase of the
software development process, we have to compare the results obtained against those that are
required. In all phases, quality has to be assessed and controlled. Verification asks if the system
meets its requirements (are we building the system right) and thus tries to assess the correctness
of the transition to the next phase. Validation asks if the system meets the user’s requirements
(are we building the right system).
1.2.2. Agile Methods
When using a heavyweight development method, it is difficult to change direction. Once the
contract has been signed, the development team’s job is to deliver the functionality as laid down
in the contract. If reality changes or the user gets a different insight, such is difficult to
accomplish. It does not fit the architecture, it requires rework not accounted for, it lengthens the
agreed upon schedule, and so on. It is a train that does not easily change direction.

Bantamlak Dejene; Semera University Department of Information 2

Technology
 Event-Driven Programming Ch-1 Introduction 2012 E.C.

This has been recognized over the years, and methods like prototyping and evolutionary
development ensued. But these methods still somehow carry an engineering flavor with them.
Essentially, they still assume the world is ordered. It may be difficult to pinpoint the true
requirements right away, but they will accrue over time.
True agile methods view the world as fundamentally chaotic. They assume change is inevitable.
Their focus is to deliver value to the customer as quickly as possible, and not bother about
extensive plans and processes that won’t be followed anyway. The key values of the agile
movement are:
Individuals and interactions: - over processes and tools.
Working software: - over comprehensive documentation.
Customer collaboration: - over contract negotiation.
Responding to change: - over following a plan.
Agile methods involve the users in every step taken. The development cycles are small and
incremental. The series of development cycles is not extensively planned in advance, but the new
situation is reviewed at the end of each cycle. This includes some, but not too much, planning for
the next cycle. Agile methods do not have an extensive architectural or design phase up front.
After all, it does not make sense to spend much effort on design if you know this will quite likely
be a waste of time. It is more effective to only do the design as far as needed for the immediate
next step. Agile methods often have a separate activity to improve the design after each
increment, known as refactoring.
Agile methods are people-oriented, rather than process-oriented. They emphasize the human
element in software development. Team spirit is considered very important. Team relationships
are close. Often, an agile team occupies one big room. The users are onsite as well. Agile
methods have short communication cycles between developers and users, and between
developers. Finally, agile methods do not spend much energy on documentation. It will have
to change anyhow, so why spend time on something that will soon be outdated. Rather, agile
methods rely on the tacit knowledge of the people involved. If you have a question, ask one of
your pals. Do not struggle with a large pile of paper that quite likely will not provide the answer
anyway. Some people contend that agile methods should be ‘pure’, and exhibit all of the
characteristics mentioned above. Others believe that a mixture of planning-driven and agile
methods can be productive as well.

Bantamlak Dejene; Semera University Department of Information 3

Technology
 Event-Driven Programming Ch-1 Introduction 2012 E.C.

1.2.3. The Rational Unified Process (RUP)

The Rational Unified Process is an iterative development process, geared towards the
development of object-oriented systems. It comes with a lot of tool support, inter/intranet sources
and templates for different kinds of documents. It complements UML, the Unified Modeling
Language. RUP might be viewed as somewhat intermediate between document-driven and agile
methods. It has a well-defined process, includes reasonably extensive upfront requirements
engineering activities, and yet emphasizes stakeholder involvement through its use-case driven
nature.
RUP distinguishes four phases: inception, elaboration, construction and transition. Within each
phase, several iterations may occur. In a second dimension, RUP distinguishes nine so-called
workflows, such as a requirements workflow and a test workflow. These workflows group
logical activities, and might extend over all phases, with varying levels of attention. For instance,
the requirements workflow is likely to get a lot of attention during the early phases, while the
deployment workflow is most relevant in the transition phase.
1.2.4. Rapid Application Development
Rapid Application Development (RAD) has a lot in common with other iterative development
process models. It emphasizes user involvement, prototyping, reuse, the use of automated tools,
and small development teams. In addition to that, it employs the notion of a time box, a fixed
time frame within which activities are done. In most development models, a set of requirements
is fixed and then the project attempts to fulfill these requirements within some estimated period
of time. Within RAD, the time frame is decided upon first and then the project tries to realize the
requested functionality within that time frame. If it turns out that not all of the functionality can
be realized within the time frame, some of the functionality is sacrificed. The agreed deadline
however is immovable.
The RAD life cycle consists of four phases:
Requirements planning, Construction,
User design, Cutover.
The requirements planning and user design phases have much in common and may be combined
for smaller projects. Together, they typically take less than two months. The main techniques
used in these phases are known as Joint Requirements Planning (JRP) and Joint Application

Bantamlak Dejene; Semera University Department of Information 4

Technology
 Event-Driven Programming Ch-1 Introduction 2012 E.C.

Design (JAD). Both these techniques make heavy use of workshops in which the developers and
the prospective users work together.
The goal of the JRP workshop is to get the requirements right the first time. For that reason, it is
imperative that the key players, i.e. the end users of the system, be present. During the JRP
workshop too, requirements are prioritized, since it is likely that not all of them will be
implemented in the first version of the system. This requirement prioritization is known as
triage. Triage usually means a process used on the battlefield and in emergency rooms to sort
injured people into groups based on their need for or likely benefit from immediate medical
treatment. In RAD, the triage process is used to make sure that the most important requirements
are addressed first. The result of this process is often a prioritization denoted by the acronym
MoSCoW:
Must haves are requirements that are definitely needed.
Should haves are requirements that are important, but not absolutely needed for a usable system.
Could haves are requirements that are only implemented if time allows so.
Won’t haves are requirements that will be left for the next iteration.
1.2.5. Extreme Programming
Extreme Programming, XP for short, is a pure agile method. XP is based on a number of best
practices that have been known for long. XP takes these practices to extreme levels. In XP, one
does this all the time: two programmers work together behind one computer screen. One of them
does the coding, the other one looks over his/er shoulder, gives advice, notices small slips, asks
questions, and the like. They act as pilot and co-pilot. At any point in time, the roles may shift.
This practice is called pair programming.
Typically, an XP team is not too big, and occupies one room. Planning meetings are very short,
and involve the immediate functionality to be delivered to the customer. Planning involves both
the customer and the technical people. The customer has to set priorities, determine dates of
releases, and the like. The customer describes desirable features of the system in stories, on index
cards. The technical people estimate how long it takes to implement a story, decide on the order
in which stories within one release will be implemented, etc.
In XP, the design is kept as simple as possible. Since the future is, after all, unclear, there is no
use to design a grand scheme that will not be followed anyhow. So the design only covers the
current version of the system. After a task is accomplished, the system is checked to see how it

Bantamlak Dejene; Semera University Department of Information 5

Technology
 Event-Driven Programming Ch-1 Introduction 2012 E.C.

can be improved (remove duplicate code, make it simpler, make it more flexible). This is called
refactoring. This refactoring need not be restricted to one’s own code. Everyone is responsible
for the whole system. To make this work, one needs to set coding standards.
When a team works on implementing a story, it writes tests to check the implementation of that
story at the same time. Before the new code is checked in, all these tests have to run successfully.
After the code has been checked in, the full test suite is run, and again all tests have to run
successfully. If not, the new code is removed again to fix it. This way, there always is a running
system.
XP is based on five principles that drive its practices:
Rapid feedback is obtained quickly, within hours, or at most a few days. By testing each small
piece added, developers immediately learn what works and what doesn’t. By frequently
delivering a running system to the customer, the customer learns what value the system offers,
and what next features are needed.
Assume simplicity Today’s job is done today, and tomorrows job is left for tomorrow. Don’t
build in extra complexity so that a certain class becomes more flexible and may be reused if a
certain feature is to be added. If and when this feature is needed, it will be added, and code will
be refactored to make it simpler.
Incremental change In XP, things change in small increments. The plan changes a little at a
time, the design changes a little, the team changes a little, etc.
Embracing change by not planning, designing, coding more than is needed right now, the most
options for the futures are kept. Only the most pressing problem is tackled today. The rest is left
for tomorrow.
Quality work Quality is a must. The team should find pride in delivering excellent quality.
1.3. Rapid Application Development
Rapid applications development (RAD) appears to have first become topical with the publication
of a text by James Martin with the same title (Martin, 1992). Martin defines the key objectives of
RAD as: high quality systems, fast development and delivery and low costs. These objectives
can be summed up in one sentence: the commercial need to deliver working business
applications in shorter timescales and for less investment. With little variation the tenets of RAD
are essentially those of software development in general: methodology or choice of architectures

Bantamlak Dejene; Semera University Department of Information 6

Technology
 Event-Driven Programming Ch-1 Introduction 2012 E.C.

and tools, requirements and design analyses, selection of personnel and management,
construction, and implementation and support.
Software development is no longer an enterprise where the traditional waterfall method of
system construction is acceptable. Information technology is changing at a pace that requires
complete system development and fielding in less than 18 months. This is due in part to faster
technology insertion, and in part by increased user expectations. Both reasons provide
justification for changing the way software is built and fielded. Increased user expectations
require that we involve the user more in the requirements engineering process, and deliver the
software to the user much more quickly. Faster technology insertion requires that we incorporate
new technology into existing products much faster and with less rework.
A new software evolution paradigm is needed to accomplish these goals, along with the
automated tools to realize the benefits. Computer Aided Prototyping is one such method that
incorporates the goals and opinions of the user from the beginning of the software evolution
process, throughout the lifecycle, and into retirement. The prototype is then used to build the
final version of the software through the use of the architecture included in the prototype, as well
as the validated set of requirements constructed during the prototyping process. The resulting
final version is delivered relatively quickly, hopefully before the user’s requirements have an
opportunity to change. This is often not sufficient to satisfy some users. If the demonstration of a
prototype to a customer results in the validation of the requirements for that system, the user may
want to take the prototype as is. Since most prototypes are not industrial strength, this may not be
possible. When the user’s requirements do change, new requirements can be incorporated into a
next version of the system by using the same iterative process where the fielded version of the
system provides the base version of the process. This incremental evolution process can proceed
throughout the life of the system.
Components
The following appear to be the common components of RAD approaches discussed in the
literature:
A. Joint application design (JAD
RAD seems to be characterized by small development teams of typically four to eight persons.
Such teams are made up of both developers and users who are empowered to make design
decisions. This means that all RAD team members must be skilled both socially and in terms
Bantamlak Dejene; Semera University Department of Information 7
Technology
 Event-Driven Programming Ch-1 Introduction 2012 E.C.

of the business. Users must possess detailed knowledge of the application area; developers must
be skilled in the use of advanced tools. Hence, ‘team-building’ activities such as team dinners are
seen as an important part of a RAD project.
Most approaches to RAD seem to use joint application development (JAD) workshops at various
points in the development process, particularly to elicit requirements. In such workshops, key
users, the client, some developers and business requirements under the direction of a ‘facilitator’.
Development teams are usually expected to come up with fully documented business
requirements in three to five days. Such requirements may specify a series of phased deliverables
over a given time-span. Further development workshops may be scheduled during the
life of a project to develop jointly each deliverable.
B. Rapidity of development
RAD projects seem to be typically of relatively small scale and of short duration. Also, two to
six months is frequently discussed as being a normal project length. The main rationale being
that any project taking more than six months to complete is likely to be overtaken by business
developments. In total, it has been suggested that no more than six man-years of development
effort should be devoted to any particular RAD project.
C. Clean rooms
JAD workshops are usually expected to take place away from the business and developer
environments in ‘clean’ rooms—that is, places free from everyday work interruptions and full of
requisite support facilities such as flip charts, post-its, coffee, computers etc. The emphasis is
on highly focused problem solving.
D. Time boxing
Project control in RAD is seen to involve scoping the project by prioritizing development and
defining delivery deadlines or ‘time boxes’. If projects start to slip, the emphasis in RAD
projects is on reducing the requirements to fit the time box, not in increasing the deadline.
E. Incremental prototyping
RAD is frequently discussed in terms of incremental prototyping and phased deliverables.
Prototyping is essentially the process of building a system in an iterative way. The developers,
after some initial investigation, construct a working model that they demonstrate to a
representative user group. The developers and the users then discuss the prototype, agreeing on
enhancements and amendments. This cycle of inspection-discussion amendment is usually

Bantamlak Dejene; Semera University Department of Information 8

Technology
 Event-Driven Programming Ch-1 Introduction 2012 E.C.

repeated at least three times in RAD projects, until the user is satisfied with the system.
In RAD, prototyping may be used at any stage of development: requirements gathering;
application design; application build; testing; delivery.
F. Rapid development tools
It is not surprising to find that modern approaches to RAD demand good support from tools for
rapid developmental change. This normally means some combination of fourth generation
languages, graphical user interface builders, database management systems and computer-aided
software engineering tools. Using such tools some changes to prototypes can be made in situ at
user-developer meetings.
G. Highly interactive, low complexity projects
Most RAD projects seem to be conducted on applications that are highly interactive, have a
clearly defined user group and are not computationally complex. It apparently took the
development team only three months to convert this system for the household sector. The
tendency is to rule out the applicability of RAD for large-scale, infrastructure projects,
particularly the construction of large, distributed information systems such as corporate-wide
databases. Evidence suggests that such infrastructure is best put in place before undertaking
RAD projects. Such an infrastructure can then act as a feeder to systems developed using RAD.
This is perhaps not surprising when one considers that most RAD tools work off a database in
some way. Therefore, the database needs to be created before application development begins.
1.4. Software Development Principles
Criteria for a set of basic principles
The criteria for a set of basic principles should be similar to those for a set of basis vectors for a
vector space:
1. They should be independent.
2. The entire space (of useful software principles) should be representable (or implied) by
combinations of the basic principles.
Seven basic principles are involved. These are:
1. Manage using a phased life-cycle plan.
 Create and Maintain a Life-Cycle Project Plan.
 Importance of the project plan.
 Essentials of a software project plan.
Bantamlak Dejene; Semera University Department of Information 9
Technology
 Event-Driven Programming Ch-1 Introduction 2012 E.C.

 Orient the Plan around a Phased Development Approach.

 Use the Plan to Manage the Project.
2. Perform continuous validation.
 Problem Symptoms.
 Getting Errors Out Early.
3. Maintain disciplined product control.
 The Need for Product Control.
 Baseline Configuration Management.
4. Use modern programming practices.
 Results to Date.
5. Maintain clear accountability for results.
 Macro scale Accountability.
 Intermediate-Scale Accountability.
 Individual Accountability.
 Summary.
6. Use better and fewer people.
 Variability among Personnel.
 Interpersonal Communications Overhead.
 Automated Aids.
7. Maintain a commitment to improve the process.
 Data Collection and Analysis.
 Maintaining Perspective.

Bantamlak Dejene; Semera University Department of Information 10

Technology