Software Engineering and Information Systems ModellingMousumi Modak Research Scholar VGSOM IIT Kharagpur

INTRODUCTIONIt was 1950s, from when the computers have been used commercially. Previously computers were characterized by high computational time, less sophisticated programming and rendered high cost. However due to the technological advancements and customer demand more and more improved technologies came into existence which as a result increased the computational power, enhanced the capability to handle more complex problems and reduced the prices dramatically. Thus with the advent of the technological breakthrough there was an emergence of more sophisticated programs to be developed and compile on such devices. As it can be said that the more powerful the computer is the more sophisticated program it can run. So as the computers were distinctly moved on, the software engineers were forced to develop and solve much complex problems and also in a cost-effective way. Since then software engineers are dedicated to innovate and solve complex problem while writing complex programs. Thus developing, the software engineers gathered lots of experiences and came across various milestones in developing such programs. Further this knowledge, intuition and notion formed the foundation of the software engineering principles. Therefore software engineering discipline can be concluded as a methodology and costeffective approach towards software development. Like other engineering discipline, software engineering is the art and skill to design software.

DEFINITION Software Engineering (SE) is a discipline dedicated to designing, implementing, and modifying software so that it is of high quality, affordable, maintainable, and fast to build. It is a "systematic approach to the analysis, design, assessment, implementation, test, maintenance and reengineering of software, that is, the application of engineering to software." The term software engineering first appeared in the 1968 NATO Software Engineering Conference, and was meant to provoke thought regarding the perceived "software crisis" at the time.

WHAT IS SOFTWARE CRISIS?1. The huge expenses that the organisations around the world are incurring to purchase

software packages to that compared to hardware products. The price ratio of hardware to software products has reduced dramatically. Given below in Fig 1, the revolutionized relative cost of hardware and software over years.

Figure 1: Change in the relative cost of hardware and software over time2. Often customer/clients faces inconvenience using software products such as i. ii. iii. iv. v. vi. Software costs more to maintain than it does to develop. Software products are difficult to alter and debug Often fail to cater the needs of the customer Far from being reliable Frequent conflict Delivered late

EMERGENCE OF SOFTWARE ENGINEERINGI. Assembly language Programming i. ii.iii.

Limited programming length Individualistic way of programming Often known as exploratory programming style

II.

High Level Language programming i. ii. iii. Large programmes can be developed More complex problem can be solved High level language like FORTRAN, ALGOL and COBOL were introduced

III.

Control Flow-Based Designi.

Indicates the sequence in which the programs instructions are executed Flow-charting technique was developed Messy control flow chart structures-problem to locate and debug Restricted only to two commands-GOTO and JUMP called as unstructured program Three new program constructs were developed a. Sequencing (ex. if then-else)b. Selection (ex. do-while) called as structured program.

ii. iii.iv.

v.

Example- PASCAL, MODULA, C IV. Data Structured Oriented Designi.

Attention was paid on the design of data structures Derives programs structure from its data structure using notation for sequence, selection and iteration. Ex-Warnier-Orr

ii.

V.

Data Flow Oriented Design i. Use of data flow diagram

ii. VI.

Detailed explanation of execution of the program

Object-Oriented Design i. ii. iii. iv. v.vi.

Use of data abstraction and data hiding Simplicity Code and design reuse Lower development time Lower development cost Easier maintenance

THE SOFTWARE DEVELOPMENT LIFECYCLEA software life cycle is the series of identifiable stages that a software product undergoes during its lifetime or it can be said that a software life cycle model is a descriptive and diagrammatic representation of the software life cycle.

Why use a Life cycle model? i. It promotes development of software in a systematic and disciplined way.ii. When a software product is developed by a team it is necessary to have integration

among the members. The two different aspects of life cycle model A. Documentation of Life Cycle Model a. Documentation of the life cycle model is one of the most important features. Documentation is done to avoid misinterpretation and helps to identify inconsistency, redundancies and omission in the development process. b. As the development of the life cycle model is a team work, documentation helps each of the team members to understand each ones contribution to the process. B. Phase Entry and Exit Criteria a. A life cycle model should have definite entry and exit criteria for each phase b. A phase can only begin only when the corresponding phase-entry criteria are satisfied

