Software Development Life Cycle Category: Concepts

Comments (6)

Software Development Life Cycle The product developed which achieves customer satisfaction is not done in a single step. It involves series of steps in a software development process. This is needed to develop quality products with error free products to achieve customer satisfaction. There are many models available in the software development process. But majority of software development process follow the model named as software development life cycle. This software develop life cycle has number of steps in it. The below article describes about the software development life cycle and the steps involved into it. Software development life cycle model is also called as waterfall model which is followed by majority of systems. This software development life cycle process has the following seven stages in it namely 1. System Requirements Analysis 2. Feasibility study 3. Systems Analysis and Design 4. Code Generation 5. Testing 6. Maintenance 7. Implementation Let us discuss each of these to have an overview about teach of the following steps in software development life cycle. 1. System Requirements Analysis: The first essential or vital thing required for any software development is system. Also the system requirement may vary based on the software product that is going to get developed. So a careful analysis has to be made about the system requirement needed for the development of the product. After the analysis and design of the system requirement phase the system required for the development would be complete and the concentration can be on the software development process. 2. Feasibility study: After making an analysis in the system requirement the next step is to make analysis of the software requirement. In other words feasibility study is also called as software requirement analysis. In this phase development team has to make communication with customers and make analysis of their requirement and analyze the system. By making analysis this way it would be possible to make a report of identified area of problem. By making a detailed analysis on this area a detailed document or report is prepared in this phase which has details like project plan or schedule of the project, the cost estimated for developing and executing the system, target dates

5. After this process the system again goes to development phase for correction of errors and again tested. 3. Based on the need the testing methods are chosen and reports are prepared about bugs. Implementation: When the system is developed and tested then it is implemented. 4. This is because this is the phase where system developed would be tested and reports are prepared about bugs or errors in system. After the code is developed generation of code also takes place in this phase. That is based on the design documents prepared in the earlier phase code is written in the programming technology chosen. functional specification design. Code Generation: This is the phase where actual development of the system takes place. After implementation it is possible that there are some errors. the design of the architecture chosen. Systems Analysis and Design: This is an important phase in system development . This phase is the base of software development process since further steps taken in software development life cycle would be based on the analysis made on this phase and so careful analysis has to be made in this phase. In other words database design.for each phase of delivery of system developed and so on. high level design documents and so on takes place. This process continues until the system is found to be error free. low level design documents. To do this testing phase there are different levels and methods of testing like unit testing. Care must be taken to prepare these design documents because the next phases namely the development phase is based on these design documents.Here analysis is made on the design of the system that is going to be developed. system test and so on. If a well structured and analyzed design document is prepared it would reduce the time taken in the coming steps namely development and testing phases of the software development life cycle. In other words the code is converted into executables in this phase after code generation. Testing: A software or system which is not tested would be of poor quality. To ease the testing process debuggers or testing tools are also available. In this case the development and testing step is Repeated .

As more and more data was stored and linked man began to analyze this information into further detail. Entity Behavior Modeling This is the process of identifying. Over time these applications became more complex and began to store increasing amounts of information while also interlinking with previously separate information systems. data was distinguished from information. often without much detail. Data Flow Modeling This is the process of identifying. The data are separated into entities (things about which a business needs to record information) and relationships (the associations between the entities). Data Flow Modeling examines processes (activities that transform data from one form to another). e. which were developed to provide managers with information about sales. Expert systems. technologies. business computers were mostly used for relatively simple operations such as tracking sales or payroll data.[2] At the start. stored data. Decision Support Systems. and other data that . Previously. data stores (the holding areas for data). data had to be separated individually by the people as per the requirement and necessity of the organization. Early on. internal reporting was made manually and only periodically. Ans 3 A management information system (MIS) is a system or process that provides information needed to manage organizations effectively [1]. The term "MIS" arose to describe these kinds of applications. and gave limited and delayed information on management performance. the term is commonly used to refer to the group of information management methods tied to the automation or support of human decision making.g. external entities (what sends data into a system or receives data from a system). modeling and documenting the data requirements of the system being designed. which cover the application of people. Later. and so instead of the collection of mass of data. modeling and documenting the events that affect each entity and the sequence in which these events occur. Management information systems are distinct from regular information systems in that they are used to analyze other information systems applied in operational activities in the organization. inventories. important and to the point data that is needed by the organization was stored. creating entire management reports from the raw. documents.[2] Academically. works in businesses and other organizations.SSADM techniques The three most important techniques that are used in SSADM are: Logical Data Modeling This is the process of identifying. and data flows (routes by which data can flow). and Executive information systems. Management information systems are regarded to be a subset of the overall internal controls procedures in a business. service or a business-wide strategy. and procedures used by management accountants to solve business problems such as costing a product. modeling and documenting how data moves around an information system. as a by-product of the accounting system and with some additional statistic(s).

