Software is more than just a program code. A program is an executable code, which serves some computational purpose. Software is considered to be collection of executable programming code, associated libraries and documentations. Software, when made for a specific requirement is called software product. Engineering on the other hand, is all about developing products, using well-defined, scientific principles and methods.
Definitions IEEE defines software engineering as: (1) The application of a systematic,disciplined,quantifiable approach to the development,operation and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in the above statement. Fritz Bauer, a German computer scientist, defines software engineering as: Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and work efficiently on real machines.
Need of Software Engineering The need of software engineering arises because of higher rate of change in user requirements and environment on which the software is working.
Large software - It is easier to build a wall than to a house or building, likewise, as the size of software become large engineering has to step to give it a scientific process.
Scalability- If the software process were not based on scientific and engineering concepts, it would be easier to re-create new software than to scale an existing one.
Cost- As hardware industry has shown its skills and huge manufacturing has lower down he price of computer and electronic hardware. But the cost of software remains high if proper process is not adapted.
Dynamic Nature- The always growing and adapting nature of software hugely depends upon the environment in which user works. If the nature of software is always changing, new enhancements need to be done in the existing one. This is where software engineering plays a good role.
Quality Management- Better process of software development provides better and quality software product.
Characteristics of good software A software product can be judged by what it offers and how well it can be used. This software must satisfy on the following grounds:
Operational
Transitional
Maintenance
Well-engineered and crafted software is expected to have the following characteristics: Operational This tells us how well software works in operations. It can be measured on:
Budget
Usability
Efficiency
Correctness
Functionality
Dependability
Security
Safety
Transitional This aspect is important when the software is moved from one platform to another:
Portability
Interoperability
Reusability
Adaptability
Maintenance This aspect briefs about how well a software has the capabilities to maintain itself in the everchanging environment:
Modularity
Maintainability
Flexibility
Scalability
In short, Software engineering is a branch of computer science, which uses well-defined engineering concepts required to produce efficient, durable, scalable, in-budget and on-time software products.
SDLC SDLC stands for Software Development Life Cycle. SDLC is a process that consists of a series of planned activities to develop or alter the Software Products. Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality softwares. The SDLC aims to produce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.
SDLC is the acronym of Software Development Life Cycle.
It is also called as Software Development Process.
SDLC is a framework defining tasks performed at each step in the software development process.
ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software.
SDLC Models There are various software development life cycle models defined and designed which are followed during the software development process. These models are also referred as Software Development Process Models". Each process model follows a Series of steps unique to its type to ensure success in the process of software development. Following are the most important and popular SDLC models followed in the industry &miuns;
Waterfall Model
Iterative Model
Spiral Model
V-Model
Big Bang Model
Waterfall Model 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.
Waterfall Model - Design Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate phases. In this Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially. The following illustration is a representation of the different phases of the Waterfall Model.
The sequential phases in Waterfall model are −
Requirement Gathering and analysis − All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification document.
System Design − The requirement specifications from first phase are studied in this phase and the system design is prepared. This system design helps in specifying hardware and system requirements and helps in defining the overall system architecture.
Implementation − With inputs from the system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing.
Integration and Testing − All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.
Deployment of system − Once the functional and non-functional testing is done; the product is deployed in the customer environment or released into the market.
Maintenance − There are some issues which come up in the client environment. To fix those issues, patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.
Waterfall Model - Application Every software developed is different and requires a suitable SDLC approach to be followed based on the internal and external factors. Some situations where the use of Waterfall model is most appropriate are −
Requirements are very well documented, clear and fixed.
Product definition is stable.
Technology is understood and is not dynamic.
There are no ambiguous requirements.
Ample resources with required expertise are available to support the product.
The project is short.
Waterfall Model - Advantages
The advantages of waterfall development are that it allows for departmentalization and control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order. Some of the major advantages of the Waterfall Model are as follows −
Simple and easy to understand and use
Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
Phases are processed and completed one at a time.
Works well for smaller projects where requirements are very well understood.
Clearly defined stages.
Well understood milestones.
Easy to arrange tasks.
Process and results are well documented.
Waterfall Model - Disadvantages The disadvantage of waterfall development is that it does not allow much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-documented or thought upon in the concept stage. The major disadvantages of the Waterfall Model are as follows −
No working software is produced until late during the life cycle.
High amounts of risk and uncertainty.
Not a good model for complex and object-oriented projects.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model.
It is difficult to measure progress within stages.
Cannot accommodate changing requirements.
Adjusting scope during the life cycle can end a project.
Integration is done as a "big-bang. at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early.
Iterative Model - Design Iterative process starts with a simple implementation of a subset of the software requirements and iteratively enhances the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental). The following illustration is a representation of the Iterative and Incremental model −
Iterative Model - Application Like other SDLC models, Iterative and incremental development has some specific applications in the software industry. This model is most often used in the following scenarios −
Requirements of the complete system are clearly defined and understood.
Major requirements must be defined; however, some functionalities or requested enhancements may evolve with time.
There is a time to the market constraint.
A new technology is being used and is being learnt by the development team while working on the project.
Resources with needed skill sets are not available and are planned to be used on contract basis for specific iterations.
There are some high-risk features and goals which may change in the future.
The advantage of Iterative Model The advantage of this model is that there is a working model of the system at a very early stage of development, which makes it easier to find functional or design flaws. Finding issues at an early stage of development enables to take corrective measures in a limited budget. The disadvantage with this SDLC model is that it is applicable only to large and bulky software development projects. This is because it is hard to break a small software system into further small serviceable increments/modules. The advantages of the Iterative and Incremental SDLC Model are as follows −
Some working functionality can be developed quickly and early in the life cycle.
Results are obtained early and periodically.
Parallel development can be planned.
Progress can be measured.
Less costly to change the scope/requirements.
Testing and debugging during smaller iteration is easy.
Risks are identified and resolved during iteration; and each iteration is an easily managed milestone.
Easier to manage risk - High risk part is done first.
With every increment, operational product is delivered.
Issues, challenges and risks identified from each increment can be utilized/applied to the next increment.
Risk analysis is better.
It supports changing requirements.
Initial Operating time is less.
Better suited for large and mission-critical projects.
During the life cycle, software is produced early which facilitates customer evaluation and feedback.
The disadvantages of the Iterative and Incremental SDLC Model The disadvantages of the Iterative and Incremental SDLC Model are as follows −
More resources may be required.
Although cost of change is lesser, but it is not very suitable for changing requirements.
More management attention is required.
System architecture or design issues may arise because not all requirements are gathered in the beginning of the entire life cycle.
Defining increments may require definition of the complete system.
Not suitable for smaller projects.
Management complexity is more.
End of project may not be known which is a risk.
Highly skilled resources are required for risk analysis.
Projects progress is highly dependent upon the risk analysis phase.
The spiral model combines the idea of iterative development with the systematic, controlled aspects of the waterfall model. This Spiral model is a combination of iterative development process model and sequential linear development model i.e. the waterfall model with a very high emphasis on risk analysis. It allows incremental releases of the product or incremental refinement through each iteration around the spiral.
Spiral Model - Design The spiral model has four phases. A software project repeatedly passes through these phases in iterations called Spirals.
Each phase of Spiral Model is divided into four quadrants as shown in the above figure. The functions of these four quadrants are discussed below-
1. Objectives determination and identify alternative solutions: Requirements are gathered from the customers and the objectives are identified, elaborated and analyzed at the start of every phase. Then alternative solutions possible for the phase are proposed in this quadrant. 2. Identify and resolve Risks: During the second quadrant all the possible solutions are evaluated to select the best possible solution. Then the risks associated with that solution is identified and the risks are resolved using the best possible strategy. At the end of this quadrant, Prototype is built for the best possible solution. 3. Develop next version of the Product: During the third quadrant, the identified features are developed and verified through testing. At the end of the third quadrant, the next version of the software is available. 4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far developed version of the software. In the end, planning for the next phase is started.
Spiral Model Application The Spiral Model is widely used in the software industry as it is in sync with the natural development process of any product, i.e. learning with maturity which involves minimum risk for the customer as well as the development firms. The following pointers explain the typical uses of a Spiral Model −
When there is a budget constraint and risk evaluation is important.
For medium to high-risk projects.
Long-term project commitment because of potential changes to economic priorities as the requirements change with time.
Customer is not sure of their requirements which is usually the case.
Requirements are complex and need evaluation to get clarity.
New product line which should be released in phases to get enough customer feedback.
Significant changes are expected in the product during the development cycle. Spiral Model - Pros and Cons
The advantage of spiral lifecycle model is that it allows elements of the product to be added in, when they become available or known. This assures that there is no conflict with previous requirements and design. This method is consistent with approaches that have multiple software builds and releases which allows making an orderly transition to a maintenance activity. Another positive aspect of this method is that the spiral model forces an early user involvement in the system development effort. On the other side, it takes a very strict management to complete such products and there is a risk of running the spiral in an indefinite loop. So, the discipline of change and the extent of taking change requests is very important to develop and deploy the product successfully.
The advantages of the Spiral SDLC Model The advantages of the Spiral SDLC Model are as follows −
Changing requirements can be accommodated.
Allows extensive use of prototypes.
Requirements can be captured more accurately.
Users see the system early.
Development can be divided into smaller parts and the risky parts can be developed earlier which helps in better risk management.
The disadvantages of the Spiral SDLC Model The disadvantages of the Spiral SDLC Model are as follows −
Management is more complex.
End of the project may not be known early.
Not suitable for small or low risk projects and could be expensive for small projects.
Process is complex
Spiral may go on indefinitely.
Large number of intermediate stages requires excessive documentation.
Software Project Management The job pattern of an IT company engaged in software development can be seen split in two parts:
Software Creation
Software Project Management
A project is well-defined task, which is a collection of several operations done in order to achieve a goal (for example, software development and delivery).
Software Project A Software Project is the complete procedure of software development from requirement gathering to testing and maintenance, carried out according to the execution methodologies, in a specified period of time to achieve intended software product. Need of software project management
Software is said to be an intangible product. Software development is a kind of all new stream in world business and there’s very little experience in building software products. Most software products are tailor made to fit client’s requirements. The most important is that the underlying technology changes and advances so frequently and rapidly that experience of one product may not be applied to the other one. All such business and environmental constraints bring risk in software development hence it is essential to manage software projects efficiently.
The image above shows triple constraints for software projects. It is an essential part of software organization to deliver quality product, keeping the cost within client’s budget constrain and deliver the project as per scheduled. There are several factors, both internal and external, which may impact this triple constrain triangle. Any of three factor can severely impact the other two. Therefore, software project management is essential to incorporate user requirements along with budget and time constraints. Software Project Manager A software project manager is a person who undertakes the responsibility of executing the software project. Software project manager is thoroughly aware of all the phases of SDLC that the software would go through. Project manager may never directly involve in producing the end product but he controls and manages the activities involved in production. A project manager closely monitors the development process, prepares and executes various plans, arranges necessary and adequate resources, maintains communication among all team members in order to address issues of cost, budget, resources, time, quality and customer satisfaction. Let us see few responsibilities that a project manager shoulders Managing People
Act as project leader
Liaison with stakeholders
Managing human resources
Setting up reporting hierarchy etc. Managing Project
Defining and setting up project scope
Managing project management activities
Monitoring progress and performance
Risk analysis at every phase
Take necessary step to avoid or come out of problems
Act as project spokesperson Software Management Activities
Software project management comprises of a number of activities, which contains planning of project, deciding scope of software product, estimation of cost in various terms, scheduling of tasks and events, and resource management. Project management activities may include:
Project Planning
Scope Management
Project Estimation Project Scheduling
Project Scheduling in a project refers to roadmap of all activities to be done with specified order and within time slot allotted to each activity. Project managers tend to define various tasks, and project milestones and them arrange them keeping various factors in mind. They look for tasks lie in critical path in the schedule, which are necessary to complete in specific manner (because of task interdependency) and strictly within the time allocated. Arrangement of tasks which lies out of critical path are less likely to impact over all schedule of the project. For scheduling a project, it is necessary to
Break down the project tasks into smaller, manageable form
Find out various tasks and correlate them
Estimate time frame required for each task
Divide time into work-units
Assign adequate number of work-units for each task
Calculate total time required for the project from start to finish
Project Management Tools The risk and uncertainty rises multifold with respect to the size of the project, even when the project is developed according to set methodologies. There are tools available, which aid for effective project management. A few are described -
Gantt Chart Gantt charts was devised by Henry Gantt (1917). It represents project schedule with respect to time periods. It is a horizontal bar chart with bars representing activities and time scheduled for the project activities.
PERT Chart PERT (Program Evaluation & Review Technique) chart is a tool that depicts project as network diagram. It is capable of graphically representing main events of project in both parallel and consecutive way. Events, which occur
one after another, show dependency of the later event over the previous one.
Events are shown as numbered nodes. They are connected by labeled arrows depicting sequence of tasks in the project.
Resource Histogram This is a graphical tool that contains bar or chart representing number of resources (usually skilled staff) required over time for a project event (or phase). Resource Histogram is an effective tool for staff planning and coordination.
Critical Path Analysis This tools is useful in recognizing interdependent tasks in the project. It also helps to find out the shortest path or critical path to complete the project successfully. Like PERT diagram, each event is allotted a specific time frame. This tool shows dependency of event assuming an event can proceed to next only if the previous one is completed. The events are arranged according to their earliest possible start time. Path between start and end node is critical path which cannot be further reduced and all events require to be executed in same order.
PERT charts Program Evaluation Review Technique (PERT) charts show each task in a project as a node. Dependencies between tasks (e.g. where one task requires another one to be completed before it can start) are clearly shown by interconnections between the task nodes. PERT charts also show timing information for each task. PERT charts are similar to the critical path method (CPM) which identifies the longest path through the project, and therefore the minimum time for the project to be completed. Project managers can use PERT charts to: • set a realistic timetable for project completion • make sure focus is maintained on the most critical tasks for the critical path – since the path leads to the minimum time the project requires, any delays to these tasks will result in a delay to the overall project • identify tasks that need to be shortened if the overall project time needs to be reduced • identify tasks that can be carried out simultaneously • identify slack time where certain tasks are not as time-critical to the overall deadline.
GANTT charts GANTT charts display the tasks in a project as a box or line showing the calendar duration of the task on the horizontal axis (the horizontal length of the task box is proportional to the task duration). Tasks are normally arranged in date order on the vertical axis. The time relation of all tasks to each other (for example, tasks carried out simultaneously) is therefore clearly apparent in a GANTT chart. The project status can be easily determined at intermediate dates in the project, and progress of individual tasks can be shown by filling in the task boxes. Unlike PERT charts, GANTT charts do not show the critical path, however, dependencies between tasks can be indicated by lines linking tasks.
EX: The following table shows the tasks, dependencies, and estimated times a project manager might input to a basic GANTT chart for a software development project.
Task 1 has no predecessors, and can thus start on 12 June. The GANTT chart shows the task as a box starting on 12 June and finishing on 13 June on the horizontal access. Task 2 requires Task 1 to be completed, and the duration is three days, so the box covers the dates 14 to 16 June. The line from the finish of Task 1 to the start of Task 2 indicates the dependency. Note that Tasks 4, 5 and 8 all require Task 3 to be completed, and have no other dependencies, so these all start on the same date. The chart below show all seven days of the week, but often, weekend days are excluded.