Docstoc

MICROCOMPUTER SYSTEMS

Document Sample
MICROCOMPUTER SYSTEMS Powered By Docstoc
					                                           SOFTWARE DEVELOPMENT M1-U2:




                       SOFTWARE DEVELOPMENT LIFECYCLE

1.       Problems with Software
         It is not uncommon in the computer industry to find projects which have resulted in a poor product,
         delivered late and over budget. Most problems with large scale computer system projects relate to
         non-hardware issues. Developing software for large-scale systems is much more difficult than
         development for smaller projects.

         The issues concerned include:

                  Complexity
                   the more complex a task the more likely errors will be introduced. Modularisation of a
                   large, complex task into smaller sub-tasks can reduce the overall complexity

                  Size:
                   as the size of a project increases, the number of individuals involved increases leading to
                   increased communicational complexity and thus higher probability of errors occuring. This
                   requires a clear medium of communication that is reliable and complete.

                  Timescales:
                   Quality of software versus cost of lateness

                  Cost:
                   software is now the predominant factor in computer system cost, far exceeding hardware
                   cost.

                  Management:
                   Good project planning vital to development of quality software on time.

2.       Software Engineering
2.1      Introduction
         In today‟s computer driven society, there is an ever increasing demand for more complex software
         applications at low cost to the consumer. It is therefore, important that software developers can
         produce these applications as efficiently as possible, whilst maintaining high reliability and quality.

         Software Engineering is the systematic approach to the development of medium to large-scale
         software systems, usually involving teams of programmers.

         It includes
                  Good software development techniques required to minimise programming errors and
                   localise the scope of errors.

                  The development of the documentation necessary to install, use, develop and maintain the
                   programs is crucial;

                  Cost-effective software development




c3bd235b-a20b-41fd-8595-60beb23a0369.doc         Page 1-2-10
                                           SOFTWARE DEVELOPMENT M1-U2:




2.2      Aim of Software Engineering
         The aim is to develop software which is:
             RELIABLE
                Software should perform as expected by the user. This is particularly important in safety or
                life-critical areas such as Avionics, chemical plant, medical systems.

                  MAINTAINABLE
                   Software should be written so that changes can be made without undue cost.

                  EFFICIENT
                   Software should not make wasteful use of system resources.

                  USABLE
                   Software should have an appropriate user interface. For example, ease of use, ease of
                   learning, presentation, attractive.

                  SECURE
                   This includes confidentiality and access rights.

3.       Software development model
         For most programming students, initially most of your time is spent entering and debugging code,
         and not enough time designing your program. However in industry programmers usually work as
         part of a team for large software development projects. Programming is a lot more involved than
         simply writing code, the problem analysis and documentation of this is a crucial part of
         programming.

         The main idea of software engineering, as with other types of engineering, is that the development of
         software is a multistage process. The outputs of one stage are the inputs to another. These inputs
         and outputs are descriptions of behaviour, the notation of which we will look at in this course.

         By following a pre-specified model, a project should increase the quality of its process. Software
         Evolution represents the cycle of activities involved in the development, use and maintenance of
         software systems. The series of steps through which a software product progresses is called a “life
         cycle” model.

         Formal Definition of “Software Life Cycle”
         “The period of time that starts when a software product is conceived and ends when the product is no longer
         available for use. The software life-cycle typically includes a requirements phase, design phase,
         implementation phase, test phase, installation and check-out phase, operation and maintenance phase, and
         sometimes, retirement phase.” From the IEEE Standard Glossary of Software Engineering Terminology, 1983

         There are a number of models for software development lifecycle, for example:
                  Build and fix model
                  Classic Software Life Cycle: The Waterfall Model
                  Rapid prototyping
                  Incremental model
                  Spiral model




c3bd235b-a20b-41fd-8595-60beb23a0369.doc         Page 1-2-10
                                           SOFTWARE DEVELOPMENT M1-U2:




3.1      Build and fix model
         Build-and-Fix Model is a “trial and error” approach. This is a simple approach of product
         construction without specification or attempt of design. This model is adequate for simple software
         programs (100 to 200 lines of code), however it is unacceptable for large and complex systems.
                                                            Build 1st
                                                             version




                                                                Modify until
                                                                customer is
                                                                 satisfied




                                                                    Use



                   Figure 1-2-1       Build and Fix Life-cycle Model

