SDLC

SDLC is the process of developing information systems through investigation, analysis, design, implementation and maintenance. SDLC is also known as information systems development or application development. It is also known as Waterfall Model

The software development life cycle (SDLC) is the entire process of formal, logical steps taken to develop a software product. The phases of SDLC can vary somewhat but generally include the following 

RequirementsAnalysis 
Extracting the requirements of a desired software product is the first task in creating it. While customers probably believe they know what the software is to do, it may require skill and experience in software engineering to recognize incomplete, ambiguous or contradictory requirements.

Specification 
Specification is the task of precisely describing the software to be written, in a mathematically 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.

Software architecture 
The architecture of a software system refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system.

Coding 
Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion.

Testing 
Testing of parts of software, especially where code by two different engineers must work together, falls to the software engineer.

Documentation 
An important task is documenting the internal design of software for the purpose of future maintenance and enhancement. Documentation is most important for external interfaces.

Software Training and Support 
A large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are occasionally resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, its very important to have training classes for the most enthusiastic software users (build excitement and confidence), shifting the training towards the neutral users intermixed with the avid supporters, and finally incorporate the rest of the organization into adopting the new software. Users will have lots of questions and software problems which leads to the next phase of Software.

Process Models 
There are several methodologies or models that can be used to guide the software development lifecycle.Someofthese include:  
--Linear or Waterfall Model  
--Rapid Application Development (RAD) 
--Joint Application Development (JAD) 
--Prototyping Model 
--Fountain Model 
--Spiral Model 
--Build and Fix 
--Synchronize-and-Stabilize

Rapid Application Development 
“Rapid Application Development (RAD) is an incremental software development process model that emphasises a very short development cycle typically 60-90 days”.The RAD approach encompasses the following phases:  
1.Business Modelling 
2.Data Modelling 
3.Process Modelling 
4.Application Generation 
5.Testing and Turnover

Business Modelling 
The information flow among business functions is modeled in am way that answers the following questions: 
1.What information drives the business process? 
2.What information is generated? 
3.Who generates it? 
4.Where does the information go? 
5.Who processes it?

Data Modelling 
The information flow defined as part of the business modelling phase is refined into a set of data objects that are needed to support the business.The characteristic of each object is identified and the relationship between these objects are defined.

Process Modelling 
The data objects defined in the data-modelling phase are transformed to achieve the information flow necessary to implement a business function. Processing the descriptions are created for adding,modifying,deleting or retrieving data object.

Application Generation 
RAD assumes the use of the RAD tools like VB,VC++,Delphi etc rather than creating 
software using conventional third generation programming languages. The RAD works to reuse  
existing program components or create reusable components. In all cases,automated tools are used to facilitate construction of the software.

Testing and Turnover 
Since the RAD process emphasizes reuse,many of the program components have already  
been tested. This minimize the testing and development time. 
 

SRS 

1.Introduction

1.1 Purpose of this document 
Describes the purpose of the document, and the intended audience.

1.2 Scope of this document 
Describes the scope of this requirements definition effort. Introduces the requirements elicitation team, including users, customers, system engineers, and developers.  
This section also details any constraints that were placed upon the requirements elicitation process, such as schedules, costs, or the software engineering environment used to develop requirements.

1.3 Overview 
Provides a brief overview of the product defined as a result of the requirements elicitation process

1.4 Business Context 
Provides an overview of the business organization sponsoring the development of this product. This overview should include the business's mission statement and its organizational objectives or goals.

2. General Description

2.1 Product Functions 
Describes the general functionality of the product, which will be discussed in more detail below.

2.2 Similar System Information 
Describes the relationship of this product with any other products. Specifies if this product is intended to be stand-alone, or else used as a component of a larger product. If the latter, this section discusses the relationship of this product to the larger product.

2.3 User Characteristics 
Describes the features of the user community, including their expected expertise with software systems and the application domain.

2.4 User Problem Statement 
This section describes the essential problem(s) currently confronted by the user community.

2.5 User Objectives 
This section describes the set of objectives and requirements for the system from the user's perspective. It may include a "wish list" of desirable characteristics, along with more feasible solutions that are in line with the business objectives.

2.6 General Constraints 
Lists general constraints placed upon the design team, including speed requirements, industry protocols, hardware platforms, and so forth.

3. Functional Requirements 
This section lists the functional requirements in ranked order. Functional requirements describes the possible effects of a software system, in other words, what the system must accomplish. Other kinds of requirements (such as interface requirements, performance requirements, or reliability requirements) describe how the system accomplishes its functional requirements. Each functional requirement should be specified in a format similar to the following:

a)Short, imperative sentence stating highest ranked functional requirement.

Description 
A full description of the requirement.

Criticality 
Describes how essential this requirement is to the overall system.

Technical issues 
Describes any design or implementation issues involved in satisfying this requirement.

Cost and schedule 
Describes the relative or absolute costs associated with this issue.

Risks 
Describes the circumstances under which this requirement might not able to be satisfied, and what actions can be taken to reduce the probability of this occurrence.

Dependencies with other requirements 
Describes interactions with other requirements.

... others as appropriate

b)<Name of second highest ranked requirement> 
And so forth...

4. Interface Requirements 
This section describes how the software interfaces with other software products or users for input or output. Examples of such interfaces include library routines, token streams, shared memory, data streams, and so forth.

