MCS-044

Mini Project
Question 1
Answer

Systems Development Life Cycle, or Software Development Life Cycle (SDLC),

relates to models or methodologies that people use to develop systems, generally
computer systems. Computer systems have become more complex and usually
(especially with the advent of Service-Oriented Architecture) link multiple traditional
systems often supplied by different software vendors.
To manage this, a number of system development life cycle (SDLC) models have
been created: waterfall, fountain, spiral, build and fix, rapid prototyping,
incremental, and synchronize and stabilize. Although in the academic sense, SDLC
can be used to refer to various models, SDLC is typically used to refer to a waterfall
methodology.

Phases
SDLC adheres to important phases that are essential for developers, such as
planning, analysis, design, and implementation, and are explained in the section
below. There are several SDLC Models in existence. The oldest model, that was
originally regarded as “the SDLC” is the waterfall model: a sequence of stages in
which the output of each stage becomes the input for the next. These stages
generally follow the same basic steps but many different waterfall methodologies
give the steps different names and the number of steps seems to vary between 4
and 7.

There is no definitively correct SDLC model, but the steps can be characterized and
divided as follows:

Initiation/Planning

To generate a high-level view of the intended project and determine the goals of the
project. The feasibility study is sometimes used to present the project to upper
management in an attempt to gain funding. Projects are typically evaluated in three
areas of feasibility: economical, operational, and technical. Furthermore, it is also
used as a reference to keep the project on track and to evaluate the progress of the
MIS team (Post & Anderson, 2006). The MIS is also a complement of this phase. This
phase is also called the analysis phase.

Requirements Gatherings And Analysis

The goal of systems analysis is to determine where the problem is in attempt to fix
the system. This step involves breaking down the system in different pieces and
drawing diagrams to analyze the situation. Analysts project goals, breaking down
functions that need to be created, and attempt to engage users so that definite
requirements can be defined.

Design

Functions and operations are described in detail, including screen layouts, business
rules, process diagrams and other documentation. The output of this stage will
describe the new system as a collection of modules or subsystems.
Build or Coding

Modular and subsystem programming code will be accomplished during this stage.
This stage is intermingled with the next in that individual modules will need testing
before integration to the main project. Planning in software life cycle involves setting
goals, defining targets, establishing schedules, and estimating budgets for an entire
software project.

Testing

The code is tested at various levels. Unit, system and user acceptance testing are
often performed. This is a grey area as many different opinions exist as to what the
stages of testing are and how much if any iteration occurs. Iteration is not generally
part of the waterfall model, but usually some occurs at this stage.

Types of testing:
• Data set Testing
• Unit Testing
• System Testing
• Integration Testing
• User acceptance
• Black Box Testing
• White Box Testing

Operations and Maintenance

The life of the system includes changes and enhancements before the
decommissioning or sunset of the system. Maintaining the system is an important
aspect of SDLC. As key personnel change positions in the organization, new changes
will be implemented, which will require system updates.

Baselines in the SDLC

Baselines are an important part of the SDLC. These baselines are established after
four of the five phases of the SDLC and are critical to the iterative nature of the
model (Blanchard & Fabrycky, 2006, p.31). Each baseline is considered as a
milestone in the SDLC.

Question 2
Answer

Cost-benefit analysis is a term that refers both to:

• a formal discipline used to help appraise, or assess, the case for a project or
proposal, which itself is a process known as project appraisal; and
• an informal approach to making decisions of any kind.

Cost Benefit Analysis is typically used by governments to evaluate the desirability of

a given intervention in markets. The aim is to gauge the efficiency of the
intervention relative to the status quo. The costs and benefits of the impacts of an
intervention are evaluated in terms of the public's willingness to pay for them
(benefits) or willingness to pay to avoid them (costs). Inputs are typically measured
in terms of opportunity costs - the value in their best alternative use. The guiding
principle is to list all of the parties affected by an intervention, and place a monetary
value of the effect it has on their welfare as it would be valued by them.

The process involves monetary value of initial and ongoing expenses vs. expected
return. Constructing plausible measures of the costs and benefits of specific actions
is often very difficult. In practice, analysts try to estimate costs and benefits either
by using survey methods or by drawing inferences from market behavior. For
example, a product manager may compare manufacturing and marketing expenses
to projected sales for a proposed product, and only decide to produce it if he expects
the revenues to eventually recoup the costs. Cost-benefit analysis attempts to put all
relevant costs and benefits on a common temporal footing. A discount rate is
chosen, which is then used to compute all relevant future costs and benefits in
present-value terms. Most commonly, the discount rate used for present-value
calculations is an interest rate taken from financial markets (R.H. Frank 2000). This
can be very controversial - for example, a high discount rate implies a very low value
on the welfare of future generations, which may have a huge impact on the
desirability of interventions to help the environment, and so on. Empirical studies
have suggested that in reality, people's discount rates do decline over time. Because
CBA aims to measure the public's true willingness to pay, this feature is typically
built into studies.

