MODULE 8-SOFTWARE REVOLUTION

                                              You may leave a response  :)

MODULE 7 - SOFTWARE QUALITY MANAGEMENT

WHAT IS QUALITY?  ---------> Quality of design

                                      ---------> Quality of conformance

                                      ---------> user satisfaction

DEFINITION                ---------> Management principles

                                       ---------> Required level of quality achieved

                                       ---------> Quality culture

SCOPE                           ---------> Large complex systems

                                        ---------> Documentation

 QUALITY DIMENSIONS AND FACTORS ---------> Efficiently

                                                                         ---------> Usability

                                                                         ---------> Maintability

                                                                         ---------> Realibility

ACHIEVING SOFTWARE QUALITY           ---------> Quality Assurance

                                                                        ---------> Quality Control

                                                                        ---------> Software Engineering method

                                                                        ---------> Project management technique

SQA GROUP ---------> Prepare SQA plan

                       ---------> Software process description

                       ---------> Review software engineering process

                       ---------> Audit desingnated software

                       ---------> Ensure work according to procedure

                       ---------> Record non compliance

SQA GOALS  ---------> Requirements quality

                        ---------> Quality control

                        ---------> Code quality

                        ---------> Design quality

MODULE 6 - VERICATION & VALIDATION

VERICATION & VALIDATION

Verification 
 -  the set of tasks that ensure that software correctly implements a specific function.

Validation 
 -  A different set of tasks that ensure that the software that has been built is traceable to customer requirements

Two principal objectives:

•    Discover defects in a system;
•      Assess whether or not the system is useful and useable in an operational situation.

Activities include :

Technical reviews

Quality and configuration audits

Performance monitoring

Simulation                                        SQA Activities

Feasibility study

Documentation review

Database review

Algorithm analysis

_____________________________________________________________________

Development testing

Qualification testing                                                 Testing         

Acceptance testing

Installation testing

SOFTWARE TESTING

- WHO TEST THE SOFTWARE ------­- DEVELOPER ( Understand the system BUT will test GENTLY & driven by ‘DELIVERY’)

                                                   -------- INDEPENDENT TESTER ( must learn about the system BUT          will attempt to break it and is driven by quality)

INTEGRATION TESTING

Incremental integration testing strategies:

• Bottom-up integration
• Top – down integration 
• Regression testing
• Smoke testing

VALIDATION TESTING


1)  Validation-Test Criteria:

• all functional requirements are satisfied,
• all behavior characteristics are achieved,
• all content is accurate and properly presented,
• all performance requirements are attained, documentation is correct, and
• usability and other requirements are met.

2)      Acceptance Tests

Alpha test – version of the complete software is tested by customer under the supervision of the developer at the developer’s site

Beta test – version of the complete software is tested by customer at his or her own site without the developer being present

SYSTEM TESTING

Types of system tests:

• Recovery Testing
• Security Testing
• Stress Testing
• Performance Testing
• Deployment Testing

TEST-CASE DESIGN

Software is tested from2 perspectives:

 ‘White-box’ testing 

focus on the program control structure (internal program logic).

-Test cases are derived to ensure that all statements in the program have been executed at least once during testing and all logical conditions have been exercised.

-Performed early in the testing process

 ‘Black-box’ testing

-Examines some fundamental aspect of a system with little regard for the internal logical structure of the software

-Performed during later stages of testing

DERIVING TEST CASES

      NOTES  : PLEASE DOUBLE-CLICK AT THIS DIAGRAM TO MAKE IT LARGE .TQ

MODULE 5 - IMPLEMENTATION AND CODING

MODULE 4 - SOFTWARE DESIGN

DESIGN PRINCIPLE

• ·         DESIGN ! = CODES
• ·         REVIEW TO REDUCE CONCEPTUAL ERROR
• ·         DO NOT REINVENT THE WHEEL
• ·         DESIGN PROCESS SHOULD NOT SUFFER FROM ‘TUNNEL VISION’

DESIGN EVALUATION

• ·         DESIGN Q IS PEOPLE SENSITIVE
• ·         DESIGN Q IS CHARGE SPECIFIC
• ·         DESIGN Q IS UNPRIDICTABLE
• ·         MODIFICATION AND MAINTENANCE TIME MORE IMPORTANT THAN CREATION   TIME

