System Development Life Cycle (SDLC)

savi.9396

New member
Introduction

Software systems development is, from a historical perspective, a very young profession.
The first official programmer is probably Grace Hopper, working for the Navy in the mid-1940s. More realistically, commercial applications development did not really take off until the early 1960s. These initial efforts are marked by a craftsman-like approach based on what intuitively felt right. Unfortunately, too many programmers had poor intuition.

By the late 1960s it had become apparent that a more disciplined approach was required.
The software engineering techniques started coming into being. This finally brings us to the SDLC.
What evolved from these early activities in improving rigor is an understanding of the scope and complexity of the total development process. It became clear that the process of creating systems required a system to do systems. This is the SDLC. It is the system used to build and maintain software systems.


The System Development Life Cycle is the process of developing information systems through investigation, analysis, design, implementation, and maintenance.
The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

SDLC Objectives

When we plan to develop, acquire or revise a system we must be absolutely clear on the objectives of that system. The objectives must be stated in terms of the expected benefits that the business expects from investing in that system. The objectives define the expected return on investment.


An SDLC has three primary business objectives:
- Ensure the delivery of high quality systems;
- Provide strong management controls;
- Maximize productivity.

In other words, the SDLC should ensure that we can produce more function, with higher quality, in less time, with less resources and in a predictable manner.

1. Ensure High Quality

Judging the quality of a wine or a meal is a subjective process. The results of the evaluation reflect the tastes and opinions of the taster. But we need a more rigorous, objective approach to evaluating the quality of systems. Therefore, before we can ensure that a system has high quality, we must know what quality is in a business context. The primary definition of quality in a business context is the return on investment (ROI) achieved by the system. The business could have taken the money spent on developing and running the system and spent it on advertising, product development, staff raises or many other things. However, someone made a decision that if that money was spent on the system it would provide the best return or at least a return justifying spending the money on it.

This ROI can be the result of such things as: operational cost savings or cost avoidance; improved product flexibility resulting in a larger market share; and/or improved decision support for strategic, tactical and operational planning. In each case the ROI should be expressed quantitatively, not qualitatively. Qualitative objectives are almost always poorly defined reflections of incompletely analyzed quantitative benefits.
The SDLC must ensure that these objectives are well defined for each project and used as the primary measure of success for the project and system. The business objectives provide the contextual definition of quality. There is also an intrinsic definition of quality. This definition of quality centers on the characteristics of the system itself: is it zero defect, is it well-structured, it is well-documented, is it functionally robust, etc. The characteristics are obviously directly linked to the system's ability to provide the best possible ROI. Therefore, the SDLC must ensure that these qualities are built into the system. However, how far you go in achieving intrinsic quality is tempered by the need to keep contextual quality (i.e., ROI) the number one priority. At times there are trade-offs to be made between the two. Within the constraints of the business objectives, the SDLC must ensure that the system has a high degree of intrinsic quality.

2. Provide Strong Management Control

The essence of strong management controls is predictability and feedback. Projects may last for many months or even years. Predictability is provided by being able to accurately estimate, as early as possible, how long a project will take, how many resources it will require and how much it will cost. This information is key to determining if the ROI will be achieved in a timely manner or at all. The SDLC must ensure that such planning estimates can be put together before there have been any significant expenditures of resources, time and money on the project. The feedback process tells us how well we are doing in meeting the plan and the project's objectives. If we are on target, we need that verified. If there are exceptions, these must be detected as early as possible so that corrective actions can be taken in a timely manner. The SDLC must ensure that management has timely, complete and accurate information on the status of the project and the system throughout the development process.

System Development Life Cycle

There are two basic definitions of productivity. One centers on what you are building; the other is from the perspective of how many resources, how much time and how much money it takes to build it. The first definition of productivity is based on the return on investment (ROI) concept. What value is there in doing the wrong system twice as fast?
It would be like taking a trip to the wrong place in a plane that was twice as fast. You might have been able to simply walk to the correct destination. Therefore, the best way to measure a project team's or system department's productivity is to measure the net ROI of their efforts. The SDLC must not just ensure that the expected ROI for each project is well defined. It must ensure that the projects being done are those with the maximum possible ROI opportunities of all of the potential projects.
Even if every project in the queue has significant ROI benefits associated with it, there is a practical limit to how large and how fast the systems organization can grow. We need to make the available staff as productive as possible with regard to the time, money and resources required to deliver a given amount of function. The first issue we face is the degree to which the development process is labor intensive. Part of the solution lies in automation. The SDLC must be designed in such a way as to take maximum advantage of the computer assisted software engineering (CASE) tools.
The complexity of the systems and the technology they use has required increased specialization. These specialized skills are often scarce. The SDLC must delineate the tasks and deliverables in such a way as to ensure that specialized resources can be brought to bear on the project in the most effective and efficient way possible.
One of the major wastes of resources on a project has to do things over. Scrap and rework occurs due to such things as errors and changes in scope. The SDLC must ensure that scrap and rework is minimized. Another activity that results in non-productive effort is the start-up time for new resources being added to the project. The SDLC must ensure that start-up time is minimized in any way possible. A final opportunity area for productivity improvements is the use of off-the-shelf components. Many applications contain functions identical to those in other applications. The SDLC should ensure that if useful components already exist, they can be re-used in many applications.
What we have identified so far are the primary business objectives of the SDLC and the areas of opportunity we should focus on in meeting these objectives. What we must now do is translate these objectives into a set of requirements and design points for the SDLC.


STAGES OF SDLC

Preliminary investigation is the first step in the system development life cycle. The preliminary investigation is a way of handling the user’s request to change, improve or enhance an existing system. The objective is to determine, whether the request is valid and feasible before any recommendation is made to do nothing, improve or modify the existing system, or build altogether a new one. It is not a design study, nor does it include the collections of details to completely describe the business system. The following objectives should be accomplished, while working on the preliminary investigation. System investigation includes the following two sub-stages.
1. Problem Definition
2. Feasibility Study


1. PROBLEM DEFINITION:
Problem Initiation includes define necessary input, output, storage etc. Define what the problem really is. State a goal to be achieved
A problem initiation will describe:
• required input (what data has to be acquired to produce the output?)
• required output (i.e. what information is the system supposed to produce?)
Problem analysis breaks the problem down into its parts and describes them. Note that this step does not care what solution will be used to solve the problem. The analysis lays down the basic requirements that the eventual solution must achieve (a logical design).
During problem initiation, one of the first things to do is to define the problem correctly. If you get this wrong (or skip it completely) everything you do afterwards could be a complete waste of time and money.
The most important task in creating a software product is extracting the requirements. Customers typically know what they want, but not what software should do, while incomplete, ambiguous or contradictory requirements are recognized by skilled and experienced software engineers. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.

