Scribd
Upload
26 views16 pages

SDLC (1) Sadia

The document discusses the main phases of the Software Development Life Cycle (SDLC) which are Requirement Gathering, Requirement Analysis, Prioritization, Development, Unit Testing, Integration Testing, Deployment to System Integration Testing, Manual Testing, Deployment to User Acceptance Testing, End-to-End Testing, and Production. It then provides a simplified example of developing a basic To-Do list web application going through each phase of the SDLC.

Uploaded by

aodhora111
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
26 views16 pages

SDLC (1) Sadia

The document discusses the main phases of the Software Development Life Cycle (SDLC) which are Requirement Gathering, Requirement Analysis, Prioritization, Development, Unit Testing, Integration Testing, Deployment to System Integration Testing, Manual Testing, Deployment to User Acceptance Testing, End-to-End Testing, and Production. It then provides a simplified example of developing a basic To-Do list web application going through each phase of the SDLC.

Uploaded by

aodhora111
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 16

SDLC

Requirement Gathering: This phase involves gathering and documenting the specific needs and
expectations of the stakeholders. For example, you could discuss how a team interviewed users,
analyzed existing systems, and used various techniques like surveys and questionnaires to gather
requirements for a new software application.

Requirement Analysis: In this phase, the collected requirements are carefully analyzed and
organized. You can provide an example of how a team might use use-case diagrams, flowcharts,
and data models to understand and document the functional and non-functional requirements of
the project.

Prioritization: Once requirements are gathered, they need to be prioritised to determine what
should be addressed first. A practical example could be discussing how the team categorized
requirements as "must-haves," "should-haves," and "nice-to-haves" to guide project planning.

Development: This phase involves the actual coding and development of the software. You can
provide an example of how developers write code, create databases, and design the user interface
based on the requirements and design specifications.
Unit Testing: During development, individual components or units of code are tested in isolation
to ensure they work as expected. For instance, you can mention how developers write test cases
to verify the correctness of a specific function or module.

Integration Testing: In this phase, the developed units are integrated and tested together to ensure
they work as a cohesive system. You can discuss how various modules or components are
combined and tested for compatibility.

Deployment to SIT (System Integration Testing): At this point, the software is deployed in a
controlled environment for system-level testing. You can explain how this environment simulates
the production environment, and how system-level tests are performed to identify and fix
integration issues.

Manual Testing: This is when manual testing is conducted to ensure that the software meets the
specified requirements. You can provide examples of test cases that are executed by testers to
identify bugs or issues.

Deployment to UAT (User Acceptance Testing): The software is deployed in an environment


where end-users can test it. You can discuss how actual users assess the software's usability, and
functionality, and provide feedback.

End-to-End Testing: This phase involves testing the entire software system, including all
integrated components, to ensure that it functions as expected in a real-world scenario. You can
give an example of how this phase validates the software's ability to handle typical user
scenarios.

Production: Once all the testing and validation are complete, the software is deployed in the
production environment for actual use by end-users. You can mention that this phase marks the
official launch of the software.

Example:

Creating a complete software project with code and visualization for every step of the Software
Development Life Cycle (SDLC) is beyond the scope of a single response, as it can be quite
extensive. A simplified example of a web application development project that goes through
each phase of the SDLC. I'll include code snippets and descriptions for each step. Please note
that this is a highly simplified example, and real-world projects are usually more complex.
Scenario: Building a simple "To-Do List" web application using HTML, CSS, and JavaScript.

Requirement Gathering:

Requirement: Develop a web application to manage to-do lists.


Stakeholder Interviews, Surveys, and Documentation.

Requirement Analysis:

Create Use-Case Diagrams, Flowcharts, and Data Models.

Prioritization:

"Must-Have": Create, Read, Update, and Delete (CRUD) tasks.


"Should-Have": User Authentication.
"Nice-to-Have": Mobile Responsiveness.

Development:

