Had an interview with Peter. Here are the list of points noted down.

• The system should be user friendly, with adequate training for Sonium's 600 staff.
• System should be able to integrate data, photos, feeds, bookmarking
• System should be able to crop, delete, add, edit, categorize the photos
• Users should be able to choose their feeds, subscribe, create, edit, delete.
• Uploading of photos should be done by proper and relevant staff.
• Picture Formats should have JPEG, GIF, Bitmap and subsets of it.
• Database should be stored in a central server.
• Information should be accessible 24/7, but users have different access rights.
• System should be able to filter pictures like adult-oriented pictures
  
• System should support mainly Windows and/or more OS(s)
• System should run smoothly and efficiently on a Pentium 3 Computer with 2GB RAM.
  
• Automatic Data Backup should be done weekly, and be stored in the central server.
  

Did the research on some Team Structures before choosing the best and implementing it. Here are the findings.

Process/Functionally Team Structure

In this structure the major functional areas have been addressed by teams focused on that area. The team would have a mix of people so that all the necessary skills, knowledge and understanding are collectively within that team, subject to any further specialized support that is needed.

Process Structure Team – With Detail

The main teams have been defined to support the major business processes within the scope of the project. Specialised shared service teams have been set up - one for all the technical support areas and one for non-technical general and specialised support, eg change management and training.

Resource Pool Structure

This structure is based on the traditional resource pool concept. Teams are constructed from similar types of resource. People often feel more comfortable in teams like this, but they do not necessarily combine together so effectively to produce solutions. For any given issue, a combination from different teams will need to communicate and collaborate. For example, design by prototyping would be conducted by members of the user team and the applications team.

Selection of Team Structure

Based on the above analysis, our group has decided to implement the Process/Functional Team Structure because of the fact that the team would have a mix of people so that all the necessary skills, knowledge and understanding are collectively within that team, subject to any further specialized support that is needed.

Our group has chose to implement the Unified Process as the Software Process. Reason being that the Unified Process has taken into considerations about the section on risk management, ensuring that the whole project process has been taken care of from the start.

Extract of risk management below.

The Unified Process requires the project team to focus on addressing the most critical risks early in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase, must be selected in order to ensure that the greatest risks are addressed first.

Difference between Waterfall and Unified Process

The main difference between the Waterfall model and the Unified Process is that the Waterfall model proceeds from one phase to the next in a purely sequential manner, while the Unified Process’ phases are divided into a series of timeboxed iterations.

Are we able to go back one step in the Waterfall model?

No, the Waterfall model strongly recommends that one should move to another phase only when it’s current phase is completed and perfected. It also states that phases of development in the waterfall model are discrete, and there is no jumping back and forth or overlap between them

Why are there many spirals in the Spiral Model and What is the benefit of it.

The reason to why there are many spirals in the Spiral Model is so that the project team is able to take advantage of the development process as they work best when they are both incremental in repetitive. The benefit of the spirals in the Spiral Model is that the project team is able to start small and benefit from trial and error steps along the way.

What do you mean the Unified Process is "iterative" and What is an "iterative" in the Unified Process?

It means that the Unified Process is repetitive. The Unified Process is based on repetitions, where each repetitive result in an increment, which is a release of the system that contains added or improved functionality

In the Spiral model, what is "rapid prototyping"?

Rapid Prototyping is the creation of a working model of the software to demonstrate the feasibility of the function before the release of the final end product.

Did some research together about software processes and examples of it, here are the findings.

Software Processes are networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. Their power emerges from their utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing.




Jessica did the research on the Waterfall Process.

The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance.

To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes "requirements specification" — they set in stone the requirements of the software. When the requirements are fully completed, one proceeds to design. The software in question is designed and a "blueprint" is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, disparate software components produced by different teams are integrated. After the implementation and integration phases are complete, the software product is tested and debugged; any faults introduced in earlier phases are removed here. Then the software product is installed, and later maintained to introduce new functionality and remove bugs.

Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are discrete, and there is no jumping back and forth or overlap between them.