3.2      Waterfall Model
         The Waterfall Model is represented as a simple waterfall software phase model shown in the figure
         below. Software evolution proceeds through an orderly sequence of transitions from one phase to
         the next in linear order. This approach does not emphasize feedback and does not apply directly to
         real projects as it is very difficult to define explicitly all requirements from start and often working
         versions of software are available quite late. Also, it should be noted that different organizations
         have different labels for stages.

                           Requirement
                             Analysis
                                               User Requirement
                                               Documentation

                                 Specification
                                               Software Specification
                                               Documentation
                                                                                              Quality
                                            Design                                           Assurance
                                                      Design Documentation


                                              Implementation
                                                                   Programs

                                                           Maintenance
                                                                          Revised Programs


                   Figure 1-2-2       Traditional Waterfall Life-cycle Model

c3bd235b-a20b-41fd-8595-60beb23a0369.doc          Page 1-2-10
                                           SOFTWARE DEVELOPMENT M1-U2:



             Requirement Analysis:
              This stage involves getting the „user requirements‟ from the customer, i.e. what is the required
              purpose of the software. The requirements should be clearly defined before a solution can be
              formulated. It is important to have a clear understanding of the problem to be solved. The user
              requirements statement should be carefully examined to determined what information is given
              and what information needs to be clarified.

             Specification:
              This is also referred to as System Analysis and involves detailing the required functions of the
              software. The underlying concepts and principles inherent to the problem must be clearly
              understood. The information needed to solved the problem (inputs) and the required outputs are
              identified and as well as the relationship between inputs and outputs. These relationships may
              be expressed in mathematical equations.

             Design
              This involves creating descriptions of a software system in terms of how it is to carry out the
              functions. A list of steps called an algorithm to meet the user requirements is developed and
              verified.

             Implementation:
              This is the process of converting the algorithm into the desired programming language.

             Maintenance
              This occurs after the software is released and consists of modifications to software due to error
              reports and making modifications to the program to incorporate additional features due to new or
              changed requirements.

             Quality Assurance
              This affects all stages of the life-cycle, i.e. each step in the development process is checked to
              ensure the delivered product satisfies the user requirements. Quality Assurance includes
               Validation which is where the output is checked against the user‟s requirements. This takes
                  place at all stages of the life cycle. When the program is completed, the programmer uses
                  test data to confirm that the program is working correctly. Testing usually uncovered errors
                  during implementation, but often errors caused earlier in the life-cycle are also uncovered.
               Verification which checks the notation used in one stage is transformed correctly into the
                  notation used in the next stage.

             Documentation:
              Program documentation should be included so that the intended users can understand the
              program and use it effectively. Internal documentation is required for each stage of the life-
              cycle. External documentation includes: user manuals and technical references.

3.3      Rapid Prototyping
         Construction of prototypes is standard practice in engineering. Requirements can be
         validated by prototyping, thus reducing risk. Prototypes are used during feasibility studies
         and are often constructed from reusable parts. Typically used for 4GL development
         projects.




c3bd235b-a20b-41fd-8595-60beb23a0369.doc         Page 1-2-10
                                           SOFTWARE DEVELOPMENT M1-U2:



3.4      Incremental Model
         In this model, maintenance is no longer a stage, i.e. "Maintenance" phases become subsequent cycles
         through the waterfall sequence. This means that risk is spread and each cycle produces a usable
         system, although the first may be a pre-production prototype.

         The product is designed, implemented, integrated and tested as a series of incremental builds
         Stepwise refinement and iterative enhancement (use prototyping as a means of refinement and
         enhancement of specification).




                   Figure 1-2-3       Incremental Model

         Incremental release is better than Waterfall but requires strict configuration management so each
         build is incorporated into the existing structure without destroying what has been already build and
         to avoid continuous change of requirements.

3.5      Spiral Model
         This is an incremental prototype-based model that implements risk management. Each cycle
         produces something to be evaluated, but not necessarily a usable system. Management of risk is
         built into model and each cycle ends with the question "should we continue?"

         This risk-driven approach supports the reuse of existing software, continuous verification (thus
         alleviating the problem of adequate testing). Weaknesses: Intended for internal development of
         large-scale software (problems when customers are members of the same organisation), only large-
         scale projects, time consuming.


                                                 Determine           Risk
                                                 objectives       Analysis

                                                 Customer
                                                 review




                                                 Plan next     Engineering/
                                                 phase         Development




                   Figure 1-2-4       Spiral Model