Problem Initiation is the task of precisely describing the software to be written, possibly in a rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable.

Here are some possible definitions of problems:
1. The existing system has a poor response time, i.e. it is slow.
2. It is unable to handle workload.
3. The problem of cost, i.e. the existing system is not economical.
4. The problem of accuracy and reliability.
5. The requisite information is not produced by the existing system.
6. The problem of security.

Similarly, a system analyst should provide a rough estimate of the cost involved for the system development. This is again a very important question that too often is not asked until it is quite late in the system development process.

2. FEASIBILITY STUDY

The literal meaning of feasibility is vitality. This study is undertaken to know the likelihood of the system being useful to the organization. Feasibility study, basically, is a high-level capsule version of the entire process, intended to answer a number of questions like what is the problem? Is the problem even worth solving? However, as the name indicates in preliminary investigation, feasibility study should be relatively brief, as the objective at this stage is not only to get an idea of the scope. The findings of this study should be formally presented to the user management. This presentation marks a crucial decision point in the life of the project. If the management approves the project, the feasibility study report represents an excellent model of the system analyst’s understanding of the problem and provides a clear sense of direction for the subsequent development of the system.

The aim of the feasibility study is to access alternative systems and to propose the most feasible and desirable system for development. Thus, feasibility study provides an overview of the problem and acts as an important checkpoint that should be completed before committing more resources.

The feasibility of a proposed system can be assessed in terms of four major categories, as summarized below.
1. Organizational Feasibility: the extent to which a proposed information system supports the objective of the organization’s strategic plan for information systems determines the organizational feasibility of the system project. The information system must be taken as a sub-set of the whole organization.

2. Economic Feasibility: in this study, costs and returns are evaluated to know whether returns justify the investment in the system project. The economic questions raised by the analyst during the preliminary investigation are for the purpose of estimating the following:
(a) The cost of conducting a full system investigation.
(b) The cost of hardware and software for the class of application being considered.
(c) The benefits in the form of reduced costs, improved customer service, improved resource utilization or fewer costly errors.

3. Technical Feasibility: whether reliable hardware and software, capable of meeting the needs of the proposed system can be acquired or developed by the organization in the required time is a major concern of the technical feasibility. In the other words, technical feasibility includes questions like:
(a) Does the necessary technology exist to do what is suggested and can it be acquired?
(b) Does the proposed equipment have the technical capacity to hold the data required to use the new system?
(c) Will the proposed system provide adequate responses to inquiries, regardless of the number of locations and users?
(d) Can the system be expanded?
(e) Is there any technical surety of accuracy, reliability, ease of access and data security?

4. Operational Feasibility: the willingness and the ability of the management, employees, customers, suppliers, etc., to operate, use and support a proposed system come under operational feasibility. In the other words, the test of operational feasibility asks if the system will work when it is developed and installed. Are there major barriers to implementation? The following questions are asked in operational feasibility.
(a) Is there sufficient support from the management? From employees? From customers? From suppliers?
(b) Are current business methods acceptable to the users?
(c) Have the users been involved in the planning and development of the system project?

Operational feasibility would pass the test if the system is developed as per rules, regulations, laws, organizational culture, union agreements, etc., and above all with the active involvement of the users.
Besides these four main categories, the system should also be accessed in terms of legal feasibility and schedule feasibility. Whereas legal feasibility refers to the viability if the system from the legal point of view, i.e. it checks whether the system abides by all laws and regulations of the land, the schedule feasibility evaluates the probability of completing the system in the time allowed for its development, since for the system to be useful, it must be finished well before the actual requirement of its usage.
For the determining feasibility, a project proposal must pass all these tests. Otherwise, it is not a feasible project. For example, a personnel record system that is economically feasible and operationally attractive is not feasible if the necessary technology does not exist, Infeasible projects are abandoned at this stage, unless they are reworked and resubmitted as new proposal.

3. Analysis
Primary objective of Analysis phase is to understand the user’s needs and develop requirements for Software development.
It involves activities like:
• Gathering Information
• Define Software requirement.
• Prioritize requirements.
• Generate & Evaluate alternatives.
• Review recommendations with management.
Before you start trying to solve a problem it's important to study the existing system before embarking on major changes.
Consider the Analysis phase like a visit to the doctor. You would be pretty worried if you told the doctor you had a headache and the doctor immediately started merrily injecting you with various things before even looking at you or asking you any questions. Such behaviour is likely to cause more problems than it solves, so doctors always analyse their patients - observing, questioning, testing - before beginning any treatment.
So also do problem solvers study the system they intend to change, and the organisation it's in, before they decide what needs to be done. By thoroughly understanding a system, its operation, its context, its strengths and weaknesses, one can better decide how to start improving it.
There's not much good getting heavily into a project if the whole thing is a silly idea to start with. The preliminary investigation is an early test of whether the project should even be started.

4. Design:
The finished design of a solution should contain:
• data structure (e.g. field names, data types and lengths, filenaming, folder structure schemes etc).
• how the data is to be acquired (what procedures and equipment will be needed?)
• data input procedures and equipment (e.g. keyboard? barcode reader? ICR/OMR?)
• interfaces (e.g. what will a data entry screen look like? Will people need to leave the main screen to access functions? How will menus be organised into commands and submenus? What shortcut keys will be used? Will you use a text box, listbox, combo box, tickbox for a particular item of data entry? What colour scheme will be used? What navigation scheme will be used? What icons represent what meaning? Will the layout of the data entry form help users enter data in the required order and the required format?
• control procedures - What validation rules will be used on what fields to check for data reasonableness, existence or format?) What will different error messages say? How can output be checked for accuracy (e.g. an average can be compared with the data items from which it was calculated). How can procedural errors or problems be detected? (e.g. an order may be cross-checked against the stock database to ensure the ordered item is in stock, or whether it needs to be backordered and the potential customer notified of the delay)
• what workloads and capacities the system must be capable of - e.g. storage capacities, number of transactions per hour, disaster-recovery abilities
• documentation and training requirements for different types of users
• validation and storage methods to be used
• how to produce the output (i.e. processing actions)
• procedures to be followed to use the solution
• backup requirements and procedures - what needs to be backed up, how often, how backups are stored, what backup scheme will be used?
• how the solution is to be tested to ensure it works properly - what needs to be tested? Functionality, presentation, usability, accessibility, communication of message. How will you test?
A data flow diagram is used to describe the flow of data through a complete data-processing system. Different graphic symbols represent the clerical operations involved and the different input, storage, and output equipment required. Although the flow chart may indicate the specific programs used, no details are given of how the programs process the data.
Gantt Charts is detailed timeline of events in a project laid out. In short it is a schedule of Software Development Life Cycle.
Structure chart consist of a top-down description of a process and its sub-processes.
Data Dictionary - describes (for example) a database's fields, types, lengths, validation rules, formulae.

