Textbook Notes (368,780)
Canada (162,164)
ITM 305 (71)
Jim Tam (16)
Chapter

Construction.docx

6 Pages
76 Views
Unlock Document

Department
Information Technology Management
Course
ITM 305
Professor
Jim Tam
Semester
Fall

Description
Chapter 12 Construction Construction This chapter discusses the activities needed to successfully build the information system: programming, testing, and documenting the system. Introduction  When projects fail, it is usually not because the programmers were unable to write the programs but because the analysis, design, installation, and/or project management were done poorly.  Construction is the development of all parts of the system, including the software itself, documentation, and new operating procedures.  Most professional organization devote more time and more to testing than to writing the programs in the first place Managing programming  The first step in programming is assigning models to the programmers  The project manager first groups together class that are related so that each programmer is working on related classed.  One rule of system development is that the more programmers who are involved in a project, the longer the system will take to build.  The best strategy is to try to break the project into a series of smaller parts that can function as independently as possible. Coordinating activities  The simplest approach is to have a weekly project meeting to discuss any changes to the system that have arisen during the past week, or just any issues that have come up  Improve coordination is to create and follow standard that can range from formal rules for naming files to forms that must be completed when goals are reached to programming guidelines.  Many project teams set up three “areas” in which programmers can work: a development area, a testing area, and a production area  At first, programmers access and build files within the development area and then copy them to the testing are when the programmers are “finished”.  One of the more important things to coordinate is the traceability of the implementation of the system back to the original requirements.  Each class and method must be associated with an individual requirement or a set of requirements.  If a case tool is used during the construction step, it can be very helpful for change control because many case tools are set up to track the status of programs and help manage programmers as they work.  In most cases, maintaining coordination is not conceptually complex. It just requires a lot of attention and discipline to track small details. 1 Chapter 12 Construction Managing the schedule  It is virtually impossible to develop an exact assessment of the project’s schedule.  A well-done set of time estimate will usually have a 10 percent margin of error by the time you reach the construction step.  Scope creep occurs when new requirements are added to the project after the system design was finalized.  Scope creep can be very expensive because changes made late in the SDLC can require much of the completed system design to be re-done.  Any proposed change during the construction phase must require the approval of the project manager and should only be done after a quick cost-benefit analysis has been done.  Another common cause is the unnoticed day-by-day slippage in the schedule. One package is a day later her, another one a day later there, pretty soon these minor delays add up, and the project is noticeably behind schedule.  A project manager will create a risk assessment that tracks potential risks along with an evaluation of their likelihood and potential impact. Designing tests  In object-oriented systems, the temptation is to minimize testing. After all, through the use of patterns, frameworks, class libraries, and components, much of the system has been tested previously. Therefore, we should not have to test as much. Right? Wrong!! Testing is more critical to object-orient system than to systems developed in the past.  Based on encapsulation, polymorphism, inheritance, and reuse, thorough testing is much more difficult and critical.  The purpose of testing is not to demonstrate that the system is free of error.  If a test fails to find problems with a theory, your confidence in the theory is increased.  However, if a test succeeds in finding a problem, then a theory has been falsified.  The purpose of testing is to uncover as many errors as feasible.  There are four stages of testing: unit tests, integration tests, system tests, and acceptance tests. Testing and Object-orientation  Most testing techniques have been developed to support non-object-oriented development.  The sheer volume of products that come out of a typical object-oriented development process has increased the importance of testing in object-oriented development Encapsulation and information hiding  Encapsulation and information hiding allow process and data to combine to create holistic entities.  Furthermore, they support hiding everything behind a visible interface, which makes testing the system problematic.  A second issue raised by encapsulation and information hiding is the definition of a “unit” for testing.  A third issue raised is the impact on integration testing. In this case, objects can be aggregated to form aggregate objects; for example, a car has many parts, or they can be grouped together to form collaborations. 2 Chapter 12 Construction Polymorphism and Dynamic binding  Polymorphism and dynamic binding dramatically impact both unit and integration testing.  With polymorphism and dynamic binding, the same method can be implemented in many different objects  Testing individual implantations of methods made no sense. Inheritance  Through the use of inheritance, bugs can be propagated from a super-class to all of its direct and indirect sub-classes instantaneously.  Inheritance is a double-edged sword Reuse  Each time a class is used in a different context, the class must be tested again Object-oriented development process and products  Testing is always covered near the end of the SDLC  Each and every product that comes out of object-oriented development process must be tested  It is a lot cheap to catch this type of error back in analysis phase than it is in the implementation phase.  Testing must be placed throughout the life span of a SDLC not just the end Test planning  Test plan that defines a series of tests that will be conducted test plan should be developed at the very beginning of the SDLC and continuously updated as the system evolves.  The test plan should address all products that are created during the development of the system.  Not all classes are likely to be finished at the same time, so the programmer usually writes stubs for the unfinished classes to enable the classed around them to be tested.  A stub is placeholder for a class that usually displays a simple test message on the screen or returns some hardcoded value.  A stub would be written for each of the classes on the other layers that interact with the problem domain class.  Stubs would contain the minimal interface necessary to be able to test the problem domain classes.  Typically, the methods would display a message on the screen notifying the tester that the method had been successfully reached. Unit test  Unit tests focus on a
More Less

Related notes for ITM 305

Log In


OR

Join OneClass

Access over 10 million pages of study
documents for 1.3 million courses.

Sign up

Join to view


OR

By registering, I agree to the Terms and Privacy Policies
Already have an account?
Just a few more details

So we can recommend you notes for your school.

Reset Password

Please enter below the email address you registered with and we will send you a link to reset your password.

Add your courses

Get notes from the top students in your class.


Submit