System and it’s Components - · PDF fileSystem and it’s Components ... SDLC is a classical thought of as the set of activities that analysts, ... -Request clarification :

dodiyahiten.wordpress.com

System and it’s Components

A system is simply a set of components that interact with each other to accomplish some

purpose or a particular goal. I.e. physical sensation is a complex nervous system, it is a set of

brain, spinal cord, nerves and special sensitive cells under your skin, that work together to

make you fill hot, cod and so on. System of words and symbols, economic system. A

business is also a system. Its components are marketing, manufacturing, sales, research,

shipping, accounting and personnel – all work together to create a profit that benefits the

employees and stock holders of the firm. Each of these components is itself a system and

it is called subsystem. I.e. the accounting department may consist of accounts payable,

account receivable, billing, auditing and so on.

Environment : Are the entity outside the boundaries of the system.

To achieve their purpose, system interact with their environment. The systems that interact

with their environment (receive input & produce output) are called open system.

The system that do not interact with their surroundings are called closed systems. In real life

all systems are open system. Thus closed systems exists only as a concept.

Any system use a basic control model consists of

- A standard for acceptable performance.

- A method of measuring actual performance.

- A means of comparing actual performance against the standard.

- A method of feedback.

A system that can adjust their activities to acceptable levels continue to function. Those can

not eventually stop.

System boundary

System component

Input Output

Actual Standard

Means of comparison

Feedback of result of comparison

For example, if a business, produces as output products or services that are at high priced

and of low quality people will probably be not continue to buy them. Low sales figures are

feedback, telling managements, it needs to adjust the products and the way they are

produced to improve performance and bring it into the line with expectation.

�� Information system

Every business system depends on a more or less abstract entity called an information

system. This system is the means by which data flow from one person/department to


another. Information system helps all the system of business, linking the different

component in such a way that they effectively work towards the same purpose.

The purpose of an information systems are to process input, maintain data and produces

information, reports and other output.

It consists of subsystems including hardware, software, and data storage for files and

database. The particular set of subsystems used – the specific equipment, programs, files

and procedures – constitutes an information systems applications.

�� System analysis and design

It refers to the process of examining a business situation with the intent of improving it

through better procedures and methods.

System development process can be thought of having two major components (i) System

analysis and (ii) System design

System analysis : It is the process of gathering and interpreting facts, diagnosing problems

and using the information to recommend improvements to the system.

System design : It is the process of planning a new business system or one to replace or

complement an existing system. The system design is like the blue print for a building, it

specified all the features that are to be in the finished products.

Analysis specifies what the system should do. Design states how to accomplish the

objectives.

� Classical system development life cycle (SDLC)

System development process consists of two major steps i.e. system analysis and system

design.

SDLC is a classical thought of as the set of activities that analysts, designers, and users carry

out to develop and implement an information system. SDLC consist of the following six

activities :

(1) Preliminary investigation

(2) Determination of system requirement

(3) Design of system

(4) Development of software

(5) System testing

(6) Implementation and evaluation

(1) Preliminary investigation :

A request is made by a manager, an employee or a system specialist for information system.

From this point the first system activity, the preliminary investigation starts. It consists of three

parts


- Request clarification : The users or the persons who wants the information

system, their request are not clear, therefore before any system investigation

can be consider, the project request must be examined to determine precisely

what the originator wants.

- Feasibility study : When ever any user request is clarified, then it is very much

important to determine whether the system request is feasible or not. There are

three aspects in the feasibility study i.e.

Technical feasibility : Can the work for the project be doe with current

equipment, existing software technology and available person?

Economic feasibility : Are there sufficient benefits in creating the system to

make the cost acceptable?

Operational feasibility : will the system be used if it is developed and

implemented?

The feasibility study is carried out by a small group of people who are familiar

with information system techniques as well as the routine and detail activities of

the organization.

- Request approval : All requested projects are not desirable or feasible.

However, those projects that are both feasible and desirable should be put into

a schedule. If the systems developer are free then the development process will

be immediately started otherwise, the proposal will be put into the priority

queue depending upon the important.

(2) Determination of system requirements :

The detailed understanding of all important facts of the business area under investigation is the

key point or heart of the system analysis. The analyst must study the business process, so that

