Site icon Pharmawiki.in

#PPT PDF Technical analysis | Components |Technical arrangement | Solutions | Use Cases

Technical Analysis:

The broad purpose of technical analysis is:

Technical analysis is essential to ensure that necessary physical facilities required for production will be available and the best possible alternatives is selected to procure them. These are to be assessed by common sense, experience and discussions with the promoters

 

  1. Manufacturing Process / Technology

 

  1. Technical arrangement

 

  1. Size of the plant

 

  1. Product Mix

 

  1. Selection of Plant and Machinery

 

  1. Procurement of Plant and Machinery

 

  1. Plant lay out

 

  1. Location of the plant.

 

  1. Land

 

  1. Raw Material

 

 

  1. Labour

 

  1. Utilities such as water, Power, fuel etc.

 

  1. Effluent disposal

 

 

  1. Schedule of Project Implementation

 

  1. Manufacturing Process / Technology

 

Appropriateness of Technology

It refers to those methods of production which are suitable to local economic, social and cultural conditions
Technology should be evaluated in terms of:
Whether the technology utilizes local raw materials?
Whether the technology utilizes local man power?
Whether the goods and services produced cater to the basic needs?
Whether the technology protects ecological balance?
Whether the technology is harmonious with social and cultural conditions?

 

  1. Technical arrangement

 

 

  1. Size of the plant

 

Size of the plant depends on the manufacturing process, availability of raw material, capital investment, size of the market.

 

Size of the plant or capacity can be expressed in one of the following terms:

 

1 With Respect to the output

( quantity of finished product)

Pulp and paper, Cement, Steel, etc.
2 With  Respect to input

( quantity of main raw material used)

Sugar Mill, Cottonseed expeller unit, Solvent extraction plant.etc.
3 With respect to number or machines Power looms, Spinning Mills, Textile Mills etc.

 

The concept of economic size of the plant changes with the changes in technology, price structure, availability of raw material, demand of the product and other circumstances.

 

 

  1. Product Mix

 

Product mix or product range depends upon market requirement of certain items may have to be done in different sizes and quality to suit different consumers.

If plant may have flexibility to change product mix according to changes in the market conditions, such flexibility may need additional investment, its impact on the viability of the project be analysed.

 

  1. Selection of Plant and Machinery

 

 

 

  Production Cycle  
Raw Material  

Stages

I II III IV Finished Goods
Capacity 90 80 60 80

The total capacity of the plant in above case will be considered as 60 units because the capacity in the third stage of process is only 60 units.

  1. Procurement of Plant and Machinery

 

 

 

  1. Plant layout

 

 

  1. Location of the plant.

 

  1. Land
    • Land should be sufficient for the proposed project and the future expansion plans.

 

  1. Raw Material
    • The requirement of raw material at full capacity should be ascertained and it should be ensured that necessary raw material will be available at reasonable price.

 

 

 

  1. Labour
    • Sometimes skilled labour is not available at a particular place. If labour has to be obtained from outside ,arrangements to provide housing facilities analyzed.

  1. Utilities such as water , Power, fuel etc.

 

 

  1. Effluent disposal

 

 

 

 

Schedule of Project Implementation

 

 

 

 

 

Technical Analysis Solutions in Software Development

Many a software project has failed due to an incomplete or inaccurate analysis process, especially technical analysis. Technical Analysis is a key step while developing a software application. It can be useful to-

Components of Technical Analysis

There are two parts to Technical Analysis – drafting an Application Specification Document and generating Use Cases.

An Application Specification Document is usually derived from the Requirements Documentation from a Business Analyst. This document briefly specifies various features of the application, details parameters of how the application will be built, etc.

A sample structure of an Application Specification Document for a typical Web Development project would be as follows:

  1. Introduction
    • Background
    • Purpose
    • Scope
    • Definitions, Acronyms and Abbreviations
    • References
    • Overview
  2. Overall Description
    • Use-Case Model Survey
    • Assumptions and Dependencies
  3. Specific Requirements
  4. Non-functional Requirements
    • Browser Compatibility
    • Layout
    • Graphics and Web Design
    • Resolution
    • Log History Analysis
    • Cookies
    • SMTP Server
    • Secure Sockets Layer
    • Accessibility
    • Performance
  5. Payment Schedule

Depending on the project, you may need to elaborate or discard a few of these points but generally, this is how a Software Requirements Specification is laid out. It shows the intended behavior of the project and behavior can be expressed in the form of tasks, functions or services

technical-analysis-components-technical-arrangement-technical-analysis-components-technical-arrangement-solutions-use-cases-solutions-in-software-development technical-analysis-components-technical-arrangement-technical-analysis-components-technical-arrangement-solutions-use-cases-solutions-in-software-development

Use Cases

Use Cases are documents that help capture and detail requirements of the project. They are usually written in casual English for easy comprehension but when required, Flow Charts, Pseudo-Code, etc may be used to explain features in the Use Case. Use Cases are now a widespread practice that originally came from the Object-Oriented Programming Community.

Use Cases define goal-based relationships between actors and various functions in the application. An actor is a term that comes from UML. They are the external entities who use the application – visitors, administrators, staff, an external interacting application, etc. There are usually two types of actors – a Primary actor and a Secondary actor. A Primary Actor is one who requires assistance of the system for their goal to be satisfied. A Secondary Actor is one who the system needs assistance from in order to help Primary Actors achieve their goal.

Every Use Case needs to describe in detail the necessary interaction required between various actors and the application in order to deliver a service that satisfies an actor’s goal. A Use Case also needs to detail any possible alternate flows that could help an actor satisfy his goal. Alternate flows also need to describe methods that could lead to a failure of the application due to errors, etc.

System Internals are not part of a Use Case. A Use Case merely describes the actor, an actor’s possible interaction with the application, optionally the goal that the actor may have set out to achieve and various ways of achieving it.

There are many formats for Use Cases. A sample Use Case for a login feature would be as follows:

Exit mobile version