GALGOTIAS University

(1)

GALGOTIAS University

LABORATORY MANUAL

CSE-208: Software Engineering Lab

SESSION 2012/2013 SEMESTER 4

SCHOOL OF COMPUTTING SCIENCE AND ENGINEERING

GALGOTIAS UNIVERSITY

(2)

PROJECT PLANNING

1. OBJECTIVES

The objectives of this experiment are to learn:

1.1 Project Team Formation: Form a project team and appoint a project manager.

1.2 Client Team Role: Assume the role of a Client. Discuss, evaluate and propose the requirements for a chosen real-world software project.

1.3 Project Requirements: Submit the Software requirement to your Lab Supervisor 1.4 Writing software requirements: Please look at the template to write the software

requirements

1.5 Developer Team Role: Assume the role of a Developer Team.

1.6 Project Schedule Preparation: Develop a project schedule and organize your project team.

2. LABORATORY

Software Engineering Laboratory

3. EQUIPMENT

3.1 Pentium PC

3.2 Tools can be installed according to your requirements

4. INTRODUCTION

In the project-planning phase, it is usual that the system requirements are first determined. At least, the preliminary requirements are made known at a brainstorming session with the users. Next, the necessary resources are allocated.

Allocation includes recruiting or deploying the necessary expertise to form the project team.

In our case, we try our best to simulate this scenario as closely as possible within the

(3)

beginning as a Client Team. The same team later on will take on the role of the Developer Team.

