Software Engineering Portal

Assalamualaikum...

Alhamdulillah...we managed to finish up our project...
This is the url of our SE portal:

www.sep.karnadya.com.my

Thank you...

second presentation

Tomorrow we have second presentation for our group project.present the portal about software engineering subject and sources..good luck for all of you..funtastic six can do it..do your best girls..InsyaAllah

Thank you...

Assalamualaikum and good day...

First of all, I would like to thank our beloved lecturer, Puan Badariah for teaching us Software Engineering subject... She has taught us a lot about this subject... We had learn many things about SE... Thank you, Puan...

Girls... thank you for being cooperative during the project period...:) I wish all of you good luck in final exams... Do your best ok...

Anyway, our second presentation will be on the 23rd of October... I hope that I will do better in the next presentation...huhuhu... I'll try my best to do the best...

Our portal is still in progress.... InsyaALLAH we will be able to finish it up before Hari Raya break...So that, all of us can enjoy our Hari Raya...hehehe....

By the way... I think this is the last post from me...since Puan Badariah will count all the posts starting from the beginning of the sem until today... I hope that we will be able to get good marks for this assignment since we are one of the group with the highest total number of posts...:)

Since this is my last post, I would like to apologize to all of you, if I said or did anything that hurt your feelings... I apologize for all the mistakes i've done...

Lastly... Selamat Hari Raya Aidilfitri to everyone...
Maaf Zahir dan Batin....
from me, Laila Hana...and the rest of the member of funtastic six...Kak Nor, Wani, Wawa, Nano and Mumtaz...

All the best to you guys...:) Take care...

TESTING VS PROVING

In proving a program correct, the test team or programmer considers only the code and its input and output conditions. The program is viewed in terms of the classes of data and conditions described in the design. Thus, the proof may not involve executing the code but rather understanding what is going on inside the program.

Customers have a different point of view. To demonstrate to them that a program is working properly, we must show them how the code performs from outside the program. In this sense, testing become a basis for deciding how the program will behave in a given situation.

Whereas a proof tells us how a program will work in a hypothetical environment described by the design and requirements, testing gives us information about how a program works in its actual operating environment.

Web Portal in Progress

For about 3 weeks earlier, we started making the web portal. Interface, overall elements and attributes need to be considered as referred to the user requirement that should be contained in the expected web portal, we were having a few meetings from time to time, discussing what should have and what should not, inserting files and document.

We were basically done with the layout, generally the interface, buttons and links. The interface will be simple as it will make the page process go more smoothly. The navigation buttons will help users to navigate around and will have easy access to view the portal as well.

The whole system will be developed using CSS. The database will be developed using PhP. However, we were having some difficulties on it, but we were trying to do our best in doing this web portal as expected by the user.

As for present, we just finished uploaded a few things expected by the user, calendar; Allow users to make appointments with the administrator besides able to look at the date of the day and search engine; User type the keyword in the search engine box and than enter -> The page searches the keyword at the database -> Database sends the information about the keyword -> Exit.

What to be done for upcoming days, user log in and just about a few more things to be inserted in the web portal, and we were done with it.

*That is all for the progression of our web portal at the moment.

*Progression will be informed from time to time :)

Format for Final Exam Paper...

Assalamualaikum and good evening....

Girls... as a reminder, this is the format of the final exam paper for Software Engineering...
Our lecturer, Puan Badariah told us about the exam format in our last class...which was on Tuesday...

There will be 3 sections in the final exam :

Section A (16 q) - Fill in the blanks ( 20 blanks) - 20 marks
Section B (7 q) - Short answers (differentiate, lists, draw, definition ) - 50 marks
Section C (2 q) - Understanding, memory recall, C codes - 15 marks

Don't forget to put examples for the questions that require detail explainations...

So,girls... please be prepared for the final examination paper which will be held one week after our Hari Raya break...

Thank you...

Last lecture..

Chapter 11 : Maintaining the System

11.1 The Changing System
Maintenance: any work done to change the system after it is in operation.
Software does not degrade or require periodic maintenance.
Lehman’s System Types :
1. S-system: formally defined, derivable from a specification.
2. P-system: requirements based on approximate solution to a problem, but real-
world remains stable.
3. E-system: embedded in the real world and changes as the world does.

11.2 The Nature of Maintenance
Types of Maintenance :
1. Corrective: maintaining control over day-to-day functions.
2. Adaptive: maintaining control over system modifications.
3. Perfective: perfecting existing functions.
4. Preventive: preventing system performance from degrading to unacceptable
levels.
Who Performs Maintenance :
1. Separate maintenance team
2. Part of development team.

11.3 Maintenance Problems
· Staff problems: Limited understanding, management priorities and morale.
· Technical problems: Artifacts and paradigms and testing difficulties.

11.4 Measuring Maintenance Characteristics : Maintainability is not only restricted to code, but also including specification, design, and test plan documentations. Maintainability can be viewed in two ways, either external view of the software or internal view of the software.

11.5 Maintenance Techniques and Tools
· Configuration management
– Configuration control board
– Change control
· Impact analysis
· Automated maintenance tools

11.6 Software Rejuvenation
1. Redocumentation: static analysis adds more information.
2. Restructuring: transform to improve code structure.
3. Reverse engineering: recreate design and specification information from the code.
4. Reengineering: reverse engineer and then make changes to specification and design
to complete the logical model; then generate new system from revised specification
and design

11.7 Information System Example
Piccadilly System
- The software can not be an S-system.
- The software can not be a P-system.
- The software must be E-system.

11.8 Real Time Example : Developers focused on mitigating random failure. The inertial reference system failed because of a design fault, not a result of a random failure. Needs to change the failure strategy and implement a series of preventive enhancements. Invokes change control and configuration management

CASE TOOL For reverse engineering