5. Development (Coding):
The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like compilers, interpreters, debuggers etc... are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.
Software coding standards are language-specific programming rules that greatly reduce the probability of introducing errors into your applications, regardless of which software development model is being used to create that application.
Languages used:
• Java
• C/C++
• Web-related scripting: HTML, JavaScript
• Database related: MS-SQL, Oracle.


6. Testing:
Software testing:
Software testing is the process of checking software, to verify that it satisfies its requirements and to detect errors.
Software testing is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service under test, with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding software bugs.
Testing can never completely establish the correctness of computer software. Instead, it furnishes a criticism or comparison that compares the state and behaviour of the product against a specification. A primary purpose for testing is to detect software failures so that defects may be uncovered and corrected.
Testing methods: Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases.
Black box testing
Black box testing treats the software as a black-box without any understanding of internal behavior. It aims to test the functionality according to the requirements. Thus, the tester inputs data and only sees the output from the test object. This level of testing usually requires thorough test cases to be provided to the tester who then can simply verify that for a given input, the output value (or behavior), is the same as the expected value specified in the test case. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix etc.
White box testing
White box testing, however, is when the tester has access to the internal data structures and algorithms. (and the code that implement these)
Types of white box testing
The following types of white box testing exist:
• code coverage - creating tests to satisfy some criteria of code coverage. For example, the test designer can create tests to cause all statements in the program to be executed at least once.
• mutation testing methods.
• fault injection methods.
• static testing - White box testing includes all static testing.

7. Implementation:
In SDLC, implementation refers to post-development process of guiding a client to use the software or hardware that was purchased. This includes Requirements Analysis, Scope Analysis, Customizations, Systems Integrations, User Policies, User Training and Delivery.
Software Implementations involve several professionals like Business Analysts, Technical Analysts, Solution Architect , and Project Managers.Analysts in the implementation phase acts as the intermediator between user and developers. The Implementation Phase includes:
 Hardware and software installation
 User Training
 Documentation

Primary objectives of Implementation phase are to ensure that:
• Software is installed - The systems are placed and used by actual users.
• The users are all trained - Training is provided to the users of the system usually through workshops or online
• The business is benefiting


8. Maintenance and Support
Maintenance includes activities like keeping the system up to date with the changes in the organization and ensuring it meets the goals of the organization by:
• Building a help desk to support the system users – having a team available to aid technical difficulties and answer questions
• Implementing changes to the system when necessary.

System maintenance involves the monitoring, evaluating and modifying of a system to make desirable or necessary improvements. In other words, maintenance includes enhancements, modifications or any change from the original specifications. Therefore, the information analyst should take change as his/her responsibility so as to keep the functioning at an acceptable level.
Software needs to be maintained not because some of its modules or programs wear out and need to be replaced, but because there are often some residual errors remaining in the system which have to be removed as soon they are discovered. This is an on-going process, until the system stabilizes.
Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. About ⅔ of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new things, which in many ways can be considered new work.




SYSTEM DEVELOPMENT LIFE CYCLE FLOW CHART
 

DesiDude666

New member
Introduction

Software systems development is, from a historical perspective, a very young profession.
The first official programmer is probably Grace Hopper, working for the Navy in the mid-1940s. More realistically, commercial applications development did not really take off until the early 1960s. These initial efforts are marked by a craftsman-like approach based on what intuitively felt right. Unfortunately, too many programmers had poor intuition.

By the late 1960s it had become apparent that a more disciplined approach was required.
The software engineering techniques started coming into being. This finally brings us to the SDLC.
What evolved from these early activities in improving rigor is an understanding of the scope and complexity of the total development process. It became clear that the process of creating systems required a system to do systems. This is the SDLC. It is the system used to build and maintain software systems.


The System Development Life Cycle is the process of developing information systems through investigation, analysis, design, implementation, and maintenance.
The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

SDLC Objectives

When we plan to develop, acquire or revise a system we must be absolutely clear on the objectives of that system. The objectives must be stated in terms of the expected benefits that the business expects from investing in that system. The objectives define the expected return on investment.


An SDLC has three primary business objectives:
- Ensure the delivery of high quality systems;
- Provide strong management controls;
- Maximize productivity.

In other words, the SDLC should ensure that we can produce more function, with higher quality, in less time, with less resources and in a predictable manner.

1. Ensure High Quality

Judging the quality of a wine or a meal is a subjective process. The results of the evaluation reflect the tastes and opinions of the taster. But we need a more rigorous, objective approach to evaluating the quality of systems. Therefore, before we can ensure that a system has high quality, we must know what quality is in a business context. The primary definition of quality in a business context is the return on investment (ROI) achieved by the system. The business could have taken the money spent on developing and running the system and spent it on advertising, product development, staff raises or many other things. However, someone made a decision that if that money was spent on the system it would provide the best return or at least a return justifying spending the money on it.

This ROI can be the result of such things as: operational cost savings or cost avoidance; improved product flexibility resulting in a larger market share; and/or improved decision support for strategic, tactical and operational planning. In each case the ROI should be expressed quantitatively, not qualitatively. Qualitative objectives are almost always poorly defined reflections of incompletely analyzed quantitative benefits.
The SDLC must ensure that these objectives are well defined for each project and used as the primary measure of success for the project and system. The business objectives provide the contextual definition of quality. There is also an intrinsic definition of quality. This definition of quality centers on the characteristics of the system itself: is it zero defect, is it well-structured, it is well-documented, is it functionally robust, etc. The characteristics are obviously directly linked to the system's ability to provide the best possible ROI. Therefore, the SDLC must ensure that these qualities are built into the system. However, how far you go in achieving intrinsic quality is tempered by the need to keep contextual quality (i.e., ROI) the number one priority. At times there are trade-offs to be made between the two. Within the constraints of the business objectives, the SDLC must ensure that the system has a high degree of intrinsic quality.

2. Provide Strong Management Control

The essence of strong management controls is predictability and feedback. Projects may last for many months or even years. Predictability is provided by being able to accurately estimate, as early as possible, how long a project will take, how many resources it will require and how much it will cost. This information is key to determining if the ROI will be achieved in a timely manner or at all. The SDLC must ensure that such planning estimates can be put together before there have been any significant expenditures of resources, time and money on the project. The feedback process tells us how well we are doing in meeting the plan and the project's objectives. If we are on target, we need that verified. If there are exceptions, these must be detected as early as possible so that corrective actions can be taken in a timely manner. The SDLC must ensure that management has timely, complete and accurate information on the status of the project and the system throughout the development process.

System Development Life Cycle