the questions related to study, can be answered. For these the system analyst has to work with

variety of persons to gather details about the business process.

As the details are gathered, the analyst study the requirement data to identify features the new

system should have.

(3) Design of system :

The design of information system produces the details that state how a system will meet the

requirements identified during systems analysis. Some times this stage is called logical design. In

controls to the process of development program software, which is referred to as physical

design.

System analyst begins the design process by identifying reports and other outputs, usually

designer sketch it to appear when the system is complete. This may be done on paper.

The system design also describes the data to be input, calculated or stored. Individual data items

and calculation procedure are written in detail.


The detailed design information is passed on to the programmers with complete and

clearly outlined software specifications. As programming starts, designers are

available to answer questions, clarify fuzzy areas & handle problems that confront

the programmers when using the design specifications.

(4) Development of software

Software developers may install purchased software or they may write new, custom designed

programs. The choice depends on the cost of each option, the time available to write software

and the availability of programmers.

Programmers are also responsible for documenting the program, providing an

explanation of how and why certain procedures are coded in specific ways.

(5) System testing

In testing, the system is used experimentally to ensure that the software does not fail. I.e. that it

will run according to its specifications and in the way users expect. Special test data are inputted

for processing, and the result examined. A limited number of users may be allowed to use the

system so analyst can see whether they try to use it in unforeseen ways.

In many organization testing is performed by persons other than those who wrote the original

programs to ensure more complete and unbiased testing and more reliable software.

(6) Implementation & evaluation

Implementation is the process of having systems personnel check out and put new equipment

into use, train users, install he new applications and construct any files of data needed to use it.

Evaluation of the system is perform to identify its strengths and weakness. The

evaluation process can be categorized in following three way :

(i) Operational evaluation : In this, it will determine how system is functioning,

it also includes ease of use, response time, suitability of information

formats, overall reliability and level of utilization.

(ii) Organizational impact : Identification and measurement of benefits to the

organization in such area as financial concerns (cost, revenue and profit),

operational efficiency and competitive impact.

(iii) User manager assessment : Evaluation of the attitudes of senior and user

managers within the organization, as well as end users.

(iv) Development performance : It measure overall development time and

effort, conformance to budgets and standards, and other project

management criteria, includes assessment of development methods and

tools.


� What is requirement determination?

It studies the current business system to find out how it works and where improvement

should be made? These study consider both manual and computer methods

A requirement is a feature that must be included in a new system. It may include a

way of capturing or processing data, producing information, controlling a business

activities or supporting management.

� Fact finding techniques

The analyst does not know the working process of the user for which, he is going to develop

information system. The analyst uses specific method for collecting data about requirements

are called fact-finding techniques. It includes the interview, questionnaire, record review

and observation. Analyst usually employ more than one of these technique to help an

accurate and comprehensive investigation.

(i) Interview : Analyst use the interview to collect information from individuals or from

groups. The respondents are the user of the investigated system. Some analyst

always prefer the interview method compare to other fact finding techniques, it is

not always best that to collect the data about the application. Because if the number

of the user are very high then this process is time consuming, so at that time other

fact finding technique should be adopted.

In this method respondents and system analyst converse during the interview.

Interviews provide analyst with opportunity for gathering information from

respondents who have been chosen for their knowledge of the system under study.

This method is frequently the best source of qualitative information.

This method of fact finding can be especially helpful for gathering information from

individuals who do not communicate effectively in writing or who may not have the

time to complete questionnaires. It allows the analyst to discover area of

misunderstanding, unrealistic expectations, and even indication of resistance to the

proposed system. Interview can be structure or unstructured. Unstructured

interviews uses a questions and answers format when the analyst want to get the

general information about the system. Structured interviews use standardized

questions in either an open response or in close response and the answer must be in

the pre formatted.

Structured interview Unstructured interview

Advantages

- Ensure uniform wording of questions

for all respondents

- Easy to administer and evaluate

- Result in shorter interviews

- More objective evaluation of both

interviewer and respondent.

- Limited interview training needed

Disadvantages

- Cost of preparation is high

- Respondent has to give the answer

Advantages

- Interviewer has greater flexibility in

wording question to suit respondent

- Interviewers can pursue the area

that arise at the time of interview.

- It may produce the information

about the areas that were