here some information on reverse engineering CASE TOOL (InSight Tool):
http://ieeexplore.ieee.org/iel5/6783/18169/00841062.pdf

Definition of Software Engineering

Software Engineering has come to mean at least two different things in our industry. First of all the term "software engineer" has generally replaced the term "programmer". So, in that sense there is a tendency to extrapolate in people's minds that Software Engineering is merely the act of programming. Secondly, the term "Software Engineering" has been used to describe "building of software systems which are so large or so complex that they are built by a team or teams of engineers. Yet, there is increasing evidence that many of the processes we have been developing for large groups of engineers also apply to the best practices of even individual engineers.
Software Engineering is intended to mean the best-practice processes used to create and or maintain software, whether for groups or individuals, in attempt to rid ourselves of the usual haphazard methods that have plagued the software industry. This would include subjects like Configuration Management, Project Planning, Project Tracking, Software Quality Assurance, Risk Management, Formal Inspections, etc.

** extra knowlegde for everybody**

what web portal means?...

Portal

Web access point. A portal consists of web pages that act as a starting point for using the Web or web-based services. The word was first used to describe the sites of popular Internet access providers or search engines such as AOL, MSN and Yahoo! Later on, it was extended into the world of work, where a corporate portal or enterprise information portal acts as a starting point for employees or associates of an organization to access corporate information and applications. Portal software has become a distinct class of web server software that acts as a platform for deploying portals.

-Just for extra knowledge for everybody-

Chapter 10 : Delivering the System

This is for up coming lecture...

Delivering the System is more than just putting the system in place.It is also helping users to understand and feel comfortable with the system training and documentation.

10.1 Training

• Types of People Who Use a System
• User and Operator Functions
• Types of Training
• Training Aids
• Guidelines for Training

10.2 Documentation

• Considering the Audiences
• Types of Documentations
• User Helps and Troubleshooting
• Guidelines for Failure Messages

10.3 Information System Example

• Piccadilly System

10.4 Real Time Example

• Ariane-5

10.5 What this Chapter Means for You

Training and documentation should be planned and tracked from the project’s beginning. Training and documentation software should be integrated with the regular system software. All training and documentation modules and documents should take into account the varying needs of different audiences.

Today's Lecture

Hello everyone,

As mentioned by Pn. Badariah on Tuesday's lecture, go back and study on the testing issues, about the Testing Organization Illustrated. As we had to study on it, again, another quiz on today's lecture, which is to briefly explain about the testing organization illustrated and state the objective of each of the stage within the testing organization.

Define the objective of Unit Test
Define the objective of Integration Test
Define the objective of Function Test
Define the objective of Performance Test
Define the objective of Acceptance Test
Define the objective of Installation Test

- Plus, Pn. Badariah also mentioned to explore the text book and correct the slide 9.5 on chapter 9 about Acceptance Test as stated below:

• Pilot Test: Install on experimental basis
• Alpha Test: In-house test
• Beta Test: Customer Pilot
• Parallel Testing: New system operates in parallel with old system

- But, there is about a misspelled on the slide. The correction is as stated as below:

• Pilot Test: Install on experimental basis

1) Alpha Test: In-house test

2) Beta Test: Customer Pilot

• Parallel Testing: New system operates in parallel with old system

- Pilot Test itself is actually consist of 2 ways, Alpha Test and Beta Test.

Within one hour lecture today, we did the quiz for about 10 mins added with 5 mins extra, plus remainder of other mins we went through chapter 9 and finished up the chapter.

For next week lecture, we will continue with chapter 10. So as usual, do not forget to scan through and read the chapter that we are going to continue first before we come to class :)

Chapter 9 - Testing the System

Assalamualaikum...

Today we had lecture on chapter 9, Testing the System. However, we only learnt part of chapter 9 because Pn. Badariah had to dismissed the class early due to some reasons. These are part of the contents that Pn. Badariah explained during our class today :-

9.1 Principles of system testing
9.2 Function Testing
9.3 Performance Testing
9.4 Reliability, availability and maintainability
9.5 Acceptance Testing

Our lecturer told us to read 'Acceptance Testing' from the textbook because there are some mistakes in the notes on that topic. So girls, as a reminder, please read the textbook on page 448.

Anyway dont forget that we'll be having our 2nd presentation on the 9th of October 2007. So, girls...we need to proceed on our portal as soon as possible...

Thank you...

reasons on the implication of testing (Cyclomatic Complexity)

Reasons on the implication of testing (Cyclomatic Complexity)


The word “cyclomatic” comes from the number of fundamental (or basic) cycles in connected,undirected graphs [BERGE]. More importantly, it also gives the number of independent paths through strongly connected directed graphs. A strongly connected graph is one in
which each node can be reached from any other node by following directed edges in the graph. Program control flow
graphs are not strongly connected, but they become strongly connected when a “virtual edge” is added connecting the exit node to the entry node. The cyclomatic complexity definition for avoids explicit mention of the virtual edge.

Be Prepared

Assalamualaikum...
Now we in Fasting Month,we actually near to final exam..
after we celebarate Hari Raya....we have Final exam...
i just wat to remaind to all of you including me...to be prepay for our coming final exam..
hopefully we can do well and the result will be 'Great'..InsyaAllah..
see yah...and Selamat Menyambut Ramadhan Al-Mubarak...

Attention! Attention!!!

Girls...we'll be having a meeting this week...
We need to discuss about the portal...
Date and venue will be confirmed later...

Thank you...

Cyclomatic Complexity

Assalamualaikum and good evening....

Today, we learnt something new in class...Cyclomatic Complexity (CC)...

Cyclomatic complexity may be considered a broad measure of soundness and confidence for a program. Introduced by Thomas McCabe in 1976, it measures the number of linearly-independent paths through a program module. This measure provides a single ordinal number that can be compared to the complexity of other programs.
(http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html)


