Software Development Lifecycles

Get Started. It's Free
or sign up with your email address
Rocket clouds
Software Development Lifecycles by Mind Map: Software Development Lifecycles

1. Software Development Lifecycle

1.1. Feasibility Study

1.1.1. Is the project technologically feasible?

1.1.2. Is the project financially viable?

1.1.3. Does the project provide a good ROI?

1.1.4. Key Personnel

1.1.4.1. Business Owners

1.1.4.2. Technical Architects

1.1.4.2.1. Technical architects are also known as IT systems architects and act as the link between a company, its managers and the specialist designers and developers who built the IT system

1.1.4.3. System Architects

1.1.4.3.1. The system architect role is vital to the successful definition, design, delivery, and support of any IT project. A system architect analyzes and recommends the right combination of IT components to achieve a specific business, department, team, or functional goal. They objectively analyze desired processes and outcomes and advice on the right combination of IT systems and components to achieve those goals.

1.1.4.4. Domain Experts

1.1.4.4.1. A subject matter expert (SME) or domain expert is a person who is an authority in a particular area or topic. The term domain expert is frequently used in expert systems software development, and there the term always refers to the domain other than the software domain

1.2. Requirements Engineering

1.2.1. Researching the needs and wants of the client

1.2.1.1. Requirements Elicitation

1.2.1.1.1. Asking people what they want the software to do (interviews, focus groups, questionnaires)

1.2.1.2. Requirements Documentation

1.2.1.2.1. Putting the elicited requirements into an appropriate format

1.2.1.3. Requirements Verification

1.2.1.3.1. Making sure the requirements can be carried out

1.2.1.4. This process is used to create the specification and leads directly into product design

1.2.2. Functional vs Non-Functional (https://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/)

1.2.2.1. A functional requirement is related to the technical functionality of the systems, something the system should do

1.2.2.2. A non-functional requirement is a requirement that specifies criteria to judge the quality of the system

1.2.3. Business Analyst

1.2.3.1. Advises the Requirements Engineer in ways to improve business using features

1.2.3.2. Will try to increase product value

1.2.4. Requirements Engineer

1.2.4.1. Meet with stakeholders and customers

1.2.4.2. Finds out all the needs of the project

1.2.4.3. Requirements Validation; checking needs and feasibility

1.3. Design

1.4. Development

1.4.1. Software Developer

1.4.1.1. Creates software applications based on customer requirements

1.4.1.2. Works from designs created from the product Designer

1.4.1.3. Can be involved in Pair Programming

1.4.1.3.1. Driver = Code Writer

1.4.1.3.2. Observer = Watches driver and does Quality Assurance

1.5. Testing

1.5.1. Types of Testing

1.5.1.1. Unit Testing

1.5.1.1.1. Testing individual units of code

1.5.1.2. Integration testing

1.5.1.2.1. Testing how the units of code interact with each other

1.5.1.3. System testing

1.5.1.3.1. Testing how the system works as a whole

1.5.1.4. Acceptance Testing

1.5.1.4.1. Making sure all requirements have been achieved in the product

1.5.1.5. Regression testing

1.5.1.5.1. Running tests to ensure nothing is broken in updates that was previously functional

1.5.1.6. Alpha testing

1.5.1.6.1. Opening your product up to a small, select group of customers, often with a limited feature set, to get feedback

1.5.1.7. Beta Testing

1.5.1.7.1. Opening up your product to a wider audience, albeit with an incomplete feature set, to gain feedback

1.5.1.8. A | B Testing

1.5.1.8.1. Testing two versions of a product with only one difference o see which is more effective

1.5.2. White Box testing

1.5.2.1. Also called transparent box testing, this is where you check the code to make sure it follows the logic you have dictated

1.5.3. Black Box testing

1.5.3.1. Only concerned with inputs and outputs

1.5.4. Inputs and Outputs

1.5.4.1. Input would be completed software

1.5.4.2. Outputs would be completed and signed off test plan

1.5.5. Personnel

1.5.5.1. Software Testers would be responsible for executing the test plans

1.5.5.1.1. Technical

1.5.5.1.2. Non-Technical (User Experience Tests)

1.6. Implementation / Release

1.6.1. Release Engineer

1.6.1.1. Compiles and assembles code into something that can be shipped

1.6.1.1.1. Cloud

1.6.1.1.2. Physical (DVD, CD etc)

1.6.1.2. Check all software documentation is current and correct

1.6.1.2.1. Responsibility of technical authors

1.7. Maintenance

1.7.1. This would be where software would be patched up based on changing client needs to add additional functionality

1.7.2. Can also be where security holes are plugged to ensure software can still work in a safe manner

1.8. Overall Controllers

1.8.1. Project Managers

1.8.1.1. Ensure everyone has what they need to do their job. Understands the whole process

2. Types of Software Methods

2.1. Linear

2.1.1. The Waterfall Model (Waterfall Model: What Is It and When Should You Use It?

2.1.2. The V Model (V-Model: What Is It And How Do You Use It?

2.2. Spiral (Spiral Model: Software Development For Critical Projects

2.3. Evolutionary

2.4. Agile

2.4.1. Scrum {https://airbrake.io/blog/sdlc/scrum-what-is-it-and-how-do-you-use-it}

2.4.1.1. Scrum Master

2.4.1.2. Product Owner

2.4.1.3. Project Team

2.4.2. Extreme Programming

2.4.3. Lean

2.5. DevOps