There are two basic definitions of productivity. One centers on what you are building; the other is from the perspective of how many resources, how much time and how much money it takes to build it. The first definition of productivity is based on the return on investment (ROI) concept. What value is there in doing the wrong system twice as fast?
It would be like taking a trip to the wrong place in a plane that was twice as fast. You might have been able to simply walk to the correct destination. Therefore, the best way to measure a project team's or system department's productivity is to measure the net ROI of their efforts. The SDLC must not just ensure that the expected ROI for each project is well defined. It must ensure that the projects being done are those with the maximum possible ROI opportunities of all of the potential projects.
Even if every project in the queue has significant ROI benefits associated with it, there is a practical limit to how large and how fast the systems organization can grow. We need to make the available staff as productive as possible with regard to the time, money and resources required to deliver a given amount of function. The first issue we face is the degree to which the development process is labor intensive. Part of the solution lies in automation. The SDLC must be designed in such a way as to take maximum advantage of the computer assisted software engineering (CASE) tools.
The complexity of the systems and the technology they use has required increased specialization. These specialized skills are often scarce. The SDLC must delineate the tasks and deliverables in such a way as to ensure that specialized resources can be brought to bear on the project in the most effective and efficient way possible.
One of the major wastes of resources on a project has to do things over. Scrap and rework occurs due to such things as errors and changes in scope. The SDLC must ensure that scrap and rework is minimized. Another activity that results in non-productive effort is the start-up time for new resources being added to the project. The SDLC must ensure that start-up time is minimized in any way possible. A final opportunity area for productivity improvements is the use of off-the-shelf components. Many applications contain functions identical to those in other applications. The SDLC should ensure that if useful components already exist, they can be re-used in many applications.
What we have identified so far are the primary business objectives of the SDLC and the areas of opportunity we should focus on in meeting these objectives. What we must now do is translate these objectives into a set of requirements and design points for the SDLC.


STAGES OF SDLC

Preliminary investigation is the first step in the system development life cycle. The preliminary investigation is a way of handling the user’s request to change, improve or enhance an existing system. The objective is to determine, whether the request is valid and feasible before any recommendation is made to do nothing, improve or modify the existing system, or build altogether a new one. It is not a design study, nor does it include the collections of details to completely describe the business system. The following objectives should be accomplished, while working on the preliminary investigation. System investigation includes the following two sub-stages.
1. Problem Definition
2. Feasibility Study


1. PROBLEM DEFINITION:
Problem Initiation includes define necessary input, output, storage etc. Define what the problem really is. State a goal to be achieved
A problem initiation will describe:
• required input (what data has to be acquired to produce the output?)
• required output (i.e. what information is the system supposed to produce?)
Problem analysis breaks the problem down into its parts and describes them. Note that this step does not care what solution will be used to solve the problem. The analysis lays down the basic requirements that the eventual solution must achieve (a logical design).
During problem initiation, one of the first things to do is to define the problem correctly. If you get this wrong (or skip it completely) everything you do afterwards could be a complete waste of time and money.
The most important task in creating a software product is extracting the requirements. Customers typically know what they want, but not what software should do, while incomplete, ambiguous or contradictory requirements are recognized by skilled and experienced software engineers. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.

Problem Initiation is the task of precisely describing the software to be written, possibly in a rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable.

Here are some possible definitions of problems:
1. The existing system has a poor response time, i.e. it is slow.
2. It is unable to handle workload.
3. The problem of cost, i.e. the existing system is not economical.
4. The problem of accuracy and reliability.
5. The requisite information is not produced by the existing system.
6. The problem of security.

Similarly, a system analyst should provide a rough estimate of the cost involved for the system development. This is again a very important question that too often is not asked until it is quite late in the system development process.

2. FEASIBILITY STUDY

The literal meaning of feasibility is vitality. This study is undertaken to know the likelihood of the system being useful to the organization. Feasibility study, basically, is a high-level capsule version of the entire process, intended to answer a number of questions like what is the problem? Is the problem even worth solving? However, as the name indicates in preliminary investigation, feasibility study should be relatively brief, as the objective at this stage is not only to get an idea of the scope. The findings of this study should be formally presented to the user management. This presentation marks a crucial decision point in the life of the project. If the management approves the project, the feasibility study report represents an excellent model of the system analyst’s understanding of the problem and provides a clear sense of direction for the subsequent development of the system.

The aim of the feasibility study is to access alternative systems and to propose the most feasible and desirable system for development. Thus, feasibility study provides an overview of the problem and acts as an important checkpoint that should be completed before committing more resources.

The feasibility of a proposed system can be assessed in terms of four major categories, as summarized below.
1. Organizational Feasibility: the extent to which a proposed information system supports the objective of the organization’s strategic plan for information systems determines the organizational feasibility of the system project. The information system must be taken as a sub-set of the whole organization.

2. Economic Feasibility: in this study, costs and returns are evaluated to know whether returns justify the investment in the system project. The economic questions raised by the analyst during the preliminary investigation are for the purpose of estimating the following:
(a) The cost of conducting a full system investigation.
(b) The cost of hardware and software for the class of application being considered.
(c) The benefits in the form of reduced costs, improved customer service, improved resource utilization or fewer costly errors.

3. Technical Feasibility: whether reliable hardware and software, capable of meeting the needs of the proposed system can be acquired or developed by the organization in the required time is a major concern of the technical feasibility. In the other words, technical feasibility includes questions like:
(a) Does the necessary technology exist to do what is suggested and can it be acquired?
(b) Does the proposed equipment have the technical capacity to hold the data required to use the new system?
(c) Will the proposed system provide adequate responses to inquiries, regardless of the number of locations and users?
(d) Can the system be expanded?
(e) Is there any technical surety of accuracy, reliability, ease of access and data security?

4. Operational Feasibility: the willingness and the ability of the management, employees, customers, suppliers, etc., to operate, use and support a proposed system come under operational feasibility. In the other words, the test of operational feasibility asks if the system will work when it is developed and installed. Are there major barriers to implementation? The following questions are asked in operational feasibility.
(a) Is there sufficient support from the management? From employees? From customers? From suppliers?
(b) Are current business methods acceptable to the users?
(c) Have the users been involved in the planning and development of the system project?

Operational feasibility would pass the test if the system is developed as per rules, regulations, laws, organizational culture, union agreements, etc., and above all with the active involvement of the users.
Besides these four main categories, the system should also be accessed in terms of legal feasibility and schedule feasibility. Whereas legal feasibility refers to the viability if the system from the legal point of view, i.e. it checks whether the system abides by all laws and regulations of the land, the schedule feasibility evaluates the probability of completing the system in the time allowed for its development, since for the system to be useful, it must be finished well before the actual requirement of its usage.
For the determining feasibility, a project proposal must pass all these tests. Otherwise, it is not a feasible project. For example, a personnel record system that is economically feasible and operationally attractive is not feasible if the necessary technology does not exist, Infeasible projects are abandoned at this stage, unless they are reworked and resubmitted as new proposal.