The cyclomatic complexity of a software module is calculated from a connected graph of the module.

According to Puan Badariah, there are few formulas to calculate the CC...

Formulas:

• CC = E - N + 2 or
• CC = E - N + p

where:

E = number of edges

N = number of nodes

p = number of connected components

Puan Badariah also gave us an exercise on CC... We will discuss about it next week...

Girls...as a reminder, this is the codes of the exercise that we are required to do...

if x = 1 {
print "1";
else
print "2";
}
if y = 1 {
print "A";
else
print "B";
}

• For the exercise, firstly, we need to draw the equivalent graph (path).
• Secondly, we need to give reasons on the implication of testing (Cyclomatic Complexity)

Okay...that's all...:)

Selamat Berpuasa to all...

Ramadhan Al-Mubarak...

Assalamualaikum....

Dear friends,

Ramadhan, takes the entire Muslim Ummah in a religious season surpassing any annual event in the world. The holy month of Ramadhan unites all Muslims in fasting, feasting, worship and prayer.

Selamat Menyambut Ramadhan Al-Mubarak...

Semoga di limpahi rahmat-Nya...insyaAllah...

Chapter 8

Assalammu'laikum..

Today we continued with chapter 8, testing the programs....

In this chapter we learned about software faults and failures, testing issues, unit testing,
integration testing, testing object-oriented systems, test planning, automated testing
tools, when to stop testing...

Test is successful only when a fault is discovered

• Fault identification is the process of determining what fault caused the failure
• Fault correction is the process of making changes to the system so that the faults are removed

There are many types of faults :

1. Algorithmic faults
2. Computation and precision faults
3. Documentation faults
4. Capacity or boundary faults
5. Timing or coordination faults
6. Performance faults
7. Standard and procedure faults.

The types of testing is :

1. Module testing, components testing or unit testing
2. Integration testing
3. Function testing
4. Performance testing
5. Acceptance testing
6. Installation testing

We can view the test object from the outside as a closed box or black box whose contents
are unknown, your testing feeds input to the closed box and notes what output is produced.
Clear box or white box is the structure of the test object to test in different way.

There are two types of code review, its code walkthrough and code inspection.

Types of test thoroughness :

1. Statement testing
2. Branch testing
3. Path testing
4. Definiton-use testing
5. All-user testing
6. All-predicate-uses/some-computational-uses testing
7. All-computational-uses/some-predicate-uses testing

An integration testing methods:

1. Bottom-up
2. Top-down
3. Big-bang
4. Sandwich testing
5. Modified top-down
6. Modified sandwich

Each step of the testing process must be planned by test planning steps:

1. Establish test objectives
2. Design test cases
3. Write test cases
4. Test test cases
5. Execute cases
6. Evaluate test results

Don't Forget to Prepare Yourself...

Assalamualaikum and good evening....

Girls...I would like to remind all of you about this...
Please be prepared before you come to class okay??
I've reminded you guys about this many times...
Hehe...:P

Anyway...tomorrow we'll be learning chapter 8, Testing the Programs...
I hope all of you have read the slide at least...
But, it's a good practice if you also read the text book...
You will be able to understand about the topic clearly...

So, hope to see all of you tomorrow...
Adiosss....:)

Finalize SRS

Alhamdullilah... finally, we have successfully finished our SRS...
Although all of us were busy with test and assignments, we made it....
So here is our srs:

Software Requirements Specifications (SRS)

Pop Quiz

Assalamualaikum...

We had a pop quiz on last Thursday...
We were required to do the quiz in pairs...
I regreted that I didn't read the notes on chapter 8 before I come to class...
Huhu..
So, girls....make sure you read the notes first before you come to class...

Anyway...our blog is not as active as before...
Maybe because everyone was busy doing assignments and preparing for tests...
I just hope that we can make the blog active again....

Okay...that's all for now...

InsyaAllah we will upload our SRS by today or tomorrow...

Today lecture

chapter 7

Writing The Programs (coding)

1. programming guidelines
2. documentation
3. programming process

Then we must know in implementation what task that doing in implementation stage:

1. writing the program (coding)
2. complete the documentation(for user such as user manual book and documentation for system)
3. if end user are the other than people who develop the system,training must be include in implementation.

Remainder!

what software means?

• software means programs + documentation to achive the goal.

Merdeka!!

Happy 50th Merdeka Day!

Merdeka! Merdeka! Merdeka!:)

70%

We can say that at least 70% of our SRS is done....:)
InsyaAllah the SRS will be ready by next week...
Again...we'll be meeting Puan Badariah to show the draft of SRS next week...
That's all...

SRS in Progress

Assalamualaikum...

We are now working on our SRS...
InsyaAllah we will manage to produce the draft of SRS by the end of our holidays...
Okay..
Have a great holiday!!

Online Discussion

Assalamualaikum...

Girls....attention!!
We need to set the date and time for the online discussion about our group project ....
Please give your feedback as soon as possible...

Thank u...

Today's Lecture..

Assalammu'laikum..
Today we have started learning chapter 5, about Designing the Syatem..

Design is the creative process of transforming the problem into a solution. The description of a solution is also known as design, the requirements specification defines the problem. The design document specifies a particular solution to the problem.

Besides that, there are two part interactive process; Conceptual design (to tells the customer what the system will do) and Techical design (to tells the programmers what the system will do). Puan Badariah also explained about the five ways to create designs : Modular decomposition, Data-oriented decomposition, Event-oriented decomposition, Outside-in design and Object-oriented design.

We also learned about design styles, which is pipes and filters, Object-oriented design, Implicit invocation, Layering, Repositories, interpreters, Process control and Client-server.