c3bd235b-a20b-41fd-8595-60beb23a0369.doc         Page 1-2-10
                                           SOFTWARE DEVELOPMENT M1-U2:



4.       Requirement Analysis and Specification

                                                                    1. Separate WHAT the software should do from the HOW
               Requirement Analysis                                    the software should work.

                                                                    2. Separate functional and non-functional requirements
                                User requirements                      (constraints)

                                                                    3. Identify any goals to guide system design
                      Specification                                 4. Identify inputs, output and relationships between them

                                 Functiomal Specification           5. Describe the tests required to ensure the software meets
                                 any contraints and goals              its specification
                       Figure 1-2-5

4.1      Requirements Analysis
         The very first step in developing a software system is deciding what the customer wants. The
         customer has certain requirements and requirements analysis is the term used for determining and
         under standing these requirements. Requirement analysis is an important part of the development
         lifecycle as it is important to clarify your task before you begin and thus prevent wasted efforts in
         developing software that is not what the customer wants.

         A first step in requirements analysis is to analyse the problem to determine whether it is feasible or
         even possible to solve it by using a computer program. Perhaps the effort involved developing a
         computerised solution is not worthwhile, given the scale of problem. Assuming that a computerised
         solution should be pursued, the nature of the problem needs to be nailed down, for example:

                  What is the task to be done?
                  What are the input data available to carry out this task?
                  What is the desired output or result?
                  Are there any exceptional situations that may arise in the context of this task, and if so, how
                   should they be handled?
                  Are there special requirements (due to regulations, standard industry practice, company
                   policy, and so on) about how the task must be solved?
                  Are there related tasks that ought to be done at the same time?
                  Do input data already exist in electronic form? If so, what is the size of the data file? What is
                   the format of the data stored in the file?
                  What is the desired format of the output?

         All these issues might be termed functional requirements, because they are concerned with the
         functionality of the program to be written, that is, the job to be done. If a program fails to meet its
         functional requirements, it is basically giving "wrong answers" to the problem it is supposed to
         solve.

         But in addition to functional requirements that are concerned with what the program will do, there
         are also non-functional requirements that are concerned with how the program acts while it is
         doing its job, for example:

                  What should the user interface look like?
                  How long should the program take to produce its results?
                  What is the amount of computer memory needed for the program to run?
                  How easy is it for the typical user to run the program?


c3bd235b-a20b-41fd-8595-60beb23a0369.doc              Page 1-2-10
                                           SOFTWARE DEVELOPMENT M1-U2:




         The customer may have only a general idea of what he or she wants done. It is part of the software
         development process to work with the customer to elicit the total requirements for the program. A
         variety of techniques exist for talking through requirements, involving the customer, the software
         developer (who is often at this stage called a systems analyst), and perhaps a representative of the
         eventual program users. Continuing involvement of the customer, the developer, and the user
         throughout the software development process is more likely to produce a product that will satisfy the
         needs of the customer.

         The result of the requirement analysis process is a complete understanding of the functional and
         performance requirements. This is usually captured in a written document that will become part of
         the total documentation package of the program, called user requirement documentation. The user
         requirements are usually stated in the language of the customer, not the language of the software
         developer.

4.2      Specification
         These requirements often have to undergo a translation process into a tighter and more technical
         form that can be turned over to the software designers. This process is called specification or
         system analysis. The result is another piece of the documentation package, called the Software
         Specification document: includes Functional Specification and Test Specification, and may also
         include: data specification, hardware specification, performance specification and training
         specification. The specification document will be referred to often during program design,
         implementation, and testing to be sure that the program being developed meets the specifications.

         This process of requirements analysis and specification may seem unnecessary in light of the
         programs you have so far written. These programs, however, have been very small. The larger the
         project, the more care must be taken in all the steps of its development, beginning with requirements
         analysis and problem specification.




c3bd235b-a20b-41fd-8595-60beb23a0369.doc         Page 1-2-10
                                           SOFTWARE DEVELOPMENT M1-U2:



                                       SOFTWARE DESIGN STAGE