Several life cycle models have been developed. Some of the most popularly used models are discussed further.

CLASSICAL WATERFALL MODEL1. The theoretical way of developing software 2. The most primitive model 3. All other life cycle models are derived from this modelFeasibility study Requirement analysis and specification Design Coding and unit testing Integration and system testing Maintenance

Figure 2: Classical Waterfall ModelFeasibility Studya. The main aim of the feasibility study activity is to determine whether it would be

financially and technically feasible to develop the product. b. This study involves the analysis of the problem and collection of the relevant information such as different data items, which would be the input to the system, the processing to be carried out on these data, the output data required produced by the system and the difficulties faced on the performance of the system. c. It can be said that it is an abstract problem definition or rough sketch of the problem which considers only the important requirement. d. Formulation of the different solution strategiese. Analysis of alternative solution and strategies to compare their benefits and

shortcomings.f. This analysis usually requires making approximate estimates of the resources

required, cost of the development and the development time.

Requirement analysis and specification The prime concern of the Requirement analysis and specification phase is to exactly understand the customer requirements and then document them properly it is divided into two phases they are requirement gathering and analysis and the other as requirement specification. They are discussed individually. a. Requirement gathering and analysis The aim of this activity is to collect all relevant information from the customer regarding the development of the product with a view to clearly understand the customer requirements and conclude the inconsistencies to these requirements. The requirements analysis activity is begun by collecting all relevant data regarding the product to be developed from the users of the product and from the customer through interviews and discussion. During this phase the requirements are written is Software Requirement Specification (SRS) document. b. Requirement Specification This phase consists of functional requirements and the non-functional requirements and the goals of implementation. The functional requirements involve the functions that will support the system. Each function is characterized by the input data, the processing required on the input data and the output data to be produced and the non-functional requirements identify the performances requirements, the required standard to be followed etc. As the SRS document is written using end-user terminology it becomes easier to the customer/client to understand. Thereafter this document is reviewed and approved by the customer. This acts as a contract between the development team and the customer. Any future dispute between the customer and the development team can be settled by examining the SRS document. The SRS document provides not only the basis for the carrying out the development activities but also the basis for several other documents such as design document, the users manual and the systems test plan etc. The SRS document produced at the end of this phase is called the black-box specification of the problem, since in this document the system is considered as a black box whose external behaviour is only specified

and the internal details are not known. It can be said that requirement analysis and specification phase concentrates on what needs to be done and avoids that how to be done.

DesignThe goal of the design phase is to transform the requirements specified in the SRS document into a structure that is suitable for implementation in some programming language. The two distinct approaches are available; they are traditional design approach and object-oriented design approach.

a. Traditional design approachIn the traditional design approach the functional requirements specified in the SRS document are decomposed into sub functions and the data flow among these sub functions is analyzed and presented diagrammatically in the form of DFDs.

b. Object-oriented design approachIn this technique, various objects that occur in the problem domain and the solution domain are first identified and the different relations that exist among these objects are identified.

Coding and unit testingThe purpose of the coding and unit testing phase of the software development is to translate the software design into source code. The end-product of this phase is a set of program modules that have been individually tested. During this phase, each module is unit tested to determine the correct working of all the individual modules.

Integration and System testingIntegration of different modules is only done when they have been coded and unit tested. Integration of the different modules is done in this stage but step by step. System testing ensures that the developed system conforms to its requirements laid in the SRS document. System testing consists of three types of testing activities they are

testing: it is the system testing performed by the development team. - testing: it is the system testing performance by a friendly set of customers. Acceptance testing- it is the system testing performed by the customer himself after the product delivery to determine whether to accept or reject the delivery product.

MaintenanceMaintenance involves performing any one or all three following activities. i. Correcting errors-are those that were not discovered during the development phaseii. Perfective maintenance- improving the implementation of the system and enhance

functionalities of the systemiii. Adaptive maintenance- porting the software to work in a new environment.

