• 1.1 What is Software Engineering?
• 1.2 Phases in the Development of Software
• 1.3 Waterfall SDLC Model
• 1.4 Incremental SDLC Model
• 1.5 Iterative SDLC model
• 1.6 RAD SDLC model
• 1.7 Agile SDLC model
• 1.8 Spiral SDLC model

1.1 What is Software Engineering?

This is the first question that needs answer in our course. But at the beginning we should to get definition of software and its distinction of program.

The term program means a combination of computer instructions and data definitions that enable computer hardware to peform computational or control functions. In present the term program - in the sense of a self-contained piece of software that can be invoked by a user or some other system component - is not adequate. Present-day software development projects result in systems containing a large number of (interrelated) programs or components. There is a distinction between programming-in-the-large and programming-in-the-small. The borderline between large and small obviously is not sharp: a program of 100 lines is small, a program of 100 000 lines of code certainly is not. Programming-in-the-small generally refers to programs written by one person in a relatively short period of time. Programming-in-the-large refers to multi-person jobs that span several months.

According to ISO Std 2382-1:1993 Software are all or part of the programs, procedures, rules, and associated documentation of an information processing system. In IEEE Standard for Software and System Test Documentation (IEEE Std 829:2008) Software - computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system. Thus software includes programs, documentation, data, and execution control statements.

So Software engineering (SE) is a complex process and is not the same as programming. Programming is an important part of software engineering.

The definition given in the ISO Std 2382-1:1993 is as follows: Software engineering is the systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software.

Standard Glossary of Software Engineering Terminology (IEEE610) tell that Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

1.2 Phases in the Development of Software

Software development (SD) process is the process by which user needs are translated into a software product. Software development projects are often large and particularly difficult to measure. A number of people work on such a project for a long time and therefore the whole process needs to be carefully planned and controlled: progress needs to be monitored, people and resources need to be allocated at the right point in time, etc.

Each software passes through several mandatory phases (fig.1.1):

• Requirement analysis - a systematic investigation of user requirements to arrive at a definition of software system.

• Design – process during of which definitions for architecture, software components, interfaces, and data are created, documented, and verified to satisfy requirements

• Implementation ( construction /coding) - process during which a software product is created from design documentation and debugged

• Testing - the dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain, against the expected behavior.

• Maintenance - the effort to keep an application performing according to its specifications or the process of modifying a software system after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment

 

Figure 1.1 - Basic phases of software development process

In order to control progress we use a phased development in which a number of clearly identifiable milestones are established between the start and finish of the project.

In general, the milestones identified in a software development project correspond to the points in time at which certain documents become available:

• after requirements engineering, there is a requirements specification;
• after the design phase there is a (technical) specification of the system;
• after implementation there is a set of programs;
• after testing has been completed there is a test report.

Traditional models for the phased development of software are, to a large extent, ‘document-driven’. The pile of paper that is produced in the course of the project guides the development process. The development process is seen as a series of transformations. It starts with a clear requirements document, and ends with running code.

There are different software development approaches which are used during software development process, these approaches are referred as Software Development Life Cycle Models or Software Development Process Models - SDLC Models (e.g. waterfall model, incremental model, V-model, iterative model, RAD model, Agile model, Spiral model, Prototype model etc.). Each process model follows a particular life cycle in order to ensure success in process of software development.

According to Standard ISO/IEC 12207 Life Cycle (LC) is an evolution of a system, product, service, project or other human-made entity from conception through retirement.

Life cycle model is a framework of processes and activities concerned with the life cycle that may be organized into stages, which also acts as a common reference for communication and understanding.

Life cycle process is a set of interrelated activities that result in the development or assessment of software products (IEEE Std 1012). These activities may overlap or be performed iteratively.

1.3 Waterfall SDLC Model

The first introduced Process Model was Waterfall Model. It is also referred to as a linear-sequential life cycle model. As you can see from figure 1.2, the software development phases have been made a sequence.

