Software Development Methodology and Lifecycle.
.png)
Software Development(Program)
Software development is the complex process which comprises different activities that need to be carried out to develop a software product .It requires careful planning and execution to meet the goals. Sometimes a developer must react quickly and aggressively to meet ever-changing market demands. Maintaining software quality hinders fast-paced software development, as many testing cycles are necessary to ensure quality products
Software Development Life Cycle (SDLC):
•Software Development Life Cycle is a process used by software industry to design, develop and test high quality software. SDLC aims to produce a high quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates. It is a framework defining tasks performed at each step in the software development process. SDLC prescribes the different activities that need to be carried out to develop a software product and the sequencing of these activities.
Why to use SDLC?
•Software development organizations have realized that adherence to suitable well-defined life cycle model helps to produce good quality products and that too without time and the cost overruns. The primary advantage of adhering to a life cycle model is that it encourages development of software in a systematic and disciplined manner.
Phases of Software Development Life Cycle(SDLC)
.png)
1.Planning and Feasibility Study
•It establishes a high-level view of the intended project and determines its goals. It is the most important and fundamental stage in SDLC. It is performed by the senior members of the team with inputs from the customer, the sales department, market surveys and domain experts in the industry. This information is then used to plan the basic project approach and to conduct product feasibility study in the economical, operational, and technical areas.
Feasibility Study
Feasibility study is an assessment of the practicality of a proposed project. A feasibility study evaluates the project's potential for success; therefore, important factor in the credibility of the study for potential investors and lending institutions. It determines the limitations and constraints before starting to develop the system. It helps to suggests whether the system be implemented using current technology within given cost and schedule constraints.
Types of Feasibility
•Technical feasibility
•Economic Feasibility
•Behavioral Feasibility
•Legal Feasibility
•Operational Feasibility
•Time Feasibility
Technical Feasibility
Technical Feasibility determines whether the technology need for system is available or not. What technical risk is there? How the technology can be used within the system? Is the proposed technology or solution practical? Do we possess the necessary technical expertise?
Technical Feasibility identifies correct personnel and correct equipment like hardware and software.
Economic Feasibility
Economic Feasibility helps to analysis of how beneficial will be the system with regards to time, money and other resources required.
Economic Feasibility concerns with the following issues:
– Is the project possible, given constraints?
– What are the benefits?
– What are the development and operational cost?
– Where the system is affordable or not?
– Identifies the equipment cost, operating cost, manpower cost and development cost.
– Identifies the financial benefits and cost benefit analysis associated with the system.
– Concerns with return of investment.
Behavioral Feasibility:
Behavioral Feasibility studies related to behavior of user, person or the society due to adjustment of new technology or system. It concerns with how the user response to the new system. Since the new system may lose the employment, fear of loss of job, identity and displacement of manpower etc.
Legal Feasibility:
Legal Feasibility deals with legal issues such as copyright, trademark etc.
•Legal outcomes of the system in an organization
•Contractual effects like software and hardware ownership, license agreement are dealt.
Operational Feasibility:
Operational Feasibility deals with operational factors of new system to determine that whether the system will be able to perform the designed functions with the existing organizational environment and existing human resources or not.
Operational Feasibility Concerns With:
– Whether the current staff can work in the new system after training or not
– If the whole staffs need very long time to be trained in the new system then the new system will not be feasible
Time Feasibility:
Time Feasibility helps to determine the deadline for a completion of system and it is concerned with the time required for development of new system is feasible or not. If the deadline is very near but the system development time requires long duration then the system is not feasible due to time.
Requirement Analysis and Specification
The goal of the requirement analysis and specification phase is to clearly understand the customer requirements and to systematically organize the requirements into a specification document. It involves regular interaction with client to determine their expectations, providing visual representations, creating mappings between loose ends, defining boundaries of the system.. The experienced members of the development team who gather and analyze customer requirements and then write the requirement specification document are known as System Analysts.
Software Requirement Specification (SRS) is the final outcome of the requirement analysis and specification phase. It is a formal agreement between the client and the agency which clearly states as what will be in scope and what is out of scope.
Main Activities Carried Out During Requirements Analysis And Specification Phase Are Of Two Types :
– Requirement Gathering and Analysis
– Requirement Specification
Requirement Gathering and Analysis
•The requirements are almost never available in the form of a single document from the customer, neither is it completely obtainable from any single customer representative. The requirements have to be gathered by the analyst from several sources in bits and pieces. These gathered requirements are then analyzed to remove several types of anomalies
Requirement Gathering
•Requirement elicitation
•System analyst starts requirement gathering activity by collecting all information that could be useful to develop the system.
– Studying the existing documentation
– Interview
– Task analysis
– Scenario Analysis (A task can have many scenarios of operation)
– Form Analysis
Requirement Analysis
The main purpose of the requirement analysis activity is to analyze the collected information to obtain a clear understanding of the product to be developed, with a view to removing all ambiguities, incompleteness and inconsistencies from the initial customer perception of the problem. Basic questions pertaining to the project should be clearly understood by the analyst in order to obtain a good grasp of the problem.
– What is the problem?
– Why is it important to solve the problem?
– What exactly are the data input to the system and what exactly are the data output by the system?
– What are the possible procedures that need to be followed to solve the problems?
•Three main type of problems in the requirements that the analyst needs to identify and resolve:
1 Ambiguity
•Several interpretations of the requirement
2 Inconsistency
•One of the requirements contradicts the other
3 Incompleteness
•Some requirements have been overlooked
Two Types of Requirements
1 Functional Requirements :
Functional Requirements is the desired functionality that the client want us to build and delivered
to them. It describes an interaction between the system and its environment. The document is created logging all details which contains what a certain. System has to do to achieve a certain specific objective.
2 Non-Functional Categories:
Non-Functional Categories is the untold part of the project which are not communicated but readily
understood as a Global standard .It is understood as a support system of functional requirements. Non functional requirements can be Response time, security, reliability, accuracy, capacity and availability.
Why it is important or What can go wrong?
• If requirement analysis phase is not completed properly or in a sluggish manner then there might be inconsistencies in the final product. During requirement gathering, Client is not able to provide more details or not sure exactly what is required. Client comes from a non-technical background and not familiar with technical terms so they find it difficult to share the exact expectations.
Irregular Communication between the engaged parties. If there are more than one parties involved and they don’t interact regularly at the requirement analysis phase, then there is a possibility of disagreement in later phases of development.
Timelines are not achievable. Client is always in a hurry to see the final product so they directly or indirectly plan unrealistic timelines and finally receive a half-baked product. When the clients receive their final product, by then, expectations changes and they want to introduce more new features which were not part of earlier documents. This pushes the team back on their schedule. Improper Documentation is another culprit which enhances the possibility of unachievable tasks.
How can it be improved?
It provides visual examples to clients, if client is feeling difficulty in explaining the exact requirement. Minutes of meeting are the decision makers so should be prepared and circulated among the team. Language used to write requirements must always be easy to understand, precise and unambiguous. Clearly state the drawbacks of limited timelines, if not achievable.
Buffer time should be documented for each activity in case any variation in requirements are expected. Have a clearly defined process for receiving, analyzing and incorporating change requests, and make your customer aware of his/her entry point into this process. Deadlines should be documented to ensure delivery date for each asset, if not received by due date then changes in the schedule should be permitted.
Spend sufficient time to understand the objectives, deliverables and scope of the project. Document all the assumptions and let client be aware of each assumption. Clearly state all the functional requirement and non-functional requirement. Finally, proper time should be given to each parties to review the final document and provide sign-off.
Thank You!!!
Deep99Notes