SPIRAL MODEL

The diagrammatic representation of this model appears like a spiral with many loops. Each loop of the spiral represents a phase of the software process. The model is much more flexible compared to other models, since the exact number through which the product is developed is not fixed. Each phase in this model is split into four sectors (or quadrants). The phases may vary from project to project. The first quadrant identifies the objectives of the phase and to find the alternative solution. Likewise the second quadrant identifies the alternative solutions and evaluates the best solution possible. For the chosen solution, the potential risks are identified. The spiral model provides direct support for coping the project risk by building the prototype. The third quadrant develops the next level of the product. Finally the fourth quadrant emphasises reviewing the results traversed so far with the customer and planning the next iteration around the spiral. Thus beginning from the centre to outward a complete version of the software gets developed. The radius of the spiral at any point represents the cost incurred in the project and the angular dimension represents the progress made in the current phase. Actually in this type of model a prototype is developed and during each iteration, risk analysis through the prototype is handled. So this spiral can also be called as a meta-model.

Determine objectives alternatives and constraints

Risk analysis Risk analysis Risk analysis

Evaluate alternatives identify, resolve risks

REVIEW Requirements plan Life-cycle plan

Risk analysis Prototype 1 Concept of Operation

Prototype 3 Prototype 2

Operational protoype

Simulations, models, benchmarks S/W requirements Product design

Development plan Integration and test plan

Plan next phase

Code Unit test Design V&V Integr ation test Acceptance test Develop, verify Service next-level product

Requirement validation

Detailed design

Figure 3: The Spiral Model

EVOLUTIONARY MODELThis life cycle model is also known as the successive version model and also called incremental model. In this life cycle model the software is broken down into several functional units which can also be called as modules. During the software development this modules are incrementally constructed and delivered. The development team first develops the core module and then add more functionalities as per the requirement in the successive version. This model has several advantages. This model gives a chance to experiment with partially developed software much before the software is fully developed. Therefore the evolutionary model helps to change the requests as and when required so that the errors after delivery are minimised. This model is mostly useful when the customer prefers to receive the product in increments so as to start using the different features as and when they are developed, rather than receiving the full product to be developed and delivered.

A

A A B B C

Figure 4: Evolutionary development of a software product A, B, C are modules of the software product that are incrementally developed and delivered

Rough requirement specification

Identify the core and other parts to be developed incrementally

Develop the core part using an iterative waterfall model

Collect customer feedback and modify requirements

Develop the next identifiable features using iterative waterfall

Maintenance

Figure 5: Evolutionary model of software development

ITERATIVE WATERFALL MODEL

In practicing the classical waterfall model various shortcomings come into existence. Theses adequacies are due to oversight, wrong assumption, use of inappropriate technology, communication gap among the project engineers and many more. So it is not possible to strictly follow the classical waterfall model in developing the required software. Feedbacks are always needed from every phase to its preceding phase to allow for the correctness of these errors committed during a phase that are detected in later phase. The principle of detecting errors as close to their points of introduction as possible is known as phase containment of errors. This can be only achieved by reviewing each and every step of the model. Unlikely best effort is made to detect errors in the same phase in which they are committed though some errors get escape and are found in the later phase of the development. This requires rework to be done of the already completed phase. Instead of the development there should be proper documentation of the whole process as how the model has been developed.Feasibility study Requirement analysis and specification Design Coding and unit testing Integration and system testing Maintenance

Figure 6: Iterative Waterfall Model

LITERATURE SURVEY

This section is a 20th and 21st century view of software engineering. This section elucidates and discusses on the types and generations of software engineering. This survey can be thought of a journey as how the software engineering discipline came into existence and moreover the incremental developments that came into existence with this discipline as the decades passed on. According to the author this study is based on hypothesis. The simple hypothesis that the author assigned is that the people or the customer dont like to see software engineering done unsuccessfully, and try to make things better.