overlooked or not thought at all.

Disadvantages

- It may waste the time of both


into required and pre define format.

- Analyst has to prepare before

interviewing.

- While taking the interview, the

biases may appear.

- Some information will be gathered

which is of no use.

- It takes extra time to collect the

actual facts.

(ii) Questionnaire : The use of questionnaire allows the analyst to collect the

information various aspect of the system from a large number of the users. The use

of standard question will leads to collect the more reliable and important data of the

studied system. However this method does not allow the system analyst to study

the expression of the users. In addition the response may be limited.

Analyst often uses the open-ended questionnaire to study the expression or feeling

of the system user. To prepare the questions analyst has to work hard and also look

for the cost for preparing the questions.

(iii) Record review : Many kinds of records and reports can used by the analyst to

extract the required information regarding the system and the user of the system.

This process is performed at the beginning of the system study.

Records include written policy manuals, regulations and standard operating

procedures use by the most organization as a guide for managers and employees.

(iv) Observation : Observation allows analyst to gain information they can not obtain by

any other fact finding technique. Though through observation analyst can secure the

first hand activity process. This method is very much useful when analyst needs to

actually observe that how the documents are handled, how process are carried out

and whether specified steps are actually followed. Experience analyst can gain a lot

of thing from the observation, some time which is nearer to impossible collect from

other fact finding techniques.

� Tools for documenting procedure and decisions

A tool is any device, object or operations used to accomplish a specific task. System analyst

rely on such type of tools. There tools help analyst in so many different ways (i.e. To collect

data, present data, explain processes etc.) To explain the procedures or documenting the

procedures there are three tools :

- Decision tree

- Decision table

- Structured English

When analyst starts the study of any information system, the first question is about, what

are possibilities? or what can happen? Means he/she is asking about the condition to take

any appropriate action. In real situation the problem is not same, hence the conditions vary

for different problems and different situations, so some time it is referred as decision

variable.

When all possible conditions are known, the analyst next determines what to do when

certain condition occurs. Actions are alternatives, the steps, activities or procedures that an


individual may decide to take when confronted with a set of conditions. The actions will be

simple or it may be complex in different situation.

• Decision tree :

A single matter can be explained in so many different ways, for example, a

company might give discount amount on three different values for the

condition on size of order (i.e. over 10,000 – 4 %, in between 5000 to 10000 –

3 % and below 5000 - 2 %) and the payment occurs within 10 days or not.

The same process can be explained in following different ways.

- Greater than 10,000. greater than or equal to 5000 but less than or equal

to 10,000 and below 5000.

- Not less than 10,000, not more than 10,000 but at least 5000 and not

5000 or more.

Having different ways of saying the same thing can create difficulties in communications

during system study.

Decision tree is one of the method for describing decisions, while avoiding

difficulties in communications.

A Decision tree is diagram that presents conditions and actins sequentially

and thus shows which conditions to consider first, which second and so on. It

is also a method of showing the relationship of each condition and its

permissible actions. The diagram resembles branches on a tree.

Action

Condition

Action

Condition Action

Condition

Action

Root Action

Condition

Condition Action

Action

Condition


Action

Decision tree

The root of the tree, on the left of the diagram, is the storing point of the

decision sequence. The particular branch to be followed depends on the

conditions that exists and the decision to be made. Progression from left to

right in any branch will give the sequence of decision. One decision point will

lead to the another decision point. The nodes of the three thus represents

conditions and indicates that a determination must be made about which

condition exists before the next path can be chosen. The right side of the tree

list the actions to be taken, depending upon the sequence of condition that is

followed.

Developing decision tree is very much beneficial i.e. The need to describe

conditions and actions forces analyst to formally identify the actual decision

that must be made. It also force analyst to consider the sequence of

condition.

Over 10000 4%

Within 10 days 5000 to 10000 3%

Below 5000 2%

After 10 days Full payment

Decision trees may not always be the best tools for decision analysis. A

decision tree for a complex system with many sequence of steps and

combination of conditions will be unwieldy. A large number of branches with

many paths through them will could rather than aid analysis. When these

problem arise, decision table should be considered.

• Decision table

A decision table is a matrix of rows and columns, rather than a tree, that shows

conditions and actions. Decision rules, included in a decision table, state what procedure