Actually about the Characteristics of Good Design, Exeption Identification and Handling is already come out in the previous exam.

Puan Badariah also explained about Design Evalution and Validation Design Reviews. Preliminary design review, examines conceptual design with customer and users. For the Critical design review, its presents technical design to developers and the lastly is Program design review, the programmers get feedback on their designs before implementation.

Okay...that's all for today lecture...

First Interview..

Asslamualaikum n good afternoon...

Today, Kak Nor and I interviewed Puan Badariah in her room...
We went to her room around 8.30 a.m...
We interviewed her about 15 minutes...

Since we had already prepare our questionnaires,the interview went quite smoothly...
We managed to collect the requirements for our project...
Puan Badariah told us to analyze the collected requirements then produce the SRS step by step...
We will meet Puan Badariah right after developing the draft of SRS...
When everything is satisfied, then we will develop the final SRS...

We hope that everything will go well...
We will meet Puan Badariah for further requirements collection if what we collect from her during the interview is not enough....

Okay...that's all about the interview...

Our Meeting...

Assalamualaikum...

At last...we managed to meet up this morning at COIT...
During our meeting, we discussed about what questions to be asked to Puan Badariah for our interview which will be held on this Thursday...InsyaAllah...

For the interview session, Kak Nor and I will be interviewing Puan Badariah...
I just hope that everything will go well...

By the way, today we learnt on how to do state transition diagram...
The answer for the question that we were required to do about the state transition diagram has already been uploaded by wawa...

Puan Badariah show an example of SRS to all of us in the class today...
That SRS was done by our senior... They got full marks...huhuhu.....
So, girls...make sure we do our best for the SRS... So that we can get full marks too...:)

Okay....that's all...

Discussion; Statechart / State Transition Diagram

Statechart / State Transition Diagram


1. Node (State)

2. Edge




The case investigation undergoes several states in the Jenny Legal Investigation Services system. The case investigation is first established when the attorney requests an investigation be conducted. When the investigator begins to perform the various investigative techniques, the case investigation becomes active. The client-attorney can begin settlement negotiations, or the case can go trial. Settlement negotiations may result in a settlement, or the case may have to go to trial if settlement negotiations fail. Ultimately, the case-investigation is closed when the case is closed by settlement agreement or judicial verdicts.

Meeting Rescheduling...

Assalamualaikum...

Girls...we'll be having a meeting this tuesday at 10 a.m...since our HCI class is cancelled...
We didn't manage to meet up last week due to several reasons...
It seems that last week was a busy day for all of us...plus some of us had mid term for other subjects...
I just hope that the meeting on this Tuesday will be held...
I also hope that all of us can cooperate to attend the meeting...

Thank u...

Mock Quiz (Continue)

Mock Quiz( Class-Thursday 16/8/2007)

TYPES OF USE CASE:

1. Actor(stick man or orang lidi)
2. Use case
3. Interaction

*remember that types...for final exam (7 marks)

*be prepared...n GoodLuck

Today's Class

Assalamualaikum...

Today we learned how to answering the Use Case and statechart/state transition diagram questions.Actually it's past sem question.Today we just finished answering 1st question..for the question no.2 ...do by your ownself. We will continue our discussion about this exercise in next lecture..

Dont forget to answer question no.2 !

Mock Quiz..

Assalamualaikum...and hello to all of you...

Tommorow we have mock quiz for USE CASE....

so be prepare....

Madam Badariah want to teach how to answer that kind of question for in coming final exam...

so girls be ready and study ok....

Review of Use Cases

USE CASES DIAGRAM : A diagram that shows the use cases and actors for a system.

ACTOR : External entity that interact with the system

USE CASES : A complete sequence of related actions begins by an actors to finished a specific goals ( it represents a specific ways of using the system)or "what" of the system.

For example :

Use case diagram for Uniten Registration System



May these informations help u all....

Next Meeting

Assalamualaikum....

Girls...we'll be having a meeting at 12 p.m., tomorrow (Thursday)..
Hope all of you will attend our group discussion...

We need to discuss about the SRS...
As a reminder, we have to submit the SRS right after our mid semester break...
That means, we have about less than 3 weeks...

Anyway, there might be some changes about the time...

See you guys tomorrow...
Make sure all of you are prepared for our class...

Today's Lecture...

Assalamualaikum....

Today we continued with chapter 4....
Puan Badariah explained about requirements elicitation...
She also mentioned about the techniques of eliciting requirements....

According to her, students always forgot about other technique... The only technique that students usually remember is interviewing stakeholders...
So girls...make sure you remember other techniques because Pn. Badariah might ask that question in our final exam...

We also learnt about types of requirements...
There are two types of requirements; which is functional requirment and non-functional requirement (includes design constraint and process constraint).

Besides that, there are two kinds of requirements documents; that is requirements definition (a complete listing of everything the customer wants to achieve) and requirements specification (restates the requirements as a specification of how the proposed system shall behave).

Pn. Badariah also explained about the characteristics of requirments. According to her, we can follow the IEEE recommended practice for SRS in her website to develop our SRS...

Today, Pn. Badariah explained some of the modeling notations.
There are seven types of Modeling Notations... which is ERD, Event Traces, State Machines, DFD, Functions and Relations, Logic, and Algebraic Specifications...

Pn. Badariah asked us to focus on Use Cases (an example of DFD) and State-Machines...
She asked us to practice both the modeling notations...
Don't forget to practice, girls.....

Okay...that's all for now...

Notice

Assalamualaikum and hello everybody....:)

Tomorrow... we will continue with our lecture for chapter 4....
As usual...make sure that all of you are prepared....
So that, whenever Pn. Badariah asked questions, we will be able to answer...:)

Dont forget to eat something before you come to class k... hehe....
Make sure you eat something so that you can concentrate in class...

