What is software development?

“Software development refers to a set of computer science activities dedicated to the process of creating, designing, deploying and supporting software.” IBM 

"Process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications, frameworks, or other software components." Wikipedia

Types of software

System software to provide core functions such as operating systems, disk management, utilities, hardware management and other operational necessities.

Programming software to give programmers tools such as text editors, compilers, linkers, debuggers and other tools to create code.

Application software (applications or apps) to help users perform tasks. Office productivity suites, data management software, media players and security programs are examples.

A possible fourth type is embedded software. Embedded systems software is used to control machines and devices not typically considered computers — telecommunications networks, cars, industrial robots and more. These devices, and their software, can be connected as part of the Internet of Things (IoT).

Roles

Programmers, or coders, write source code to program computers for specific tasks like merging databases, processing online orders, routing communications, conducting searches or displaying text and graphics. Programmers typically interpret instructions from software developers and engineers and use programming languages like C++ or Java to carry them out.

Software engineers apply engineering principles to build software and systems to solve problems. They use modeling language and other tools to devise solutions that can often be applied to problems in a general way, as opposed to merely solving for a specific instance or client. Software engineering solutions adhere to the scientific method and must work in the real world, as with bridges or elevators.

Software developers have a less formal role than engineers and can be closely involved with specific project areas — including writing code. At the same time, they drive the overall software development lifecycle — including working across functional teams to transform requirements into features, managing development teams and processes, and conducting software testing and maintenance.

Steps

Selecting a methodology to establish a framework in which the steps of software development are applied. It describes an overall work process or roadmap for the project.

Agile development, DevOps, Rapid Application Development (RAD), Scaled Agile Framework (SAFe), Waterfall

Gathering requirements to understand and document what is required by users and other stakeholders.

Choosing or building an architecture as the underlying structure within which the software will operate.

Developing a design around solutions to the problems presented by requirements, often involving process models and storyboards.

Constructing code in the appropriate programming language. Involves peer and team review to eliminate problems early and produce quality software faster.

Steps

Testing with pre-planned scenarios as part of software design and coding — and conducting performance testing to simulate load testing on the application.

Managing configuration and defects to understand all the software artifacts (requirements, design, code, test) and build distinct versions of the software. Establish quality assurance priorities and release criteria to address and track defects.

Deploying the software for use and responding to and resolving user problems.

Migrating data to the new or updated software from existing applications or data sources if necessary.

Managing and measuring the project to maintain quality and delivery over the application lifecycle, and to evaluate the development process with models such as the Capability Maturity Model (CMM).

• Requirements analysis and specification

 

• Design and development

 

• Testing

 

• Deployment

 

• Maintenance and support

Software development process steps can be grouped into the phases of the lifecycle, but the importance of the lifecycle is that it recycles to enable continuous improvement. For example, user issues that surface in the maintenance and support phase can become requirements at the beginning of the next cycle.

Software development is important because it helps businesses differentiate themselves and be more competitive. It can improve customer experiences, bring more innovative, feature-rich products to market faster, and make operations more efficient, safe and productive.

Artificial intelligence (AI) – AI enables software to emulate human decision-making and learning. Neural networks, machine learning, natural language processing and cognitive capabilities present developers and businesses with the opportunity to offer products and services that disrupt marketplaces and leap ahead of the competition

Cloud-native development – Cloud-native development is a way of building applications to exploit cloud environments. A cloud-native application consists of discrete, reusable components known as microservices that are designed to integrate into any cloud environment. These microservices act as building blocks and are often packaged in containers.

Cloud-based development – Just as IT organizations look to the cloud to improve resource management and cut costs, so do software development organizations. In this way, the cloud can be used as a fast, flexible and cost-efficient integrated development environment (IDE) or development Platform as a Service (PaaS).

Blockchain – Blockchain is a secure, digitally linked ledger that eliminates cost and vulnerability introduced by parties like banks, regulatory bodies and other intermediaries.

Low code – It’s a development practice that reduces the need for coding and enables non-coders or citizen developers to build or help build applications quickly and at lower cost.