to follow when certain conditions exists.


The decision table is made up of four sections : Condition statements,

condition entry, action statements, actions entries. The condition statement

identifies relevant conditions. Condition entries tell which value, if any

applies for a particular condition. Action statements list the set of all steps

that can be taken when a certain condition occurs. Action entries shows what

specific actions in the set to take when selected conditions or combinations

of conditions ate true. Sometimes notes are added below the table of

indicate when to use the table or to distinguish it from other decision tables.

Condition Decision rules

Condition statements Condition entry

Action statements Action entry

The columns on the right side of the table, linking conditions and actions;

form decision rules, which state the conditions that must be satisfied for a

particular set of actions to be taken.

Condition Decision rules

C1 : Patient has health insurance Y Y N N

C2 : Patient has social health ins. Y N Y N

A1 : Pay only visit charge X

A2 : Pay nothing X X

A3 : full payment X

� Structured Analysis

The word structure in structured analysis means :

- The method attempts to structure the requirements determination process,

beginning with documentations of the existing system.

- The detailed process that describes the current system.

- It is easy to verify when relevant details have been omitted.

- Identifies requirements that will include best solutions and strategies for system

development opportunities.

� What is data flow analysis?


While developing a system, analyst wants to know the answer to four specific questions :

- What processes make up a system?

- What data are used in each process?

- What data are stored?

- What data enters and leaves the system?

Data drives the business activities. Systems analyst recognizes the central role of business

data in organization. Data flow analysis study the use of data in each activity (i.e. process,

stores, retrieved, used, changed & output).

Data Flow Diagram (DFD) graphically shows the relation between processes and

data. Data dictionary, which formally describes the system data and where they are

used.

� Data flow diagram (DFD)

A graphical tool used to describe and analyze the movement of data through a system

including the processes, stores of data and delays in the system. DFD are the central tool and

the basis from which other components are developed. The transformation of data from

input to output, through process, may be described logically and independently of the

physical components are called logical DFD. In contrast, physical DFD show the actual

implementation and the movement of data between people, departments and workstations.

Logical DFD can be completed using only four simple notations. The symbols are

developed by two different organizations (i.e. Yourdon and Gane & Sarson). The

symbols are as follow

(i) Data Flow : It shows the direction of data flow, from an origin to a

destination in the form of document, letter, telephone call.

Yourdon Gane & Sarson

(ii) Processes : People, procedures or device that use or produce data.


(iii) Source & Destination : External sources or destination of data, which may be

people, programs, organizations or other entities interact with the system

bur are outside its boundary. The term source or sink are interchangeably

used with origin & destination.



(iv) Data store : Here data are stored or referenced by a process in the system.


Each component in a DFD is labeled with a descriptive name. Process name are identified

with a number. The umber assigned to a specific process does not represent the sequence of

process. It is strictly for identification and will take on added value when we study the

components that, make up a specific process.

D. flow –1 D.F. - 4

Source P1 Destination

D F - 2

D F - 5

P2 D F -3 Data store

Several data flow can be going on simultaneously. In above DFD d. flow – 1 & d; flow – 2 may

occur I parallel.

As the name suggest, DFD concentrate on the data moving through the system, not

on device or equipment. Analyst explain why the data are being input or output and

what processing s done. It is just as important to determine when data enter the

application area and when they leave. Sometimes data are stored for later use or

retrieved from previous storage. DFD also show this.

Developing Data Flow Diagram : System analyst must first study the current system,

that is, the actual activities and processes that occur. In the terminology of

structured analysis, this is a study of the physical system.

The physical system is translated into a logical description that focus on data and

processes. It emphasize data and processes in order to focus on actual activities that

occur and the resources needed to perform them, rather than on who performs the

work.


Data flow diagrams are of two type :

- Physical data flow diagram : It is an implementation dependent view of the

current system, showing what task are carried out and how they are carried out

and how they performed. Its characteristics includes (name of people, form and

document names or numbers, names of dept, master & transaction file,

equipment & device used, locations, name of procedures etc.)

- Logical data flow diagram : It is an implementation independent view of a

system, focusing on the flow of the data between processes without any concern

of specific devices, storage location or people in the system.

Drawing context diagram : The first steps in requirement analysis is to learn about