Anyway...Girls...we will be having a group meeting this week....
I'm not sure on what day...
We need to discuss about the SRS...

Okay... see you guys tomorrow....
I will inform you about our coming group meeting...:)

What are the characteristics of a great Software Requirements Specification (SRS) ?

An SRS should be..

(1) Correct :
This is like motherhood and apple pie. Of course you want the specification to be correct. No one writes a specification that they know is incorrect. We like to say - "Correct and Ever Correcting." The discipline is keeping the specification up to date when you find things that are not correct.

(2) Unambiguous :
An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. Again, easier said than done. Spending time on this area prior to releasing the SRS can be a waste of time. But as you find ambiguities - fix them.

(3) Complete :
A simple judge of this is that is should be all that is needed by the software designers to create the software.

(4) Consistent :
The SRS should be consistent within itself and consistent to its reference documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another.

(5) Ranked for Importance :
Very often a new system has requirements that are really marketing wish lists. Some may not be achievable. It is useful provide this information in the SRS.

(6) Verifiable :
Don't put in requirements like - "It should provide the user a fast response." Another of my favorites is - "The system should never crash." Instead, provide a quantitative requirement like: "Every key stroke should provide a user response within 100 milliseconds."

(7) Modifiable :
Having the same requirement in more than one place may not be wrong - but tends to make the document not maintainable.

(8) Traceable :
Often, this is not important in a non-politicized environment. However, in most organizations, it is sometimes useful to connect the requirements in the SRS to a higher level document. Why do we need this requirement?

Today....

Thank you so much to our lecturer, Puan Badariah Solemon for teaching us today although she a little bit ill… We very appreciated to the effort that has been given by our lecturer and apologize because not able to answer to our lecturer question… These is because we are very hungry and our hard disk seems very slow today….... hehehehh

Lastly; we really appreciated and solute to our lecture and thank you so much…. Chayouk2 for CSEB233 ….. hehehe

p/s: girls; bring some candy to our class…. Then distributed among us ok… we take turns hahahahhaha…. Bring Cadbury to class hehehehheh

Chapter 4:Capturing requirement

Assalamualaikum and hello to everybody…

What have we learnt today? Requirement….

What is requirement?
According to Logman dictionary; Requirement means something that needed or asked for….
In software engineering; requirement means the something user’s needs. A requirement deal with; object or entities for example such as staff or student (in our database subject it might being referred to entities or table name), state they can be in and function that are performed to change the object characteristic.

Why requirement are very important?

Because if the requirement doesn’t satisfy the user’s needs; the project may confront failure… The top factors of project failure:
- Incomplete requirement
- Lack user requirement
- Unrealistic expectation
- Lack of executive support
- Changing requirement and specification
- Lack of planning
- System no longer needed

This can cause the organization suffered costly project and wasted the time of developing the system. For example; if a project has completed till the implementation phase suddenly the developer realized that the users/customers needs does not completed (Incomplete requirement). Therefore they needed redo all the phase from the start which is phase one; requirement and analysis .This will cause the organization to pay extra cost and wasted their time.

upgrade the blog

Assalamualaikum...
Today we upgrade the blog such as categorize the post..uplode the pictures..arrange the page and many more....
we want our blog very interactive and nice blog...
thank you girls...

WBS

Girls, here is our WBS;



if you want to download it; visit:

WBS1.doc

Have a nice day!!!

Beginning of Chapter 4

Assalamualaikum and good morning...

Today we have started learning chapter 4...Capturing the Requirements...
We learnt about the Requirement process...
A requirement is an expression of desired behaviour. Requirement deals with objects or entities, the state they can be in and functions that are performed to change states or object characterics...
Requirements focus on the customer needs, not the solution or implementation...

We will continue Chapter 4 in our next lecture...

By the way..start from this chapter, we will start to produce our Software Requirements Specification (SRS)..

Thank you...

Gantt Chart ?

A Gantt chart is a graphical representation of the duration of tasks against the progression of time. It is a useful tool for planning and scheduling projects. A Gantt chart also helpful when monitoring a project's progress. From the Planning and Scheduling perspective, Gantt Chart allows you to assess how long a project should take. It is lays out the order in which tasks need to be carried out and helps manage the dependencies between tasks.

Example :

Extra information for WBS

A Work Breakdown Structure (WBS) is a fundamental project management technique for defining and organizing the total scope of a project, using a hierarchical tree structure. The first two levels of the WBS (the root node and Level 2) define a set of planned outcomes that collectively and exclusively represent 100% of the project scope. At each subsequent level, the children of a parent node collectively and exclusively represent 100% of the scope of their parent node. A well-designed WBS describes planned outcomes instead of planned actions. Outcomes are the desired ends of the project, and can be predicted accurately; actions comprise the project plan and may be difficult to predict accurately. A well-designed WBS makes it easy to assign any project activity to one and only one terminal element of the WBS.

just read it girls.....

User Requirement Specification

Objective

The purpose of this work is to ascertain and record the users’ requirements for an EDM / workflow system. The document produced includes details of the existing and proposed IT infrastructure and business practices.
It is recommended that the process includes a high level view of the information requirements and document handling patterns of the whole organisation in addition to a detailed study of the area(s) chosen for the pilot(s). The process may take place in two stages, with the high level study being concluded in advance of a decision on the area(s) for the detailed study. In this case, the client may decide if an interim report is required.
The User Requirement Specification (URS) is constructed in such a way that it can be used as the basis from which to develop an Invitation to Tender (ITT) as part of the procurement exercise for a system to meet the client's needs. It is an internally focussed document, including discussion of options and explanation of technical processes for reference as appropriate / requested.

Method