Analytics – Cloud-based services and APIs make it simpler to guide data exploration, automate predictive analytics and create dashboards that deliver new insights and improve decision making.

Mobile – Fifty-four per cent of global executives believe that customer buying behavior has shifted from products and services to experiences. Many of these experiences occur in mobile environments.

Software development processes

The waterfall model, 1970

The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.

 

The Waterfall model is the earliest Software Development Life Cycle (SDLC) approach that was used for software development.

The waterfall model, 1970

Royce’s fixes

program design comes first

› do some design between requirements and analysis phases document the design

› how much? “my own view is quite a lot”

do it twice

› “If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned”

plan, control and monitor testing

› with a separate testing team

involve the customer

› “in a formal way, committed... at earlier points before final delivery”

spiral model, 1986

The most flexible of the SDLC models, the spiral model is similar to the iterative model in its emphasis on repetition. The spiral model goes through the planning, design, build and test phases over and over, with gradual improvements at each pass.

V model

An extension of the waterfall model, this SDLC methodology tests at each stage of development.

extreme programming

Kent Beck, 1999

› take best practices to “extreme” levels

› developed during C3 project with Ron Jeffries

a sample of XP practices

› test first: acceptance and unit tests

› continuous integration

› pair programming

› repeated refactoring

Chrysler’s C3 payroll system

› started in 1996, cancelled in 2000

› implemented in Smalltalk

› running payroll took 1000 hours initially › Chrysler said they abandoned XP after this

https://agilemanifesto.org/

Agile approaches

agile manifesto (2001)
› an articulation of common practices
› a reaction to traditional notions

rejected notions
› upfront design (“BDUF”)

› written documentation (“ceremonial”)

› planning for future modifications

 

key practices like XP
› continuous integration, test first, refactoring
› features added incrementally (“sprints” and “scrums”)

The Agile SDLC model separates the product into cycles and delivers a working product very quickly. This methodology produces a succession of releases. Testing of each release feeds back info that’s incorporated into the next version. According to Robert Half, the drawback of this model is that the heavy emphasis on customer interaction can lead the project in the wrong direction in some cases.

Agile

SCRUM

SCRUM

Scrum is a subset of Agile. It is a lightweight process framework for agile development, and the most widely-used one.

 

A “process framework” is a particular set of practices that must be followed in order for a process to be consistent with the framework. (For example, the Scrum process framework requires the use of development cycles called Sprints, the XP framework requires pair programming, and so forth.)
“Lightweight” means that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.

Scrum Roles

Scrum Development Team

The Team is a self-organizing and cross-functional group of people who do the hands-on work of developing and testing the product. Since the Team is responsible for producing the product, it must also have the authority to make decisions about how to perform the work. The Team is therefore self-organizing: Team members decide how to break work into tasks, and how to allocate tasks to individuals, throughout the Sprint. The Team size should be kept in the range from five to nine people, if possible.

Scrum Roles

Product Owner

The Product Owner is the keeper of the requirements. The Product Owner provides the “single source of truth” for the Team regarding requirements and their planned order of implementation. In practice, the Product Owner is the interface between the business, the customers, and their product related needs on one side, and the Team on the other.

Scrum Roles

Scrum Master

Is the keeper of the process. The ScrumMaster is responsible for making the process run smoothly, for removing obstacles that impact productivity, and for organizing and facilitating the critical meetings. The ScrumMasters responsibilities include

• Teach the Product Owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum.
• Improve the lives of the development Team by facilitating creativity and empowerment.
• Improve the productivity of the development Team in any way possible.
• Improve the engineering practices and tools so that each increment of functionality is potentially shippable.
• Keep information about the Team’s progress up to date and visible to all parties.

Scrum Meetings

Sprint Planning Meeting

At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to negotiate which Product Backlog Items they will attempt to convert to working product during the Sprint.

Daily Scrum and Sprint Execution

Every day at the same time and place, the Scrum Development Team members spend a total of 15 minutes inspecting their progress toward the Sprint goal, and creating a plan for the day. Team members share with each other what they did the previous day to help meet the Sprint goal, what they’ll do today, and what impediments they face