the general characteristics of the business process under investigation. The data flow

diagram (fig – 1) describes account payable processing at a very general or top level.

Account

Payable

Balance

Mailing address

Invoice

Vendor Account

Check payable

Vendor data

� Data dictionary

When the volume of data is very large, it is very much difficult for analyst to manage the

data definitions. If the information system is very big, then more than one person are

working on the same data, at that time, any data defined by any person, can be used by the

other person, hence they need the definition or description of the data.

Data dictionaries are an integral component of structured analysis, it provides

additional information about the system.

A data dictionary is a catalog – a repository – of the elements in a system. As the

name suggest, these elements center around data and the way they are structured

to meet user requirements and organization needs. It contains a list of all the

elements composing the data flowing through a system. The major elements are

data flows, data stores and processes. The data dictionary stores details and

descriptions of these elements. If data dictionary is developed properly, then any

data related questions – answer can be extracted from data dictionary.


It is developed during data flow analysis and assists the analysts. The stored details

are used during system design.

Definition of Software Engineering

� Software Engineering is the establishment and use of sound engineering principles in

order to

obtain economically software that is reliable and works efficiently on real machine.

Fritz Bauer

� Software Engineering is the application of systematic, disciplined, quantifiable approach

to

the development, operation and maintenance of software; that is the application of

engineering to software.

� Testing

System testing is an expensive but critical process that can take as much as 50 percent of the

budget from program development. The common view of testing held by users is that it is

performed to prove that there are no errors in a program. Therefore the most useful and

practical approach is with the understanding that testing is the process of executing a

program with the explicit intention of finding errors, that is making the program fail. The

tester who may be an analyst, programmer or specialist trained in software testing. It is

actually trying to make the program fail. A successful test then is one that finds an error.

Code testing : The code testing strategy examines the logic of the program. To follow

this testing method, the analyst develops test cases that result in executing every

instruction in the program or module, that is every path through the program is

tested. Code testing seems to be an ideal method for testing software.

However, even if code testing can be performed in its entirety it does not guarantee

against software failures. This testing strategy does not indicate whether the code

meets its specifications not does it determine whether all aspects are even

implemented. Code testing also does not check the range of data that the program

will accept even though when software failures occur in actual use.

Special testing : To perform special testing, analyst examines the specifications

stating what the program should do and how it should perform under various

conditions. Then the test case are developed for each condition or combination of

conditions and submitted for processing. By examining the result analyst will

determine whether the program is working as per the required specification?

This strategies treats the program as if it were a black box. The analyst does not look

into the program to study the code and is not concerned about whether every

instruction or path through the program tested. In that sense specification test is not

complete test. However, the assumption is that, if the program meets the

specifications, it will not fail.


Neither code nor specification testing strategy is ideal. However the specification

testing is more efficient strategy, since it focuses on the way software is expected to

be used.

Unit test : In unit testing the analyst test the programs making up a system. Unit

testing focus first on the modules, independently of one another, to locate errors.

This enables the tester to detect errors in coding and logic that are contained within

that module alone. Unit testing can be performed from the bottom up, starting with

the smallest and lowest level modules and proceeding one at a time. Top down

testing as the name implies begins with the upper level modules and continue up to

the lower level.

System testing : System testing performs the testing of integration of each module

in the system. It also tests to find discrepancies between the system and its original

objective, current specifications and system documentation. The primary concern is

the compatibility of individual modules. Analyst are trying to find areas where

modules have been designed with different specifications for data length, type and

data element name.

Peak load testing : There are critical times in many systems, particularly online

systems. For example, in banking system, analysts want to know what will happen if

all tellers sign on at their terminals at the same time before the start of the business

day. Will the system handle them one at a time without incident, will it attempt to

handle them at once and be so confused that it locks up. And must be restarted. So

such type of testing is looking at real situation.

Storage testing : Analyst specify a capacity for the system when it is designed and

constructed. Capacities are measured in terms of the number of records that a disk

will handle or a file can contain. These capacities are linked to disk space and the size

of indices, records keys and so on. Storage testing often requires entering data until

the capacity is reached. Comparing the actual and claimed capacities will verify the

accuracy of the documentation on the one hand and allow a judgment about actual

capacity at the same time. Many of the live systems are not tested in these way,