Designated people from the relevant areas are interviewed. Notes of the interviews are produced and fed back to the interviewees for agreement. The existing IT infrastructure are documented as needed, together with any plans for upgrading and any impact of an EDM system on these proposals. The outcome of these processes are written up in a User Requirement Specification. This is circulated in draft form for comment and then issued as a final document.

What happen to our WBS?

Assalamualaikum and good evening...

Today we had our Work Breakdown Structure(WBS) presentation.We would like to apologise to our lecturer,Pn. Badariah because we cannot show our WBS. We had uploaded our WBS in the blog, but..during Pn.Badariah tried to open the link to our WBS document..however 'server not found' was stated. After our class, we went to the lab to try to open the link again, we managed to open the link and see the WBS document..we succeed. We are not sure why the link cannot be open in class. May be there's something wrong with the computer in our class.

WBS uploader

Girls... here are the links to our new WBS..... hehehehhe

WBS2.doc

WBS again..

Hello everyone...

Tomorrow we have to present our Work Breakdown Structure in the class...
Pn. Badariah told us to upload our WBS in the blog...

InsyaAllah this evening we will upload it....:)

Hope to see all of you tomorrow...
We will continue with chapter 3 tomorrow...so, be prepared before you guys come to class...

Adioss...

Work Breakdown Structure

Assalamualaikum...

Today, Pn. Badariah tought us part of chapter 3 about Planning and Managing the Project...
After about 3o minutes of lecture, we were required to sit in our own group to discuss and start doing the Work Breakdown Structure (WBS) for our project.

All of us were there, except Mumtaz... If i'm not mistaken, she was not feeling well...

Anyway, back to the group discussion...
The purpose of doing the WBS is to separate the project development into a succession of phases which are composed of steps, which are composed of activities...

WBS describes the software-development cycle for a particular project by enumerating te phases or stages of the project and breaking each into discrete tasks or activities to be done. Besides that, the WBS potrays the interactions among these activities and estimates the time that each task or activity will take. Therefore, we can say that the WBS is a timeline that shows when activities will begin and end, and when the related development products will be ready.

According to Pn. Badariah, we are required to show our WBS on our next class which is on Tuesday...

Anyway, we are still working on our schedule. We didn't manage to finish it during class...

That's all...

What is a Software Requirements Specification (SRS)

An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point intime (usually) prior to any actual design or developmentwork. It's a two-way insurance policy that assures that boththe client and the organization understand the other'srequirements from that perspective at a given point intime.

The SRS document itself states in precise and explicitlanguage those functions and capabilities a software system(i.e., a software application, an eCommerce Web site, and soon) must provide, as well as states any required constraints by which the system must abide. The SRS also functions as a blue print for completing a project with as little cost growt has possible. The SRS is often referred to as the "parent" document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it.

First Presentation

Assalamualaikum and good evening.....

Today we had our first presentation in the class...
We had no lecture...but, all groups were required to present their blogs...
We were the last group to present....

First of all... I would like to apologise to my group members...
The presentation didn't go well as we planned...
Perhaps because I was not fully prepared...and kindda nervous...
I'm sorry... I hope that I will do better in the future...:)

I would like to congratulate some of my friends who did well in their presentations.
Some of them presented very well.

We were required to present everything about the blog... from the reason we choose blogspot...up to the job distribution among the team members.
As I said during the presentation, all of us are free to update the posts anytime as we want to...
This is because, some of us might have no internet access at times, or busy with assignments and classes...therefore, anyone who is free can update the post. We did not specify the day for each of us to update the post... Anyone can update the post at anytime.

Anyway...I'm sorry because I didn't mention the right number of the post we had uploaded during the presentation this afternoon... Actually...we had uploaded 23 posts at that time...not 29 posts... I'm sorry for that... Maybe I was confused during the presentation... I just totally forgot everything....huhuhu....

I just hope that I'll be fully prepared for the second presentation...
I must say that I had learn a lesson from the first presentation and I hope that I wont repeat the same mistake...

A sample of a basic SRS outline

1. Introduction
1.1 Purpose
1.2 Document conventions
1.3 Intended audience
1.4 Additional information
1.5 Contact information/SRS team members
1.6 References

2. Overall Description
2.1 Product perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating environment
2.5 User environment
2.6 Design/implementation constraints
2.7 Assumptions and dependencies

3. External Interface Requirements
3.1 User interfaces
3.2 Hardware interfaces
3.3 Software interfaces
3.4 Communication protocols and interfaces

4. System Features
4.1 System feature A
4.1.1 Description and priority
4.1.2 Action/result
4.1.3 Functional requirements
4.2 System feature B

5. Other Nonfunctional Requirements
5.1 Performance requirements
5.2 Safety requirements
5.3 Security requirements
5.4 Software quality attributes
5.5 Project documentation
5.6 User documentation

6. Other Requirements
Appendix A: Terminology/Glossary/Definitions list
Appendix B: To be determined

Upcoming Topic

Chapter 2

• 2.3 Tools and Techniques for Process Modelling

Static Modelling

Dynamic Modelling

• 2.4 Practical Process Modeling Marvel Case Studies

Marvel Case Studies

Examples of Marvel Commands

Desirable Properties of Process Modeling

• 2.5 Information System Example

Piccadilly System

Lai Artifact Table for Piccadilly System

• 2.6 Real Time Example

Ariane-5 Software

update activities(picture)

assalamualaikum everybody..finally i upload the picture.

meeting or discussion at 26 july 2007...

group members

Laila Hana,Wawa,Wani,Baizura,Nano and Mumtaz

thank you girls...

Presentation 1

Assalamualaikum....

We'll be having our first presentation tomorrow...
huhuhu....
I hope that everything will go well...

Girls...make sure you come to class tomorrow...and don't be late.....

For tomorrow's presentation, we are required to present everthing about our blog... including the job distribution among us...