and in virtual real-time. evaluate. and do so in such a way that identifies individual accountability. project management and database retrieval application. bulky to use and difficult to manage. This is because paper medical records are cumbersome. Today. as information technology management. integrated information system designed to manage the administrative.would help in managing the enterprise. the term is used broadly in a number of contexts and includes (but is not limited to): decision support systems. These reports would include performance relative to cost centers and projects that drive profit or loss. MIS must not only indicate how things are going. including recruitment and training regimens. The distinction is not always clear and there is contradictory evidence against a consistent use of both terms. financial and clinical aspects of a hospital. and distribute needed. According to Philip Kotler "A marketing information system consists of people. . equipment. In a way it is a documented report of the activities that were planned and executed. processing. in a restrictive sense. The number of investments in computers and types of hospital systems has increased. This encompasses paper-based information processing as well as data processing machines. analyze.g. CISs are sometimes separated from HISs in that the former concentrate on patient-related and clinical-state-related data (electronic patient record) whereas the latter keeps track of administrative issues. MIS has also some differences with Enterprise Resource Planning (ERP) as ERP incorporates elements that are not necessarily focused on decision support. On the other hand digital records are much easier to handle and improve the workflow efficiency by integrating various tasks. and procedures to gather. timely. It must provide for reports based up performance analysis in areas critical to that plan. ERP. but why they are not going as well as planned where that is the case. Radiology Information System). Laboratory Information System. resource and people management applications. In effect. An 'MIS' is a planned system of the collecting. IT service management is a practitioner-focused discipline. It can be composed of one or a few software components with specialty-specific extensions as well as of a large variety of sub-systems in medical specialties (e. variously also called clinical information system (CIS) is a comprehensive. sort. storing and disseminating data in the form of information needed to carry out the functions of management. The past decade has witnessed the foray of numerous information systems and their resultant products into the hospital scenario. CRM. Information technology has made a significant impact on the healthcare sector. with feedback loops that allow for titivation of every aspect of the business. Any successful MIS must support a businesses Five Year Plan or its equivalent. Information systems include systems that are not intended for decision making. and accurate information to marketing decision makers The terms MIS and information system are often confused. The area of study called MIS is sometimes referred to. Hospital information system A hospital information system (HIS). That area of study should not be confused with computer science. SCM.

pharmacy ordering. diagnostic reports related to laboratory. A Hospital Information System (HIS) can be defined as a computerized system that is designed to meet all the information needs within a hospital. staffing and scheduling. radiology and patient monitoring as well as providing decision support. Despite the fact that these individual centers are autonomous. maintenance and orders management. they are interdependent in terms of delivering services and to ensure effectiveness of providing care. and so on in order to effectively meet the needs arising within the hospital. This includes diverse data types such as patient information. supplies. finance and accounting. . billing. pharmacy. Functional Model of a Hospital Information Functional Model of a Hospital Information System. prescription handling. Decision table Decision tables are a precise yet compact way to model complicated logic. inventory. All this can be achieved through hospital information systems (HIS) that have formed the cornerstone of today’s modern hospital.The ultimate objective is to build a network of interdependent centers such as the clinical laboratory. radiology department.