Role of Client Team: Each group will prepare an informal requirements document for the project (title to be provided if you really can't select a real-world practical project) and be responsible for its evaluation and criticism as it progresses. In effect, you will be the Client for the system. You will be expected to be present at all presentations by your Developer, and comment on the weekly progress write-ups/documents maintained by your Developer. Your grade will depend on how thoroughly the evaluation is carried out, the extent to which it is fair and reasonable and the extent with which it agrees with the judgments of your instructor. Groups are advised to meet the instructor and discuss any problems or disagreements with the progress.

Role of Developer Team: Your group will receive informal requirements for a system from the lab supervisor, and will produce a more formal specification, produce the analysis and design, code a prototype, evaluate and refine the prototype, and present a final product according to the details below. You will be the Developer of the system. You are expected to meet your Client during the preparation of the formal specification as well as during the different stages of the project. Presentations and discussions will be required at various points within the project, and will be evaluated and assessed by the Client. You should submit all weekly write-ups/documents preferably on the web, before the required date (at least 1 day before the next lab class). All documents should have a title page which has on it the title of your project, the name of your group, a list of members indicating who was responsible for which parts, and the date. You should notify (by email) all interested parties concerning any re-submitted documents as soon as they are completed. Groups are required to discuss any problems or disagreements with the instructor. Marks will normally be deducted for documents that are late.

5. EXPERIMENT

Before you even touch the keyboard, your first job is to become a member in a project team. It is entirely your choice to join a particular team or the team’s choice to include or reject you as a member. However, each team must not have more than 5 members and all members must sit in the same row. Teams with more than 5 members will be streamlined (dice may be used and then forcibly, if necessary!).

Appoint a project manager among your team members. It is the responsibility of a project manager to ensure that there is a fair distribution of work among the team members and that each member (including the manager) is pulling his/her own weight.

Refine your Client’s preliminary requirement specifications for your project and document them as part of your system specification using an editor (e.g. Microsoft Word) on the PC. The preliminary system specification provided to you should describe the information needed and used in the system.

Requirements should also describe the functionality of the system but not the procedural details. Use use case diagrams to visualize and refine your requirements.

When you have sufficient detail in your system specification to comfortably and equitably allocate work among your team members, develop your project schedule.

You have a total of 9 lab sessions including this one for project development. The last session is for project demo. Develop a project schedule to target completion on the before last 2 lab sessions. A formal guideline is shown below:

(4)

Week 2: Establish project team and preliminary system specifications

Week 3: Familiarization with software tools and refinement of system specifications Week 4: Analyze and model requirements

Week 5: Develop software design Weeks 6-7: Implementation and Testing Weeks 8-9: Testing and Integration

Although this corresponds closely to the formal lab schedule, note that you can do your development during free access as well.

Concurrently, assign roles and responsibilities to your team members (analysts, designers, programmers, testers etc.) and determine your project team organization.

Document your system specification, project schedule and team organization structure.

This will form part of your project report later.

REMEMBER TO BACKUP YOUR WORK ON DISKETTE (IMPORTANT).

6. REFERENCES

6.1 Rational Rose User's Guide.

6.2 Lecture Notes.

(5)

TOOLS FAMILIARIZATION 1. OBJECTIVE

The objective of this experiment is to enable project teams to familiarize themselves with the development platform and software tools used in their projects.

2. LABORATORY

3. EQUIPMENT (Same as in Experiment 1)

4. INTRODUCTION

4.1 This experiment enables you to familiarize yourself with the development environment offered by the Windows-based PC. You can develop your product during the scheduled lab sessions in this lab or during free access. All product demos will, however, be done on the PCs in the software engineering lab during the last two lab session.

4.2 Project teams may also choose to familiarize themselves with the programming environment they required to develop their project and the associated modeling tools.

4.3 A project team may have their own choice of programming language and tools.

4.4 The Rational Rose is a very comprehensive Computer-Aided Software Engineering (CASE) platform. It contains several contemporary software development methodologies. However, do note that a small number of notations in Rational Rose deviate slightly from standard UML.

4.5 To avoid corrupting your project and having to restart all over again, you are strongly advised to regularly take a backup of your work.

5. EXPERIMENT

5.1 You may install your own choice of software development tool and familiarize yourself with it.

5.2 In the course of the current lab session, you may need to update/refine your preliminary system specification and make changes to your project schedule and/or team organization structure.

5.3 REMEMBER TO BACKUP YOUR WORK ON DISKETTE (IMPORTANT).

6. REFERENCES

6.2 Lecture Notes.

(6)

REQUIREMENTS ANALYSIS

1. OBJECTIVE

The objective of this experiment is to enable each project team to analyze, model and refine the preliminary requirements of their allocated software project.

2. LABORATORY

4. INTRODUCTION

4.1 This experiment enables you to apply either the Object-Oriented or Function-Oriented approach to analyze, model and refine your preliminary system specification. The Object-Oriented approach is more suitable for data-intensive applications while the Function-Oriented approach may be used for applications that provide processing for simple or more straightforward data requirements.

4.2 With the Object-Oriented approach, you model your system specification with a preliminary Object Diagram. With the Function-Oriented approach, the system specification (or software statement of scope) is modeled as a series of Data Flow Diagrams (DFDs). Both analysis approaches will be covered in the lectures.

5. EXPERIMENT

5.1 Model your requirements using either Object Diagrams or Data Flow Diagrams depending on whether you wish to use the Object-Oriented or Function-Oriented approach respectively.

5.2 As you model, you may need to update or refine your earlier assumptions and requirements. It would be expedient if you assign a team member to update/refine your preliminary system specification obtained in Experiment while the system model is being worked out by other members who are assigned the role of analyst(s).

5.3 Print and keep a copy of your refined system specification (one copy is sufficient for each project team). For consistency as well, during development, all members should reference the same version of the system specification.

5.4 Remember to backup your work on diskette (IMPORTANT).

6. REFERENCES

6.2 Lecture Notes.

(7)

SOFTWARE DESIGN

1. OBJECTIVE

The objective of this experiment is to enable each project team to translate their refined system specification to a corresponding software design.

2. LABORATORY

4. INTRODUCTION

4.1 Depending on whether you applied the Object-Oriented or Function-Oriented approach to model your refined system specification, translate your model to the corresponding design adhering to the principles and guidelines of that approach. With the Object-Oriented approach, you model your system design with a refined Object Diagram. With the Function-Oriented approach, the system design is modeled as a Structure Chart.

4.2 During design, focus on issues of reusability, use of database, implosion and explosion (factoring), user-interface design, coupling and cohesion. If your software system makes use of exceptions and/or interrupts, you may have to consider task management issues as well.

5. EXPERIMENT

5.1 Model your system design using either refined Object Diagrams or Structure Charts depending on whether you are using the Object-Oriented or Function-Oriented approach respectively.

5.2 As you model, you may need to update or refine your earlier assumptions and requirements. It would be expedient if you assign a team member to update/refine your preliminary system specification obtained in Experiment 1 while the system design is being worked out by other members’ assigned designer roles.

5.3 Print and keep a copy of your system design (one copy is sufficient for each project team). For consistency during implementation, all members should reference the same version of the system design.

6. REFERENCES

6.4 Lecture Notes.

(8)

IMPLEMENTATION I

1. OBJECTIVE

The objective of this experiment is for each project team to translate their software design to code.

2. LABORATORY

4. INTRODUCTION

4.1 During implementation, the software design is converted to programming language code. It is assumed that a programming language or environment has already been selected at this stage.

5. EXPERIMENT

5.1 Refer to the manpower allocation information in your project schedule. Assign implementation work accordingly and equitably. You may need to reassign roles, e.g.

have more programmers, if you are behind schedule.

5.2 Create, compile, link and test your assigned objects or modules. You may also make use of the free access periods in this lab to continue your work.

6. REFERENCES

6.6 Lecture Notes.

(9)

IMPLEMENTATION II

1. OBJECTIVE

The objective of this experiment is for project teams to continue translating their software designs to code.

2. LABORATORY

4. INTRODUCTION

4.1 During implementation, the software design is converted to programming language code. It is assumed that a programming language or environment has already been selected at this stage.

5. EXPERIMENT

5.1 Continue and try to complete your implementation by this lab session. Alternatively, target for completion according to your project schedule. If necessary, make use of the free access periods in this lab to continue your work.

5.2 REMEMBER TO BACKUP YOUR WORK ON DISKETTE (IMPORTANT).

6. REFERENCES

6.8 Lecture Notes.

(10)

TESTING I

1. OBJECTIVE

The objective of this experiment is for project teams to test their implementations.

2. LABORATORY

4. INTRODUCTION

4.1 In the software engineering context, testing is regarded as a quality assurance activity. Its aim is to verify / ensure compliance of the software component under test with stated requirements.

4.2 There are two main categories of testing: static and dynamic. Static testing techniques include desk checking, walkthroughs, inspections, and compiling.

Dynamic testing comprises both white and black box techniques.

5. EXPERIMENT

5.1 Owing to the relatively small size and complexity of your projects, desk checking and compiling are the best form of static testing. Alternatively, if you are ahead of schedule and perhaps just for the experience, you may wish to conduct a mock-up of a walkthrough or inspection involving your team members and a selected sub-system component.

5.2 Proceed onto dynamic testing when you are done.

5.3 Remember to backup your work on diskette (IMPORTANT).

6. REFERENCES

6.10 Lecture Notes.

(11)

TESTING II

1. OBJECTIVE

The objective of this experiment is for project teams to complete testing their software components.

2. LABORATORY

4. INTRODUCTION

4.1 White box testing techniques comprise basis path testing, graph matrices and loop testing. Graph matrices, in the form of connection matrices, are generated by flow analyzers. Loop testing is specifically for loops and is used as a supplementary measure.

4.2 Black box testing techniques comprise equivalence partitioning, boundary value analysis, logic-based testing, and data validation testing. In an object-oriented software system, an object is the primitive black box while in a function-oriented software system, this is the module.

5. EXPERIMENT

5.1 Perform white box testing on individual software components while aggregates (clusters) of software components should progressively be subjected to black box testing. Perform regression tests for completeness, as your aggregates get incrementally larger.

5.2 Remember to backup your work on diskette (IMPORTANT).

6. REFERENCES

6.12 Lecture Notes.

(12)

INTEGRATION

1. OBJECTIVE

The objective of this experiment is for each project team to test and integrate their software system.

2. LABORATORY

4. INTRODUCTION

4.1 In this experiment, you will apply the incremental integration techniques you have learnt. For an object-oriented system, typical incremental integration may be performed on unit tested objects in specified generalization-specialization or whole- part structures. For function-oriented systems, perform integration with unit-tested modules.

4.2 Integration of object-oriented and function-oriented systems proceed according to the refined object diagram and refined structure charts, respectively. In the case of a structure chart, integration may proceed module by module (or module clusters) in a top-down, bottom-up or sandwich approach. In an object-oriented system, specific classes or structures of objects have to be selected as clusters first.

5. EXPERIMENT

5.1 Project manager must devise a test plan specifying the unit testing and integration strategy, test data and test cases to be used.

5.2 Apply what you have learnt, unit test and incrementally integrate your software system guided by the test plan.

5.3 Remember to backup a copy of your system (important).

6. REFERENCES

6.14 Lecture Notes.

(13)

PRODUCT DEMONSTRATION

1. OBJECTIVE

The objective of this experiment is for each project team to demonstrate their software product and attempt to convince the “user” that it meets (or exceeds) its requirements.

2. LABORATORY

4. INTRODUCTION

4.1 In a practical situation, the project manager or an appointed member of the project team conducts a demonstration of the functions and features of the product to the customer representative.

4.2 The demonstrator will focus on aspects that show how and the extent to which the user’s requirements have been met.

5. EXPERIMENT

5.1 Ensure that your product is ready by demo time. There must be no further modifications during demonstration.

5.2 The project manager or his appointee will demonstrate the product and attempt to convince the “user” (lab supervisor(s)) that the product meets (or exceeds) the specified requirements.

6. REFERENCES

6.2 Lecture Notes.

(14)

7. ONLINE REPORT FORMAT

7.1 Project Team Organization (all member’s names and roles must be stated) 7.2 Project Schedule

7.3 Refined System Specification 7.4 Use Case Diagrams

7.5 Requirements Model – Class Diagram or Data Flow Diagram

7.5 Software Design – Object Diagram and Collaboration/Sequence Diagrams or Structure Chart

7.6 Architectural Views (Optional) 7.6.1 Logical View Diagrams 7.6.2 Component View Diagrams 7.6.3 Process View Diagrams 7.6.4 Deployment View Diagrams 7.7 Discussion

7.7.1 Explain how you derived your requirements model.

7.7.2 Explain how you derived your design.

7.7.3 Explain the implementation steps.

7.7.4 Explain the different testing strategies that you have used.

7.7.5 Describe difficulties encountered during development and how you resolved them.

PLEASE NOTE:

ONE ONLINE REPORT IS TO BE SUBMITTED FOR EACH PROJECT TEAM.

THE REPORT SHOULD HAVE THE ITEMS 7.1 TO 7.7.

THE INFORMATION FOR THE REPORT HAS TO BE UPDATED EVERY WEEK.

THE FINAL VERSION OF THE ONLINE REPORT SHOULD BE IN PLACE WITHIN 1 WEEK OF THE GROUP'S LAST LAB SESSION (EXPT 10).

Late submissions will have a proportion of marks deducted from their course work.

SUBMISSIONS THAT ARE MORE THAN 1 WEEK LATE WILL NOT BE MARKED AND THE AFFECTED CANDIDATES WILL BE BARRED FROM THE.