28 July 2011

Module 6: Software Verification and Validation

In Module 6, we study about Software Verification and Validation. In this chapter,  software testing plays an extremely important role in V&V, but many other SQA activities are also necessary.


 This is about fundamental concepts of software verification and validation.



Testing must be planned carefully to avoid wasting development time and resources, and conducted systematically. The developer and Independent Test Group (ITG) must work together throughout the software project to ensure that thorough tests will be conducted. We must know what is unit testing.

We also need to know when is the right time to stop testing. 

created by: nursakinah mohd rosli

Module 3 Part 1: Requirements Engineering

This module is first about the concept of requirements and types of requirements. the key points that we should remember is:
  1. the meaning of requirements
  2. the two types of requirements:
    • Functional requirements (FR) 
    • Non-functional requirements (NFR)

 Second is what Requirements Engineering, its process, and the importance of them to product development projects in general. The key point that we sholud remember is:
  1. the meaning of requirements engineering
  2. the important of requirements engineering
Third is about what requirements elicitation, requirements analysis and negotiation, requirements specification, requirements verification and validation, and requirements management tasks are.




Fourth is various methods, approaches, and techniques for performing and supporting the RE process.The key point from requirements management that we should remember is:
  •      Managing changes to requirement
  •      Managing configuration of requirements and requirements document – version control
  •      Maintaining requirements traceability
  •      Tracking requirements status

That is, for overall for module 3 part 1. We as student may I suggest to study group this module 3 because it is one of important module that coming up in final exam.


created by : nursakinah mohd rosli

Module 7: Software Quality Management

The major in this module is all about the quality of the software. After study this chapter, we must be able to explained the concepts and principles of quality, software quality and software quality management. 

Software Quality Management. 

Software quality management adopt a number of management principles that can be used by upper management to guide their organizations towards improved software product performance. Software quality assurance (SQA) is often called quality management.

Quality.

In software, there are two kinds of quality may be encountered which is quality of design and quality of conformance. 

Software Quality.

Software quality is an effective software process applied in a manner that creates a useful product that provides measurable value for those who produce it and those who use it.

Quality Dimensions and Factors.


To achieving software quality, we need to broad activities to help software achieve high quality. 
  • Quality assurance
  • Quality control
  • Software engineering method
  • Project management technique
We need also to know about the role of the SQA group. There are six role that required in SQA group.
  • prepares an SQA plan for project
  • Participates in the development in the development of the project's software process description
  • reviews software engineering activities to verify compliance with the defined software process
  • audits designated software work products to verify compliance with those defined as part of the software process.
  • ensures that deviations in software work and work products are documented and handled according to a documented procedure.
  • records any noncompliance and reports to senior management.
SQA Goals

  1. requirements quality
  2. design quality
  3. code quality
  4. quality control effectiveness
Quality of the software is the most important things that we must applied when we build any software.

By the end of this chapter, we must be able to understand the whole story on this module. In this module all part are memorizing or theory notes. So, we as student must apply the best technique of study to make it clear and understand. 

27 July 2011

Module 3: Requirements Engineering (Part 2)

In module 3 part1, we already talk more theory about requirements engineering. So, in this part we will focus more about the guidelines of creating requirements analysis model. We have been explained about use case diagram, activity diagram, state diagram, and sequence diagram in previous class. But, what we need to know in details is how to implement use case diagram if any situation is given. 

Basically, requirements or analysis model is a graphical representations of business processes, the problems to be solved, and the new proposed product (software).

There are a  lot of principles in requirements modelling. The principles are:
    • Principle1: the information domain of a problem mustbe represented and understood.
    • Princple2: The functions must be defined.
    • Principle3: The behavior of the software must be represented.
    • Principle4: The models that describe information, function and behavior must be partitioned in manner.
    • Principle5: The analysis task should move from essential information toward implementation detail. 
Rules of thumb.

A rule of thumb is a principle with applications that is not intended to be strictlyor reliable for every situations. it is an easily appliedprocedure for approximately calculating or recalling some value or for making some determination. 

In this chapter also, Pn. Badariah already talk about two main levels in analysis modelling. Both levels are:

  • Context Modelling : Context modelling is a divide and conqure method based on separations into sub         data by context, so that each sub data can be approximated with a simple mode.Technical modelling:
  • Technical Modelling.
Technical Modelling.

2 approaches for this modelling.
  1. Structured analysis
  2. Object oriented analysis.(OO Analysis) 
We as student needs to understand OO analysis. OO modelling has 3 elements which is:
  • Scenario-based
  • Class-based
  • Behavioral
We need to know the basic of this 3 elements. But need to focus more in Scenario-based Modelling (Use Case diagram).

Use-case diagram.