4.1 User Interfaces 
Describes how this product interfaces with the user.

4.1.1 GUI 
Describes the graphical user interface if present. This section should include a set of screen dumps or mockups to illustrate user interface features.  
If the system is menu-driven, a description of all menus and their components should be provided.

4.1.2 CLI 
Describes the command-line interface if present. For each command, a description of all arguments and example values and invocations should be provided.

4.1.3 API 
Describes the application programming interface, if present. For each public interface function, the name, arguments, return values, examples of invocation, and interactions with other functions should be provided.

4.1.4 Diagnostics or ROM 
Describes how to obtain debugging information or other diagnostic data.

4.2 Hardware Interfaces 
Describes interfaces to hardware devices.

4.3 Communications Interfaces 
Describes network interfaces.

4.4 Software Interfaces 
Describes any remaining software interfaces not included above.

5. Performance Requirements 
Specifies speed and memory requirements.

6. Design Constraints 
Specifies any constraints for the design team using this document.

6.1 Standards Compliance 
 
6.2 Hardware Limitations 
... others as appropriate

7. Other non-functional attributes 
Specifies any other particular non-functional attributes required by the system. Examples are provided below.

7.1 Security 
7.2 Binary Compatibility 
7.3 Reliability 
7.4 Maintainability 
7.5 Portability 
7.6 Extensibility 
7.7 Reusability 
7.8 Application Affinity/Compatibility 
7.9 Resource Utilization 
7.10 Serviceability 
... others as appropriate

8. Preliminary Object-Oriented Domain Analysis 
This section presents a list of the fundamental objects that must be modelled within the system to satisfy its requirements. The purpose is to provide an alternative, "structural" view on the requirements stated above and how they might be satisfied in the system.

8.1 Inheritance Relationships 
This section should contain a set of graphs that illustrate the primary inheritance hierarchy (is-kind-of) for the system.

8.2 Class descriptions 
This section presents a more detailed description of each class identified during the OO Domain Analysis.

Each class description should conform to the following structure:

8.2.1 <Class name>

8.2.1.1 Abstract or Concrete:  
Indicates whether this class is abstract or concrete.

8.2.1.2 List of Superclasses:  
Names all immediate superclasses.

8.2.1.3 List of Subclasses:  
Names all immediate subclasses.

8.2.1.4 Purpose:  
States the basic purpose of the class.

8.2.1.5 Collaborations:  
Names each class with which this class must interact in order to accomplish its purpose, and how.

8.2.1.6 Attributes:  
Lists each attribute (state variable) associated with each instance of this class, and indicates examples of possible values (or a range).

8.2.1.7 Operations:  
Lists each operation that can be invoked upon instances of this class. For each operation, the arguments (and their type), the return value (and its type), and any side effects of the operation should be specified.

8.2.1.8 Constraints:  
Lists any restrictions upon the general state or behavior of instances of this class.

9. Operational Scenarios 
This section should describe a set of scenarios that illustrate, from the user's perspective, what will be experienced when utilizing the system under various situations.  
In the article Inquiry-Based Requirements Analysis (IEEE Software, March 1994), scenarios are defined as follows:

In the broad sense, a scenario is simply a proposed specific use of the system. More specifically, a scenario is a description of one or more end-to-end transactions involving the required system and its environment. Scenarios can be documented in different ways, depending up on the level of detail needed. The simplest form is a use case, which consists merely of a short description with a number attached. More detailed forms are called scripts. These are usually represented as tables or diagrams and involved identifying an action and the agent (doer) of the action. FOr this reason, a script can also be called an action table.  
Although scenarios are useful in acquiring and validating requirements, they are not themselves requirements, because the describe the system's behavior only in specific situations; a specification, on the other hand, describes what the system should do in general.

10. Preliminary Schedule 
This section provides an initial version of the project plan, including the major tasks to be accomplished, their interdependencies, and their tentative start/stop dates. The plan also includes information on hardware, software, and wetware resource requirements.  
The project plan should be accompanied by one or more PERT or GANTT charts.

11. Preliminary Budget 
This section provides an initial budget for the project, itemized by cost factor.

12. Appendices 
Specifies other useful information for understanding the requirements. All SRS documents should include at least the following two appendices:

12.1 Definitions, Acronyms, Abbreviations 
Provides definitions of unfamiliar definitions, terms, and acronyms.

12.2 References 
Provides complete citations to all documents and meetings referenced or used in the preparation of this document.

DFD ( Data Flow Diagrams)

A data flow diagram is a graphical technique that depicts information flow and the transforms that are applied as data move from input to output. The data flow diagram is also known as ‘data flow graph’. Various symbols are used to depict the data from one level to another level. 
The data flow diagram must be used to represent the system or software at any level of abstraction. In fact data flow diagram may partitioned into the levels that represent increasing information flow for functional modeling as information on flow modeling. In doing so it satisfies the second operational analysis principle i.e., creating a functional model.

Notation 
Logical data flow diagrams can be completed using only four simple notations, i.e. special symbols or icons and the annotation that associates them with a specific system the Yourdon approach is used.

1.Data Flow 
Data move in a specific direction from an origin to a destination in the form of a document. The data flow is a “packet of data”.

2.Process 
People procedure or devices that use or produce data. The physical component is not identified.

3.Source or Destination 
External sources or destinations of data interact with the system but are outside its boundary.

4.Data Store 
Here data are stored or referenced by process in the system