Projekt Shembulli , Software Engineering

7/30/2019 Projekt Shembulli , Software Engineering

1/22

DEPARTMENT OF: Informatics

Project in:Software Engineering

Topic: Topic Name

Professor: Students:Festim Halili, MSc Student 1

Student 2Student 3

Student 4


2/22

2

December, 2011

Project Title:

Name of Project

Stages required:1) Feasibility study,

2) Requirements and analyses,

3) Design/Modeling in UML (all the diagrams),

4) Formal specification of the system in Z -ZED

5) Software Project Management issues,

6) Software Life Cycle model,

7) Implementation and

8) Maintenance.

If in any case you want to be 5 people in one team then your team should cover additional 2 stages:

9) Programming and

10) Testing.

Student: Student 1 .

ID: 105163


ID: 104840


ID: 105030


ID: 104877

Professor Signature: _________________

SOFTWARE ENGINEERING - PROJECT

Name Surname IDProject Stageresponsible

Project Leader

1 Student1 105163 1, 7

2 Student 2 105030 2, 5

3 Student 3 104840 3, 6

4 Student 4 104877 4, 8

5 9 all of us


3/22

3

Deklarat pr origjinalitetin e punimit

Prvec n ato pjes n t cilt n mnyr eksplicite kemi deklaruar n t kundrt, ky

proekt sht pun personale e antarve t grupit dhe nuk kemi plagijazuar asnj pjes t

tij. Gjithashtu konfirmojm se nuk sht dorzuar n asnj form ose vllim m pare nndonj mnyr pr not ose kredit poena n ndonj lnd tjetr.

-------------------------------------------------- -----------------Nnshkrimi i t gjith Studentve Data


4/22

4

Acknowledgement

We would like to thank all of them, who contributed in progress of the project,first of all to our colleagues with their suggestions.Special thanks belong to our professor who allowed us to work on this topic,and to the assistant for the unconditioned recommendations.


5/22

5

Table of Contents

TABLE OF CONTENTS ............................................................................................................................. 5

PROJECT PROPOSAL: .......................................................................................................................... 7DOMAIN....................................................................................................................................................... 7

ABSTRACTION.......................................................................................................................................... 8

PROJECT OUTCOMES............................................................................................................................ 8

1. FEASIBILITY STUDY ............................................................................................................................ 8

INCLUDED OPERATIONS ....................................................................................................................... 8USERS TYPE.......................................................................................................................................... 8INPUTS/OUTPUTS OF THE SYSTEM ................................................................................................... 8IS TECHNICALLY AND ECONOMICALLY FEASIBLE? ............................................................................. 8

2. REQUIREMENTS AND ANALYSES ................................................................................................... 9

CRITICALTHOUGHTS ............................................................................................................................. 9USERINTERFACE ANDHUMANFACTORS............................................................................................. 9HARDWARECONSIDERATION................................................................................................................10SYSTEMINTERFACING...........................................................................................................................10QUALITYISSUES.....................................................................................................................................10SYSTEMMODIFICATION.........................................................................................................................11PHYSICALENVIRONMENT.......................................................................................................................11SECURITY.................................................................................................................................................11RESOURCES ANDMANAGEMENTISSUES.............................................................................................11

3. DESIGN/MODELING IN UML (ALL THE DIAGRAMS) ................................................................13

USE CASE DIAGRAM ...........................................................................................................................13ACTIVITY DIAGRAM ............................................................................................................................13SEQUENCE DIAGRAM

..........................................................................................................................13

COLLABORATION DIAGRAM ...............................................................................................................14CLASS DIAGRAM ..................................................................................................................................14OBJECT DIAGRAM ...............................................................................................................................14STATE DIAGRAM .................................................................................................................................14COMPONENT DIAGRAM .......................................................................................................................14DEPLOYMENT DIAGRAM .....................................................................................................................15

4. FORMAL SPECIFICATION OF THE SYSTEM IN Z -ZED ............................................................15

