Let's look at Figure 1.1. above. For computer users, the image above is a very familiar display. This image is the desktop display of the Microsoft Windows Operating System. In the image, we see a number of certain icons. If we double-click on one icon, a certain software will open and we can use it to complete a certain task.
Figure 1.1. Microsoft Windows desktop view
Nowadays, it seems that almost all areas of life are touched by the use of software. Some software may be familiar to us or we see such as software to play or create music, software to help cashiers in selling goods, software to type documents, and others. This software is the result of a series of processes or activities known as Software Engineering. What exactly is Software Engineering? This chapter will provide the answer to this question.
Objective
After studying this chapter, it is expected that you will be able to:
- Explaining the concept of software, programs, procedures and software engineering
- Understanding the goals of software engineering
- Understanding the scope of software engineering
- Understanding the position of the field of software engineering in the computer science discipline and its relationship to other fields of science.
- Knowing the development of software engineering science
- Know the professions and certifications in the field of software engineering
- Explains the principles of problem solving in software engineering.
1. Understanding Software Engineering
The term Software Engineering (SEE) is generally agreed to be a translation of the term Software Engineering. The term Software Engineering began to be popularized in 1968 at the Software Engineering Conference organized by NATO. Some people interpret SEE only as how to create computer programs. In fact, there is a fundamental difference between software and computer programs.
Software is all the commands used to process information. Software can be a program or a procedure. A program is a collection of commands that are understood by a computer while a procedure is a command needed by the user in processing information (O'Brien, 1999). The definition of RPL itself is as follows:
A discipline that discusses all aspects of software production, starting from the initial stage, namely analyzing user needs, determining specifications of user needs, design, coding, testing to maintaining the system after use.
It is clear that RPL is not only related to how to create computer programs. The statement "all aspects of production" in the above definition means that all things related to the production process such as project management, personnel determination, budget, method, schedule, quality to user training are part of RPL.
2. Objectives of Software Engineering
In general, the purpose of RPL is no different from other engineering fields. Let's look at Figure 1.2 below.
Figure 1.2. Objectives of RPL
From Figure 1.2 it can be interpreted that the engineering field will always try to produce output that has high performance, low cost and right completion time. More specifically we can state the purpose of RPL is:
- Achieve low software production costs.
- Produce high performance, reliable and timely software.
- Produce software that can work on various types of platforms.
- Produce software that has low maintenance costs.
3. Scope of RPL
According to the definition previously presented, the scope of RPL can be described as follows.
- Software requirements relate to the specification of software needs and requirements.
- Software design includes the process of determining the architecture, components, interfaces, and other characteristics of the software.
- Software construction deals with the details of software development, including algorithms, coding, testing, and error finding.
- Software testing includes testing the overall behavior of the software.
- Software maintenance includes maintenance efforts once the software is in operation.
- Software configuration management deals with the effort of changing software configurations to meet specific needs.
- Software engineering management is concerned with the management and measurement of software engineering, including software project planning.
- Software engineering tools and methods includes theoretical studies of software engineering tools and methods.
- The software engineering process deals with the definition, implementation, measurement, management, change and improvement of the software engineering process.
- Software quality focuses on the quality and life cycle of software.
Figure 1.3. Scope of RPL (Abran et.al., 2004).
4. RPL & Computer Science Discipline
The discipline of computer science was born in the early 1940s which is an integration of algorithm theory, mathematical logic and the discovery of how to store programs electronically on computers. Since then, computer science has experienced continuous development so that its scope has become increasingly broad.
The scope of knowledge in computer science is often described as a systematic study of algorithmic processes that explain and transform information (Denning, 2000). Included here are theory, analysis, design, efficiency, implementation and its application. There are several models of grouping sub-fields of science in the discipline of computer science as seen in Figures 1.4, 1.5 and 1.6.
Figure 1.4. Classification of computer science disciplines according to ACM (1998).
Figure 1.5. Classification of computer science disciplines according to Denning (2000).
Figure 1.6. Classification of computer science disciplines according to Wikipedia (2007).
Based on the grouping of Denning (2000) and Wikipedia (2007), RPL is a sub-field of computer science that is equivalent to other sub-fields. Meanwhile, according to the ACM (Association for Computing Machinery), RPL is part of Section D (Software). Although it looks separate, in its application, the RPL sub-field always needs support from other sub-fields, especially the sub-fields of Algorithms and Data Structures, Programming Languages, Databases, Operating Systems and Networks, and Information Systems.
5. RPL & Other Disciplines
The scope of the scope is quite broad, making RPL very related to other disciplines. Not only with sub-fields in computer science but with several other disciplines outside of computer science. The relationship between RPL and other sciences can be seen in Figure 1.7.
- The field of management science includes accounting, finance, marketing, operations management, economics, quantitative analysis, human resource management, business policy and strategy.
- The field of mathematics includes linear algebra, calculus, probability, statistics, numerical analysis and discrete mathematics.
- The field of project management includes all things related to projects, such as project scope, budget, workforce, quality, risk management, and project scheduling.
- The field of quality management science includes quality systems development, risk and reliability management, quality improvement, and quantitative methods.
- The field of ergonomics concerns the relationship (interaction) between humans and other components in a computer system.
- The field of systems engineering includes systems theory, cost-benefit analysis, modeling, simulation, business processes and operations.
Figure 1.7. The relationship between RPL and other fields of science
6. Development of Software Engineering
Although it was only initiated in 1968, RPL has had a fairly long history. Figure 1.8 presents the essence of RPL development. From a discipline perspective, RPL is still relatively young and will continue to develop. The development directions that are currently being developed include:
Agile Software Development, Experimental Software Development, Model-Driven Software Development and Software Product Lines.
Figure 1.8. Development of RPL
7. Profession & Certification
The profession of a Software Engineer may still sound foreign to the ears of Indonesians. Most Indonesians may be more familiar with the terms Information Technology Expert, Information Systems Analyst, Programmer, Operator or other professional terms. This is because of the confusion about the term RPL as mentioned at the beginning of the chapter. However, in countries that are advanced in the field of information technology, the term Software Engineer has begun to be widely used.
Certification of competency in the field of RPL is currently still a debate among experts and software providers. Most certifications in the software industry are usually very specific to certain software. For example, software companies such as Redhat Linux Inc., Adobe Inc., Oracle, or Microsoft, provide certification of ability to someone who masters the software they produce.
ACM (Association for Computing Machinery) once held certification for Software Engineer programs in the 1980s, but was discontinued due to lack of interest. IEEE (Institute of Electrical and Electronics Engineers) has issued more than 500 software professional certificates. In Canada, a legal certificate for RPL has been issued called ISP (Information Systems Professional).
Currently, certification for RPL in Indonesia is also not yet available, but the Indonesian National Work Competency Standards for Computer Programmers have been prepared. Although it does not yet meet the scope of the RPL field as a whole, it can at least be used as an approach to RPL field certification.
8. RPL & Troubleshooting
Conceptually, software engineering is closely related to the principles of problem solving. Understanding problems, problem-solving strategies and processes, and systems approaches to problem solving will greatly assist the software engineering process.
8.1 Problems and Symptoms
A problem is a difference between the conditions that occur and the expected conditions or can also be interpreted as a difference between the current conditions and the desired goals. For example, a student hopes to get a score above 80 for a C++ Programming exam, but in reality he only gets a score of 60. The existence of this difference indicates a problem.
Often we have difficulty distinguishing between symptoms and problems. Symptoms are signs/indications of a problem. Consider a doctor who, in an effort to treat a patient's illness, always asks about the symptoms felt by the patient first, then concludes that the patient is suffering from a certain disease and determines the right medicine. Dizziness, fever, cough, and runny nose are symptoms or signs of the flu. If the doctor only gives headache medicine, the flu will not be cured. One problem may have one symptom but may also have more (see Figure 1.10).
Figure 1.10. Symptoms and problems
We may wonder what the relationship between problems and symptoms is with RPL. As stated at the beginning of the chapter, software that is the result of RPL is a tool used to solve certain tasks/problems. If we do not know the problem properly, it is impossible for us to determine how to solve it. And, to know the problem well, knowledge of the symptoms of the problem becomes very important.
8.2 Types of Problems
Problems can be grouped as in Figure 1.11.
Figure 1.11. Types of problems (Deek et al, 2005)
Standards compliance issues
The types of problems in this group are problems related to achieving standards that have been determined in an organization. Usually, goals like this apply in the relatively long term.
Alternative selection problem
Problems in this group relate to how to choose the best solution from various alternatives based on certain criteria. We often encounter these problems in everyday life, such as how to choose the right school, choose a place to live, choose a field of work. Each alternative and criterion has an agreed weight.
Problems of fulfilling customer satisfaction
In for-profit organizations, problems in this group are the types that often arise. Consumers have various desires that are different from each other. Fulfilling all consumer desires is very impossible and very burdensome for an organization. Therefore, it is necessary to find a solution that is mutually beneficial, both for consumers and the organization.
Problems of achieving goals
This type is similar to the first type (standard fulfillment problem). The difference is, in this type the goals to be achieved can change and are short-term.
8.3 Troubleshooting
Problem solving is a process in which a situation is observed and then if a problem is found, a solution is made by determining the problem, reducing or eliminating the problem or preventing the problem from occurring. There are many sequences of problem solving processes proposed by experts, one of which is as shown in Figure 1.12.
Figure 1.12 shows a series of different process steps that can be used at different levels, depending on the type and nature of the problem. Different problems require different approaches, perhaps even different orders. The critical step in the problem-solving process is Problem Definition. If the problem is not clearly defined, the following steps are difficult to carry out. Even if forced, it is likely that a proper solution will not be obtained.
Figure 1.12. Problem solving process (adopted from Deek et al, 2005)
In general, the problem solving process can be carried out in four main stages, namely:
Understanding and defining the problem
This section is a very important section because it is the beginning of the entire problem-solving process. The goal of this section is to understand the problem well and eliminate parts that are considered less important.
Make a plan for problem solving
In this section there are two important activities, namely:
- looking for various possible solutions that can be implemented
- create a problem solving plan
The solution to a problem is usually not just one but may be several. As an illustration, if we are in the city of Surabaya and want to go to Jakarta, then there are many ways that can be done, for example we can travel by land, sea or air transportation. With land transportation we can use trains, buses or other transportation. The route we can also go through the north, central or south route. So there are many ways of solving that we can develop. Each has its own characteristics.
From these many solutions we have to choose one that based on certain requirements is the best way to solve the problem. Once selected, we can make a rough plan (outline) of the problem solving and divide the problem into smaller parts. The rough plan (outline) of the problem solving contains only the main stages of solving the problem.
Design and implement plans to obtain solutions
In this section, the rough plan for solving the problem is refined and clarified with detailed divisions and sequences that must be taken in solving the problem.
Check and communicate the results of problem solving
This section aims to check whether the accuracy (precision) of the results of the chosen method has met the desired objectives. In addition, it is also to see how the utility of the chosen method is selected.
9. Summary
Software
It is all the commands used to process information.
- A program is a collection of commands that a computer understands
- Procedures are commands required by users to process information.
Software development is a discipline that discusses all aspects of software production, starting from the initial stage, namely analyzing user needs, determining specifications of user needs, design, coding, testing to maintaining the system after use.
Purpose of RPL
is to produce high-performance, timely, low-cost, multiplatform software.
RPL
is a sub-field of computer science which in its application requires support from both other sub-fields of computer science and other scientific fields.
Certification for the RPL field is not yet available, but refers to the Programmer field.
problem
is the difference between the conditions that occur and the expected conditions and Symptoms are signs/indications of a problem occurring.
Types of problems:
- Standards compliance issues
- Alternative selection problem
- Problems of fulfilling customer satisfaction
- Problems of achieving goals
Solution to problem
is a process in which a situation is observed and then if a problem is found, a solution is created by determining the problem, reducing or eliminating the problem or preventing the problem from occurring.
Main stages of problem solving:
- Understanding and defining the problem
- Make a plan for problem solving
- Design and implement plans to obtain solutions
- Check and communicate the results of problem solving.
Introduction
50 years ago no one could have imagined that:
- Software will become a technology that cannot be separated from business, science and others.
- software will enable the creation of many new technologies.
- software will enable the development of existing technology. Example: telecommunications.
- allows for radical changes to old technologies. Example: printing industries
- software products wrapped in small packages can be purchased at shopping centers
- software will slowly evolve from a product to a service. Example: web
- The vast, software-driven network known as the Internet will evolve and change everything from how research was previously conducted in libraries, to how consumers shop, to how political communications are conducted, to how people date.
- Software is becoming embedded in all types of systems: transportation, health, telecommunications, defense, industry, entertainment, office machines, and so on.
As computer software continues to evolve
- when software meets the needs of the humans who use it
- when the software works flawlessly for a long time
- when software is easy to modify and even easier to use, software can really change things for the better.
But when the software fails
- when its users are disappointed
- when the software is proven to have errors
- When software is difficult to change and even harder to use, bad things can and do happen.
Understanding Software Engineering
- Engineering Definition Engineering = engineering The use of 'science' to solve 'practical problems' From nothing to something
- Definition of softwareSoftware (1) Commands (computer programs) that when executed provide the desired function and performance. (2) Data structures that allow programs to manipulate information proportionally. (3) Documents that describe the operation and use of a program.
- Definition of software engineering. Software Engineering is a discipline that discusses all aspects of software production, starting from the initial stage of requirement capturing (analyzing user needs), specification (determining specifications of user needs), design, coding, testing to system maintenance after use.
- The formation and use of engineering principles to obtain software that is economical but reliable and can work efficiently on computers (Fritz Bauer, 1968)
So what needs to be underlined! Software Engineering is a series of long processes to create or create software, not a branch of computer science that studies technical coding.
Software Characteristics
- Maintainability (Maintainability), Software must be able to meet changing needs.
- Dependability, Software must be trustworthy
- Efficiency, Software must be efficient in its use of resources
- Usability, Software must be able to be used as planned
Software Categories
- System Software. Is a collection of programs written to serve other programs, compilers, editors and file management utilities.
- Real-Time Software. Programs that monitor/analyze/control real-world events.
- Business Software.Business information processing, payroll, inventory
- Engineering and Science Software. This software has a range of applications from astronomy to volcanology, from automotive analysis to spacecraft orbital dynamics, and from molecular biology to automated manufacturing.
- Personal Computer Software.Word processing, spreadsheet, multimedia, database management, business and personal financial applications.
- Artificial Intelligence Software. Active areas of artificial intelligence are expert systems, Artificial Neural Networks, Voice and Image Recognition, game playing etc.
Software Development Life Cycle
- a process by which user needs are translated into software products.
- This process includes the activity of translating user requirements into software requirements.
- transforming software requirements into designs
- implementation of design into program code
- program code testing and installation
- and checking the correctness of the software for operation.
Based on this understanding, in general it can be said that the software development process follows the following stages:
- Determine WHAT the software should do within a certain time frame.
- Defines HOW the software is built, including its software architecture, internal interfaces, algorithms, and so on.
- Implementation (program writing) and testing of program units.
- Integration and testing of program modules.
- Overall software validation (system testing).
Developing software can be a complex task that requires a lot of resources and can take months or even years to complete.
The software development process goes through several stages from when the software is planned to when the software is implemented, operated and maintained.
If the operation of the software that has been developed still causes critical problems and cannot be resolved during the software maintenance phase, then it is necessary to develop new software to resolve them.
This process returns to the first stage, namely the software planning stage. This cycle is called the software life cycle.
The time period that begins with the decision to develop a software product and ends after the software is delivered.
The time period that begins with the decision to develop a software product and ends when the product can no longer be improved by the developer.
The idea of the software life cycle is simple and makes sense.
In the software life cycle, each part of software development is divided into several work stages.
Each of these stages has its own characteristics. The main stages of the software development life cycle can consist of software planning, software analysis, software design, software implementation and software maintenance.
1970 JF Kelly, computerized Management Information Systems, (MacMilan, 1970) cited by A. Ziya Aktas, Structured Analysis & Design of Information Systems, (NJ: Prentice-Hall, 1987).
1]. Systems Survey
- Scope definition
- Research study (survey study)
2]. Systems analysis and design
- Research study (survey study)
- Data collection and analysis
- System design
- Implementation planning
3]. Systems development
- Development
- Testing
- Operation of new system (cutover)
- Maintenance.
1980 Enid Squire, Introduction to Systems Design (Massachusetts : Addison-Wesley) 1981
- Submitting project design and implementation
- Feasibility study
- Planning and projecting cost estimates
- System design and development
- System implementation
- System maintenance
1985. Gordon B. Davis, Management Information Systems: Conceptual Foundations, Structure, and Development, (Tokyo: McGraw-Hill Kogakusha)
1]. Level of definition
- Definition of proposal
- Feasibility assessment
- Information needs analysis
- Design in concept
2]. Level of development
- Physical system design
- Physical database design
- Program development
- Procedure development
3]. Installation and operation
- Conversion
- Operation and maintenance
- Post-implementation check.
1985 Donald H. Sander, Computer Today, (New York : McGraw-Hill)
- Problem definition
- System analysis
- System design
- System implementation
PL Development Process Model
There is no standard so there are various process models for describing the software life cycle. However, the principal stages for mapping the process model to fundamental development activities are as follows:
- Requirements Analysis and definitions
- System and Software Design
- Implementation and unit testing
- Integration and system Testing
- Operation and maintenance
Software Project Planning
- to provide a framework that enables managers to make accountable estimates of scope, resources and costs.
- planning objectives are achieved through a process of discovering information that leads to accountable estimates.
Software Scope
- Things always seem unclear when a software project starts.
- the information needed to determine the scope has not been determined
- A technique that is widely used in general to bridge the communication gap between customers and developers and to start the communication process is to conduct a preliminary meeting or interview.
- The developer starts by asking context-free questions.
- a series of questions that will lead to a fundamental understanding of the problem, the people who want a solution, the nature of the desired solution, and the effectiveness of the meeting itself
- The first set of context-free questions focuses on customers, overall goals, and profits. For example, the analyst might ask:
- Who is behind this job request?
- who uses this solution?
- are there any other resources for this solution?
The next series of questions allows the analyst to better understand the problem and allows customers to voice their perceptions of a solution:
- How do you (the customer) characterize good output that will be generated by a good solution?
- what problem will this solution address?
- Can you show or describe the environment in which the solution will be used?
- Are there any specific performance limitations or issues that will affect how you approach the solution?
- The final series of questions focuses on the effectiveness of the meeting.
- are you the right person to answer this question? is your answer official?
- Is my question relevant to the problem you have?
- Is there anyone else who can provide additional information?
- Is there anything else I can ask you?
Resource
- The second task of software planning is to estimate the resources to complete the software development effort. Resources can be depicted as a pyramid.
- Hardware/software, sits at the foundation of the resource pyramid and provides the infrastructure to support development efforts.
- Reusable software components, software building blocks that can dramatically reduce development costs and speed delivery.
- Humans, the primary resource at the top of the development pyramid.
Estimated costs
- Software volume measurement has become important, because measuring the volume of software will be useful for planning the resources, costs and duration required to build the software.
- Developers can also evaluate product quality by comparing the system volume with the number of errors (error-count) in the software being worked on.
- From a business perspective, software volume can be the basis for determining the price value of the software product in question.
- In the past, many people measured the volume of software using a simple method, namely LOC (Lines Of Code) or KLOC (1000 Lines Of Code).
- a technique for measuring the size of software by counting the lines of existing program code.
- This technique has its drawbacks.
Relative to the programming language/tool and the programmer's coding style. LOC is highly dependent on the characteristics of the programming tool used and the programmer's coding style. In BASIC, the code a = a + 1 is written in one line. In PASCAL, the code is written in 6 lines.
Also note the examples of differences in coding style of the following 2 program scripts resulting in differences in LOC.
LOC cannot be determined before the development project completes the implementation phase (coding). Therefore, LOC cannot be used to plan the development process and cannot be used to estimate the price of the product. From these shortcomings, the desire arose to obtain a software volume measurement technique that is not only based on the number of lines of program code, but more towards something that can be measured earlier in the software development life cycle. so that the idea of the Function Point method emerged.
The function point method was first introduced by Albrecht in 1979.
The function point method is calculated using the following steps:
- Calculating crude function points (CFP)
- Calculating the relative complexity adjustment factor (RCAF)
- Calculating Function Point (FP)4. Calculating the number of LOC.
Calculating crude function points (CFP), used to measure information processing. There are 5 components involved in this measurement. These components have the categories "simple", "intermediate" or "complex".
- Number of types of input applications: each data input from the user that is used to run the application.
- Number of types of output applications: each output result of the process that is displayed to the user.
- Number of types of online query/inquiry applications – these applications deal with queries against stored data.
- Number of files: each master file that is part of the application.
- The number of types of external interfaces – output or input that can connect to the computer via data communication, CDs, diskettes, etc.
- Before measuring CFP, the components in the software design must first be identified.
- In this case a data flow diagram can be used.
- The identified components are then grouped into "simple", "medium" and "complex" based on their complexity.
- After that, the amount of each component that has been categorized can be entered into the CFP table.
Calculate the relative complexity adjustment factor (RCAF).
RCAF functions to calculate the technical complexity of a software system from the perspective of the subject that has the most influence on the development effort required.
The assessment is carried out using a measurement scale of 0 to 5 which is given to each subject.
The subjects assessed at this level are as follows:
- The complexity of backup/recovery reliability
- Complexity of data communication
- Complexity of distributed processing
- Complexity of performance requirements
- Operational environment requirements
- Developer knowledge requirements
- Complexity of updating master files
- Installation complexity
- Complexity of input, output, online query and file applications
- Data processing complexity
- Impossibility of reuse of the codes to be created (non-reusable)
- Customer organization variations
- Possibility of change/flexibility
- The need for ease of use.
Calculating Function Point (FP)
After completing the RCAF calculation, the last step of this method is to calculate the Function Point value itself. The function point value for the software system being assessed is calculated based on the results of stages 1 and 2 which are entered into the following equation.
FP = CFP x (0.65 + 0.01 x RCAF)
Calculating the number of LOC
The estimated number of LOC can be obtained by multiplying the FP value obtained from calculation no. 3 by the approximate number of lines of code per function point of the programming language to be used.
FP * LOC
Step 1: Calculate crude function points(CFP)
determine the values required to calculate the CFP, namely the amount of each component
- Number of input applications – 2
- Number of output applications – 3
- Number of online queries – 3
- Number of logical files – 2
The number of external interfaces – 2 is re-evaluated to sort each component based on its complexity level group (simple, medium or complex) by a professional to obtain the CFP value.
Step 2: Calculate the relative complexity adjustment factor (RCAF)
- evaluate the complexity characteristics of the Master PSDM and the calculation of RCAF. The results of the RCAF calculation in this study are described in the RCAF Table
- The results of the RCAF calculation in Table 5, which shows that the sum of the 14 elements/adjustment factors of relative complexity produces a value of 41.
Step 3: Calculating Function Point (FP)
As a final step, by using equation (2) we can calculate the Function Point value of this PSDM software project, namely:
FP = CFP x (0.65 + 0.01 x RCAF) = 81 x (0.65 + 0.01 x 41) = 85,86Step 4: Calculate Estimated Number of LOCs
If the PL language used is Java, then the estimated number of LOC of your PL is
FP * 55 = 85,86 * 55 = 4722,3Step 5: Calculate Estimated Costs
- If in your PL team a programmer can complete 20 LOC in 1 hour, then the time needed to complete the PL is = 4722.3/20 = 236.115 hours.
- And if a programmer's hourly salary is Rp. 10,000 then the amount of money that must be spent to create this PL is 236,115 * 10000 = 2,361,150 rupiah.
Software Engineering Methods
When we work with computers, we need a series of stages and certain ways to produce something that we hope for. Likewise in software engineering, there are stages of work that must be passed. Successful software engineering requires not only strong computing capabilities such as algorithms, programming, and databases, but also good goal setting, identification of solutions, development methods, sequence of activities, identification of resource requirements, and other factors. Things like this are related to what is called the software engineering method.
The contents of this chapter are not included in the RPL expertise competency standards. However, the author considers it necessary to convey it so that you can know how software engineering is actually done and what methods are commonly used. Some parts of this chapter may be a bit difficult to understand, so the role of the teacher in helping to explain will be very necessary. A summary of the chapter is presented at the end of the content description.
Objective
After studying this chapter, it is expected that you will be able to:
- Understand the general characteristics of process models in software engineering.
- Mention some software engineering models.
- Understand the principles of waterfall, prototyping, and unified process methods.
- Understanding the stages in software engineering.
1. Software Engineering Process Model
In software engineering, many models have been developed to assist the software development process. These models generally refer to a system development process model called the System Development Life Cycle (SDLC) as shown in Figure 2.2.
Figure 2.2. System Development Life Cycle (SDLC)
Each model developed has its own characteristics. However, in general there are similarities between these models, namely:
- The need for a clear problem definition. The main input of any software development model is a clear problem definition. The clearer the better because it will make it easier to solve the problem. Therefore, understanding the problem as explained in Chapter 1, is an important part of the software development model.
- Orderly development stages. Although software development models have different patterns, they usually follow the general pattern of analysis -- design -- coding -- testing - maintenance.
- Stakeholders play a very important role in all stages of development. Stakeholders in software engineering can be users, owners, developers, programmers and people involved in the software engineering.
- Documentation is an important part of software development. Each stage in the model usually produces a number of writings, diagrams, images or other forms that must be documented and are an integral part of the resulting software.
- The output of the software development process must be economically valuable. The value of a software is actually quite difficult to put into rupiah. However, the effect of using the software that has been developed must provide added value to the organization. This can be in the form of reduced operating costs, efficient use of resources, increased organizational profits, improved organizational "image" and others.
There are many software development models, including The Waterfall Model, Joint Application Development (JAD), Information Engineering (IE), Rapid Application Development (RAD) including Prototyping, Unified Process (UP), Structural Analysis and Design (SAD) and Framework for the Application of System thinking (FAST). This book will discuss three development models, namely The Waterfall Model, Prototyping, and Unified Processes (UP).
2. The waterfall model
The life cycle model is the main model and the basis of many models. One of the models that is quite well-known in the world of software engineering is The Waterfall Model. There are 5 main stages in The Waterfall Model as seen in Figure 2.3. It is called waterfall because the process stage diagram is similar to a tiered waterfall.
The stages in The Waterfall Model are summarized as follows:
- The investigation stage is carried out to determine whether a problem occurs or whether there is an opportunity for an information system to be developed. At this stage a feasibility study needs to be carried out to determine whether the information system to be developed is a feasible solution.
- The analysis stage aims to find user and organizational needs and analyze existing conditions (before implementing a new information system).
- The design stage aims to determine detailed specifications of the components of the information system (human, hardware, software, network and data) and information products that are in accordance with the results of the analysis stage.
- The implementation stage is the stage for obtaining or developing hardware and software (program coding), conducting testing, training and moving to a new system.
- The maintenance stage is carried out when the information system has been operated. At this stage, process monitoring, evaluation and changes (improvements) are carried out if necessary.
Figure 2.3. The Waterfall Model
3. Prototyping model
Prototyping is an approach in software engineering that directly demonstrates how a software or software components will work in its environment before the actual construction phase is carried out (Howard, 1997).
Prototyping models can be classified into several types as shown in Figure 2.4.
Figure 2.4. Classification of prototyping models (Harris, 2003)
- Reusable prototype: A prototype that will be transformed into a final product.
- Throwaway prototype: A prototype that will be thrown away once it has completed its purpose.
- Input/output prototype: A prototype that is limited to the user interface.
- Processing prototype: Prototype that includes basic file maintenance and transaction processes.
- System prototype: A prototype that is a complete model of the software.
The stages in prototyping can be said to be accelerated stages. The main strategy in prototyping is to do the easy things first and deliver the results to users as soon as possible. Harris (2003) divides prototyping into six stages as shown in Figure 2.5.
The stages can be briefly explained as follows:
- Identify prototyping candidates. Candidates in this case include the user interface (menus, dialogs, input and output), major transaction files, and simple processing functions.
- Design and build prototypes with the help of software such as word processors, spreadsheets, databases, graphics processors, and CASE (Computer-Aided System Engineering) software.
- Prototype testing to ensure the prototype can be easily run for demonstration purposes.
- Prepare a USD (User's System Diagram) prototype to identify the parts of the software to be prototyped.
- Evaluate with users to evaluate the prototype and make changes if necessary.
- Transform prototypes into fully operational software by eliminating unnecessary code, adding necessary programs, and repeatedly improving and testing the software.
Figure 2.5. Stages of model prototyping (Harris, 2003)
4. Unified Process and Unified Modeling Language
Unified Process (UP) or sometimes referred to as Unified Software Development Process (USDP) is a development process framework that is use-case-driven, centered on software architecture, interactive and growing (Alhir, 2005). This development framework is relatively new in software development methodology. UP can be applied to various project scales, from small to large scale.
The UP life cycle will generally appear as in the chart in Figure 2.6. This chart is commonly referred to as a "hump chart". In this chart, there are four stages of development, namely inception, elaboration, construction and transition. In addition, there are also a number of activities (disciplines) that must be carried out throughout software development, namely, business modeling, requirements, analysis and design, implementation, test. These stages and activities will be carried out iteratively (Ambler, 2005).
Figure 2.6. RUP Life Cycle (Ambler, 2005)
A brief explanation of the four stages in UP is as follows:
Inception
This stage is the earliest stage where the assessment activity of a software project is carried out. The goal is to get agreement from stakeholders regarding the goals and funds of the project.
Elaboration
The purpose of this stage is to get an overview of the needs, requirements and main functions of the software. This is important to better understand the risks of the project, including risks of software architecture, planning, and implementation. At this stage, the software design has begun iteratively through activities such as business modeling, requirements, analysis and design, although only in the early stages.
Construction
The purpose of this stage is to build the software until the software is ready to use. The focus of this stage is on determining the priority level of needs / requirements, completing the specifications, deeper analysis, designing solutions that meet the needs and requirements, coding and testing the software. If possible, an early version of the software is tested to get input from users.
Transition
This stage focuses on how to deliver the finished software to the user. The software will be formally tested by both competent testers and users. Several activities such as data center relocation and user and support staff training should be done at this stage.
In software development using UP, it is inseparable from the use of notations commonly referred to as UML (Unified Modeling Language). Although UP requires the use of UML, UML itself can be used in various other methodologies and can even be used in fields other than information systems. UML is a standard modeling language or collection of modeling techniques for specifying, visualizing, constructing and documenting work results in software development (Fowler, 2004). UML was born from the merger of many object-oriented graphical modeling languages that developed rapidly in the late 1980s and early 1990s.
In simple terms, UML is used to draw system sketches. Developers use UML to convey some aspects of a software through graphical notation. UML defines notation and semantics. Notation is a set of special shapes that have certain meanings to describe various software diagrams and semantics defines how these shapes can be combined. There are several types of diagrams provided in UML, including:
- Use-case diagram. This diagram is useful for describing the interaction between users and software.
- Activity diagram. This diagram is useful for describing software behavior procedures.
- Class diagram. This diagram is useful for describing classes, features, and relationships that occur. In this diagram, the object-oriented approach plays a very important role.
- Sequence diagram. This diagram is useful for describing interactions between objects with an emphasis on the sequence of processes or events.
- State machine diagram. This diagram is used to describe how an event changes an object during the object's lifetime.
- Component diagram. This diagram is useful for describing the structure and connections of components.
5. Software Engineering Stages
As mentioned, although the approaches are different, the models above have similarities, namely using the analysis -- design -- coding (construction) -- testing -- maintenance stage pattern.
5.1. Analysis
Systems analysis is a problem-solving technique that decomposes a system into its component parts for the purpose of studying how well those components work and interact to accomplish their purpose.
Analysis is probably the most important part of the software engineering process. Because all subsequent processes will depend heavily on the quality of the analysis results. The stages in software engineering analysis can be seen briefly in Figure 2.7.
There is one important part that is usually done in the analysis stage, namely business process modeling. A process model is a model that focuses on the entire process in a system that transforms data into information (Harris, 2003). The process model also shows the flow of data entering and leaving a process. Usually this model is depicted in the form of a Data Flow Diagram (DFD). DFD presents a picture of what humans, processes and procedures do to transform data into information.
Figure 2.7. Stages and activities in analysis
Generally there are four notations that are often used in DFD as shown in Figure 2.8.
External Entity represents the data source (where the data comes from) or the recipient of information (the final destination of the data). Examples of external entities include consumers ordering a product, managers evaluating weekly sales reports, and so on.
A process is a series of steps taken to manipulate data, for example collecting, sorting, selecting, reporting, summarizing, analyzing and so on.
Data store is a place to store data for later use. The name of the data store is an abstraction of the data stored. However, the details / data items that exist, how to access them, or how to organize them are not explained in this notation.
Data flow shows the flow of data from one place to another. This data movement can be from an external entity to a process, between one process and another, from a process to a data store. In its depiction, each data flow must be labeled to indicate what data is flowing.
In making DFD there are several stages that are carried out sequentially. Figure 2.9. shows the sequence of these stages.
Figure 2.9. Stages of DFD creation
Context diagram is a DFD of the scope of the system that shows the boundaries of the system, external entities that interact with the system and the main data flow between external entities and the system. Context diagram describes the entire system in a single process. Figure 2.10 shows an example of a context diagram.
Figure 2.10. Context diagram of a food ordering system (Hoffer et al., 2002)
The context diagram in Figure 2.10 shows that there is only one single process that represents the modeled system. In this process, the number 0 is given to indicate that this is the most abstract level of the system. In addition, there are three external entities, namely customer, kitchen and restaurant manager. All three can act as data sources (in the example above, the customer) or as recipients of information (in the example above, the customer, kitchen, and restaurant manager). The data flow shown in the figure shows that there is one data flow entering the system and there are three data flows leaving the system. Each data flow is labeled to indicate what data is flowing.
After the context diagram is formed correctly, the next step is to detail the context diagram in DFD Level 0. DFD Level 0 is a DFD that represents the processes, data flow and main data storage in the system. This DFD Level 0 will be used as a basis for building DFDs at lower levels (Level 1, 2, 3, .. etc.) or commonly referred to as DFD decomposition. Figure 3.10 is a DFD level 0 of the context diagram in Figure 2.11.
Figure 2.11. DFD Level 0
In Figure 2.11, there is a breakdown of the process from the original one to four. Each process is given a code number 1.0, 2.0, 3.0 and 4.0. The number of external entities must remain at 3, as well as the data flow that comes in and out (input and output) into the system must be the same as in the context diagram. Meanwhile, the data flow in the system (which flows between processes and/or data storage) depends on the processes and data storage involved. There are two data storages, namely Goods Sold
File and Inventory File. Both of these data storage are used to store data from a process. This data will also be read / accessed by other processes. For example, the Inventory File data storage contains data from process 3.0 (Update Inventory File). This data will be used by process 4.0 (Produce Management Reports) to create a report that will be submitted to the Restaurant Manager.
The next level of DFD, namely level 1, 2 and so on, is needed if the previous level is considered less detailed. For example, if DFD level 0 (Figure 14.12) is considered not detailed enough to show the data flow, then the details can be made at DFD level 1. The part that must be detailed is usually the process. Details at the next level may be on all processes or only on certain processes. DFD at level 0 and the levels below have the same rules presented in the following table.
Table 2.1. Rules in DFD
| Kelompok | Aturan |
|-----------------|--------------------------------------------------------------------------------------------------------------------------------|
| Umum | input-input ke suatu process akan selalu berbeda dengan outputoutputnya |
| | obyek obyek (External Entity, Process, Data Storage, dan Data Flow) yang ada pada suatu DFD selalu memiliki nama yang unik |
| External Entity | nama yang dipakai pada External Entity selalu menggunakan kata benda |
| | data tidak boleh mengalir secara langsung dari External Entity yang satu ke External Entity yang lain |
| Process | nama yang dipakai pada Process selalu menggunakan kata kerja |
| | tidak ada Process yang hanya menghasilkan output |
| | tidak ada Process yang hanya menerima input |
| Data Storage | nama yang dipakai pada Data Storage selalu menggunakan kata benda |
| | data tidak boleh mengalir secara langsung dari Data Storage yang satu ke Data Storage yang lain |
| | data tidak boleh mengalir secara langsung dari External Entity ke Data Storage demikian juga sebaliknya. |
| Data Flow | nama yang dipakai pada Data Flow selalu menggunakan kata benda |
| | Data Flow di antara dua notasi hanya memiliki satu arah aliran |
| | Percabangan (fork) menunjukkan adanya data yang persis sama yang mengalir dari suatu tempat ke dua atau lebih tempat yang lain |
| | Penggabungan (join) menunjukkan adanya data yang persis sama yang mengalir dua atau lebih tempat menuju satu tempat yang lain |
| | Data Flow menuju Data Storage berarti terjadi update data |
| | Data Flow dari Data Storage berarti terjadi pembacaan / pengambilan data |5.2. Design
Software design is a task, stage or activity that focuses on the detailed specifications of a computer-based solution (Whitten et al, 2004).
Software design is often also referred to as physical design. If the system analysis stage emphasizes business problems (business rules), then on the contrary software design focuses on the technical side and implementation of a software (Whitten et al, 2004).
The main output of the software design phase is the design specification. This specification includes a general design specification that will be submitted to system stakeholders and a detailed design specification that will be used in the implementation phase. The general design specification only contains a general description so that system stakeholders understand what the software to be built will be like. Usually the USD diagram of the new software is an important point in this section. Detailed design specifications or sometimes called detailed software architecture design are needed to design a system so that it has good construction, precise and accurate data processing, is valuable, has user friendly aspects and has the basis for further development.
This architectural design consists of database design, process design, user interface design that includes input design, output form and report, hardware, software and network design. Process design is a continuation of the process modeling carried out at the analysis stage.
5.3. Construction
Construction is the stage of translating the results of logical and physical designs into computer program codes. This book is mostly about this section.
5.4. Testing
System testing involves all user groups that have been planned in the previous stage. Acceptance testing of the software will end when it is felt that all user groups state that they can accept the software based on the criteria that have been set.
5.5. Maintenance and Configuration
When a software has been deemed fit to run, then a new stage emerges, namely software maintenance. There are several types of maintenance commonly known in the software world as seen in the diagram in Figure 2.12.
Figure 3.12. Types of care
- Corrective maintenance type is done if there is an error or commonly known as bugs. Maintenance can be done by fixing the program code, adding parts that are deemed necessary or even removing certain parts.
- Routine maintenance type is also called preventive maintenance and is carried out routinely to check whether the software is performing correctly or not.
- The upgrade system maintenance type is performed if there is a change in the components involved in the software. For example, a change in the operating system platform from an old version to a new version causes the software to be upgraded.
6. Summary
- Software engineering models generally refer to a system development process model called the System Development Life Cycle (SDLC).
- The software development models currently in common use are The Waterfall Model, Prototyping, and Unified Process (UP).
- The main stages in software engineering include; analysis, design, construction, testing and maintenance.
7. Practice Questions
- Mention the stages in the System Development Life Cycle (SDLC)
- State the characteristics that software development models have in common.
- Name five software development models that you know.
- What is meant by construction stages in software engineering?
- Describe the notations in Data Flow Diagrams that you know.