Figure 1.2 – Waterfall model of software development process

It is very simple to understand. In this model software testing starts only after the development is complete. In waterfall model phases do not overlap. In a waterfall model, each phase must be completed fully before the next phase can started. This type of SDLC model is basically used for the small project with no uncertain requirements.

Pros:

• This model is simple and easy to use.
• It is easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
• In this model phases are processed and completed one at a time. Phases do not overlap.
• Waterfall model works well for smaller projects where requirements are very well known, clear and fixed.

Cons:

• No working software is produced until late stage of the life cycle.
• Poor model for long, complex and object-oriented projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing.
• High amounts of risk and uncertainty.

 

1.4 Incremental SDLC Model

In practice, one often uses more sophisticated process models. For a real project activities usually will overlap.

The definition of designed system is broken down and functionality of the system is produced and delivered to the customer in a number of steps – increments. Incremental Model is shown in fig.1.3. In each of these steps, the phased approach that we know from the waterfall model, is employed. Incremental development process lets software to grow. With this incremental approach, the user is closely involved in planning the next step.

Figure 1.3 – Incremental model of software development process

This model can be implemented when the requirements of the whole system are clearly defined and easy understood. Also incremental model is used when there is a need to get a product to the market early or a new technology is being used or resources with needed skill set are not available. Major requirements must be defined; however, some details can evolve with time.

Pros:

• Elaborate working software quickly during the software life cycle.
• The model is more flexible - less cost of change scope and requirements.
• It is easier to test and debug in a smaller iteration.
• Customer can respond to each built.
• Delivery cost is lower.
• Easier to manage risk because risky pieces are identified and handled during iteration.

Cons:

• Needs a clear and complete definition of the complete system before it can be built incrementally.
• Needs good planning and design.
• Total cost is higher than waterfall.

1.5 Iterative SDLC model

When the project is big and the requirements of the complete system are clearly defined one can implement the Iterative Model (fig.1.4).

Figure 1.4 – Iterative model of software development process

Development begins by specifying and elaborating just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model. Changing requirements and errors discovered occur backtracking to earlier phases of software lifecycle. One had better think of these phases as a series of workflows. Early on, most resources are spent on the requirements engineering workflow. Later on, effort moves to the implementation and testing workflows.

In this model in early iterations a high-level design of the application can be created before the product actually begin to build. Later on a skeleton version of software can be designed and built, and then the design based on what had been built.

Pros:

• The software product is built and improved step by step. Hence, defects can be tracked at early stages.
• The reliable user feedback can be achieved. When presenting sketches of the product to users for their feedback, they can effectively imagine how the product will work.
• Less time is spent on documenting and more time is given for designing.

Cons:

• Each phase of an iteration is rigid with no overlaps
• Costly system architecture or design issues may arise because not all requirements are gathered up front for the entire lifecycle

 

1.6 RAD SDLC model

Rapid Application Development (RAD) Model is a type of incremental model. In RAD model the components or functions are developed in parallel as if they were mini projects. The developments are time boxed, delivered and then assembled into a working prototype. This can quickly give the customer something to use and to provide feedback regarding the delivery and requirements.

RAD SDLC model should be chosen only if resources with high business knowledge are available and there is a need to produce the system in a short period of time (2-3 months). Also it should be used if there’s high availability of designers for modeling and the budget is high enough to afford their cost along with the cost of automated code generating tools.

Figure 1.5 – RAD-model of software development process

The phases in the rapid application development (RAD) model are:

• Business modeling - an information flow is identified between various business functions.
• Data modeling - information collected from an earlier stage is used to identify the data objects required for business functions.
• Process modeling - data objects defined in previous step are converted to achieve the business information flow to achieve some specific business objective. Description are identified and created for CRUD (Create-Read-Update-Delete) of data objects.
• Application generation - automated tools are used to convert process models into code and the whole system.
• Testing and turnover - test new components and all the interfaces.

Pros:

• Reduced developer’s risks and efforts during projects.
• Quick customer feedback.
• Increases reusability of components.
• Integration at initial stages solves a lot of integration problems.

Cons:

• Only system that can be modularized can be built using RAD.
• Requires a strong team and depends on individual performances for identifying business requirements.
• Needs highly skilled developers in modeling and high qualified designers.
• Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.

 

1.7 Agile SDLC model

Agile Development Model is also a type of Incremental model. Software is developed in rapid cycles. This results in small incremental releases with each release building on previous functionality. Each release is well tested to ensure software quality is maintained. It is used for time critical applications.

One of the most known agile software development methodologies is Extreme Programming (XP).

Figure 1.6 – Agile model of software development process

Pros:

• Rapid (weeks rather than months), continuous delivery of working software is satisfied customer.
• People and cooperation are emphasized rather than process and tools (Customers, developers and testers constantly interact with each other).
• Face-to-face conversation is the best form of communication.
• Continuous attention to technical excellence and good design.
• Regular adaptation to changing circumstances.
• Even late changes in requirements are allowed.

Cons:

• There is lack of emphasis on necessity of design and documenting.
• In case of complex, usually large software applications, it is difficult to evaluate the effort required at the beginning of the SDLC.
• Only senior programmers are capable to make decisions required during the development process. So it has no place for newbie programmers, unless combined with experienced developers.

 

1.8 Spiral SDLC model

The Spiral Model is similar to the incremental model, with emphasis on risk analysis. Each spiral has four phases: Planning, Risk Analysis, Engineering and Evaluation.

• Planning Phase - Requirements are collected during this phase .
• Risk Analysis - a process is undertaken to identify risk and alternate solutions. At the end of this phase prototype is produced. If any risk is found during the risk analysis then alternate solutions are suggested and implemented.
• Engineering Phase - software is developed, along with testing at the end of the phase.
• Evaluation phase - a phase in which the customer should evaluate the output of the project to date before the project continues to the next spiral.

A software project repeatedly passes through these phases in iterations. Boehm (1988) suggests a spiral model of the software development process, in which each convolution of the spiral gives rise to the following activities:

• identify the sub-problem which has the highest associated risk;
• find a solution for that problem.

The baseline spiral, starting in the planning phase, requirements are accumulated and risk is assessed. Each subsequent spirals builds on the baseline spiral (fig.1.7). 

Figure 1.7 – Spiral model of software development process

The various process models discussed before can be coupled with Boehm’s spiral model in a natural way:

• If obtaining the proper set of user requirements is seen as the area with highest risk, follow the spiral a few times around to solve this sub-problem (i.e., prototype).
• If, starting from a precise requirements specification, the main question is to obtain a robust and well-documented system, follow the spiral once, using the traditional process model with its phases and corresponding milestones as intermediate steps.
• If developing software incrementally, track the spiral a number of times, once for each increment.
• During maintenance, the reported errors or changing requirements are triggers to track the spiral.

Viewed this way, the spiral model subsumes the other process models discussed before. 

Spiral model should be used:

• For medium to high-risk projects when costs and risk evaluation is important.
• Requirements are complex.
• When users are unsure of their needs and significant changes are expected.
• Project potentially can change to economic priorities.

Pros:

• Good for large and mission-critical projects.
• High amount of risk analysis let to avoid of potential risks.
• Strong documentation control.
• Additional functionality can be added at a later spirals.
• Software is delivered early in the software life cycle.

Cons:

• Can be an expensive model to use.
• Risk analysis requires highly specific expertise.
• Project’s success is strongly dependent on the risk analysis phase.
• Doesn’t work well for small projects.

The software development models are the various methodologies that are being selected for the software development project depending on it’s goals. There are many SDLC-models that have been developed in order to achieve different required objectives. The models specify the various stages of the process and the order in which they are carried out.

The selection of model has very high impact on the analysis, testing and documentation that is carried out. SDLC-model define the what technique, tools and resources, where and when in development process will be use.