5. SOFTWARE PROJECT MANAGEMENT ISSUES ...........................................................................16

6. SOFTWARE LIFE CYCLE MODEL ...................................................................................................18

1. FEASIBILITY STUDY ......................................................................................................................192.REQUIREMENTS ANALYSIS ..............................................................................................................193)SYSTEM DESIGN.................................................................................................................................194)DETAILED DESIGN .............................................................................................................................205)CODING AND TESTING ......................................................................................................................207)MAINTENANCE ...................................................................................................................................20CONCLUSION: ..........................................................................................................................................20

7. IMPLEMENTATION .............................................................................................................................20

8. MAINTENANCE ....................................................................................................................................20


6/22

6

9. PROGRAMMING PART .................................................................................................................22

REFERENCES ............................................................................................................................................22


7/22

7

SOFTWARE ENGINEERING - PROJECT

Name Surname ID Project LeaderProject #Preference Comments (IF AN

1 Student 1

Propozimi yn

Ato jan n vazhdim...

2 Student 2

3 Student 3

4 Student 4

Project Proposal:

Emri i Projektit

Nisur nga fakti q projektet e shitjes online, na u bn aq tshpeshta, grupi yn vendosi q t merret me dika m konkrete dhe tpazakonshme, gj t ciln e pam si munges.

Domain

Our project aims to provide for us an experience of developing amedium-scale computing project in a small team. All aspects of the

development process are considered: problem specification, requirement

extraction, system design, implementation, integration, testing anddocumentation.Software engineering project information is frequently evolving and

queried to reflect project development changes in the softwarerequirements or in the design process, to incorporate additionalfunctionality to systems or to allow incremental improvement and the

like.Building a software product is a team effort that, besides

specialized knowledge, involves non-technical skills such as the ability tocommunicate, to work as a group, to partition, assign and monitor taskprogress, and to assume responsibility for making choices.


8/22

8

Abstraction

Project outcomes

Successful:The project is completed on time and on budget, with all features

and functions specified.

Challenged:The project is completed and operational, but over budget, late,

and with fewer features and functions that initially specified

1. FEASIBILITY STUDY

This stage has been responsibility of the student:

Name: Student 1

Included operations

Users Type

We have two kinds of users, and that:

1. AdministratorsText

2. Users Text

Inputs/Outputs of the system

Input data Outputs

Actors:

Is technically and economically feasible?

Technically feasible? Yes.


9/22


10/22

10

Hardware Consideration

The table bellows describe the hardware requirements on whichthe application will be deployed.

Requirement Performance

Processor PC with a Pentium II-class processor, 450 MHzRecommended: Pentium III-class, 600MHz

RAM ?

Available Hard Disk Space ?

Operating System ?

CD-ROM Drive or DVD-ROM ?

Video ?

Mouse ?2

System Interfacing

The systems output will be used outside the proposed system bythe billing system and the printer. This means that cannot be doneany illegal choices or, disorders.

There will be restrictions on the format or medium that must beused as input or output. The input restrictions are those of a kindthat any data already existing on the server cannot be replicated.For any certificate issued as output (from the printer) needs someinput data, as for example identity-card, passport etc.

Quality Issues

Reliability, Safety and Quality are the key words to success intoday's commercial, industrial and public sector environments

- There are minimized any unintentional disruptions in operation-The applications mean time between failures shall be at least 1month.-The components mean time between failures shall be at least 1year

2 http://msdn2.microsoft.com/en-us/library/4c26cc39(VS.71).aspx


11/22

11

- The probability that the component fails shall not exceed .001%per year3

- It is easy manageable- User friendly forms for the persons who will work on it.

System Modification

.

Physical Environment

The physical environment were the application will be deployed arethe municipality offices. Also the application will be deployed in

several offices, which means in several locations.

Security

There should be control on the system by the admin, ensuring thateventual errors will be prevented. The control of the data will bedone automatically by the application ensuring no replication orlosing data

