Mcs-044 Solved Assignment

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.