MCS-044

Mini Project

Question 1
Ans

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 those 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
Ans

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 behaviour. 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 intertask dependency. Classical PERT charting is used to
support projects that are often completed using an assemply 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
Ans
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 overallocations or other problems in your
schedule, be aware of the critical tasks and that changes to them will affect
your project finish date.