DESIGN CONCEPT

• ·         ABSTRACTION
• ·         ARCHITECTURE
• ·         PATTERN
• ·         SEPERATION OF CONCERN
• ·         MODULARITY
• ·         OO DESIGN CONCEPT
• ·         REFACTORING
• ·         DESIGN CLASSES

FOUR DESIGN ELEMENT

• ·         DATA OR CLASS DESIGN
• ·         ARCHITECTURE DESIGN
• ·         INTERFACE DESIGN
• ·         COMPONENT-LEVEL DESIGN

QUIZ 3

On 13 July 2011 on Wednesday during class time we had our quiz 3 based on module 4 (software design) and chapter 5 ( implementation and coding) . The format of our quiz is structure question and have 4 question that must we answer . This quiz takes 30 minutes for answer it and all student trying so hard to answer it . so study hard and smart for our next quiz :) GOOD LUCK !

Task: Doing Past Year Exam Papers

Past Exam Papers Sem II 2007/2008

Question 3

       After a student has been registered to XHZ University, a student record will be created in a database by administration. This record shall hold the student's name, identification number, major and grade point average(GPA). It also shall hold list of all semesters the student has attended. For each semester, there is a list of course the student takes. Each course has a code, title, credit hours and the grade student will receive.
      Faculty member and administrator may view and update student records. A student may view his own record.
    Develop a use case diagram for student.

Solution:

Author:

1.      Student

2.      Administrator

3.      Faculty member

Past Exam Papers Sem II 2007/2008

Question 2

           An auto rental company wants to develop a computerized system that would handle car reservations customer billing, and car auctions. Usually a customer reserves a car, picks it up, and then returns it after a certain period of time. At the pick up time, the customer has the option to buy or waive collision insurance on the car. When the car is returned, the customer receives a bill and pays the specified amount. In addition to rent cars, every 6 months or so, the auto rental company auctions the cars that have accumulated ober 20,000 miles.

Author:

1.  Staff
2. Customer

MODULE 3 -Part 2

                                              Click to view people  :)

MODULE 3 -Part 1

                                                 Please click to enlarge :)

QUIZ 2

We had our quiz just now during class on Chapter 2 and 3.We have been informed last week in order for us to prepare for the quiz .Alhamdulillah we managed to answer all in 10 mins .Class dismissed as soon as we checked answer. Lets hope for the best in next quiz. Fighting yeah ;) !

Study well people :)

                                                                                                                           

Task: Case Study

Case Study 2

When a lecturer has a large amount of students registered for a class, it can be tedious for the lecturer to keep track of all students’ attendance, due to the fact that the lecturer has to manually scroll through the attendance list to see who has not been attending lecturers.

Also throughout the semester, lecturers might misplace the attendance. When this happens there is no way of recovering the information, so they would have to disregard that attendance, for the period of time that was recorded on the missing sheet. An issue arises here, because if that lecturer decides to overlook the tardy students on the attendance that was lost but penalized the ones on the attendance list that they can find, there would be unfair balance in terms of disciplinary action taken.

From time to time, the lecturer has to analyze the attendance record and submit the names the tardy students to the clerk of the department and the clerk responsible for generating the warning letter/bar letters then get them signed by the dean before mailing them to parents of the students. It may be time consuming for the lecturers to pass this information to the clerk and the clerk put aside time to generate those letters. This process may require a relatively large amount of time which can result in the late arrival of the letters to parents.

User:

1.      Student

2.      Lecturer

3.      System administrator

Student Attendance Management

1.      Create/read new attendance record

2.      View attendance list

3.      Update attendance record

4.      Generate first warning letter

5.      Generate second warning letter

6.      Signed the letter by dean

7.      Generate bar letter

8.      Update attendace record

9.      Delete name of student in attendance record

Module 2: Software Processes

Task 4

 Software Myths 

Software Myths- beliefs about software and the process used to build it - can be traced to the earliest days of computing. Myths have a number of attributes that have made them insidious. For instance, myths appear to be reasonable statements of fact, they have an intuitive feel, and they are often promulgated by experienced practitioners who "know the 

score". 

There are three types of myths :

• Management myth
• Customer myth
• Practitioner myth

Management Myths 