1950s Thesis: Software Engineering is Like Hardware Engineering During 1955 the concept that prevailed was Engineering software like engineer hardware. There were only hardware engineers or a mathematician to be found. The hardware that was used on those days and also used by the author was GD ERA 1103 which filled a large room. The various operations that were practiced in those days were desk checking, buddy checking and manually executing the programs before running them. The information processing project that was developed in that era was software for Semi-Automated Ground Environment (SAGE). Figure 7 shows the software development process developed by the hardware engineers for the use of SAGE. It shows the sequential waterfall model for the development of the software. Thousands of programmers participated in the development process which included an assembler, a library and build management system, a number of utility programs and aids to testing and debugging. This SAGE system successfully met its specification at about one year.

Figure 7: The SAGE software Development Process (1956)

1960s Antithesis: Software CraftingIn this era researchers found software engineering to be different to that of hardware engineering. At first software was much easier to modify than that of software as it did not require expensive production lines to make product copies. One change in the program was much easier to change than individually making change in every configuration of the hardware. This ease of modification led to adopt a code and fix approach. Another advantage of software was that software did not wear out. Software maintenance was different to that of hardware development. Another approach of the software development was the surpass demand of software development. Various non-engineers were hired for the

development of such softwares. The developers were comfortable using code and fix approach but their fixes often led to heavily patched spaghetti code. Much better infrastructure was used. As like powerful mainframe operating systems and high-order languages such as FORTRAN and COBOL was extensively used. This was the era of the beginning for profit software development and product companies. This situation led to the NATO Science Committee to declare a conference on Software Engineering in 1968, 1969. These conferences provided a strong baseline of understanding of the software engineering state of practice so as to develop software products.

1970s Synthesis and antithesis: Formality and Waterfall Process

Figure 8: Software Engineering Trends Through the 1970s

The movement shown in the figure has two primary branches. One is the formal methods branch that focused on program correctness and the other branch a less formal approach or

can be said as top-down structured programming. The concept of structured programming was hence developed and applied to software designing. Waterfall Model was extensively used where one phase did not start until the previous phase was completed.

Figure 9: The Royce Waterfall Model (1970)

1980s Synthesis: Productivity and ScalabilityIn 1980, initiatives were taken to address the problems of the 1970s. The development of software engineering productivity and scalability was gaining importance in this era. Distribution of efforts and defects by phase and activity enabled better prioritization of improvement areas. The cost drivers in estimation models identified management controllable that could reduce cost through investment in better staffing training, processes, methods, tools, and asset reuse. CMU Software Engineering Institute has developed a software capability maturity model (SW-CMM) and was associated with the software maturity of the organizations. Based extensively on IBMs, the SW-CMM provided highly effective framework for both capability assessment and improvement. SW-CMM was largely method dependent although it followed the sequential waterfall model. The, International Standards Organization, ISO-9001 standard was developed for quality practices applicable to

software. Deploying SW-CMM and ISO-9001mostly there were good returns on investment and reduced software rework. These resulted in developing more and more maturity models. Software tools- beside the requirement and design tools discussed there were various software tools that were developed. Those tools are path and test coverage analyzers, automated test case generators, unit test tools, test traceability tools, test data analysis tools etc. Software processes-in this era improved software processes contributed to significant increase in productivity by reducing rework. Both revolutionary and evolutionary approaches to avoid rework came into existence. In 1980 another potential productivity improvement approaches such as expert systems, very high level languages, object orientation, powerful workstation and visual programming. The essential task involved in this phase were the four major challenges for productivity solutions they are high levels of software complexity, conformity, changeability and invisibility.

1990s Antithesis: Concurrent vs. Sequential processIn 1990 there was an emergence of object-oriented methods. Object-oriented methods were to develop software design patters, software architecture and architecture description language and hence UML came into existence. With the emergence of Internet and World wide web object-oriented programming was extensively used. Due to the growing competition in the software development there was a need to reduce software time-to-market, which caused a major shift from the classical waterfall model to models emphasizing concurrent engineering of requirements, design and code of product and processes and software and systems. Beside time-to market, another factor caused organizations to depart from waterfall model was the use of user-interactive products. Another field of research that was considered in this time phase was to support concurrent engineering. With the projects risk it was also to determine the influence of concurrent engineering.