5.       DESIGN:
         The next step in program development after requirement analysis and specification is the design
         stage. You have an understanding of the job to be done; now you must begin to plan how to do it.

         Whereas the specification stage deals with WHAT the user requires, the design stage examines
         HOW the requirement is to be implemented. The objective is to develop the specification to the
         stage where it can be implemented as a piece of software. The design stage also includes the
         development of test procedures for the software.

         The main steps involved in the software design stage include:
             System Design: partition system into modules
             Detailed Design: develop algorithms for each module, includes flowcharts and pseudocode
             Data Design: adopt suitable data structures for the algorithms to operate upon
             Testing Procedures

5.1      Top-Down Design
         The accepted philosophy in developing a program is to do a top-down design. To understand what
         this means, suppose that your assignment is to design and build a completely new automobile. There
         are thousands of parts in an automobile, so viewed as whole, this is a staggering task. However, you
         know that you can approach the job by viewing the car as the sum of components that work together-
         engine, transmission, brake system, and so on. You can decide on the components you need and how
         they will work together. After that you can turn your attention to each of the components and break
         them down into sub-components that work together. You refine your level of detail at each step,
         until finally you reach the lowest level, where the individual pieces should be simple enough to
         design in their entirety without difficulty.

         In large-scale software development projects it is necessary to follow a systematic design procedure
         because of the complexity of the problem and the need to manage large amounts of detail. By
         breaking a large task down into smaller sub-tasks, these sub-tasks can be dealt with separately and
         the overall task become more manageable. This is the philosophy of Top-Down Design.

         Top-down design consists of two techniques:
                Decomposition
                Step-wise refinement

         The first step in the algorithm development process is a statement of the problem in general terms.
         The next step consists of decomposing the problem into a series of smaller sub-problems and
         addressing each sub-problem individually. The solution is written in English and each part of the
         overall problem is described in general terms. Problem decomposition outlines the major steps to be
         performed in solving the problem.

         In the stepwise refinement technique, you start with general English language description of the
         steps to the problem solution and successively refine each step in greater detail. With each iteration,
         one step of the algorithm is chosen for refinement and more detail is added. For large programs,
         there is usually many levels of refinement. The refinement process is continued until each step is
         detailed enough to convert to code.

         Top-down design provides us with a procedure for developing well-designed modular programs. It
         enables program development on various levels, each level being obtained from the previous level.
         It helps reduce complexity.

5.2      Modular Design
         When a system is designed using Top-Down design, the problem is broken down into smaller more
         manageable sub-problems, each problem is then considered independently. The program is this

c3bd235b-a20b-41fd-8595-60beb23a0369.doc         Page 1-2-10
                                           SOFTWARE DEVELOPMENT M1-U2:



         decomposed into a number of smaller independent modules. A module usually has its own
         instructions and data. For example, a module is implemented using functions in the C language.

         With Modular design, the overall task is performed by the main program and each sub-task is
         performed by a separate module. The main program has some external inputs and outputs, a module
         may also have external inputs and outputs, but it also will have internal input-output relationships
         with other modules.

         Modules should be designed as follows:
           1. A module should be relatively small and self contained. Opinions differ of what the
               optimum size of a module should be. If a module is too small there will be added overhead
               due to extra inter-module communication causing the program to run slower, however if the
               modules are too large, the complexity increases and the benefits of modularity are lost. As a
               guideline, a module should be no more than one or two pages.

              2. A module should have only one entry point, i.e. it should only be accessed as a single unit
                 which can be updated or replaced without having to change other segments of the program.

              3. A module should be independent and self-contained allowing it to be developed and tested
                 separately.

              4. Changes in a module should not affect other modules

              5. Each module should perform a single well-defined function. This will facilitate reuse of
                 modules in other programs

              6. A module should have a well-defined interface. The interface defines the inputs required by
                 the module to perform its function and the output returned by the module.

         A main advantages of modular design is that it limits complexity and simplifies the design of the
         program, making it easier to follow and understand.

         Modular programs

                  Are easier to write and debug.

                  Are easier to maintain and update. Updating a module should not lead to many knock-on
                   affects as the modules are independent.

                  Aid independent development. More than one programmer can work in parallel on a
                   program, i.e. different programmers can work on different modules and test the modules
                   separately before testing the overall program.

                  It aids the software reuse – i.e. reuse of previously written and tested modules

         Thus modular design leads to faster development times and improved quality.




c3bd235b-a20b-41fd-8595-60beb23a0369.doc         Page 1-2-10
                                           SOFTWARE DEVELOPMENT M1-U2:




6.




c3bd235b-a20b-41fd-8595-60beb23a0369.doc         Page 1-2-10

				
DOCUMENT INFO