Managers with software responsibility, like managers in most disciplines, are often under pressure to maintain budgets, keep schedules from slipping, and improve quality. Like a drowning person who grasps at a straw, a software manager often grasps at belief in a software myth, If the Belief will lessen the pressure. 

Myth 1 : We already have a book that's full of standards and procedures for building software. Won't that provide my people with everything they need to know? 

 The book of standards may very well exist, but is it used? 
- Are software practitioners aware of its existence? 
- Does it reflect modern software engineering practice? 
- Is it complete? Is it adaptable? 
- Is it streamlined to improve time to delivery while still maintaining a focus on Quality? 
In many cases, the answer to these entire question is no. 

Myth 2 : If we get behind schedule, we can add more programmers and catch up (sometimes called the Mongolian horde concept) 
Reality : Software development is not a mechanistic process like manufacturing. In the words of Brooks [BRO75]: "Adding people to a late software project makes it later." At first, this statement may seem counterintuitive. However, as new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development effort 

Myth 3 : If we decide to outsource the software project to a third party, I can just relax and let that firm build it. 
Reality : If an organization does not understand how to manage and control software project internally, it will invariably struggle when it out sources software project. 

Customer Myths 

A customer who requests computer software may be a person at the next desk, a technical group down the hall, the marketing /sales department, or an outside company that has requested software under contract. In many cases, the customer believes myths about software because software managers and practitioners do little to correct misinformation. Myths led to false expectations and ultimately, dissatisfaction with the developers. 

Myth 1 : A general statement of objectives is sufficient to begin writing programs we can fill in details later. 

 Although a comprehensive and stable statement of requirements is not always possible, an ambiguous statement of objectives is a recipe for disaster. Unambiguous requirements are developed only through effective and continuous communication between customer and developer. 

Myth 2: Project requirements continually change, but change can be easily accommodated because software is flexible. 

 It's true that software requirement change, but the impact of change varies with the time at which it is introduced. When requirement changes are requested early, cost impact is relatively small. However, as time passes, cost impact grows rapidly - resources have been committed, a design framework has been established, and change can cause upheaval that requires additional resources and major design modification. 

Practitioner Myths

Myths that are still believed by software practitioners have been fostered by over 50 years of programming culture. During the early days of software, programming was viewed as an art form. Old ways and attitudes die hard.

Myth 1: Job is done once we write and get the program work.

Someone once said that the sooner you begin writing code, the longer it’ll take you to get done. Industry data indicate that between 60 and 80 percent of all effort expended on software will be expended after it is delivered to the customer for the first time.Myth 2: I should not accessing the quality, until i got the program running.

One of the most effective software quality assurance mechanisms can be applied from the inception of a project – the formal technical review. Software reviews are a “quality filter” that have been found to be more effective than testing for finding certain classes of software errors.Myth 3: Working program is the only deliverable work for a successful project.

A working program is only one part of a software configuration that includes many elements. Documentation provides a foundation for successful engineering and a more importantly, guidance for software support.

                                                                                                                                    

Task 3 ACCOMPLISHED !

 Please click to enlarge .Thankyou.

                                                                                                                                 Natasha

Task: Characteristics of Process Model

Task: Characteristics of Process Model 1

Module 1 : Introduction to Software Engeneering

Do click to enlarge yaw :)

The Group Members

Hello again people ,
Before we start our blog ,let us first introduce ourselves :
 

      

        Name : NATASHA AMIRA BINTI ROSLI

   ID Number : GM084503

        

       Name : INTAN NABILAH BINTI ROSLAN

     ID Number : GM083313

     

        Name : FARAH NUR ZAHEERAH BINTI ZAIHAN

                                                    ID Number : GM084486                                              

So in order to fulfill the requirements given by Madam Badariah , we are required to complete all the tasks given .You may view and get information from here. Do comment here and we will response as soon as possible. TQ :) 

                                                                                                                                   

Task 1: Welcome to our blog!

Assalamualaikum w.b.t,

     

       First of all I would like to thank you for dropping by to our blog of Fundamental of Software Engineering course where we will later updating our post of  this course's modules. This task is given by our lecturer of this course, Madam Badariah Solemon, as a fresh start introducing our blog.

Make yourself comfortable, and have a look around :)