Use case diagram is similar to a top level data flow diagram that depicts observable, user-initiated functionality  in terms of interactions between the system and its environment.
There are two elements in use case diagram which is actor and use case. The relationship of use cases are uses and extends. We already discussed in details about how to generate use case diagram in the class. Figure below is an example for complete use-case diagram.

Example for Use-Case Diagram with the explanations. :)
So, you need to study more about  how to make use case diagram. Practice more to understand the concept of Use-case diagram. Practice makes perfect. InsyaAllah. :D

Posted by: Aema Ismail ( SW 095790 )

Module 10: Advanced Topic in Software Engineering

In this module we have learn about software process improvement (SPI), emerging trends that are expected to have significant influence on SE practice in future and the ethics of software engineers.

FYI, Software Process Improvement (SPI) strategy transforms the existing approach to software development into something that is more focused, more repeatable, and more reliable (in terms of the quality of the product produced and the timeliness of delivery). 

While SPI frameworks are:
  • SPICE
  • Bootstrap
  • PSP and TSP
  • TickIT
In software engineering there is a trends which it include:
  • Managing complexity
  • Open world software
  • Emergent requirements
  • Software building blocks
  • Open source
And we must know that software engineering ethics are been used world widely which it has been categorized into
  • PUBLIC 
  • CLIENT AND EMPLOYER 
  • PRODUCT 
  • JUDGMENT 
  • MANAGEMENT 
  • PROFESSION
  • COLLEAGUES
  • SELF 
Software engineers need to follow this ethic.


P/S: Because I came late to the class when madam taught us this module so little bit understand and need to do some revision and simple notes on this module. 

26 July 2011

Module 8: Software Evolution

Few things to know in this module are maintenance and supports required of an application, Lehman’s laws of software evolution, concept of reengineering and activities of software reengineering.


Key points
  • Within days, bug reports filter back to the software engineering organization. 
  • Within weeks, One class of users indicates that the software must be changed so that it can accommodate the special needs of their environment. 
  • Within months, another corporate group who wanted nothing to do with the software when it was released, now recognizes that it may provide them with unexpected benefit. They’ll need a few enhancements to make it work in their world.
This is called Software Maintenance.

Another key points to remember
  • Software does not degrade or require periodic maintenance
  • Software is continually evolving.
  • Correcting defects
  • Adapting application to a changing business environment
  • Implementing enhancement at the request of stakeholders.
  • Supporting users as they integrate an application into their personal and business workflow.
This is what called "Ongoing activities to change and support the software after it is in operation"

And how about the Lehman’s laws of software evolution that I mention earlier??

Please check it out


Now the importance part in maintenance.  Who'll perform the maintenance?? The answer are Separate maintenance team and Part of development team.

Both are really importance actually in maintenance part.

Now we move on to Reengineering.  Basically reegineering upport ‘new business rules’, existing software may be modified or rebuilt (reengineered) and it may begin with a Business Process Reengineering (BPR) before move on to software reengineering.

As you can see below:

This is model for BPR


This is Software Reengineering model

And you must know how to differentiate between Reverse engineering and Forward engineering.

Reverse Engineering
  • Recreate design and specification information from the source code.
Forward Engineering
  • Process applies software engineering principles, concepts, and methods to re-create an existing application.
You can create a table to differentiate between all the thing stated above. That will make you understand more.  And from that table we can now the differences I mean we can differentiated it.



Created by: Siti Assyifa (SW087271)

9 July 2011

Module 4: Software Design

Software design is the best part to learn because this module thought us about how to design our software by following the design principles, concepts as well as practices.

Why design are so important in software development??

Design are important because the model can be assessed for quality and improved before code is generated, tests are conducted, and more users are involved.

BTW design creates a representation or model of the software and provides detail about software architecturedata structures, interfaces, and components that are necessary to implement the system.

Like shown below *I took it from slide*


We might think that design is the easiest part of software development but we should follow the design principles. According to Davis 1995
  • The design process should not suffer from ‘tunnel vision.’   
  • The design should be traceable to the analysis model. 
  • The design should not reinvent the wheel. 

You must remember that design is not coding and coding is not design

And did you know the characteristic of good design??

Nevermine I'll tell you.

Good software design must implement all of the explicit requirements, must accommodate all of the implicit requirements and must be readable and understandable also should provide a complete picture of the software.

Ohh almost forgot.  There are 12 design concept and this is the harder part to remember and understand, I think we should concern more on this part because without this concept, there is no such thing towards good design.

Maybe madam should explain more or show us more example eventhough madam had explained it during class or maybe we should work hard to understand it ^_^


A good software design minimizes the time required to create, modify, and maintain the software while achieving run-time performance.“ (Shore and Chromatic, 2007)



Created by: Siti Assyifa (SW087271)