Technical Feasibility

The Technical Feasibility Study assesses the details of how you will deliver a product
or service (i.e., materials, labor, transportation, where your business will be located,
technology needed, etc.). Think of the technical feasibility study as the logistical or
tactical plan of how your business will produce, store, deliver, and track its products
or services.

A technical feasibility study is an excellent tool for trouble-shooting and long-term

planning. In some regards it serves as a flow chart of how your products and services
evolve and move through your business to physically reach your market.

The Technical Feasibility Study Must Support Your Financial

Information

Do not make the mistake of trying to entice investors with your staggering growth
projections and potential returns on their investment that only includes income
(revenue) to the business. With any increase in revenue there is always an increase
in expenses. Expenses for technical requirements (i.e., materials and labor) should
be noted in the technical feasibility study.

You should also not strictly rely on feasibility study conclusions to impress an
investor. An experienced investor or lending institution will read your entire report
and come to their own conclusions. Therefore, it is critical that the technical and
financial data in your study reconcile. If other parts of your feasibility study shows
growth, you will also have to project labor and other costs and the technical ability to
support that growth. The technical component serves as the written explanation of
financial data because if offers you a place to include detailed information about why
an expense has been projected high or low, or why it is even necessary. It
demonstrates to potential investors and lenders (and in some cases, potential
clients) that you have thought about the long-term needs your business will have as
it grows.

• Materials
• Labor
• Transportation or Shipping
• Physical Location
• Technology

Feasibility analysis of a hard-real-time system refers to the process of determining

off-line whether the specified system will meet all deadlines at runtime. For many
important (and interesting) task models and scheduling algorithms, feasibility
analysis is provably computationally very expensive. A framework is established for
speeding up the feasibility analysis of uniprocessor real-time systems by
implementing these algorithms on parallel machines. The viability of this framework
is validated by developing a parallel algorithm for the feasibility analysis of systems
of asynchronous periodic tasks that are to be scheduled using the preemptive
earliest deadline first scheduling algorithm, and by implementing and testing the
performance of this parallel algorithm.

Transaction operational feasibility (TOF) analysis is important in electricity markets

to ensure reliable and secure operation of power systems. This paper presents a
web-based design and implementation of TOF analysis, based on three-tier
client/server architecture and up to date web technologies, so that the TOF analysis
can be easily and effectively accessed by all market participants for competitive
decision making. The proposed TOF analysis is based on approximate ATC
computations for efficient real-time market operation. A 3-area system example is
given for illustration purposes.

Gantt and PERT Charts

Gantt and PERT charts are visualization tools commonly used by project managers to
control and administer the tasks required to complete a project.

The Gantt chart, developed by Charles Gantt in 1917, focuses on the sequence of
tasks necessary for completion of the project at hand. Each task on a Gantt chart is
represented as a single horizontal bar on an X-Y chart. The horizontal axis (X-axis) is
the time scale over which the project will endure. Therefore, the length of each task
bar corresponds to the duration of the task, or the time necessary for completion.
Arrows connecting independent tasks reflect the relationships between the tasks it
connects. The relationship usually shows dependency where one task cannot begin
until another is completed. The resources necessary for completion are also
identified next to the chart. The Gantt chart is an excellent tool for quickly assessing
the status of a project. The following Gantt chart was developed using MS Project for
developing a proposal.

Making this chart is a pretty self explanatory task. Almost all controls are available
by double clicking task names in the column on the left. This chart shows the
resources, completion (shown by the horizontal black line within the task bar), and
prerequisite relationships....all controllable through double clicking appropriate task
name on the left. You can change the time scale on the top by right click....time
scale option. Its basically controlled by typical Microsoft actions used in any MS
application.

PERT (Program Evaluation and Review Technique) charts were first developed in the
1950s by the Navy to help manage very large, complex projects with a high degree
of inter-task dependency. Classical PERT charting is used to support projects that are
often completed using an assembly line approach. MS Project can create a PERT
chart from a Gantt chart. The PERT below is another representation of the Proposal
project shown above.

Question 3
Answer

Again, the representation above is relatively self explanatory. The completed tasks
have been crossed out while partially completed tasks have one slash through them.
The tasks also show duration, beginning date and ending date. The critical path
(shown in red) is a series of tasks that must be completed on schedule for a project
to finish on schedule. Each task on the critical path is a critical task. Most tasks in a
typical project have some slack and can therefore be delayed a little without
affecting the project finish date. Those tasks that cannot be delayed without
affecting the project finish date are the critical tasks. As you modify tasks to resolve
over allocations or other problems in your schedule, be aware of the critical tasks
and that changes to them will affect your project finish date.