Software development models

In 1984 Zave (1984, p. 104) defined “software development” as an effort to solve a problem with a computer system and spoke about the deficiencies of a con-ventional model in software development. Software development methodolo-gies offer a context for planning, executing, managing, and controlling the pro-cess of software system development. Ruparelia (2010, p. 8) lists multiple mod-els that are used from traditional and agile sides. Three of the listed modmod-els are Waterfall, Kanban and Scrum. This listing is continued by Ghilic-Micu, Mircea and Stoica (2013, pp. 72–73) and still further by Butler and Vijayasarathy (2016, pp. 86–89). Bassil (2012, p. 1) writes that all models have the same principle, they have steps or phases that must be completed to have results and produce a product. All methodologies that came up during the literature perusal are shown in

TABLE 2, agile practices are used as a foundation for the model that is pro-duced for the commissioner and some parts follow Scrum. That is why Agile principles and Scrum are described in more detail.

TABLE 2 Traditional and agile methodologies

Maciaszek (2007, p. 6) claims that most contemporary software development processes are consistently iterative and incremental. Babar, Liming, Ming and Verner (2004, p. 520) state that on the abstract level Waterfall and Agile are very different but their practices in the development cycle do share parallels. Hoss-ain and Moniruzzaman (2013, p. 5) confirm that traditional and agile methodol-ogies have different characteristics. They write that traditional development trusts in predictability, specificity and extensive planning. Agile development relies to small teams, continuous design improvements and feedback. Jain and Patel (2013, p. 1386) specify that in traditional methodologies the process in plan driven and the process is initiated with requirements elicitation and doc-umentation, after which architectural design and design development and in-spection follow.

Balaji and Murugaiyan (2012, p. 26) write that iterative and incremental development form a base for agile software development which is a group of software development methodologies where requirements and resolutions de-velop through cooperation amid self-organizing cross-functional teams. Cho (2008, p. 188) confirms this and adds that agile methods do emphasize iterative and incremental development and also focus on customer satisfaction, frequent and fast delivery including quicker adaptation on requirements changes.

Babar et al. (2004, p. 523) specify that customers support the development teams through the whole development process in agile models. In waterfall model the customer is typically involved during the requirements definition phase and sometimes during system or software design. They do not however contribute significantly and are not as involved as the customer is in agile mod-els.

Balaji and Murugaiyan (2012, pp. 28–29) define Agile as “moving quickly”, an adaptive team can respond to changing requirements swiftly and changes are welcomed. It has iterations instead of phases. Rapid delivery at short inter-vals and keeping the customer satisfied are the most important principles, these are achieved through continuous communication with the client and involving the client to the process.

Cho (2008, p. 191) tells that Scrum is an agile process that operates an em-pirical process control with three points in all its implementations; transparency, inspection and adaptation. Transparency implies that all facets of the process that influence the outcome must be kept evident. Inspection entails that the as-pects of the process are examined periodically to detect any undesirable vari-ances in the process. Adaptation means that if the inspection discovers any un-desirable aspects the process will be adjusted accordingly.

Ghilic-Micu et al. (2013, p. 74) write that Scrum is centered on two aspects:

team autonomy and adaptability. Scrum does not focus on implantation level practices but rather on how the members of a development team should co-operate to produce a flexible, adaptive, and productive system in a continually transforming environment. Cho (2008, pp. 191–192) concurs and adds that Scrum process consists of responsibilities, meetings and texts. How the work is divided and what roles do the team members have, how are the meeting orga-nized and when and ultimately, what text material does the process produce.

Next the traditional methodologies are represented. Those have also been collected to TABLE 2 and Waterfall is described in more detail because its prin-ciple forms the foundation for the model that is being produced. Ruparelia (2010, p. 8) remarks that Waterfall or a cascade model relies firmly on require-ments definition and analysis before development initiation Babar et al. (2004, p. 521) write that waterfall model is divided into five consecutive phases, each phase results in well-defined deliverables. Every phase requires the delivera-bles of a previous phase as an input so, no subsequent phase can commence before its predecessor has produced its deliverables and they have been signed.

Balaji and Murugaiyan (2012, p. 27) specify that Waterfall model has se-quential steps that must be completed before the next one can be initialized, there is no overlap between the phases and because it is a linear model it is easy to implement. Documentation and testing are conducted after every phase to maintain high quality of the project. Requirements are frozen from the very be-ginning of the project and changes are not considered; this means that require-ments are clear before development starts. Waterfall does not consider changes well, if a stakeholder changes their mind or a new need arises it will not be tak-en as a part of the currtak-ent developmtak-ent process.

Lauesen (2002, pp. 3–4) reminds that Waterfall model is an ideal, one pha-se is not always completed before the developer embarks onto the next one, something must be redone, iterative analysis, design and programming take place and then several phases are repeated more than once. Analysis, design and programming happen, but often these actions take place iteratively and concurrently. This in turn leads to altered requirements when missing, wrong and unrealistic requirements are spotted, this is where requirements manage-ment is needed. Cho (2008, p. 189) remarks that Waterfall model has drawbacks, it is inflexible and it is often not completed on-time or on-budget, rather it is often finished with less features and functions than intended and one third of the projects get cancelled altogether.

Babar et al. (2004, p. 525) argue that software quality cannot be compared realistically or reliably between waterfall model and agile methods because their initial development conditions are not equal particularly concerning to cost. Mitchell and Seaman (2009, p. 514) add that there is hardly any empirical evidence of one model’s superiority compared to other models. There are a lot of opinions and anecdotes but proof of advantages on one model over others in regards of quality, cost and duration are minimal. It is vital that the team or a company chooses the best suited method for a project, every method has its

drawbacks and advantages. Bhatia and Kumar (2014, p. 196) remark that tradi-tional and modern models are suited to different projects and the project type affects the choice; whether the project is critical or not so critical or are the re-quirements dynamic or are they stationary.

Software development processes need to consider a varying number of re-quirements that must be included in the process, depending on the product that is developed or the commissioner for which the product is meant. Some re-quirements are such that all the projects need to consider them. Some require-ments are so specific that only a product or two must take them into account.

Including information security into the process model of software development helps to enhance and maintain the high quality of the product.