Sprint Review Meeting

At the end of the Sprint, the Scrum Team holds a Sprint Review Meeting to demonstrate a working product increment to everyone who is interested, particularly outside stakeholders. The meeting should feature a live demonstration, not a report.

Scrum Meetings

Sprint Retrospective Meeting

Each Sprint ends with a retrospective. At this meeting, the team reflects on its own process. They inspect their behavior and take action to adapt it for future Sprints.

Backlog Refinement Meeting

Most Product Backlog Items (PBIs) initially need refinement because they are too large and poorly understood. While Backlog Refinement is not a required event, it is a required activity. Most Scrum Teams find it useful to take a short time out of every Sprint for this activity. They get together to prepare the Product Backlog for upcoming Sprint Planning Meetings.

Scrum Meetings

Scrum Artifacts

* Product Backlog

Force-ranked (prioritized) list of desired functionality
• Visible to all stakeholders
• Any stakeholder (including the Team) can add items
• Constantly re-prioritized by the Product Owner
• Constantly refined by the Scrum Team
• Items at top should be smaller (e.g. smaller than 1/4 of a Sprint) than items at bottom

Product Backlog Item (PBI)

• Describes the what more than the how of a customer-centric feature
• Often written in User Story form
• Has a product-wide definition of done to prevent technical debt
• May have item-specific acceptance criteria
• Effort is estimated by the Development Team, ideally in relative units (e.g., story points)

Scrum Artifacts

* Sprint Backlog 

• Consists of selected PBIs negotiated between the team and the Product Owner during the Sprint Planning Meeting
• No changes are made during the Sprint that would endanger the Sprint Goal.
• Initial tasks are identified by the team during Sprint Planning Meeting
• Team will discover additional tasks needed to meet the Sprint Goal during Sprint execution
• Visible to the team
• Referenced during the Daily Scrum Meeting

Scrum Artifacts

* Increment 

• The product capabilities completed during the Sprints
• Brought to a usable, releasable state by the end of each Sprint
• Released as often as the Product Owner wishes
• Inspected during every Sprint Review Meeting

What are stories, epics, initiatives, and themes?

• Stories, also called “user stories,” are short requirements or requests written from the perspective of an end user.
• Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories).
• Initiatives are collections of epics that drive toward a common goal.
• Themes are large focus areas that span the organization

Innovation

Uber, Airbnb, SpaceX. All inspiring examples of innovation, but they don’t tell the whole story.

 

Innovation isn’t just the domain of headline-making organizations or brilliant entrepreneurs. Innovations can be big, like a new product or service. Or smaller, like getting a project team on a common document-sharing platform.

Every innovation is unique. Even so, some strategies and skills are useful across a range of innovative projects.

Something “different” doesn’t have to be earthshaking or even entirely new.

• Innovation involves creating “something different that has impact.”
• To increase your odds of coming up with new and different approaches, observe, question, explore, and network.
• Discover the unexpected by connecting ideas in new ways.
• Expand your options by focusing on what people want to accomplish, not what they say they need.
• Before jumping to a solution, define and redefine a problem in different ways.

You can’t pursue every potential solution—not even close.

• Make smart choices about where to invest your time and resources for the biggest impact.
• Become clear about what assumptions you and your group have that might affect your innovation.
• Figure out how to test those assumptions to know if your solution will work.

Let’s begin!

The purpose isn’t to find “the right solution.” It’s to assess—and balance—risks and rewards.

• You can’t pursue every potential solution, so narrow in on the most promising ones.
• Improve your options by eliminating some and sorting and combining others.
• Next, decide which two or three are worth digging into, testing, and refining.
• Assumptions are things you and your group believe about your innovation.
• To check your assumptions, turn them into testable hypotheses.

• Use small, inexpensive experiments to test whether an innovation will succeed.
• Begin by defining what you want to learn. That means documenting your core hypothesis, assumptions, and success criteria.
• Experiments come in all shapes and sizes. Design yours to meet your needs.
• Capture what you learned. Analyze results and document key findings.
• Decide what’s next. Keep experimenting and refining, launch your innovation, or end the project and focus your innovation efforts elsewhere.