3. Analysis
Primary objective of Analysis phase is to understand the user’s needs and develop requirements for Software development.
It involves activities like:
• Gathering Information
• Define Software requirement.
• Prioritize requirements.
• Generate & Evaluate alternatives.
• Review recommendations with management.
Before you start trying to solve a problem it's important to study the existing system before embarking on major changes.
Consider the Analysis phase like a visit to the doctor. You would be pretty worried if you told the doctor you had a headache and the doctor immediately started merrily injecting you with various things before even looking at you or asking you any questions. Such behaviour is likely to cause more problems than it solves, so doctors always analyse their patients - observing, questioning, testing - before beginning any treatment.
So also do problem solvers study the system they intend to change, and the organisation it's in, before they decide what needs to be done. By thoroughly understanding a system, its operation, its context, its strengths and weaknesses, one can better decide how to start improving it.
There's not much good getting heavily into a project if the whole thing is a silly idea to start with. The preliminary investigation is an early test of whether the project should even be started.

4. Design:
The finished design of a solution should contain:
• data structure (e.g. field names, data types and lengths, filenaming, folder structure schemes etc).
• how the data is to be acquired (what procedures and equipment will be needed?)
• data input procedures and equipment (e.g. keyboard? barcode reader? ICR/OMR?)
• interfaces (e.g. what will a data entry screen look like? Will people need to leave the main screen to access functions? How will menus be organised into commands and submenus? What shortcut keys will be used? Will you use a text box, listbox, combo box, tickbox for a particular item of data entry? What colour scheme will be used? What navigation scheme will be used? What icons represent what meaning? Will the layout of the data entry form help users enter data in the required order and the required format?
• control procedures - What validation rules will be used on what fields to check for data reasonableness, existence or format?) What will different error messages say? How can output be checked for accuracy (e.g. an average can be compared with the data items from which it was calculated). How can procedural errors or problems be detected? (e.g. an order may be cross-checked against the stock database to ensure the ordered item is in stock, or whether it needs to be backordered and the potential customer notified of the delay)
• what workloads and capacities the system must be capable of - e.g. storage capacities, number of transactions per hour, disaster-recovery abilities
• documentation and training requirements for different types of users
• validation and storage methods to be used
• how to produce the output (i.e. processing actions)
• procedures to be followed to use the solution
• backup requirements and procedures - what needs to be backed up, how often, how backups are stored, what backup scheme will be used?
• how the solution is to be tested to ensure it works properly - what needs to be tested? Functionality, presentation, usability, accessibility, communication of message. How will you test?
A data flow diagram is used to describe the flow of data through a complete data-processing system. Different graphic symbols represent the clerical operations involved and the different input, storage, and output equipment required. Although the flow chart may indicate the specific programs used, no details are given of how the programs process the data.
Gantt Charts is detailed timeline of events in a project laid out. In short it is a schedule of Software Development Life Cycle.
Structure chart consist of a top-down description of a process and its sub-processes.
Data Dictionary - describes (for example) a database's fields, types, lengths, validation rules, formulae.

5. Development (Coding):
The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like compilers, interpreters, debuggers etc... are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.
Software coding standards are language-specific programming rules that greatly reduce the probability of introducing errors into your applications, regardless of which software development model is being used to create that application.
Languages used:
• Java
• C/C++
• Web-related scripting: HTML, JavaScript
• Database related: MS-SQL, Oracle.


6. Testing:
Software testing:
Software testing is the process of checking software, to verify that it satisfies its requirements and to detect errors.
Software testing is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service under test, with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding software bugs.
Testing can never completely establish the correctness of computer software. Instead, it furnishes a criticism or comparison that compares the state and behaviour of the product against a specification. A primary purpose for testing is to detect software failures so that defects may be uncovered and corrected.
Testing methods: Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases.
Black box testing
Black box testing treats the software as a black-box without any understanding of internal behavior. It aims to test the functionality according to the requirements. Thus, the tester inputs data and only sees the output from the test object. This level of testing usually requires thorough test cases to be provided to the tester who then can simply verify that for a given input, the output value (or behavior), is the same as the expected value specified in the test case. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix etc.
White box testing
White box testing, however, is when the tester has access to the internal data structures and algorithms. (and the code that implement these)
Types of white box testing
The following types of white box testing exist:
• code coverage - creating tests to satisfy some criteria of code coverage. For example, the test designer can create tests to cause all statements in the program to be executed at least once.
• mutation testing methods.
• fault injection methods.
• static testing - White box testing includes all static testing.

7. Implementation:
In SDLC, implementation refers to post-development process of guiding a client to use the software or hardware that was purchased. This includes Requirements Analysis, Scope Analysis, Customizations, Systems Integrations, User Policies, User Training and Delivery.
Software Implementations involve several professionals like Business Analysts, Technical Analysts, Solution Architect , and Project Managers.Analysts in the implementation phase acts as the intermediator between user and developers. The Implementation Phase includes:
 Hardware and software installation
 User Training
 Documentation

Primary objectives of Implementation phase are to ensure that:
• Software is installed - The systems are placed and used by actual users.
• The users are all trained - Training is provided to the users of the system usually through workshops or online
• The business is benefiting


8. Maintenance and Support
Maintenance includes activities like keeping the system up to date with the changes in the organization and ensuring it meets the goals of the organization by:
• Building a help desk to support the system users – having a team available to aid technical difficulties and answer questions
• Implementing changes to the system when necessary.

System maintenance involves the monitoring, evaluating and modifying of a system to make desirable or necessary improvements. In other words, maintenance includes enhancements, modifications or any change from the original specifications. Therefore, the information analyst should take change as his/her responsibility so as to keep the functioning at an acceptable level.
Software needs to be maintained not because some of its modules or programs wear out and need to be replaced, but because there are often some residual errors remaining in the system which have to be removed as soon they are discovered. This is an on-going process, until the system stabilizes.
Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. About ⅔ of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new things, which in many ways can be considered new work.




SYSTEM DEVELOPMENT LIFE CYCLE FLOW CHART

Just finished this in my IT Project Management module. You need a proper framework before the Systems development process can be used. For instance, you could use the DSDM or the RAD approach. You would need to ensure piloting, end-user feedback and scope control etc.

I suggest adding in a quality assurance framework or a RAD model since software development is much more complex and may be divided in components and processes.
 

stockally

New member
It was nice going through the content of this post. It would be much better if we see some examples of application
 
Introduction

Software systems development is, from a historical perspective, a very young profession.
The first official programmer is probably Grace Hopper, working for the Navy in the mid-1940s. More realistically, commercial applications development did not really take off until the early 1960s. These initial efforts are marked by a craftsman-like approach based on what intuitively felt right. Unfortunately, too many programmers had poor intuition.