Create HTML, CSS, and JavaScript files for the web application.
html
Copy code
<!-- index.html -->
<!DOCTYPE html>
<html>
<head>
<title>ToDo List</title>
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body>
<h1>ToDo List</h1>
<ul id="taskList">
<!-- To-Do tasks will be dynamically added here -->
</ul>
<input type="text" id="taskInput" placeholder="Add a task">
<button onclick="addTask()">Add</button>
<script src="script.js"></script>
</body>
</html>
css
Copy code
/* style.css */
/* Styles for the ToDo List */
h1 {
text-align: center;
}

/* Add more styling as needed */


javascript
Copy code
// script.js
// JavaScript for ToDo List
function addTask() {
// JavaScript code to add a task
}

Unit Testing:

Write unit tests for the JavaScript functions (e.g., addTask()).

Integration Testing:

Ensure that HTML, CSS, and JavaScript are integrated and work together.

Deployment to SIT (System Integration Testing):

Deploy the application to a test server for system-level testing.


Ensure the application runs in a controlled environment similar to the production setup.

Manual Testing:

Test the application manually to find and fix bugs or issues.


Ensure that CRUD operations work correctly.

Deployment to UAT (User Acceptance Testing):

Deploy the application to a staging server for user testing.


Collect feedback from users regarding usability and functionality.
End-to-End Testing:

Test the entire application to simulate real-world use cases.


Verify that the application performs well on different devices and browsers.

Production:

Deploy the application on the production server for public use.


Monitor and maintain the application.
This example represents a simplified SDLC process. In a real-world scenario, each phase would
be more comprehensive and involve multiple iterations to refine the product. Additionally, you
would use tools and frameworks for development, testing, and deployment, and a project
management methodology (e.g., Agile, Waterfall) would guide the process.

A simplified another example of how you might progress through each step of the Software
Development Life Cycle (SDLC) for the e-commerce platform project.

Scenario: Your team is developing an e-commerce platform. You are currently in the
Requirement Analysis phase.

Step 1: Requirement Gathering


In this step, you'll collect requirements from the client. For the e-commerce platform, the client
provides the following requirements:

Requirement: "The platform should allow users to browse products, add them to their cart, and
make secure payments."
Step 2: Requirement Analysis
Now, you analyze and organize the requirements. For the given requirement, you might create a
use-case diagram, which helps you visualize how users will interact with the system:

Use Case: "User adds a product to the cart."


Step 3: Prioritization
You prioritize the requirements based on their importance. For this project, the "must-have"
requirement is the core functionality, allowing users to add products to their cart and make
payments. You would categorize other requirements accordingly.

Step 4: Development
In the Development phase, you create HTML, CSS, and JavaScript files to implement the
platform. Here's a simplified code snippet for adding a product to the cart in JavaScript:

javascript
Copy code
// JavaScript for adding a product to the cart
function addToCart(product) {
// Logic to add the product to the user's cart
}
Step 5: Unit Testing
You write unit tests for the addToCart function to ensure it works correctly. For example

javascript
Copy code
// Unit test for the addToCart function
function testAddToCart() {
// Test if the function adds a product to the cart
// and updates the cart correctly
}
Step 6: Integration Testing
In this phase, you ensure that the product listing, cart management, and payment processing
components work together correctly.

Step 7: Deployment to SIT (System Integration Testing)


You deploy the e-commerce platform to a controlled testing environment that mimics the
production setup. It allows you to test the system as a whole.

Step 8: Manual Testing


Testers perform manual tests to identify and report issues, such as usability problems or
functional bugs.

Step 9: Deployment to UAT (User Acceptance Testing)


The platform is deployed to a staging server for user testing. Actual users assess its usability and
functionality. You collect their feedback for improvements.

Step 10: End-to-end Testing


You conduct end-to-end testing to simulate real-world scenarios, like a user searching for
products, adding them to the cart, and making a payment.
Step 11: Production
Finally, the platform is deployed to the production server, and it's now available for the public to
use. Continuous monitoring and maintenance are essential to keep the platform running
smoothly.

