Advantages and disadvantage of the SDLC

The following are some of the advantages of the SDLC:

 It enhances control and monitoring of large project.
 It is formed of well detailed step.
 The orderly sequence of development steps and strict controls ensures the
adequacy of documentation.
 the design reviews help to ensure the quality, reliability, and maintainability of the
developed software or solution.
 The progress and the cost of system development, completion targets are
measurable.
These are some of the disadvantages of the SDLC:
 Increases the development time and cost
 Difficulty to estimate the cost of the project
 The performance of the system cannot be tested until it is almost fully coded.
 The system details have to be specified up front
 It increases the amount of documentation as time advances.
Advantages:

 Applicable to complex projects.

 Provides a common framework.
 Defines expectations with Business Areas and ensures their written
approval.
 Work for outsourced contracts.
 Can have different teams and specialization for each phase
Disadvantages:

 Not applicable at all to simple or evolutionary projects.

 If the scope is not too big adds a lot of overhead and cost.
 Humans are not really good at defining everything in detail before seeing it.
This requires a high level of abstraction.
 Sometimes add complex and not used scope: “Let´s add this, just in case”
 Not applicable to the new digital environment.

 Starting with the advantages

 1. Formal review is created at the end of each stage allowing maximum management
control.
 2. This approach creates considerable system documentation.
 3. This documentation ensures that system requirements can be traced back to stated
business requirements.
 4. It produces many intermediate products that can be reviewed to see whether they meet
the user’s needs and conform to standards. These can be further worked on if they require
tweaks to be made, ensuring that the business gets exactly what it needs.
 There are always disadvantages with everything…
 1. What may be seen as a major problem for some, end-user does not see the solution
until the system is almost complete.
  2. Users get a system that meets the need as understood by the developers; this may not
be what was really needed for them. There may be a loss in translation.
 3. Documentation is expensive and time-consuming to create. It is also difficult to keep
current. What may be current this month may not be the same this time next year!
 4. Users cannot easily review intermediate products and evaluate whether a particular
product (e.g., data flow diagram) meets their business requirements.
 5. Another disadvantage of a program or software that follows the SDLC program is it
encourages stiff implementation instead of creativity. There are requirements that must
be met and that is all that developers complete.

In computer programming, event-driven programming is a programming paradigm in which

the flow of the program is determined by events such as user actions (mouse clicks, key
presses), sensor outputs, or messages from other programs/threads. Event-driven programming
is the dominant paradigm used in graphical user interfaces and other applications (e.g.
JavaScript web applications) that are centered on performing certain actions in response to user
input. This is also true of programming for device drivers (e.g. P in USB device driver stacks[1]).
In an event-driven application, there is generally a main loop that listens for events, and then
triggers a callback function when one of those events is detected. In embedded systems the
same may be achieved using hardware interrupts instead of a constantly running main loop.
Event-driven programs can be written in any programming language, although the task is easier
in languages that provide high-level abstractions, such as closures.

Event-driven programming is a programming paradigm in which the flow of program

execution is determined by events - for example a user action such as a mouse click, key
press, or a message from the operating system or another program. An event-driven
application is designed to detect events as they occur, and then deal with them using an
appropriate event-handling procedure. The idea is an extension of interrupt-driven
programming of the kind found in early command-line environments such as DOS, and in
embedded systems (where the application is implemented as firmware). Event-driven
programs can be written in any programming language, although some languages(Visual
Basic for example) are specifically designed to facilitate event-driven programming, and
provide an integrated development environment (IDE) that partially automates the production
of code, and provides a comprehensive selection of built-in objects and controls, each of
which can respond to a range of events. Virtually all object-oriented and visual languages
support event-driven programming. Visual Basic, Visual C++ and Java are examples of such
languages.

How event-driven programming works

The central element of an event-driven application is a scheduler that receives a stream of

events and passes each event to the relevant event-handler. The scheduler will continue to
remain active until it encounters an event (e.g. "End_Program") that causes it to terminate the
application. Under certain circumstances, the scheduler may encounter an event for which it
cannot assign an appropriate event handler. Depending on the nature of the event, the
scheduler can either ignore it or raise an exception (this is sometimes referred to as "throwing"
an exception). Within an event-driven programming environment, standard events are usually
identified using the ID of the object affected by the event (e.g. the name of a command button
on a form), and the event ID (e.g. "left-click"). The information passed to the event-handler
may include additional information, such as the x and y coordinates of the mouse pointer at
the time the event occurred, or the state of the Shift key (if the event in question is a key-
press).

Events are often actions performed by the user during the execution of a program, but can
also be messages generated by the operating system or another application, or an interrupt
generated by a peripheral device or system hardware. If the user clicks on a button with the
mouse or hits the Enter key, it generates an event. If a file download completes, it generates
an event. And if there is a hardware or software error, it generates an event. The events are
dealt with by a central event-handler (usually called a dispatcher or scheduler) that runs
continuously in the background and waits for an even to occur. When an event does occur,
the scheduler must determine the type of event and call the appropriate event-handler to deal
with it. The information passed to the event handler by the scheduler will vary, but will include
sufficient information to allow the event-handler to take any action necessary.