By the late 1960s it had become apparent that a more disciplined approach was required.
The software engineering techniques started coming into being. This finally brings us to the SDLC.
What evolved from these early activities in improving rigor is an understanding of the scope and complexity of the total development process. It became clear that the process of creating systems required a system to do systems. This is the SDLC. It is the system used to build and maintain software systems.


The System Development Life Cycle is the process of developing information systems through investigation, analysis, design, implementation, and maintenance.
The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

SDLC Objectives

When we plan to develop, acquire or revise a system we must be absolutely clear on the objectives of that system. The objectives must be stated in terms of the expected benefits that the business expects from investing in that system. The objectives define the expected return on investment.


An SDLC has three primary business objectives:
- Ensure the delivery of high quality systems;
- Provide strong management controls;
- Maximize productivity.

In other words, the SDLC should ensure that we can produce more function, with higher quality, in less time, with less resources and in a predictable manner.

1. Ensure High Quality

Judging the quality of a wine or a meal is a subjective process. The results of the evaluation reflect the tastes and opinions of the taster. But we need a more rigorous, objective approach to evaluating the quality of systems. Therefore, before we can ensure that a system has high quality, we must know what quality is in a business context. The primary definition of quality in a business context is the return on investment (ROI) achieved by the system. The business could have taken the money spent on developing and running the system and spent it on advertising, product development, staff raises or many other things. However, someone made a decision that if that money was spent on the system it would provide the best return or at least a return justifying spending the money on it.

This ROI can be the result of such things as: operational cost savings or cost avoidance; improved product flexibility resulting in a larger market share; and/or improved decision support for strategic, tactical and operational planning. In each case the ROI should be expressed quantitatively, not qualitatively. Qualitative objectives are almost always poorly defined reflections of incompletely analyzed quantitative benefits.
The SDLC must ensure that these objectives are well defined for each project and used as the primary measure of success for the project and system. The business objectives provide the contextual definition of quality. There is also an intrinsic definition of quality. This definition of quality centers on the characteristics of the system itself: is it zero defect, is it well-structured, it is well-documented, is it functionally robust, etc. The characteristics are obviously directly linked to the system's ability to provide the best possible ROI. Therefore, the SDLC must ensure that these qualities are built into the system. However, how far you go in achieving intrinsic quality is tempered by the need to keep contextual quality (i.e., ROI) the number one priority. At times there are trade-offs to be made between the two. Within the constraints of the business objectives, the SDLC must ensure that the system has a high degree of intrinsic quality.

2. Provide Strong Management Control

The essence of strong management controls is predictability and feedback. Projects may last for many months or even years. Predictability is provided by being able to accurately estimate, as early as possible, how long a project will take, how many resources it will require and how much it will cost. This information is key to determining if the ROI will be achieved in a timely manner or at all. The SDLC must ensure that such planning estimates can be put together before there have been any significant expenditures of resources, time and money on the project. The feedback process tells us how well we are doing in meeting the plan and the project's objectives. If we are on target, we need that verified. If there are exceptions, these must be detected as early as possible so that corrective actions can be taken in a timely manner. The SDLC must ensure that management has timely, complete and accurate information on the status of the project and the system throughout the development process.

System Development Life Cycle

There are two basic definitions of productivity. One centers on what you are building; the other is from the perspective of how many resources, how much time and how much money it takes to build it. The first definition of productivity is based on the return on investment (ROI) concept. What value is there in doing the wrong system twice as fast?
It would be like taking a trip to the wrong place in a plane that was twice as fast. You might have been able to simply walk to the correct destination. Therefore, the best way to measure a project team's or system department's productivity is to measure the net ROI of their efforts. The SDLC must not just ensure that the expected ROI for each project is well defined. It must ensure that the projects being done are those with the maximum possible ROI opportunities of all of the potential projects.
Even if every project in the queue has significant ROI benefits associated with it, there is a practical limit to how large and how fast the systems organization can grow. We need to make the available staff as productive as possible with regard to the time, money and resources required to deliver a given amount of function. The first issue we face is the degree to which the development process is labor intensive. Part of the solution lies in automation. The SDLC must be designed in such a way as to take maximum advantage of the computer assisted software engineering (CASE) tools.
The complexity of the systems and the technology they use has required increased specialization. These specialized skills are often scarce. The SDLC must delineate the tasks and deliverables in such a way as to ensure that specialized resources can be brought to bear on the project in the most effective and efficient way possible.
One of the major wastes of resources on a project has to do things over. Scrap and rework occurs due to such things as errors and changes in scope. The SDLC must ensure that scrap and rework is minimized. Another activity that results in non-productive effort is the start-up time for new resources being added to the project. The SDLC must ensure that start-up time is minimized in any way possible. A final opportunity area for productivity improvements is the use of off-the-shelf components. Many applications contain functions identical to those in other applications. The SDLC should ensure that if useful components already exist, they can be re-used in many applications.
What we have identified so far are the primary business objectives of the SDLC and the areas of opportunity we should focus on in meeting these objectives. What we must now do is translate these objectives into a set of requirements and design points for the SDLC.


STAGES OF SDLC

Preliminary investigation is the first step in the system development life cycle. The preliminary investigation is a way of handling the user’s request to change, improve or enhance an existing system. The objective is to determine, whether the request is valid and feasible before any recommendation is made to do nothing, improve or modify the existing system, or build altogether a new one. It is not a design study, nor does it include the collections of details to completely describe the business system. The following objectives should be accomplished, while working on the preliminary investigation. System investigation includes the following two sub-stages.
1. Problem Definition
2. Feasibility Study


1. PROBLEM DEFINITION:
Problem Initiation includes define necessary input, output, storage etc. Define what the problem really is. State a goal to be achieved
A problem initiation will describe:
• required input (what data has to be acquired to produce the output?)
• required output (i.e. what information is the system supposed to produce?)
Problem analysis breaks the problem down into its parts and describes them. Note that this step does not care what solution will be used to solve the problem. The analysis lays down the basic requirements that the eventual solution must achieve (a logical design).
During problem initiation, one of the first things to do is to define the problem correctly. If you get this wrong (or skip it completely) everything you do afterwards could be a complete waste of time and money.
The most important task in creating a software product is extracting the requirements. Customers typically know what they want, but not what software should do, while incomplete, ambiguous or contradictory requirements are recognized by skilled and experienced software engineers. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.

Problem Initiation is the task of precisely describing the software to be written, possibly in a rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable.

Here are some possible definitions of problems:
1. The existing system has a poor response time, i.e. it is slow.
2. It is unable to handle workload.
3. The problem of cost, i.e. the existing system is not economical.
4. The problem of accuracy and reliability.
5. The requisite information is not produced by the existing system.
6. The problem of security.