CODE ARCHITECTURE

There are five top architectures:

● Layered (n-tier ) architecture - this approach is probably the most common


because it is usually built around the database, and many applications in
business naturally lend themselves to storing information in tables.
● Event-driven architecture - many programs spend most of their waiting for
something to happen. This is especially true for computers that work directly
with humans, but it’s also common in areas like networks.
● Micro-kernel architecture - many applications have a core set of operations that
are used again and again in different patterns that depend upon the data and the
task at hand.
● Micro-services architecture - software can be like a baby elephant: it is cute and
fun when it’s little, but once it gets big, it is difficult to steer and resistant to
change.

● Space-based architecture - many websites are built around a database, and they
function well as long as the database is able to keep u with the load. But when
usage peaks and the database can’t keep up with the constant challenge of
writing a log of the transactions, the entire website fails.

Creating Clean Code with Hexagonal Architecture


BAD CODE:

package com.viewfromthecodeface.procedural;
import java.util.Scanner;
public class GuessMyNumber {
private final int numberToGuess;
public GuessMyNumber(int numberToGuess) {
this.numberToGuess = numberToGuess;
}

public void play() {


displayIntroduction();
boolean guessedCorrectly = givePlayerUpToFiveAttemptsToGuess();
displayFinalResult(guessedCorrectly);
}
private boolean givePlayerUpToFiveAttemptsToGuess() {
int attemptNumber = 1;
boolean guessedCorrectly = false;
while ( attemptNumber <= 5 && !guessedCorrectly){
int latestGuess = readIntegerFromKeyboard(attemptNumber);

if ( latestGuess == numberToGuess ){
guessedCorrectly = true ;
}
else {
display("Try again");
}

attemptNumber++;
}

return guessedCorrectly;
}

private void displayIntroduction() {


display("I'm thinking of a number between 1 and 10.");
display("Can you guess it, in five guesses?");
}

private void displayFinalResult(boolean guessedCorrectly) {


if ( guessedCorrectly ) {
display("You guessed it! Spooky. Or a good use of binary search...");
}
else {
display("Bad luck. If there's nothing on Netflix, you could try again");
}
}

private int readIntegerFromKeyboard(int attemptNumber) {


display( String.format("Your Guess? (attempt %d) > ", attemptNumber));

Scanner keyboard = new Scanner(System.in);


return keyboard.nextInt();
}

private void display( String text ) {


System.out.println(text);
}
}

package com.viewfromthecodeface.procedural;
public class Main {

public static void main(String[] commandLineArguments) {


new GuessMyNumber(3).play();
}
}

The main method is trivial. It creates a GuessMyNumber object and supplies it with our secret
number.
It then calls play() to run the game.
The code is short. It’s reasonably clear and readable. And it works.
What’s not to like?

What if we want to display it somewhere else?

A console-based game has a retro hipster appeal to it.


But what if we wanted to display to a GUI? Or maybe a simple web page?
How could we do it?

We have to modify the code

To display to a GUI, we would have to rip out the innards of the display() method.
We would need it to write to a JTextArea – or something from JavaFX.
This would need main windows created, and other modifications to the code.
It’s not ideal.
We’ve built and manually tested this thing. Now we’re going to invalidate that.

How do we test this thing?

Before mentioning testing, it has been all manual.


How would you automate tests for this?
Well, the input must come from the keyboard. So you would need to drive that.
The output goes to the console. You would need to intercept that.
Whilst tools such as Mercury WinRunner will do this (and Selenium for Web Apps), testing
through the User Interface is no fun.
UI tests tend to be slow, and a bit ‘flaky’. Sometimes, screen updates are missed, and tests fail
wrongly. ‘False negatives’ as they are known.

Fixing this so we can change and test easily

The big problem with changing the input and output sources is also the problem with testing.
If we could change the input and output sources easily, then we could write a unit test using
stubs.
Stubs are simple Java objects that let us ‘pretend’ to be the real objects:
● We can simulate keystrokes in Java, without messing around with the real keyboard
● We can simulate a console – and capture the program output as simple Java strings.
Using these ideas, we can write a fast, not-flaky Unit Test.