Okay...good luck everyone..
See you guys tomorrow....

Project

Assalamualaikum and good morning...

Project

About the project, we are required to produce a portal for this subject, Software Engineering. The client to this project is our lecturer, Puan Badariah. All of the requirements must be collected, analyzed, validated and documented properly from the client using methods and techniques that we learn in class. Minimally, the portal should contain the following:

• About the subject.
• Lecturer's info.
• Information related to a particular semester (also archive of information from past semesters, if any).
• Teaching/learning materials such as notes, slides etc.
• Assignments (also archive of past assignments, if any) page, inclusive of links to current student's blogs.
• Ease future maintenance, and has professional interface.
• Others that will make the portal complete and excellent.

The Deliverables

1. Assignment 1: Create a blog of group's activities throughout the project this semester.

2. Presentation 1: Present everything about the blog including job distributions among the team members.

3. Assignment 2: Produce SRS.

4. Assignment 3: Development and Delivery of Portal.

5. Presentation 2: The completed portal will be presented.

Comparison of Sofware Process Model (PART 3)

Girls; here summarized all of the software process model... hope this will help u all remember the important term(PART 3):

COMPARISON OF SOFTWARE PROCESS MODEL

AGILE MODEL
Pair programming (more on programming) *These method not being used nowadays because of critically time for market.

Comparison of Software Process Model (PART 2)

Girls; here summarized all of the software process model... hope this will help u all remember the important term(PART 2):

COMPARISON OF SOFTWARE PROCESS MODEL

OPERATIONAL SPECIFICATION MODEL	TRANSFORMATIONAL MODEL	SPIRAL MODEL
Detail up the program specification (coding) and try to execute.	Suitable for developing critical system (which definitely more complex because related to human life, environment, economic etc.	The only model that include the risk taking management (RTM)

Comparison of Software Process Model (PART 1)

Girls; here summarized all of the software process model... hope this will help u all remember the important term(PART 1):

COMPARISON OF SOFTWARE PROCESS MODEL

WATERFALL MODEL	PROTOTYPING	V MODEL
Document driven model Developer need full requirement and understanding to build the product. User should wait in a long time before the final product being release. without iteration	Developer need minimum requirement to build the product. User involved in the beginning of the developmentof the product.	Iteration from one phase to another.

Waterfall Model with Prototype

Why we had chosen Waterfall Model with Prototype, but not traditional Waterfall Model?

Weaknesses or disadvantages of traditional Waterfall Model in hand, as we decided not to choose it to be implemented to our group project:

• It is very important to gather all possible requirements during the first phase of requirements collection and analysis. If not all requirements are obtained at once the subsequent phases will suffer from it. Reality is cruel. Usually only a part of the requirements is known at the beginning and a good deal will be gathered during the complete development time.
  It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses.
• For ever changing user requirements this model will not suit, one process starts only when the previous process comes to an end.
• Iterations are only meant to happen within the same phase or at best from the start of the subsequent phase back to the previous phase. If the process is kept according to the school book this tends to shift the solution of problems into later phases which eventually results in a bad system design. Instead of solving the root causes the tendency is to patch problems with inadequate measures.
• There may be a very big "Maintenance" phase at the end. The process only allows for a single run through the waterfall. Eventually this could be only a first sample phase which means that the further development is squeezed into the last never ending maintenance phase and virtually run without a proper process.

Discussion Update

Assalamualaikum....

I would like to update more about our discussion...

As what Mumtaz said, we had a meeting on the 26th of July...right after SE class...
We discussed about the group presentation which will be held on next Tuesday...
I just hope that everything will go well...:)

About the blog, we are still working on something...to make our blog look nicer...
During the meeting, we took some pictures...hehehe.....
I don't know when Mumtaz or Wawa is going to upload it on the blog, since I don't have any of those pictures...

As Kak Nor mentioned in the earlier post, we decided to choose Waterfall Model with prototype for our project. At first, we were not so sure which model to choose. In fact, we had thought of choosing Spiral Model. But since our project is not big, we had chosen Waterfall Model with prototype as our choice... This is because, all of us are quite familiar with waterfall model...besides, it is simple and easy to understand... With prototyping, the user...which is our lecturer, Puan Badariah will be involved in the project from the beginning until the final product is produced...Therefore, InsyaAllah we will produce the right final product at the end of the project...:)

If I'm not mistaken, there was another group choose the same model as us. Some of the groups decided to choose Spiral Model, Waterfall Model, Transformational Model and Agile Method... Puan Badariah did some comments about the models that had been chosen by each group.
According to her, Spiral Model is not that suitable because it includes risk management. Since our project is not a big one, risk management is not that important... Spiral Model is suitable to handle big projects. She also said that Transformational Model is not a good choice because that model is usually applied for developing critical system. I think, we had made the right choice of choosing Waterfall Model with prototype...

Anyway, I just hope that all of our group members will cooperate well for the project... Girls, if you are not satisfied with anything, just say so... It's better to speak out now before it's too late...

All right...that's all for now...:)

discussion..26 julai 2007

1. discuss about group presentation..
2. discuss about upgrade our blog...
3. discuss about what types of process model that we want use for our project..
4. discuss about giving the task to each group members..

thank you everybody..

by Mumtaz

Choosing model

Today, we have discuss in class about Softwere Development Process Model. My group choosed Waterfall Model with Prototype for our project. We choosed this model because our group familiar and understand about that model. This model can help us to finish our project with systematic. The model has iteration steps, so that we can make the system base on what user requests.

Portal vs Website

Typical Website Attributes

• Public Interface
• Target one user type or audience.
• Support users in specific tasks such as marketing or e-commerce
• Provides targeted content from specfic resources or authors.
• Generally content focused.
• May or may not have authentication.

Typical Portal Attributes:

• Public and private interface such as extranet, intranet etc.
• Common access point for multiple user roles.
• Personalization or Role-specific functionality and content.
• Versatile or Enhanced functionality and flexibility.
• Provide users with access to broad resources.
• Support users in multiple tasks such as discovery, learning, research, purchasing, etc.
• Provides content from diverse distributed resources.
• Generally spans content, collaboration and e-commerce.
• Authentication process to "know" a user

Software Development Process Models

•Waterfall model
•V model
•Prototyping model
•Operational specification
•Transformational model
•Phased development: increments and iterations
•Spiral model
•Agile methods



by Mumtaz

Software Development Process Models

Assalamualaikum and hello....

Today we learn about types of Software Development Process Models ; Waterfall Model, V Model, Prototyping Model, Operational Specification model and others... It seems that Waterfall model is the simplest model among all..however, it provides no guidance how to handle changes to products and activities during developments...

We were reminded by Puan Badariah to choose the right model to develop our project...so that the final product will meet all the requirements...

About the project...our group will be having a meeting on Thursday at 10.a.m... right after SE class... don't forget about the meeting, girls..

Okay...that's all for now...

Summarize Of Chap 1....

Assalamualaikum...

Girls, here some key words that we need to remember ....

What is Software Engineering : Method,Tool, Procedure and Paradigm (MTPP)

What is Good Software :

1. User judge external characteristic
2. Designers and maintainer judge internal characteristic
3. diff stakeholder diff criteria
4. quality model = user external view + developer's internal view

Who does Software Engineering : Customer,User, Developer .(CUD) they are also known as the stakeholder.

System Approach :

1. Identify activities and objects
2. Define the system boundary
3. Consider nested system, systems interrelationship

Wasserman's Seven Key Factors (How has SE changed): this is very important....

1. critically time-to-market
2. shift in the economics of computing (new hardware)
3. Availability of powerful dekstop computing
4. GUI
5. Unpredictability of the waterfall model of software development.

ok girlssss. thats all for now... hope this might help u all.... Adios Senorita! (n_n)

update

hye...everybody.....
funtastic six...
tomorrow we have class isnt it?...
we already learned until the half of chapter 2 kan?...

by Mumtaz.

Next Class

Assalamualaikum and hello to everybody.....

Hope all of you are doing fine...:)

Btw...we'll be having SE class tomorrow...from 12-2 p.m....

I hope that everyone will attend the class and be prepared...

Make sure you eat something before you come to class, so that you will be able to concentrate during the lecture... Jangan perut korang menyanyi dalam class ye...:P

Okay... hope to see you guys tomorrow...:)

About "Software Engineering"

Software development is introduced to students as an engineering process. The students will acquire the knowledge of the complete software engineering process and they will be introduced to several software engineering methodologies and techniques. They will also be exposed to the process of managing software projects.

Weekend

Assalamualaikum.....

I'm sure that everybody is enjoying their weekend doing asignments... hehehe.....

Girls...don't forget that we'll be having a meeting next week...

I hope that all of us are able spend some time to study this SE subject during our weekend..
I know that some of you are busy with other stuffs...tgk wayang, jalan2 kat shopping complex, balik kampung, etc...but at least spend some time to read the notes. Maybe you guys can bring along the notes masa tengah jalan2 tu. Hehehe...

I think it's very important to read the notes and the text book before we come to class. We should always be prepared for each classes. So that, if the lecturer ask questions, we are able to give some answers. In fact, we can concentrate a lot better when the lecturer explain about that particular topic in class.. We can also ask questions to the lecturer if we don't understand something..

It's also important to read the notes or text book after the class. When we repeat the same thing again and again, the information will be transfered from short term memory to long term memory.

As conclusion, we must put effort to read the notes and text book before we come to class and try to understand it, take some notes during lecture, and read about the topic again after class.
By doing that, InsyaAllah we can achieve what we want...:)

Enjoy your weekend!! :) and don't forget to study....

Fuhh..

Actually all of us are quite busy this week because we have a lot of assignment are not finish yet.However we still not ignoring our SE project.Anyway we plan to make a group discussion coming soon for make our blog more interesting. =)

Our Meeting..

Assalamualaikum...

First of all, I would like to thank my group members for their cooperation...:)
We had finally created our blog together. We had a few meetings and we did some discussion about the project given by our Software Engineering lecturer, Pn. Badariah.

Since none of us have a blog, we tried to create the blog a few times... We had some minor arguments which can be considered as 'gaduh olok-olok'... This person said like this... The other person said like that... hehe...At one point, all of us were confused. Tak tahu yang mana satu betul... Ambik je IT...tapi semua hampeh... hehehe...

Actually, FUNTASTIC SIX came from the word FUN + FANTASTIC + 6 members... me (Laila), Wani, kak Nor, Mumtaz, Nano aka Noni, and wawa... I was appointed to be the group leader...
Maknanya ada kuasa mutlak lah nak buat apa pun... hehehe...:P Jgn marah...

By the way, we had a great time creating this blog together... Masing-masing kecoh and bising2...:P apa pun...I tetap berkuasa...hehehe...

I hope that everything will go well with the planning and everybody will participate and contribute to make our project a success...

That's all for now...:)

Introduction

The purpose of having this blog is to share our activities and expriences.
This blog will be used as our mean of communication between each other since we are taking different major..

Hope that all of us will enjoy ourselves doing this activity...:)

Welcome

Assalamualaikum and good evening.

This is the blog of our group....Funtastic Six..

Funtastic Six have 6 members...

1. Sharifah Laila Hana (IS 077984)
2. Nurzawani (IS 077976)
3. Nor Syazwani (GM 077955)
4. Nor Baizura (IS 078188)
5. Aslina Nor (SW 078606)
6. Mumtazila (GM 078322)