1. Definitions
1.1. Software Development Life Cycle
THEORETICAL PART
In theoretical part of this diploma thesis are described steps in Software Development Life Cycle, Agile is explained together with Agile mindset (for better understanding), project management principles are also stated together with a definition of software testing. Reader will also learn about a company, their strategie, organizational structure and SWOT analysis.
Theoretical part was made for a purpose of better understanding of the problems, that will be described and solved in practical part.
1. Definitions
1.1. Software Development Life Cycle
The profession of “software developer” has existed since the first computers and their operators, as far back as the days of first calculation machines and vacuum tubes. Practices and methods for developing software have evolved over the decades since the invention of the computer.
Those methods have adapted to the state of the art in computer hardware, development tools, and modern thinking about the organizational management of software development teams. With this progress, new methods of software development have grown out of private and public software development efforts around the globe.
These methods vary widely, yet they have a common goal: to develop software as cheaply, efficiently and effectively as possible.
“Under “Software Development Life Cycle” we understand description of activities, where connection between them are clear and timeline is set. That means that SDLC has it’s beginning, clearly defined parts, hierarchical structure and end” (Doucek, 2010) (authors translation).
The entire SDLC process divided into the following stages:
12
Figure 1.1: Stages of Software Development Life Cycle Resources: (Lock, 2007)
• Phase 1: Requirements collection and analysis
This stage is conducted by the senior team members together with stakeholders (ideally also with domain experts from industry). During this phase high-level requirements are build, quality gates for QE department could be also established, risks are identified.
Requirement collection and analysis gives a clearer picture of the scope of the entire project and precise requirements.
• Phase 2: Feasibility study
Next step is to define and document software needs. Often during this phase “Software Requirement Specification” (SRS) is created, which includes everything that should be designed and developed during the project life cycle. There are mostly five types of feasibilities checks: economic, legal, operation feasibility, technical and schedule.
• Phase 3: Design
During this phase, the system and software design documents are prepared as per the requirement specification document and overall system architecture is defined. Most of the time, output of this phase are two documents: High-Level Design (HLD) and Low-Level Design (LLD).
HLD – each module has brief description, name, list of functionalities, interface relationship and dependencies. Databases and complete architecturure diagrams are also stated there.
LLD – contains functional login of each modules and in general provides more detailed description to each part, that was stated in HLD (including complete input/output of each module and error handling policies).
• Phase 4: Coding
Once the design is over, coding phase steps in. During this phase, developers start build the entire system by writing code using the chosen programming language and tools. Tasks are divided into units or modules and assigned to various teams or individual developers. Usually, it’s the longest phase of the Software Development Life Cycle.
• Phase 5: Testing
Once the software or it’s part is complete and deployed into the testing environment – testing team starts part of their work. Team verifies, that the entire application works according to the customer requirement. They may find bugs, defects, issues or unexpected behavior in the system. Those should Requirement
analysis Feasibility study Design Coding
Testing Install Deploy Maintenance
13
be reported into bug tracking tools. This process continues until the software meets the acceptance criteria.
Any project, either it was developed specifically for customer needs or was just a prototype, will go to the testing stage, says prof. Doucek (Doucek, 2010) (authors translation).
• Phase 6: Install Deploy
Once system meets acceptance criteria then final deployment process starts. Based on the feedback by the project manager, the final software is released and checked for deployment issues if any persists.
• Phase 7: Maintenance
During this phase customer start using the systems and most of the time, 3 following activities occur:
bug fixing (issues/incidents are reported to team by customers/QA); upgrade; enhancement (adding some new features).
There are many SDLC models out there, the most popular are:
• Waterfall
In context of this diploma thesis it is important to describe in details 2 the most commont approaches – Waterfall and Agile.
Waterfall
Waterfall – one of the types of Software Development Life Cycle, where project activities are divided into linear sequential phases, where each phase depends on the deliverables of the previous one.
As prof. Doucek (Doucek, 2010) (authors translation) describes, “old models of software development (like Waterfall, for example) are used also nowadays, but mostly for tactical and strategical development”.
Waterfall model was created due to market demand, when each information system project was specifically created for customer needs, says prof. Doucek (Doucek, 2010) (authors translation).
Waterfall steps are:
• requirement analysis – requirements are gathered together, analysed and organized into a defined scope;
• design – system/project is design according to requirements, which were gathered in a previous phase;
• implementation – project is being implemented (mostly takes around 30-40% of total time);
• verification/testing – developed project is being verified against the requirements;
• maintanence – project is being updated.
14
Figure 1.2: Waterfall (illustrative) Source: (UKEssays, 2018)
Waterfall is critised for delivering to clients something different, as was initially planned. The main reason is that requirements may not be clear enough at the beginning and designers/implementators could take their own approach during the design/implementation phase, which could lead to inconsistencies.
At the same time, Waterfall provides a structured approach to the project management or software development; phases are self-explanatory and easy to understand. Is perfectly suited for a projects where requirements and scope are fixed, product is firm and stable.
Agile
According to Castillo (Castillo, 2016), agile-scrum methodologies have become very fashionable of late. One of the original attractions of SCRUM methodologies is focusing on the output: delivering the application, rather than tasks devoted to the analysis and documentation. It also gives a lot of importance to teamwork and informal organization in producing these outputs.
15
Tab 1.1. Waterfall versus Agile-scrum methodologies (Castillo, 2016)
Waterfall methodology Agile-scrum
Has very distinct analysis and design, build, test phases
These phases exist, but not in sequential order as they are run iteratively within short, repetitive periods calles sprints
Requires detailed documentation of design to be done
Requires minimal documentation, in extreme cases, the code is the documentation
End-users are consulted for their requirements during the analysis phase
End-user representatives are an integral part of the project and are involved during the whole duration of the projects and regularly consulted
After the design is signed-off by the users, the build phase is conducted, which will adhere to the signed-off specifications
Build is an inherent and iterative process, users are presented with the result, from which they critique and modifications or new features are added Scope is clearly defined at the beginning of the
project
Scope is iteratively decided upon as the project progresses
Project teams can be large, composed of many different skillsets of people
Project teams are composed of 6-12 people maximum
Heterogeneous team with distinct, specialized skills per team member
Homogeneous team, tasks can be accomplished by any team member
At the start, we need to define what is Agile.
According to the ISTQB Glossary, Agile software development is: „A group of software development methodologies based on iterative incremental development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams“ (ISTQB Glossary, 2018).
Classical Agile is mainly about the mindset, not methodologies. It includes 4 following values (Manifesto for Agile Software Development, 2001):
„We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation
Responding to change over following a plan
16
That is, while there is value in the items on the right, we value the items on the left more“.
I want to explain some of those values more detailed:
Individuals and interactions over processes and tools: even so properly handled processes and right tools for a project are necessary. Agile states, that right communication channels are more important, than following processes.
Working software over comprehensive documentation: of course, nowadays main goal for each software development team is to make customer happy and Agile states to be the right mindset for it. Every customer wants to have the working software. But what if for your customer it’s more important to have complete documentation, than software with more functionalities? Could it be done in the Agile way without losing quality of documentation? We will discuss it more detailed in the late chapters.
One of the most important things, that during Agile transition (the ongoing process of changing development processes from Waterfall/whatever into Agile) it shouldn’t become “the dark Agile Manifesto” (Janes, 2012):
“We are uncovering better the only ways of developing software by doing it and helping teaching others do it.
Through this work we have come to value:
Individuals and interactions over and not processes and tools Working software over and not comprehensive documentation Customer collaboration over and not contract negotiation
Responding to change over and not following a plan That is, while since there is no value in the items on
the right, we value only the items on the left more.”
No one in organization or team should forget, that Agile is mostly about finding the right balance, not about creating totally different way of software development. That’s why Agile transition should start always from the right analysis, during which organization should establish goals, which they want to achieve, ways of implementation, measurements and a lot more.
Also, Agile Manifesto follows next principles (Manifesto for Agile Software Development, 2001) and I would like to add some comments to them:
„Our highest priority is to satisfy the customer through early and continuous delivery of valuable software“
(Manifesto for Agile Software Development, 2001) – the whole team should work with that principle in mind, but shouldn’t also forget about the best way of delivering those value. What I mean is, that no one should forget about maintenance of those changes and their impact on the whole system.
„Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage“ (Manifesto for Agile Software Development, 2001) – of course, changes in the name of competitive advantage is important, but there is a water line for some people from business between the late changes for competitive advantage and the unnecessary changes. Sometimes it’s really hard to find that border.
17
„Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale“ (Manifesto for Agile Software Development, 2001) – not all the time shorter timescale means more value to the customer. For example, in big corporations, frequent delivery means delivery in the smaller parts, which need to be then integrated with other pieces of the whole eco-system, and sometimes all of the parts are not ready to be integrated and deployed.
„Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done“ (Manifesto for Agile Software Development, 2001) – but we shouldn’t forget about controls, measurement and KPI’s.
„The most efficient and effective method of conveying information to and within a development team is face-to-face conversation“ (Manifesto for Agile Software Development, 2001) – in a real world, not all of the people are communicative (introverts, for example), so their performance numbers could say more or add some understanding to their words.
„Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely“ (Manifesto for Agile Software Development, 2001) – of course, during Agile software development in ideal there should be sustainable development, but a properly handled Waterfall could achieve that goal too.
Not the last think in Agile is the right mindset. According to Peter Measey (Measey, 2015), Agile mindset should look like that:
Figure 1.3: Agile mindset Resource: (Measey, 2015)
18
In my opinion, the main goal of Agile is to change the way of thinking from traditional to Agile and it’s the hardest think. Good comparison of those two mindsets (Measey, 2015):
Figure 1.4: Fixed mindset against Agile mindset Resource: (Measey, 2015)
With correct analysis, clear understanding of purposes and goals and piece-by-piece changing of the way of thinking to “be more agile” team should achieve better results, but not must.