Event-handlers can be seen as small blocks of procedural code that deal with a very specific
occurrence. They will usually produce a visual response to inform or direct the user, and will
often change the system’s state. The state of the system encompasses both the data used by
the system (e.g. the value stored in a database field), and the state of the user interface itself
(for example, which on-screen object currently has the focus, or the background colour of a
text box). An event handler may even trigger another event too occur that will cause a second
event-handler to be called (note that care should be taken when writing event handlers that
invoke other event-handlers, in order to avoid the possibility of putting the application into an
infinite loop). Similarly, an event-handler may cause any queued events to be discarded (for
example, when the user clicks on the Quit button to terminate the program).The diagram
below illustrates the relationship between events, the scheduler, and the application’s event-
handlers.

Key features and characteristics of event-driven programming

Service Oriented

Service oriented is a key features in event-driven programming that used to write programs that
are made for services and it takes does not slow down the computer as service oriented only
consume little of the computer processing power and usually services run in the background of
OS.

Time Driven

In event driven programming, time driven is a paradigm, it's a code that runs on a time trigger,
time driven can be a specific code that runs on a specific time, which could be once an hour,
once a week or once a month, this means it's a pre-set to do task. For example, windows update
is the example of time driven, which user can set when to update or when to check and
download the update.

Event Handlers

Event handlers is a type of function or method that run a specific action when a specific event
is triggered. For example, it could be a button that when user click it, it will display a message,
and it will close the message when user click the button again, this is an event handler.

Trigger Functions

Trigger functions in event-driven programming are a functions that decide what code to run
when there are a specific event occurs, which are used to select which event handler to use for
the event when there is specific event occurred.

Events

Events include mouse, keyboard and user interface, which events need to be triggered in the
program in order to happen, that mean user have to interacts with an object in the program, for
example, click a button by a mouse, use keyboard to select a button and etc.

Simplicity of Programming and Ease of Development

Event-driven programming is simple and easier to program compared to other type of

programming as it's very visual, for example you can place a button by just select it and place
it onto a form and write a code for it. Event-driven programming also easy for user to insert a
pre-written code scripts into an existing application because it allows user to pause the code
while it's running. Which make developing using event-driven programming is easy.

Service Oriented: service oriented programmes are programmes that often appear in the
background and have no user interface to use but all have the ability to be stopped and started
at the users will. These programmes can also be set to activate immediately when your pc starts
up. Examples of these sort of programmes are Bluetooth, Autodesk functions, NVidia display
driver and other programmes that offer customizable features that are not necessarily essential
for your computer to have. Also because these programmes are constantly using your memory
for background programmes which may be non crucial to the running/ maintaining of your pc
it can be seen by many as a waste of memory for some of the functions being run.

Time Driven: Time Driven programmes such as antivirus scans, task scheduler and operating
system updates are important features in the maintain and running of your pc. These events
follow real time settings and variables in there programming generally used to plan out
maintence and update tasks that occur on future dates and at future times. Because of this time
settings they can be planned to take place at regular intervals that does not have to be
independently monitored by the user and will not be interrupted by other programmes and
processes taking place while the timer to begin this is important when it comes to safety critical
operations such as antivirus scans and updates.

Event Handlers:

Event handlers within programming are sections of code that are set out to denote the actions
of event triggers within the coding structure e.g. the effect it will have on the programme if I
right or left click can have different results if programmed differently leading to a secondary
programming step of the code giving an alternate outcome. The image above shows an example
of sub procedure created in visual basic that utilizes the trigger of closebutton_click which
means that a button within the programme will close when the user triggers it by clicking.

Trigger functions: trigger functions are used to be able to designate a specific coded event with
an action e.g. click the button to trigger the calculation on a calculator which works out the
result based on your input numbers until the event is triggered. The trigger functions are a big
part of the appeal of object oriented programming because it gives the user a lot of flexibility
in the way that they are able to trigger events within there programmes.

Events: events can be sub categorized into five different categories which refers to different
hardware and software uses of events. These events are: mouse events, keyboard events,
HTML object events, Form events and User Interface Events.
Mouse events: mouse events refer to actions performed by the mouse which can be dependant
on either mouse buttons e.g. left click, right click, double click; the scroll wheel e.g. scroll up,
scroll down, scroll wheel click or even mouse motion and movement sensor e.g. mouse move
forward, back, left, right.

Keyboard Events: Keyboard events refer to actions performed with a keyboard which is
dependant on either individual key presses of any keys on the board or even a combination a
good example of this is Ctrl+Alt+Delete function which triggers a windows menu which allows
you to lock your computer; change your password or open your task manager using a windows
operating system.

Html Events: Html events such as onclick, onmousemove and onkeydown is used in online
applications using software like JavaScript and cascading style sheets which are designed for
working on browser applications. These triggers are not to be confused with hardware mouse
and keyboard events despite being similar these events are only for use on web browsers.

The event queue

In an event-driven system, a number of events can occur in a relatively short space of time.
The scheduler, and the event-handlers at its disposal, may not be able to handle all of the
events immediately they occur. The obvious solution is to place unhandled events into
an event queue until such time as they can be dealt with. Events are added to the end of the
queue as they arrive, and are dealt with by the scheduler once they reach the front of the
queue. There may well also be a priority scheme in operation in which certain types of event
take priority over others. Such events may be fast-tracked through the scheduler by moving
them to the head of the queue, or there may be a separate queue for priority events. The
existence of the queue guarantees that all events will be handled at some point, and in some
semblance of order. The length of the queue, and the time taken to process events, will
probably depend on factors such as the speed of the processor, the amount of installed RAM,
and the number of other applications that are running at the same time (which will obviously
be competing for the same system resources). Much of the time, however, the queue will be
empty, and the scheduler will be in an idle state waiting for the next event.
GUI programming