Similarly, a system analyst should provide a rough estimate of the cost involved for the system development. This is again a very important question that too often is not asked until it is quite late in the system development process.

2. FEASIBILITY STUDY

The literal meaning of feasibility is vitality. This study is undertaken to know the likelihood of the system being useful to the organization. Feasibility study, basically, is a high-level capsule version of the entire process, intended to answer a number of questions like what is the problem? Is the problem even worth solving? However, as the name indicates in preliminary investigation, feasibility study should be relatively brief, as the objective at this stage is not only to get an idea of the scope. The findings of this study should be formally presented to the user management. This presentation marks a crucial decision point in the life of the project. If the management approves the project, the feasibility study report represents an excellent model of the system analyst’s understanding of the problem and provides a clear sense of direction for the subsequent development of the system.

The aim of the feasibility study is to access alternative systems and to propose the most feasible and desirable system for development. Thus, feasibility study provides an overview of the problem and acts as an important checkpoint that should be completed before committing more resources.

The feasibility of a proposed system can be assessed in terms of four major categories, as summarized below.
1. Organizational Feasibility: the extent to which a proposed information system supports the objective of the organization’s strategic plan for information systems determines the organizational feasibility of the system project. The information system must be taken as a sub-set of the whole organization.

2. Economic Feasibility: in this study, costs and returns are evaluated to know whether returns justify the investment in the system project. The economic questions raised by the analyst during the preliminary investigation are for the purpose of estimating the following:
(a) The cost of conducting a full system investigation.
(b) The cost of hardware and software for the class of application being considered.
(c) The benefits in the form of reduced costs, improved customer service, improved resource utilization or fewer costly errors.

3. Technical Feasibility: whether reliable hardware and software, capable of meeting the needs of the proposed system can be acquired or developed by the organization in the required time is a major concern of the technical feasibility. In the other words, technical feasibility includes questions like:
(a) Does the necessary technology exist to do what is suggested and can it be acquired?
(b) Does the proposed equipment have the technical capacity to hold the data required to use the new system?
(c) Will the proposed system provide adequate responses to inquiries, regardless of the number of locations and users?
(d) Can the system be expanded?
(e) Is there any technical surety of accuracy, reliability, ease of access and data security?

4. Operational Feasibility: the willingness and the ability of the management, employees, customers, suppliers, etc., to operate, use and support a proposed system come under operational feasibility. In the other words, the test of operational feasibility asks if the system will work when it is developed and installed. Are there major barriers to implementation? The following questions are asked in operational feasibility.
(a) Is there sufficient support from the management? From employees? From customers? From suppliers?
(b) Are current business methods acceptable to the users?
(c) Have the users been involved in the planning and development of the system project?

Operational feasibility would pass the test if the system is developed as per rules, regulations, laws, organizational culture, union agreements, etc., and above all with the active involvement of the users.
Besides these four main categories, the system should also be accessed in terms of legal feasibility and schedule feasibility. Whereas legal feasibility refers to the viability if the system from the legal point of view, i.e. it checks whether the system abides by all laws and regulations of the land, the schedule feasibility evaluates the probability of completing the system in the time allowed for its development, since for the system to be useful, it must be finished well before the actual requirement of its usage.
For the determining feasibility, a project proposal must pass all these tests. Otherwise, it is not a feasible project. For example, a personnel record system that is economically feasible and operationally attractive is not feasible if the necessary technology does not exist, Infeasible projects are abandoned at this stage, unless they are reworked and resubmitted as new proposal.

3. Analysis
Primary objective of Analysis phase is to understand the user’s needs and develop requirements for Software development.
It involves activities like:
• Gathering Information
• Define Software requirement.
• Prioritize requirements.
• Generate & Evaluate alternatives.
• Review recommendations with management.
Before you start trying to solve a problem it's important to study the existing system before embarking on major changes.
Consider the Analysis phase like a visit to the doctor. You would be pretty worried if you told the doctor you had a headache and the doctor immediately started merrily injecting you with various things before even looking at you or asking you any questions. Such behaviour is likely to cause more problems than it solves, so doctors always analyse their patients - observing, questioning, testing - before beginning any treatment.
So also do problem solvers study the system they intend to change, and the organisation it's in, before they decide what needs to be done. By thoroughly understanding a system, its operation, its context, its strengths and weaknesses, one can better decide how to start improving it.
There's not much good getting heavily into a project if the whole thing is a silly idea to start with. The preliminary investigation is an early test of whether the project should even be started.

4. Design:
The finished design of a solution should contain:
• data structure (e.g. field names, data types and lengths, filenaming, folder structure schemes etc).
• how the data is to be acquired (what procedures and equipment will be needed?)
• data input procedures and equipment (e.g. keyboard? barcode reader? ICR/OMR?)
• interfaces (e.g. what will a data entry screen look like? Will people need to leave the main screen to access functions? How will menus be organised into commands and submenus? What shortcut keys will be used? Will you use a text box, listbox, combo box, tickbox for a particular item of data entry? What colour scheme will be used? What navigation scheme will be used? What icons represent what meaning? Will the layout of the data entry form help users enter data in the required order and the required format?
• control procedures - What validation rules will be used on what fields to check for data reasonableness, existence or format?) What will different error messages say? How can output be checked for accuracy (e.g. an average can be compared with the data items from which it was calculated). How can procedural errors or problems be detected? (e.g. an order may be cross-checked against the stock database to ensure the ordered item is in stock, or whether it needs to be backordered and the potential customer notified of the delay)
• what workloads and capacities the system must be capable of - e.g. storage capacities, number of transactions per hour, disaster-recovery abilities
• documentation and training requirements for different types of users
• validation and storage methods to be used
• how to produce the output (i.e. processing actions)
• procedures to be followed to use the solution
• backup requirements and procedures - what needs to be backed up, how often, how backups are stored, what backup scheme will be used?
• how the solution is to be tested to ensure it works properly - what needs to be tested? Functionality, presentation, usability, accessibility, communication of message. How will you test?
A data flow diagram is used to describe the flow of data through a complete data-processing system. Different graphic symbols represent the clerical operations involved and the different input, storage, and output equipment required. Although the flow chart may indicate the specific programs used, no details are given of how the programs process the data.
Gantt Charts is detailed timeline of events in a project laid out. In short it is a schedule of Software Development Life Cycle.
Structure chart consist of a top-down description of a process and its sub-processes.
Data Dictionary - describes (for example) a database's fields, types, lengths, validation rules, formulae.