and the action entries are check-marks.Decision tables. associate conditions with actions to perform. like flowcharts and if-then-else and switch-case statements. Each action is a procedure or operation to perform. In decision table conditions are known as causes and serinal numbers of conditions are known as business rule. relation or predicate whose possible values are listed among the condition alternatives. . The four quadrants Conditions Condition alternatives Actions Action entries Each decision corresponds to a variable. The following is a balanced decision table. representing which of the actions in a given column are to be performed. decision tables vary widely in the way the condition alternatives and action entries are represented[2][3]. In some cases. especially when a given condition has little influence on the actions to be performed. or in more advanced decision tables. but in many cases do so in a more elegant way. A technical support company writes a decision table to diagnose printer problem A technical support company writes a decision table to diagnose printer problems based upon symptoms described to them over the phone from their clients. Aside from the basic four quadrant structure. In the 1960s and 1970s a range of "decision table based" languages such as Filetab were popular for business programming. In a similar way. Structure A decision table is typically divided into four quadrants. The condition alternatives are simple boolean values. as shown below. entire conditions thought to be important initially are found to be irrelevant when none of the conditions influence which actions are performed. a hyphen. Example The limited-entry decision table is the simplest to describe. action entries can simply represent whether an action is to be performed (check the actions to perform). the sequencing of actions to perform (number the actions to perform). Many decision tables include in their condition alternatives the don't care symbol. Some decision tables use simple true/false values to represent the alternatives to a condition (akin to if-then-else). other tables may use numbered alternatives (akin to switch-case). Using don't cares can simplify decision tables. and the entries specify whether (or in what order) the action is to be performed for the set of condition alternatives the entry corresponds to. and some tables even use fuzzy logic or probabilistic representations for condition alternatives[citation needed]. Decision table can be used if the combination of conditions are given.

Software Design. it demonstrates how decision tables can scale to several conditions with many possibilities. . the whole process of software development is divided into separate process phases. so the name "Waterfall Model". this is just a simple example (and it does not necessarily correspond to the reality of printer troubleshooting). Waterfall approach was first Process Model to be introduced and followed widely in Software Engineering to ensure success of the project.Printer troubleshooter Rules Printer does not print Conditions A red light is flashing Printer is unrecognised Check the power cable Check the printer-computer cable Actions X Y Y Y Y N N N N Y Y N N Y Y N N Y N Y N Y N Y N X X X X X X X X Ensure printer software is installed X Check/replace ink Check for paper jam X X X Of course. and may mean different things to people in different roles. All the methods and processes undertaken in Waterfall Model are more visible Software documentation or source code documentation is written text that accompanies computer software. but even so. In "The Waterfall" approach. All these phases are cascaded to each other so that second phase is started as and when defined set of goals are achieved for first phase and it is signed off. Implementation and Testing & Maintenance. It either explains how it operates or how to use it. The phases in Waterfall model are: Requirement Specifications phase.