then after implementing the system when it is in running mode, after few days user

will realize that the system is not capable to handle the volume of data in master file

as well as transaction file.

Performance time testing : when analysts are developing a design, their concerns

are more on reports, inputs, files and processing sequence than on performance

time, although this changes with experience. Performance time testing is conduct

prior to implementation to determine how long it takes to receive a response to an

inquiry, make a backup copy of a file, or send a transmission and receive a response.

It also include test runs to time indexing or restoring of large files of the size the

system will have during a typical run or to prepare a report. A system that runs well

with only a handful of test transactions may be unacceptably slow when fully loaded.


Recovery testing : Analyst must always assume that the system will fail and data will

be damaged or lost. Even though plans and procedures are written to cover these

situations, they also must be tested. By creating a failure or data loss event where

the users are forced to reload and recover from a backup copy, analysts can readily

determine whether recovery procedures are adequate. The best designed plans

usually are adjusted or augmented after this test.

Procedure testing : Documentation and run manuals telling the user how to

perform certain functions are tested quite easily by asking the user to follow them

exactly through a series of events. Analyst concentrate on the major and critical

details of a systems design and include them in the documentation. They also pay

attention to the little details. This type of testing not only shows where they are

needed but also where they are wrong, that is where actions suggested in the

documentation do not match those that must actually be taken to make the system

run.

� Verification and validation

Like testing verifications is also intended to find errors. It is performed by executing a

program in a simulated environment. Validation refers to the process of using

software in a live environment in order to find errors. Verification test is some times

called the alpha test. The feedback from the validation phase generally produce

changes in the software to deal with errors and failures that uncovered. Then as set

of user sites is selected that puts the system into use on a live basis. These beta test

site use the system in day-to-day activities. They process live transactions and

produce normal system output. The system is live in every sense of the word.

Validation may continue for several months. During the course of validation the

system, failure may occur and the software will be changed. Continued use may

produce additional failures and the need for still more changes.

What is Software quality? Explain ISO 9000.

In the context of software engineering, software quality measures how well software

is designed (quality of design), and how well the software conforms to that design

(quality of conformance), although there are several different definitions.

Whereas quality of conformance is concerned with implementation (see Software

Quality Assurance), quality of design measures how valid the design and

requirements are in creating a worthwhile product.

Software Quality Consist following points

conformance to requirements or program specification; related to Reliability

Scalability


Correctness

Completeness

Absence of bugs

Fault-tolerance

Extensibility

Maintainability

Documentation

ISO 9000 is a family of standards for quality management systems. ISO 9000 is

maintained by ISO, the International Organization for Standardization and is

administered by accreditation and certification bodies. Some of the requirements in ISO

9001 (which is one of the standards in the ISO 9000 family) include

• a set of procedures that cover all key processes in the business;

• monitoring processes to ensure they are effective;

• keeping adequate records;

• checking output for defects, with appropriate and corrective action where necessary;

• regularly reviewing individual processes and the quality system itself for

effectiveness; and

• facilitating continual improvement

A company or organization that has been independently audited and certified to be in

conformance with ISO 9001 may publicly state that it is "ISO 9001 certified" or "ISO 9001

registered". Certification to an ISO 9000 standard does not guarantee any quality of end

products and services; rather, it certifies that formalized business processes are being

applied. Indeed, some companies enter the ISO 9001 certification as a marketing tool

Although the standards originated in manufacturing, they are now employed across

several types of organizations. A "product", in ISO vocabulary, can mean a physical

object, services, or software. In fact, according to ISO in 2004, "service sectors now

account by far for the highest number of ISO 9001:2000 certificates - about 31% of the

total."

ISO 9000:2000, Quality management systems – Fundamentals and vocabulary.

Covers the basics of what quality management systems are and also contains the core

language of the ISO 9000 series of standards. A guidance document, not used for

certification purposes, but important reference document to understand terms and

vocabulary related to quality management systems. In the year 2005, revised ISO

9000:2005 standard has been published, so it is now advised to refer to ISO 9000:2005.

Explain Project Management with 3Ps.

Effective software project management focuses on the four P's: people, product,

process, and project. The order is not arbitrary. The manager who forgets that

software engineering work is an intensely human endeavor will never have success