Unit tests and Dependency Inversion

Our program’s real problem is that it depends on the System.scanner for input and
System.out.println for output.
Our code creates and uses the objects directly.
What if we turned that upside down?
What if we made the code so that it didn’t depend on these objects, but instead, provide a way to
plug them in later?
This trick is called dependency inversion.

Second design – using Dependency Inversion

Have a look at this. More code – yes. But better.


Pay attention to:
● interface Guesses – the source of input
● interface Display – where we send text output
● how main() ‘wires up’ the input and output
● HexagonalGuessMyNumber constructor – look at those parameters

Hexagonal
package com.viewfromthecodeface.hexagonal.adapters;

import com.viewfromthecodeface.hexagonal.domain.Display;

public class ConsoleDisplay implements Display {


@Override
public void show(String text) {
System.out.print(text);
}
}

package com.viewfromthecodeface.hexagonal.adapters;

import com.viewfromthecodeface.hexagonal.domain.Guesses;

import java.util.Scanner;

public class KeyboardGuesses implements Guesses {


@Override
public int latestGuess() {
Scanner keyboard = new Scanner(System.in);
return keyboard.nextInt();
}
}
package com.viewfromthecodeface.hexagonal.domain;

public interface Display {


void show(String text);
}

package com.viewfromthecodeface.hexagonal.domain;

public interface Guesses {


int latestGuess();
}

package com.viewfromthecodeface.hexagonal.domain;

public class HexagonalGuessMyNumber {


private final int numberToGuess;
private Guesses guesses;
private Display display;

public HexagonalGuessMyNumber(int numberToGuess, final Guesses guesses, final


Display display) {
this.numberToGuess = numberToGuess;
this.guesses = guesses;
this.display = display;
}

public void play() {


displayIntroduction();
boolean guessedCorrectly = givePlayerUpToFiveAttemptsToGuess();
displayFinalResult(guessedCorrectly);
}

private boolean givePlayerUpToFiveAttemptsToGuess() {


int attemptNumber = 1;
boolean guessedCorrectly = false;

while ( attemptNumber <= 5 && !guessedCorrectly){


displayPrompt(attemptNumber);

if ( guesses.latestGuess() == numberToGuess ){
guessedCorrectly = true ;
}
else {
display.show("Try again");
}

attemptNumber++;
}

return guessedCorrectly;
}

private void displayPrompt(int attemptNumber) {


display.show(String.format("Your Guess? (attempt %d) >", attemptNumber));
}

private void displayIntroduction() {


display.show("I'm thinking of a number between 1 and 10.");
display.show("Can you guess it, in five guesses?");
}

private void displayFinalResult(boolean guessedCorrectly) {


if ( guessedCorrectly ) {
display.show("You guessed it! Spooky. Or a good use of binary search...");
}
else {
display.show("Bad luck. If there's nothing on Netflix, you could try again");
}
}

package com.viewfromthecodeface.hexagonal;

import com.viewfromthecodeface.hexagonal.adapters.ConsoleDisplay;
import com.viewfromthecodeface.hexagonal.adapters.KeyboardGuesses;
import com.viewfromthecodeface.hexagonal.domain.Display;
import com.viewfromthecodeface.hexagonal.domain.Guesses;
import com.viewfromthecodeface.hexagonal.domain.HexagonalGuessMyNumber;

public class Game {


public static void main ( String[] commandLineArguments ){

Display display = new ConsoleDisplay();


Guesses guesses = new KeyboardGuesses();

new HexagonalGuessMyNumber(3, guesses, display).play();


}
}

public interface Guesses {


int latestGuess();
}
REF:

https://www.viewfromthecodeface.com/portfolio/clean-code-hexagonal-architecture/

https://radixweb.com/blog/software-architecture-patterns

You might also like