Resources and Management Issues

According to the classic data backup schedule involved a backupto tape run at the end of each business day, so 5 backups perweek. So, the 5th backup each week, we think to be saved as aweekly backup and archived rather then being re-used in the nextweek. This pattern should continue until the end of the month.Afterwards, the last data backup of the month may likewise bestored as a monthly backup and the last backup of the year bestored as the yearly backup. The total usage breaks down asfollows:

Daily x4 tapesWeekly x4 tapes

Monthly x11 tapesYearly 1/year4

3http://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ReliabilityR

equirements.html~Contents

4http://free-backup.info/how-often-should-i-backup-my-data.html
http://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ReliabilityRequirements.html~Contentshttp://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ReliabilityRequirements.html~Contentshttp://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ReliabilityRequirements.html~Contentshttp://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ReliabilityRequirements.html~Contentshttp://free-backup.info/how-often-should-i-backup-my-data.htmlhttp://free-backup.info/how-often-should-i-backup-my-data.htmlhttp://free-backup.info/how-often-should-i-backup-my-data.htmlhttp://free-backup.info/how-often-should-i-backup-my-data.htmlhttp://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ReliabilityRequirements.html~Contentshttp://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ReliabilityRequirements.html~Contents


12/22

12

As usual, system administrators are responsible for the backup

and recovery of systems within their enterprise environment5.Wesuppose that for our application data, the only administratorwhich is involved in the general and most important stuff must

have this responsibility of backing up the data.

He (the administrator) should be responsible also for the systeminstallation, and for the common system maintenances.

5http://www.sun.com/training/catalog/courses/VT-269.xml
http://www.sun.com/training/catalog/courses/VT-269.xmlhttp://www.sun.com/training/catalog/courses/VT-269.xmlhttp://www.sun.com/training/catalog/courses/VT-269.xmlhttp://www.sun.com/training/catalog/courses/VT-269.xml


13/22

13

3. DESIGN/MODELING IN UML (ALL THE DIAGRAMS)


Name: Student3 Surname: ID: 104840

Designing and modeling the UML diagrams, undoubtedly is one of themost important fazes, which weights a lot in the well-doing of the projectthat is being developed. Under way, we hope to concentrate deeper in thediagrams in Unified Modeling Language (UML).

Use Case Diagram

This diagram shows from higher site, what in fact have to do with.

There are mentioned general actors and the general processes aroundwhich are placed all the others

Activity Diagram

As we know, activity diagram represent the business andoperational workflow of a system. An activity diagram is a dynamicdiagram that shows the activity and the event that causes the object to

be in the particular state. In our case, the activity diagram describes thesituation of requesting certificate. First, the user requests a certificate,and employee will have to log-in to system by typing username andpassword...

Sequence Diagram

A sequencediagram depicts the sequence of actions that occur in asystem. The invocation of methods in each object, and the order in which

the invocation occurs is captured in a sequence diagram


14/22

14

Collaboration Diagram

A collaboration diagram is very similar to a sequence diagram, and

a distinguished feature of collaboration diagram is that it shows theobjects and their association with other objects in the system apart from

how they interact with each other .

Class Diagram

Class diagram consists of group of classes and interfaces reflectingimportant entities of the business domain of the system being modeled,and the relationships between these classes and interfaces.

Object Diagram

An object diagram shows relations between the instantiatedclasses and the defined class, and the relation between these objects inthe logical view of the system.

State Diagram

State diagrams are used to describe the behavior of a system, anddescribes all of the possible states of an object as event occur

Component Diagram

Component diagram represent different high level reusable parts ofa system, also captures the interrelationships between these parts. Alsorepresent the implementation perspective of a system.


15/22

15

Deployment Diagram

Deployment diagram captures the configuration of the runtimeelements of the application and more useful when a system I built and

ready to be deployed.

4. FORMAL SPECIFICATION OF THE SYSTEM IN Z -ZED