in project management. A manager who fails to encourage comprehensive


customer communication early in the evolution of a project risks building an elegant

solution for the wrong problem. The manager who pays little attention to the

process runs the risk of inserting competent technical methods and tools into a

vacuum. The manager who embarks without a solid project plan jeopardizes the

success of the product.

1 The People

The cultivation of motivated, highly skilled software people has been discussed since

the 1960. In fact, the "people factor" is so important that the Software Engineering

institute has developed a people management capability maturity model (PM-CMM),

"to enhance the readiness of software organizations to undertake increasingly

complex applications by helping to attract, grow, motivate, deploy, and retain the

talent needed to improve their software development capability" [CUR94].

The people management maturity model defines the following key practice areas for

software people: recruiting, selection, performance management, training,

compensation, career development, organization and work design, and team/culture

development. Organizations that achieve high levels of maturity in the people

management area have a higher likelihood of implementing effective software

engineering practices.

The PM-CMM is a companion to the software capability maturity model that guides

organizations in the creation of a mature software process. Issues associated with

people management and structure for software projects are considered later in this

chapter.

2 The Product


Before a project can be planned, product objectives and scope should be

established, alternative solutions should be considered, and technical and

management constraints should be identified. Without this information, it is

impossible to define reasonable (and accurate) estimates of the cost, an effective

assessment of risk, a realistic breakdown of project tasks, or a manageable project

schedule that provides a meaningful indication of progress.

The software developer and customer must meet to define product objectives and

scope. In many cases, this activity begins as part of the system engineering or

business process engineering and continues as the first step in software