2000s Antithesis and partial Synthesis: Agility and ValueDuring 2000s a continuation of the trend toward rapid application development, and an acceleration of the pace of change in information technology (Google, Web-based collaboration support), in organizations (mergers, acquisitions, start ups), in competitive

countermeasures (corporate judo, national security), and in the environment (globalization, consumer demand patterns) was vivid.

Agile Methods During early 2000 there was an emergence of a number of agile methods such as Adaptive Software Development, Crystal, Dynamic Systems Development, extreme Programming (XP), Feature Driven Development, and Scrum. The four of its characteristics are as follows Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation Responding to change over following a plan. Value-Based Software Engineering Agile methods emphasised on usability improvement via short increments and valueprioritized increment content which are also responsive to trends in software customer preferences.

A View of the 2010s and beyondB. Boehm (2006) in his one of the research paper identified eight surprise-tree trends and two wild-card trends that would strongly influence future software and systems engineering directions. Five of the eight surprise-tree trends were, rapid change and the need for agility; increased emphasis on usability and value; software criticality and the need for dependability; increasing needs for COTS (Commercial-off-the-shelf), reuse, and legacy software integration; and the increasing integration of software and systems engineering. Two of the eight surprise-tree trends are assumed to be covered in next 2010, those are global connectivity and massive systems of systems. Surprise-free computational plenty and the two wild-card trends (increasing software autonomy and combinations of biology and computing)

will be covered under 2020 and beyond. Figure 10 shows the extension of the timeline through which the software development addresses its journey.

Figure 10: A full timeline of the software Engineering trends

THE RATIONAL UNIFIED PROCESSThe Rational Unified Process (RUP) is an iterative software process product, originally developed by Rational Software, which was acquired by IBM in February 2003. RUP is a specific implementation of the Unified Process. Rational Unified Process (RUP) is an object-oriented and Web-enabled program development methodology. RUP is like an online mentor that provides guidelines, templates, and examples for all aspects and stages of program development.

The Rational Unified Process is a project Life cycle consisting of four phasesInception Phase Elaboration Phase Construction Phase Transition Phase

Inception Phase The primary objective is to validate initial costing and budgets. In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc.), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements) are generated.

Elaboration Phase The primary objective is to mitigate the key risk items identified by analysis up to the end of this phase. The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.

Construction Phase The primary objective is to build the software system. In this phase, the main focus is on the development of components and other features of the system. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes. This phase produces the first external release of the software.

Transition Phase The primary objective is to 'transit' the system from development into production, making it available to and understood by the end user. The activities of this phase include training the end users and maintainers and beta testing the system to validate it against the end users' expectations. If all objectives are met, the Product Release Milestone is reached and the development cycle ends.

USE CASE ANALYSISA use case in software engineering, is a description of steps or actions between a user (or "actor") and a software system which leads the user towards something useful. The user or actor might be a person or something more abstract, such as an external software system or manual process. Use cases are a software modelling technique that helps developers determine which features to implement and how to gracefully resolve errors.

Benefits of Use Cases Use cases are the primary vehicle for requirements capture in RUP Use cases are described using the language of the customer Use cases provide an easily-understood communication mechanism Use cases provide a concise summary of what the system should do at an abstract (low modification cost) level.

Figure 11: Use Case Diagram

REFERENCES1. Boehm, B., Some Future Trends and Implications for Systems and Software Engineering Processes, Systems Engineering, vol. 9, No. 1, 2006, pp 1-19. 2. Buxton J. N. and Randell B. (Eds.) Software Engineering Techniques: Report on a Conference Sponsored by the NATO Science Committee, Rome, Italy, 27-31 Oct. 1969. Scientific Affairs Division, NATO, Brussels (May 1970). 3. Boehm B., ICSE '06 Proceedings of the 28th international conference on Software engineering, ISBN: 1-59593-375-1 4. Mall R., Fundamentals of Software engineering, PHI Learning Private Limited, ISBN-97881-203-2445-9, August 2008.