Name: Student4 Surname ID: 104877

The mathematical representation of project things, sounds of akind to this tables you see.


16/22

16

5. SOFTWARE PROJECT MANAGEMENT ISSUES



The Critical Path Method (CPM) is one of several related techniquesfor doing project planning. CPM is for projects that are made up of anumber of individual "activities." If some of the activities require otheractivities to finish before they can start, then the project becomes acomplex web of activities

Estimate Activity Times

Weeks are a commonly used unit of time for activity completion, but anyconsistent unit of time can be used.

Expected time = ( Optimistic + 4 x Most likely + Pessimistic ) / 6

Critical Path

MLT = 24

CP: 10607080110

CP: 15 202580110

According to calculations we have this result:

Ot = 19Pt = 32

AndExpected time = ( Optimistic + 4 x Most likely + Pessimistic ) / 6

Expected time = 25


17/22

17

The diagram showing the cost vs project completion time

And the diagram showing the resource used for the time passed.


18/22

18

6. SOFTWARE LIFE CYCLE MODEL



The two big advantages of the pure

waterfall model are producing a"highly reliable system" and one

with a "large growth envelope"

- Steve McConnell

Software life-cycle modeling is the business of tracking source codeas it goes through various stages throughout its life, from development,to testing, release, reuse, and retirement.

It has seven stages:

1. Feasibility Study

2. Analysis3. System design4. Detailed design5. Coding & Testing6. Integration & Testing

7. Maintenance


19/22

19

We think its more appropriate for the development of our softwarebecause:

1. Feasibility study

This phase is concerned about collection of requirement of the system.

Our project will consist of data about

In this phase we will emphasize on Algorithm Data structure

Software Architecture

Interface design

Technically feasible? Yes.Economically feasible? Yes.

After feasibility study, we will provide a document that holds thedifferent specific recommendations .

2. Requirements Analysis

In systems engineering and software engineering, requirements analysis

encompasses those tasks that go into determining the requirements of anew or altered system, taking account of the possibly conflictingrequirements of the various stakeholders, such as users. Requirementsanalysis is critical to the success of a project.6

3) System design

Before a starting for actual coding, it is highly important tounderstand what we are going to create and what it should look like?The requirement specifications from first phase are studied in this

phase and system design is prepared

6"Software Requirements", in Executive editors: Alain Abran, James W. Moore; 2004 Version, Los

Alamitos
http://www.swebok.org/ch2.htmlhttp://www.swebok.org/ch2.htmlhttp://www.swebok.org/ch2.htmlhttp://www.swebok.org/ch2.html


20/22

20

4) Detailed design

Development of the complete specification of each module's internalstructure.

Speaking about the design particularly about our project we arethinking about the system to have two types of interfaces

5) Coding and Testing

In this phase we have started his coding in order to give a full sketchof product. The design must be decoded into a machine-readableform

6) Integration & Testing

In this phase all programs(models) are integrated and tested ensure tothat the complete system meet the software requirements After codegeneration phase the software program testing begins

7) Maintenance

Software will definitely go through change once when it is delivered tothe customer.

Conclusion:

In conclusion i will prefer to say Waterfall Model is a document driven and wellorganized .

7. IMPLEMENTATION



Implementation refers to the final process of moving the solution fromdevelopment status to production status

8. MAINTENANCE




21/22

21

The maintenance problem surely is one of the most important stages, inwhich the company should give maximal forces in order to fulfill the

needs of the customers .This stage knows to take a lot of time. Nevertheless, this activity is

notable, considering the fact that two-thirds of a software system's

lifetime cost involves maintenance (Page-Jones pg 31).7

Maintenance Checklist

A procedure exists for handling emergency changes that

cannot be implemented as part of a scheduled release.

An identification number is assigned to the modification.

The modification is categorized as corrective, adaptive,

emergency, scheduled, perfective, mandatory, required, or nice

to have.