requirements analysis. Objectives identify the overall goals for the product.(from the

customer's point of view) without considering how these goals will be achieved.

Scope identifies the primary data, functions and behaviors that characterize the

product, and more important, attempts to bound these

Characteristics in a quantitative manner.

Once the product objectives and scope are understood, alternative solutions are

considered. Although very little detail is discussed, the alternatives enable managers

and practitioners to select a "best" approach, given the constraints imposed by

delivery deadlines, budgetary restrictions, personnel availability, technical interfaces,

and other factors.

3 The Process

A software process provides the framework from which a comprehensive plan for

software Development can be established. A small number of frame work

activities are applicable to all software projects, Regardless of their size or

complexity. A number of different task sets-tasks, milestones, work products,

and quality assurance points-enable the framework activities to be adapted to

the characteristics of the software project and the requirements of the project

team. Finally, umbrellaactivitie


such as software quality assurance, software configuration management, and

measurement-overlay the process model. Umbrella activities are independent of

any one framework activity and occur throughout the process.

4 The Project

We conduct planned and controlled software projects for one primary reason-it is

the only known way to manage complexity. And yet, we still struggle. in 1998,

industry data indicated that 26 percent of software projects failed outright and 46

percent experienced cost and schedule overruns. Although the success rate for

software projects has improved somewhat, our project failure rate remains higher

than it should be. In order to avoid project

failure, a software project manager and the software engineers who build the

product must avoid a set of common warning signs, understand the critical success

factors that lead to good project management, and develop a commonsense

approach for planning, monitoring and controlling the project.

Explain the Project Planning.

In order to manage a successful software project, we must understand what can go

wrong (so that problems can be avoided) and how to do it right. in an excellent

paper on software projects, John Reel [REE99] defines ten signs that indicate that an

information systems project.

1. Software people don't understand their customer's needs.

2. The product scope is poorly defined. 3. Changes are managed poorly.

4. The chosen technology changes.

5. Business needs changed or are ill-defined.

6. Deadlines are unrealistic.

7. Users are resistant.

8. Sponsorship is lost lor was never properly obtained

9. The project team lacks people with appropriate skills.

10. Managers [and practitioners] avoid best practices and lessons learned.


The following are the points of software project.

Start on the right foot. This is accomplished by working hard (very hard) to

understand the problem that is to be solved and then setting realistic objects and

expectations for everyone who will be involved in the project. it is reinforced by

building the right team (Section 3.2.3) and giving the team the autonomy, authority,

and technology needed to do the job.

Maintain momentum. Many projects get off to a good start and then slowly

disintegrate. To maintain momentum, the project manager must provide incentives

to keep turnover of personnel to an absolute minimum, the team should emphasize

quality in every task it performs, and senior management should do everything

possible to stay out of the team's way.

Track progress. For a software project, progress is tracked as work products (e.g.,

specifications, source code, sets of test cases) are produced and approved (using

formal technical reviews) as part of a quality assurance activity. in addition, software

process and project measures (Chapter 4) can be collected and used to assess

progress against averages developed for the software development organization.

Make smart decisions. In essence, the decisions of the project manager and the

software team should be to "keep it simple." Whenever possible, decide to use

commercial off-the-shelf software or existing software components, decide to avoid

custom interfaces when standard approaches are available, decide to identify and

then avoid obvious risks, and decide to allocate more time than you think is needed

to complex or risky tasks (You'll need every minute).

Conduct a postmortem analysis. Establish a consistent mechanism for extracting

lessons learned for each project. Evaluate the planned and actual schedules, collect

and analyze software project metrics, get feedback from team members and

customers, and record findings in written form.

Explain Risk Management

A risk is something that may happen and if it does, will have a positive or negative

impact on the project. A few points here. "That may happen" implies a probability of


less then 100%. If it has a probability of 100% - in other words it will happen - it is an

issue. An issue is managed differently to a risk and we will handle issue management

in a later white paper. A risk must also have a probability something above 0%. It

must be a chance to happen or it is not a risk.

Risk Management Plan

There are four stages to risk management planning. They are: ·

• Risk Identification

• Risks Quantification

• Risk Response

• Risk Monitoring and Control

Risk Identification

In this stage, we identify and name the risks. The best approach is a workshop with

business and IT people to carry out the identification. Use a combination of

brainstorming and reviewing of standard risk lists.

There are different sorts of risks and we need to decide on a project by project basis

what to do about each type.

Business risks are ongoing risks that are best handled by the business. An example is

that if the project cannot meet end of financial year deadline, the business area may

need to retain their existing accounting system for another year. The response is

likely to be a contingency plan developed by the business, to use the existing system

for another year.

Generic risks are risks to all projects. For example the risk that business users might

not be available and requirements may be incomplete. Each organization will

develop standard responses to generic risks.

Risks should be defined in two parts. The first is the cause of the situation (Vendor

not meeting deadline, Business users not available, etc.). The second part is the

impact (Budget will be exceeded, Milestones not achieved, etc.). Hence a risk might

be defined as "The vendor not meeting deadline will mean that budget will be

exceeded". If this format is used, it is easy to remove duplicates, and understand the

risk.


Risk Quantification

Risk need to be quantified in two dimensions. The impact of the risk needs to be

assessed. The probability of the risk occurring needs to be assessed. For simplicity,

rate each on a 1 to 4 scale. The larger the number, the larger the impact or

probability. By using a matrix, a priority can be established.

Note that if probability is high, and impact is low, it is a Medium risk. On the other

hand if impact is high, and probability low, it is High priority.

Risk Response

There are four things you can do about a risk. The strategies are:

Avoid the risk. Do something to remove it. Use another supplier for example.

Transfer the risk. Make someone else responsible. Perhaps a Vendor can be made

responsible for a particularly risky part of the project.

Mitigate the risk. Take actions to lessen the impact or chance of the risk occurring. If

the risk relates to availability of resources, draw up an agreement and get sign-off

for the resource to be available.

Accept the risk. The risk might be so small the effort to do anything is not worth

while.

A risk response plan should include the strategy and action items to address the

strategy. The actions should include what needs to be done, who is doing it, and

when it should be completed.

Risk Control

The final step is to continually monitor risks to identify any change in the status, or if

they turn into an issue. It is best to hold regular risk reviews to identify actions

outstanding, risk probability and impact, remove risks that have passed, and identify

new risks.

The second thing to consider from the definition is "will have a positive or negative

impact". Most people dive into the negative risks but what if something goes right

Risk management is not a complex task. If you follow the four steps, you can put

together a risk management plan for a project in a short space of time. Without a

plan, the success of the project, and your reputation as a Project Manager, are on

the line. Follow these steps and you will increase your chances of success.

System and it’s Components - · PDF fileSystem and it’s Components ... SDLC is a classical thought of as the set of activities that analysts, ... -Request clarification :

Documents