Software Development Activities

JOURNAL #TEN [SYD701]

Software Development Activities

Several activities make up the methodologies commonly deployed for software development, these include:

• Requirements analysis
• System & software design
• Implementation
• Testing
• Integration (where necessary)
• Deployment/Implementation
• Maintenance

The purpose of these activities plus the inputs and outputs are described as follows:

Requirements Analysis

Purpose: To gain a shared high-level understanding of the requirements and end-user needs amongst the team and stakeholders.

Inputs: A thorough analysis requires the gathering of organisational documentation, stakeholder interviews, observing end-users and assigning questionnaires.

Outputs: A set of clearly defined, achievable and verifiable requirements linking end-users with system elements and basic functions.

System & Software Design

Purpose: Provide sufficiently detailed data and information about the system to support the designing of elements that includes the architecture, modules, components and interfaces.

Inputs: Identify technologies that can compose the system and the architectural characteristics that meet business requirements and make them implementable.

Outputs: A defined logical solution that enables it to be passed to the programmers for development or prototyping.

Implementation

Purpose: Deploying and configuring software and writing code capable of meeting the business needs, involving the correct personnel to extract the full benefits.

Inputs: These can include data from stakeholders, end-users or other systems deployed in the organisation. Inputs may be an element of the design that the developer can implement.

Outputs: A well planned and considered solution in addition to any working code that is made accessible in the most effective way by end-users.

Testing

Purpose: Discover and evaluate errors or bugs in the design or software to verify that the application is suitable for use.

Inputs: Test against the validated requirements ranging from acceptance testing of the whole system to integration, user, functionality, performance, regression, stress and usability tests.

Outputs: These could include the prevention of bugs, reduced development costs and improved performance with the working code.

Integration

Purpose: To combine various software subsystems and components to develop a single, unified system.

Inputs: Disparate systems purchased or developed and configured to meet the integration strategy.

Outputs: A single system that functions as one, with the necessary capability to meet the end-user and stakeholder needs.

Deployment/Installation

Purpose: To roll out the application, taking it from the developer environment through to the end-user installation.

Inputs: A checklist for a tested, running application on a cloud server or local device.

Outputs: An application that has been approved for delivery and is operational for end-users.

Maintenance

Purpose: To modify and update the application after it has been delivered to the end-users, continuous development can also be considered.

Inputs: Customer feedback reports, vendor changes, recommended patches or the identification of errors or vulnerabilities may lead to maintenance.

Outputs: These include the correction of faults, fixes to improve performance or optimisation, or the deletion of features.

The Agile Manifesto

The Agile Manifesto is defined by 4 statements, where the items on the left are considered more valuable then the items on the right:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Twelve principles comprise the Agile Methodology:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, and then tunes and adjusts its behaviour accordingly.

The following is an analysis of the fourth principle: Business people and developers must work together daily throughout the project.

How do you think the principle is derived from the agile manifesto?

The manifesto values individuals and interactions over processes and tools, and customer collaboration over contract negotiation. The complexity of software development increases the risk of failure, the business stakeholder’s regular and ongoing involvement allows teams to overcome communication and cultural differences between IT professionals and business people, improving the chances of success. The intention is that these separate individuals become familiar with each other over time, making them more effective.

Why is the principle important?

The best way to achieve this is through building relationships of trust through regular communication and interaction. Regular, daily interaction forces these different groups to work together. The business people can begin to understand the complexity and challenges faced and support the team through any problems or frustrations encountered. Binding teams together can allow for a common culture to emerge as they become used to operating together towards a shared goal of system deliverables, which is often viewed as a developer-only area.

The principle allows for increased feedback time, a shared feeling of responsibility for the development and a common knowledge framework from which to operate, aiding discussion and even technical solutions when design elements or functionality change.

In practice, what would the application of the principle look like in a software development context?

In a Scrum framework, this would be inviting business users to observe the daily stand-up, attend the sprint review and retrospective and can even include a shared kitchen or drinks area to allow natural communication outside the more formal gatherings.

The Scrum Framework

Describe the practice:

Scrum is an agile framework that focuses on continuous improvement and team collaboration, whereas agile is a mindset, Scrum is a framework for getting work done. Scrum allows teams to continually learn and adjust to factors that are susceptible to change as the development evolves.

Scrum inherits the benefits experienced with Agile software deployments, the cyclical nature of sprints allows the team to collaborate and stay well informed by transferring knowledge and solving problems as a team. The characteristics of Scrum are:

• Short planning cycles of between 7 and 30 days with a focus on requirements and completing tasks
• Ability to produce deliverables effectively within the short iteration (Sprint)
• Prompt incorporation of stakeholder feedback into the following sprint

Scrum acknowledges that there are known unknowns and unknown unknowns at the start of the project that teams will have to navigate, which can be amplified by changing conditions or requirements throughout the development. Scrum compromises the following practices:

Artefacts: Product Backlog, Sprint Backlog, Increment, Sprint goal

Roles: Product Owner, Scrum Master, Scrum development team, Stakeholders

Events: Sprint, Sprint Planning, Daily stand up, Review and Retrospective meetings

Give an example of how that practice would be applied in the real world (you can use the assignment scenario):

Establishing a product backlog should be considered foundational, providing a structure from which to start development based on a shared understanding of the tasks involved that can add tangible value to the stakeholders and begin user testing early in the process.

The outsourcing of product development means that access to end-users and stakeholders will be more challenging. Deploying a tool such as Jira Service Management will aid the visibility and understanding of the steps involved to produce software, capable of meeting the needs and technical competencies of business managers and users. The product backlog should be applied as a validation tool in the daily scrum meetings, measuring the achieved goal.

Reflect on the practice (ease of use, suitability, technical or social issues, etc.:

Scrum has events and artefacts built into the framework that make it suitable. The alignment with the Agile Manifesto means that it is suitable for deployment in cross-functional teams to break down technical and social barriers. It can be difficult to learn but easy to use, once the common practices are established, such as the product and sprint backlogs and daily stand-ups become familiar, teams can begin to understand what is expected of them.

The concept of failing fast, important in Scrum, can help individuals overcome problems they have encountered and work to find solutions. The sprint review and retrospective allow the team to adapt the framework to their unique development project, improving the processes over time and making it easier to use.

12 Principles Behind the Agile Manifesto - Agile Alliance. (n.d.). Retrieved May 22, 2022, from https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/