The modification is analyzed to determine whether to accept,

reject or further evaluate.

Changes are assigned an initial priority ranking.

Modification requests and process determinations have been

uniquely identified and placed into the project file.

A peer review has been conducted (as appropriate) on

problem/modification identification

Metrics are recorded (e.g., number of requests, time expended

for problem validation)

A preliminary estimate of the modification size/magnitude

has been made.

Not every dot of them has to be considered as obligatory, but thereare some of them that are necessary. For those, it is left to the team andthe objective needs.

7http://en.wikipedia.org/wiki/Software_maintenance8http://cio.energy.gov/documents/maintenance.pdf

Metrics are recorded (e.g., number of requests, time expended

for problem validation).

A preliminary estimate of the modification size/magnitude

has been made.

The impact of the modification has been assessed.

Consultation has been provided on future enhancements.8
http://en.wikipedia.org/wiki/Software_maintenancehttp://en.wikipedia.org/wiki/Software_maintenancehttp://en.wikipedia.org/wiki/Software_maintenancehttp://cio.energy.gov/documents/maintenance.pdfhttp://cio.energy.gov/documents/maintenance.pdfhttp://cio.energy.gov/documents/maintenance.pdfhttp://cio.energy.gov/documents/maintenance.pdfhttp://en.wikipedia.org/wiki/Software_maintenance


22/22

9. PROGRAMMING PART

This part was a work of the all project team in order to gain the extrapoints mentioned from the professor.It was made in c#, as a possibility to be combined with MS SQL

database, MS Access or MySQL Some screenshots of the applicationare given below:

REFERENCES

1. Subjectlectures and examples

2. Pacestar UML Diagrammer V5.0 User Guide.pdf

3. "Software Requirements", in Executive editors: Alain Abran, James W. Moore;

2004 Version, Los Alamitos

4. http://msdn2.microsoft.com/en-us/library/4c26cc39(VS.71).aspx

5. http://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/R

equirements/ReliabilityRequirements.html~Contents

6. http://free-backup.info/how-often-should-i-backup-my-data.html

7. http://www.sun.com/training/catalog/courses/VT-269.xml

8. http://en.wikipedia.org/wiki/Software_maintenance

9. http://cio.energy.gov/documents/maintenance.pdf
http://www.swebok.org/ch2.htmlhttp://www.swebok.org/ch2.htmlhttp://www.swebok.org/ch2.htmlhttp://msdn2.microsoft.com/en-us/library/4c26cc39(VS.71).aspxhttp://msdn2.microsoft.com/en-us/library/4c26cc39(VS.71).aspxhttp://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ReliabilityRequirements.html~Contentshttp://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ReliabilityRequirements.html~Contentshttp://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ReliabilityRequirements.html~Contentshttp://free-backup.info/how-often-should-i-backup-my-data.htmlhttp://free-backup.info/how-often-should-i-backup-my-data.htmlhttp://www.sun.com/training/catalog/courses/VT-269.xmlhttp://www.sun.com/training/catalog/courses/VT-269.xmlhttp://en.wikipedia.org/wiki/Software_maintenancehttp://en.wikipedia.org/wiki/Software_maintenancehttp://cio.energy.gov/documents/maintenance.pdfhttp://cio.energy.gov/documents/maintenance.pdfhttp://cio.energy.gov/documents/maintenance.pdfhttp://en.wikipedia.org/wiki/Software_maintenancehttp://www.sun.com/training/catalog/courses/VT-269.xmlhttp://free-backup.info/how-often-should-i-backup-my-data.htmlhttp://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ReliabilityRequirements.html~Contentshttp://www.opfro.org/index.html?Components/WorkProducts/RequirementsSet/Requirements/ReliabilityRequirements.html~Contentshttp://msdn2.microsoft.com/en-us/library/4c26cc39(VS.71).aspxhttp://www.swebok.org/ch2.html

Documents

Projekt Shembulli , Software Engineering