• You can’t innovate alone. You need help—from a variety of people.
• Potential supporters include decision makers, champions, partners, and users.
• Before you make your pitch, know what you need from each person or group.
• Understand what matters most to your potential supporters.
• Customize your appeal for each supporter to convince them that helping you is a valuable opportunity.

• Learning is a key part of innovation.
• You can’t learn without reflecting—regularly looking back on experiences so you can improve moving forward.
• Be aware of confirmation bias so you learn the right things from your innovations.
• In innovation, the only real failure is failing to learn—from both wins and losses.
• By learning how to innovate time and again, you create value for you and your organization.

Motivation

Top Five Motivation Factors

• Achievement
• Possibility for Growth
• Work Itself
• Personal Life
• Technical-Supervision Opportunity

Achievement

Software developers like to work. The best way to motivate developers is to provide an environment that makes it easy for them to focus on what they like doing most, which is developing software.

Ownership
Ownership—"buy-in"—is one key to achievement motivation. People will work harder to achieve their own goals than to achieve someone else's. Microsoft's Chris Peters points out that if you let developers create their own schedules, they take ownership of their schedules, and you get their buy-in.

 

Goal setting
Goal setting is another key to achievement motivation. Explicitly setting development-speed objectives is a simple, obvious step in achieving accelerated software development, and it's easy to overlook. Developers can't respond to objectives that change daily or that are collectively impossible to meet.

Possibility for Growth

One of the most exciting aspects of being a software developer is working in a field that is constantly changing. You have to learn something every day just to stay current, and half of what you need to know to do your job today will be out of date 3 years from now. Considering the nature of the industry developers have chosen to work in, it isn't surprising that they are motivated by possibilities for growth.

An organization can show interest in its developers' professional growth in any of these ways:
• By providing tuition reimbursement for professional-development classes
• By giving time off to attend classes or to study
• By providing reimbursement for purchase of professional books
• By assigning developers to projects that will expand their skill sets

Work Itself

Hackman and Oldham identified five dimensions of the work itself that contribute to these sources of motivation. The first three of these job characteristics contribute to how meaningful people find their work to be:

 

• Skill variety is the degree to which your work requires you to exercise a variety of skills so that you can avoid boredom and fatigue. People find meaning in jobs that offer variety, even in work that is not very significant or important in any absolute sense.
• Task identity is the degree to which your job requires you to complete a whole, identifiable piece of work. People care more about their work when they have a whole job to do and when they feel that their con- tribution matters.
• Task significance is the degree to which your work affects other people and contributes to social welfare. People need to feel that the final product has value. As Hackman and Oldham point out, people who tighten nuts on airplanes will feel that their work is more important and meaningful than people who tighten nuts on decorative

Personal Life

Achievement, possibility for growth, and work itself are in the top five motivators for both developers and managers (although they prioritize the factors differently).

Those factors present a significant opportunity for developers and managers to understand what makes the other tick. But personal life is fourth for developers, fifteenth for managers. Thus, the motivational impact of a developer's personal life is likely to be the hardest motivational factor for a manager to understand.

A close second is probably responsibility, which is ranked first for managers and tenth for developers. One upshot of this disparity is that managers sometimes reward their best developers by assigning them to their highest-profile, highest-pressure projects. To the manager, the extra responsibility would be a treat, and the diminished personal life wouldn't matter much.

Technical-Supervision Opportunity

Managers are less motivated by opportunity for technical supervision than are developers. The easiest way to understand this is to recognize the connection between technical-supervision opportunity and achievement.

For a developer, a technical-supervision opportunity represents an achievement. An opportunity to supervise technical work implies that the developer has achieved a level of technical expertise sufficient to direct others.

For a manager, a technical-supervision opportunity would probably represent a step backwards; the manager is already supervising others and is quite happy not to be supervising technical details. So it's really not surprising that developers are more motivated by technical-supervision opportunity than managers are.