5. Development (Coding):
The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like compilers, interpreters, debuggers etc... are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.
Software coding standards are language-specific programming rules that greatly reduce the probability of introducing errors into your applications, regardless of which software development model is being used to create that application.
Languages used:
• Java
• C/C++
• Web-related scripting: HTML, JavaScript
• Database related: MS-SQL, Oracle.


6. Testing:
Software testing:
Software testing is the process of checking software, to verify that it satisfies its requirements and to detect errors.
Software testing is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service under test, with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding software bugs.
Testing can never completely establish the correctness of computer software. Instead, it furnishes a criticism or comparison that compares the state and behaviour of the product against a specification. A primary purpose for testing is to detect software failures so that defects may be uncovered and corrected.
Testing methods: Software testing methods are traditionally divided into black box testing and white box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases.
Black box testing
Black box testing treats the software as a black-box without any understanding of internal behavior. It aims to test the functionality according to the requirements. Thus, the tester inputs data and only sees the output from the test object. This level of testing usually requires thorough test cases to be provided to the tester who then can simply verify that for a given input, the output value (or behavior), is the same as the expected value specified in the test case. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix etc.
White box testing
White box testing, however, is when the tester has access to the internal data structures and algorithms. (and the code that implement these)
Types of white box testing
The following types of white box testing exist:
• code coverage - creating tests to satisfy some criteria of code coverage. For example, the test designer can create tests to cause all statements in the program to be executed at least once.
• mutation testing methods.
• fault injection methods.
• static testing - White box testing includes all static testing.

7. Implementation:
In SDLC, implementation refers to post-development process of guiding a client to use the software or hardware that was purchased. This includes Requirements Analysis, Scope Analysis, Customizations, Systems Integrations, User Policies, User Training and Delivery.
Software Implementations involve several professionals like Business Analysts, Technical Analysts, Solution Architect , and Project Managers.Analysts in the implementation phase acts as the intermediator between user and developers. The Implementation Phase includes:
 Hardware and software installation
 User Training
 Documentation

Primary objectives of Implementation phase are to ensure that:
• Software is installed - The systems are placed and used by actual users.
• The users are all trained - Training is provided to the users of the system usually through workshops or online
• The business is benefiting


8. Maintenance and Support
Maintenance includes activities like keeping the system up to date with the changes in the organization and ensuring it meets the goals of the organization by:
• Building a help desk to support the system users – having a team available to aid technical difficulties and answer questions
• Implementing changes to the system when necessary.

System maintenance involves the monitoring, evaluating and modifying of a system to make desirable or necessary improvements. In other words, maintenance includes enhancements, modifications or any change from the original specifications. Therefore, the information analyst should take change as his/her responsibility so as to keep the functioning at an acceptable level.
Software needs to be maintained not because some of its modules or programs wear out and need to be replaced, but because there are often some residual errors remaining in the system which have to be removed as soon they are discovered. This is an on-going process, until the system stabilizes.
Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. About ⅔ of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new things, which in many ways can be considered new work.




SYSTEM DEVELOPMENT LIFE CYCLE FLOW CHART



thanks for the information

kewl job@!
 

abhishreshthaa

New member
hey friend, check out the ppt on SDLC .....
i hope it can be helpful...

:SugarwareZ-230:
 

Attachments

  • 21894887-system-development-life-cycle-Presentation.ppt
    680.5 KB · Views: 20

IF4IT

New member
I suggest that this SDLC is not one that is commonly used because it uses vague phases, like "Implementation." Good SDLCs break phases out by clear purpose...

- Strategy
- Research & Analysis
- Planning
- Requirements
- Design
- Federated Building
- Common/Centralized Build
- Systems Integration Testing
- User Acceptance Testing
- Performance Testing
- Training & Education
- Production
- Disaster Recovery
- Closing

I hope this helps.
 

IF4IT

New member
Here is a link to a more common SDLC Framework that includes things like alignment to Environments, Deployment Functions, and IT Projects.

As mentioned, the phases are:

  1. Inception and Strategy: Develop Release Strategy
  2. Research and Analysis: Develop Solutions Options
  3. Planning: Develop Release Plans
  4. Requirements: Requirements Gathering and Analysis
  5. Design: Detailed Design & Engineering
  6. Build and Procurement: Procurement and Federated Building/Coding
  7. Common/Centralized Build: Merge of all Federated Builds into one common build
  8. Systems Integration Testing: Check that integrations work (technically work)
  9. User Acceptance Testing: Functional Testing of Business Requirements
  10. Production: Deploy to Customers and End Users
  11. Disaster Recovery: Deploy to DR solution
  12. Close: End of Release and Postmortem

It's important to understand that when use very vague words to name your SDLC Phases like "Development" and "Implementation," you are using naming conventions that are unclear to the people who work within and across each of the phases. For example, in a Small Enterprise, "Development" means doing all work across all phases because there are only a few people to do the work. Also, "Implementation" is something that is done in every Environment.

Also, "Testing" is not only done in a single phase. It's something you do in multiple phases. You test in...

  • Research and Analysis Phase: (Usually only basic testing of the environment and the tools in the environment)
  • Procurement & Build Phase: Unit and Module Testing
  • Common/Centralized Build Phase: Build Testing, Unit Testing, and Module Testing
  • Systems Integration Testing Phase: Build Testing, Unit Testing, Module Testing, and Integration Testing
  • User Acceptance Testing Phase: Build Testing, Unit Testing, Module Testing, Integration Testing, and User Acceptance Testing
  • Performance Testing Phase (If you need this phase): Build Testing, Performance Testing
  • Security Penetration Testing Phase (If you need this phase): Usually performed only in production environment
  • Product Phase: Production Integrity Tests
  • Disaster Recovery Phase: DR Testing

The above are explicit phase related testing examples. Within each phase are also the testing functions that are directly aligned with each of the deployment functions. So, for every phase that you Deploy software and/or systems to, you have to perform and re-perform testing of each separate Deployment Function within that Phase. For example:

Deployment Functions:
  • Build -> Build Testing
  • Package -> Package Testing
  • Distribute -> Distribution Testing
  • Install -> Installation Testing
  • Instantiate -> Instantiation Testing
  • Initialize -> Initialization Testing
  • Execute -> Execution Testing

As mentioned, the above gets repeated in every phase that has an Environment that you would deploy your Assets (Software and/or Systems) to.

Something to keep in mind is that...
  • a Bad SDLC uses vague phase naming conventions that confuse stakeholders.
  • a Good SDLC uses strong and relevant naming conventions for phases that make things clear to stakeholders.

I hope this helps.
 
The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software engineering to describe a process for planning, creating, testing, and deploying an information system.Here are some advantages given below:


1)System Development Life Cycle allows maximum management control.
2)Builds considerable system documentation.
3)system requirements can be traced back to stated business requirements.
4)It allows products to be reviewed to see whether they meet the user’s needs and conform to standards.
 
Top