RPL yang sukses membutuhkan kemampuan :
- Komputasi seperti algoritma, pemrograman, dan basis data yang kuat
- Penentuan tujuan yang baik
- Identifikasi cara penyelesaian
- Metode pengembangan, urutan aktifitas, identifikasi kebutuhan sumber daya
Model Pengembangan Perangkat Lunak :
- Waterfall Model
- Jpint Application Development ( JAD )
- Information Engineering ( IE )
- Rapid Application Development ( RAD )
- Unified Process ( UP ) termasuk di dalamnya Prototyping
- Structural Analysis and Design ( SAD )
- Framework for the Application of System thinking ( FAST )
Tahapan Rekayasa Perangkat Lunak :
- Pola tahapan analysis
Sofware Quality - Definition IEEE
1. The degree to which a system, component, or process meets specified requirements.
2. The degree to which a system, component, or process meets customer or user needs or expectations.
1. Classification of the causes of software errors :
- software errors are the cause of poor software quality
- software errors can be : code error, documentation error, software data error
- the cause of all these errors are human.
2. The nine causes of software errors :
- faulty requirement definition
- client - developer communication failures
- deliberate deviation from SW requirements
- logical design errors
- non-compliance with documentation and coding instruction
- shortcomings of the testing process
- procedure errors
- docmentation errors
3. Faulty requirement definition :
- erroneous definition of requirements
- absence of vital requirements
- incomplete definition of requirements
- inclusion of unnecessary requirements
Software refactoring is the process of applying changes to the internal structure of software without changing its observable behavio. Improving a computer program by reorganising its internal structure without altering its external behaviour. When software developers add new features to a program, the code degrades because the original program was not designed with the extra features in mind. This problem could be solved by either rewriting the existing code or working around the problems which arise when adding the new features. Redesigning a program is extra work, but not doing so would create a program which is more complicated than it needs to be. Refactoring is a collection of techniques which have been designed to provide an alternative to the two situations mentioned above. The techniques enable programmers to restructure code so that the design of a program is clearer. It also allows programmers to extract reusable components, streamline a program, and make additions to the program easier to implement. Refactoring is usually done by renaming methods, moving fields from one class to another, and moving code into a separate method. Although it is done using small and simple steps, refactoring a program will vastly improve its design and structure, making it easier to maintain and leading to more robust code.
Before a refactoring project is actually started, an assessment and an in-depth analysis are made which result in a list of findings. Ideally, these findings will be translated into a master plan, which defines WHAT should be refactored. This master plan helps to keep the overall picture of the refactoring project in mind and to divide it into several sub-projects or refactoring parts. Once the master plan is defined we use an iterative approach to tackle the individual refactoring steps.
Refactoring, which is one of the techniques to keep software maintainable. Function the refactoring is modification of code so as to improve internal structure and preserve external functionality. Refactoring is a technique that makes the source code of the software easier, more readable, and more understandable by eliminating the bad smells from the source code. Refactoring has a two kinds of techniques, source code refactoring and non source code refactoring. Source code refactoring identified bad smell in code. Bad smell likely mean should change the source code. For example, a characteristic of a design that is a strong indicator it has poor structure and should be refactored. We discussed in this paper, which good techniques for refactoring in bad code smell. Especially bad code smell for object oriented refactoring, Java programming. Therefore object oriented refactoring has some kind technique to eliminating bad smell. So, we should to know how to identified which is good technique for bad smell object oriented refactoring.
Sebuah perangkat lunak dibuat atau dikembangkan untuk membantu aktivitas manusia. Dalam proses pembuatan atau pengembangan perangkat lunak terdapat beberapa tahapan yang harus dilalui, salah satunya adalah tahapan analisis. Tahapan ini merupakan tahapan awal yang dilakukan oleh pengembang perangkat lunak selama proses pengembangan berlangsung. Dalam tahapan ini, pengembang harus mengetahui kebutuhan-kebutuhan dari perangkat lunak yang akan dikembangkan. Kebutuhan perangkat lunak berkaitan dengan elisitasi, analisis, spesifikasi, validasi dan pengelolaan kebutuhan perangkat lunak secara kesuluruhan selama siklus hidup perangkat lunak. Kebutuhan perangkat lunak juga mencakup kebutuhan dan batasan terhadap suatu produk perangkat lunak yang dikembangkan agar dapat secara optimal dalam membantu memenuhi kebutuhan manusia dalam menghadapi permasalahan di kehidupan nyata.
Software Requirements Fundamental :
Dalam fundamental kebutuhan perangkat lunak, yang terpernting adalah tahapan verifikasi kebutuhan. Alasannya adalah dalam tahap pengujian kualitas perangkat lunak harus dapat diverifikasi dengan sumber daya yang tersedia untuk mengetahui kesesuaiannya. Dalam perangkat lunak terdapat beberapa macam kebutuhan yang harus dipahami. Kebutuhan fungsional menggambarkan fungsi perangkat lunak yang dapat dieksekusi atau lebih dikenal sebagai fitur pada perangkat lunak. Jadi kebutuhan fungsional merupakan fitur atau layanan yang harus didefinisikan dan juga dapat berinteraksi secara langsung dengan pengguna perangkat lunak. Dalam skala proyek yang besar dan kompleks, untuk dapat mencapai pendefinisian yang benar memiliki sedikit kemungkinan. Alasannya adalah sering terjadi kelalaian dalam membuat spesifikasi yang kompleks. Sedangkan kebutuhan nonfungsional merupakan kebutuhan kualitas atau kebutuhanyang tidak secara langsungberkaitan denganlayanan pada sistem untukpenggunanya, misalnya kebutuhan kinerja, kebutuhan pemeliharaan, kebutuhan keselamatan, kebutuhan keandalan, kebutuhan keamanan, kebutuhan interoperabilitas.
Ada juga kebutuhan produk dan kebutuhan sistem. Kebutuhan produk merupakan batasan pada perangkat lunak yang akan dikembangkan, misalnya perangkat lunak yang memverifikasi bahwa seorang siswa telah memenuhi semua persyaratan sebelum dia mendaftar kursus. Sedangkan kebutuhan sistem adalah kebutuhan sistem secara keseluruhan yang mencakup kebutuhan pengguna, kebutuhan para stakeholder lainnya (seperti peraturan otoritas).
There are four types of maintenance, namely, corrective, adaptive, perfective, and preventive. Corrective maintenance is concerned with fixing errors that are observed when the software is in use. Adaptive maintenance is concerned with the change in the software that takes place to make the software adaptable to new environment such as to run the software on a new operating system. Perfective maintenance is concerned with the change in the software that occurs while adding new functionalities in the software. Preventive maintenance involves implementing changes to prevent the occurrence of errors. The distribution of types of maintenance by type and by percentage of time consumed.
Corrective maintenance deals with the repair of faults or defects found in day-today system functions. A defect can result due to errors in software design, logic and coding. Design errors occur when changes made to the software are incorrect, incomplete, wrongly communicated, or the change request is misunderstood. Logical errors result from invalid tests and conclusions, incorrect implementation of design specifications, faulty logic flow, or incomplete test of data. All these errors, referred to as residual errors, prevent the software from conforming to its agreed specifications. Note that the need for corrective maintenance is usually initiated by bug reports drawn by the users.
In the event of a system failure due to an error, actions are taken to restore the operation of the software system. The approach in corrective maintenance is to locate the original specifications in order to determine what the system was originally designed to do. However, due to pressure from management, the maintenance team sometimes resorts to emergency fixes known as patching. Corrective maintenance accounts for 20% of all the maintenance activities.
Adaptive maintenance is the implementation of changes in a part of the system, which has been affected by a change that occurred in some other part of the system. Adaptive maintenance consists of adapting software to changes in the environment such as the hardware or the operating system. The term environment in this context refers to the conditions and the influences which act (from outside) on the system. For example, business rules, work patterns, and government policies have a significant impact on the software system.
For instance, a government policy to use a single 'European currency' will have a significant effect on the software system. An acceptance of this change will require banks in various member countries to make significant changes in their software systems to accommodate this currency. Adaptive maintenance accounts for 25% of all the maintenance activities.
Perfective maintenance mainly deals with implementing new or changed user requirements. Perfective maintenance involves making functional enhancements to the system in addition to the activities to increase the system's performance even when the changes have not been suggested by faults. This includes enhancing both the function and efficiency of the code and changing the functionalities of the system as per the users' changing needs.
Examples of perfective maintenance include modifying the payroll program to incorporate a new union settlement and adding a new report in the sales analysis system. Perfective maintenance accounts for 50%, that is, the largest of all the maintenance activities.
Preventive maintenance involves performing activities to prevent the occurrence of errors. It tends to reduce the software complexity thereby improving program understandability and increasing software maintainability. It comprises documentation updating, code optimization, and code restructuring. Documentation updating involves modifying the documents affected by the changes in order to correspond to the present state of the system. Code optimization involves modifying the programs for faster execution or efficient use of storage space. Code restructuring involves transforming the program structure for reducing the complexity in source code and making it easier to understand.
Preventive maintenance is limited to the maintenance organization only and no external requests are acquired for this type of maintenance. Preventive maintenance accounts for only 5% of all the maintenance activities.
Yes—because today, everyone’s a programmer…
We are bobbing on a sea of data, using our electronic devices to stay mobile and afloat. Each device requires software in order to operate, and the sheer number of users imagining new ways to use these gadgets—and the ease of creating instructions that tell the hardware what to do—almost guarantees that software will always be a step ahead of the machines running it.
“Pretty much everyone is able to write software these days,” says Srini Devadas, a professor in MIT’s Department of Electrical Engineering and Computer Science. “They may not realize it, but formatting in a word processing program or writing commands and scripts in Excel is doing a kind of rudimentary programming.”
It’s second nature for digital natives to spend an afternoon updating and reconfiguring their Facebook presence, and they can easily share their creations with their friends—who modify them even further. Conversely, “designing hardware from scratch or even redesigning it is very difficult for the ordinary person,” says Devadas. “In order to build something like an iPad or even the integrated circuits that go into our devices requires design knowledge, raw materials, and a manufacturing technology.” Plus, Devadas add, “It’s harder to share hardware. If I build a radio, I’d have to give you the physical object. But I could email you—and 10,000 other people—a program I’ve written, and they could all improve it.”
One challenge Devadas regularly sets for his students is to improve the efficiency of software so that every increase in functionality does not require an upgrade in hardware. Devadas teaches a course on software engineering (where students do a bit more than post updates on FB or create spreadsheets), and encourages his students to think through the challenges of hardware performance, which can inhibit the proper display of their creations that include games. “The hardware lags because it’s not capable of running the functionality fast enough,” he says.
When it comes to gaming and a software solution just won’t cut it (or you’re not able to take Devadas’s class and figure it out), he suggests you employ a partial hardware solution: “Just pop out the graphics card and replace it with a new one,” he says. New cards provide enough processing power to achieve the high speed required in gaming.—Sarah Jensen
In enhancement and replacement projects, even if you don’t have existing documentation, you do have a system to work from to discover the relevant requirements. During enhancement projects, consider drawing a dialog map for the new screens you have to add, showing the navigation connections to and from existing display elements. You might write use cases or user stories that span the new and existing functionality.
In replacement system projects, you need to understand all of the desired functionality, just as you do on any new development project. Study the user interface of the existing system to identify candidate functionality for the new system. Examine existing system interfaces to determine what data is exchanged between systems today. Understand how users use the current system. If no one understands the functionality and business rules behind the user interface, someone will need to look at the code or database to understand what’s going on. Analyze any documentation that does exist—design documents, help screens, user manuals, training materials—to identify requirements.
You might not need to specify functional requirements for the existing system at all, instead
creating models to fill the information void. Swimlane diagrams can describe how users do their jobs with the system today. Context diagrams, data flow diagrams, and entity-relationship diagrams are also useful. You might create user requirements, specifying them only at a high level without filling in all of the details. Another way to begin closing the information gap is to create data dictionary entries when you add new data elements to the system and modify existing definitions. The test suite might be useful as an initial source of information to recover the software requirements, because tests represent an alternative view of requirements.
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 thesize 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 the 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 the 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 andquality software product.
Software Development Life Cycle (SDLC) merupakan pendekatan bertahap untuk melakukan analisa dan membangun rancangan sistem dengan menggunakan siklus yang spesifik terhadap kegiatan pengguna. Beberapa metode SDLC diantaranya waterfall, spiral, RUP, agile, dan sebagainya.
Tahapan-tahapan yang terdapat pada proses SDLC
- Requirement specification
Software Operation Life Cycle (SOLC) merupakan proses untuk memindahkan perangkat dari lingkungan development ke operation. Pada tahapan operation dan pada penggunaannya terdapat masalah, maka akan diambil tindakan berdasarkan klasifikasi masalah yang ada
- Minor, Contohnya apabila terdapat bug pada perangkat lunak maka tindakan yang diambil adalah proses maintenance.
- Mayor, Contohnya apabila terjadi perubahan proses bisnis, maka tindakan yang diambil adalah fisibility study. Fisibility study dilakukan untuk menentukan apakah perlu dilakukan proses development ulang terhadap perangkat lunak atau tetap menggunakan perangkat lunak yang ada. Jika perangkat lunak yang telah ada sudah cukup efektif dan tidak menimbulkan kerugian yang berarti maka perangkat lunak tersebut tetap digunakan (Not Go). Tetapi jika sebaliknya, artinya dengan mengubah perangkat lunak akan lebih menguntungkan dan memudahkan, maka perangkat lunak akan dikembalikan ke proses Development (Go).
Requirement engineering is the process of collecting the software requirement from customer analyse and document them. it is a sophisticated and descriptive system requirement document that illustrate all the required data to develop the software.in this requirement, there are two categories
Functional requirement and nonfunctional requirement. the difference between this categories are as follow: Functional Requirements
A functional requirement is requirements, that have an impact or direct relation to the functionality aspect of developed software.
They define functions and functionality within and from the software system.
- The search option is given to the user to search from various invoices.
- The user should be able to mail any report to management.
- Users can be divided into groups and groups can be given separate rights.
- Should comply business rules and administrative functions.
- The software is developed keeping downward compatibility intact.
The nonfunctional Requirements hose that requirement that does not have any impact on functional aspect of software. They are implicit or expected characteristics of software, which users make assumption of.It is just all about the behavior of the software system after its implementation.
The example of nun function requirement include the following :
In software development industries the software developer team gather information from the software stakeholders and these collected information must be modeled and produce a single document which will be used by software designer.
in the following part we are going to discuss about Requirements Modeling with Enterprise Architect
Requirements modeling represents in the life of a software development project, an effective way to prepare the analysis UML structuring the business and technical needs of project management through its specifications.
The benefits of requirements modeling Requirements modeling are the first link between the expression of needs of project management and project analysis phase. During the life of the project, it is the reference of the project in the design phase and approval of the developed software.
Requirements modeling contribute essentially to:
The requirements identified once in their totality, are neither more nor less than what the software should provide in terms of services. At this stage, we do not know yet how the software will perform the services expected, but we must, however, be sure of what he will do and on what terms, and therefore it will not have to do. Requirements modeling can be considered complete when both parties, the developers and the customers, agree on number and contents of recorded and modeled requirements.
Each application require more or less effort to be translated into a software feature or operating conditions (example: on performance or security software). An estimate of the complexity can be filled for a requirement and thus serve as a criterion for both refine the project charge estimate and to guide the phasing of the project.
In general, in order to control risks on a project, it is better to focus the early development iterations, the requirements for which the complexity is highest.
Guide the team Master of Work in the project phases
Requirements model is a reference for the Guidance to the master work of the project team in the phases of analysis, design and software licensing . Indeed, the UML(Unified modeling Language) elements involved in the analysis models, design and project tests have reason to exist if they were created to respond to one or more business or technical requirements (link realization between a requirement and the UML element that is involved in its implementation). Also, Analyst, Designer and Test Engineer must be able to control, for each feature or object of the system in which they intervene, the requirements are met and those that are not will be done in future software increments (in the case of an iterative development).
The objectives of the initiative are to ensure that the requirements are clearly understood by the prime contractor team and shared with project management through product models.
The models are developed on the basis of a comprehensive census of the requirements of a deepening when necessary some of them and finally their grouping by affinities to prepare their analysis.