interfaces. marketing. project managers. customers. or qualities of a system. algorithms. distributed work environment). Thus.Documentation of code.Statements that identify attributes.. Requirements . builds can be started by right-clicking a configuration file and select the 'build' function). Technical .4 User documentation o 1. End User .g. and APIs. It is also used as an agreement or as the foundation for agreement on what the software shall do. to name a few. requirements documentation has many different purposes. notations and formality. 5. software architects.g. Includes relations to an environment and construction principles to be used in design of software components. as detailed mathematical formulas. and it is difficult to know how to document requirements considering the variety of people that shall read and use the documentation. Requirements are produced and consumed by everyone involved in the production of software: end users. Types of documentation include: 1. 2.2 Architecture/Design documentation o 1. usability experts. Requirements come in a variety of styles. as drawn figures.Overview of softwares.Contents [hide] • • • • 1 Involvement of people in software life o 1.Manuals for the end-user.. system administrators and support staff. close to design (e. interaction designers. developers.1 Requirements documentation o 1.How to market the product and analysis of the market demand. They can be specified as statements in natural language. Architecture/Design . Requirements documentation Requirements documentation is the description of what a particular software does or shall do. Requirements may be implicit and hard to uncover. requirements documentation is often . characteristics. It is used throughout development to communicate what the software does or shall do. This is the foundation for what shall be or has been implemented. capabilities. sales. Requirements can be goal-like (e. and as a combination of them all. product managers. and anything in between. The variation and complexity of requirements documentation makes it a proven challenge. Marketing .5 Marketing documentation 2 Notes 3 See also 4 External links Involvement of people in software life Documentation is an important part of software engineering.3 Technical documentation o 1. Thus. 4. and testers. 3. It is difficult to know exactly how much and what kind of documentation is needed and how much can be left to the architecture and design documentation.

more formal requirements documentation is often required. and enumerate the pros and cons of each. These documents do not describe how to program a particular routine. It may suggest approaches for lower level design. If the software is a first release that is later built upon. Traditionally. Another breed of design docs is the comparison document.. If the software is safety-critical and can have negative impact on human life (e. using word processing applications and spreadsheet applications).g. It could be at the user interface. A very important part of the design document in enterprise software development is the Database Design Document (DDD). mobile phone software). requirements can help to better communicate what to achieve. and code documents being first). database-centric systems and special-purpose requirements management tools are advocated. Architecture/Design documentation Architecture documentation is a special breed of design document. and the life expectancy of the software. requirements documentation is very helpful when managing the change of the software and verifying that nothing has been broken in the software when it is modified.. but leave the actual exploration trade studies to other documents. and Physical Design Elements. or trade study. If the software is very complex or developed by many people (e. not as a marketing technique. or even architectural level. This would often take the form of a whitepaper. Very little in the architecture documents is specific to the code itself. The purpose of preparing it is to create a common source to be used by all players within the scene. but instead merely lays out the general requirements that would motivate the existence of such a routine. It contains Conceptual. It should honestly and clearly explain the costs of whatever solution it offers as best. It focuses on one specific aspect of the system and suggests alternate approaches. In a way. expresses its idea clearly (without relying heavily on obtuse jargon to dazzle the reader).incomplete (or non-existent). To manage the increased complexity and changing nature of requirements documentation (and software documentation in general).. requirements are specified in requirements documents (e. rather than to push a particular point of view. The potential users are: • • Database Designer Database Developer . architecture documents are third derivative from the code (design document being second derivative. software changes become more difficult—and therefore more error prone (decreased software quality) and timeconsuming (expensive). The DDD includes the formal information that the people who interact with the database need. The objective of a trade study is to devise the best solution. design. It should be approached as a scientific endeavor.g. describe one or more alternatives. the impact of the product. or to conclude that none of the alternatives are sufficiently better than the baseline to warrant a change.g.g. A good trade study document is heavy on research. If the software is expected to live for only a month or two (e. medical equipment). The need for requirements documentation is typically related to the complexity of the product. code. Without proper requirements documentation. It is perfectly acceptable to state no conclusion. nuclear power systems. Logical. A good architecture document is short on details but thick on explanation. very small mobile phone applications developed specifically for a certain campaign) very little requirements documentation may be needed. or even why that particular routine exists in the form that it does. and most importantly is impartial. It will outline what the situation is.

Often. they extract the comments and software contracts. Many programmers really like the idea of auto-generating documentation for various reasons. especially in the software field. There must be some text along with it to describe various aspects of its intended operation. Today. o Cardinality of referential constraints o Cascading Policy for referential constraints o Primary keys It is very important to include all information that is to be used by all actors in the scene. industry automation and a variety of other domains. Code documents are often organized into a reference guide style. because it is extracted from the source code itself (for example. energy. Sandcastle. This documentation may be used by developers. the document should include following parts: • • Entity . where available. TwinText. NDoc. transportation. POD. Technical documentation This is what most programmers mean when using the term software documentation. foreign keys. When creating software. or Universal Report can be used to auto-generate the code documents—that is. For example. Several How-to and overview documentation are found specific to the software application or software product being documented by API Writers. including following information and their clear definitions: o Entity Sets and their attributes o Relationships and their attributes o Candidate keys for each entity set o Attribute and Tuple based constraints Relational Schema.Relationship Schema. including following information: o Tables. technical documentation has gained lot of importance in recent times. but not so verbose that it becomes difficult to maintain them. including following information and their clear definitions: When talking about Relational Database Systems. code alone is insufficient. It is important for the code documents to be thorough. Attributes. the document should include following parts: • Entity . security.Relationship Schema. we see lot of high end applications in the field of power. aerospace. javadoc. testers and also the end customers or clients using this software application. It is also very important to update the documents as any change occurs in the database as well. safety.• • • Database Administrator Application Designer Application Developer When talking about Relational Database Systems. networks. Technical documentation has become important within such organizations as the basic and advanced level of information may change over a period of time with architecture changes. Hence. EiffelStudio. and their properties o Views o Constraints such as primary keys. ROBODoc. allowing a programmer to quickly look up an arbitrary function or class. from the source code and create reference manuals in such forms as text or HTML files. through . tools such as Doxygen.

writing at the same time and location as the source code and extracted by automatic means. in which they are guided through each step of accomplishing particular tasks [1]. In the case of a software library. On the other hand. This level of ease of use is unheard of in putatively more modern systems. This paradigm was inspired by the same experimental findings that produced Kelp. Donald Knuth has insisted on the fact that documentation can be a very difficult afterthought process and has advocated literate programming. but for a general application this is not often true. is of more general use to an intermediate user. Such annotations are usually part of several software development activities. This . Lisp users could look up documentation prepared by these API Writers and paste the associated function directly into their own code. Thematic: A thematic approach. and it depends on them to refresh the output (for example. The Elucidative paradigm proposes that source code and documentation be stored separately. and instead simply describe how it is used. See also Technical Writing. 2. There are three broad ways in which user documentation can be organized. Annotations can therefore help the developer during any stage of software development where a formal documentation system would hinder progress. Consistency and simplicity are also very valuable. User documentation Unlike code documents. but it is very important for them to have a thorough index. Elucidative Programming is the result of practical applications of Literate Programming in real programming contexts. and assists the user in realizing these features.comments). the programmer can write it while referring to the code. This makes it much easier to keep the documentation up-to-date. Tutorial: A tutorial approach is considered the most useful for a new user. In combination with strong search capabilities (based on a Unixlike apropos command). linking the information to the source code dynamically. where chapters or sections concentrate on one particular area of interest. a downside is that only programmers can edit this kind of documentation. the user documentation describes each feature of the program. and online sources. Often. A good user document can also go so far as to provide thorough troubleshooting assistance. Kelp stores annotations in separate files. the code documents and user documents could be effectively equivalent and are worth conjoining. by running a cron job to update the documents nightly). such as code walks and porting. 1. and for them to be up to date. software developers need to be able to create and access information that is not going to be part of the source file itself. user documents are usually far more diverse with respect to the source code of the program. where third party source code is analysed in a functional way. User documentation is considered to constitute a contract specifying what the software will do. User documents need not be organized in any particular way. It is very important for user documents to not be confusing. and use the same tools used to create the source code to make the documentation. Some would characterize this as a pro rather than a con. Of course. Some authors prefer to convey their ideas through a knowledge based article to facilitating the user needs. API Writers are very well accomplished towards writing good user documents as they would be well aware of the software architecture and programming techniques used. the Lisp machine grew out of a tradition in which every piece of code had an attached documentation string. Typically.

Those are the components of any information system. and many other computer professionals who utilize the computer-based information systems are the personnel in a management information system Added in edit: Many people would also include data. This latter approach is of greater use to advanced users who know exactly what sort of information they are looking for. users. not just an MIS. To completely shroud the function of the product in mystery. which an organization establishes for the use of a omputer-based information system Personnel The computer experts. This form of documentation has three purposes:1. and also emphasize the interoperability of the program with anything else provided by the manufacturer.approach is usually practiced by a dynamic industry. managers. 2. One good marketing technique is to provide clear and memorable catch phrases that exemplify the point we wish to convey. analysts. so that their expectations are in line with what they will be receiving. Marketing documentation For many applications it is necessary to have some promotional materials to encourage casual observers to spend more time learning about the product. such as Information technology. 4. 3. A common complaint among users regarding software documentation is that only one of these three approaches was taken to the near-exclusion of the other two. programmers. HardwARE Input and output devices constitute the hardware components of MIS Software The programs and applications that convert data into machine-readable language are known as software Procedures Procedures are sets of rules or guidelines. It is common to limit provided software documentation for personal computers to online help that give only reference information on commands or menu items. who are often given significant assistance by the software developer. [3]. . often via cross-referenced indexes. usually positioned between software and procedures in the above list. The job of tutoring new users or helping more experienced users get the most out of a program is left to private publishers. To excite the potential user about the product and instill in them a desire for becoming more involved with it. database managers. To inform them about what exactly the product does. where the user population is largely correlated with the troubleshooting demands [2]. To explain the position of this product with respect to other alternatives. 3. List or Reference: The final type of organizing principle is one in which commands or tasks are simply listed alphabetically or logically grouped.

Sign up to vote on this title
UsefulNot useful