Serene did the research on the Spiral Process.

While the waterfall methodology offers an orderly structure for software development, demands for reduced time-to-market make its series steps inappropriate. The next evolutionary step from the waterfall is where the various steps are staged for multiple deliveries or handoffs. The ultimate evolution from the water fall is the spiral, taking advantage of the fact that development projects work best when they are both incremental and iterative, where the team is able to start small and benefit from enlightened trial and error along the way.

The spiral methodology reflects the relationship of tasks with rapid prototyping, increased parallelism, and concurrency in design and build activities. The spiral method should still be planned methodically, with tasks and deliverables identified for each step in the spiral.

Truman did the research on the Documentation Model.

The reality is that increased processes usually result in increased documentation. An improved process produces intermediate work products that represent the elaboration of the product design at each step in the development life cycle. Where possible, documentation should be generated using automated tools, so outputs can contribute to generation of code structures or help generate the code itself.

The difference between hacking and software engineering is professional discipline applied with common sense. Software quality, reliability, and maintainability are enhanced by having good documentation for requirements, architecture, interfaces, detailed design, well-commented code, and good test procedures. Requirements documentation practices should facilitate your customer's understanding and review of the real requirements. Software project planning should include estimating the time and resources to produce, review, approve, and manage such documentation products.

Derrick did the research on Unified Process.

The Unified Software Development Process or Unified Process is a popular iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process or RUP.

The Unified Process is not simply a process, but rather an extensible framework which should be customized for specific organizations or projects.

Iterative and Incremental

The Unified Process is an iterative and incremental development process. The Elaboration, Construction and Transition phases are divided into a series of timeboxed iterations. (The Inception phase may also be divided into iterations for a large project.) Each iteration results in an increment, which is a release of the system that contains added or improved functionality compared with the previous release.

Although most iterations will include work in most of the process disciplines (e.g. Requirements, Design, Implementation, Testing) the relative effort and emphasis will change over the course of the project.

Use Case Driven

In the Unified Process, use cases are used to capture the functional requirements and to define the contents of the iterations. Each iteration takes a set of use cases or scenarios from requirements all the way through implementation, test and deployment.

Architecture Centric

The Unified Process insists that architecture sit at the heart of the project team's efforts to shape the system. Since no single model is sufficient to cover all aspects of a system, the Unified Process supports multiple architectural models and views.

One of the most important deliverables of the process is the executable architecture baseline which is created during the Elaboration phase. This partial implementation of the system serves to validate the architecture and act as a foundation for remaining development.

Risk Focused

The Unified Process requires the project team to focus on addressing the most critical risks early in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase, must be selected in order to ensure that the greatest risks are addressed first.

Hafiz did the research on the V-Model.

The V-model is a software development model which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

Requirements analysis

In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase.

With some extra time on our hands, we decided to do research on a last model, the Chaos Model as a group.

In computing, the Chaos model is a structure of software development that extends the spiral model and waterfall model.

The chaos model notes that the phases of the life cycle apply to all levels of projects, from the whole project to individual lines of code.

• The whole project must be defined, implemented, and integrated.
• Systems must be defined, implemented, and integrated.
• Modules must be defined, implemented, and integrated.
• Functions must be defined, implemented, and integrated.
• Lines of code are defined, implemented and integrated.

One important change in perspective is whether projects can be thought of as whole units, or must be thought of in pieces. Nobody writes tens of thousands of lines of code in one sitting. They write small pieces, one line at a time, verifying that the small pieces work. Then they build up from there. The behavior of a complex system emerges from the combined behavior of the smaller building blocks.

There are several tie-ins with chaos theory.

• The chaos model may help explain why software tends to be so unpredictable.
• It explains why high-level concepts like architecture cannot be treated independently of low-level lines of code.
• It provides a hook for explaining what to do next, in terms of the chaos strategy.

Comments please, thanks!

testing testing
testing 1, 2, 3

cheong pandai here! >_<"